"LoRaWAN networks drive IoT applications - They'll be responsible for connecting the next billion devices to the internet
This page explains a LoRaWAN network and how it works with Telemetry2U
LoRaWAN Network Technical Description
Internet of Things (IoT) technology is a wireless network of hardware and software designed to exchanges data over the internet so information can be easily collected, analysed, and shared, adding a level of smart and responsive digital intelligence. It is widely used in monitoring and control systems and applies to all sorts of applications, environments, and industries.
LoRaWAN stands for ‘Long-Range Wide-Area-Network’ and is a wireless protocol designed to provide two-way communication for low cost and low power (IoT) products. Gateways pass messages to and from end-devices to a network server. The gateways connection to the network server made by a standard IP connection (Ethernet, Wi-Fi or 4G) while communications with the end-device is made by an efficient and dynamic RF link termed ‘LoRa’. In short, a Gateway acts as a bridge that will convert RF packets to IP packets and vice versa.
LoRaWAN Topology
The LoRaWAN network architecture is deployed in a star-to-star topology, meaning any end-device can send messages to any gateway that is in range with a single-hop link. The RF link, LoRa, was developed by Semtech as a Low-Power Wide-Area-Network (LPWAN) based on spread spectrum modulation derived from Chirp Spread Spectrum (CSS) technologies. It operates on a total of 72 channels. 64 channels with 200KHz increments at fixed bandwidth of either 125KHz or 500KHz are used for uplinks and 8 channels with 1.6MHz increments with a bandwidth of 500KHz for downlinks. Using low power consumption and frequency hopping, it is capable of more than 10km range in rural areas with high sensitivity and noise immunity. A table of the frequencies used in Australia are listed below.
LoRaWAN Frequency Plans
Telemetry2U end-devices and gateways are programmed to work on channels 8-15 on the AU915 region frequency plan. Different countries use different frequency plans and Telemetry2U will preconfigure and test all hardware appropriately before shipment so your nodes will connect to our network as soon as you power them up.
LoRaWAN Classes
LoRaWAN nodes can operate in three different specified classes that are explained below, however, Telemetry2U have chosen to only operate in Class-A and Class-C.
Class A
Class A supports bi-directional communications between the gateway and the end-device with communication initiated by the end-device only. Uplink messages can be sent to the gateway at any time. After every uplink, two receive windows at are opened on the end-device following a respective one and two second delay, where it will wait for a single downlink command from the network server. Downlinks can either be used for message confirmations or control commands. The end-device will enter low power mode at the end of the receive windows whether a command is received or not. Commands can be placed in the command que at any time, but only one command can be sent for every uplink. Class A is the most common Class, as it is the most power efficient from the end-devices point of view.
Class B
Class B extends on Class A by opening more receive windows periodically using time synchronised beacons sent from the gateway. This means that there are more opportunities for commands to get through to the end device between uplink transmissions. Telemetry2U does not currently support this mode.
Class C
In Class C mode, the receive windows are open all the time, except when the end-device is transmitting. This means that commands will come through with very low latency, but due to the receiver being permanently on, power use is greatly increased. Therefore, most battery powered nodes will not use Class C mode. Telemetry2U only recommend using Class C for the LT22222L I/O controller and the RS485LN as they are designed to be powered from an external 12V source.
LoRaWAN DataRates (DR)
The DR is made up of an ‘Orthogonal Spreading Factor’ and ‘Bandwidth’. Bandwidth is how many bits of data can be transmitted per second, while the spreading factor is the duration of the chirp used to transmit the data. Spread factors (SF) vary from SF7 to SF12, with SF7 being the shortest chirp length and SF12 the longest. Each step up in SF roughly doubles the amount of airtime required to transmit the same amount of data. The higher the data rate, the less airtime required, resulting in lower power consumption but less range. A lower DR means more airtime, thus more range but more power used. With LoRaWAN in Australia, the maximum permitted power output is +30dBm, however +20dBm is sufficient in most applications. It is also assumed that the maximum airtime for a LoRaWAN uplink packet is 400mS on the AU915 band, but Telemetry2U disables this limit with a command sent back from the server, so packets will still get through.
LoRaWAN currently uses 13 Data Rates in total on the AU915 band. 0-7 are used for uplinks and all have a bandwidth of 125KHz, except for DR6(500KHz). DR’s 8-13 are only used for uplinks and all have a bandwidth of 500KHz. The data rate used for downlinks (messages from the gateway) will match the Spread Factor used for the uplink. For example, DR11 will be used for a downlink if DR3 was used for an uplink as they both use SF9. An exception is again made for DR6, which uses DR13, the same as DR5. A table of Data Rates (DR) with associated spread factors and bandwidths is given below.
In Class C mode, the receive windows are open all the time, except when the end-device is transmitting. This means that commands will come through with very low latency, but due to the receiver being permanently on, power use is greatly increased. Therefore, most battery powered nodes will not use Class C mode. Telemetry2U only recommend using Class C for the LT22222L I/O controller and the RS485LN as they are designed to be powered from an external 12V source.
Telemetry2U takes advantage of LoRaWAN’s Adaptive Data Rate (ADR) setting in most circumstances. With ADR turned on, the Data Rate (DR) along with the Transmit Power (TXP) are automatically adjusted until the optimal performance settings are found with a trial-and-error type approach over around 20 cycles. The server analyses things like packet length, packet loss, signal strength to the gateway (RSSI) and network capacity to make the small adjustment when deemed necessary. This ensures that the most efficient data rate and transmit power are used for every environmental and operating condition. It also helps increase the networks capacity since signals on different data rates are nearly orthogonal, meaning gateways can receive different data rates on the same channel at the same time. In some cases, the server might lower the data rate of end-devices to attempt to increase capacity but also decrease the transmit power to compensate.
The only time the Adaptive Data Rate can cause issues are when the end-devices position is not static i.e. GPS node on a moving vehicle of some kind. In cases like this, it is best to hard fix the DR or the ADR algorithm will be constantly adjusting due to the constant changing conditions, thus making the system less efficient. When the DR is manually configured, the transmit power will always be set to the maximum with Dragino products.
It is often better to add more gateways to a system even if network capacity has not been reached so higher data rates are more probable and message retries are lowered, again extending the end-devices battery life through saved airtime, which will save money over the long term. Extra gateways will also increase downlink command capacity and reliability since LoRaWAN gateways cannot receive data while they are transmitting.
LoRaWAN Security
All LoRaWAN end-devices are programmed with a 64-bit DeviceUEI (DEVEUI) and a 128-bit Application Key (APPKEY) that must first be entered into the Telemetry2U network server data base before an Over The Air Activation (OTAA) can establish a connection. When the end-device joins the network, it is given address (DevAddr), a Network Session Key (NwkSKey) and an Application Session Key (AppSKEY).
The 32-bit device address is defined by the network server and represents device information like the region and configuration.
The 128-bit network session key is used to detect message tampering and is shared with the network server. It is used to validate each message with a Message Integrity Check (MIC) that works in a similar way to a checksum.
The 128-bit Application session key is kept private and is used to encode and decode the message payload between the end-devices and the network.
Both session keys are unique for a device and its current session so are regenerated every time a new connection is formed. It is possible for unwanted users to intercept LoRaWAN packets, however, they will be unable to decode or modify the messages without the private session keys. Telemetry2U can also detect if a message has been re-transmitted by keeping track of the frame counters. The frame counters are set to 0 when a connection is formed and are incremented by 1 every time an uplink or downlink is made. The network server and the end-device will keep track of the frame counter and if a message comes in with a lower frame count, it will be ignored.
Typical Power Cycle
Calculating battery life for IoT products can be a little tricky due to the various operating modes, each with differing power levels and timing. Power consumption usually concerns only Class-A and Class-B end-devices since Class-C end-devices are usually externally powered. Since Telemetry2U does not support Class-B operation, we have decided to base all or our power calculations on Class-A end-devices.
A Typical Dragino power cycle is shown above and is broken down into sample time, transmit time, receive delays, and receive times for both Rx1 and Rx2. Outside of this cycle, the end-device is in a low power sleep mode that is typically <5uA.
Sample Time
The sample time and power requirements will vary depending on what configuration the end-device is running, often determined by what sensors are connected to the inputs. Different sensors will require longer sampling delays to make sure reading are stable. During this period, the processor is awake drawing some amount of power that is combined with the sensor power. The power used during this stage can vary greatly but is usually between 1-20mA.
Transmit Time
This is the period where the end-device is actively uploading its data to the gateway and will vary dependant on the Data Rate (DR) settings and the Transmit Power (TXP). The DR and payload size dictate the length of the transmit period, making it possible to predict. The amount of power used is dependent on the TXP setting and needs to be taken by measurement in most circumstances. If the Adaptive Data Rate (ADR) is turned off, the Transmit Power will always be at its maximum setting (TXP=0). In practice, Telemetry2U use the ADR so the transmit power and data rate will dynamically vary depending on signal strength and environmental factors. After transmitting, the end-device will enter a low power sleep mode for a 1 second period before opening the first receive window (Rx1).
Receive Time(s)
LoRaWAN Class-A uses two receive periods that are exactly one and two second after every transmit period (on AU915 band). This is where both message confirmations (CFM) and control commands can be sent to the end-device(s) from the network server. The power used during these windows vary slightly but are usually around 20mA. The receive window period for Rx1 will vary depending on what DR was used for the uplink, remembering that the DR used for the downlink matches the SF of the DR used for the uplink. The Rx2 windows is always set to receive on DR8, to increase the chance of the message getting through by giving it the most airtime. Window time also depends on the downlink payload size and if message confirmations are turned on (CFM=1) or not. Telemetry2U usually configures end-devices to use message confirmations on all uplinks, meaning the network server will send back a message to the Dragino end-device containing the MAC Header (13-Bytes), which includes the message confirmation flag, as well as some other network information. Message confirmations give the packet a much greater chance of hitting the server. If the Dragino end-device does not receive the message confirmation back from the server, it will re-transmit the message up to 8 times, each time using lower data rate and a higher transmit power where possible.
With all the above in mind, there are three possibilities during the receive windows (Rx1 and Rx2) that are outlined below.
In some cases, message confirmations can be turned off (CFM=0) and no downlink command will be sent from the network server at all (unless a control command is in the que). In this instance, nothing will be received in either receive window, so the period is dictated by the Rx window time-out which can vary between 10-100ms depending on the DR and end-device configuration. Without message confirmations, it is possible for uplink messages to get los as they will not be resent if the server does not receive it the first time.
Telemetry2U prefers to use message confirmations to ensure that all uplinks make it through to the server. In this instance, the end-device is sent a 13-Byte MAC header back from the server that contains the message confirmation flag among other things. The time it takes to receive the downlink command again depends on the DR used, the lower the DR, the longer it takes to receive the packet. If the end device does not receive the confirmation message in the first window, it will open the second window after the 2-second delay as shown below in figure 6.
In some cases, message confirmations can be turned off (CFM=0) and no downlink command will be sent from the network server at all (unless a control command is in the que). In this instance, nothing will be received in either receive window, so the period is dictated by the Rx window time-out which can vary between 10-100ms depending on the DR and end-device configuration. Without message confirmations, it is possible for uplink messages to get los as they will not be resent if the server does not receive it the first time.
Sample Time
If the Dragino end-device is not sampling, transmitting, or receiving, it is in a low power sleep mode. Dragino end-devices usually draw well under 5uA but it is dependent on what sensors are connected to the inputs and what power rails they are connected to. DS18B20 temperature sensors are connected to the main power supply that is active while the device is sleeping, meaning the 1uA sleep current of the sensor must be added to the end-devices sleep current. The sensors active power must also be added to the end-devices sampling power for accurate power calculations.
LoRaWAN Power/Timing Measurements
These measurements were taken with a Dragino LSN50v2 with as DS18B20 Temperature Sensor attached. All measurements very closely match what Dragino have in their relevant documentation
Figure 7. compares measurements taken using DR0 and DR5 for an 11-Byte uplink from a Dragino LSN50 (running MOD1) with confirmations turned off (CFM=0) and a DS18B20 temperature probe attached. While using DR0, Rx1 and Rx2 both listen on DR8 for downlinks, with on-times around 60ms each, totalling 120ms. When using DR5, Rx1 is powered for roughly 25mS with Rx2 (still using DR8) on for 60ms, totalling 85ms. Either way, the total receiver on-time is less then 120ms, even in the worst case.
Figure 8. is measured from the same set-up as Figure 7, except confirmations are turned on (CFM=1). While using either DR, the confirmation message is received from the network server during the Rx1 window, so there is no need for Rx2 to open. The 13-Byte MAC header takes 288mS to receive on DR0 and less than 15ms on DR5.
Clearly, the most time efficient network is formed when confirmations are turned on while using the highest Data Rate. In this state, the transmit and receive window times are both at their lowest. This again highlights the importance of using more gateways to improve network performance while extending the overall battery life on the end-devices and reliability.
