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.OpenSpecification.IoT.Gateway.DeviceManagement - FIWARE Forge Wiki

FIWARE.OpenSpecification.IoT.Gateway.DeviceManagement

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.IoT.Gateway.DataHandling
Chapter IoT Services Enablement,
Catalogue-Link to Implementation Gateway Device Management GE - Ericsson IoT Gateway
Owner Ericsson, Jakob Saros


Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


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

Detailed Open Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

Other Open Specifications

In addition to the above mentioned specifications the first release of the Gateway Device Management GE will also support the following IETF CoRE specifications:


Re-utilised Technologies/Specifications

The Gateway Device Management GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

  • RESTful web services
  • HTTP/1.1 (RFC2616)

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

[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

  • Thing. One instance of a physical object, living organism, person or concept interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Examples of physical objects are: building, table, bridge (classes), the Kreml, the tennis table from John’s garden, the Tower bridge (instances). Examples of living organisms are: frog, tree, person (classes), the green frog from the garden, the oak tree in front of this building, Dr. Green.
  • Class of thing. Defines the type of a thing in the style of object-oriented programming: a construct that is used as a blueprint to create instances, defining constituent members which enable class instances to have state and behavior. An example of class of thing is “person”, whereas an instance of a thing is “Dr. Green”, with all the static/dynamically changing properties of this particular person.
  • Group of things. A physical/logical group of things. Examples are all office buildings from Munich, all bridges above the Thames, all screws from a drawer, the planes of Lufthansa currently above Germany, all cars inside a traffic jam driven by a female driver, the trees from the Amazonian forest, the squids from the Mediterranean see the mushrooms from Alice’s garden, all the fish from the aquarium of John., the soccer team of Manchester, the colleagues from OrangeLabs currently working abroad (from the perspective of France), all patients above 60 years of age of Dr. Green, the traffic jams from Budapest, the wheat crop in France in the year 2011, the Research and Development Department of the company Telefónica.
  • Device. Hardware entity, component or system that may be in a relationship with a thing or a group of things called association. A device has the means either to measure properties of a thing/group of things and convert it to an analog or digital signal that can be read by a program or user or to potentially influence the properties of a thing/group of things or both to measure/influence. In case when it can only measure the properties, then we call it a sensor. In case when it can potentially influence the properties of a thing, we call it an actuator. Sensors and actuators may be elementary or composed from a set of elementary sensors/actuators. The simplest elementary sensor is a piece of hardware measuring a simple quantity, such as speed of the wind, and displaying it in a mechanical fashion. Sensors may be the combination of software and hardware components, such as a vehicle on-board unit, that consists of simple sensors measuring various quantities such as the speed of the car, fuel consumption etc and a wireless module transmitting the measurement result to an application platform. The simplest elementary actuator is a light switch. We have emphasized potentially because as a result of the light switch being switched on it is not sure that the effect will be that light bulb goes on: only an associated sensor will be able to determine whether it went on or not. Other examples of devices are smart meters, mobile POS devices. More sophisticated devices may have a unique identifier, embedded computing capabilities and local data storage utilities, as well as embedded communication capabilities over short and/or long distances to communicate with IoT backend. Simple devices may not have all these capabilities and they can for instance only disclose the measurement results via mechanical means. In this latter case the further disclosure of the measurement result towards IoT backend requires another kind of device, called IoT Gateway.
  • Association. It is a physical/logical relationship between a device and a thing or a device and a group of things or a group of devices and a group of things from the perspective of a FI-WARE instance, an application within a usage area project or other stakeholder. A device is associated with a thing if it can sense or (potentially) influence at least one property of the thing, property capturing an aspect of the thing interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Devices are associated with things in fully dynamic or mainly static or fully static manner. The association may have several different embodiments: physical attachment, physical embedding, physical neighborhood, logical relation etc. Physical attachment means that the device is physically attached to the thing in order to monitor and interact with it, enabling the thing to be connected to the Internet. An example is the on-board device installed inside the vehicle to allow sending sensor data from the car to the FI-WARE instances. Physical embedding means that the device is deeply built inside the thing or almost part of the thing. An example of physical embedding is the GPS sensor inside a mobile phone. Physical neighborhood means that the device is in the physical neighborhood of the thing, but not in physical contact with it. An example of physical neighborhood is the association of the mobile phone of a subscriber who is caught in a traffic jam with the traffic jam itself: the mobile phone is the device, the traffic jam is the thing and the association means that the mobile phone is in the physical neighborhood of the area inside which the traffic jam is constrained (e.g. within 100 m from the region where the average speed of cars is below 5 km/h). Logical association means that there is a relationship between the device and the thing which is neither fully physical in the sense of attachment or embedding, nor fully physical proximity related. An example of logical association is between the car and the garage door opener of the garage where the car usually parks during the night.
  • IoT gateway. A device that additionally to or instead of sensing/actuating provides inter-networking and protocol conversion functionalities between devices and IoT backend potentially in any combination of these hosts a number of features of one or several Generic Enablers of the IoT Service Enablement. It is usually located at proximity of the devices to be connected. An example of an IoT gateway is a home gateway that may represent an aggregation point for all the sensors/actuators inside a smart home. The IoT gateway will support all the IoT backend features, taking into consideration the local constraints of devices such as the available computing, power, storage and energy consumption. The level of functional split between the IoT backend and the IoT gateway will also depend on the available resources on the IoT gateway, the cost and quality of connectivity and the desired level for the distribution of intelligence and service abstraction.
  • IoT resource. Computational elements (software) that provide the technical means to perform sensing and/or actuation on the device. There may be one-to-one or one-to-many relationship between a device and its IoT resource. Actuation capabilities exposed by the IoT resource may comprise configuration of the management/application features of the device, such as connectivity, access control, information, while sensing may comprise the gathering of faults, performance metrics, accounting/administration data from the device, as well as application data about the properties of the thing with which the device is associated. The resource is usually hosted on the device.
  • Management service. It is the feature of the IoT resource providing programmatic access to readable and/or writable data belonging to the functioning of the device, comprising a subset of the FCAPS categories, that is, configuration management, fault management, accounting /access management/administration, performance management/provisioning and security management. The extent of the subset depends on the usage area. Example of configuration management data is the IP endpoint of the IoT backend instance to which the device communicates. Example of fault management is an error given as a result of the overheating of the device because of extensive exposure to the sun. Example of accounting/administration is setting the link quota for applications using data from a certain sensor. Example of security management is the provisioning of a list of device ID-s of peer devices with which the device may directly communicate.
  • Application service. It is the feature of the IoT resource providing programmatic access to readable or writable data in connection with the thing which is associated with the device hosting the resource. The application service exchanges application data with another device (including IoT gateway) and/or the IoT backend. Measured sensory data are example of application data flowing from devices to sensors. Setting the steering angle of a security camera or sending a “start wetting” command to the irrigation system are examples of application data flowing from the application towards the sensor.
  • Event. An event can be defined as an activity that happens, occurs in a device, gateway, IoT backend or is created by a software component inside the IoT service enablement. The digital representation of this activity in a device, IoT resource, IoT gateway or IoT backend instance, or more generally, in a FI-WARE instance, is also called an event. Events may be simple and complex. A simple event is an event that is not an abstraction or composition of other events. An example of a simple event is that “smart meter X got broken”. A complex event is an abstraction of other events called member events. For example a stock market crash or a cellular network blackout is an abstraction denoting many thousand of member events. In many cases a complex event references the set of its members, the implication being that the event contains a reference. For example, the cellular network blackout may be caused by a power failure of the air conditioning in the operator’s data center. In other cases such a reference may not exist. For example there is no accepted agreement as to which events are members of a stock market crash complex event. Complex events may be created of simple events or other complex events by an IoT resource or the IoT backend instance.
  • IoT Backend. Provides management functionalities for the devices and IoT domain-specific support for the applications. Integrant component of FI-WARE instances.
  • IoT application. An application that uses the application programming interface of the IoT service enablement component. May have parts running on one/set of devices, one/set of IoT gateways and one/set of IoT backends.
  • Virtual thing. It is the digital representation of a thing inside the IoT service enablement component. Consists of a set of properties which are interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Classes of things have the same set of properties, only the value of the properties change from instance to instance.
Personal tools
Create a book