DTN-based Vehicular Cloud for Post-disaster Information Sharing

Transcription

1 DTN-based Vehicular Cloud for Post-disaster Information Sharing Celimuge Wu, Tsutomu Yoshinaga University of Electro-Communications Chofu-shi, Tokyo, Japan Yusheng Ji National Institute of Informatics Tokyo, Japan Abstract We first propose a framework which utilizes vehicular delay tolerant network (DTN) to form a vehicular cloud in order to provide information exchange without communication infrastructure. The framework does not rely on cellular network and therefore provides an approach which is suitable for postdisaster communication where cellular network is unavailable or severely congested. The paper also proposes a protocol which is able to provide vehicle-to-cloud communication in frequently changing vehicular environment. The protocol takes into account the link throughput, additional signal coverage, connection time, and the probability to encounter a RSU for the forwarder selection by using a fuzzy logic-based approach. The protocol also employs a network coding approach to reduce the overhead while maintaining a high data delivery ratio. We use computer simulations to evaluate the proposed framework. I. INTRODUCTION Vehicular ad hoc networks (VANETs) have been attracting interest for their potential roles in many applications such as intelligent transport systems. In this paper, we propose a framework which utilizes VANETs to provide communications in post-disaster situations. The communication is one of the most important requirements for post-disaster management. However, the cellular infrastructure could be destroyed or difficult to access due to the sudden increase of user traffics. VANETs could be a promising solution for post-disaster communication because vehicles could have sufficient battery and fast movement which facilitate efficient dissemination of critical information. Designing an efficient multi-hop communication protocol in VANETs is a very challenging task. Most existing routing protocols [] [6] discuss the routing problem under the assumption of a connected network topology. However, in many cases, there is no multi-hop path between the source node and the destination node. The concept of delay-tolerant networking (DTN) [7] [9] has been proposed to provide communication in a situation that no end-to-end connectivity exists (at least the connectivity is intermittent, or high error rates exist). The main approach of DTN protocols is to deliver data to an intermediate node which is not currently connected with the destination node but will possibly reach the destination in future. DTN is known as a solution to provide communications for a challenged network. There have been some DTN protocols for VANETs [7] [7]. Khabbaz et al. [] have discussed the bundle delivery problem for twohop vehicular delay tolerant networks, and proposed a protocol which could minimize bundle delivery delay. Targeting for the same network, Khabbaz et al. [] have discussed the problem of information delivery delay minimization, and proposed a probabilistic bundle release scheme. They conducted a study on the estimation of the bundle queueing, transit, and endto-end delivery delay. Most studies [2] [4] have discussed vehicular DTN based on theoretical analysis and showed the efficiency of DTN approach. However, only a few of them [5] [7] discussed about the routing procedure of the DTN. Balasubramanian al. [5] have treated DTN routing as a resource allocation problem, and proposed a framework to optimize delivery delay or delay bounded data delivery ratio. Cai et al. [6] have proposed a protocol for two-hop DTNs. In [6], the relay nodes are selected by considering both the encounter probability among nodes and the transmission cost which is defined based on a game theoretical approach. Cao et al. [7] have proposed EBRR (Encounter-Based Replication Routing) which considers the nodal encounter history information. Similar to [7], most existing routing protocols make routing decision based on historical information. However, the historical information does not make sense in VANETs because the probability of two vehicles meeting multiple times is very low unless they are moving to the same direction with similar velocity (in this case, these two vehicles have the similar encounter properties and therefore replicating the data from one vehicle to the other vehicle does not result in a significant improvement of destination encounter probability). All the existing protocols use the same approach where the data are replicated when there is a better candidate. However, this is not always correct depending on the number of copies and the nodes which have the copies. Therefore, it is important to consider the destination encounter probability of forwarders (who have a copy of the data) and the number of forwarders jointly. In this paper, we first propose a framework which utilizes vehicular DTN to provide communication for post-disaster management. In the framework, a vehicular cloud is formed by vehicles and road side units (RSUs) as shown in Fig.. We than propose a DTN protocol which is able to provide vehicleto-cloud (vehicle-to-rsu) communication in the framework. The protocol takes into account achievable throughput between the sender and forwarder node, additional radio coverage of the forwarder node, and connection time between the sender /7/$3. 27 IEEE 67

