Skip to main content



The OM2M project is a proposed open source project under the Eclipse Technology Project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the Eclipse community. Please send all feedback to the Eclipse Proposals Forum.


Machine-to-Machine communications (M2M) is a phenomenon that has been proceeding quietly in the background, and it is coming into the phase, where explosion of usage scenarios in businesses will happen. Sensors, actuators, RFID/NFC tags, vehicles, and intelligent machines all have the ability to communicate. The number of M2M connections is continuously increasing, and it has been predicted to see billions of machines interconnected in a near future. M2M applications provide advantages in various domains from building, energy, healthcare, industrial, transportation, retail, security to environmental services. This fast-growing ecosystem is leading M2M towards a promising future, however M2M market expansion opportunities are not straight forward.

M2M is suffering from the highly fragmented vertical domain specific approach, which has increased the R&D cost in each specific domain. In fact, various vertical M2M solutions have been designed independently and separately for different applications, which inevitably impacts or even impedes large-scale M2M deployment. The existence of multiple manufacturers, the lack of a common M2M Service Capability Layer and no clarity about what can be achieved have all combined to leave the field of M2M communications closer to dream than reality.

To reduce the standardization gap which exist between M2M domains, the ETSI Technical committee M2M defined an end to end M2M service platform with the intermediate service layer that are key components of the horizontal M2M solution. This standards based platform follows a RESTful approach with open interfaces to enable developing services and applications independently of the underlying network, thus easing the deployment of vertical applications for an effective interoperability, and facilitating innovation across industries.

To avoid creation of competing M2M standards the 7 standards developing organizations, that publish telecom standards: TTC, ARIB (Japan), ATIS, TIA (USA), TTA (Korea) CCSA (China), ETSI (Europe) started the OneM2M Global Initiative to develop one globally agreed M2M Specification with initial focus on Service Layer. OneM2M aims to consolidate current M2M Service Layer standards activities such as ETSI TC M2M (Europe), TIA TR-50 (USA) and CCSA TC 10 (China), and to reduce standardization overlap and confusion and provide ongoing standards support to enhance interoperability, reduce market fragmentation, and improve security and reliability.


The OM2M project is an open source implementation of the ETSI M2M standard. It provides a framework for developing services independently of the underlying network and aims to facilitate deployment of vertical applications and heterogeneous devices. The scope of this project can be summarized as follows:

  • Implement a Service Capability Layer (SCL) for an M2M network, M2M gateway and M2M device according to the ETSI M2M architecture.
  • API for applications is based on REST principles to enhance interoperability and allow exposing data and providing services through unreliable connections within a highly distributed environment.
  • Support generic communication technologies for ensuring multiple protocol binding such as HTTP and CoAP.
  • Re-use of the OMA-DM protocol as a remote entity management service to perform software updates and life-cycle managements on OMA-DM enabled devices based on SyncML files.
  • Ensure security based on the TLS-PSK protocol to enable secure communication based on pre-shared keys.
  • Provides various interworking proxies to enable seamless communication with non-ETSI compliant devices such as ZIGBEE and PHIDGETS technologies.
  • Manage M2M SCLs mutual authentications and M2M applications registrations
  • Provide advanced user profile, access right and permission management.
  • Enable synchronous communications based on the request/response design pattern.
  • Enable asynchronous event notifications based on the publish/subscribe design pattern.
  • Provide advanced mechanism for distributed M2M resource discovery.
  • Be the basis for the future implementation of the OneM2M standard.


The OM2M architecture follows the ETSI M2M standards. It is composed of the following elements:

  • M2M Device: a machine that runs an M2M device SCL (DSCL) that can be queried by M2M device applications (DAs) via an open interface. An M2M device can connect directly to the M2M Network or indirectly via a gateway that acts as a network proxy.
  • M2M Area Network: provides connectivity between M2M devices, and also between the devices and the M2M gateways. It is based on existing technologies such as Zigbee, Phidgets, M-BUS, KNX, etc.
  • M2M Gateway: a machine that runs an M2M Gateway SCL (GSCL) that can be queried by M2M Gateway applications (GAs) or DAs via an open interface. It identifies and addresses heterogeneous devices, and interconnects M2M area networks with different protocol technologies by performing mapping/converting operations.
  • Wide Area Network provides the core network with access networks to enable M2M devices and gateways to communicate with the M2M network. It is based on existing technologies such as xDSL, GERAN, UTRAN, eUTRAN, W-LAN, WiMAX, etc.
  • M2M Network: provides an M2M Network SCL (NSCL) that can be queried by M2M Network applications (NAs) via an open interface.
  • M2M service capabilities Layer (SCL) provides a horizontal service layer for M2M applications abstracting the complexity of hetergogeneous devices and enhancing M2M interoperability .
  • M2M application a domain-specific software application that interracts with the M2M machines by quering the service layer through a set of open interfaces

