XMPP IoT Sensor Data (XEP-0323)

Sensor Data
XMPP & XEP-0323
Peter Waher
https://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'
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'>
</timestamp>
</node>
</fields>
</message>

Simple Publish/Subscribe (presence)
<presence>
</timestamp>
</node>
</fields>
</presence>

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'
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)

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

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.

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.

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.

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://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

XMPP IoT Sensor Data (XEP-0323)

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to XMPP IoT Sensor Data (XEP-0323) (20)

More from Peter Waher (20)

Recently uploaded (20)

XMPP IoT Sensor Data (XEP-0323)