Streamline Messages and Take the Load off IoT Sensors

A recent industry research report by Juniper Research predicts a near doubling of the internet of things (IoT) market, from $31 billion in 2022 to more than $61 billion by 2026. Adoption expectations are high in sectors such as agriculture, smart cities, and manufacturing. Two factors that underpin these opportunities are low-cost connectivity and low-cost devices. This combination favors the market for constrained devices. This is because limits on memory and processor capabilities keep costs down and encourage mass-market scale.

Efficient data transfer is another characteristic of the low-cost calculus. In the IoT domain, this begins with the use of efficient data transmission protocols, such as CoAP and MQTT. Beyond these protocols, designers are looking at ways to optimize data payloads by only sending essential data, for example.

Other strategies involve intelligent ways of transmitting data. This can mean avoiding data communications when data values have not changed from one sample to the next. Another approach is to delay transmissions. This applies to non-time-critical communications where sensor readings can be accumulated and sent in an aggregated fashion or scheduled at times when communications minimize the risk of congesting networks.

Standardization and the oneM2M Framework

Individual vendors can implement one or more of these techniques in their connected device and sensor offerings. In many ways, however, a standardized, industry-wide approach would be better. Standardization would allow solution providers to mix and match IoT solution components. By fostering common operational practices, standardization would encourage a common body of knowledge and benefit the developer community.

The oneM2M initiative provides a global and open standard for IoT systems. It contains the building blocks to realize vendor interoperability and developer community goals. oneM2M technical specifications define a three-layer architecture. This consists of a lower layer for device and communications technologies. An upper layer encompasses IoT applications, including data exchange and visualization dashboards. In between the two resides a common services layer. It contains a suite of frequently used common service functions (CSFs). Think of these as the tools that developers use to build, deploy and support IoT systems.

Common Service Functions

Over time, the number of common service functions defined in the oneM2M common services layer has expanded to seventeen. Thanks to oneM2M’s standardization procedures and architectural framework, there is a high degree of consistency and cohesion among these CSFs. Consider the ‘Device Management’ common service function as an example. It handles software and firmware update operations on devices across a variety of use-case and deployment environments.

Another example is the ‘Registration’ common service function whose purpose is to establish authorization and authentication relationships between an IoT platform and connected device or application endpoints. A ‘Communications Management’ common service function handles the efficient delivery and scheduling of messages supporting mechanisms such as buffering of messages based on device availability. 

IoT Message Streamlining

One solution to the challenge of optimizing communications with constrained devices uses two common services from the oneM2M portfolio. These are ‘Communications Management’ and ‘Data Management and Repository’. The objective is to streamline the size of messages that IoT devices need to generate and send without losing information. The service layer can apply a message profile to enrich each message it receives from an IoT device by adding supplementary metadata. This can reduce overhead on devices and networks without sacrificing information that is useful to the apps that consume this data. 

In action, the process functions as follows. Take the case of a simple IoT system consisting of a constrained IoT sensor device, an IoT platform comprising a service layer and a dashboard application to display sensor readings. To begin with, the IoT platform is configured with a message profile for the IoT sensor device. This message profile comprises metadata which the IoT platform is to add to readings that it receives from the IoT sensor device. The metadata includes a unique identifier and a location of the sensor device. The metadata also includes a descriptive label for the meaning of the data. In case of a heat sensor, an example label is ‘temperature’.

When the sensor sends a reading, this need only be a numerical value, such as 32. Upon receipt of the reading, common service functions within the IoT platform would then apply a message profile. This would add useful metadata to the reading before dispatching it to the dashboard application. In addition to the numerical value, 32, the enhanced message would include the unique identifier and location of the sensor device. It would also include the ‘temperature’ label to convey meaning about the data. Depending on use-case requirements, more complex message profiles are possible.

At scale, this simple arrangement, using two common service functions, demonstrates the potential to design systems that manage for constrained device capabilities and communications costs.