Constructing a framework for understanding IoT

Analysis of IoT technology, players, and capabilities

Published in

Eugene Zhelezniak

28 min readApr 1, 2017

Besides Duffield Hall, Collegetown Bagels, and evening exams, one thing I miss about college is the ease of constructing and maintaining frameworks. While execution is rarely ideal, at least in idea each successive lecture builds upon the one preceding it. The problem sets then serve to both solidify and test your understanding of the given subject.

Unfortunately, such frameworks are not readily available when you leave the college campus. This means it gets exponentially harder to cut through the noise and truly understand something. This has been the case for me with IoT, otherwise knows as the Internet of Things. The buzzword is thrown around in articles, conversations, networking events — but I still don’t understand what IoT is or what it means. So I decided to change that.

Contents & Section Links:

What is IoT?
The three variables
Possible Solutions
LPWAN and LoRa
SigFox
Ingenu
Summarizing LPWAN
Introducing Zigbee
Zigbee Pro
Zigbee IP, IPv6, and 6LoWPAN
Connecting it all together, or how in the world do you actually make it function?
Resources Used

What is IoT?

Let’s start with a story. Internet of Things is neither a new phrase nor a new concept. The phrase “Internet of Things” was coined by Kevin Ashton in 1999 as a title for the presentation he made while at Procter & Gamble. The phrase was used in a reference to employing RFID chips to help manage P&G’s supply chain — and you guessed it — subsequently connecting it to the internet. Kevin Ashton went on to co-found a research group at MIT called Auto-ID center, which among other things, created a standard for RFID.

One of the first IoT devices —for this purpose, I simply mean a device that is connected to a network— was a Coke machine at Carnegie Mellon out in Pittsburgh. In the mid 1970s, a few employees installed micro-switches to sense how many bottles of coke were present in each column and how long each bottle has been in the machine. The machine was connected to PDP-10 mainframe, the main computer at the CMU’s CS department, which when queried, would display an information that looked something like this:

>                 EMPTY   EMPTY   1h 3m
>                 COLD    COLD    1h 4m

The machine ran on a local network at CMU until 1992, when a graduate student connected the machine to the internet with a TCP/IP stack. While this Coke machine was the first network connected device, the first truly internet connected device was a toaster built for the INTEROP conference in 1989. One small toast for man, one giant leap for mankind.

So what is the Internet-of-Things? Like the toaster and the Coke machine, IoT refers to a system of computing devices that possesses the ability to send communications over a network, without necessarily requiring human interaction. A device could be a temperature gauge that alerts when a temperature rises above a set point, or a sensor that alerts when you’re running low on carbonated beverages. There are hundreds of different types of devices, and none of them are exactly the same. However, from a business perspective, there are a few key factors that differentiate a good IoT device from a bad one:

The IoT device is energy efficient. By energy efficient, people literally mean that a device can operate for years. The desired range of operation is often greater than 5 years. This isn’t as easy as just connecting a big enough battery; it is also making sure that the way data is sent and received is efficient.
The IoT device can communicate over long distances. You can have a device that measures salinity of ocean water 5 km offshore in Louisiana or a moisture sensor on a farm in a middle of Iowa— and both of them have to send and receive data. That’s hard.
The IoT device maintains good data rate and doesn’t interfere with other devices. Denial-of-service attacks are based on a network of machines flooding a particular service with more requests than it can handle. Making billions of devices operate and send data at the same time — as proposed in some Smart Cities plans— while maintaining the structural integrity of each message is difficult.

And as you may have guessed, these three factors — lets refer to them as variables — are interrelated and coupled. You can’t have your cake and eat it too.

The three variables

When you’re creating a new framework, the hardest part is asking the right set of questions — which will then serve as a guide to logically connecting pieces together.

In the case of IoT, one of these question is how do you connect a device to the internet?

To help guide discussion, lets recap the three key variables discussed above:

Variables:Power     | As the power used goes up, battery life goes down.
Range     | Good range ~ increased power ~ decrease data rate.       Data Rate | Good speed ~ increased power ~ decreased range.

