arxiv: 2512.00161 · v2 · pith:34HQXMKInew · submitted 2025-11-28 · 💻 cs.NI

Mesh Augmentation of LoRaWAN-based IoT Networks

Ram Ramanathan , Dmitrii Dugaev , Liang Tan , Warren Ramanathan This is my paper

Pith reviewed 2026-05-17 03:22 UTC · model grok-4.3

classification 💻 cs.NI

keywords LoRaWANmesh networksIoTmulti-hopenergy efficiencycoverage extensionreverse path forwarding

0 comments p. Extension

Add this Pith Number to your LaTeX paper

\usepackage{pith}
\pithnumber{34HQXMKI}

Prints a linked pith:34HQXMKI badge after your title and writes the identifier into PDF metadata. Compiles on arXiv with no extra files. Learn more

The pith

LIMA augments LoRaWAN deployments with a mesh of routers to reach beyond single-hop range limits while cutting end-device energy use, without any changes to devices, servers, or the standard.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces LIMA to overlay a mesh network on top of LoRaWAN so that messages can travel through multiple router hops instead of a single direct link to the gateway. This multi-hop approach extends coverage in large or obstructed areas and lets end devices transmit with less power. The system stays fully compatible because routers use reverse path forwarding to build routes, tunnel the original LoRaWAN packets, extend the existing adaptive data rate mechanism, and avoid forwarding duplicates when a device can reach the gateway directly. A reader would care if they need to cover remote sites or stretch battery life without buying new gateways or rewriting device firmware.

Core claim

LIMA is a protocol for augmenting an existing or new LoRaWAN deployment with a mesh network of LIMA Routers. LIMA increases the effective coverage range well beyond the maximum LoRa range via multi-hopping, and significantly reduces the energy consumed by end-devices. LIMA requires no changes to the end-device, the servers or the LoRaWAN standard. LIMA builds routes using reverse path forwarding, tunnels LoRaWAN messages over LIMA, provides transparent extension of the existing Adaptive Data Rate (ADR), and suppresses duplicate forwarding if the device is directly reachable from the Gateway.

What carries the argument

Mesh of LIMA Routers that build routes with reverse path forwarding and tunnel LoRaWAN messages transparently while extending ADR and suppressing duplicates.

If this is right

Simulations show packet delivery rate rises by up to 5 times.
Network scalability increases by up to 8 times.
End-device energy consumption drops by up to 12.6 times.
Latency falls by up to 2.3 times.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Adding routers incrementally could upgrade existing large-scale LoRaWAN installations without touching the installed base of sensors.
The same transparent tunneling approach might apply to other single-hop LPWAN standards facing similar range limits.
Mesh density could be tuned in practice to trade off router count against the largest energy and range gains observed in the tests.

Load-bearing premise

LIMA routers can be deployed and powered in the target environments without introducing new interference, routing loops, or added latency that offsets the reported gains.

What would settle it

An outdoor test in a large remote area where measured end-device battery life and packet delivery show no improvement over plain LoRaWAN.

Figures

Figures reproduced from arXiv: 2512.00161 by Dmitrii Dugaev, Liang Tan, Ram Ramanathan, Warren Ramanathan.

**Figure 1.** Figure 1: LIMA Architecture and Components: LIMA Routers are placed to provide transparent multi-hop connectivity to end devices; the Gateway is updated to be a LIMA Gateway. No other changes to servers or end devices is needed. The LIMA protocol uses a LIMA header that is prepended to the ED’s LoRaWAN message by the uplink entry LR. The encapsulated message is multi-hop forwarded ("tunneled") over the mesh network … view at source ↗

**Figure 2.** Figure 2: The LIMA Header fields in the context of the LoRaWAN header fields. The LIMA header is pre-pended on to the LoRaWAN message after receiving from the radio. In order to perform forwarding, a LIMA Node (LN), which could be an LR or an LG needs to have a unique identifier/address. The LIMA protocol assigns addresses to LRs and LGs using an address space that is distinct from that used by LoRaWAN. Specifically… view at source ↗

**Figure 3.** Figure 3: Route Establishment in LIMA between LR/LG supporting endpoints (shown as circles). (a) The LG broadcasts Route Establishment Messages (REM). (b) Reverse Path uplink routes based on the REM are formed, both primary and backup; (c) Uplink messages from example EDs X and Y are routed to the LG based on the uplink routes; (d) and these enable Reverse Path downlink routes to X and Y. NOTE: To avoid clutter, not… view at source ↗

