On average, the U.S. experiences about 70,000 wildfires annually (EPA, 2025). In 2023, over 56,000 fires burned nearly 2.7 million acres, destroying 4,318 structures, including 3,060 homes (NIFC, 2024; Center for Disaster Philanthropy, 2024). Research suggests that reducing wildfire response time by one hour can significantly decrease the likelihood of a fire becoming large-scale, while delays increase the risk of rapid spread (USDA Forest Service, 2023). Therefore, we were on a mission to detect fires in their earliest stages and deliver real-time alerts to first responders within 5–10 minutes, enabling faster deployment and more targeted suppression efforts.

Our system promotes environmental stewardship and community resilience in the face of rising wildfire threats. By enabling early detection it gives first responders a critical head start, reducing the likelihood of large-scale destruction to homes, forests, and lives. The low-cost, low-power mesh network ensures coverage even in remote areas, making wildfire protection more equitable and accessible. Beyond its technical function, the project also raises awareness around the importance of preparation overreaction, highlighting that investing in early warning systems and proactive solutions is far more effective than responding after disaster strikes.

Implementation

The solution we thought about was sprinkling nodes in a forest to be smelling for fire. Once it gets a whiff of fire, it will alert an operator that there might be a fire. To complete this solution, we need a node that has sensors whiffing for fire attributes, a ML algorithm that fuses the sensor readings and can detect if it is a fire, and a wireless mesh network to relay that critical piece if it is a fire.

The system is built around four main components:

• ClusterDuck Protocol
• MamaDucks
• PapaDucks
• Analytics Dashboard

ClusterDuck Protocol

With a press of a button, the MamaDucks and PapaDuck connect with each other using OWL’s open source protocol, the ClusterDuck Protocol (CDP). The CDP is a simple, low-cost, and low-power self healing mesh network for IoT that operates in remote and infrastructure-limited environments. In wildfire prone areas where cellular or Wi-Fi coverage is unreliable, CDP allows devices to pass packets between one another until they reach a connected node (PapaDuck), which pushes the data to the cloud. By leveraging CDP for our system, we create a robust connectivity system capable of relaying critical information such as early wildfire detection.

MamaDuck

Each MamaDuck is a Lilygo TTGO TBeam with a SX1262 LoRa chip and a NEO-M8 GNSS Module with a BME 688 module soldered into it. It handles three main tasks:

• Sensing — The BME 688 is a gas sensor that collects environmental data (temperature, pressure, humidity, gas levels)
• Detecting Wildfire — Runs on-device ML inference. We are using a Random Forest model due to its low resource constraints. Since Random Forests don’t capture time-based patterns directly, we add rolling statistics, volatility and velocity, to provide temporal context for each reading. Inference results are packaged and sent just like sensor data.
• Packet forwarding — It receives data from nearby nodes and relays it to other Ducks, maintaining the mesh network.

PapaDuck

The PapaDuck is the bridge that connects the CDP mesh network and the Internet. We used a basic WiFi PapaDuck. All it needs is WiFi credentials to connect to the Internet.

Analytics Dashboard

Once the data was pushed to the cloud via a PapaDuck, we used OWL’s APIs to extract that data and inject it into our analytics dashboard, where users can monitor real-time sensor readings and Duck status seen below

Furthermore, we can observe where data points are being recorded from the MamaDucks on our dashboard seen below. If a data point collected has been inferred to be a wildfire, an alert will be sent to authorities containing details of the measurement as well as the GPS coordinates of the MamaDuck that detects the wildfire.

Testing

These nodes were tested with two main goals; training the machine learning model on both fire and non-fire present areas and the ClusterDuck protocol running alongside said model in parallel to ensure no bottlenecks. We replicated as many common factors as we could between the first forest we were planning to deploy (Kaibab National Forest) in our own local environment. Following the location we set up our nodes at varying heights and distances and monitored the readings prior to any fire being present. Finally we introduce a fire, done safely in a campfire style, to start getting data with a fire present. This here is the main challenge with the project, but as many factors as could have been replicated where and the model accuracy reflected the data quality. Visualization of the data collection efforts can be observed below.

In red, is the node placed nearest to the fire, blue being furthest. Below, see additionally the deployment structure of the nodes. In total around 15,000 readings were collected and stored with around 800 determined NULL due to collection being done during sensor calibration periods.

