Deploy with oneM2M

Using oneM2M devices and platforms

This information is for application developers and solution providers that want to deploy IoT systems using publicly available and pre-built oneM2M devices and platforms. This could be as simple as registering an IoT device to feed data to an IoT platform or, a more complex arrangement to gather data from multiple sources to feed into an IoT application or visualisation dashboard. 

By using pre-built oneM2M components, solution providers can focus on use-case and application issues and not have to build the reusable components of a full IoT technology stack.

The starting point is an overview of oneM2M and its basic elements. There follows a step-by-step description of how to apply these concepts through several use cases. Finally, application developers can access device and platform implementation resources. Some are available for download. Others are accessible as web-hosted services. Developers can get more information and interact with other developers via oneM2M’s StackOverflow developer forum and testing tools.

Further Reading & Information

For more detailed information about oneM2M standards, readers can refer to:

For any other information needs, check our FAQs or contact oneM2M via (insert email address).   

 

 

Overview and Introduction to oneM2M Basics

In this section, you will learn about the basics of oneM2M and how to build IoT systems using the architectural framework and common services toolkit defined in the oneM2M standard. This section also contains links to example use-cases, downloadable software, development tools and community resources.

  

 

Architecture and Common Service Functions 

oneM2M is an end-to-end technology for IoT systems that can include end-point, sensor and data visualization devices, IoT gateways and platforms and interfaces to non-oneM2M sub-systems that may involve proprietary technologies or the reuse of established industry standards. It is applicable to a range of application domains, including intelligent factories, smart cities and smart homes.

To illustrate oneM2M’s end-to-end framework and the benefits of standardization in complex and evolving systems, consider the example of a connected street lighting scheme. This use case illustrates the basic components of an IoT system beginning with connected devices and the flow of data to a dashboard and control application. This use case can also evolve over time to interoperate with other deployments in a city, such as a transportation hub or a large waste handling site.

An example deployment might include street lights in three different locations, each using a different connectivity technology (cellular NB-IoT, LoRA and SigFox). Gateway units for each of these subsystems act as the interface, or Interworking Proxy Entity (IPE) in oneM2M terminology, to supply IoT data into a cloud IoT platform which is known as a Common Services Entity (CSE).

 

The IoT platform also receives data from a municipal database, via a standardized protocol between a oneM2M Application Entity (AE) agent in the database and the CSE. The database might include location and configuration data for each street light which can help with maintenance activities. It might also contain operational data about temporary street closures or licenses for night-time markets which would affect street lighting needs.

The IoT platform supplies data to a dashboard and can respond to commands from a control panel. It can send and receive data from a third-party analytics service via an IPE in the case of an external and proprietary system.


The basic components of this architecture are Application Entities (AEs), Interworking Proxy Entities (IPEs) and Common Service Entities (CSEs).

  • AEs represent the applications (Apps) that reside in connected devices and sensors. AEs can also reside in the devices that support user applications and services such as visualisation dashboards and analytics applications. These AE’s (Apps) communicate with the oneM2M Service Layer via REST API’s.

  • IPEs provide the means to create an interface between non-oneM2M technologies (e.g. legacy devices) and the oneM2M service layer standard. An IPE functions as an adapter to translate between oneM2M and non-oneM2M protocols and data models. oneM2M has standardized  this mode of interworking for several mainstream technologies. Examples include interfaces to the Modbus protocol for programmable logic controllers in the industrial sector and the ZigBee protocol for smart home devices.

  • CSEs represent the oneM2M Service Layer that reside in gateways, servers and in some higher-capability user devices. This layer offers common data and connectivity services that are needed for typical IoT deployments.

