What are LoRa® and LoRaWAN®?

LoRa is an RF modulation technology for low-power, wide area networks (LPWANs). The name, LoRa, is a
reference to the extremely long-range data links that this technology enables. Created by Semtech to
standardize LPWANs, LoRa provides for long-range communications: up to three miles (five kilometers) in
urban areas, and up to 10 miles (15 kilometers) or more in rural areas (line of sight). A key characteristic of the
LoRa-based solutions is ultra-low power requirements, which allows for the creation of battery-operated
devices that can last for up to 10 years. Deployed in a star topology, a network based on the open LoRaWAN
protocol is perfect for applications that require long-range or deep in-building communication among a large
number of devices that have low power requirements and that collect small amounts of data.
Consider the differences between LoRa and other network technologies that are typically used in IoT or
traditional machine-to-machine (M2M) connectivity solutions:

 Figure 1: IoT Technologies

Note: In Europe, mobile network operators have implemented a dual strategy to address packet size and latency
issues. They often offer both LoRaWAN and Cat-M1, which are complementary technologies. LoRaWAN
accommodates the need for longer battery life, with a trade-off of longer latency and smaller packet sizes. In
contrast Cat-M1 can be used for larger payloads with less latency than LoRaWAN can accommodate.
Figure 2 highlights some important advantages of deploying a LoRaWAN network:
 Figure 2: Advantages of deploying a LoRaWAN network
Let’s look into these advantages in a little more depth.
With respect to range, a single LoRa-based gateway can receive and transmit signals over a distance of more
than 10 miles (15 kilometers) in rural areas. Even in dense urban environments, messages are able to travel up
to three miles (five kilometers), depending on how deep indoors the end devices (end nodes) are located.
As far as battery life goes, the energy required to transmit a data packet is quite minimal given that the data
packets are very small and only transmitted a few times a day. Furthermore, when the end devices are asleep,
the power consumption is measured in milliwatts (mW), allowing a device’s battery to last for many, many
years.
When it comes to capacity, a LoRaWAN network can support millions of messages. However, the number of
messages supported in any given deployment depends upon the number of gateways that are installed. A single
eight-channel gateway can support a few hundred thousand messages over the course of a 24-hour period. If
each end device sends 10 messages a day, such a gateway can support about 10,000 devices1. If the network
includes 10 such gateways, the network can support roughly 100,000 devices and one million messages. If
more capacity is required, all that is needed is to add additional gateways to the network.
And then, there is cost. Given the capabilities of LoRa-based end nodes and gateways, only a few gateways –
configured in a star network – are required to serve a multitude of end nodes. This means that capital and
operational expenses can be kept relatively low. Also, when the cost-effective LoRa RF modules that are
embedded in inexpensive end nodes are used in conjunction with the open LoRaWAN standard, the return on
investment can be considerable.
Radio Modulation and LoRa
A proprietary spread-spectrum modulation technique derived from existing Chirp Spread Spectrum (CSS)
technology, LoRa offers a trade-off between sensitivity and data rate, while operating in a fixed-bandwidth
channel of either 125 KHz or 500 KHz (for uplink channels), and 500 KHz (for downlink channels).
Additionally, LoRa uses orthogonal spreading factors. This allows the network to preserve the battery life of
connected end nodes by making adaptive optimizations of an individual end node’s power levels and data rates.
For example, an end device located close to a gateway should transmit data at a low spreading factor, since very
little link budget is needed. However, an end device located several miles from a gateway will need to transmit
with a much higher spreading factor. This higher spreading factor provides increased processing gain, and
higher reception sensitivity, although the data rate will, necessarily, be lower.
LoRa is purely a physical (PHY), or “bits” layer implementation, as defined by the OSI seven-layer Network
Model, depicted in Figure 3. Instead of cabling, the air is used as a medium for transporting LoRa radio waves
from an RF transmitter in an IoT device to an RF receiver in a gateway, and vice versa.
 

1 There is no one-to-one relationship between LoRa-based devices and gateways in a LoRaWAN network;
messages sent to and from end devices travel through all gateways within range. Deduplication is handled by
the network server.

Figure 3: OSI seven-layer network model

In a traditional or Direct Sequence Spread Spectrum (DSSS) system, the carrier phase of the transmitter signal
changes according to a code sequence as shown in Figure 4. When multiplying the data signal with a pre-
defined bit pattern at a much higher rate, also known as a spreading code (or chip sequence), a “faster” signal is
created that has higher frequency components than the original data signal. This means that the signal
bandwidth is spread beyond the bandwidth of the original signal. In RF terminology, the bits of the code
sequence are called chips (in order to distinguish between the longer, un-coded, bits of the original data signal).
When the transmitted signal arrives at the RF receiver, it is multiplied with an identical copy of the spreading
code used in the RF transmitter, resulting in a replica of the original data signal.
 Figure 4: DSSS system carrier phase transmitter signal changes
You might ask: Why go through all this trouble? Why not just transmit the original data signal instead of going
through this code sequence multiplication? The answer is simple: going through this code sequence
multiplication buys you a higher RF link budget, so you can transmit over a longer range.
The Log10 ratio of the code sequence’s chip rate and the data signal’s bit rate is called the processing gain
(Gp). This gain is what allows the receiver to recover the original data signal, even if the channel has a negative
signal-to-noise ratio (SNR). LoRa has a superior Gp compared to frequency-shift keying (FSK) modulation,
allowing for a reduced transmitter output power level while maintaining the same signal data rate and a similar
link budget.
One of the downsides of a DSSS system is the fact that it requires a highly-accurate (and expensive) reference
clock. Semtech’s LoRa Chirp Spread Spectrum (CSS) technology offers a low-cost and low-power, yet robust,
DSSS alternative that does not require a highly-accurate reference clock. In LoRa modulation, the spreading of
the signal’s spectrum is achieved by generating a chirp signal that continuously varies in frequency, as is
depicted in Figure 5.

Figure 5: LoRa Chirp Spread Spectrum illustration

An advantage of this method is that the timing and frequency offsets between transmitter and receiver are
equivalent, greatly reducing the complexity of the receiver design. The frequency bandwidth of this chirp is
equivalent to the spectral bandwidth of the signal. The data signal that carries the data from an end device to a
gateway is chipped at a higher data rate and modulated onto the chirp carrier signal. LoRa modulation also
includes a variable error correction scheme that improves the robustness of the transmitted signal. For every
four bits of information sent, a fifth bit of parity information is sent.
Key LoRa Modulation Properties
As noted above, LoRa processing gain is introduced in the RF channel by multiplying the data signal with a
spreading code or chip sequence. By increasing the chip rate, we increase the frequency components of the total
signal spectrum. In other words, the energy of the total signal is now spread over a wider range of frequencies,
allowing the receiver to discern a signal with a lower (that is, worse) signal-to-noise ratio (SNR).
In LoRa terms, the amount of spreading code applied to the original data signal is called the spreading
factor (SF). LoRa modulation has a total of six spreading factors (SF7 to SF12). The larger the spreading factor
used, the farther the signal will be able to travel and still be received without errors by the RF receiver.
Table 1 shows the four different spreading factors [SF7…SF10] that can be used for uplink (UL) messages on a
125 KHz channel2. It shows the equivalent bit rate as well as the estimated range (this depends on the terrain;
longer distances will be achieved in a rural environment than in an urban environment). It also shows the dwell
time, or time on air (TOA), values for an 11-byte payload for each of the four spreading factors.
 

2 Downlink messages broadcast over 500 KHz channels can use all six available spreading factors (SF7…
SF12).

Table 1: LoRa Spreading Factors

Importantly, the LoRa modulation spreading factors are inherently orthogonal. This means that signals
modulated with different spreading factors and transmitted on the same frequency channel at the same time do
not interfere with each other. Instead, signals at different spreading factors simply appear to be noise to each
other.
LoRa signals are robust and very resistant to both in-band and out-of-band interference mechanisms. LoRa
modulation also offers immunity to multipath and fading, making it ideal for use in urban and suburban
environments, where both mechanisms dominate. Additionally, Doppler shifts cause a small frequency shift in
the time axis of the baseband signal. This frequency offset tolerance mitigates the requirement for tight
tolerance reference clock sources and, therefore, makes LoRa ideal for data communications from devices that
are mobile.
LoRa Modulation Characteristics
The LoRa modulation characteristics for each region are defined in the LoRaWAN Regional Parameters
document, available from the LoRa Alliance® (https://lora-alliance.org/resource-hub/rp002-100-lorawanr-
regional-parameters). In North America, there are 64, 125 kHz LoRa uplink channels defined, centered on a
200 kHz raster as can be seen in Figure 5. 11. There are eight 500 kHz uplink channels as well as eight, 500
kHz downlink channels defined. In North America, gateways can have up to 64, 125 kHz uplink channels as
well as eight 500 kHz uplink and downlink channels. This type of gateway is referred to as a carrier grade
macro gateway and is used for outdoor applications only.
 Figure 6: LoRa modulation characteristics
Table 2 provides another way to understand these modulation characteristics.
Table 2: LoRa modulation characteristics

 The LoRa physical layer is intended for low throughput, low data rate, and high link budget (i.e., “long-
range”) applications.
 For a fixed channel bandwidth, the higher the spreading factor, the higher the processing gain, resulting
in an increase in sensitivity and, therefore, an increase in link budget. Subsequently, however, the time
on air will also increase.
 Orthogonality between spreading factors allows for the transmission of multiple LoRa signals that are
both on the same channel frequency and in the same time-slot.
 For a fixed SF, a narrower bandwidth will increase sensitivity as the bit rate is reduced.
 LoRaWAN in North America uses 125 kHz uplink channels and 500 kHz uplink and downlink channels
 The Code Rate is the degree of redundancy implemented by the forward error correction (FEC) used to
detect errors and correct them. This rate is fixed at 4/5 for the LoRaWAN protocol
As Stephan Hengstler asserts in his book, A Novel Chirp Modulation Spread Spectrum technique for Multiple
Access, “LoRa is a constant envelope modulation (very low cost, power efficient power amplifier
implementation) … [it] is the most robust, ultra-low power and long range RF solution available.”
Data Collisions and Spreading Factor Orthogonality
With LoRa, packets using different spreading factors are orthogonal, meaning that they are invisible to each
other: as mentioned earlier, they simply appear as noise to one another. Therefore, two packets that arrive at the
same time on the same receive channel at different spreading factors will not collide and, both will be
demodulated by the gateway modem chip. However, two packets with the same spreading factor arriving at the
same time on the same channel might result in a collision. However if one of the two packets is stronger by six
dB, it will survive.
The capacity of a LoRaWAN network is a function of its gateway density. To maximize the capacity of the
network, using an adaptive data rate (ADR) mechanism is essential. The main goal of ADR is to save the
battery power of the LoRaWAN end-nodes. By having the end-nodes closest to a gateway transmit using the
lowest spreading factor, their time on air is minimized, thereby prolonging their battery life. More distant
sensors transmit at a higher spreading factor. A trade-off is made between battery power and distance given that
a higher spreading factor allows for a gateway to connect to devices that are farther away.
LoRaWAN Network Fundamentals
To fully understand LoRaWAN networks, we will start with a look at the technology stack. As shown in Figure
7, LoRa is the physical (PHY) layer, i.e., the wireless modulation used to create the long-range communication
link. LoRaWAN is an open networking protocol that delivers secure bi-directional communication, mobility,
and localization services standardized and maintained by the LoRa Alliance.

Figure 7: LoRaWAN technology stack

LoRaWAN Network Elements: An Introduction
Now that we have a basic understanding of LoRa, we will examine the architecture of a LoRaWAN network.
Figure 8 shows a typical LoRaWAN network implementation from end to end.
 Figure 8: Typial LoRaWAN network implementation
Let us examine this diagram in smaller pieces.
LoRa-based End Devices

Figure 9: End devices in a typical LoRaWAN network deployment

A LoRaWAN-enabled end device is a sensor or an actuator which is wirelessly connected to a LoRaWAN
network through radio gateways using LoRa RF Modulation.
In the majority of applications, an end device is an autonomous, often battery-operated sensor that digitizes
physical conditions and environmental events. Typical use cases for an actuator include: street lighting, wireless
locks, water valve shut off, leak prevention, among others.
When they are being manufactured, LoRa-based devices are assigned several unique identifiers. These
identifiers are used to securely activate and administer the device, to ensure the safe transport of packets over a
private or public network and to deliver encrypted data to the Cloud.
LoRaWAN Gateways
 Figure 10: Gateways in a typical LoRaWAN network deployment
A LoRaWAN gateway receives LoRa modulated RF messages from any end device in hearing distance and
forwards these data messages to the LoRaWAN network server (LNS), which is connected through an IP
backbone. There is no fixed association between an end device and a specific gateway. Instead, the same sensor
can be served by multiple gateways in the area. With LoRaWAN, each uplink packet sent by the end-device
will be received by all gateways within reach, as illustrated in Figure 10. This arrangement significantly reduces
packet error rate (since the chances that at least one gateway will receive the message are very high),
significantly reduces battery overhead for mobile/nomadic sensors, and allows for low-cost geolocation
(assuming the gateways in question are geolocation-capable).
The IP traffic from a gateway to the network server can be backhauled via Wi-Fi, hardwired Ethernet or via a
Cellular connection. LoRaWAN gateways operate entirely at the physical layer and, in essence, are nothing but
LoRa radio message forwarders. They only check the data integrity of each incoming LoRa RF message. If the
integrity is not intact, that is, if the CRC is incorrect, the message will be dropped. If correct the gateway will
forward it to the LNS, together with some metadata that includes the receive RSSI level of the message as well
as an optional timestamp. For LoRaWAN downlinks, a gateway executes transmission requests coming from
the LNS without any interpretation of the payload. Since multiple gateways can receive the same LoRa RF
message from a single end device, the LNS performs data de-duplication and deletes all copies. Based on the
RSSI levels of the identical messages, the network server typically selects the gateway that received the
message with the best RSSI when transmitting a downlink message because that gateway is the one closest to
the end device in question.

Figure 11: Gateways receiving and transmitting messages from end devices
Furthermore, LoRa allows for scalable, cost-optimized gateway implementation, depending on deployment
objectives. For example, in North America, 8-, 16-, and 64-channel gateways are available.
The 8-channel gateways are the least expensive. The type of gateway needed will depend on the use case.
Eight- and 16-channel gateways are available for both indoor and outdoor use. Sixty-four channel gateways are
only available in a carrier-grade variant. This type of gateway is intended for deployment in such places as cell
towers, the rooftops of very tall buildings, etc.
Network Server

Figure 12: LoRaWAN Network Server in a typical LoRaWAN network deployment

The LoRaWAN network server (LNS) manages the entire network, dynamically controls the network
parameters to adapt the system to ever-changing conditions, and establishes secure 128-bit AES connections for
the transport of both the end to end data (from LoRaWAN end device to the end users Application in the Cloud)
as well as for the control of traffic that flows from the LoRaWAN end device to the LNS (and back). The
network server ensures the authenticity of every sensor on the network and the integrity of every message. At
the same time, the network server cannot see or access the application data.
In general, all LoRaWAN network servers share the following features:
 Device address checking
 Frame authentication and frame counter management
 Acknowledgements of received messages
 Adapting data rates using the ADR protocol
 Responding to all MAC layer requests coming from the device,
 Forwarding uplink application payloads to the appropriate application servers
 Queuing of downlink payloads coming from any Application Server to any device connected to the
network
 Forwarding Join-request and Join-accept messages between the devices and the join server
Application Servers
Application servers are responsible for securely handling, managing and interpreting sensor application data.
They also generate all the application-layer downlink payloads to the connected end devices.

Figure 13: LoRaWAN Application Server in a typical LoRaWAN network deployment

Join Server
The join server manages the over-the-air activation process for end devices to be added to the network.
The join server contains the information required to process uplink join-request frames and generate the
downlink join-accept frames. It signals to the network server which application server should be connected to
the end-device, and performs the network and application session encryption key derivations. It communicates
the Network Session Key of the device to the network server, and the Application Session Key to the
corresponding application server
 

Figure 14: LoRaWAN Join Server in a typical LoRaWAN network deployment

For that purpose, the join server must contain the following information for each end-device under its control:
 DevEUI (end-device serial unique identifier)
 AppKey (application encryption key)
 NwkKey (network encryption key)
 Application Server identifier
 End-Device Service Profile
LoRaWAN Network Elements: Device Commissioning
For the sake of security, quality of service, billing, and other needs, devices must be commissioned and
activated on the network at the start of operation. The commissioning process securely aligns each device and
the network with respect to essential provisioning parameters (such as identifiers, encryption keys, and server
locations)
The LoRaWAN specification allows for two types of activation: Over-the-Air Activation (OTAA) (preferred)
and Activation by Personalization (ABP). Table 2 shows the different characteristics of each of these types of
activation.
Table 3: Activation Types

LoRaWAN Network Elements: Security

There are two key elements to the security of a LoRaWAN network: the join procedure and message
authentication. The join procedure establishes mutual authentication between an end device and the LoRaWAN
network to which it is connected. Only authorized devices are allowed to join the network. LoRaWAN MAC
and application messages are origin-authenticated, integrity-protected and encrypted end-to-end (i.e., from end
device to the application server and vice versa).
These security features ensure that:
 Network traffic has not been altered
 Only legitimate devices are connected to the LoRaWAN network
 Network traffic cannot be listened to (no eavesdropping)
 Network traffic cannot be captured and replayed
With that foundation, we will take a look at the LoRaWAN security measures in more detail.
The Join Procedure
We will begin with the security keys, as illustrated in Figure 15. Individual root keys are securely stored on the
end devices, and matching keys are securely stored on the join server.

Figure 15: Security keys generated during the Join procedure

The end device sends a join request message to the join server, as illustrated in Figure 16.

Figure 16: Sending a join request message to the join server

After the join server authenticates the device requesting to join the network, it returns a join accept message to
the device, as illustrated in Figure 17.
 Figure 17: Sending a join accept message to an end device
Next, the end device derives session keys locally, based on the DevEUI, Join EUI, DevNonce, root keys and
fields in the join request and join accept messages. On its end, the join server also derives session keys from the
serial IDs, root keys and fields in join requests and join accept messages. Finally, the join server shares session
keys with network and application servers, as illustrated in Figure 18.

Figure 18: Session keys are shared with the network server and the application server
Figure 19 illustrates the security of data packet transmissions. The control traffic between the end device and
the network server is secured with a 128-bit AES Network Session Key (NwkSKey). The data traffic that
travels between the end device and the application server, is secured with a 128-bit Application Session Key
(AppSKey). This method ensures that neither the gateway nor the network server can read the user data.
 Figure 19: Secure transmission of data packets
Device Classes: A, B and C
LoRa-based end devices may operate in one of three modes, depending on their device class. All such devices
must support Class A operation. Class B devices must support both Class A and Class B modes, and Class C
devices must support all three modes of operation. These modes of operation have to do with how the devices
communicate with the network.
Class A Devices
Figure 20 shows how the Class A mode of operation works.

Figure 20: Class A operation

In this case, the end device spends most of its time in an idle state, (that is, in sleep mode). When there is a
change in the environment related to whatever the device is programmed to monitor, it wakes up and initiates
an uplink, transmitting the data about the changed state back to the network (Tx). The device then listens for a
response from the network, typically for one second (although this duration is configurable). If it does not
receive a downlink during this receive window (Rx1), it briefly goes back to sleep, waking a moment later,
again listening for a response (Rx2). If no response is received during this second Rx window, the device goes
back to sleep until the next time it has data to report. The delay between Rx1 and Rx2 is configured in terms of
a delay from the end of the uplink transmission.
Note: There is no way the application of the end device can wake up a Class A device. Given this limitation,
Class A devices are not suitable for actuators.
Figures 21, 22 and 23 illustrate these communication patterns.

Figure 21: Class A operation when nothing is received

Figure 22: Class A operation when a data packet is received in the first receive window

Figure 23: Class A operation when a data packet is received in the second receive window
Note: A device will not try to send another uplink message until either:
1. It has received a downlink message during Rx1, or
2. The second receive window following the last transmission is complete
Class B Devices
An enhancement of Class A, LoRaWAN Class B mode offers regularly-scheduled, fixed-time opportunities for
an end device to receive downlinks from the network, making Class B end devices suitable for both monitoring
sensors as well as actuators. All LoRa-based end devices start in Class A mode; however, devices programmed
with a Class B stack during manufacturing may be switched to Class B mode by the application layer.
End devices in Class B mode provide for regularly-scheduled receive windows, in addition to those that open
whenever a Class A-style uplink is sent to the server.
1.1.1.1        Class B Beacons
For the Class B mode of communication to work, a process called beaconing is required. During the beaconing
process, a time-synchronized beacon must be broadcast periodically by the network via the gateways, as
illustrated in Figure 24. The end device must periodically receive one of these network beacons so that it can
align its internal timing reference with the network.
 Figure 24: Class B beaconing operations
Devices use beacons to derive and align their internal clocks with the network. Devices do not need to process
every beacon if the device is already aligned. In most cases, realigning several times a day is sufficient, with a
minimal impact on battery life, as illustrated in Figure 25.

Figure 25: Periodic Class B beaconing for device synchronization

Based on the beacon’s timing reference, end devices can open receive windows (ping slots) periodically. Any
of these ping slots may be used by the network infrastructure to initiate a downlink communication, as shown in
Figure 26. In order for a LoRaWAN network to support Class B devices, all the LoRaWAN gateways in this
network need to have a built-in GPS timing source, so they all can be synchronized to the exact beacon timing.
 Figure 26: Class B ping slots
Note: Class B devices can also operate in Class A mode.
Class C Devices
Class C are always “on”; that is, they do not depend on battery power. Class C devices include such things as
street lights, electrical meters etc. These devices are always listening for downlink messages, unless they are
transmitting an uplink. As a result, they offer the lowest latency for communication from the server to an end
device.
Class C end devices implement the same two receive windows as Class A devices, but they do not close the
Rx2 window until they send the next transmission back to the server. Therefore, they can receive a downlink in
the Rx2 window at almost any time. A short window at the Rx2 frequency and data rate is also opened between
the end of the transmission and the beginning of the Rx1 receive window, as illustrated in Figure 27.

Figure 27: Class C operation

