1 Introduction

As evidenced by experience from recent natural disasters such as the Tsunami and earthquake in Japan, and Hurricanes in the USA (Sandy and Katrina) and Haiti (Fay, Gustav, Hannah, and Ike), it is essential to develop effective disaster response systems (DRS) in order to secure citizen’s safety. In a disaster situation, long-term needs coexist with short-term needs that must be addressed in a timely fashion. For examples, people in disaster areas need to continuously receive updated disaster data related to local areas, such as flooded areas nearby or the collapse of the nearest freeway, to know the situation of the surrounding areas and quickly escape from disaster, as well as data related to the overall situation, such as the path of a Hurricane. In addition, it is critical to meet short-term needs to rescue distressed people by establishing dynamic communication between citizens in distress and emergency response personnel.

Emerging technologies such as smart mobile devices and the online social networks (OSNs) allow unprecedented ease in discovering and communicating with their peers at anytime and anywhere and, in turn, bring a paradigm shift in how users interact with each other. To leverage emerging technologies to cope with disasters, some mobile applications have been developed, such as the Shelter Finder App of the Red Cross [1], the Outbreaks Near Me App of the HealthMap [2], the Disaster Alert App of the Pacific Disaster Center [3], the HelpBridge App of Microsoft [4], and the Ushahidi [5]. However, current mobile applications focus on collection, analysis, and dissemination of disaster data in a centralized manner, and do not fully exploit the potential benefits of tapping into mobile devices and OSNs in enhancing the ability of users to dynamically organize disaster-responsive communities and cooperate with each other during emergencies. For example, it would be helpful if a distressed person with a mobile device can use sensor information (GPS coordinates, images and audio) in combination with user-input messages to a disaster community and receive a cooperative help from people nearby. To this end, the following challenges must be addressed.

  1. 1.

    Establishing temporary relationships with nearby peers that can give essential information or vital help – It is desirable that users are able to establish temporary social relationships with peers that may not be in their circle of friends, such as other users who are nearby within a geographical area. Typical OSNs connect users to friends who are selected by users themselves based on pre-established relationships built over a long period of time. However, in disaster situations, in which short-term relationships with strangers are necessary, users may not be able to effectively discover and communicate with others who may be in the best position to provide help. Existing OSNs are thus fundamentally hindered by these constraints.

  2. 2.

    Disaster-responsive ad-hoc communication links – Existing centralized OSNs may become unavailable during a disaster due to outages in the network. For instance, users may not be able to connect to the central services of Twitter [6] or Facebook [7] in a disaster situation. Moreover, considerations on performance, capability, and privacy are additional limitations of traditional centralized OSNs, as they require all information to be processed by (and shared with) a provider.

  3. 3.

    Decentralized disaster response – Real-time processing and sharing of local disaster data captured by environmental sensors and people are essential for effective rescue and evacuation. Although a centralized DRS may not be working correctly in a disaster situation, critical information must be disseminated to people and disaster data must be retained for disaster recovery in the future.

To meet the challenges above, we propose the Hybrid Disaster Response System (HyDRS) that supports both centralized and decentralized disaster responses on the basis of on-demand collaboration between nearby objects, including environmental sensors and users, over ad-hoc social overlay networks. The rest of the paper is organized as follows. In Section 2, we describe our motivation for innovative disaster response and identify the contributions of the HyDRS. In Section 3, we explain the layered approach to disaster response and describe the three phases in the HyDRS implementation. In Section 4, we focus on the Active HyDRS and describe its architecture, operational flow, and example use cases. In Section 5, we present simulation results and then introduce related work in Section 6. In Section 6, we summarize our contributions and discuss future research directions.

2 Motivation

2.1 Requirements for innovative disaster response

To protect the safety of citizens, disaster response systems need to support the following features.

  1. 1.

    Dynamic creation and maintenance of localized disaster community - As stated earlier, in a disaster situation, localized communities can play a key role by enabling people closely located each other to receive sensing information from nearby sensors, share local information, and provide/obtain help to/from nearby people. OSNs have great potential to facilitate wide and rapid dissemination of disaster information and recruitment of nearby people because of its huge user set. For that reason, many location-based social networks (LBSNs) have been proposed for disaster response. However, existing LBSNs have not much considered smart devices such as surveillance cameras and sensors and emergency-responsive cooperation between human users and sensors (See Section 6.1).

  2. 2.

    On-demand creation and management of ephemeral localized social networks - Existing centralized OSN services and disaster response systems that mediate user communication raise major concerns in performance, fault-tolerance, and privacy. Therefore, it is required to dynamically establish and maintain connections between nearby peers without interference of a centralized server.

  3. 3.

    Localized disaster response – The disaster response services including disaster data management and rescue must be available even if a centralized system and infrastructures are destroyed.

