---
title: ns3-LoRa-NTN Simulation Module
url: https://www.emergentmind.com/topics/ns3-lora-ntn-simulation-module
type: topic
---

# ns3-LoRa-NTN Simulation Module

The **ns3-LoRa-NTN simulation module** is an ns-3 extension for studying LoRa-based Internet of Things connectivity over non-terrestrial links, specifically the case in which ground LoRa end devices communicate directly with a Low Earth Orbit satellite acting as a LoRa gateway. It was introduced to fill the gap between terrestrial LoRa/LoRaWAN simulation and ns-3 support for 3GPP non-terrestrial channels, by integrating and extending **ns3-LoRa** and **ns3-NTN** into a single framework for **full-stack end-to-end simulation of satellite communication in LoRa networks** [2509.02811].

## 1. Module scope and architectural position

ns3-LoRa-NTN is described as an **integration and extension** of two open-source modules: **ns3-LoRa** and **ns3-NTN**. From ns3-LoRa it inherits the **LoRa PHY/MAC stack**, including **LoRaWAN Class A end devices**, asynchronous uplink transmissions, the opening of **up to two receive windows** after each uplink, interference handling, duty-cycle configurability, and LoRa-specific packet success logic based on interference rejection. From ns3-NTN it inherits the **3GPP TR 38.811 NTN channel model**, atmospheric and scintillation effects, antenna models, Earth-curvature-aware coordinates, and timing support for large propagation delays [2509.02811].

The modeled chain is not a generic satellite network stack. The scenario is explicitly **ED \(\rightarrow\) satellite LoRa gateway \(\rightarrow\) network server**, with the gateway forwarding collected data to the network server “for storage or processing.” A distinct ground station is not explicitly modeled, and the description does not introduce a rich satellite core network, feeder-link chain, or EPC/5GC-style entities. The implemented focus is therefore the **access link and end-to-end LoRaWAN behavior** in an NTN setting rather than a complete bent-pipe or regenerative satellite architecture [2509.02811].

The underlying ns3-NTN substrate is itself an ns-3 implementation of the 3GPP NTN channel and antenna models from **TR 38.811**, with additional support for atmospheric absorption, scintillation, and geocentric positioning. That substrate introduces reusable components such as `GeographicPositions`, `GeocentricConstantPositionMobilityModel`, and `CircularApertureAntennaModel`, which clarify the geometric and antenna abstractions available beneath higher-layer protocols [2305.05544].

A practical limitation is that ns3-LoRa-NTN is documented at the behavior level rather than through a class-by-class software architecture. The available description states what the module functionally combines, but it does not provide a UML-style inventory of new C++ classes, helper objects, or public APIs [2509.02811].

## 2. Access-link model, geometry, and NTN-specific channel assumptions

The access link between each end device and the satellite gateway follows the **3GPP TR 38.811** model. The path loss is given as

$$
PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,
$$

where \(d\) is the propagation distance, \(\lambda\) is the wavelength, \(L_a\) is atmospheric loss, \(CL\) is clutter loss, and \(SF\) in this formula denotes **shadow fading**, not the LoRa spreading factor [2509.02811].

In LOS conditions, clutter loss is described as negligible and set to **0 dB**. Shadowing is modeled as a **zero-mean log-normal random variable** with variance \(\sigma_s^2\), where \(\sigma_s\) depends on environment and elevation. For the sub-GHz LoRa case, the module retains **ionospheric scintillation** as the significant atmospheric effect. The reproduced atmospheric-loss expression in the available text is malformed and truncated, so its exact equation is not technically reliable as printed; what is explicit is the use of the **Gigahertz Scintillation Model** and the statement that it is valid only for geographical regions with **maximum latitude \(20^\circ\)** [2509.02811].

The received power is modeled as

$$
P_{rx} = P_{tx} + G_{tx} + G_{rx} - PL.
$$

This quantity is central to the module’s adaptation logic because each end device is assigned, at the beginning of the simulation, the **lowest possible spreading factor** that still guarantees \(P_{rx}\) above gateway sensitivity [2509.02811].