Wrap Up

This is a potential use case and not the final solution. The testing was completed through a replication of what a wildfire might entail, but in no way representative of collecting data during a real wildfire. Ideally the first deployment of these devices is a monitor to collect measurements from different parts of a large forest. With this data high risk areas can be detected by locating high temperature low humidity areas more conducive to fires. Then if a wildfire were to break out invaluable data could be collected and used to train a fire detection model. Alternatively a controlled forest fire could also replicate the data to train the model. In addition to this the only step needed is ensuring self sufficiency from each node by adding solar power to the nodes rather than relying on batteries.

This solution would help anyone with a need to monitor a large area susceptible to fires, where early response could minimize the damage. Organizations both in charge of and owners of wildlife preservations could use this system to monitor their environment, but more importantly quickly respond to wildfires. Farmers, specifically with dry crops such as wheat which could easily catch fire would find value. The United States Government, which oversees the majority of the forest in the United States, would find a smart investment in the preservation of their land with a system to minimize losses in an area where the problem is at an all time high.

CONTRIBUTORS:

Eric Rodriguez, Kortney Curry, Prabhath Naidu Adireddi, Sai Shiva Satwik Mallajosyula

Fire Alert System was originally published in ClusterDuck Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

In November 2023, my companion, Mohammad Waris Ali, and I embarked on an adventure to explore the Langtang Valley in Nepal with the goal of reaching Tsergo Ri, a peak standing at 5,033 meters. Lantang, being part of the Himalayas, naturally attracts many tourists around the world because of its beautiful views.

However, this was not the only reason we were on this week-long trek. Not only does Lantang attract tourists but it also attracts natural disasters such as landslides. Taplejung, only a couple of months ago, experienced a landslide that left the area contactless for days. Also, people suffer emergencies during their treks with nowhere to seek help. In January 2023, a South Korean woman was found dead in Thorang La Pass, the world’s highest pass. It highlights the importance of being aware of the unique risks associated with high-altitude trekking and ensuring that emergency response and communication resources are readily available to address unforeseen challenges and emergencies.

Coming from a tech background, being a frequent trekker, and residing in one of the most disaster-prone regions of Asia, I want to contribute to effective disaster management; whether it’s a natural disaster or health emergency. I wanted to witness disaster scenarios and understand their frequency in the region. It was important to survey the challenges people face in remote areas like Langtang, where there is a lack of internet, electricity, and reliable cellular communication. This trip allowed me to see firsthand the vital importance of establishing communication channels in such critical situations, particularly for post-disaster recovery, where timely assistance can be a matter of life and death. Indeed, the region has already experienced devastating disasters, such as the 2015 earthquake that wiped out the main village and took over 300 lives. Landslides and avalanches are constant threats, especially in close proximity to human settlements. Due to the remote location of this region, being far from the city and capital, post-disaster recovery becomes an even greater challenge. It bridges the gap between remote areas and the rest of the world, ensuring that help and information can reach even the most secluded communities. The need for reliable communication and assistance in such critical situations is evident, as these remote areas are particularly vulnerable to the devastating impacts of natural disasters.

The area affected in the above video is really huge, there was an entire village before 2015 earthquake. For size reference, there is a well-grown Himalayan Sheepdog crossing the bridge.

I discovered OWL while conducting a literature review for my bachelor’s thesis on disaster management without relying on cellular and internet connections back in 2022. As someone with a background in cybersecurity, I have a preference for open-source tools and applications, and the ClusterDuck Protocol (OWL’s open-source firmware) piqued my interest. Since that initial discovery, I’ve been fascinated by CDP’s capabilities and potential applications in the field of disaster management, especially in disaster-prone nations like Nepal.

The key characteristics of Ducks (the basic unit of the ClusterDuck Protocol) that intrigued me revolved around their reliability, range, and potential for disaster management. Ducks proved to be remarkably reliable, even in the most challenging altitudes and temperatures, as witnessed during the Langtang Valley trek. This level of dependability is essential in regions prone to natural disasters, where communication can be a lifeline.