The LoRa Alliance
With more than 500 member companies, the LoRa Alliance is one of the fastest-growing technology alliances.
A community of innovators, the LoRa Alliance is committed to standardizing low power wide area networks
(LPWANs). To this end, the group provides the LoRaWAN Specification (https://lora-
alliance.org/search/specification) free of charge. The specification is based on open standards and provides for
certified interoperability.
The LoRa Alliance also offers the LoRaWAN Certification Test Tool, to help manufacturers ensure that their
devices are fully LoRaWAN-compatible prior to sending those devices to an Authorized Test House for formal
LoRaWAN Certification testing.
For more information on the LoRa Alliance, visit their website: https://lora-alliance.org.
This document is a theoretical analysis of a LoRaWAN® network trial performed by MachineQ and Semtech in
Philadelphia in 2017. The trial consisted of 10 indoor gateways and 108 indoor devices in an urban
environment. The goal of the trial was to demonstrate the network capacity of LoRaWAN.
During the trial, devices sent approximately one million frames, over two days. The network load was set to
various levels. The success rate evolved accordingly and was always higher than 96 percent.
From the analysis, we show that closed-form formulas can predict capacity accurately. We also show that these
formulas can replace long simulations.
Signal Levels
First, let’s analyze the statistics related to the received signal strength. For each frame we have access only to
the highest RSSI received. If more than one gateway receives the frame correctly, we know the number of
gateways which received the signal, but not the individual RSSI for each gateway. Since LoRa® operates
below the noise floor, the RSSI itself can be lower than the noise floor, which is approximatively -120dB.
We also know the data rates used. This test was conducted in the US region, so only SF7, SF8, SF9 and SF10
were used (not SF11 nor SF12).
Figure 1 shows the RSSI distribution of correctly received frames. The legend for each curve indicates the
proportion of frames which follow this distribution, the average RSSI (in dBm), and the standard deviation of
RSSI (in dB). For instance, 30.7% of frames are received by exactly 3 gateways; when this occurs the average
RSSI is -103.7dBm and the standard deviation of RSSI is 5.9dB.

Figure 1: Signal Level Distribution of Received Frames

We see that most frames were received by two or three gateways. The number of gateways receiving a signal
depends on how the LoRa Network Server (LNS) configures the Adaptive Data Rate (ADR). Different ADR
settings can have different redundancy targets leading, for instance, to a lower ratio of single gateway
receptions. Here 17% of frames are received by a single gateway.
The next figure is an attempt to model the cases of one, two, three, and four gateways receiving the signal, in
comparison to just one. The blue curve shows the mean and standard deviation, and models the single receiving
gateway case with a Gaussian distribution with same mean and standard deviation. We then model the case of
two receiving gateways with a maximum of two independent Gaussian variables. For three gateways we take a
maximum of three, etc.
 Figure 2: RSSI Comparison - One Gateway and Multiple Gageways
We see that there is a good fit between the oberved data and the modeled curves, whatever the number of
receiving gateways (i.e. the plain lines match the dotted lines). This means that modeling the RSSI by a
gaussian variable is valid, and when a signal is received over several gateways each RSSI is independant. There
is a peak in the observation at -102dBm, which corresponds to a measurement bias. This bias comes from a
rounding error of the gateway which makes -102dBm twice as likely as -101 or -103.
Orthogonality Factor
Interference Levels Observed in Measured Data
Data rates orthogonality is a shortcut for expressing that different data rates can coexist. Indeed, assuming data
rates are different, an aggressor frame will affect a victim frame only as much as white noise would. Since
LoRa data rates can be received with negative signal-to-noise ratios (SNR), frames with different data rates can
be received at the same time. Table 1 shows the required SNRs for each data rate. These numbers correspond to
first-generation LoRa demodulators, the second generation is 1dB better.
Table 1: Data Rates and Required Signal-to-Noise Ratios

In addition, for same data rate interference, when there is a signal level difference higher than 7dB, the
strongest frame is received correctly. This holds true when the coding rate is 4/5, normal interleaving, which is
the LoRaWAN default LoRa PHY configuration.
Next, we plot the measured RSSI distribution per data rate. On the same plot, we will also show the traffic load
versus time. While the traffic load varies over time, the data rate ratios remain constant, as does the RSSI
distribution per data rate. The set-up is tested with a single data rate (SF10), then the first load level is tested
from hours 7 to 18, a higher load from hour 19 to 30, and the highest load from hour 31 to 45.
 Figure 3: RSSI Distribution per Data Rate and Traffic Load over Time
From this distribution, and the table above, we can compute the probability that a time overlap of frames yields
the loss of a frame. The distribution is simplified to four random Gaussian variables with same mean and Sigma
as the observed distribution. We report this in a matrix, with columns representing the aggressing data rate, and
lines the victim data rate.
Table 2: Orthogonality Matrix

This table shows that if a frame transmitted using SF8 is overlapped by an SF10 frame while being received by
a gateway, there is a six percent probability that the SF8 frame will not be received correctly. Thus, there is a 94
percent probability that the gateway will receive the frame correctly.
If the orthogonality were perfect, there would be a zero percent error rate for overlaps, except on the diagonal.
In this dataset, the RSSI measures are incomplete because we only have access to the best RSSI among all
receiving gateways of each frame. It is difficult to determine how different the orthogonality matrix would be
with a complete set of measures.
Orthogonality Factor Simulation
Let’s look at a slightly different scenario, one with indoor/deep indoor nodes, and outdoor gateways. The
simulation uses 660 gateways with a density of 1.5 gateways per square kilometer (950 m site distance). 
100,000 nodes are spread on the grid, and propagation to each gateway is simulated using the Hata model1 for a
small-to-medium city, with shadowing, fast fading, and indoor penetration losses distributed from 20dB to
40dB. The path loss exponent value here is 3.6.
Spreading factors SF7 through SF12 are used in this example. Here, we apply an Adaptive Data Rate (ADR)
and Transmit Power Control (TPC) strategy with a margin of 8dB to account for fast fading. The range of TPC
is 20dB, i.e. once the fastest data rate is reached, the transmitted power can be reduced by up to 20dB.
1
 https://en.wikipedia.org/wiki/Hata_model

 
