IPv4, IPv6, The Internet of Things, 6LoWPAN, and lots of other “Stuff”

My head is currently reeling with all of the amazing “stuff” I’ve learned over the past few days. Just in case you are new to this tortuous tale, a short time ago I wrote a column in which I mentioned that the folks at Google had recently announced something called Android@Home (Click Here to see the original column).

As part of that column, I explained how I had deduced that the wireless protocol used for the Android@Home demo was based on SNAP from Synapse Wireless. But then someone called my super-sleuthing abilities into question, causing me to pen a follow-up column that tied things down 100% (Click Here to see the follow-up column).

During my investigations, I got to chat with David Ewing, who is the CTO at Synapse Wireless. As part of our discussions, David told me in a hushed whisper that Synapse Wireless is currently working on a SNAP-enhanced version of “six-low-pan”. My first thought was “Wow, that’s mega-exciting!” My second thought was “What the heck is six-low-pan?” (I later discovered that this is written “6LoWPAN”.)

When I posed this question to David, there was a thoughtful pause while he reevaluated the depths of my ignorance, and then he was kind enough to explain things in such a way that even I can understand what’s going on.

IPv4 and IPv6
Now, there’s a lot to wrap one’s brain around here, so please excuse me while I take things step by step. Let’s start with the fact that the term “Internet Protocol (IP)” is at the core of the standards-based internet working methods of the Internet. The first version of the Internet Protocol to be widely deployed was version 4, which is known as IPv4. Everything on the Internet has to have a unique address. IPv4 uses 32-bit (four-byte) addresses, which limits the address space to 2³² = 4,294,967,296 possibly unique addresses.

Of course, these approximately four billion addresses would have seemed like an unbelievably large number in the early days of the Internet. In those days of yore, few would have imagined in their wildest dreams that personal computers would proliferate as they have and that regular folks’ homes would have their own wireless networks and contain multiple devices that required their own IP addresses.

The thing is that we are starting to run out of IPv4 addresses. As usual this has caused the “End of the World is Nigh” crowd to start running around in ever-decreasing circles flapping their arms around and generally making a nuisance of themselves. For example, we’ve started to see articles like the one on Thursday 3rd February 2011 that grimly proclaimed “The Internet Will Run Out of Addresses By Friday,” which – had it been true – certainly wouldn’t have given folks much time to prepare (Click Here to see that article).

In reality, of course, things aren’t quite as dire as the doom-mongers would have us believe. First of all there are a variety of tricks that we can play, such as having our wireless routers assign local IP addresses to the various systems in our homes (televisions, set-top-boxes, game consoles, regular tower and notebook and netbook-type computers, iPod Touch and iPad tablet-type devices…), where these local addresses aren’t visible to the outside world (this is an oversimplification, but it will serve our purposes here).

Also, those who don the undergarments of authority and stride the corridors of power have known that this was coming for a long time. The solution is Internet Protocol version 6 (IPv6), which is being deployed as we speak (don’t ask what happened to IPv5). IPv6 uses 128-bit (16-byte) addresses, so the new address space supports 2¹²⁸ (approximately 340 undecillion or 3.4×10³⁸) addresses.

The Internet of Things
First discussed by Kevin Ashton in 1999, The Internet of Things is now generally understood to refer to the concept of having uniquely identifiable objects along with their virtual representations accessible and controllable using an Internet-like structure. Apart from anything else, this requires that anything we decide to connect into the network – ranging from individual light bulbs to the most complex of systems – has a unique address.

But what addressing scheme should we use? There is now a broad consensus that IPv6 addressing should be used to assign electrical appliances and systems their own unique IP addresses. Is IPv6 sufficient for this task? Well, as one simple example, according to calculations and estimations performed by the folks at the University of Hawaii (who obviously have far too much time on their hands), if we account for all of the beaches around the world, together they contain around 7.5 x 10¹⁸ grains of sand. Thus, the addressing space of IPv6 is sufficient to give each grain of sand its own unique IP address – and to do this for approximately 5 x 10¹⁹ Earthlike worlds – so I don’t think we’re going to run out of IPv6 addresses in the foreseeable future.

