7 Representation of non-oneM2M entities in Proximal IoT networks

7.1 Representation of non-oneM2M Proximal IoT Devices

From a device management perspective in oneM2M, a device is represented using a resource. All management related capabilities of a device are then represented using child resources ( resource. This principle shall also be applied for non-oneM2M Proximal IoT devices (which are NoDNs), i.e. all aspects of device management of a device subject to device management methods defined in oneM2M should be exposed by using child resources of a resource. The resource instances representing device management aspects of non-oneM2M Proximal IoT devices shall be created by the responsible IPE on the IPE's Registrar CSE.

NOTE: The CSE-based DM approach uses [2] and Annex D of oneM2M TS-0004 [8]. For the IPE-based DM approach with Smart Device Template (SDT), as presented in this document, the IPE creates on its registrar CSE a [flexNode] clause 8.

If the device complies to oneM2M-defined information models - such as the ones defined in oneM2M TS-0023 [3] - the device should be represented using the respective specializations of resources specified in oneM2M. For example, a home domain device for a light as defined in oneM2M TS-0023 [3] is represented using the corresponding specializations of defined by the [deviceLight] resource type. If the information model of the device is not defined by oneM2M, a may also be used with its containerDefinition attribute configured with a URI linking to the schema definition for that device type specified by the respective organization. Also if the resource represents a non-oneM2M Proximal IoT device, the resource may be linked with the corresponding resource that is used to reflect device management aspects of the device or to indicate relationship(s) to applications on the device represented by resource instances, if applicable. The instances of specializations of resource types representing non-oneM2M Proximal IoT devices shall be created by the responsible IPE on the IPE's Registrar CSE. The preferred parent resource for such specialization of resource instances is the IPE's own resource instance. The linkage between an instance of a specialization of the resource type, representing a non-oneM2M Proximal IoT device, and the corresponding resource instance, that is used to reflect device management aspects or relationships to applications of the device, shall be established as follows:

A nodeLink attribute of the specialization instance, representing the non-oneM2M Proximal IoT device, shall point to the resource instance, which contains a [flexNode] specialization that has as children resources corresponding to SDT DM module classes defined in TS-0023 clause 5.8.For devices that do not follow any standardized information model nor have any management requirements, there is no distinct resource types to be instantiated in the oneM2M system for the representation of the device.

7.2 Representation of non-oneM2M Proximal IoT Applications

A general pattern in oneM2M is the use of instances of an resource to represent applications running on devices/gateways if needed. In addition, all services provided by these applications should be represented as child resources of the respective resource instance. By browsing the child resources of an resource instance, it is easily understood what are all the services provided by the respective application. If an application de-registers (i.e. the resource instance is deleted) from the system, all the resources representing its services are also deleted since they are child resources of the instance. For example, if an application is to report temperature data, after registration, an resource instance representing the application is created on the registrar CSE. The data reporting service is then e.g. represented as a or child resource of the resource. If the resource gets deregistered, the or resource is deleted at the same time. The same principles should be applied to represent non-oneM2M Proximal IoT Applications on NoDN(s) and the services they provide (see clause 7.3).

According to the specific needs in a service deployment, the service provider may deploy one or multiple application instances on one device. Each NoDN application instance that needs to be exposed to the oneM2M system shall be represented by one resource instance and be assigned with one unique AE-ID to identify the application instance.

Depending on the type of oneM2M node hosting an application, its resource instance(s) may be hosted by different types of CSEs in the oneM2M system:

  • For applications on ASNs and MNs, the corresponding resources shall be created under the of the corresponding ASN-CSE and MN-CSE, accordingly.
  • For applications on an ADN, the corresponding resources shall be created under the of the Registrar CSE of the ADN (which may be an MN-CSE or IN-CSE).

If there is a need to represent applications on interworked NoDNs - which is the case if the interworked applications need to be identifiable for the purpose of service subscription, charging, differentiation during access control enforcement, authentication, App-ID registry, etc. - then one or more resource instances shall be created to represent those applications. The IPE is responsible to issue requests to the oneM2M system on behalf of the interworked applications by using the AE-ID of the created resources. Care should be taken for determining the number of necessary security associations for the created resources. If there is no need to represent different applications when interacting with functions on interworked NoDNs just one resource shall be created as the representation of the IPE that is responsible for accessing the NoDN services.

When a non-oneM2M Proximal IoT application running on a NoDN is represented by an resource instance and at the same time device management aspects or relationships to applications of that NoDN are represented by a resource instance, the nodeLink attribute of that resource instance shall point to the resource instance corresponding to that NoDN. Also the reverse linkage via the hostedAELinks attribute of the resource shall be established.

7.3 Representation of non-oneM2M Proximal IoT Services

oneM2M defines different types of resources that may be used to represent services provided by a device. When representing non-oneM2M Proximal IoT services from interworked NoDN(s), proper resource types shall be chosen since the misusage of resource types for representing services may cause interoperability problems. General guidelines for resource representation of different services are as follows:

  • For device management services:
    • Specialized resource types as specified in oneM2M TS-0001 [2] and oneM2M TS-0022 [4], can be used. These resources are created as child resources of the resource, which represents the managed device (see clause 7.1).
    • Another approach, described in this document, is to use specialized resource types as specified in oneM2M TS-0023 [3], based on the SDT data model. These resources are created by the responsible IPE as child resources of a [flexNode] child of the resource, which represents the managed device (see clause 7.1).
  • Services defined in vertical domains specified in oneM2M TS-0023 [3] (agriculture, city, health, home, industry, railway, vehicular...): Specialized resource types for moduleClasses shall be used to represent those services.
  • Data management services (not covered by oneM2M TS-0023 [3]): , , , as specified in oneM2M TS-0001 [2] shall be used.
  • Location services: , , , , as specified in oneM2M TS-0001 [2] shall be used.
  • Group services: , , as specified in oneM2M TS-0001 [2] shall be used
  • Event/notification services: , , , , as specified in oneM2M TS-0001 [2] shall be used.
  • Security services: , , , , , , as specified in oneM2M TS0001 [2] and oneM2M TS-0003 [5] shall be used
  • Semantic services: , , , , , , , as specified in oneM2M TS-0001 [2] and oneM2M TS-0034 [6] shall be used.
  • Charging services: , , as specified in oneM2M TS-0001 [2] shall be used.

There are two ways of expressing relationships between resources as well as relationships between the services these resources represent: Parent-child relationship and linkage relationship. The linkage relationship only applies to specific oneM2M resource types such as , announced resources, and resources, etc.

The parent-child relationship of resources shall be used when the service represented by the child resource cannot exist independent of the services represented by the parent resource. If the parent service is deleted, the child services shall be deleted automatically.