2.2 Contributions

To meet the requirements above, we propose the Hybrid Disaster Response System (HyDRS) that allows users to effectively cope with a disaster by discovering essential sensors and people who can give vital information and help and communicating with them using their mobile devices. It dynamically creates ad-hoc social overlay networks that encompass mobile devices of users and sensors to enable real-time information sharing and knowledge creation on top of in a peer-to-peer (P2P) so that it is not constrained by the availability, capability and privacy considerations of central services. The features of the HyDRS are as follows.

  1. 1.

    Static and dynamic localized disaster community – The HyDRS extends the organization and cooperation mechanism of Whistle [8] that creates a large-scale user pool with structured user contexts while minimizing user interference, searches the most suitable users in real-time, and organizes emergency communities with eligible and available users. Unlike Whistle, in the HyDRS, smart devices such as surveillance cameras and environmental sensors can be also a community’s members. Basically, the communities are divided into two types, the static community and the dynamic community.

    A static community is a location-based community that is created and maintained by a local manager which administers a zone. An eligibility condition is always objects’ proximity and the goal of the static communities is data sharing among members. Note that the zones must be predefined and the local managers need to be installed by a government agency, such as The Federal Emergency Management Agency (FEMA) in the United States, prior to disaster management. A dynamic community is a goal-oriented community that goal and eligibility criteria are dynamically defined. A dynamic community is created upon a distressed person’s request and maintained by one or more local managers.

    To organize effective communities, the HyDRS searches the most suitable objects in real-time, based on eligibility conditions. Once a community is created, members start to communicate and cooperate with each other. Currently, the HyDRS is supposed to provide the four levels of cooperation service: 1) Posting (Passive information sharing), 2) Alerting (Active information sharing such as notifying users in disaster areas), 3) Donate (Passive cooperation such as donation of water, food, or shelter), and 4) Rescue (Active cooperation).

  2. 2.

    Ad-hoc localized social overlay networks – The HyDRS requires instant peer-to-peer (P2P) communication among social peers nearby. To this end, the HyDRS leverages SocialVPN [9] to incorporate bootstrapping through social connections. SocialVPN is a network overlay technique that embeds social links in its topology by providing virtual private IP networking, in order to support mobile peers, unstructured P2P routing, and network resilience. Such an overlay provides a foundation to address performance, privacy and fault-tolerance concerns in a disaster situation by allowing direct peer-to-peer communication without the interference of a centralized system.

  3. 3.

    Hybrid disaster response – In the HyDRS, localized disaster communities carry out disaster response in a decentralized manner. A disaster community is able to provide local disaster information and organized help to distressed people. In addition, local disaster data is stored in local manager nodes or object nodes until a centralized system is available.

3 Hybrid disaster response system

3.1 3-tiers architectural layers

The HyDRS aims to process and collect local disaster data in real-time, and dynamically connect a variety of networking elements. To this end, the HyDRS integrates techniques that are applied to different architectural layers: the networking layer, the coordination layer, and the application layer.

At the networking layer, a network overlay allows devices to communicate over private (possibly ad-hoc) tunnels with social network peers using a virtual network abstraction, SocialVPN [9]. SocialVPN creates and manages end-to-end VPN tunnels among endpoint devices, exposes a virtual network interface to each device, and uses an OSN service (accessed through the XMPP protocol) to discover tunnel endpoints and exchange public key certificates for VPN configuration. SocialVPN virtual network software runs on each device, and is responsible for picking and injecting packets from a virtual network interface (e.g. a tap virtual device), determining their overlay destination based on virtual IP addresses, encapsulating, encrypting, and forwarding packets through overlay link tunnels. Membership in the SocialVPN is managed through the OSN service, allowing temporal VPNs to be created and terminated on demand.