Initially, we tested the Duck within the elevation of 3000 to 4000 meters to evaluate its communication capabilities. It proved effective for our team of two to stay connected and assess its basic range. The real challenge came when we pushed the device beyond 4,000 meters, subjecting it to extreme cold. At such altitudes, even modern smartphones often struggle, but the Ducks and the ClusterDuck network held up remarkably well. To examine its range from high elevations to lower ones, we left one of our Ducks in a Yak shed at approximately 4100 meters. We instructed the shed owner to monitor messages and respond if they received any. We got a range of around 4 km in a 915 Mhz frequency channel. A few times we had a problem with the Lora connection between two duck devices. Since we didn’t have a laptop with us we were unknown what caused that.
The concept of establishing a mesh network with Ducks was particularly fascinating, as it could create a self-sustaining communication infrastructure, critical in disaster scenarios. The network concept behind Ducks is clever and reminiscent of a walkie-talkie network (Not exactly the same).

Talking about the key characteristic of Ducks, it demonstrated a high level of reliability, even in extreme conditions and at high altitudes, as described in the Langtang region trek. This reliability is crucial in disaster-prone and remote areas.

Talking about the usability of ducks, setting up a clusterduck network was surprisingly straightforward once the firmware was burned into the hardware. The compact size of the Ducks made them highly portable, similar to a mobile device, and this ease of use was particularly advantageous during our trek in Langtang Valley. The captive portal of the network was straightforward and intuitive, making it accessible to users of various age groups who are familiar with using mobile phones. With a little training on the captive portal’s functionalities, users can harness the full potential of the application, enhancing the effectiveness of the Duck network for communication and connectivity in remote and challenging environments.

One notable improvement with this Duck was its stability. In previous versions, we encountered issues like the LoRa connection disconnecting on its own or not connecting even when devices are in close proximity. This version showed significant progress in terms of reliability.
One feature that could significantly enhance the Duck is the inclusion of a small screen that displays the list of Duck devices within range and their respective connections. Additionally, the implementation of a network monitoring tool, similar to Nagios, could complement the Duck Device Management System’s (Duck DMS) existing map, which illustrates device locations. By deploying a network of Ducks in specific areas and establishing a base station with an internet connection, this monitoring tool could track device connections and the formation of a mesh network. This capability would be instrumental in visualizing any connectivity issues during deployment and identifying potential breaks in the mesh connection. But the overhead is that there must be a network monitoring packet like SNMP (Are you alive packets) sent to all the devices in a certain interval of time. I would love to contribute to the development of this visualization tool if it happens.

• On the way to Peak
• Duck Device (CDP)

Elevating Disaster Resilience was originally published in ClusterDuck Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview

At our outdoor camp in Ohio, we utilize over 200 acres of maple trees to create delicious maple syrup. Our process involves tapping each tree with 1–2 taps and connecting them to lateral 5/16" tubing. These lines are then connected to 1 of 7 main lines, made of 1" plastic tubing, which transport the sap downhill to sap collection tanks. To maximize production, we have implemented a vacuum system that runs throughout the entire system. This innovative technology has had a significant impact on our syrup production, allowing us to create more syrup than ever before.

Our camp contains a total of over 900 taps, connecting 700 trees in total. On a good day over 2000 gallons of sap can be collected. It takes 60–70 gallons of sap to make 1 gallon of syrup. Last year we collected 24,000 gallons of sap and produced close to 300 gallons of finished syrup!

As you can imagine, producing maple syrup at this scale is a highly labor-intensive process, and we rely entirely on volunteers to make it happen. However, by automating certain aspects of the process, we are able to significantly increase efficiency and streamline our operations. By leveraging technology to our advantage, we can produce maple syrup more efficiently and ensure that we are able to provide a high-quality product to our customers.

Vacuum and Temperature Monitoring

With all the tubing and the connectors, there are many places where the tubing can leak and loose vacuum. If it does leak, it would be very hard to pinpoint where it is in the 200 acre of land. For a solution, I created sensors built with Arduino micro controllers to monitor vacuum and temperature. If there is any abnormality in the readings, then we would know exactly where the leak is and fix it right away.

These devices are placed at the ends of each of the main sap lines. If it is deployed at the end of each main sap line, how do we get the readings?

The first option was utilizing Wi-Fi. We can use Wi-Fi to send sensor readings to the cloud. However it was not the optimal solution. One major problem was power. Wi-Fi consumes a lot of power and there is the lack of electricity in forests. Previously, I used a 12 volt car battery connected to a Wi-Fi access point to provide Wi-Fi. Sensors would connect to Wi-Fi and publish sensor readings. Another problem was the distance. The sensors are 300–400 yards from the closest relay/gateway device. Wi-Fi was not supportive of long range communications. The last problem was unreliability of Wi-Fi. Obstructions (trees, hills) and weather made Wi-Fi access points unreliable at times.