And now, lets superimpose these on the technology that you may have heard of before:

We see that:

LTE has a good range and rate, but uses a lot of energy.
WiFi — based on IEE 802.11 standard — has a short range and uses a lot of power, but has a terrific data rate.
Bluetooth uses little power, but has a lackluster data rate and short range.

This is a simplistic view, yes, but it helps to motivate a question — is there a technology that we can use?

And don’t worry, it will get complicated soon enough.

Footnote:

There is a lot written about challenges of connecting M2M devices to LTE based networks. LTE uses RACH — Random Access Channel — the transport layer channel used to manage how the communication pathway is accessed by devices like your phone. The 3GPP identified RACH procedure as the greatest challenge for connecting IoT devices due to likely network overload. See more about this here.

Possible Solutions

So far, we arrived at a conclusion that the already widely available technology — LTE, WiFi, Bluetooth — is not readily applicable to IoT needs. So what technology can we use? There are a few solutions, and we will cover those in-depth below, but here are the guiding points:

LPWAN: Low Power Wide Area Networks. Multiple flavors and implementations thereof are available: LoRa, Sigfox, Ingenu, Weightless. We will cover some of these in-depth.
IEEE 802.15.4: a technical standard defined by the Institute of Electrical and Electronics Engineers (hence the IEEE). These are the people that brought you Ethernet (IEEE 802.3) and WiFi (IEEE 802.11). 802.15.4 is the standard that defines the physical and data layers in the OSI model. Companies have built proprietary solutions on top of this (i.e. — defined higher levels of OSI - network, application, security, etc). Zigbee is one of these.
GPRS: General Packet Radio Service — that functions on top of the existing 2G and 3G infrastructure. There are a number of manufactures who are making chips and transmitters available to the general public. The key issue here is sun-setting of 2G technology and poor battery life.

Other concepts that we will touch upon:

IPv6
6LoWPAN

Footnote: the OSI model — Open Systems Interconnection — can be thought of as 7 levels that define how a network operates. The PHY and Data link layers are the lowest two layers. PHY controls how the hardware reads and encodes bits from and to actual EM waves. Data Link controls how data packets are encoded and decoded into bits.

Introducing LPWAN

LPWAN stands for Low Power Wide Area Networks. It is not a standard; it is an umbrella term that encompasses various implementations and protocols. Typically, LPWAN is characterized by an extensive lifetime — 7 to 10 years — and an impressive wide area coverage (in practice, 22 km for line of sight propagation, and around 2 km in dense urban areas).

Many companies recognize just how lucrative this space is, and hence introduce their version of LPWAN. It is best to cover these one by one.

LoRa and LoRaWAN

LoRa is an alliance of companies whose members have developed both the LoRA modulation technique and the LoRaWAN standard. The alliance includes influential members like Cisco, IBM, Comcast, and Orange among many others.

It’s important not to confuse LoRa and LoRaWAN. LoRa is a physical layer of the OSI model that has been developed by the alliance in general, and Semtech in particular. In 2012, Semtech, a California based chip-maker, acquired a French company named Cycleo. Cycleo specialized on building chips that used CSS — chirp spread sequence — modulation technique for IoT.

CSS was developed in 1944 for uses in radar applications. The chirp refers to a linearly varying frequency that covers (“spreads across”) the whole frequency bandwidth in the given period T. In an up-chirp, the frequency increases with time, in a down-chirp the frequency decreases with time. CSS has some notable advantages: it is Doppler resistant, long range capable, and network scalable.

Semtech quickly became the core of the group. It also locked down what chips can be used by the alliance members. SX1272 and SX1276 chips are some of the CSS-capable chips manufactured by Semtech specifically available for LoRa applications.

LoRaWAN is an open standard that defines the MAC — media access control — or how the data is communicated within the network. LoRa alliance realized early on that the protocol and network architecture play a key role in determining the battery lifetime, the network capacity, and security — so developing LoRaWAN was a savvy step.