2 and the forwarder node. The proposed protocol also employs a network coding-based approach to improve the probability of successful data delivery with low overhead. We use computer simulations to evaluate the proposed protocol. Fig.. Vehicular cloud formed by vehicles and RSUs. The remainder of the paper is organized as follows. We first introduce the proposed DTN-based vehicular cloud framework in section II. In section III, we give a detailed description of the proposed vehicle-to-rsu protocol. Simulation results are presented in section IV. Finally, we present our conclusions and future work in section V. A. Assumption II. PROPOSED FRAMEWORK Each node (vehicle) is equipped with a positioning device. RSUs have sufficient storage devices to save all the packets in flight. Each node knows the road map information. Each RSU sends own location information using beacon messages with a predefined interval ( second by default), and therefore each vehicle is able to know the RSUs in vicinity. Each node disseminates the information about velocity, location, and the nearest RSU by using beacon messages. RSUs are connected with each other using wired communication line. B. Vehicular cloud with DTN As shown in Fig., the proposed framework uses an approach where vehicles and RSUs form a cloud. All intermediate data (the data that are not delivered to the destination yet) will be maintained by RSUs. Since RSUs are connected with each other, the information exchange can be conducted by using RSU as a contact point. From the service perspective, there are two main types of communications in the framework specifically vehicle-to-rsu (user-to-cloud) communication and RSU-to-vehicle (cloud-to-user) communication. Vehicle-to-RSU communication is used to send user data (such as data sensed from the vehicles, or data sensed from pedestrians) to the cloud, and RSU-to-vehicle communication is useful when a user wants to acquire information from the cloud. By storing data on the RSUs, vehicles (users) can exchange information without other infrastructure support. Providing acknowledgments to received data is important. In the proposed framework, after receiving each block of user data, the RSU which is the closest to the user will send acknowledgment to the user (the size of data block will be determined by the end user). Since RSUs are inter-connected, the cloud receives the data if any RSU receives that. In this paper, we also propose a vehicle-to-rsu routing protocol for the framework (this will be explained in the next subsection). RSU-to-vehicle communication can be conducted in a similar way. For the RSU-to-vehicle communication, the vehicle sends a request to the RSU which is the nearest to itself, and then the RSU schedules the transmission according to the network topology information. III. PROPOSED VEHICLE-TO-RSU PROTOCOL The protocol selects forwarder nodes to replicate the data. The sender node evaluates each neighbor node by taking into account multiple metrics specifically throughput factor (TPF), additional coverage factor (ACF), and connection time factor (CTF) by using a fuzzy logic (see III-A). The protocol also employs a network-coding approach to improve the data delivery probability with low overhead (see III-C). A. Fuzzy logic-based forwarder evaluation We consider three metrics specifically throughput factor (TPF), additional coverage factor (ACF), and connection time factor (CTF). TPF is used to take into account the possible throughput between the sender and a forwarder. It is important to consider this factor especially for low bandwidth network because this determines how much data can be delivered within a short time. ACF denotes how much the forwarder can improve the destination encounter probability. CTF is used to take into account the connection time between the two nodes, which is another factor influencing the total throughput. ) Throughput factor (TPF): TPF is calculated as { d(x) TPF c (x) = R, d(x) <= R (), d(x) > R. where c is the current node (the node which does the calculation), and d(x) is the distance between the current node and its neighbor node x. R is the maximum distance over which stable communications can be provided. The users can tune this parameter in order to make the protocol work efficiently in various situations. However, the tuning of this parameter is outside the scope of this paper. 2) Additional coverage factor (ACF): ACF is calculated as ACF c (x) = V(y) V(x) max y Nc V(y) where V( ) denotes the velocity, and N c is the one-hop neighbor set of the current node (c). If the relative vehicle velocity between two vehicles is higher, ACF of the corresponding vehicle is higher because the vehicle is more likely to encounter a new RSU. (2) 68

