TR-0057 Functional architecture
Functional Architecture description
oneM2M Layered Model comprises three layers:
the Application Layer,
the Common Services Layer
the underlying Network Services Layer.
oneM2M Layered Model
The oneM2M functional architecture comprises the following functions:
- Application Entity (AE): The Application Entity is an entity in the application layer that implements an M2M application service logic. Each application service logic can be resident in a number of M2M nodes and/or more than once on a single M2M node. Each execution instance of an application service logic is termed an "Application Entity" (AE) and is identified with a unique AE-ID.
Examples of the AEs include an instance of a fleet tracking application, a remote blood sugar measuring application, a power metering application or a pump controlling application.
- Common Services Entity (CSE): A Common Services Entity represents an instantiation of a set of "common service functions" of the oneM2M Service Layer. A CSE is actually the entity that contains the collection of oneM2M-specified common service functions that AEs are able to use. Such service functions are exposed to other entities through the Mca (exposure to AEs) and Mcc (exposure to other CSEs) reference points. Reference point Mcn is used for accessing services provided by the underlying Network Service Entities such as waking up a sleeping device. Each CSE is identified with a unique CSE-ID.
Examples of service functions offered by the CSE include: data storage & sharing with access control and authorization, event detection and notification, group communication, scheduling of data exchanges, device management, and location services.
- Underlying Network Services Entity (NSE): A Network Services Entity provides services from the underlying network to the CSEs.
Examples of such services include location services, device triggering, certain sleep modes like PSM in 3GPP based networks or long sleep cycles.
oneM2M Reference Points:
oneM2M Functional Architecture
The oneM2M functional architecture defines the following reference points:
Mca: Reference point for the communication flows between an Application Entity (AE) and a Common Services Entity (CSE). These flows enable the AE to use the services supported by the CSE, and for the CSE to communicate with the AE. The AE and the CSE may or may not be co-located within the same physical entity.
Mcc: Reference point for the communication flows between two Common Services Entities (CSEs). These flows enable a CSE to use the services supported by another CSE.
Mcn: Reference point for the communication flows between a Common Services Entity (CSE) and the Network Services Entity (NSE). These flows enable a CSE to use the supported services provided by the NSE. While the oneM2M Service Layer is, usually independent of the underlying network – as long as it supports IP transport – it leverages specific M2M/IoT optimization such as 3GPP’s eMTC features (e.g. device triggering, power saving mode, long sleep cycles, etc).
Mcc’: Reference point for the communication flows between two Common Services Entities (CSEs) in Infrastructure Nodes (IN) that are oneM2M compliant and that reside in different M2M Service Provider domains.
Additional reference points are defined in oneM2M for specific purposes such as enrolment functions etc. and are not detailed in this overview.
oneM2M has defined a set of Nodes that are logical entities identifiable in the oneM2M System. oneM2M Nodes typically contain CSEs and/or AEs. For the definition of Node types, oneM2M distinguishes between Nodes in the “Field Domain” – i.e. the domain in which sensors / actors / aggregators / gateways are deployed – and the “Infrastructure Domain” – i.e. the domain in which servers and applications on larger computers reside.
oneM2M node topology
Nodes can be of the following types:
Application Dedicated Node (ADN): a Node that contains at least one AE and does not contain a CSE. It is located in the Field Domain. An ADN would typically be implemented on a resource constraint device that may not have access to rich storage or processing resources and – therefore – may be limited to only host a oneM2M AE and not a CSE. Examples for devices that would be represented by ADNs: simple sensor or actor devices.
Application Service Node (ASN): a Node that contains one CSE and contains at least one Application Entity (AE), located in the Field Domain. An ASN could be implemented on a range of different devices ranging from resource constraint devices up to much richer HW. Examples for devices that would be represented by ASNs: data collection devices, more capable sensors and actors including simple server functions.
Middle Node (MN): a Node that contains one CSE and could contain AEs. MNs are located in the Field Domain. There could be several MNs in the Field Domain of the oneM2M System. Typically an MN would reside in an M2M Gateway. MNs would be used to establish a logical tree structure of oneM2M nodes, e.g. to hierarchically aggregate data of buildings / neighborhoods / cities / counties / states etc.
Infrastructure Node (IN): a Node that contains one CSE and could contain AEs. There is exactly one IN in the Infrastructure Domain per oneM2M Service Provider. An example of physical mapping, an IN could reside in an M2M Service Enablement Infrastructure.
Non-oneM2M Node (NoDN): This Node type is not shown in the figure above. oneM2M specifications also define a Node Type for non-oneM2M Nodes which are Nodes that do not contain oneM2M Entities (neither AEs nor CSEs). Typically such Nodes would host some non-oneM2M IoT implementations or legacy technology which can be connected to the oneM2M system via interworking proxies.