SOS Message Distribution for Searching Disaster Victims

Abstract

This chapter presents the design and implementation of the SOSCast application which enables SOS message distribution for searching victims in a disaster-damaged area. During catastrophic disasters such an earthquake or tsunami, people may be injured or trapped in fallen buildings and debris. In situations like these, it is critical that rescue operations must be done within the first 72 h to save many lives. It is also during these events where communication infrastructures are severely damaged, and thus, makes it difficult for victims to ask for help due to the absence of communication channels. By using the SOSCast application in such scenario, victims are able to exchange SOS messages automatically by communicating directly among smartphones with less operation. By collecting these SOS messages, rescuers can find the existences of the victims as mapped on their smartphones. We have shown in our preliminary experiment within a residential area that SOSCast is capable of determining the existence of a propagator based on the collected SOS messages.

1. Introduction

In a catastrophic disaster such as the Great Eastern Japan earthquake of 2011, victims of the disaster must be rescued at least within 72 h because the chances of surviving typically decreases thereafter. However, during search and rescue operations, it is difficult to estimate the damage on the affected area. In addition, determining the existences of victims has been proven difficult with the absence of communication channels as they may have been destroyed. In fact, during the 2011 Great Eastern Japan earthquake, 29,000 base stations ceased to operate [1]. The government responded by administering (1) emergency message service, (2) specially installed public telephones, (3) satellite-based mobile phones, (4) mobile telecommunications equipment, (5) amateur radio, and (6) free Internet connection. Nonetheless, it was not easy to dispatch these services immediately after the incident. Also, the rescue teams may not be dispatched right away due to insufficient information.

Thus far, several solutions for maintaining communication in a disaster-affected area with destroyed communication equipment have been proposed in Refs. [2–4]. These typically enable direct communications between mobile devices such as the smartphone via Bluetooth and store-carry-forward (SCF) routing. In recent technology, smartphones have built-in devices like the Bluetooth and WiFi that permits data transmission even without the Internet. Developing software-based applications is one way to take advantage of the features of smartphone devices. With SOSCast that we designed, we aim to find the existence of the victims of disaster in support of the search and rescue operations. As this application make use of the Bluetooth as a communication device, it is possible to establish direct connection between smartphone devices. This then allows victims to send each other SOS messages and at the same time ensure that these messages can be delivered to the rescuers.

In this chapter, we discuss in detail the implementation and design of the SOSCast application that enables Android OS-based smartphones to send SOS messages directly via Bluetooth communication. It must be noted that throughout this chapter, we refer to two kinds of victims. One is the mobile victim who is capable of moving around the damaged area. The other is the immobilized victim, an individual who may be trapped within destroyed buildings or one who is badly injured and incapable of moving away from the current location. Moreover, we refer to rescuers as a group of people authorized to perform the search and rescue operations who come from outside of the disaster area. In general, it is challenging for the rescuers to estimate the location of an individual because the GPS information of the device that the victim has on hand may not be accurate. It is most especially difficult to identify indoor location due to signal blockade from damage buildings and absence of communication infrastructures. However, SOSCast attempts to support the rescuers in locating them most especially the victims who need immediate medical care. With the development of SOSCast, we aim to contribute the following features:

• Estimation of the area where the immobilized persons exist via SOS messages

• Definitions of data format for SOS messages to support searching immobilized persons

• Propagation method for SOS messages directly among smartphones

• Information deletion of rescued immobilized persons

Based on an experiment within a residential area using SOSCast, we present how SOSCast works and how it potentially locate immobilized victims even when the individual is located indoors. The rest of the chapter is organized as follows. Section 2 discusses related work. Section 3 presents the detailed explanation of the application design. Section 4 describes the actual use of the application in an experiment. Finally, Section 5 provides the chapter summary.

2. Related work

In a natural disaster such as a devastating earthquake, typical medium of contacting friends and family nowadays is via a mobile cellular device. However, when damaged areas are most likely left with destroyed communication infrastructures, victims would find it hard to communicate especially for those victims who are immobilized. Several studies have thought about utilizing the mobile cellular device, more commonly known as the smartphone, in sending information even with the absence of communication channels. For example, research by Sakurai et al. [5] proposes a minimalist information system that provides the functions of identifying victims, compiling these information in a database and, matching these information with relief solutions. However, in a worst case scenario, even with limited bandwidth, battery depletion and the guarantee of the information in the database were not considered as we do in SOSCast.

