FIWARE provides an IoT platform that connects IoT devices to applications through the FIWARE IoT stack. The IoT Broker acts as an abstraction layer between IoT devices and applications, organizing information flows and enabling applications to interact with "things" instead of individual sensors. The IoT Broker can be scaled and supports advanced features like an IoT Knowledge Server to add semantic information and federation to allow separate IoT domains to communicate through a common protocol.

1. Connecting IoT Devices to FIWARE
Fernando López
FIWARE Cloud and Platform Senior Expert
fernando.lopez@fiware.org
@flopezaguilar

2. 1

3. #SmartCities
#SmartAgrifood
#SmartIndustry
FIWARE: Technology for Smart*
#SmartRegions
NGSI CONTEXT INFORMATION

4. IoT Interoperability ? Still a $1,000,000 question
3

5. 4

6. 5
We need to find
We need to find the exit of this labyrinth

7. 6

8. FIWARE IoT: Interoperability at Context Data Level
Satisfying Developers view:
§ Common language for all Data Sources (IoT and non-IoT).
§ Single REST API. Query, Subscribe, Trigger Actions.
§ Open Source solutions published in GitHub, Read-the-docs, etc.
7
Street Devices
• Location
• Observations
• Commands
Context Broker
NGSI API
Boiler
• Manufacturer
• Last revision
• Product id
• Temperature
• Actions
Users
• Name-Surname
• Birthday
• Location
• ToDo list
City
• OpenData
• Users Input
Public Bus T.System
• Location
• Arrival time
APPs / Services / Data Scientist

9. Previously: Sylos or Verticals
SmartCity/Smart*
8
High Efficiency
• Automatization
Higher IT Business
• Common suppliers
Maintenance
• Different platforms

10. Previously: Horizontals
SmartCity/Smart*
9
Higher Efficiency
• Automatization
• Maintenance
Higher IT Business
• Common suppliers
Intelligence
Connectivity
Monolithic
• Very complex
• Scaling
• Only one connectivity

11. FIWARE Smart*: Local Ecosystem
growth engine
10
Higher Efficiency
Boost Overall
Business
• Cross-vertical ideas and
services
• New Players
• Data Scientists
• Developers
• Shared Networks, Cloud

12. Smart* FIWARE most-used IoT Stack
11

13. Talking to IoT – Choosing an IoT-Agent
12
Use IoT Agents node.js
library to develop your
own IoT Agent.
Can I program my
devices/gateways
to support a given
IoT protocol?
Is your IoT network
lossy & unstable or
your devices too
constrained to support
HTTP/TCP?
Use LWM2M IoT Agent. UDP is
recommended for constrained
networks and CoAP is REST for
constrained devices
Are your coding
Preferences/ libraries/
language handling better
JSON objects rather than
shorter text messages?
Use Ultralight2.0 IoT
Agent. Messages are
simple and light as “t|25”
No
Yes
Use JSON IoT Agent.
Choose MQTT if RT
bidirectionality is a
must.
Yes
No
No
Yes

14. Ongoing Work
§ Evolution of IoT Agents
• Include new functionalities such as data Transformations.
• New protocols (Modbus)
• Consider IoT management.
§ From Cloud-Centralized to Distributed models
• IoT Agents, NGSI Brokers and CEP at the IoT Gateway Level.
§ Context Data Models
• Smartcities: OASC Alliance
• SmartAgrifood: IoF Project
• SmartIndustry
§ Federation and other implementations of NGSI Brokers
• IoT Broker
§ Market dynamization (marketplace)
• FIWARE-ready IoT Device Program.
13

15. IoT Agents
14

16. FIWARE IoT architecture
15

17. 16

18. IoT Platform
1717
IOTA IOTA IOTA
DEV
DEV
DEV
DEV
DEV
DEV
DEV
DEV
DEV
UL 2.0 LWM2M MQTT
NGSI
IoT Manager
Provision API
App
App
App
App
App
App
App
App
App
App
App
App

19. IoT Agents Overview
18
• Design principles:
• Modular approach
• Deployment flexibility
• Ease the creation of Custom IoT Agents
• Device Protocol to NGSI Bridge
• One entity per device
• Constrained set of interactions
• Provisioning of devices and groups of devices
• IoT Manager
• Additional services (e.g. security, model transformation, stats)

20. Example: Group provision
19
API Key provision
Type definition
Common attributes and
commands
POST /iot/services HTTP/1.1
Host: localhost:4041
Fiware-Service: smartsville
Fiware-ServicePath: /management
Content-Type: application/json
{
"services": [
{
"apikey": "1234567890",
"resource": "/iot/d",
"type": "smartcity",
"protocol": "PDI-IoTA-UltraLight"
}
]
}

21. Example: Device provision
20
Device ID definition
Defines per-device
attributes and commands
POST /iot/devices HTTP/1.1
Host: localhost:4041
Fiware-Service: smartsville
Fiware-ServicePath: /management
Content-Type: application/json
{
"devices": [{
"device_id": "smartsville",
"entity_type": "smartcity",
"protocol": "PDI-IoTA-UltraLight",
"attributes": [
{
"object_id": "lum",
"name": "Luminance",
"type": "lumens"
}
]}]}

