Information Centric Vehicular Networking · Overview of ICVN (3/4) 24 ①The data publisher stores...
Transcript of Information Centric Vehicular Networking · Overview of ICVN (3/4) 24 ①The data publisher stores...
Information Centric Vehicular Networking
Sangheon Pack (백상헌)School of Electrical Engineering, Korea University
Contents
• Introduction– Vehicular Networks and ICN
• Information Centric Vehicular Network• Vehicular Cloud Computing• Conclusion
2
Vehicular Network: Introduction• Vehicular Networks (or ITS/Telematics)
– Safety and transport efficiency• In Korea, around 6,000 people die and around 330,000 people are injured every year on the roads
• Traffic jams generate a tremendous waste of time and of fuel
– These problems can be solved by providing appropriateinformation to the driver or to the vehicle
3
Vehicular Network: Architecture
Infrastructure
Vehicle-to infrastructure (V2I)Communication
V2VVehicle-to vehicle (V2V)Communication
4
Vehicular Networks: Characteristics
• Large scale networks • Highly dynamic topology• Obstacles such as buildings • Frequently disconnected network• Predictable movement pattern• Sufficient energy and storage• Geographical type of communication• Hard delay constraints
5
Information Centric Network: Introduction (1/2)
• (Origin) Internet– Internet was designed for host‐to‐host communications
• Remote login, file transfer, …
– Internet (TCP/IP) architecture is well‐suited for communications between two stationary hosts
6
Information Centric Network: Introduction (2/2)
• (Today) Internet– Majority of Internet usage is data retrieval and service access
– Users care about the contents/information and are oblivious to location
• This usage pattern does not fit comfortably within the host‐to‐host communication model
• A new paradigm for contents/information‐centric from host‐centric architecture!
7
• Current Internet– Host‐to‐host communications– Node‐centric design
• ICN– Contents access/retrieval and Data‐centric design– Don’t worry about location (or address)!
Information Centric Network: Key Idea
8
Query Response
Information Centric Network: Long‐Term Vision
ICNCurrent Internet 9
Different ICN Architectures
• Data oriented network architecture (DONA) – http://radlab.cs.berkeley.edu/wiki/DONA
• Content centric networking (CCN) – http://www.ccnx.org/ (http://www.named‐data.org/)
• Publish‐subscribe Internet routing paradigm (PSIRP)– http://www.psirp.org/
• Network of Information (NetInf)– http://www.netinf.org/
• See [AHL12] for survey10
DONA vs. CCN
• Data‐Oriented Network Architecture (DONA)– The first ICN approach by UC Berkeley– Flat naming and (logically) hierarchical network architecture
• Contents‐Centric Networking (CCN) (or Named Data Network (NDN))– By Xerox PARC (Dr. V. Jacobson) and UCLA (Prof. L. Zhang)
– Hierarchical naming and flat network architecture
11
CCN: Overview
• Key idea– Send a query with contents name and receive the corresponding contents from nearby nodes
• Similar to Directed Diffusion in wireless sensor networks
• Features– Hierarchical name (cf. URL): name aggregation– In‐network caching– External trust source is needed for integrity
12
CCN: Naming
• Hierarchical name– Consumers request individual pieces from large collection of data
– Many recipients may share the same data packets: caching effect
13
CCN: Interest and Data Packets
• Interest packet– Similar to http “get”
• Data packet– Similar to http “response”
14
CCN Router
15
CCN Router: Forwarding Example
2
16
CCN Routing Example
1. Interest
3. Caching
2. Data
4. Interest
5. Data
17
Information Centric Vehicular Network: Motivation
• Conventional end‐to‐end (E2E) framework is not appropriate to vehicular networks!– Applications in vehicular network are service/information‐oriented
– In many situations, end‐to‐end paths do not exist
• Let’s design information‐centric networking/service frameworks in vehicular networks!
18
Application Challenges in Vehicular Networks [Bai10]
• Local and dynamic nature of information– Information in vehicular applications is spatially and temporally localized (e.g., traffic congestion application)
– E2E framework targeting for addressable entity is not appropriate!
• Application diversity– Spatio‐temporal scope varies from application to application
19
Network Challenges in Vehicular Networks [Bai10]
• Spatio‐temporal variation of vehicle density– Seoul vs. Jeju and 8AM‐9AM vs. 1AM‐2AM
• Spatio‐temporal variation link quality
• Network heterogeneity– Long‐range (3G/4G) vs. short‐range (WiFi/DSRC)
20
Analysis of Vehicular Applications [Bai10]
21
Application Spatial scope Temporal scope Interest scope
Safety information
250 m 10 sec All cars
Location‐based service
1‐5 km weeks Subscribers
City‐wide alert 20 km hours All cars
Road congestion information
5 km minutes All cars
File sharing 250 m minutes (index) days (content)
All subscribers (index) client‐server pair (content)
Interactive service 1‐5 km minutes Subscribers
Overview of ICVN (1/4)
• A vehicle can be– Information provider (e.g., each vehicle can generate various data using various sensors)
– Information consumer for different purposes– Each vehicle embeds an ICN module
22
Head Unit Smartphone/Tablet
ICN Forwarding Engine
Forwarding Information BaseFIB
PIT Pending Interests TableCS Contents Caches (data from
Built-in sensors, built-in cameras,safety system)
DSRC/WAVE/802.11p
WiFiNetwork
InterfacesDatabases
Driver
From [Wakikawa12]
Overview of ICVN (2/4)
• Requirements– Information provider describes what they have– Information consumer describes what they need– Geographical and temporal scoping
• Define location based scope for generated content and validity time for the content generated
– Duplication detection and elimination– Replication– Data accuracy and security/privacy
23
Overview of ICVN (3/4)
24
① The data publisher stores data from sensors, cameraor safety systems.
② The data mule cachesany data it can collect.
Trafficmessage
via DSRC
③ The data consumer sendsinterest and receives data.
data 1 data 2 data 3++New processed data
④ Head Unit displays theprocessed information.
From [Wakikawa12]
Overview of ICVN (4/4)
• A naming proposal in [Wakikawa12]– /traffic/geolocation/timestamp/data type/nonce
• “traffic” serves as application id to make naming application specific
• “geolocation” specifies where the event happens• “timestamp” shows when the event happens• “data type” indicates the meaning of data, e.g. closed lane, vehicle speed etc.
• “nonce” is used to uniquely identify each interest– e.g., /traffic/Highway 101/north/{400,410}/{1323201600,1323205200}/speed/19375887 25
State‐of‐the Art of ICVN
• General ICVN Framework– F. Bai and B. Krishnamachari, “Exploiting the Wisdom of the Crowd‐
Localized, Distributed Information‐Centric VANETs,” IEEE Communications Magazine, 48(5), May 2010.
• NDN/CCN‐based ICVN Framework– G. Grassi et al., “Vehicular Inter‐Networking via Named Data,” ACM
SIGMOBILE MCCR, 17(2), July 2013 – M. Amadeo et al., “Enhancing Content‐Centric Networking for Vehicular
Environments,” Computer Networks, 57(16), November 2013.
• NDN/CCN‐based ICVN Applications– J. Wang et al., “DMND: Collecting Data from Mobiles using Named Data,”
in Proc. IEEE VNC 2010, December 2010. – L. Wang et al., “Rapid Traffic Information Dissemination using Named
Data,” in Proc. ACM NoM 2012, June 2012.26
Information‐Centric Networking on Wheels (IC NoW)
• Information Producers/Consumers/Facilitators
27
Distributed Information Dissemination
• IC NoW is agnostic to particular network layer strategy– IC NoW packet includes general tuple describing information relevance scope rather than address
• Hybrid dissemination– Spatial‐domain dissemination (e.g., MANET routing)
– Temporal‐domain dissemination (DTN routing)
28
Distributed Information Management
• Information generation• Information relay
– Mobile infrastructure (or super vehicle)
• Information in‐network aggregation and processing
• Information replication• Information elimination• Information consumption
29
Implementation
• Distributed rule set APIs– How a corresponding packet should be handled by a node (or vehicle)
– REJECT and ACCEPT– CONSUME the packet, i.e., hand it to a local application at upper‐layer
– STORE and REMOVE– BROADCAST and PROCESS
30
IC NoW: Example
31
More Considerations
• Integration into existing architecture– Co‐exist with IP: overlay vs. GW
• Cooperative behaviors– Incentive mechanism
• Security issues– No unique ID: not easy E2E trust establishment
• QoS and Priority– Latency, reliability, and other QoS parameters
32
Vehicular NDN (V‐NDN)
• Heterogeneous connectivity– 3G/LTE/WiMAX– WiFi and DSRC/WAVE (IEEE 802.11p)
• Role– Publisher– Consumer– Forwarder/Mule
33
Features of V‐NDN (1/2)
• 1) V‐NDN encodes geolocation information into data names– All Interest packets can be forwarded to the geolocation
• 2) V_NDN hardly maintains FIBs for every data because of publishers’ movement– A publisher does not advertise its data name to create FIB for the data as in the original NDN
34
Features of V‐NDN (2/2)
• 3) V‐NDN leverage wireless broadcasting nature and lets every node in the broadcasting range cache the received data– Original NDN node accepts a data packet only when it has an PIT entry
35
V‐NDN Behavior (1/3)
• Infrastructure assisted V2V– Assisted left‐terns and accident warnings
36
WiFi / WiMax
CONSUMER1. INTEREST to the hub
NDN-HUB
2. INTEREST forwarded to a default WiMAX Client
5. CONTENT forwarding
3. INTEREST forwarded to Ad‐Hoc
4. The node with the data replies with a CONTENT
V‐NDN Behavior (2/3)
• I2V– Traffic monitoring system that constantly requests the current status for various critical intersections
37
CONSUMER
1. INTEREST to the hub
NDN-HUB
2. INTEREST forwarded to a default WiMAX Client 5. CONTENT
forwarding
3. INTEREST forwarded to Ad‐Hoc
4. The node with the data replies with a CONTENT
Internet
PRODUCER
6. CONTENT forwarded to the consumer which sent the interest
V‐NDN Behavior (3/3)
• V2I– Retrieve traffic information at the destination and direct V2V routing may be inefficient
38
PRODUCER
5. The producer replies with a CONTENT
NDN-HUB
6. CONTENT forwarded to the node which sent the interest over the infrastructure
3. INTERESTForwarded to the Hub
2. INTEREST forwarded
1. The consumer sends the INTEREST over Ad‐Hoc
Internet
CONSUMER
4. INTEREST forwarded to the registered clients
7. CONTENT forwarding
Content Centric Vehicular Networking (CCVN) (2/2)
• IEEE 802.11p – designed for vehicular networks and WAVE short message protocol (WSMP) can be used for safety‐critical and control messages
• How about non‐safety data?– TCP/IP is not the best choice!
Content Centric Vehicular Networking (CCVN) (2/2)
CCVN on top of802.11p layers asa replacement ofTCP/IP
Extended Interest Packet
• Basic Interest (B‐Int)– Retrieving the first content packet
• Advanced‐Interest (A‐Int)– Request subsequent data packets– Advertising information about the preferred content provider in the PROVIDER INFO field
Two Provider Selection Schemes
• Most Responsive Provider (MRP)– Only need the ProvID subfield– A provider is selected by response counter that is the number of times the provider replies
• Nearest and Most Responsive Provider (NMRP)– ProvID and Dp (hop distance)
Extended Data Packet
CCVN Operations (1/2)
1. A content consumer (C) broadcasts B‐Int– Content providers reply with the requested Data
after appending its PROVIDER INFO field– Intermediate node receiving the Data checks its
PIT• Yes: Add a new entry in CPT (Content Provider Table)• No: Discard the Data packet
– C also collects information about the reachable providers and stores the related parameters in its CPT and decides the preferred content provider and the hop distance
CCVN Operations (2/2)
2. C broadcasts A‐Int and intermediate node Rreceives A‐Int
– If CS hit and the node is the preferred one, • it immediately sends the Data
– If CS hit but not preferred one,• For MRP policy, always replies with the Data• For NMRP policy, replies with the Data only when it is
closer to the preferred one
– If CS miss,• CPT is updated and A‐Int is broadcasted
Data Collection Application
46
From [http://wwwen.zte.com.cn/endata/magazine/ztecommunications/2010Year/no4/articles/201012/t20101220_197102.html]
From [http://www.morgantechnicalceramics.com/markets-applications/automotive/]
System Requirements
• Scope specification– Topological scope/device type
• High data collection efficiency– Latency and delivery ratio
• Robustness to high mobility speed and scalability and a large number of mobiles
• Verification of content: integrity and malicious report
• Protection of users’ privacy• Mitigation to DDoS attacks 47
Design Assumptions
• Database servers are capable of expressing NDN interests and handle incoming content
• NDN routers have been deployed on edge networks (e.g., base station (BS)) in a global scale
• Special NDN boxes, provided by vehicle manufacturers, are installed at home, and serve as the first access point for mobiles within home network
48
Routing Announcement
• Base stations announce their name prefixes– BS1=> ndnx://toyota/diagnosis/us/ca/mountain‐veiw/bs‐1/
– BS2=> ndnx://toyota/diagnosis/us/ca/mountain‐veiw/bs‐2/
– Routing announcement entries can be aggregated• ndnx://toyota/diagnosis/us/ca/mountain‐veiw/
49
Interest Propagation
• Example: the database server in Toyota is only interested in collecting diagnosis information from Prius released in 2009 and only from those in California– Interest name=> ndnx://toyota/diagnosis/us/ca/*/prius/2009
– Interest is propagated to all base stations in California and broadcasted to vehicles
– Interests are further propagated to nearby vehicles by DSRC
50
Other Extensions
• Long‐lived interest– How to handle unreliable transmission property of wireless channels
• Increase the timer for PIT entries• BSs broadcast a pending Interest several times before timout
• Security– All contents are encrypted using the public key of the database server
– Mitigate DDoS attack by controlling the number of interest messages 51
Rapid Traffic Information Dissemination
• A driver on a road would like to know if there is any accident or traffic jam on his/her planned route and choose an alternative route – Not safety purpose!
52https://www.kapsch.net/ktc/its-solutions/V2X-Cooperative-Systems
NDN‐Layer Broadcast (1/2)
• Collision‐avoidance timer– Dissemination of traffic jams, accidents, road closures doesnot require a large amount of data
– A uniform random value from [0, 2msec]
• Pushing timer– Traffic accident information is valuable for the drivers traveling towards this place
– Need to disseminate packet farther away from the origin efficiently and to make a transmitter’s neighbor that is farther away to re‐broadcast the packet 53
NDN‐Layer Broadcast (2/2)
• NDN‐layer retransmission timer– For DSRC MAC broadcast, no ACK is defined– Every node broadcasts every packet several times with a pre‐configured retransmission timeout
– When the node hears that the packet has been successfully re‐broadcast farther, it will cancel subsequent retransmissions
• Application retransmission timer– Re‐express interest if the link layer recovery is failed
54
Vehicular Cloud Computing: Motivation (1/2)
55
• Resources of vehicles in VANET are most likely not utilized (or under‐utilized) for applications– Computing, Communication, Storage capabilities
• Future smart vehicles will be more sophisticated with advanced in‐vehicle resources– Powerful computing and storage devices, and multi‐modal programmable sensor nodes
Vehicular Cloud Computing: Motivation (2/2)
56
• Upload and download of every content (or traffic) to Internet are too costly and too time‐consuming
• Local relevance of VANET contents
VCC: Overview• Vehicles and roadside units (RSUs) effectively form a vehicular cloud (VC) as virtual platform– Vehicles collaborate to produce, maintain, and consume advanced vehicular services
57
Computing Storage
∙∙∙∙∙
Resources
VCC: Architecture (1/2)
58
M. Whaiduzzaman, M. Sookhak, A. Gani, and R. Buyya, “A survey on vehicular cloud computing,” Elsevier Journal of Network and Computer Applications, vol. 40, pp. 325‐344, April 2014.
VCC: Architecture (2/2)
59
Vehicles, RSUs(Physical resources)
Communication(V2V or V2I)
Vehicular cloud(Virtual resource pool)
Applications(Services)
Computing Storage Communication ∙∙∙∙∙
TrafficManagement
RoadSafety
UrbanSurveillance
∙∙∙∙∙
VCC: Operations (1/2) [Lee14]
• Cloud resource discovery– A vehicle (to be cloud leader) broadcasts a resource request (RREQ) message to recruit VC members
• Cloud formation– Vehicles willing to share their resources send a resource reply (RREP) messages
• Task assignment and result collection– The cloud leader splits the application into several tasks and distributes them to cloud members
– The cloud members return the results60
VCC: Operations (2/2) [Lee14]
• Content publishing and sharing– The leader processes results to obtain output content and saves/publishes
• Cloud maintenance & release– A members that wants to leave the VC send a cloud leave message to the leader
– When the leader no longer uses the cloud or moves out of the cloud, it sends a cloud release message to all the members
61
VCC: Services (1/2)
• Software as a service (SaaS)– Delivers various applications to consumers (vehicles) in VC
– Traffic management, autonomous driving, road safety, urban surveillance…
• Network as a service (NaaS)– An moving vehicle in VC can be used as WiFi access point gateway to access the Internet
62
VCC: Services (2/2)
• Storage/Computing as a service (STaaS/CaaS)– Some vehicles can require additional storage/computing resources to run their applications (e.g., backup, replication and p2p)
– Data center in mall/airport/parking lot
63
Contents / tasks
Use Case: CROWN [Mershad13]
• CROWN– Discovering and consuming services within vehicular clouds
– STAR• Transportation Server
– RSU‐aided STAR discovery
64
CROWN: Operation (1/2)
• Step 1) Registration of a STAR at its nearest RSU
• Step 2) Requesting to rent the STAR resources
• Step 3) Finding STARs that satisfy a request
• Step 4) RSU reply to a User
• Step 5) Consuming the STAR’s Resources65
CROWN: Operation (2/2)
66
CROWN: Service
67
VCC: Issues (1/2)
• VC Formation & Management– Static / Dynamic (Moving) / Hybrid– Centralized / Distributed– Connectivity and Resource availability
• Networking in VC– IP‐based / Content‐based– Resource discovery and Content distribution & sharing
68
VCC: Issues (2/2)
• Security and privacy in VC– Authentication / Integrity & confidentiality of contents
– Secure location & localization
• Incentive & Fault talerance in VC– A VC member should be rewarded properly for services
– A VC should prepare for unpredictable failures
69
Conclusion
• Vehicular Cloud Computing– Architectures, Services, Issues
• Vehicular Cloud Computing is an emerging technology– More research is needed
70
References (1/2)• [Bai10] F. Bai and B. Krishnamachari, “Exploiting the Wisdom of the
Crowd‐Localized, Distributed Information‐Centric VANETs,” IEEECommunications Magazine, 48(5), May 2010.
• [Wakikawa12] Ryuji Wakikawa et al.,” NDN Applicability to V2V and V2RNetworks,” in Proc. CCNxCon2012, September 2012
• [AHL12] B. Ahlgren et al., “A Survey of Information‐Centric Networking,”IEEE Communication Magazine, 50(7), July 2012.
• [Grassi13] G. Grassi et al., “Vehicular Inter‐Networking via Named Data,”ACM SIGMOBILE MCCR, 17(2), July 2013.
• [Amadeo13] M. Amadeo et al., “Enhancing Content‐Centric Networkingfor Vehicular Environments,” Computer Networks, 57(16), November 2013.
• [Wang10] J. Wang et al., “DMND: Collecting Data from Mobiles usingNamed Data,” in Proc. IEEE VNC 2010, December 2010.
• [Wang12] L. Wang et al., “Rapid Traffic Information Dissemination usingNamed Data,” in Proc. ACM NoM 2012, June 2012. 71
References (2/2)• [Whaiduzzaman14] M. Whaiduzzaman, M. Sookhak, A. Gani, and R. Buyya,
“A survey on vehicular cloud computing,” Elsevier Journal of Network andComputer Applications, vol. 40, pp. 325‐344, April 2014.
• [Lee14] E. Lee, E. Lee, and M. Gerla, “Vehicular Cloud Networking :Architecture and Design Principles,” IEEE Communications Magazine, vol.52, no. 2, pp. 148‐155, February 2014.
• [Olariu11] S. Olariu, I Khalil, and M. Abuelela, “Taking VANET to theclouds,” International Journal of pervasive Computing andCommunications, vol. 7. no. 1, pp. 7‐21, February 2011.
• [Hussain12] R. Hussain, J. Son, H. Eun, S. Kim, and H. Oh, “RethinkingVehicular Communications: Mergine VANET with cloud computing,” inProc. IEEE CloudCom 2012, December 2012.
• [Mershad13] K. Mershad and H. Artail, “Finding a STAR in a VehicularCloud,” IEEE Intelligent Transportation Systems Magazine, vol. 5. no. 2, pp.55‐68, April 2013.
72