3 3) Connection time factor (CTF): CTF is calculated as { CT c(x) max CTF c (x) = y Nc CT, CT c(y) c(x) <= T data (3), CT c (x) > T data where CT c (x) is the connection time to the neighbor x, and T data is the time required to send all the data. CT c (x) is calculated based on the relative velocity of c and x. Typically, a larger connection time means that the deliverable data size is large. Note that the throughput is dependent on many factors especially the inter-vehicle distance. The total achievable date size is the product of throughput and connection time, which means that the result is dependent on TPF and CTF. 4) Procedure: The sender node calculates the evaluation value for each neighbor as follows, and selects the neighbor node which has the largest evaluation value as the (next) forwarder. Step: Fuzzification Use predefined linguistic variables and membership functions to convert throughput factor (TPF), additional coverage factor (ACF), and connection time factor (CTF) to fuzzy values (see Fig. 2, Fig. 3, and Fig. 4). Step2: Fuzzy operation Map the fuzzy values to predefined IF/THEN rules (see Table I) and combine the rules to get the rank of the neighbor as a fuzzy value. Step3: Defuzzification Use a predefined output membership function (see Fig. 5) and defuzzification method (we use the Center of Gravity method) to convert the fuzzy output value to a numerical value (evaluation value). Degree Degree Small Medium Large ACF Fig. 3. ACF membership function. Short Medium Long CTF Fig. 4. CTF membership function. TABLE I FUZZY RULES Degree Small Medium Large B. Forwarder node selection TPF Fig. 2. TPF membership function. In the forwarder node selection, we evaluate each candidate node by taking into account throughput factor (TPF), additional coverage factor (ACF), and connection time factor (CTF). We also consider another metric, RSU meeting probability (RMP). For each road, the forwarder node could be selected from whether the forward direction or backward direction depending on the RSU location. RMP is calculated based on each vehicle s velocity information and RSU information (if the RSU information is unavailable, we can calculate RMP based on the number of road segments that are involved in the upcoming intersection). The probability of making turn at Rule No. Throughput Coverage Connection time Rank Large Large Long Perfect 2 Large Large Medium Good 3 Large Large Short Unpreferable 4 Large Medium Long Good 5 Large Medium Medium Acceptable 6 Large Medium Short Bad 7 Large Small Long Unpreferable 8 Large Small Medium Bad 9 Large Small Short VeryBad Medium Large Long Good Medium Large Medium Acceptable 2 Medium Large Short Bad 3 Medium Medium Long Acceptable 4 Medium Medium Medium Unpreferable 5 Medium Medium Short Bad 6 Medium Small Long Bad 7 Medium Small Medium Bad 8 Medium Small Short VeryBad 9 Small Large Long Unpreferable 2 Small Large Medium Bad 2 Small Large Short VeryBad 22 Small Medium Long Bad 23 Small Medium Medium Bad 24 Small Medium Short VeryBad 25 Small Small Long Bad 26 Small Small Medium VeryBad 27 Small Small Short VeryBad each intersection is considered in this metric. For example, as shown in Fig. 6, After the source node S selects node F as a forwarder node, and then can know there is 3 probability that 69