Internet-level Networks
Before we proceed, I should note that the following images are high-level visualizations I’m about to throw together using Visio, so please excuse their somewhat rough-and-ready quality. Let’s start by considering a standard Internet-level network as illustrated in Figure 1.


In this case, the nodes could be regular computers and servers and other stuff (see the IPv4 and IPv6 discussions above for examples of systems you might find in your house, for example). Meanwhile, the transport mechanisms could include things like WiFi, DSL, Satellite, Cable, Ethernet, and so forth. Of course power consumption is always a consideration, but it’s typically less of a concern with larger devices as opposed to the types of nodes we see in low-power wireless networks, which are introduced in the next topic. One big point to note with regard to standard networks is that the size of the packets of data whizzing around between nodes are relatively large – they are typically around 1,500 bytes, but they may range up to 9,000 bytes or more.

LoWPANs
Now let’s consider a typical Low-power Wireless Personal Area Network (LoWPAN) as illustrated in Figure 2. This is the sort of network we’re talking about when we think of things like home automation and industrial control and suchlike. Graphically, this may look very similar to the standard network shown in Figure 1, but when we look underneath the hood things are very different.


First of all the nodes themselves are really, really small. Each node may be powered by an 8-bit, 16-bit, or 32-bit microcontroller with 64 Kbytes or more of Flash memory (the smaller the better / cheaper). The most commonly used underlying transport protocol is defined by the IEEE 802.15.4 standard. And the packets of data are only 127 bytes (they call them “octets”) in size. Sitting on top of 802.15.4 is what’s known as the wireless stack, and sitting on top of this are the applications that may be executed by the node.

There are a bunch of different wireless protocols, like ZigBee, Z-Wave, EnOcean, and SNAP. Most of these protocols are proprietary. The one that just about everyone on the planet has heard about (even if they don’t know what it is) is ZigBee. Some people are under the impression that ZigBee is an open standard, but in fact it’s owned and controlled by a consortium of companies. The end result is that ZigBee is largely designed by committee (with all of the “advantages” that implies [grin]); the various players have been accused of pushing their own special interests, and many people feel that ZigBee has evolved beyond its original mandate and has grown too complex and bloated to address LoWPAN applications.

So, the real question is, with all of these wireless protocols to choose from, why did Google end up using SNAP from Synapse Wireless for their Android@Home demo? The short answer is that it works (grin). A slightly longer answer is… well, let’s delve a little further into this morass to see what we shall see…

ZigBee versus SNAP
The first thing to note is that SNAP is more than a simple wireless stack; in fact, SNAP may be considered to be a network operating system because it includes application-layer support. Also, we should note that SNAP runs on anything from the low-power (8-bit, 16-bit, 32-bit) microcontrollers found in wireless nodes, all the way up to full-blown PCs and Linux-based systems. Figure 3 shows a very simplistic graphical representation of the differences between ZigBee and a SNAP-based wireless node.


Note that the 802.15.4 mentioned in this illustration refers to the software portion of the transport mechanism; not shown here are the hardware PHY (physical layer) and RF elements of 802.15.4, which may be implemented as a separate device or – more recently – on the same chip as the microcontroller itself.

We should also note that both ZigBee and SNAP can implement a wide range of network topologies, from simple point-to-point, through line, ring, star, and tree, all the way up to full-blown mesh networks. Having said this, there are a number of key differences between the ZigBee and SNAP implementations. Perhaps the most obvious is that the ZigBee stack is greater than 64KB, which means designers have to move to a microcontroller containing 128KB or more of on-chip Flash memory.

