LoRaWAN, or Long Range Wide Area Network, is no longer a new term. Designed for the Internet of Things (IoT), it is a type of Low Power Wide Area Network (LPWAN) that uses open-source technology and transmits over unlicensed frequency bands. The fact that LoRaWAN technology provides a far longer range than Wi-Fi or Bluetooth connections quickly establishes it as a technology of choice for many new IoT solutions. Not only that! LoRaWAN also works well indoors and is especially valuable for applications in remote areas where cellular networks have poor coverage.

LoRaWAN is the upper layer protocol stack that defines the network’s communication and architecture. More specifically, it’s a Medium Access Control (MAC) layer protocol with some Network Layer components. It uses LoRa®, but it specifically refers to the network and how data transmissions travel through it.

But how is the communication between devices inside this protocol actually happening?

While there are several options, some more popular than others, generally one based on something called pure ALOHA is used for data transmission. What is that? ALOHA is a multiple access protocol for the transmission of data via a shared network channel. It operates in the MAC sublayer of the open systems interconnection (OSI) model. This is a fairly simple protocol in which several data streams coming from multiple nodes are transferred through a multi-point transmission channel.

Simplicity is the thing that makes ALOHA so popular and yet not the optimal choice for data transferring when we talk about big deployments. In pure ALOHA, the time of transmission is continuous. Whenever a node has something to send, it sends it. If there is a collision in packets, for example when another node transmits at the same time, the frame is destroyed, and the sender waits for a random amount of time before retransmitting it. This can lead to crucial data loss and unnecessary transmission delays.

Not only that. Even though LoRaWAN is free to use there are still regulations. To ensure it is accessible for everyone and safe to use, local governments decide on restrictions and rules at the country level. Some are stricter than others. The South Korean frequency regulations, for example, impose specific duty cycles on devices for each sub-band. Most channels used by LoRaWAN have a duty cycle as low as 2%. Japan has specific requirements as well. In these countries, Listen Before Talk (LBT) functionality is mandatory for equipment accessing unlicensed channels where one or more clear channel assessments (CCAs) should be performed before transmitting.

What is Listen Before Talk and how does it work?

The wordplay in the title is not accidental. LBT is a potential solution for two major problems presented before any innovative IoT project:

• Data loss due to packet collision in the network.
• Blocked market entry for South Korea and Japan due to strict regulations.

As we already mentioned, for a device to be sold and used in South Korea and Japan, integrated LBT functionality is a must. Without it, the device won’t be able to get the needed certification for legal operation in those countries. That is easily fixable. But what about the bigger problem – the data loss?

The answer is actually contained in the nature of the LBT itself. The protocol makes it possible for multiple users to share the same channel. When LBT is enabled, the device continuously monitors channels to transmit only when a channel is not in use. Listen Before Talk requires the application of a Clear Channel Assessment (CCA) check before using the channel. For a device to transmit its data (talk) first, it needs to make sure that the channel is free (listen).

This CCA is conducted using one of two methods depending on the country-specific regulations. In their paper Augmenting LoRaWAN Performance with Listen Before Talk, Jorge Ortín, Matteo Cesana, and Alessandro Redondi explain the two different implementations of LBT: physical layer LBT based on energy detection only, and MAC layer LBT based on layer-2 frame decoding, and propose a Markovian framework to evaluate the performance of LoRaWAN under such setting in terms of Data Extraction Rate and average delay experienced by transmitted uplink messages. This is an interesting read that explores the possibility of using LBT approaches in LoRaWAN to augment the network performance since the MAC scheme adopted by LoRaWAN based on pure ALOHA proved to be a major performance bottleneck as the network size scales up because the maximum channel utilization is only 18,4%.

The need for use of LBT is also determined by the devices themselves. The MAC level defines three classes of end devices. Class A devices transmit in the uplink using by standard a simple random ALOHA-based access protocol and can receive traffic in the downlink only after an uplink transmission. Class B devices can wake up periodically to receive scheduled downlink data traffic. Class C devices listen continuously and are typically mains-powered. Class A devices are, at the moment of writing, the ones with the highest diffusion in the market. To limit interference in the ISM band, Class A devices are mandated to operate in Europe with a duty cycle below 1% if running ALOHA access protocol, or adopting a Listen Before Talk approach with no limitations on the duty cycle.

So, the “listening” is done either on the physical layer or the MAC layer, each with its upsides and downsides. But what about the “talking” part?

In the article Towards LoRaWAN without Data Loss: Studying the Performance of Different Channel Access Approaches, Frank Loh, Noah Mehling, and Tobias Hoßfeld explain very well the results of their research about different approaches to data transmission to lessen data loss. There, they explain the principle that LBT usually uses – the back-off strategy. Before a device transmits a message with Listen Before Talk, it listens to the channel whether it is already occupied. If it is free, the transmission is started and otherwise, the message is delayed according to a predefined back-off strategy with no additional synchronization required. The back-off strategy for LBT determines the duration a message is delayed after an unsuccessful transmission attempt when the channel was occupied (for ALOHA the delay is always the transmission time). In that article, they demonstrate an approach how to determining the optimal delay for a message. On one hand, the goal is to not delay it too much before the new transmission attempt. On the other hand, however, sits the risk of another unsuccessful attempt due to the channel still being used on the other. The optimal back-off delay is determined by taking into account the physical surroundings (location and distance) of the actual deployment (try to predict if there will be a hidden node problem) and the density of the deployment.

Listen Before Talk in RAKwireless’ ecosystem.

We are happy to state that RAKwireless’ WisGate Edge gateways do support LBT. Version 2 of the hardware is providing the physical support needed for the operating system – WisGateOS 2 to offer this functionality. LBT is not a requirement everywhere so we are going to launch the option to add it to your setup as an Extension. RAKwireless is giving you reliable devices and the freedom to use them in any market in the world by providing all essential functionality. And with the growth of LoRaWAN, we consider LBT essential.

Channel access planning in LoRaWAN is a complex task. Challenging factors are, among others, different channel access approaches, limited synchronization possibilities due to duty cycle limitations for class A devices and the gateway, and strict requirements at the end devices to save battery. Furthermore, the free usage possibility of the frequency bands can lead to potential cross-traffic. But Listen Before Talk offers a solution and a path to clearer LoRaWAN communication with no data loss. No matter if you are a Solutions Provider that wants to grow their business to South Korea and Japan, or you are a company from those countries that considers using LoRaWAN, or you just want to make sure your data is passed through the network safely and in its integrity, LBT is for you.