6 General interworking architecture

6.1 Concept of Representation

In the oneM2M system, any kind of device, application or service or more generally speaking any kind of function that needs to be exposed to oneM2M-specified entities such as CSEs or AEs is represented by instances of specified resource types. Interaction with these termed functions is enabled by executing operations (e.g. create, delete, retrieve, update) on the resource instances. For example, by updating an attribute of a particular resource instance, an AE can change the state of a light actor from on to off. In addition, the concept of subscribing to resource instances and receiving notifications about content changes is also specified in oneM2M to allow for efficient monitoring of resource instances and thus the exposed function(s).

Following that fundamental concept of representing all functions by resource instances and their operations, real world devices or things in Proximal IoT networks that were not designed according to oneM2M specifications including the applications running on devices and/or services provided by devices can be represented by resource instances in the oneM2M system if interworking with those devices or things is needed. The resource instances are digital representations for the real world devices or things that are exposed to other entities in the oneM2M system via the oneM2M-specified interfaces for executing operations on those resource instances. How such resource instances, representing non-oneM2M Proximal IoT functions, are to be created and managed is described in the remainder of the present document. Furthermore, it is also described how to expose functions that are natively accessible in the oneM2M system, via the oneM2M-specified resource types and interfaces, to non-oneM2M Proximal IoT networks.

A representation of a non-oneM2M Proximal IoT function in a oneM2M-specified resource instance needs to be synchronized with the entity that it actually represents. For instance, if an attribute of a resource instance that represents the power state of an external Proximal IoT light is modified, the actual light state needs to be modified accordingly. The remainder of the present document describes how such synchronization is accomplished. Essentially any request targeting the representation of a non-oneM2M Proximal IoT function results in the corresponding interaction with the external device or thing in the Proximal IoT network. Similarly, any action in a non-oneM2M Proximal IoT function that is associated with a representation in the oneM2M system contained in a oneM2M resource instance shall result in an according operation on that resource instance.

Adhering to this concept of representation, oneM2M entities (AEs and CSEs) are enabled to request services or information provided by external non-oneM2M devices or things - termed "non-oneM2M Proximal IoT functions" - in the same way as interaction with native oneM2M devices or things - termed native oneM2M functions - is done.

6.2 Role of IPE(s)

6.2.1 Fit with the Functional Architecture

oneM2M is using an Interworking Proxy Entity (IPE) to handle the interworking between the oneM2M system and external non-oneM2M Proximal IoT functions residing on Non-oneM2M Device Nodes (NoDNs). The functional relationship between a NoDN and the CSE that is supposed to host the interworking functionality is defined in the following, see also Annex F of oneM2M TS-0001 [2].

Figure 6.2.1‑1: Interworking through IPE

An Interworking Proxy Entity is an AE that supports both, the oneM2M Mca reference point as well as the nononeM2M interface that the functions on one or more connected NoDN(s) require. The IPE is responsible for synchronizing the services provided by the non-oneM2M Proximal IoT functions on the NoDN with oneM2M resource instances and vice versa. The IPE can be deployed together with the CSE or NoDN, or the IPE can also be deployed separately. Deployed together means running in the same execution environment or running on the same operating system where in such case, the communication between the deployed entities doesn't involve remote communication through wired or wireless network. In this kind of deployment, the communication method for supporting communication between the functional entities depicted in Figure 6.2.1‑1 shall be provided by the execution environment or the operating system, e.g. inter-process communications, function calls, service call-backs or message bus technologies.

The IPE is registered to the CSE that is meant to host the interworking functionality and it translates the functions or services provided or consumed by one or more NoDN(s) to or from content of resource instances that are hosted by CSEs in the oneM2M system. When such resource instances represent functions or services provided by NoDN(s) connected to a specific IPE, the Registrar CSE of that IPE shall host those resource instances. The IPE shall translate any occurrence of operations on the oneM2M resource instances into invocation of the corresponding non-oneM2M Proximal IoT functions provided by the connected NoDN(s) and vice versa when non-oneM2M Proximal IoT functions executed on any connected NoDN(s) need to be reflected by change(s) of content in the corresponding representation(s) in oneM2M resource instances.

NOTE: More than one IPE may be instantiated in order to support interworking with an external non-oneM2M Proximal IoT technology. Also, an IPE may instantiate one or more supporting AEs that are used to simplify correlation with AE aspects such as service subscription profiles, access control privileges, authentication, authorization, etc.

6.2.2 Exposure of Proximal IoT functions to the oneM2M System

