Expert Series: 5 Things You Need to Know about LoRaWAN®-based Gateways

The LoRaWAN-based gateway is the physical layer (PHY) interface for the LoRaWAN network server (LNS). On the one hand, it listens to certain parts of the radio spectrum and decodes LoRa®-modulated signals originating from LoRa-based sensors. On the other hand, the gateway transmits messages from the network down to a sensor as LoRa-modulated signals.

The exact parameters which govern the reception and transmission of these signals is specified in the LoRaWAN Regional Parameters. The parameters are regionally differentiated because there are different regulatory requirements in different regions of the world.

Figure 1. LoRaWAN Architecture

1. The Role of the Gateway in LoRaWAN

First, decoded LoRa frames are checked for proper LoRaWAN encoding. An additional CRC check ensures the integrity of the messages. When a frame passes all checks it is directly forwarded to the network server along with metadata, such as

• Radio Signal Strength (RSSI)
• Signal-to-Noise Ratio (SNR)
• Receive Channel Frequency
• Reception Time
• Data Rate (DR)

When communicating with LoRaWAN Class A devices, the network server has the opportunity to respond to uplink messages after a fixed delay. For this purpose, the LNS schedules a downlink transmission on the gateway to ensure all regulatory restrictions are met before initiating the transmission.

LoRaWAN architecture allows the gateway to fulfill its role without knowing any device-specific information. Particularly, the gateway does not need to handle any LoRaWAN cryptographic keys or other state information related to the individual LoRaWAN-based devices it communicates with. This aspect of the LoRaWAN protocol ensures its security and scalability, and enables LoRaWAN-based gateways to focus purely on their primary mission: relaying LoRaWAN packets between device and network server quickly and reliably.

LoRaWAN gateways are traditionally mains powered devices consisting of a LoRa radio front end, which is controlled by a host platform via a serial interface. An additional high-bandwidth communication module (Cellular or Ethernet) provides backhaul connectivity to the LNS over IP. The host platform often features a full Linux operating system. However, more recently the trend towards miniaturization has prompted the design of gateways based on more cost-effective but resource-constrained host platforms based on real-time operating systems.

For OEM aiming to design and commercialize LoRaWAN gateways, Semtech offers a comprehensive set of RF front end, base band processors and reference designs with the LoRa Core™ portfolio.

Table 1. Duplexer Specifications

These are all the available Semtech LoRa gateway reference designs as of March 2024. Kits labeled “Obsolete” are not recommended for new designs.

2. Gateway Types and Deployment Options

Gateway models are often classified into two groups: indoor and outdoor gateways.

Indoor gateways typically come in light plastic enclosures and aim to facilitate easy, cost-effective indoor deployment to extend LoRaWAN network coverage deep into buildings. The most common configurations of such gateways feature a single LoRa antenna plus a Wi-Fi or Ethernet interface for backhaul connectivity.

Outdoor gateways are found on towers or rooftops, enclosed in a weatherproof casing. These gateways provide coverage over large areas by using high-gain antennas. Backhaul connectivity is ensured through a range of high-bandwidth channels often using Cellular connectivity as a fallback. Additionally, a GPS receiver provides a precise time source to enable the gateway to emit LoRaWAN Class B beacons.

The most common gateway configuration features a single SX1302 LoRa baseband processor which is able to receive on eight channels and all spreading factors simultaneously.

A variety of gateway vendors offer solutions that differentiate on various aspects related to backhaul connectivity, RF options, interoperability, mounting options, size, support, management software, and more. It is this diversity of gateway options that allows LoRaWAN deployments to be flexible and able to adapt to different needs; for example, with a small number of outdoor gateways, large campuses can be covered with a private network. Technology enthusiasts can build their own gateways and use them to provide coverage to sensors deployed in the neighborhood. Industrial outdoor gateways provide nationwide base coverage for many applications.

3. Gateway Software

At its core, the software of every LoRaWAN-based gateway must include functionality to drive the radio hardware and to communicate with the network server. More concretely, this entails:

• Managing backhaul connectivity
• Reconnecting after losing the backhaul connection
• Managing credentials for client and server authentication
• Managing spectrum access
• Configuring radio hardware
• Enforcing regional regulations (such as duty cycle, dwell time, listen-before-talk)
• Handling packet flow
• Polling radio hardware for new packets
• Verifying packet integrity
• Buffering received uplink packets
• Maintaining the schedule of downlink transmissions

