We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.ArchitectureDescription.IoT.Gateway.DeviceManagement - FIWARE Forge Wiki

FIWARE.ArchitectureDescription.IoT.Gateway.DeviceManagement

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture
This page refers to the previous version of this GE and thus obsolete. It will be replaced soon with the new functionalities including the Gateway Logic, currently under definition


Copyright

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.

Overview

The Gateway Device Management GE is contains much of the "core" gateway functionality. It is responsible for the communication with the Backend and IoT and non-IoT devices. The Gateway Device Management GE includes the functional components to handle the registration/connection phases towards the Backend/Platform, to translate the incoming data or messages in an internal format and to send the outgoing data or messages in the ETSI M2M format (marshal/unmarshal). It is also capable of managing the communication with the IoT Resources, i.e. the devices connected to the IoT Gateway (that may be online or offline), and resources hosted by the gateway. The GE also contains Resource Management capabilities, i.e. to keep track of IoT Resource descriptions that reflect those resources that are reachable via the gateway. These can be both IoT Resources, or resources hosted by legacy devices that are exposed as abstracted IoT Resources. In addition, any IoT resource that is hosted on the gateway itself is also managed by this GE. The GE makes it possible to publish resources in the gateway, and also for the backend to discover what resources are actually available from the gateway.

Figure 1. Gateway Architecture
Figure 1: Gateway architecture

Basic Concepts

The IoT Gateway Device Management GE is based on the OMA NGSI context data model [1].

The core functionality of the GE is provided by the GSCL component of the OpenMTC [1] software developed at Fraunhofer FOKUS. This component natively provides the RESTful M2M interfaces as specified by ETSI [2] - specifically those described in TS 102.921 [3] and TS 102.690 [4]. In addition, an NGSI interface component has been developed according to FI-Ware specs.

FI-WARE NGSI

The IoT Gateway Device Management GE implements FI-WARE's RESTful binding specification of the OMA NGSI context management interface (FI-WARE NGSI specifications for short). More specifically, the GE implements the full set of NGSI-9 and NGSI-10 operations, where it acts both as a client and as a server.

FI-WARE NGSI Context Management specifications are based on the NGSI Context Management specifications defined by OMA (Open Mobile Alliance) [2]. They take the form of a RESTful binding specification of the two context management interfaces defined in the OMA NGSI Context Management specifications, namely NGSI-9 [3] and NGSI-10 [4].They also solve some ambiguities in the OMA specs and extend them when necessary to implement the FI-WARE Vision.

You can visit the FI-WARE NGSI Context Management tutorial [5] (currently under construction) to learn the main concepts underlying FI-WARE NGSI Context Management specifications.

Architecture

Figure 1 shows an overview of the IoT gateway and the position of the Gateway Management GE. The Gateway Device Management GE currently has four interfaces:

  • A northbound interface towards the backend is used for retrieving information from IoT and non-IoT resources and gateway-hosted resources. This interface is also used for resource discovery. This is currently based on IETF CoRE.
  • A southbound interface towards native IoT resources used for retrieving sensor data, managing subscriptions etc. Essentially the same as the backend northbound interface. Currently based on IETF CoRE.
  • A southbound interface towards the Protocol Adapter GE used for communicating with non-IoT resources
  • An interface towards the Data Handling API used by the Publish/Subscribe broker for creating, updating and deleting subscriptions to resources. Also used to retrieve locally stored data from IoT resources.

The Security API and Communication Extension API's may be supported in future releases of Fiware.

Figure 2 shows the internal architecture of the Gateway Device Management GE.

Figure 2: Gateway Device Management GE internal architecture

Resource Management

Resource Management is about handling information of connected devices and the resources they host. The Resource Management component makes it possible to discover resources by doing lookup searches, and store resource descriptions.

The Resource Directory is a data store for IoT and legacy resource descriptions used for discovering which device that hosts a particular resource. Typically these resource descriptions can contain information about the endpoints that host the resources (address, port, etc...), the type of resource (e.g. temperature), and contextual data such as position. The Resource Directory supports looking up resource descriptions, as well as publishing, updating and removing resource descriptions to it.

Discontinuous connectivity