This is where the ClusterDuck Protocol (CDP) comes in. CDP is an open-source firmware that leverages LoRa to wirelessly communicate with internet-of-things devices called Ducks. CDP allows for greater distances without the need to adding Wi-Fi access points out in the woods. And best of all, it is a low power wireless ad hoc network (LPWAN). This simplifies the process and, in my experience, is much more stable than Wi-Fi.

We integrate the CDP into the sensors so that all the data from the sensors relay through the trees back to our maple barn. Leveraging CDP allowed us to monitor the maple syrup production in real-time.

Design of MapleDuck Network (2023)

Sensors

• Heltec WiFi LoRa 32 V2 boards
• Onewire temperature sensor
• Adafruit MPRLS Ported Pressure Sensor
• 90X60mm Micro Mini Solar Panel Cells
• 18650 battery

PapaDuck

• gateway LoRa + Wi-Fi
• TTGO T-Beam board — Connected to power

Raspberry Pi

• Apache web server
• Mosquito MQTT server

How Does The Network Deliver Data

The sensors take readings of vacuum and temperature from the environment every 10 minutes. Then they broadcast these readings to the to nearby devices and then goes to sleep (to preserve battery) until it is time to read the sensors again or it receives a message to relay.

The messages are relayed from device to device until it reaches the PapaDuck (the gateway). When the PapaDuck sees the LoRa message, it decodes the CDP message and publishes a message over Wi-Fi to MQTT server.

In the maple barn I have a Raspberry Pi running Mosquito, and Apache. As the readings are published to the server, they are displayed on a web page. With the current setup 90X60mm Micro Mini Solar Panel and 18650 a battery, several of the sensors have been running 5 weeks with no issues.

Tank Level and Temperature Monitoring

Along with the Vacuum/Temperature sensors, I have built Tank Level Sensors. These use a Maxbotix Weather-Resistant Ultrasonic Rangefinder — MB7092 XL-MaxSonar-WRMA1 to measure the distance from the top of a tank to where the sap is located. We have 6 different tanks varying in sizes from 150–1500 gallons. Most of these are retired bulk milk tanks, horizontal cylinders. I convert the volume into gallons of sap. These sensors are using WeMos D1 WiFi Arduino Development Boards. Readings are taken every 30 seconds a sent to the MQTT sever. These are close to power and Wi-Fi, so I have not converted these to LoRa

At the moment, I am working with the ClusterDuck Protocol open source community to provide some feedback and improve the network. In addition, I am in the process of finalizing the microprocessing board. I used Heltecs but maybe CubeCell might be a better option. Also Onewire temperature sensor integrated with CDP network. The end goal will be automating the entire process to significantly increase efficiency and streamline our operations.

Using ClusterDuck Protocol to Monitor Vacuum and Temperature in Maple Syrup Production was originally published in ClusterDuck Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

To make CDP more resilient, we needed to take it a step further by solving the issue of getting the messages to the cloud and into the DMS when Internet infrastructure goes down. Through research and development, the solution I came up with is to integrate satellites into the CDP.

The concept is that CDP will work normally as intended. When the PapaDuck receives a message, it will send it to the DMS using a WiFi connection. The moment when the PapaDuck cannot establish a connection to the Internet, the PapaDuck will evolve into a DishDuck, a Duck that can communicate with a satellite. It will send the messages to the satellite and when the satellite receives the messages, it will send the message back down to the DMS. It will continually send messages through the satellite until the PapaDuck regains Internet connection. To establish the connection with a satellite, we need to integrate the RockBlock 9603, a small form factor low power Short-Burst Data modem.

The RockBlock utilizes the Iridium Network, a network of 66 satellites in the Earth’s orbit that allows for devices to send Short-Burst Data. Using the Rockblock, the PapaDuck can bounce the data off one of the 66 satellites to the DMS when an internet connection is not available or goes down (Fig 1.2).

