This document outlines the primary components of a LoRa network, specifically utilizing the The Things Network (TTN) environment for illustrative examples.

The focus of this discussion will be the backend architecture of the LoRa network, emphasizing the components necessary for receiving messages, distributing Over-The-Air Activation (OTAA) identifiers, routing messages to their intended destinations, and similar functionalities.

Main Components

According to The Things Network’s official website, the following components are integral to a LoRa network:

1. Mote (IoT Device): Typically a combination of a LoRa transceiver and a sensor.
2. LoRaWAN Gateways: Multiple gateways can be within range to receive messages from devices, forwarding these messages over UDP to a router/broker service.
3. The Things Network Router: This black-box service receives UDP messages from gateways and subsequently forwards them to user-subscribed applications. This process involves at least two steps:
   • Receiving and decoding UDP messages from gateways and publishing them to an MQTT broker.
   • Application Handlers.
     TTN employs a complex architecture consisting of brokers, routers, and handlers; however, not all modules are available for private use at this time.

LoRa Devices

The design of LoRa devices (motes) is detailed in the hardware guide, and technical aspects of their construction are beyond the scope of this document. Comprehensive technical details regarding LoRa can be found in the LoRa Specification (V 1.0.1, Oct 2015).

For the architecture of the LoRa network, it is essential to understand that devices can be integrated into the network through two activation methods:

• OTAA (Over-The-Air Activation)
• ABP (Activation by Personalization)

Devices must be activated on the network before the network can process the data they transmit. While gateways will forward upstream messages, subsequent components in the network will not act on data from unrecognized devices. Activation can occur through either a fixed identity (ABP) or dynamic addressing, similar to Wi-Fi, where the network router assigns a unique address.

OTAA
OTAA is the preferred method for activating devices on the TTN. This process is analogous to connecting to a Wi-Fi network; however, it differs significantly because LoRa devices, typically simple sensor nodes, cannot be manually configured in the field. Instead, each device receives a unique ID to request a temporary unique address.

During the OTAA process, the device undergoes a join procedure and must store the following information prior to this process:

• AppEUI: Application End-device Unique Identifier.
• DevEUI: Device End-device Unique Identifier.

The device generates a JOIN request using its DEVEUI and APPEUI. The network must be made aware of the devices wishing to join via the application code; this is facilitated through the TTN network’s ttnctl tool and web interface.

Upon acceptance of the JOIN request, the network sends a downlink message containing the DevAddr (Device address) for the device’s use.

ABP
To ensure security in ABP, the network prevents unauthorized devices from assuming the identity of a node by requiring the device to maintain a frame counter. This counter confirms that both parties recognize each other as legitimate communicators.

Unlike OTAA, ABP does not involve a join procedure. Instead, the LoRa device is programmed with a unique code (DevAddr) for communication, along with the AppSKey and DevSKey, which must also be stored prior to any data transmission.

LoRa Gateway

Most gateways receive messages from LoRa devices and can forward them to multiple routers, referred to as uplink messages. Gateways typically utilize a UDP connection to relay these messages to the backend router/broker, commonly through port 1700.

Gateways can also facilitate downlink messages, enabling the backend to send commands back to devices. After transmitting an uplink message, the LoRa device will check for downlink messages.

It is important to note that while LoRa gateways are sophisticated devices, they lack intelligence beyond receiving and transmitting LoRa messages across various channels and speeds to designated router servers.

Single Channel Gateways
Single Channel Gateways operate on only one channel and speed, limiting their ability to receive a complete range of LoRa messages (approximately 10% of total transmitted messages). They may be useful in low-traffic areas or for private networks serving a limited set of known devices.

These gateways do not support downlink functions and cannot forward JOIN accept messages, making them suitable only for ABP addressing. While they are more cost-effective than full-fledged LoRa gateways, their use may disrupt OTAA functions in areas where both types of gateways coexist.

Future iterations of the TTN environment are expected to accept messages from single channel gateways in a staging environment for testing purposes but will not route downlink traffic to these gateways. The potential for single channel gateways in the production environment remains uncertain, as TTN aims to prioritize full gateways.

Router, Broker, and Handler

In general, the Router, Broker, and Handler functions are combined into a single program:

Router: Receives UDP messages from gateways and forwards them to brokers. The broker monitors associated gateways to ensure compliance with TTN’s fair use policy.

Broker: Acts as an intermediary between the router and application handler, identifying the appropriate handler for each device based on registered information.

Handler: Delivers MQTT messages to subscribed applications, requiring knowledge of device registrations.