This post describes how the IPv6 Internet brings a new approach for m2m or IoT services resulting on a number of benefits for all players in the value chain as well as opportunities in pretty different vertical businesses, such as: geek-like gadgets, smart homes, connected cars, smartcities, logistics, e-health, etc.
To write this article a bunch of previous studies and hands-on with real sensors was needed. The collaboration and good ideas of my colleague and friend Cristina Peña (@crisisP) are an essential part of those results. If you want to read a similar resource in Spanish language, follow this link.
How is the machine-to-machine landscape today?
Most M2M systems are based on sensors or actuators that use some kind of low-level communication protocol to communicate to a gateway which, in turn, enables users' interaction, service creation or expose services/APIs to local or remote platforms or Apps.
Some communication low-level protocols work over existing or new wiring and others work over radio systems. Many times they tend to be proprietary protocols, far from the IP convergence that is happening in most domains.
On the contrary, IoT gateways are typically connected using the standard TCP/IP to the Internet, normally over 2,5G/3G/LTE, Wifi or wired access points.
This way, most Internet of Things implement the generic model drawn in the following diagram.
Actually, I am myself a fan of home smart devices for a long time at home. My current setting does follow the model presented above:
- A MAC notebook running perceptive Indigo home-automation software implements a complex state-machine, aware of house occupancy thanks to movement and door-status RF X10 sensors.
- Additionally, the system is able to control all blinds, lights and lamps over X-10, a whole-house audio system over RS-232 and the home air-conditioned over the Red-Rat IR converter.
While my own setting works fine, X-10 usage of home power wiring results on unreliability at many other installations. At the same time, RF X-10 sensors are normally unidirectional and with limited coverage and reliability.
Several new technologies have been developed to improve the historic but still popular and cheap X-10 for smarthomes. In parallel, others have been developed for industrial applications or other sectors where reliability and other features are a must.
Popular wired solutions are Lonworks, KNX (very popular wired system for smarthomes in EU) and, similarly, well-known wireless solutions today are Zigbee or Z-wave.
Zigbee and Z-way are both proprietary technologies that implement bidirectional devices improving reliability and coverage by the means of radio meshed networks (IEEE 802.15.4), where nodes may use others to route messages to a gateway.
Devices send and receive messages to/from the gateway, that might implement local services or be connected to the Internet and expose services or APIs to remote platforms or Apps.
The Web of Things
The following picture shows a different and emerging model, where sensors are truly nodes of the Internet and expose Web services themselves.
This model enables sensors to send observations directly to the customers using direct unicast links, a hierarchy of relays or even multicast flows. This enables new approaches saving resources, complexity and costs at the m2m backend, that still may manage the registration, configuration and actuation over the devices.
Moreover, in some specific scenarios devices could directly be managed by end-user Apps (e.g. from a mobile) without the intervention of an m2m backend.
In contrast, what we have seen so far are devices connected to gateways that offer services. Normally, APIs exposed to remote apps or platforms are provided over the successful REST WEB paradigm.
REST model exposes resources via URIs (WEB resources) and remote clients are able to perform CRUD (Create, Read, Update, Delete) operations over them. For instance, you can send a command to a sensor or get an observation from it by accessing the proper URI (e.g. http/server/home-sensors/temperature/living-room) at the server with the correct HTTP method and payload (normally XML or JSON descriptions).
The next two sections explain the technologies delivered by the IETF to make this a feasible paradigm and further sections explain available commercial implementations and how you can get to play with it, if interested.
6LowPAN: efficiently making sensors nodes in the Internet6
Electronics integration advances and economy-scale have resulted in powerful and cheap radio-mesh sensors operated by regular 1,5V AAA batteries during one year or more.
Such devices are perfectly able to run an embedded reduced OS (Operating System) that includes a TCP/IP stack, libraries for Web services, and basic REST services exposed to the overall Internet.
However, IP is not efficient at that level because of the headers overhead and link-layer convergence mechanisms.
This exactly what the IETF has been lately working out, creating an specific IP protocol for WSN (Wireless Sensor Networks) or LowPANs (Low-power PANs).
Obviously, in order to have enough addresses for sensors and avoid the need of NATs, what the IETF has actually delivered is an IPv6 protocol for those networks, known as "6LowPAN".
6LowPAN is basically an IPv6 with extremely compressed headers and much more efficient protocols for routing, neighbor discovery, etc. Because of this, it still needs a gateway to get connected to the Internet6, but differently to other solutions such as zigbee or z-wave, the gateway only operates at the OSI layer 3, behaving more as a router between the 6LowPAN domain and the outer world.
Therefore sensors are real Internet6 nodes that can be even pinged from any node, if the security policies allow that to happen.
6LowPAN has become an emerging technology with a respectable wide implementation by different companies and open software and hardware initiatives, as described in further sections of this article.
CoAP: making sensors service plane efficient for 6LowPAN comms
As said before, m2m platforms normally expose services exploiting the successful REST model that relays on HTTP/TCP.
The problem of using the same model for sensors to expose services is that TCP is a connection-oriented protocol introducing plenty of overhead due to session establishment (3-way handshake) flow control and retransmissions in case packets are lost (an often fact in LowPAN networks).
In order to optimize communications at this level, the IETF CORE WG has delivered CoAP, an application level protocol that we can consider a REST implementation (CRUD operations) over UDP.
CoAP has been designed to be fully compatible with the current Web infrastructure, including existing proxies, new CoAP-HTTP proxies, browsers, etc.
CoAP has been largely implemented so far. There exist libraries available for C, C++, Java and Python.
We can also find CoAP libraries in embedded open Operating Systems with 6LowPAN support for sensors (e.g. ContikiOS, TinyOS).
Detailed Architecture of the Internet6 Web of Things
As shown in the following diagram, sensors provide services via CoAP (over 6LowPAN) that might be translated later to HTTP/IPv6. However, we can also think on clients directly accessing CoAP URIs.
Existing Internet6 Web of Things Products & Solutions
Sensinode: Building the 'Embedded Web'
Sensinode is Finland-based company that is, in my opinion, an example of pioneering the above-described 'Web of Things' paradigm. They are also major contributors in the IETF for the standardization of 6LoWPAN and CoAP and they were a founder of the IPSO Alliance.
Sensinode has developed a complete commercial end-to-end software solution at the devices and backend platform sides.
The following snapshot is directly taken from their WEB product description, where more information is available.
With such a product and technology expertise, Sensinode is offering solutions right today for connected homes, lighting control and smart grid networking.
Arch Rock 6LowPAN stack/devices
Arch Rock Corporation is a systems and software company that builds innovative products and technology for wireless sensor networks. The company was founded in 2005 and is based in San Francisco, California, and was acquired by Cisco in Sep 20th 2010.
As described in this white-paper, Arch Rock was bringing an IPv6 Network Stack for Wireless Sensor Networks as early as in 2007.
Arch rock has largely contributed to standardization as well. An example is their contribution in 2008 to this "Interoperability Test for 6LoWPAN" IETF draft, together with Sensinode corporation introduced above.
As a curious example, the winery cellar of Vinton Cerf (also known as one of the 'fathers of Internet') shown in LAs Vegas CES 2013 is based on Arch Rock 6LowPAN devices and stack.
+15.13.55.png)
BTW, Vinton Cerf has actually been one of the promoters of IPv6 adoption.
I had the extremely nice opportunity to make an IPv6 Video-on-Demand demo to him long time ago as part of an event related to his "Fathers of Internet" prize in the "Principe de Asturias Awards" (Spain, 2002). Let me remind a bit those wonder years, with a picture of that moment.
+15.21.05.png)
My colleague Antonio Lucientes (@AntLucientes) also in the picture. Of course, more colleagues (@CrisisP , @AmandaAzTer , @auro74, @alien1912 and others ) were not in the picture, but at the backoffice making all the demo to work too! :-)
An Android operated LED-bulb. Google first incursion in Internet6 m2m?
In 2011 Google's I/O developers conference the Montain View company announced an demoed "a competitively priced and supremely energy-efficient omnidirectional 60-watt equivalent light bulb with a small, embedded computer chip that can be turned on and off or dimmed with your Android-equipped smartphone, laptop, or tablet".
According to this article, such an Android LED bulb was to be based on the 6LowPAN standard.
However, in this techcrunch note in 2012 they doubt if that was really to happen as a commercial product. On the other hand, this recent post in March 2013 opens the possibility of further work.
Despite of Google's strategy or plans on this regard, the fact is to develop this kind of bulb is feasible and it has been schematized by NXP manufacturer (JenNet-IP solution).
The DIY (Do-It-Yourself) way
Wanna prototype m2m solutions with 6LowPAN & CoAP? Keep on reading ...
While normally software has become a commodity available to the broad community to create solutions, devices (hardware) have been a closed realm where only large specific companies or harware savvy could prototype, test and deliver solutions. This fact has recently changed with the appearance of open hardware kits, that include powerful microprocessors for the standards of this domain, such as Arduino, shields for Arduino including myriads of functionalities, sensor motes, etc.
There is even a circuit called Zigduino based on the generic Arduino, and fully compatible with its shields, that includes the IEEE802.15.4 chipset for radio mesehed network communications.
To complete the whole picture new tiny PC-like cheap boxes have appeared in the market enabling anyone to easily develop m2m gateways. A good example is the well-known Raspberry-PI type B suitable for this applications, using a free and open linux-based OS and sold at a price of $35.
As a consecuence, nowadays prototyping and building complete m2m solutions is easier and cheaper than any other time before.
The statement above is also valid for 6LowPAN and CoAP sensor technologies, so this is my contribution as a kind DYI manual on this:
1. A first item to select is the free operating system to use in the sensors. I have checked ContikiOS and TinyOS both with lots of supported hardware platforms.
ContikiOS is programmed in C while C# used in TinyOS. There are many resources in the web to compare both platforms. In my case, I selected ContikiOS.
2. Once you selected an embedded OS, you have to select a hardware platform.
In my case, I did a first analysis with the supported Contiki hardware page.
If you like to make your own hardware you have to choose those chipsets supported by the OS and then design and create your circuit board. There are also multiple examples of boards available in the net.
If you do not feel to play so much with hardware you need to find out a provider of "motes" which are basic prototypes with some sensors onboard and often come with a USB to make tests with your PC quite easy.
Regarding ContikiOS, I found several providers. Some of them are:
- Zolertia, a Barcelona (Spain) based company, that sells Z1 motes at a very competitive price.
- Advanticsys, a Madrid (Spain) based company, selling also XM1000 motes at a good price.
- Zigduino. This is actually an Arduino clon with an IEEE802.15.4 radio meshed network chipset. If you're a fan of Arduino you may choose this one as long as Arduino shields are compatible. Another way is to add the proper radio shield to Arduino.
- Redwire, a US based company, selling the porpular and cheap EconoTag motes.
- Arago Systems, a Sophia Antipolis (France) based company, providing the wismote.
In my particular case, I selected Advanticsys XM1000 motes for my experiments. The company provides libraries for both TinyOS and ContikiOS.
3. Do not forget to buy one extra sensor or a USB gateway to connect a computer for the tests.
In my case, I use another XM1000 motes connected to a MacBook Pro, but Advanticsys provides this specific USB dongle.
4. Install a VM in your computer to compile software that will be transferred to the actual sensors.
For the Contiki OS that I use, this is explained in detail in this page.
5. Develop your software using 6LowPAN and CoAP libraries in the OS. Compile the software and transfer it to one or more sensors to perform your trials. Enjoy!
If you go for ContikiOS as well, there are some first examples provided together with the standard distro that you installed in the virtual machine.
Efficiency
The following picture summarizes a recent study with a comparison of various ways to encapsulate REST operations, mainly to compare CoAP/UDP with previous approaches.
Future Work and further analysis
There are mobile vendors that have started to consider 6LowPAN and CoAP technologies as a way to incorporate smart gadgets (measuring user heartbeats, number of steps, speed when running, etc) and even wearable computers (textiles with embedded gadgets).
The key for this approach is the implementation of 6LowPAN over Bluetooth Low Energy so devices will talk to the mobile using that (instead of IEEE802.15.4 that is not expected to be supported by mobiles in the short term).
At the same time, the mobile device that is connected to the Internet via 3G or Wifi is an ideal placeholder for the 6LowPAN gateway and even v4-v6 translator/proxy.
In such a model, gadgets offer CoAP services to the user and to external platforms. Think for instance on a heartbeat sensor that normally provides the info to our sport-training platform and that automatically sends its observations to medical urgencies whenever abnormal periodicity or intensity of heartbeats are detected.
