1. 1 Data Naming in Vehicle-to-Vehicle Communications HU Yao Goto Lab 2012.06.07

2. 2 Outline Introduction Challenges of NDN naming in V2V Communication User Case In-vehicle System Assumptions & Operation Data Naming Requirements & Design Data Retrieval Example Conclusion

3. 3 Introduction [1] Today, vehicles use TCP/IP to communicate with centralized servers through cellular networks –Scalability challenges –Likely to take long delays than retrieving data directly from nearby vehicles –Information sharing for safety and real time traffic purposes, desire direct V2V communications which is difficult to achieve using the existing solutions

4. 4 Introduction [2] A new approach of using named-data to support direct V2V communication –Potentially eliminating the mobility management, session management and service discovery This paper represents the first attempt to present the specific data naming proposal, rather than the final words on data naming in vehicle networks

5. 5 Challenges of NDN naming in V2V Well defined application naming conventions understood by all vehicles flexible enough to allow vehicles to express exactly what kinds of data they may desire For example, some car wants to know the expected total driving time from location A to location B, while another car wants to know whether there is any congestion between A and B

6. 6 User Case Dissemination of traffic information –Timestamp when data was produced, e.g. a UNIX timestamp 1323201889 –Location information such as latitude and longitude of the car (collected by GPS), e.g. 37.446346, -122.120183 –Road name on which the car is traveling, e.g. Highway101, between exit 402 and 403 –Direction in which the car is traveling, e.g. Northbound Such traffic data could be generated either once or periodically, e.g. the average speed over the last 5 minutes

7. 7 In-vehicle system assumptions Each vehicle can have sufficient memory space and transmission power so that it can serve as data mule in addition to being data producer and consumer Each vehicle should try to collect as much information as feasible

8. 8 System operation [1] Three different roles played by vehicles and RSUs* –Data publisher –Data consumer –Data mule It helps disseminate the traffic information to vehicles in many different locations It also keeps the information available even when the original publisher has gone off the system (e.g. reached its destination and turned off) RSU: Vehicle-to-Road side unit, small static stations deployed along the roads

9. 9 System operation [2] Multiple data can be processed into a new one which carries a different information and becomes available to other interested vehicles

10. 10 Requirements on data naming Geographical Scoping –e.g. a specific section of a highway Temporal Scoping –e.g. any road event occurred within the last 30 mins Duplication detection –replies of the same data by the same producer or the same event by multiple publishers Data accuracy –One way to increase data accuracy is to leverage on redundancy, i.e. based on the number of vehicles advertising data for the same road event Application type –The data naming structure should be able to accommodate different data naming structures for individual applications

11. 11 Naming design Structure of data names for V2V traffic information exchanges –/traffic/geolocation/timestamp/data type/nonce –/traffic/road ID/direction/section number/timestamp/data type/nonce –/traffic/Highway 101/north/{400, 410}/{1323201600, 1323205200}/speed/19375887

12. 12 Data retrieval example [1] /traffic/Highway 101/north/{400, 410}/{1323201600, 1323205200}/speed/ –To request speed data within the specified 10-section and 1-hour scope /traffic/Highway 101/north/{400,410}/ –To request traffic data in the specified region generated at any time and regardless of the data type /traffic/Highway 101/ –To request all traffic information on highway 101 regardless of the regions and time

13. 13 Data retrieval example [2] A vehicle within the wireless broadcast range of an Interest and having matching data in its own cache will generate a response packet with the data If a vehicle has multiple pieces of data that all match the interest, but not all of them can fit into one reply packet –The first option is to only list the names of the available data pieces, rather than actual data. –The second option is to send a reply with randomly selected pieces of the matching data (e.g. 4/10).

14. 14 Conclusion [1] 2 departures from the general NDN module –Single-hop Interest packet forwarding only, which does not use the FIB (vehicles can indeed receive traffic information retrieved from far away and across multiple hops, thanks to data muling by all the vehicles) –In order to serve as an more effective data mule, a vehicle should take the opportunity to cache all received data packets even they are requested by others, rather than ignoring them

15. 15 Conclusion [2] This paper represents the first exploration of applying CCN to V2V communications The design of data name structure remains an open challenge

16. 16 References Lucas Wang, Ryuji Wakikawa, Romain Kuntz, Rama Vuyyuru, and Lixia Zhang, “Data Naming in Vehicle-to-Vehicle Communications”

17. 17 Thank you!