Network equipment provider Ericsson forecasts that by 2026, there will be 26,4 billion IoT devices, 5,4 billion of them connected to the internet over cellular networks. That leaves a lot of devices – 21 billion, in fact – looking for another way to connect. Many of these connections will be made through wired networks, for example in smart-city, smart-building, and smart-lighting deployments, where the provision of fixed connectivity can be part of the design process. But the ad hoc and distributed nature of many IoT deployments (environmental sensors are placed where they are needed, not where there is a network jack) means that many IoT devices need other forms of wireless connectivity.
There are multiple approaches to wireless connectivity for the IoT, each representing a different trade-off between their reach, their topology, the data rates they support, the radio spectrum and modulation schemes they use, the energy efficiency with which they send data, the complexity of implementation in the device and the network base station. Many are adaptations of consumer technologies, such as mesh networking over Bluetooth, or are designed for a very narrow set of applications.
Long-range Radio (LoRa) is used to implement low-power, wide-area networks (LoRaWANs) over distances of up to 5 km in urban areas and 15 km in suburban areas. It supports data rates of up to 27 Kbit/s, and is therefore a good match for IoT devices such as sensors that need to report only small amounts of data irregularly. LoRa uses unlicensed ISM radio spectrum, making it easy to deploy worldwide. It uses a simple and robust modulation scheme, so the necessary RF power amplifiers are inexpensive and efficient. It adapts its RF output power to the amount of data being sent, saving battery power, and preserving the aggregate capacity of the network. And because of this relative simplicity, a single LoRaWAN gateway device can service thousands of LoRa nodes. The flipside of this simplicity is that LoRa is not ideal for real-time applications or for serving nodes that need to transfer large amounts of data on a regular basis.
LoRa applications
The ability to create wide area networks at a lower implementation cost than cellular connectivity would require is making LoRa attractive in a host of applications. In smart buildings, it can be used to connect environmental monitors and equipment trackers, to detect room occupancy, and to manage issues such as lighting and metering. In an Industry 4.0 context, applications include monitoring machinery, asset tracking, and equipment management. Smart-city applications could include all those previously given for smart buildings, as well as enhancing the management of civic infrastructure such as waste collection, traffic control, and city-wide environmental monitoring and alerts. It’s a similar story in logistics and the supply chain: LoRa networks could provide the communications backbone for managing fleets of material-handling equipment in warehouses and shipping yards.
Table 1 breaks out some further potential applications for LoRa by market sector.
The LoRaWAN gateway
The LoRa specification defines how low-power nodes can communicate over relatively long distances at low data rates. To turn this capability into a network, LoRaWAN implementations need something to communicate with – a LoRaWAN gateway. This provides the interface between multiple LoRa nodes distributed in the field and a network server, which in turn consolidates data from multiple gateways before passing it along to an application server. Simple LoRaWAN gateways have minimal firmware and act as packet forwarders to the network server. More complex gateways can have an operating system that enables them to run packet-forwarding software as a background task and provide other support to gateway administrators as a foreground task.
Because of the relative simplicity of the radio implementation, the low data rates that the protocol supports, and the relatively low duty cycles expected of each LoRa node, many LoRaWAN gateways can support hundreds, or even a few thousand, LoRa nodes at once. This capability opens opportunities to install and run a group of LoRaWAN gateways as a platform through which multiple users can provide their LoRa nodes with connectivity, without having to install their own gateways. Some organisations are creating global collaborative networks of LoRaWAN gateways that operate on a fair-use basis – “I’ll carry your data if you’ll carry mine” – to enable low-cost experimentation with IoT ecosystems. Commercial vendors are also offering LoRa connectivity and services as a cloud platform.
Of course, LoRaWAN gateways need a network connection to provide the backhaul for the messages from each node. In a smart-building, smart-city, or warehouse context, this could be provided by a wired Ethernet interface or a Wi-Fi connection. LoRaWAN gateway designers should consider adding cellular connectivity as well, so that their designs can serve LoRa nodes that have been distributed throughout a remote location, such as a civil engineering project. Cellular backhaul can also make it easier to support applications in which LoRa nodes move en masse, such as cattle tracking.
Even in static implementations with good wired and Wi-Fi connectivity, cellular connectivity may be necessary to overcome potential objections about running LoRa data packets over the incumbent network. For example, a building contractor renovating a school might want to track all its tools and equipment using LoRa, but finds the school unwilling to share its Wi-Fi network for fear of security breaches. Cellular capabilities in the LoRaWAN gateway would make it easy to set the whole issue aside by easily establishing a separate backhaul connection.
Managing LoRaWAN gateways
Well-designed LoRaWAN gateways can provide connectivity to large estates of IoT nodes at relatively low cost. But there are challenges in running an estate of LoRaWAN gateways. One of the most obvious is that the devices are physically distributed, and so support and maintenance must be performed remotely. Many devices are remotely monitored and updated, but the challenge for LoRaWAN gateways, and especially for the simplest packet-forwarding types, is that updating their firmware or reconfiguring its operation could go wrong. This would leave the device inoperable and could only be rectified by a costly visit to the gateway in situ.
The second key concern for LoRaWAN gateway operators is ensuring and sustaining their security. A compromised gateway could be used to steal or corrupt vital data or suborned into taking part in a denial-of-service attack, leading to reputational damage.
Sustaining the security of IoT devices is not a challenge unique to LoRaWAN gateways and nodes. Indeed, it is such a widespread and challenging issue that Microsoft’s Azure Sphere team, which develops its IoT platform offering, has identified seven properties that it believes are necessary to build and sustain the security of network-connected devices. These include:
• A hardware root of trust, usually implemented as a unique, immutable, and uncopiable feature of an IC, which allows software developers to be sure they are communicating with a particular chip, and which also acts as the basis for the cryptographic functions needed to communicate securely with the device.
• Defence in depth, a way of ensuring that if one security mechanism is breached, another is available.
• A small, trusted computing base, which holds encryption keys in a protected area of an IC that is inaccessible to software, and divides software into self-protecting layers.
• Dynamic compartments, which are hardware-enforced barriers between software components to stop breaches propagating.
• Password-less authentication, using certificates derived from the hardware root of trust, so that the device can prove its identity and authenticity.
• Error reporting, so that the device can be analysed to ensure it is operating correctly, and to identify new threats.
• Renewable security, so the device can be updated in the field to protect it from new threats.
It’s a daunting list, and implementing it is even more challenging. The team eventually recruited chip designer MediaTek to help it produce the necessary secure microcontroller, by adapting an existing MediaTek design and then adding Microsoft’s own Pluton security processor, which was developed to protect the Xbox from hacking attempts. It also had to develop a ‘secured’ operating system that takes advantage of the security features in the custom microcontroller, and then put the resultant device and software up to a hacker challenge to see if it was, in fact, secure.
The platform alternative
For those who want to take advantage of the potential of LoRa connectivity to implement distributed IoT ecosystems, without having to worry about managing the LoRaWAN gateways, there are cloud-based alternatives.
For example, Microsoft’s Azure Sphere IoT platform, working with LoRaWAN gateways from Miromico, can securely monitor, track, and manage data in almost any indoor location. The Miromico LoRa gateways, which have been designed to work with Azure Sphere, have cellular, Wi-Fi and Ethernet connectivity.
Azure Sphere provides guaranteed maintenance for the gateways through its operating lifetime, handling security maintenance tasks such as daily authentication of hardware and software automatically. Close integration between the Azure Sphere platform and the Miromico gateway has enabled a failsafe mechanism for over-the-air updates, allowing customers to remotely upgrade gateways without fear of them becoming unreachable due to a glitch during the update.
| Tel: | +27 11 319 8600 |
| Fax: | +27 11 319 8650 |
| Email: | [email protected] |
| www: | www.avnet.com/wps/portal/silica |
| Articles: | More information and articles about Avnet Silica |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version