4 VeryBad Bad Unpreferable Acceptable Good Perfect Fig. 5. Output membership function. node F would meet the RSU (there will be three road segments specifically A, B, and C). Each sender node selects the next forwarder node until the sum of RSU meeting probabilities of all the forwarder vehicles reaches (see III-C) (we use the sum of RSU meeting probabilities of all the forwarder vehicles because the calculation is simple and sufficient to indicate the level of real RSU meeting probability). Algorithm Actions for sending each block of data : Divide the data in to 2 parts, specifically a and b. 2: Calculate a XOR b. 3: Sort all the possible candidate nodes according to the value of fuzzy logic-based forwarder evaluation. 4: Transmit the data blocks, specifically a, b, and a XOR b independently as follows 5: repeat 6: Get a new forwarder node which shows the highest fuzzy evaluation value. 7: Transmit the data to the selected forwarder node. 8: Calculate the RSU meeting probability based on the selected forwarder node. 9: until RSU meeting probability of the selected forwarder nodes meets. Table II shows the transmission procedure comparison between the proposed protocol and the conventional approach such as EBRR [7]. G denotes the first group of vehicles which are specified by the sender node (in Fig. 7, G denotes the set of V, V2 and V3). As shown in Fig. 6, the vehicle S is the sender node. The forwarder nodes selected by the sender node could take one of the three road segments specifically A, B, and C (here we consider the vehicle is moving towards the same direction as the sender node; the vehicle velocity is known). For the proposed protocol, the loss probability for each coded segment is ( 2 3 )4 = 6 8. Therefore, the reception probability for the whole data block is ( 6 8 )3 ( ) 3 2 ( 6 8 )(6 8 )2 =.9. For the conventional routing protocols, the reception probability for the whole data block ( a and b ) is ( ( 2 3 )8 )( ( 2 3 )4 ) =.77. We can observe that the proposed protocol can significantly improve the packet delivery probability. Fig. 6. An example of intersection. C. Network coding-based data transmissions We use network coding to reduce the number of required transmissions while providing a high possibility of data delivery (see Algorithm ). For brevity, we explain the proposed protocol by using a simple example as shown in Fig. 6 and Fig. 7. The source node has to send two packets specifically a and b. In the proposed protocol, the sender nodes first sends a, then b, and finally a XOR b. If the RSU can receive any two of these three packets, the original data ( a and b ) can be retrieved. For the packet a, the sender node selects three different vehicles to forward the data considering the probability of meeting the RSU (as explained in the previous subsection, each vehicle has 3 probability to meet the RSU; in order to satisfy the sum of probability reaches, three vehicles are required). Similarly, the sender node does the same action for packet b and a XOR b. Fig. 7. An example of network coding-based data forwarding (replication). TABLE II TRANSMISSION PROCEDURE COMPARISON Time Slot No. 2 3 Sent data (Proposed) a b a XOR b Sent data (Conventional) a b a (or b) Forwarder group (Proposed) G G2 G3 Forwarder group (Conventional) G G G2 IV. SIMULATION RESULTS We used ns-2.34 [8] to conduct simulations for street scenarios. We evaluated the protocol s performance in various vehicle velocities and various vehicle densities. The vehicle 7

