Editor’s note: In Part 1 of this two-part series, we will discuss the issue of long-range, low-power communication for IoT and how to achieve it, securely. In Part 2, LoRaWAN Part 2: How to Use Microchip’s Modules to Speed IoT Design, we will discuss an implementation using off-the-shelf LoRaWAN hardware and software.
Low-power wireless networks are a key enabler for the Internet of Things (IoT), but familiar options such as Bluetooth, ZigBee, Wi-Fi, or cellular, lack an acceptable combination of extended range and battery life. To address this, new sub-GHz specifications are being offered, one of which is LoRaWAN.
LoRaWAN can achieve a 15 km range at power consumption levels low enough to enable 10-year battery life. Further, the availability of an off-the-shelf development kit lets designers quickly bring up a complete LoRaWAN network application with minimal effort.
This article will look at the advantages of sub-GHz communication, examine the important role of modulation schemes, and introduce LoRaWAN with a description of its physical and media access control layers, as well as its security features. It will conclude with a brief introduction to the RN2903 LoRaWAN module from Microchip Technology.
Sub-GHz advantages
High-frequency connectivity options provide high data rates but have limited range at acceptable power levels. For power-constrained designs that need extended range, low-frequency operation is a preferred approach. The lower the frequency, the less power is required to maintain a particular link budget at a specified range, as shown by the Friis transmission equation:
Where:
Pt = transmitted power
Pr = received power
Gt = transmitter antenna gain
Gr = receiver antenna gain
λ = wavelength
d = distance between transmitter and receiver
Lower frequency transmissions typically translate to lower data rates, but IoT applications rarely present significant throughput requirements. Additionally, lower data rates bring another advantage in the form of reduced error rates, thereby decreasing the sensitivity requirements of the receiver.
The downside is that with slow links the duty-cycle increases, thereby increasing the chance of error due to interference from noise and other signals. Further, the longer the time required to transmit a message means increased power consumption at both the transmitter and receiver ends.
That said, sub-GHz communications can help meet the requirements for range, power, and data rate required by most IoT applications. Still, the choice of modulation method used for data encoding adds a further layer affecting these three key parameters.
Modulation methods
Communications specialists have for years relied on spread spectrum modulation techniques to enhance immunity to noise or interfering signals. Channel coding methods used in spread spectrum techniques, such as direct-sequence spread spectrum (DSSS), are able to reduce transmitter power requirements by building redundancy into the spreading algorithm.
Although this approach can support very high data rates, it requires a high bandwidth carrier and sophisticated modulation/demodulation signal chains able to ensure efficient transmission and reception of the wideband signal. IoT applications rarely need the kind of maximum data rates possible with modulation techniques such as DSSS. Further, the design complexity and power requirements associated with traditional spread spectrum techniques can make them less effective for low-cost, battery-operated IoT designs.
This is where LoRa comes in. Developed by Semtech, LoRa is a unique spread spectrum modulation method that brings some of the benefits of spread spectrum noise immunity, while simplifying design requirements. LoRa modulation is based on a frequency modulated "chirp" signal that can be generated with a relatively simple fractional-N phase-locked loop (PLL).
When initiating a LoRa transmission, a LoRa modem issues a preamble comprised of a series of chirps (Figure 1, left). The transmission continues with a series of chirps that encode data essentially as frequency jumps in the chirp signal, similar to the use of multiple frequency tones to encode data in M-ary FSK (Figure 1, right).
Figure 1: This waterfall view (newest data at the top) shows the repeated chirps used in the LoRa transmission preamble (left) and the chirps encoding the payload of a transmission (right). (Image source: Link Labs)
On the receiver side, a PLL can lock onto the preamble to initiate reception of a message stream. Because of the distinct pattern of the chirps, a LoRa modem can detect signals as low as 20 dB below the noise floor. LoRa technology enables -148 dBm sensitivity, enabling robust connectivity over very long ranges. Further, a LoRa modem can receive several different transmissions simultaneously, each differing only in chirp rates. As a result, it can support very large numbers of IoT devices operating simultaneously.
LoRa networking
LoRa technology's unique modulation method lies at the heart of performance characteristics that make it well suited to IoT applications: It can operate successfully at ranges exceeding 15 km in suburban settings and more than 2 km in dense urban environments. It can achieve over 10-year battery life and it can operate in networks comprising up to 1 million nodes. Further, its support for different chirp rates, or "spreading factors," gives designers the flexibility to trade data rate for range or power as needed to optimize network performance (Figure 2).
Figure 2: With LoRa technology, IoT developers can trade data range for bit rate by using different spreading factors. (Image source: Microchip Technology)
For all its benefits, LoRa is still a physical layer (PHY) mechanism. In an actual IoT application, developers' ability to apply it as a connectivity solution depends on the availability of a network protocol stack able to build on the LoRa PHY. The LoRaWAN standard does just that with its definition of the media access control (MAC) layer designed to operate with the LoRa PHY. Created and maintained by the LoRa Alliance, the LoRaWAN specification was developed specifically for long-range IoT applications and provides access and control protocols geared for secure, low-power wireless communications.
LoRaWAN defines a familiar IoT hierarchy comprising end devices, local controllers, and cloud-based servers (Figure 3). In LoRaWAN terminology, end devices are connected wirelessly in a star topology to a gateway, and gateways connect through IP networks to a central network server. The network server can double as an IoT application server or connect to one or more separate application servers.
Figure 3: The LoRaWAN network topology presents a familiar IoT hierarchy comprising end devices connected wirelessly (dotted lines) to gateways that connect through IP networks (solid lines) to an upstream network server and application servers. (Diagram drawn using Digi-Key Scheme-it)
The LoRaWAN stack provides applications with a standard interface to LoRa-based communications (Figure 4). At the bottom of the stack, the LoRa PHY works with regional sub-GHz ISM bandwidth allocations. Above the LoRa PHY, the LoRaWAN MAC provides familiar MAC-layer services including channel access and addressing. As described below, the LoRaWAN standard defines specific message formats and timing for uplink and downlink transactions.
Figure 4: Built on the LoRa PHY, the LoRaWAN media access control (MAC) defines the message formats for different device classes. (Image source: LoRa Alliance)
Communications options
The LoRaWAN MAC protocol is designed to support IoT applications with different requirements for downlink communications from a LoRaWAN gateway to an end device. As defined by the LoRa Alliance, the LoRaWAN MAC includes three different classes of devices, all of which support bidirectional communications but differ in their downlink availability:
- Class A operation supports low-power devices such as wireless sensor nodes that require minimal downlink communication from the server after uplink transmission. A Class A device can transmit data to a gateway any time, but can only receive within two windows, each occurring at a specified delay after the transmission (Figure 5).
Figure 5: In the default Class A transaction, a device transmits a LoRa-compatible message to a gateway and then listens after preset delays for a response in two receive windows. (Image source: LoRa Alliance)
- Class B operation extends Class A with additional downlink receive windows. Besides the usual two short receive windows following transmission, a Class B IoT device listens for additional downlink messages at other scheduled windows. The downlink windows occur at specific times following a beacon that is transmitted by a recognized LoRaWAN gateway. Class B downlink scheduling provides a mechanism for applications to contact the IoT device at specific times rather than depending on the non-deterministic downlink windows available in default Class A operation.
- Class C operations supports devices that need near-continuous availability of downlink receive windows. A Class C device constantly listens for downlink messages except when it is transmitting data or opening the two default receive windows.
LoRaWAN is designed with multiple security features, using a combination of device, session and application crypto keys to encrypt data and to authenticate device access to the network. For a LoRaWAN application, end devices can be programmed at the factory with the authentication information required to join a specific LoRaWAN network, which LoRaWAN calls "activation by personalization”. LoRaWAN also offers "over-the-air activation”, which specifies a procedure for authentication and authorization required for a device to join any available LoRaWAN network.
For network-join operations and secure data communications, only IoT devices and the application server hold crypto secrets (Figure 6). Encrypted messages are simply conveyed, not processed, by the intermediate gateway and network, eliminating their use as an effective attack surface for bad actors.
Figure 6: In a typical LoRaWAN application, crypto keys are maintained only in end devices and application servers (green highlight). The end-device MCU and upstream IoT application software (red highlight) operate on plain text, while the LoRaWAN gateway and network server (blue highlight) see only encrypted data. (Image source: Microchip Technology)
Simplified communications
Designed to simplify development of LoRaWAN communications, Microchip Technology offers a discrete module that implements LoRa modulation and provides LoRaWAN compatibility. The Microchip RN2903 supports LoRaWAN-compatible communications at the ITU Region 1 ISM standard frequency band of 915 MHz. Along with LoRa modulation, the onboard transceiver also supports FSK and GFSK modulation for proprietary network-protocol design. Similarly, Microchip's RN2483 provides identical features, supporting the ITU Region 2 ISM bands at 433 or 868 MHz.
Figure 7: The Microchip LoRa module provides a drop-in solution for LoRaWAN connectivity with its onboard command processor, LoRaWAN protocol stack, radio transceiver, and serial connectivity. (Image source: Microchip Technology)
Fully certified, the Microchip module includes all the components required to implement LoRaWAN connectivity (Figure 7). The module's command processor uses the onboard LoRaWAN firmware to fully support the LoRaWAN Class A protocol. The onboard EEPROM provides storage for LoRaWAN configuration parameters, enhancing performance and increasing security by reducing data transfers between the host and module.
Conclusion
In creating IoT devices intended for long-range communications, developers face a challenge in finding a wireless connectivity able to meet requirements for extended range, long battery life, and sufficient data rate. LoRaWAN can satisfy these demands with unique modulation technology that can achieve a 15 km wireless range and a 10-year battery life. Still, meeting LoRaWAN's underlying PHY and MAC requirements can stretch development resources and project schedules. Microchip Technology's RN2903 LoRa module provides a near drop-in solution for implementing LoRaWAN in IoT device designs. As we will discuss in part two, end-device connectivity is only part of a complete LoRaWAN-based IoT application.
In Part 2 of this two-part series, we will discuss how to implement the Microchip RN2903 module using relevant code examples. We will also examine its role in a Microchip LoRaWAN evaluation kit that offers a complete off-the-shelf LoRaWAN-compatible solution including hardware and software for end devices, gateways, and network servers.