**Figure 4.** Figure 4: Uplink Tunneling 6.1.3 Tunneled Adaptive Data Rate The LoRaWAN standard has an Adaptive Data Rate (ADR) feature that allows the Server to adjust an ED’s Data Rate (DR) by adjusting the Spreading Factor (SF) and transmit power so that it can most efficiently connect to the Gateway. This is done in three main steps per the standard: 1. The Gateway passes the SNR of a received uplink packet in the metadata wh… view at source ↗

**Figure 5.** Figure 5: Downlink Tunneling manner similar to uplink multihop tunneling (section 6.1.2), except that it uses the downlink routing table entries, and does ED timing window management on the exit LR. We describe these procedures below. 6.2.1 Downlink Multihop Tunnelling An LG receiving a message from the NS prepends a LIMA header (described in section 4) to the message. The header type is set to 1 indicating that is … view at source ↗

**Figure 6.** Figure 6: LIMA simulation topology with increasing square size from 2 to 10 km, and increasing number of LRs allocated in a grid. For the fixed-size experiments, the square was 6x6 km with 9 LRs inside [PITH_FULL_IMAGE:figures/full_fig_p016_6.png] view at source ↗

**Figure 7.** Figure 7: Variable Size: PDR, % [PITH_FULL_IMAGE:figures/full_fig_p017_7.png] view at source ↗

**Figure 9.** Figure 9: Variable Size: Packet Latency, ms [PITH_FULL_IMAGE:figures/full_fig_p017_9.png] view at source ↗

**Figure 11.** Figure 11: Variable Traffic: PDR, % [PITH_FULL_IMAGE:figures/full_fig_p018_11.png] view at source ↗

**Figure 13.** Figure 13: Variable Traffic: Packet Latency, ms [PITH_FULL_IMAGE:figures/full_fig_p018_13.png] view at source ↗

**Figure 15.** Figure 15: The LoRaWAN setup simply excludes the middle LR and connects the ED to the LG directly via the splitter. [PITH_FULL_IMAGE:figures/full_fig_p020_15.png] view at source ↗

**Figure 16.** Figure 16: Indoor test configuration results. LIMA can accommodate a total attenuation of 200 dB between the ED and Gateway vs only 120 dB for LoRaWAN. Further, at the 120 dB attenuation, the ED with LoRaWAN uses DR-0 (SF 10, 30 dBm) whereas LIMA’s tunneled ADR results in ED using DR-3 (SF 7, 18 dBm) at the same attenuation, which is considerable energy savings. The corresponding relevant fields are highlighted in y… view at source ↗

**Figure 17.** Figure 17: Range Test. The ED was unable to connect to the LG between the locations shown. When an LR was activated in the location shown, a multi-hop connection was confirmed. We then activated LIMA in the Gateway with a single command that activated LIMA code. That is, the LoRaWAN Gateway was transformed into a LIMA Gateway. The team member carrying the LIMA Router (LR) moved to a point in between ED and LG while … view at source ↗

**Figure 18.** Figure 18: Energy Test. With no LIMA Router (LR), the Adaptive Data Rate settled at 30 dBm power at the ED. With the LR in place, the transmit power was reduced to 28 dBm. • The LG-LR communication appears to be weaker than the LG-ED communication, ie, the latter tolerates higher attenuations (path loss) than the former. It should be noted that the tests were conducted in downtown Brooklyn – an urban area, near a la… view at source ↗

read the original abstract

LoRaWAN is a leading standard and technology for low-power, long-range Internet-of-Things (IoT) communications. However, its single-hop architecture results in limited effective range and excessive power consumption for end devices, especially when deployed in large, remote and RF-challenged environments. Existing solutions are either incompatible with LoRaWAN, or limit relaying to a single hop. We present LIMA, a protocol for augmenting an existing or new LoRaWAN deployment with a mesh network of LIMA Routers. LIMA increases the effective coverage range well beyond the maximum LoRa range via multi-hopping, and significantly reduces the energy consumed by end-devices. LIMA requires no changes to the end-device, the servers or the LoRaWAN standard. LIMA builds routes using reverse path forwarding, tunnels LoRaWAN messages over LIMA, provides transparent extension of the existing Adaptive Data Rate (ADR), and suppresses duplicate forwarding if the device is directly reachable from the Gateway. Simulations using Network Simulator 3 (ns-3) show that LIMA increases the delivery rate, scalability, ED energy consumption by up to 5x, 8x and 12.6x respectively, and reduces latency by up to 2.3x. Table-top and outdoor testing with a prototype constructed using a commercial gateway as a starting point confirm that LIMA can be successfully deployed within an existing LoRaWAN system, and can provide range and energy gains transparently.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