And it works! We applied the DishDuck in one of our recent deployments in space! The SpaceDuck was the payload that had the RockBlock in it and it was attached to a weather balloon. The goal was to launch the balloon and keep the connection locked in throughout the whole flight time. There was a ground station that was attached to a Yagi antenna to collect the packets that the SpaceDuck was sending. However, as it goes up and up, there might be a chance that SpaceDuck might lose connection with the ground station. That is when the DishDuck kicks in. The DishDuck will be sending data to the satellite so that if the SpaceDuck does lose connection, there is a backup to ensure that the data will still be received.

Watch the Full SpaceDuck Documentary

Now this makes the Ducks more resilient to unstable or crippling existing internet infrastructure taking the CDP a step further into making it a fully resilient network. Integrating the DishDuck will allow anyone to retrieve sensor data or emergency messages from anywhere globally without worrying that they will miss any emergency messages or sensor data readings due to failures in WiFi or LTE connectivity. As for some future work it is in our hopes that we can access cheaper and higher throughput satellites or even create a LoRa satellite service.

Integrating Satellite Communications into Clusterduck Protocol was originally published in ClusterDuck Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

BMP180 is a great way to start learning how to integrate sensors with DuckLinks. The BMP180 are these really small sensors that collect temperature and pressure. It requires three steps: Soldering the BMP180 to a board and Uploading the firmware, and Collecting the data.

The BMP180

The BMP180 has four pin holes: VIN, GND, SDA, SLA. The VIN is the input voltage. This is where the power source goes into. GND is the ground. SDA stands for Serial DAta and SCL stands for Serial CLock. These are special pins used to transfer data. We can solder these BMP180s to both the Heltec ESP32 and TTGO T-Beams.

Soldering to the Heltec ESP32

The ESP32 board has many pins but only two of them correspond to the SDA and SCL. So we have to make sure we solder in the right places.

Uploading the Firmware

The next step is to upload the firmware from the ClusterDuck Protocol. (If you haven’t cloned the repo, check out our wiki on how to do that. [LINK]) We can get the BMP180 example by opening Arduino then File -> Examples -> ClusterDuck -> examples -> 3. Sensor-Examples -> BMP180Example.

That should open up the BMP180 example. Two things I like to change for preferences is the name of the Duck and the frequency we send the data. To change the name of the Duck, we go to line 37:

std::string deviceId(“MAMA0001”);

Replace MAMA0001 with a name of preference. The name has to be 8 characters long and inside quotes.

To change the frequency we send the data, we have to go to line 30:

const int INTERVAL_MS = 60000;

And replace the 60000 value with another value of preference. This value is in milliseconds, so right now it is sending data every 60 seconds. If we only need to take measurements every hour, we have to convert 1 hour into milliseconds (1 hr = 3600000 milliseconds).

Collecting the Data

There are two ways to get the data. One way is to register for the Duck Management System (DMS) or if you would like a local solution, you can make a DMS-lite.

So now we finished the set-up, we can deploy the Ducks and watch the data flow!

User Case

I have already deployed three Ducks named Gotham00, Central0, Mtrpolis, with BMP180s around my house. Each duck sent temperature and pressure reading every 30 minutes and I collected the data for about a week. These are the some data graphs I have created:

Hope you enjoyed this tutorial of integrating a BMP180 with a Duck. We will be doing more integration blogs. If there are any specific sensors you would like help with or have any questions and/or comments join our ClusterDuck Protocol community and give us a quack in Slack.

Learn more about the ClusterDuck Protocol

Setting up a BMP180 using the ClusterDuck Protocol was originally published in ClusterDuck Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

There has been a lot of interest in LoRa over the last few years in the IoT space for its long range, low power, and low cost of both hardware and electrical requirements. Platforms (like SigFox, The Things Network (TTN) and now the ClusterDuck Protocol), have made getting started with LoRa and IoT easy by providing wireless hardware and software infrastructure. We can easily connect our device to services we build ourselves. The benefits of LoRa intrigued the interest of people in the natural disaster sector. The natural disaster sector has been stuck with a problem: “How will we be able to communicate in the event of a disaster when mobile communication networks aren’t available?” And they believe that LoRa might be a viable solution. Current research is being done to leverage LoRa technology solve this problem. We will explore this subject using a few research papers that propose network architectures pursuant to this problem.

LoRa Modules, Meshed

Let’s start with how LoRa’s characteristics and how it can be used in a mesh network. In our first paper, Pham, Kisel, et al [1]. examine LoRa’s capabilities in mesh networks using OMNET++, a popular piece of network simulation software.

