Designing LoRaWAN Network For Dense IoT

Designing LoRaWAN Network for Dense IoT
Deployments
Authors:
Pierre DUFOUR, Rohit GUPTA, Ramez SOSS, Olivier HERSENT (Actility)
William VERSTEEG (JumpStartIoT.com)
Actility S.A. au capital de 744 810 € - 4 rue Ampère, 22300 Lannion, France
1
CONTENTS
ABSTRACT .............................................................................................................................................. 5
1 INTRODUCTION ................................................................................................................................ 6
2 LORAWAN OVERVIEW .................................................................................................................. 8
2.1 Architecture ......................................................................................................................... 8
2.2 LoRaWAN Device Classes ............................................................................................... 9
2.3 LoRaWAN Deployment Model ....................................................................................... 11
3 LORAWAN MAC LAYER ............................................................................................................. 13
3.1 Regulatory Constraints ................................................................................................... 13
3.2 Transmission Parameters .............................................................................................. 15
3.3 LoRaWAN packet structure ........................................................................................... 16
3.4 Airtime ................................................................................................................................. 18
4 THEORETICAL CALCULATIONS ..................................................................................................... 19
4.1 Gateway sensitivity .......................................................................................................... 19
4.2 Link budget and propagation model ........................................................................... 21
5 SIMULATION ASSUMPTIONS ......................................................................................................... 23
5.1 Packet error rate (PER) ................................................................................................... 23
5.2 Fading simulation ............................................................................................................. 23
5.3 Collision behavior ............................................................................................................ 25
5.3.1 Spreading factor collision .......................................................................................... 26
5.3.2 Frequency collision ..................................................................................................... 26
5.3.3 Time collision ............................................................................................................... 27
5.4 ADR (Adaptive Data Rate) .............................................................................................. 27
5.5 Deployment Assumptions .............................................................................................. 28
6 RESULTS ....................................................................................................................................... 31
6.1 Isolated Cell Deployment ............................................................................................... 31
6.2 Multi-Cell Deployment ..................................................................................................... 32
6.3 Retransmissions ............................................................................................................... 34
6.4 Power consumption ......................................................................................................... 34
6.5 Why does LoRaWAN exhibit capacity beyond Aloha?........................................... 36
7 OPERATOR USE CASES ................................................................................................................ 37
7.1 Traditional vs Opportunistic network designs [30] [31] ......................................... 37
7.2 Example use-case with water meters [30] [31] ......................................................... 37
7.3 Conclusion ......................................................................................................................... 38
8 SUMMARY...................................................................................................................................... 39
2
9 ABOUT ACTILITY ........................................................................................................................ 41
10 REFERENCES ................................................................................................................................ 43
11 ABOUT AUTHORS ......................................................................................................................... 46
3
ILLUSTRATIONS TABLE
Figure 1. LoRaWAN Overview (source: Actility) .............................................................................. 8

Figure 2. LoRaWAN Architecture (source: LoRa Alliance) ............................................................ 9
Figure 3. LoRaWAN Device classes (source: LoRa Alliance) ..................................................... 10
Figure 4. LoRaWAN Hybrid Deployment Model (source : Actility) .............................................. 12
Figure 5. Typical channel line-up for EU 863-870 MHz bands for SRD (source: Actility) ....... 14
Figure 6. LoRaWAN packet structure (source [6]) ........................................................................ 16
Figure 7. LoRaWAN packet structure (source: [14]) ..................................................................... 17
Figure 8. Typical values of airtime for a 20 bytes payload and different SF ............................. 17
Figure 9. SNR versus SF, SF6 is not used in LoRaWAN (source: [19]) .................................... 19
Figure 10. SX1301 Sensitivity Figures (source: Semtech)........................................................... 20
Figure 11. Hata-Okumura model parameters (source: Actiltiy) ................................................... 22
Figure 12. ISD calculation following the cell pattern (source: Actility) ........................................ 22
Figure 13. Fast-fading effect: attenuation on vertical axis vs time. The mean is 0. ................. 24
Figure 14. Rayleigh distribution CDF curve vs dB margin (source: Actility) .............................. 25
Figure 15. SF distribution inside a typical LoRaWAN cell ............................................................ 28
Figure 16. Device distribution in a simulated cell. One color per SF .......................................... 28
Figure 17. Simulated network layout with hexagonal tiling .......................................................... 30
Figure 18. Fixed SF Vs ADR comparison (single cell, 1 TX) ....................................................... 31
Figure 19. Impact of multi-cell deployment on Capacity ............................................................... 32
Figure 20. Evolution of capacity when ISD is becomes short (number of messages, per
millions, vs ISD) .................................................................................................................................. 33
Figure 21. Impact of retransmissions on Capacity ........................................................................ 34
Figure 22. Worst case battery life of cell-edge users (48 uplinks/day, No downlink) ............... 35
Figure 23. Future of LoRaWAN deployments ................................................................................ 40
Figure 24. ThingPark Product Portfolio ........................................................................................... 41
4
ABSTRACT
LoRaWAN has recently emerged as one of the key radio technologies to address the challenges of Low
Power Wide Area Network (LPWAN) deployments, namely power efficiency, long range, scalable
deployments and cost effectiveness. LoRaWAN architecture is like cellular system in which devices
communicate directly with a central node. LoRaWAN provides different communication options
(center frequency, spreading factor, bandwidth and coding rates) to facilitate simultaneous
transmissions.
In this paper, we develop an uplink multi-cell model for LoRaWAN capacity and then validate it with
system simulations. These studies are based on inputs from real-world Actility world-wide
deployments of LoRaWAN with leading Tier-1 carriers such as Comcast, Enforta, KPN, NTT, Orange,
Proximus, SoftBank or Swisscom, or large cities such as the city of Shanghai (with partners such as
FoxConn group and OPG).
We show in this paper how quasi-orthogonal spreading factors, macro diversity, power control,
retransmissions and Adaptive Data Rate (ADR) techniques are the key to scale LoRaWAN dense multi-
cell deployments and to ensure consistent QoS (Quality of Service) in presence of increasing traffic as
usage of LoRaWAN and ISM band networks in general grows.
We highlight the fact that LoRaWAN capacity scales very gracefully with densification of gateways, but
the key to achieving this capacity lies in the network server algorithms that are proprietary and not
part of the LoRaWAN standard.
We also show how the simplicity of LoRaWAN leads to ultra-low power consumption and ease of
deployment for end nodes. However, this simplicity of protocol needs to be compensated by advanced
algorithms for network management in the network server to meet the needs of the IoT deployments.
Finally, we conclude the paper with the case study for operator use cases and show how densification
leads to dramatic reduction in TCO for both operator and enterprises.
5
1 INTRODUCTION
There has been massive growth in the Internet of Things (IoT) deployments in the last few years with
a wide variety of applications ranging from smart city, industrial IoT, intelligent transportation systems
to smart agriculture and smart utilities. The list of IoT use cases is long with complex requirements that
vary depending on the needs of each vertical. A significant number of these use cases rely on Low-
Power Wide-Area Network (LPWAN).
LPWAN refers to the group of technologies which use very low data rate, are long-range and promise
ultra-low power consumption for battery operated end-devices which can last more than a decade.
There are several LPWAN technologies such as LoRa™ used by LoRaWAN [5], UNB (Ultra Narrow Band,
e.g. Sigfox) [1], RPMA [2], Weightless [3] in unlicensed spectrum. 3GPP also has own flavors of LPWAN
technologies standardized in Rel13 namely NB-IoT [4] and LTE-M [4] .
LPWAN networks are typically deployed in a star topology like cellular deployments. The different end-
devices communicate with only a few gateways and the capacity and scaling of such deployments has
always been a point of investigation both within the academia and the industry. The capacity of LPWAN
network is very critical to meet the business objectives set forth by the needs of different IoT verticals.
Typically, IoT networks are deployed using battery-powered end-devices with life span requirement of
more than 10 years. These devices are mostly static. This poses the challenging problem of providing
coverage “almost everywhere” and guarantee long-term stability and reliability of the network at the
same time without altering/moving the device.
The number of IoT devices are projected to increase by 10x -100x the number of human-centric devices
(for example cell-phones). Hence the IoT deployments need to be as streamlined as possible. This
requires automated deployment, provisioning, network management and firmware updates that are
managed autonomously by the network management tools in order to minimize human intervention.
Any requirement of human intervention during the device lifetime is prohibitive considering the large
number and location of these devices and it would also kill the ROI and business opportunity that IoT
seems to promise.
In this paper, we focus on LoRaWAN capacity and power consumption of devices as the network
densifies and discuss techniques for scaling LoRaWAN deployment. LoRaWAN (standardized by the
LoRa Alliance [5]) is one of the most successful IoT radio technologies with more than 500+ members
in 2018. Its ecosystem is still growing exponentially due to its simplicity, low cost and unlicensed
network deployment that allows almost anyone to build and operate a LoRaWAN network.
However, as the network grows and becomes dense, LoRaWAN poses complex challenges in terms of
network capacity. There have been several works [6], [7], [8] that have shown initial results on
LoRaWAN capacity even with some experimental deployments. We extend this work based on real-
world network deployments and studies carried out by Actility using ThingPark Wireless Platform [9].
We also give insight into how LoRaWAN based deployment needs to be carried out initially and
guidelines on how to scale the networks. We also provide quantitative hindsight on the behavior of a
LoRaWAN network as network usage scales and the network is densified.
We have extended LoRaSim [10] with our assumptions and studies conducted from field deployments
and showed the theoretical potential of LoRaWAN. LoRaWAN standard provides a wide range of
communication choices (carrier frequency, spreading factor, bandwidth and coding rate) for
transmitters. Many of these settings are orthogonal, but not all. Like any communication standard,
6
LoRaWAN does have capacity limits, which are significantly influenced by the optimization of the trade-
offs in the protocol configuration.
This paper shows how LoRaWAN can scale as we densify LoRaWAN Gateway deployments. However,
these large capacity gains can only come if several key metrics are addressed successfully:
1. Careful network planning (including an efficient degree of gateway macro-diversity)

