oneM2M Basics
oneM2M is similar to a distributed Operating System for the Internet of Things. It takes the form of a middleware service layer consisting of a suite of common service functions (CSFs). The middleware service layer sits between applications and connectivity transport. oneM2M's common service functions (CSFs) are exposed to applications and to IoT devices via RESTful APIs.
A oneM2M service layer and/or applications can reside in field devices and sensors, on gateways and in back-end or cloud applications. This supports cooperative intelligence in distributed IoT systems.
This section covers the following topics:
Service Layer
oneM2M’s Service Layer is typically implemented as a software layer. It sits between IoT applications and processing or communication hardware corresponding to the connectivity layer. Data storage, processing and transport in the connectivity layer normally rides on top of IP. However, oneM2M also supports non-IP transports via interworking proxies.
The oneM2M Service Layer provides commonly needed functions for IoT applications. To date, oneM2M specifications cover fourteen such functions. Developers can use these functions progressively for their applications, beginning with the most frequently required ones such as device management, registration and security. More complex applications can incorporate features to support semantic interoperability and location services, for example.
oneM2M follows a modular standardisation roadmap. This allows for future IoT requirements and new common service functions.
Functional Architecture
oneM2M standards comprise a horizontal architecture in the form of a three-layer model comprising applications, middleware services and networks.
The oneM2M functional architecture comprises the following entities:
- Application Entity (AE): The Application Entity is an entity in the application layer that implements application service logic. Examples of AEs include an instance of a fleet tracking application, a remote blood sugar measuring application, a power metering application or a pump controlling application. Each application service logic can be resident in a number of nodes and/or more than once on a single node. Each execution instance of an application service logic is termed an "Application Entity" (AE) and is identified with a unique AE-ID.
- 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. Examples of service functions offered by a 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. Each CSE is identified with a unique CSE-ID.
- 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.
Application Entities (AEs) are hosted on nodes (e.g., enterprise server, device). These nodes may be virtualized or physical instances. AEs communicate with each other by sending requests to a Common Service Entity (CSE) that, in turn routes the request to the target AE while providing services based on the request. CSEs are hosted on virtualized or physical nodes. An AE and a CSE can share the same node (e.g., device).
It is possible to enable bi-directional communications between oneM2M and non-oneM2M systems via an IPE (Interworking Proxy Entity). This is a specialized AE (Application Entity) that allows the oneM2M system to interact with any non-oneM2M system, in a seamless way, through the Mca interface. It relies on the capability to remap non-oneM2M data models to oneM2M resources (<AE>, <container>, <flexContainer>, etc.).
oneM2M Nodes
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 / actuators / aggregators / gateways are deployed – and the “Infrastructure Domain” – i.e. the domain in which servers and applications on larger computers reside.
Nodes can be of the following types:
- 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 constrained devices up to more powerful hardware. Examples of devices that could be represented by ASNs include data collection devices, more capable sensors and actuators including simple server functions.
- 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 constrained device that may not have access to ample storage or processing resources and – therefore – may be limited to only host a oneM2M AE and not a CSE. Examples for devices that could be represented by ADNs include simple sensor or actuator devices.
- Middle Node (MN): a Node that contains one CSE and could also 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 also contain AEs. There is exactly one IN in the Infrastructure Domain per oneM2M Service Provider.
- Non-oneM2M Node (NoDN): A Node that does 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.
oneM2M Reference Points
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 Node.
-
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.
Common Service Functions (CSFs)
oneM2M defines a set of common service functions that apply to all the IoT domains. Think of these functions as items in a large toolbox to solve a number of IoT problems across many different domains. For example, a screwdriver can be used to fasten screws in a car as well as in a plane. In the same way, oneM2M CSFs, such as device management or security, are applicable to different IoT use cases and across different industry domains.
oneM2M members analysed a large number of IoT use cases to identify a set of common requirements in the initial phase of standardisation. This process resulted in the design of a set of Common Service Functions. Furthermore, oneM2M standardized how these functions are executed, i.e. it defined uniform APIs to access these functions.
CSFs are general purpose services and are not specific to any IoT domain in particular. This enables each domain to build on top of this service layer and focus on its specific industrial needs. This is similar to functions of a generic operating system (OS) exposed to applications running on that OS. For instance, many applications read and write to files. File I/O is typically provided by the OS. oneM2M’s Service Layer provides similar functions in a generic way to many different IoT Applications.
The common services functions reside within a CSE They provide services to the AEs via the Mca reference point and to other CSEs via the Mcc reference point.
Data Management
Within oneM2M, data storage relies on a Container type of resource. A Container is an entity that is associated with an object within an IoT system. This could be a specific sensor or a specific location, such as a room in a building, for example.
Containers are defined by the publisher of the data. This requires a function to discover and understand the data that an application wishes to consume. The scope of data management within oneM2M encompasses a set of CSFs that allow developers to manage Access Control Policies, Subscription & Notification functions and Discovery.
Horizontal Platform
The practice of building single-purpose and “vertical” domain applications leads to isolated silos. This makes it difficult to exchange data and to address cross-domain use cases. In contrast, a “horizontal” architecture allows the provision of a seamless interaction between applications and devices, even across silos and “verticals”.
Using the example of a smart building use case, a security application can detect when nobody is in the building. It could then trigger lights to be switched off and for the air conditioning system to operate on a reduced setting.
