efficient content delivery in urban VANET scenarios. Specifically, ... NDN can easily support the mobile content consumers [6], and the design for the support of ...
Boosting Named Data Networking for Efficient Packet Forwarding in Urban VANET Scenarios Chaoyi Bian, Tong Zhao, Xiaoming Li and Wei Yan School of EECS, Peking University, Beijing, China Email: {bcy, zhaotong, lxm, w}@pku.edu.cn Abstract—Named Data Networking (NDN) is a data-centric architecture designed for the future Internet. Existing works show that NDN brings significant performance improvement for typical content-centric applications, and can also fit the mobile environment well. However, directly applying NDN to Vehicular Ad hoc NETworks (VANETs) is confronted with great challenges due to the high mobility of vehicles. Most applications in VANETs are relied on data dissemination mechanisms. Therefore, we aim to improve the performance of NDN packet forwarding for the efficient content delivery in urban VANET scenarios. Specifically, we introduce the geo-location information to the NDN forwarding plane, and propose a geo-based forwarding strategy to make NDN fit the urban VANETs. Simulation results show our strategy can achieve 27% ∼ 75% higher request success ratio, and 40% ∼ 80% lower delay compared with the default NDN strategy in urban scenarios with different vehicle densities. Keywords—NDN, VANET, forwarding strategy, simulation
I.
I NTRODUCTION
Vehicular Ad hoc NETwork (VANET) is a special kind of wireless ad hoc network, in which moving vehicles are communication nodes. Although initially proposed to improve driving safety, sorts of informative applications are also supported to serve drivers and passengers, e.g., real-time traffic information query, advertisements. Most of these applications aim to serve the position-related information requests, e.g., “what is the exhibition currently on at XXX Museum?”, “what are the shows recently on at XXX Theater?”. Existing works mainly employ geo-based routing and data dissemination mechanisms to support the information exchange, but performance issues exist, i.e., the packet delivery ratio has obvious drops and the latency experiences significant increase when communication vehicles are distant from each other [1][2]. Named Data Networking (NDN, aka Content-Centric Networking) [3] is a clean-slate design for the future Internet. NDN can bring significant performance improvement for popular content-centric applications on the Internet, such as video streaming [4], data synchronization [5], etc. In this work, we concern about the availability and performance when applying the NDN architecture to urban VANET scenarios. Instead of establishing host-based end-to-end communications, NDN focuses on the delivery of named data. Content consumers express the data requirement with Interest packets identified by data name, and content publishers reply with the corresponding Data packets. Data are cached at routers along the forwarding path, and any node with the cached data can c 978-1-4673-6762-2/15/$31.00 2015 IEEE
also serve as the content publisher afterwards. Besides, NDN provides good support for multicast, so multiple requests from various positions for the same data can be efficiently replied. Therefore, VANETs should benefit from NDN especially in the respect of data dissemination. However, each coin has two sides. Directly applying NDN into VANETs are confronted with great challenges in the forwarding plane. NDN can easily support the mobile content consumers [6], and the design for the support of mobile content publishers is also presented [7]. However, for a scenario in which all nodes are moving, such as VANETs, challenges still exist. Because it is impossible to establish any stationary route beforehand, the default NDN forwarding strategy degenerates to flooding which incurs high overhead and poor performance. Some mechanisms have been proposed by existing work to reduce the unnecessary broadcasts [8][9]. Comparatively, we make a step further based on the related studies in traditional VANETs. We present a new forwarding strategy which utilizes the geo-location information in the packet forwarding to make NDN more suitable for urban VANET scenarios, thus further improve the performance of data dissemination. The main contributions of our work are listed as follows. • We present a geo-based design of NDN forwarding strategy for urban VANETs to deal with the challenges caused by the high mobility of vehicles. We borrow ideas from the geobased routing and data dissemination mechanisms to make NDN more suitable for urban VANET scenarios. To the best of our knowledge, this is the first forwarding strategy that uses geo-location information for NDN-based VANETs. • We also take reliability and caching benefit into account in the design of forwarding strategy. Specifically, we employ a timer-based forwarding decision mechanism to improve the reliability, and multi-path forwarding is exploited to enhance both reliability and caching benefit. • We implement our strategy and carry out simulations to validate the proposed design. Results show that our forwarding strategy achieves 27% ∼ 75% higher request success ratio and 40% ∼ 80% lower delay compared with the default NDN strategy in urban scenarios with different vehicle densities. The rest of this paper is organized as follows. Section II provides the background and some related work. Section III presents our forwarding strategy design with details. Evaluation results are given in Section IV. Finally, Section V concludes the whole paper.
II.
,QWHUHVW
R ELATED W ORK
A. Vehicular Ad Hoc Networks The features of wireless transmission and the high mobility of vehicles define the challenges of VANETs. Existing work mainly focuses on the data dissemination mechanisms, and three schemes are widely employed, i.e., geo-based routing, hop-by-hop forwarding and carry-and-forward technique. Geo-based routing mechanisms use position information to assist packet routing. GPSR [10] is a position-based routing protocol for wireless ad hoc networks, in which nodes forward packets greedily to the destination. Many studies use additional information to improve the routing efficiency for VANETs. For instance, VADD [11] utilizes the digital map with vehicle density information to calculate the best path. Hop-by-hop forwarding is widely used because it is difficulty to establish the whole forwarding path beforehand in highly dynamic VANETs. The forwarder selection can be based on various metrics, e.g., CLWPR [12] takes multiple factors into account including distance, sending queue length, frame error rate, etc. Carry-and-forward technique is used to cope with disconnected scenarios. Vehicles need to store the packets if no better forwarder exists. The packets are carried on the moving vehicles until better forwarders appear. For instance, UVCAST [13] chooses boundary vehicles of connected network components to store and carry the packets B. Named Data Networking Rather than establishing host-based communications, NDN adopts a data-centric design. A content consumer sends an Interest packet (abbr. Interest) containing the name of the requested data, and a content publisher responds with a Data packet (abbr. Data). Interest packets are routed based on the name of requested data, and Data packets follow the reverse path back. The data are cached at routers along the forwarding path, which can be used to satisfy future requests.
&RQWHQW6WRUH &6 1DPH
'DWD
« «
3HQGLQJ,QWHUHVW7DEOH 3,7 1DPH3UHIL[
,QFRPLQJ )DFH V
• The FIB stores information about where Interests matching some name prefixes should be forwarded. 1 • The CS stores the cached Data which are forwarded through the router. Fig. 1 shows these data structures and the forwarding process at an NDN router. For an incoming Interest, the router first checks the CS to see if any cached Data exist. If found, the Data is returned. Otherwise, the router looks up the PIT to check whether there is a matching record. If such a record 1 The FIB can be constructed through conventional routing algorithms, e.g., link state and distance vector. NDN routers announce name prefixes of the data that they serve, and the routing protocol propagates these announcements across the network.
$GGLQFRPLQJIDFH LQWKH3,7HQWU\
« $OH[YLGHRVOHFWXUH$PSJYV
«
&UHDWHWKH3,7HQWU\ )RUZDUGLQJ,QWHUHVW%DVH ),% 1DPH 3UHIL[
2XWJRLQJ )DFH V
« %RESLFWXUHV
)RUZDUG
«
'RQRWIRUZDUG (a) Interest forwarding process at an NDN router
Data
Pending Interest Table (PIT) Name Prefix
Incoming Face(s)
… /Alex/videos/lectureA.mpg/v1/s2
Discard Data
2
…
Content Store (CS)
Cache
There are three important data structures that each NDN router needs to maintain, i.e., a Pending Interest Table (PIT), a Forwarding Information Base (FIB), and a Content Store (CS). The functions of them can be briefly described as follows. • The PIT keeps records of Interests received by the router but not satisfied yet.
5HSO\ZLWK'DWD
'DYLGYLGHRVOHFWXUH%PSJYV ««
Name
Data
… /David/videos/lectureB.mpg/v2/s1 …… …
Forward (b) Data forwarding process at an NDN router Fig. 1. The data structures and forwarding process at an NDN router. The checkmark indicates a lookup hit, while the cross denotes a miss. The example entries shown in the data structures give the formats, which are not related to any specific matching process.
exists, it adds the incoming face of the Interest to the record. Otherwise, a new record is created in the PIT, and the FIB is checked to find out where the Interest should be forwarded. As for an incoming Data, the router forwards it according to the record in the PIT, and store it in the CS. All the matching mentioned above are done with names which have hierarchical structures, and the longest prefix matching scheme is used.
There are some preliminary studies trying to apply NDN into VANETs. A simple design to reduce packet flooding for freeway scenarios is presented [8]. CCVN [9] gives an enhanced forwarding design for VANETs, which applies a timer based mechanism to alleviate packet redundancy, and hop counts are used to make choices from multiple content publishers. A recent work includes a small-scale field test with a similar broadcast-suppressing design, and simulations of the default NDN forwarding strategy in VANETs [14]. However, there is a lack of a complete targeted design of forwarding strategy for NDN-based VANET to fit urban scenarios. Our work fills this blank with a geo-based forwarding strategy which aims to improve efficiency as well as reliability, thus make NDN more suitable for urban VANET scenarios. III.
F ORWARDING S TRATEGY
A. Overview As described above, each NDN router maintains a FIB. Each entry in the FIB has two fields, i.e., name prefix and forwarding face list. In a normal Interest forwarding process, the router looks up the FIB to find the longest matching name prefix, and forwards the Interest to the corresponding faces. Meanwhile this unsatisfied Interest is recorded in the PIT. Once the Data is received, the router looks up the PIT to find the incoming faces of the corresponding Interest which the Data should be forwarded to. However, because vehicles are moving fast, no stable FIB entries can be created in VANET scenarios. Therefore, except for the Interests matching with the name prefixes for the local application face, all the other Interests are flooded through the wireless communication face. As a result, the default behavior of vehicles becomes forwarding all the incoming Interests, and all the incoming solicited Data (i.e., matching entry of which can be found in the PIT) are also forwarded. Obviously, this flooding strategy raises much redundancy and may lead to lots of conflicts in wireless transmission. As mentioned in Section I, most VANET applications relies on the location-related data dissemination. An intuitive idea is that we can utilize the location information in the packet forwarding. Thus a problem emerges, i.e., how can we acquire and manage the geo-location information in the NDN architecture. We work on this issue from two aspects. First, the position information of the data source can be embedded into the data name with an existing data naming design [15]. This naming scheme includes the geo-location information in the name, i.e., /traffic/geo-location/data type. Therefore, the position of the data source, i.e., “geo-location” part, can be directly extracted from the name. Second, we also need the information about positions of each vehicle that may participate the packet forwarding. In order to manage the information, each vehicle employs a data structure, i.e., a neighbor table, in which the positions of neighbor vehicles are stored and periodically updated. We introduce a special hello Interest for the periodic exchanges of neighbor information. The hello Interests have the name form of /hello/nodeID/geo-location. Vehicles can recognize them by the “/hello” prefix. Then “nodeID” and “geo-location” can be extracted and stored in the neighbor table. Hello Interests
,QWHUHVW3DFNHW
'DWD3DFNHW
1DPH
1DPH
6HOHFWRUV
0HWD,QIR
RUGHUSUHIHUHQFHSXEOLVKHU ILOWHUH[FOXGHILOWHU
FRQWHQWW\SHIUHVKQHVV SHULRG
1RQFH
&RQWHQW
*XLGHUV
VFRSH,QWHUHVWOLIHWLPH
6LJQDWXUH
VLJQDWXUHW\SHNH\ORFDWRU VLJQDWXUHELWV
Position Position Next Hop Forwarder List Fig. 2. Extensions on the packet format. Both Interest and Data packets contain an additional field to store the sender position, and Interests have one more field to indicate the next hop forwarder list.
are only broadcast locally (i.e., limited in one hop), and vehicles periodically broadcast such an Interest. Based on the above designs, we aim to design a forwarding strategy which can use the geo-location information to assist packet forwarding. When a packet (Interest or Data) is received by a vehicle, the geo-based forwarding decision immediately starts after the matching process with the CS, PIT and FIB as described in Section II. We are confronted with some other challenges in the strategy design. 1) The unreliability of wireless communication. This can cause unexpected packet loss which has great impacts on the packet forwarding to a specific destination. 2) Additional difficulties introduced by the urban scenario. These include the obstructed connectivity at intersections [16], the routing void problem when applying greedy mechanisms [17], etc. To tackle these, we make corresponding designs which are presented with details in the following subsection. B. Geo-based Forwarding Our geo-based forwarding strategy tries to achieve both efficiency and reliability for packet delivery in urban VANET scenarios. Because Data packets follow the reverse forwarding path of Interest packets back in NDN, the Interest forwarding plays a more important role and needs more elaborate designs. By applying the naming scheme and the neighbor information exchange mechanism described above, each vehicle knows neighbors’ positions and the position of the data source for any specific Interest, so the best next hop forwarder can be selected for efficient Interest delivery. However, the neighbor information may be outdated, and wireless communication is unreliable, so the selected vehicle may not receive the forwarded Interest. Therefore, to improve the reliability, any vehicle that receives an Interest makes its own decisions on whether to forward the Interest even if the vehicle is not the indicated forwarder. To summarize, our forwarding strategy consists of two parts, i.e., forwarder selection and forwarding decision. In order to convey the necessary information such as the selected forwarders, we make simple extensions on the NDN
Receive an Interest
Prepare to send an Interest
A neighbor at the location of data source exists?
Yes
Is the vehicle in the forwarder list?
Put the neighbor in the forwarder list
No
No
Located at an intersection?
Yes
Put the farthest neighbor on each outgoing roads closer to destination into the forwarder list
No
Yes
Yes No
Start a wait timer Yes
Is the vehicle a neighbor of an indicated forwarder?
Put the neighbor in the forwarder list
No
Does the same Interest arrive before the timer expires?
No Do not forward the Interest
Any neighbor on the same road in the forwarding direction exists?
Forward the Interest
Is the forwarder list empty?
No A neighbor exists at an intersection in forwarding direction?
Yes
Yes
Put the farthest one in the forwarder list
No Leave the forwarder list empty
Fig. 3. The flow chart of the next hop forwarder list computation process when a vehicle prepares to forward an Interest.
packet format. As shown in Fig. 2, Interest packets include two additional fields to contain the sender position and the next hop forwarder list. When a vehicle is about to send or forward an Interest, the vehicle needs to compute the next hop forwarder list as follows, which is also illustrated in Fig. 3. 1) The vehicle looks up the neighbor table to find whether there is a neighbor located in the geo-location of data source indicated in the name. If there is, put the neighbor into the forwarder list. Otherwise, 2) If the vehicle is located at an intersection, it looks up the neighbor table to find out the farthest neighbors on each outgoing road that goes closer to the data source and adds them into the forwarder list. Otherwise, 3) It first checks the neighbor table to look for a neighbor at an intersection in the forwarding direction (with the assist of digital map information). If found, put it into the forwarder list. Otherwise, it chooses the farthest neighbor in the forwarding direction on the same road instead. If still not found, the forwarder list is left empty. We employ a multi-path forwarding in Step 2), which has two concerns. The first is that with different forwarding paths, higher reliability can be achieved, and the second is about caching. Returned Data can be cached on multiple paths so that the cached copies are more widely spread which is beneficial for future requests for the same data. In Step 3), we favor the vehicles located at intersections as forwarders to avoid the obstacle effects in junctions similar to GPCR [18]. As for forwarding on roads, a greedy scheme is exploited to approach the data source. However, when network disconnection happens, suitable vehicle forwarders cannot be found, in which case the forwarder list is left empty. When a vehicle receives an Interest, the vehicle checks the next hop forwarder list and makes the forwarding decision as below, which is also demonstrated in Fig. 4.
Fig. 4.
Yes
The flow chart of forwarding decision when receiving an Interest.
1) If the vehicle finds itself in the list, it forwards the Interest. Otherwise, 2) If the list is empty, the vehicle starts a timer. If the same Interest is not received again before the timer expires, which means none of the neighbors forwards the Interest, it should forward the Interest, otherwise it stops the timer and cancel forwarding. Otherwise, 3) If the vehicle is a neighbor of an indicated forwarder in the list, it also uses the same timer-based mechanism as above, otherwise it does not forward the Interest. In Step 2), the vehicle receives an Interest with empty forwarder list because the last hop forwarder cannot find a suitable vehicle to greedily approach the data source. We employ a timer-based mechanism similar as CCVN [9] to make forwarding decisions. The expire time of the timer is computed using Eq. (1), which tries to make the vehicle that is farther from the Interest sender have a shorter latency to wait so that it has a higher priority to forward the Interest. R−d Tslots = × Wmax (1) S Tslots is the expire time expressed as the number of time slots, with the same slot length as that in the MAC(Media Access Control) layer. R is the wireless transmission radius. d is the distance from the last forwarder. Thus, the expire time is shorter when d is closer to R. S is called step length, which controls the granularity of waiting timer mechanism. For instance, if we set S to 10m, vehicles located in the same tens of meters from the last forwarder wait for the same number of time slots. We do not need to care about the conflict problem because it is handled in the MAC layer. Wmax is the maximum number of waiting time slots in MAC layer. Multiplication by Wmax ensures that the timer delay dominates rather than the MAC layer delay. In Step 3), vehicles not indicated as forwarders also apply the timer-based mechanism in case that the indicated vehicles do not receive the Interest. Comparatively, the forwarding decision of an incoming Data is simpler. When a solicited Data arrives, the vehicle decides whether to forward it or not using a similar timer-based mechanism as described above. In other words, the vehicle
C. Overhead
1
0.8 Request Success Ratio
starts a wait timer with the expire time set using Eq. (1). If the vehicle does not overhear the same Data before the timer expires, it forwards the Data, and vice versa. Similar as above, this mechanism gives higher priority in forwarding the Data to vehicles farther from the last forwarder. Note that the Data packet format is also extended to include the sender position as shown in Fig. 2.
Three types of additional overhead are introduced in the geo-based forwarding strategy compared with the default NDN forwarding strategy. 1) Storage overhead of the neighbor table. Each entry consists of a neighbor ID (4 bytes), position information (16 bytes) and update time (4 bytes). Thus, for a vehicle with ten neighbors, the size of the neighbor table is only 240 bytes, which does not introduce any storage burden. 2) Communication overhead of the hello Interest. The hello Interest consists of the /hello prefix (5 bytes), the vehicle ID (4 bytes) and the vehicle position (16 bytes). Thus, with the commonly-used 1Hz sending frequency, each vehicle only generates an additional communication overhead of 25 Bps, which is negligible compared with wireless communication bandwidth. 3) Communication overhead of the additional information in the packets. The additional information include the sender position (16 bytes) and the next hop forwarder list (in typical urban scenarios with four-way intersections, one or two forwarders are selected, which cost 4∼8 bytes). Hence the total size of additional information is no more than 24 bytes per packet, which is acceptable. IV.
E VALUATION
A. Simulation Environment We implement the proposed strategy in an NS-3 based open-source NDN simulator ndnSIM [19]. To generate the vehicle mobility trace, we use a well-known simulator for urban traffic, i.e., SUMO [20] (version 0.21.0). We use a map of 5 × 5 Manhattan-like grid with a grid length of 400m, covering a total area of 1.6km × 1.6km. For all streets, there are two lanes in each direction, and the speed limit is 40km/h. The transmission radius of vehicles is 150m. The content publisher is located in the center of the map, and the same series of requests come from ten random positions following an exponential distribution with a mean interval of 4s. We use this map setting to simulate a typical urban scenario in which requests come from various positions in all directions. Every vehicle sends out hello Interests with a mean frequency of 1Hz at random instants to avoid conflicts. Each result shown below is an average result of 50 independent simulation runs, with each run lasting for 100s (which includes about 25×10 = 250 requests). B. Results For comparison, we also implement GPSR [10], the original NDN flooding strategy described in Section III-A, and the timer-based strategy used in the basic design of CCVN [9] mentioned in Section II. Here we let GPSR work in the
0.6
0.4 GPSR NDN-orig NDN-timer NDN-geo w/o cache NDN-geo w/ cache
0.2
0 200
Fig. 5.
300
400 Total Vehicle Number
500
600
Average request success ratios using different forwarding strategies
request-response fashion, and we replace the route recovery method of GPSR with a simple carry-and-forwarding scheme which is considered to be more suitable for VANET scenarios [21]. We choose the following widely-used performance metrics to validate the effect of forwarding strategies. 1) Request Success Ratio: the ratio of the successful requests to all the requests. 2) Request-Response Delay: the time duration from the sending of a request to the receiving of the data response. Fig. 5 shows the average request success ratios with different total number of vehicles, and Fig. 6 shows the average request-response delay for the successful requests. In the plots, “NDN-orig” denotes the original flooding strategy in NDN, “NDN-timer” denotes the timer-based strategy, “NDN-geo w/o cache” and “NDN-geo w/ cache” represent our geo-based strategy with no cache and full-path cache, respectively. In Fig. 5, we can see that our forwarding strategy achieves much higher request success ratios. Specifically, our geobased forwarding strategy with full-path cache can achieve 75.0% higher success ratios than the original NDN flooding strategy (also with full-path cache) in sparse scenarios, and 27.3% higher in dense scenarios, which indicates the obvious effects of our geo-based strategy design in performance improvement. Compared with the timer-based strategy, our geobased strategy also achieves visible improvement in sparse scenarios (around 10%). When the vehicle density increases, the difference gradually becomes smaller due to the fact that higher density leads to better connectivity. Therefore, we can conclude that with the geo-based design, the NDN architecture can be well fit into the urban VANET scenarios. Compared with GPSR, our strategy with no cache can obtain 81.5% higher success ratios in sparse scenarios and 17.2% higher in dense scenarios, which verifies the advantage in the reliability design concerns including the forwarding decision based on not only the information in the packet but also the local geo-location information, and the multi-path forwarding at intersections, etc. Besides, the difference between our strategy with no cache and full-path cache indicates the cache effects, i.e., about 14% improvement with cache in both sparse and dense scenarios. In Fig. 6, we observe that our geo-based strategy with full-path cache achieves 39.1% ∼ 83.5% less delay than the
R EFERENCES
20 GPSR NDN-orig NDN-timer NDN-geo w/o cache NDN-geo w/ cache
Delay(s)
15
10
5
0 200
300
400 Total Vehicle Number
500
600
Fig. 6. Average request-response delay for successful requests using different forwarding strategies
original flooding strategy, and 13.1% ∼ 63.8% less delay than the timer-based strategy in scenarios with different vehicle densities. Compared with the no cache version, 30.7% ∼ 77.8% less delay can be achieved, indicating that cache plays an important role in reducing delay. As for GPSR, only a low ratio of requests are successful, and these successful requests experience a short delay, which results in a short average delay. We also count the number of Interest and Data packets generated for each request. The results show that our strategy introduce slightly more packets than the timer-based strategy which is mainly due to the multi-path forwarding mechanism, but much less than the original flooding strategy. Due to the space limit, we omit the plot. To summarize, our geo-based forwarding strategy can effectively improve the performance of data dissemination with high success ratio and low latency, thus can provide a good support for informative applications in urban VANET scenarios. There is still space for improvement in the sparse scenarios, which will be included in our future work. V.
C ONCLUSION
In this paper, we identify the challenges when applying NDN to VANETs, and propose the corresponding solutions for a better support of content delivery required by most typical VANET applications. We re-design the NDN forwarding strategy to combine the idea of geo-based routing and data dissemination which is more suitable for VANET scenarios, and we also take reliability and caching benefit concerns into account in the strategy design. We implement the strategy and carry out simulations to verify its performance. For comparison, we also implement some typical strategies presented by existing work. Simulation results show there is a great improvement in the request success ratio and delay with our forwarding strategy. In the future work, we will make special designs for scenarios with poor network connectivity, and the explicit caching effect will be investigated. ACKNOWLEDGMENT This work is supported by NSFC (61272340, 61201245), and 973 Program (2014CB340405).
[1] C. Wu, S. Ohzahata, and T. Kato, “Fuzzy logic based multi-hop broadcast for high-density vehicular ad hoc networks,” in Vehicular Networking Conference (VNC), 2010 IEEE. IEEE, 2010, pp. 17–24. [2] C. Wu, S. Ohzahata, and T. Kato, “A broadcast path diversity mechanism for delay sensitive vanet safety applications,” in Vehicular Networking Conference (VNC), 2011 IEEE. IEEE, 2011, pp. 171–176. [3] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard, “Networking named content,” in Proceedings of the 5th international conference on Emerging networking experiments and technologies. ACM, 2009, pp. 1–12. [4] J. Burke, “Video streaming over named data networking,” IEEE COMSOC MMTC E-LETTER, 2013. [5] Z. Zhu and A. Afanasyev, “Let’s chronosync: Decentralized dataset state synchronization in named data networking.” in ICNP, 2013, pp. 1–10. [6] Z. Zhu, A. Afanasyev, and L. Zhang, “A new perspective on mobility support,” Named-Data Networking Project, Tech. Rep, 2013. [7] Y. Zhang, H. Zhang, and L. Zhang, “Kite: A mobility support scheme for ndn,” in Proceedings of the 1st international conference on Information-centric networking. ACM, 2014, pp. 179–180. [8] L. Wang, A. Afanasyev, R. Kuntz, R. Vuyyuru, R. Wakikawa, and L. Zhang, “Rapid traffic information dissemination using named data,” in Proceedings of the 1st ACM workshop on Emerging Name-Oriented Mobile Networking Design-Architecture, Algorithms, and Applications, 2012, pp. 7–12. [9] M. Amadeo, C. Campolo, and A. Molinaro, “Enhancing content-centric networking for vehicular environments,” Computer Networks, vol. 57, no. 16, pp. 3222–3234, 2013. [10] B. Karp and H.-T. Kung, “Gpsr: Greedy perimeter stateless routing for wireless networks,” in Proceedings of the 6th annual international conference on Mobile computing and networking, 2000, pp. 243–254. [11] J. Zhao and G. Cao, “Vadd: Vehicle-assisted data delivery in vehicular ad hoc networks,” Vehicular Technology, IEEE Transactions on, vol. 57, no. 3, pp. 1910–1922, 2008. [12] K. Katsaros, M. Dianati, R. Tafazolli, and R. Kernchen, “Clwpr: A novel cross-layer optimized position based routing protocol for vanets,” in Vehicular Networking Conference, 2011 IEEE, 2011, pp. 139–146. [13] W. Viriyasitavat, F. Bai, and O. K. Tonguz, “Uv-cast: An urban vehicular broadcast protocol,” in Vehicular Networking Conference (VNC), 2010 IEEE, 2010, pp. 25–32. [14] G. Grassi, D. Pesavento, G. Pau, R. Vuyyuru, R. Wakikawa, and L. Zhang, “Vanet via named data networking,” in IEEE INFOCOMM 2013 NOMEN Workshop, 2014. [15] L. Wang, R. Wakikawa, R. Kuntz, R. Vuyyuru, and L. Zhang, “Data naming in vehicle-to-vehicle communications,” in INFOCOM WKSHPS, 2012 IEEE, 2012, pp. 328–333. [16] M. G. Almiron, O. Goussevskaia, A. A. Loureiro, and J. Rolim, “Connectivity in obstructed wireless networks: From geometry to percolation,” in Proceedings of the Fourteenth ACM International Symposium on Mobile Ad Hoc Networking and Computing, ser. MobiHoc ’13. New York, NY, USA: ACM, 2013, pp. 157–166. [17] P. Sahu, E. Wu, J. Sahoo, and M. Gerla, “Bahg: Back-bone-assisted hop greedy routing for vanet’s city environments,” Intelligent Transportation Systems, IEEE Transactions on, vol. 14, no. 1, pp. 199–213, March 2013. [18] C. Lochert, M. Mauve, H. F¨ußler, and H. Hartenstein, “Geographic routing in city scenarios,” ACM SIGMOBILE Mobile Computing and Communications Review, vol. 9, no. 1, pp. 69–72, 2005. [19] A. Afanasyev, I. Moiseenko, and L. Zhang, “ndnSIM: NDN simulator for NS-3,” NDN, Technical Report NDN-0005, October 2012. [Online]. Available: http://named-data.net/techreports.html [20] D. Krajzewicz, J. Erdmann, M. Behrisch, and L. Bieker, “Recent development and applications of SUMO - Simulation of Urban MObility,” International Journal On Advances in Systems and Measurements, vol. 5, no. 3&4, pp. 128–138, December 2012. [21] A. Fonseca and T. Vaz˜ao, “Applicability of position-based routing for vanet in highways and urban environment,” Journal of Network and Computer Applications, vol. 36, no. 3, pp. 961–973, 2013.
