PaperlayerView exact revision on arXiv

Source-linked AI summary

Design and Implementation of Open LoRa for IoT

Qihao Zhou, Kan Zheng, Lu Hou, Jinyu Xing, Rongtao Xu

arXiv:1812.09012v4cs.NI

TL;DR

Practical, scalable implementation of a private LoRa network remains an open challenge. The paper presents gateway hardware and an open-source, modular network-server architecture, then reports urban range and node-capacity results. The authors conclude that the system offers a flexible and feasible private-network solution.

  • Problem

    The reference LoRaWAN architecture centralizes functions in the network server, which may create a bottleneck and limits expansibility, while concrete implementation guidance is lacking.

    Source: A. Related Works on Architecture Design · p. 4

  • Method

    The paper proposes gateway hardware and an open-source network server divided into four decoupled modules that communicate through streaming-data messaging.

    Source: §I · pp. 1–2, §V · p. 4, 1) Interaction Between Modules · p. 5

  • Results

    The urban prototype achieved a maximum transmission distance of about 7.5 km and supported more than 10,000 LoRa Nodes with well-deployed computing resources.

    Source: §VII · p. 8

  • Takeaways & Limitations

    The authors expect the open LoRa network to provide flexibility and feasibility for building private networks.

    Source: §VII · p. 8

Abstract

from arXiv · show

Long Range (LoRa) network is emerging as one of the most promising Low Power Wide Area (LPWA) networks, since it enables the energy-constraint devices distributed over wide areas to establish affordable connectivity. However, how to implement a cost-effective and flexible LoRa network is still an open challenge. This paper aims at exposing a feasible solution of design and implementation, allowing users to conveniently build a private LoRa network for various IoT applications. Firstly, several typical application scenarios of LoRa network are discussed. Then, the LoRa system architecture is presented with the functionality of each component. We address the hardware design and implementation of LoRa Gateway, which is the bridge between LoRa nodes and LoRa network server. Especially, the paper contributes by proposing an improved software architecture of LoRa network server whose source codes are open on GitHub. Under the architecture, LoRa network server is divided into four decoupled modules and uses the messaging system based on streaming data for the interaction between modules to guarantee scalability and flexibility. Finally, extensive experiments are conducted to evaluate the performance of LoRa networks in typical environments.

I. INTRODUCTION

The paper identifies practical deployment and scalability challenges for private LoRa networks, then presents a gateway design and a modular, open-source network-server architecture. It also frames typical applications around LoRa’s long-range, low-power capabilities and low data rate.

I. INTRODUCTION

  • Prior implementations leave deployment and scalability gaps: independent TTN deployment is cumbersome, while LoRaServer concentrates functionality in one module.The paper argues that this concentration may negatively affect throughput and scalability.Source: §I · p. 1
  • The paper proposes a LoRa Gateway design, an improved open-source network-server architecture, and an urban prototype evaluated through experiments.The server is divided into four decoupled modules.Source: §I · pp. 1–2

II. TYPICAL APPLICATIONS OF LORA NETWORKS

  • LoRa offers long-range, low-power connectivity for IoT applications, but does so at the expense of a low data rate.The introduction also notes that LoRa operates in the unlicensed ISM band.Source: §I · p. 1, §II · p. 2

A. Smart City

The section describes LoRa applications in smart cities, environmental monitoring, healthcare, and farming, emphasizing sensor data collection across geographically broad settings.

A. Smart City

  • Smart-city nodes can report sensing data automatically and be controlled remotely for applications such as smart metering and waste management.These applications offer opportunities to improve municipal operating efficiency and reduce maintenance costs.Source: A. Smart City · p. 2

B. Environmental Monitoring

  • Environmental-monitoring sensors can report indicators such as air quality, temperature, and humidity, and alert to critical situations.The passage describes LoRa as suitable for networks spanning large geographical areas given financial and energy requirements.Source: B. Environmental Monitoring · p. 2