The coordination layer is responsible for managing membership of objects (e.g. users and sensors) on SocialVPNs that are dynamically established for emergencies, and bringing objects across different geographical regions into a virtual community to assist in passive and active cooperation among objects. At the application layer, the HyDRS application software can be used on top of dynamically established SocialVPNs for sharing data or streaming audio/video between two peers.

3.2 Disaster response layers

The HyDRS consists of three response layers as shown in Fig. 1: the physical layer, the localized response layer, and the generic response layer. The physical layer represents our real world that consists of immobile objects (e.g. local managers or fixed sensors) and mobile objects (e.g. human users and vehicles). Each object becomes an end node of a disaster-responsive social network and has temporary connections with previously unknown users and/or sensors in order to effectively respond to disasters.

Fig. 1
figure 1

Disaster Management of the HyDRS

Full size image

Ordinarily, each user performs normal social networking tasks, for examples, posting a message or making friends through existing OSNs. When a disaster occurs, users who turn on the HyDRS application are immediately involved in the nearest static community. After joining a local community, they are able to communicate and cooperate with their nearby peers within the local community. Towards this end, the localized response layer takes responsibility of managing local communities and local disaster data. When a centralized system becomes available, it collects all local disaster data stored in local managers and objects. The generic response layer manages comprehensive data collection and analysis.

3.3 Phases of HyDRS

To realize these innovations in a stepwise fashion, we conceive of three phases of the HyDRS, based on levels of innovation as shown in Table 1: the Passive HyDRS (Phase-1), the Active HyDRS (Phase-2), and the Evolutional HyDRS (Phase-3). The Passive HyDRS aims to support information sharing (passive cooperation) between members of a static community. People within the same community can receive disaster-related data from participating sensors in text format and share own information with other members through a P2P data sharing and streaming.

Table 1 Features of three phases of the HyDRS
Full size table

In the Active HyDRS, a local manager is capable of creating an on-demand dynamic community across zones by interacting with neighbor local managers, conducting local data mining, and if necessary, saving disaster history data in its database. In each community, users can share their data with a few selected members to protect their privacy, and the health of connections between members is continuously maintained until termination. The Evolutional HyDRS is able to handle heterogeneous data and support decentralized data handling and community management. Hence, an individual end node can organize a community based on its demand. Furthermore, an end node keeps disaster data when super nodes are unavailable. Its application service is upgraded to a P2P-based visual map board service so that users can understand the big picture easily.

4 Active HyDRS (Phase-2 HyDRS)

Among three phases of the HyDRS, in this paper, we focus on the phases-2 HyDRS (Active HyDRS). To describe the Active DRS in detail, we present its overall architecture, operational flow, and two example use cases in this section.

4.1 Architecture

The Active HyDRS consists of a number of local managers and object applications that are connected through disaster-responsive social networks as shown in Fig. 2. We assume that a local manager is a trusted party that complies with laws and regulations relevant to privacy protection and it consists of five components as below.

Fig. 2
figure 2

Overall architecture of the Active HyDRS (Phase-2 HyDRS)

Full size image

  • Object Data Manager –This component manages object-related data, including dynamic location data and trust values of objects. If requested, it searches the most suitable objects for a community in real-time, based on eligibility criteria for the community. To this end, the Active HyDRS adopts and extends the Whistle Location Ontology and the location-based search algorithm [8].

  • Community Manager – This component aims to organize a local community with most suitable objects. When receiving a request, it fetches a corresponding community template and delivers eligibility conditions for necessary members to the Object Data Manager. When the Object Data Manager returns a set of candidates, it selects the most suitable candidates and checks their availability. With only available users, it creates a member list with members’ XMPP accounts.

  • Overlay Manager – The goal of this component is to dynamically create overlay network configuration files for each member so that members can automatically establish social connections among them. To do so, it receives a member list from the Community Manager and generates virtual IP addresses for each member, and then distributes the generated configurations to members.

  • Localized Disaster Data Processor – This module processes and stores local disaster data produced by sensors and users. For better scalability, the Localized Disaster Data Processor will leverage existing technologies in big data management and cloud computing to accommodate a sudden burst of data flooding from massive population in the future.