On a similar study that addresses the loss of communication in a disaster-affected area, Sakano et al. [6] suggested the deployment of a “movable and deployable resource unit (MDRU)” to reclaim connectivity. They have proposed a network architecture that utilizes these MDRU to restore the communication channels in a badly damaged area as per lesson from the Great Eastern Japan earthquake of 2011. It is commendable as to how they have demonstrated the effectiveness of the proposed architecture with the MDRUs by simulation but is yet to be tested in actual scenario. However, these MDRUs are estimated to be set up about 2 days and are the size of a typical container van. Thus, it implies that this solution focuses more on the post disaster recovery operations. As with SOSCast, we are more concerned on confirming the existence of victims right after the disaster has occurred and at least within 72 h of estimated survival rate.

Another related study to SOSCast is this proposal of a communication scheme between mobile devices even without communication infrastructures. Nishiyama et al. [7] developed an information relay technique between smartphones that enables the device to switch between MANET and DTN communication mode. The switch allows for the conservation of resource such as battery and bandwidth. In an actual experiment they conducted, they have successfully relayed information from the source to the destination for within 2.5 km even when the source is located indoors. The idea of a message relay via smartphone is attractive since it is important that the message be delivered to the rescuers. However, this study does not generally addresses accounting the victims in a disaster area as it is only concerned with getting the message to the destination. With SOSCast, the application is capable of identifying victims, accumulate these information and effectively deliver these to the rescuers.

Having similiar goals with SOSCast, WIISARD or Wireless Internet System for Medical Response in Disasters aims to establish reliable connections even with the absence of communication channels. Chipara et al. [8] describes WIISARD as an emergency response system having actually tested the system through an emergency drill. It required the deployment of the Calmesh wireless networking node for the Intelligent Triage Tags (ITT) and iMOX device, which monitors the victim’s oxygen level, as well as the network of PDA’s or tablets with developed software to complete the system. Meanwhile, another emergency response system called DistressNet is similar to that of WIISARD. Collaborating with an actual search and rescue team, Chenji et al. [9] aims to establish a disaster response system using off-the-shelf devices to establish a reliable network of sensors and communication. To do so, routers and vibration sensors need to be deployed by the search and rescue team members to create the mesh network and to successfully triage the disaster victims. In contrast to both emergency response systems, SOSCast does not require the deployment of additional devices or infrastructure to enable triage of immobilized victims. It is sufficient that the victim has a smartphone on hand installed with SOSCast application for the victim to be accounted for.

3. SOSCast application design

The SOSCast application was developed to enable direct communication between victims during a catastrophic disaster particularly when the communication channels are unavailable. It allows for the victims to exchange SOS messages that contains information of their current physical status, GPS location information, etc., via the smartphone using Bluetooth communications. It must be noted that the victims we refer to are both mobile and immobilized victim. A victim is mobile when the individual is capable of traversing the damaged area while at the same time helping out other victims. Immobilized victims on the other hand are individuals who are badly injured or trapped between debris and are unable to move from within their current location. It is assumed that the application will be utilized in a scenario where the disaster-affected area is cut off from the conventional communication services, i.e., landline and cellular. That is, victims having smartphones with the installed application are able to communicate directly. In this section we will discuss in detail how SOSCast functions when it is in use. Section 3.1 describes the general function of the SOSCast. Section 3.2 presents the message format of SOSCast. Section 3.3 describes the propagation process of the SOSCast. Section 3.4 discusses how duplicate messages are avoided to prevent unnecessary confusion. Section 3.5 explains how SOSCast finds the existence of the victims.

3.1. General overview and requirements

Figure 1 shows the general picture of the SOSCast message exchange. The roles, as defined by how the SOSCast application is used, are the victims, propagators, and rescuers. Victims are described to be immobilized victims that are severely injured or trapped in damaged infrastructures. Meanwhile, propagators are mobile victims who are capable of traversing the damaged area. Lastly, rescuers are mobile individuals who have the complete authority for searching and rescuing especially the immobilized victims. Each of these roles labeled accordingly in the diagram.

Figure 1.

General overview of SOSCast.

