Upload
peter-waher
View
413
Download
2
Embed Size (px)
Citation preview
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='[email protected]/amr' to='[email protected]/123' id='S0001'> <req xmlns='urn:xmpp:iot:sensordata' seqnr='1' momentary='true'/></iq>
<iq type='result' from='[email protected]/123' to='[email protected]/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='[email protected]/amr' to='[email protected]/123' id='S0001'> <req xmlns='urn:xmpp:iot:sensordata' seqnr='1' momentary='true'/></iq>
<iq type='result' from='[email protected]/123' to='[email protected]/amr' id='S0001'> <accepted xmlns='urn:xmpp:iot:sensordata' seqnr='1'/></iq>
<message from='[email protected]/123' to='[email protected]/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='[email protected]/amr' to='[email protected]/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