CSEs host a set of Common Service Functions (CSFs). These form a toolkit of basic capabilities that developers can call upon when building and deploying IoT systems. They include the following:

  • Registration: establishes authorization and authentication relationships between AEs and CSEs via a single registration point (registrar CSE.

  • Discovery: searches information about applications and services contained in attributes and resources, subject to filter criteria and access control policies.

  • Security and access control: provides functionality for the handling of sensitive data; security administration; establishment of security associations; access control (identification, authentication, and authorization); and identity management.

  • Group Management: handles group related requests for bulk operations (e.g. read, write, subscribe, notify, device management) supported by the group and to re-use broadcasting or multicasting capabilities supported by underlying networks.

  • Communication Management and Delivery Handling: manages and controls communication between CSEs, AEs and NSEs. It determines at what time to use which communication technology and, when needed and permitted, to buffer communication requests for later transmission.

  • Data Management & Repository: provides data storage and mediation functions for the exchange of data between devices and applications. A simple example is a device that generates measurement data while there is a lack of network connectivity coverage. This function takes care of storing the data locally and transmitting when connectivity is recovered. This includes the capability to collect and aggregate large amounts of data, conversion into a specified format, and storage for subsequent analysis and semantic processing. The data can be either raw data transparently retrieved from an IoT device, or processed data which is calculated and/or aggregated by IoT entities.

  • Subscription & Notification: tracks event changes on a resource (e.g., deletion or change of a resource by an application) and provides notifications to applications that subscribe to the resource.

  • Device Management: abstracts the management of device capabilities for devices and gateways and exposes them commonly towards the applications.

  • Application & Service Management: provides capabilities to configure, troubleshoot and upgrade the functions of CSEs and to upgrade AEs, taking account of different node types (e.g. constrained devices, gateways, servers).

  • Network Service Exposure: manages communications for services such as device triggering, small data transmission, location notification, policy rules setting, location queries, IMS services and device management. This CSF provides an abstraction layer to shield AEs from the specific technologies and mechanisms supported by underlying networks.

  • Location: allows AEs to obtain geographical location information of nodes for location-based services.

  • Service Charging & Accounting: manages charging policies and generates charging records for events at the service layer. It supports different charging models, including online real time credit control, and can also interact with the charging system in underlying networks.

  • Semantics: provides the foundation for semantic interoperability, comprising abstract data modelling and, the application of ontology and semantic descriptions to enable the exchange of data between different user entities. oneM2M specifications leverage semantic tools like RDF/OWL to construct the oneM2M Base Ontology as the common vocabulary for interworking with heterogeneous systems.

  • Transaction Management: assists applications with the atomic and consistent processing of transactions. The CSF supports the scheduling of a transaction, the locking and unlocking of resources targeted by a transaction, the atomic and consistent execution of a transaction on targeted resources, the committal of successful transaction results, and the abort and rollback of non-successful transactions.

 

 

REST APIs for Accessing Common Services Functions

Through the use of REST APIs exposed by the CSE, developers can focus on building their end-to-end IoT solutions, drawing on reusable service layer capabilities defined in the oneM2M standard. These service layer functions provide the benefits of an abstraction layer, much like an operating system between actual applications and the underlying connectivity network that links IoT devices and data sources.  


Any IoT application can interact and leverage from oneM2M CSF’s via the Machine-Application reference point (Mca). Any interaction between the CSE and an underlying network connectivity entity (Network Service Entity) is handled via the Machine Network reference point (Mcn). The reference point for communications flows between two CSEs is the Mcc reference point. These flows enable a CSE to use services supported by another CSE.

 

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.


The oneM2M API is used by CSEs and AEs to communicate with one another. The communication can be originated from an AE or CSE depending on the operation. oneM2M REST APIs handle CRUD+N (Create, Retrieve, Update, Delete and Notification) operations for oneM2M resources specified in oneM2M standards.

The oneM2M API includes the following components:

  • Primitives
  • Resources + Attributes
  • Data Types
  • Protocol Bindings
  • Procedures (CRUD+N).

 

 

oneM2M Resources

oneM2M utilizes a resource-based approach for all components in an IoT system. Every function and all the data from devices, backend and management systems are represented as a resource in a tree structure. These resources can be discovered, retrieved and updated following CRUDN principles. 

Example resources are AEs (applications), which can access the service layer after a successful registration. Containers are another resource type and used to structure and store data generated by AE’s. A different category of resource is the subscription policies that define notifications of changes to other resources. 


Each resource represents a type of functionality with a defined set of mandatory and optional attributes as well as child resources. The attributes are :

  • Universal Attributes : which appear in all resources

  • Common Attributes : which appear in more than one resource and have the same meaning whenever they do appear.

  • Resource-specific attributes

Access to these resources is based on Access Control Policies (ACPs). These are technology-independent and defined via Reference Points that can be implemented using various technologies such as HTTP, MQTT, or SOAP.

All information in a oneM2M System corresponding to AEs, CSEs, application data representing sensors, commands, etc. is represented as a resource in the CSE. The root of the oneM2M resource structure is the <CSEBase> resource. The <CSEBase> resource is assigned an absolute address. All other child resources are addressed relative to the <CSEBase>.

 

Getting Started

One of the simplest use cases for experimenting with oneM2M involves connecting a sensor to an IoT platform to collect its data and display it on a dashboard. This procedure involves several steps to register a device, to set up a data storage container and to notify a dashboard application when new data is available. Each of these steps is simplified through the use of a common service function in the oneM2M toolkit.

This site contains links to a set of illustrative use cases, pre-built device and platform resources and developer support tools and forums.