PaperlayerView exact revision on arXiv

Source-linked AI summary

LoRaWAN in the Wild: Measurements from The Things Network

Norbert Blenn, Fernando Kuipers

arXiv:1706.03086v1cs.NI

TL;DR

Evidence on operational LoRaWAN deployments was limited as the technology’s adoption grew. The paper measures The Things Network and uses empirical findings in a simulator; it reports practical usage patterns and packet-loss estimates, alongside deployment guidance.

  • Problem

    LoRaWAN adoption was growing, while the paper identifies a need to measure and analyze an operational network across its deployment stages.

    Source: §I · p. 1

  • Method

    The authors analyze eight months of packets from The Things Network and use an empirically grounded simulator to estimate packet loss.

    Source: §I · p. 1, §VIII · p. 8

  • Results

    The measurements show that channel use is uneven, which the authors report leads to increased packet loss.

    Source: §VIII · p. 8

  • Takeaways & Limitations

    The authors recommend balancing gateway reach with low spreading factors and using ADR for stationary nodes, but not mobile nodes because retries can increase airtime.

    Source: §VIII · pp. 8–9

Abstract

from arXiv · show

The Long-Range Wide-Area Network (LoRaWAN) specification was released in 2015, primarily to support the Internet-of-Things by facilitating wireless communication over long distances. Since 2015, the role-out and adoption of LoRaWAN has seen a steep growth. To the best of our knowledge, we are the first to have extensively measured, analyzed, and modeled the performance, features, and use cases of an operational LoRaWAN, namely The Things Network. Our measurement data, as presented in this paper, cover the early stages up to the production-level deployment of LoRaWAN. In particular, we analyze packet payloads, radio-signal quality, and spatio-temporal aspects, to model and estimate the performance of LoRaWAN. We also use our empirical findings in simulations to estimate the packet-loss.

I. INTRODUCTION

LoRaWAN is an LPWAN protocol developed for IoT applications as adoption grew rapidly. The paper introduces LoRa’s long-range radio approach and LoRaWAN’s network protocol, then outlines its measurements and analyses.

I. INTRODUCTION

  • LoRaWAN was developed for IoT applications,,, and the paper examines its growing adoption and deployment.The paper outlines measurements, regulation, distance estimation, and simulation of packet loss in The Things Network.Source: §I · p. 1

A. LoRa

  • LoRa uses chirp spread-spectrum modulation; increasing bandwidth can support error-free transmission at fixed SNR over longer distances.Chirp modulation is described as robust to multipath interference, fading, and Doppler shifts.Source: A. LoRa · p. 1

B. The LoRaWAN protocol

  • LoRaWAN was designed over LoRa as a network protocol, with mobility and MAC-level security among the considerations described for its design.The paper presents three bidirectional classes: Class A opens two receive windows after uplinks, Class B adds beacon reception, and Class C receives continuously except while transmitting.Source: B. The LoRaWAN protocol · pp. 1–2

C. Connecting Devices to a LoRaWAN Network

A typical LoRaWAN class A network forwards device packets through gateways and network servers to an application. Devices can join through OTAA, which supplies session parameters and keys after a validated request.

C. Connecting Devices to a LoRaWAN Network

1) Over the Air Activation (OTAA):

  • OTAA devices send a MIC-signed join request using their DevEUI, AppEUI, and DevNonce, authenticated with an AppKey.A validating server may respond with session keys, a device address, RF delays, and channels to use.Source: 1) Over the Air Activation (OTAA) · p. 2

2) Activation by Personalization (ABP):

ABP lets devices send packets using provisioned network and application session keys, while generic devices use globally known default keys. LoRaWAN encrypts application payloads and authenticates frames, but key handling and generic-key conventions affect security.

2) Activation by Personalization (ABP):

3) Default Activation for Generic Devices:

  • Generic devices use globally known default keys and may send unencrypted packets, leaving transmission metadata publicly visible.When AppSKey equals NwkSKey by convention, everyone can decode the data.Source: 3) Default Activation for Generic… · p. 2
  • Support for generic keys may change because server-side routing can make it unclear whether packets belong on a public interface or a registered user’s application.Source: 3) Default Activation for Generic… · p. 2

D. Data Encryption

  • LoRaWAN encrypts the application payload with AppSKey and signs the full packet with NwkSKey; only the AppSKey owner can decrypt the payload.Keys must be stored at the network server and node, and compromise of a node’s keys can enable interception or malicious traffic; distinct device keys limit cross-device compromise.Source: D. Data Encryption · pp. 2–3

A. Data Collection

The measurements cover class A LoRaWAN traffic on The Things Network, with gateway reception patterns and device use varying substantially. Reported RSSI and SNR values suggest most received data came from devices close to gateways.

