The futuristic vision for smart cities is that millions of IoT devices will be seamlessly interconnected through city data platforms and communications service providers’ (CSPs’) networks to manage traffic, parking, waste collection, pollution, energy consumption, weather forecasting and much more. But IoT devices are far from homogenous. Many different vendors provide them, and they use different protocols to transmit data, which has made interconnecting them a complex and time-consuming integration effort – until now.TM Forum’s new Internet of Things (IoT) Device Management API Suite aims to simplify end-to-end IoT device management. The suite, developed in collaboration with Axiata, Vodafone and
the IoT Forum, builds upon TM Forum’s
Open APIs. The idea is to speed up prototyping and commercial IoT deployments so that CSPs can expand quickly into vertical markets.
The IoT Device Management Component Suite is available now for developers to use, and the team is working on a companion IoT Service Management Component Suite to be released later. Importantly, the device suite includes a new IoT Data Access Endpoint API developed by Pierre Gauthier, TM Forum’s Chief API and Ecosystem Architect, to encapsulate different types of protocols (for example,
MQTT,
NGSI and
CoAP), allowing devices to be easily integrated. I caught up with Pierre recently to learn more.
What does the IoT Device Management API Component Suite do and why is it important?
These APIs are basically doing what the title says: managing IoT devices and IoT agents, which are collections or federations of IoT devices. What’s important is that the suite provides a normalized interface to configure and manage the IoT device – get alarms, configure and monitor IoT devices, and provide secure access to them. The same set of Open APIs can be deployed in the silicon of the IoT device or used by an agent.
This is one of the building blocks to support our
smart city initiative. From a smart city point of view, one of the most fundamental issues is setting up the management of the IoT devices. Let me give you an example: traffic light data. It seems simple, but all the vendors in the world are providing traffic light data in different formats. It’s a nightmare. So, we worked with FiWare to create an open source initiative and created a
Smart City Data Model that is based on our
Information Framework. This is used by the IoT Device Management Component Suite and will be used by the IoT Service Management Component Suite.
Do these suites use existing Open APIs, or has the team created new ones?
Both. We try to reuse existing APIs as much as possible. For some of the use cases like alarm management, we can reuse our
Alarm Management API and the same goes for our Resource Function Activation & Configuration API, which we can use to configure the IoT device. But we also needed to create an IoT Data Access Endpoint API.
Why is the Data Access Endpoint API necessary?
It’s important because we completely encapsulate the protocols used by a specific IoT device or IoT agent. For example, some IoT devices may report pollution data using MQTT, while others might support the same data using NGSI. There are so many protocols out there. The Data Access Endpoint API lets the user not only provide multiprotocol support for data access, but also for data modification or data event streaming.
We’ve created another new API, the Event API, to support event streaming. This could be used for machine learning to enable autonomous network management and autonomous IoT management. That’s an important use case.
The IoT Forum has been helping with this work. What is their role?
We validated the component suite with the IoT Forum. They’re a well-recognized organization in the context of IoT. They provide a lab and they have a product called the universal device gateway, UDG. At the beginning of the activity, we knew that we wanted to do the proof of concept of the IoT Device Management suite in their lab, working on top of the UDG capabilities, which were already multiprotocol but not standardized or normalized.
We are working together with the IoT Forum to submit the component suite to the
ITU-T [International Telecommunication Union Telecommunication Sector], and we expect it to become an ITU-T recommendation. That’s the goal.
What is the purpose of the companion IoT Service Management API Component Suite, which the team is working on next?
CSPs want to be able to create services around all the IoT device data that’s collected, and for that they need the service management suite. For example, maybe they want to create a garbage collection routing service. Based on all the data collected, they could use machine learning to optimize the route for garbage collection [for a city or a waste management company].
The IoT Service Management API Component Suite will look a lot like our Network as a Service API Component Suite. We’re reusing those APIs, but, again, the services will need to provide IoT device data, so they will use our API Data Access Endpoint API for multiprotocol support.
Is this applicable in the 5G world?
CSPs that have already adopted our APIs will be able to integrate these management capabilities into their existing set of APIs, so they could use them to deliver a 5G slicing service, where the IoT device runs on top of a 5G slice. That’s one of the use cases. The API will allow you to connect the IoT device to a particular 5G slice, and the nice thing is that the NaaS Component Suite could be used to set up the 5G slices. It’s an ecosystem of APIs.
Are there plans to demonstrate these capabilities in TM Forum Catalyst proofs of concept?
Yes, absolutely. Catalysts for
Digital Transformation World in Copenhagen are being discussed as we speak, and the APIs are being implemented in the IoT Forum lab in Geneva. It’s also possible we will work with the
Bristol 5G lab [the Smart Internet Lab at the University of Bristol] to demonstrate interconnectivity.
If you’re interested in learning more about the IoT Device and Service Management API Component Suites or would like to participate in a Catalyst project, please contact Joann O’Brien.