2. Adaptive Data Rate (ADR) algorithm and packet repetition leverage
3. Number of available channels
The overview of the paper is as follows. Section 2 provides an overview, section 3 describes details on
LoRaWAN MAC layer, section 4 describes the theoretical calculations involved in estimating a
LoRaWAN network capacity and section 5 gives the simulations assumptions and how they were
conducted.
Section 6 describes the results from time-based simulator, LoRaSim [10] based on our own adaptations
to match real-life deployments. We show in that section specifically how LoRaWAN performs better
than Aloha based networks due to its strong immunity to interference, orthogonal spreading factors,
Adaptive Data Rate Algorithms (ADR), and macro-diversity. As a result, the capacity of the network
scales dramatically as network is densified.
We also show in section 7 how operators and enterprises can benefit from densification with reduced
TCO. Finally, we conclude this paper in section 8 with the outlook and industry trends we foresee for
LoRaWAN deployments.
7
2 LORAWAN OVERVIEW
The LoRaWAN specification is a Low Power, Wide Area (LPWA) networking protocol developed by LoRa
Alliance. LoRaWAN uses proprietary LoRa™ (“Long Range”) physical layer developed by Semtech which
is based on a Chirp Spread Spectrum (CSS) modulation with integrated Forward Error Correction (FEC).
LoRa™ key properties are: long range, high robustness, multi-path resistance, doppler resistance and
low power.
LoRaWAN networks are generally deployed in unlicensed spectrum, eg. EU: 863-870 MHz and 433-434
MHz, USA and Australia: 902-928 MHz and 433 MHz, Asia: 920-925 MHz with a few differences in some
countries. The details of the supported bands are listed in [11].
However, there has also been some interest from operators to use this technology for licensed bands.
Figure 1. LoRaWAN Overview (source: Actility)
2.1 Architecture
LoRaWAN deployments use a star topology with frequency reuse factor of 1 which allows simplicity in
network deployment and ongoing densification: there is no need for frequency pattern planning or
reshuffling as more gateways are added to the infrastructure.
Compared to mesh technologies, the single hop to network infrastructure minimizes power
consumption as nodes do not need to relay communication from other nodes. Another advantage is
that gradual initial network deployment in sparse mode with low node density is possible, compared
to mesh which requires minimum node density to operate. Even more importantly, LoRaWAN is
immune from the exponential packet loss suffered by multi-hop RF mesh technologies in presence of
increasing interferers and noise floor power.
8
Another unique feature of LoRaWAN networks is that messages in uplink can be received by any
gateway (Rx macro-diversity), and it is the function of network server to remove duplicates in uplink
and select the best gateway for downlink transmission based on the uplink RSSI estimates. This allows
enabling of features such as geolocation to be easily built into LoRaWAN deployment and enables
uplink macro-diversity that significantly improves network capacity and QoS (Quality of Service).
LoRaWAN also supports features such as Adaptive Data Rate (ADR) that allows network server to
dynamically change parameters of end-devices such as transmit power, frequency and spreading
factor via downlink MAC commands. Optimization of theses settings is key to increase the capacity and
reduce the power consumption of end-devices.
LoRaWAN uses industry grade encryption AES 128 and exhibits two levels of cryptographic protection.
Network Server Key (NwkSKey) is used for integrity protection of messages between network server
and end-device, whereas Application Session Key (AppSKey) is used to provide end-to-end encryption
between application server and the application running on end-device.
Figure 2. LoRaWAN Architecture (source: LoRa Alliance)
2.2 LoRaWAN Device Classes
End-devices serve different applications and have different requirements. In order to optimize the
variety of end application profiles, LoRaWAN utilizes different device classes. The device classes trade
off network downlink communication latency for battery lifetime. In a control or actuator-type
application, the downlink communication latency is an important factor.
9
Figure 3. LoRaWAN Device classes (source: LoRa Alliance)
Battery Powered – Class A:
Class A devices are most power efficient and must be supported by all devices. These devices are
sleeping most of the time unless they have some uplink message to transmit. After the uplink has been
sent, the device wakes-up for a short period of time after a predetermined delay (RX1 and RX2 receive
window) to listen to potential downlink message. This mechanism is called RIT (Receiver Initiated
Transmit).
Low Latency – Class B:
Class B devices are like class A devices, but they have more opportunities to receive downlink data
from gateway resulting in reduced downlink latency. Class B devices are synchronized with periodic
beacons transmitted by the network gateways and can receive downlink data during periodic “ping
slots” which are determined by their time offset to beacon.
No Latency - Class C:
Class C devices are the least power efficient and are expected to be connected to mains supply. They
are permanently listening and gateways can send downlink messages to them at any time.
Asynchronous communication, Star topology with single

hop to infrastructure, Adaptive Data Rate and Receiver
macro-diversity optimize battery life & QoS while
achieving long-range connectivity
10
2.3 LoRaWAN Deployment Model
LoRaWAN is generally deployed in unlicensed spectrum which allows anyone to roll-out IoT/LPWAN
network based on LoRaWAN. This allows three deployment models:
1. Public Operator Network: In this traditional model, the operator invests in a regional or
nation-wide network and sells connectivity services to its customers.
2. Private/Enterprise Network: In this model, enterprise customers typically setup LoRaWAN

gateways on private premises (e.g. an airport), and either have these gateways managed by
an operator, or use their own LoRaWAN network platform.
This mode of deployment is a game changer for dense device use cases, as network capacity
and enhanced QoS can be provided at marginal increased cost. It becomes possible because
LoRaWAN runs in unlicensed spectrum and gateways are quite inexpensive and easy to
deploy.
3. Hybrid model: This is the most interesting model that LoRaWAN allows due to its open
architecture.
This is not possible or rather difficult in other competing LPWA technologies or Cellular IoT
(due to licensed spectrum and absence of roaming/peering model between private and public
networks). There are initiatives like CBRS [12] but they are still in progress and far from
maturity for large scale deployments.
In this model, operator provides light country-wide outdoor coverage, but different
stakeholders such as private enterprises or individuals help in densifying the network further
based on their needs on their premises, via managed networks. This model enables a win-win
private/public partnership in sharing the costs and revenues from the network and densify the
network where the applications and devices are most present.
This model is possible because multiple gateways can receive LoRaWAN messages and
network server removes duplication. In the cases where different operators/enterprises run
their networks, LoRa Alliance already has approved roaming architecture in “LoRaWAN
Backend Interfaces 1.0 Specification” [13] to enable network collaboration.
This model significantly reduces the operator investment and offers a disruptive business
model to build IoT capacity where it is mostly needed. In the later part of the paper, we show
how LoRaWAN capacity scales dramatically with densification of gateways with the intelligent
use of Adaptive Data Rate (ADR) algorithms.
11
Figure 4. LoRaWAN Hybrid Deployment Model (source : Actility)
LoRaWAN enables Public-Private deployment that allows

disruptive model for cost/revenue sharing and densifying
the network where it is needed most, depending on IoT
application needs
12
3 LORAWAN MAC LAYER
The LoRaWAN specification is link-layer protocol describing the different element in a LoRaWAN
network and how they interact to allow the efficient and secure transport of messages from end-device
to application servers.
The published specifications are freely available on the website of the LoRa Alliance.
The specification has been improved since its creation and the latest version number is 1.1 [14]. Most
of the devices today still used the 1.0.2 version [15].
For each version, there’s a “companion document” describing the region-specific parameters that
apply for each country or area of the world [11].
3.1 Regulatory Constraints
There are certain restrictions on access to the physical medium, imposed by the regulatory body for
the region where the network is operated.
These limitations have an impact on communication performance and hence have an impact on the
scalability of LoRaWAN deployments. Scalability is therefore often limited due to regulatory
constraints and not due to the absolute technical limitations.
We describe in more detail the EU regulation on which the simulations are based. Some regions such
as APAC (Asia-Pacific) have country specific regulations, others like Middle-Eastern countries or South
American ones have regulatory frameworks often modelled on EU or US standards respectively.
As of today, LoRaWAN is classified as a Short-Range Device (SRD) for European Regulation (CEPT see
[16]). The annex 1 of that document covers the requirements for SRD. The 863-870 MHz band usually
used is subdivided in 7 (overlapping) sub-bands. Each sub-band has specific requirements regarding
maximum Effective Radiated Power (ERP), medium access and channel spacing.
A typical network will use sub-bands “h1.3”, “h1.4” and “h1.6” which is the best trade-off in terms of
requirements / number of possible channels.
The ERP requirement is then 25mW (14 dBm) or 16 dBm EIRP. For spectrum access the duty cycle
mechanism (requirement on the total transmission duration for 1 hour) is preferred over the LBT
(“Listen Before Talk”) one. The maximum allowed Duty Cycle is 1%
This configuration allows to use 16 channels as shown in figure 5.
13
Figure 5. Typical channel line-up for EU 863-870 MHz bands for SRD (source: Actility)
14
3.2 Transmission Parameters
As summarized in [17], a typical LoRaWAN device is configured with five different parameters:
1. Carrier Frequency (CF),