OM2M provides the following service capabilities that communicate through the Routing Function (RF) module within the SCL. SCs can be deployed on an M2M network, gateway or device:

  • Application enablement(xAE) provides a single point of contact to M2M applications using XML files and HTTP protocol but can be mapped easily to other protocol technologies such as CoAP.
  • Generic communication(xGC) provides a single point of contact for communication between different SCLs using XML files and HTTP protocol but can also bind to other protocols. It makes use of existing network connectivity and manages all security aspects for secure session establishment and teardown.
  • Reachability, addressing, and repository(xRAR) provides persistence capability to store M2M resource states within the SCL. It enables to Create, Retrieve, Update and Delete (CRUD) M2M resources, to store information related to M2M applications and SCls registrations, and to manage data required for publish/subscribe communication..
  • Communication selection(xCS) provides network selection algorithms and mechanisms based on policies for M2M machine with multiple interfaces and bearer such as Ethernet, Wifi, GPRS or 3G. It also proposes alternative Network after a communication failure.
  • Remote entity management(xREM) interworks with existing REM standards such as the OMA-DM by performing mapping/converting operations. It provides functions pertaining to device/gateway life cycle management, such as software and firmware upgrade and provides mechanisms for fault and performance management.
  • SECurity(xSEC) implements bootstrapping, authentication, authorization, and key management functions to establish secure communication between M2M applications and SCLs based on the TLS-PSK protocol.
  • Interworking proxy(xIP) allows non-ETSI-compliant devices such as Zigbee, Phidgets, and many other technologies to interwork with the ETSI M2M standard by performing mapping/converting operations. In the smart building domain, a specific application payload is proposed based on the OBIX information model to enhance interoperability.

(Where x refers to: "N" for network, "G" for gateway, and "D" for device)

OM2M offers the mIa, dIa, and mId reference points:

  • mIa reference point: allows a NA to communicate remotely with the NSCL
  • dIa reference point: allows a DA to communicate with the DSCL or the GSCL where it is residing. It allows also a GA to communicate with the GSCL where it is residing
  • mId reference point: allows DSCL and GSCL to communicate with the NSCL on the service level and vice versa. the mId uses core network connectivity functions as an underlying transport.

As the OM2M architecture follows a RESTful style with a hierarchical namespace, an AJAX web interface based is provided to enable exploring SCLs resource trees, monitoring sensors and controlling actuators. The OM2M web interface offers the following functionalities:

  • Explore SCL resource tree of an M2M machine and display sub-resources attributes
  • Discover authenticated SCLs and navigate from one SCL to another in a seamless way using retargeting mechanism
  • Retrieve sensor events e.g. temperature, luminosity, power, etc. using two ways: read cached copies from the resources tree, or make a direct request to the sensor through the interworking proxy
  • Execute action on actuators e.g. to switch ON/OFF a lamp, control a servo motor, etc. and monitor their new states using retargeting mechanism

A screenshot of the OM2M web interface is presented on the following figure:

ETSI M2M standardized the M2M SCL resources tree. Each SCL resource is referenced with a global identifier and has a type, a set of attributes, a set of methods that operate on it, and some links to other resources. Most important SCL resources are listed below:

  • sclBase resource describes the hosting SCL, and is the root for all other resources within the hosting SCL.
  • scl resource stores information related to M2M SCLs residing on other M2M machines after successful mutual authentication. It enables SCLs interractions using retargeting operations
  • application resource stores information about the application after a successful registration on the hosting SCL.
  • container resource acts as a mediator for data buffering to enable data exchange between applications and SCLs
  • accessRight resource manages permissions and permissions holders to limit and protect the access to the resource tree structure.
  • group resource enhances resources tree operations and simplifying the interactions on the API interfaces by adding the grouping feature. It enables an issuer to send one request to a set of receivers instead of sending requests one by one.
  • subscription resource stores information related to subscriptions for some resources. It allow subscribers to receive asynchronous notification when an event happens such as the reception of new sensor event or the creation, update, or delete of a resource.
  • collection resource groups commun resources togethers. It is used at different places such as scls, applications, or containers.
  • announced resource contains a partial representation of a resource in a remote SCL to simplify discovery request on distributed SCLs.
  • discovery resource acts as a search engine for resources. It enables to retrieve the set of resources URIs matching a specific filter criteria and constraints.

