7.2 Representation of non-oneM2M Proximal IoT Applications

A general pattern in oneM2M is the use of instances of an <AE> 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 <AE> resource instance. By browsing the child resources of an <AE> resource instance, it is easily understood what are all the services provided by the respective application. If an application de-registers (i.e. the <AE> resource instance is deleted) from the system, all the resources representing its services are also deleted since they are child resources of the <AE> instance. For example, if an application is to report temperature data, after registration, an <AE> resource instance representing the application is created on the registrar CSE. The data reporting service is then e.g. represented as a <container> or <flexContainer> child resource of the <AE> resource. If the <AE> resource gets deregistered, the <container> or <flexContainer> 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 <AE> 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 <AE> resource instance(s) may be hosted by different types of CSEs in the oneM2M system:

• For applications on ASNs and MNs, the corresponding <AE> resources shall be created under the <CSEBase> of the corresponding ASN-CSE and MN-CSE, accordingly.
• For applications on an ADN, the corresponding <AE> resources shall be created under the <CSEBase> 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 <AE> 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 <AE> resources. Care should be taken for determining the number of necessary security associations for the created <AE> resources. If there is no need to represent different applications when interacting with functions on interworked NoDNs just one <AE> 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 <AE> resource instance and at the same time device management aspects or relationships to applications of that NoDN are represented by a <node> resource instance, the nodeLink attribute of that <AE> resource instance shall point to the <node> resource instance corresponding to that NoDN. Also the reverse linkage via the hostedAELinks attribute of the <node> resource shall be established.