2. Bandwidth (BW),
3. Transmission Power (TP),
4. Spreading Factor (SF),
5. Coding Rate (CR)
Energy consumption, transmission range and resilience to noise is determined by the selection of these
parameters.
Carrier Frequency (CF)
The minimal LoRaWAN deployment for EU in the 863-8670 MHz band has 8 channels, however
depending on the needs of the network, this can be increased up to 16 channels.
In USA, the whole band can use 64 channels and there’s a separation between uplink (UL) channels,
used by devices, and downlink (DL) channels used by the gateways. A subset of 8 or 16 channels can
be used with a restriction on the transmission power.
With more channels, a network will be able to absorb more traffic with less collisions.
Bandwidth (BW)
BW is the width of the channel used for transmission. Higher BW gives a higher data rate (thus shorter
time on air), but a lower sensitivity (because of integration of additional noise). A lower BW gives a
higher sensitivity, but a lower data rate. Very low BW (like 100 Hz, used in UBN technologies) also
requires more accurate crystals (with lower ppm value).
Data is sent out at a chip rate equal to the bandwidth. So, a bandwidth of 125 kHz corresponds to a
chip rate of 125 kcps. Although the bandwidth can be selected in a range of 7.8 kHz to 500 kHz, a typical
LoRaWAN network operates at 125 kHz.
In USA, additional channels of 500 kHz can be used every 8 channels of 125 kHz.
Transmission Power (TP)
Transmission Power on a LoRaWAN device can usually be adjusted from 2 dBm to 16 dBm EIRP by step
of 2 dB. A special mode called PA_BOOST allows to transmit up to 20 dBm.
The maximum allowed power is given by the local regulations. In Europe and most of the world, the
value is 16 dBm.
In USA, up to 30 dBm is allowed if the whole 64 channels of the ISM bands are used.
Spreading Factor (SF)
SF is the ratio between the symbol rate and chip rate. A higher spreading factor increases the Signal to
Noise Ratio (SNR), and thus sensitivity and range, but also increases airtime of the packet (and will
15
likely increase the risk of collision). The number of chips per symbol is calculated as 2SF. LoRAWAN has
six different orthogonal spreading factors from 7 to 12.
In USA, the local regulation allows a maximum airtime of 400 ms, making SF10 the slowest allowable
spreading factor.
Coding Rate (CR)
CR is the FEC rate used by the LoRa modem that offers protection against bursts of interference. It can
be set to either 4/5, 4/6, 4/7 or 4/8. A higher CR offers more protection but increases time on air.
Radios with different CR (and same CF, SF and BW), can still communicate with each other if they use
an explicit header, as the CR of the payload is stored in the header of the packet.
In LoRaWAN it is set by default at 4/5 for payload data and 4/8 for the header which is necessary to
decode the whole packet and then must be particularly protected.
3.3 LoRaWAN packet structure
The physical LoRa™ packet structure is shown in Fig. 6. A packet starts with a preamble of 8 symbols
to which the radio adds 4.25 symbols. Follows a header, which describes the length and FEC rate of
the payload and indicates the presence of a 16-bit CRC (only for UL packets). That header is always
transmitted with a 4/8 FEC rate and has its own CRC.
After the optional header, follows the payload containing LoRaWAN MAC specific commands and
applicative user payload. That payload frame could physically accept 255 bytes (length coded in 8 bits)
but the actual maximum payload length is specified by the LoRaWAN specification to comply with the
regional regulation and to keep airtime reasonably low.
Figure 6. LoRaWAN packet structure (source [6])
LoRaWAN MAC layer introduces at least 13 bytes of additional overhead as shown in Fig. 7. There’s a
first byte to give the type of LoRaWAN frame (MType in MHDR). There are 4 bytes to identify the device
(DevAddr), 1 byte to describe option (FCtrl byte), 2 bytes as a counter for the packet (FCnt) and 1 byte
to specify a logical port (Fport).
Furthermore, there’s a 4 bytes MIC (Message Integrity Code) to be able to check the integrity of the
LoRaWAN message and ensure that it has not been tampered with.
16
Radio PHY Layer: Radio PHY structure (CRC* is only available on uplink messages)
PHYPayload: PHY Payload Structure
MACPayload: MAC Payload Structure
FHDR: Frame Header Structure
Figure 7. LoRaWAN packet structure (source: [14])
Symbol Preamble UL Payload + Header Total UL

Duration (ms) Duration (ms) + CRC Duration (ms) Airtime (ms)
LoRa SF7 / 125KHz 1.02 12.54 59.39 71.94
LoRa SF8 / 125KHz 2.05 25.09 108.54 133.63
LoRa SF9 / 125KHz 4.10 50.18 196.61 246.78
LoRa SF10 / 125KHz 8.19 100.35 352.26 452.61
LoRa SF11 / 125KHz 16.38 200.70 786.43 987.14
LoRa SF12 / 125KHz 32.77 401.41 1409.02 1810.43
Figure 8. Typical values of airtime for a 20 bytes payload and different SF
17
3.4 Airtime
The parameters (SF, BW, and CR) combined with the packet structure and length described above will
give the total duration of the radio emission on the air medium, called the “airtime”.
The airtime is key in estimating a LoRaWAN network capacity and scaling it. The longer it will be, higher
is the risk of collision.
The duration of a transmission can be calculated using the Semtech LoRa modem calculator [18]. It
must be noted that depending on the selected communication settings a data packet can have
significant variations in airtime.
Hence, a typical 20 bytes applicative payload with a 125 kHz BW, 4/5 CR and different spreading factors
(SF) varies from 71.94 ms to 1.81s as shown in Fig. 8.
18
4 THEORETICAL CALCULATIONS
In this section, we develop the link budget calculations and the propagation model used to estimate
the achievable communication range. This range depends on the parameters detailed above in section
3.2.
4.1 Gateway sensitivity
The first step in a budget link calculation is to estimate the receiver’s sensitivity.
Only uplink (from devices to the LoRaWAN network) was modelled in a first approach. Hence, the
sensitivity is the one from the gateway.
The sensitivity of a radio receiver at room temperature is given by:
𝑆 = −174 + 10 × 𝑙𝑜𝑔(𝐵𝑊) + 𝑁𝐹 + 𝑆𝑁𝑅 (1)

The first term describes thermal noise in 1Hz of bandwidth and can only be influenced by changing the
temperature of the receiver. BW is the receiver bandwidth (125 kHz in Europe). NF is the receiver noise
figure of the receiver, it represents the amount of noise power created by the RF front end. It is fixed
for a given hardware implementation.
SNR is the signal-to-noise ratio required by the underlying modulation scheme and is determined by
the spreading factor SF: the faster the SF, the higher the SNR, as shown in Fig. 9 below.
Spreading Factor Spreading Factor LoRa Demodulator
(RegModemConfig2) (Chips/Symbol) SNR
6 64 -5
7 128 -7.5
8 256 -10
9 512 -12.5
10 1024 -15
11 2048 -17.5
12 4096 -20
Figure 9. SNR versus SF, SF6 is not used in LoRaWAN (source: [19])
Figure 10 shows the receiver sensitivity for Semtech SX1301 LoRa Chip [20] for Average White Gaussian
Noise (AWGN) channel (static conditions, no fast fading and no additional interference on top of
thermal noise).
19
Figure 10. SX1301 Sensitivity Figures (source: Semtech)
20
Only the 1% PER values are considered because, in a real network, the capacity will be mostly limited
by packet losses because of collision and fading and not because of AWGN.
A LoRaWAN packet will be correctly demodulated if the ESP (estimated signal power) is above Receiver
sensitivity.
The ESP is not the RSSI (which also contains noise and interference energy) but the actual useful signal
received by the chipset, calculated as follows:
𝐸𝑆𝑃 = 𝑅𝑆𝑆𝐼 − 10 × 𝑙𝑜𝑔(1 + 10(−𝑆𝑁𝑅/10) ) (2)

The packet will be received if:
𝐸𝑆𝑃 > RXSGW, SF (3)

Where RXSGW, SF is the gateway sensitivity for the given SF.
4.2 Link budget and propagation model
To estimate the cell range, a link budget must be calculated. From that link budget a MAPL (Maximum
Allowed Path Loss) value will be deduced and that path loss will be translated into a distance by the
mean of a propagation model.
The radio propagation model used for the calculations is the Okumura-Hata model. This model is valid
for deployments where the base station is installed in outdoor location at high points compared to the
height of the surrounding buildings.
The cell range will be needed to simulate a real network and derive the number of gateways needed
for a given area.
We first calculate EIRP (which is the Equivalent Isotropic Radiated Power or the quantity of energy
radiated over the air by the end-device)
𝐸𝐼𝑅𝑃𝐸 = 𝑃𝑇𝑋 + 𝐺𝐸 − 𝐿𝐸 (4)

