This document provides an overview of IoT agents, which serve as a bridge between various IoT device protocols and the NGSI standard by translating specific protocols to facilitate communication. It outlines transport mechanisms, message protocols, and the roles of northbound and southbound traffic in accessing and controlling IoT devices. Additionally, it explains how IoT agents can be configured and highlights their flexibility in integrating with different protocols and services.

1. Session 2 - What is an IoT Agent?
Fernando López, Cloud & Platform Senior Expert
fernando.lopez@fiware.org
@flopezaguilar
FIWARE Foundation, e.V.

2. Learning Goals
What is a transport? What is a message protocol?
What do the terms northbound/southbound and
north/south port mean ?
How are commands and measurements processed?
What is an IoT Agent? What does it do?
How can I configure up an IoT Agent over HTTP?
How can I configure an IoT Agent over MQTT?
1

3. IoT Agents
2
● Device Protocol to NGSI Bridge:
o One entity per device.
o Constrained set of interactions.
● Design principles:
o Modular approach.
o Deployment flexibility.
o Simplify the creation of Custom IoT Agents.
● Provisioning of devices and groups of devices.
● Additional services (e.g. security, device registration, stats).

4. Integration with sensor networks
3
● 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
Context Broker
IoT
Agent-1
IoT
Agent-2
IoT
Agent-n
Standard API (northbound interface)
(southbound interfaces)
MQTTETSI M2M IETF CoAP

5. IoT Sensor Transport & Message Format
4
The transport is the mechanism through
which messages are exchanged (HTTP,
MQTT, …).
The message protocol is the format of data
exchanged (JSON, Ultralight 2.0, Binary, …)
The South Port of an IoT Agent is listening to
traffic from IoT Devices
The North Port of an IoT Agent is listening to
command traffic to IoT Devices

6. IoT Agent for Ultralight 2.0 over HTTP
5
The IoT Agent translates an IoT specific protocol
(in this case UltraLight 2.0) into NSGI v2
The North Port of an IoT Agent is listening to
traffic from the Context Broker
The North Port of an IoT Agent is also used
during configuration
For HTTP Transports the South Port of an IoT
Agent is listening to traffic from IoT Devices.

7. IoT Agent for Ultralight 2.0 over MQTT
6
Every IoT Agent supports a single message
format
Some IoT Agents can be configured to use
alternative transports (e.g. HTTP, MQTT, AMQP)
In all cases, the North Port of an IoT Agent is:
● Listening to traffic from the Context Broker
● Used during configuration
The precise meaning of South Port may differ
according to the transport in use.

8. Northbound Traffic : Processing a Measurement
Requests generated from an IoT device
and passed back upwards towards the
Context Broker (via an IoT agent) are
known as northbound traffic.
Northbound traffic consists of
measurements made by sensor devices
and relays the state of the real world
into the context data of the system.
7

9. Southbound Traffic : Processing a Command
HTTP requests generated by the
Orion Context Broker and passed
downwards towards an IoT
device (via an IoT agent) are
known as southbound traffic.
Southbound traffic consists of
commands made to actuator
devices which alter the state of
the real world by their actions.
8

10. Attribute types
9
● Active attributes
o Actively updated to CB
● Lazy attributes
o Kept at the device, obtained using the CPr-forwarding mechanism
● Static attributes
o As active attributes, but with a “fixed” value
● Commands
o For actuation capabilities
o Managed in a similar way to lazy attributes, but involving also an info and a status CB attributes

11. Interaction models: Active & Static Attributes
10
Device
Protocol
NGSI
Interaction
begins
Orion
Context
Broker
IoT
Agent
DB
Entity
information

12. Active attributes
11
…
"attributes": [
{ "object_id": "t", "name": "temperature", "type": "float" },
{ "object_id": "h", "name": "humidity", "type": "float" }
],
…

13. Static attributes
12
…
"static_attributes": [
{ "name": "serialID", "type": "02598347", "value": "02598347" }
]
…
● Similar to active attributes but…
o They don’t correspond to actual measures sent by the physical device
o They have a fixed value
o They are attached to every IOTA-to-CB update operation
● Q: Why using static attributes?

14. Interaction models: Lazy Attributes & Commands
13
Device
Protocol
NGSI
Result
information
Interaction
begins
Orion
Context
Broker
IoT
Agent
DB
Command
Execution
Requires the IOT Agent to
be registered as a Context
Provider

15. Lazy attributes
14
…
"lazy":[
{ "object_id": "l", "name": "luminosity", "type": "percentage" }
],
…
● Q: Why all this complication? Why don’t use only active attributes?

16. Commands
15
● Three supporting attributes at Context Broker (per command)
o <cmd> (write), the one used by the application (through update context at CB) in order to execute
command
o <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
o <cmd>_info (read only): upon completion, the result of the command execution (if any) is
published by IOTA in this attribute
● Example:
o turn
o turn_info
o turn_status
…
"commands": [
{ "object_id": "u", "name": "turn", "type": "string" }
],
…

17. Commands
16
…
"commands": [
{ "object_id": "u", "name": "turn", "type": "string" }
],
…
turn_status
turn_status
turn_info

18. Summary: Terms
A Message Transport is the mechanism through which data is exchanged
• HTTP is a request-response protocol
• MQTT is a publish-subscribe protocol
• LoRaWAN is a network protocol for battery powered devices
A Message Protocol is the definition of the format of the data
• JSON (JavaScript Object Notation) is a well-known data exchange format
• Ultralight is a simplified ASCII-based data exchange
• Cayenne LPP is an encoded binary data protocol for small payloads
Commands are actions to alter the state of a device. Command are:
• Sent to the North Port of the IoT Agent
• Passed southbound down the stack from the Context Broker to the IoT devices
Measurements are readings from the devices. Measurements are:
• Sent to the South Port of the IoT Agent
• Passed northbound up the stack to the Context Broker
The North Port of an IoT Agent is used:
• By the context broker for sending commands to IoT devices
• General IoT Agent configuration
17

19. Summary: What is an IoT Agent?
IoT Agents overcome common problems in the IoT domain:
• How can I translate my received measurements into a common standard regardless of the device
used?
• How can I abstract my communications, so the users are able to remain unaware of the device
specific protocols?
• How can I map data received in a meaningful manner?
An IoT Agent translates an IoT specific protocol into NSGI v2
Any class of devices with an existing IoT Agent can be considered as FIWARE-Ready
device
For unsupported protocols you can build your own agent.
You only need an IoT Agent if your devices can’t support NGSI v2 directly
18

20. Question & Answer
19
fiware-tech-help@lists.fiware.org

21. Further reading
20
● The FIWARE Catalogue
o https://www.fiware.org/developers/catalogue/
● IoT Agent Library
o https://github.com/telefonicaid/iotagent-node-lib
● Orion Context Broker
o ReadTheDocs: https://fiware-orion.readthedocs.io

22. 2
1
http://fiware.org
Follow @FIWARE on Twitter

23. 2
2