The Internet of Things and Machine to Machine (M2M) communication are not only buzz words in the computing industry today but also in the telecoms sector. In telecoms there is a framework referred to as OneM2M that I’ve come across several times before. However 99% of what I found on the Internet did not bring me any closer to understanding the principles of the framework and how it ties in with cellular networks and NB-IoT. After digging a bit deeper I finally found some resources that helped me to understand what OneM2M actually does and how.
The following post is part 1 of a ‘telescope’ view of the M2M framework that doesn’t necessarily offer a complete picture of all aspects the framework covers. If you think I missed a major topic please let me know!
Any Sensor To Any Device – Abstraction and Standardized Protocol
The basic idea of oneM2M is to offer a standardized way to exchange information and commands between any IoT device and any application. Without a standardized way of doing this a company producing, for example a parking sensor, would use NB-IoT as cellular technology and implement an API to interact with their devices. Another vendor of parking sensors would implement a different API and use LTE as cellular technology. And a third vendor of parking sensors would use Lora as cellular technology and implement yet another way of communicating with their device. This is nice and well if you buy the hardware and software from one vendor and only want to talk to one brand of parking sensors. But what if you want to build an application that wants to get information from different parking sensors to check for free parking spaces in different parking garages that use different sensors and, in addition, you want to query another type of sensor built and operated by yet other companies to see what the traffic situation is around the parking garages to take this into account as well? In this case the software would have to implement many different APIs, deal with different access networks and incompatible data aggregation servers. It’s all a big mess and not scalable.
This is where oneM2M comes in as a generic communication framework. It offers a standardized communication interface on two sides: On the one hand oneM2M describes a standardized way for IoT devices to exchange information with a centralized server. Communication can be bi-directional, i.e. IoT devices can send data and receive data to and from a centralized server. On the other hand oneM2M describes a standardized way how applications can exchange data with IoT device via a centralized server.
It is important to realize that applications do not communicate directly with IoT devices but only via a centralized server. This way the server shields the application from knowing how the IoT device is connected to the network. And from the IoT device’s point of view it shields it from too many requests from applications and responsibilities such as knowing who is allowed to access them, from where and how often. This is important for IoT devices that only have a limited energy resource. Data can be cached on that central sever and hence the device only needs to push its data once when it changes and applications can then access the cached value as often as needed without further interaction with the restricted IoT device.
And one more interface oneM2M standardizes is communication between different centralized oneM2M servers. This way an application can exchange data with IoT devices that communicate with different centralized servers without needing to be aware of this.
Standardized Discovery of Devices and Capabilities
Another important aspect of communicating with IoT devices is to actually find them and to discover their capabilities. In the IP world this would typically be done by giving the device a DNS entry and then resolving its name into an IP address. That works fine as long as the device is connected to an IP network and can be reached from the outside. This can’t be taken for granted for a number of reasons ranging from NATs to devices being shielded from direct access on purpose, e.g. for security reasons. In the oneM2M world, devices are identified via a URI, i.e. similar to a URL that is used by a web browser to access a certain page on a web server. OneM2M uses the same concept but replaces the web server with the centralized server and the web page with the id of the device. Let’s make a practical example. An application wants to read the free/occupied information of parking sensors. To do so it would need to know the ID of the parking sensors it wants to query and to which centralized server they are connected to. The application would generate a URI out of these two pieces of information and then send a query to the centralized server. The centralized server can then either forward the request to the device or return an answer based on cached information. In the parking sensor example, cached data would make sense. Here the parking sensor informs the server immediately whenever the parking slot becomes occupied or empty. In between there is no need to query the sensor and might not even be possible as the IoT parking sensor does not listen for incoming data for most of the time to conserve energy.
Sending and receiving data to/from devices is nice but meaningless if one doesn’t know how data is organized and what it represents. As a consequence, oneM2M structures data transfers and capability discovery. Let’s make a practical example: When the afore mentioned parking sensor connects to the centralized server it makes the server aware in a standardized way what kind of information it makes available. Let’s say the parking sensor can monitor two adjacent parking spots. When connecting to the network it tells the server its ID and that it will send two pieces of data. In the programming world these two pieces of data are referred to as variables. In other words, the device tells the server that it wants to make two variables available, their names being ‘parking-spot-1’ and ‘parking-spot -2’. Applications can later-on ask the centralized server what the names of those variables are and then ask the server to send them the value currently stored in ‘parking-spot-1’ and/or ‘parking-spot-2’.
Variables can also be written to by an application which would not make sense in the parking sensor case. But imagine an IoT device that measures the temperature and makes it available on request. It could have a variable for the temperature and one variable of how often it should measure and report a value. While the application would read both variables it can also write into the ‘how often’ variable to change the reporting interval. The server would then forward the write request to the IoT device. In other words, writing to a variable is like sending a command, e.g. change the reporting interval, switch on an LED, etc.
Summary
This is all for today. In the next part I’ll continue with things like the transport protocol (HTTPS/CoAP) used by oneM2M, gateways for restricted devices, push vs. pull and oneM2Ms relation with NB-IoT, non-IP based data transfers, how oneM2M can use the Service Capability Exposure Function (SCEF) of 3GPP networks and about security and access control is implemented.