This slideset gives an overview over the FIWARE IoT-Broker Generic Enabler.

1. IoT Broker GE
Internet-of-Things Service Enablement
Stefan Gessler stefan.gessler@neclab.eu
Flavio Cirillo flavio.cirillo@neclab.eu
Tobias Jacobs tobias.jacobs@neclab.eu
NEC Laboratories Europe, Heidelberg, Germany, 2015

2. Outline
The scope of this slide set is to explain …
▐ … the role of Brokers in FIWARE.
▐ … the specific role and distinguishing features of the IoT Broker.
▐ … the FIWARE IoT Broker GE specification and the available GE
implementation.
▐ … the data model and interactions supported by the FIWARE NGSI
protocol.
▐ … the control and information flow in the typical IoT Broker interactions.
▐ … the concept of associations for data model customization.
Out of scope are …
▐ … the details of FIWARE NGSI message bodies.
▐ … IoT Broker installation and administration.
▐ See slide 5 for links to further documentation.
Page 2

3. Data Brokers in FIWARE
Page 3
What does a Broker do?
data
source data
source
data
source data
source data
source
data consumer
data consumer
data consumer
Broker
Broker provides logical separation of data
consumers from data consumers
 applications need to know only Broker, not
the data sources
 data sources do not need to manage data
requests from several applications
Brokers in FIWARE
▐ Context Broker
 General-purpose data broker for all
kinds of FIWARE data producers and
consumers
▐ IoT Broker
 Broker specialized for Internet-of-
Things deployments
What else is needed?
▐ FIWARE NGSI – compliant data
sources
 Data exchange in FIWARE is mainly
based on NGSI standard.
 FIWARE offers “IoT Agents” to
translate other protocols into NGSI
 Smart Cities feed their data into
FIWARE using NGSI standard

4. FIWARE IoT Broker
Page 4
IoT Broker(s)
data consumer
data consumer
data consumer
IoT Discovery
IoT Gateways
Sensors
Sensors
Specific Features of IoT Broker
▐ Statelessness
 The registry of available data sources is in a
separate component “IoT Discovery”
 Main approach of IoT Broker is to retrieve data on-
demand from sources only when needed by data
consumer (but central data storage can still be
connected and used to answer queries)
 Due to statelessness, IoT Broker can be easily
replicated to achieve scalability
▐ Data model translation
 IoT Sensors and Gateways deliver data
categorized by Device ID & Device type ( who
produced the data)
 Data consumers are rather interested in data
categorized by the context ( what does the data
describe)
 IoT Broker can make abstraction from sensor-
based (“Device-Level information”) data models to
context-based data models (“Thing-level
information”)

5. IoT Broker GE specification and GE implementation
▐ IoT Broker GE specification
 provided by FIWARE
 specification of protocol and functionality of IoT Broker GE (please click
highlighted links for the documents)
Page 5
GE = FIWARE Generic Enabler
IoT Broker IoT Discovery
▐ IoT Broker implementation
 FIWARE reference implementation provided by NEC, based on Java +
OSGi
 sources + binaries available through FIWARE Catalogue
 This IoT Broker implementation also contains a basic IoT Discovery
• (But note that the FIWARE reference implementation of the full IoT Discovery GE is
provided separately via the FIWARE Catalogue)
 Documentation:
• User and Programmer Guide
• Installation Guide

6. FIWARE NGSI data model
Page 6
NGSI Context
Information
=
Information about
Entities and their
attribute values
IoT Broker
data consumer
NGSI = Next Generation Service Interface
(Standard originally from Open Mobile Alliance)

7. FIWARE NGSI interfaces
Page 7
133.122.44.6
NGSI-10 is the
context data
interface
NGSI-9 is the
context availability
interface
synchronous
retrieval
asynchronous
retrieval
push-mode
interaction
queryContext
 get data now
subscribeContext,
notifyContext
 get data regularly
updateContext
 send (“push”) data
discoverContextAvailability
 get data providers now
subscribeContextAvailability,
notifyContextAvailability
 get regular updates on data providers
registerContext
 announce data providers