By comparison, the SNAP network operating system – which encompasses the SNAP stack and the SNAPpy virtual machine (the name “SNAPpy” is derived from “SNAP” and “Python”) – has an extremely low footprint of only 40KB, so even a low-cost microcontroller with only 64KB of Flash has 24KB left over in which to store the node’s applications.

Actually the memory footprint disparity between ZigBee and SNAP is even more acute than shown here. This is because ZigBee applications are stored in the form of the microcontroller’s machine code. By comparison, SNAPpy applications are created in the open standard Python language and compiled into Bytecode, which is subsequently executed on the SNAPpy virtual machine. This has a number of implications, starting with the fact that Bytecode is extremely efficient – each byte of Bytecode can equate to up to 10 machine code instructions, with the result that SNAPpy applications consume very little memory.

One very interesting point is that, in order to keep network traffic to a minimum (thereby conserving bandwidth and power), SNAP provides complete support for Remote Procedure Calls (RPCs). The term RPC refers to a messaging architecture where the name of a function and its associated parameters can be bundled up and broadcast over the network (this is much more efficient than the larger, more complex packets employed by conventional LoWPANs).

Functions in SNAPpy applications can be invoked on any node by any other node or by any other device accessing the network. In addition to facilitating inter-node communication, debugging applications is greatly expedited by the fact that developers can quickly edit their SNAPpy application scripts on their host computer, download them "over-the-air" into the wireless nodes, use RPCs to invoke individual functions in those nodes, and monitor any RPCs being made by any network node.

And yet one more significant consideration is that ZigBee applications are typically created using a traditional embedded flow. This means they are captured in C/C++, compiled along with the ZigBee stack, and the resulting monolithic image is loaded into the wireless node’s microcontroller using a physical link. It also means that ZigBee applications have to be recompiled for each different type of microcontroller. By comparison, SNAPpy applications (which, as was previously noted, are created in Python and compiled into Bytecode) can be uploaded into the wireless node ”Over-the-Air”. Also, since SNAPpy applications are presented in the form of Bytecode that is executed on the SNAPpy virtual machine, this means that they will immediately run on any SNAP-enabled wireless node without recompilation.

6LoWPAN
This is where we get to the nitty-gritty – the "Crux of the Biscuit" as it were (the full quote by American composer, guitarist, singer, film director, and satirist Frank Vincent Zappa is: "The crux of the biscuit is the apostrophe." I actually know what he meant by this, but there’s no time to go into that here [and – if you happen to be a devotee of the master – before you ask, it looks nothing whatsoever like a Telefunken U47]).

So what we have, as illustrated in Figure 4, is standard Internet-level networks on one side of the metaphorical fence and LoWPANs on the other. The whole point of The Internet of Things is that we want every node in our LoWPAN to have its own Internet address. Also, that we want to be able to access and control these nodes from anywhere in the world using the combination of the main Internet running IPv6 and devices connected into the Internet like tablets, smartphones, PCs, and so forth.


Remembering that the size of the packets in the standard network can range from 1,500 to 9,000+ bytes, while the packets in the LoWPAN are only 127 bytes in size, and also that LoWPANs have lower data bandwidths and must consume only miniscule amounts of power, it’s obvious that this is a non-trivial problem.

The bottom line is that the Internet community in general – and the big players like Cisco and Google in particular – are saying that LoWPAN devices somehow need to be addressed and accessed using IPv6. The solution is an open standard known as 6LoWPAN, where the ‘6’ stands for IPv6 and we already know what LoWPAN means.

The 6LoWPAN specification describes how to take a large packet from a standard Internet-level network, to strip it down and remove a lot of the high-level complexity and redundancy, and to dice-and-slice it up in such a way that it can be handed over to the LoWPAN. Similarly, the 6LoWPAN specification describes how to take small LoWPAN packets and reformat them in such a way that they can be passed back into the higher-level network. As part of this, we are going to see 6LoWPAN wireless protocol stacks that sit on the microcontrollers in the LoWPAN wireless nodes.