LoRaWAN maintains a star-on-star network topology, which means that each node — in our case an IoT device — can transmit the data to multiple gateways, which then forward the data to a central server. Because of the star-on-star topology, the packets sent by the devices have no destination address, and there is no association between between a given end node and a gateway. In the scheme, the central server is thus responsible for de-duplication and decoding of the information, as well as determining which gateway to use to communicate with the end node.

What is the format of this data ? It looks like this:

Uplink is the data sent from node to server, and downlink is the data sent from server to the node. There are whole university courses devoted to the study of just what the words in those figures mean and how they are encoded, so I will leave that up to a reader. Here is a good link for outlining exactly what is encoded.

LoRaWAN defines three classes of devices that can be used:

Class A, bi-directional (aka baseline). Class A end devices can schedule an uplink transmission. Each uplink transmission is followed by two short downlink transmission windows. The recommended receive windows are spaced out 1 to 2 seconds apart. Class A device is generally the most battery efficient.

Class A device with two receive windows.

Class B, bi-directional with scheduled receive slots (aka beacon). Class B devices allow for more receive slots at scheduled times. In order for the Class B device to initiate a listening window, it receives a time from the gateway. Medium power consumption.

Class C, bi-directional with maximum receive slots (aka continuous). The devices of this type have almost continuous receive windows, and pay for it with a maximum power consumption.

LoRa is capable of operating in various ISM (Industrial, Scientific and Medical) frequency bands, depending on the region. In the US, the central operation frequency is 915 MHz (902–928 MHz band). In Europe, the central frequency is 433.92 MHz (433.05 MHz — 434.79 MHz).

For the US, LoRa defines 64 uplink channels 125 KHz in width, spread out from 902.3 to 914.9 MHz in 200 KHz increments. Additional eight 500 KHz-wide uplink channels are defined, spaced out in 1.6 MHz increments from 903–914.9 MHz. There are eight downlink channels defines, each 500 KHz wide, starting from 923.3 MHz to 927.5 MHz.

Customers who want to use LoRaWAN can purchase and install LoRA gateways themselves. The hardware is relatively inexpensive. Currently, the monetization comes from the silicon sales (Semtech) and hardware sales (other alliance members). There are discussions around creating publicly available networks, and many companies are moving into this space quickly. Amsterdam, for instance, became the first “smart city” when it was completely covered by a LoRaWAN network. The network was built by The Things Network, a group of IoT enthusiasts. Surprisingly, only 10 gateways were used to cover the whole city (each one costing less than 1200 USD). Senet claims to have built a first LoRaWAN network in US, covering more than 100 cities. Owning these networks and thus the data that’s streamed through them is going to create a new generation of billionaires, so it’s not exactly surprising. Check out Senet’s release here.

If you’re reading thus far, you’re probably wondering just how fast LoRa can communicate. The sensitivity and throughput depend on 3 parameters: bandwidth, coding rate, and spreading factor.

Bandwidth: simply the frequency width in which the device is operating. Think of this as the width of a highway lane— theoretically, your car can be anywhere from the left edge to the right edge of the lane. For LoRaWAN, depending on the region, it is one of the following (in KHz): 62.5, 125, 250, 500.
Coding Rate: in very simple terms, it is a portion of the data stream that is useful (engineers introduce redundancies to data to make sure it is still readable in case of errors and noise). For LoRaWAN, it is a following set: {4/5, 2/3, 4/7, 1/2}
Spreading factor: in simple terms, how many pulses it takes to transmit one symbol. For LoRa, the set is: {7,8,9,10,11,12}.

Semtech provides tables as far as data throughput, but the speeds can theoretically range anywhere from 0.24 kbps to 37.5 kbps.

Security on LoRaWAN is a key question, and is complicated one as well. LoRaWAN uses AES128 — Advanced Encryption Standard with 128 bit key length. The encryption requires both the network and application key (NwkSKey and AppKey). The network key is used for network layer security, while the app key is used for application layer end to end security. The AppKey is assigned by the owner of the application layer, and is only known to the application owner. A version of the key is stored in the device and the server that will perform authentication.

The NwskSKey is a network session key specific to each device. It is shared between the network server and an end device, and is used to verify the Message Integrity Code that is attached to each message. Read more about LoRaWAN security features here.

