IPv6: The engine of “The WEB of Things”
In previous articles we have explained the basis of the new Internet protocol and the fact that the Internet6 is growing rapidly, in parallel to the current network. In this new installment, we explain in a didactic way how IPv6 is called to become an essential part of the paradigm of the “WEB of things”.
Surely you have heard the terms M2M (Machine-to-Machine) and IoT (Internet-of-Things) on numerous occasions. The Internet of Things it means connecting millions of new autonomous devices to the network. The concept ranges from simple sensors or actuators to operate household appliances, to complex public lighting infrastructures or industrial systems, through cars and smart homes.
From the “Internet of things” to the “WEB of things”
If we carefully analyze many of the IoT solutions existing today, we will conclude that, strictly speaking, the devices are not really part of the Internet. For example, they do not have an IP address.
Furthermore, WEB services are not offered from the same devices, but from intermediate gateways or platforms. The latter are the ones that are actually present on the Internet and offer services to users.
Finally, as communication between devices and gateways is not an Internet standard, proprietary protocols and solutions have proliferated. In many cases, they are protected by patents and ultimately involve the payment of royalties for the development of new implementations. The following figure shows the alternative that we describe in this article.
In devices of a certain entity and powered by the electrical network, it is possible to use TCP / IP over WiFi or 3G networks, and for the device to implement the well-known REST-type WEB services for their management.
However, one of the challenges we face in the communication of the devices is that, in many cases, they are small sensors powered by batteries and linked to more powerful gateways through low-power radio networks (WSN networks or LowPAN).
These radio networks have a greater probability of message loss and for their optimal operation they require that the messages be as short as possible.
Due, using HTTP-REST over TCP / IP is inefficient and inadvisable in these environments.
However, as we will see below, improvements in component integration, energy consumption and new standards have finally prevented us from abandoning the idea that all devices, including small battery-powered sensors, have an IP address and offer their own services in the new WEB. Obviously, for there to be enough addresses, IPv4 does not work, it has to be IPv6.
Thus, recently, the IETF (Internet Engineering Task Force, the organization of Internet protocol standards) has defined an alternative in the form of a standard so that these devices are actually connected to the Internet, more specifically to the Internet6. It is known by the name of “6LowPAN ”, the IPv6 of LowPAN networks (Low Power Area Networks).
The main difference with the previous model is that the devices are full-fledged Internet nodes, that is, they have an IPv6 address and a priori have end-to-end connectivity with any other node on the Internet6.
Furthermore, these end nodes (the devices) are the ones that directly offer the WEB services (measurements or commands with SensorML, XML, JSON standards, etc.). For this reason, it is said that 6LowPAN opens the paradigm of the “WEB of Things” (WoT, Web of Things) or “Internet of Embedded Systems”.
In any case, as we will see in the next section, the traditional scheme of REST services over HTTP / TCP is not used, but the new CoAP / UDP standard, notably extending the current WEB paradigm.
In the previous figure we can see that a gateway to the IPv6 Internet is also needed. However, it is simply a router (router) that compresses and expands the headers, following the 6LowPAN standard. Because of this, these networks and devices are just another part of the Internet6.
Furthermore, these are totally open technologies that anyone can implement without infringing patents or incurring intellectual property costs.
Finally, although the devices have all the intelligence to offer basic services on the Internet, this does not mean that we do not build platforms that allow us to manage them and provide more complex services. When it comes to platforms, the main advantage is that we avoid proprietary protocols and gateways that introduce delays, limitations and costs.
What is the architecture of this “Web of things” on the Internet6?
6LowPAN has been defined to work on the IEEE 802.15.4 radio network standard. This standard allows wireless meshed networks (meshed networks). In this way, some nodes can make use of others as repeaters or routers of their messages to always guarantee coverage, and the sending and receiving of messages.
When it comes to the service layer, the logical thing to do would be to use the ubiquitous REST service model, since there are many implementations, tools, and developer experience. However, using HTTP-REST in LowPAN networks has many drawbacks, since the TCP protocol is used as transport.
The problem with TCP is that it is a connection-oriented protocol and therefore requires establishment and termination messages (Three-wayhandshake). Furthermore, being a reliable transport protocol, it performs retransmissions whenever any of the datagrams into which the information to be transmitted has been divided is lost.
For this reason, the IETF has defined CoAP, a new service layer for restricted environments that preserves the REST model, but uses UDP as the transport layer.
CoAP has an API identical to REST-http, that is, the set of CRUD operations (Create, Read, Update and Delete), but the transport is carried out over the UDP protocol, not connection-oriented and unreliable. CoAP allows two types of messages: confirmed and unconfirmed.
Confirmed messages assume acceptance by the receiver (ACK), in such a way that, if they are lost, they are retransmitted a limited number of times. Unconfirmed messages can be used for those cases in which it is preferable to lose the periodic information of some sensors, rather than saturate the network with retransmissions, something that is not possible with the REST-HTTP model.
With all of the above, we have described the complete architecture of the “Web of Things” for radio networks with mesh topology:
- IEEE802.15.4, for the radio level (physical and link layer, OSI levels 1 and 2).
- 6LowPAN, for the network layer (network layer, OSI level 3).
- UDP: for the transport level.
- CoAP: which offers a REST API and forwarding capabilities for committed messages.
The devices can use any standard currently used over CoAP, such as SensorML or other variants based on XML or JSON.
Are there prototypes or test kits?
The architecture described above has become part of the standards promoted by ETSI M2M, in such a way that multiple implementations have appeared, which have been tested in the interoperability tests of that standards body.
In addition to proprietary developments by commercial companies, there are already two free operating systems, Contiki and TinyOS, for embedded systems that implement the 6LowPAN stack and the CoAP services layer.
Thanks to these free operating systems and open hardware, devices with this architecture can be developed at very affordable prices, within the framework of DIY projects or prototypes (“Do-It-Yourself”).
As far as open hardware is concerned, there are general purpose boards, such as Arduino or Zigduino (which incorporates the radio chipset as standard), or modules or “specks” oriented to the prototyping of sensors and actuators.
The following photo shows an open hardware module recently purchased for testing with 6LowPAN and CoAP, thanks to the Contiki operating system.
Users and platforms that access these services can be done using the traditional REST-HTTP (CoAP was designed so that the proxies between both protocols are simple and efficient) or by implementing CoAP on the platform or client. The latter is also very simple since there are already CoAP libraries for C, C ++, Java and Python.
Is the industry positioning itself with implementations?
A relevant example is the light bulb controllable by Android smartphones announced by Google. This solution employs 6LowPAN technology. The following diagram includes a reference schematic of a similar bulb published by the manufacturer JennetIP.
Another well-known example is Vinton Cerf’s smart wine cellar (considered the father of the Internet) presented at CES in Las Vegas this year and which is based on 6LowPAN devices.
Devices with IP address? Will it be expensive? Will it be inefficient?
Many times we are asked this question. In reality, electronics and software have reached much higher heights on the scales of integration, power consumption, and prices. A clear example is the smartphone.
At present we have been able to test devices with the architecture described above (motas 6LowPAN) and that work with two 1.5V AA batteries for a little over a year.
On the other hand, CoAP / 6LowPAN offers a great optimization in terms of the total number of information (bytes) transmitted and the transmission time, which also results in a longer battery life.
To conclude, the following diagram shows a comparison of the transmission of a message from a sensor in a LowPAN network over CoAP / UDP and over REST-HTTP.