At the moment when the immobilized person realizes that rescue is needed, he or she will begin to create the SOS message. When rescuers or propagators start to survey the damaged areas, it is to be assumed that they begin to broadcast for pairing requests. Then the immobilized person, who is severely and may be trapped inside the damaged buildings, will start to listen and scan for the broadcasted pairing requests from propagators that may be passing by as depicted in i of Figure 1. Upon capture of a scan packet, the smartphone of the immobilized person will initiate connection with that of the propagator’s smartphone and start to communicate. To do so, the immobilized person transmits the created SOS message, which includes the current location based on GPS information. The SOS message composed also states the current condition that the immobilized victim is in and most importantly the victim’s name. When the propagator receives the message, an acknowledgement receipt shall be sent back to the victim which states the GPS location information where the propagator has received the SOS message. The propagator’s smartphone will then disconnect from the current pairing connection and search for more pairing requests while traversing the vicinity of the damaged area. Such process, when in a repeated cycle, enables the propagator to collect several SOS messages from immobilized victims with successful pairing connections. The propagators are also able to share the received SOS messages with other propagators, such that, each of the propagators will have a consolidated list of SOS messages as in ii of Figure 1. After that, it will now be a matter of which propagator is able to deliver the collected SOS messages to rescuers who will estimate the locations of the immobilized victims based on the GPS locations of the SOS messages collected (see iii of Figure 1).

Meanwhile, Figure 2 describes in detail how SOSCast functions on the application level. First, the victim identifies self if immobilized or mobile. Note again that, a victim is considered immobilized if trapped inside a damaged building or infrastructure and is unable to move away from current location. Whereas, a victim is mobile if the individual is capable of traversing the affected area. Now, if the victim is immobilized, the victim will be asked to create the SOS message using the smartphone application with the needed information. Otherwise, the mobile victim would simply enable smartphone to broadcast a pairing request. After the immobilized victim creates the SOS message, the smartphone must be enabled to broadcast a pairing request as well. While the application is used by a mobile victim, the device continues to listen to pairing requests from other victims using the application. If the mobile victim’s device found a pairing request, the device will begin to establish connection. Then, if the connection is identified to be with an immobilized victim, the mobile victim’s device will wait to receive the SOS message. Simultaneously, the immobilized victim sends the created SOS message to the mobile victim and waits to receive the extended SOS message. At the time when the mobile victim receives the SOS message, the mobile victim will attach personal information to the message, store this on the device, then send back to the immobilized victim the extended message. The purpose of an extended message is for the immobilized victim to confirm that the SOS message has been acknowledged. In that regard, the extended message actually includes the name of the mobile victim and an ID as well as the communicated time and location information. Finally, the mobile victim ends the connection with the immobilized victim and broadcast again a new pairing request searching for other victims.

Figure 2.

The working process of the SOSCast application.

On the other hand, if the mobile victim happens to find a pairing request from another mobile victim or rescuer, the mobile victim on inquiry mode sends a connection request and establish connection with the other party. Then, instead of receiving an SOS message, the mobile victim sends the other mobile victim or rescuer the currently stored SOS messages from immobilized victims with the extended information. Afterwards, the mobile victim waits to receive the stored messages from the other party to update the database in the device. When the exchange of stored messages is done, both parties end the connection and begin to search for other unaccounted victims.

3.2. Message format

The SOS message formats between immobilized and mobile victims differ in content. The immobilized victim records ID, and remarks on current physical condition. The location information and the time when the message was created are also logged. The immobilized victim’s ID may include a nickname or the real name of the person. As for the remarks, it is a message field where the immobilized victim selects from a dropdown menu of current statuses with predefined messages. The location field includes the currently identified GPS information by the device. Lastly, the time when the immobilized victim created the message is also recorded. From this, it is possible to estimate the time when the immobilized victim began to ask for help. Moreover, it is useful to sort and delete duplicated messages based on this time field. Table 1 lists fields of the message format for immobilized victims with corresponding byte size.

Item	Description	Size (byte)
Immobilized victim ID (IMEI)	Name to identify the victim	15
Message creation time	Time when the SOS message was composed	4
Immobilized victim location	GPS information of the victim	8
Communication time	Time when a connection was established	4
Propagator location	GPS information of the propagator	8
Immobilized victim information	Current status of the immobilized victim	0

Table 1.