LoRa modules can be configured using a few key parameters, which are spreading factor (SF), coding rate (CR), and bandwidth (BW). Explained nicely by Josef Matondang, these three components can be used to determine the data rate (DR), given by this equation:

Noted by the authors, high BW increases the data rate, but decreases coding sensitivity. High SF increases decoding sensitivity but decreases the data rate. The typical LoRa mesh is going to look like any other wireless mesh you’ve encountered. The authors give this figure to illustrate.

Routing selection is done via Received Signal Strength Indicator (RSSI), a common method of metric for measuring the strength of a signal. Here it’s being used to determine the cost of a link between two nodes, which can be used to determine the total cost of any route. The algorithm always chooses the link with the lowest cost.

When simulating the network, a propagation model that considers an urban setting where devices have structures in between them. Payload is generated randomly and there is a gateway node in the center of the network. For completeness, you can see the simulation parameters here in one of the paper’s tables.

Now let’s look at their results. Below are Figures 3 and 4 graphing the influence of load intensity and number of relay nodes respectively, on delivery latency.

High spreading factor on increasing loads leads to considerable jumps in latency but can be counteracted by increases in bandwidth. This tracks with the original equation that model’s data rate. Interestingly latency numbers seem to converge on SF = 9, BW = 125 and SF = 10, BW = 250. The number of relays is also quite important here, showing a similar arrangement of linear relationships. Notice again the convergence of the previously mentioned spreading factor-bandwidth pairs. The relationship between spreading factor and latency is further intimated by the authors when increasing the node count to 100, showing the high SF means longer transmission time.

The number of nodes in the network makes more interesting data. When there are more nodes, there are more packets generated. With more nodes to travel through, the latency is higher and there are more chances for a packet to get lost. The authors find this in Figures 6 and 7 below.

This should give us some good intuition about LoRa and how a mesh network would operate using it. Next, we’ll look at some problem-based solutions being researched today.

Phone, Meet Network

Our second paper is out of the University of the Philippines from Macaraeg, Hilario, et al. [2] It looks directly at our topic of off-grid communications by evaluating LoRa’s ability to serve as a text message delivery medium. The work is accomplished by implementing an ad-hoc on-demand distance vector (AODV) routing protocol using received signal strength indicator (RSSI) for the routing metric.

The network assumes a mobile phone is available to the user, and a LoRa transceiver is present. The LoRa transceiver is on an ESP32 development board along with a battery and bluetooth submodule. This will allow the phone to exchange information over the network as shown in Figure 1 of the paper.

The AODV routing mechanism using RSSI as the distance metric (RSSI-AODV) is chosen by our authors because of it correlates well with peak data rate (PDR). The routing is described by Figure 3 of the paper.

The experimentation includes two sets of tests; one point-to-point test and a multi-hop test. The point-to-point test has two nodes on the ground, with clear line of sight between nodes. The authors have shown reliable communication beyond 800 meters using packet size groups of x<25 bytes and 256>x>25 bytes. Results of the PDR performance are detailed in Figure 4.

However, in a more “real-world” scenario with obstructions in between nodes, the authors indicate a PDR of only 50% with a distance of up to 300 meters.

In the second set of tests using a multi-hop network, the authors implement two network structures shown in Figure 7 of the paper.

The tests are then run using both AODV and RSSI-AODV and monitor the route from source to destination. In confirming the route, the packets do take path with higher RSSI as expected. In Figure 8, it’s shown that PDR deteriorates wit hop count, consistent in AODV and RSSI-AODV and across both spreading factors evaluated.

The authors note that this type of network could cover a 5-square km area for around USD$240 at the cost of USD$40 per node. Since smartphones are ubiquitous in the Philippines, the deployment of such a network should be negligible with the assistance of local governments.

What If the Users Could Help Each Other?

The next paper in our research battery examines a network that links each person into a sort of mutual aid infrastructure using LoRa as the wireless network. They call this strategy LOCATE.

This work out of University of Bologna in Italy [3] seeks to disseminate emergency requests (E-REQs) throughout a LoRa network where each node is phone connected via USB to a LoRa radio. The E-REQ should eventually encounter another node that can solve the emergency.

The messaging system follows a dissemination strategy that uses a timer set when a node in the network receives an E-REQ. When the timer is up and no emergency solver (EV) is identified, the node passes the message to other nodes in the network. The authors described the strategy visually in their Figure 5.