The footprint geometry is specified analytically. For a satellite at altitude \(h\) with antenna beamwidth \(\theta\), the coverage radius and area are

$$
R_c = \tan \left( {\theta}/{2} \right) \cdot h,
$$

$$
A_c = R_c^2 \pi.
$$

Given end-device density \(\rho_d\), the number of covered devices is

$$
N = \rho_d A_c.
$$

The communication distance is the **slant range**

$$
d = \sqrt{R^2_E \sin^2(\alpha) + h^2 + 2 h R_E} - R_E \sin(\alpha),
$$

with \(R_E = 6371~\text{km}\) and \(\alpha\) the elevation angle [2509.02811].

These expressions make the modeled NTN effect explicit: different positions inside the footprint imply different slant ranges, which then change path loss, feasible spreading factor, and airtime. The inherited ns3-NTN machinery additionally provides Earth-curvature-aware geometry, non-negligible propagation delay, and Timing Advance support. However, the evaluated ns3-LoRa-NTN scenario remains a **quasi-static single-satellite access study** rather than a full orbital-dynamics or handover study; the reported evaluation varies satellite altitude but does not present explicit orbital motion, satellite passes, or Doppler-focused analysis [2509.02811].

## 3. LoRaWAN behavior, PHY parameterization, and spreading-factor selection

The module adopts **LoRaWAN Class A** behavior from ns3-LoRa. End devices transmit **asynchronously**, and after each uplink they open **at most two reception windows** while waiting for any command or data returned by the network server. In the evaluated scenario, the gateway mainly **collects uplink traffic from the end devices and forwards it to the network server**, so the use of the module is decisively **uplink-centric** [2509.02811].

The LoRa PHY configuration in the reported study uses **bandwidth \(B = 125\) kHz**, **carrier frequency \(f_c = 868\) MHz**, **PHY payload size \(p_s = 32\) bytes**, **explicit header mode**, and **code rate equal to 2**. For \(B=125\) kHz, the chirp rate is

$$
k = {B}/2^\text{SF},
$$

with \(\text{SF} \in \{7,\ldots,12\}\) [2509.02811].

The module uses the following spreading-factor mapping.

| SF / DR | Data rate | Sensitivity / Time on Air |
|---|---:|---:|
| SF7 / DR5 | 5.470 kbit/s | \(-130.0\) dBm / 74 ms |
| SF8 / DR4 | 3.125 kbit/s | \(-132.5\) dBm / 136 ms |
| SF9 / DR3 | 1.760 kbit/s | \(-135.0\) dBm / 247 ms |
| SF10 / DR2 | 0.980 kbit/s | \(-137.5\) dBm / 493 ms |
| SF11 / DR1 | 0.440 kbit/s | \(-140.0\) dBm / 888 ms |
| SF12 / DR0 | 0.250 kbit/s | \(-142.5\) dBm / 1777 ms |

The interference model follows the usual LoRa abstraction that spreading factors are **pseudo-orthogonal**. Transmissions using different SFs on the same channel may be decoded simultaneously if the desired signal is sufficiently stronger, described as “generally about **6 dB higher**” than interfering signals. In ns3-LoRa terms, a packet is delivered only if the **equalized interfering power** remains below the **channel rejection parameter** from the cited Goursaud model [2509.02811].

This configuration makes the SF-selection rule structurally important. A sensitivity-based assignment minimizes link-budget risk, but it can also concentrate many terminals on the same SF. The reported study identifies that concentration, especially on **SF12** at larger distances, as a principal cause of collision-limited performance rather than a purely propagation-limited failure mode [2509.02811].

## 4. Simulation methodology and reported operating regimes

