Jump to: navigation, search

IoTDM Overview


The Internet of Things Data Management (IoTDM) on OpenDaylight (ODL) project is about developing a data-centric middleware that will act as a oneM2M compliant IoT Data Broker and enable authorized applications to retrieve IoT data uploaded by any device. The ODL platform is used to implement the oneM2M data store which models a hierarchical containment tree, where each node in the tree represents an oneM2M resource. Typically, IOT devices and applications interact with the resource tree over standard protocols such as CoAP, MQTT, and HTTP.

Initially, the oneM2M resource tree is used by applications to retrieve data. Possible applications are inventory/device management systems or big data analytic systems designed to make sense of the data collected. But, at some point, applications will need to configure the devices. Features and tools will have to be provided to enable configuration of the devices based on applications responding to user input, network conditions, or some set of programmable rules or policies possibly triggered by the receipt of data collected from the devices.

The ODL platform, with its rich unique cross-section of SDN capabilities, NFV, and now IOT device and application management, can be bundled with a targeted set of features and deployed anywhere in the network to give the network/service provider ultimate control. Depending on the use case, the ODL IOT platform can be configured with only IOT data collection capabilities where it is deployed near the IOT devices and its footprint needs to be small, or it can be configured to run as a highly scaled up and out distributed cluster with IOT, SDN and NFV functions enabled and deployed in a high traffic data center.

Software Architecture

The ODL platform was chosen to implement the oneM2M data manager for its rich feature set:

  • MDSAL and transactional data store is a natural fit for the oneM2M resource containment tree
  • Flexible support for protocol plugin’s
  • Clustering support for scale and performance
  • Flexible distribution/deployment capabilities via OSGI and karaf
  • Potential to leverage AAA and Group Based Policy features
  • SDN and NFV feature interaction

Block Diagram


Directory Structure

The following is the outline for the IOTDM repository ...

├── onem2m
│   ├── onem2m-api
│   ├── onem2m-core
│   ├── onem2m-notifier
│   ├── onem2m-protocols
│   │   ├── coap
│   │   ├── http
│   │   ├── mqtt
│   ├── onem2m-karaf
│   ├── onem2m-features
│   ├── onem2m-artifacts

Component Descriptions

  • onem2m-karaf: this is the folder which contains a local distribution of karaf which contains the onem2m karaf features defined in the features.xml file in the iotdm-features directory
  • onem2m-features: contains the features.xml file which define the onem2m feature set, repos, dependencies, and config files.
  • onem2m-api: the definition of the oneM2M resources are defined in the onem2m-api yang files. In addition, the RPCs to manage the resource tree are defined here.
  • onem2m-core: the provider of the oneM2M resource containment tree. The onem2m-core provides/implements the MDSAL RPCs defined in the onem2m-api yang files. These RPCs enable oneM2M resources to be created, read, updated, and deleted (CRUD), and also enables the management of subscriptions. When resources are CRUDed, the onem2m-notifier issues oneM2M notification events to interested subscribers. TS0001: oneM2M Functional Architecture and TS0004:oneM2M Service Layer Protocol are great reference documents to learn details of oneM2M resource types, message flow, formats, and CRUD/N semantics.
  • onem2m-notifier: the manager of the oneM2M notification subsystem. The onem2m-core implements the MDSAL RPCs defined to CRUD subscription resources. These are special resources that enable subscribers to be notified if normal oneM2M resources are CRUDed. This is the publish-subscriber mechanism defined by oneM2M.
  • onem2m-protocols: the root directory for the oneM2M wire protocols. oneM2M defines request/response/error message formats for each of the CRUD operations and resource types. It also specifies how each of the oneM2M attributes are mapped/adapted to run over a specific wire-protocol message fields. TS0004:oneM2M Service Layer Protocol describes generally oneM2M messaging. The message formats can be sent with a JSON payload, or an XML payload. OneM2M defines the oneM2M<ResourceType>.json and .xsd formats for each resource. The software has to handle eventually both formats.
    • coap: The Constrained Application Protocol (CoAP), is documented in RFC7252; https://datatracker.ietf.org/doc/rfc7252. The way oneM2M defines how it should be used is described in TS0008: CoAP Protocol Binding. This wire-protocol uses the Eclipse Technology Project: Californium which implements the CoAP protocol. See http://eclipse.org/proposals/technology.californium for details on the implementation. onem2m-protocols/coap instantiates a Californium CoapServer, and implements each of the :handleGet(), handleDelete(), handleUpdate(), and handleCreate() methods. These methods adapt the coap formatted messages into internal oneM2M messages as defined in the iotdm-api yang files, then sends RPCs over MDSAL to the onem2m-core for further processing.
    • mqtt: This will be documented further once we start to look at it. It is not at present in the Lithium release. TS0010: MQTT Protocol Binding.
    • http: TS0009: HTTP Protocol Binding documents how to map oneM2M messages onto the HTTP protocol.