The interface to the radio hardware is provided by Semtech in the form a C library which implements a hardware abstraction layer (HAL). Different HAL layer implementations exist for the different gateway reference designs. , however for new design Semtech recommends to rely on corecell reference design (https://github.com/Lora-net/sx1302_hal).

The interface between the gateway and the network server is not standardized yet and there are a number of different LNS-vendor-specific implementations of that interface.

Semtech provides two open source gateway software implementations: Packet Forwarder and LoRa Basics™ Station.

The packet forwarder project has a long history and has thus established wide usage. It provides a simple UDP-based interface, allowing developers to get started with new hardware quickly in a lab or test setting.

LoRa Basics Station (LBS) addresses issues that arise when gateways operate in large numbers at scale. Released in 2019, it provides a variety of useful features on top of its two protocols. The LNS protocol is the primary data plane, providing a low-latency bidirectional communication channel over secure WebSockets. Aspects of load-balancing and centralized configuration management are built into this protocol. In addition, LBS provides credentials management and firmware update interface via the Configuration and Update Server (CUPS) protocol – a simple authenticated HTTPS transaction for delivering LNS interface credentials and signed firmware binaries. With these basic building blocks, a variety of deployment, configuration, management, and inspection operations can be performed securely without the need for physical interaction.

4. Gateway Security

The security of gateways is paramount for protecting the infrastructure of a LoRaWAN network. That being the case, the communication link to the corresponding LNS must be secured. An important aspect of securing the communication link is mutual authentication, i.e., both client and server authentication. Two approaches are common for securing this communication link: TLS and IPSec. IPsec VPNs (virtual private networks) connect hosts or networks to a protected private network, while SSL/TLS VPNs securely connect a user's application session to services inside a protected network. Depending on the available network infrastructure and the hardware resources of the gateway, one approach or the other may be preferred. For example, when using a low-cost embedded gateway, with limited volatile memory IPSec may require too many resources, making TLS the appropriate solution.

A secure communication link becomes even more important when deploying a large number of low-cost gateways in picocells. To support massive deployment scenarios, it is good practice for gateways to have a gateway-specific set of bootstrap credentials embedded during production, similar to the way LoRaWAN-enabled end devices are manufactured with an embedded, device-specific key. Such bootstrap credentials allow gateways to discover an LNS endpoint and to securely exchange further credentials for subsequent provisioning and communication with the corresponding LNS. This type of process allows gateways to use various LNS instances offered by different vendors while remaining secure by using gateway-specific personalized credentials that provide client-authentication. The distribution of secure credentials and the provisioning of gateways on corresponding LNS can be referred to as the “gateway join process.”

In addition to the secure gateway join process, which ensures a secure LNS communication link, several aspects should be considered with respect to overall gateway security and protection of the LoRaWAN infrastructure. These aspects include:

• Hardening the gateway operating system (OS)
• Applying security patches and updates
• Reducing the number of open listening ports and network connections in general
• Using gateway-specific credentials, i.e., passwords, keys, tokens, and certificates
• Disabling password-based access and configuring public key access
• Ensuring physical access is authenticated

5. Network Planning and Adaptive Data Rate (ADR)

When setting up your network, there are a number of critical aspects in determining the capacity of the gateways.

• Keys to uplink capacity (device-to-network, through a gateway):
• The number of channels available in the regional parameters specification
• The number of channels employed in the gateway
• The number of data rates specified in the regional parameters specification
• Utilization of the LoRaWAN network for adaptive data rates (ADR)
• Restrictions on device duty cycles defined in countries or regions (also specified in the regional parameters specification)
• Distribution of gateways in a network to achieve timing and signal strength diversity (at least 6 dB)

At a high level, the simplest way of looking at capacity is the number of channels used over time. The additional factor incorporated in LoRaWAN is the use of data rates (DR), which are a combination of LoRa spreading factors together with bandwidth. DRs represent the total occupied time on a channel for a fixed amount of data. The lower the DR, the longer it takes to transmit the message over the air; however, the benefit is extra processing gain and thus a longer range of reception for the signal. Signals received at the exact same time with the exact same DR can be received if they are on different channel frequencies.

Figure 2. Channel Occupancy over Time with Four Data Rates

Figure 2 shows N channels of data received at a gateway over time, transmitted at four different DRs. As mentioned, signals from the different channels will not interfere with one another. Additionally, this example was formulated where there are no signal broadcast overlaps within the same channel for the same DR. Although there are overlaps within the channel at different DRs, the LoRa radio will often be able to distinguish between two different DR signals received at the same time. If there were signals on the same channel at the same DR received at the same time, both of those signals would likely be lost. This emphasizes the need to use higher DRs and shorten the time on-air while maximizing channel capacity.

It is important to understand that signals from two devices on the same channel, received at the same time and at the same DR will typically result in a collision and both device messages will likely be lost. However, if one signal is 6 dB or higher than the other, the LoRa PHY layer can resolve the higher signal and reject lower one. Therefore, if you have a distribution of gateways in a coverage area with enough separation, it is possible that signals which may be completely lost by a single gateway could be at least partially resolved by two gateways in a distributed network.

The impact of ADR will distribute the DRs such that devices closest to a gateway will have the highest DRs and occupy the least amount of time on a transmit channel. It is important to recognize that the network needs to control ADR because the devices transmitting the signals do not have a measure of what the signal levels received by the gateway will be. The network needs to be able to determine these signal levels (and the amount of traffic) and command devices to use the proper DRs for the traffic and the signal levels received. Note that the device also needs to support the ability to receive and implement the DR change parameters.

6. Gateway Product Ecosystem

Semtech Corp. produces Gateway Reference Designs for development and evaluation of the LoRa technology. Several companies produce gateway products for LoRaWAN. The LoRa Alliance Product Marketplace provides a catalog of gateway products. Raise a Semtech Salesforce ticket for guidance by our Field Application Engineers.

Semtech, the Semtech logo and LoRa® are registered trademarks or service marks, and LoRa Core™ is a trademark or service mark of Semtech Corporation or its affiliates.