To compute the orthogonality matrix, we consider the gateways in the center, and gather the distribution of
RSSI for each data rate. Then we proceed as with the measured data: for each couple of spreading factors,
(victim SF, aggressing SF), we derive the probability that the aggressing SF RSSI is too high for the victim
frame to be received. This probability is probability of (RSSI_aggressor > (RSSI_victim -
victim_required_sinr).  For instance, if victim is SF12, and aggressor SF7, this is probability:
 .
This probability is computed as:

Table 3: Simulated Orthogonality Matrix

This matrix is slightly different than that shown in Table 2, which relies on incomplete measures. We can note,
however, that if we remove the diagonal, the sum of each line is roughly the same. Given this information, we
can see that ADR and power control tend to give devices with a higher RSSI a higher data rate, which means
these devices have a better chance of creating errors in case of a collision.
In this MachineQ and Semtech trial, there is no ADR; each physical device emulates traffic from several virtual
devices, using the four data rates.
Interference Levels Inferred from Simulated Data
The measured data is generated from a relatively small network, with only 10 gateways in the same
neighborhood. Thanks to the simulation, we can estimate how much additional noise comes from devices that
are not in range of a given gateway. Collisions can be classified as one of two types: collisions from frames that
can be received by the gateway we consider, or collisions from frames that are out of the coverage area.
Next, using the simulation above, let’s consider a central gateway and count the devices in range, along with
the data rate at which they operate. We then define three channel load levels: 10 percent, 100 percent, and 400
percent. The 400 percent load means that on average, on each LoRa channel, four transmissions of in-range
devices occur. For each channel load, we derive the duty cycle required to achieve the load specified for the in-
range devices, assuming an identical rate of frames per device, whatever their data rate. Last, we apply the same
duty cycle to the devices that are not in range, and measure the average power received by the central gateway
from these devices. We compute this sum over different disk sizes, to check whether the integral converges.
The result is plotted in Figure 4. We compare this average interference level to the thermal noise floor. This
thermal noise floor is experienced by any receiver, and values at normal temperature are -114dBm/MHz + NF,
where NF is the noise figure of the receiver. In our case, the bandwidth is 125KHz, and typical NF is 3dB for a
gateway, so receiver noise floor is -114dBm/MHz+10*log10(0.125MHz)+3dB = -120dBm.

Figure 4: Average Interference levels from Out-of-Range Devices

First we see that the integral converges.
This convergence is expected, since the path loss exponent (PL) is higher than 3. To explain this point, let us
note itf(r), the total interference level from devices within a disk of radius r.  It is computed with:
 ,
where K is a constant that depends on node density, transmit power, and average impact of shadowing and fast
fading. Such an integral converges as r grows if PL-2>1, i.e. PL>3.
In addition to convergence,we also see that a two kilometer radius is enough to gather most of the interference
from devices which are out of range of the gateway.
Second, it is clear that the average interference level coming from devices not in range is lower than the thermal
noise, even at a high network load. This shows that we can neglect the interference from out of range devices,
as such interference does not increase the average noise floor.
Of course, the instantaneous interference power might be higher. Taking a disc radius of two kilometers, we
count seven times more un-connected devices than connected devices. This means that at a load of 400 percent
there are, on average, 28 simultaneous transmissions from out-of-range devices that contribute to the
interference level. The maximum interfering power from a single device corresponds to an SF7 transmission,
which would be just below SF7 receiving sensitivity, i.e. -130dBm.
Prediction of Collisions and Packet Error Rate (PER)
Collision Probability in Random Access (ALOHA)
The usual formula for calculating the probability of collision is:
Pcol = 1-exp(-load*2)
Where load is the offered load. This assumes that when a time overlap occurs, both frames are lost. This also
assumes that all frames have equal length.
A more generic formula can be used, assuming that the length of victim and aggressor frames are different. We
call it the probability of time overlap, rather than collision, because a time overlap does not always result in lost
frames.
Povlap=1-exp(-load_interferer * (1+length_victim/length_interferer)
When length_victim is null, we go to the known formula of probability that channel is occupied, at any instant.
When length_victim equals length_interferer, we go to the classic formula.
Last, if length_victim tends to infinity, the probability of overlap tends to 1, whatever the load of the interferer
might be.
Single Gateway Packet Error Rate
Let’s compute the load per gateway, i.e. the traffic each gateway receives.
The frames all have 8 bytes of LoRaWAN payload, Table 4 below shows their duration.
Table 4: Load Per Gateway, by Spreading Factor

We cannot directly observe the offered load for each gateway because some packets are lost and because the
logs only provide the number of receiving gateways, rather than the gateway IDs. Figure 5 shows the total
number of received frames, without duplicates, over time. From these curves, we then derive the spreading
factor distribution, to check whether it is relatively constant over time.

Figure 5: Packet Count per Hour and Data Rate Distribution

Next, we derive the load for the network, noting that the load is evenly spread over eight channels. Figure 6
shows the load for each channel.
 Figure 6: Channel Load
Now we compute the average load for the three steps of the trial, as shown in Table 5.
Table 5: Average Load

From the load, we compute the probabilities of overlap. For each phase, there are four probabilities for each
data rate. Here, we take the example of Phase 3, and report the overlap probabilities in Table 6.
Table 6: Overlap Probabilities

Not all time overlaps result in reception errors. We can now use the pseudo orthogonality matrix to multiply,
term by term, the overlap probabilities. This gives the collision probability. The sum of each line is the total
probability of collision, from all data rates. We report the collision rate, for a single gateway, in Table 7. We
see that, compared to Table 6, the diagonal terms are slightly reduced, while the non-diagonal terms are reduced
a considerable amount, thanks to the orthogonality of the various spreading factors.
Table 7: Collision Rate Probability for a Single Gateway

Network Packet Error Rate of a Frame

To determine the network PER, we compute the gateway redundancy from the received packets. We then
assume that this redundancy is very close to what it would be without collisions. (This is backed by the fact that
the redundancy is stable during the three stages of the trial.)
 Figure 7: Average Reception Redundancy
Instead of taking the redundancy directly, we subdivide it by the single receiving gateway case, the two
gateways case, the three gateways case, etc. The final results come from the weighted average of the probability
of these distinct cases.
To give a simplified example, let’s assume that 30% of frames are received by a single gateway, 50% by two
gateways, and 20% by 3 gateways. The network level probability of error per packet PER_nwk, from a gateway
level probability PER_gw, will be: PER_nwk = 0.3*PER_gw + 0.5*(PER_gw)^2 + 0.2*(PER_gw)^3. 
This gives the following collision probabilities for each SF for the third stage of the trial.
Table 8: Collision Probabilities for Stage 3 of the Trial

We see that this closely matches our observations.

Prediction of Collisions and Packet Error Rate – Simulated Network
We now show that this method can be applied to a simulated network. We start with a propagation and ADR
simulation, then we compare the results from an explicit collision simulator and the closed formulas described
above.
The explicit collision simulator creates a time grid, adds frames to this grid, computes received signal levels for
all gateways at each time instant, then computes the PER from each frame’s SINR. The load is varied, so the
end result is the system PER as a function of load. The load unit is the number frames per hour per gateway.
This number is the total number of frames divided by the number of gateways, so that multiple receptions have
no impact on our definition of load.
The method using closed form formulas starts with the same propagation and ADR simulation. This gives
signal levels and data rates for all simulated devices. From these we compute the orthogonality matrix. Then,
for each load, we compute overlapping probabilities and collision probabilities at the gateway level. Last, from
the reception redundancy for each spreading factor, which is also an output of the propagation and ADR
simulation, we derive the PER at the network level.
The comparison of two methods is shown inFigure 8.

Figure 8: Derived Collision Rate versus Load

The dotted green line indicates that the ADR is worse. The ADR margin is raised from 5dB to 8dB, meaning a
higher average redundancy (1.8 compared to 1.4 gateways), and the TPC is reduced from 20dB to 15dB. The
primary effect of this is to increase the load of the lowest data rate. The propagation model here assumes
placement of devices indoors/deep indoors (20dB to 40dB penetration losses). We also expect the devices to be
static, so a low margin of 5dB is reasonable. SF12 devices have a higher redundancy than average: 1.9
gateways at 5dB ADR margin.
Figure 9 shows the result of another simulation, where we see that the PER depends on the data rate. Low data
rates tend to have a higher PER.
 Figure 9: Data Rate and Corresponding PER
From this curve, we can see that from a capacity perspective, message repetition is a good strategy. For
instance, looking for a PER=1%, the  maximum load is 10,000 messages per hour. This means that with a
single transmission, 10,000 messages per hour can be transmitted to achieve a PER of 1%.
To achieve 1% PER after two transmissions, the single transmission PER target becomes 10%, this is because
frames are independent from the point of view of collisions, therefore the probability of losing 2 frames is
(10%)^2 = 1%. 10% PER for single transmissions corresponds to 110,000 messages per hour, or 55,000 unique
messages with double transmission. Last, triple transmission corresponds to 21.5 percent PER, as (0.215)^3 =
1%, and a unique load of ~240,000/3 = 80,000 messages per hour.
Repetition, therefore, increases capacity for a given Quality of Service (QoS) target. Of course, it is possible to
adjust the repetition rate to the device data rate. Delay between successive transmissions does not matter.
It is also possible to use a Forward Error Correction on groups of messages, which is a generalization of
messages repetition. This trades PER for delay, and considerably reduces the overhead when compared to
systematic repetition. For applications that are not delay-sensitive, this is the solution of choice.
Introduction
Being able to perform remote firmware upgrades over-the-air (FUOTA) is becoming a requirement for most
Internet of Things (IoT) devices. The details of any FUOTA procedure are tightly linked to the MCU
architecture used by the device. However, any FUOTA system requires an efficient and secured file delivery
system to reliably push the firmware patch file to (potentially) many devices simultaneously. LoRaWAN®
provides such a secured and reliable file distribution system using multicast. This service is provided by a set of
application layer packages. This paper presents two of those packages, which form the basis of the LoRaWAN
file distribution service: the “Remote Multicast Setup” package and the “Fragmented Data Block Transport”
package.
Updating Firmware Over-the-Air
Updating firmware over-the-air is a complex task. Generally, the following steps are involved:
1. Identifying the devices that need to be updated and putting them in multicast groups
2. Generating a binary firmware patch file specific to the device platform to be upgraded
3. Signing this binary file with a private key to guarantee integrity and authenticity
4. Pushing the binary file to the group of devices to be upgraded
5. Each device verifies the signature to authenticate the file and its origin
6. Each device then installs the firmware update
7. Each device reports the status of the upgrade operation (success or failure). This information is collected
by a device management platform which is used to monitor the status of the devices in the field.
Some of these steps (2, 3, 5, and 6) are very device-specific, and depend on many design choices, including but
not limited to:
 Device MCU architecture (ARM, X86, etc.)
 Device memory capacity
 Whether or not the device uses an operating system
 Whether or not the device uses a secure boot-loader
 Whether or not the device firmware was designed for partial updates
 Whether or not the device features a cryptographic hardware accelerator
Such constraints make it impossible to standardize a FUOTA process that will work for every device in every
LoRaWAN network. An additional challenge is the low bit rate intrinsic to LoRaWAN networks.
However, efficient and reliable transport to push firmware patches to a large group of devices through a
LoRaWAN network is possible. Furthermore, LoRaWAN has a radio multicast capability. This means that a
given radio packet transmitted by the network (containing a fragment of the firmware patch) may be received
by many devices. This way, the patch file does not need to be transmitted individually to each device. FUOTA
over LoRaWAN overcomes the low-bit rate issue by transmitting the patch file to all devices at once.
Firmware Updates with LoRaWAN
With LoRaWAN, there are two primary application layer packages for FUOTA:
 Multicast remote setup
 Fragmented data block transport
These application-layer packages are defined by the FUOTA Working Group within the LoRa Alliance®. The
specifications are publically available on the LoRa Alliance website.
 Figure 1: LORAWAN APPLICATION LAYER PACKAGES FOR FUOTA
On the device side, these packages live at the application layer and use the LoRaWAN MAC layer to transmit
and receive packets to and from the network. Additionally, other packets may coexist at the device application
layer, and generally some user application code will be present as well.
Each package on the device corresponds to a service implementation on the server side. For example, the
“clock synchronization” package communicates with a clock synchronization service implemented on the back
end. In Figure 1, all back end services related to FUOTA are grouped together in a single instance called the
“Device Management Service.” Each of these packages uses a different port to communicate over the air. This
way, the different data streams that correspond to each package can easily be separated in both the uplink and
downlink directions.
LoRaWAN Multicast Group
The first step in updating firmware over-the-air in a LoRaWAN network is to identify and list the devices that
need to be updated and place them into a LoRaWAN multicast group. This group can be created dynamically
and be set up over the air. To do this, use the functions offered by the “Remote Multicast Setup” package.
Remote Multicast Setup Package
Every device in a LoRaWAN-based network is equipped with a unicast identity consisting of a device address
(32 bits) and a unicast security context (a set of AES128 keys) that are used to uniquely identify and
authenticate the device on the network.
Such a device may also belong to as many as four multicast groups. Multicast groups have the following
characteristics:
 A multicast group address
 A multicast security context
o McAppSKey: a multicast application key used to encrypt the payloads delivered to the group
o McNwkSKey: a multicast network session key used to compute the Message Integrity Check
(MIC) field of the packets that are sent to the group
 A multicast frame counter
If a device is part of more than one multicast group, the addresses of those groups must be distinct in order to
differentiate among them.
The multicast security context is identical for all devices belonging to a given group; however, different
multicast groups have different security contexts. They must also use different keys.
The “Remote Multicast Setup” package offers commands allowing the following operations:
1. Querying the package’s implementation version
2. Querying the list and status of the multicast groups to which a device has been assigned
 3. Creating or modifying a multicast group for a given device
4. Deleting a multicast group definition from a device
5. Defining a Class B or Class C broadcast session and associating it with a multicast group
The McGroupSetup command allows you to create the complete context of a multicast group for a given
device. This command embeds a mechanism to securely transport the multicast group keys over the air. This is
achieved by transporting the multicast keys that are encrypted using a device-specific transport key. It also
provides the minimum and maximum valid frame counter values and improves the security of the process by
essentially limiting the lifetime of a multicast group.
Creating the context, however, is not sufficient for operating a multicast group.
LoRaWAN-based devices are low power and rely on a battery. These devices normally wake up only when
they have data to transmit and then immediately go back to sleep. Therefore, to be able to transmit a frame to an
entire group of devices, the system must first make sure that all of the devices within the multicast group have
their receivers active at the same time and for the same duration.
To address the issue of ensuring that the receivers are all active at the same time, LoRaWAN networks use the
GPS time (GPS epoch) as a time reference (This was chosen over UTC time because GPS time can be
represented simply by an unsigned 32-bit counter, incremented by exactly 1 every second, independent of leap
seconds. For an in-depth understanding of leap seconds, see https://en.wikipedia.org/wiki/Leap_second).
There are different ways to synchronize the clocks of LoRaWAN-based devices to the network’s time:
1. The device may periodically query the network time using the corresponding MAC layer command
(The DeviceTimeReq command is available in the LoRaWAN specification version 1.0.3 and later)
2. The device may listen for the periodic Class B beacon, which contains the GPS time
3. The device may use a dedicated package called “Application Layer Clock Synchronization”
The decision of which techniques to use will be based on the trade-offs of power consumption, application
requirements, and timing precision. A discussion of these trade-offs is beyond the scope of this document.
Once the device clocks are synchronized, the Device Management Service must program the devices to open
their receivers simultaneously, and to use the same radio channel and data rate. For this purpose, the Remote
Multicast Setup package allows you to define either a Class C or Class B multicast session.
Class C multicast sessions are defined by a start time, a duration, and a set of radio parameters (channel and
data rate). When the devices’ clock time reaches the start time, the device programs its radios using the
designated radio parameters and they turn on their receivers. The network can then broadcast packets using the
same radio parameters at any moment during the Class C session.
This method is simple and does not require a very accurate timing synchronization. A few seconds of drift
among devices will not create any issues. However, for the duration of the Class C session, the devices in the
group leave their receivers on continuously. Therefore, this method is not power-efficient in regions where the
network is obliged to respect a low transmission duty cycle (for example, less than ten percent in Europe). A
ten percent duty cycle means that 90 percent of a device’s energy is wasted during a Class C multicast session.
This being the case, the package also supports using Class B multicast sessions. When a Class B multicast
session is used, all the devices in a group must first synchronize with the Class B beacon (which broadcasts
every 128 seconds) before the session starts. Once the session has begun, the devices in the group open periodic
reception slots simultaneously, and they stay open for the duration of the session. This enables the devices to
duty-cycle their receivers while still spending most of their time asleep.
Note: The network might not use every one of the available slots to transmit information. However, Class B
mode is slightly more complicated to implement than Class C, and requires the network to broadcast the Class
B beacon.
LoRaWAN is one of very few radio protocols that enables true multicast transmission over the air. For
example, Cellular networks emulate multicast transmissions by setting up as many simultaneous unicast
sessions as there are devices in a group. However, in this scenario, the data is actually sent as many times as
there are devices in the group, rather than just once.
The Multicast Remote Setup package does not make any assumptions about the nature of the data frames being
transmitted by the network during a Class C or Class B multicast session. The data frames, for instance, could
be individual control frames (ones that turn an entire group of streetlights on and off, for example).
Therefore, during a multicast session, it is necessary to implement a means of efficiently fragmenting a file and
ensuring complete delivery to every device in the group. To this end, the ”Fragmented Data Block Transport
over LoRaWAN” package has been created. We will discuss this in the next section.
Transporting a File to a Multicast Group
The use of radio multicast transmissions improves the efficiency of the network tremendously. Each frame is
transmitted only once, and can be received by all devices in the group simultaneously, rather than having to
transmit the same frame individually to each device. However it comes with a challenge, namely, coping with
missed receptions. Consider the following example:
A network broadcasts 100 fragments of a file to a group of 1,000 devices assembled in a single multicast group.
The radio channel experiences interference, causing each device to randomly lose ten percent of the frames that
are broadcast by the network. If the network were transmitting to a single device (unicast transmission) this
would not be a big deal. In this case, while a fragment might need to be repeated when lost (which occurs about
ten percent of the time) on average it would take 110 transmissions to successfully push 100 data fragments to a
device.
However, this is more complicated in a multicast group. The first fragment broadcast by the network, on
average, is received by 900 of the 1,000 devices. This means that 100 devices do not receive the first fragment.
Therefore, the network transmits it again, this time (on average) ten of the remaining 100 devices will receive
it. The network transmits the fragment for a third time, and one device will likely still miss it. So, on average, it
takes approximately four transmissions of the same data to ensure that all devices receive the complete
fragment. This number only grows if the number of devices in the group or the error rate are increased.
Thus, a different method must be used to guarantee that all devices receive the full file without having to repeat
every fragment multiple times.
To overcome this problem, the “Fragmented Data Block Transport” package implements an erasure correction
code. The principle behind this approach is this:
1. The file to be sent is fragmented into N equal-length fragments, such that each fragment can fit in a
single LoRaWAN broadcast payload. In the case of our example, N = 100 fragments of equal length.
2. For those N uncoded fragments, the erasure code is used to generate N + M coded fragments, where
(N + M)/N is the redundancy ratio. That redundancy ratio must be greater than the packet loss rate we
want to compensate for, plus a margin. In our example, assuming a typical ten percent packet lost rate, a
20 percent redundancy ratio would be appropriate.
3. Those coded fragments are designed in such a way that any subset of N coded fragments out of the (N +
M) generated fragments can be used to rebuild the N original file fragments, and therefore ensure
transmission of the complete file.
Again, in the case of our example, the Device Management Service would divide the file into 100 fragments
and generate 120 coded fragments. Those 120 coded fragments are then broadcast by the network during a
Class C or Class B multicast session. Every device listening may lose a different subset of fragments during the
session. However, as soon as a device receives at least 100 coded fragments out of the 120 that are broadcast by
the network, the device is able to reconstruct the complete file.
Where the repetition method would lead to broadcasting 400 frames, using this coding scheme allows the
network to achieve the same success rate while broadcasting only 120 frames.
In addition to the required coding/decoding methods just described, the “Fragmented Data Block Transport”
package provides the following functionality:
 Querying the implementation version of the fragmentation package
 Creating a fragmentation session
 Requesting a device or group of devices to provide the status of a fragmentation session
 Deleting a fragmentation session
Prior to sending a file to a device or group of devices, a fragmentation session must be created, providing the
device(s) with the details of the file that will be broadcast.
The FragSessionSetupRequest command is used with the following parameters:
 A fragmentation session ID. A device may have up to four active fragmentation sessions at the same
time. This ID is used to differentiate them from one another.
 The fragment size expressed in bytes.
 The number of fragments required to reassemble the file being transported in the given session (ranging
from 1 to 65535).
 The number of padding zeroes contained in the last fragment (The zeroes may be required if the file
length is not an exact multiple of the fragment length. In this case, the zeroes would be added as
padding for the last fragment length).
 A file descriptor. This is a freely-allocated four-byte field. If the file transported is a firmware patch
image, this field might—for example—encode the version of the firmware being transported, allowing
 compatibility verification upon reception by the end device. The encoding of this field is application-
specific.
Once the FragSessionSetupRequest command has been acknowledged by all devices within the multicast
group, the coded fragments can be transmitted.
Although multicast transmissions are more efficient when transmitting the same file to a group of devices, the
fragmentation package allows us to send fragments using a unicast downlink as well.
After all coded fragments have been broadcast, the server may query the status of each device using
the FragSessionStatusRequest command. This command may be sent as either a unicast or multicast frame.
Devices respond to this command with the following information:
 The status of the fragmentation session: File Successfully Reconstructed, or an error code, if the file
could not be reassembled
 The total number of fragments received during the fragmentation session
 The number of missing fragments received before the file could be reassembled
Additional coded fragments may be sent to devices that have not yet been able to entirely reassemble the file.
Those fragments may be sent as unicast downlinks, or a new multicast session can be created if too many
devices have been unable to reassemble the file.
Summary
In this paper we introduced the “Fragmented Data Block Transport” and “Remote Multicast Setup” application
layer packages, and discussed how LoRaWAN provides an efficient and reliable fragmented-file delivery
service. We also explained how using the fragmented-file delivery service can be used to push binary firmware
updates over-the-air to large groups of devices. This is achieved by using the LoRaWAN protocol’s unique
over-the-air multicast capability in conjunction with an efficient fragment coding scheme, which significantly
reduces the number of repeated transmissions required.
The Immune System | Avoiding RF Interference with LoRa®
by Tim Cooper
Dealing with Uncertainty
Interference can be hard to predict, especially in a license-exempt ISM band, where the interferer could be
another legitimate spectrum user or a service in a neighboring band. This is complicated further, as the severity
of interference depends upon how much unwanted power couples to a receiver. This is as unpredictable as the
environment where the radio is used.
This combination of hard-to-predict power levels and unforseen interference sources can lead to interference
problems being discovered late in the design process – when they are the most expensive to correct. In this
article, I tackle this problem and show you how to answer the deceptively simple question:
How likely is my radio to be immune to the interference it will encounter?
As the question implies, the answer will be probabilistic. Just as for estimations of range or packet error,
knowing what level of error is tolerable is an important starting point. Other inputs are the likely sources of
interference and the immunity performance of the radio. Ask yourself:
 Sources of Interference: What are the potential sources of interference in my application?
 Radio Receiver Interference Immunity: What kind of immunity can I expect from my radio?
There are two main ways of identifying potential sources of interference:
 Consulting the frequency allocations for the country or ITU region where the application is to be
deployed [1]
 Surveying a typical application environment [2]
I will walk through an example based upon a LoRa® receiver, and predict the probability of how susceptible to
interference the signals it receives might be. Contrary to how this is normally presented, my explanation should
provide an intuitive indication of the level of risk.
Radio Receiver Interference Immunity
To understand which sources of interference may pose a problem, you need to have a basic understanding of
receiver interference immunity. At the system level, there are three aspects to consider when examining
interference:
 Interferer Frequency
 Interferer Power
 Interference Duty Cycle
Frequency and Power
To seek out interference we will look at the busiest, most heavily congested spectrum in the world and examine
a LoRa modem operating in the global 2.4 GHz ISM band [3]. For this example, I will consider a LoRa radio in
the presence of Bluetooth® Low Energy (BLE) interference. However, the broader principles presented here
are applicable to any interferer in any band.
Figure 1 shows a typical low-IF receiver front end. Here we have a radio signal transduced by the antenna, then
filtered by a low-pass filter before being amplified by the low noise amplifier (LNA). The amplified signal is
down-converted to a low intermediate frequency (IF) before being band-pass filtered and sampled by an analog
to digital converter (ADC). The ensuing channel filtering and demodulation is in the digital domain.
 

 Figure 1. Receiver Block Schematic

Before we look at the rejection performance, let us examine the various filtering stages in our receiver because
they are of vital interest when thinking about interference. Figure 2 shows the desired signal on the bottom,
with the filtering on the same frequency scale just above it. The signal view is simple: we mix the desired signal
from fRF down to our intermediate frequency fIF using a local oscillator (LO) at frequency fLO (Figure 2).

Figure 2. The frequency domain view of reception without an interferer

The filtering is all very standard, so I will not go into the detail of why each filter is there (for a good
explanation see IF transceiver filtering  [4]). However, it is important to note that the farther the interference is
from the center frequency, the more cumulative rejection we receive from the increased filtering effort.
Because of this, interference is grouped into broad categories according to the frequency offset between the
wanted and unwanted signal [5].
Absolute or Relative?
It is important to pay attention to the units used to quantify the level of interference immunity, namely, absolute
or relative units. Figure 3 shows how interference immunity is usually measured.
The receiver under test connects to two signal sources, one wanted signal and the interferer. The sensitivity of
the receiver is first measured in the absence of any interference, using only the wanted signal (for a specific bit
or packet error rate).  The power of the wanted signal will then be increased by 6 dB and the unwanted signal
applied.
The power of the unwanted, interfering, signal is then increased until the same message error rate as for the
senitivity test is obtained.

Figure 3: Quantification of Interference Immunity

The power of the interfering signal can either be recoded as an absolute power level or as the relative power of
the interferer relative to the power of the wanted signal.
You can determine the frequency response of the interference immunity by varing the frequency offset between
wanted and unwanted signal.
  Figure 4. Interference Immunity of the LoRa Modem versus an always-on BLE interferer
To shed light on each of these interference categories, Figure 4 shows a plot of the real immunity of the LoRa
modem to a Bluetooth interferer1.
Throughout this document, I will refer to the axis on the left hand side, which shows the absolute power of the
BLE signal. The background colors in the plot correspond to the background colors in the receiver block
schematic in Figure 1 and illustrate which elements are dominant in determining the immunity of the receiver
at that frequency offset.

1. Full details can be found in Application Note: Bluetooth® Immunity of LoRa® at 2.4 GHz.  [6] A very
important consideration is that, unlike a real Bluetooth interferer, the unwanted interfering signal is always
“on.” This is not representative of the “bursty,” packetized nature of a true BLE interferer.
 
Far from the Wanted Frequency: Out of Band Interference

Figure 5. Receiver Blocking

How and why does a radio’s immunity change as a function of frequency?
Starting far from the wanted signal, over 20 MHz in our example, is the area highlighted in green in the plot of
Figure 4 where the modem can still receive even in the presence of a -17 dBm BLE interferer. The element
which limits the receiver performance in the presence of a high power signal are the LNA and input filter area
highlighted in green in Figure 2.
Blocking is the phenomenon of a high-powered signal causing gain compression in the LNA. The unwanted
signal saturates the LNA, reducing the LNA gain of both the high-powered blocking signal and the small-signal
gain at the wanted frequency. The reduced amplification of the wanted signal (sometimes also combined with
spectral regrowth in the baseband due to nonlinearity) reduces the receiver sensitivity.
The advantage we have for any interfering signal far out of band is that it will be attenuated by any front-end
receiver filtering. Sources of filtering also include the oft-overlooked antenna, as well as the filtering of the low
pass filter, which will further attenuate the signal.
Same Band: In-Band Interference
When the interferer is closer to the wanted signal (highlighted in yellow in Figure 4) we get between -17 dBm
and -50 dBm of immunity. In this region, the rejection performance is a complicated mix of the blocking
performance of the LNA, the frequency response of the mixer and the band-pass filter. As we get close to the
wanted channel, the in-band rejection becomes limited by the RF phase noise of the local oscillator.
 

Figure 6. Reciprocal Mixing

Figure 6 shows the dominant contribution just within the channel filter stop band, a process known
as reciprocal mixing. Here, the local oscillator (LO) phase noise folds into the wanted channel and limits the
receiver sensitivity. An excellent description, not only of the process itself, but also the equations to derive an
LO phase noise requirement can be found in Computing the LO Phase Noise Requirements in a GSM
Receiver [7].
Image Rejection: At the Image Frequency Only
In the case of a Low-IF receiver, there is one last exception to handle: the image frequency. The down-
conversion process mixes the wanted RF signal down to the intermediate frequency. In addition to this, the low-
side (FLO – FIF) is down-converted to minus the IF. This complex signal folds into the channel filter, as can be
seen in Figure 7.

Figure 7. Image Rejection

The intermediate frequency of the SX1280 in receive mode is 1.625 MHz. This means that the image frequency
can be found at twice the IF below the programmed RF center frequency, i.e. FRF minus 3.25 MHz. The image
rejection can be seen in Figure 4, as a dip at 3.25 MHz below the RF center frequency.
Same Frequency: Co-Channel Interference
The worst case rejection (highlighted in red in Figure 4), with only -97 dBm unwanted signal power preventing
reception, is with an interferer on the same channel. Referring back to our receiver block diagram, in this case
all of the interference rejection comes from the demodulator, as the signal within the receiver channel filter
(red) must discriminate between the wanted and interfering signal. The frequency domain view of this is shown
in Figure 8:

Figure 8. Co-Channel Rejection

While this is the worst case for interference because it has the lowest immunity, LoRa has the advantage of
being able to receive signals below the noise floor and, equivalently, below interference (Figure 9).

Figure 9. LoRa Reception is Possible with negative SNR

Unintentional Antennas
So far I have assumed that all of the sources of interference are arriving in the radio receive path via the
antenna. It is important to note that there are other coupling mechanisms possible. A simplified example of
which is illustrated below (Figure 10).
In the example below, we have two sources of iterference, a wireless router and a smart watch. These are
generating interference on two different frequencies (shown in the leftmost plot) that arrive at the radio PCB
with a certain field strength. Any metallic structure can act as an antenna – wanted or not! In this case, the
unintentional antenna has a certain efficiency as a function of frequency (the middle plot).
The result is shown in the graph in Figure 11. The incident interference is transduced by the unintentional
antenna formed by the PCB, and results in conducted interfering signals present on the board.
The remedy to this is adhering to good RF design principles and using board-level sheilding where
appropriate [4].
 Figure 10. Interference can couple to the radio from paths other than the radio antenna
Distance not Power
While the interference immunity curve of Figure 4 is useful for comparing systems, it does not give a sound
insight into how it can cope with interference. The plots can give more insight about the risk of interference
when we convert these interference immunity figures into distances. This gives us information, both about what
to really expect, and that we can use in our design process.
In converting to distance, my only assumptions are that the interferer is line-of-sight, and I estimate a
conservative 20 dB of coupling loss between the LoRa antenna and the BLE antenna, even at zero distance. A
quick check of this in a lab shows 25 dB of loss between a pair of Taoglas ceramic antennas at aproximately 1
cm of separation (Figure 11).
Figure 11. 25 dB of Measured Close Range Coupling between a pair of 2.4 GHz Taoglas chip antennas at 1 cm
(Inset: measurement setup)
My final assumption is that the Bluetooth transmitter EIRP is 0 dBm.
Based upon these assumptions we can calculate the distance at which the absolute interferer power will be
generated at the receiver input. I start by calculating an interferer link budget, L, in dB.

Where Lcoupling = 20 dB, Pimmunity is the absolute blocking immunity of Figure 3 and  Ptx is 0 dBm.
Taking the resulting link budget, we plug it into a rearranged free-space path-loss equation to calculate the
separation distance, d at which our receiver would be overpowered by the BLE interferer.

Where f is the frequency in Hz (2.45 GHz).

Figure 12. Interference immunity of an always-on interferer: translating the interference rejection into distances
can help interpretation
The plot of d – the distance at which my BLE interferer blocks our LoRa communication – versus the
frequency offset is shown in Figure 11. The probabaility of experiencing interference from our Bluetooth
transmitter appears low at ranges, when there is more than 1 meter separation between the LoRa and BLE
radios, with only six percent of the 80 MHz band where there is the possibility of interference. Only 15 percent
of the band would be interfered with when the devices are from 20 cm to 1 m apart.
You should now have a more intuitive feel for when and how our receiver could be affected by interference.
But this is still only part of the story. This plot in Figure 11 is for an always-on interferer. I have ignored the
infleunce of when the interference is present.
Time on Air
To calculate the probability of collision (i.e. a LoRa packet coinciding with a BLE packet), we need to consider
the time-on-air of each. Let us assume we will receive a packet with the following format, on a single channel
(Figure 13).

Figure 13. LoRa Packet Format of the Purpose of our interference immunity study
At SF12, 200 kHz bandwidth, this equates to a time on air of 892.8 ms and a LoRa symbol time of 20.2 ms.
We compare this with an example of BLE time on air from BLE v4.2: Creating Faster, More Secure, Power-
Efficient Designs—Part 1 [8]. Here, I assume the worst-case data transfer possible in Bluetooth 4.2, i.e. a very
high data transfer from an interfering radio that is very close to our LoRa radio.
Assuming a hopping pattern over all 37 non-advertising channels of the BLE channel plan, we can expect 2.12
ms of transmission time, repeating every 277.5 ms.
 Figure 14. The Duty cycle of the BLE interferer (red) versus a single LoRa packet (top) on a single channel
In the general case, the product of the probability of collision is used to determine the immunity. In our case, a
packet collision is guaranteed. Meaning that if we have a collision, and are within the range of power that will
cause interference, we will lose our LoRa packet.
 
A very important feature of the LoRa modem, is its ability to lose up to half of every LoRa symbol, and still
demodulate the incoming data.
Interferer Duty Cycle vs LoRa Symbol Time

In LoRa systems this is a frequent occurrence. LoRa allows us to trade-off time-on-air for increased sensitivity.
This implies interference with much lower time-on-air (higher data rate than LoRa). A very important feature of
the LoRa modem is its ability to lose up to half of every LoRa symbol and still demodulate the incoming data.
Recalling that the symbol time is given by:

In our 2.4 GHz example, we can see that 2.12 ms BLE packet duration versus our 20.2 ms LoRa symbol period
means we should still be able to recover a LoRa symbol that has been blocked by a BLE packet.
To demonstrate the immunity of the LoRa modem to “bursty” interference, I performed a LoRa co-
channel rejection measurement. Contrary to previous measurements, this is done with a pulsed interferer. On
the X-axis, instead of varying the frequency offset, I am varying the “on” time of the interferer. The timing
diagram in Figure 15 illustrates this.
 Figure 15. Pulsed Interference with a Fixed Duty Cycle
In this example, the interferer will always be on the same channel, and it will have a fixed duty cycle of 10
percent. Instead of changing the frequency variable, we are changing the “on” time TON (so consequently also
the “off” time), and retaining our fixed duty cycle of 10 percent.
Duty cycle = TON / (TON + TOFF)
Although these specific measurements were performed with a pulsed CW interferer (no modulation) and in the
sub-GHz band, the measurement results apply to any LoRa modem. The exact settings used were:
 LoRa SF12
 FEC Coding Rate = 4/5
 LoRa BW = 125 kHz
 LoRa Symbol time = 32 ms

Figure 16. Measured Pulsed Interference Rejection of the LoRa Modem

Figure 16 shows the resulting measurements. The red line at the top of the graph shows the power level of the
unwanted interfering signal. The solid green line shows the minimum LoRa signal level we can receive in the
presence of our pulsed interferer.
The incredible result here is that, once our interference pulse duration is less than about 50 percent of the
symbol time, we win a 100 dB relative signal-to-interference ratio (SIR). That is the ability to receive a signal a
mere 10 billionths of the blocking power. With 100 dB of wanted signal-to-interference in response to bursty
interference, the overall rejection of Bluetooth by our LoRa modem equates to a total immunity beyond 2 cm.
(Figure 17. Note the change in Y-axis units.)
 Figure 17. LoRa Modem Rejection of Frequency Hopped BLE Interfernce
 
Conclusion
The general method and principles outlined here are applicable to any radio technology. Using our example of
LoRa in the 2.4 GHz band in the presence of BLE interference, we have seen a way of converting interference
immunity data to an easier-to-interpret immunity-versus-distance plot.
We then looked at the worst-case scenario permitted in the BLE 4.2 specification, where the LoRa receiver is
next to a BLE transmitting the highest volume of data possible. This additional timing information allowed us
to derive the interference-immunity versus distance plot including the additional 100 dB of isolation due to the
LoRa modem.
This finally allowed us to determine that our LoRa receiver at SF12 200 kHz would have to be within a couple
of centimeters of the BLE transmitter to experience any kind of interference.
Semtech, the Semtech logo, LoRa, and LoRaWAN are registered trademarks or service marks of Semtech
Corporation or its affiliates.
The Bluetooth® word mark and logos are registered trademarks owned by Bluetooth SIG, Inc.
References
[1] ITU Channel Plan: https://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/frequency-plans.aspx
[2] Spectral survey examples:
https://www.rfmw.com/data/Whitepaper_Modern-Co-Site-Interference-Mitigation-Techniques_Southwest-
Antennas.pdf
https://www.keysight.com/upload/cmc_upload/All/Site_Survey_Webcast.pdf
[3] Congestion in the 2.4 GHz ISM band
https://blog.aerohive.com/suffering-from-wi-fi-congestion-dual-5ghz-radios-can-help/
[4] Transciver architectures and filtering can be found in Pozar, “Microwave and RF Design of Wireless
Systems”, John wiley & Sons, 2001 ISBN 0-471-32282-2
[5] Categories of interference as defined by the CEPT:
https://ecocfl.cept.org/display/SH/1.2.11+In-band%2C+out-of-band%2C+spurious%2C+unwanted+emission
[6] Application Note: Bluetooth® Immunity of LoRa® at 2.4 GHz
(https://www.semtech.com/uploads/documents/AN1200.44_Bluetooth_Immunity_of_LoRa_at_2.4_GHz_V1.0.
pdf)
[7] Emanuel Ngompe Conexant app note: Computing the LO Phase Noise Requirements in a GSM
Receiver (https://archive.org/details/ComputingTheLOPhaseNoiseRequirementsInAGSMReceiver)
[8] BLE v4.2: Creating Faster, More Secure, Power-Efficient Designs—Part
1 (https://www.electronicdesign.com/communications/ble-v42-creating-faster-more-secure-power-efficient-
designs-part-1)
[-] Receiver linearity and blocking IP2 and IP3 Nonlinearity Specifications for 3G/WCDMA
Receivers https://highfrequencyelectronics.com/Jun09/HFE0609_Liu.pdf
What is an Adaptive Data Rate?
In this whitepaper, we will look at the Adaptive Data Rate (ADR) mechanism. ADR allows us to exploit the
advantages of the LoRa® physical layer.
Adapting the data rate in a LoRaWAN® network allows us to easily scale the network, simply by adding
gateways. Additionally, using ADR can drastically increase the capacity of such a network.
Let’s begin by looking at a legacy system. Consider an M2M network using FSK-based communications, for
example, MBUS. For this exercise, we will consider the 2.4 kbps incarnation of MBUS operating on a single
channel. For our scenario, imagine that we are monitoring water use in an urban area, using the metering
industry standard of 2500 water meters per square kilometer. In such a case, using typical MBUS settings,
assume that we get an urban coverage range of about 500 meters. At this density, figure that this corresponds to
2000 water meters.
Assuming that we transmit at 2.4 kbps and have 64 bytes of payload data, if we run the numbers, we end up
only being able to transmit twice a day before we exceed a 1% packet error rate, due to collisions.
A LoRaWAN network is more robust than this. To understand why, we will look into the behavior of the LoRa
modem and the sensitivity available for each data rate (spreading factor or SF). For this exercise, assume that
the LoRa bandwidth is fixed at 125 kHz.
Table 1: Data Rate and Sensitivity at 125 kHz

Now, let’s also consider the time-on-air:

Table 2: Data Rate, Sensitivity, and Time On Air.

Given the time on air, it is clear that end devices (nodes) closer to the gateway do not need the high link budget
that goes along with SF12; nor do they need to stay on air as long. This being the case, using ADR can optimize
the SF used for each meter, and minimize the subsequent Time on Air.
ADR is a very simple mechanism that changes the data rate based on simple rules:
 If the link budget is high, the data rate can be increased (i.e. the SF is increased)
 If the link budget is low, the data rate can be lowered (i.e. the SF is reduced)
It tailors the node’s data rate to the available link budget.
Determining the Data Rate
How does the network server determine the appropriate data rate? Let’s take a look:
The end device’s application sends a message up through the gateway, which simply passes the message along
without acting on the data. The gateway in a LoRaWAN network is a simple, low-cost device that converts
LoRaWAN packets into IP packets which can be sent over a secure backhaul to the network server. These IP
packets include a small amount of metadata about the reception time and signal strength. Based upon the
strength of the received signal, the network server determines what the optimal node data rate should be (that is,
the spreading factor).
 Figure 1
The Media Access Controller, also called the MAC layer, of the network server, talks to the same layer in the
LoRaWAN stack of the end-node. A MAC command is then issued from the server based upon its global view
of the strength of the signals received from all gateways. The data rate that the node should use, is sent back to
the device from the server through the gateway with the best signal strength.
Bit Rate vs. Energy Downlink
What is the influence of this ADR mechanism when there is only one gateway?
Figure 2 illustrates the result of a simplified case, in which we consider a free space path loss model to estimate
the attenuation between both antennas (that of the gateway, and that of the device).

Figure 2
Nodes close to the gateway use a high data rate (e.g. SF7). Therefore, they spend less time on air and exploit
the low link budget that they need. For more distant nodes, the data rate is lower (e.g. SF12) and the link budget
is higher. In reality of course, the path loss picture is more complicated. It will depend on the specific
environment around the gateway, as well as where and how the nodes are deployed.
The important point to keep in mind is that, because the communications are orthogonal to each other: multiple
data rates on the same channel can be received simultaneously.
Moreover, the amount of airtime required for a device to send its payload is optimized, which radically reduces
the device’s energy consumption.
Network Capacity Optimization
Consider ADR from the perspective of the network. Figure 3 shows a single gateway, G1, with a range of
devices in a variety of applications.

Figure 3
Here we can see that ADR has already been in effect and the nodes have all had their rates adjusted. Even
though the gateway can serve all of the nodes, because of the long range of the LoRa physical layer, we can end
up ‘seeing’ too many devices from a given gateway, and therefore need additional capacity.
This is easily done with LoRaWAN. Because there are no constraints on which gateway receives signals from a
given node, we simply add another gateway (G2). This gateway will also serve any previously-unconnected
nodes in the vicinity. More interestingly though, for nodes that are already connected to G1, ADR will do the
rest. The nodes closest to G2 will be instructed by the MAC command from the server to increase their data
rate, thereby reducing their link budget accordingly.
By reducing the available link budget, we reduce the range of the communication. This will render many nodes
invisible to G1 and add capacity to uplinks from, and downlinks to, the end-nodes.
Gateway Limitations
Before we can examine ADR in greater detail, we need to consider some important design trade-offs that come
into play because the gateways are being used in a license-free ISM band. The ISM band, although free, comes
at the expense of some practical constraints that are common to any Low Power Wide Area Network
(LPWAN).
The first considerations are legal. Some ISM bands, notably in Europe (which is governed by ETSI) restrict the
amount of airtime a license-free radio can use. For most applications, this is no problem. However for a
gateway that aggregates many applications and must acknowledge a fair portion of the uplink traffic, the legal
limit may become problematic.
The second consideration is that, even when not constrained by the law, ISM bands and available filtering
technologies do not permit full duplex operation of the gateway, at least not in Europe for instance. That means,
when a device sends an uplink, it cannot listen for a downlink.
The result is that downlinks, such as acknowledgements and ADR commands, are expensive when compared
with uplinks. A LoRaWAN network can support far fewer downlinks from a gateway to a node than it can
uplinks from the node to the gateway.
The other point to think through in the context of LoRaWAN is that end devices operating in Class A mode can
announce themselves at any time and then virtually disappear until the next communication. This is important
to consider when determining the link budget for a given node on a given application. A fairly conservative
ADR mechanism is required here because, while optimizing the data rate is generally advantageous, it must not
come at the cost of lost connectivity.
Given these considerations, it is clear that mobile devices cannot use ADR. Imagine a car-tracking application.
In such a case, by the time an ADR command reached the node, the propagation environment will have
changed so radically that the data rate, and therefore the link budget, would no longer be valid.
Acknowledgement Limits
To better understand which applications can make use of ADR, and which can’t, we need to look into the
control mechanism behind ADR.
While the actual data rate itself is determined by the network server, the ADR mechanism can be invoked from
either the network or the end-node. Regardless of which side of the communication triggers the ADR
mechanism however, whether or not using ADR is appropriate is determined by the application. ADR is
invoked simply by setting the ADR bit in the frame control header. Ordinarily, the end device application
decides whether or not using ADR is appropriate. If so, the bit is set – letting the network know that the end-
device can have its data rate determined by the network.
To understand this process, imagine a device is connected to the network and has announced itself as ADR-
enabled via an uplink (Figure 4). This uplink travels through one or more gateways that simply relay the
message back to the network server. By default, it will be sent at the lowest data rate, that is, the longest range
setting.
What does the network server do? It waits.

Figure 4
 
Once the network server has amassed several results, it calculates the median of those results and determines
both the available link budget and the highest data rate that can be supported, along with a margin for error, to
allow for fluctuation in the channel characteristics. Following the next uplink, a MAC command to change the
data rate is sent down to the end device, as appropriate. (Figure 5 shows a MAC command setting the ADR to a
data rate of SF7.)
 Figure 5
The end device then switches to the new spreading factor and all future uplinks are set at this new data rate. The
network server remains aware of any degradation of the channel. It will issue new MAC commands the next
time it determines the data rate needs to be changed.
You might be asking yourself: “What happens if the link is lost?”
The entire time that the end device sends its uplink packets, it also increments the “ADR acknowledge
counter”. The counter can be incremented until it reaches a predefined limit, as illustrated in Figure 6.
  

Figure 6
When the node reaches the ADR acknowledgement limit, it sets the ADR acknowledge request bit in the frame
control header, shown in red:
For downlink frames, the FCtrl content of the frame header is

For uplink frames, the FCtrl content of the frame header is

Acknowledgement Delay
After the ADR acknowledge request bit is set, there is a predefined delay, the ADR acknowledge delay, as
illustrated in Figure 7. During this time, the end device waits for the network server to respond to the
acknowledgement request. Because the network server might need to respond to several requests, or need to
send other downlink traffic, this delay helps make scheduling a given downlink easier for the network server to
accomplish.

Figure 7
Rather than being specified in terms of time, the ADR acknowledge delay is expressed as a number of uplink
messages. This keeps the implementation of a low-cost, low-consumption end device simple.
Any downlink packet can include the ultimate acknowledgement from the network server. No special bit needs
to be set in the header; the packet is simply treated as also being the acknowledgement.
If no answer is received from the network server by the time the acknowledgement delay period has expired,
the data rate will automatically be reduced by one step, as illustrated in Figure 8.
 Figure 8
After this one-step data rate reduction, the end device continues sending messages to the server (at this new,
lower, data rate) requesting an ADR acknowledgement. Once an acknowledgement is received, the end device
uses the new, server-determined, data rate until it receives an instruction to change it again via the normal ADR
mechanism. However, if no answer is forthcoming, the end device continues to ratchet down the data rate, step
by step, until it gets a response or, assuming the device and network are in Europe, until it reaches SF12 (Figure
9).
Note: The highest spreading factor that can be used with LoRaWAN varies by region, for instance in the USA,
the highest SF is SF10.
 Figure 9
Figure 10 shows very simplified picture depicting a situation wherein a single frequency channel is shared
among multiple data rates.

Figure 10
Conclusion
For static end devices, the ADR is managed by the network server, based on the history of the uplink packets
received. This is referred to as Network-managed ADR or Static ADR.
For mobile end devices, the network based ADR strategy does not work because of the unpredictable channel
attenuation which occurs as the device moves. Rather, with mobile end devices, ADR is performed “blindly” by
the end device. This is referred to as Blind ADR. For more information about Blind ADR, see the tech
paper An Introduction to Blind ADR.
LoRa® Device Mobility: An Introduction to Blind ADR
The LoRaWAN® adaptive data rate (ADR) mechanism slowly adapts the data rate between an end device
(“end node”) and a gateway depending upon the prevailing channel conditions1. Once established, the link is
periodically maintained and removes much of the need for downlink confirmation messages to the end node.
This makes it ideal for high capacity, static applications such as metering. However, for mobile applications
where the channel conditions will change rapidly, we cannot use ADR.
In this article, we introduce the notion of blind ADR its purpose, and its advantages.
Consumption, Link Budget and Airtime
To see how to strike a balance between these conflicting requirements, we will consider a GPS-plus-LoRaWAN
pet tracking application, where every 10 minutes the tracker wakes and sends its GPS status and coordinates,
comprising 17 bytes. Wrapped in a LoRaWAN frame, this equates to a total of 30 bytes of packet payload. We
assume that the battery will need to last for one year. If we were going to select a LoRa single data rate, we
would have to choose from among the compromises outlined in Table 1.
Table 1

 *Battery capacity includes an estimate of the whole radio consumption.

Because LoRa is a direct trade-off between link budget and time on air, deeper coverage comes at a cost of
higher energy consumption. Achieving a high link budget with deep indoor coverage for our pet tracker will
result in a higher power consumption cost, and a larger battery will be required due to the lower data rate. In
contrast, the use of a smaller, cheaper battery would be possible if we use a high data rate, but at the cost of
reduced coverage, as illustrated in Table 2:
Table 2

Blind ADR: How Does It Work?

The purpose of blind ADR is to reject this fixed range-consumption trade-off of using a single data rate.
Instead, we use a spread of data rates to gain both good coverage and long battery life. To see this in action, we
will take the case of a GPS pet tracker using blind ADR.
Instead of using a single data rate, we use three data rates and different periodicity depending upon the data
rate.
Figure 1

As illustrated in Figure 1, we will transmit at:

 SF12 once every hour,
 SF10 twice an hour, and
 SF7 three times an hour
For our pet tracking application, this gives us frequent outdoor position information when the pet is moving,
with fewer updates when the animal is located indoors – and therefore, less mobile.
Advantages of Blind ADR
In this example application, blind ADR allows us to economize on battery life in a way that still meets the
application’s needs. Here, we retain the low power consumption of the application while maintaining frequent
outdoor updates. Moreover, additional application intelligence and sensors or accelerometers are not required
for deciding when to transmit.  

1. For information on the standard ADR mechanism, network-based ADR, see the LoRa Adaptive Data Rate
tech paper.
An In-depth look at LoRaWAN® Class A Devices
Introduction
A LoRaWAN®-based network is made up of end devices, gateways, a network server, and application servers.
End devices send data to gateways (uplinks), and the gateways pass it on to the network server, which, in turn,
passes it on to the application server as necessary.
Figure 1: Uplink Transmission

Additionally, the network server can send messages (either for network management, or on behalf of the
application server) through the gateways to the end devices (downlinks).
Figure 2: Downlink Transmission
 

End devices in a LoRaWAN network come in three classes: Class A, Class B and Class C. While end devices
can always send uplinks at will, the device’s class determines when it can receive downlinks. The class also
determines a device’s energy efficiency. The more energy efficient a device, the longer the battery life.
All end devices must support Class A (“Aloha”) communications. Class A end devices spend most of their time
in sleep mode. Because LoRaWAN is not a “slotted” protocol, end devices can communicate with the network
server any time there is a change in a sensor reading or when a timer fires. Basically, they can wake up and talk
to the server at any moment. After the device sends an uplink, it “listens” for a message from the network one
and two seconds after the uplink (receive windows) before going back to sleep. Class A is the most energy
efficient and results in the longest battery life.
In contrast, rather than only waiting for one of its sensors to notice a change in the environment or fire a timer,
Class B end devices also wake up and open a receive window to listen for a downlink according to a
configurable, network-defined schedule. A periodic beacon signal transmitted by the network allows those end
devices to synchronize their internal clocks with the network server.
Finally, Class C (“Continuous”) end devices never go to sleep. They constantly listen for downlink messages
from the network, except when transmitting data in response to a sensor event. These devices are more energy-
intensive, and usually require a constant power source, rather than relying on a battery.
To illustrate the different levels of power consumption for each of the different end-device classes, see Figure
3.
Figure 3: Energy Consumption by Device Class

In this paper, we take an in-depth look at Class A end devices.

Understanding Class A End Devices
The LoRaWAN protocol relies on an Aloha-type network. In this type of network, end devices are allowed to
transmit arbitrarily.
The key characteristic of Class A is that communication is initiated only by the end device.
Downlink messages from the network server are queued until the next time an uplink message is received from
the end device and a receive window (Rx) is opened. This design is specifically geared toward applications that
require downlink communication in response to an uplink, or that can schedule downlinks ahead of time with
fairly loose latency requirements.
Receive Windows
Following an uplink, a Class A end device opens a short receive window (Rx1) and, if no downlink is received
during that period, it opens a second receive window (Rx2). The start time of Rx1 begins after a fixed amount
of time following the end of the uplink transmission. Typically, this delay is one second, however this duration
is configurable. Rx2 typically begins two seconds after the end of the uplink transmission, though this duration
is also configurable. The following diagrams illustrate the different receive window state possibilities.
Figure 4: Nothing is received
Figure 5: Packet received in Rx1 window

Figure 6: Packet received in Rx2 window

 

The default delay for Rx1 (RECEIVE_DELAY1) is a network parameter found in the LoRaWAN Regional
Parameters document from the LoRa Alliance®. The default delay may be region-specific, and can be changed
by the network operator through the MAC command RxTimingSetupReq. It is typically set to one second
The end device then waits one second after Rx1 closes before opening Rx2. This means that
RECEIVE_DELAY2 = RECEIVE_DELAY1 + one second.
Note: A device will not try to send another uplink message until either:
1. It has received a downlink message during Rx1, or
2. The second receive window following the last transmission is complete
Transmission Frequencies and Data Rates
The frequency used for Rx1 is a function of the uplink frequency. The data rate it uses is a function of the data
rate used for the uplink transmission. The default relationship between the uplink frequency and the Rx1
downlink frequency and data rate are defined in the LoRaWAN Regional Parameters document. The default
parameters can be remotely reconfigured by the network operator using the relevant LoRaWAN MAC
commands.
Rx2 uses a frequency and data rate that can be configured using a MAC command. The defaults are region-
specific.
MAC Commands
With respect to Rx1, the offset between the uplink transmission (Tx) data rate and the downlink data rate can be
configured using the Rx1DRoffset field of the RxParamSetupReq MAC command
To configure the Rx2 data rate, use the MAC command RxParamSetupReq.
The DiChannelReq MAC command allows the network to associate a different downlink frequency with the
Rx1 window. This command works for all regions that support the NewChannelReq MAC command. For
example, DiChannelReq applies in the EU and in China, but not in the U.S. or Australia, as described in the
LoRaWAN Regional Parameters document.
Class A Energy Profile
The duration of each receive window must be at least as long as the time required by the end device’s radio
transceiver to effectively detect a downlink preamble. If the device detects a downlink preamble during this
time, the radio receiver will stay open until the downlink data is demodulated.
If a downlink was detected and demodulated during Rx1 and if, (after the address and Message Integrity Check
(MIC)) it is determined to be intended for the end device that received it, the device will not open Rx2 in an
attempt to conserve energy. However, if the end device does not receive a downlink message during Rx1, it will
continue to open Rx2 on schedule.
When there is nothing for an end device to receive, it will still open its reception windows, but just long enough
to determine whether there is a preamble. At minimum, this is 5.1 milliseconds (ms) at a data rate of SF7. At
maximum, it is 164 ms at a data rate of SF12. If, on the other hand, there is a downlink coming to the device, at
SF7, it will take less than 100 ms to demodulate the message. At SF12 it can take more than two seconds.
Figure 7: Uplinks, Downlinks and Wake-up Times for SX126x Radios

The energy drain linked to Rx1 and Rx2 when no downlink message is detected is negligible compared to the
energy required for the transmission of the uplink
LoRaWAN Network Topology
Figure 8 illustrates the LoRaWAN network topology. The key difference between the LoRaWAN approach and
others is that end devices are paired with the network itself and are not exclusively tied to a single gateway.
Rather, end devices broadcast their signals to all gateways within range. Each of the receiving gateways pass
the data packet along to the network server, and then the network server de-duplicates the message and sends a
single version of it to the application server.
Figure 8: LoRaWAN Network Topology
There are several advantages to this topology:
 No complicated network planning is required. Gateways can be added anywhere at any time.
 Accurate message delivery is more robust, since multiple gateways receive the same data packet during
each uplink. This is called uplink spatial diversity.
 There is no need to plan for different frequencies for each gateway, or to reallocate frequencies when
the number of gateways change. All gateways are constantly listening to all frequencies of the network.
 Mobile devices can operate at low power thanks to the fact that any gateway can receive messages from
any device. This means that (in contrast, for example, to Cellular networks) the LoRaWAN network
does not notice or care that the device is moving; it simply receives uplinks from the gateways nearest
the device’s current location.
Unconfirmed and Confirmed Messaging
Messages from end devices to the network and application servers and vice versa may be unconfirmed or
confirmed.
When a device sends an unconfirmed message, it does not require an acknowledgement from the server. For
example, most of the time a smoke detector will send periodic, unconfirmed uplinks to the network server via
nearby gateways just to confirm that it is working. The gateways receive the data and pass it on to the network
server, which in turn passes it on to the application server.
When sending a confirmed message, the end device requires that the message be acknowledged as received by
the network server. Let’s look at our smoke detector again. When the smoke detector detects something, it will
continue to transmit alerts that need to be confirmed until the alert is acknowledged. The acknowledgement
informs the smoke detector that someone is responding to the alert. Because downlinks from the network are a
scarce resource, they should be used sparingly. Confirmed messages should be used only for very important
sensor data.
Figure 9 shows a smoke detector transmitting encrypted, unconfirmed messages (see the arrows pointing from
the device at the bottom of the diagram up to the Application Server at the top via the three leftmost boxes),
which are received by two gateways. The gateways add encrypted metadata to the messages and then forward
them to the network server. The network server decrypts the metadata and sends the data packet to the
application server, which decrypts the data.
In orange, we see the smoke detector sending an alert. These are confirmed messages, however, in the first two
instances, no acknowledgement has been received, so the device continues to broadcast the alert. Finally, after
the third transmission of the alert in our example below, the application server sends an acknowledgement to
the device via the network server and the most appropriate gateway.
Figure 9: Unconfirmed and Confirmed Messaging

 
Application Server Downlinks
In this next example, the smoke detector application server has data to transmit to a specific, sleeping, smoke
detector (the end device). However, since the smoke detector is a Class A device, the application server has to
wait until the smoke detector wakes up before the server can send the data. For smoke detectors, this is a
periodic message (e.g., sent every 8 hours) sharing status information—like battery status—with the application
server and not a real smoke-detection event. Receipt of this message by the end device may be either confirmed
or unconfirmed. Take a look at Figure 10. Here, the application server has data to send to the smoke detector,
but the device is asleep. The server must wait for an uplink from the device before it can send its data. As soon
as the uplink is received, the application server immediately transmits the downlink. In the case of an
unconfirmed message of this sort, upon receipt of the downlink, the device goes back to sleep.
Figure 10: Application Server Downlink
Summary
In short, all end devices must support Class A operation, which is the most energy efficient mode of
communication and supports the longest battery life. Class A end devices stay in deep-sleep mode until they
sense a change in their environment or some other event is triggered. When this occurs, the affected device
wakes up and sends its data to the network server (and eventually the application server) via one or more
gateways. Following the uplink transmission, the end device will open two consecutive receive windows,
during which they listen for potential downlink transmissions from the server.
An In-depth Look at LoRaWAN® Class B Devices
Introduction
In a LoRaWAN® network, end devices operate in one of three modes: LoRaWAN Class A, Class B, and Class
C. As described in An in-depth look at LoRaWAN Class A devices,  the network can only send messages
(downlinks) to an end device in Class A mode during one of two short receive windows, which open just after
the device has sent a message (an uplink) to the network. These uplinks, however, are not prescheduled and
may be transmitted by the device at unpredictable times. While this is great for conserving power, that power
conservation comes at a cost. For example, end devices in Class A mode do not allow for a known reaction time
when the customer application or the server wants to send a message to the device.
This is where LoRaWAN Class B mode can help. An enhancement of Class A, Class B mode offers regularly-
scheduled, fixed-time opportunities for an end device to receive downlinks from the network. All LoRaWAN
end devices start in Class A mode; however, devices programmed with a Class B stack during manufacturing
may be switched to Class B mode by the application layer.
Class B: The “Beaconing” Class
End devices in Class B mode provide for regularly-scheduled receive windows, in addition to those that open
whenever a Class A-style uplink is sent to the server. For this to work, a time-synchronized beacon is broadcast
periodically by the network via the gateways, as illustrated in Figure 1. The end device must periodically
receive one of these network beacons so that it can align its internal clock with the network.
Based on the beacon timing reference, end devices can open receive windows (ping slots) periodically. Any of
these ping slots may be used by the network infrastructure to initiate a downlink communication.
Figure 1: Network beacon opportunities

The transmission of a downlink message from an application server to a Class B device is illustrated in Figure
2. Here is a summary of the flow:
1. The application server (AS) queues a downlink message (DL) into the network server (NS)
2. The network server computes the next ping slot schedule
3. The network server computes the best gateway to use based on the last uplink received from the device
and the current gateway’s transmission schedule
4. The network server queues the downlink into the selected gateway
5. When the selected ping slot start time is reached, the gateway transmits the downlink
6. At the same time, the device turns its receiver on and receives the downlink
When there is no downlink to be sent (roughly 99 percent of the time), the network does not transmit anything.
However, the device still opens its receiver at the beginning of the ping slot. When it does not detect a
preamble, it goes back to sleep as quickly as possible to conserve power.
Figure 2: Beacon flow
 
The reception of the synchronization beacons and the ping slots add additional power consumption overhead
compared to a Class A device; therefore, a device is allowed to toggle between the Class A (the lowest power
consumption mode) and Class B modes.
The decision to switch between the two modes is use-case specific and is left to the device’s application layer.
If the switch needs to be controlled from the network side, the customer application must use one of the Class A
uplinks to trigger a downlink to the application layer. The application layer on the end device must then
recognize and respond to the request to switch modes—this process is not managed at the LoRaWAN level.
For a LoRaWAN network to support Class B end devices, gateways must be able to synchronously broadcast a
beacon that provides a timing reference for the end devices’ internal clocks. The end devices then use this
timing reference to schedule when ping slots are opened to receive potential downlinks from the network.
Because all gateways broadcast the Class B beacon synchronously on the same channel and using the same
radio parameters, a device within range of several gateways will receive the superposition of multiple beacons,
all experiencing different attenuations and phase distortions.
In order for this end device to be able to demodulate the superposed beacons with as little interference as
possible, the gateways must synchronously transmit their beacons with a timing jitter smaller than one
microsecond.
This way, the various beacons that superpose at the antenna of the device actually look like a single beacon
packet suffering from radio multi-path, therefore they can be demodulated.
The Beaconing Period
Synchronization beacons are transmitted by network gateways once every 128 seconds.
The interval between two consecutive beacons is divided evenly into 4096 ping slots.
Figure 3: Ping slots
The 128-second beaconing period has been chosen as a trade-off between minimizing the gateway transmit
duty-cycle (saving the gateway transmit time budget for useful downlinks from the application server), while
minimizing the power consumption of the end device as it attempts to lock-on to and track the beacon. (To
acquire the beacon, the device must keep its receiver on for at least one beacon period.)
You can estimate the power consumption of a Class B end device by first calculating the time on air as well as
the time the receive windows are active.
Class B Power Estimation
Here is an example of how to estimate the power consumption for Class B end devices.
The power overhead of Class B operation is a function of:
 The time-on-air of the beacon, which is region-specific
 The periodicity of the ping slots (application driven)
 The ping slot data rate (which sets the minimum duration of each ping slot)
 The average Class B downlink periodicity
For this numerical example, we will assume the following hypothesis:
 Beacon is transmitted using SF9/125kHz => beacon time-on-air ~ 160mSec
 Ping slot periodicity: 32sec (the device opens a ping slot every 16 seconds)
 Default ping slot data rate: SF9/125kHz
 Device receives, on average, one 30-byte Class B downlink per hour.
 The device current in Rx mode is 10mA (typical for SX1272/76 products)
Equation 1: Estimating Class B device power consumption

We can see from this example that for a ping slot periodicity of 32 sec (meaning that the device is reachable
with an average latency of 16sec), the power contribution is, roughly, split equally between the beacon
synchronization and the opening of the ping slots.
The table above takes into account a possible imprecision of +/-30ppm RTC XTAL. 30ppm over 128sec leads
to a +/- 4mSec maximum timing inaccuracy. The 32mSec ping slot duration is long enough to allow a +/-
4mSec misalignment between the transmitter (network) and the receiver (device). For more information about
this calculation, see Application Note AN1200.23.
What Does the Beacon Look Like?
All beacons are transmitted using the LoRa modulation in a mode known as implicit header mode; that is,
without a LoRa® physical header, and without CRC appended by the radio. This is possible because the beacon
uses a fixed coding rate and a fixed payload length. The beacon therefore only consists of a preamble and a
fixed-length payload.
The beacon preamble is longer than the default. This allows end-devices to implement a low-power, duty-
cycled beacon search. This helps to minimize the power consumption of the device during beacon acquisition.
The beacon payload, BCNPayload, consists of three parts: a network common part (that is, this data is sent
identically by all gateways), an optional gateway-specific part (this part may be different for each gateway), and
a timestamp time in seconds since January 6, 1980 00:00:00 UTC (the start of the GPS epoch). The integrity of
the beacon’s network common part is protected by a 16-bit CRC. For specific information about how the CRC
is computed, see the latest LoRaWAN specification.
The RFU field is equal to zero. (The length of the RFU field is region-specific.)
Note: In practice, many networks only broadcast the network common part of the beacon and do not include
gateway-specific fields.
The Gateway-Specific Beacon Element
The gateway-specific portion of the beacon payload, when present, provides additional information regarding
the gateway that is sending the beacon. Therefore, this portion of the beacon will likely be different for each
gateway. The gateway-specific portion of the beacon payload is protected by a CRC-16 computed on
the GwSpecific+RFU fields. The CRC-16 definition is the same as that of the network common part.
Figure 4: Beacon payload

The InfoDesc and Info Fields

The information descriptor, InfoDesc, describes how the information field should be interpreted. For a single
omnidirectional antenna gateway, the InfoDesc value is 0 when broadcasting GPS coordinates. In contrast, for a
site featuring sectored antennas for example, the first antenna broadcasts the beacon with InfoDesc equal to 0,
and the second antenna with InfoDesc field equal to 1, etc. If InfoDesc equals 0, 1 or 2, the content of
the Info field encodes the GPS coordinates of the antenna broadcasting the beacon.
Table 1: InfoDesc field values

The latitude and longitude (Lat and Lng) fields within the Info field encode the geographical location of the
gateway.
Figure 5: Info field format

The North-South latitude is encoded using a signed, 24-bit word, where -223 corresponds to 90° south (the South
Pole) and 223 corresponds to 90° north (the North Pole). The equator corresponds to 0.
The East-West longitude is encoded using a signed 24-bit word where -223 corresponds to 180° west and
223 corresponds to 180° east. The Greenwich meridian corresponds to 0.
Beacon Acquisition and Tracking
As mentioned previously, an end device must receive a timing beacon to bring its internal time base in sync
with the network before it can switch from Class A mode to Class B. Once successfully operating in Class B
mode, the end device must stay in alignment with the network beacons. This helps ensure that the device’s
internal time base does not drift compared to the network time.
A device operating in Class B mode may temporarily stop receiving beacons for many reasons (interference,
device moving in and out of the network coverage area, etc.).
When the device temporarily loses a beacon, it relies on its internal clock to keep opening the Class B
synchronous ping slots. The LoRaWAN specification requires that Class B devices should be able to operate in
Class B mode without receiving the beacon for up to two hours.
This temporary Class B operation without a beacon is called beaconless operation. During this holding period,
the reception of any beacon directed to the end device will extend beaconless operation for another two hours.
If a Class B end device is temporarily unable to receive beacons, it will gradually widen its beacon and ping
slot reception windows to account for any drift of its internal time base. Obviously, a higher precision time base
allows the device to open narrower reception windows, thus minimizing its power consumption. The accuracy
of the real time clock oscillator is therefore very important for Class B devices. If a Class B end device doesn’t
receive a beacon during the 120-minute holdover period, the end device will return to operating in Class A
mode.
Ping Slots and Ping Periods
Based on the beacon timing reference, end devices periodically open ping slots (reception windows). A
network-initiated downlink to an end device using one of these ping slots is called a ping. The gateway chosen
to transmit this ping is selected by the network server based on signal quality indicators from the last uplink
sent by the end device. For this reason, mobile Class B devices must send periodic uplinks, so that the network
server can update the downlink routing-path database.
To avoid systematic collisions and problems of overhearing messages, each device’s ping slot index is
randomized and changed at every beacon period.
The ping slot periodicity may be as short as one second, or as long as 128 seconds, as illustrated in Figure 6.
Figure 6: Ping slot periodicity
The device opens ping slots regularly. However, the network does not always have downlinks to transmit.
Therefore, most ping slots are not used by the network. When this is the case, the reception window on the end
device is closed as soon as the radio transceiver determines that no preamble is present. If a
preamble is detected, the radio transceiver will remain on until the downlink frame is demodulated. The MAC
layer will then process the frame, check that the address field matches the end device address, and that the
Message Integrity Check (MIC) is valid. Only then will the message be forwarded to the application layer on
the end device.
Unicast and Multicast Pings
Downlinks can be either unicast or multicast. Unicast messages are sent to a single end device, while multicast
messages are sent to several end devices at the same time. For a multicast message to be successful, the
following conditions must be met:
 All devices in a multicast group must share the same multicast address and associated encryption keys
 All devices must be open at the same time, on the same channel, using the same data rate
Note: To remotely set up a multicast group please see the LoRaWAN Remote Multicast Setup Specification
(v1.0.0)
Class B: Uplink Frame and MAC Commands
Uplink frames in Class B mode have the same structure as those used in Class A communications, with the
exception of the Frame Control (FCtrl) octet in the frame header.
Figure 7: Uplink frame structure
For Class A communication uplinks, Bit 4 of the FCtrl octet is set to 0. This bit is set to 1 for Class B uplinks.
Setting the Class B bit to 1 in an uplink message will signal to the network server that the device has switched
to Class B mode and is ready to receive scheduled downlink pings.
Because a LoRa-based device always starts in Class A mode, All MAC commands specified for Class A end
devices MUST be implemented in Class B end devices, in addition to those commands specifically used for
Class B operation. For more information, see the LoRaWAN Specification, v1.0.3.
Conclusion
By design, all LoRa-based end devices support Class A communication. Class A devices can send uplinks to
the network server at any time, and only listen for downlinks immediately after sending their uplinks. In
contrast, Class B devices allow for predictable times when the network server can send a downlink to the
device. The trade-off for this predictability is that Class B devices are not as energy efficient as those in Class A
mode; therefore, the battery life of Class B devices is shorter than that of Class A devices.
An In-depth Look at LoRaWAN® Class C Devices
Introduction
End devices in Class C mode are used when extremely low power consumption is not an issue and latency
needs to be minimized. The server-side application determines that it is managing class C devices during the
join procedure.
Characteristics of a Class C Device
 Based on Class A foundations
 Devices cannot simultaneously operate in Class B and Class C mode
 Lowest latency among all operating modes
 Uses more power than Class A and Class B devices
Class C: Continuous Reception
End devices operating in Class C mode have receive windows that are almost always open. These windows
close only when the device is transmitting. Because of this, Class C end devices use more power to operate than
Class A or Class B devices. However, in turn, they offer the lowest latency for communication from the server
to an end device.
A device may be switched to Class C mode temporarily. This approach may be used to perform a firmware
upgrade of a battery-powered device. A battery-powered Class A device may switch to Class C for a few
minutes at a given time in order to receive a firmware update over-the-air (FUOTA) broadcast. Once the
broadcast of the update is complete, the device can return to its default Class A, low-power mode of operation.
Class C end devices implement the same two receive windows as Class A devices, but they do not close the
RX2 window until they send the next transmission back to the server. Therefore, they can receive a downlink in
the RX2 window at almost any time. A short window at the RX2 frequency and data rate is also opened
between the end of the transmission and the beginning of the RX1 receive window, as illustrated in Figure 1.
Figure 1: Receive Windows: Packet can be received in RX2 window

Multicast Downlinks
Class C end devices may receive multicast downlink frames in a manner similar to end devices in Class B
mode. The multicast address and the associated network session key and application session key must come
from the application layer.
The FPending bit is used to indicate that there is more multicast data to be sent. Given that a Class C device
keeps it receiver active most of the time, the FPending bit does not trigger any specific behavior on the end
device.
MAC Commands
All commands described in the Class A specification must be supported in Class C end devices.
For more information about other end device operating modes, see An In-Depth Look at Class A
Devices and An In-Depth Look at Class B Devices. 
Understanding the Gateway Join Server
To support massive gateway deployment scenarios in an automated and secure way, LoRa®-based gateways
must follow a join process, similar to that used for end devices on a LoRaWAN® network. The gateway join
process decouples the two major phases in a gateway’s lifetime: manufacturing and deployment.
In this article, we start by looking at the journey of a gateway from manufacturing until deployment. Next, we
discuss who owns a gateway, followed by an overview of the gateway join server, before diving into the details
of the relevant APIs.
This article assumes that the reader is familiar with LoRaWAN networks, LoRa Basics™ Station, and “gateway
join process” described in the article 5 Things You Need to Know about LoRaWAN-based Gateways.
A LoRa-based Gateway’s Journey
Figure 1 illustrates the two phases of a gateway’s journey. Typically, the life of a LoRa-based gateway starts
with a design that is then realized in a manufacturing phase. This manufacturing phase may include some
form of personalization, whereby secrets are embedded into the gateway’s persistent storage.

Figure 1: Gateway Manufacturing and Deployment Phases

After a gateway is sold, the purchaser deploys it in a LoRaWAN network, where it connects to a LoRaWAN
Network Server (LNS). The deployment phase may be repeated several times over the life of a gateway and
may require that the gateway renews its LNS credentials, for instance, during migration to a new LNS. This
allows solution providers flexibility in their choice of network provider.
The Manufacturing Phase
During the manufacturing phase, gateways are produced with either generic or custom LNS firmware.
Generic LNS Firmware
Generic LNS firmware typically does not include specific LNS endpoint configuration or corresponding LNS
credentials for the gateway. In this case, during manufacturing, the LNS endpoint to which the gateway will
connect in a deployment is unknown. Instead, in order to connect a gateway to the appropriate LNS, this
information must be configured on each gateway prior to deployment. However, generic LNS firmware may
also contain additional embedded secrets.
Custom LNS Firmware
By and large, custom LNS firmware does include gateway-specific credentials and LNS-endpoint configuration
details. However, customer firmware usually requires a minimum purchase quantity and special agreements
with the manufacturer. These types of arrangements are only possible for large LoRaWAN operators.
Furthermore, the gateway-specific credentials for the LNS endpoints must be shared with between the gateway
manufacturer and the gateway owner. This being the case, the LNS endpoints to which the gateways will
connect in a deployment is known at manufacturing.
The Deployment Phase
During deployment, gateways must be configured for an LNS endpoint, and must be configured with the
appropriate LNS authorization credentials. The Configuration Update Protocol (CUPS) can be used to
configure gateways and distribute the corresponding authentication credentials.
Gateway Ownership
Defining gateway ownership is not a straightforward task. In this article, we consider that the person,
organization, or other entity legally tasked to manage a gateway’s LNS endpoints and corresponding set of
credentials as the gateway owner. In addition, gateway owners may also control the execution of signed code.
Given this definition, an owner can be one or more of the following entities:
 Manufacturer – With appropriate support agreements, the gateway manufacturer may provide gateway
management services
 Network Operator – Cable operators fully manage modems installed in people’s homes; similarly,
utility companies manage the meters installed in homes
 Solution or Service Provider – Part of a complete solution includes gateway management
 End User – End users can manage their gateways much as they manage personal Wi-Fi gateways
Proof of Ownership
To connect a gateway to a LoRaWAN network, you must be able to prove ownership. How do you do this?
Gateways should be able to derive a secret from a gateway-specific master key, typically embedded during
manufacturing. To prove ownership, an entity must provide the appropriate secret, which can only be known by
a secure physical interaction with the gateway, or with an authentic record of purchase. We will refer to this
secret as a claim PIN.
The Gateway Join Server
The gateway join server decouples the configuration of LNS credentials from manufacturing and enables
gateway migration of a gateway among LNS providers. The manufacturing and deployment phases when using
a gateway join server are depicted in Figure 2. In this scenario, gateway owners have full control in configuring
an LNS endpoint and no LNS credentials are shared with gateway manufacturers.

Figure 2: Manufacturing and Deployment Phases with a Gateway Join Server

It is crucial that the gateway join server is able to verify both claims from owners and authentication tokens
from gateways. To this end, the gateway join server must be able to verify the validity of claim PINs and
authentication tokens using a twin hardware secure module (HSM), one that has the same batch root key
information as the HSM used during gateway manufacturing. The batch root key is the only secret that is shared
between the two HSMs (the one used in manufacturing and the one associated with the gateway join server). A
gateway batch encompasses a range of gateway MAC addresses which share a key derivation scheme using a
common batch root key. The batch root key never leaves the security domain of the twin HSMs.
The HSM for the manufacturing phase personalizes the gateways with a gateway master key, which is derived
from the batch root key. The gateway is then able to autonomously derive authentication tokens and claim PINs
from this gateway master key, as illustrated in Figure 3. Note that the second HSM is connected to the gateway
join server and holds the same batch root key.
 

Figure 3: Gateway Keys, Tokens and Claim PINs

To assist the gateway owner, the claim PIN should be either printed on the gateway label together with the
corresponding MAC address, or it should be possible to use an API to read the claim PIN from the gateway
itself. Alternatively, to prove ownership of a large number of gateways, the claim PINs could be made available
via a secure process for customers placing large orders with a particular manufacturer. Here, the claim PIN is
the secret that proves ownership of a gateway.
API Overview
At its core, the gateway join server provides two important APIs, the Gateway API and the Owner API.
The Gateway API implements the server-side authentication for the CUPS protocol, defined by LoRa Basics
Station. The Owner API allows gateway owners to configure LNS endpoints and the corresponding
credentials, as well as schedule generic signed updates.
In the following sections we will focus on the basic functions of the Owner API:
 Claim a gateway using the embedded claim secret
 Setup credentials and URIs for LNS and CUPS
 Delete a gateway (to allow other owners to claim it, for example)
 Add a gateway (this is a generic case covering gateways which do not have an embedded authorization
token nor a claim secret)
The Gateway API is described at length in the LoRa Basics Station CUPS Protocol documentation. Advanced
functions of the Owner API will be the subject of a future article.
Owner API: Claim
Use to claim a single gateway or set of gateways for the specified owner. The claim string is gateway-
dependent. Before any operation can be performed on a gateway (e.g. setup, info, delete, etc.) it must be
claimed by an owner.
POST /api/v1/gateway/claim
Response Headers:
   Content-Type – application/json 
 200 OK – no error
 400 Bad Request – error details reported in JSON response
Status
 401 Unauthorized – error details reported in JSON response
Codes:
 403 Forbidden – error details reported in JSON response
 404 Not Found – error details reported in JSON response 
JSON Request Single:
{
  "ownerid" : ID6
  "gateway"  : ID6 or EUI64 or MAC
  "claim"   : STRING
}
 
JSON Request Bulk:
{
  "ownerid" : ID6
  "gateways" : [ {"gateway": ID6, "claim": STRING}, ..]
}
 
JSON Response:
[
 {
    "gateway": ID6
    "error" : STRING // only on failure
 }
  ..
]
 
Example Request:
POST /api/v1/gateway/claim HTTP/1.1
Host: gwjs.sm.tc:9193
Content-Type: application/json
{
   "ownerid": "::1",
   "gateway":  "00-00-00-FF-FE-00-0A-BC",
   "claim":   "VfjK89h3"
}
 
Example Response:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
[ {"gateway":  "0:ff:fe00:abc" } ]
 
Owner API: Setup
Allows an owner to configure the endpoint URI and corresponding credentials. The endpoint URIs and
credentials are configurable for both LNS and CUPS instances.
POST /api/v1/gateway/setup
Response Headers:
   Content-Type – application/json on success 
 200 OK – no error
 400 Bad Request – error details reported in JSON response
Status
 401 Unauthorized – error details reported in JSON response
Codes:
 403 Forbidden – error details reported in JSON response
 404 Not Found – error details reported in JSON response 
JSON Request Single:
{
   "ownerid"    : ID6
   "gateway"     : ID6
   "cupsUri":   : STRING // URI
   "cupsKey"    : B64STR // bytes of DER key or HTTP 'Authorization' Header (including \r\n)
   "cupsCrt"    : B64STR // bytes of DER certificate
   "cupsTrust"  : B64STR // bytes of DER certificate
   "lnsUri":    : STRING // URI
   "lnsKey"     : B64STR // bytes of DER key or HTTP 'Authorization' Header (including \r\n)
   "lnsCrt"     : B64STR // bytes of DER certificate
   "lnsTrust"   : B64STR // bytes of DER certificate
   "fwcrc"      : INT    // firmware CRC
   "fwafter"    : ISOTIME// ISO time string after which a single firmware update is provided ONCE.
}
 
JSON Request Bulk:
{
   "ownerid"    : ID6
   "gateways"    :
   [
     {
       "gateway"     : ID6
       "cupsUri":   : STRING // URI
       "cupsKey"    : B64STR // bytes of DER key or HTTP 'Authorization' Header (including \r\n)
       "cupsCrt"    : B64STR // bytes of DER certificate
       "cupsTrust"  : B64STR // bytes of DER certificate
       "lnsUri":    : STRING // URI
       "lnsKey"     : B64STR // bytes of DER key or HTTP 'Authorization' Header (including \r\n)
       "lnsCrt"     : B64STR // bytes of DER certificate
       "lnsTrust"   : B64STR // bytes of DER certificate
       "fwcrc"      : INT    // firmware CRC
     }
     ..
   ]
}
 
JSON Request Mixed:
To simplify setting up a large number of gateways, parameters common to all gateways can be specified
at the top level of a mixed request. The following code example shows a mixed request where the URI
and trust base for the LNS are specified at the top level, and the gateway-specific client certificate and
key are specified individually.
{
   "ownerid"    : ID6
   "lnsUri":   : STRING
   "lnsTrust"  : B64STR
   "gateways"    :
   [
     {
       "gateway"     : ID6
       "lnsKey"     : B64STR
       "lnsCrt"     : B64STR
     }
     ..
   ]
}
 
JSON Response:
[
 {
    "gateway": ID6
    "error" : STRING // only on failure
 }
  ..
]
 
Detailed Description
The API call allows an owner to configure corresponding URIs for CUPS and LNS servers implementing LoRa
Basics Station protocols. The URIs are encoded as ASCII. All credential parameters (trust, certificate and key)
are encoded as Base64.
Note: If a parameter is not specified, its value will be merged with the existing value in the gateway join server
DB.
When using HTTP (for CUPS) or Web Socket (for LNS) as URIs, all credential parameters can be omitted.
Their values will be set to null, that is, no server authentication and no client authentication will be enabled. In
other words, the communication channel will not be secure.
When using HTTPS (for CUPS) or Web Socket Secure (for LNS), trust must be specified for server
authentication. Furthermore, if the certificate is not empty, certificate-based client authentication requires that
the key be a Base64 string encoding of the DER format of the private key for the gateway. If the certificate
parameter is not present or an empty byte string, the key parameters must be a Base64-encoded string
containing the Authorization HTTP header, which will be used for token-based client authentication.
Example Request
POST /api/v1/gateway/setup HTTP/1.1
Host: gwjs.sm.tc:9193
Content-Type: application/json
 
{
  "ownerid"     : "::1",
  "gateway"      : "00:00:00:ff:fe:00:0a:bc",
  "cupsUri"     : "http://some.cups.com:7654",
  "cupsKey"     : "QXV0aG9yaXphdGlvbjogU29tZVNlY3JldEdhdGV3YXlUb2tlbiE="
}
 
Example Response
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
 
[ { "gateway" : "0:ff:fe00:abc" } ]
 
Owner API: Delete
Deletes a single gateway or set of gateways for the current owner. Deleting a gateway effectively releases (“un-
claims”) it from the gateway join server. This allows the ownership of the gateway to be changed.
POST /api/v1/gateway/delete
Response Headers:
   Content-Type – application/json 
 200 OK – no error
 400 Bad Request – error details reported in JSON response
Status
 401 Unauthorized – error details reported in JSON response
Codes:
 403 Forbidden – error details reported in JSON response
 404 Not Found – error details reported in  JSON response
JSON Request Single:
{
  "ownerid" : ID6
  "gateway"  : ID6
}
 
JSON Request Bulk:
{
  "ownerid" : ID6
  "gateways" : [ID6, ..]
}
 
JSON Response
[
 {
    "gateway": ID6
    "error" : STRING // only on failure
  },
  ..
]
 
Example Request
POST /api/v1/gateway/delete HTTP/1.1
Host: gwjs.sm.tc:9193
Content-Type: application/json
{
   "ownerid": "::1",
   "gateway":  "00-00-00-FF-FE-00-0A-BC"
}
}
 
Example Response
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
[ {"gateway":  "0:ff:fe00:abc"} ]
 
Owner API: Add
Adds a gateway for the specified owner. This operation is for gateways which have been manufactured without
an embedded claim secret. The gateway is implicitly claimed by the owner for whom it is added. The same
token should be used in the corresponding cups*.key files for the LoRa Basics Station configuration. Adding a
gateway will fail if the gateway already exists or conflicts with an existing batch.
The number of calls for the Add operation is strictly limited per owner. The default limit is 64.
The token is a string. The same string should be placed as a proper HTTP header (i.e. with \r\n as end-of-line
delimiters in the corresponding cups*.key files in the LoRa Basics Station home folder.
Note: The cups*crt should be empty or removed.
Example cups.key
Authorization: TOKEN\r\n
 
Example Request
POST /api/v1/gateway/add HTTP/1.1
Host: gwjs.sm.tc:9193
Content-Type: application/json
{
  "ownerid": "::1",
  "gateway":  "00-00-00-FF-FE-00-0A-BC",
  "flavorid": "Kerlink",
  "token":   "HJg87hjgsadi8732kh=="
}
 
Example Response
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
[ {"gateway": "0:ff:fe00:abc"}]
Building a LoRa®-based Device End-to-End with Arduino
In this guide we will walk you through building your own LoRa®-based node from end-to-end using an
Arduino board and Dragino shield. We are using a moisture sensor in this tutorial, but there are many potential
uses for LoRa devices; alternative sensors for your node could include temperature, humidity, motion, air
quality, light, accelerometers, and more.  
What are LoRa and LoRaWAN®?
LoRa, is an RF modulation technique which allows for extremely low powered wireless communication
systems. Since the frequencies used are orders of magnitude smaller than other common wireless
communication methods, such as Wi-Fi, the range of transmission is much larger; up to 10 miles or more in
rural areas with a clear line of sight. Coupling this long-range transmission with ultra-low power requirements
makes LoRa an ideal choice for battery-powered Internet of Things (IoT) devices with applications that
necessitate communication with widely-distributed systems.
LoRaWAN® is a protocol based on an open-source specification. In short, LoRaWAN is an example of a low
power wide area network that is based on LoRa radio modulation. This standard allows the wireless connection
of LoRa-based devices (nodes) to the internet and helps ensure compatibility of devices among manufacturers
around the world. It is even possible, as we will outline in this guide, to build your own custom LoRa end node
which can transmit information to other LoRa devices and the internet via a LoRaWAN network server (LNS).

Figure 1: LoRaWAN network high level architecture.

                                                        
The architecture of a LoRaWAN network is shown in Figure 1. The end devices – or nodes – transmit their
payloads in what is known as an uplink message, to be picked up by a LoRaWAN gateway. A key aspect of
LoRaWAN is that a device is not associated with a single gateway and its payloads may be picked up by any
number of LoRaWAN gateways within the device’s range. In theory an entire city could be covered by a just a
handful of gateways and messages from devices belonging to any user could be detected anywhere in the city.
The gateway then passes messages to its associated network server, usually carried out over Wi-Fi or Ethernet.
However, cellular and satellite gateways are available to enable very remote solutions without relying on an
internet connection. There are various options for network servers, for example third-party public network
servers are provided by The Things Network (TTN) and Helium, among others. For more information about
choosing your network server refer to this guide.
The LNS receives the messages from the gateway and checks whether the device is registered on its network;
the LNS also carries out deduping, since the message may be received and uploaded by multiple gateways. The
message is then forwarded to the application server on which the device is registered.
Communication is also possible in the other direction, where a message is sent as a downlink to the node. The
downlink message is sent from the application server to the network server. The network server then queues the
downlink, and when the device next sends an uplink message, the network server will pass the downlink
message to the nearest gateway which received the uplink. The gateway then broadcasts the downlink message
for the device to receive.
Common uses for a downlink message are to update a device’s broadcast settings, for example, to trigger
updates more or less frequently or trigger some other action, such as causing a device to open, closing a water
valve or turning an A/C unit on or off.
For a detailed look at LoRa and LoRaWAN including RF modulation, more information on architecture
including the technical detail on how devices join the network using a Join Server, and different classes of
devices, refer to our technical paper on 'What are LoRa and LoRaWAN?'
What Will We Build?
This guide is split into three stages:
1. We will build a LoRa-based end node to measure and communicate the moisture level in soil. This is a
great example of the power of LoRa-based communication, since detecting soil moisture levels is key to
many agricultural processes and is often challenging given the wide geographical areas where wireless
monitoring is needed. We will set up a detector node which will connect to a moisture sensor and then
send a LoRa payload containing the moisture level in the soil at regular intervals.
2. We will build a LoRa receiver node which will receive the payload and log the moisture level to the
console.

Figure 2: Schematic of the system for stages 1 and 2.

The moisture level is read by the LoRa-based broadcast node which broadcasts a message. The receiver
node receives the message, logging it to the Serial Monitor in the Arduino IDE
3. We will then use the LoRaWAN specification and connect our moisture detection node to The Things
Network, where we will be able to see the moisture level of the soil.
 

Figure 3: Schematic of the system for stage 3.

The moisture level is read by the LoRa broadcast node which broadcasts a LoRa uplink. The uplink is
received by the LoRaWAN gateway. The gateway sends the message over Wi-Fi to the TTN network
server. The node uplink is then visible in the TTN Console.
If you are limited by time, budget or hardware availability, it is possible to complete stage 1 and then either one
of;
a. Stage 2, explore LoRa in a local setting, node-to-node
b. Stage 3, explore LoRaWAN and send messages via the TTN network server

Objectives
By the end of this tutorial we will know how to:
 Build a LoRa-based node using the Dragino shield for LoRa devices and an Arduino Uno
 Connect a moisture sensor and configure the node to send moisture readings on a set interval
 Build a LoRa-based node to receive and log messages
 Determine a sensible uplink frequency for our device
 Build a LoRa-based end device connected to TTN via a LoRaWAN gateway
Hardware Recommendations
There are many manufacturers of certified hardware which can be used to create your solutions. The Semtech
catalog is a great reference for hardware, and contains listings from companies offering LoRa-based hardware
and software products, solutions and services.
For this tutorial we recommend the following reference hardware:
Stage 1: Hardware Recommendations for Building a Broadcasting LoRa-based Node (Required)
A. 1 x Arduino Uno (or other Arduino board compatible with the shield)
o US: Amazon.com, Arrow, Mouser
o UK: CPC, Amazon.co.uk, RS Components
B. 1 x Dragino’s Arduino Shield featuring LoRa technology, local variant
o US (915Mhz model): Amazon.com, Robotshop.com
o UK (868Mhz model): CPC, Amazon.co.uk
C. 1 x Grove Moisture Sensor by Seeed Studio (other sensors are available but may require soldering)
o US: Amazon.com, Arrow, Mouser
o UK: CPC, RS Components
D. 1 x Grove 4 pin JST to male jumper cable (to connect the moisture sensor to the Arduino board)
o US: Amazon.com, Mouser
o UK: CPC, Amazon.co.uk
E. 1 x USB-B Male to USB-A Male cable (to connect the Arduinos to the computer)
o US: Amazon.com
o UK: CPC
F. 1 x 9V battery
o US: Amazon.com
o UK: CPC
G. 1 x Battery clip to barrel jack connector (or other compatible portable power supply for the broadcasting
Arduino)
o US: Amazon.com, Arrow
o UK: Amazon.co.uk, Robotshop
Stage 2: Hardware Recommendations for Building a Receiver LoRa-based Node to Enable Node-to-Node
Communication
This stage is optional, although if you choose not to complete it, you should still complete stage 3.
A. 1 x Arduino Uno (or other Arduino board compatible with the shield)
o US: Amazon.com, Arrow, Mouser
o UK and EU: CPC, Amazon.co.uk, RS Components
B. 1 x Dragino’s Arduino Shield featuring LoRa technology, local variant
o US (915Mhz model): Amazon.com, Robotshop.com
o UK (868Mhz model): CPC, Amazon.co.uk
Stage 3: Hardware Requirements for Connecting the LoRa-based Device to a Network Server (Optional)
This stage is optional, although if you choose not to complete it you should still complete stage 2.
A. 1 x The Things Indoor LoRaWAN gateway
o US (915Mhz model): Adafruit
o UK and EU (868Mhz model): Connected Things Store
Alternatives
If you have a different Ardunio board, you may use that instead of the Arduino Uno. However, you must
ensure the shield is compatible with your board. The Dragino shield is listed as compatible with Ardunio
Leonardo, Uno, Mega, and DUE.
If you are unable to acquire the Dragino shield listed above, or would prefer to choose your own, you can do
so. The shield needs to be listed as compatible with your Arduino board. LoRa uses license-free bandwidth, and
the frequencies are different depending on the region. To use LoRa-based radios legally, the shield must operate
on, and only be used with, the frequencies designated for your region.  
If you are within range of a LoRaWAN gateway already, you could use that instead of purchasing your own.
You can find worldwide coverage and links to operator maps on the LoRa Alliance® home page.
We recommend the Wi-Fi-connected indoor LoRaWAN gateway from The Things Industries for its low cost,
but there are other options:
A. More expensive gateways which can be used outdoors and/or have a greater operating range due to a
more sophisticated antenna, or that can be connected via Ethernet.
B. Available single-channel gateways which are not fully LoRaWAN-compliant, but could provide a
cheaper alternative to a multichannel gateway for initial development or hobbyist purposes.
C. Building your own LoRaWAN-compliant gateway using a Raspberry Pi and a Gateway HAT. TTN has
published a guide on how to do this; Helium has a similar guide.
It is essential to ensure the gateway operates on the same frequency as the shield you have selected, designated
for your region, and that will work with your chosen network server. TTN has a list of tested compatible
gateways; Helium has a similar list.
Software
In order to configure the Arduino nodes we will be using the Arduino IDE, which you can download for
Windows, Mac OS X or Linux from the official Arduino website.

Putting It All Together

Stage 1: Build a broadcasting LoRa-based node
In this first stage we will build the LoRa-based moisture-sensing broadcasting node and configure it to send the
moisture reading every 30 seconds.
Assemble the Arduino, Dragino shield and moisture sensor
If you happen to have the Grove base shield, you can add the shield to your Arduino and plug the Grove
Moisture sensor directly into the A0 analog sensor port; otherwise follow along with these steps.
1. Place the shield next to the Arduino so that the both the shield and the Arduino have the same number of
pins at the top as each other, and the same number of pins at the bottom (as seen in Figure 4).

Figure 4: Arduino and shield side-by-side, ready to mount

2. Without turning the shield, place it directly on top of the Arduino so that the pins on the shield go into
the pin headers on the Arduino and push firmly down (see Figure 5).
 Figure 5: Arduino and shield, mounted
3. Attach the antenna to the shield, screwing it in clockwise (Figure 6).

Figure 6: Assembled Arduino and shield, with antenna

  
Figure 7: Screwing the antenna onto the shield
4. Locate the JST-to-male jumper cable, and the Grove Moisture Sensor.

Figure 8: (left to right) Grove Moisture Sensor, JST to male jumper cable, assembled Arduino and
shield
 
5. Connect the male end of the jumper cable to the Grove Moisture Sensor, pushing firmly to clip it into
place (Figure 9).
 Figure 9: The Grove Moisture Sensor with male jumper connected
6. At the other end of the JST-to-male jumper cable are 4 colored wires. We need to plug these into the
terminals on the shield.
a. VCC (red wire) to the 5V terminal (Figure 10)
b. GND (black wire) to GND terminal ( Figure 11)
c. SIG (yellow wire) to an Analog terminal, A0 ( Figure 12)
d. The white wire is not used, we can connect it to the second GND terminal to keep it out of the
way (Figure 13)

Figure 10: Red wire connected to the 5V terminal

Figure 11: Black wire, connected to a GND terminal

Figure 12: Yellow wire, connected to the A0 terminal

 Figure 13: All wires connected, including unused white wire
The end node is now built.
Setup the Arduino IDE
We need to install the open-source library, Arduino LoRa by Sandeep Mistry. This will allow us to send and
receive data using LoRa-based radios. Then, we will select our board.
1. Download and install the latest Arduino IDE (1.8.12 at time of writing).
2. Open the Arduino IDE.
3. At the Arduino IDE menu, select Sketch > Include Library > Manage Libraries.
 
Figure 14: Selecting ‘Manage Libraries’ in the Arduino IDE
4. In the Library Manager window that opens, search for “LoRa.”
5. Select the latest version of the LoRa library,  (0.7.2 at time of writing), and select Install.

Figure 15: Installing the LoRa library in Arduino Library Manager

6. At the Arduino IDE menu, select Tools > Board > Arduino Uno (or whichever board you are using for
this tutorial).
 Figure 16: Selecting your board in the Arduino IDE
Configure the LoRa-based Node Moisture Sensor
We are going to demonstrate sending a moisture reading at a regular set interval. If you did not purchase the
second Arduino and Dragino shield, proceed to section 3.
1. At the Arduino IDE menu, select File > New.
2. Copy the following code snippet:
#include
void setup() {
  Serial.begin(9600);
  while (!Serial);
  Serial.println("LoRa Sender Test");
}
void loop() {
  Serial.println("Hello.");
  delay(30000);
}

This is a very simple starting sketch. We will build on this in the following steps.

The setup function will be executed first; this function sets up the console logging so that we can see the
readings logged in the Arduino IDE Serial Monitor.

The loop function will log a message every 30 seconds.

3. Connect the Arduino to the computer’s USB port using the USB-B cable. We should see a power LED
illuminate on the Arduino and the shield.
4. At the Arduino IDE menu, select Tools > Port. We need to select the Serial Port that the Arduino is
connected to. Select the port which has the model of Arduino named alongside. If none of the ports are
labelled, disconnect the Arduino board and reopen the menu; the entry which disappears should be your
board. Reconnect the board, then select the entry which had disappeared.
5. At the top left of the sketch window, select the checkmark Verify icon. This will verify the sketch,
which checks it for errors.
 Figure 17: Verifying the sketch
6. At the top of the sketch window, select the right arrow Upload icon, to the right of the Verify icon
(Figure 18). This will upload the sketch to the device.

We will see a message Done uploading at the end of the sketch file window, confirming the upload has
taken place.
 Figure 18: Uploading the sketch
7. At the menu, select Tools > Serial Monitor. The Serial Monitor window will open.
8. Select the 9600 baud option from the drop-down menu at the bottom-right of the Serial Monitor (Figure
19).
 Figure 19: Changing the baud rate in the Serial Monitor
9. If the code uploaded successfully, we will see the Hello message logged to the Serial Monitor every 30
seconds.

Figure 20: Arduino Serial Monitor showing message logging on 9600 baud.
10. Now we will extend this sketch to send the current moisture reading from the sensor connected to the
A0 analog terminal. Add the lines marked in bold to our sketch.
 
 #include
#define SensorPin A0
int sensorValue = -1;
void setup() {
  Serial.begin(9600);
  while (!Serial);
  Serial.println("LoRa Sender Test");
}
void loop() {
  sensorValue = analogRead(SensorPin);
  Serial.print("Reading is: ");
  Serial.println(sensorValue);
  delay(30000);
}

The declarations at the top of the sketch define which analog pin the sensor is connected to and set an initial
value of -1.
 
Within the loop we then use the analogRead function to get the current reading from the moisture sensor via the
sensor pin. The moisture sensor reading is then printed out to the Serial Monitor.
 
11. Verify and upload the new sketch to the Arduino. Open the Serial Monitor. You should see the real-time
sensor value logged every 30 seconds, which for now will read ‘0’.

Figure 21: Arduino Serial Monitor showing sensor readings

12. We can test the Soil Moisture sensor by locating two pots of soil, making one pot of soil damp and
keeping one dry. If you do not have a pot of soil, use a shallow glass of water, but take care to only
insert the metal coated probes into the water and keep liquids away from the top of the sensor above the
prongs, as well as away from the Arduino to avoid potential short circuits.

Insert the sensor into the pot of moist soil. The sensor measures across the whole length of the probes,
so make sure you push the majority of the length of the probe into the soil to get a good reading (see
Figure 22).
 
 Figure 22: Testing the assembled moisture sensor
13. Inspect the Serial Monitor to see the readings. The higher the number, the more moisture has been
detected in in the soil.

Suggested mappings for the Grove Moisture Sensor measurement are:

- 0: the sensor is in the open air
- 1-299: dry soil
- 300-699: moist soil
- 700-949: waterlogged soil
- 950: the sensor is immersed in water, e.g. the glass of water
14. Move the sensor to a drier pot of soil and see the numbers decrease in the Serial Monitor.
15. We will put this reading into a LoRa packet that the node will send every 30 seconds. Add the following
bolded lines of code to the sketch:
#include
// Add the LoRa library
#include
#define SensorPin A0
int sensorValue = -1;
void setup() {
  Serial.begin(9600);
  while (!Serial);
   Serial.println("LoRa Sender Test");
  // Initalize the LoRa radio on the shield.
  // NB: Replace the operating frequency of your shield here.
  // 915E6 for North America, 868E6 for Europe, 433E6 for Asia
  if (!LoRa.begin(868E6)) {
    Serial.println("Starting LoRa failed!");
    while (1);
 }
}
void loop() {
  sensorValue = analogRead(SensorPin);
  Serial.print("Reading is: ");
  Serial.println(sensorValue);
  // Transmit the LoRa packet
  LoRa.beginPacket();
  LoRa.print(sensorValue);
  LoRa.endPacket();
  delay(30000);
}
We first add the reference to the LoRa library.
Next, we initialize the LoRa radio on the Dragino shield with LoRa.begin.
We transmit the LoRa packet containing the sensor value using LoRa.beginPacket, LoRa.print and
LoRa.endPacket.
 
16. Edit the code in bold to insert the operating frequency for your region. For the U.S. this is ‘915E6’, for
Asia ‘433E6’.
…
  Serial.println(“LoRa Sender Test”);
  // Initalize the LoRa radio on the shield.
  // NB: Replace the operating frequency of your shield here.
  // 915E6 for North America, 868E6 for Europe, 433E6 for Asia
  if (!LoRa.begin(868E6)) {
    Serial.println("Starting LoRa failed!");
    while (1);
 }
…
17. Verify and upload the sketch to the Arduino.
18. Check the Serial Monitor to verify the device is still logging readings every 30 seconds.
Well done! – We now have a working wireless LoRa-based node which broadcasts a soil moisture reading at
regular intervals.
If you purchased a second Arduino and shield, continue to Stage 2: Build a LoRa-based Receiver to Enable
LoRa-based Node-to-Node Communication, to build a LoRa-based node to receive the message locally.
If you did not purchase a second Arduino and shield, continue to Stage 3: Connecting the LoRa-based Node to
a Network Server, to setup your gateway and receive the message via the cloud.

Stage 2: Build a LoRa-based Receiver to Enable LoRa-based Node-to-Node Communication

In this stage, we will use another end node to receive messages from our broadcasting node and print the
contents out to the Serial Monitor. If you did not purchase a second Arduino and shield, you can skip this step
and proceed to Stage 3: Connecting the LoRa-based Node to a Network Server.
Assemble the Receiver Arduino
We will assemble a second Arduino and Dragino shield, which we will use to receive the message.
 1. Place the Dragino shield next to the Arduino, so that the both the shield and the Arduino have the same
number of pins at the top as each other, and the same number of pins at the bottom (as seen in Figure 4).
2. Without turning the shield, place it directly on top of the Arduino, so that the pins on the shield go into
the pin headers on the Arduino. Push firmly down. (see Figure 5).
3. Attach the antenna to the shield, screwing it in clockwise.
Configure the LoRa-based Receiver
Now that we have confirmed that the sensor is making readings and the code is being looped over every 30
seconds. Now, it is time to use the second node to receive the moisture readings being sent out.
1. Connect the receiver Arduino to the computer’s USB port using the USB-B cable. We should see a
power LED illuminate on both the Arduino and the shield.
2. Start a new sketch (File > New) and paste in the following code:
#include
#include
void setup() {
  Serial.begin(9600);
  while (!Serial);
  Serial.println("LoRa Receiver Test");
  // Replace the operating frequency of your shield here.
  // 915E6 for North America, 868E6 for Europe, 433E6 for Asia
  if (!LoRa.begin(868E6)) {
    Serial.println("Starting LoRa failed!");
    while (1);
 }
}

We first add the reference to the LoRa library.

We initialize the LoRa radio on the shield with LoRa.begin.
We transmit the LoRa packet containing the sensor value using LoRa.beginPacket, LoRa.print and
LoRa.endPacket.
3. Edit the code in bold to insert the operating frequency for your region. For the U.S. this is ‘915E6’, for
Asia ‘433E6’.
…
  Serial.println(“LoRa Receiver Test”);
  // Replace the operating frequency of your shield here.
  // 915E6 for North America, 868E6 for Europe, 433E6 for Asia
  if (!LoRa.begin(868E6)) {
    Serial.println("Starting LoRa failed!");
    while (1);
…
4. Update the sketch to add the following bolded lines, which will parse and LoRa packets the node
receives:
 
…
    while (1);
 }
}
void loop() {
  // see if a packet was received
  int packetSize = LoRa.parsePacket();
  if (packetSize) {
    // if a packet size is defined, a packet was received
    Serial.println("");
     Serial.println("Received packet!");
   }
}
 
The loop continually attempts to parse any LoRa packets. If a message is received, the packetSize will be
returned and a message will be printed to the Serial Monitor.

Figure 23: Arduino Serial Monitor showing the receipt of LoRa packets
 
5. To read out the payload sent in the packet, update the sketch to add the following bolded lines:
 
…
void loop() {
  // see if a packet was received
  int packetSize = LoRa.parsePacket();
  if (packetSize) {
    // received packet
    Serial.println("");
    Serial.println("Received packet: ");
    // read the packet
    String message = "";
    while (LoRa.available()) {
      message += (char)LoRa.read();
    }
    // print the Packet and RSSI
    Serial.println(message);
    Serial.print(“RSSI: “);
    Serial.println(LoRa.packetRssi());
 }
}
 

We use LoRa.available and LoRa.read to read each character of the packet, printing them to the Serial Monitor.
We use LoRa.packetRssi to print the Received Signal Strength Indicator (RSSI). RSSI is measured in dBm and
is the received signal power in milliwatts. The closer the measurement is to 0, the better, indicating a strong
signal.
 
6. Plug the Arduino into the computer using the USB-B cable.
7. Verify and upload the code to the Arduino.
8. Locate the broadcasting node we built in Stage 1.
9. Connect the 9-volt battery to the battery clip, and the barrel jack into the barrel jack of the broadcasting
node. For now, keep the broadcasting node close to the receiving node.

Figure 24: Left to right, battery clip, 9-volt battery, broadcasting node
 
 Figure 25: Battery clip connected to 9-volt battery, barrel jack connected to Arduino
10. Check the Serial Monitor. If all is well, we will see received packets being logged out every 30 seconds.
This means the receiving node is receiving the packets from the broadcasting node (Figure 26).
 Figure 26: Arduino Serial Monitor showing received packet values
11. Move the broadcasting node away from the receiving node. Return to the Serial Monitor and observe
the message and the change in RSSI.
12. See how far you can maintain a signal by moving the nodes farther apart. Using a more powerful radio,
a much wider range can be achieved, but even with the shield, we can observe the range is much greater
than other protocols, such as Wi-Fi.
13. Unplug the battery pack from the broadcasting node when you are finished to preserve battery life. In a
real-world device, you would make use of sleep functionality to minimize battery consumption during
broadcasts.
We have now successfully set up the broadcasting node and seen the LoRa packets being received by a second
receiving node.
In the next stage of this tutorial we will move on to reconfigure the broadcasting node to connect to a TTN
server to demonstrate a full end-to-end solution.

Stage 3: Connecting the LoRa-based Node to a Network Server

In the first stage, we built the LoRa-based moisture-sensing broadcasting node and configured it to send the
moisture reading every 30 seconds, Now, we can reconfigure the device to allow connection to a public
network server. In this case we’ll be using The Things Network (TTN), but as discussed in the introduction to
this guide, you can use another public network server such as Helium, or even a private network if you have
access to one. Connecting to a network server is the next step to building a fully LoRaWAN-compliant IoT
solution, and doing so allows messages from our LoRa-based nodes to be viewed through an application server
to present data to end users.
Setup the Gateway
If you are using The Things Network’s indoor gateway, follow the official documentation from TTN to set it
up. If you are using another gateway to connect to TTN then you should be able to find instructions on the
manufacturer’s website, TTN gateway documentation pages, or you can search and ask for help on The Things
Network forum. If you are using Helium and want to connect a LoRaWAN gateway or build your own hotspot,
rather than purchasing a Helium hotspot, more information can be found on the Hotspot section of
Helium’s developer site.
Add the Device to The Things Network
1. If you do not have an account already, register a new account with TTN, or login to your existing
account.
2. On the top menu click on Console and select Applications.

An application allows devices to communicate outside of the network server, for example, into AWS
IoT, Azure IoT or private servers.

Each device registered to TTN must be added to an application, so we will need to add at least one to
associate with your LoRa-based node.

Figure 27: TTN Console homepage

3. Select add application.
 Figure 28: TTN applications page
 
4. Fill out the form as follows:
a. Application ID: supply a unique ID using only lower case, alphanumerical characters and
nonconsecutive ‘-‘ and ‘_’ symbols. E.g. ‘moisture-sensor-application-q123’ where q123 is
random. The ID must be unique throughout TTN, so you may need to try a few times.
b. Description: choose your own description, e.g. ‘Moisture sensor application as part of Semtech
tutorial’
c. Application EUI: you can use the auto-generated EUI. The application EUI (or AppEUI)
globally identifies the application.
d. Handler registration: this determines the region of TTN where the packet will be transmitted.
You should select the handler that matches the region you are in, ‘ttn-handler-eu’ in the EU, ‘ttn-
handler-us-west’ in the U.S., ‘ttn-handler-asia-se’ in Asia, etc. This should be automatically
detected for you.
Figure 29: Adding an application to TTN
5. Click Add application.
6. If any errors are shown, for example, if the Application ID was not unique, update and click Add
application again.
7. We are taken to the Application Overview page where we can see our application and its EUI. Locate
the Devices section of the page, and click register device.

Figure 30: Application Overview page

8. Fill out the form as follows:
a. Device ID: give the device a unique identifier for use in this application, using lower case
alphanumerical characters and nonconsecutive ’ –‘ and ‘_’, e.g. stg-moisture-1.
Note: The device ID cannot be changed later.
b. Device EUI: click the Generate button to the left of the input field to generate the device EUI
automatically. When you purchase a device from a third-party, they will often supply you with a device
EUI, and you would need to add the one supplied here.
c. App Key: this will be automatically generated. The app key, or ‘application key’ is used to secure
communication between the device and the network.
d. App EUI: this field will be prepopulated with the App EUI of the application that we just created.

Figure 31: Adding a device to our application

9. Click Register.
10. If any errors are shown, for example, if the Device ID was not valid, update and click Register again.
11. We will be taken to the Device Overview page for our registered device.

The Device EUI, Application EUI and App Key displayed on the Device Overview page will be used to
configure our node and activate it via Over-The-Air Activation (OTAA). Once complete, when the node
sends an uplink message the network server will know that the device is registered with itself and this
application.
12. Save the following strings into another file, following the instructions below to display them in the
correct format:
a. Device EUI:
i. click the <> button (1st left) to toggle between hex and C-style
ii. click the second button from the left to toggle to lsb (least significant byte first, which
reverses the bytes)
iii. click the copy button on the far right
iv. paste into a file, labelling this ‘Device EUI’
b. Application EUI:
i. click the <> button (1st left) to toggle between hex and C-style
ii. click the second button from the left to toggle to lsb format
iii. click the copy button on the far right
iv. paste into a file, labelling this ‘Application EUI’
c. App Key:
i. click the <> button (1st left) to toggle between hex and C-style
ii. verify the format is msb (most significant byte first)
iii. click the copy button on the far right
iv. paste into a file, labelling this ‘App Key’
 Figure 32: Device details page on TTN showing the Device EUI and Application EUI in
the format required
The device is now registered in TTN, and we have our keys to use for OTAA.
Setup the Arduino IDE for LoRaWAN
We need to install the open-source library MCCI LoRaWAN LMIC (LoRaWAN-MAC-in-C) that will allow us
to send and receive data using LoRa-based radios, edit a config file (unless you are based in the U.S.), and
select our board.
1. Open Arduino IDE.
2. At the Arduino IDE menu select Sketch > Include Library > Manage Libraries.
3. Search for MCCI LoRaWAN LMIC and install the MCCI LoRaWAN LMIC library by IBM, Matthijs
Kooijman and others. At the time of this writing, the latest version is 3.2.0.
 Figure 33: Arduino IDE Library Manager showing the installed LMIC library
4. At the menu select Tools > Board > Arduino Uno (or whichever board you are using for this tutorial)
to ensure that the correct board is still selected.
5. The LMIC library contains a flag to toggle between region frequencies. We next need to make sure the
correct frequency is selected for your region. If you are in the U.S., you do not need to perform these
remaining steps, since the default region is the U.S. region.
a. At the Arduino IDE menu select Arduino > Preferences > Settings, or File > Preferences on
Windows and Linux. Locate the Sketchbook location field (see Figure 34), we will refer to this
as  On MacOS or Windows the default location is in your
documents; /Users//Documents/Arduino, or D:\Users\\Documents\Arduino respectively. On
Linux the default location is /home/Sketchbook.

Figure 34: Arduino IDE settings screen showing Sketchbook location

 b. Open your code editor, or install Visual Studio Code.
c. Open the file /libraries/MCCI_LoRaWAN_LMIC_library/project_config/lmic_project_config.h. This
file contains the settings for the LMIC library.
d. Edit lmic_project_config.h to comment the #define CFG_us915 1 line, and uncomment the frequency
for your country/region.
      The frequencies are:
      - CFG_eu868 – EU
      - CFG_us915 – U.S.
      - CFG_au915 – Australia
      - CFG_as923 – Asia
      - CFG_in866 – India
      - CFG_kr920 – South Korea
       For example, to use the EU frequency, comment and uncomment as follows:
// project-specific definitions
#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_au915 1
//#define CFG_as923 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP /* for as923-JP
*/
//#define CFG_kr920 1
//#define CFG_in866 1
…
 
 
6. Save the lmic_project_config.h file.
Configure the LoRa-based Node
Now, we’ll update the LoRa-based node we created in Stage 1 to use the LoRaWAN protocol to broadcast the
soil moisture readings over the network.
1. At the Arduino IDE menu, select File > New.
2. Copy the code below into the sketch. This code, and the code which follows, references the TTN-OTAA
sample provided with the LMIC library, which is found here.
#include
#include
#include
#define SensorPin A0
int sensorValue = -1;
// Pin mapping – set your pin numbers here. These are for the Dragino shield.
const lmic_pinmap lmic_pins = {
    .nss = 10,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 9,
    .dio = {2, 6, 7},
};
 
3. We import the LMIC and SPI library headers.

We define SensorPin, and sensorValue, as in Stage 1.

 
We set up the variable lmic_pinmap to tell the LMIC library which Arduino pins our shield uses. We
have supplied the pin mapping in the code above for the Dragino shield, but if you are using a different
shield, you will need to update this struct. Refer to your hardware documentation for the correct pin
mappings. The settings are:
                 - .nss, for the ‘slave select’ connection,
                - .rxtx, for controlling the antenna switch, not used by this software so set to
LMIC_UNUSED_PIN
                - .rst, reset pin, used to reset the transceiver
                - .dio, digital I/O pins to get status information from the shield, for example when a
transmission starts or is complete.

Learn more about pin mapping at the GitHub page for the LMIC library.
4. Add the bolded lines below to the sketch to set the variables for Over-the-Air device activation
(OTAA):
…
    .dio = {2, 6, 7},
};
 
// Insert Device EUI here
static const u1_t PROGMEM DEVEUI[8] = ;
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}
 
// Insert Application EUI here
static const u1_t PROGMEM APPEUI[8] = ;
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}
 
