A Telescope View on How OneM2M Works – Part 2

This is part 2 of my telescope view on how OneM2M works and deals with a number of additional topics. If you haven’t read part 1 I strongly recommend you do this first before continuing here.

HTTPS and CoAP

O.k., so devices communicate with a centralized oneM2M server and applications also communicate with the centralized server. But how do they do this? In the past, I’m sure obscure protocols would have been used but in this case the oneM2M forum chose to use HTTP(S) as the protocol of choice to send and request information between devices and a server on the one hand and applications and the server on the other. In other words, it works very similar to a web browser requesting data (HTTP GET) or to sending data (HTTP GET, POST) to a web server. It’s important to realize that HTTP(S) is used both by the IoT device and the application. As a second, more resource efficient alternative, CoAP (Constrained Application Protocol) can be used by either side. It’s based on UDP and optionally includes DTLS encryption. In addition, data transfer over CoAP can be transparently mapped to HTTP requests. In other words, CoAP is a condensed HTTP protocol for constrained devices. For details have a look at this Wikipedia article.

Gateways for Restricted Devices

Another thing shown in the videos below is that oneM2M gateways can be used to communicate with sensors that have not enough memory, processing capacity or very limited connectivity. To the outside the oneM2M gateway communicates using oneM2M request/responses over HTTP(S) and CoAP while to the restricted sensors, proprietary and even non-IP protocols can be used.

Push vs. Pull

Especially for bandwidth and power restricted devices it is often important to keep data exchanges to a minimum. A oneM2M device can thus be instructed to push its data when it feels it is necessary. A pull mode is obviously also available for less restricted devices so applications can request the sensors status or send a command to an actuator in real time.

NB-IoT, Gateways, NIDD and the SCEF

The big question I had when I started to look into oneM2M documents was what oneM2M has to do with NB-IoT. The answer is: (Almost) nothing! This is because oneM2M communication is completely independent of the transport networks. All oneM2M communication is based on IP, TCP/UDP, HTTP(S)/CoAP and the oneM2M syntax and structure on top. It doesn’t really matter if a oneM2M capable IoT device is connected over Wifi, LTE or NB-IoT as long as the network offers an IP bearer.

I said ‘almost’ nothing because oneM2M is independent from the transport technology because it is based on IP. NB-IoT networks, however also offer non-IP based data transfers (NIDD) for very power and bandwidth constrained devices (see here and here). Such devices can’t communicate directly with a oneM2M Server so there has to be a oneM2M gateway outside the 3GPP NB-IoT network that connects to the NB-IoT devices and translates requests and commands to and from the oneM2M Server. The boxes 3GPP networks can put in place to allow oneM2M gateways (and other devices) to communicate with non-IP NB-IoT devices is the Service Capability Exposure Function (SCEF). In addition to forwarding non-IP data to and from NB-IoT devices it also offers and interface to the oneM2M system for device events. For example, the SCEF can inform the oneM2M system when a device has woken up and has become reachable again for a certain time, it can report its location (e.g. the ID of the cell that was last used for communication) and it can be asked to store and forward data to NB-IoT devices that only wake up occasionally. Such functionality is not part of the oneM2M core specification. Instead, oneM2M is in the process of standardizing the interface to the SCEF (have a look at oneM2M TR-0024 for details).

Security and Access Control

One more topic that I want to point out at the end of this introduction is that the oneM2M system also deals with security and access control. As devices only communicate with a single server, only one application protocol has to be secured. In addition, authentication and encryption is used on the HTTP/CoAP layer using public key cryptography. This is done very similar to a web browser requesting a page via HTTPS. I assume, that in the case of oneM2M, certificates are/can be used not only on the server side but also on the client for mutual authentication. In addition, oneM2M servers are responsible for access control to devices and individual services (variables, see above). This way it can be ensured that oneM2M IoT devices can only be accessed by their owners.

Summary

Bringing all of these things together is by far not an easy undertaking. However, the alternative of not having a standardized protocol and servers between devices and applications would mean and endless flood of proprietary ways to communication with IoT devices and a huge overhead on the application side to get data from different devices.

So much for my telescope view. [UPDATE 15.6.2018]: The story continues here with a look at how the protocol looks like and how it is used in practice.

For more details have a look at the following sources: