This file type includes high resolution graphics and schematics.
Recent developments in connectivity technologies have spurred the adoption of Internet-connected “smart” devices for remote sensing, actuating, and intelligent monitoring using advanced analytics and real-time data processing. As the pace and the scale of such solutions increase rapidly, there will soon be a problem getting these disparate solutions to work seamlessly together to realize a large-scale Internet of Things (IoT). Recent developments in protocols and standardization initiatives for the IoT, particularly application layer protocols, aim to address these issues.
Table Of Contents
- Introduction
- Emerging Dilemmas
- IoT Protocol Stack
- Application-Level Interoperability Scenarios
- Conclusion
- References
Introduction
There is an ongoing trend in integrating machine-to-machine (M2M) and wireless sensor network (WSN) solutions with other established Internet services using existing Internet protocols (IPs). This trend has brought the standard IP-centric protocols into the realm of smart devices and smart objects. Solutions such as the iDigi Connect attempt to bring standard connectivity to embedded devices through TCP/IP stacks and Web services through which data acquired can be aggregated over the Internet for visualization and analysis.1
Two of the biggest challenges that IoT implementations face are the presence of low-powered devices, which need to function for months or years without getting any power recharge, and frequent data exchanges over lossy networks. These unique characteristics and challenges make the as-is use of the existing IPs less than ideal and suboptimal.
Different standardization bodies and groups are active in creating more interoperable protocol stacks and open standards for the IoT. As we move from the HTTP, TCP, IP stack to the IoT-specific protocol stack, we suddenly confront an acronym soup of protocols, from wireless protocols like ZigBee, RFID, Bluetooth, and BACnet to next-generation protocol standards such as 802.15.4e, 6LoWPAN, RPL, and CoAP, which attempt to unify the wireless sensor networks and the established Internet.
The IoT is an ambitious paradigm that significantly increases the scale of connected devices. To manage the complexity of such a scale, interworking solutions that can reuse pre-existing technologies seamlessly with newer and more efficient technologies is a necessity. Ongoing standardization efforts towards harmonizing Internet protocols for a WSN-based IoT have raised hopes of global interoperable solutions at the transport layer and below. With that being addressed, the next requirement is to address interoperability at the application layer.
Emerging Dilemmas
Smart objects, low-powered devices, and WSNs are trying to grow beyond narrower domains/fields of deployments, wanting to be connected to the cloud/Internet, but suffer from constraints and scalability limiters. On the other hand, there is the worldwide Internet, which is very successful in terms of scale and where users are spoiled for choices on de-facto standard technologies like HTTP, SMTP, and SSH but never have to deal with severe power/data loss constraints. Hence, developers today have to choose between efficient but proprietary islands of standards and the scalable and interoperable but less power-efficient Internet technologies. There is a natural consequent attempt from both sides to assimilate and harmonize. This is where the challenges and, hence, the opportunities are. Innovation here can happen in several directions.
Related Articles
• The Internet Of Things Needs Firewalls Too
• Data Mashups Will Make Internet Of Things Useful
• White Space: First Frontier For Internet Of Things
First, the resource constraints may get eased through advances in device computation/networking technologies such as low-powered microcontrollers, longer lasting batteries, alternate power sources, cheaper storage, and bandwidth. These developments might enable the introduction of proven Internet technologies in the newer IoT domains. But these are usually high-investment, high-impact innovations and tend to involve corporations with very large research budgets, such as Intel’s Atom processors for the IoT.2
Second, standardization bodies and alliances are working on defining newer protocols that are optimized for specific use cases and underlying deployment scenarios. Adoption of these protocols and standards involves collaboration among government standards institutes like ETSI, organizations like IETF/IAB, and alliances like ZigBee and Dash 7. Large corporations can make choices for implementing protocols and standards that may be independent of standardization efforts, like Facebook using the IBM MQTT protocol for integration with mobile devices.3
Third, there will be a (perhaps prolonged) period of mixed deployments bridging islands of highly domain specialized and optimized WSNs with the rest of the Internet through gateways and middleware. This is where many incremental innovations might be most visible in the coming few years. But this is also going to require the availability and understanding of a few well-defined open standards-backed protocols.
IoT Protocol Stack
Embedded networked sensor researchers had agreed upon the idea that IP could and should be applied to even the smallest of devices. IPv6, which has succeeded IPv4, has a near infinite address space, allowing for 2128 or approximately 3.4 x 1038 unique addresses. The new 6LoWPAN protocol was defined to enable IPv6 packets to be carried on top of low-powered and lossy personal area networks (LLNs). A draft architecture for a gateway or middleware that provides interoperability between 6LoWPAN and external IPv6 networks has been defined.4
The underlying physical layer (PHY) and media access layer (MAC) for the 6LoWPAN protocol is the IEEE 802.15.4 standard. The 802.15.4-2006 (successor of the 2003 version) is the physical or layer 1 protocol for low-power and low-rate (data transfer at 250 kbits/s) LLNs. The MAC amendment to the existing 802.15.4-2006 has been called IEEE 802.15.4e to better support the industrial markets and permit compatibility with the modifications proposed within the Chinese wireless personal area network (WPAN). The key technical element of the new proposed 802.15.4e is channel hopping, which significantly increases robustness against noisy and lossy networks and persistent multi-path fading.
This file type includes high resolution graphics and schematics.
The IETF Constrained RESTful Environments (CoRE) workgroup is working on the application-layer protocol for introducing the Web-services paradigm in the IoT.5 The CoRE group has defined a REST-based Web transfer protocol called the Constrained Application Protocol (CoAP). This protocol includes several HTTP functionalities but has been redesigned to account for the low processing power and energy consumption constraints of IoT devices. CoAP, similar to HTTP, identifies resources using a universal resource identifier (URI) and allows the resource to be affected using similar methods such as GET, PUT, POST, and DELETE. But CoAP is not just a blind compression of HTTP.
W. Colitti, et al., at Vrije Universiteit have compared the performance of HTTP with CoAP and have experimented with an IP-based smart objects protocol stack (see the table).6
CoAP’s transaction layer can include four types of messages: confirmable (requires an ACK), non-confirmable (does not need an ACK), acknowledgement (ACK for a confirmable message), and reset (indicates a confirmable message is received but context is missing to be processed). The request/response layer is where the REST-based communication occurs. The CoAP request has the following format:
GET coap://[]: []/[]The experiment involved a CoAP-enabled Web server. An HTTP Web server on the Contiki embedded operating system has found that requesting the same resource on the device uses 154 bytes per CoAP transaction and 1451 bytes for an HTTP transaction. The power consumption for the CoAP and HTTP transaction is 0.774 mW and 1.333 mW, respectively. Hence, the CoAP transaction was found to consume 42% less power than the HTTP transaction in the particular experiment.
An IoT application frequently involves a device or a smart object transmitting information regarding its state, context, or sensory measurements to other clients or devices. CoAP supports a functionality called observations wherein a client (the observer) can register itself to the resource (the subject) by means of a modified GET request. The server establishes an observation relationship between the client and the resource. This functionality avoids the frequent server polling or keep-alive sessions that clients need to do in the case of an HTTP-based connection. CoAP has been built over the UDP since the minimally required reliability is achieved through the transaction layer of the protocol.
Researchers from the OpenWSN team from Berkeley are creating an open-source implementation of protocol stacks based on IoT standards, using a variety of hardware and software platforms. A detailed guide for implementing the 802.15.4e standard for different microcontrollers has been prepared and made freely available on the team’s site.7
One of the key energy/power considerations in wireless communications for low-powered devices is the functioning of the wireless radio transceiver. Communication protocols that allow the radio to remain off for longer periods of time are far more energy efficient than those that require the radio to be in the receive mode for longer durations.
Recent research advances have shown that the CoAP protocol can be made more power-efficient through generic radio duty cycling.8 Radio duty cycling essentially means the ability to keep the radio off as much as possible. Experimental studies have shown that existing IoT protocols like CoAP, when used over a radio-duty cycling-enabled MAC protocol, can provide a power efficiency of up to a factor of 26 compared to no duty cycling.
The implementation of ContikiMAC by Matthias Kovatsch, et al., has demonstrated that an existing application-layer protocol can be made power-efficient through the use of a generic radio-duty cycling protocol without changing any of its features or extensions. Besides the IEFT standards-based initiatives, several other protocols are also under various stages of discussion, development, and implementation. Relevant protocols from an IoT solution implementation perspective include:
- Message Queue Telemetry Transport (MQTT): Developed by researchers at IBM, MQTT is designed as a lightweight publish/subscribe messaging transport connectivity protocol. It has been integrated with the IBM WebSphere application server.
- ZigBee Alliance: ZigBee is a set of application profiles for creating low-rate wireless mesh networks that has been built upon the 802.15.4-2003 standard. While ZigBee is not directly comparable to IEFT standards like 6LoWPAN, it has been extensively implemented in small-scale ad-hoc networking smart-home and smart-objects applications.
- Dash7 Alliance: Dash7 works at the 433-MHz frequency range and is employed, among other uses, for tag-to-tag communications. It typically has a range up to 1 km, which shrinks as the data-transfer bit rate is increased.
- BACnet: A communications protocol for building, automation, and control networks, BACnet was standardized in 1995 and became an ISO standard in 2003. It is essentially used in HVAC systems, lighting control, and access control.
Application-Level Interoperability Scenarios
The MQTT protocol specification describes the protocol to be ideally suited for resource-constrained environments where the network runs on embedded devices with limited processor or memory resources and is expensive, has low bandwidth, or is unreliable.9 Designed for asynchronous transfer of telemetry messages, this open publish/subscribe protocol uses a broker-based asymmetric architecture where the complexity is moved to the higher resource-capable broker nodes. While MQTT is based on the TCP/IP stack, MQTT-S is an extension for non-TCP/IP stacks, keeping low-end sensor devices in mind.
MQTT-S attempts to provide an abstraction for asynchronous communication using a content-centric communication paradigm rather than a network address-centric one. Such a decoupling is expected to allow scaling and dynamic application topologies.10 But of the three principal types of publish/subscribe systems, topic-based systems are the easiest. Type-based and content-based systems are more difficult to achieve. Type-based communication demands type information to be additionally exchanged as meta-data among the publishers and subscribers, adding substantial overhead for the constrained devices.
IETF is standardizing the CoAP protocol for low-powered and lossy networked environments. Unlike MQTT, CoAP, while being a single protocol, is conceptually separated into two sub-layers: a messaging layer and a request-response sub-layer. The messaging layer provides asynchronous messaging services over datagram transport. The request-response sub-layer handles and tracks requests and responses exchanged between a client and servicer-side application endpoints. Thus, CoAP directly supports Web services. It also provides stateless mapping between HTTP and CoAP at the proxies.
A situation may arise where an application running on a low-powered device uses the MQTT protocol and may need to communicate and interact knowledgeably with a remote device that may only understand CoAP-based messages. This is a plausible real-world scenario that can, as an example, occur when the mobile Facebook app (via the Messenger app) would like to communicate with not just a group of people but also Internet-enabled devices. The IoT is specifically about people and devices interacting seamlessly.
In the case of the Mobile Facebook app, the messenger app is designed so groups of people can chat easily. But if one of those messages involved retrieving data from a remote sensor or sending a command to an actuator, it would need to be sent in a protocol that is understood by the remote device. Many sensing and actuating devices are being built using open-source hardware like Arduino. Different CoAP server-side libraries have already been ported to the Arduino platform. Hence, an interoperability issue arises when an MQTT-enabled client wishes to send a message to a CoAP-enabled server or vice versa.
A seemingly obvious solution would be to simply enable the client and the server to handle both the MQTT and CoAP protocols and, depending on the remote device capabilities, to send the message in a suitable protocol. But in an environment where the processing and memory availability is highly constrained, implementing multiple protocols on these low-powered devices would not be an ideal situation.
Implementing multi-protocol libraries and interoperability at the device level should be avoided. This leads to the need for IoT gateways or middleware that can provide protocol-level interoperability by translating the data, the context, or the meaning of the message from one protocol to another. In essence, the IoT gateway should be able to handle a situation where a message comes to a mobile device over the MQTT protocol, and the same message, keeping the data (in case related information is sensed) or the command (in case related instructions are actuated), should be translated correctly to the CoAP protocol without changing the meaning or context of the message.
Conclusion
While these scenarios may not be immediate requirements in terms of interoperability, they represent the kind of needs that will arise rapidly as IoT solutions get built based on varied and custom protocols. Interoperability goes beyond providing protocol proxy types of services. Middleware that provides interoperability needs to be aware of the context and meaning contained both in the header (fixed and variable) as well as in the payload of the message. This middleware will play a crucial role in keeping the applications on resource-constrained devices optimized and providing a seamless experience for the solution developers as well as the end user.
References
- Digi: http://www.digi.com/products/wireless-wired-embedded-solutions/solutions-on-module/digi-connect/
- Intel Intelligent Systems: http://www.intel.com/p/en_US/embedded/innovation/manageability/marisetty-article-manageability
- “MQTT and Android make great partners,” http://mqtt.org/2011/08/mqtt
- K. Kim, S. Yoo, H. Kim, S. D. Park and J. Lee, “Interoperability of 6LoWPAN,” draft-daniel-6lowpan-interoperability-01, IETF, vol. 7, 2005
- Z. Shelby, K. Hartke, C. Bormann, and B. Frank, “Constrained application protocol (coap),” draft-ietf-corecoap-07, 2011
- W. Colitti, K. Steenhaut, and N. De Caro, “Integrating Wireless Sensor Networks with the Web,” Extending the Internet to Low Power and Lossy Networks (IP+ SN 2011), 2011
- OpenWSN: http://openwsn.berkeley.edu/
- Kovatsch, Matthias, Simon Duquennoy, and Adam Dunkels, “A low-power CoAP for Contiki,” Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8th International Conference on. IEEE, 2011
- “MQTT v 3.1 Protocol Specification,” IBM, http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/MQTT_V3.1_Protocol_Specific.pdf
- U. Hunkeler, H. Truong, and A. Stanford-Clark, “MQTT-S—A publish/subscribe protocol for Wireless Sensor Networks,” in 3rd International Conference on Communication Systems Software and Middleware and Workshops, COMSWARE 2008, IEEE, 2008, pp. 791-798
This file type includes high resolution graphics and schematics.