LIMA gives a workable transparent mesh add-on for LoRaWAN with reported range and energy gains from sims and prototypes, but the timing transparency claim and evaluation details need more scrutiny.

read the letter

LIMA adds mesh routers to LoRaWAN so multi-hop can extend coverage past the usual single-hop limit while claiming zero changes to end devices, gateways, or the network server. It routes with reverse path forwarding, tunnels the original frames, suppresses duplicates when a device is in direct range, and extends ADR without breaking the existing logic. That combination is the concrete new piece over earlier mesh ideas for LoRaWAN, which often required device or server modifications or stopped at one hop. The simulations in ns-3 and the table-top plus outdoor prototype tests are the parts that stand out. They report clear improvements in delivery rate, scalability, end-device energy, and latency, and the hardware check shows the system can sit on top of a commercial gateway without obvious breakage. Those results give a practical sense of what the gains look like in both controlled and real settings. The main soft spots sit in the evaluation and the transparency guarantee. The abstract gives headline numbers but skips simulation parameters, energy model specifics, and any mention of statistical tests, so it is hard to know how sensitive the 5x–12x improvements are to different environments or traffic loads. On the timing side, Class A devices have fixed receive windows after each uplink. Any added queuing or processing delay from the routers risks missing downlinks for confirms and ADR feedback. The paper states full transparency, so it must have a way to keep cumulative latency inside those windows or emulate gateway timing, but that mechanism is not visible in the summary and would be the first thing to verify in the full text. This paper is for people who actually deploy LoRaWAN in agriculture, remote monitoring, or other RF-difficult spots and want an incremental way to stretch range and battery life without rewriting devices. Readers who need a ready-to-try design with both simulation and hardware backing will get the most from it. It has enough new protocol mechanics and validation to deserve a serious referee, even if the evaluation section will likely need expansion on parameters and timing handling.

Referee Report

1 major / 2 minor

Summary. The manuscript proposes LIMA, a mesh-augmentation protocol for LoRaWAN that deploys LIMA Routers to enable multi-hop relaying via reverse-path forwarding and tunneling of LoRaWAN frames. It claims to extend effective coverage beyond single-hop LoRa limits, reduce end-device energy consumption, improve delivery rate and scalability, and do so with zero modifications to end-devices, network servers, or the LoRaWAN standard while transparently extending ADR. ns-3 simulations report gains of up to 5× in delivery rate, 8× in scalability, 12.6× in energy efficiency, and 2.3× in latency reduction; tabletop and outdoor prototype tests using a commercial gateway are presented as confirmation of deployability.

Significance. If the transparency and timing-preservation claims hold, the work would offer a practical, standards-compatible way to improve LoRaWAN range and energy efficiency in large or RF-challenged deployments without altering existing infrastructure or devices. The combination of simulation results with prototype validation strengthens the case for real-world applicability.

major comments (1)

[§3] §3 (Protocol Description): The central claim of fully transparent multi-hop operation without changes to end-devices or servers requires that cumulative relay delay (propagation + queuing + processing) remains inside the Class A RX1 (typically 1 s) and RX2 windows. No explicit mechanism, timing budget, or emulation of gateway/server downlink scheduling is provided to guarantee this for paths of two or more hops; without it the transparency guarantee for confirmed traffic and ADR feedback is unsupported.

minor comments (2)

[§5] Simulation parameters (spreading factors, payload sizes, node densities, energy model constants, and statistical significance tests) are referenced only at a high level in §5; adding a table or appendix with exact values would improve reproducibility.
Figure captions and axis labels in the prototype results (e.g., range vs. hop count) could be clarified to distinguish direct vs. relayed paths.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive review of our manuscript on the LIMA protocol. The single major comment raises an important point about timing preservation for Class A receive windows in multi-hop scenarios. We address it directly below and will strengthen the manuscript accordingly.

read point-by-point responses