Where 𝑃𝑇𝑋 is the conducted power from the device, 𝐺𝐸 the device’s antenna gain and 𝐿𝐸 the potential
RF losses on the end-device’s side (RF switch, non-matching circuit, connectors).
Then we calculate the « Maximum Allowable Path Loss » in uplink, as follows:
MAPLUL = (EIRPE − RXSGW, SF) + (GGW − LGW) − (MShadowing + MRayeleigh )
− NoiseDL − Mindoor (5)
Where RXSGW, SF is the gateway sensitivity for the given SF (cf. previous paragraph). GGW and LGW are
the antenna gain and RF losses on the gateway side, M𝑅𝑎𝑦𝑒𝑙𝑒𝑖𝑔ℎ and M𝑆ℎ𝑎𝑑𝑜𝑤𝑖𝑛𝑔 are the margins
taken for fading effects, Noise𝐷𝐿 is the noise rise on the gateway’s receiver and at last M𝑖𝑛𝑑𝑜𝑜𝑟 is the
additional attenuation if the end-device is located indoor.
21
Using the Hata-Okumura model, the MAPL can be expressed in the following form:
𝑀𝐴𝑃𝐿𝑈𝐿 = 𝐾1 + 𝐾2 × 𝑙𝑜𝑔(𝑅𝑈𝐿 ) (6)

𝐾1 and 𝐾2 are two factors depending on the morphology of the environment and the relative heights
(above ground) of end-device and gateway. An example is given in Fig. 11.
Figure 11. Hata-Okumura model parameters (source: Actiltiy)
That MAPL can be translated into a cell range 𝑅𝑈𝐿 from equation (6):
𝑀𝐴𝑃𝐿𝑈𝐿 −𝐾1
𝑅𝑈𝐿 = 10 10×𝐾2 (7)
From that distance, the ISD (Inter Site Distance, the distance between two gateways in the network)
can be calculated. This ISD will allow the exact computation of the network density.
As illustrated below, the ISD calculation depends on the network’s topology:
• If omni-directional antennas are used, then:
𝐼𝑆𝐷𝑜𝑚𝑛𝑖 = 𝑅𝑈𝐿 × √3 (8)
• If directional antennas are used, then:
3
𝐼𝑆𝐷𝑜𝑚𝑛𝑖 = 𝑅𝑈𝐿 × (9)
2
Figure 12. ISD calculation following the cell pattern (source: Actility)
22
5 SIMULATION ASSUMPTIONS
This section details the assumptions added to the LoRaSim [10] simulator tool and explanation of the
reasons they are needed to have a correct evaluation of a real network.
5.1 Packet error rate (PER)
The packet error rate (PER) is the percentage of packet loss over the whole number of transmitted
packets. In LoRaWAN, we don’t distinguish PER and MER (Message Error Rate) because 1 packet
contains only 1 message.
The goal of the simulations was to find the maximum number of end-devices for a target PER.
The PER comprised packet losses due to collision and the losses due to radio effects (namely fading, as
described in the next paragraph).
𝑃𝐸𝑅𝑡𝑎𝑟𝑔𝑒𝑡 = 𝑃𝐸𝑅𝑐𝑜𝑙𝑙𝑖𝑠𝑖𝑜𝑛𝑠 + 𝑃𝐸𝑅𝑟𝑎𝑑𝑖𝑜 (10)
As of today, in our simulations, a fixed ratio of ½ between collision PER and radio PER is taken but in
future implementations it could be dynamic to find the optimum ratio between collisions and radio
losses. That means that for high density network with small cell range, most of the packet losses will
be due to collision and not fading, allowing to target a PER of nearly 10% instead of 5% and increasing
again the estimated capacity.
𝑃𝐸𝑅𝑡𝑎𝑟𝑔𝑒𝑡
𝑃𝐸𝑅𝑐𝑜𝑙𝑙𝑖𝑠𝑖𝑜𝑛𝑠 = 2
= 5% (11)
It should be noted here that the target is not an average Packet Error Rate (PER) over the whole cell
(which would give rather optimistic results) but the worst PER for each SF group.
Hence, for each simulation we compute:
𝑃𝐸𝑅𝑆𝑖𝑚𝑢𝑙𝑎𝑡𝑖𝑜𝑛 = 𝑚𝑎𝑥(𝑃𝐸𝑅𝑆𝐹,𝑁𝑐𝑒𝑙𝑙 ) ∀ 𝑆𝐹 ∈ {𝑆𝐹7 , . . 𝑆𝐹𝑚𝑎𝑥 } (12)
Where 𝑆𝐹𝑚𝑎𝑥 is the maximum SF allowed in the cell, 𝑁𝑐𝑒𝑙𝑙 is the number of end-devices in the cell
(central cell for multi-cell simulation) and 𝑃𝐸𝑅𝑆𝐹,𝑁𝑐𝑒𝑙𝑙 is the average PER for the all the device using
that SF :
∑ 𝑃𝑎𝑐𝑘𝑒𝑡𝑠 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑 𝑤𝑖𝑡ℎ 𝑆𝐹
𝑃𝐸𝑅𝑆𝐹,𝑁𝑐𝑒𝑙𝑙 = 𝐴𝑙𝑙 𝑝𝑎𝑐𝑘𝑒𝑡𝑠 𝑏𝑦 𝑡ℎ𝑒 𝑒𝑛𝑑−𝑑𝑒𝑣𝑖𝑐𝑒𝑠
(13)
The simulation is stopped when:
𝑃𝐸𝑅𝑆𝑖𝑚𝑢𝑙𝑎𝑡𝑖𝑜𝑛 ≥ 𝑃𝐸𝑅𝑡𝑎𝑟𝑔𝑒𝑡 (14)
And the number of devices satisfying the target is then 𝑁𝑐𝑒𝑙𝑙 .
5.2 Fading simulation
Fading is an unavoidable impairment of every wireless channel. It’s necessary to take it into account
because it has an important contribution to packet loss. Moreover, as some packets will never be
received by a gateway it will change the collision rate.
23
Figure 13. Fast-fading effect: attenuation on vertical axis vs time. The mean is 0.
Both types of fading have been implemented in the simulator by taking 2 margins which will reduce
the cell range to ensure that the packets are received properly. In a real LoRaWAN network, cell
planning is also done by taking those margins into account.
• Slow fading (or “shadowing”) accounts for the big, slow or static obstacles between the
devices and the gateway. Those different attenuations are modeled by a gaussian distribution
with a mean of 0 and a standard deviation of 8.7 dB, according to the usual target of 95% of
covered area in cellular planning (it’s a typical value for wireless channels < 900 MHz). This
margin is calculated once and for all at the device’s creation, then it is applied to each packet
sent.
• Fast fading (or “Rayleigh fading”) is the fast, transient effect occurring because of the
combination of different reflections of the signal. These different rays are combined to create
destructive interference (but occasionally constructive interference, increasing the received
signal strength). Those attenuations are modeled by a Rayleigh distribution (considering that
you rarely have a dominant line-of-sight ray in a typical LoRaWAN network). A margin is
calculated once at the cell’s creation then, on each packet sent, a fast-fading attenuation
(impairment) is added.
The fast-fading margin is calculated as follows:
• The CDF of a Rayleigh distribution is:

−𝑥2
𝐹(𝑥, 𝜎) = 1 − 𝑒 2𝜎2 (15)
• In the simulations done for this paper, the value of σ is 0.8. This value depends on how fast
the channel is changing around the device and the gateway. 0.8 is a typical value for a wireless
channel < 900 MHz.
24
• Plotted against a dB margin, that gives the following curve:
Figure 14. Rayleigh distribution CDF curve vs dB margin (source: Actility)
Moreover, the number of message repetition changes that margin:
• For a total of 10% PER we accept that at most half of the lost packets will be because of fading
effect, we then target a 5% radio PER
• For 1 Tx we want to have less than 5% of chance to lose a packet because of fading. Looking at
that curve, we get a margin of 11.8 dB
• For 3 Tx, as we have twice additional “chances” to receive and decode the packet, we can
accept to have an individual PER of 36.7% because 0.367^3 = 0.5. It’s OK to lose 36.7% of each
individual packet because on average we’ll still recover 5% of the messages sent
• That 36.7% value gives a margin of 2.3 dB thanks to the curve above
We apply that margin on each device for the pathloss calculation to ensure that the 5% PER won’t be
exceeded. The effective cell radius is then reduced accordingly.
At last, in the present study, the shadowing effect has been deactivated. The positions of device have
been randomized to avoid bias in the results, thus the shadowing wouldn’t have any significance
because its distribution’s mean is zero.
In other words, we were not interested in presenting results for a specific geographical location
(considering obstacles and then shadowing) but rather in having typical capacity for a LoRaWAN
network given a radio configuration with different parameters (such as SF, power, and so on).
5.3 Collision behavior
It’s crucial to properly model collision between packets to be able to derive the real capacity figures.
A collision may occur, by definition, when more than 1 message overlap as seen by the receiver:
25
• Using the same LoRa Spreading Factor (unless signal levels are different by more than 6 dB,
in which case strongest signal is decoded see details below)
or
Using different LoRa Spreading Factors when the interferer signal degrades the SNR of device
signal beyond minimum SNR for the Spreading Factor in use (near-far effect)
• At the same time
• On the same frequency channel
5.3.1 Spreading factor collision
Spreading factors exhibit quasi-orthogonal characteristics. It means that, most of the time, up to 6
packets with different spreading factors (SF7 to SF12) can be decoded at the same time on the same
frequency. This is one of the important properties of LoRaWAN which explains the increased capacity
beyond pure Aloha based deployments.
As for every wireless technology, there’s a “near-far” effect when a message with strong signal is
received at the same time as a very weak message. The stronger packet will be recovered and other
can also be demodulated if the SINR is above the minimum required.
Moreover, ADR will minimize that “capture effect” by applying power control on the transmissions to
reduce.
Each element of the matrix 𝑇𝑖𝑗 below (source [15]) represents minimum SINR required to decode
packet with 𝑆𝐹𝑖 interfering with packet with 𝑆𝐹𝑗 with Ɛ {SF7, SF8, SF9, SF10, SF11, SF12}.
6 −5 −5 5 5 5
−10 6 −10 −10 −10 −10
−12.5 −12.5 6 −12.5 −12.5 −12.6
𝑇𝑖𝑗 = (16)
−15 −15 −15 6 −15 −15
−17.5 −17.5 −17.5 −17.5 6 −17.5
( −20 −20 −20 −20 −20 6 )
The relative SINR needed to be able to decode a packet (row being the SF trying to be demodulated)
in presence of another packet (SF in column). When two packets are received with the same SF, one
must be 6 dB higher to be able to be decoded. When the SF is not the same, both packets can be
decoded as soon as the co-channel rejection value is respected (e.g., SF8 packet must be at most 20
dB higher than a SF12 packet).
When there are multiple packets interfering, we considered in the simulation the sum of energy of all
the interfering packets to calculate the SNR:
𝐸𝑆𝑃𝑖
𝑆𝑁𝑅 = ∑𝑛
(17)
1 𝐸𝑆𝑃 +𝐼
5.3.2 Frequency collision
26
The LoRaWAN channels do not overlap and are spaced by 200 kHz. That additional guard band (the
modulation itself being only 125 kHz) makes that the power leaked in adjacent channel is negligible.
Hence, each frequency channels in LoRaWAN are considered orthogonal to each other.
5.3.3 Time collision
At last, a collision only occurs if more than one packet is received on the same frequency at the same
time.
“Same time” must be correctly defined as well: from the measurements done by [21], it’s taken as
assumption that there’s a collision if the preamble is overlapping on more than 3 symbols.
5.4 ADR (Adaptive Data Rate)
ADR is a fundamental mechanism in LoRaWAN networks. It allows the network to dynamically set the
end-device’s Spreading Factor (SF), Transmit (TX) Power or number of repetitions to have the most
optimal configuration (in terms of coverage and battery life).
The LoRaWAN specifies the MAC message to send for changing such parameters but not when to do
it.
ADR is calculated once at the beginning of the simulation as follows:
• When a device is created, the link budget is calculated (with fading margin but without the
transient fading component added) towards each base station
• The base station with the best link budget is chosen
• From that link budget, a Data rate (Spreading Factor) and TX Power is calculated and
configured into the device
• When the multiple transmission feature is enabled, the fading margin is calculated
accordingly, giving a better link budget and allowing for a better SF
This method avoids complex calculations on each packet and assumes that the ADR algorithm has
converged as soon as the first packet. This is valid as the only transient effect in the simulation model
is the Rayleigh fading.
The SF distribution is the key in those capacity calculations and simulations, because we compute
capacity for a homogeneous device distribution in space, i.e. the areas with lowest capacity per unit of
surface are the limiting factor. The slower SF there is in the cell, the less the capacity will be. That is
why a good ADR algorithm is a crucial element. An example of the SF distribution in a LoRaWAN cell is
given below.
27
Figure 15. SF distribution inside a typical LoRaWAN cell
Figure 16. Device distribution in a simulated cell. One color per SF
5.5 Deployment Assumptions
Finally, in this section, we summarize all the assumptions used for the simulations. Note that we
selected 0dBi antenna gain, which is realistic for compact IoT devices, as opposed to the better 3dBi
antennas that are often found in specialized test devices.
28
Applicable Regulatory Rules Europe – 863-870 MHz
Number of LoRaWAN channels 16
Target UL Cell Edge Data Rate LoRa SF7-SF12 / 125 kHz (multiple simulation
scenarios)
Target UL Effective Packet Error Rate 10%
#Transmissions per UL packet 1-3 Tx (multiple simulation scenarios)
End-Device Location Indoor Daylight
UL Noise Rise at Gateway 10 dB
End-Device Max TX Power 16 dBm
End-Device Antenna Gain 0 dBi
Default Gateway Cable and Connector 0.5 dB

Losses
UL Payload size 20 Bytes
DL Payload Size 10 Bytes (not simulated yet)
# UL Packets / day / device 48
Morphology Urban
Dense-Urban Urban Sub-Urban Rural
End-Device Antenna Height 1.5m 1.5m 1.5m 1.5m
Gateway Antenna Type Omni Omni Omni Omni
Gateway Antenna Gain 8 dBi 8 dBi 8 dBi 8 dBi
Gateway Antenna Height 30m 25m 20m 40m
Indoor Penetration Margin 18 dB 15 dB 12 dB 11 dB
The simulation considers an omni-directional cell layout based on hexagonal deployment of gateways.
It’s like what’s done in cellular networks.
The end-devices are assumed to be distributed homogeneously in the whole area.
Only the performance (PER) of the central cell is calculated but the other cells are there to simulate
the macro-diversity effect. The outer ring is employed to consider the traffic load it will imply on the
inner ring gateways.
29
Figure 17. Simulated network layout with hexagonal tiling
30
6 RESULTS
6.1 Isolated Cell Deployment
An “isolated cell” is a LoRaWAN cell without any overlapping neighbor cells. That means that no macro-
diversity gain (a message being received by more than one gateway) will be considered.
In this section, we describe the results of single cell deployment with different targets for cell-edge
targets ranging from SF7, SF8, SF9, SF10, SF11, SF12. In the next sections, we investigate further on the
effect of uplink macro-diversity and retransmissions on the capacity.
We compare the results below for two scenarios:
• In the first scenario, we use a static target SF without using ADR

• In a second scenario, we adapt the transmission SF using an ideal Adaptive Data Rate (ADR)
algorithm. It’s “ideal” because it converges toward the optimal configuration (in terms of SF/
Tx Power / number of transmission) based on the path loss between gateway and end-device
on the 1st packet
We plot the capacity in terms of number of messages/day/km² as different IoT devices have different
throughput requirements. We believe that for short-message based deployments like LoRaWAN, it is
rather appropriate to evaluate capacity in terms of number of messages/day/km².
Figure 18. Fixed SF Vs ADR comparison (single cell, 1 TX)
ADR and advanced network algorithms are the key to

achieving high capacity needed for LPWAN Deployments
With ADR enabled, the results show dramatic (up to 2X) increase compared to static settings. ADR is
one of the key features that must be implemented carefully in network server.
31
Static SF12 exhibits worst case performance for pure Aloha for the static SF configuration.
However, LoRaWAN exhibits strong immunity to interference and allows simultaneous decoding of
different spreading factors when they overlap. We show further in later sections how the capacity
increases dramatically in multi-cell deployments and retransmissions.
6.2 Multi-Cell Deployment
In this section, we show the results of multi-cell deployment. We simulate 19 cells in hexagon
deployment and only take results from the innermost cell to make things comparable with the single
cell scenario and avoid border effects.
For each scenario, we averaged the results from 15 individual simulations, each simulation consisting
of 200 hours of device’s traffic. It has been done to avoid any bias due to randomness of the packet
transmission time and device positioning.
The cell-range is based on different spreading factor (SF) targets as described in earlier section.
Densification is then simulated by changing the cell-edge SF: as gateway will be installed closer to each
other, the worst SF used in the cell will increase because any end-device will be closer to a gateway
and have a better link budget.
Figure 19. Impact of multi-cell deployment on Capacity
Uplink Macro-Diversity with ADR results in capacity increase

of at least 4X compared to isolated Gateway deployment
scenario. This increase is exponential when the ISD
decreases.
32
The results show up to 4x gain in capacity compared to single-cell scenario thanks to uplink macro-
diversity in-built into LoRaWAN network architecture that allows simultaneous decoding of uplink
messages from users at the cell-edge.
As a side note, when LoRaWAN network is designed for geo-location, there is a minimum of 3 way
(ideally 4 way or more) macro-diversity required in network design. This macro-diversity also brings
tremendous benefits to nodes which are not using geolocation, in terms of lower PER, which in turn
translated to lower power consumption.
The cost of LoRaWAN small-cell gateways is very low and the deployment is plug and play with meager
requirements for backhaul which can be supported by even 3G/4G/LTE Cat-M1 modems.
Below is the complete curve showing exponential capacity growth when the base stations are put
closer (calculations have been done until an ISD of 500 meters).
Even if there’s only one SF available with such a short cell range (SF), the capacity continues to increase
thanks to the macro-diversity gain. The collisions do not happen on the same gateway with the same
reception level at the same time.
This shows that the future of LoRaWAN networks, particularly in urban environments where the noise
floor is expected to get higher due to increased traffic, goes towards micro-cellular networks, e.g. with
receivers integrated to triple play modems. Macro-diversity provides not only increased capacity, but
greater resilience to interference and lower power consumption for end devices.
Figure 20. Evolution of capacity when ISD is becomes short (number of messages, per millions, vs ISD)
The future of LoRaWAN networks, particularly in urban

environments where the noise floor is expected to get
higher due to increased traffic, goes towards micro-cellular
networks
33
6.3 Retransmissions
Retransmissions are an easy way for LoRaWAN to either improve reliability or increase capacity.
Keeping the effective target packet error rate at 𝑃𝐸𝑅𝑡𝑎𝑟𝑔𝑒𝑡 = 10% , PER for each individual
retransmission can be much higher. For example, with 3 transmissions for each message, each
individual packet can have a PER of 46.4% for a global PER of 10% for the message) and thus can even
allow to increase the SF.
𝑛(1⁄ )
PER individual = 𝑃𝐸𝑅𝑡𝑎𝑟𝑔𝑒𝑡 (18)
Figure 21 below shows the effect of retransmissions for multi-cell scenario when going from 1 to 3
transmissions with a goal to increase capacity, while keeping the same PER target.
Retransmissions can add up to 5X gain especially for lower gateway density scenarios.
Figure 21. Impact of retransmissions on Capacity
Multiple transmissions allow to increase the SF, which

