LoRa Basics™ Station
HOME » RESOURCES » TOOLS » LoRa Basics Station » Welcome

LoRa Basics Station

Welcome!

A LoRa® packet forwarder is a program running on the host of a LoRa-based gateway (with or without GPS), forwarding RF packets received by the concentrator (uplinks) to a LoRaWAN® Network Server (LNS) through some secured IP link and transmitting RF packets sent by the LNS (downlinks) through the same secured IP to some device. It further may transmit (potentially network-wide) GPS-synchronous beacon signals used for time coordinating devices within the network.

System Overview

System Overview

A LoRa Basics Station (or Station, for short) is an implementation of such a LoRa packet forwarder, which can be remotely managed by a Configuration and Update Server (CUPS).

The core features of a Station are:

  • Support for Class A, B, and C: All three types of LoRaWAN device communication patterns are supported, whereby Class B is possible with different time-synchronization techniques (see below).
  • Centralized Update and Configuration Management: Station regulary contacts a separate Configuration and Update Server (CUPS) to check for configuration or software updates, possibly even including updates of the underlying operating system.
  • TLS and Token-based Authentication: LNS and CUPS use TLS for authenticating Station, while Station can use either TLS or a token-based scheme for authentication. The latter requires less resources and therefore is preferably 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 read by each Station on connection establishment.
  • No Dependency on Local Time Keeping: Station obtains time synchronization from the LNS with no need for a local UTC-based clock. For Class B, Station only requires a PPS signal routed to the concentrator. Synchronization of the PPS pulse with the global GPS time then is negotiated with the LNS. An NMEA based interface or any other kind of interface to a GPS module is not required. If present, though, it is used to augment health information.
  • In-door Beaconing with Server Assist: Station has 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 in-door beaconing applications.
  • Remote Shell Through LNS Link: The secured IP link to the LNS can be used to run a shell session on Station. This obviates the need for a reverse ssh tunnel setup or can be seen as another means to access a gateway in case of problems.
  • No Incoming Connections Configuration: If LNS and CUPS connection end-point identifiers for 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 with no NTP or ssh required.
  • Supports Concentrator Designs v1.5 and v2: Station can be built for both v1.5 and v2 concentrator designs. Multiple v1.5 concentrator boards are suported and managed by a single Station process.
  • Easily Portable to Linux-based Gateways and Embedded Systems: Station can be easily ported with minimal efforts to Linux-based gateways; adapting to custom concentrator designs is possible through a radio abstraction layer (RAL). Station protocols further have been designed to allow for implementations on embedded gateways running on resource-constrained hardware.

Architecture

Architecture