Understanding the LoRaWAN® Architecture

LoRaWAN® networks primarily use the Aloha method for communication between end devices and their associated network servers. Using the Aloha method, end devices send data through a gateway to the network server only when one or more of their sensors notice a particular change in their environment or when some other event is triggered, such as a timer expiring. After the end device sends the uplink, it “listens” for a message from the network one and two seconds after the uplink before going back to sleep.

End devices spend most of their time asleep. During this time, they consume less than one microampere of energy. This power-saving method ensures that applications can achieve a lifespan of 10 to 15 years on a very small battery. In contrast, the Time Division Multiple Access (TDMA) approach requires device synchronization, which has an associated energy cost for end devices because they need to be awake and broadcasting to ensure they remain synchronized. For example, in a LoRaWAN network, end devices (illustrated by the colored icons in Figure 1) broadcast packets to a network asynchronously.

Figure 1

Packets broadcast by end devices will be picked-up by one or more gateways within the network, as illustrated in Figure 2.

Figure 2

Gateways are embedded with a multi-channel and multi-data rate radio-frequency device that can scan and detect packets on any of the active channels and then demodulate the packets.

Gateways are simply passages to the core network and typically have no built-in intelligence. This has two primary advantages:

• Gateways are made of very simple and inexpensive hardware.
• Roaming from cell to cell is not required. End devices broadcast packets without making an assumption about which gateway will receive them. Additionally, multiple gateways can receive packets without any impact on their energy consumption. No hand-off procedure or synchronization is required.

As illustrated in Figure 3, gateways typically have an Ethernet backhaul. However, some deployments use a 2G, 3G or 4G backhaul. Furthermore, some companies in the LoRaWAN ecosystem have proposed using a satellite backhaul for remote locations, such as those without Cellular coverage.

Figure 3

The core network server, as shown in Figure 4, is the central component of any LoRaWAN network. It carries all the required intelligence to manage the network and dispatch data to other servers.

Figure 4

The network server is responsible for:

• Message Consolidation: Multiple copies of the same data packet may reach the network server via multiple gateways. The network server must keep track of these, analyze the quality of the packets received and inform the network controller.
• Routing: For messages sent from the server to an end device (downlinks), the network server decides which is the best route to send a message to a given end device. Typically, this decision is based on a link quality indication that is calculated based on the Received Signal Strength Indication (RSSI) and the Signal-to-Noise Ratio (SNR) of the previously-delivered packets. Alternately, this decision can be made with respect to the availability of the gateway (is it free to transmit, or has it exhausted it Tx duty cycle?).
• Network Control: The link quality can also help the network server decide the best spreading factor (i.e. communication speed) for a given end device. This is the Adaptive Data Rate (ADR) policy, which is managed by the network controller.
• Network and Gateway Supervision: Gateways typically connect to the network server via an encrypted Internet Protocol (IP) link. Similarly, the network usually has a gateway commission and supervision interface allowing the network provider to manage their gateways, handle breakdown situations, monitor alarms, etc.

In addition, the core network communicates with other servers to organize roaming, links to application servers and more.

The LoRaWAN protocol is designed to support different types of networks. In some cases the network provider and the application provider are the same entity; in other cases they are not. Given these differences, application servers may be integrated with the network server or hosted elsewhere, as illustrated in Figure 5. Indeed, device on-boarding options support this multi-tenant network scenario, in which different application vendors provide heterogeneous applications.

Figure 5

To learn more about LoRaWAN networks, enroll in the free LoRaWAN Academy™.

LoRa and LoRaWAN are registered trademarks or service marks of Semtech Corporation or its affiliates.