The wireless standards zoo
When it comes to the Internet of Things (IoT), there is one thing that everyone seems to agree on: it has to be wireless. Consensus, however, seems to stop right there. There is currently a plethora of wireless standards, with an increasing rate of new arrivals, all bearing the promise of wireless connectivity solutions for applications including home and building automation, smart energy grid monitoring, industrial control, security systems and many others.
“But wait”, I can hear some of you say. “Hasn’t humanity once and for all solved its wireless connectivity issues with WiFi?”
Not exactly. I will outline the reason why in the next section.
Why not WiFi?
It is true that in most people’s minds, wireless equals WiFi. After all, good-old reliable WiFi trivially lets us connect our smartphones, laptops and printers, can’t it do the same for our sensors and home automation products? Well, of course it can! In fact, many cool products in our ICT-WG, like the Koubachi indoor plant sensor or the Sonos sound system rely on WiFi.
Unfortunately, WiFi comes with certain limitations. It is a Local Area Network (based on the IEEE 802.11 protocol family) designed with internet connectivity in mind and mainly operating within the 2.4 GHz band, which on the one hand allows for a rapid exchange of data (a 20 or 40 MHz bandwidth per channel can yield hundreds of Mbits/s) but on the other hand it limits connectivity to only a small range from the Access Point. Even inside the same apartment there can be spots with low coverage, owing to high absorption from walls, doors and other obstacles as well as effects such as multi-path propagation. Needless to say, this rules out most long-range IoT applications beyond home automation, but even within the context of the latter, an enthusiastic gardener wanting to use Koubachi or any other WiFi-based sensor system to keep track of their garden in the backyard might be sorely disappointed.
Another important consideration regarding IoT systems is power consumption. And WiFi doesn’t fare well on that one either.
In fact, because of implementing the entire TCP/IP stack for internet connectivity, WiFi requires a fair amount of processing power and memory, which together with exchanging and processing large data packets, results in complex, expensive and power-hungry modules. One can therefore understand all too well why many manufacturers of IoT systems, most of which are battery-based and have only modest bit rate requirements, would opt for other solutions.
Of course, the good people of the Wi-Fi alliance are fully aware of these issues. In response, they have announced the new IEEE 802.11ah standard, expected to be finalized possibly within 2016, with the first products hitting the market shortly thereafter. The new WiFi standard, operating at frequencies around 900 MHz, aims to support a range of options, from a throughput of 150 Kbits/s with a 1 MHz wide band to as much as 40 Mbits/s over an 8 MHz band. Being a “sub-Gigahertz” standard, it’s also expected to cover distances 50% longer than those of 802.11n products. These features will probably render WiFi an attractive solution for home and building automation systems, especially when considering that no additional hubs or base stations, other than the ones used to provide internet connectivity, will be required in order to hook up these systems. So why not WiFi indeed…
What else is out there?
Even if WiFi 802.11ah eventually manages not to arrive too late, its core limitations with respect to power consumption, range and complexity will remain. So which other wireless connectivity solutions are available in order to cover the IoT needs that WiFi cannot? In a word, lots! So many, in fact, that I cannot hope to even briefly outline them here (for example, there is more than a dozen “standards” contesting the “sub-Gigahertz” regime). I will only very concisely present the ones which currently have a strong presence and/or the ones experts consider to be the most likely to define the future of IoT. I will also refrain from covering cellular standards, although they can have an important role in the so-called “Machine-2-Machine” business, as well as Bluetooth (including Bluetooth Low Energy), which apart from dominating the personal accessories field and providing short-range connectivity for keyboards, printers, TV sets etc, it has also moved on to tackle IoT applications such as industrial sensor monitoring. So, let us begin with the currently most popular low-power networking protocol for IoT:
ZigBee
Interestingly, the weird-sounding name actually does have to do with bees. It was inspired by the zig-zag dance that bees perform in order to communicate the whereabouts of food. And just like bees hopping from flower to flower, data packets hop from node to node in multiple directions and paths throughout large scale ZigBee networks. For, you see, ZigBee doesn’t follow WiFi’s star topology (see image below), but a mesh network topology instead, where each node can be directly connected with each other. This way, devices don’t all have to be within reach from a central access point, they just have to “see” any one node connected to the network. Each node in the system acts both as a wireless data source as well as a repeater. The gateway participates as one of the nodes in the ZigBee network and it additionally runs a TCP/IP stack and application over Ethernet or WiFi to connect the ZigBee network to the Internet.
While it supports the 868 MHz (Europe) and 915 MHz (USA) ISM bands, ZigBee mainly uses the globally standard 2.4 GHz ISM frequency band. This means that hardware is not country specific and can be used anywhere. It also means that it can be subject to pretty intense interference from both WiFi and Bluetooth systems. Similarly to WiFi, ZigBee suffers from range issues in this band – however, thanks to the mesh topology, adding intermediate nodes (i.e. devices running ZigBee) can render this an issue of little significance for many applications.
Inarguably, the most prominent advantage of ZigBee is its capability to maintain very long sleep intervals and short operation phases (duty cycles), which allows devices to be powered by coin cell batteries for years. It was designed as an “assemble and forget” protocol (meaning that once you set it up, it can last for months). New ZigBee devices coming to the market can even make use of energy harvesting techniques for battery-less operation. Low power consumption, coupled with a maximum throughput of 250 Kbits/s, have made ZigBee a favorite in the fields of home automation, urban smart grid controllers, security systems, Heat-Ventilation-AC control. The lamps (Philips hue) lighting the room in which I am sitting right now are connected over ZigBee.
ZigBee is an open standard defining the higher networking layers on top of the IEEE 802.15.4 link layer and is maintained by the ZigBee Alliance, which runs certification programs ensuring interoperability between devices – at least in theory. Sadly, products from many wireless manufacturers using ZigBee are not actually interoperable, due to several reasons (but mainly because each manufacturer wants to give their distinct “flavor”). This is somewhat embarrassing for something that wants to be called a standard and is certainly off-putting for people buying products in the hopes that they will be able to “talk” to each other. The ZigBee Alliance is currently working on this problem and promises that future products wearing the “ZigBee Certified” logo will be fully interoperable. Let’s hope they will succeed.
Z-Wave
Similar to (and a direct competitor of) ZigBee, Z-Wave is a mesh network specification relying on the IEEE 802.15.4 low-rate personal area network protocol for a unified physical layer, structuring packets and creating MAC (Medium Access Control) schemes. It can offer data rates up to 100 Kbits/s. Unlike ZigBee, it only supports sub-Gigahertz bands, (915 MHz in Europe and 868 MHz in the US), which means that products purchased or developed in different zones worldwide will not be interoperable. However, given each band, “Z-Wave certified” devices are guaranteed to co-operate.
This high interoperability is mainly based on the fact that unlike ZigBee and WiFi, Z-Wave is a proprietary specification made and licensed by one company, Sigma Designs, which has been able to tightly control how Z-Wave products communicate with each other. However, some manufacturers fear that its proprietary nature could eventually give Z-Wave the necessary weight to keep prices high and control what products are allowed to do and they have therefore been reluctant to embrace it. In fact, many experts believe that proprietary “standards” in the long run will not be able to survive against industry accepted international standards.
6LoWPAN
Far from being a graceful acronym, what the “IPv6 over Low power Wireless Personal Area Networks” lacks in grace of name it makes up for in versatility. It can operate in the 2.4 GHz, 868 MHz and 916 MHz ISM bands and has been designed to enable the smallest devices with limited processing ability to transmit information wirelessly using an internet protocol. Building both on the advantages of 802.15.4 (mesh network topology, large network size, reliable communication and low power consumption) as well as the benefits of IP communication, 6LoWPAN allows devices residing in different networks to communicate via the Internet as long as they use the same application protocol. 6LoWPAN devices are also able to communicate with any IP-based servers or devices on the Internet, including WiFi and Ethernet devices.
The standard is fairly new but has gained almost instant traction after its adoption by Google/Nest as part of the Thread Group (yet another standardization body). Although it is competitive to ZigBee on the network layer, there is still no comprehensive 6LoWPAN standard for the entire protocol stack, as it only defines an efficient adaptation layer inserted between the 802.15.4 data link layer and the TCP/IP stack. This thankfully leaves room for co-operation on the application layer. Indeed, recently (2 April 2015) the two groups (ZigBee and Thread) announced that they collaborate to aid development of connected home products, an agreement that paves the way for the ZigBee Cluster Library Application Protocol to run on Thread networks. Experts herald this as an important development and the future currently looks particularly auspicious for 6LoWPAN.
LoRaWAN
What do all the above connectivity technologies have in common?
Limited range, for one. But what if the “smart things” we want to connect are spread over a really wide area? Sensors used for collection of meteorological and scientific data of all kinds, asset tracking, irrigation management and control, parking and facility management and large scale industrial monitoring are all application examples.
Enter LoRa, a physical layer wireless protocol based on a unique modulation format best described as a “frequency modulated (FM) chirp”, which allows for connections in a range of many kilometers. LoRaWAN, the corresponding Medium Access Control (MAC) protocol, is the low power, wide-area network global standard for carrier-operated networks, adopted by the LoRa Alliance (there is also a smaller scale LoRa-based protocol called Symphony Link, which extends IEEE 802.15.4). The network topology is a star-of-stars, while the frequency bands used are the aforementioned sub-Gigahertz 915 MHz in Europe and 868 MHz in the US.
When I first heard of LoRa, one question immediately jumped to mind: Given the kilometer-wide range, how can interference be avoided? Answer: with difficulty! The extraordinary range is not the result of sorcery – rather, it comes at the expense of data rate: the bit rate is limited between less than 1 Kbits/s up to a theoretical maximum of 50 Kbits/s, being in direct trade-off with range. The downlink latency ranges from 4 up to (theoretically) 120 seconds. Communication between end-devices and gateways is spread out on different frequency channels and data rates. Different data rates do not interfere with each other and create a set of “virtual” channels, increasing the capacity of the gateway. Still, because all of the channels are tuned to the same frequencies, LoRaWAN isn’t very suitable for private network solutions. In order to avoid collision problems, it is a better fit for public wide-area networks and it’s better to have only one network operating in a single area. Because all of the gateways in a network are connected to the same server, it’s the server’s job to decide which gateway should respond to a transmission. In a large network, any given transmission is typically heard by multiple receivers, and the server then tells one gateway to respond and the others to ignore the transmission. This process helps to avoid downlink and uplink collisions, because a single gateway is transmitting, and the gateways that are overlapping can simply listen for other transmissions.
To sum up, LoRaWAN is a great choice for wide range, low power solutions, best used to build on carrier-owned and operated public networks. Swisscom has been part of the LoRa Alliance since January 2015 and has initiated pilot networks in Zurich and Geneva as of April 2015. During the Swisscom IoT Hackathon, which took place between the 6-8th November 2015 in Zurich and which I happened to attend, teams presented innovative LoRa-based systems in fields like patient monitoring, transportation, security and asset management/leasing. On my part, the sudden interest in wireless standards isn’t exactly coincidental either: our first project in the frame of #P365d involves connecting a mailbox located far away from our apartment on the 4th floor. Guess which protocol we are using to achieve that.
Conclusion
From the above discussion it becomes evident that there are multiple wireless standards competing in many application fields and on several hierarchy layers. Some have clearly overlapping or antagonistic roles, while others can be complementary. The broad and fuzzy nature of IoT itself is partly to blame for this situation – there isn’t even a common definition of what the “Things” in the IoT might be. How can we expect light bulbs to comply with the same standards as pacemakers? At least in the forseeable future, no universal IoT standard seems likely to establish itself as “the one”. In fact, a few experts claim that it might be too late to impose any standards at this point, or that these become increasingly irrelevant since there are technologies like IFTTT (which I personally use to control the lights from my LG Urbane smartwatch) and SmartThings, bridging incompatible technologies together. Of course, others disagree and deem coalescence around a single standard per application area as essential for future progress.
Whether there is going to be an all-out industry war or some sort of reconciliation, only time will tell. The victor will ultimately be determined by market dynamics and politics. Until that time comes, system developers, service providers and users alike have to continue making choices depending on the individual needs of each specific application and hope for the best.
Sources:
[1] http://www.link-labs.com/
[2] http://www.eetimes.com/document.asp?doc_id=1319364
[3] http://www.theverge.com/2014/1/24/5336104/smart-home-standard-are-a-mess-zigbee-z-wave
[4] http://www.newelectronics.co.uk/electronics-technology/wireless-iot-connectivity-which-standards-can-be-used/74705/
[5] http://www.greenpeak.com/Press/PressKit/2015GreenPeakWhitePaperIoT&CommStandards.pdf
[6] http://www.ti.com/lit/wp/swry010/swry010.pdf?DCMP=ep-con-wcs-cmtech&HQS=ep-con-wcs-cmtech-hpb-whip-en
[7] http://techbeacon.com/state-iot-standards-stand-big-shakeout
[8] https://www.lora-alliance.org/
[9] Image from: https://www.fiware.org/