ETSI M2M references

For more details on the ETSI M2M standard you can see:
  • M2M Communications: A Systems Approach. Edited by David Boswarthick, Omar Elloumi and Olivier Hersent
  • ETSI TS 102 689, Machine-to-Machine communications (M2M); M2M service requirements
  • ETSI TS 102 690, Machine-to-Machine communications (M2M); Functional architecture
  • ETSI TS 102 921, Machine-to-Machine communications (M2M); mIa, dIa and mId interfaces

Why Eclipse?

Being an eclipse project, OM2M aims to boost the development of M2M applications through the Eclipse community. The OM2M service architecture can be a key peice to bring together M2M projects within the Eclipse M2M Industry Working Group. OM2M already has a strong relationship with other Eclipse projects such as Koneki which is used for remote entity management based on the OMA-DM protocol. The Equinox project will be also adopted for dynamic deployment and dependencies management of M2M services and applications. OM2M team will work closely with other Eclipse M2M projects to come up with one global technology-agnostic M2M platform that makes easy the development of new service capabilities, connecting heterogeneous devices, and deployment of vertical applications.

Initial Contribution

The OM2M project will be provided with an initial contribution from LAAS-CNRS laboratory:

  • A java implementation of an M2M network, M2M gateway and M2M device in line with the ETSI M2M specifications
  • A HTTP mapping module for vertical and horizontal reference points for application enablement and generic communication
  • A Phidget and Zigbee interworking proxies to experiment non-ETSI compliant devices
  • An OMA-DM remote entity management service using the Funambol server and the Koneki Simulator
  • A web interface based on AJAX for SCLs resource trees exploration, and devices monitoring and controlling.

Legal Issues

The following parts of the code are available under different licenses

  • Apache HTTP Server library: Apache 2.0
  • Apache HTTP Client library: Apache 2.0
  • JAXB library: CDDL v1.1 and GPL v2
  • DB4O library: dOCL and GPL v3
  • jQuery library: MIT

Optional libraries:

  • Security IAIK-JCE library: EUPL and GPL v2
  • RXTX library: LGPL v 2.1 + Linking Over Controlled Interface
  • Phidgets library: LGPL v3
  • Obix JAVA Toolkit: Free


The following individuals are proposed as initial committers to the project:

Mahdi Ben Alaya, LAAS-CNRS
OM2M project co-lead
Thierry Monteil, LAAS-CNRS
OM2M project co-lead
Khalil Drira, LAAS-CNRS
OM2M project commiter
Christophe Chassot, LAAS-CNRS
OM2M project commiter

We welcome additional committers and contributions.


The following Architecture Council members will mentor this project:

  • Denis Roy
  • Benjamin Cabé

Interested Parties

The following individuals, organisations, companies and projects have expressed interest in this project:

  • Luigi Alfredo Grieco, Department of Electrical and Information engineering, Politecnico di Bari, Italy
  • Miriam Capretz, Software Evolution Lab/ECE, Western University, Canada
  • Amine Dhraief, HANA Lab, University of Manouba, Tunisia
  • Juhani Latvakoski, VTT Technical Research Centre of Finland
  • Georges Da Costa, IRIT, France
  • Giuseppe Monteleone, Italtel, Italy
  • Gowri Shankar, Prodapt Solutions, India
  • Werner Keil, Eclipse UOMo Project lead
  • Mathieu Rousselle
  • Mario Kusek, Faculty of Electrical Engineering and Computing, University of Zagreb

Project Scheduling

Changes to this Document

Date Change
6-January-2014 Added interested parties
13-November-2013 Added interested parties
30-October-2013 Document created

Back to the top