22. Example: Ultralight 2.0 HTTP
21
Simple HTTP Protocol
Key Pair values
Push and Pull commands
POST /iot/d?k=1234567890&i=smartsville HTTP/1.1
Host: localhost:7896
Content-Type: text/plain
Cache-Control: no-cache
park1|true|park2|false|lum|300
HTTP/1.1 200 OK
Content-Length: 88
Content-Type: text/html
Connection: Closed
smartsville@semaphoreFreq|2|smartsville@luminosityL
imit|200

23. Links and documentation
§ IoT Agent Library
• https://github.com/telefonicaid/iotagent-node-lib
§ Ultralight 2.0 IoT Agent
• https://github.com/telefonicaid/iotagent-ul
§ The FIWARE Catalogue
• https://catalogue.fiware.org/
22

24. IoT Broker
23

25. Table of Contents
• Introduction
• What does IoT Broker do?
• Advanced Features:
• IoT Knowledge Server
• IoT Broker Federation
• IoT Broker Scalability

26. 25
The FIWARE Enablers for IoT

27. What does the IoT Broker do?
FIWARE GE:
IoT Broker
Thing Abstraction: enable
applications to interact with things instead of
sensors
Thing-Level Interaction: Organizing
information flows:
- executing information
queries on behalf of
applications
- discover the resources
providing the requested
information
- collecting & aggregating the
received information – query
and subscribe/notify
abstractions
apps
Devices Gateways other sources

28. IoT Broker
§ decouples applications from underlying IoT device installations
§ paradigm adopted: Subscribe/Notify
§ Context data fetched directly from reporitory
§ No need of a centralized repository, but can be added “Plug&Play”
§ Optimized communications with underlying device installations
§ Initialized only when requested from the application
§ Bandwidth communication reduced
§ Scalability ensured in a scenario of billion of devices
§ Assemble lower-level device information (device-centric access) into
higher-level Thing information (information-centric access)
§ Naming: From Devices (e.g. sensorId) to Things (e.g. Trafalgar Square).
§ Type & Context: Close the gap between information-centric applications and
device-centric IoT installations
§ Discovery & Resolution: IoT applications are agnostic of the device
installations
§ Advanced Features:
§ Association
§ Entity Composition

29. Emerging IoT Protocol Stack
IoT Development System
• SDK
• OS Integration
• IoT Hardware
IoT Integration Layer
• IoT Resources: Black Box
Container
• REST-based Access
OMA NGSI
(IoT Broker)
IoT Entities
• Contextualized Information
• Content-based Queries
• Pub / Sub
Knowledge-base
Semantic Processing Agents
Data Integration
• across many systems
• Semantic Representation
• Semantic Mediation
New Standardization: ETSI ISG on
Contextualized Information Models

30. Advanced Feature:
§ IoT Knowledge Server
§ Add semantic information into NGSI messages
§ Enhance NGSI messages with semantic reasoning
§ IoT Broker Federation
§ Separate IoT domains
§ Improve IoT system integration
§ IoT Broker Scalability
§ Enhance performances in envisioned scenario of millions of devices in
each domain

31. IoT Knowledge Server

32. IoT Knowledge Server: Overview
§ IoT Knowledge Server: A standalone component created for serving
semantic information
§ Purpose: serving IoT Broker with triple-store datasets of semantic
ontologies (e.g., NGSI/SmartSantander ontology)
§ Record and Explore Information Structure contained in the real-world
data
§ “get sub types of an entity type”
§ Interfaces: REST API and Subscribe/Notify in JSON format
§ IoT Knowledge Server is composed of two components (web servers)
and two databases along with the servers

33. Functionalities
§ Pre-Defined Queries
§ HTTP requests for getSubTypes, getSuperTypes, getAttributes,
getAllSubTypes, getAllSuperTypes
§ Add new queries
§ New queries with one or zero variables (e.g. Entity Type) can be added to a
file and we can start using as a new functionality (other than the 5 above)
§ Register new queries
§ Adding new queries by HTTP request on the fly (without restarting the
server)
§ Forward SPARQL queries
§ To provide single point of contact even for direct SPARQL queries along with
the high level ones (getSubTypes)
§ Subscribe functionality
§ Subscribing to queries and regular (fixed time) updates on change to the
subscribers by the IoTKnowledgeServer.
§ Caching mechanism
§ Caching mechanisms for fast respond (without asking SPARQL server)
§ Both for Queries and for Subscriptions