Description of the SOS message format.

The mobile victim’s information includes ID, the current location information, and the time when the mobile victim communicated with the immobilized victim. Similar to immobilized victim’s ID, this field may also include a nickname or real name. The location field logs the current GPS information where the mobile victim has established connection with the immobilized victim. Occasionally, the GPS information of immobilized victim may not be accurate or may not be obtained due to indoor location, etc. If so, the information may lead to the wrong operation. However, as the number of obtained messages increases, using the GPS information of mobile victims improves the precision even if some GPS information of mobile victims are not accurate. Lastly, the time when the mobile victim has received SOS message from the immobilized victim is logged in the time field.

In general, the GPS information for both the immobilized and mobile victims is inaccurate by around 10 m. The SOSCast application is not capable of identifying the accuracy of the obtained GPS information. However, we rely on this information to at least have an idea where the immobilized victim may be at. We discuss this idea further in Section 3.5 to justify how this information proves to be useful even if it is not accurate sometimes.

3.3. Propagation process

When the communication channel is unreliable or unavailable, the smartphones would need to propagate SOS messages by means of store-carry-forward (SCF) routing. In propagating SOS messages, this study mainly implements Bluetooth technology, which is favorable for its simplicity and availability in the majority of smartphones. Bluetooth mainly has two mode types, the inquiry mode and the discoverable mode. In the inquiry mode, a smartphone broadcasts inquiry packets to detect other bluetooth devices. On the other hand, during the discoverable mode, it is listening for broadcast inquiry packets. For the immobilized victims to conserve as much battery as possible, their smartphones are set to discoverable mode. Meanwhile, the propagators could be both in inquiry and discoverable mode, periodically sending inquiry packets during the inquiry mode and constantly listening to broadcast requests during discoverable mode. When the inquiry responses from both immobilized and propagators are received within the period, the propagator generates a list of possible connections. These connections are classified according to the capability of the immobilized person or the propagator to propagate SOS messages as soon as possible.

Table 2 shows six types of connection lists, namely, immobilized persons, propagators, and already connected persons classified into either having a strong or weak Bluetooth Received Signal Strength Indication (RSSI).

Priority	Classification	RSSI level
1	Immobilized persons	Strong
2	Propagators	Strong
3	Already connected persons	Strong
4	Immobilized persons	Weak
5	Propagators	Weak
6	Already connected persons	Weak

Table 2.

List of SOSCast connections.

Immobilized victims and propagators alike are considered to be already connected persons, as such, persons connected via SOSCast. It is also to be noted that SOSCast in a propagator’s smartphone is capable of logging the RSSI of the pairing requests received. With this, the propagator can classify the SOSCast connections by the RSSI level. For instance, when the RSSI of the request sent by the immobilized victim’s smartphone is higher than the previously set threshold,¹ SOSCast will identify such ID as immobilized persons with strong RSSI. Else, if the identified RSSI is lower than the threshold, then it will be assigned as immobilized persons with weak RSSI. Moreover, propagators and already connected persons are similarly classified with their RSSI relative to the threshold. Propagators with RSSI higher and lower than the threshold are addressed as propagators with strong RSSI and propagators with weak RSSI, respectively. Already connected persons with RSSI higher and lower than the threshold are, namely, already connected persons with strong RSSI and already connected persons with weak RSSI. When such classification list is made, the priority of connection is in the order of strong RSSI from the immobilized person, propagators and already connected persons. Within the classification, the order of addressing which connection will depend on the order the IDs whose SOS message arrive first. Less priority is given to those IDs with weak RSSI beginning from immobilized persons, propagators and already connected persons. Connections to persons with weak RSSI will be postponed because there is a lower probability that a connection can be made compared with those having higher RSSIs.

3.4. Message deletion

Redundant SOS messages are to be deleted properly from the network to avoid misleading the rescuers to continue the search when the immobilized person was already rescued. Removal of such messages must be done immediately for time efficiency during rescue. Illustrated in Figures 3 and 4 are the deletion processes of unnecessary SOS messages.

In Figure 3, assuming that the immobilized person has been rescued and if such person is capable of moving around to help in the rescue, the status will be changed to propagator.

Figure 3.

Deletion process in immobilized victim’s device.

Figure 4.

Deletion process in mobile victim or propagator’s device.

