Download this article in PDF format.
“Far-flung” is a fun phrase, particularly for a Brit like me who enjoys American sayings that are colorful, baffling, and perfect all at the same time. It sounds like the kind of old-timey language you would hear in black-and-white newsreels from the early 1900s: “News flash. Dateline Chicago. Here we see a vehicle of the future, called an aero-plane, taking flight to far-flung destinations like Peoria and ‘Saint Louee’ in less than a day. What will they think of next? A phonograph you can fit in your watch pocket?”
When it comes to the Internet of Things (IoT), far-flung is also fun because it’s about where the future of IoT lies: Way out on the edge of where sensor device-to-cloud wireless connectivity has ever been able to go geographically.
IoT has been anything but far-flung up until now. Yes, it is already being deployed in lots of locations. The analyst reports that come out each month say that billions upon billions of wireless sensors and devices will be deployed in the next few years.
But if you fling a dart at a map, chances are you would hit a geographic location where IoT was once likely to be difficult or challenging to achieve—either technically or economically. That’s because the vast majority of wireless IoT deployments today are done within arm’s reach of telecommunications infrastructure, whether in the form of wired infrastructure or wireless towers.
However, there are just as many locations where that infrastructure is not present or is too costly to use for an IoT deployment. And guess what? Those areas of the map happen to be areas that have myriad uses for low-power, long-range IoT, whether for monitoring and information relay of remote industrial equipment, pipelines, energy tanks, soil, moisture, and more.
Infrastructure Dependency
There’s a good reason why IoT has stuck close to that infrastructure, which typically means close to cities and towns and the routes that connect them. IoT deployments rely on Ethernet, fiber, and cellular infrastructure as the conduit for data sent to and received from those wireless devices. That provides the backhaul for an engineer in Chicago to receive packets of data from a set of sensors in Peoria, and to send instructions and other information to the wireless IoT devices remotely.
Typically, that backhaul is provided via fiber through something like a Wi-Fi or cellular connection from a gateway. It acts as the go-between that connects the network of devices with fiber or wireless infrastructure for two-way communications with the IoT deployment. But what happens when there isn’t any fiber or cell tower in sight? Or when there is a cell signal, but the cost or power demands are just too prohibitive for the IoT deployment to make sense?
Well, in the past, nothing would happen. The IoT project would simply be shelved as impractical or never be proposed in the first place. Such a scenario has put an artificial boundary around IoT deployments to date. Lots of implementations are happening, but how many more implementations would be on the drawing board if those geographic boundaries disappeared and you could fling them as far as you hypothetically wanted them flung?
That is exactly what is possible when you combine a new technology, LoRa, with one that is already a fundamental element of so many IoT deployments: Bluetooth Low Energy (BLE).
IoT networks that utilize BLE (also known as Bluetooth Smart) can be deployed in nearly any physical space, given its small footprint and energy-miser architecture that enable small wireless sensors and controls to operate on a battery charge for years. With BLE, these small devices can be placed nearly anywhere within a given location, allowing users to put sensors and other devices in spots that are often physically impossible, technically difficult, or fiscally impractical for traditional wired devices. Simply put, BLE works for IoT, which is why engineers embrace it as the foundation for short-range wireless connectivity in these deployments.
This diagram represents a simple geographic setup of a long-range enterprise IoT scenario.
But without backhaul, those BLE devices are simply talking to one another in an echo chamber—they lack two-way communication back to the people who want to get that data and send instructions. As a result, the majority of BLE-based IoT applications use the mobile phone as a gateway back to the cloud via its cellular connection. But in absence of a cellular or mobile phone, what do you do? This is where LoRa comes in.
Enter LoRa Technology
LoRa, often referred to as a low-power wide-area-network (LPWAN), provides secure, bidirectional data transfer and communications with IoT networks over long distances for years without a battery change (for more on the technology, see "Looking at the LoRaWAN Specification" below). It can send and receive signals up to 10 miles, and that distance can extend to hundreds of miles with repeaters, if needed. LoRa works well as a complement for BLE in battery-powered networks of IoT devices because it can operate for an extended time on a battery and requires very infrequent maintenance—just like BLE.
LoRa nodes are also inexpensive, allowing companies to create a low-cost backhaul network that bypasses fiber or cell service. Thus, they are able to avoid the high cost of building fiber to a remote site or the cost of a cell contract can. These costs can be expensive for the kind of connectivity needed with an IoT deployment.
LoRa is also highly scalable and highly interoperable, supporting up to a million nodes and compatible with both public and private networks for the data backhaul and bidirectional communications. And one of its best qualities is the ability to perform in environments with vibration, interference, extreme temperatures, etc. These conditions are quite common in industrial environments and remote locations where the elements can go to extremes.
Together, BLE and LoRa provide the combination of short-range, inter-device communications and long-haul backhaul over distance to allow the implementation of IoT networks in a much broader geographic area. This geographic freedom is particularly important for enterprise-level IoT, because so often these wireless networks of sensors and devices are located a great distance from urban areas (see figure).
With that said, some exciting applications await LoRa in metro areas: A few LoRa gateways can create an IoT network for a large urban area, connecting a large number of devices with their own low-power network that need not rely on traditional telecom infrastructure. Those applications include environmental monitoring, to city management, to utility-meter measurements among dozens of others.
Those non-far-flung applications are fascinating, but what makes LoRa+BLE so significant is how it turns nearly anyplace on the map into a realistic location for an IoT deployment. As an example of LoRa+BLE in action, take a basic temperature sensor, which is one of the most common types of devices in IoT deployments. It could measure the temperature of an exhaust outlet on a generator in a remote location, or measure changes in temperature of liquid oil in a holding tank, or measure air temperature in an environmentally sensitive wilderness area. Regardless of the location, it’s still a temperature-sensor deployment at heart, which most engineers have done at least once—if not a thousand times.
But for the sake of this example, let’s say that there isn’t any telecom infrastructure anywhere close enough to be of practical use. The short-range network of sensors would look very familiar to many because it is a BLE-based network of wireless devices. However, with a LoRa+BLE module in those devices, and a LoRa gateway to provide the long-haul data transfer, that network of IoT devices can perform the task even with no Wi-Fi or cellular service in sight.
The LoRa gateway on-site would relay data packets to and from the cloud via a series of small nodes every 10 miles, each of which utilize the ultra-low-power LoRa to stay running for long periods on a small battery. That backhaul can extend as far as necessary until a connection is able to be made to traditional telecom infrastructure. This means IoT networks can be 10 miles or hundreds of miles further away than previously possible, dramatically expanding where these networks can go.
Now when you spin a globe and put your finger down randomly on any far-flung corner of the earth, not only can you daydream about taking a vacation there, you can daydream about putting an IoT network in that spot as well.
Looking at the LoRaWAN Specification
LoRaWAN targets key IoT requirements, such as secure bidirectional communication, mobility, and localization services. The LoRaWAN specification provides seamless interoperability among smart “things” without the need for complex local installations, thus giving back the freedom to the user, developer, and businesses, and enabling the rollout of IoT.
LoRaWAN network architecture is typically laid out in a star-of-stars topology. In this configuration, a gateway is a transparent bridge relaying messages between end devices and a central network server in the backend. Gateways are connected to the network server via standard IP connections, while end devices use single-hop wireless communication to one or many gateways. All end-point communication is generally bidirectional. However, it also supports operations such as multicast, enabling software upgrades over the air or other mass-distribution messages to reduce the on-air communication time.
Communication between end devices and gateways is spread out on different frequency channels and data rates. The selection of the data rate is a tradeoff between communication range and message duration. Due to spread-spectrum technology, communications with different data rates do not interfere with each other and create a set of "virtual" channels, increasing the capacity of the gateway. LoRaWAN data rates range from 0.3 to 50 kb/s. To maximize battery life of the end devices as well as overall network capacity, the LoRaWAN network server manages the data rate and RF output for each end device individually by means of an adaptive-data-rate (ADR) scheme. (Source: LoRa Alliance)
