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

[email protected]

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]


• 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


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]


• 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


• 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


• 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

information centric vehicular networking · overview of icvn (3/4) 24 ①the data publisher stores...

Documents