5 movement was generated by [9], [2]. The maximal vehicle velocity was 8 km/h, and the average transmission range was 25 m. We used a street scenario as shown in Fig. 8 and every street had two lanes in each direction. The distance between any two neighboring intersections was 4 m. We used IEEE 82.p MAC (2 Mbps) to simulate realistic VANET scenarios. Nakagami propagation model was used to simulate the channel fading (see Table III). We used these parameter values because they model a realistic wireless channel of VANETs [2]. In the simulations, one sender node was sending 4Mbytes data to the vehicular cloud. The proposed protocol was compared with EBRR [7]. The error bars indicate the 95% confidence intervals. TABLE III PARAMETERS OF NAKAGAMI MODEL gamma gamma gamma2 d gamma d gamma m m m2 d m d m 8 2 ratio of Proposed ( RSU) in 8km/h is larger than the one in 6km/h. Data delivery ratio EBRR ( RSU) EBRR (2 RSUs) Proposed ( RSU) Proposed (2 RSUs) Velocity of the sender node (km/h) Fig. 9. Data delivery ratio for various sender vehicle velocities (the results for RSU and 2 RSUs scenarios are the same for EBRR). B. Data delivery ratio for various vehicle densities Fig. shows the data delivery ratio for various node velocities. The velocity of the sender nodes was 6 km/h. The proposed protocol can significantly improve the data delivery ratio by using multiple forwarder nodes and network coding. When the number of possible candidate nodes is large enough, the proposed protocol can attain near percent data delivery ratio even in the -RSU scenario. Fig. 8. An example of simulation scenario. A. Data delivery ratio for various sender vehicle velocities Fig. 9 shows the data delivery ratio for various sender vehicle velocities (node S is the sender node in Fig. 8). The number of nodes in the transmission range was. By taking into account encounter duration and inter-meeting time, EBRR intends to choose a vehicle which has a lower relative velocity as the sender node (in most cases, inter-meeting time in street scenarios is large enough to neglect). Therefore, EBRR always selects only one forwarder node (the one which has the lowest relative velocity as the sender node), resulting in a small data delivery ratio. Since the proposed protocol can distribute the data using multiple forwarder nodes and also increase the data retrieval probability by using network coding, the data delivery ratio is significantly improved. In the figure, Proposed ( RSU) and Proposed (2 RSUs) denote the result of the proposed protocol in -RSU scenario (only RSU- was available) and 2-RSU scenario (two RSUs, specifically RSU- and RSU-2, were available) respectively. When the velocity of the sender node is higher, the probability of selecting more forwarder nodes is higher because the sender node could meet more vehicles. This is why the data delivery Data delivery ratio EBRR ( RSU) EBRR (2 RSUs) Proposed ( RSU) Proposed (2 RSUs) Number of nodes in the transmission range Fig.. Data delivery ratio for various numbers of vehicles in the transmission range (the results for RSU and 2 RSUs scenarios are the same for EBRR). C. Delay for various vehicle densities We simulated the proposed protocol for a larger scale vehicular network as shown in Fig. where the distance between any two neighboring intersections was 4 m. Fig. 2 shows the delay for various numbers of vehicles in the transmission range. Here, the delay denotes the elapsed time for transmitting the 4Mbytes data. The average length of traffic light was 3 7