An object application is composed of two components: the Overlay Controller, and the Disaster Communicator.

  • Overlay Controller – This controller takes responsibility of creating, maintaining, and removing social overlay links. According to a configuration file that the Overlay Manager sent, it establishes ad-hoc overlay connections between members, maintains network condition, and removes connections when cooperation is terminated.

  • Disaster Communicator – This communicator displays members and enables a user to cooperate with each other through a rich set of communication and sharing methods (e.g. text messaging, file transfer, and text/audio/video conferencing). Each communicator has an Access Controller that prevents indiscriminate sharing of private resources and information based on privacy policies of users and devices. To facilitate immediate yet secure cooperation in disaster situations, the Access controller should be able to answer to three questions: 1) what should be protected during cooperation for each type of objects; 2) what can be criteria to authorize an access (e.g. an object’s status/attribute, access purpose, action, or role); and 3) how we can enforce security policies in a decentralized manner. As an initial step, the Active HyDRS employs the community-centric property-based access control model (CPBAC) [10], a cooperation-aware access control model for OSN users. Since the CPBAC model considers human users only, a more comprehensive model considering cooperation between smart devices and human should be applied in near future.

4.2 Disaster-responsive social overlay network

Today the Internet presents an environment where end-to-end user connectivity has been hindered by Network Address Translators (NATs), firewalls, and user mobility. People are increasingly interacting with peers through online social networking (OSN) services and applications. In a disaster situation, however, OSN services that mediate user communication in a centralized manner raise major concerns in performance, privacy, and fault-tolerance. Our approach therefore demands interactive P2P communication among social peers. To this end, we investigate novel network overlay techniques that embed social links in its topology, provide virtual private IP networking as a core service, support mobile peers and unstructured P2P routing, and is resilient against failures.

At the networking layer, the overlay can be visualized as a communication system where every participating device (e.g. mobile devices, surveillance cameras, environmental sensors, or desktop) has virtual private links to each of their OSN social peers. As described above, in the Active HyDRS, the social peers are determined based on their proximity and capabilities, and social relationships are ephemeral. Such an overlay provides a foundation to address performance, privacy, and fault-tolerance concerns. This is because it allows users to leverage OSN services to discover and establish peer relationships, while bypassing a centralized service to communicate end-to-end with social peers. Direct peer-to-peer communication is important when privacy is desired (e.g. users do not wish to store private data on OSN provider resources), when the exposed OSN interfaces are performance-limiting and/or limit scalability (e.g. OSN imposes limits on size or rate of requests), or when the OSN service is unavailable.

A P2P virtual network link is created in the overlay network as follows. Each device is equipped with a virtual network interface as shown in Fig. 3, and a user-level overlay software router is responsible for picking up and injecting IP packets from this interface. When an endpoint sends a packet destined to another endpoint in the overlay, the software router looks up the overlay ID associated with the endpoint’s virtual IP address. If it does not have a link to the destination, it uses the local manager’s XMPP service to initiate the establishment of a link. This involves exchange of network endpoints. A network endpoint is possibly discovered using STUN services, when nodes are behind network address translators (NATs), and possibly using TURN relay services when symmetric NATs cannot be traversed using STUN-based hole punching.

Fig. 3
figure 3

Architecture of the Overlay Controller

Full size image

The XMPP request also contains a fingerprint of the certificate of each peer, which is used to validate the request. This process leverages the libjingle library for session establishment. Once a Jingle P2P link is established, it is used as a basis for tunneling virtual IP packets in a P2P fashion. In our approach, packets come through a virtual Network Interface Controller (vNIC) into the Packet Forwarder. The Link Table maintains information on local overlay links to community members. If a lookup is successful, the packet is forwarded over the appropriate link. Packets that are not reachable directly through a link generate an upcall to the Router module, which maintains the Next-hop Table, a source-based forwarding table that it discovers through limited-scope flooding. The Router module self-adapts to route around failures by resending route discovery messages and by managing its forwarding table.

4.3 Operational flow