Putting all the pieces together, the full LoRaWAN network would look something like the image below:

Note that gateways are TCP/IP connected (so they can upload / download at considerable speeds). We will cover an example showing how to connect the IoT network to a server and to an application later. The network-application part is relatively easy — there are hundreds of different companies offering cloud connector services.

SigFox

SigFox is a French company based in Toulouse, France. It was founded in 2009. Like LoRA, SigFox falls under the LPWAN umbrella, although the technology at the core of SigFox is a little different. Unlike LoRA, however, SigFox is a private company; this means that the amount of information available about it is naturally limited. In particular, SigFox allows chip manufactures to make their own radios that are compatible with SigFox stack; the protocols (i.e. — Data Link layer and higher) to use these radios, however, are proprietary.

Why proprietary? SigFox operates on a fundamentally different business model. It positions and markets itself as an all-in-one approach. Instead of purchasing your own gateways and maintaining a private LoRaWAN network, SigFox uses its own series of base stations to connect the IoT devices. Like in a cellular network, there is no negotiation between nodes and gateways; any gateway — in practice the closest one — can receive and verify the message. The base stations relay the data to the SigFox back-end server via TCP/IP and other speedier protocols. Various cloud connectors are then used to extract your data from the server, like you would with any other cloud application. Think of SigFox as your phone; unless you pay Sprint or your sub-par provider of choice, it’s not much of a phone.

SigFox says that customers only need 3 things to get started:

Be in a coverage area
A SigFox subscription
SigFox powered IoT device

Since SigFox operates like a cellular network, it shouldn’t be surprising that the network topology is very similar to other LTE networks. Such topology is referred to as LTN, and you can read more about it here.

SigFox uses ultra-narrow band modulation in the bandwidth of around 100 Hz. Compared to the narrowest LoRa channel, the 100 Hz channel is 1250 times narrower. The technology has not been invented by SigFox; it has been in development more or less since at least 1985. It claims to send a relatively large amount of data very slowly, thereby allowing the nodes to remain extremely sensitive (detecting messages of lower power than LoRa).

Thanks to UNB, SigFox is able to maintain extraordinary range. In rural, line of sight settings, the range is anywhere from 30 to 50 km. In dense urban settings, the range is anywhere from 3 to 10 km. This is significantly more than LoRa. Physically speaking, the narrower the channel, the less noise is present, and the less costly it is to filter that noise out — hence the higher sensitivity.

Increased sensitivity comes at a cost. The key limitation of SigFox is the amount of data it can send; devices are typically limited to a maximum of 140 messages of 12 bytes. In other words, a SigFox device can send a maximum of 1 message every 11 minutes. Is this a bad thing? Not necessarily; SigFox argues that this is more than enough for most IoT applications (the table on the left can be used as a rough reference point). For now, keep in mind that it doesn’t have to do with SigFox per se; it’s a product of government regulation over certain frequencies. If you want to learn more about this, look into Duty Cycle regulations here.

With this limitation in mind, Sigfox currently offers a four-tiered plan to its customers:

Tier 1: 101 to 140 uplink messages ; 4 downlink
Tier 2: 51 to 100 uplink messages; 2 downlink
Tier 3: 3 to 50 uplink messages; 1 downlink
Tier 4: 1 to 2 uplink messages ; 0 downlink

What does the data format look like in SigFox? The data transmitted in SigFox systems carries the following form (here in the MAC layer view):

The key thing to remember is that the payload in a SigFox transmission is 12 bytes, and the overall frame (i.e. — the whole message with all identifiers) is 26 bytes. In context, compare this to IP stack, which uses 40 byte frames to deliver a 12 byte payload.

In Europe, where SigFox is significantly more popular than the US, the company operates in the ISM band. The uplink frequencies are divided in 100 Hz channels, from 868.180 MHz to 868.220 MHz. There are 400 channels packed in here, of which 40 are currently unused. SigFox base stations listen to all of the channels in the band, so in practice an end node can transmit the message on any channel. Why have so many channels? SigFox historically had some issues with reliability, collision detection and evasion (read — SigFox has none). Thus, the protocol is going to frequency-hop across the band to avoid collisions and comply with regulations.