reduces the power consumption and increases the
capacity. It’s especially powerful with low GW density
scenarios.
6.4 Power consumption
In the figure below, we plot how the power consumption or battery lifetime changes with the
densification of the network.
The curve below assumes battery capacity of 5Wh, no downlink traffic and uplink traffic of 20 bytes
payload 48 times per day. The worst situation is considered: when the device is at the cell edge.
The calculations are based on the figures found in the Semtech SX1272 datasheet [19].
34
The conclusion is that the battery lifetime increases dramatically with the gateway densification: as
the worst SF used increased, the reception duration is much shorter and the consumption drops
making the battery lifetime increase.
Between message reception events, the consumption of a LoRaWAN device is extremely low because
there’s no need to maintain a connection with the network.
Figure 22. Worst case battery life of cell-edge users (48 uplinks/day, No downlink)
Densification leads to very dramatic reduction in power

consumption of the end-devices thus reducing overall TCO
35
6.5 Why does LoRaWAN exhibit capacity beyond Aloha?
There has been lot of discussion in the previous works ( [6], [8]) that LoRaWAN is not scalable due to
its ALOHA characteristics. Even if LoRaWAN has characteristics that make it much more scalable than
traditional ALOHA, we have shown in earlier sections that a poor network design (for example, static
SF setting without using ADR) and/or inefficient algorithms will result in poor scalability.
LoRaWAN specification has simple ADR guidelines, but it is up to the network vendors to implement
their own ADR algorithms. The network fine-tuning of any network, especially for IoT devices (which
are sleeping most of the time and are constrained by battery) is a challenging problem by itself. It
needs to be addressed by the network server manufacturer.
For example, the network server can choose to increase repetition or decrease data rate (or both) to
decrease PER. Not all choices are equal and the optimization, which also needs to consider the specific
RF channel statistics of the given device, including the macro diversity properties, is complex.
This problem will need to be solved even for synchronous protocols such as 3GPP NB-IoT, LTE-M where
scheduling algorithms are never part of the standard.
The asynchronous nature of LoRaWAN protocol for class A devices allows device to send a message
only when it's needed and is one of the key features that makes it significantly power efficient and the
cost-effective (in terms of modem hardware) compared to synchronous protocols such as 3GPP LTE-
M or NB-IoT. However, there are other classes in LoRaWAN (class B or class C) which results in less
latency at the cost of higher power consumption.
Simple LoRaWAN protocol coupled with a sophisticated network management algorithm (namely ADR
for power consumption and capacity regulation) yields highly-scalable and power-efficient networks
The key to LoRaWAN scaling lies in the advanced algorithms at the network server and maturity of
vendor equipment.
LoRaWAN spreading factor quasi-orthogonality, ADR and

uplink macro-diversity are the main factors to achieve
capacity beyond traditional Aloha based deployments.
36
7 OPERATOR USE CASES
When designing and deploying a LoRaWAN network, the system operator must balance the cost of a
dense network (and its served sensors) against the cost of a sparse network (and its served sensors).
We compare two alternative deployment models in this section of the paper.
7.1 Traditional vs Opportunistic network designs [30] [31]
In the traditional deployment model, the operator hangs LoRaWAN gateways on towers. This entails
leasing the space from the tower owner, purchasing a waterproof outdoor gateway, climbing the tower
to hang the gateway, and perhaps paying for additional power, zoning, permitting, and backhaul. The
operator does the detailed RF propagation study and hangs enough gateways to provide coverage for
the sensor locations required to provide the services he wants to provide.
Another option is to opportunistically deploy “femto” gateways in devices that the operator is already
fielding. The gateways are stateless, and thus do not add much complexity to the hosting device. An 8-
channel LoRaWAN reference design is mated to the host device using either USB or I2C. The options
here are quite diverse. The operator can embed a simple 8 channel gateway into ongoing WiFi hotspots,
power supplies, amplifiers, cable modems, thermostats, virtual assistants, or any mass-produced
device that already has backhaul. The Bill of Materials adder is quite modest, the power consumptions
and heat dissipation are less than 3 Watts, and the size delta is roughly 7 cm by 3 cm.
Calculating the number of opportunistic gateways to provide adequate coverage for a given
deployment can be challenging. The height of the gateways has a large impact on the coverage of the
gateway. A gateway deployed in a 20th story of an apartment building has a much better coverage
pattern than the same gateway deployed in the basement of a single-family home. Gateways deployed
in WiFi hotspots mounted on power poles have a different coverage area than a gateway deployed on
light poles. So, the actual number of gateways deployed in each scenario varies widely. When you
complete the detailed design of each network type, you typically find that an opportunistic deployment
model allows the operator to cover a given area by deploying roughly 100 times as many gateways for
roughly 1/10th of the cost (when compared to the traditional 3rd party leased tower model).
7.2 Example use-case with water meters [30] [31]
For the rest of this analysis, we will assume that the operator needs to deploy a LoRaWAN network to
service 100K water meters. Water meters represent a difficult RF propagation model. They are
installed at or below ground level, must last 20 years, and suburban meters tend to have accumulations
of grass and dirt collect over time. Let’s assume a North American deployment model, and we have
the option of using a high power (27dBm) or a low power (17dBm) meter.
One possible design is to use a tower-based approach. In a tower-based approach, the operator
typically ends up deploying high power water meters in order to reduce the number of (expensive)
tower leases. In order to run at high power, the North American regulations require the sensor to send
across 50+ channels, which drives the operator to deploy 64 channel gateways. Let’s assume that the
average distance between a water meter and a tower-based gateway is ~3km and the sensors need to
send one reading per day. Many of the meters thus operate at SF10 at 27dBm. The sensor designer
includes a high-power RF amplifier, calculates the energy requirements over the life of the sensor, and
sizes the battery appropriately.
37
Another possible design is to opportunistically deploy thousands of femto gateways into the area. The
question boils down to “How many femto gateways do I need to cover the desired area?”. Working
backwards from the densest possible deployment, most MSOs (Multiple-System Operator) serve 1/3
of the households in their footprint. In many urban environments, the average distance between a
given operator’s subscribers is 30 meters. If such an operator could opportunistically deploy in most
of those sites, they would have inter-gateway distances as small as 30 meters. For the purposes of this
analysis, let’s say that the average distance between the sensor and the closest gateway is reduced
from 3000 meters to 100 meters. When a sensor is 100 meters from a gateway, it can typically operate
at SF7 at 17dBm (or lower). Clearly, the network designer must account for a distribution of distances
between a given sensor and its closest gateway, but the overall power savings is significant.
It is also instructive to compare the overall capacity of a tower-based LoRaWAN network to the overall
capacity of the opportunistic LoRaWAN network. Remembering that 100 eight channel opportunistic
gateways cost about 1/10th of a single 64 channel gateway, we realize that we get ~13 times as much
network capacity for 1/10th of the cost. As the sensor density increases, we could deploy additional
opportunistic gateways and get ~130 times as much network capacity for the same cost as a tower-
based network.
When we compare the cost to build a sensor designed to last 20 years using SF10 at 27dBm to the cost
to build a sensor designed to last 20 years using SF7 at 17dBm, we find that we can save more than
$10 per sensor by deploying the denser network.
So, in addition to saving a significant amount of capital by opportunistically deploying the gateways,
the operator can save more than $10 per water meter by opportunistically deploying a dense network.
This saves more than $1M on the 100K water meter deployment. When one layers in additional use
cases, the dense LoRaWAN network provides sensor savings on each additional set of sensors. Most of
the sensors do not have the 20 years requirement and thus do not save the same amount of money,
but batteries are one of the primary drivers for any sensor’s cost.
7.3 Conclusion
This analysis is somewhat simplified, and a very large-scale deployment may require a certain amount
of traditional gateway placement to provide an “umbrella” of coverage that is then densified using
opportunistic methods. By densifying the network, the overall sensor power budget is decreased
significantly. One could also envision a deployment model in which an opportunistic gateway is
deployed in conjunction with a set of services. The operator would add IoT based services to an existing
bundle (let’s say voice/video/data, thermostat control or personal assistant) and know that the sensors
would be co-resident with the gateway.
38
8 SUMMARY
This paper shows that LoRaWAN exhibits significant capacity gains when ADR algorithms are used in
the network. We showed how LoRaWAN networks are deployed for coverage and how network
capacity can be scaled gracefully by adding more gateways.
There are already 16 channels in EU, but there have been recent modifications of the regulatory
framework to relax the spectrum requirements and increase transmit power, duty cycle and number
of channels [22].
Moreover, Semtech released the latest version of LoRa chipsets [23] with the following key features:
• 50% less power in receive mode