The reported ns3-LoRa-NTN evaluation uses a **rural scenario** in which end devices are **uniformly distributed on the Earth’s surface** within the beam footprint. The fixed density is \(\rho_d = 0.01\) EDs/km\(^2\). Satellite altitude is swept over \(h \in [200, \dots, 700]\) km, beamwidth over \(\theta \in \{5^\circ, 10^\circ, 15^\circ\}\), and total antenna gain over **5 dBi** and **10 dBi**. Other fixed parameters are **\(P_{tx} = 14\) dBm**, **\(B = 125\) kHz**, **\(f_c = 868\) MHz**, **\(p_s = 32\) bytes**, and **\(R_E = 6371\) km**. Traffic is periodic, with each end device sending one **32-byte uplink packet every \(p\) seconds**, where \(p \in \{60, 30, 10\}\) s [2509.02811].

The explicit metrics are: **number of covered end devices**, **coverage radius**, **data-rate distribution**, **average data rate**, and **Packet Reception Ratio (PRR)**. At **200 km**, the coverage radius is about **8.7 km**, **17.45 km**, and **26.18 km** for beamwidths \(5^\circ\), \(10^\circ\), and \(15^\circ\), respectively; at **700 km**, the corresponding radii are about **30.54 km**, **61.09 km**, and **91.63 km**. The covered device counts rise from about **2.4**, **9.6**, and **21.8** at 200 km to about **29.3**, **117.8**, and **266.8** at 700 km [2509.02811].

For the **5 dBi** total-gain case with **\(p=60\) s**, nearly all end devices use **DR4 / SF8** at **200 km**, giving an average rate of about **3 kbps**. As altitude increases, devices shift toward lower DRs and higher SFs; for **\(h>500\) km**, most use **DR0 / SF12**, and at **700 km** the average data rate falls to around **0.25–0.30 kbps**. PRR then deteriorates strongly with altitude and beamwidth. For \(\theta=5^\circ\), PRR remains **1** at 200–300 km, then falls to **0.969** at 400 km, **0.930** at 500 km, **0.857** at 600 km, and **0.691** at 700 km. For \(\theta=15^\circ\), the corresponding high-altitude collapse is much steeper: **0.7548** at 400 km, **0.5041** at 500 km, **0.3106** at 600 km, and **0.0245** at 700 km [2509.02811].

For the **10 dBi** total-gain case with **\(p=60\) s**, the operating point shifts materially. At **200 km**, all end devices use **DR5 / SF7**, yielding **5.47 kbps** average data rate. At **500 km**, most devices use **DR3 / SF9**, and at **600 km**, **DR2 / SF10** becomes most common. Example average rates are about **5.47 kbps** at 200 km, **3.69–3.75 kbps** at 300 km, **2.40–2.43 kbps** at 400 km, **1.69–1.71 kbps** at 500 km, **1.16–1.18 kbps** at 600 km, and about **0.95 kbps** at 700 km. Example PRRs are **1**, **1**, **0.992**, **0.967**, **0.957**, and **0.915** for \(\theta=5^\circ\) as altitude increases from 200 to 700 km; for \(\theta=15^\circ\), they are **0.989**, **0.960**, **0.929**, **0.793**, **0.659**, and **0.405** [2509.02811].

Traffic intensity exposes the collision-limited nature of the system. With **10 dBi** total gain and **\(\theta=10^\circ\)**, PRR at **200 km** changes only slightly, from about **0.993** at \(p=60\) s to **0.966** at \(p=10\) s. At **700 km**, however, PRR drops from about **0.675** at \(p=60\) s to about **0.106** at \(p=10\) s. The study attributes this to two coupled mechanisms: higher altitude increases the number of devices inside the footprint, and it also drives devices toward larger SFs with longer airtimes, enlarging the vulnerable collision window under ALOHA-like access [2509.02811].

A representative example clarifies the scale of this effect. With \(p=60\) s, the source rate per end device is **4 bps**. At **700 km** and \(\theta=10^\circ\), approximately **120 end devices** are covered, giving a total source rate around **480 bps**; when \(p=10\) s, the total source rate rises to about **3 kbps**, which exceeds the average sustainable LoRa data rate in that setting and causes sharp PRR degradation [2509.02811].

## 5. Relation to terrestrial ns-3 LoRaWAN and adjacent non-terrestrial simulators

