: An Android based Infrastructure Less Application for Post Disaster Information Exchange Suman Bhattacharjee, Student Member IEEE, Sourav Kanta, Saket Modi, Madhumita Paul and Sipra DasBit, Senior Member IEEE Department of Computer Science and Technology Indian Institute of Engineering Science and Technology, Shibpur, India suman.bhattacharjee21@gmail.com, sdasbit@yahoo.co.in Abstract Natural disasters take its toll on traditional communication infrastructure severely causing intermittent network connectivity due to partially or fully damaged communication infrastructure. Therefore, data dissemination is hampered and the volunteers and different disaster management agencies find it difficult to communicate among them. Fortunately, a sizeable population (around 35% - 45%) these days owns various wireless devices like smart phones, tablets etc. with multiple communication interfaces (Bluetooth, Wi-Fi Direct). These devices with their alternative communication capabilities can be harnessed in a disaster aftermath in order to disseminate situational information. However, the procedure to disseminate such information through these devices should be simple enough so that minimal technical expertise is required from the user end. Several Android based applications are available which offers data forwarding service based on Wi-Fi direct. All such applications provide only unicast mode of communication while lacking to provide multicast and broadcast services. In this paper we provide a complete solution Disaster Messenger, an Android based application which allows the volunteers to disseminate information in absence of network infrastructure (through Wi-Fi direct) in unicast, multicast and broadcast mode. We perform rigorous field experiments to evaluate the performance of by varying movement speeds of the nodes and distance between the nodes. We also evaluate its performance in terms of energy efficiency. The comparison of the with a couple of wellknown file sharing applications namely and BitTorrent Sync reveals that outperforms and in terms of energy efficiency and data transfer rate in unicast mode. Due to unavailability of any competing application which supports multicast and broadcast services, we have not been able to compare the performance of our application for the said services. Keywords Post-disaster communication; Situational information; Information forwarding; Android application; Energy efficiency; I. INTRODUCTION Natural disasters damage existing communication infrastructure (wired or wireless) partially or fully. As a result, the disaster response teams and the rescue and relief teams experience huge challenge to communicate among themselves due to absence of stable connectivity. A well-managed disaster recovery operation requires effective sharing of situational information among them. Such information can help the disaster response teams and the rescue and relief teams to appropriately coordinate, manage and channelize their resources. An absence of prior knowledge about the situation results in a disproportionate distribution of relief materials among victims and shelters. But, due to the scarcity of power, network connectivity and suitable infrastructure, it is very difficult to set up a fully connected temporary network supporting data communication in the post-disaster scenario. A viable option for exchanging situational information is to use Delay-tolerant networks (DTNs), where battery-powered wireless devices (e.g. smart phones, PDAs, laptops, etc.) with multiple communication interfaces (Wi-Fi direct and Bluetooth), configured in ad-hoc mode, are used to exchange situational information [1-3]. But, this option has two major limitations. Firstly the procedure to disseminate situational information over DTNs is a complex procedure and requires fair amount of technical expertise from the users. The local volunteers working under different disaster management agencies might not be that much tech savvy. Moreover, implementing DTNs protocol suite for the application development requires data transfer through peer to peer ad-hoc mode. The root access of the device and a modified version of the operating system are essential for that purpose as majority of the device manufacturers do not support data transfer through the peer to peer ad-hoc mode due to security reasons [4-6]. Therefore, the applications developed for these platforms are not portable and distribution of the applications to the volunteers of different disaster management agencies become challenging in post disaster scenario. Therefore, we have developed, an Android application, which allows sharing of situational information (text, image, video or voice recordings) without the help of network infrastructure. We harness the potential of Wi-Fi direct to provide DTNs like features without the aforesaid limitations. Moreover, creates a new thread for every transmission and reception. Hence it can send or receive data to/from multiple sources in parallel.
New Existing Authentication Registered Interaction Activity Mode Request File Manager Fig. 1. Modular architecture of Several other applications are available in the market which offers data forwarding service based on Wi-Fi direct viz. [7] and [8]. is a file sharing application that shares files through Wi-Fi direct across multiple platforms including Android, Windows and ios in unicast mode. On the other hand transfer files directly from device to device through Wi-Fi direct across multiple platforms including Mac, Windows, Linux, ARM, FreeBSD, ios, Android, Kindle Fire. encrypts all files during transfer and never stores any information on third-party servers. This means data is protected against identity theft or attacks. Therefore, most of the existing applications offer data forwarding in unicast mode only. Multicast and broadcast modes of communications are unavailable. allows communication in all three modes. Another important aspect which needs to be considered while developing applications for post disaster scenario is energy efficiency of the applications. Power grids may get affected due to the extent of disaster. As a result rescue and relief teams experience unstable power supply. Majority of the devices which are used in post disaster communication (e.g. smart phones, PDAs, laptops, etc.) runs primarily on alternative power sources (battery). Such devices remain active for only a restricted period of time after which they need to be recharged. So, an application developed for those devices must be energy efficient in order to make the devices active for a longer period of time. Hence, we have evaluated the performance of our application () in terms of energy efficiency compared to and. The rest of the paper is organized as follows. Section II describes the design modules of. Performance evaluation is explained in Section III. Finally, conclusions are drawn in Section IV. II. DESIGN MODULES Store File Retrieve File File - 1 File - 2 This section introduces various modules of Disaster Messenger along with their functionalities. A. Architecture of Fig. 1 represents the modular architecture of the Disaster Messenger application. The application consists of four modules viz. Authentication, Interaction, File Manager and. File - N Success/Failure Sender/Receiver Run Application New Yes Authentication Complete Registration No Retrieval/ Storage Request Interaction Activity Mode File Manager Start a new thread with an initialized socket Are destination(s)/ source reachable? Retrieval/ Storage Retrieve/ Store File Fig. 2. Flow diagram of data transfer activity File - 1 File - 2 The main purpose of Authentication is to authenticate new users (first time users after installing the application). After authentication, the control is forwarded to the Interaction. This module consists of two sub modules namely Activity and Mode. Depending on the send or receive request selected by the user, the Interaction s transfers the control to the Activity and Mode respectively. Activity allows the user to choose the send or receive activity. Mode allows the user to choose unicast, multicast or broadcast mode of communication and subsequently request user to choose appropriate recipient(s) as destination(s). After selection of appropriate activity and mode of communication, the control is transferred to the File Manager. File Manager retrieves or stores file for send or receive request respectively. The control is then transferred to the Interaction again. The Interaction creates a new thread for send or receive request and transfer the control to the module. module sends success or failure acknowledgement to the Interaction and Yes Transmit/receive the file and close the socket to the sender or receiver No Send Receive Unicast Multicast Broadcast File - N
subsequently the success or failure acknowledgement is communicated to the users. B. Flow Diagram Fig. 2 represents the flow diagram of data transfer activity. Immediately after starting the application, the Authentication checks the authenticity of the user (for new user) and control is forwarded to the Interaction. This module allows the users to select between send and receive activities. If user wants to send information the mode of communication (unicast, multicast or broadcast) must be chosen. The control is then transferred to the File manager for selecting appropriate file. In case of receive request from user the control is directly transferred to the file manager. The file manager retrieves or stores file from/to the secondary or extended storage as per user request and sends a response to the Interaction. Upon receiving the response from the File Manager the Interaction creates a new thread for communication, checks the reachability of the destination(s) or source as per user request and finally transmit or receive the file. The control is then transferred to the which sends success or failure acknowledgement to the Interaction. C. Algorithm In this section the algorithm of is described Preamble: There are N numbers of devices in the network trying to send/receive situational information from other device(s) in any of the three modes (Unicast, Multicast or Broadcast). Each device searches for the intended sources(s)/recipient(s). If the sources(s)/recipient(s) are within the communication range, each device creates a new thread for communication and transfers control to the thread. Each device runs the following algorithm in order to send/receive situational information from other device(s). Input: Situational information to be shared among various devices Output: Sent/received data at the sender/receiver end Begin 1: if (F auth = False) /* F auth is device authentication flag*/ 2: set (D id ) /* D id user id for the new user*/ 3: end if 4: if (A select = send) /* A select is the selected activity*/ 5: if (M select = unicast) /* M select is selected mode*/ 6: D id_dest =select single device /* D id_dest is the destination device id*/ 7: elseif (M select = multicast) 8: D id_dest = select multiple devices 9: elseif (M select = broadcast) 1: D id_dest = select all devices 11: endif 12: send retrieve request to the file manager 13: select file to be send 14: create (S new ) /* S new new socket*/ 15: create (T new ) /* T new new thread*/ 16: start (T new ) 17: if (is_reachable (D id_dest ) = True) 18: while (F ack = False) /* F ack acknowledgement flag*/ 19: F ack = check (Ack) 2: endwhile 21: endif 22: elseif (A select = receive) 23: send store request to the file manager 24: create (S new ) 25: create (T new ) 26: start (T new ) 27: while (F ack = False) 28: F ack = check (Ack) 29: endwhile 3: endif End Analysing the time complexity of the aforesaid algorithm we found that the best case complexity of the algorithm is O(1) and the worst case complexity is O(n). The best case complexity arises when the sender and the receiver(s) are within the communication range of each other. In that case the receiver receives data sent by the sender immediately. On the other hand when the sender and receiver(s) are not connected then the sender will periodically checks for the availability of the receiver and the complexity of the proposed algorithm becomes O(n). III. PERFORMANCE EVALUATION In this section we analyze the performance of Disaster Messenger under different scenarios. A. Testbed Setup We have conducted several field trials in order to evaluate the performance of under different scenarios. The field trials have been conducted at the IIEST, Shibpur campus with ten volunteers equipped with Disaster Messenger preinstalled smart phones or Tablets. The volunteers have been divided into three groups (three volunteers in each group) and placed in distant locations such Fig. 3. Location of three volunteer groups at IIEST, Shibpur campus
We have used PowerTutor [1], an Android application in order to evaluate the energy efficiency of. The experiment has been conducted on S Duos 2 smart phones. The energy consumption readings from Power Tutor have been recorded during the transmission and receptions of a video file with size 83MB through Disaster Messenger for 1 times. The average energy consumption is computed by calculating the arithmetic mean of the 1 readings for both transmission and reception. Table I represents the list of Android devices along with their detailed specifications for the testbed implementation Fig. 4. Pictures of field trials conducted at IIEST, Shibpur that no groups can communicate with each other directly. One volunteer carrying a smart phone visited each group periodically to collect data from each group. Such moving volunteers are known as Data Mule [9]. It gathers data from one group and eventually moves towards other groups with the collected bundle of data. The data is stored in the secondary storage of the Data Mule. Upon reaching a new group it transmits a copy of the collected data to that group and collects data from that group. Fig. 3 represents the location of three volunteer groups at IIEST, Shibpur campus. Fig. 4 represents some of the pictures taken during field trials at IIEST, Shibpur. We have used heterogeneous devices (Smart Phones and Tablets from different manufacturers) for the field trials in order to evaluate the interoperability of the application. The performance of has been evaluated based on three aspects viz. deviation in average data transfer rate with distance between sender and receiver, deviation in average data transfer rate with movement speed of the nodes and energy efficiency of the application. The results of the field trials reveal that the data transmission range is device specific and the data transmission speed depends on the distance from the sender to the receiver. Device Name S Duos 2 J5 Moto E (1st Gen) TabS-1 TabS-2 TABLE I. DEVICE SPECIFICATION FOR TESTBED IMPLEMENTATION Device Category Memory (MB) Storage (GB) Battery (mah) Wi-Fi Direct Range Outdoor (Meter) Phone 768 4 15 8.5 Phone 248 16 33 16 Phone 124 4 198 47.5 Tablet PC Tablet PC 372 32 587 57 372 32 79 16 Moto G2 Phone 124 8 27 47.5 18 16 14 12 1 8 6 4 2 Unicast Multicast Broadcast -5 6-1 11-2 21-3 31-4 41-5 More Distance (meter) than 5 Fig. 5. Comparison between average data transfer rates with distance in three different modes 18 16 14 12 1 8 6 4 2-5 6-1 11-2 21-3 31-4 41-5 More than Distance (Meter) 5 Fig. 6. Comparison between average data transfer rates with distance in unicast mode 45 4 35 3 25 2 15 1 5 Upto 5 6-1 11-2 More than 2 Movement Speed (Km/Hour) Fig. 7. Comparison between average data transfer rates with movement speed in unicast mode
Average Energy Consumption (mj) 45 4 35 3 25 2 15 1 5 Transmission Reception Fig. 8. Comparison between average energy consumption during transmission and reception in unicast mode B. Results and discussion Fig. 5 represents the change of data transfer rate with respect to distance in three different modes for Disaster Messenger. From the result it is clear that increasing distance from the destination reduces data transfer rate. Fig. 6 represents the comparison of average data transfer rate between, and BitTorrent Sync with respect to the distance between sender and receiver in unicast mode of communication. Precisely we observe that exhibits around 8.75% and 2.81% higher data transfer rate in comparison with and Bit Torrent Sync respectively with respect to the distance between the sender and receiver. Fig. 7 represents the comparison of average data transfer rate between, and BitTorrent Sync with respect to the movement speed of the nodes in unicast mode of communication. In this scenario, we observe that exhibits around 7.1% higher data transfer rate compared to with respect to the movement speed of the nodes. Finally it exhibits around 9.2% higher data transfer rate compared to. Hence the results indicate superiority of compared to and in terms of average data transfer rate in unicast mode. Fig. 8 illustrates the comparison between Disaster Messenger, and with respect to the average energy consumption during transmission and reception in unicast mode. We observe that exhibits around 37% and 38.4% less energy consumption compared to whereas it exhibits around 33% and 36.4% less energy consumption compared to during transmission and reception in unicast mode respectively. IV. CONCLUSION In this work we have demonstrated the architecture and evaluated the performance of our proposed application. We have illustrated the time complexity of the algorithm of our proposed application and found that the algorithm exhibits time complexity of O(n) in worst case scenario and O(1) in best case scenario. We have also compared the performance of the application with a couple of well-known file sharing application namely and. The comparison reveals that Disaster Messenger saves around 37% and 33% energy during data transmission compared to and respectively. It also exhibits around 8.75% and 2.81% higher data transfer rate in unicast mode compared to and respectively. Hence, the application outperforms and in terms of energy consumption and data transfer rate in unicast mode of communication. Moreover, offers multicast and broadcast mode of communication. It also provides a simple user interface which does not demand technical expertise from the users. The aforesaid advantages make unique and suitable for post disaster communication. REFERENCES [1] S. Basu, S. Roy, S. Das Bit and S. Bandyopadhyay, A human mobility based knowledge sharing approach for post disaster need assessment using DTN, in Proc. ICDCN, article 34, 216. [2] H. Ntareme, M. Zennaro and B. Pehrson, DTN on smartphones: Applications or communication challenged areas, in Proc. ExtremeCom, 211. [3] E. Gelenbe and G. Gorbil, Wireless networks in emergency management, in Proc. PINGEN, pp 1-6, 212. [4] C. Funai, C. Tapparello and W. Heinzelman, Supporting Multi-hop Device-to-Device Networks Through WiFi Direct Multi-group Networking, arxiv preprint arxiv:161.28, 215. [5] http://android.stackexchange.com/questions/4777/connect-androiddevices-in-ad-hoc-mode-without-needing-to-net-connection [6] https://developer.android.com/guide/topics/connectivity/wifip2p.html [7] http://shareit.lenovo.com/ [8] https://getsync.com/ [9] S. Bhattacharjee, S. Roy and S. Bandyopadhyay, Exploring an energyefficient DTN framework supporting disaster management services in post disaster relief operation, Springer Wireless Networks, vol. 21, issue. 3, pp 133-146, 215. [1] L. Zhang, B. Tiwana, R. P. Dick, Z. Qian, Z. M. Mao, Z. Wang and L. Yang, Accurate Online Power Estimation and Automatic Battery Behavior Based Power Model Generation for Smartphones, in Proc. CODES/ISSS, pp 15-114, 21.