A. Data Collection

  • The study focuses on class A networks because the authors report that all large-scale LoRaWANs then deployed operated in class A.Source: A. Data Collection · p. 3
  • The dataset captures gateway-received frames from December 2015 to July 2016, plus 23.5 million gateway status updates collected from May to July 2016.The frames were sent using ABP with a generic network session key.Source: A. Data Collection · p. 3
  • 94.8% of unique frames reached one gateway, 3.7% reached two, and 1.1% reached three; one frame reached 31 gateways from 1.4 km altitude.Frames can be received by multiple gateways, so received-frame totals exceed unique-frame totals.Source: A. Data Collection · p. 3
  • Device packet counts approached a power law: few devices sent more than 1,000 packets, while many sent fewer than 50.Fig. 2 plots the number of devices against the number of packets sent.Source: A. Data Collection · p. 3, Figure 2 · p. 3

B. Signal quality

  • Small RSSI values and positive SNR values suggest that most received data came from devices close to gateways.The distributions cover all frames in the dataset.Source: B. Signal quality · p. 3, Figure 3 · p. 3

C. Payload analysis

The payload analysis finds that captured frames were generally small, while their contents included human-readable strings and undeciphered payloads. The spreading-factor analysis finds SF7 125 kHz was most used and examines how spreading factor and transmit power relate to packet loss in single-location tests.

C. Payload analysis

  • 93.7% of payloads were smaller than 50 bytes, 50% were smaller than 19 bytes, and the average size was 18 bytes.Source: C. Payload analysis · p. 3, Figure 5 · p. 4
  • The remaining 16.1 million frames included 10,104,330 human-readable strings and roughly 6 million payloads the authors could not decipher.Table II classifies the human-readable strings.Source: C. Payload analysis · pp. 3–4, Table II · p. 4
  • Table II provides an indication of device use on The Things Network during the measurement period.Multiple sensor measurements can be combined in a frame, so Table II counts sum to more than 10.1 million.Source: C. Payload analysis · p. 4

D. Spreading Factor

  • Most devices used SF7 125 kHz, the default setting for devices using IBM's open-source LoRa implementation and devices manufactured by Microchip.Spreading factors range from SF7 to SF12 and encode each bit using a number of chirps.Source: D. Spreading Factor · p. 4, Figure 6 · p. 4
  • In single-location tests, higher spreading factors and transmit power reduced observed packet loss; SF12 frames arrived at 2 dBm where SF7 frames did not arrive below 8 dBm.The tests used one-character payloads and 20 packets per spreading-factor and power configuration.Source: D. Spreading Factor · p. 4

IV. FREQUENCY USAGE AND REGULATION

The dataset’s frequency usage suggests most devices were in Europe and the USA, with European traffic concentrated on the three compulsory channels. The section relates observed usage to regional LoRaWAN rules and frame-airtime calculations.

IV. FREQUENCY USAGE AND REGULATION

  • 89.4% of packets were sent in the 868 MHz band, 10.5% in 902–928 MHz, and 0.1% in the 433 MHz band, suggesting most devices were in Europe and the USA.The specification assigns the 863–870 MHz and 433 MHz bands to Europe, and 902–928 MHz to the USA.Source: §IV · pp. 4–5
  • The three compulsory European frequencies—868.1, 868.3, and 868.5 MHz—were the most used; operators also support five additional frequencies in the 863–870 MHz band.For Europe, the specification sets three 125 kHz channels, data-rates DR0–DR5, a duty-cycle below 1%, and default radiated transmit power of 14 dBm.Source: §IV · p. 5
  • Frame airtime is calculated from symbol duration, payload-symbol count, and the LoRaWAN preamble size of eight symbols.The section cites Eq. (5) for frame airtime; coding rate relates to forward error correction, with higher values implying better reconstruction of noisy signals.Source: §IV · p. 5

A. Limits

The section estimates specification-based transmission limits from frame airtime and payload size. Its daily-capacity estimates assume unconfirmed frames and no OTAA activation; retransmissions can reduce capacity.

A. Limits

  • Under specification-compliant assumptions, airtime per frame increases linearly with payload size; maximum payloads are 230 bytes for SF7 and SF8, 123 bytes for SF9, and 59 bytes for SF10–12.Figures 10 and 11 show how different airtime values affect the maximum number of frames a node may transmit per day in one channel.Source: A. Limits · p. 5
  • Daily transmission estimates assume unconfirmed frames and no OTAA activation; if a confirmation is not received, configured retransmissions reduce the frames and data sendable per day.The corresponding frame-count visual is Fig. 10.Source: A. Limits · pp. 5–6, Figure 10 · p. 6

V. DISTANCE ESTIMATION

The paper estimates node-to-gateway distance from received signal level and compares estimates with distances derived from GPS locations. Most estimates are close to measured distances, but urban structures can make estimates too large.

V. DISTANCE ESTIMATION

  • 320,391 captured frames contained GPS coordinates, enabling comparison of estimated gateway distances with distances from known node and gateway locations.The GPS coordinates came from LoRaMotes or individuals sending latitude-longitude tuples.Source: §V · p. 6
  • In the absence of a specific LoRa path-loss equation, the paper uses a free-space path-loss approximation to estimate distance from received signal level and frequency.The equation’s variables are frequency in MHz, received signal level in dB, and expected distance in meters.Source: §V · p. 6
  • Most estimated distances matched measurements, and hardly any difference exceeded 100 m; in urban environments, estimates can exceed measured distances because buildings or other structures dampen the signal.Fig. 12 is a histogram of measured-minus-estimated distance differences.Source: §V · pp. 6–7, Figure 12 · p. 6