8. FIWARE NGSI interactions of IoT Broker
Page 8
IoT Broker
data consumers
IoT Discovery
IoT data providers
NGSI-10 context data:
QueryContext
SubscribeContext
NotifyContext
UpdateContext
NGSI-10 context data:
QueryContext
SubscribeContext
NotifyContext
UpdateContext
NGSI-9 context availability:
DiscoverContextAvailability
SubscribeContextAvailability
NotifyContextAvailability
NGSI-9 context availability:
RegisterContext

9. Registration data flow
▐ registration makes IoT
Discovery aware of a data
provider
▐ registration specifies which
data the provider has
available
▐ IoT Broker is not involved in
this data flow
Page 9
IoT Broker IoT Discovery
IoT data provider
RegisterContext

10. Query data flow
▐ (1) data consumer invokes
QueryContext on IoT Broker
 The query specifies which data the
application wants to retrieve
▐ (2) IoT Broker invokes
DiscoverContextAvailability
on IoT Discovery to find data
sources that can satisfy the query
in (1)
▐ (3) IoT Broker invokes
QueryContext on the IoT data
providers retrieved from IoT
Discovery in step (2)
▐ (4) IoT Broker assembles the
query results from (3) into a single
query result and returns it to the
data consumer
Page 10
IoT Broker
data consumer
IoT Discovery
IoT data providers
(1)
(2)
(3)
(4)

11. Subscription data flow, Part I
Page 11
IoT Broker
data consumer
IoT Discovery
(1)
(2)
▐ (1) data consumer invokes
SubscribeContext on IoT
Broker
▐ (2) IoT Broker invokes
SubscribeContextAvailability
on IoT Discovery, in order to
receive updates on sources that
can provide data relevant for the
subscription in (1)
SubscribeContext
SubscribeContextAvailability

12. Subscription data flow, Part II
▐ (1) IoT Discovery invokes
NotifyContextAvailability to
inform IoT Broker about a new data
provider
▐ IoT Broker checks whether the
data provider is relevant for an
existing subscription from a data
consumer. If yes, then
▐ (2) IoT Broker invokes
SubscribeContext on the new
data provider in order to regularly
get data notifications.
Page 12
IoT Broker IoT Discovery
IoT data provider
(1)
(2)
NotifyContext
Availability
Subscribe
Context

13. Subscription data flow, Part III
Page 13
▐ (1) IoT Data provider invokes a
NotifyContext to send IoT
Broker some data the IoT Broker
has previously subscribed for
▐ (2) IoT Broker invokes
NotifyContext on the data
consumer that has originally
subscribed for the data.
IoT Broker
data consumer
IoT data provider
(2)
(1) NotifyContext
NotifyContext

14. Update data flow
Page 14
IoT Broker
data consumer
IoT Discovery
IoT data provider
(3)
(2)
(1)
▐ (1) IoT data provider invokes
UpdateContext on IoT Broker
 This operation is typically used for
sending data in push-mode without a
previous subscription
▐ (2) IoT Broker invokes
DiscoverContextAvailability
on IoT Discovery to find
information on how to interpret the
update.
 See next slide on associations
▐ (3) IoT Broker invokes
UpdateContext on a data
consumer to forward the (possibly
interpreted) update.
 A default data consumer for receiving
updates can be freely configured
UpdateContext
DiscoverContext
Availability
Update
Context

15. Associations
▐ Associations are
information about how
to map “device-level”
data to “thing-level”
data
▐ Associations are stored
in IoT Discover and
used by IoT Broker for
translating the data
models
▐ Currently supported
association types are
 Entity mappings
 Attribute mappings
 Aggregation functions
(planned for Autumn
2015)
▐ IoT Broker can be
extended with custom
plugins for further
association types.
Page 15
IoT Broker
IoT data providers
data consumer
IoT Discovery

16. Summary
▐ The IoT Broker GE is a middleware component for the IoT Backend,
connecting Internet-of-Things applications to the data sources they
need.
▐ The IoT Broker needs to be connected to an instance of the IoT
Discovery GE.
 But IoT Broker implementation also includes a basic IoT Discovery.
▐ IoT Broker purpose is to hide the complexity of IoT installations from
applications by providing a single point of contact.
▐ The data models of the data sources can be flexibly translated into
higher levels of abstraction by usage of associations.
Page 16

17. Page 17