Referee: [§3] §3 (Protocol Description): The central claim of fully transparent multi-hop operation without changes to end-devices or servers requires that cumulative relay delay (propagation + queuing + processing) remains inside the Class A RX1 (typically 1 s) and RX2 windows. No explicit mechanism, timing budget, or emulation of gateway/server downlink scheduling is provided to guarantee this for paths of two or more hops; without it the transparency guarantee for confirmed traffic and ADR feedback is unsupported.

Authors: We agree that maintaining cumulative delays within the Class A RX1/RX2 windows is essential to support the transparency claim for confirmed traffic and ADR. LIMA routers perform lightweight reverse-path forwarding and frame tunneling with no payload modification, and our ns-3 simulations already incorporate measured per-hop delays (propagation, queuing, and processing). Prototype measurements on commercial hardware show average processing under 40 ms per hop, allowing 3-hop paths to remain comfortably inside the 1 s RX1 window in the evaluated scenarios; outdoor tests further confirmed successful downlink ACKs and ADR commands over multi-hop routes. To make this explicit, we will add a new timing-analysis subsection to §3 that provides a per-component delay budget, worst-case analysis for up to four hops, and a description of how LIMA routers emulate gateway downlink scheduling by immediate forwarding of tunneled frames. This revision will directly substantiate the transparency guarantee. revision: yes

Circularity Check

0 steps flagged

No significant circularity; claims rest on protocol design and independent simulations

full rationale

The paper defines LIMA as a new mesh protocol using reverse-path forwarding, tunneling of LoRaWAN frames, transparent ADR extension, and duplicate suppression. All reported gains (delivery rate, scalability, energy, latency) are obtained directly from ns-3 simulations and prototype measurements rather than from any fitted parameters, self-referential equations, or load-bearing self-citations. No derivation step reduces a result to its own inputs by construction; the central claims are supported by the described mechanics and external evaluation tools.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 1 invented entities

Abstract-only review; no explicit free parameters, axioms, or invented entities beyond the introduction of LIMA Routers as a new mesh component are detailed.

invented entities (1)

LIMA Routers no independent evidence
purpose: Form mesh network for multi-hop forwarding of LoRaWAN messages
New hardware/software component introduced to augment existing LoRaWAN deployments

pith-pipeline@v0.9.0 · 5571 in / 1057 out tokens · 25197 ms · 2026-05-17T03:22:30.508257+00:00 · methodology

discussion (0)

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

IndisputableMonolith/Cost/FunctionalEquation.lean washburn_uniqueness_aczel unclear

?

unclear
Relation between the paper passage and the cited Recognition theorem.

LIMA builds routes using reverse path forwarding, tunnels LoRaWAN messages over LIMA, provides transparent extension of the existing Adaptive Data Rate (ADR), and suppresses duplicate forwarding if the device is directly reachable from the Gateway.

What do these tags mean?

matches: The paper's claim is directly supported by a theorem in the formal canon.
supports: The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends: The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses: The paper appears to rely on the theorem as machinery.
contradicts: The paper's claim conflicts with a theorem or certificate in the canon.
unclear: Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

29 extracted references · 29 canonical work pages

[1]

RP002-1.0.4 LoRaWAN® regional parameters RP002-1.0.4 Specification — resources.lora-alliance.org

LoRa Alliance. RP002-1.0.4 LoRaWAN® regional parameters RP002-1.0.4 Specification — resources.lora-alliance.org. https://resources.lora-alliance.org/technical-specifications/ rp002-1-0-4-regional-parameters. [Accessed 01-09-2025]

work page 2025
[2]

Energy consumption model for sensor nodes based on lora and lorawan.Sensors, 18(7):2104, 2018

Taoufik Bouguera, Jean-François Diouris, Jean-Jacques Chaillout, Randa Jaouadi, and Guillaume Andrieux. Energy consumption model for sensor nodes based on lora and lorawan.Sensors, 18(7):2104, 2018

work page 2018
[3]

TS011-1.0.0 LoRaWAN® Relay Specification — resources.lora-alliance.org

LoRa Alliance. TS011-1.0.0 LoRaWAN® Relay Specification — resources.lora-alliance.org. https:// resources.lora-alliance.org/document/ts011-1-0-0-relay, 2022. [Accessed 21-03-2025]

work page 2022
[4]

TS0011-1.0.4 LoRaWAN® L2 1.0.4 Specification — resources.lora- alliance.org

