Sensor DataXMPP & XEP-0323

Peter Waherhttps://linkedin.com/in/peterwaher

Design principles Loosely coupled architecture Generic approach Interoperable interfaces Security Maximize possible number of use cases Support multiple communication patterns Minimize latency in feedback Support both M2M and H2M interfaces.

Loosely Coupled Architecture Interfaces do not presuppose knowledge about contents. Sufficient meta-data exists for services, devices and users

to interact. Sufficient information exists to manage both machine

(M2M) and human (H2M) interfaces. Allows for abstract bulk processing algorithms, such as

data storage, transportation, conversion, presentation, processing, logging, management, administration, etc. regardless of type of device.

Content base can be freely updated or extended, without updating underlying infrastructure or software.

Allows for a separation of responsibilities between: Thing manufacturers Infrastructure providers Service providers

Loosely Coupled Architecture Insensitive to changes:

Software should not have to be updated when… New types of devices are added Devices are updated New types of services are introduced Services are updated

Support ad hoc networks Descriptive meta-data

Allows participants to adapt themselves M2M H2M Information about a device, lies in the device.

Requires abstraction

Security in XMPP Global unique identities Authentication Forwarded identities Authorization Pseudonymization instead of

anonymization Encryption End-to-end encryption IoT Discovery (safe discovery), XEP-0347 Provisioning, XEP-0324

Use cases Client initiates readout

Request/Response Sensor initiates readout

Event subscription (Observe) Messages PubSub / Multicast

Sensors fast in responding Directly connected

Sensors slow in responding Queued in a concentrator Slow communication medium

Simple sensors Complex sensors

“Meters” Quality of Service Partial readouts

Three axes of sensor data Device, or “Node” Timestamp Field

Field data types Single value types

boolean date dateTime duration int long string time

Enumeration (enum) Has value and enumeration type attributes

Physical Quantity (numeric) Has value, precision and unit.

Request/Response, Simple Case<iq type='get'       from='client@example.org/amr'       to='device@example.org/123'       id='S0001'>      <req xmlns='urn:xmpp:iot:sensordata' seqnr='1' momentary='true'/></iq>

<iq type='result'       from='device@example.org/123'       to='client@example.org/amr'       id='S0001'>      <fields xmlns='urn:xmpp:iot:sensordata' seqnr='1' done='true'>         <node nodeId='Device01'>            <timestamp value='2013-03-07T16:24:30'>               <numeric name='Temperature' momentary='true'

automaticReadout='true' value='23.4' unit='°C'/>             </timestamp>         </node>      </fields></iq>

Request/Response, General Case

Asynchronous Response<iq type='get'       from='client@example.org/amr'       to='device@example.org/123'       id='S0001'>      <req xmlns='urn:xmpp:iot:sensordata' seqnr='1' momentary='true'/></iq>

<iq type='result'       from='device@example.org/123'       to='client@example.org/amr'       id='S0001'> <accepted xmlns='urn:xmpp:iot:sensordata' seqnr='1'/></iq>

<message from='device@example.org/123'            to='client@example.org/amr'>      <fields xmlns='urn:xmpp:iot:sensordata' seqnr='1' done='true'>         <node nodeId='Device01'>            <timestamp value='2013-03-07T16:24:30'>               <numeric name='Temperature' momentary='true'

automaticReadout='true' value='23.4' unit='°C'/>             </timestamp>         </node>      </fields></message>

Simple Publish/Subscribe (presence)

<presence>      <fields xmlns='urn:xmpp:iot:sensordata' seqnr='1' done='true'>         <node nodeId='Device01'>            <timestamp value='2013-03-07T16:24:30'>               <numeric name='Temperature' momentary='true'

automaticReadout='true' value='23.4' unit='°C'/>             </timestamp>         </node>      </fields></presence>

Rejection

Asynchronous failure

Cancellation

Multiple devices (ties into XEP-0326)

Field Types (Categories) Fields can be categorized using a Field Type:

momentary identity status peak computed historical*

Second, Minute, Hour, Day, Week, Month, Quarter, Year Other

Special Field Types: all (implies all fields, regardless of type) historical (implies all historical fields, regardless of period)

Partial Readout (Field Types)

<iq type='get'       from='client@example.org/amr'       to='device@example.org/123'       id='S0001'>      <req xmlns='urn:xmpp:iot:sensordata' seqnr='1’ historical='true’ from=’2013-03-01T00:00:00’ to=’2013-04-01T00:00:00’/></iq>

Partial Readout (Specifying Fields)

Scheduling a readout

Partial Readout (Field Types) Fields can be categorized using a Field Type:

momentary identity status peak computed historical*

Second, Minute, Hour, Day, Week, Month, Quarter, Year Other

Special Field Types: all (implies all fields, regardless of type) historical (implies all historical fields, regardless of period)

Optional QoS levels for fields

Localization (H2M)

Localization (H2M)

Strings vs. EnumerationsThis protocol has avoided the use of enumerations for data types such as units, field names, etc., and instead use strings. The reasons for this are:

Enumerations would unnecessarily restrict the use of the protocol to field names and units listed in the protocol.

It would be very difficult to try to create a complete set of field names and units that would suit all applications.

Leaving these values as strings would let developers the liberty to use units as they desire.

If EXI is used for compression, the use of strings will only increase payload slightly, with only one copy of each distinct value used.

If EXI is not used, this does not affect packet size.

However, some things need to be taken into account:

Since free strings are used, XML validation cannot be used to secure correct names are used.

xep-0000-IoT-Interoperability lists recommendations on how field names and units should be used in order to achieve maximum interoperability in SN.

Consumers of sensor data need to include unit conversion algorithms.

Related XEPsList of related XEPs:

Security related to sensor data, and who can read what, is described in XEP-0324 – Provisioning.

Control of parameters in a device, is described in XEP-0325 – Control.

Discovery & Management of nodes in a Concentrator, is described in XEP-0326 – Concentrators.

Device Life Cycle and Ownership is described in XEP-0347 – Discovery.

Event Subscription (Observe pattern) of Sensor Data, is described in the proto-XEP: IoT Events.

Interoperability Interfaces defining Sensor Data contracts for conceptual devices, is described in proto-XEP: Interoperability.

TO DOKnown issues that have to be addressed in the XEP:

Correct JIDs in. Document the direct response use case, with example. Document the presence use case, either in XEP-0323 or in

separate IoT Publish/Subscribe XEP. Update image in rejection use case.

Links & Resourceshttp://xmpp.org/http://xmpp.org/about/xmpp-standards-foundation.htmlhttp://xmpp.org/uses/internet-of-things.htmlhttp://wiki.xmpp.org/web/Tech_pages/SensorNetworkshttp://www.xmpp-iot.org/https://xmpp.net/http://xmpp.org/extensions/xep-0323.htmlhttp://xmpp.org/extensions/xep-0324.htmlhttp://xmpp.org/extensions/xep-0325.htmlhttp://xmpp.org/extensions/xep-0326.htmlhttp://xmpp.org/extensions/xep-0347.htmlhttp://www.xmpp.org/extensions/inbox/iot-events.html http://htmlpreview.github.io/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/xep-0000-IoT-Interoperability.html https://prezi.com/esosntqhewhs/iot-xmpp/http://www.slideshare.net/peterwaher/iot-harmonization-using-xmpp