This document outlines design principles and specifications for using XMPP and XEP-0323 to transmit sensor data in a loosely coupled, interoperable, and secure manner. Key aspects covered include supporting request/response and publish/subscribe communication patterns, representing sensor readings and metadata, and ensuring flexibility through the use of descriptive strings rather than enumerations. Related XEPs for security, device management, and event subscription are also referenced.

1. Sensor Data
XMPP & XEP-0323
Peter Waher
https://linkedin.com/in/peterwaher

2. 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.

3. 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

4. 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

5. 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

6. 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

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

8. 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.

9. 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>

10. Request/Response, General Case

11. 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>

12. 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>

13. Rejection

14. Asynchronous failure

15. Cancellation

16. Multiple devices (ties into XEP-0326)

17. 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)

18. 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>

19. Partial Readout (Specifying Fields)

20. Scheduling a readout

21. 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)

22. Optional QoS levels for fields

23. Localization (H2M)

24. Localization (H2M)

25. Strings vs. Enumerations
This 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.

26. Related XEPs
List 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.

27. TO DO
Known 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.

28. Links & Resources
http://xmpp.org/
http://xmpp.org/about/xmpp-standards-foundation.html
http://xmpp.org/uses/internet-of-things.html
http://wiki.xmpp.org/web/Tech_pages/SensorNetworks
http://www.xmpp-iot.org/
https://xmpp.net/
http://xmpp.org/extensions/xep-0323.html
http://xmpp.org/extensions/xep-0324.html
http://xmpp.org/extensions/xep-0325.html
http://xmpp.org/extensions/xep-0326.html
http://xmpp.org/extensions/xep-0347.html
http://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