Demystifying LoRa and LoRaWAN Wireless Network Protocols

In the world of the Internet of Things (IoT), connectivity is everything. It’s the “I” in IoT and the vehicle through which we deliver remote products and applications that can pipe their on-the-ground smarts to the cloud for monitoring, management, and decision-making. While it’s never been easier to add connectivity to a product, device, or machine, choosing the right connectivity option for a solution is still rife with complexity.

It may be obvious in some cases that Ethernet or Wi-Fi is the right choice—such as in a home or factory. In others, near-field communication (NFC) or Bluetooth may be a preferred option because your solution requires short-range device-to-device communication. However, if your product is mobile, or in an urban, agricultural, or other setting where the complexity of Wi-Fi setup simply won’t do, you’re left looking elsewhere. Specifically, at cellular or LoRa (formed from the phrase "long-range") and LoRaWAN (long-range wide-area networking).

The global reach of cellular via global harmonization of frequency bands and inter-carrier roaming agreements, as well as the availability of high-bandwidth connections for data-intensive applications, makes this approach appealing for many use cases. Despite the appeal, some applications favor LoRa, where signals are noise resistant, and the availability of free, unlicensed frequency bands makes the unit costs of individual devices significantly lower.

Given that different needs will lead you to choose either cellular or LoRa, and that these approaches are more complementary than competitive, let's dive more deeply into LoRa.

 

What is LoRa?

LoRa is a low-power communication protocol intended to operate over long distances using an unlicensed spectrum, specifically radio bands reserved for industrial, scientific, and medical (ISM) purposes.

LoRa devices communicate at sub-gigahertz frequencies, thus enabling long rage data transfer, though the available bands are narrow, and some governments have strict rules about how often a device on these bands may transmit. In Open Systems Interconnection (OSI) terms, as seen in the reference model in Figure 1, a LoRa chip is the physical layer that underpins everything above it and enables hardware devices to leverage unlicensed spectrum for low-power wide-area networking (LPWAN) applications. Basically, it dictates the spectrum and protocol used for radio communication.

 

Figure 1. LoRa operates at the Physical layer of the OSI reference model 

 

Though LoRa operates at the sub-gigahertz spectrum, the specific bands that a LoRa chip leverages differ from one region to the next. LoRa radios in Europe operate at 863-870/873 MHz, while devices in Asia and South America operate at 915-928 MHz, and devices in North America operate at 902-928 MHz. When purchasing LoRa chips for an application, many will be pre-programmed to the spectrum for a region depending on the specific range requirement. An overview of the spectrum, with LoRa's frequency range, can be seen in Figure 2.

 

Figure 2. LoRa radios operate on the sub-gigahertz spectrum. Image [modified] used courtesy of NASA

 

Beyond the spectrum used, LoRa also specifies the protocol used for radio communication or LoRa PHY.

 

LoRa Modulation: Chirp Spread Spectrum

LoRa uses a proprietary wireless modulation technique that is a derivative of the chirp spread spectrum, which uses “chirp” pulses as a way of encoding information. A chirp is a sine wave, as seen in Figure 3, with a signal frequency that increases or decreases with time.

 

Figure 3. LoRa encodes information using a series of increasing (as shown here) or decreasing “chirp” pulses. Image used courtesy of Georg-Johann

 

A LoRa radio performs its modulation by representing each bit of information in a payload with multiple chirps of information. In this case, the “spread spectrum” in the name means that devices using this technique, including the LoRa derivative, all use allocated bandwidth to broadcast, making these signals resistant to the channel noise common on ISM bands.

LoRa devices allow engineers to tune their applications and choose between high data rate or high sensitivity using something called the spreading factor (SF). Using a tunable radio parameter, engineers can select the number of chirps sent per second. A low SF will send more chirps per second, meaning that you can encode more data per second, but the signal is not very sensitive from the receiver’s point of view.

A low sensitivity translates to a higher likelihood that the data you intend to send is lost along the way. A high SF, on the other hand, will send fewer chirps per second but produces a signal that is more sensitive to the receiver, thus more reliable. However, high SF chirps need more “airtime” (transmission time on the network) and require more power because the modem is running for a longer period than with a low SF approach.

By setting the SF for radio, as well as changing the modem’s transmission power (tunable between 2 dBm and 20 dBm depending on the region), LoRa provides engineers with capable tools for configuring an application for power consumption and communication range based on their needs.

As a physical layer, LoRa covers everything needed to enable long-range communication between devices on a common spectrum that can speak the same protocol. It does not, however, cover how devices identify one another, how they communicate with one another in a way that minimizes crosstalk on the network, or how data from local network devices can be securely transmitted to the cloud or remote locations. That’s where LoRaWAN (and others) come in.

 