LoRa Alliance. TS0011-1.0.4 LoRaWAN® L2 1.0.4 Specification — resources.lora- alliance.org. https://resources.lora-alliance.org/technical-specifications/ ts001-1-0-4-lorawan-l2-1-0-4-specification. [Accessed 21-03-2024]

work page 2024
[5]

Narrowband Internet of Things — rohde-schwarz.com

Rohde & Schwarz GmbH & Co KG. Narrowband Internet of Things — rohde-schwarz.com. https: //www.rohde-schwarz.com/us/applications/narrowband-internet-of-things-white-paper_ 230854-314242.html. [Accessed 21-03-2024]

work page 2024
[6]

M2m communications in cellular network de- ployments using lte

Rapeepat Ratasuk, Nitin Mangalvedhe, and Amitava Ghosh. M2m communications in cellular network de- ployments using lte. In2014 21st International Conference on Telecommunications (ICT), pages 477–481, 2014

work page 2014
[7]

Sigfox Device Radio Specifications | Sigfox build — build.sigfox.com

Sigfox. Sigfox Device Radio Specifications | Sigfox build — build.sigfox.com. https://build.sigfox.com/ sigfox-device-radio-specifications. [Accessed 21-03-2024]

work page 2024
[8]

LoRa and LoRaW AN: Technical overview | DEVELOPER PORTAL — lora-developers.semtech.com

Semtech. LoRa and LoRaW AN: Technical overview | DEVELOPER PORTAL — lora-developers.semtech.com. https://lora-developers.semtech.com/documentation/tech-papers-and-guides/ lora-and-lorawan. [Accessed 27-03-2024]

work page 2024
[9]

Formal validation of adr protocol in lorawan network using event-b

Chaib Mostefa, Nouar Abdelouahab, Tahar Abbes Mounir, Selma Boumerdassi, Smain Femmam, and Za- houi Anissa Amel. Formal validation of adr protocol in lorawan network using event-b. In2023 7th International Conference on Computer, Software and Modeling (ICCSM), pages 11–15, 2023

work page 2023
[10]

How Spreading Factor affects LoRaWAN® device battery life — thethingsnetwork.org

Qoitech. How Spreading Factor affects LoRaWAN® device battery life — thethingsnetwork.org. https://www.thethingsnetwork.org/article/ how-spreading-factor-affects-lorawan-device-battery-life. [Accessed 27-03-2024]

work page 2024
[11]

Lorawan mesh networks: A review and classification of multihop communication.Sensors, 20(15):4273, 2020

Jeferson Rodrigues Cotrim and João Henrique Kleinschmidt. Lorawan mesh networks: A review and classification of multihop communication.Sensors, 20(15):4273, 2020

work page 2020
[12]

Monitoring of large-area iot sensors using a lora wireless mesh network system: Design and evaluation.IEEE Transactions on Instrumentation and Measurement, 67(9):2177–2187, 2018

Huang-Chen Lee and Kai-Hsiang Ke. Monitoring of large-area iot sensors using a lora wireless mesh network system: Design and evaluation.IEEE Transactions on Instrumentation and Measurement, 67(9):2177–2187, 2018

work page 2018
[13]

A World of Wireless, Mobile and Multimedia Networks

Daniel Lundell, Anders Hedberg, Christian Nyberg, and Emma Fitzgerald. A routing protocol for lora mesh networks. In2018 IEEE 19th International Symposium on "A World of Wireless, Mobile and Multimedia Networks" (WoWMoM), pages 14–19, 2018

work page 2018
[14]

Multihop gateway-to-gateway communication protocol for lora networks

Made Harta Dwijaksara, Wha Sook Jeon, and Dong Geun Jeong. Multihop gateway-to-gateway communication protocol for lora networks. In2019 IEEE International Conference on Industrial Technology (ICIT), pages 949–954, 2019

work page 2019
[15]

Smart-hop: Low-latency multi-hop networking for lora

Absar Ahmar, Wouter Joosen, and Danny Hughes. Smart-hop: Low-latency multi-hop networking for lora. In 2022 18th International Conference on Distributed Computing in Sensor Systems (DCOSS), 04 2022

work page 2022
[16]

Improving the capacity of a mesh lora network by spreading-factor-based network clustering.IEEE Access, 7:21584–21596, 2019