Maximum transmission power in the band is capped at 25 mW. For downlink, the frequency range from 869.4 to 869.65 MHz is used, the channel width is dynamic. In the United States, the central frequency used is 902 MHz, but the principles stay the same.

How quickly can SigFox transmit data? The frequent estimate quoted is 100 bits/s = 0.1 kbit/s. This is at least an order of magnitude smaller than LoRaWAN. The SigFox argument is that this is plenty for IoT applications. Likewise, more studies need to be done with SigFox modules in motion. While LoRA is Doppler resistant due to CSS, the significance of impact on SigFox requires further analysis.

Last but not least — security. SigFox is significantly less secure that LoRaWAN. It uses 16 bit. Each device on a SigFox network has a unique id, and each message possesses its own message authentication code. The combination of the two is used to verify that the given device did indeed send a specified message, and that the message has not been tempered with.

Ingenu

Formerly known as On-Ramp Wireless, Ingenu is a California based company founded in 2008. The company has received significant attention, and is among the top 10 most valuable start-ups in the IoT space. The company has origins in the oil and gas industry; in fact, San Diego Gas & Electric currently uses Igenu technology for its network of sensors.

Like SigFox, Ingenu is a private company. The technology is proprietary, meaning that unless you go through Ingenu or its approved manufacturers you cannot get your hands on a chip capable on encoding/decoding it’s proprietary RPMA scheme. For example, in September of 2016, Ingenu paired up with U-Blox, a Swiss semiconductor and wireless module manufacturer. U-Blox will be building the transceivers, and likely reselling them directly to other companies and the public. A full device library is available here.

Ingenu appears to be following a route that is similar to what SigFox is working on. Ingenu has shown that it is developing private networks and is also building a publicly available network called the Machine Network. There are currently 38 private networks (San Diego Gas & Electric is a private network). The Machine Network is like a cellular network, but running on Ingenu’s RPMA technology. Ingenu will sell you their proprietary radio module and will then collect a certain fee for the use of their networks; this is a cellular model, IoT edition.

Current coverage of the Ingenu’s Machine Network.

In practice, the network will look something like the image below. The sensors and actuators are connected via RPMA to access points. Access points themselves are connected to the internet via other speedier protocols. The customers can use cloud connectors to pull their data from Ingenu’s servers.

What exactly is Ingenu’s technology? Ingenu holds 32 patents around what it calls Random Phase Multiple Access, or RPMA for short. RPMA is a Direct Sequence Spread Spectrum (DSSS) waveform, and servers as Ingenu’s PHY layer. Long story short, the DSSS scheme operates on the phase of the wave, continuously changing it according to some pattern (often but not always pseudo-random — notably the Gold Sequence is used in RPMA). The receiver knows this sequence , and is thus able to decode the message.

In practice, you can visualize RPMA using this picture, where the start of each wave is delayed according to a sequence:

In such scheme, the access point (the gateway) is always listening. Since the access point and the node do not agree on the uplink/downlink, the basic assumption is any incoming message could contain a payload. The access points thus employ multiple demodulators. The details are complicated, but Ingenu claims that through the process each access point can support more than 1000 fully overlapping signals — in a single time slot.

On a downlink, Ingenu uses CDMA. This is called link asymmetry (i.e. — downlink and uplink are not employing the same scheme). Taken as a whole, the network topology is a star (i.e. nodes connect to an access point, and there is no ability for inter-node communication). With an extender, the topology can be converted to a tree network.

Ingenu is working hard to standardize it’s approach. Hence, it is an advocate for 802.15.4k standardization, which seeks to define DSSS and FSK modulation scheme for the PHY layer. There is a lot of movement in the space of IEEE standardization; in fact, Ingenu’s approach falls under the umbrella of 802.15.4 categorizations. We will discuss this later.