In a disaster situation, the Active HyDRS is operated according to the following operational flow.

  1. 1.

    Object registration – An object including a human user needs to register in the central HyDRS server and install an object application shown in Fig. 2, before taking or giving cooperative help in disaster situation. A user can sign up with his/her existing OSN account (for example, Facebook or Twitter) and enter additional contexts. With a user’s OSN username, the Object Data Manager in a central server fetches various user data from an OSN using APIs that the OSN provides. Once the Object Data Manager retrieves all related data from the OSN, it creates a sticky object data set, encrypts the data set with its private key, and sends it to the object.

  2. 2.

    Object joining in a static disaster community – When a disaster occurs, an object sends a joining request with its sticky data set to the nearest local manager. Note that object applications know location of local managers. When receiving a request to join a location-based static community, a local manager decrypts the object’s sticky data set with the public key of the central server, and maintains those object data until the object leaves the zone. In a disaster situation, a local manager maintains membership of objects in its zone in a decentralized manner and users in its zone can communicate with peers nearby, regardless of availability of a centralized service.

  3. 3.

    On-demand creation of a dynamic rescue community across multiple zones – When a user in danger sends a request for disaster rescue, a local manager retrieves a community template selected by the requestor from the Template Repository and asks the Object Data Manager to find out candidates who meet eligibility conditions. In candidate search, the primary criterion is users’ locations. If there is no eligible user in a zone, then the local manager broadcasts the request to neighbor managers. After receiving the candidate lists from neighbors, the Community Manager selects the most suitable candidates and sends an invitation to each candidate with information about a rescue community. With only available candidates, the local manager finalizes a community’s members and the Overlay Manager creates network configuration files for each member.

  4. 4.

    Secure and unrestricted cooperation among members – As soon as a member object receives a configuration file and a member list, it establishes ephemeral social overlay connections between members and runs the Communicator. All conversations and resources are shared through the Communicator are protected from unauthorized accesses by the Access Controller. Towards this end, a user must specify its own access control policy when it installed an object application.

  5. 5.

    Localized management of disaster data – In the event of a disaster, user-generated disaster data and sensing data are sent to a local manager. The Localized Data Processor of a local manager extracts disaster situations such as local torrential rainfalls in its zone. Note that the third, fourth, and fifth steps can be operated in parallel.

  6. 6.

    Community dissolution – When an object leaves a zone, it sends a withdrawal request to a local manager of a static community. Then, the Object Manager deletes the data related to the object while the object removes all overlay connections to members of the static community. Unlike location-based static communities, a dynamic community is terminated by a community’s leader. When a community’s goal is achieved, a leader notifies members of the end of cooperation, and in turn, each object removes overlay connections with members of the dynamic community.

4.4 Example use cases

For better understanding, we describe two example use cases of the Active HyDRS, the Localized Disaster Data Management (static community) and the Disaster Rescue (dynamic community).

  1. 1.

    Localized Disaster Data Management – Let us suppose a hurricane hits the East Coast of Miami in the United States. Alice is far from the disaster area, while Bob is in that area. When a local manager (super node) detects a disaster, it starts to create its own static community consisting of pre-defined surveillance cameras and sensors within its geospatial zone. Note that disaster detection is out of scope of this paper.

    Once Alice and Bob turn on their Active HyDRS application, those applications automatically check if they are in a disaster area. If a user is under the effect of disaster (in this case, Bob), his application sends a joining request to the nearest local manager so that Bob can receive local disaster data. Towards this, a local manager aggregates and processes local disaster data sent from member objects of its static community. One of surveillance cameras in its zone sends an image of collapsing bridge nearby Bob. The local manager quickly processes that image and recognizes a dangerous situation. In turn, it notifies its members including Bob of the status of that bridge, and shares the news with neighbor communities. Such localized data processing and management enables quicker dissemination of local disaster situations (e.g. the populations of disaster areas or the number of epidemic disease patients).

    The local manager maintains local disaster data until a centralized system is available. Once the central system is up and running, the centralized service can create precise situation maps and allocate emergency resources more quickly and effectively.

  2. 2.

    Disaster Rescue – Let us assume that Bob breaks his leg while escaping a disaster area. He sends a request for emergency rescue with his location to his local manager (local manager of the zone C in the Fig. 1). The local manager broadcasts Bob’s location and necessary capability into neighbor managers in the zone A, B, and D. After receiving responses from neighbors, the local manager creates a rescue community with eligible objects. Finally, two people who are close to Bob assist in search and rescue and they all can escape successfully.

    Compared to cooperation through existing OSNs, the Active HyDRS can promote active rescue by dynamically creating a community with necessary sensors and people, regardless of pre-established social relationships. To protect Bob’s privacy, his rescue request and medical/location information are shared with only a few selected members.