6 ACKNOWLEDGMENT This research was supported in part by JST Strategic International Collaborative Research Program (SICORP). Fig.. Simulation scenario for large scale vehicular networks. seconds. The velocity of the sender node was 6km/h. The proposed protocol can reduce the data delivery delay significantly by improving the RSU encounter probability by using multiple forwarder nodes. The consideration of additional coverage factor for the forwarder selection also contributes to the short delay. Delay (s) EBRR Proposed Number of nodes in the transmission range Fig. 2. Delay for various numbers of vehicles in the transmission range. V. CONCLUSIONS AND FUTURE WORK We proposed a framework which utilizes vehicular delay tolerant network (DTN) to provide communication for postdisaster management, and then designed a routing protocol for vehicle-to-rsu commination in this framework. The routing protocol takes into account the achievable throughput between the sender and forwarder node, additional radio coverage of the forwarder node, and connection time between the sender and the forwarder node. The protocol also conducts a networkcoding based data replication by considering RSU encounter probability. Through computer simulations, we confirmed the advantages of the proposed protocol over a recent DTN protocol. In future work, we will discuss the downlink transmission (RSU-to-vehicle) for the proposed framework. The combination of multi-hop transmission and DTN protocols is also considered as a future work. REFERENCES [] D. Lin, J. Kang, A. Squicciarini, Y. Wu, S. Gurung, and O. Tonguz, MoZo: A Moving Zone Based Routing Protocol Using Pure V2V Communication in VANETs, IEEE Trans. Mobile Comput., DOI:.9/TMC , 26. [2] C. Wu, S. Ohzahata, Y. Ji, and Toshihiko Kato, How to Utilize Interflow Network Coding in VANETs: A Backbone-Based Approach, IEEE Trans. Intell. Transp. Syst., vol.7, no.8, pp , 26. [3] C. Wu, Y. Ji, F. Liu, S. Ohzahata, and Toshihiko Kato, Toward Practical and Intelligent Routing in Vehicular Ad Hoc Networks, IEEE Trans. Veh. Technol., vol.64, no.2, pp , 25. [4] M. H. Eiza and Q. Ni, An Evolving Graph-Based Reliable Routing Scheme for VANETs, IEEE Trans. Veh. Technol., vol.62, no.4, pp , 23. [5] R. Jiang, Y. Zhu, T. He, Y. Liu, and L.M. Ni, Exploiting Trajectory- Based Coverage for Geocast in Vehicular Networks, IEEE Trans. Parallel and Distrib. Syst., vol.25, no.2, pp , 24. [6] C.-M. Huang and S.-Y. Lin, Timer-based greedy forwarding algorithm in vehicular ad hoc networks, IET Intelligent Transport Systems, vol.8, no.4, pp , 24. [7] P.R. Pereira, A. Casaca, J.J.P.C. Rodrigues, V.N.G.J. Soares, J. Triay, and C. Cervello-Pastor, From Delay-Tolerant Networks to Vehicular Delay-Tolerant Networks, IEEE Commun. Surveys Tuts., vol.4, no.4, pp.66-82, 22. [8] M.J. Khabbaz, C.M. Assi, and W.F. Fawaz, Disruption-Tolerant Networking: A Comprehensive Survey on Recent Developments and Persisting Challenges, IEEE Commun. Surveys Tuts., vol.4, no.2, pp.67-64, 22. [9] S.M. Tornell, C.T. Calafate, J.-C. Cano, and P. Manzoni, DTN Protocols for Vehicular Networks: An Application Oriented Overview, IEEE Commun. Surveys Tuts., vol.7, no.2, pp , 25. [] M. J. Khabbaz, H. M. K. Alazemi, and C. M. Assi, Delay-Aware Data Delivery in Vehicular Intermittently Connected Networks, IEEE Trans. Commun., vol.6, no.3, pp.34 43, 23. [] M. J. Khabbaz, W. F. Fawaz, and C. M. Assi, Modeling and Delay Analysis of Intermittently Connected Roadside Communication Networks, IEEE Trans. Veh. Technol., vol.6, no.6, pp , 22. [2] Y. Li, D. Jin, Z. Wang, L. Zeng, and S. Chen, Coding or Not: Optimal Mobile Data Offloading in Opportunistic Vehicular Networks, IEEE Trans. Intell. Transp. Syst., vol.5, no., pp , 24. [3] D. Niyato and P. Wang, Optimization of the Mobile Router and Traffic Sources in Vehicular Delay-Tolerant Network, IEEE Trans. Veh. Technol., vol.58, no.9, pp , 29. [4] A. Agarwal, D. Starobinski, and T.D.C. Little, Phase Transition of Message Propagation Speed in Delay-Tolerant Vehicular Networks, IEEE Trans. Intell. Transp. Syst., vol.3, no., pp , 22. [5] A. Balasubramanian, B. N. Levine, and A. Venkataramani, Replication Routing in DTNs: A Resource Allocation Approach, IEEE/ACM Trans. Networking, vol.8, no.2, pp , 2. [6] Y. Cai, Y. Fan, and D. Wen, An Incentive-Compatible Routing Protocol for Two-Hop Delay-Tolerant Networks, IEEE Trans. Veh. Technol., vol.65, no., pp , 26. [7] Y. Cao, N. Wang, Z. Sun, and H. Cruickshank, A Reliable and Efficient Encounter-Based Routing Framework for Delay/Disruption Tolerant Networks, IEEE Sensors Journal, vol.5, no.7, pp.44 48, 25. [8] The Network Simulator - ns-2, Accessed on Dec. 23, 25. [9] D. Krajzewicz, G. Hertkorn, C. Rossel and P. Wagner, SUMO (Simulation of Urban MObility): An open-source traffic simulation, Proc. 4th Middle East Symposium on Simulation and Modelling (MESM22), SCS European Publishing House, pp.83 87, 22. [2] TraNS (Traffic and Network Simulation Environment), Accessed on Feb. 23, 2. [2] A. Khan, S. Sadhu, and M. Yeleswarapu, A comparative analysis of DSRC and 82. over Vehicular Ad hoc Networks, Project Report, University of California, Santa Barbara, pp. 8,