The role of an IPE, when it comes to exposure of external non-oneM2M Proximal IoT functions to the oneM2M System, includes the creation, monitoring, modification (update/delete) of resource instances that are supposed to represent those external functions on its own Registrar CSE. This role also includes the following:

• The IPE needs to determine which non-oneM2M Proximal IoT functions need to be exposed (e.g. through provisioning, discovery, on-demand signalling, etc.) and detect dynamic changes of the set of the nononeM2M Proximal IoT functions to be exposed. On-demand discovery or change of exposure configurations may be triggered by other AEs/CSEs by modifying corresponding resource instances created by the IPE. A request to trigger discovery or to demand a change of the exposure configuration can be accomplished, for instance, via creation and monitoring of a resource instance by the IPE, under which authorized AEs can create resource instances, that indicate which action to take. Details of such a triggering mechanism are implementation dependent and will not be further specified in the present document.
• The IPE needs to handle creation/deletion of resource instances representing non-oneM2M Proximal IoT functions according to the - possibly dynamically changing - need to expose them to the oneM2M system using resource types that are independent of the external Proximal IoT technology.
• The IPE is responsible to modify the resource instances representing the non-oneM2M Proximal IoT functions according to any state changes occurring in the external Proximal IoT system.
• The IPE is responsible for monitoring relevant changes in the resource instances representing the non-oneM2M Proximal IoT functions and invocation of appropriate non-oneM2M Proximal IoT function(s) when any operation(s) meant to trigger the execution of that non-oneM2M Proximal IoT function(s) occur for those resource instances in the hosting CSE. This monitoring can be achieved for instance by creating under each such resource a resource with eventNotificationType attribute set to "Blocking_Update".

The set of responsibilities of the IPE when exposing non-oneM2M Proximal IoT functions to the oneM2M system is summarized in Figure 6.2.2‑1. The dashed boxes describe optional/alternative means to determine the set of exposed functions. Note that, in this Figure one IPE is responsible for all interworking actions. More than one IPE may be used to interwork with one particular Proximal IoT network. Also additional AEs may get instantiated by an IPE to support interworking, see clause 6.1. Details on the resource mapping are contained in clause 7.

Figure 6.2.2‑1: Exposure of Proximal IoT functions to the oneM2M System

6.2.3 Exposure of native oneM2M functions to the Proximal IoT System

The role of an IPE, when it comes to exposure of native oneM2M functions (aspects of devices, applications, services) to an external non-oneM2M Proximal IoT network, includes the monitoring, modification (update/delete) of resource instances that are representing oneM2M-internal functions to be exposed to an external non-oneM2M Proximal IoT network. This role also includes the following:

• The IPE needs to determine which native oneM2M functions need to be exposed to the external non-oneM2M Proximal IoT network (e.g. through provisioning, resource instance discovery, on-demand signalling, etc.) and detect dynamic changes of the set of native oneM2M functions to be exposed. On-demand discovery or change of exposure configurations may be triggered by other AEs/CSEs by modifying corresponding resource instances created by the IPE. A request to trigger discovery or to demand a change of the exposure configuration can be accomplished, for instance, via creation and monitoring of a resource instance by the IPE, under which authorized AEs can create resource instances, that indicate which action to take. Details of such a triggering mechanism are implementation depended and will not be further specified in the present document.
• The IPE needs to handle creation/deletion of functions in the non-oneM2M Proximal IoT network representing native oneM2M functions according to the - possibly dynamically changing - need to expose them to the non-oneM2M Proximal IoT network.
• The IPE is responsible to modify the resource instances representing exposed native oneM2M functions according to any events occurring in the external non-oneM2M Proximal IoT network that require state changes of the resource instances representing the exposed native oneM2M functions.
• The IPE is responsible for monitoring relevant changes in the resource instances representing exposed native oneM2M functions and invocation of the corresponding non-oneM2M Proximal IoT function(s) provided by the IPE when any operation(s) occur for those resource instances that require an indication of the changed state in the provided external functions.

The set of responsibilities when exposing native oneM2M functions to the external non-oneM2M Proximal IoT network is summarized in Figure 6.2.3‑1. The dashed boxes or lines describe optional/alternative means to determine the set of exposed functions. Note that, in this Figure one IPE is responsible for all interworking actions. More than one IPE may be used to interwork with one particular Proximal IoT network. Also additional AEs may get instantiated by an IPE to support interworking, see clause 6.1. Details on the resource mapping are contained in clause 7.

Figure 6.2.3‑1: Exposure of native oneM2M functions to the Proximal IoT System