One of the most difficult choices you need to make when you are designing an Internet of Things (IoT) product is about that silent bit in the middle. You have the internet. You have your thing. But how do you connect one to the other? It is a multi-faceted question.

First, you need to decide on the type of connection – is it wired or wireless? Then there is the choice of standard, which impinges on battery life, along with the important considerations of commissioning and provisioning. That last point is often missed, but it is an important one, as it determines how easy it will be to set up. Can you just ship it in a jiffy bag, assuming it will connect and work as soon as it is turned on? Or will it need someone with technical expertise to commission it? And then there is the practical issue of cost, which involves both hardware and data contracts. That means you need to think about how much data you send, how often you need to send it and where your things are likely to be deployed.

These are all questions that need to be asked at the very start of any IoT project, as the choices affect much of the rest of the design. To further complicate the choice, almost all of these decisions are inter-related, so making a hardware choice will impact other criteria, such as battery life. In this article, we look at how to make those choices.

It is worth reiterating what the IoT is. At its most basic level, it is about getting data from a sensor to the cloud and then extracting value from that data. A single stream of data has limited value. Where the power of the IoT concept lies is in the way it aggregates and analyses data from multiple sensors and other data sources. So, whilst communication is not what drives the IoT, the IoT only becomes possible when communications become low-cost and ubiquitous, allowing tens of millions of sensors to be deployed and their data collected.

The problem with comms is that it is still something of a black art. Very quickly you can find that it dissolves into a debate about obscure technical features, where standards and suppliers fight to claim that their variant is best. To understand the best choice, it is useful to go back to basics. The figure below splits the various communications options into three main categories.

When most people talk about connectivity for IoT devices, they assume a direct connection from the thing to the cloud. That invariably means a cellular connection or something similar. Until recently, that ‘something similar’ did not really exist – the option basically came down to one of the original Global System for Mobile (GSM) communication standards, which have been around for the last fifteen to twenty years. For low data rates and the lowest hardware cost, the first choice would have been General Packet Radio Service (GPRS), which is ideally suited for low volumes of data. If you needed more throughput, then you could go for the slightly more expensive 3G modems, which support higher data rates. However, most network operators are starting to turn off their 2G and 3G networks, which leaves IoT designers with a problem. 4G modems are available, but they are both expensive and power-hungry. The 3GPP standards group, which develops mobile standards for our cellular networks, has belatedly attempted to address this hole with a new Narrowband IoT standard, called NB-IoT, but this is still in the early days of development and will probably not be widely available until after 2020. There are some interim 3GPP standards, such as LTE-M and LTE-Cat M1, but it looks unlikely that these will be widely deployed or supported by chip vendors, as the cellular industry is rushing pell-mell into NB-IoT.

Figure 1 IoT communication options

In the meantime, a number of alternative Low Power Wide Area Networks (LPWANs) have appeared, as start-up companies have tried to promote themselves as viable alternatives to the traditional cellular systems. They offer narrowband solutions, generally supporting very low data rates, but with long range, low battery consumption, very attractive hardware costs and low data charges. The market has narrowed down to three main contenders – SigFox, LoRa and Ingenu. All three operate in a licence-free spectrum – Ingenu at 2.4GHz and the other two in the 868 / 910 MHz bands, so are usable anywhere in the world. Some of them have very limited data rates and may not support over-the-air firmware upgrades, so that needs to be factored in.

All of the low-power options, whether LPWAN or NB-IoT, currently pose a problem regarding coverage. Whilst 3G and 4G networks are available across most of the world, LPWANs are not. Most LPWAN networks are working with established mobile operators to build up networks, but currently coverage is limited to major cities in a few countries. LoRa offers the possibility for a company to set up its own LPWAN network by installing a gateway, which can be run as a stand-alone network or connected to a wider underlying infrastructure, but developers need to take care to find out how long any infrastructure or standard is going to be supported. Unfortunately, there is no easy answer to that question, as the different, incompatible networks vie for supremacy in the market. As with VHS and Betamax, it will probably not be the relative merits of the technology that determine the winner.

Although the cellular/LPWAN approach has the lowest friction in terms of set-up, as devices should automatically connect to the cloud, it is still important to work out how to set up your IoT devices, that is, how they are provisioned and how they connect the first time they are turned on. The ideal is that a device automatically connects to the network and starts sending data as soon as it is powered up. If the industry wants to get to tens of millions of connected nodes, it will need to design things that do not need SIM cards or any user input – they just connect. There has been progress with embedded or hardware SIMs, which are chips soldered onto the printed circuit board (PCB), which can be provisioned at manufacture. In addition, a number of compans are now offering roaming services, where a SIM will connect to whichever network has the best signal, which helps to simplify this process. But you need to make these decisions early in the design process, as this affects the choice of hardware, PCB design, data contracts and cloud services.

A cheaper alternative, both in terms of hardware cost and data contracts, is to utilise Wi-Fi, connecting your ‘thing’ to an existing wireless access point. An increasing number of products aimed at the consumer market are taking this approach. Ericsson, who are responsible for the original visionary paper that put forward the concept of ‘50 billion connected devices by 2020’¹ have recently started calling these ‘capillary networks’, stating that a significant percentage of the 50 billion will be connected this way. To be honest, that is probably mostly in recognition of the fact that there is no way that the market will get to anywhere near 50 billion devices without including this topology. Wi-Fi certainly offers a simple way to connect things to the web, but still presents some problems. The most obvious one is the difficulty of provisioning. It needs a relatively technically competent person to associate the ‘thing’ with the access point. You can no longer just turn on a device and expect it to connect. It also raises the issue of devices becoming disconnected when an access point is changed, which in a consumer scenario can happen every couple of years.