What is LoRaWAN?

LoRaWAN, on the other hand, is a networking protocol built on top of LoRa-based modulation. Although LoRa itself is inherently peer-to-peer, LoRaWAN shapes the network into a hub-and-spoke by defining two core device roles:

• A node, which is generally a sensor
• A concentrator, which acts as a gateway between nodes and the cloud

In OSI terms (Figure 4) LoRaWAN dictates both the data link layer that handles node-to-node communication, as well as the network layer for handling how nodes can send data to and receive data from across the local network boundary.

 

Figure 4. LoRaWAN specifies technologies that operate at the Data Link and Network layers of the OSI reference model.

 

At the data link layer, LoRaWAN defines a medium access control (MAC) protocol that determines how nodes on the network identify themselves (aka a MAC address) as well as the power requirements, frequencies, and data rates used for communication between LoRa devices.

At the network layer, LoRaWAN covers both the physical hardware that sits at the edge of the network to communicate with LoRaWAN nodes and the services that sit in the cloud. This includes the receiving, routing, processing data from, and routing data to the local LoRa network (Figure 5). 

 

Figure 5. A typical LoRaWAN network consists of on-premises and cloud-based elements.

 

A concentrator acts as a gateway that manages connections from LoRaWAN nodes, as well as connections to wide area network servers over the internet. Many concentrators available on the market tend to include eight channels for simultaneous receipt of request packets from LoRaWAN nodes and a single channel for sending response packets back to those nodes. The gateway cooperates with the network servers to manage devices as they join the LoRaWAN network, and to handle communications to and from cloud-based application servers.

Although not the only media access protocol for LoRa, the LoRaWAN protocol enjoys broad industry support and has a healthy ecosystem. It was started and is maintained by the LoRa Alliance, an association created in 2015 to support the collaborative development of the LoRaWAN protocol and ensure interoperability across LoRaWAN products and services.

In some parts of the world (most notably in Europe), cellular carriers have seen revenue potential in offering their own proprietary LoRaWAN networks, many of these targeting smart city and agricultural applications. Elsewhere, it is more common to think of LoRaWAN networks as “build your own” wide-area private networks that a customer would need to fund and deploy themselves.

 

LoRa vs. LoRaWAN

I mentioned at the beginning of this article that LoRa and LoRaWAN are often used interchangeably, so it should be no surprise that most engineers would expect that these technologies must be used together in a solution. While it is certainly true that LoRaWAN requires the use of LoRa devices in an edge network to function, is it not the case that deployment of LoRa devices requires a LoRaWAN concentrator, network, or application servers.

The reality is that, while LoRaWAN is the most popular and broadly deployed protocol for LoRa wide-area networking, and an interoperable standard that powers many devices, it may not be the best option for every LPWAN application. Beyond the expense of 8-channel concentrators, the LoRaWAN protocol dictates link, airtime, and power requirements that may not be appropriate for every use case—particularly those with small numbers of nodes that don't transmit very often. What’s more, it may be that the cloud service you wish to use doesn’t mesh with the network and application server requirements of a LoRaWAN solution. 

 

Using LoRa Without LoRaWAN

Step one in using LoRa without LoRaWAN is that you must implement your own medium access protocol so that nodes may agree amongst themselves on how to identify one another, how to conceal communications, and how and when to communicate on the air without stepping on one another. Connecting a LoRa deployment to the cloud without LoRaWAN also requires implementing your own mechanism for handling backhaul to cloud services. 

This may feel overly complex, however, it can be quite simple depending upon your need: a two-node peer-to-peer connection can just alternate send and receive roles, and a small network of a few dozen nodes can use a quite straightforward time division multiple access (TDMA) time slot protocol. LoRaWAN was designed for large-scale networks, and LoRa nodes need not re-implement every piece of the LoRaWAN protocol if the goal is a flexible and lower-cost point solution. This approach is not uncommon in the market.

Amazon Sidewalk, which is used in the Echo, Ring, and other Amazon smart devices, uses LoRa and implements a mesh network MAC layer. And in the commercial IoT space, Blues Wireless offers a product called Sparrow, seen in Figure 6, which uses LoRa for nodes that communicate with a Cellular or Wi-Fi gateway for cloud backhaul (full disclosure: I work for Blues). 

 

Figure 6. The Blues Wireless Sparrow product uses LoRa for local network communication alongside traditional Wi-Fi or Cellular cloud backhaul to the Notehub.io cloud service and a customer’s ultimate cloud infrastructure.

 

The LoRa MAC included with Sparrow is Open Source, implementing a simple one-touch gateway/node secure pairing mechanism as well as an adaptive transmit power subsystem that optimizes the lifetime of battery-operated nodes.