What is LoRaWAN® Sensors?
LoRaWAN® Sensors
A sensor is perhaps the most commonly used type of end node for IoT networks. While IoT is a technological milestone of the past few years, sensors have been around for many decades, starting with the conception of the first thermostat in the 1880s. With the ever-increasing popularity of IoT solutions, the importance of sensors will be all the more important. They are inside our homes, in buildings, in space, and in some cases, even inside our bodies. LoRaWAN® enables sensors to operate longer on a single battery charge as they have the ability to run on a standby mode when no data needs to be transmitted or received. Also, due to their low bandwidth, their range is much further than that of typical cellular connectivity protocols, such as 3G, 4G or 5G. Both of these factors combined, make the deployment of IoT enabled sensors at a larger scale much more viable.
The integral role of sensors in an IoT environment
Sensors are devices dedicated to detecting specific changes in an environment. These changes can be measured through different inputs, such as voltage, light, temperature, pressure, motion etc. Actuators are the polar opposite of sensors; they do not collect information but “act” based on instructions. Actuators and sensors are the most crucial components of a functional IoT environment. By upgrading sensors and making them IoT-enabled, the deployment, operation, and maintenance of these sensors can be scaled, which greatly reduces costs.
What are the most common IoT-enabled sensors?
Any type of sensor has the potential to be modified into an IoT-compatible (and therefore LoRaWAN®-compatible) sensor. Here are some of the most applicable types of sensors for many IoT and LoRaWAN® use cases.
Temperature sensors
Temperature sensors are the oldest type of sensors. With regards to IoT use cases, they are often utilized in smart homes, health care, manufacturing, and agriculture. Smart homes use temperature sensors to control the AC units (i.e. the actuators), in manufacturing, machines are often at the brink of overheating. An impending malfunction can be detected early on using temperature sensors, so maintenance can be organized in advance. This ability is known as predictive maintenance, and IoT sensors make it possible.
Water sensors
Water sensors are mostly being used in the utility sector. LoRaWAN® solutions with their low power consumption and wide coverage are particularly useful to utility companies that have to check the water levels and the water quality of remote reservoirs. Using this data, potential shortages, or pollutants (which could cause public health disasters) can be prevented.
Infrared sensors
Infrared sensors are used in our daily life. Every TV has an infrared sensor to detect and understand the signals broadcast by a TV remote. In healthcare, infrared sensors are used to observe blood flow and blood pressure.
Pressure sensors
Pressure sensors are mostly used in manufacturing to monitor heavy machinery or mechanical devices that are crucial to the continuous productivity of a manufacturing plant. In smart hospitality, hotels use pressure sensors to determine and control the water pressure of hotel rooms. When guests stay at a hotel, water pressure can be limited to avoid exceptionally high water consumption. As soon as room service enters the room with their dedicated key card, the IoT network can automatically lift the limits on water pressure to allow for faster, more efficient cleaning.
Chemical Sensors
Chemical sensors are used in the environmental sector to detect the release of harmful chemicals or radiation. In the pharmaceutical and food safety sectors, these types of sensors are used to detect potential contaminants.
What is LoraWAN®?
LoRaWAN® is a proprietary LPWAN that was developed by Semtech. It is one of the most promising LPWANs, taking the low-power, wide-area aspect to the extreme. To achieve long-range and low power consumption, LoRaWAN® makes sacrifices in terms of bandwidth and latency. Fortunately, most sensors gather relatively binary, light-weight data that does not require lots of bandwidth to transmit to the server.
A LoRaWAN® IoT network typically consists of:
- An application server running the software
- A network server that enables the communication between the application and end devices
- End devices (That typically feature an IoT SIM Card slot)
- Gateways
- End nodes
- Actuators
- Sensors
While the communication between the network server and the gateways may not always utilize LoRaWAN® as its primary connectivity protocol, the communication between end nodes and gateways almost exclusively happens on LoRaWAN®, since end nodes are more likely to be located in remote locations compared to gateways. In other words, the communication between end nodes and gateway is generally regarded as the biggest bottleneck. Thus this is the place in the network architecture that benefits the most from LoRaWANS® reliability, low maintenance costs and wide coverage.
Where to find LoRaWAN® sensors?
As mentioned, LoRaWAN® technology is proprietary, which means that only certified manufacturers (i.e. members of the LoRa Alliance) are allowed to produce official LoRaWAN® compatible hardware components, such as antennas, gateways (which feature slots for M2M sim cards), and end nodes like sensors.
The Lora Alliance showcases available hardware products on their website, where you can browse through various types of sensors available for custom Lora-based IoT solutions. Network operators who are considering the deployment of a LoRa IoT environment can also filter sensors based on their use case potential in vertical markets, such as smart homes, smart agriculture, transportation, logistics etc.
Some LoRa sensors can gather various environmental changes at the same time. For example, indoor ambiance monitoring sensors are lightweight, relatively cheap, and can measure motion, humidity, temperature, pressure and light.
Different classes of end devices
Common to all classes is bidirectional communication. LoRaWAN® devices and gateways can both send and receive data. Data transmission between devices and gateways can therefore be implemented in both directions, and a clear distinction is made between uplink and downlink transmission. “Uplink transmission” refers to a communication from the device to the gateway (i.e. sensor to gateway) and “downlink transmission” to a communication from the gateway to the device (i.e. gateway to the actuator). A device can perform an uplink transmission at any time. Depending on the class, there are different numbers of transmission windows for downlink transmissions, which open at different times.
Class A
An uplink transmission is always followed by two short time windows for a downlink transmission. In Europe, these usually start 1s and 2s after the end of the uplink transmission. During these two time windows, the device must have the receive mode activated. In the remaining time, the device including the radio part can be set to sleep mode to save energy. If a downlink transmission already takes place in the first time window, the second time window can be skipped. A downlink transmission from the network server is thus only possible shortly after an uplink transmission. If further downlink transmissions from the network server are to take place, it is necessary to wait until the next uplink transmission. It is not possible for data transmission to the device to take place immediately after a downlink transmission has been initiated by the application server. This can result in large delays in the data transfer from the server to the device. All LoRaWAN® devices available on the market must support class A functionality in any case.
Class B
In addition to the two time windows defined in class A after an uplink transmission, additional time windows are available for downlink transmissions. To make this possible, all class B devices in a LoRaWAN® radio network are synchronized. For this purpose, the gateways send out a short radiotelegram, a so-called beacon, every 128s. By receiving this beacon, the devices can synchronize. Between these beacons, there are 4096 defined time windows for a downlink transmission. The network server assigns one of these time windows to the device. In addition to the duration for uplink transmissions and the immediately following two-time windows for downlink transmissions (as in class A), the device additionally only has to wake up at the two known time windows for receiving the beacon and possible downlink transmission. Thus, the device can stay in power-saving sleep mode most of the time. A downlink transmission initiated by the application server can thus be executed by the network server in the allocated time window. The maximum delay is 128s.
Class C
In devices of class C, these time windows are permanently opened for downlink transmission. These windows close only during an uplink transfer. A downlink transmission initiated by the application server can be started immediately. The device can never switch to sleep mode in this operating class.
Power consumption vs delayed downlink transmission
When it comes to particularly power-saving operation, class A is clearly preferable. This results in the lowest energy consumption. It is therefore hardly surprising that most battery-powered terminal devices in a LoRaWAN® use class A. Operation without battery replacement is possible for several years. Devices that are operated with class C have the highest power consumption. Only grid-operated devices are suitable for class C. Class B is a compromise between the long delay of a downlink transmission of class A and the high power consumption of class C.
Different classes serve different use cases
The vast majority of LoRaWAN® sensors utilize Class A. For example, level sensors in public waste containers send their data via uplink transmission at a fixed time interval or after an event. This can be, for example, an exceeding of a threshold value. Downlink transmission is not required in this case.
Class B is suitable for remote maintenance of a machine. The status of the machine can be transmitted to the application server once a day at a fixed interval. Nevertheless, set values existing on the machine can be adjusted by the application server at any time. A maximum transmission delay of 128s is typically tolerated by these use cases.
For bus stations, electronic display boards for departure times with class C can be integrated into a LoRaWAN®. The display can be updated at any time without delay and thus show in real-time when the next bus is leaving. These display boards are always connected to a stationary power grid, which means class C’s trade-off will not inhibit the functionality or cost associated with the maintenance of the electronic display board.
Sources
https://www.nke-watteco.com/products/lorawan/
https://www.thethingsnetwork.org/marketplace/products/devices
https://lora-alliance.org/about-lorawan
https://www.researchgate.net/figure/LoRaWAN-communication-classes_fig4_318866065
https://www.chirpstack.io/network-server/features/device-classes/
https://lora-alliance.org/showcase/search?is_certified=1