5 Evaluation

As a first step to evaluate the performance of the Active HyDRS, we developed a prototype and simulate community creation process in three steps: 1) candidate search, 2) community confirmation with only available candidates, and 3) establishment of mobile-to-mobile SocialVPN connections between members.

First, we generated a set of synthetic profiles representing 1 million objects including human users and sensors. Towards this end, we referred well-known ontologies, for examples, GeoNames ontology [11] for location data, the occupation profiles of the United States department of Labor, and the Semantic Sensor Network Ontology [12] that defines concepts related to sensors (e.g. sensor type, accuracy, response time, latency) and relationships between concepts. Using the synthetic data set, we first measured the speed of the candidate search for a dynamic community. Note that we simulated creation of dynamic communities only. This is because a static community is instantly created by a local manager with predefined members (mostly sensors and surveillance cameras).

5.1 Evaluation of candidate search

When a local manager receives a request for dynamic community, it immediately searches candidates who meet eligibility conditions for a community. Note that in this simulation, the Active HyDRS uses Whistle’s Location Ontology and search algorithm [8]. Figure 4 presents the time to search candidates as a number of objects increases from 10,000 to 1 million.

Fig. 4
figure 4

Evaluation results of Candidate Search

Full size image

As you can see, with 1 million objects, the location-based search in a single zone takes less than 400 milliseconds (ms) while the cross-zone search takes 900 ms. It seems that the overhead for the cross-zone search is because of communication delays between local managers. The overhead for the multi-criteria search using location, capability, and turnaround time is continuously less than 1200 ms in all the search cases, which is a reasonable timespan to search candidates.

5.2 Evaluation of community confirmation

After candidate search, a local manager must send invitations to all candidates in order to check their availability. If the most suitable candidate is unavailable, then the manager sends an invitation to a second choice candidate as specified in a community template. When a local manager receives acceptance messages from all necessary members, it confirms a community’s members.

To evaluate the performance of the community confirmation process, we measure the time taken to receive acceptance from 100 members among 1 million objects. To do this, we randomly generated objects’ acceptance rate and turnaround time for each simulation and conduct simulations 5000 times with variations in mean acceptance rate from 0.5 (50%) to 1.0 (100%) and mean turnaround times: 400 ms, 600 ms, 800 ms, 1000 ms, and 1200 ms as shown in Fig. 5. For instance, the first simulation examined the community confirmation time when objects’ mean acceptance rate was 0.5 and their mean turnaround time was 400 ms and the results was 97 s.

Fig. 5
figure 5

Community confirmation time with variations in mean acceptance rate and mean turnaround time: in milliseconds (line chart) and in seconds (table)

Full size image

As you can see in Fig. 5, the community confirmation took 97.012 s when a mean of acceptance rate was 0.5 and turnaround time was 400 ms. However, it took 113.776 s with 1200 ms mean turnaround time. In case of 1.0 mean acceptance rate, it took only 46.927 s and 52.344 s respectively. It means that objects’ acceptance rate is a determinant of the community confirmation process. For rapid creation of dynamic community, local managers are therefore required to keep track of objects’ acceptance ratios and select a candidate that has a higher acceptance rate first.

5.3 Evaluation of SocialVPN in mobile-to-mobile communication

The HyDRS provides connectivity among mobile devices for users who are in a disaster area using P2P virtual private network links driven by temporal social network relationships. It is therefore essential to measure the overhead to run SocialVPN on mobile platforms to determine the feasibility of the HyDRS. In this experiment, we evaluate the end-to-end overhead of SocialVPN for mobile-to-mobile communication.

In order to measure overheads due to encapsulation, tunneling, and encryption over P2P channels, the evaluation considers data transfers between mobile devices and primarily focuses on measuring the transfer time and the number of packets and Bytes while transferring various sizes of images. Another metric that has been evaluated is the connection establishment time when a new mobile device joins the SocialVPN. Note that the overhead of running SocialVPN on mobile platforms in mobile-to-workstation environments is presented in [9]. In addition to the previous evaluations, in this paper, we present new experimental results measuring the overhead of running SocialVPN on Android-based devices in mobile-to-mobile communications.

