In-Vehicle Cloudlet Computing System for Disaster Information based on Delay Tolerant Network Protocol

Transcription

1 2017 IEEE 31st International Conference on Advanced Information Networking and Applications In-Vehicle Cloudlet Computing System for Disaster Information based on Delay Tolerant Network Protocol Masaki Otomo Graduate School of Software and Information Science Iwate Prefectural University Iwate, JAPAN Goshi Sato Faculty of Software and Information Science Iwate Prefectural University Iwate, JAPAN Yoshitaka Shibata Faculty of Software and Information Science Iwate Prefectural University Iwate, JAPAN Abstract In this paper, we propose an in-vehicle cloudlet computing disaster information system that can flexibly deal with critical network connectivity. In order to achieve this purpose, we develop a dynamic allocation of server resources in accordance with the load change on the system so that it is possible to take full advantage of in-vehicle server and network resources in the disaster areas. Also, by introducing mobile cloudlet computing and DTN protocols, our system can realize rapidly sharing disaster information even if the communication infrastructure is disconnected or challenged in the disaster. Keywords Disaster Information System, Cloud Computing, System Virtualization, Delay Tolerant Networking I. INTRODUCTION From the geological conditions of Japan Island, many serious disasters such as earthquake, tsunami and typhoon occur in history. A huge number of people, buildings and communication infrastructure are completely damaged. In fact, the Great East Japan Earthquake on March 11, 2011 [9] and Kumamoto Earthquake on April 16, 2016 brought huge damages [*]. Many Information network infrastructures were destroyed and the network traffics were seriously congested. In order to respond to the anticipated large scale disasters, such as Nankai Trough Quake and Tokai earthquake, GIS based disaster prevention systems which can perform collecting and sharing disaster information, resident safety confirmation, decision making to disaster-response headquarter are developed On the other hand, in recent, cloud computing is getting popular for various business fields because of its easy and efficient introduction and elastic expandability for computing resource allocation. Using cloud computing services, a series of preliminary works including design and maintenance of hardware and software are carried out at a data center. Since the users do not need to newly introduce servers physically for business, the maintenance cost can be largely reduced. Furthermore, by introducing network and server virtualization technologies, user can easily construct and run his own private cloud computing system. Thus, there are many advantages to use the cloud computing to provide Internet and Web services. On the other hand, so far we have investigated the research of a distributed disaster information sharing system by considering mobile environment on disaster situation [1]. In this system, the network states are monitored at background. If network access to Internet is difficult, then the disaster information is locally stored on the mobile relay station. After moving to the location where the Internet connection can be established, then the stored disaster information can be transmitted to the objective disaster information server on the Internet. However, this system does not consider the case where the server load changes rapidly and the network and server failures occur. When the disaster information server is operated just after the disaster occurred, the system failure and traffic load concentration have to be considered. [10] In this research, we introduce a mobile cloudlet computing disaster information system for large scale disasters to be able to keep continuously disaster information collection and sharing operations even the network environment is unstable or challenged. The computing resources can be also dynamically provided to different user s groups or organizations such as different local governments and offices as required to maximize the physical resource utilization. Furthermore, this system can not only provide information transmission by introducing DTN protocol on the network, but more quick collection and sharing functions by introducing mobile cloudlet disaster information servers where the communication networks are unstable or even disconnected. II. RELATED WORKS There are several disaster formation systems so far. The system of previous research [2] was developed to respond to the case where large delay and frequent link disconnection happen as a network environment. In this system, the data can transmit if the disaster server can connect to the network by monitoring the network state. The disaster information can be also smoothly shared with multiple servers of different organization such as different local governments. However, this system cannot consider the case where rapid network and system traffic change and failure. When the servers of the local government X/17 $ IEEE DOI /AINA