Note that when I say 6LoWPAN is an “open standard,” this does not imply that all implementations will be “open source.” Just as with IPv4 and IPv6, companies will likely base products on proprietary as well as open-source stacks. The main point here is that 6LoWPAN will be driven and controlled by the IETF (Internet Engineering Task Force), which is an international standards body. This means that the functionality of 6LoWPAN will not be dictated by groups with special interests and agendas.

Thus, the current state of play is that we have existing LoWPAN wireless networks based on SNAP, ZigBee, Z-Wave, and so forth, none of which can work with IPv6. We also have 6LoWPAN, which is currently in the process of being deployed and which is designed from the ground up to support IPv6, to provide full-up mesh network topologies, to be very efficient, and have a small memory footprint.

So the answer is obvious; everyone creating low-power personal wireless area networks – including the folks at Google with their Android@Home – are going to adopt 6LoWPAN. Game over… that’s all she wrote… or is it? Consider the existing SNAP, ZigBee, and 6LoWPAN scenarios as illustrated in Figure 5.


As wonderful as 6LoWPAN may be, there remains one fatal flaw when it comes to creating and deploying applications. The problem is that, as for ZigBee, applications will have to be captured in C/C++, compiled along with the 6LoWPAN stack, and the resulting monolithic image will have to be loaded into the wireless node’s microcontroller using a physical link. In addition to requiring a lot of 6LoWPAN expertise on the part of the application developer, this also means that these applications will have to be recompiled for each different type of microcontroller.

SNAP-enhanced 6LoWPAN
Now we begin to see why the advanced tip from David Ewing about the fact that Synapse Wireless is working on a SNAP-enhanced 6LoWPAN is so exciting. Basically, what they are talking about is augmenting 6LoWPAN with the SNAPpy virtual machine as illustrated in Figure 6.


The result is the best of all worlds – the open standard 6LoWPAN wireless protocol stack enhanced by the SNAPpy virtual machine. As we already discussed, this means that applications can be quickly and easily created in Python, compiled into Bytecode, and downloaded over-the-air into the wireless node. Although it’s true that the SNAPpy virtual machine does consume some of the memory that a standalone 6LoWPAN implementation could use for its applications, this is more than offset by the fact that applications in SNAPpy Bytecode are so much more efficient in terms of their memory footprint.

One key aspect to all of this is that it forms the basis for a seamless migration from existing SNAP-based networks to future SNAP-enhanced 6LowPAN networks. This is because a SNAPpy application can be executed on any microcontroller running SNAPpy without the need for recompilation.

But wait, there’s more... Earlier I was waffling on about the fact that SNAP provides complete support for Remote Procedure Calls (RPCs), which means that functions in SNAPpy applications can be invoked on any node by any other node or by any other device accessing the network. This also means that, by means of appropriate gateways, existing SNAP-based networks will be able to “talk” with SNAP-enhanced 6LowPAN networks, thereby preserving existing investments and providing a seamless migration path into future installations.

Last but not least…
And so, I think we finally have the answer to the question as to why – given the choice of all of the existing LoWPAN technologies currently in production – the folks at Google used a SNAP-based network for their Android@Home demo. The answer is that SNAP works today and SNAPpy applications can be rapidly created, debugged, and deployed, so Google’s developers (who are also fond of Python) were able to use SNAP to get their demo up and running quickly and successfully.

Furthermore, it’s also clear why the actual real-world implementation of Android@Home will not be based on any stack that does not inherently support IPv6, because this is a key requirement when it comes to the realization of The Internet of Things.

It seems obvious to me that the future of The Internet of Things (with regard to low-power wireless networks) is going to be based on 6LoWPAN. And I think it’s safe to say that some developers will opt to use 6LoWPAN in a standalone form. But I also think that a LOT of developers are going to seriously consider the advantages of a SNAP-enhanced 6LoWPAN platform.

As always, we certainly do live in exciting times, and I for one cannot wait to see where we will be technology-wise just a few years in the future…