// Insert App Key here
static const u1_t PROGMEM APPKEY[16] = ;
void os_getDevKey (u1_t* buf) {  memcpy_P(buf, APPKEY, 16);}
 
5. Edit the code to replace the fields in tags with the values saved earlier from the TTN console.
a. <DEVICE_EUI> : The saved ‘Device EUI’
b. <Application_EUI> : The saved ‘Application EUI’
c. <APP_KEY> : The saved ‘Application Key’
6. Check that our code is formatted as below, with the keys from TTN.
…
// Insert Device EUI here
static const u1_t PROGMEM DEVEUI[8] = { 0x6B, 0x1E, 0x77, 0xEB, 0xDF, 0x69,
0x20, 0x00 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}
 
// Insert Application EUI here
static const u1_t PROGMEM APPEUI[8] = { 0x9E, 0x03, 0x03, 0xD0, 0x7E, 0xD5,
0xB3, 0x70 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}
 
// Insert App Key here
static const u1_t PROGMEM APPKEY[16] = { 0x69, 0x21, 0xFB, 0x85, 0xE4,
0x49, 0x05, 0x97, 0x4D, 0xCF, 0x8D, 0x33, 0x9C, 0xB1, 0x37, 0x9D };
void os_getDevKey (u1_t* buf) {  memcpy_P(buf, APPKEY, 16);}void
os_getDevKey (u1_t* buf) {  memcpy_P(buf, APPKEY, 16);}
 