ns3-LoRa-NTN is best understood as a specialization built above two previously separate lines of work. On the terrestrial side, **“Experimental Evaluation of LoRaWAN in NS-3”** documents an existing ns-3 LoRaWAN environment for **Class A** devices, with one gateway, one network server, confirmed and unconfirmed uplink, duty-cycle constraints, and capture-based collision handling. That work is explicitly a **terrestrial Class A LoRaWAN baseline**, not an NTN framework, but it establishes the LoRaWAN event logic that ns3-LoRa-NTN reuses through ns3-LoRa [2009.09503].

On the channel side, **“Implementation of a Channel Model for Non-Terrestrial Networks in ns-3”** provides the ns3-NTN basis for 3GPP channel conditions, atmospheric and scintillation loss, antenna modeling, and geocentric coordinate handling. ns3-LoRa-NTN does not replace that substrate; it repurposes it beneath a LoRaWAN access network [2305.05544].

Two neighboring strands are related but distinct. **“Performance Evaluation of IoT LoRa Networks on Mars Through ns-3 Simulations”** shows how the Padova ns-3 LoRaWAN stack can be extended with a custom propagation class, `MarsPropagationLossModel`, for a non-Earth environment. This is useful as a channel-extension pattern, but its scenario is a **surface LoRaWAN star topology on Mars**, not LoRa over satellites or 3GPP NTN access [2412.19549]. **“Connectivity Analysis of LoRaWAN-Based Non-Terrestrial Networks for Subterranean mMTC”** studies underground-to-UAV/HAP/LEO links with LoRa and LR-FHSS, but it uses a **MATLAB-based Monte Carlo simulator**, not ns-3, and omits a full LoRaWAN MAC state machine [2508.19350].

A common misconception is to treat any earlier LoRa simulation study as direct evidence for an ns3-LoRa-NTN module. The provided material for **“Optimizing Multi-hop Mechanism for the Long Range Wide Area Network”** does not support that use: it contains **no actual paper text**, and therefore provides **no extractable information** about ns-3, LoRaWAN modeling, or NTN adaptation [1811.05386].

## 6. Limitations, reproducibility, and likely extensions

The reported ns3-LoRa-NTN study is explicit about several limitations. The evaluated topology uses **a single LEO satellite gateway**, the scenario is **rural** and mainly **LOS**, clutter loss in LOS is effectively **0 dB**, the implementation focuses on **sub-GHz LoRa** at **868 MHz**, and the only atmospheric impairment retained in practice is **ionospheric scintillation**. The present SF-assignment rule is a simple **sensitivity-based** heuristic. The work does **not** yet include **multi-satellite**, **multi-layer NTN**, or **realistic satellite mobility**, and it does **not** present a dedicated **validation or calibration section** against measurements or another simulator [2509.02811].

Reproducibility is partial. The parent modules **ns3-LoRa** and **ns3-NTN** are identified as open source, and repository links are provided for both. ns3-LoRa-NTN itself is described as a **new open-source module**, but the available text does **not** include a direct public repository URL, release instructions, commit hash, or replication package. This suggests that the simulation setup is reproducible in principle from the parameter tables and module lineage, but not fully packaged by the article text alone [2509.02811].

The study’s principal design conclusion is that direct LoRa ground-to-LEO communication is feasible, but system performance becomes **collision-limited** when many end devices converge on the same spreading factor over large footprints. The authors therefore identify **improved SF selection**, **multi-satellite support**, **multi-layer NTN**, and **realistic mobility** as natural next steps [2509.02811].

Subsequent research directions reinforce that interpretation. **“FSMA: Scalable and Reliable LoRa for Non-Terrestrial Networks with Mobile Gateways”** examines mobile-gateway NTN settings using a custom **Satellite IoT Simulator** and proposes a gateway-controlled FreeChirp access mechanism; it reports gains in throughput, PRR, and energy efficiency, but it is not an ns-3 module. A plausible implication is that future ns3-LoRa-NTN development will need to address not only channel realism and geometry, but also **NTN-specific MAC design** for large footprints, moving gateways, and collision-heavy uplink operation [2510.02800].

Source: https://www.emergentmind.com/topics/ns3-lora-ntn-simulation-module