http://www.fiware.orghttp://lab.fiware.orgFollow @FIWARE on Twitter

IoT Discovery: An IntroductionTarek ElsalehUniversity of Surreyt.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.

3

FIWARE IoT Architecture

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

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

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.

7

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)*

* 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

* 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)

11

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

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.

http://www.myledlightingguide.com/images2/StreetLight1.jpg

http://fiware.org

http://lab.fiware.org

Follow @Fiware on Twitter !

Questions?

14

Contact: Tarek Elsaleh

Email: t.elsaleh<at>surrey<dot>ac<dot>uk

Twitter: @UniSurreyIoT