RPMA has some exciting characteristics. Apparently, Ingenu is capable of transmitting data at a distance of up to 200 km in line of sight setting, and an estimated 10 km in urban setting (estimate using the Hata model). Ingenu reports that it has achieved speeds upwards of 624 kbps on upload, and 156 kbps in download. The speed does drop when in motion; some sources quote that the data rate in these circumstances averages 2 kbit/s.

Ingenu claims you only need 500 access points to cover the US.

Ingenu operates in a 2.4 GHz band, and defines 40 channels, each one 1 MHz wide. The channels are buffered (i.e. have a cushion) of 1 MHz on each side of the central frequency. There are a few benefits to using 2.4 GHz band — it is free, and available internationally. This means that the infrastructure doesn’t need to change depending on the region and frequency band. Apparently San Diego Gas & Electric operates their whole network covering 4100 squared miles on only 1 MHz of bandwidth, thus 40 channels appear to be more than enough for IoT purposes.

Security wise, RPMA offers two-way authentication and either 128 or 256-bit encryption. In essence, this means that a message sent contains extra 128/256 bits = 16/32 bytes, that create a digital signature and secure the payload. Thus, similar to LoRaWAN, Ingenu guarantees message integrity.

Summarizing LPWAN

The key lesson to extract from the section above is that LPWAN is an umbrella term, and there are many flavors — some open and some proprietary. I only sought to cover a few of the largest players in the field. Other players include Weightless (W,N,P flavors) and Dash7.

Introducing Zigbee

Many years ago, a group of engineers from the IEEE decided that it must meet in order to define ground rules around what is called low-rate wireless personal area networks. The group —whose name is IEEE 802.15 — was motivated by the limitations of cellular networks for machine to machine communication. Factors like range, coverage, energy use, and data rate come to mind. Their work culminated in a definition of a standard IEEE 802.15.4, which was completed in 2003.

After the standards were proven, a lot of companies wanted to reuse and recycle this knowledge — after all, if IEEE 802.11 (aka WiFi) is so extremely successful, maybe 802.15.4 will be as well? Thus, the Zigbee Alliance was born. While the actual story is more complicated, the important thing to understand is that at the core Zigbee runs on 802.15.4. The alliance is comprised of over 300 semiconductor manufacturers, OEMs, software companies, and others. Comcast, Huawei, Kroger, Philips, and Texas Instruments are some of the largest and most notorious members.

IEEE 802.15.4 defines the two bottom layers of the OSI stack — the PHY and the Data Link layer. The PHY stack was (and for the most part still is) based on Direct Sequence Spread Spectrum (DSSS; recall that RPMA is based on this too). As a reminder, unlike AM and FM modulation where the transceiver uses the amplitude and the frequency to encode information, DSSS encodes information with phase changes. DSSS scheme varies the phase the according to some pattern. The receiver knows this sequence , and is thus able to decode the message.

802.15.4 defines three operational frequency bands: 2.4 GHz worldwide, in addition to 868.3 MHz band in Europe and 902–928 MHz band in the US. The channels are further defined as follows, each one 5 MHz in bandwidth:

16 channels spaced out between 2.405 and 2.480 GHz; achievable data rate of 250 kbps.
1 channel centered around 868.3 MHz; achievable rate of 20 kbps.
10 channels sandwiched between 902–928 MHz; achievable rate of 40 kbps.

The image below — although cluttered — demonstrates the channel distribution around 2.4 GHz:

At this point you’re probably wondering where Zigbee comes in. Zigbee builds on top of the PHY and Data Link layer, developing the network topology, security features, and the way the application interacts with the rest of the stack. The Zigbee alliance released its first specification in June of 2005. Here is a graphical depiction of where the 802.15.4 starts and Zigbee begins:

The IEEE does not provide or lock users into any specific network topology; Zibgee, therefore, designed its own — and it’s pretty diverse. Zigbee supports star topology, tree topology, and mesh topology. This does depend on the type of Zigbee device used, so lets cover these first:

