Welcome!

LoRa Basics™ Station is an implementation of a LoRa® packet forwarder. The code is hosted on https://github.com/lorabasics/basicstation

A LoRa packet forwarder is a program running on the host of a LoRa-based gateway (with or without GPS). It forwards RF packets received by the concentrator (uplinks) to a LoRaWAN® Network Server (LNS) through a secured IP link. It also transmits RF packets sent by the LNS (downlinks) through the same secured IP to one or multiple devices. Additionally, it may transmit beacon signals used for time coordinating devices within the network. These beacons may be transmitted GPS-synchronously across the entire network.

System Overview

System Overview

LoRa Basics Station runs on a host systems and controls the LoRa Concentrator board over SPI or USB. The communication to the LoRaWAN Network Server is defined in The LNS Protocol. Some aspects of LoRa Basics Station can be remotely managed by a Configuration and Update Server (CUPS) over a dedicated configuration protocol, The CUPS Protocol.

The core features of LoRa Basics Station are:

  • Support for Class A, B, and C Communication: All three types of LoRaWAN communication patterns are supported. Class B communication is possible with different time-synchronization techniques (see below).

  • Centralized Update and Configuration Management: A LoRa Basics Station (“Station”) regularly contacts a separate Configuration and Update Server (CUPS) to check for configuration and software updates, which can include updates to the underlying operating system.

  • TLS and Token-based Authentication: LNS and CUPS use TLS for authenticating a Station. A Station can use either TLS or a token-based scheme for authentication. The latter requires fewer resources and is therefore preferable for embedded gateways running on resource-constrained hardware.

  • Centralized Channel-Plan Management: Channel plans and other network parameters are managed centrally by the LNS and are read by each Station when a connection is established.

  • No Dependency on Local Time Keeping: A Station obtains time synchronization from the LNS. There is no need for a local UTC-based clock. For Class B, a Station only requires a PPS routed to the concentrator. Synchronization of the PPS pulse with the global GPS time then is negotiated with the LNS. No NMEA-based interface, or any other kind of interface to a GPS module, is required. If present, however, it is used to augment health information.

  • In-door Beaconing with Server Assist: Stations have an API that lets the LNS control synchronization of the concentrator clock with a remote GPS/PPS time signal. This time synchronization can be used for indoor beaconing applications.

  • Remote Shell Through LNS Link: The secured IP link to the LNS can be used to run a shell session on a Station. This obviates the need for a reverse SSH tunnel setup. It can be seen as another means to access a gateway in case of problems.

  • No Configuration of Incoming Connections: If LNS and CUPS connection end-point identifiers for a Station are using IP addresses instead of domain names, the gateway does not need to support any incoming network connections. Time synchronization and shell access are managed via the LNS. No NTP or SSH is required.

  • Supports Concentrator Designs v1.5, v2 and Corecell (SX1302CxxxxGW1): Stations can be built for v1.5, v2 and Corecell concentrator designs. Multiple v1.5 concentrator boards are supported and can be managed by a single Station process.

  • Easily Portable to Linux-based Gateways and Embedded Systems: Stations can be ported, with minimal effort, to Linux-based gateways. Adapting a Station to custom concentrator designs is possible through a radio abstraction layer (RAL). Additionally, Station protocols have been designed to allow for implementations on embedded gateways that run on resource-constrained hardware.

Architecture

LoRa Basics Station Architecture