This person will now be propagating other immobilized persons’ SOS messages the same way as propagators do. In the status transition, however, the information sent to the consolidated SOS message list must be deleted and should indicate self as “RESCUED” in the message field. The now mobile victim should be able to collect SOS messages from immobilized persons and exchange information with other propagators. Within the collected SOS messages from other propagators, the information relating to self upon the change in status must be removed as in Figure 4.

However, some victims who had sent SOS messages and were rescued may need to call rescue again by some reason such as during a secondary disaster. They can also create SOS messages, and these messages are not deleted by the old rescued message. Note that the rescued information is maintained in the SOS message. Therefore, rescued immobilized persons’ information is deleted during propagating process.

3.5. Location mapping

Based on the logged SOS messages, the rescuers can easily find the existence of the immobilized victims from the recorded GPS location information. This is so because the SOS messages will be propagating within the network of propagators until the consolidated message list is received by the rescuers. Rescuers and propagators or mobile victims alike carry the same function of the SOSCast in their smartphones. However, only the rescuers has the capability of actually searching for the immobilized victims and the authority of rescuing them. The map in SOSCast, meanwhile, helps the rescuers by giving an idea on where the immobilized victim should be searched. Note that SOSCast also collects the GPS location from where the propagator has received the SOS message as an acknowledgement. Without such, it will be difficult to know where to search for the immobilized victim when the given GPS location information of the immobilized victim is unavailable or incorrect. It would be helpful, thus, to have both the acknowledged receipt location from the propagators and the location the immobilized victim provided to make it easy for the rescuers to estimate the search area efficiently.

4. Evaluation

To examine how a smartphone obtain messages in the real environment, we conducted an experiment using Android OS-based smartphones. Section 4.1 describes the experimental environment while Section 4.2 discusses the results.

4.1. Environment

Based on the design of the SOSCast in the general overview, the application was implemented based on Android. To evaluate the potential of the Android application, a preliminary experiment within a residential area nearby the campus was conducted. All persons assuming the roles of the immobilized person and propagator in the experiment have SOSCast installed on their respective device. In this case, the Samsung Galaxy Tab SC-01C was used as a smartphone device by both the immobilized person and propagator. In the scenario as in Figure 5, an immobilized person is assumed to be trapped inside the building with propagators moving around the building. Considering that the building is damaged and inaccessible, propagators walk along the surrounding street. Traversing the area is done five time in all five directions indicated. When a rescuer receives the collected SOS messages from the propagators, the logged GPS location information from the SOS messages both indicated by the immobilized persons and that of the location acknowledged by the propagator of having received the message will be displayed on the map.

Figure 5.

Experimental environment.

4.2. Results

Figure 6 is a screenshot of the display on the rescuer’s smartphone which shows the locations of both the immobilized person and propagators. The results of the experiment have shown us that the propagators were able to receive the messages within the 10 m parameter in average on the directions indicated in 1, 2, and 5. In the case of directions 3 and 4, the distances of the locations where the SOS messages were received are higher than average. Even so, the availability of the distance, based from those indicated by the propagator from where the SOS messages were acknowledged to have been received, could indicate the presence of an immobilized person within the vicinity. Again, this could aid the rescuers in estimating the search area even with incorrect or unavailable GPS location information from immobilized person.

Figure 6.

Experimental result.

5. Conclusion and future work

In this chapter, we showed the implementation and design of sending SOS messages by both immobile and mobile victims of a very damaging disaster, namely the SOSCast application. By estimating the locations, we have shown that SOSCast has the potential to locate victims specifically targeting immobilized persons trapped under fallen debris or infrastructures based on this information. In SOSCast, the victims collect and propagate these messages which rescuers can use to estimate locations of the immobilized persons by using the smartphone. The more GPS information received from collected SOS messages, the more it is possible to estimate the victim’s location. In a disaster area where conventional communication services are impaired, SOSCast can potentially aid the work of rescuers as it can enable direct communication between smartphones. As future work, we will consider to utilize other wireless communication like Wi-Fi Direct, in addition to Bluetooth. Also, with the development of Bluetooth Low Energy technology, this could dramatically reduce power consumption during pairing request broadcasts between immobilized persons and propagators.

Acknowledgments

This work was supported by KAKENHI (26730050 and 17K00124).