"LoRaWAN drives IoT applications - it'll be responsible for connecting the next billion devices to the internet
This page explains LoRaWAN and how it works with Telemetry2U
LoRaWAN 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 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 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 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 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.
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 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.