VI. SIMULATIONS

The paper uses empirical observations to simulate packet collisions and examine practical LoRaWAN limitations. Same-time transmissions with the same spreading factor and channel collide, while simulated collision counts rise with packet rate.

VI. SIMULATIONS

  • The simulator is intended to explore practical LoRaWAN limitations using observations from the paper’s empirical data.The simulation considers packet loss apart from losses caused by being too far from a receiving gateway.Source: §VI · p. 7, A. Packet loss · p. 7

A. Packet loss

  • Packets using the same spreading factor and channel at the same time collide, causing packet loss; unlike a plain-LoRa experiment, these tests did not recover the stronger signal.Both devices sent 120 packets per configuration; the tested LoRaWAN gateway checks frame integrity and does not forward corrupted data.Source: A. Packet loss · p. 7
  • The simulator estimates single-gateway collisions for n one-byte packets, assigning each packet a uniformly random spreading factor from 7–12 and one of the three EU channels.A collision is counted when a frame arrives within the same interval, spreading factor, and channel as another frame; airtime is calculated using Eq. (5).Source: A. Packet loss · p. 7
  • A high number of collisions is expected as packet rate increases; the simulation’s collision-rate figure varies spreading factor for n packets sent within one minute on one of three EU base channels.Fig. 13 presents the collision-rate comparison.Source: A. Packet loss · p. 7, Figure 13 · p. 7
  • The paper states that collisions can be mitigated by using lower spreading factors or reducing transmission power to reach only one gateway.The proposed power reduction is to a value sufficient to reach only one gateway.Source: A. Packet loss · p. 7

B. Confirmed and Down-link Frames

The simulations show that confirmations increase packet loss and can push gateways over duty-cycle limits; the authors therefore recommend minimizing confirmations and down-links. The paper also discusses single-channel gateways as a possible low-cost response to high packet loss and situates its measurements against prior single-base-station studies.

B. Confirmed and Down-link Frames

  • The simulation assumes 1% of packets request confirmation and models confirmations as 13-byte ACK messages that occupy a half-duplex gateway.The observed received-to-sent packet ratio is 0.01095 and informs the 1% assumption.Source: B. Confirmed and Down-link Frames · p. 7
  • Packet loss increases with the share of confirmed packets; losses for SF11 and SF12 exceed the plotted lines, while SF7–SF9 fall slightly below them.SF10 tracks the average; the figure describes expected collisions across all spreading factors, including non-received frames, due to gateway acknowledgments.Source: B. Confirmed and Down-link Frames · pp. 7–8, Figure 14 · p. 7
  • Because simulations omit retransmissions and other band interference, the authors recommend minimizing confirmed packets and down-links.Those omitted effects would aggravate the situation.Source: B. Confirmed and Down-link Frames · p. 8
  • At 1% confirmed packets, gateway duty-cycle violations begin at 200 packets per minute; above 2%, violations occur in every tested case.At 0.5% confirmed frames and 700 packets per minute, estimated confirmation airtime is 1.28%.Source: B. Confirmed and Down-link Frames · p. 8
  • Single-channel gateways may offer a cheap way to mitigate high packet loss, but their inability to transmit limits device configuration and means operators should not schedule down-links through them.The dataset suggests 97 of 691 gateways were likely packet forwarders; such devices require ABP and a single channel and spreading factor.Source: B. Confirmed and Down-link Frames · p. 8

VII. RELATED WORK

  • Unlike prior work confined to a single base station, this study reports measurements from The Things Network over eight months.Source: §VII · p. 8

VIII. CONCLUSION

The paper combines eight months of large-scale live-network measurements with a simulator to examine LoRaWAN use and possible obstacles under heavy gateway load. It reports practical configuration recommendations, including avoiding excessive gateway down-links and treating mobile scenarios differently from stationary ones.

VIII. CONCLUSION

  • The paper analyzes all packets sent by generic-key devices over eight months and uses a simulator to study possible obstacles under heavy gateway load.Source: §VIII · p. 8
  • Uneven channel use is associated with increased packet loss; the authors suggest default device settings may contribute, while OTAA avoids the issue described.They believe mobile nodes may remain on ABP, where users must program the channel list.Source: §VIII · p. 8
  • The authors recommend reaching a minimum number of gateways and using the lowest possible spreading factor to reduce airtime and collision-related packet-loss probability.They suggest ADR for finding optimal settings during a node’s first packets.Source: §VIII · p. 8
  • For mobile scenarios, the authors advise against ADR because repeated retries, especially in urban environments, add transmission overhead and airtime.Source: §VIII · p. 9
  • Half-duplex gateways cannot receive while transmitting or confirming, so the authors recommend reducing gateway-to-node packets; gateway-side duty-cycle enforcement remains unclear when multiple compliant nodes send confirmed frames.Source: §VIII · p. 9

Related papers

Loading 1706.03086v1…