C. Smart Healthcare

  • Smart healthcare sensors can transmit biological information and abnormal indicators to health providers for timely checking and disease prevention.The passage identifies healthcare costs as a challenge and describes LoRa as low-cost with reliable performance.Source: C. Smart Healthcare · p. 2

D. Smart Farming

  • Smart farming use cases include soil-moisture monitoring and autonomous irrigation, with sensors transferring farm information to the cloud.The passage connects these use cases to more efficient farm operations and management.Source: D. Smart Farming · p. 2

III. LORA NETWORK ARCHITECTURE

The paper presents a three-tier LoRa network architecture in which nodes and gateways support data exchange, while the network server handles packet processing and protocol functions.

III. LORA NETWORK ARCHITECTURE

  • The proposed LoRa network architecture is organized as three hierarchical tiers.The section describes the functions of the architecture’s components.Source: §III · p. 2

A. LoRa Node and Gateway

  • Nodes perform application-specific tasks, while gateways relay uplink and downlink packets between nodes and the network server.Gateways add metadata such as SNR and RSSI to uplink packets and typically do not interpret payloads.Source: A. LoRa Node and Gateway · p. 3

B. LoRa Network Server

  • The network server processes packets and analyzes protocols, including filtering duplicate uplinks, managing the network, scheduling acknowledgements, and forwarding application data.The section identifies flexibility, scalability, and management of nodes and gateways as important design needs.Source: B. LoRa Network Server · p. 3

C. Application Server in IoT cloud

The section describes the application server’s role between the IoT cloud and network server, then outlines gateway hardware and its controller software environment.

C. Application Server in IoT cloud

  • The application server bridges the IoT cloud and LoRa network server, processing application payloads and supporting encryption, decryption, and varied encoding methods.Users can access applications and control nodes through browsers or smartphones.Source: C. Application Server in IoT cloud · p. 3

IV. HARDWARE DESIGN AND IMPLEMENTATION

  • The gateway relays between LoRa nodes and the network server and is designed for two-way multichannel communication, high receiving sensitivity, rich interfaces, and outdoor deployment.Its five modules include controller, localization, power management, LoRa, and communication; the enclosure meets IP65 requirements.Source: §IV · p. 4

A. Controller Module

  • The controller uses a Smart4418 board and Debian Linux, while a packet forwarder connects the gateway to the server over UDP.The board has a quad-core Cortex A9 CPU, 1 GB RAM, and 8 GB eMMC.Source: A. Controller Module · p. 4

B. LoRa Module

The LoRa Gateway’s communication module supports multichannel packet reception and data-rate adaptation, while separate modules provide server connectivity and GPS-based localization and time synchronization.

B. LoRa Module

  • Two SX1255 transceivers feed an SX1301 baseband processor, which can demodulate up to 8 LoRa packets simultaneously across its programmable paths.The gateway also supports data-rate adaptation, allowing nodes to transmit at different data rates on a given channel as required.Source: B. LoRa Module · p. 4

C. Communication Module

  • Wi-Fi, LTE, or Ethernet provides the gateway’s connection to the LoRa network server, depending on the deployment environment.Source: C. Communication Module · p. 4

D. Localization Module

  • The MAX-7Q GPS module provides position accuracy below 5 meters and supplies information used for localization and time synchronization.GPS information passes to the controller over a serial port for parsing according to standard protocols.Source: D. Localization Module · p. 4

E. Power Management Module

The paper presents gateway power management and an improved LoRa network server architecture intended to support flexible private-network deployment. It contrasts this design with existing architectures that concentrate functionality in a central server.

E. Power Management Module

V. LORA NETWORK SERVER DESIGN AND IMPLEMENTATION

  • The proposed server architecture aims to make private LoRa networks easier to deploy and support flexible operation.Source: §V · p. 4

