In early 2021, oneM2M spoke to Poornima Shandilya of the Centre for Development of Telematics (C-DOT) about her group’s early work to develop an IoT platform in line with the oneM2M standard. During recent oneM2M’s 57th Technical Plenary, held in Seoul, Korea, Poornima spoke about post-2021 developments, use case project experiences and market demand for oneM2M solutions.
About C-DOT:
C-DOT is a Research & Development wing of the Department of Telecommunication of the Government of India.
C-DoT has been contributing to India’s telecom technology development by developing innovative technologies and transferring it to partners through a technology transfer model that aims for bulk production of high-quality telecom products and solutions. It continues to develop the latest technology products in areas like optical, switching, wireless, security, cryptography, M2M/IoT, AI/ML, 5G etc. Recently, at IMC 2022, our honorable prime minister ‘Shri Narendra Modi’ launched 5G Non-Standalone (NSA) core indigenously designed and developed by C-DOT.
In the IoT/M2M arena, C-DOT’s vision is to empower the Indian nation by proliferating technologies which can help in sustainable development. C-DOT has continuously strived to understand the challenges in this segment by partnering with several organizations. In addition to developing its own products, C-DOT aims to be a torch bearer by enabling the industry for standards-based deployments.
Q: Would you remind our readers about your role in C-DOT and within oneM2M?
PS: I got involved with oneM2M in 2015 and began working towards a prototype a middleware platform for IoT systems. This was in parallel with C-DOT’s decision to contribute to oneM2M’s standardization activities.
At C-DOT, I am a technical lead in the M2M Communication project and involved in the design and development of C-DOT’s Common Service Platform (CCSP), which is based on oneM2M standards. We began our prototyping work in 2016 and developed our first platform in 2017. Gradually we enhanced it with more features and deployed it within our campus with smart living, vehicle monitoring and fire protection system application.
In 2022, we launched Center Of Innovation (COI) under which we opened C-DOT Common Service Platform (CCSP) interfaces to IoT/M2M industry partners for testing and integration.
In terms of standardization activities, I represent C-DOT in oneM2M meetings and at oneM2M interoperability test events. I have made several contributions for new features in oneM2M’s standards roadmap. Since Feb 2020, I have held the role of oneM2M System Design and Security (SDS) working group Vice-Chair role. I also look after the rapporteur activities for field device configuration specifications and test purposes and test cases development for oneM2M release 4 features.
Q: Would you expand on your comments at TP57, when you spoke about an “80/20” development approach for CCSP?
PS: oneM2M specifies several common service functions (CSFs) for use in developing and operating IoT systems. Participants in oneM2M’s standardization activities derived these CSFs after studying the common technical requirements arising across several IoT verticals. Beginning with Release 2, there were 12 CSFs. As oneM2M continued to address new requirements, new CSFs were added so that the total number rose to 14 CSFs in Release 3 and17 in Release 4.
When C-DOT started with the development of CCSP, we aimed at four essential CSFs which were required in our use cases. Those were for streetlight monitoring, smart living applications and fire control and monitoring. What we needed at that point was the ability to assign a unique identifier to each application entity (AE). In oneM2M terms, an AE can represent a connected sensor, a visualization dashboard or a data-analytics application, among other possibilities. With its unique identifier, a dashboard application can discover one or more devices that are associated with it. In operational terms, as soon as a streetlight comes onboard, for example, a dashboard application should be able to display it.
We also needed the ability to store data generated by various sensors, and the ability to inform dashboard applications about new readings. The dashboard application could also actuate a device, as in the case of turning off the HVAC plant when temperature readings go below a threshold.
For our initial requirements the four CSFs we required were Registration, Discovery, Subscription and Notification and, Data management and Repository. That is what I meant by 80/20. For our use cases, we could do most of the work using a sub-set of the CSFs that oneM2M offers.
As requirements become more complex, we can introduce other CSFs. The entire process is relatively straightforward because each CSF fits into oneM2M’s horizontal architecture. To give you a concrete example, we had a use case to control a group of streetlights. This requires less work for the system operator compared to controlling each streetlight individually. This can be helpful when the operator wants to adjust lighting on different stretches of a road or in different districts. To address this requirement, we added the Group Management CSF which is a reusable capability to manage groups of devices, applications or other IoT resources.
Q: Are there other CSFs you added over time?
PS: When it comes to IoT, security becomes the first question that comes up considering the number of devices that will grow in future, especially as many of these will be constrained devices. The question raises many concerns. For example, how can designers ensure that communications from IoT devices are secure? How to ensure that only identified, authenticated, and authorized devices or applications can communicate with the IoT platform? How to ensure that credentials are not impersonated by some other device application?
With all those concerns in mind, we implemented the Security CSF and provided support for symmetric key and certificate-based security for various types of certificates. It enabled secure communication between the applications residing on IoT devices to our CCSP platform. Using our configuration modules and security CSF, we ensured that only known entities are given credentials.
For authorization, we implemented the Access Control Policies mechanism specified in oneM2M. That allows the system to control resource access between applications belonging to one application service provider or between multiple providers.
Q: Are you doing anything special for constrained devices?
PS: Yes, we are. In general terms, constrained devices might have limited processing capacity and local data storage capacity. These devices might also require careful management if they are battery-powered so that they are active for as little time as possible to extend their service life.
For constrained devices, we developed Middle Node (MN) provisioning. This allows us to configure a middle node dynamically for all the incoming devices. Constrained devices that do not have the processing capacity to support security functions can talk to this MN node which is treated as a private network environment. The middle node then can talk securely to the infrastructure node which is a oneM2M term for the IoT platform server.
C-DOT has developed and offered 4G and 5G core network capabilities to our home-grown telecom operator BSNL to support NB-IoT functionality. oneM2M is the only standards which provides seamless interworking with 3GPP standards. To implement Non-IP Data Delivery (NIDD) functionality for NB-IoT devices, we implemented oneM2M 3GPP Interworking.
Q: What are you implementing in relation to IoT data?
PS: We felt that for industrial IoT there will be a need for features like time series data, so we implemented oneM2M’s time series functionality which is a feature in the Data Management and Repository CSF. This sends a notification if a given number of data points are missed in a given time interval.
We are also looking ahead in anticipation of data interoperability requirements. In the initial release, oneM2M’s <contentInstance> (CI) resource holds data sent by an application entity. There is no constraint on how the data is represented as there is no specific definition or data model. This is problematic when we want to align data coming from applications or sensors supplied by different vendors. oneM2M is already actively working on defining models or Smart Device Templates (SDTs) for different industry verticals. These data models are represented as <flexContainer> resources in oneM2M and they specify a well-defined structure that may contain a rather complex structure of data points. Seeing the need, we implemented the <flexContainer> feature of the Data Management & Repository CSF. We are in the process of testing the SDT models added as part of oneM2M Release 4 to support data interoperability.
Q: How is C-DOT making the CCSP available to organizations in India?
PS: C-DOT is making CCSP available to organizations under its Center of Innovation (COI) initiative which encourages collaboration between industry partners in the IoT/M2M arena. The COI will assist in development, integration and testing of innovative Smart Solutions based on oneM2M standards. Here is a link for more details on COI under the COI tab and here is where industry partners can register their interest in collaborating with C-DOT.
Once registered, a dedicated screening committee reviews each use case application. Based on the potential, novelty, readiness and application of use case an industry partner is shortlisted. For selected parties we provision service agreements in our system and create user logins. These parties can then log in to our portal. They can download configurations for their devices and make use of CCSP services. Our website contains various useful guides, tutorials, and videos to assist partners.
With our initiative, it is heartening to see that parties are readily able to understand oneM2M messages, interfaces, security practices and integrate with CCSP Platform.
Q: What have been your successes to date?
PS: Over 40 industry partners have registered with the COI across various industry verticals. As you can see from the illustration, there are many interesting use cases in areas such as street lighting, smart homes, surveillance, smart meters, asset tracking and fire safety, among others.
The areas showing greatest interest are surveillance, transport, smart home, and street lighting use cases. There are several integration projects with CCSP going on with startups and larger industry players. There is a fire system for safety and health monitoring and a smart street lighting system using individual and group controllers. Another firm is building digital twins. There is an innovative ‘digital ocean’ solution digital ocean that combines IoUT (Internet of Underwater Things) and AI to support ocean bed data mining, real time life safety and profitable fishing.
At India Mobile Congress (IMC) 2022, we demonstrated a fire detection and fault reporting application. When an incident occurs, the system informs multiple fire system applications to trigger different actions. These involve switching off HVAC units to prevent the spread of fire, automatic opening of access-control doors, messaging apps to inform people in the building about fire and building navigation apps to guide them along fire free pathways.
The streetlights solution from our industry partner brings intelligence to street Lights and empowers users to have the power to control & manage illumination levels. They have integrated with the COI’s CCSP so that their solution is oneM2M compliant. The next phase of their vision is to make use of oneM2M’s standard data models, as defined in Technical Specification TS-0023.
I should also mention another solution that allows users to build applications for the Enterprise Metaverse. These take the form of digital twins that are powered by real-time data from sensors, equipment, processes, and interactions. Our industry partner wants to setup a sandbox for creating Digital Twins empowered with CCSP and oneM2M. This will allow users to overlay 3D heatmaps to show information from IoT devices in a much more visual way than just charts and graphs.
There are many other innovative solutions which are still in the process of integration with CCSP.
Q: What lessons has C-DOT learned from these early deployments??
PS: Every time we integrate with parties, we find a new set of requirements. Thanks to our deep understanding of oneM2M specifications, we try to find answers for those problems within standards. We do find answers to those problems in the standards, but implementation of such requirements can be challenging. Let me explain with a couple of examples.
The first one is the streetlights solution. Two ways to lower the cost of each device involve placing limitations on hardware and bandwidth usage. If a designer has to incorporate all software within a few KBs and limit data transmission to 200 bytes, how do we achieve that? Since these devices have already been deployed for many years, they already have software installed for device-to-cloud communications. Although it is not much, the addition of software for oneM2M requires additional space.
For such situations, we already identified that there would be a need of an application to manage a hierarchical resource tree and other data so that such devices require minimum changes in configuration and minimum bandwidth to transmit data.
For my second example, another challenge we faced stems from the use of proprietary data structures for sending data. If we have multiple vendors each supplying data in the <contentInstance> resource using their own formats, then it becomes impossible for northbound applications to consume that data unless these proprietary data structures are shared with them. That is where standardized data models become useful. oneM2M’s TS-0023 specifications contain the fruits of a lot of efforts to define data models for several different industry verticals. So now in collaboration with these parties we are trying to focus on re-use of the data models. If we do not have a data model already defined, we can work on adding it to the library.
Q: What can we expect to see from C-DOT’s CCSP in the future?
PS: We intend to put more focus on harmonizing data models for IoT verticals. Through our engagement with industry, we not only target oneM2M compliant applications on northbound and southbound interfaces, but we also aim to employ standardized data models to ensure proliferation of standard based deployments.
With our oneM2M standard based CCSP Platform, we expect to create unique solutions while also offering more sustainable solutions for many existing problems. CCSP can be offered in multiple variants for industry, using public cloud and on-premises approaches. Due to its versatility, we expect to see an increased need for CSSP in the market. Thanks to the COI’s efforts, we also expect to have many more integrations and deployments in different IoT verticals.