Zigbee End Device (ZED): the most battery efficient Zigbee device of all. A ZED can send and receive data to and from higher level devices (routers and coordinators). ZEDs cannot natively communicate with other ZEDs. An end device has superb battery life in part because it is in sleep mode majority of the time.
Zigbee Router (ZR): a higher level device that can receive data from end devices and pass it to other routers, nodes, or higher level devices. It has more memory and computing power compared to a regular end device.
Zigbee Coordinator (ZR): the most sophisticated device. It has the most memory, and thus uses the most battery. It is capable of communicating with any device, receiving and sending data from routers, end devices, and other coordinators.

Now lets move to the topologies. Star topology is the simplest topology of all — the end nodes communicate with a coordinator type device.

In a tree topology, the networks are scaled by device type — in other words, end devices communicate with routers, and routers can communicate with coordinators. The end device, however, doesn’t have direct access to ZC — it must go through ZR.

Lastly, in the mesh network, routers can talk to other routers and coordinators. Likewise, coordinators can talk to other routers and coordinators.

The mesh network is a powerful tool in Zigbee’s arsenal. End nodes are reduced function devices, and thus they naturally will not send out a signal with a lot of power to conserve their battery. Using a mesh network, the end node just needs to reach the closest gateway, which can then relay the data to other gateways and coordinators, sending the signal far beyond the reach of the node. Mesh networks are a natural solution for a lot of applications — asset tracking, inventory control and management are just some of these. Zigbee addressing scheme is capable of supporting more than 64,000 nodes on a network (i..e — per coordinator device). But multiple coordinators can be linked up, establishing massive super-networks in size. The catch here is that mesh networks for Zigbee aren’t a perk — they are more of a requirement. A node can only achieve a range of 10 to 30 meters (compare this to kilometers for LPWANs). Thus, you need a mesh topology to make network communication effective.

In practice, mesh networks are called “self-healing” because there are no preset paths to get from A to B (the routing is done using AODV — Ad Hoc On Demand Distance Vector). For instance, if a node normally communicates with a coordinator B through gateways C, if C fails and gateway D is within range, then A can reroute through D to connect with B.

Like LoRaWAN, Zigbee has a number of security features. The security is implemented on the Network and Application layers. The Network key is used to protect the messages inside a network. An AES 128 bit key is used to verify that a device is a member of the given network. Zigbee’s Application layer key is known as a Link key, and is responsible for securing the message frame. Read more about security of Zigbee networks here.

Zigbee radios and devices are relatively inexpensive. However, to manufacture Zigbee-capable technology, you need to be a member of the alliance — and that’s harder. Zigbee Qualification Process involves a full validation of the physical layer of the developed device, which can take a long time. Furthermore, each individual device must have a battery life of at least 2 years to pass the certification. Zigbee imposed these standards because there were concerns about the stringency of the standard; a common critique is that manufacturers label their transceivers as Zigbee compatible when in fact they are not.

For completions sake, I am also including the data frame format that is used to transport data on the Zigbee capable network. The most important lesson to extract here is the variable size of the payload (i.e. — it is application set):

What’s the business proposition for Zigbee? The more standardized the Zigbee format becomes, the more Zigbee enabled devices can be built and sold. And the more devices are sold and installed, the more widespread the standard becomes. It is a self reinforcing cycle; in this sense, Zigbee and LoRa alliances are rather similar.

Zigbee Revamped

Zigbee Pro

In 2007, the Zigbee alliance ratified an amendment that updated its standard. The result is now known as Zigbee Pro. What exactly did an update do? A few things:

Enhanced functionality
Stochastic addressing
Upgraded security

While Zigbee and Zigbee Pro are compatible, if a network is initially established as Zigbee then the Pro devices can only function as end nodes. Similarly, if you establish a Zigbee Pro network, then the Zigbee devices can only function as end nodes.

In 2012, another series of updates introduced Green Power. Green Power devices create their own kinetic power by converting extraneous heat, light and vibrations into an energy source. Green Power devices don’t need batteries — which is a great selling point for large facilities like malls and campuses, where battery maintenance and upkeep for thousands of devices would be both expensive and time consuming.

Zigbee IP, IPv6, and 6LoWPAN