• 20% extended cell range
• +22 dBm transmit power
• A 45% reduction in size: 4mm by 4mm
• Global continuous frequency coverage: 150-960MHz
• Simplified user interface with implementation of commands
• New spreading factor of SF5 to support dense networks
• Protocol compatible with existing deployed LoRaWAN networks
The above LoRaWAN features and upcoming changes to EU regulations will allow significantly scaling
of unlicensed LoRaWAN deployments for years to come to meet the needs of IoT applications and use
cases. LoRaWAN capacity depends indeed on the regional and morphology parameters. As we have
showed in the above results, if the network is deployed carefully and advanced algorithms such as ADR
are used, there can be dramatic increase in network capacity. This will be one of the main factors that
will determine the success of LoRaWAN deployments as the demands and breadth of IoT applications
scale in future.
We also showed earlier how LoRaWAN offers innovative public/private deployment model in which
operators can build capacity incrementally and supplement with extra capacity by leveraging gateways
deployed from private individuals/enterprises. Typically, for cellular networks there can be anywhere
from 5-10% IoT devices on cell-edge which are in outage [24]. This applies especially to deep indoor
nodes (for example, smart meters with additional 30 dB penetration loss). Such nodes can only be
covered by densification of cellular network which is expensive considering it is being done only for 5-
10% of IoT devices. One way to address this problem is deploying private LoRaWAN on cell-edge and
using multi-technology IoT platform that combines both LoRaWAN and Cellular IoT [36].
On the other hand, LoRaWAN offers a cost-effective way to augment network capacity where it's
needed most. LoRaWAN gateways are very cost-effective and can be deployed using Ethernet/3G/4G
backhaul with minimal investment in comparison to 3GPP small cells. This allows building IoT network
in cost-effective manner and scale it progressively based on the application needs. We believe that his
deployment model has dramatic effect on ROI for IoT connectivity based on LoRaWAN.
The LoRa Alliance has standardized the roaming feature, which enables multiple LoRaWAN networks
to collaboratively serve IoT devices. Macro-diversity used across deployments enables
operators/enterprises to jointly densify their networks, hence providing better coverage at lower costs.
39
The future of LoRaWAN as shown in Fig. 23 will be private/enterprise network deployments and
disruptive business models through roaming with the public networks [32] [33] [34] [35].
Figure 23. Future of LoRaWAN deployments
In future work, we plan to extend LoRaSim with downlink and show the impact of retransmissions and
downlink communication on the capacity of LoRaWAN deployments and understand better the
dynamics between UL/DL traffic. We also plan to extend the work with the scenarios where there is
LoRaWAN macro-cell that provides light outdoor coverage, whereas pico-cells are deployed on
demand for supporting capacity hotspots.
LoRaWAN does provide horizontal connectivity solution to

address wide-ranging needs for IoT applications for
LPWAN deployments. However, these benefits are only
possible with intelligent network server algorithms
proprietary to network solution vendors
40
9 ABOUT ACTILITY
Actility is world leader in OSS/BSS solutions for the IoT and is the co-founder of LoRa Alliance (along
with IBM and Semtech). Actility is leader in country-wide carrier grade LPWAN IoT deployments and
holds more than 70% market share in LoRaWAN deployments, with tier-1 customers such as Comcast,
KPN, NTT, Orange, SoftBank, Swisscom, and many other cellular and fixed service providers. Actility
has also developed optimized connectivity and OSS/BSS solutions for cellular IoT to help operators
maintain profitability despite lower ARPU.
As an early pioneer in LPWAN innovation and one of the only technology agnostic players, Actility can
help you map your use cases to connectivity. We provide the multi-technology ThingPark Wireless
platform for seamlessly integrating LoRaWAN and Cellular IoT technologies. We also provide ThingPark
Enterprise to enable private LoRaWAN deployments for enterprises.
Figure 24. ThingPark Product Portfolio
ThingPark Wireless presents a unified user interface and APIs to applications, and a single layer of
device and connectivity management for both LoRaWAN and cellular IoT technologies. It exhibits the
following high-level features:
▪ Cost-effective Multi-technology radio agnostic Platform to seamlessly manage both LoRaWAN

