Connecting Networked Devices

Chapter 1. Where Does Your Product Sit?

The dot-com revolution happened in part because, for a few thousand or even just a few hundred dollars, anyone could have an idea and build a software startup. Today, for the same amount of money, you can build a business selling goods or software, and both your product and the process by which you develop it are augmented because devices and people can communicate and connect across the globe.

Project Requirements

Everything begins with how users will interact with your device, and how it will interact with both them and the network. In other words, where will your product sit in the hierarchy of connected devices?

Local, Edge, or Cloud?

In general, connected devices can be roughly split into three broad categories: local devices, edge devices, and cloud-connected devices.

Local devices don’t have the capability to reach the Internet, but they are still connected in a network. This network usually isn’t TCP/IP based. For instance, both ZigBee and Bluetooth LE devices are good examples of network-connected things that operate locally rather than directly connected to the Internet, and illustrate the two types of local networking. In the case of ZigBee, the device operates in either mesh or peer-to-peer mode, with packets hopping between devices until they reach a gateway on the edge of the local network. In the case of Bluetooth LE, the device operates in either paired or broadcast mode, with messages being picked up directly by a device on the edge of the network.

Edge devices typically have multiple radios, and operate in both local and connected modes—for instance, utilizing ZigBee or Bluetooth LE to talk to a local non-TCP/IP network, but also fully supporting a TCP/IP connection to the outside world. They act as a bridge, or gateway, between a local network and the outside world, typically forwarding data received from a local network of sensor devices to the cloud, or sending commands to a network of actuators from the cloud.

Cloud devices connect directly to a TCP/IP network, in most cases using WiFi or cellular, and wired devices also count in this category. They’re distinct from edge devices in that they typically don’t communicate via a local network to other network-enabled devices. If they are part of an extended network of smart, connected devices, all the communication is normally funnelled via the cloud.

Prioritizing Your Decisions

Although it’s tempting to imagine that a single protocol and network stack will come to dominate the IoT, it is in fact unlikely that this will happen. The history of the Internet suggests that the IoT will remain diverse in the protocols and architectures used.

If you want to deploy devices in massive quantities, cost management means it is likely that these devices will have the minimum viable specification that is required to do the task at hand. The purchase decisions you make may constrain future options as far as which protocols are available to you.

It’s possible that some convergence will happen at the highest level of the protocol stack, with the data exchange formats tending toward a single standard, while all the underlying transport protocols remain diverse. This is almost the opposite of the existing digital Internet, where a diverse number of low-level networking protocols have been effectively replaced with TCP/IP, layered on top by a large number of other higher-level transport protocols and document standards.

Designing the Minimum Viable Product

A minimum viable product (MVP) is a product (rather than a prototype) that you deploy to customers, with the minimum set of features you need to gather information on how it is used so that you can refine it. Typically, you’d roll out the MVP to a small group of customers, and for each major set of refinements, expand that group. In the software world, this approach is popular and successful because of the relative ease of updating software in a cloud-based world.

However, the story of hardware development is somewhat different. While the concept of a minimum viable product still exists and is useful, building hardware tends to led by design rather than by feature. That results in two prototypes being built, a “looks like” and a “works like” prototype. The “looks like” model, true to its name, looks like the final product, but has little—or sometimes none—of the intended functionality. The “works like” prototype behaves like the final product, but generally bears no outward resemblance to the final product in terms of industrial design.

Confusing the “looks like” and “works like” prototypes, or mixing them, leads to what’s commonly referred to as feature-driven design. For hardware products intended for the IoT, this leads to poor user interaction with the product. That’s caused by design decisions you didn’t make, instead offloading design decisions to the user. If you make these design decisions once, users won’t have to go through that decision tree every time they use the product.

The Standards Problem

As we alluded to earlier, there is a brewing—if not all-out—standards war ongoing in the IoT. There is a great deal of confusion around protocols at different levels of the networking stack. For instance, there is a fundamental difference between low-level wireless standards like ZigBee or WiFi, and much higher-level concepts such as TCP/IP or above that HTTP and “the web” which sits on top of the TCP/IP networking stack. Above even that are document-level standards like XML and JSON, and even more conceptually wooly things such as patterns.