In 2013, Zigbee introduced a version it called Zigbee IP. This newer version of Zigbee utilizes a compressed version of the IPv6 protocol. Why is that important? Most of the current infrastructure — your computer and phone included — runs on IPv4, short for Internet Protocol Version 4. The internet protocol is a huge part of the success behind the widespread adoption of internet.

Unfortunately, IPv4 is inherently limited in numbers. Only 2³² addresses are available (it’s a 32 bit field, and each field can be occupied either by a 0 or a 1). Seems like a lot? Not really; it’s actually just slightly over 4 billion addresses, and given that there are already over 7 billion people on the planet we’re going to hit that limit sooner or later (it is important to note that technology like NAT — Network Address Translation — has helped to slow how many unique addresses are occupied at a given time). The updated version of IP, IPv6, has 2¹²⁸ addresses available — each atom in your body can get a unique address many million times over. We are currently in the midst of migrating from v4 to v6.

Long story short, many people believe that the internet protocol could and should be applied to even the smallest devices. Why? There isn’t one concrete answer to this question, but basically the story is: we can and we might as well, since sooner or later we will want to grant direct internet access to these devices anyway. The problem is it’s not that easy. IPv6 in it’s pure form is clunky. It is not optimized for low power communication and is verbose due to heavy metadata and headers.

Pushing IPv6 over a low power network is akin to pushing an elephant through a mouse burrow

So a compressed format was developed, called 6LoWPAN (IPv6 over Low power Wireless Personal Area Network). The protocol is based on IPv6, but compresses the header and the frame that is used for data transport. It’s essentially a modification of the Data Link layer.

Zigbee saw the threat from the idea of IPv6 implementation and 6LoWPAN. In essence, Zigbee IP is a Zigbee’s take on implementing IPv6. Zigbee IP is still backwards compatible and now has upgraded security.

Connecting it all together, or how in the world do you actually make it function?

Okay, so lets assume you read everything that I wrote above. How do you put all of this together? If you are a company, where do you start?

One of the best ways to scale is by selecting a provider that sells sensors with the technology of your choosing. There are a lot of manufacturers out there who make sensors functioning with Zigbee, Z-wave, LoRaWAN, etc. Let’s go through an example of one.

Libelium is a Spanish company specializing in manufacturing end-nodes (i.e. sensors) and gateways compatible with almost any technology out there, including LoRaWAN, Zigbee, WiFi, 4G — you name it. Until one or two standards become dominant in the field, it makes sense for manufacturers like Libelium to cover all of their bases. Their main lines include Waspmote and Waspmote Plug & Sense. Libelium calls these two devices “wireless sensor platforms”. In more mainstream terms, the sensors, once deployed, get connected to either Waspmote and Waspmote Plug & Sense. These “platforms” will then forward the information to a gateway. That is, they are a multi-sensor forwarding devices.

What kind of sensors are available? A wide variety:

Gas sensors
Humidity sensors
Luminosity sensors
Liquid presence probe
Liquid level probe
Liquid flow probe
Hall effect probe — magnetic field detection
Solar radiation probe
Soil temperature probe
Soil moisture probe
Dentrometer probe — measuring trunk, stem, diameter of vegetables and fruit
Leaf wetness probe
Weather station probe — wind direction, wind speed and rain monitoring

The sensors look like this (here they are connected to a variation of Plug & Sense platform):

Smart Water module with three sensors attached

Okay, so far so good. The Waspmote collects the data, and sends it over to a gateway. Libelium markets Meshlium as its gateway of choice. The way that this informaiton gets routed is through the protocol of your choosing (assuming Waspmote supports it). You can use either LoRaWAN, SigFox, 4G, etc. The method you choose will obviously affect the range, data rate, as well as battery life of the node. Here is picture of the Libelium gateway, Meshlium:

You don’t have to use Meshlium — any gateway that supports a particular networking protocol will work. Putting it all together, the full IoT network would look something like this:

Note that here you have a LoRaWAN network running on a non-Libelium made LoRaWAN gateway.

Libelium will allow you to store the data and integrate it with third party cloud servers — Amazon, IBM, Telefonica, ThingWorx are some of them. You add the account info, synchronize the data, and you’re on your way with a full-blown IoT system. Congrats!