To measure the overhead of running SocialVPN on mobile platforms, we conduct an experiment in which two mobile devices (Nexus 5 and 7) are bound to a SocialVPN overlay through a XMPP server deployed on FutureGrid [13] cloud resources. These two devices are equipped with 2.3Ghz (Nexus 5) and 1.2Ghz (Nexus 7) Quad-core processor respectively, and we use SocialVPN version 14.07 for Android.

We measure the transfer time and the number of packets and Bytes transferred using the Wireshark application [14] for Android, while two mobile devices perform various file transfers with different sizes of images using SSH File Transfer Protocol (SFTP). Table 2 and 3 show us the cost comparison between when two mobile devices exchange various sizes of images through Wi-Fi and SocialVPN with respect to total number of packets and Bytes, and the file transfer time. First, as shown in Table 2 and 3, SocialVPN has 13.5% and 15.3% overhead in terms of the number of packets and Bytes, with small variation when compared with Wi-Fi. For tunneling, SocialVPN uses a Maximum Transmission Unit (MTU) smaller than typical (1280 Bytes vs. 1500 Bytes) to avoid packet fragmentation. IP encapsulation of SocialVPN incurs attaching 40 bytes of an extra header for each packet consisting of 20-byte source unique identifier and another 20-byte destination unique identifier. The overall overhead introduced by the SocialVPN layer, per packet, is around 15%, as reflected in the cost for the file transfer. Similarly, as the number of packets and Bytes, Table 2 and 3 demonstrates around 13% of overhead for file transfer time, which is an end-to-end metric accounting for endpoint processing at the mobile devices.

Table 2 Comparison of Total Number of Packets and Bytes, and File Transfer Time
Full size table

In the HyDRS, it is critical that connectivity among mobile users and sensors in disaster areas is established promptly so that they can communicate and collaborate with each other in a timely manner. In this experiment, we measure the connection establishment time for a newly joining mobile device under the situation where another device is in the overlay network. To this end, we deployed a mobile device into SocialVPN and measured the connection setup time when a new mobile device joins the SocialVPN overlay. The experiment has been repeated 100 times and the averaged value is recorded. Results show that the average connection setup time is 3.29 s with a variance of 0.12 s. This connection setup time includes negotiation of the P2P tunnel through the XMPP service.

Table 3 SocialVPN Overheads respect to WiFi
Full size table

6 Related work

6.1 Location-based social networks (LBSNs)

Location-based Social Networks (LBSNs) aim to enable social users to share location-embedded information with friends and also make new friends who are recommended based on similarities in locations in the physical world as well as their location-tagged media content [15]. At present, there is a variety of LBSNs; for examples, NeerbyFeed Friends [16], Facebook Places [17]. According to the study of TNS in 2012 [18], mobiles users are increasingly using location-based services. Around a quarter uses it to find restaurants and entertainment venues (26%) and one in five is using it to find their friends nearby (22%).

Unlike existing LBSNs that are mainly focusing on sharing of geo-tagged information and recommending nearby friends, the HyDRS focuses on dynamic organization of local communities and cooperation management within communities. Existing LBSNs process location-embedded data in a centralized manner to find interesting places, events, and people, while the HyDRS processes location-tagged disaster data in decentralized manner to grasp local disaster situations. Above all, existing LBSNs basically consider human users only. In contrast, the HyDRS aims to create localized ad-hoc social networks that include computing devices, such as sensors and vehicles, as well as users. Furthermore, existing LBSNs is insufficient for active disaster response due to lack of real-time organization and cooperation management mechanisms.

6.2 Ad-hoc overlay network

A key motivation behind network overlays is the ability to layer functionality that enables deployment of new useful services on top of existing, unmodified Internet infrastructure. Overlays can be used to provide various services, such as resilient routing [19], content-delivery networks [20], file sharing [21], distributed hash table object storage [22], and voice-over-IP [23]. Following the taxonomy of [24], the disaster-responsive social overlay network in the HyDRS can be characterized as a P2P routing security overlay.

