Standardised Common Service Layer in IoT Applications

The common service functions are:

Registration
Discovery
Security
Group Management
Data Management & Repository
Subscription & Notification
Device Management
Application & Service Management
Communication Management and
Delivery Handling
Network Service Exposure
Location
Service Charging & Accounting

These functions are exposed to the applications via developer friendly APIs. The Common Service Functions (CSFs) are not confined only to the core infrastructure. Rather, it is integrated into devices/gateways/servers and allows distributed intelligence. It hides the complexity of Network usage from applications as the standard remains agnostic to the communication protocol. Due to this functionality, divergent applications can seamlessly be integrated by using pluggable adapters which convert the data model of the particular Network Type to the oneM2M Data Model. It controls when communication happens and notifies applications about events so that the applications are not required to continuously poll for the arrival of the data. It stores and shares data based on the policies governing the data storage and grant of access control privileges.

All the entities in this framework are represented as resources and all the data generated by these sensors and associated applications are the content instances; Example, a temperature sensor would be represented by a resource and the readings of the sensor would be the content instances. The Registration CSF ensures that all applications register themselves to the platform before they are allowed to communicate. So, whenever you register yourself you get a unique application entity ID, you get a set of keys, so the set of keys will enable you to encrypt the data that you are sending and communicating. Now encryption can be a hop by hop encryption, you can have an end to end encryption, thereby securing your data. Security as you see, security is now engrained into this common service layer. So, while you are following the standard you have to have security implemented into your application. The Discovery CSF discovers all those resources which are being used in this ecosystem.

One major function – subscription and notification – this is a game changer because now your business application doesn’t have to poll each device in order to fetch the data. It only must subscribe to the element it is interested in and it will be notified whenever a data comes. This helps immensely in smart metering cases and in connected cars as well.

It is a service layer which is a software layer. It sits between applications & underlying communication and networking hardware and relies primarily on IP protocol stack. But that doesn’t mean that your sensors must also be IP because the sensors mostly will be interfaced with some controller unit, if it is your car. That controller unit in turn can make an IP connectivity to the backend and that happens even today.

From being a proprietary communication from one’s car to a backend business application and a server, what is recommended is that it should communicate in a standard compliant way to a common service layer and an infrastructure which is provided by a service provider.

While we are talking about the oneM2M standards, we shall also be clear about the way the same can be deployed in the field and the different functional roles.

There will be users like you and me, there will be IoT application providers, ITS being one of the applications. In smart parking, somebody comes with an application, so it will be an application provider. And there will be a platform provider who will be called a M2M service provider; he will come as a common service layer provider. So, he will set in his infrastructure in order to provide this common service functions. Then there will be a network service provider which already exists in the form of the TSPs and ISPs.

Now these are only functional roles, anybody can take up any role at any point in time. So, what it gives you, it combats fragmentation, so more partnering choices. Just try to think of it, it creates an immense opportunity because so far it is being siloed and verticalized any vertical that you pick in today actually has to consider the thing in entirety, tomorrow the start-ups can create innovative applications and only think about applications. They will create applications in a jiffy, so there are so many partnering choices. Lower capex, you are making use, reusing the sensors, reusing the applications, so thereby a significant cost decrease, lower operating cost also and time to market is too fast.

It is not that the existing devices and sensors are not going to work, they will coexist because all of them are not going to be changed. We must have a coexistence of non-standardised entities and the standardised entities. While we are promoting standardisation, we are saying standardisation should be there, so standard oneM2M devices would be there, non-standard would be there. They will be categorised as devices, they definitely would have to talk through some service provider.

Now applications will be there in the form of application service providers and they will all be driven by policies. The policies would be like KYC policies, regulations, licensing, privacy, security and this policy will actually drive all of them. And the governing body also will be driven by the policy.

So, this particular governing body then on will actually talk to the service providers, the devices and applications in order to get the metadata (data about the data and not the data itself as the data might be encrypted) out of all these entities to be able to make informed decision and the policies in order to cater to the citizens in a far better way than it is being done today.

For future proof ITS application infrastructure, these are the essential entities. The architecture shall be standardised and futureproof, it shall promote interoperability, it shall be possible to share data amongst verticals and authenticated devices & applications shall be permitted to communicate and security shall be an integral component of the architecture.

Further, it is important to consider the fact that if we try to think each application vertical like ITS, Health, Power, Industry, Home, Street Light, Waste Management and Surveillance in isolation, we may again end up in siloes. A much better approach thus would be to consider the architecture which cuts across all these verticals in a horizontal way staying agnostic to these application intricacies, yet covering all the essential ingredients of all the applications in a standard way. And oneM2M fulfils this in every way.