AOS OneM2M Key Concepts
AOS currently implements aspects of Release 2 of the oneM2M specification.
- Official Documentation:
- TS-0001 "Functional Architecture"
- Architectural overview of OneM2M. The best place to start.
- Documents all the Resource types and their attributes, and the relationships between Entities.
- TS-0004 "Service Layer Core Protocol"
- All the fundamental implementation details.
- Includes a complete explanation of Resource addressing.
- TS-0008 "CoAP Protocol Binding"
- Covers using CoAP as the transport-level protocol underlying oneM2M message passing.
- TS-0009 "HTTP Protocol Binding"
- Covers using HTTP as the transport-level protocol underlying oneM2M message passing.
- Infrastructure domain: generally speaking, the cloud services belonging to the service provider
- Field domain: field devices that report to and are managed by the systems in the infrastructure domain
- CSE: Common Service Entity. A server that provides oneM2M-related services to client Applications via RESTful APIs
- AE: Application Entity. An application that registers with a CSE in order to use its oneM2M-related services
- AppName: Application Name. AE's specify their AppName and App-ID when they register.
- App-ID: Application Identifier. Uniquely identifies an M2M application. Registered App-IDs are globally unique.
- Infrastructure Node: The node (server) containing the CSE in the infrastructure domain
- Middle Node: A field device that contains a CSE
- IN-CSE: the CSE in the infrastructure domain
- MN-CSE: a CSE that resides in a field device and registers with the IN-CSE
- IN-AE: an application (AE) that resides in the infrastructure domain and registers with the IN-CSE
- MN-AE: an application (AE) that resides on a field device and registers with a co-resident MN-CSE. I.e. a hosted app.
- ADN-AE: an application (AE) that resides on a device that does not have its own MN-CSE. It registers with one over a network.
- Resource Tree: Hierarchy of addressable resources hosted by a CSE
- Resource: uniquely addressable entity in oneM2M architecture A resource is transferred and manipulated using CRUD operations. A resource can contain child resource(s) and attribute(s), which are also uniquely addressable.
- Commonly used Resources:
- AE: represents an Application Entity
- remoteCSE: represents a remote CSE (the IN-CSE in the case of an MN-CSE, and vice versa)
- node: represents a node, i.e. a physical device, which may host a CSE and AEs. The parent resource for management operations.
- container: a parent resource for contentInstance resources, and child containers
- contentInstance: a resource for storing arbitrary data within a container
- subscription: used for subscribing to resources in order to be notified of changes, for example the adding of contentInstances to a container
The IN-CSE is the central server to which MN-CSEs and IN-AEs register and use its services.
In the field, a device hosts an MN-CSE. Co-resident apps on the device may register as MN-AEs with the MN-CSE to gain access to oneM2M services provided locally and in the cloud.
Additional devices in the field may join an MN-CSE's network (for example by associating to the Wi-Fi AP of the hosting device). They can then register as an ADN-AE with the local MN-CSE.
Each CSE hosts a hierarchical Resource Tree. A resource is a uniquely addressable entity in oneM2M architecture. A resource is transferred and manipulated using CRUD operations. A resource can contain child resources and attributes, which are also uniquely addressable.
The root of the resource tree is the "cseBase" resource. Child resource types of the cseBase include "node", "AE", "remoteCSE", "container", and other resources types.
When an MN-CSE registers with an IN-CSE, it creates a "remoteCSE" resource under the IN-CSE cseBase to represent itself, and it creates a "remoteCSE" resource under its own cseBase to represent the IN-CSE.
When an AE wants to register with a CSE, it sends a request to the CSE to create an "AE" resource under the local cseBase. During the registration process on a middle node, the MN-CSE requests to create an AEAnnc (announced AE) resource under its respective remoteCSE resource in the IN-AE resource tree. If registration is successful, the AE receives a success response containing a representation of the AE resource.
Containers and contentInstances are the primary mechanism by which AEs communicate with each other. In some cases they are used by AEs to access local system services as well. Container resources can have three types of child resources: containers (to form a container hierarchy), contentInstances (to hold and publish data in a container), and subscriptions (to generate notifications on changes to the container).
When an AE creates a container, it can include resource attributes which control the behavior of the container, such as the maximum number of contentInstances they can hold, or the maximum total amount of bytes it can contain. The AE can then create contentInstances in the new container, or create a subscription under it, to be notified when contentInstances are created (or deleted).
A typical data reporting pattern is for an IN-AE to create a child container in the IN-CSE for receiving data. It then creates a subscription on the container to be notified when contentInstances are created. An MN-AE on a device can then publish content to the data container and the IN-AE will be notified of its arrival. The address of the data resource can be a predetermined, fixed address, or it can be provided to the MN-AE through factory or over-the-air (OTA) configuration.
For OTA app configuration, an AE can create a container for receiving contentInstances with configuration data, to which it would then subscribe. The IN-AE would then publish configuration data to that container.
The AOS SDK additionally provides a convenient api for receiving app configuration data. It uses the method described above, but hides the details, allowing the app to simply register a callback to be invoked when configuration data is available.