Guibing Zhu, Chun-Hao Liao, Theerat Sakdejayont, I-Wei Lai, Yoshiaki Narusue, and Hiroyuki Morikawa. Improving the capacity of a mesh lora network by spreading-factor-based network clustering.IEEE Access, 7:21584–21596, 2019

work page 2019
[17]

Multi-hop lora networks enabled by concurrent transmission.IEEE Access, 5:21430–21446, 2017

Chun-Hao Liao, Guibing Zhu, Daiki Kuwabara, Makoto Suzuki, and Hiroyuki Morikawa. Multi-hop lora networks enabled by concurrent transmission.IEEE Access, 5:21430–21446, 2017

work page 2017
[18]

Lorahop: Multihop support for lorawan uplink and downlink messaging.IEEE Internet of Things Journal, 10(17):15376–15392, 2023

Pei Tian, Carlo Alberto Boano, Xiaoyuan Ma, and Jianming Wei. Lorahop: Multihop support for lorawan uplink and downlink messaging.IEEE Internet of Things Journal, 10(17):15376–15392, 2023

work page 2023
[19]

Lorawan range extender for industrial iot.IEEE Transactions on Industrial Informatics, 16(8):5607–5616, 2020

Emiliano Sisinni, Paolo Ferrari, Dhiego Fernandes Carvalho, Stefano Rinaldi, Pasetti Marco, Alessandra Flammini, and Alessandro Depari. Lorawan range extender for industrial iot.IEEE Transactions on Industrial Informatics, 16(8):5607–5616, 2020. 24

work page 2020
[20]

Jarun Khonrang, Mingkwan Somphruek, Thanapon Saengsuwan, Pairoj Duangnakhorn, and Atikhom Siri. Development of a long-range iot air quality monitoring system using lora mesh repeaters for real-time pollution tracking.Journal of Renewable Energy and Smart Grid Technology, 19(2):28–37, 2024

work page 2024
[21]

Rak wireless gateway mesh

RAK Wireless. Rak wireless gateway mesh. https://www.rakwireless.com/en-us/ expand-lorawan-network-with-gateway-mesh. [Accessed 10-09-2025]

work page 2025
[22]

Chirpstack gateway mesh

ChirpStack. Chirpstack gateway mesh. https://www.chirpstack.io/docs/chirpstack-gateway-os/ use/chirpstack-gateway-mesh.html. [Accessed 10-09-2025]

work page 2025
[23]

Chirpstack relay encapsulated protocol

ChirpStack. Chirpstack relay encapsulated protocol. https://www.chirpstack.io/docs/ chirpstack-gateway-mesh/protocol/index.html. [Accessed 10-09-2025]

work page 2025
[24]

LoRaWAN® message types

The Things Network. LoRaWAN® message types. https://www.thethingsnetwork.org/docs/lorawan/ message-types/. [Accessed 10-09-2025]

work page 2025
[25]

Experimental assessment of common crucial factors that affect lorawan performance on suburban and rural area deployments.Sensors, 23(3):1316, 2023

Markos Fragkopoulos, Spyridon Panagiotakis, Michail Kostakis, Evangelos K Markakis, Nikolaos Astyrakakis, and Athanasios Malamos. Experimental assessment of common crucial factors that affect lorawan performance on suburban and rural area deployments.Sensors, 23(3):1316, 2023

work page 2023
[26]

LoRaWAN – simple rate adaptation recommended algorithm — thethingsnet- work.org

Qoitech. LoRaWAN – simple rate adaptation recommended algorithm — thethingsnet- work.org. https://www.thethingsnetwork.org/forum/uploads/default/original/2X/7/ 7480e044aa93a54a910dab8ef0adfb5f515d14a1.pdf. [Accessed 24-04-2024]

work page 2024
[27]

[Accessed 11-09-2025]

Network simulator 3.https://www.nsnam.org/. [Accessed 11-09-2025]

work page 2025
[28]

Performance evaluation of lora networks in a smart city scenario

Davide Magrin, Marco Centenaro, and Lorenzo Vangelista. Performance evaluation of lora networks in a smart city scenario. In2017 IEEE International Conference on communications (ICC), pages 1–7. ieee, 2017

work page 2017
[29]

D. Magrin. LoRaWAN® ns3 module. https://github.com/signetlabdei/lorawan. [Accessed 02-09- 2025]. 25

work page 2025