FIWARE is an open source platform for building IoT applications and services. It provides interfaces like NGSI for discovering, accessing, and controlling IoT devices and sensor data. FIWARE supports exposing sensor data as consumable web services and discovering heterogeneous data sources. Its architecture includes roles for IoT context producers, consumers, and generic enablers for registry, orchestration, and data handling functions.

1. http://www.fiware.org
http://lab.fiware.org
Follow @FIWARE on Twitter
IoT Discovery: An Introduction
Tarek Elsaleh
University of Surrey
t.elsaleh@surrey.ac.uk @UniSurreyIoT

2. FIWARE and the IoT
 Service Enablement for the IoT
• Exposing information from sensor devices and “things” as consumable services.
› exposing also actuator devices for remote control.
• Allow applications to source information from heterogonous sources.
• Allow an IoT Infrastructure(s) to provide a shared pool of “IoT resources” i.e. sensor/actuator devices that are not used
only for a specific purpose.
› IoT infrastructures could consist of multiple systems and deployments which originally serve a particular use case.
› Enable them to be used in other use cases or “contexts”.
› Enable the consumption of “opportunistic” context, where context from a sensor device can be associated to a dynamic object at
a particular time and location
› E.g. a temperature sensor used to monitor the temperature of a room can be relevant to a person’s ambient temperature when (the “thing”) entering the
room.
• Enable the discovery of sensors/actuator and things
› Discover what contextual data is available, and get information on how to access.
› Enable brokerage on behalf of consumers to discover and retrieve complex sets of contextual data.
• Enable access to and control of sensor/actuator devices and Things.
› Constrained devices might not support the full IP stack
› or it’s limited power capacity could force limited access to it.
› Hence gateways (edge access devices) can act as a mediator.
• Enable pre-processing of data and event handling at the edge, for data aggregation and data summarization
› Allow the restriction of amount of data sent to the backend
› To minimize communication overhead.
› Report only on information that is required.
1

3. FIWARE IoT Architecture
2
Global access and control
management for devices
Registry for sensors
and things
Orchestrator for data
retrieval
Data handling and
complex event
processing
Local access and control management for
devices via constrained protocols

4. NGSI: Main Interface in FIWARE
 NGSI (Next Generation Service Interface)
• Standardized suite of interfaces exposing device capabilities and network
resources.
• Originally specified by the OMA Mobile Alliance
• FIWARE has provided an implementation for 2 of the specified interfaces
› NGSI-9: enables the registration and discovery of available context entities
› NGSI-10: enables the submission and querying of contextual data
3

5. Main Roles in FIWARE IoT
 IoT Context Producer
• A system entity that
› captures context information from the real world
› through sensor devices; e.g. temperature sensors
› Influences things in the real world
› through actuator devices, e.g. window control module
› Announces the availability and reachability of context information
 IoT Context Consumer
• A system entity that
› Discovers sources of context information
› Consumes context information through service endpoints exposed
by IoT Context Providers or via context information brokers.
 IoT GE:
• A system entity that
› Provides some form of IoT context management
› Context access/control, processing, registration, orchestration
4

6. IoT Discovery
 A service discovery mechanism (SDM)
• About availability of context sources/influencers i.e.
sensor or actuator devices.
• Allow context producers to register
› Describe what attributes of an entity can be queried
› Specific metadata associated with them; e.g. unit, resolution,
location etc.
› Provide endpoint for invoking the IoT context service.
• Allow context consumers to discover
 Synonyms
• Registry, directory, catalogue, repository.
 Analogies
• “Yellow pages”: Info about service(s) provided, and
how to contact them.
• Searching for Web content using search engines
› Search engines point to relevant sources of Web content.
5

7. 6
Target Users
 Context Producers
• IoT Agent/Data Handling GE
› Exposes a service endpoint for data/actuation provision via NGSI-10 (“data interface”)
› e.g. gateway
› Register resources; sensing sources, actuators, processing elements (composite of sensing
sources)
• Backend Device Management GE
› Register sensing/actuator devices,
 Context Consumers
• Applications
› Directly discover what context sources are available and for how long.
• IoT Broker GE
› Discovers and retrieves data from multiple context sources on behalf of the consumer
› offers consumers a simple interface and masking the complexity and heterogeneity of the IoT
• Data Context Broker GE
› Subscribes for notification of context source availability directly for simple request, or via the IoT
Broker for more complex requests.

8. Usage Scenario (2)*
7
* From FIWARE wiki on IoT Architecture

9. Usage Scenario (2)*
 An application could invoke the data context broker about a set of entities and
their corresponding attributes
 If the data context broker does not have the match to the query, it will invoke
an IoT infrastructure that employ the FIWARE IoT framework.
 The first point of contact in the IoT infrastructure can be either the IoT Broker
or IoT Discovery.
• For a simple discovery request it could contact IoT Discovery directly
• For more complex requests, it would forward the original request from the
application to the IoT Broker
› The IoT Broker will handle the discovery process with IoT Discovery via the NGSI-9
interface
› and thereafter the retrieval of the context in question from an IoT gateway via the NGSI-10
interface
8
* From FIWARE wiki on IoT Architecture

10. Other scenario
 An application could directly contact an IoT infrastructure by invoking either
the IoT Broker or IoT Discovery, depending on the complexity of the request
• Use NGSI-9 for context discovery or NGSI-10 for context query via IoT Broker
• Use NGSI-9 for context discovery via IoT Discovery
• If application directly invokes IoT Discovery for context discovery, it will need to use
NGSI-10 to invoke the context source.
› Context source endpoint provided with discovery response (if match found)
9

11. 10
Interfaces/APIs (Main)
 NGSI-9
• Mainly adopted by GEs in the FIWARE architecture for context discovery
• Discover what sensors and things are available
› Before querying for data
› Know where actual context sources are
› Not only relying on Context Broker
› Know what entities are available and what attributes they have beforehand
› Avoid unnecessary network overload of IoT services.
› IoT Services might be constrained
 Serialization in XML or JSON
 Release 4
• Geolocation

12. 11
Interfaces/APIs (Semantic)
 Sense2Web API v1 (Release 3)
• For sematic context discovery
› Discover what sensors and things are available
• Adopts the IoT-A ontology for modelling IoT entities.
• RESTful CRUD operations for registering, updating, looking up and deleting
semantically-annotated context descriptions
• RESTful SPARQL endpoint for querying
• Association mechanism matches “things” with services that are co-located and
share the same attribute (e.g. ambient temperature of a person co-located with a
temperature sensor)
• Probabilistic search based on text analysis of registered descriptions.
 Sense2Web API v2 (Release 4 – Oct’15)
• Context producers can submit annotated information using simpler formats
› CSV, JSON
• Content negotiation through header fields
• Adopts a simpler model for IoT devices and things

13. Examples
 Streetlight scenario
• Sensors on streetlight used for measuring luminosity
› One for daylight level to check for transition from/to twilight period
› One for light luminosity to check correct level is set
• An application could provide the most brightest routes for late
pedestrians
› consume a set of IoT services that provide information about the light
intensity in a particular area.
› Application discovers what sensor devices are available in the area
› Application can then query the sensor devices for sensed light level using the
endpoint retrieved form the discovery process.
12
http://www.myledlightingguide.com/images2/StreetLight1.jpg

14. http://fiware.org
http://lab.fiware.org
Follow @Fiware on Twitter !
Questions?
13
Contact: Tarek Elsaleh
Email: t.elsaleh<at>surrey<dot>ac<dot>uk
Twitter: @UniSurreyIoT