2 are failed by external factors such as tsunami, those systems cannot be served. In the other previous system, disaster information can be visually shown on the display by combining with GIS system or namely digital map. The user can easily understand what kind of the disaster information is registered in the system by properly using various icons and figures related to disaster properly. Furthermore, by operating seek bar on the window, the registered disaster information can be displayed in temporal order as replay operations on video window. III. SYSTEM CONFIGURATION Figure 1 shows a network system of our proposed disaster information system. There are two types of cloud computing including GDC and LDC are introduced. The GDC is a central cloud computing located at somewhere on Internet and integrates all of the disaster information stored in Temporal Servers (TSs) and LDCs in each local area. used to exchange the information between the LSs and LDC or LDC and GDC. Figure 2 shows the system behavior on challenged network condition case where the network connection to Internet is unstable or even though disconnected. Many different wireless network deivces including 3G/LTE, Wi-MAX, Wi-Fi and satellite networks are installed to organize a cognitive wireless network. Just after occurrence of disaster, movile LDC vehicle as cloudlet computing server with the cognitive wireless netowork perambulates around the disaster area and approaches to the LS. Then the LDC automatically recieves those stored data from the LS by DTN protocol. When the LDC approaches to GDC, then the GDC automatically retrieve the stored data from LDC. By collecting those disaster information, all of the data between GDC and TS, GDC and LDC are synchronized to gurrantee the consistency. Thus, data transmission between LSs and GDC can be realized throuth the LDC using DTN protocol even through the Internet cannot be available in the disaster area. Figure 1 System Configuration The LDC is based on a mobile typed cloudlet computing which is carried on vehicle. The LDC performs as cloudlet computing server. The LDC circulates around the local government office, the evacuation places, the community centers and public places where the TSs are located. The TSs as temporal servers store disaster information after the disaster occurred in each local government area. When the communication network can be available, those TSs can directly share the disaster information with the GDC. When the communication network cannot be available, those LDCs go around the disaster area and collect and store the local disaster information from the TSs until the communication network in this local area recovered. When the communication network is note available, Delay Tolerant Network (DTN) [6][7] is employed. DTN is defined as the communication protocol which can realize reliable data transmission on the challenged network condition with large delay teime and frequent network disconnection in addition to the normal network condition. In our system, DTN protocol is Figure 2 System behavior on challenged network condition IV. SYSTEM ARCHITECTURE Figure 3 shows architecture of our proposed system. By assigning the required number of Virtual Machines (VM) to each cloud server, the disaster information system can be provided. The proposed disaster information system is consisted of Monitoring Module (MM), Resource Management Module (RMM), VM Control Module (VMCM) and DTN Transport Module (DTM). The MM monitors resource utilization rates of CPU and memory of the VM and sends them to RMM. The RMM controls VM resource assignment based on the results and sends an operation commands to VMCM such as start, stop, addition and reduction of VMs. The DTM manages sending/receiving/storing data by DTN protocol. 738

3 safety state with his locations by GPS using their mobile telephone, and another is that the residents evaluate to the prespecified shelter and the disaster volunteers in the shelter register from the PC server instead of the residents. VI. PROTOTYPE SYSTEM 6.1 Prototype System Configuration In order to verify usefulness of our proposed system, a prototype system is constructed and evaluated its functionality and performance. Figure 4 shows system configuration of the prototype of our proposed system. In the prototype system, the cloud system in the prototype, Management Server manages the whole cloud system and Host provides VM resource. As LDC, a note PC is used to easily carry on the mobile vehicle. The hardware and software specification of GDC, TS, LDC is shown in the Table 1. Figure 3 System Architecture The process for resources addition is based on [3][4][5]. First, the resource utilization rates of VMs are monitored by MM. Second, the number of VM clocks or CPU resources themselves are controlled by referring the utilization rates of CPU and memories. When the CPU utilization rate is more X [%], then the CPU clock frequency is increased until U[GHz] or the number of CPU resources is increased. Also when CPU utilization rate is less than X [%] and memory utilization rate is more than Y [%], the volume of memory is increased is increased until V[Mbytes]. Finally, the process of load valancing for each resource is executed by depending on the change of VM specification. V. DISASTER INFORMATION In our research, two types of disaster information system are supported; one is stricken area information sharing system, and another is safety information sharing system. Disaster area information sharing system: Just after occurring disaster, the disaster residents register their safety information and location s data, and the disaster aid volunteer send photo images with disaster information, position information and stricken area information using mobile phones to the disaster information server. The collected disaster area information is overlaid on Denshi-Kokudo as icons and displayed by the PC client. All of the disasters are not only categorized and displayed individually, but all of the disaster can be integrated into one category and displayed on the same display. Since the icons correspond to the categories that were selected when the disaster information was registered, the user can easily understand what kind of disaster is dominated in particular disaster area. In addition, when a user reads this information on a PC client, one can use the temporal presenting operations and understand the change of the state of the stricken area through time. The safety information : The safety information is very important to confirm the lives of the evaluated residents when disaster is just occurred. It is assumed that there are two different registration cases; one is that the residents directly register his Figure 4 Prototype System Table 1 Hardware Specification of LDC and GDC Servers 6.2 Cloudstack As cloudlet computing system environment, we applied CloudStack [8] which is one of open source and can provide an infrastructure as Service (IaaS) to construct both public and private cloud computing system such as Amazon EC2. The CloudStack is used by many organizations because of its excellent GUI and easy operations. Since load balancer and firewall functions as internal architecture are also installed as standard system, more functional expansion can be possible. In our system, dynamic resource control function of VM depending on the resource utilization rate is implemented using CloudStack API on Linux OS environment. VII. PERFORMANCE EVALUATION 7.1 End-to-End Response time between TS and GDC 739

