Avnet Arm

CoAPing with the REST of the Internet of Things

by DonDingee on ‎03-14-2013 12:00 PM

On the Internet, computers are optimized for big, fast file transfers. Nobody has time to sit around waiting for a web page to load, or watching progress meters chunk away while an MP3 is downloaded, or staring at a buffering percentage while streaming video. Faster is better. The entire network from the microprocessor to the router to the server is designed for speed and interoperability with devices spread all over the globe.


In the realm of “Things,” everyday devices with intelligence built in, the criteria are quite different. Usually quite small, Things typically send little chunks of data to something else, and they often run on batteries so they sleep a lot to save power. Microcontrollers and wireless sensor networks have generally been designed for power efficiency, with relatively limited compute power and limited interoperability connecting with other devices very close by.


We put these ideas together and get the Internet of Things, or IoT for short. Things should be accessible from a web page, with an address just like a computer. Any computer or smart phone could connect to anything, anywhere. We could then write killer applications to create and processes mountains of big data from billions of devices, transforming the world as we know it.


Except, the technology that made the Internet work well does not work very well on Things.


HTTP comnparison to CoAP.jpg


On the left side of the above chart are the layers of Internet protocols necessary to make most web applications work.  TCP/IP and IPv6, driven by the popularity of PCs, Ethernet and Wi-Fi, are the networking standard.  These protocols, designed for robustness, enable forwarding of packets from machine to machine until they reach their destination and retransmitting data if messages become corrupt en route.


On the right side is a world designed for small, efficient transfers. While it is possible to embed the heavyweight protocols from the left side on smaller devices, the result will be relatively expensive, slow and power consuming. Overhead factors in heavily: when transfers are short bursts of data, the headers and other formatting for packets can be far larger than the actual bytes of data being transferred.


6LoWPAN provides an IPv6 endpoint in a small footprint, designed for operation over any physical medium, such as an IEEE 802.15.4 compliant radio. UDP is already familiar to most as the lighter transport protocol for data, omitting retransmission and error correcting overhead. Together, these enable the basics of device addressing and packetized data transfers over a wireless or wired network.


A relatively new innovation is the Constrained Application Protocol (CoAP), created within a REpresentational State Transfer (REST) architecture. CoAP uses similar mechanisms to HTTP – GET, PUT, POST, DELETE, and more – which brings web-style application programming to bear, but in a much lighter implementation suitable for small devices.


Practically all cloud implementations today are IP-based, but many of the wireless sensor network technologies require some type of protocol gateway to connect with IP clouds. An implementation of 6LoWPAN with CoAP is a more direct method for connecting and controlling Things via the cloud.  Add to that the straightforwardness of RESTful application programming compared to the massiveness of CORBA, RPC, SOAP, and other web services methods, and this approach is one embedded developers should be aware of.


The CoAP specification is ready for publication by the IETF. Commercial implementations like NanoService from Sensinode are enabling developers to get started with the technology today. The design of NanoService can handle up to 20 million nodes, manages a directory of devices and resources, and supports an eventing model.  The developer tools include a web-based admin GUI, a Java SDK and reference applications, and device libraries for C, Java, and Android.


Are you seeing a need for 6LoWPAN and CoAP in embedded devices? What problems have you encountered in trying to implement IoT applications, and will a RESTful framework help with solving the issues? Your comments and ideas are welcome.


Don editor gray iso.jpg



Don Dingee is bringing ideas and information from across the social computing community to unite developers, vendors, and anyone interested in connected device technology and software development. His journey has taken him to places like the University of Southern California, General Dynamics, and Motorola, where he built a foundation in embedded engineering and product marketing. Don has taken to storytelling in recent years as an author, speaker, consultant