For instance, the concept of RESTful services is effectively a design pattern built on top of document- and high-level networking protocol standards. It is not in itself fundamental, and is unrelated to the underlying hardware, at least if the hardware itself is capable of supporting an implementation of these higher-level protocols.

However, perhaps the greatest standards problem with the IoT is that, due to constraints in power or computing resources, it is a mess of competing and incompatible standards at the lowest level. Factors such as range, data throughput requirements, power demands, and battery life dictate the choice from a bewildering array of different wireless standards.

The Big Three

The big three, the most familiar to consumers and to developers, are Bluetooth, WiFi, and cellular.

The most obvious choice, perhaps even the default choice, for networking an IoT device is the WiFi standard. It offers good data rates, and reasonable ranges (of the order 150 feet or larger), and means your device can connect directly to the Internet if needed. However, WiFi devices with even moderate duty cycles are power hungry.

Bluetooth, especially the low-energy configurations intended for low data rates and limited duty cycles, is designed for personal (wearable) devices with limited ranges and accessories. While recent standards revisions include support for direct Internet access via 6LoWPAN (IPv6), there is still only limited support that effectively means that Bluetooth devices are restricted to local, and small, networks spanning (despite manufacturers claims) around 30 or 50 feet. In the shortest-range use cases (a few inches), you should also be looking at near-field communication (NFC).

Of the three, perhaps the most ubiquitous, with the widest deployment and market penetration, is cellular. If your cell phone can get signal in a location, so can an IoT device with a 2G or 3G module onboard. Data rates lie somewhere between WiFi and Bluetooth, with the main advantage being range. Cellular devices can be located up to 20 miles from a cell tower, and depending on intervening obstacles, still get reception. However, cellular is both power hungry and expensive to operate. While GSM may be a good choice for a gateway device, it’s unlikely to be a good fit for most IoT devices.

Mesh Networks

Standards such as ZigBee and Z-Wave fill a niche in the local networking space. While they need a gateway device to talk to the Internet, both standards have mesh networking capability, so while individual devices can have between 30- to 300-foot range, the size of the network is actually only limited by the number of devices deployed. Both ZigBee and Z-Wave are targeted for low-power applications with lower data rates.

While ZigBee and Z-Wave have been around for a while, newer IPv6 protocols, such as Thread, which are based around a basket of standards including 6LowPAN, offer mesh networking and direct access to the digital Internet so long as IPv6-capable networking gear is in place. Designed to stand alongside WiFi, IPv6-based protocols such as Thread are attempting to address the lack of TCP/IP at the lowest levels of the IoT, accepting that the high-powered WiFi standard may be inappropriate for many (if not most) IoT devices.

Wide Area Networks

While cellular (typically GSM or UMTS) is the most popular standard used to provide wide area networks (WAN), there exist other newer standards that attempt to provide this functionality at much lower costs.

Sigfox uses the ISM radio bands, with typical operational ranges of up to 30 miles in rural environments and as low as 6 miles or less in urban environments. Sigfox networks are being rolled out in major cities across Europe and the United Kingdom. Making use of ultra-narrow band signaling, it is intended for very low data rates (just 10 to 1,000 bps) but also very low-power deployments (consuming a factor of 100 less power than cellular).

Other alternatives include Neul, which leverages the small slices of whitespace spectrum between the allocated TV bands and has a range of around 6 miles, and perhaps the most well known of the three, LoRaWAN.

LoRaWAN has a range of up to 3 miles in an urban environment and perhaps 9 or 10 miles in a suburban environment. Its rates range from 0.3 kbps up to as high as 50 kbps, and it makes use of various frequencies, depending on deployment. Much like Sigfox, it is also optimized for low-power deployments and large (millions of devices) deployments. The first LoRa network with nationwide coverage was rolled out in June 2016 in the Netherlands by the Dutch telecoms group KPN.