and Cellular IoT technologies
▪ OSS/BSS Solution with focus on IoT
▪ Data Mediation layer for building data analytics and interfacing with 3rd party cloud servers
(for ex. Amazon AWS)
▪ Pre-integrated interface with Click and Go (https://iot.thingpark.com/clickandgo/) or
ThingPark Market (http://market.thingpark.com) enabling acceleration of operator go to
41
market through dynamic open ecosystem management, and facilitating the shift of service
provider business by tapping into the whole service value, not just connectivity
▪ Billing solution tailored for the needs of IoT use cases
Open and modular with OSS/BSS APIs allowing easy integration with operator’s internal or 3rd
▪ party platforms/applications
▪ Strong security options with Secure Element and HSM options, and integration with
eSIM/eUICC technologies via OSS/BSS APIs
▪ ThingPark Enterprise for private LoRaWAN deployments [32] [33]
▪ ThingPark Exchange for enabling roaming between operator and enterprise deployments [34]
[35]
For more information or to arrange a demo in ThingPark Lab@Paris or to contact our sales team, feel
free to contact us below:
https://www.actility.com/contact/
42
10 REFERENCES
[1] SigFox, https://www.sigfox.com/en.
[2] RPMA, https://www.ingenu.com/technology/rpma/.
[3] Weightless, http://www.weightless.org/.
[4] 3GPP NB-IoT, Cat-M1, http://www.3gpp.org.
[5] What is LoRa, LoRa Alliance. https://www.lora-alliance.org/what-is-lora.
[6] Do LoRa Low-Power Wide-Area Networks Scale?, Martin Bor, Utz Roedig, Thiemo Voigt, and
Juan Alonso, MSWiM 2016.
[7] Mitigating Inter-Network Interference in LoRa Networks, Thiemo Voigt, Martin Bor, Utz
Roedig, and Juan Alonso, EWSN 2017.
[8] Scalability analysis of large-scale LoRaWAN networks in ns-3 Floris Van den Abeele, Jetmir
Haxhibeqiri, Ingrid Moerman, Jeroen Hoebeke, Univ. of Ghent,
https://arxiv.org/abs/1705.05899.
[9] ThingPark Wireless Platform, Actility, https://www.actility.com/products/.
[10] LoRaSim, http://www.lancaster.ac.uk/scc/sites/lora/lorasim.html.
[11] LoRaWAN Regional Parameters v1.1rB – Final (LoRa Alliance).
[12] https://www.cbrsalliance.org/.
[13] LoRaWAN Backend Interfaces 1.0 Specification (LoRa Alliance) - https://lora-

alliance.org/resource-hub/lorawantm-back-end-interfaces-v10.
[14] LoRaWAN™ Specification v1.1 https://lora-alliance.org/resource-hub/lorawantm-specification-

v11.
[15] LoRaWAN™ Specification v1.0.2 https://lora-alliance.org/resource-hub/lorawantm-

specification-v102.
[16] ERC Recommendation 70-03: Relating to the use of Short Range Devices (SRD), Oct. 2017
CEPT/ERC/REC 70-03.
[17] LoRa Transmission Parameter Selection, Martin Bor, Utz Roedig, Lancaster University -
http://eprints.lancs.ac.uk/85515/4/lora_tps_r1342.pdf.
[18] LoRa Calculator:

https://www.semtech.com/uploads/documents/SX1272LoRaCalculatorSetup1_1.zip.
43
[19] Semtech SX1272 Chipset - https://www.semtech.com/products/wireless-rf/lora-
transceivers/SX1272.
[20] Semtech SX1301, https://www.semtech.com/products/wireless-rf/lora-gateways/SX1301.
[21] Network level performances of a LoRa system Master Thesis - Davide Magrin supervised by
Lorenzo Vangelista.
[22] http://eur-lex.europa.eu/eli/dec_impl/2017/1483/oj.
[23] https://www.semtech.com/products/wireless-rf/lora-transceivers.
[24] http://vbn.aau.dk/files/236150948/vtcFall2016.pdf.
[25] Electromagnetic compatibility and Radio spectrum Matters (ERM); Short Range Devices (SRD);
Radio equipment to be used in the 25 MHz to 1000 MHz frequency range with power levels
ranging up to 500 mW;, Part 1: Technical characteristics and test methods, May 2012. EN 300
220-1 V2.4.1..
[26] 3GPP Standards for IoT, Huawei,

http://www.3gpp.org/Information/presentations/presentations_2016/2016_11_3gpp_Standa
rds_for_IoT.pdf.
[27] LoRaWAN Specification, https://www.lora-alliance.org/lorawan-for-developers.
[28] Link budget calculation for 3GPP Cat-M1 is based on different assumptions, Source:
https://www.sierrawireless.com/resources/white-paper/coverage-analysis-lte-m-cat-m1.
[29] LoRaWAN™ Specification v1.0.3 - https://lora-alliance.org/resource-hub/lorawantm-

specification-v103.
[30] Actility webinar slides: Designing a LoRaWAN Network for Dense Deployment-
https://www.slideshare.net/Actility/designing-lorawan-for-dense-iot-deployments-webinar.
[31] Actility webinar replay: Designing a LoRaWAN Network for Dense Deployment-
https://www.youtube.com/watch?v=xQOZWUQdvf0.
[32] Actility webinar slides: Industrial IoT - Transforming businesses today with LoRaWAN,
https://www.slideshare.net/Actility/actility-and-factory-systemes-explain-how-iot-is-
transforming-industry
[33] Actility webinar replay: Industrial IoT - Transforming businesses today with LoRaWAN,
https://www.youtube.com/watch?v=pRoEbWjffBA
[34] Actility webinar slides: LoRaWAN Roaming Webinar,

https://www.slideshare.net/Actility/lorawan-roaming
[35] Actility webinar Replay: LoRaWAN Roaming webinar,

https://www.youtube.com/watch?v=tWP6VV1CKEg
44
[36] Actility Whitepaper: How to build a multi-technology scalable IoT connectivity Platform,
https://www.slideshare.net/Actility/whitepaper-how-to-build-a-mutiltechnology-scalable-iot-
connectivity-platform
45
11 ABOUT AUTHORS
Dr. Rohit received B.Tech at the IIT, Roorkee in 2002 and the M.Sc. in 2003
from Nanyang Technological University in Electronics and Communications.
He received his Ph.D in 2009 from the University of Washington, Seattle in
Electrical Engineering in cross layer design of wireless networks(cellular +
WiFi). He has worked in National Instruments, EURECOM,
STMicroelectronics, Ericsson, CEA-LETI in several roles related to RnD project
management on various topics in wireless communication related to LTE/5G.
He currently works in Actility as Senior wireless product manager and
manages both LTE and Geolocation related products in Actility.
LinkedIn: https://fr.linkedin.com/in/rohit-gupta-2b51503a
Olivier is a recognized telecom and technology expert. He founded

NetCentrex, a leading provider of VoIP infrastructure for service providers,
then became CTO of Comverse after the acquisition of NetCentrex in 2006.
Olivier is a recognized thought leader in Telecoms and Energy markets. He is
the author of several books on networking technology, VoIP, M2M, Internet
of Things(IoT) and the Smart Grid. Olivier graduated from Ecole
Polytechnique. Olivier founded Actility, IoT solution provider, in 2010. Via its
ThingPark Wireless platform, Actility uses the Lora technology to enable
LPWA IoT networks for applications such as Smart Cities.
LinkedIn: https://fr.linkedin.com/in/ohersent
Pierre Dufour received an Engineer's degree (Electrical Engineering) from

INSA, Lyon in 2007. He has more than 10 years of experience in the telecom
industry as RF Engineer. He worked for Bouygues Telecom during 7 years,
holding different positions (RAN technical engineer in the NOC, PM) and has
managed the roll-out of indoor cellular networks for high-value venues
(stadium, airports, conference center, high-rise office buildings and events).
From 2013 to 2017, he worked for Paris Airports as RF Engineer where he
designed various wireless networks (WiFi, TETRA, GSM, VHF, DAS) in complex
and highly secure environments. He currently works for Actility since June
2017 where he's in charge of RF related questions (RFP and pre-sales, radio
planning, good practices definition, code review and validation for RF
features, on-site troubleshooting).
LinkedIn: https://fr.linkedin.com/in/pierre-dufour-a547774
46
Ramez Soss received an Electronics & Telecommunication Engineering
degree from Cairo University in 2005 (distinction with honors). He has 10
years of experience working at Alcatel-Lucent (2005-2015), working on 3GPP
technologies GSM/GPRS/EGPRS, UMTS/HSPA, LTE/LTE-A as well as IEEE
802.11 WiFi. He occupied the post of Radio Engineer from 2005 to 2007, then
Network Planning and Optimization SME from 2007 to 2011 where he was in
charge of Technology Introduction and Support of new BSS products to major
Tier-1 Network Operators (Orange, SFR, Deutsche Telekom, CMCC…). From
2011 to 2015, Ramez occupied the post of LTE/LTE-A Senior RF Design
Engineer, developing Network Planning Tools for air-interface coverage and
capacity dimensioning.
He moved to Actility in 2015 as a Senior RF Engineer, focusing on LoRaWAN

technology. From 2017, in addition to his role as Director of the Radio & Tools
Competence Center, he is also ThingPark Wireless Product Manager.
LinkedIn: https://fr.linkedin.com/in/ramez-soss-a9692718
Bill VerSteeg is the founder of JumpStartIoT, where he is a consultant to the

IoT industry. He specializes in driving emerging networking technologies into
the market. He is currently working with a North American cable company to
bring up a LoRaWAN. Prior to founding JumpStartIoT, Mr. VerSteeg led the
IoT engineering team Comcast’s machineQ group. Prior to that, Mr. VerSteeg
was a Distinguished Engineer at Cisco Systems and Scientific Atlanta. He cut
his teeth in the networking industry when he wrote the TCP/IP stack for the
first digital Set Top Boxes in the 90s. He was also the Chief Architect of IPTV
for Cisco. Mr. VerSteeg holds 60+ patents, mostly in how to optimize MSO
networks to carry new types of data (like video or IoT). These patents cover
IoT network optimizations, IP network design, acquisition of multicast data
streams on several receivers, Forward Error Correction schemes, network
function virtualization, video processing, fast channel change, hybrid
unicast/multicast data delivery, and managing network buffers to reduce
delay. Mr. VerSteeg received a BSEE from the Georgia Institute of Technology
and has been an active contributor to IETF and LoRaWAN Alliance standards.
Linkedin: https://www.linkedin.com/in/billversteeg/
47
48

Designing LoRaWAN Network For Dense IoT

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Designing LoRaWAN Network For Dense IoT

Uploaded by

Copyright:

Available Formats

Designing LoRaWAN Network for Dense IoT

Pierre DUFOUR, Rohit GUPTA, Ramez SOSS, Olivier HERSENT (Actility)

William VERSTEEG (JumpStartIoT.com)

Figure 1. LoRaWAN Overview (source: Actility) .............................................................................. 8

1. Careful network planning (including an efficient degree of gateway macro-diversity)

Figure 1. LoRaWAN Overview (source: Actility)

Figure 2. LoRaWAN Architecture (source: LoRa Alliance)

2.2 LoRaWAN Device Classes

Battery Powered – Class A:

Low Latency – Class B:

Asynchronous communication, Star topology with single

2. Private/Enterprise Network: In this model, enterprise customers typically setup LoRaWAN

LoRaWAN enables Public-Private deployment that allows

3.1 Regulatory Constraints

This configuration allows to use 16 channels as shown in figure 5.

1. Carrier Frequency (CF),

Carrier Frequency (CF)

Transmission Power (TP)

Spreading Factor (SF)

Coding Rate (CR)

3.3 LoRaWAN packet structure

Figure 6. LoRaWAN packet structure (source [6])

PHYPayload: PHY Payload Structure

MACPayload: MAC Payload Structure

FHDR: Frame Header Structure

Figure 7. LoRaWAN packet structure (source: [14])

Symbol Preamble UL Payload + Header Total UL

LoRa SF7 / 125KHz 1.02 12.54 59.39 71.94

LoRa SF8 / 125KHz 2.05 25.09 108.54 133.63

LoRa SF9 / 125KHz 4.10 50.18 196.61 246.78

LoRa SF10 / 125KHz 8.19 100.35 352.26 452.61

LoRa SF11 / 125KHz 16.38 200.70 786.43 987.14

LoRa SF12 / 125KHz 32.77 401.41 1409.02 1810.43

Figure 8. Typical values of airtime for a 20 bytes payload and different SF

4.1 Gateway sensitivity

The sensitivity of a radio receiver at room temperature is given by:

𝑆 = −174 + 10 × 𝑙𝑜𝑔(𝐵𝑊) + 𝑁𝐹 + 𝑆𝑁𝑅 (1)

Spreading Factor Spreading Factor LoRa Demodulator

(RegModemConfig2) (Chips/Symbol) SNR

𝐸𝑆𝑃 = 𝑅𝑆𝑆𝐼 − 10 × 𝑙𝑜𝑔(1 + 10(−𝑆𝑁𝑅/10) ) (2)

𝐸𝑆𝑃 > RXSGW, SF (3)

4.2 Link budget and propagation model

𝐸𝐼𝑅𝑃𝐸 = 𝑃𝑇𝑋 + 𝐺𝐸 − 𝐿𝐸 (4)

Then we calculate the « Maximum Allowable Path Loss » in uplink, as follows:

MAPLUL = (EIRPE − RXSGW, SF) + (GGW − LGW) − (MShadowing + MRayeleigh )

− NoiseDL − Mindoor (5)

𝑀𝐴𝑃𝐿𝑈𝐿 = 𝐾1 + 𝐾2 × 𝑙𝑜𝑔(𝑅𝑈𝐿 ) (6)

Figure 11. Hata-Okumura model parameters (source: Actiltiy)

As illustrated below, the ISD calculation depends on the network’s topology:

• If omni-directional antennas are used, then:

𝐼𝑆𝐷𝑜𝑚𝑛𝑖 = 𝑅𝑈𝐿 × √3 (8)

• If directional antennas are used, then:

5.1 Packet error rate (PER)

𝑃𝐸𝑅𝑡𝑎𝑟𝑔𝑒𝑡 = 𝑃𝐸𝑅𝑐𝑜𝑙𝑙𝑖𝑠𝑖𝑜𝑛𝑠 + 𝑃𝐸𝑅𝑟𝑎𝑑𝑖𝑜 (10)

Hence, for each simulation we compute:

𝑃𝐸𝑅𝑆𝑖𝑚𝑢𝑙𝑎𝑡𝑖𝑜𝑛 = 𝑚𝑎𝑥(𝑃𝐸𝑅𝑆𝐹,𝑁𝑐𝑒𝑙𝑙 ) ∀ 𝑆𝐹 ∈ {𝑆𝐹7 , . . 𝑆𝐹𝑚𝑎𝑥 } (12)

The simulation is stopped when:

𝑃𝐸𝑅𝑆𝑖𝑚𝑢𝑙𝑎𝑡𝑖𝑜𝑛 ≥ 𝑃𝐸𝑅𝑡𝑎𝑟𝑔𝑒𝑡 (14)

And the number of devices satisfying the target is then 𝑁𝑐𝑒𝑙𝑙 .

5.2 Fading simulation

The fast-fading margin is calculated as follows:

• The CDF of a Rayleigh distribution is:

Figure 14. Rayleigh distribution CDF curve vs dB margin (source: Actility)