RON [19] is a routing overlay that provides resilient communications to applications through a set of overlay nodes. In contrast to RON’s primary motivation to provide resilient routing across widely-distributed servers and its approach of quickly detecting failures in Internet routes and recovering from these failures through overlay routing, the primary goals of the disaster-responsive social overlay network in the HyDRS are to recover end-to-end connectivity and selectively create secure network links among mobile social peers during disasters. RON achieves resiliency through a managed all-to-all overlay topology. In contrast, the proposed overly networks self-organizes a social, unstructured topology.

A closely related routing P2P overlay is UIA [25]. UIA follows an ad-hoc peering model and does not leverage OSN relationships and infrastructure to build social graphs. Furthermore, UIA has not evaluated neither online social graph networks where constraints on the number of connections arise in large-degree or resource-limited nodes, nor peer churn and its impact on topology.

SocialVPN [9] has demonstrated a P2P VPN and provides evidence that user-level social VPN overlay routers are feasible. The SocialVPN code has been ported to Android and allows mobile devices to connect among each other as well as to infrastructure resources in a seamless manner. Measurements show that the per-packet latency overhead (of the order of 0.5 ms) and achievable bandwidth (of the order of 60Mbps) can support a wide range of applications. SocialVPN has been used by thousands across the world. The availability of an implementation with a user base is a differentiating factor with respect to related systems such as UIA.

6.3 Bluetooth-based emergency response systems

Recently, the emergency response systems (ERSs) using Bluetooth or Wi-Fi beacons have been emerged [26,27,28,29]. Most of the Bluetooth-based ERSs are focusing on creating an instant communication network and transmitting simple text messages by using Bluetooth or Wi-Fi beacons.

GoTenna [26] is a packet-size tool that immediately creates a low-frequency radio wave network so that a user’s mobile phone can send emergency messages to someone who has a GoTenna or is located within reliable cellular networks. It helps distressed people to communicate with each other, when existing cellular service is unavailable. Peter Rysavy [27] proposed a way to get to wireless 911 with better accurate address instead of approximate coordinates, using Bluetooth and Wi-Fi beacons. In an emergency, Bluetooth beacons, such as Apple’s iBeacon [28], send signals to a patient’s mobile phone. When receiving signals, the phone calculates its location based on the distance from signaling beacons and signal strength and then provide that location when dialing 911.

The emergency response system based on Bluetooth low energy (BLE) beacons [29] also leverages Bluetooth beacon technology. When a cellular network is disabled, it creates a BLE network consisting of at least three BLE beacons and a master beacon. When an emergency occurs, people within a BLE network can send an emergency request. A beacon receiving emergency requests forwards that requests to the master beacon with the location information of a requestor. Then, the master beacon alerts emergency response personnel nearby. Some of smart phones, for example IPhones running iOS 7 or later, may be able to function as BLE beacons if programmed to provide functionalities of the proposed BLE beacons. Otherwise, a large number of BLE beacons should be pre-installed in the area.

Compare to the HyDRS that assumes the availability of the local network infrastructures (for examples, Internet connectivity and the SocialVPN XMPP services must be available), the Bluetooth-based ERSs allow emergency communication between distressed people even when the local network infrastructure is destroyed. However, due to the short transmission range of Bluetooth (e.g. one mile for GoTenna and 230 ft for the BLE network), the Bluetooth-based ERSs require a dense and widespread deployment of beacons for practical use. Furthermore, they focus on creating a temporary network and transmitting simple messages but do not consider organization of emergency communities and cooperation within communities. To cope with different levels of disasters, the HyDRS may adopt the Bluetooth based network technologies in its networking layer in the future.

7 Conclusions

To address an urgent need for short-term ad-hoc connectivity between nearby people and environmental sensors in disaster situations, we propose the hybrid disaster response system that deals with disaster in a distributed manner. The HyDRS enables distressed people to connect with each other based on their proximity and capabilities regardless of pre-established relationships, share vital information related to surrounding areas, and rescue distressed people without serious privacy loss. For complete disaster response service, however, the following work should be conducted in the future.

  • Distributed data processing under the constraints of computing resources

  • Disaster-specific situation model

  • Extension of organization, cooperation, and security model to consider sensors as well as human users

  • Resilient and secure peer-to-peer overlay routing in situations where the SocialVPN XMPP service is unavailable, or when Internet connectivity of a subset of devices is restricted and only ad-hoc connections to nearby Internet-connected devices (e.g. over Bluetooth) are available.