4 In this performance evaluation, each performance of end-toend response time between LS and GDC through the LDC using DTN protocol is evaluated. Therefore, it is assumed that LDC, TS and GDC exist in disaster areas and communicate with each other to send data disaster information. Figure 5 Perambulation of LDC between Each Server Figure 5 shows the traverse of LDC to TS and GDC. Firstly, the vehicle with LDC traverses in the disaster area and receives the disaster information on TS in the shelter using DTN for 60 sec. ( Connected ). Then, the vehicle releases from the shelter for 180 sec. ( Disconnected ). After that the vehicle comes back to the shelter and again receives the disaster information for 180 sec. ( Connected ). In this procedure, Connected or Disconnected between the LDC and TS servers are repeated until the 6 th step in this experiment. From the 7 th step, the LDC vehicle traverses to Headquarter where the Internet connection to the GDC can be available and transmits all of the disaster information from the LDC server to the GDC server. Thus, in the procedure form the 1st step through to the 7th step, the network communication can be guaranteed even though those servers are in challenged communication environment. Figure 6 Transmission Area in TS Each server locates on local network environment. The vehicle of LDC traverses TS or GDC and collects the data files of the disaster information during 1st to 7th steps with wireless environment. Reliability of data transmission in DTN protocols differs depending on the distance between each server. Figure 6 shows communication areas where the data can be transmitted between LDC and TS. At the area where signal strength is more than -40dBm, it is assumed that the LDC vehicle can collect data from TS sufficiently and the network condition is enough to send data between each the server. Along with this, the LDC vehicle can get high throughput during it receives data. At the area where signal strength is between -40dBm to - 60dBm, however the LDC vehicle collects data depending on the network conditions, some data is not transmitted because of the conditions. Between -60dBm to -80dBm, the network connectivity is getting worse by approaching the outside. If the LDC vehicle goes over -80dBm, it cannot communicate with TS at all. In these situations, such environment is made prospectively. Finally, the LDC vehicle transmits the collected data to GDC in the 7th step. Figure 7 shows the communication areas where data is transmitted between LDC and GDC. Figure 7 Data Quantity during 1 st to 5 th Step in TS 7.2 Results in proposed experiment The experimental results are shown in Figure 8 to Figure 10. The data size of the disaster information to be transmitted between TS to the LDC vehicle and the GDC server is 1Mbyte on every 1 second. The buffer size of the DTN bundle layers on each server is large and enough to store the transmitted data. This means that the minimum network transmission speed requires 8 Mbps. Figure 8 shows the result of the variation in quantity of the transmitted data which are stored in the DTN buffer of TS. In the scenario of the 1 st step, because the network condition between TS and LDC was Connected, the data on the DTN bundle layer in TS were immediately transmitted to the DTN buffer in LDC, the quantity of the data was 0 for this period. In the network area, the throughput value to transmit data from TS to LDC was Mbps. On the 2 nd step, because the network condition was Disconnected, the data in the TS were accumulated in the DTN buffer. On the 3 rd step, although the network condition was Connected, the data were not transmitted for 50 seconds. This is due to the time delay of the 740

