10. IoT Agents
▪ Device Protocol to NGSI Bridge:
• One entity per device.
• Constrained set of interactions.
▪ Design principles:
• Modular approach.
• Deployment flexibility.
• Simplify the creation of Custom IoT Agents.
▪ Provisioning of devices and groups of devices.
▪ IoT Manager.
▪ Additional services (e.g. security, device registration, stats).
10
11. Integration with sensor networks
▪ Smart solutions need to deal with the wide variety of IoT protocols today
▪ Rather than trying to solve the battle of standards at IoT level, it brings a
standard where no standard exists today: context information management
11
Context Broker
IoT
Agent-1
IoT
Agent-2
IoT
Agent-n
IoT Agent
Manager
create/monitor
IoT Framework
Standard API (northbound interface)
(southbound interfaces)
MQTTETSI M2M IETF CoAP
12. Transport & Payload
▪ Device protocol = transport protocol + payload format
▪ Transports protocols
• HTTP
• MQTT
• Others
▪ Payload format
• UL (ultralight)
• JSON
• Others
▪ Transport and payload format are orthogonal, e.g.
• HTTP transport using JSON payload
• MQTT transport using JSON payload
• HTTP transport using UL payload
• MQTT transport using UL payload
• Etc.
12
Physical
Link
TCP
MQTT
Physical
Link
TCP
HTTP
14. Ultralight 2.0 (Measures)
▪ Simple HTTP-based protocol
▪ Measure reporting:
• Key/Value pairs separated by | and #
• POST request with plain/text content to the IoTA path:
POST http://{{host}}:{{iota_ul-port}}/iot/d?k=&i={{device-id}}&t=2016-03-01T10:00:00Z
▪ Payload example:
t|34#h|87#l|1900
▪ Required query params
• k: Service API Key
• i: Device ID
▪ Optional query params
• t: timestamp of the measure 14
23. Attribute types
▪ Active attributes
• Actively updated to CB
▪ Lazy attributes
• Kept at the device, obtained using the CPr-forwarding mechanism
▪ Static attributes
• As active attributes, but with a “fixed” value
▪ Commands
• For actuation capabilities
• Managed in a similar way to lazy attributes, but involving also an
info and a status CB attributes
23
24. Interaction models: Active & Static
Attributes
24
IOT Agent
DB
Device
Protocol
NGSI
Entity information
Interaction
begins
26. Static attributes
▪ Similar to active attributes but…
• They don’t correspond to actual measures sent by the physical device
• They have a fixed value
• They are attached to every IOTA-to-CB update operation
▪ Q: Why using static attributes?
26
…
"static_attributes": [
{ "name": "serialID", "type": "02598347", "value": "02598347" }
]
…
27. Interaction models: Lazy Attributes &
Commands
27
IOT Agent
Device
Protocol
NGSI
Command
Execution
Interaction
begins
Result Information
Requires the IOT Agent to be
registered as a Context
Provider
28. Lazy attributes
▪ Q: Why all this complication? Why don’t use only active attributes?
28
…
"lazy":[
{ "object_id": "l", "name": "luminosity", "type": "percentage" }
],
…
29. Commands
▪ Three supporting attributes at CB (per command)
• <cmd> (write), the one used by the application (through update context at
CB) in order to execute command
• <cmd>_status (read only), the one in which IOTA published status
□ UNKNOWN: transient status, just after device provisioning and before any
execution is done
□ PENDING: command execution is in progress
□ ERROR: command execution finished in error status
□ FINISHED: command execution finished in ok status
• <cmd>_info (read only): upon completion, the result of the command
execution (if any) is published by IOTA in this attribute
▪ Example:
• turn
• turn_info
• turn_status
29
…
"commands": [
{ "object_id": "u", "name": "turn", "type": "string" }
],
…