Discontinuous Connectivity Management deals with the connectivity with the Backend/Platform and with the Protocol Adapter GE for the connectivity with the IoT Resources. When the Backend/Platform wants to communicate with an IoT Resource it sends a message to the Discontinuous Connectivity Management module so that it can check if the IoT Resource is currently connected. If it is connected the Discontinuous Connectivity Management forwards the message directly to the IoT Resource, otherwise it stores the message into a Connectivity Cache. When the IoT Resource connects to the Gateway then the messages stored in the Connectivity Cache will be forwarded. When an IoT Resource wants to communicate with the Backend/Platform it sends a message to the Discontinuous Connectivity Management module so that it can check if the Gateway is currently connected to the Backend/Platform. If it is connected then the Discontinuous Connectivity Management forwards the message directly to the Backend/Platform, otherwise it stores the message into the Connectivity Cache. When the Gateway connects to the Backend/Platform the messages stored in the Connectivity Cache will be forwarded.

Connected Device List (store) is a repository that keeps all the information of the different IoT Resources registered and connected to this IoT Gateway, providing information about:

  • The identifier of the IoT Resources
  • What are the properties/capabilities of the IoT Resources
  • The registration status of the IoT Resources
  • The connectivity status of the IoT Resources

Communication Core

The Communication Core contains the basic communication capabilities of the gateway to setup communications to the IoT Backend and IoT Devices.

Main interactions

Resource Management

IoT Resources can be both contained on devices outside the gateway and locally stored (ex. cached data) within the gateway. Figure 3 shows how devices outside the gateway can:

  • Create an entry in the Resource Directory exposing the availability of a particular IoT Resource.
  • Delete an entry in the Resource Directory, e.g. when the IoT Resource entry is not available any more.
  • Update an entry in the Resource Directory, e.g. to reflect a change in the service description of the IoT Resource.
  • Publish entries in the Resource Directory, i.e. resources that are exposed by the gateway, to the backend Resource Directory

Devices can be both "native" IoT devices communicating directly with the Gateway Device Management GE or legacy devices where communication pass through the Protocol Adapter GE as pictured below. The Gateway Device Management GE can also publish resource descriptions to the backend on behalf of devices. Notable in this figure is that the Discontinuous Connectivity Management component will check if the backend is online. Otherwise this request will be cached and sent at a later stage when the backend/gateway is back online.


Figure 3: Resource Management (external resources)


The IoT gateway can also contain locally stored resources. In this case these resource descriptions are contained within the Data Handling GE. Figure 4 shows how to:

  • Create an entry in the Resource Directory exposing the availability of locally stored data for a particular IoT Resource.
  • Delete an entry in the Resource Directory, e.g. when the IoT Resource entry in the Data Store is not available any more.
  • Update an entry in the Resource Directory, e.g. to reflect a change in the service description of the IoT Resource.


Figure 4: Resource Management (internal resources)


The Gateway Device Management GE exposes an API so that it is possible for the backend to read entries in the Resource Directory, i.e. discover which IoT resources that are exposed by the gateway.


Figure 5: Lookup resources

Accessing resources

The Gateway Device Management GE enable basic communication with resources hosted on devices outside the gateway as well as resources hosted by the gateway.

Figure 6 shows how the backend can manipulate an IoT resource by Create, Read, Update, Delete (CRUD) operations on an IoT resource. Notable in this figure is that the Discontinuous Connectivity Management component will check if the device hosting the resource is online. Otherwise this will be cached and sent at a later stage when the device is back online.

Figure 6: Access to resource hosted by device

Figure 7 shows the corresponding Create, Read, Update, Delete operations on a resource hosted by the gateway.

Figure 7: Access to resource hosted by the gateway

Basic Design Principles

The OpenMTC platform has been designed to act as a horizontal convergence layer in terms of a Machine-2-Machine (M2M) middleware for machine type communication that supports multiple vertical application domains. Those domains are usually the classic M2M verticals (market segments) such as transport and logistics, utilities, automotive, eHealth, etc. which can be deployed independently or as part of a common platform.

OpenMTC fosters the development of M2M applications on the gateways or over the top of the backend server though abstract high-level APIs by hiding the complexity of device resource structure and enabling more functionality. The APIs are classified in three categories:

  • Data APIs handle functionalities related to accessing/manipulating data collected from devices/sensors.
  • Network APIs deal with the roles related to the network applications and its session control with the M2M core.
  • Device APIs find appropriate devices and gateway resources to fetch information from them.

References

[1]

https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/NGSI_9/10_information_model

[2]

http://technical.openmobilealliance.org/Technical/release_program/docs/CopyrightClick.aspx?pck=NGSI&file=V1_0-20101207-C/OMA-TS-NGSI_Context_Management-V1_0-20100803-C.pdf

[3]

https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-9_Open_RESTful_API_Specification_%28PRELIMINARY%29

[4]

https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-10_Open_RESTful_API_Specification_%28PRELIMINARY%29

[5]

https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI_Context_Management_tutorial

Personal tools
Create a book