Transponder: Support for Localizing Distressed People through a Flying Drone Network

Abstract

Context: In Search and Rescue (SAR) operations, the speed and techniques used by rescuers and effective communication with the person in need of rescue are vital for successful operations. Recently, drones have become an essential tool in SAR, used by both military and civilian organizations to locate and aid missing persons. Objective: The paper introduces Transponder, a Wi-Fi-based solution designed to enhance SAR efforts by tracking, localizing, and providing first aid information to distressed individuals, even in challenging environments such as forests, mountains, and urban areas lacking GSM/UMTS coverage or that are difficult to reach with terrestrial rescue. Methods: Provide an innovative mechanism based on Wi-Fi beacon detection, LoRa communication, and the possible mobile application to leverage the SAR operation. Provide the preliminary implementation of the Transponder and perform its assessment in scenarios with dense vegetation. Results: The Transponder functionalities have been proven to enhance and expedite the detection of missing persons. Additionally, responses to several research questions regarding its performance and effectiveness are provided. Conclusions: Transponder is an innovative detection mechanism that combines ground-based analysis with on-board analysis, optimizing energy consumption and realizing an efficient solution for real-world scenarios.

1. Introduction

Search and Rescue (SAR) operations use logistical and human resources to rescue or protect individuals in distress on land or sea. Various agreements exist for search and rescue operations in maritime and terrestrial areas, including the EUR SAR Plan [1] and Frontex (https://www.frontex.europa.eu/assets/Publications/General/In_Brief_2022/2022_in_brief.pdf, accessed on 28 August 2024) within the European and Atlantic Pact signatory levels. Additionally, various agencies manage national SAR operations. For instance, In Italy, Prefectures coordinate SAR operations [2], while the Italian Air Force, Alpine troops, National Fire Brigade, Financial Guard, National Alpini, and the Speleological Rescue Corps handle the terrestrial aspect of the operations. The Italian Red Cross provides medical support, and volunteer groups can provide search assistance. The Port authorities and Coast Guard are responsible for maritime SAR operations. During operations, protocols and procedures are followed regarding internal and external communications and operational aspects. In the following, some points regarding operational procedures will be clarified with the assistance of available documentation, provided by the involved government entities.

Numerous national and international military organizations use Unmanned Aerial Systems (UAS) for Search and Rescue (SAR) operations. Drones are mainly used for search and rescue operations related to helping distressed individuals. Additionally, autonomous groups of civilian pilots have emerged, dedicating themselves to providing voluntary support for search operations. In the military context, drone-based technologies, such as Remotely Piloted Aircraft Systems (RPAs), have been used for over twenty-five years. Initially, they were used for territorial control and border monitoring and subsequently for strategic attacks.

This paper targets a solution based on Wi-Fi called Transponder: supporT foR locAliziNg diStressed People thrOugh a flyiNg Drone nEtwoRk that aims to provide an efficient and low-cost tool to SAR teams for facilitating Search and rescue (SAR) by tracking, localizing, and providing first aid information to missing or distressed (unconscious or incapable) individuals. A missing person is someone whose location is unknown because they wander into an area without GSM/UMTS or other infrastructure coverage. In this situation, they cannot communicate their distress or be tracked according to standard procedures. For being detected by Transponder, they have to carry a general-purpose device with a generic Wi-Fi interface.

Transponder has been conceived for operational execution in different situations that include the following: Wooded scenario, Mountainous scenario, and Urban scenario. In all these scenarios, a missing person could be someone who has lost the path, suffers a more or less severe accident, is located in an area full of snow or ice, or is the victim of a natural disaster (such as an earthquake [3,4], a flood, or other catastrophic events). Standard terrestrial communication systems such as 3G/4G/5G and PSTN can have low or absent coverage [5]. This prevents the missing person from sending rescue requests or being located via GSM triangulation by competent authorities. Additionally, the area could be characterized by dense vegetation or forestation that could inhibit visual analysis through drones’ onboard cameras.

Analyzing the report provided by the Department of Public Security—Central Directorate of Criminal Police [6] provides a significant percentage regarding the trend of missing persons in wooded areas. Indeed, 75.97% (51.03% minors) of the missing persons provided a voluntary leaving motivation; among them, 79.88% were found, while the remaining 20.12% are still lost. These numbers highlight the importance of efficient and strategic proposals such as Transponder for supporting and speeding up SAR operations.

Figure 1 visually depicts the emergency situation where Transponder can operate, i.e., detecting a missing person without classical GSM/UMTS coverage. As in the figure, the four main actors/components are as follows:

• The Ground Node: This is the node in charge of receiving missing person detection notifications. The Ground node can be a simple LoRa device connected to the smartphone of the rescuer, another device that allows the reception of LoRa messages;
• The Drone Pilot: This node is responsible for configuring the mission from a software perspective and piloting the drone during SAR operations;
• The Mobile Node: This is the mobile device of the missing person, with an active Wi-Fi interface sending Wi-Fi beacons (more details will be provided in the following sections) and possibly using a dedicated mobile application for improving SAR operations;
• The OnBoard Node: This is the prototype in charge of detecting data generated by the device of the missing person and analyzing and sending them to the Ground Node using the LoRa Transmitter.

The manuscript structure is as follows: Section 2 describes the Research Questions (RQs) on which the proposed solution focuses. Section 3 describes the state-of-the-art technologies related to drone-based rescue systems, LoRa, and monitoring, while Section 4 describes the detection mechanism developed to allow the the proposal work. In Section 5, the architectural and technical description of the developed hardware and software is detailed, while Section 6 presents the scenario to validate the approach and its execution, providing answers to the declared research questions. Finally, Section 7 describes the future research activities.

2. Reseach Questions

Transponder has been conceived focusing on the following research questions:

• (RQ1) Is increasing the search capacity for missing persons possible?
• (RQ2) Is creating a low-cost, scalable, and easily deployable solution for multiple units possible?
• (RQ3) Is accelerating search and recovery operations possible?
• (RQ4) Is providing first aid information or psychological support to a missing person possible?

The selection of the above research questions has been motivated by several practical issues and challenges that emerged from an accurate analysis of the Italian procedures of SAR operation. They can be easily generalized to other countries, even if specific to a particular national context. Considering RQ1, in Italy, the first localization is performed by analysis of the last known location of the missing person’s mobile device through access to GSM networks. Then, ground searches (with organized teams and canine units) are conducted in the detected area, and aerial drone searches only start afterward. In this last case, drone operations are used to collect photographic data. Thermal cameras are rarely used due to their high cost and the need for specialized teams, which may not be readily available in the area. In wooded areas or places with low or no GPS signals, locating or visually tracking a missing person can be extremely difficult and has a large margin of error. Therefore, the most stringent requirement is leveraging the quality and type of data that SAR authorities can use for search analysis and localization, significantly reducing detection time.

Professional drones, especially those equipped to operate in particular weather conditions, could improve the SAR operation results, but their cost is prohibitively increased. The situation could be more critical when drone data processing requires ground-based systems equipped with mobile bases or network transmissions. Therefore, the motivation of RQ2 is to create a low-cost, scalable, and easily deployable solution based on economic, non-professional drones that can be federated to improve the granularity and speed of search operations.

A fundamental aspect of any solution is the search and rescue time. Each operation must be done as quickly as possible because any delay could be fatal to or severely affect the missing person. Indeed, several challenges cause the aerial patrolling of specific areas to provide reliable results. More importantly, even in the case of success, drones may not allow direct contact with the missing person, assist in facilitating operations, or provide helpful information for safe recovery. This motivates RQ3 and RQ4. Solutions to provide first aid information (to the missing person or his/her companions) despite the absence of a communication infrastructure (GSM/UMTS coverage) could resolve the emergency and provide psychological support to the involved individuals waiting to be safely recovered.

To address the above RQs and enhance applicability and adoption, Transponder utilizes low-cost and low-weigh hardware and software components integrated through a scalable architecture based on messages/events. These technologies can communicate through common communication patterns and protocols, allowing for installation on commonly used commercial drones. Furthermore, Transponder includes a specialized processor capable of managing emergent behaviors and responding promptly to enhance the localization of missing persons to ensure adaptability and reconfigurability in different situations. Transponder will provide them with first-aid information and facilitate their recovery. In this case, localization relies on capturing the Wi-Fi packets of the individual device, and the communication is established using LoRa radio technologies.

3. Background

This section presents the current state-of-the-art drone-based rescue systems and the technologies related to the proposed system’s development. In particular, the following subsections investigate three main pillars: Section 3.1 exploits the usage of drones in rescue systems; Section 3.2 exploits the usage of LoRa technologies for communications in areas where infrastructures are not available; while in Section 3.3, the use of monitoring infrastructure for improving rescue operations has been described.

3.1. Drone-Based Rescue Systems

For the past decade, drones have been utilized for Search and Rescue (SAR) operations to assist missing persons because they can either provide the possibility of photographic analysis [7,8], performed directly onboard the drone or remotely by sending the data to a base station [9,10,11,12,13], or they can be connected to systems specialized in locating subjects, such as Avalanche Research Apparatus (ARVA) devices [14,15] or provide support during rescue operations [16]. Different authors have reported evidence of successful experiences, such as the studies of [17,18], which focus on the possibility of using UAVs in catastrophic scenarios (earthquakes or other natural disasters), the work of [19], which relies on LoRa technologies for SAR operations, or the solution in [20], which relies on mobile networks for localization in SAR operations.

As depicted in Figure 2, the available drone-based rescue systems conducting their analysis are divided into three categories. Each approach has pros and cons that should be evaluated, considering the criticality of the SAR operations and the environmental context in which it should be performed, and relies on one of the following methodologies:

(a)

Placing the data collector and analyzer onboard the drone. In this case, the drone’s data collector and the analyzer can easily solve data transfer and transmission interface issues. However, this solution requires significant computational power for data collection and analysis, often necessitating additional energy sources depending on the analysis and the technology used. Indeed, the drone’s standard computing power could be insufficient to execute high-performance machine-learning algorithms [21]. Using the extra batteries can partially solve the problem but increase the drone’s weight and sometimes compromise the drone’s flight requirements.

(b)

Relying on cloud facilities. This could require a suitable and reliable transmission–support connection in the working drone’s area and data transmission to a remote device/component for the analysis computation. However, external servers may compromise the computation, especially in areas with missing GSM/4G/5G coverage. Improvements could be obtained by using satellite connections.

(c)

Relying on portable devices such as smartphones or tablets for data analysis. These devices, often the same ones used for drone piloting, could have the same required computational performance as dedicated devices but could have computing power and battery life issues.

The solution presented in this paper focuses on a hybrid solution that involves the first and third approaches. The computation is executed on external devices placed on the drone, sending data to the ground node for further analysis and actions.

3.2. LoRa Technologies

LoRa technology, an acronym for Long Range, refers to a specific Wide Area Network (WAN) modulation technique. LoRa has a relatively limited data rate, typically a few kilobits per second, which allows for the use of highly sensitive receivers. These bands improve transmission range and signal penetration compared to those used for wireless communication (such as 2.4 GHz). Additionally, the frequencies used by LoRa are unlicensed, making them freely usable without limits on the number of devices employed. This technology has widespread adoption in Internet of Things (IoT) devices due to its capability for long-distance transmission, low resource consumption, and low operational costs.

Studies and uses of the enabling technology LoRa mainly focus on the following areas:

• Experiments for evaluating the performance of LoRa and LoRaWAN networks [22,23,24,25,26,27]. For instance, the work of [28,29] evaluated the scalability in terms of the high guarantee of packet transmission with hundreds of devices connected to the same gateway. The analysis of [30] linked quality and packet loss to the operational conditions of the system, considering transmission power, payload length, and antenna orientation. The evaluation of [31] focused on the relation between energy consumption and the system’s throughput. Finally, the simulations of [32] evaluated how the different spreading factor influences the transmission range of LoRa in approximately 10 km under line-of-sight conditions.
• Application of LP-WAN technologies in IoT domains [33,34,35,36]. The experiments showed that LoRa is generally suitable for large outdoor environments. A wireless monitoring system with reduced throughput can often be used for long-range communication. This is because the transmission delay in LoRa systems, while acceptable, is not considered a fundamental requirement.
• Improvement of LoRaWAN architecture, for instance, integrating specific security and privacy solutions or using the Hardware Secure Module (HSM) for data protection against unauthorized manipulations [37].
• Usage of LoRa technologies for SAR (Search and Rescue) operations. Examples include the following: The proposals of [38], which show how the antenna selection can profoundly affect LoRa signal propagation; Ref. [39], which focus on the energy efficiency of the LoRa-based SAR system; and Ref. [40], which showcases the effectiveness of LoRa communication in catastrophic situations, while [41] proposes a technique based on a LoRa system based on speech recognition in a rescue environment and [42] proposes a hybrid network based on LoRa and ZigBee for SAR operations.

3.3. Event-Based Monitoring System

Monitoring activity can be defined as the process of dynamically collecting and interpreting information to interpret its meaning or uncover new knowledge [43]. The event-based approach [44] allows abstracting the monitored concepts and making them independent of the reference context to be aggregated downstream by an inference engine driven by rules. Regarding the aspects related to the conducted study, one of the factors that increased the amount of analyzable data is attributable to the reduction in cost of sensors, which has fueled the Internet of Things (IoT) world: inexpensive devices with low computational capabilities but capable of offering services on platforms, almost always cloud-based, which often hold the data and can analyze or resell it to third parties. Monitoring mechanisms are used in multiple system architectures, whether they are based on orchestration or choreography. The data collected by monitoring systems can be used to improve the quality of life of citizens within a smart city [45], monitor and track the health of an elderly subject through Body Area Network (BAN) sensors [46], increase automotive safety through Vehicular Ad-hoc Networks (V2X) [47], or refine information circulation through search engines tailored to the user’s profile [48], or the patient’s profile [49] in the medical case. Initially developed to identify unauthorized access to resources or attempts to degrade software performance, rule inference techniques increase the understanding of one or more interacting systems [50,51,52].

By observing individual events, their aggregated meaning can indicate an unexpected or otherwise not easily interpretable emergent behavior. The capture of emerging behaviors is accomplished using rule and metarule languages; notable ones include Drools (https://www.drools.org/, accessed on 28 August 2024), used in the proposed system, and Confluent (https://www.confluent.io/, accessed on 28 August 2024), RuleML (https://www.ruleml.org/, accessed on 28 August 2024), TIBCO (https://www.tibco.com/, accessed on 28 August 2024), ruleCore (https://pypi.org/project/ruleCore/, accessed on 28 August 2024), and Esper (https://www.espertech.com/esper/, accessed on 28 August 2024).

4. Missing Person Detection Mechanism

This section details the original detection mechanism implemented in the Transponder solution. The necessary and sufficient working conditions for the Transponder application is the availability of a device (mobile phone or other facilities) equipped with a Wi-Fi interface turned on. It is essential to understand that every device with a wireless interface constantly scans for wireless signals by sending out a frame (beacon) known as a Probe request, even if it is not connected to a network. A Probe Request beacon frame is an 802.11 management-type frame periodically transmitted (every 1024 µs) by every Wi-Fi Device. This beacon enables the sending device to check for any familiar networks in the proximity and establish a connection. The same process occurs when the connection is established to identify a network with the strongest signal and execute a connection handover.

The Probe Request sending process, executed constantly, can have an impact on battery life [53,54] but, considering the low impact on duration with a standard interval of Probe Request, the aspect has not been taken in consideration for the validation. The process of the Probe Request and the packet content obtained by analyzing the traffic of any Wi-Fi network are illustrated in Figure 3.

The localization and subsequent operations are in charge of the microcomputer on the OnBoard Node (see Figure 1). It executes specific procedures to guarantee the avoidance of any false positives in the localization, generating a secondary Wi-Fi network to provide first aid information to the missing persons routing the data sending (to the ground node or directly to the rescue teams) according to computed parameters such as the distance from the missing person and the operational load.

As in the figure, the client, represented by one of the devices on the left side, sends a Probe Request frame over a wireless channel and waits for a predefined time [55]. The access point on that channel (if any) recognizes the request and responds with a Probe Response message. This message is not encrypted because it is sent before any network connection negotiation with the access point.

The Probe Request message is broadcast or sent directly to a specific address. It may contain the SSID name to which the device wishes to connect. The Probe Request, Probe Response, and Beacon packets are identified as shown in

Table 1. Filter for capturing required data.

Frame type	Filter
Probe Request	wlan.fc.type_subtype eq 4
Probe response	wlan.fc.type_subtype eq 5
Beacon	wlan.fc.type_subtype eq 8

according to the Reference Guide of the 802.11 protocol [56]. Consequently, detecting a Probe Request message in a search area indicates the presence of a mobile device.

The underlying assumption of this system is that, in the area where the search and rescue operation is being carried out, the population density is very low. Therefore, detecting a probing message can be considered reliable data for locating missing persons. This assumption holds in many real-life scenarios, such as in forested or mountainous regions, where the presence of people is very rare, and no other devices belonging to individuals are in the same area.

Transponder captures the Probe Request message using the tcpdump software. It provides the possibility of capturing the direct stream of packet acquisition. An example is shown in Figure 4, which shows the capture results of the execution of the script listed in Listing 1. In particular, Figure 4 identifies the missing person device’s MAC address, signal, and dBm value. The last two parameters will help improve the drone’s convergence on the location of the missing person.

Listing 1. tcpdump execution.

To prevent false positive results, such as mistakenly detecting a Probe Request or Beacon message from one of the rescuers’ devices in the same area, the analysis of the Probe Request packet takes into account the MAC Address parameter. Indeed, the list of rescuers’ MAC Addresses could be provided in advance to the Transponder system logic on the OnBoard Node, reducing the probability of critical mistakes. To avoid privacy issues, new mobile operative systems include features for an anonymization process, for instance by the randomization of MAC address [57,58,59,60,61,62]. These features could increase the number of false positives. Therefore, a suitable compromise should be adopted in different situations.

Following best practices is one way to address privacy concerns during Search and Rescue (SAR) operations. To improve the chances of success, rescue teams often divide the search area into quadrants and conduct thorough, systematic searches. This approach helps avoid redundant aerial patrolling over areas that have already been thoroughly searched [57,58,59,60,61,62].

5. Prototype

This section details the Transponder (https://transponder.isti.cnr.it, accessed on 2 September 2024) prototype implementation and positively replies to RQ2, as presented in Section 2. As detailed in this section, Transponder has been assembled with low-cost components and conceived as a scalable and easily deployable solution on multiple units.

As shown in Figure 5, the system is composed of three nodes:

• The primary node, called the OnBoard Node, is the system’s intelligence. It is composed of four interconnected devices, which are a Rasbperry Pi, a LoRa transmitter, a GPS, and a Wi-Fi. The Rasbperry Pi device executes RaspiOS AARCH64 and is the operative system and the component responsible for the monitoring activity. In detail, these are the Event-based monitoring system, Wi-Fi Probe, and GPS Probe. The Rasbperry Pi also includes a Serial Port Writer. More details are provided in Section 5.1.
• the Ground Node is the operational base that receives detection notifications by the OnBoard Node. The Ground Node contains a Lora Receiver device managed by the Receiver Module. More details are provided in Section 5.2.
• a Mobile Node is the device owned by the missing person. It is detected by the methodology presented in Section 4. However, as described in Section 5.3, a specific Mobile APP could improve the SAR operation’s success.

To clarify the interaction between the components and provide a clear view of the Transponder system in action, a Business Process Model Diagram (https://bpmnquickguide.com/quickguide/bpmn-quick-guide/bpmn-glossary.html, accessed on 28 August 2024) is shown in Figure 6. The three main nodes: OnBoard, Ground, and Mobile, are represented using the Pool BPMN construct, which refers to separate entities cooperating in the overall process, while the OnBoard and Mobile nodes are further organized using the Lane construct, which refers to the interactions between internal component of an entity represented in a Pool construct.

5.1. OnBoard Node

The OnBoard Node is shown in Figure 7. It has a global weight of 188 g (with 3800 mAh battery pack) and is equipped with the following hardware components:

• A Raspberry-Pi model 4 Mod B 8 GB;
• A High-gain 2.4/5 GHz Wi-Fi module manageable via USB;

  2.1.

  Two different antennas have been tested, which provide approximately the same results: TP-Link Archer T3U Plus (https://www.tp-link.com/it/home-networking/adapter/archer-t3u-plus/#specifications, accessed on 28 August 2024) and TP-Link ArcherTX50UH (https://www.tp-link.com/it/home-networking/high-power-adapter/archer-tx50uh/#specifications, accessed on 28 August 2024)

• A USB module for GPS signal detection;
• A LoRa device SX1275 ESP32 with antenna (LoRa Transmitter);
• A battery pack of 3800 mAh or a battery pack of 5000 mAh for 226 g version.

On top of the Raspberry PI device, an open-source OS (RaspiOS 64) has been installed to execute all the artefacts shown in Figure 5. The OnBoard Node software artefacts are detailed in the following subsections.

5.1.1. Event-Based Monitoring System

As shown in Figure 5, inside the Raspberry PI device, the Event-based monitoring system includes an existing monitor solution called Concern (https://github.com/acalabro/ConcernMonitoringRest, accessed on 28 August 2024). The Concern high-level architecture is shown in Figure 8. As in the figure, raw events generated by the system (RAW events from real world on the left side) are captured by probes. Probes are software artefacts capable of structuring data in a format easily manageable by the monitoring infrastructure. A complex event processor continuously uses the data received by the probes to assess a set of predefined rules representing functional or non-functional properties. Rules are stored on the Pattern/Rules Meta-Rules DB components. The results of the assessment of the rule are collected into the Historical Data Collection db for statistical analysis and sent to the external users (Result message on the right of Figure 8). In case of a rule violation, a notification is provided, and the corresponding countermeasure is activated, if any (Actuators message on the right of Figure 8). More details about the proposed monitoring infrastructure are provided in [63,64].

5.1.2. Wi-Fi and GPS Probe

As shown in Figure 5, inside the Raspberry PI device are the Wi-Fi Probe and the GPS Probe. The former is a software artefact able to listen to the wireless traffic generated by the Wi-Fi device and capture packets such as Probe Request/Response and Beacon. It applies the missing person’s detection mechanism described in Section 4.

The Wi-Fi Probe uses tcpdump (https://www.tcpdump.org/, accessed on 28 August 2024) software for signal capturing. Collected data and the relevant information are encapsulated in a ConcernWiFiEvent<String> object and then sent to the Event-based monitoring system on the dedicated event channel.

The GPS Probe is a piece of software that captures the data generated by the GPS device. As shown in Listing 2, collected data conform to the GPS & GLONASS format. The GPS Probe filters and encapsulates the data into a ConcernGpsEvent<String> object and sends them to the Event-based monitoring system. The payload of the ConcernGpsEvent<String> event contains the GPS coordinates in the format (Latitude, Longitude).

Listing 2. Single data trace provided by the GPS device.

5.1.3. JMS/MQTT Server & JMS/MQTT Mediator

As shown in Figure 5, inside the Raspberry PI device, there are the JMS/MQTT Server and the JMS/MQTT Mediator. The former is realized by Artemis (https://activemq.apache.org/components/artemis, accessed on 28 August 2024).

All of the communication between components relies on messages conforming to specific formats: JMS and MQTT. The choice is for improving compatibility between the Mobile APP component (Section 5.3), usually relying on MQTT messages, and the Event-based monitoring system component, usually based on JMS format.

The JMS/MQTT Mediator component is conceived explicitly for managing conversion from JMS to MQTT and vice-versa, as in the scenarios where the missing person can use the Mobile APP to interact with the rescuers. More details are provided in Section 5.3.

The message conversion operation involves deserializing the MQTT message generated by the Mobile APP and translating it into a Java object following the specification of the Event-Based Monitoring System. The reverse operation occurs when the Event-based monitoring system, following the verification of a rule in its knowledge base, needs to notify a response to the requesting user. Figure 9 illustrates the abstract conversion process.

5.1.4. LoRa Transmitter

Figure 10 shows the Lora Transmitter device managed by Sender Module software. The module has been developed using Arduino IDE (https://www.arduino.cc/en/software, accessed on 28 August 2024) and Heltec libraries (https://heltec.org/project/wifi-lora-32-v3/, accessed on 28 August 2024). The Sender Module receives the data for the Ground Node through the Serial Port Writer components and sends them according to the LoRaWAN frame protocol.

As shown in Figure 11, according to the protocol specification (https://lora-alliance.org/wp-content/uploads/2021/11/LoRaWAN-Link-Layer-Specification-v1.0.4.pdf, accessed on 28 August 2024), the lower level of the LoraWan frame protocol is the application layer. It is divided into three sections: Frame Header, Frame Port, and Frame Payload (green upper part of Figure 11).

The Frame Payload section has been enriched with specific data to realize the missing persons’ detection mechanism, as described in Section 4. In particular, as shown in the purple lower part of Figure 11, the added information includes the incident type, the number of missing persons involved, and the GPS position where the missing persons have been detected. This information is mapped onto the Frame Payload as follows:

• The begin of the packet is identifiable through a 1-byte Frame Header;
• The type of incident is represented by the Distress ID field (1-byte);
• The number of missing persons is defined by the Involved Person field (1-byte);
• The detection latitude and longitude is represented by the GPS Position field, having a variable length ranging from 17 to 22 bytes depending on the precision or geographic location bytes;
• The end of the packet is identifiable through a 1-byte Frame Tail;

Two bytes as a “separator” have been included. They were used during the debug session and have been kept in the system to exploit further functionalities in the MobileApp described in Section 5.3.

As a result, the size of the transmitted packet varies from 22 to 25 bytes.

5.2. Ground Node

The Ground Node depicted in Figure 5 contains a Lora Receiver device managed by a software artefact called the Receiver Module. The Receiver Module provides several features for facing different SAR operation configurations. In particular it

• manages the received LoRa messages and temporarily stores them;
• can be connected to Wi-Fi networks;
• exposes a web server allowing rescuers to visualize received LoRa messages on a browser.

The abstract architecture of the Lora Receiver comprises three layers. The Wi-Fi and LoRa layers are in charge of providing information to the upper layer called WebServer. An example of data exposed by WebServer in the rescuer’s device is shown in Figure 12. The provided data can be converted into a Google Map link to visualize the computed position of the missing person on a map, as represented in Figure 13.

5.3. Mobile Node

The Mobile Node is the device of the missing person having the wireless interface turned on. Therefore, it can generate data (Probe Request or Beacon) that the Mobile Node can detect according to the procedure described in Section 4.

A specific Mobile App has been created to leverage missing persons’ localization in the Transporter solution. Through the Mobile App, missing persons can also provide information about their health status and the number of people involved. It can be installed on each mobile device and continuously executed or run on demand.

In the prototype Transponder implementation, the Mobile App has been developed for Android smartphones using APIs compatible from Android 6.0 (Level 23) to Android 11.0 (Level 30). Figure 14 shows its preliminary interface, while Figure 15 represents the drop-down menu, created to specify the type of emergency and requested assistance. As in the figure, the Mobile App allows missing persons to Select the emergency, Specify the number of people requiring assistance, and Send the emergency request. Once the parameters have been selected, the emergency request can be forwarded by pressing the Send emergency request button.

In this case, the message is encapsulated in an MQTT envelope and provided to a background daemon continuously attempting to connect to the secured wireless network generated by the closest OnBoard Node flying nearby. When this happens, the Mobile APP sends the MQTT message on the specific channel established by the JMS/MQTT Mediator of the OnBoard Node. As described in Section 5.1.3, the received message is converted into JMS format and forwarded to the Event-based Monitoring System. This last analysis analyses the parameters the missing person provides and, depending on the situation, composes a reply containing the most suitable first aid information. Finally, the information is returned to the Mobile APP through the JMS/MQTT Mediator. Using the MobileApp, which tries to push data to the Wi-Fi network of the drone, which is continuously scanning the available networks, increase battery consumption. This has also been demonstrated in [53].

The realization of the Mobile App lets us reply to RQ4, as presented in Section 2, positively. As detailed in this section, the app can provide first aid information or psychological support to a missing person.

6. Scenario Execution

Considering the three scenarios presented in the introduction, a showcase experiment in a wooded area has been performed to validate the Transponder prototype in a real situation and provide a reply to RQ1 and RQ3.

Regarding the Wooded scenario, the showcase experiment was located in a wooden area near Pisa where no flight restrictions were active. The woods comprised pines and fir trees with an average height of 30 m. The test was executed in good weather conditions, with low humidity levels and no wet tree leaves. The density of the leaves and ground vegetation prevented using onboard drone cameras for missing person detection. Satisfying the RQ2 and therefore containing the overall cost of the experiment, thermocameras were not considered during SAR operation. To ensure the accuracy of the collected results, an individual not involved in the experiment placed the Mobile Node (a mobile phone referred to as the Target Device) inside the wood and recorded the device’s GPS position (referred to as the Experiment Mobile Position). Specifically, the individual obtained the Experiment Mobile Position with a precision radius of 5m after successfully capturing enough satellites. This data was unknown to any other experiment participants until its conclusion.

The localization capability has been considered for replying to RQ1, i.e., the possibility of increasing the rescuer’s search capacity to localize missing persons. In particular, the experiment evaluated the capability to detect and notify a Beacon generated by the missing person Wi-Fi device.

Regarding RQ3, the maximum distance of detection has been evaluated to assess the capability of Transponder to accelerate search and recovery operations. The experiment considered the maximum distance a Wi-Fi device generated Beacon can be detected. To assess the Transponder performance in the worst-case scenario and with the minimal data set, the use of the Mobile App has not been considered. To ensure unbiased results, an independent individual who has never been involved in defining or implementing the Transponder system was asked to place a mobile phone with the Wi-Fi interface enabled in an undisclosed place within the selected wooden area. This mobile phone is called Target Device in the following.

In the experiment, a Rescuer mobile phone was used for the Ground Node. The mobile was connected with the LoRa Receiver through the USB-C port.

The experiment execution was performed by installing an OnBoard Node on top of a DJI Air 2S commercial drone (https://www.dji.com/it/support/product/air-2s, accessed on 28 August 2024), as shown in Figure 16. The drone began the SAR mission by taking off from the wooden area nearest the field. During the experiment, the drone followed a standard research path schema, with concentric flies over the wooden area at an average ground speed of 5 km/h. An example of the messages received by the Ground Node consequent to the detection of the Beacon from the OnBoard Node are shown in Figure 12. In the following section, details about the experiment execution and RQs assessment are presented.

6.1. Localization Capability

The assessment of RQ1 has been performed considering the capability to detect and notify a Beacon generated by the missing person Wi-Fi device. During the patrolling flight, as soon as the OnBoard Node detected a Beacon generated by the Target Device, identified by a specific mac address assigned to the device before being abandoned under a tree, it sent a message to the Ground Node according to the procedure described in Section 4 and Section 5.1.4. As shown in Figure 12, the message has been correctly received, and the localization of the target device has been computed. The collected results positively reply to RQ1 and demonstrate the feasibility of the Transponder solution.

6.2. Maximum Distance of Detection

Assessment of RQ2 has been performed by offline analysis of the data acquired during the scenario execution. In particular, the following process has been performed:

• Establish the position of the Target Device, maximizing the localization’s precision. In this phase, the Experiment Mobile Position collected by the independent person at the beginning of the experiment has been used;
• Compute the distance between the Target Device position and each detected Beacon position. This calculation has been executed offline by analyzing data captured by the GPS device installed on the OnBoard Node and the information related to the real GPS position of the Target Device computed in step 1;
• Order the computed distances and establish the maximum one. This activity has been executed offline by ordering data by the distance computed in step 2;
• Cluster the detected Beacon positions according to similar distances.

Figure 17 reports a graphical representation of the maximum detection distance.

The farthest Beacon has been detected at a ground distance of 79 m from the terrain projection related to the position of the OnBoard Node. Considering a flying quote of around 35 m, it is possible to infer that the Beacon, in a Wooden area, has been detected around a distance of 86.4 m, representing an average covered area of 19,607 m².

A cluster representation of Beacon detection density is reported in Figure 18.

While approaching the Target Device, the density of beacons detected proportionally increases. The post-analysis also revealed that the take-off position of the drone was around 180m far from the Target Device position.

7. Conclusions and Future Works

This paper presented the Transponder system, developed to facilitate Search and Rescue (SAR) operations by tracking, localizing, and providing first aid information to missing persons. Transponder is a wireless rescue system based on LoRa communications, integrated with Wi-Fi beacon detection and GPS positions to enhance the effectiveness of SAR operations. By leveraging non-professional drones and a mobile application for communication, the system addresses critical challenges in locating and assisting individuals in distress, especially in areas without connectivity. Additionally, the prototype realization of Transponder has been shown to increase the search capacity for missing persons, create a low-cost and scalable solution, accelerate search and recovery operations, and provide first aid information or psychological support, which are all crucial benefits during SAR operations. Finally, the experimentation of the Transponder in a real wooded scenario demonstrated different peculiarities such as:

• Transponder can be an innovative detection mechanism, relying on the capture of Wi-Fi probe requests and beacons, able to effectively identify the presence of mobile devices, even in dense vegetation or areas with limited GPS signals,
• Integrating LoRa technology, Transponder can enhance communication capabilities, ensuring long-range transmission and reliable data exchange in SAR missions.
• The hybrid computational approach—combining onboard processing with ground-based analysis—optimizes the balance between computational power and energy consumption, making the Transponder solution efficient and practical for real-world applications;
• Using inexpensive and lightweight components, Transponder ensures the system’s economic feasibility and ease of deployment.

Overall, future Transponder research will focus on refining the system’s capabilities, exploring advanced algorithms for data analysis, empowering transmission mechanisms, reducing the weight of the OnBoard Node, and expanding its applicability to various SAR scenarios. One of them is related to the possibility of deploying a cooperative fleet of drones that will analyze data related to the beacon detected from each drone of the fleet. Considering the trend of the signal’s power detected, it will be possible to try to boost timing in detection and let the fleet converge on the distressed subject, as is done in the indoor environment by applying multi-user detection mechanisms. Regarding the possibility of reducing the weight of the OnBoard Node, there is ongoing work on moving all the functionalities on the new Raspberry PI 2 Zero that will drastically reduce the weight, allowing the possibility to install the OnBoard Node on a DJI Mini 4 Pro. Attention will also be devoted to improving communication and avoiding packet loss or signal discontinuity. In particular, the Selective Automatic RQ mechanisms among LoRa devices could be included on the onboard node to ensure a more robust communication channel. In the case of a lack of communication via LoRa and/or 4G/5G, the possibility of including a low-energy satellite device to ensure coverage in all possible scenarios and environmental conditions is currently under evaluation.