The timer is referred to as a “contention window” and is described by

Where CWacc is the acceptance contention window, or the time a node will wait for an EV. Our exponent in e determines how close or far away priority should be given to potential solvers, as d(as, aj) is defined as the distance between the emergency source and the receiver node. For this contention window, priority is given to nodes closer to the source to win the contention. since nearby solvers might be able to reach the emergency source sooner.

For forwarding the E-REQ, there is a forwarding timer with a very similar equation.

This prioritizes the nodes further from the source node, so the message can be spread as fast as possible.

This was all done in phase 1 of a transmission. In phase 2, those that have received a message give an emergency response (E-REP), disseminated over this same scenario. This entire protocol is tuned using an epidemic diffusion model, where whether or not to actually send out the E-REQ message is determined probabilistically so as to not flood the network. How to tune this p∗ value is discussed further in the paper, but that’s enough math for now.

The simulation results of this strategy look promising. Several strategies were evaluated, but we’re going to look at the LOCATE scheme vs flooding and continuous dissemination in the graphs from Figures 11 and 12.

Here, the emergency resolution rate (ERR) is far and away an improvement over continuous dissemination, which is the probabilistic dissemination scheme without any analytical tuning. Even flooding is outdone here, as the ERR really picks up at 20 nodes and beyond.

For the emergency response time (ERT), the LOCATE scheme employing the probabilistic tuning again outpaces both continuous dissemination and flooding, indicating that not rebroadcasting the E-REQ from every node is key to good performance of the network. But wouldn’t it be nice to have an overhead metric? Well, University of Bologna does happen to report that as well.

The overhead of LOCATE does spike at 20 nodes as the other metrics do, but tapers off the more you have. This makes sense given that greater number of node means fewer actually have to disseminate the message. Even so, the overhead of LOCATE at its worst is better then both continuous dissemination and flooding at their best.

Now what about actual experimental results? Empirical data is always best, so let’s see those results.

Again, the LOCATE scheme performs better on each metric, although emergency overhead (EO) seems to grow much closer to flooding’s overhead. It should be noted that varying the number of solvers in the LOCATE scheme has a noticeable impact, shown in the paper. It should also be noted that the attempts to use 802.11 with the LOCATE scheme did not go well, further enhancing our desire to use LoRa.

Closing Thoughts

We’ve seen three different implementations of the LoRa technology for disaster relief scenarios. Beyond the development of Doomsday Survival Tech, there are other more mundane scenarios LoRa is being explored such as smart cities. The concept of smart cities is to provide promising opportunities for water safety monitoring, positional sensing, responsive wireless-enabled technology and more. We could have a city where current kilowatt-hour prices are given straight to vehicles so that smart electric cars are aware of the cost of charging up whenever they’re near a charging station. And even smart traffic lights that can detect accidents and communicate with other traffic lights using LoRa to reroute traffic to avoid the accident area? In these scenarios LoRa would be a possible solution since it is a long-range, low cost, low power communication standard. There are some limitations to LoRa such as the limiting power transmission and low bandwidth, and that is why there is still research being done to navigate through these limitations. I am very interested in the implementations of LoRa and hope to be in the forefront on these research topics, whether it be for disaster relief or improving the daily lives of people.

The graphs and tables are from the research papers summarized within the article.

1. Pham, V. D., Kisel, V., Kirichek, R., Koucheryavy, A. & Shestakov, A. Evaluation of A Mesh Network based on LoRa Technology. 2021 23rd International Conference on Advanced Communication Technology (ICACT) 1–6 (2021) doi:10.23919/icact51234.2021.9370792.
2. Macaraeg, K. C. V. G., Hilario, C. A. G. & Ambatali, C. D. C. LoRa-based Mesh Network for Off-grid Emergency Communications. 2020 Ieee Global Humanit Technology Conf Ghtc 1–4 (2020) doi:10.1109/ghtc46280.2020.9342944.
3. Sciullo, L., Trotta, A. & Felice, M. D. Design and performance evaluation of a LoRa-based mobile emergency management system (LOCATE). Ad Hoc Networks (2020) doi:10.1016/j.adhoc.2019.101993.

Research in LoRa: The Disaster Communication Networking Space was originally published in ClusterDuck Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.