7. To set the frequency of broadcast, add the bolded lines below to the sketch. We have chosen to
broadcast once every 150 seconds for this device.
 
…
 void os_getDevKey (u1_t* buf) {  memcpy_P(buf, APPKEY, 16);}
// Schedule uplink to send every TX_INTERVAL seconds
const unsigned TX_INTERVAL = 150;
 

The duty cycle, the amount of time a device is allowed to broadcast in the LoRaWAN spectrum, is regulated by
government. A duty cycle limit of 1% means that for any given time period the device may only broadcast for
1% of that time, e.g. 864 seconds within a 24-hour period. In addition, TTN has a fair usage policy limiting the
uplink time per node to 30 seconds per day.

There are calculators, such as this third-party one on GitHub, that allow us to estimate our airtime for an uplink
message. Once we have completed this tutorial, we will also be able to see the estimated airtime in the TTN
console at TTN console applications page > select our application > ‘Devices’ > select our device > ‘Data’
tab > select an uplink > ‘Estimated Airtime’ section. The following calculation can then be used to calculate
the minimum time between uplinks:

8. Add the following bold lines to the sketch file to define the method we will use to send an uplink:
…
const unsigned TX_INTERVAL = 150;
void do_send(osjob_t* j){
    // Check if there is not a current TX/RX job running
    if (LMIC.opmode & OP_TXRXPEND) {
        Serial.println(F("OP_TXRXPEND, not sending"));
    } else {
        // Prepare upstream data transmission at the next possible time.
        sensorValue = analogRead(SensorPin);
        Serial.println("Reading is: ");
        Serial.println(sensorValue);
        // int -> byte array
        byte payload[2];
        payload[0] = lowByte(sensorValue);
        payload[1] = highByte(sensorValue);
        // transmit packet at the next available slot. The parameters are
        // - FPort, the port used to send the packet – port 1
        // - the payload to send
        // - the size of the payload
        // - if we want an acknowledgement (ack), costing 1 downlink message, 0
means we do not want an ack
        LMIC_setTxData2(1, payload, sizeof(payload), 0);
        Serial.println(F("Payload queued"));
    }
}
 

