IoT interop across the OSI model
December 12, 2016
The Open Systems Interconnection (OSI) model is the foundation of Internet communications, including for devices connected to the Internet of Things (...
The Open Systems Interconnection (OSI) model is the foundation of Internet communications, including for devices connected to the Internet of Things (IoT). However, the wide variety of existing communications technologies and protocols that plug into this framework has resulted in significant interoperability issues that often force IoT device manufacturers and end users to adopt one method of connectivity or another at various layers of the OSI model, leaving industry at a crossroads of consolidating around a few ubiquitous technologies or accepting fragmentation that could exist on a vertical-by-vertical or application-by-application basis.
In this interview with Sarva Thulasingam, CTO at IoT cloud platform and connectivity company Infiswift, we discuss the potential of an agnostic common data format that could circumvent interoperability issues up and down the OSI stack.
What are some of the leading connectivity/communications technologies being used in the Internet of Things today?
THULASINGAM: If you look at the OSI model and communications stack, at the physical link layer, Wi-Fi, Bluetooth, Low-Power Wide-Area Network (LPWAN), and GPRS are the communications technologies being used. At the network layer, we see a lot of IPv4 and IPv6 being used. At the transport layer we see TCP but also some customers using UDP servers, so we have to have a client that’s compatible with TCP and UDP. At the presentation layer, it’s pretty much the lightweight presentation protocol (LPP), the X.25 packet assembler/disassembler protocol, and things like that. At the application layer, publish/subscribe-based protocols such as MQTT are predominant. We also see big Google-like companies using request/response protocols like HTTP, and of course they have their own protocols like Weave that they are using as well.
The technologies vary from sector to sector based on the use case. This is quite an important decision point in IoT deployments since, as everyone is aware of, communications technologies are evolving at rapid rates and a farmer or a fleet manager is not equipped with the know-how and expertise to adapt to this changing landscape. That’s why at Infiswift we try to address interoperability through an IoT connectivity abstraction platform and software that can aid in the transition to newer and potentially cost-saving technologies.
Is there a need for industry to settle on a few specific standards given the number of technologies currently associated with IoT communications, or should we rather accept the fragmentation and develop solutions to address it?
THULASINGAM: We believe that interoperability in IoT will be addressed differently at different layers. For example, at the physical layer, if one device uses ZigBee and another uses Bluetooth, there needs to be some sort of bridge that allows them to interoperate with each other. Similarly at the protocol layer, a device that uses MQTT and another that uses HTTP can interoperate through the use of protocol adapters.
Different standard bodies have done a significant amount of work to standardize protocols and simplify implementations, and as a result you keep seeing new protocols being developed, with MQTT as a perfect example. Existing protocols are also being combined in new ways, with lightweight protocols being defined.
In addition to all of these bridges and adapters at the communication layers, we also need application layer interoperability. For instance, how do we ensure that a sensor from a particular manufacturer talks to a device gateway from another vendor, and eventually through the gateway to a cloud backend that’s operated by yet another vendor? To me, at the application layer, interoperability is not yet mature. Work on data formats especially has not seen the same level of consistency throughout the various standardization groups.
Infiswift’s vision is to develop an open, semantic model that represents the state, configuration, attributes, behavior, etc. of a device in an encoding-agnostic, protocol-agnostic, and hardware architecture-agnostic manner. We intend to use this model for all of our machine-to-machine (M2M) communications such that we can drive semantic understanding and control of devices within an ecosystem, and also so that we can interoperate with any other network or device in the future that embraces the open semantic model. We’ve filed for a patent on a common data format that is protocol agnostic, but there’s a huge amount of work to do as an industry around how the semantics of different frameworks interoperate.
What can you tell me about the data format?
THULASINGAM: That’s a fully loaded question, so I’ll keep it a little high level. Let me break down the IoT communications stack into smaller chunks and talk about the approach.
At the end of the day, IoT communications is M2M. A machine in IoT terms could be a simple sensor in the real world that communicates with a hand-held computer or tablet that displays information on the behavior of connected devices through a dashboard. The layers of communication technology that lay in the path of delivering sensor data to interested parties or devices include:
-
- First, sensor to messaging device communications. Sensor to messaging device communications involves the sensor itself, which is fundamentally a very low-end computer with very minimal compute that is usually optimized to collect measurements. Sensor platforms also include some sort of wireless access mechanism and the hardware to send readings through a remote server or device. In many cases, simple and cheap technologies such as Bluetooth Low Energy (BLE) are employed to connect a bunch of proximate sensors to a local gateway device, which acts as a messaging client that encapsulates the sensor readings and sends them on to the next layer of processing in the IoT hierarchy.That’s the sensor to messaging device communications, and what we are essentially doing there is building on a communication technology-agnostic abstraction layer that will help customers transcend across the variety of hardware and software stacks needed to get sensors hooked into a messaging device. In other words, we are writing a shim kind of layer that runs on our client software and takes care of converting data coming from a different format into a single format that can be transferred into our backend cloud for analytics and so on.
- The next segment is messaging device to messaging gateway communications. The messaging gateway is usually a more powerful computer than the sensors, and has the capability of longer distance transmissions at higher bandwidth rates. Often, this is an optional layer, but there are a variety of last-mile access technologies that can be used based on the location, cost, and scale of devices (as well as the architecture of the system being deployed) to connect to a gateway device that then provides Internet or cloud access for all of the devices connected to it.For messaging device to messaging gateway applications, the Infiswift approach to is to hide the complexity of the underlying last-mile access technologies and provide consistent and rich abstraction to any messaging device so that it can seamlessly connect to the cloud via the messaging gateway using a variety of mechanisms.
- The next segment in the stack is messaging device to cloud communications. Here, a messaging device (or messaging gateway) encapsulates sensor readings and sends them to load-balanced cloud servers, which are also called messaging brokers in terms of MQTT, etc. Typical communication technologies used here range from MQTT at the session layer to TCP/IP at the transport and networking layer to GSM, GPRS, and LTE as typical physical and link access technologies to reach the cloud-connected servers.There are several highly secure, available, and connectivity agnostic cloud platforms for messaging device to cloud-connected server communication that can serve the connectivity and data management features needed by IoT consumers, including AWS, Microsoft Azure, Google Cloud, and bare metal. Infiswift takes the best of all these technologies and unifies them in our platform so that that key insights and learnings from various solutions and verticals can be abstracted and shared among customers, based on their preferences.
- The last piece is the cloud broker to interested machine communications. There highly secure communication mechanisms with rich analytics and reporting features provide industrial machines with data that has been transformed into useful information in the cloud. The Infiswift platform supports this through multi-tenancy in our various cloud components, which includes provisions for privacy, separation of data and processing, and so on.
What is going to prevent the open, semantic framework you’ve suggested from encountering the same problem of fragmentation that’s occurred elsewhere with IoT communications?
THULASINGAM: We’re looking at taking this technology to different standardization bodies. One of the organizations we are looking at is the Open Mobile Alliance Lightweight M2M (OMA-LWM2M) Working Group because we are interested in what they are doing around the single object model for different interoperability scenarios. The OMA consortium initially developed standards for mobile devices, and is now expanding that use case into different varieties of IoT devices, especially edge devices.
Also, we are looking at the IPSO Alliance’s Starter Pack, the Cluster Library developed by the ZigBee Alliance, and, of course, the Open Connectivity Foundation (OCF), who is doing some work on the Universal Plug and Play (UPNP) management and control specification.
These are some of the obvious standards and specifications we are looking at, and we’d like to partner with various players already focusing on these areas to see how we can contribute.
Infiswift
LinkedIn: www.linkedin.com/company-beta/6643091
Facebook: www.facebook.com/infiswift
