ns3-LoRa-NTN Simulation Module

• The module integrates ns3-LoRa and ns3-NTN to enable full-stack, end-to-end simulation of LoRaWAN satellite communications with detailed channel and PHY modeling.
• It adopts LoRaWAN Class A and leverages 3GPP TR 38.811 NTN models to analyze propagation, SF selection, and collision-limited performance.
• Simulation results highlight altitude and beamwidth impacts on coverage and PRR, guiding future improvements like multi-satellite support and adaptive SF strategies.

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 (Traspadini et al., 2 Sep 2025).

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 (Traspadini et al., 2 Sep 2025).

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 (Traspadini et al., 2 Sep 2025).

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 (Sandri et al., 2023).

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 (Traspadini et al., 2 Sep 2025).

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 (Traspadini et al., 2 Sep 2025).

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 $\rightarrow$0 (Traspadini et al., 2 Sep 2025).

The received power is modeled as

$\rightarrow$1

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 $\rightarrow$2 above gateway sensitivity (Traspadini et al., 2 Sep 2025).

The footprint geometry is specified analytically. For a satellite at altitude $\rightarrow$3 with antenna beamwidth $\rightarrow$4, the coverage radius and area are

$\rightarrow$5

$\rightarrow$6

Given end-device density $\rightarrow$7, the number of covered devices is

$\rightarrow$8

The communication distance is the slant range

$\rightarrow$9

with $$PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,$$0 and $$PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,$$1 the elevation angle (Traspadini et al., 2 Sep 2025).

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 (Traspadini et al., 2 Sep 2025).

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 (Traspadini et al., 2 Sep 2025).

The LoRa PHY configuration in the reported study uses bandwidth $$PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,$$2 kHz, carrier frequency $$PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,$$3 MHz, PHY payload size $$PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,$$4 bytes, explicit header mode, and code rate equal to 2. For $$PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,$$5 kHz, the chirp rate is

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

with $$PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,$$7 (Traspadini et al., 2 Sep 2025).

The module uses the following spreading-factor mapping.

SF / DR	Data rate	Sensitivity / Time on Air
SF7 / DR5	5.470 kbit/s	$$PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,$$8 dBm / 74 ms
SF8 / DR4	3.125 kbit/s	$$PL = 20\log_{10}\left(\frac{4\pi d}{\lambda}\right) + L_{a} + CL + SF,$$9 dBm / 136 ms
SF9 / DR3	1.760 kbit/s	$d$0 dBm / 247 ms
SF10 / DR2	0.980 kbit/s	$d$1 dBm / 493 ms
SF11 / DR1	0.440 kbit/s	$d$2 dBm / 888 ms
SF12 / DR0	0.250 kbit/s	$d$3 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 (Traspadini et al., 2 Sep 2025).

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 (Traspadini et al., 2 Sep 2025).

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 $d$4 EDs/km$d$5. Satellite altitude is swept over $d$6 km, beamwidth over $d$7, and total antenna gain over 5 dBi and 10 dBi. Other fixed parameters are $d$8 dBm, $d$9 kHz, $\lambda$0 MHz, $\lambda$1 bytes, and $\lambda$2 km. Traffic is periodic, with each end device sending one 32-byte uplink packet every $\lambda$3 seconds, where $\lambda$4 s (Traspadini et al., 2 Sep 2025).

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 $\lambda$5, $\lambda$6, and $\lambda$7, 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 (Traspadini et al., 2 Sep 2025).

For the 5 dBi total-gain case with $\lambda$8 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 $\lambda$9 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 $L_a$0, 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 $L_a$1, 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 (Traspadini et al., 2 Sep 2025).

For the 10 dBi total-gain case with $L_a$2 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 $L_a$3 as altitude increases from 200 to 700 km; for $L_a$4, they are 0.989, 0.960, 0.929, 0.793, 0.659, and 0.405 (Traspadini et al., 2 Sep 2025).

Traffic intensity exposes the collision-limited nature of the system. With 10 dBi total gain and $L_a$5, PRR at 200 km changes only slightly, from about 0.993 at $L_a$6 s to 0.966 at $L_a$7 s. At 700 km, however, PRR drops from about 0.675 at $L_a$8 s to about 0.106 at $L_a$9 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 (Traspadini et al., 2 Sep 2025).

A representative example clarifies the scale of this effect. With $CL$0 s, the source rate per end device is 4 bps. At 700 km and $CL$1, approximately 120 end devices are covered, giving a total source rate around 480 bps; when $CL$2 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 (Traspadini et al., 2 Sep 2025).

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 (Khan et al., 2020).

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 (Sandri et al., 2023).

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 (Favero et al., 2024). “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 (Lin et al., 26 Aug 2025).

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 (Du, 2018).

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 (Traspadini et al., 2 Sep 2025).

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 (Traspadini et al., 2 Sep 2025).

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 (Traspadini et al., 2 Sep 2025).

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 (Vennam et al., 3 Oct 2025).