The do_send function contains the code from Stage 1 to read the sensor. We then convert the reading into the
byte array packet, using lowByte and highByte to convert the integer value into a small 2-byte array. This tiny
payload is then sent using LMIC_setTxData2.
9. Add the following bolded lines to the sketch file to handle events from the LMIC library:
…
        Serial.println(F(“Payload queued”));
     }
}
static osjob_t sendjob;
void onEvent (ev_t ev) {
    switch(ev) {
        case EV_JOINING:
            Serial.println(“EV_JOINING”);
            break;
        case EV_JOINED:
            Serial.println(“EV_JOINED”);
            // We will disable link check mode, this is used to periodically verify
network connectivity, which we do not need in this tutorial
            LMIC_setLinkCheckMode(0);
            break;
        case EV_JOIN_FAILED:
            Serial.println(“EV_JOIN_FAILED”);
            break;
        case EV_REJOIN_FAILED:
            Serial.println(“EV_REJOIN_FAILED”);
            break;
        case EV_TXCOMPLETE:
            Serial.println(“EV_TXCOMPLETE”);
            // Schedule next transmission
            os_setTimedCallback(&sendjob, os_getTime() +
sec2osticks(TX_INTERVAL), do_send);
            break;
         default:
            break;
    }
}

The onEvent function is called from the LMIC library whenever events complete, such as transmission
complete (EX_TXCOMPLETE). We log join and transmission events to the Arduino Serial Monitor. When the
transmission is complete, we schedule the next uplink message via our do_send function using the
setTimedCallback method, the TX_INTERVAL constant.
10. Add the following bolded lines to the sketch file:
…
            break;
    }
}