A. Related Works on Architecture Design

  • LoRaWAN’s central Network Server may become a bottleneck and lacks expansibility and resistance to a single point of failure; CableLabs uses gRPC between modules, while the proposed design uses messaging and separates functions into four modules.The paper also notes that LoRaWAN gives a typical architecture without a concrete implementation; Fig. 5 depicts the improved server architecture.Source: A. Related Works on Architecture Design · pp. 4–5, Figure 5 · p. 5

B. Design of LoRa Network Server

The server separates functions into low-coupling modules and uses streaming messaging for their interaction. Consumer groups provide load balancing and fail-over across parallel module instances.

B. Design of LoRa Network Server

  • The server divides functionality among Connector, Central Server, Join Server, and Network Controller, with Connector filtering illegal packets and Network Controller handling schemes such as ADR.The modules follow microservice principles and can be deployed in separate processes or servers; Docker containerization packages components for deployment across environments.Source: B. Design of LoRa Network Server · p. 5

1) Interaction Between Modules:

  • Apache Kafka topics act as streaming-data pipelines: modules subscribe as consumers and publish as producers, enabling asynchronous processing with ordering and reliability guarantees.Producers need only the specified message format, rather than knowledge of consumers.Source: 1) Interaction Between Modules · p. 5

2) Load balancing:

  • Consumer groups distribute messages round-robin among available module instances, improving throughput and allowing processing to switch to another instance if one fails.Each message is assigned to one consumer in the subscribing group; the paper describes this as avoiding service interruption during a single-module failure.Source: 2) Load balancing · p. 5

3) Database:

The server assigns different data to SQL and NoSQL storage and implements processing through decoupled modules. Connector verifies and parses gateway traffic, while Central Server routes packets, filters duplicates, and schedules downlinks.

3) Database:

  • MySQL stores persistent data with definite relationships, while NoSQL stores session-related and non-persistent data such as logs and duplicate packets.The paper also identifies caching as necessary for low-latency handling of large volumes of concurrent packets.Source: 3) Database · p. 5

C. Implementation of LoRa Network Server

  • The implementation uses microservices to decouple module duties and support distributed deployment, alongside a website for device registration, monitoring, and historical-data retrieval.Source: C. Implementation of LoRa Network Server · p. 6

1) Connector:

  • Connector verifies gateway and node legality, parses and packages LoRaWAN payloads, and forwards activation-related packets to Central Server.It connects to the gateway over an IP backbone using UDP; illegal packets are discarded.Source: 1) Connector · p. 6

2) Central Server:

  • Central Server routes uplink data, MAC commands, and join packets to their respective modules, filters duplicate receptions, and selects a downlink gateway using RSSI and SNR.It also determines downlink parameters and reads payloads from application-data and MAC-command queues.Source: 2) Central Server · p. 6

3) Join Server:

Join Server handles node activation and session-key generation, while Network Controller manages MAC commands; the experiments assess LoRa coverage and network-server performance.

3) Join Server:

  • Join Server handles activation requests and generates session keys; OTAA uses a join request/accept exchange, while ABP nodes require website registration.Source: 3) Join Server · p. 6

4) Network Controller:

VI. EXPERIMENTAL RESULTS AND ANALYSIS

  • Prototype experiments evaluate LoRa coverage and network-server performance; Fig. 8 presents transmission coverage.Source: §VI · p. 6, Figure 8 · p. 7

A. Coverage performance and analysis

Urban field trials measured gateway uplink coverage, while server stress tests found throughput limits that rise with the number of deployed Central Servers and are associated with CPU bottlenecks.

A. Coverage performance and analysis

B. LoRa Network server performance and analysis

VII. CONCLUSION

The paper concludes that its hardware design achieved about 7.5 km maximum transmission distance in urban environments, and its improved architecture supported more than 10,000 LoRa Nodes with well-deployed computing resources.

VII. CONCLUSION

  • About 7.5 km maximum transmission distance was measured in urban environments, and the improved architecture supported more than 10,000 LoRa Nodes with well-deployed computing resources.Source: §VII · p. 8
Loading 1812.09012v4…