5 restarting process transmission on DTN2 in which the source server took time to find the destination server. In addition, another reason except the redundancy of system configuration is the electric field strength. When the vehicle of LDC connected to the network on TS at the 3 rd step, the throughput value was 7 to 12 Mbps at -80dBm. This means the network condition was intermittent because the condition needs more than 8 Mbps to send data. After the 50 seconds, those stored data in the DTN buffer were sent to the LDC with the maximum throughput. On the 4 th step, the same result was repeated as the 2 nd step. Finally, on the 5 th step, the same result was repeated as the 3 rd step. Figure 9 Data Quantity of 1 st to 5 th Step in LDC Figure 8 Data Quantity during 1 st to 5 th Step in TS Figure 9 also shows the variation in quantity of the received data from TS which are stored in the DTN buffer of LDC. On the 1 st step, the data from TS were received and be accumulated increasingly in the DTN buffer of LDC. On the 2 nd step, because the network condition was Disconnected, the data transmissions from TS were stopped and the accumulated data of 60 Mbytes were maintained. On the 3 rd step, although the network condition was Connected, the data from the TS were not transmitted for 50 seconds. This is due to the same reason of TS as shown Figure 8. After 50 seconds, those stored data in DTN buffer were received from TS with the maximum throughput after 290 seconds. On the 4 th step, the same result was repeated as the 2 nd step and the same result on the 5 th step was repeated as the 3 rd step. When the iteration in the 5 th step finished, the vehicle went out from the TS transmission area and went into the GDC transmission area at 960 seconds. In this transmission area, GDC could receive all of the accumulated data, 744 Mbytes from LDC with the throughput of more 1 Mbyte per second (8 Mbps) as shown in Figure 10. Therefore, these processes were completed at 1710 seconds. Thus, all of the data generated in TS could be uploaded to the GDC server via LDC even though the network environment is disconnected in the disaster. Figure 10 Data Quantity of 6 th to 7 th Step in GDC 7.3 Receive Window Scaling DTN2 has an issue that data cannot be transmitted from LDC to TS for 50 seconds after 2 nd and 4 th step. Therefore, we have attempted to improve the time delay to assure reliability of data transmission in DTN2. In order to improve the delay time to transmit data, we adjusted receive window size. Basically, data is transmitted after confirming the data that a communication partner was able to transmit definitely on the method of TCP/IP. On the other hand, Amount of data which is received at one time without the confirmation that the communication partner replies is called RWIN (Receive Window). It is known from the RWIN definition that the more the RWIN value increases, the more the amount of data which is received at one time also increases [12]. Thus, it can be expected that transmission time of data is reduced between LDC and TS. As the procedure to expand RWIN value, we enabled TCP window scaling and defined minimum, default and maximum value of RWIN in TS. Table 2 shows each reception window size of before/after setting. We set minimum RWIN value to 4380 which is 3 times as large as MSS, default RWIN value to which is 368 times as large as MSS and maximum RWIN value to which is 4416 times as large as MSS. By increasing the RWIN value, we attempted to shorten the delay time after 2 nd and 4 th steps in Figure 8 and

6 Table 2 Reception Window Size (Byte) MSS : 1460 Minimum Default Maximum Before After Result after Changing RWIN Value Figure 11 and figure 12 show results of data quantity in each server after changing RWIN value of TS. The transmission time could be shortened from 50 to 40 seconds after 2 nd and 4 th steps compared to the environment that RWIN values are not changed as we expected. Figure 11 Data Quantity in TS Figure 12 Data Quantity in LDC VIII. CONCLUSIONS AND FUTURE WORK In this paper, we proposed mobile cloudlet typed disaster information sharing system based on DTN. Using this system, disaster information collected will be provided for victims in the stricken areas after a disaster occurs immediately. Also by introducing mobile typed cloud computing, quick disaster information collection in the disaster areas even just after disaster occurrence can be actualized. In addition, using communication means by DTN protocol, data are locally stored when the communication network cannot be available and automatically transmit in the area where the connection to the network can be available, eventually data transmission can be attained on the any network conditions. As some future researches, we are going to implement and evaluate server resource control functions, data synchronization functions between cloud computing and reliable transmission functions in DTN with the transmission speed improved from TS to LDC. Acknowledgment. The research was supported by SCOPE (Strategic Information and Communications R & D Promotion Program) Grant Number by Ministry of Internal Affairs and Communication in Japan. References [1] Y. Sasaki, and Y. Shibata, Construction of Distributed Disaster Information System in consideration of the mobile communication environment, IEICE, "S-65"-"S-66" (2011) [2] Y. Sasaki, and Y. Shibata, Construction of Disaster information system that enables the display time series uniform, Information Processing Society of Japan (IPSJ), "3-427"-"3-428" (2010) [3] Trieu C. Chieu, Ajay Mohindra, Alexei A. Karve and Alla Segal, Dynamic Scaling of Web Applications in a Virtualized Cloud Computing Environment, 2009 IEEE International Conference on e-business Engineering [4] Gihun Jung, Kwang Mong Sim, Agent-based Adaptive Resource Allocation on the Cloud Computing Environment, 2011 International Conference on Parallel Processing Workshops [5] Zhang Zhang, Jizhong Han, Bo Li, Wei Zhou, Dan Meng, Lynn: A Multi-Dimensional Dynamic Resource Management System for Distributed Applications in Clouds, 2013 International Conference on Cloud and Service Computing [6] Delay Tolerant Networking Research Group, < [7] Delay Tolerant Networking Research Group DTN2 Documentation, < [8] CloudStack User Group, < [9] Ministry of Internal Affairs and Communications Situation of information and communication in the Great East Japan Earthquake, < n pdf> 2011 [10] Ministry of Internal Affairs and Communications Enhance of disaster tolerance in communication, < /nc html> 2012 [11] Apache Software Foundation Apache JMeter, < [12] Network Working Group TCP Extensions for High Performance, <