At this point, it’s worth pointing out that the IoT does not need to be wireless. Currently there are probably more wired connections to the internet than wireless ones. Most of these will be wired Ethernet, not just from computers, but from many industrial and commercial sensors. Within buildings, most sensors and switches are still wired to control centres, which are themselves connected with Ethernet to private clouds.

For some applications, cables may still be a relevant option – they are inherently more robust than any wireless options, but they come with two disadvantages: they cost more, not so much due to the cable itself, but due to the cost of installation; and associated with that, they generally need professional installation. That typically limits them to new-build installations, where the wiring is part of the building or production line infrastructure, or ones where the reliability they offer is more important than the convenience of wireless. Despite that, it is worth pointing out that the IoT does not need to be wireless. It is about retrieving data, and wires have been doing that for decades.

Bluetooth provides a final alternative, offering one of the lowest cost ways of connecting devices to the net. Bluetooth Low Energy – the low power version of the standard, which came out in the Version 4.0 specification – has become the most common way to connect wearable and other consumer devices to mobile phones. This is largely driven by the growing popularity of apps that communicate to these devices, either for setting them up, sending notifications or collecting data. Once that connection is in place – and for many of these devices the Bluetooth to the phone app is an integral part of the product’s function – then it can also be used for forwarding data to the cloud using the phone’s cellular connection.

The limitation of this approach is that it is not an always-on connection. Data can only be harvested from the sensor when the phone is within range, which is generally when the customer is at home and in the same room as the IoT device, or if they are wearing it. For many sensors this is no problem, but it does mean that products need to be designed to time-stamp all of the data they record, so that once in the cloud, it can be properly aligned in a time-series database. Where the lack of real-time is not a problem, this can be a very cost-effective solution for connecting sensors. Like Wi-Fi in a domestic environment, if the phone or access point is changed, the user will need to reset connections for their new network. Inevitably, that means some devices will never get connected. But this is a balance between commercial and consumer products and applications and can be mitigated by good user interfaces and cloud support for device management. It is possible to deploy Bluetooth gateways for regular data feedback. This is common in areas like nursing homes, hospitals and gyms where there is a high concentration of static, Bluetooth-enabled products, but these are the exception rather than the rule.

This is the first part of the challenge. There is no universally correct solution – you need to pick the one that best fits your application model as well as the value of the data. The more valuable the data, the more you may want to lean towards a cellular solution, which is likely to have the most robust service availability. Cellular solutions generally support higher data rates than LPWAN, but at a price. They may also offer lower latency, so are appropriate where real-time, or near real-time, data capture is required.

If low power is the prime requirement, which may equate to zero maintenance and a battery that lasts for several years, the equation tilts towards the LPWAN offerings. Part of the way of how they achieve low power and long battery life is through limited data throughput, waking occasionally to transmit data. As battery life becomes important, more attention needs to be paid to the overall system power management, ensuring that sensors either work occasionally or are fired up by other lower power sensors to minimise the sleep current. It may also be effective to time-stamp and compress data to limit the number of transmissions required each day, as the radio can be a major user of power. It is certainly possible to use these technologies to design battery-driven sensors that have a ten-year life. The irony is that the network itself may not last that long.

Bluetooth and Wi-Fi can bring other optimisations and cost saving. Their adoption in a wider range of high-volume consumer products has resulted in some very highly featured systems on chip designs, which include radios, multiple processors and I/O processing on a single chip. Rather than just using these chips to add communications to a device, they are often powerful enough to run the complete sensor application, drastically reducing the cost of sensors. For anyone looking at high volumes, these highly integrated chips can be an ideal way of pushing the price down.

To conclude, the choice of a communications standard is a complex one. Start off by understanding how much data you want to receive, how often and whether you need two-way communications for firmware updates. Consider the power supply options and battery life. Check that the wireless options you are considering have the correct lifetime cost of operation and are available in the areas you plan to ship your products. Do all of this before you do your first hardware design, as you may be able to use the processing power within these chips to run your sensor. Alternatively, depending on your current product and time-to-market requirement, you may just want to tack a comms module onto your existing board.

I have not mentioned security, as that needs to be a separate work item. All of the wireless standards contain security, which should always be enabled, but their security only covers the extent of the wireless connection. Every IoT project needs to develop an overall security model that includes end-to-end security as a non-negotiable feature. Wireless security helps, particularly against replay and man-in-the-middle attacks, but should never be considered as sufficient by itself.

There is no single ideal solution for communications – in fact, there has never been a wider choice. But that means you need to think carefully to make sure you choose the right one. The IoT is all about collecting data. The more cost-effective you make that data collection, the more data you can afford to collect, which confirms the virtuous circle that is the IoT.

REFERENCE

1. Ericson White Paper (2011) ‘More than 50 billion connected devices’. Available from: http://www.akos-rs.si/files/Telekomunikacije/Digitalna_agenda/Internetni_protokol_Ipv6/More-than-50-billion-connected-devices.pdf [27 March 2017].