34. An example query
Apache
Jena
Fuseki
RDF Triple Store
REST
JSON
JDBC
IoT Broker
JSON
Ontology
manager
REST
getSubTypes of Sensor
“getSubTypes_Sensor”
2
Get SPARQL
Query for getSubTypes
SELECT ?type WHERE {?type
rdfs:subClassOf ngsi:<???>}
SELECT ?type WHERE {?type
rdfs:subClassOf ngsi:Sensor}
NULL
3
1
4
5
6
7 {TempSensor,
NoiseSensor,
LightSensor}
8
{TempSensor,
NoiseSensor,
LightSensor}
<K,V>
REST
9
<“getSubTypes_Sensor”,
{TempSensor,
NoiseSensor,
LightSensor} >
IoT Knowledge
Server

35. IoT Knowledge Server: Example
ApplicationApplicationApplications
IoT AgentsContext
Providers
IoT Broker IoT Discovery
Availability request:
Entity of type “sensor”
Legend:
- NGSI-10
- NGSI-9
- IoT
Knowledge
Server APIData request:
Entity of type
“sensor”
Data Responses:
Entity of type
“sensor”,
“TempSensor”,
“NoiseSensor”,
“LightSensor”
IoT Knowledge
Server
getSubTypes of Sensor {TempSensor,
NoiseSensor,
LightSensor}
Data request:
Entity of type
“sensor”,
“TempSensor”,
“NoiseSensor”,
“LightSensor”

36. IoT Broker Federation

37. IoT Broker Federation
§ Smart Cities are dominated by federated information from different
agencies
§ An IoT platform is responsible for a single IoT domain
§ Separate IoT data in different domains
§ Full power on the produced data to the IoT domain administrator, e.g. for
privacy purpose
§ Selective communication to a specific domain
§ Selected by IoT domain name
§ Selected by entity name
§ Selected by attribute type provided
§ Selected by scope, e.g. geographic scope
§ Mixture of the above.

38. Federation: hierarchical
Applications
NGSI
agents
NGSI
NGSI
NGSI
NGSI
IoT Platform (a)
IoT
Broker
IoT
Discovery
IoT Platform (b)
IoT
Broker
IoT
Discovery
NGSI
agents
▌IoT Platform Hierarchy
lTwo type of platform
• Subordinated IoT Platform: responsible for
its IoT domain; subordinated to Platform
• Top IoT Platform: responsible of its own
domain of NGSI devices; contact point for all
subordinated domains
lTwo IoT domains manage their data in
separate repositories
lCommon communication language
based on standard NGSI protocol
lMechanism of Subscribe Notify for
accessing the data
▌Feature: broadcasting
lTop IoT Platform dispatches
query/subscription to subordinated IoT
Platform
▌Feature: selective communication
lPossibility to query/subscribe only to a
specific subordinated IoT Platform

39. Federation: mash-up
Applications
NGSI
agents
NGSI
NGSI
NGSI
NGSI
agents
NGSI
Applications
NGSI
NGSI
agents
NGSIApplications NGSI
IoT Platform (a)
IoT
Broker
IoT
Discovery
IoTPlatform(c)
IoT
Broker
IoT Platform (b)
IoT
Broker
IoT
Discovery
NGSI
▌ IoT Platform Mesh
l Each platform is a peer
l Each peer is responsible of its own domain
l Applications requesting a peer will get data
coming from other peer transparently
▌ Feature: broadcasting
l Peer broadcast request to all known peer
▌ Feature: selective communication
l Possibility to query/subscribe only to a specific
known peer
▌ Feature: loop detection
l A loop detection feature avoid loop in the topology

40. IoT Broker Scalability

41. Scalability
ApplicationApplicationApplications
IoT AgentsContext
Providers
IoT Broker
IoT Discovery
registration
availability
requests
LoadBalancer(e.g.DNS)
Legend:
- NGSI-10
- NGSI-9
IoT Broker
IoT Broker
- Update
- Query
- Subscription
Responses
- Query
- Subscription

42. IoT on the edge
41

43. FIWARE IoT architecture
42

44. edge
43
FIWARE in the cloud & in the edge
sensor data providers
LPWAN sensors
developers
end users
other data
providers
latency-critical
sensor & actuator
networks
FIWARE
backend
Apps
Operator
platform
LPWA
Network
servers
Equipment
vendor
platform
sensor data providers

45. Smart City platform
44
CKAN
Big Data
Context Broker
Accounting&Payment&Billing
IDM&Auth
Short-term
historic
data
BigData
Processing
Data
Quering/Action,
Publish/Subscr
Open Data
publishing
Real-time
processing
BI
ETL
RULES
DEFINITION
TOOL
OPERATIONAL
DASHBOARD
KPI GOVERNANCE OPEN DATA PORTALS
Service
orchestrator
Context
Adapters
CEP
IoT Backend
measures /
commands
Sensors Open DataActuators
Media
streams
Real Time
Media
Stream
Processing
City Services
GIS
Inventory
Specific Enablers
Generic Enablers
IoT Edge
Device
manag
ement
&
abstra
ction

46. 45

47. 46
http://fiware.org
Follow @FIWARE on Twitter

48. Thank you!
http://fiware.org
Follow @FIWARE on Twitter

49. Backup slides