void setup() {
    Serial.begin(9600);
    Serial.println(F(“Starting”));
    // Initalizes the LIMIC library,
    os_init();
    // Resets the MAC state – this removes sessions, meaning the device must
repeat the join process each time it is started.
    LMIC_reset();
    // Let LMIC compensate for an inaccurate clock
    LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
    // Disable link check validation – this is used to periodically verify network
connectivity. Not needed in this tutorial.
    LMIC_setLinkCheckMode(0);
     // Set data rate to Spreading Factor 7 and transmit power to 14 dBi for
uplinks
    LMIC_setDrTxpow(DR_SF7, 14);
    // Start job
    do_send(&sendjob);
}
 
void loop() {
    os_runloop_once();
}
 
In the function, we initialize the LMIC library using . We also reset the MAC state to ensure the join process
occurs each time the device is started, turn off link-check validation and set the spreading factor and transmit
power. We then call which will attempt to send the first message and start OTAA automatically.
The function calls LMIC’s method. This hands the loop function over to LMIC and the code then responds to
the event callbacks returned from LMIC in the method.
 
11. If you are in the U.S. and using TTN, joining is faster if we select channels 8-15 (subband 1) to
broadcast the joining message on.

If you are not using the U.S. frequency setting in the LMIC library, adding this line will cause an error
and, for Helium, you do not need to perform this step. This step is only for U.S.-based TTN users. If you
are using a different network server provider, ask them which subband they recommend for join
messages.

Add the following bolded lines to the setup function:

…
    // Set data rate to Spreading Factor 7 and transmit power to 14 dBi for uplinks
    LMIC_setDrTxpow(DR_SF7,14);
    // US only, select subband 1 (channels 8-15) for joining TTN
    LMIC_selectSubBand(1);
    // Start job
    do_send(&sendjob);
…
12. Plug in your gateway.
 
13. Sign in to the TTN console and open the Gateways page. Check to verify that your gateway is showing
as connected. At the time of writing this article there is a known bug in TTN Console which can cause
the gateway status to display incorrectly – so do not worry if your gateway is listed as ‘not
connected.’ Move onto the next steps and you should see the gateway display as connected as soon as
your LoRa-based broadcasting node sends a message to the LNS.
 Figure 35: TTN console showing connected gateway
14. Connect the broadcasting node Arduino to the computer’s USB port using the USB-B cable. We should
see a power LED illuminate on the Arduino and on the shield.
15. At the Arduino IDE menu, select Tools > Port. We need to select the serial port that the Arduino is
connected to. Select the port labeled with the model of your Arduino board. If none of the ports are
labelled, disconnect the Arduino board and reopen the menu; the entry which disappears should be your
board. Reconnect the board, then select the entry which had disappeared.
16. At the Arduino IDE menu, open Tools > Serial Monitor to open the Serial Monitor.
17. Verify and upload the sketch using the buttons in the Sketch Window menu bar.
18. We should see the logs showing the EV_JOINING and EV_JOINED messages in the Serial Monitor.
The device has now completed the OTAA process, using the Device EUI and Application Key.

If you only see the EV_JOINING message, double-check that the DEVEUI, APPEUI and APPKEY
settings are all correct, as added at the start of this stage.
 

Figure 36: Serial Monitor showing the join process

19. Navigate to the TTN console applications page > select our application > Devices > select our device
> Data tab. We will see the readings from the device.
 Figure 37: TTN console showing the application data tab
20. Next, we’ll add a decoder so we can read the payloads more easily. Navigate to the TTN console
applications page > Select our application > Payload Formats tab.
21. Complete the form as follows:
a. Payload Format: leave set to custom
b. Decoder tab: leave selected, paste the bolded lines below into the field below
function Decoder(bytes, port) {
  // Decode an uplink message from a buffer
  // (array) of bytes to an object of fields.
  var decoded = {};
  decoded.Moisture = bytes[0] + bytes[1] * 256;
  return decoded;
}
 
c. Payload: test the function by pasting in ’61 01’ and then select Test. We should see a reading in the
original numeric format, e.g:
{
  "Moisture": 353
}
 
 Figure 38: TTN console custom payload format decoder
 
22. Click the save payload functions button at the bottom of the page.
23. Navigate to the TTN console applications page > Select our application > Devices > Select your
device > Data tab. Here we can now see the readings from the device, alongside our translated payload.
 Figure 39: TTN console Application Data log showing moisture readings

Summary and Next Steps

In this tutorial we have built and configured, end-to-end, a LoRa-based device which broadcasts a reading from
an analog soil moisture sensor. The device has been registered with The Things Network and the broadcast
message, received by a configured gateway, appears in the TTN console.
You can improve the device you have built by configuring the LoRa-based message to broadcast only if certain
threshold criteria are met for the sensor reading. For example, you might want to send a message only if the
moisture sensor reading value is above a certain level, or if the value has changed from the previous reading.
You could attach multiple sensors to the same node; for instance, you might want to know the moisture reading
as well as the temperature and lighting levels. The node could then be configured to broadcast a payload
containing the current readings from all the sensors, or only broadcast if a series of criteria are met, e.g. only
broadcast if the moisture level is below a certain threshold and the temperature and light levels are above some
other thresholds. Remember to update the application payload formatter so that each reading shows in TTN
console data log. Also, remember to recalculate your broadcast delay time if you increase your payload size.
If you are planning to build multiple LoRa-based nodes, the ESP32 microcontroller can be used to build nodes
in a very similar way. There are many manufacturers of ESP32 boards, some with LoRa devices built-in. These
boards are considerably smaller and cheaper than Arduino boards, but often require some soldering to get
started. The boards can be programmed using the same LMIC library and should simply require the pin
mapping to be updated. The ESP32 boards also have built-in deep sleep methods, allowing you to easily set
sleep time between broadcasts or have the device sleep until an interruption is triggered by one of the sensors.
Putting the board to sleep between broadcasts is good practice and highly recommended for extending the
battery life of the LoRa-based node.
Now that you have a LoRa-based node broadcasting messages to a third-party network server, you can design
and develop your own dashboard or app and use the TTN API to fetch your device data and represent it in any
way you wish.
Coexistence of LoRaWAN and UHF RFID
LoRaWAN® is a low power wide area network (LPWAN) protocol that offers a compelling mix of long-range,
large link margin and low power consumption[1]. In recent years, we have seen an explosive expansion in the
deployment of LoRaWAN networks which addresses the needs of today’s Internet of Things (IoT) applications.
An illustration of the LoRaWAN protocol stack is shown in Figure 1. The physical layer can be implemented in
the sub-GHz ISM bands, for example, 902-928MHz in North America.
The ISM bands are unlicensed and anyone can operate within them as long as they comply with regulatory
requirements regarding transmitting power, power density, and frequency- hopping. In some regions, dwell
times and duty cycles are also regulated. The purpose of these requirements is to minimize the interference of
various wireless systems operating on the same frequency bands[2]. But despite these regulations, interference
between different systems can still occur, especially when a listen-before-talk (LBT) mechanism is not
required.

Figure 1: LoRaWAN Protocol Stack

One of the potential interferences which has attracted attention is the signal from the RFID systems, specifically
the UHF RFID systems which operate on the same 902 MHz - 928MHz frequency band in North America,
following EPC Gen2[3]. These dense RFID systems are frequently deployed in large retail stores, airports,
museums, and other large facilities which require inventory functionality. However, there is great potential for
the concurrent deployment of LoRaWAN-based IoT solutions in these same locations.
Semtech and other LoRaWAN ecosystem companies executed a joint investigation on the LoRaWAN
performance when co-locating and co-existing with a densely deployed UHF RFID system. The study portion
of the investigation evaluated the impact of the RFID system on a LoRaWAN network, and attempted to
identify an optimized solution to mitigate the interference. The solution from the study portion of this
investigation was validated by several field trial tests. The validated solution also provides a reference for when
a LoRaWAN network co-exists with other high-power systems that generate frequency-selective interference.
This study involved multiple stages of the investigation, theoretical calculation, controlled lab measurements,
channel plan optimization, and field measurements conducted in large-footprint retail stores.
This paper focuses on the configuration, methodology, results, and conclusions from the channel optimization
and field measurement aspects of this study.
Background
LoRa®-based Devices and the LoRaWAN Protocol
A LoRaWAN network is typically deployed in a star-of-stars topology, in which gateways relay messages
between end-devices and a central network server[4]. The gateways are connected to the network server via
standard IP connections. They act as transparent bridges, simply converting RF packets to IP packets and vice
versa. The wireless communication takes advantage of the long-range characteristics of the LoRa physical
layer, which allows a single-hop link between the end-devices and one or more gateways. LoRa-based end-
devices are capable of bi-directional communication. There is also support for multicast addressing groups so
that it is possible to make efficient use of the spectrum during specific tasks.
 Figure 2: LoRaWAN Network Architecture
