5 Introduction

The scope of Proximal IoT Interworking is to enable the exchange of information between different things, devices and applications and the use of services they provide, irrespective of whether they are designed as oneM2M-defined entities according to the Functional architecture specified in oneM2M TS-0001 [2] or according to other non-oneM2M-defined Proximal IoT technologies. Proximal IoT Interworking can be modelled to be composed of actions on several layers: On the connection layer, on the resource framework layer and on the information model layer:

  • Interworking on the connection layer - focus on the connection of entities. Two entities are interworkable if they support the same communication interface and communication protocol. Examples include Wifi connection, 3GPP wireless connection, etc. If two entities are interworkable on the connection layer, it is only guaranteed that data could be sent from one to another.
  • Interworking on the resource framework layer - focus on the data types, resource template and data schemas. Two entities are interworkable if they share the same serializations, data types and resource templates. For example, if both entity can share information with the common understanding of xml schema, each entity will be able to recover the complete information contained in the message. Examples include SOAP, REST API, with specified serializations, etc.
  • Interworking on the information model layer - focus on the information model, data model and common semantic understanding. Two entities are interworkable if they share the same information model and semantics. For example, in a smart home scenario, a light switch, a home gateway and an application that share the same information model can actually deploy the service of switching on and switching off the light if all of them use an information element with content "ON" to represent switching on the light and "OFF" to represent switching off the light. If the light switch is using "ON" but the application is using "TRUE" , the service cannot be deployed.

Interworking on the resource framework layer depends on the connection layer, and interworking on the information model layer depends on the resource framework layer.

To enable such consistent exchanges, oneM2M has designed the entire end to end architecture spanning entities for the platform (IN-CSE), gateways (MN-CSE) to devices (ASN and ADN), as described in oneM2M TS-0001 [2]. Corresponding to each layer, oneM2M has specified dedicated definitions for the enablement of:

  • Interworking on the connection layer - Bindings defined by oneM2M i.e. HTTP, CoAP, MQTT and Websocket binding and associated procedures.
  • Interworking on the resource framework layer - Serializations and resource structures defined by oneM2M.
  • Interworking on the information model layer - The definition or the import of existing information models including the associated procedures in oneM2M, for example the SDT-based Information Model and Mapping for Vertical Industries in oneM2M TS0023 [3]. For device management purposes, it is either possible to:
    • Use the CSE-based approach (described in TS-0001 [2]clause 6.2.4.1.1) with external technology specific protocols (e.g. BBF TR069, OMA-DM, and LWM2M): in this case, the information model uses specializations of as defined in Technical Specifications oneM2M TS0001 [2] and oneM2M TS-0022 [4]. Information models are detailed in specific documents (TS-0005 for OMA protocols, TS-0006 for BBF protocols), and operations in TS-0001 [2]clause 10.2.8 and Annex D of TS-0004 [8].
    • Or use IPE-based approach (described in TS-0001 [2]clause 6.2.4.1.2) with Smart Device Template (SDT) module classes defined in oneM2M TS-0023 [3]clause 5.8. The operations are detailed in clause 8 of the present document.
    • Or use native oneM2M operations, with either

The focus of the present document is the interworking on the information model layer and the implications on how to represent external Proximal IoT functions with means of resource instances in the oneM2M system.

However, the set of resource structures defined by oneM2M is very loosely coupled with the service of devices which may still cause interworking problems. Using CRUDN operations [2] on resources defined by oneM2M is the mechanism to enforce the common services oneM2M is trying to deliver. How to use these common services relies on interpretation of the implementer of the standard. For devices designed for non-oneM2M Proximal IoT technologies, if services of these devices are exposed to oneM2M entities using resources in inconsistent ways, it is still very hard to enable the interworking with these devices, because consumers of the services may need additional adaptation depending on different interpretations of resource content and relationships in different implementations.

In the present document, a general interworking architecture and framework to enable interworking up to the information model layer is defined.

For Device Management purposes, some generic guidelines for CRUDN operations on DM SDT modules are defined in clause 8. Detailed procedures depend on the underlying Proximal IoT Technologies.