As described in the introduction, the LoRaWAN physical layer relies on the LoRa/FSK link between the end-
devices and gateways, which uses the sub-GHz ISM bands[5]. Though robust to the co-channel and adjacent
channel interferences, some penalties can still be measured when strong interferers coexist, sharing the same
spectrum and space. 
The LoRaWAN regional parameters for North America has a fixed uplink and downlink channel plan. There
are a total of 64 125kHz uplink channels, spreading across the 902.3MHz to 914.9MHz bands, with 200kHz
channel spacing. For the downlink, eight 500kHz channels are specified, occupying the 923.3MHz to
927.5MHz range, with a channel spacing of 600kHz.
EPC Gen2 RFID System
The UHF RFID system in this study is deployed indoors for inventory-related applications. For this study, we
primarily considered the passive RFID system. The Interrogator (“Reader”) communicated with one or more
Tags by modulating a carrier using Phase Reversal Amplitude Shift Keying (PR-ASK), which itself used Pulse-
Interval Encoding (PIE) with a reference time interval of 25ms. This implementation is as defined by the EPC
Gen2 Air Interface Specification for a high-density multiple Interrogator environment.
The Interrogator both enables and communicates with the Tag using PR-ASK modulation. The Interrogator
switches to continuous wave (CW) mode after its downlink information has been delivered. The carrier tone is
then used by the Tag during the Tag-to-Interrogator communications period (i.e., the “Backscatter”
communications).
To achieve the desired range, the effective radiated power (ERP) of the Interrogator signal can be quite high.
The RFID system in this study delivered four watts (36 dBm) of output power with the help of a 6 dBi antenna.
Additionally, it used a channel spacing of 500kHz, pseudo-randomly hopping over a minimum of 50 channels,
and had a channel dwell-time approaching 400 ms, the maximum dwell-time allowed in the region.
The primary Tag sidebands were centered at 250kHz from the Interrogator CW frequency, as illustrated in
Figure 3. The ERP of these sidebands is a function of incident energy. Typically these are much lower than the
Interrogator signal power.
 Figure 3: Passive RFID channel implementation
In the United States, passive RFID Interrogators are considered frequency-hopping devices, falling under the
guidelines of CFR 47, Part 15.247[6]. Each single RFID Interrogator randomly hops among 50 channels. For
the default 500kHz channel spacing, the RFID Interrogators used the spectrum from 902.75MHz to
927.25MHz, covering a frequency range of 24.5MHz. This allowed for a 750kHz guard-band at the band-edges.
Co-Existence of LoRaWAN and RFID
The Impact of RFID on LoRaWAN
A co-located RFID Interrogator emitting 4 W ERP and sharing the same space and frequency spectrum can
impact the reception of LoRa packets under the following scenarios.
Co-channel Interference
As illustrated inFigure 4, the signal-to-interference-and-noise ratio (SINR) can be degraded when the RFID
Interrogator carrier shares the same channel frequency as the LoRa signal. Typical LoRa-based chipset
implementation requires -5 to -19.5 dB signal-to-interference ratio (SIR)[7]. When this occurs, filtering cannot
be applied to increase the rejection of the interference.

Figure 4: RFID Interrogator Co-channel with LoRa Carrier.

Adjacent-channel Interference

Figure 5: RFID Interrogator in adjacent channels of LoRa.

As illustrated in Figure 6, there can be interference when LoRa carriers are located between Interrogator
signals. This situation can be due to power leakage from the RFID Interrogator into LoRa channels. In addition,
the strong signal will also impact the AGC mechanism in the LoRa-based receiver. The Type A Reference
Interval (Tari) in Figure 6 is 25 us in a dense Interrogator environment.
 Figure 6: RFID Interrogator channel mask
Nonlinear Impairments (IM3, IM5)
The third- and fifth-order intermodulation products, due to nonlinearity of the front-end, could also cause an
issue. As depicted in Figure 7, the potential impact is considerable, given a large number of co-located
interfering sources and the ERP of the interfering signal.

Figure 7: Co-Channel impairments of LoRa due to Interrogator IM3/IM5

 
The Impact of LoRaWAN on RFID
Given the relatively-low emitting power of LoRa-based end-devices and gateways, and the high density of
RFID Interrogators, the impact of LoRaWAN transmissions on an RFID system is negligible.
Features for Better Coexistence
LoRaWAN Features
LoRaWAN includes features designed to be adaptive and to coexist with systems that generate frequency-
selective interference, such as the UHF-RFID system.
1. LoRa modulation provides strong co-channel and adjacent-channel rejection: As noted in
the SX1262 datasheet, the co-channel rejection with a single carrier interference is 5-19 dB, depending
on the spreading factor (SF), and the adjacent-channel rejection is 60-72 dB.
2. As described in the LoRaWAN MAC protocol, an adaptive channel plan from the Adaptive Data Rate
(ADR) command is mandatory. This feature allows the network server to disable channels that are
known to have strong interference as a means of improving the overall packet transmission quality.
UHF RFID Features
1. UHF RFID Interrogators are all network-controlled and provide a configurable channel plan. Some
high-end products support changing the RFID channel plan during operation without losing data.
2. The end-node (RFID tag) is a passive device and does not store the channel plan. This means that the
tags can be adapted to any channel plan the Interrogator uses.
Blocking Performance of LoRaWAN-based System
Test Bench Information
This section presents the lab test bench for characterizing the LoRa-based receiver performance in the presence
of simulated RFID Interrogator interference, in both co-channel and adjacent-channel scenarios.
Equipment and tools:
 Vector Signal Generator – SMBV100a
 RF enclosure
  The device under test (DUT) – LoRa-based PicoCell gateway
 The device under test (DUT) – SX1272 Nucleo shield and L152RE Mbed boards.
 Programmable Attenuator – RCDAT-6000-90
 RF cables
 Gateway HOST - Raspberry Pi
Waveforms:
 Waveforms of RFID Interrogators captured in a real retail store by SDR kits were used for Interrogator
signal generation.
Figure 8 illustrates the test bench implementation: 

Figure 8: Test bench setup for lab measurements

Gateway Performance
The purpose of the uplink test is to quantify the rejection and robustness of the PicoCell gateway as the victim
receiver.
The SMBV100a simulated a single RFID Interrogator transmitter by playing back a captured and post-
processed Interrogator waveform. The waveform was extracted from the captured data in the retail stores, using
an eight-tap Butterworth filter with 50kHz bandwidth and a carrier frequency of 912.25MHz.
The LoRa uplink packet had the following parameters:
 Bandwidth: 125kHz.
 Carrier frequency: 914.5MHz
 Spreading factor: SF7, SF10
 Code Rate: 4/5
 Packet length: 16 bytes in the physical layer payload.
The baseline performance was set by measuring the 10 percent Packet Error Rate (PER) for the device under
test, without an RFID Interrogator. Next, the desired signal level was set at 6 dB, 26 dB, and 46 dB above this
nominal sensitivity threshold. The Interrogator carrier was then injected into the PicoCell gateway at various
frequency offsets. The interferer power was also changed until the LoRa PER was nominally 10 percent. The
result illustrates the power level of an RFID Interrogator incident upon the PicoCell gateway that can be
tolerated as a function of the frequency offset.
The relative rejection performance using SF7 is shown in Figure 9 below. With varying transmission power
levels of LoRa signals, the relative interference signal level was constant in the same frequency offset point. It
suggested a linear impairment depredating the SINR before analog-to-digital conversion (ADC) due to
insufficient filtering
Figure 9: Co-channel and adjacent-channel rejection performance by Pico gateway receiver in relative interferer
signal level, SF=7.
As illustrated in Figure 9, for an adjacent channel interferer at an offset of 250kHz, the PicoCell gateway could
tolerate an RFID signal that is 55-60 dB higher than the desired LoRa signal. However, when the interferer is
on the same channel, the rejection is typically reduced to 5 dB.
The PicoCell gateway receiver rejection performance was saturated when the received RF power of the
interferer was -30 dBm to -20 dBm. This was due to the increased noise floor when the signal generator
transmitted at high output power. This also applies to real-world scenarios in which the Interrogator transmits at
high power.
The SF10 result is shown in Figure 10, with the relative rejection as the metrics:
 Figure 10: Co-channel and adjacent-channel rejection performance by Pico gateway receiver in relative
interferer signal level, SF=10
End-Node Performance
The downlink receiver performance was conducted with two SX1272DVK1xAS development kits that were
configured as the downlink packet transmitter and the target receiver, respectively.
Again, the purpose of this test was to measure the end node receiver performance in the presence of a nearby
RFID Interrogator. In addition to all parameters considered in the uplink test, the receiver low-noise amplifier
(LNA) gain was fixed, to demonstrate potential performance improvement by backing off the LNA gain at the
expense of signal sensitivity.
The LoRa packets had the following parameters:
 Bandwidth: 500kHz.
 Carrier frequency: 923.3MHz
 Spreading factor: SF7, SF10
 Code Rate: 4/5
 Packet length: 16 bytes in the physical layer payload.
 Figure 11: Co-channel and adjacent-channel rejection performance by an SX1272 receiver, in an absolute
interferer signal level
The constant spacing between different LNA gains settings suggested that the RFID interference was a linear
impactor that reduced the SINR. Thus, the receiver performance was a function of the signal-to-interference
ratio (SIR) with a given frequency spacing.
The results indicated that the absolute level of blocking immunity increased as we backed-off LNA gain and
lost some sensitivity. This suggested that a zoned or micro-cell gateway deployment would mitigate the impact
of the multiple co-located interference sources.
Similar to the uplink results, adjacent channel rejection was typically 50 dB better than the co-channel rejection.
The co-channel rejection was measured at about 5 dB for SF7.
Summary
From the lab measurements, the transceivers in LoRaWAN demonstrated great robustness against interference
(>50 dB difference in rejection) when the interference and the LoRa signal did not share the same frequency. It
also showed that the absolute rejection performance can be improved at the cost of sensitivity; hence, reduced
gateway spacing is preferred in a deployment where LoRa and UH-RFID signals coexist.
Channel Plan Optimization
Based on the results from the lab measurements noted in in the Summary above, and the system features
described in Features for Better Coexistence, it is clear that an optimized channel plan could help mitigate the
impact of adjacent and co-channel interference from high-power RFID systems.
Default RFID Channel Plan
The default 500kHz RFID channel plan uses 50 channels, with a spacing of 500kHz. The first channel is
902.75MHz, and the last channel frequency is 927.25MHz.
Four LoRaWAN uplink channels are selected, hence four downlink channels are used, in accordance with the
LoRaWAN regional specification for the US902-928 region. The RFID channels and LoRaWAN
uplink/downlink channels are listed in Table 1. The normalized spacing between LoRaWAN and RFID
channels is also listed. The normalization is by LoRa channel bandwidth, which is 125kHz for uplinks and
500kHz for downlinks.
In principle, if the normalized spacing is greater than 0.5, the signal could be separated by filtering (if we do not
consider the RFID Interrogator signal bandwidth), and the interference scenario becomes adjacent interference.
Otherwise, the interference scenario is co-channel interference.
Table 1: Default RFID Channel Plan with 500kHz Spacing.
With this channel plan, LoRaWAN uplink channels 1, 3, 4, and 6 are suitable for transmission among the block
A with a minimum spacing of 1.2 times the bandwidth between the LoRaWAN channel frequency and the
RFID channel frequency. The other four channels experienced degraded performance due to co-channel
impairment or nonlinear third-order inter-modulation (IM3). For the downlink, all eight channels were blocked
by the RFID signal, and there was not enough separation from the closest RFID channel due to its larger signal
bandwidth.
This channel plan is referred to as the 500kHz Channel Plan in the Field Measurement section.
Optimized RFID Channel Plan
By shrinking the space between RFID Interrogators from 500kHz to 450kHz, and carefully selecting four
uplink channels and their corresponding downlink channels, we successfully avoided all co-channel
interference, while maintaining full compliance with the LoRaWAN specification.
Table 2: Optimized RFID channel plan with 450kHz spacing, free up four uplink and four downlink channels.
We chose 902.5MHz, 902.9MHz, 903.3MHz, and 903.7MHz for the uplink channel plan. None of these
channels overlapped with RFID channels or IM3/IM5 products.
The corresponding downlink channels were at 923.9MHz, 925.1MHz, 926.3MHz, and 927.5MHz. None of the
RFID channels overlapped with LoRaWAN downlinks. However, IM3/IM5 products may collide with
LoRaWAN downlink traffic.
The channel plan is referred to as the 450kHz Channel Plan in the Field Measurement section.
Compliance
Both channel plans should comply with the FCC regulation in North America, specifically the 47 CFR 15.247
federal regulation.
The RFID Interrogator runs in Frequency Hopping Spread Spectrum (FHSS) mode. The RFID Interrogator has
passed FCC certifications with both channel plans.
The LoRaWAN gateway runs in digital transmission system (DTS) mode, and the LoRaWAN sensor runs in
hybrid mode. Both gateway and sensor reference designs have passed FCC pre-certification tests. The channel
plan proposed in this section complies with the LoRaWAN regional parameters for the US902-908 region.
Field Measurement
The purpose of this field measurement was to measure the LoRaWAN system performance in typical retail
stores with a dense UHF-RFID Interrogator deployment.
Test Site Information
Test Site Description
Two large retail stores were selected to test the LoRaWAN performance. Both stores had a similar dense RFID
system deployment.
Store-1
One large retail store was selected to perform the baseline test discussed in the Baseline Measurement and
Result section of this document. The store size was about 410 feet by 330 feet, including both the open store
floor and back stock areas.
For better efficiency and accuracy of RFID inventorying, there was additional RF insulation installed along the
wall separating back stock and open floor areas. Additionally, some internal walls are concrete. This caused
higher attenuation than is typical in drywall structures.
Store-2
Another retail store was tested with LoRaWAN deployment. More details can be found in the Evaluation with
Optimized Channel Plan section. The size of the store was about 520 feet by 380 feet. An RFID system similar
to that in use in Store 1 was deployed and running.
Device Location
LoRaWAN Gateway/Device
The potential locations of LoRa-based sensors included places such as cold storage in the refrigerators of the
grocery section and (separate) liquor store, sensors/detectors in the server room, mouse traps in non-public
areas, and motion detectors near the fitting rooms and liquor store.
In the long-term, this LoRaWAN network could also support LoRa Edge™[8] based long-range inventory and
geolocation functionality.
Five gateways were deployed near the in-store Ethernet switches in the back stock area and in the fitting room
area, typically at a height of 12 to 15 feet. The detailed locations are mapped in Error! Reference source not
found. below.
RFID Devices
The RFID Interrogators were mounted on the ceiling, with 25-ft to 40-ft spacing horizontally, covering the
whole shop floor. In the back stock area, they were also ceiling-mounted. Each one covered one stock aisle.
Hardware Configuration
The following LoRa-based hardware was used in the field measurement.
1. End nodes: SX1272 mbed shields and mbed boards, with 14 dBm output power.
2. End nodes: SX1276 mbed shields and mbed boards, with 20 dBm output power.
3. LoRa Pico Gateway.
Baseline Measurement and Result
The baseline measurement was conducted in Store-1, as described in the Test Site Description.
For this part of our investigation, we evaluated the performance degradation caused by the RFID system.

Figure 12: Map and sensor location of Store-1

A total of nine sensor nodes were deployed for the test, as illustrated by the orange boxes in Figure 12 Both
uplinks and downlinks were tested.
Uplink Measurement
All 8 channels (channel 0-7) were enabled in this test.
We first turned off the RFID system and measured the uplink packet success rate (PSR/ FSR). Only a single
gateway (GW-1) was enabled. All end-nodes generated uplink frames using circulated spreading factors
between SF7 and SF10.
Table 3: Packet success rate in uplink with RFID system off

 
The PSR performance was good; however, some nodes were separated by RF insulation. All nodes achieved
beyond 80 percent PSR, with a single gateway placed on a table in the corner of the store.
Note: All measurements were based on circulating spreading factors. If ADR were enabled, we would expect to
see further improvement in performance.
The PSR with different spreading factors is shown in Figure 13, along with a detailed analysis of the packet
received by the node at location 1. Generally, better performance is expected when using a higher spreading
factor, with the exception of SF10. (The long time-on-air for signals using SF10 increases the probability of
collisions with transmissions from other end nodes.)

Figure 13: Packet Success Rate For Location-1 Node Grouped By Spreading Factors, with RFID Off.
We then turned the RFID system on, using the 500kHz (default) channel plan, expecting a large degradation
due to the strong interference. To address this interference issue, we deployed multiple LoRa-based gateways to
provide redundancy and diversity.
A multi-gateway scenario was evaluated with 5 PicoCell gateway locations in the stock area, loading bay, cold
chain area, employee break room, and the clothing floor. The result is shown in Table 4.
Table 4: PSR with Single/Multiple Gateways in the Uplink, with Default 500kHz RFID
While relying on a single gateway did not provide good performance, (for example, using only GW-1 can lead
to 0% PSR for node location 1), the redundancy provided by deploying additional gateways, allowed the overall
PSR to be maintained beyond 80 percent.
We analyzed one typical end node result in detail: location-8 with 79 percent PSR measured with GW-1. The
result, grouped by spreading factors, is shown in Figure 14. With an increased noise floor, the transmission
became an SINR-sensitive system that provided a better success rate with higher spreading factors.

Figure 14: Packet success rate of location-8 node grouped by spreading factors in the uplink, with 500kHz
RFID.
Downlink Measurements
A similar performance was expected in the downlink when the RFID was off, namely, that a single gateway
could cover the whole store.
For this, we tested the downlink performance with the RFID system turned on. Performance with two channels
were measured: 927.5MHz and 924.5MHz, with the RFID system on and running with default 500kHz spacing.
The 924.5MHz downlink channel was impaired by two adjacent RFID channels at 924.25MHz and
924.75MHz. SF7 was used in the results shown in Table 5.
Table 5: PSR with a single gateway in the downlink, with the 500kHz RFID plan.
We investigated the performance of the different spreading factors for the location-7 node, with the 924.5MHz
channel, as illustrated in Figure 15.

Figure 15: Packet success rate of location-7 node grouped by spreading factors in the downlink, with 500kHz
RFID.
As we can see, increasing the spreading factor improved the robustness to noise/interference, which effectively
improved the success rate from 32 percent using SF7 to more than 75 percent when using SF 10/11. However,
it is significant to note that SF12 performance as degraded. This is primarily due to the long time-on-air, which
increased collisions among LoRaWAN signals and RFID transmissions.
Evaluation with Optimized Channel Plan
The purpose of this test was to measure the performance of a LoRaWAN network in a retail store with a dense
RFID Interrogator deployment.
A Semtech evaluation network server[9] was selected as the LoRaWAN network server (LNS) in this
measurement.
This LoRaWAN measurement was generated in the larger retail store, as described in Test Site
Description above. Four channels were used in this test: when testing with 500kHz RFID channel plan, we used
channels 1, 3, 4, and 6; when testing with 450kHz RFID channel plan, we used channel 1, 3, 5, 7.
As illustrated in Figure 16, four gateways were mounted in the store: the bottom right gateway (GW-1) was
mounted about seven feet high. The other three gateways were mounted higher than the RFID Interrogators, so
that the interference from the RFID Interrogators could be minimized. The back stock area was located in the
upper section, while the bottom section was the employee area.
On the map, we marked the node locations by the first four characters of their device EUIs.
 Figure 16: Map and sensor/gateway location of Store-2
Some nodes need special attention:
1. CC5E simulated a mouse trap close to an exit in the hallway. It was far from any gateways.
2. D135 sat in a walk-in refrigerator with a thick door that was covered by a metal structure.
3. D924 was placed in a freezer at a low temperature.
In the following result sections, each PSR/FSR value was generated by collecting the data in a four-hour
window. More than 2,000 packets were measured.
Uplink Measurement
When measuring the uplink PSR, two RFID channel plans were implemented and compared, as described
in Channel Plan Optimization.
Table 6: PSR in uplink using LoRaWAN.
The 450kHz plan provided significantly better performance, improving the average PSR from 92 percent to
about 97 percent.
We also measured the confirmed uplink with limited retransmissions. The maximum number of retransmission
attempts is seven. Therefore, if either the uplink packet failed or the downlink acknowledgment failed for any
given frame, no more than eight transmission attempts could be made
Table 7: PSR in uplink using LoRaWAN and confirmed uplink/retransmission.

Most of the nodes were error-free; only the back stock mousetrap and the one in the freezer experienced some
frame loss with the 500k channel plan. We saw no frame loss with the optimized channel plan and confirmed
uplink.
Downlink Measurement
The downlink performance is shown in Table 8. The average PSR was 60 percent for the default channel plan.
This improved to 81 percent for the 450kHz optimized channel plan.
Table 8: PSR in downlink using LoRaWAN.
Result Summary
Using a practical gateway installation and four gateways in a retail store, we achieved greater than 95 percent
FSR with respect to uplinks, and more than 80 percent FSR with respect to downlinks, as shown in Table 9.
Table 9: Summary of average FSR among multiple end-nodes

For mission-critical applications, it became clear that the 450kHz channel plan can provide very high service
quality without significant frame losses.
LoRaWAN-based applications are generally focused on transmitting uplinks. Downlinks are predominantly
used for provisioning and network control, with feedback enabled. Typically, failed downlink transmissions can
be observed by the network (for example, a failed join accept message, or a failed ADR command) and
downlink retransmissions can be easily scheduled.
The LoRaWAN network can operate normally with the transmission quality presented in Table 9.
Interestingly, there was no performance degradation from the RFID system when the channel spacing was
moved from 500kHz to 450kHz when it coexisted with the LoRaWAN network.
Conclusion
In this paper, we have investigated the coexistence of co-located LoRaWAN network and UHF-RFID systems.
Based on the datasheet and lab measurements presented in the section on Blocking Performance of LoRaWAN-
based System we have proposed an optimized channel plan for both LoRaWAN and RFID systems, as
described in the section on Channel Plan Optimization. Furthermore, we were able to demonstrate that
LoRaWAN and high-power RFID systems can coexist with a good performance. The LoRaWAN success rate
exceeded 96 percent for uplinks and 80 percent for downlinks, without any observed impact on the RFID
system.
For applications in locations such as a large retail store, warehouse or airport, RFID and LoRaWAN are better
suited for different applications. For example, RFID is well-suited for choke-point data capture, for instance,
scanning a truck at a loading bay. For its part, LoRaWAN is great for ubiquitous coverage, both indoors and
outdoors, to track and find an item in a yard or in a warehouse. In addition, LoRaWAN can support other sensor
and monitoring applications. This investigation/demonstration illustrates that both system can work in the same
location and frequency band, to better serve user needs. 
 
 
[1] AN1200.22 “LoRa Modulation Basics”, available at https://www.semtech.com/products/wireless-rf/lora-
transceivers/sx1272
[2] AN1200.26 “LoRa™ and FCC Part 15.247: Measurement Guidance”, available
at: https://www.semtech.com/products/wireless-rf/lora-transceivers/sx1272
[3] “EPC Radio-Frequency Identity Protocols Generation-2 UHF RFID”,
https://www.gs1.org/sites/default/files/.../epc/uhfc1g2_2_0_0_standard_20131101.pdf
[4] “LoRaWAN Specification v1.1”, available at: https://lora-alliance.org/resource-hub
[5] “LoRaWAN® Regional Parameters RP002-1.0.0”, available at: https://lora-alliance.org/resource-hub
[6] “Operation within the bands 902MHz – 928MHz, 2400MHz – 2483.5MHz, and 5725MHz – 5850MHz”,
https://www.gpo.gov/fdsys/pkg/CFR-2013-title47-vol1/pdf/CFR-2013-title47-vol1-sec15-247.pdf
[7]“SX1261/SX1262 Datasheet”, available at: https://www.semtech.com/products/wireless-rf/lora-
transceivers/sx1261
[8] https://www.semtech.com/products/wireless-rf/lora-transceivers/lr1110
[9] https://na.iot.semtech.cloud/