Transcript CMT-TS-CAG Meeting - Grupo de Redes de Computadores

Redes Inalámbricas – Tema 5
Vehicular Networking
General overview
Technologies
 WAVE
 CALM
Mobility
Thanks to:
• Knut Evensen - CVIS Chief Architect
•John Moring
•Vinod Kone
•Jeonghoon Mo @ WINE LAB, Information and Communications University
REDES INALÁMBRICAS
Máster de Ingeniería de Computadores-DISCA
2
MIC 2009/2010
REDES INALÁMBRICAS
Motivation
 Safety and transport efficiency
 In Europe around 40,000 people die and more than 1.5 millions
are injured every year on the roads
 Traffic jams generate a tremendous waste of time and of fuel
 Most of these problems can be solved by providing appropriate
information to the driver or to the vehicle
REDES INALÁMBRICAS
MIC 2009/2010
3
Motivation: other scenarios
REDES INALÁMBRICAS
MIC 2009/2010
4
Motivation: other scenarios
5
MIC 2009/2010
Motivation: Sensor networks on the road
 Position sensors
 GPS, accelerometer,
compass, tilt sensor
 Environment sensors
 CO2, cameras,
thermometer, barometer,
humidity sensor
 Vehicle sensors
REDES INALÁMBRICAS
 ignition, speed, engine
speed, engine
temperature, …
Source: Davies, Cottingham, Jones: A Sensor Platform for
Sentient Transportation Research, LNCS 4272. Oct. 2006.
 Vehicle interior sensors
 camera, ID card reader
6
MIC 2009/2010
REDES INALÁMBRICAS
Technology trends
 Wi-Fi (and possibly WiMAX) enabled
vehicles are expected to be on the road
within the next 3-5 years. Assuming
10% market penetration, this amounts
to ~3-4 million Wi-Fi enabled vehicles
in the UK, and ~20 million in the US in
near future.
 FCC has allocated 75 MHz of spectrum
exclusively for V2V and V2I wireless
communications (total UK 3G spectrum
is ~ 70 MHz). In the UK and across the
EU 30 MHZ of spectrum has been put
aside for vehicular networks.
 Vehicles equipped with WiFi can
communicate directly with each other
(V2V), and with the fixed infrastructure
(V2I). They can form Vehicular Adhoc
Networks (VANET)
7
MIC 2009/2010
Vehicular Ad Hoc Network (VANET)
 Vehicular Ad Hoc network (VANET)
 Uses equipped vehicles as the network nodes
 Nodes move at will relative to each other but within the constraints of the
road infrastructure
REDES INALÁMBRICAS
 VANETs vs MANETs
 Rapid Topology Changes
High relative speed of vehicles => short link life
 Frequent Fragmentation
Chunks of the net are unable to reach nodes in nearby regions
 Small Effective Network Diameter
A path may cease to exist almost as quickly as it was discovered
(reactive routing)
 Limited Redundancy
The redundancy in MANETs is critical to providing additional bandwidth
In VANETs the redundancy is limited both in time and in function
8
MIC 2009/2010
So what kind of a system do we need?
 Desirable system properties
 Data collection and distribution in a local environment
 Low information delivery latency
 Cheap deployment and communication
 Probable solutions
 Cellular ? Service fees
 Satellite ? High latency
 Vehicular Networks ?
REDES INALÁMBRICAS
 What is a vehicular network?
 Vehicles are equipped with sensing, computing and wireless devices
 Vehicles talk to road-side infrastructure (V2I) and other vehicles (V2V)
 Has all the desirable properties
9
MIC 2009/2010
Vehicular Networks
 What does road-side infrastructure (Infostation) mean?
 High bandwidth & Low cost device
 Coverage is less compared to a cellular base station
 Advantages of infrastructure support
REDES INALÁMBRICAS
 Low latency communication with vehicles
 Gateway to the Internet and extend connectivity
 Distributing time-critical data (e.g. accident notifications, traffic jam) near
the affected area is efficient
10
MIC 2009/2010
Data Dissemination approaches and tradeoffs
Vehicular networks need to handle large amounts of data
(emergency messages, videos etc)
How do we efficiently disseminate this information?
REDES INALÁMBRICAS
 Characteristics
 High mobility
 Dynamic topology
 Receivers are a priori
unknown
 Large scale
 High density
 Low penetration ratio
 Challenges
 Maintaining routing tables
is difficult
 Scalability
 Dealing with partitions
11
MIC 2009/2010
Classification of Dissemination Approaches
 V2I / I2V dissemination
 Push based
 Pull based
 V2V dissemination
 Flooding
 Relaying
 How to deal with network partitions?
REDES INALÁMBRICAS
 Opportunistic forwarding
12
MIC 2009/2010
V2I / I2V dissemination
Push based
Pull based
V2V dissemination
Flooding
Relaying
How to deal with network partitions?
Opportunistic forwarding
Push based dissemination
 Infostation pushes out the data to everyone
 Applications: Traffic alerts, Weather alerts
 Why is this useful?
REDES INALÁMBRICAS
 Good for popular data
 No cross traffic  Low contention
 Drawback
 Everyone might not be interested in the same data
13
MIC 2009/2010
V2I / I2V dissemination
Push based
Pull based
V2V dissemination
Flooding
Relaying
How to deal with network partitions?
Opportunistic forwarding
Pull based dissemination
 Request – Response model
 Applications: Email, Webpage requests
 Why is this useful?
REDES INALÁMBRICAS
 For unpopular / user-specific data
 Drawback
 Lots of cross traffic  Contention, Interference, Collisions
14
MIC 2009/2010
V2I / I2V dissemination
Push based
Pull based
V2V dissemination
Flooding
Relaying
How to deal with network partitions?
Opportunistic forwarding
 Basic Idea
 Broadcast generated and received data to neighbors
 Usually everyone participates in dissemination
 Advantages
 “Good” for delay sensitive applications
 Suitable for sparse networks
 Key Challenges
REDES INALÁMBRICAS
 How to avoid broadcast storm problem?
Flooding
15
MIC 2009/2010
V2I / I2V dissemination
Push based
Pull based
V2V dissemination
Flooding
Relaying
How to deal with network partitions?
Opportunistic forwarding
Techniques to avoid the broadcast problem
 Simple forwarding
 Timer based
 Hop limited
 Map based / Geographic forwarding
 Directed flooding
 Aggregation
REDES INALÁMBRICAS
 Drawbacks / Limitations of Flooding
 Flooding in general
High message overhead  Not scalable
 Map based / Geographic
Geographically closest doesn’t necessarily reflect the best path!
Depend on a location based service
Aggregation techniques tradeoff with accuracy
16
MIC 2009/2010
V2I / I2V dissemination
Push based
Pull based
V2V dissemination
Flooding
Relaying
How to deal with network partitions?
Opportunistic forwarding
 Basic Idea
 Instead of flooding the network, select a relay (next hop)
 Relay node forwards the data to next hop and so on
 Advantages
 Reduced contention  Scalable for dense networks
 Key Challenges
REDES INALÁMBRICAS
 How to select the relay neighbors?
 How to ensure reliability?
Relaying
17
MIC 2009/2010
V2I / I2V dissemination
Push based
Pull based
V2V dissemination
Flooding
Relaying
How to deal with network partitions?
Opportunistic forwarding
How to select a relay neighbor?
 Simple forwarding
 Select the node farthest from source
 Map based / Geographic forwarding
 Closest to the destination
 Abstract topology into a weighted directed graph
 Drawback / Limitations
REDES INALÁMBRICAS
 Locally best next hop may not be globally best !
18
MIC 2009/2010
V2I / I2V dissemination
Push based
Pull based
V2V dissemination
Flooding
Relaying
How to deal with network partitions?
Opportunistic forwarding
How to ensure reliability?
 Use RTS/CTS & ACK
 Use indirect acknowledgments
 Drawbacks / Limitations
REDES INALÁMBRICAS
 RTS/CTS incurs lot of overhead
 Interference affects indirect acknowledgments
19
MIC 2009/2010
V2I / I2V dissemination
Push based
Pull based
V2V dissemination
Flooding
Relaying
How to deal with network partitions?
Opportunistic forwarding
Opportunistic Forwarding
 Problem with partitioned networks
 Next hop is not always present
 Opportunistic Forwarding
 Basic Idea: Store and Forward
 Challenge: What is the right re-broadcast interval?
 Solutions
REDES INALÁMBRICAS
 Broadcast repeatedly
 Cache at infostations
20
MIC 2009/2010
V2I / I2V dissemination
Push based
Pull based
V2V dissemination
Flooding
Relaying
How to deal with network partitions?
Opportunistic forwarding
Opportunistic: Drawbacks / Limitations
 It is difficult to select the correct re-broadcast interval
 Too soon  high overhead
 Too late  doesn’t deal with partitions effectively
REDES INALÁMBRICAS
 Maintaining a neighbor list induces high overhead and contention
21
MIC 2009/2010
REDES INALÁMBRICAS
Take Away
V2I/I2V Dissemination
Pros
Cons
Push
Suitable for popular data
Not suitable for un-popular
data
Pull
Suitable for un-popular/
user-specific data
Cross traffic incurs heavy
interference, collisions
V2V Dissemination
Pros
Cons
Flooding
Can reliably & quickly
distribute data
Not scalable for dense
networks
Relaying
Works well even in dense
networks
Selecting best next hop &
reliability is difficult
Dissemination in
Partitioned networks
Pros
Cons
Opportunistic
Suitable for network
partitions
Difficult to estimate
re-broadcast interval
High overhead in dense
networks
22
MIC 2009/2010
EU activities
Political, Social and Economic Interests
Harmonization
REDES INALÁMBRICAS
Specifications
European
Projects
Etc.
Convening
Stimulation
Moderation
Editoring
Dissemination
Standardisation
ETSI
CEN
Group of
Experts
Combination
Clarification
C2C-CC
IEEE
ITU
ISO
IETF
23
MIC 2009/2010
Numerous Systems and Standards are under
Construction…
A variety of EU and national projects elaborate
Protocol Architectures,
System Architectures,
High-Level Architectures .......
REDES INALÁMBRICAS
Do we really need yet another Communication - Architecture ?
Yes, because a comprehensive framework is needed to enable
individually developed components to cooperate easily
Source: Timo Kosch, BMW
ITS Station Reference Architecture
 Joint
development:
SM-SAP
 ETSI TC ITS
 COMeSafety
+ R&D
projects
Traffic
Efficiency
Other
Applications
SA-SAP
Road
Safety
SA-SAP
MA-SAP
MA-SAP
Station management
Security
NF-SAP
NF-SAP
Networking & Transport
SN-SAP
... +
IPv6
Mobility
Extensions
SI-SAP
GeoOther
Routing protocols
SN-SAP
ITS
Network
TCP/UDP
SI-SAP
MN-SAP
MN-SAP
ITS Transport
IN-SAP
Firewall and Intrusion Management
Session
Support
SF-SAP
Information
Support
SF-SAP
MF-SAP
MF-SAP
Application Support
Security Information Base
(Identity, CryptoKey and Certificate Managment)
FA-SAP
Facilities
Authentication, Authorization, Profile Management
FA-SAP
IN-SAP
MI-SAP
Access Technologies (PHY&DLL)
MI-SAP
Management
Networking Management
Management Information Base (MIB)
REDES INALÁMBRICAS
SM-SAP
Applications
Cross-Interface Management
24
MIC 2009/2010
Proposed European ITS Communication
Architecture
Station-External
Interfaces
e.g.
5.9GHz
e.g.
WiFi
Station-Internal
Interfaces
e.g.
e.g.
e.g.
e.g.
GPS BlueTooth 2G/3G/... Ethernet
Hardware Security
Module (HSM)
Redes Inalámbricas – Tema 5
Vehicular Networking
General overview
Technologies
 WAVE
 CALM
Mobility
Thanks to:
• Knut Evensen - CVIS Chief Architect
•John Moring
•Vinod Kone
•Jeonghoon Mo @ WINE LAB, Information and Communications University
REDES INALÁMBRICAS
Máster de Ingeniería de Computadores-DISCA
MIC 2009/2010
Wireless technologies for BWA
Wi-Fi
802.11a/b/g
WiMAX
DSRC
802.16d/e
802.11p ( WAVE)
Range
up to1000 m
up to 4 km
up to 40 km
Up to 250 m
data rate
11-54 Mbps
384 Kbps – 2Mbps,
14Mbps
10-100 Mbps
54 Mbps
spectrum
2.4 GHz (b/f)
2.5 GHz (US),
5.9 GHz
5.2 GHz (f)
1900 to 1980 MHz
and 2110 to 2170
MHz (UK)
licence
licence-exempt
licensed
Licensed & licenceexempt
dedicated spectrum
access
mechanism
contention-based
centrally scheduled
centrally scheduled
contention based
limitations
•Interference issues
due to shared
spectrum
•high deployment
costs
•high deployment
costs
short range
•lower transmission
rates, centralised.
•centralised
•already available,
•high data rates
• high coverage
•large coverage
•short range
REDES INALÁMBRICAS
3G
advantage
•low deployment
cost,
•distributed
3.5, 2.3/2.5, 5 GHz
•low deployment
costs
•Distributed
26
MIC 2009/2010
REDES INALÁMBRICAS
802.11b at speeds II: speed dependence
 Experiments performed
under no-interference
conditions (desert)
 External antenna on the
roof
 UDP, TCP, HTTP
 Observed some velocitydependent packet loss
Gass, Scott, Dio, 2005.
Redes Inalámbricas – Tema 5
Vehicular Networking
General overview
Technologies
 WAVE
 CALM
Mobility
Thanks to:
• Knut Evensen - CVIS Chief Architect
•John Moring
•Vinod Kone
•Jeonghoon Mo @ WINE LAB, Information and Communications University
REDES INALÁMBRICAS
Máster de Ingeniería de Computadores-DISCA
29
MIC 2009/2010
WAVE Scope
Host
Host
ON-BOARD
UNITS
External
Systems
OBU
OBU
Applications
Host
Host
WAVE Stack
WAVE Stack
WAVE Stack
WAVE Stack
Wireline Stack
Wireline Stack
Applications
Optional
External Interface
REDES INALÁMBRICAS
Covered by
WAVE Standards
Air Interface
Wireline Stack
Wireline Stack
ROAD SIDE
UNIT
Wireline Stack
Wireline Stack
External
Systems
In Vehicle
In Vehicle
Optional
Network
Network
External Interface
30
MIC 2009/2010
Protocol Architecture
Data Plane
Management Plane
UDP / TCP
WSMP
Management
Security
IPv6
LLC
WAVE MAC
(including channel coordination)
Air
Interface
REDES INALÁMBRICAS
PHY
31
MIC 2009/2010
Trial Use Standards
 IEEE Std 1609.1-2006
WAVE device
WAVE
IEEE 1609.2 Service
Security
 Resource Manager
Upper Layers IEEE 1609.1,
et al.
Networking
Services
IEEE 1609.3
Lower Layers IEEE 1609.4,
IEEE 802.11p
 IEEE Std 1609.2-2006
 Security Services
 IEEE Std 1609.3-2007
 Networking Services
 IEEE Std 1609.4-2006
 Multi-Channel Operation
 IEEE P802.11p - draft
REDES INALÁMBRICAS
 WAVE MAC and PHY
 IEEE Std 802.11-1999
Medium
 MAC and PHY
32
Future higher
layer standards
MIC 2009/2010
Full Use Standards in process
1609.2
WSMP
REDES INALÁMBRICAS
WAVE MAC
(including channel coordination)
PHY
802.11
LLC
1609.4
Management
Security
IPv6
1609.3
UDP / TCP
33
MIC 2009/2010
Overview of 802.11p (D7.0)
 Specifies channelization in the 5.9 GHz band
 Tunes some RF specs to allow highway operation
 Defines a mode of operation “outside the context of a basic
service set”
 Removes latency-causing link setup operations such as authentication
REDES INALÁMBRICAS
 Defines a Time Advertisement message
34
MIC 2009/2010
Overview of 1609.4 Multi-Channel Operation
 Extensions to the 802.11/802.11p MAC
 Management plane (MLME: MAC SubLayer Management Entity)
 Manages optional regular switching between control channel and service
channel
 Queues regular time advertisements and/or service advertisements
 Data plane (MAC)
REDES INALÁMBRICAS
 Multiplexes/demultiplexes higher layer protocols (IPv6, WSMP)
 Queues messages for transmission on the correct channels
 Manages transmit message priority
35
MIC 2009/2010
1609 Channel Coordination examples
CCH Interval
SCH Interval
CCH Interval
SCH Interval
Time
a)
CCH
Continuous access
Control Channel: management and (high priority) messages
b)
CCH
SCH
Alternating access
Service Channel: general user message and IP traffic
c)
CCH
REDES INALÁMBRICAS
SCH
d)
CCH
SCH
Immediate access
For devices that don’t
need continuous CCH
access
Extended access
36
MIC 2009/2010
1609.4 Transmit Operation
LLC
MAC (with Muti-Channel Operation)
Channel Routing
AC=4
AC=1
AC=2
AC=3
AC=4
AIFS[AC]
CW[AC]
TXOP[AC]
AIFS[AC]
CW[AC]
TXOP[AC]
AIFS[AC]
CW[AC]
TXOP[AC]
AIFS[AC]
CW[AC]
TXOP[AC]
AIFS[AC]
CW[AC]
TXOP[AC]
802.11p MAC (CCH)
AC=3
AIFS[AC]
CW[AC]
TXOP[AC]
AIFS[AC]
CW[AC]
TXOP[AC]
AC=2
AIFS[AC]
CW[AC]
TXOP[AC]
AC=1
REDES INALÁMBRICAS
SCH (WSM and/or IP data)
CCH (WSM data only)
Internal Contention
Internal Contention
Channel Selector and Medium Contention
Transmission
Attempt
Management
frames
802.11p MAC (SCH)
Management
frames
37
MIC 2009/2010
Overview of 1609.3 Networking Services
 Management plane (WME: WAVE Management Entity)
 Generates contents of service advertisements based on higher layer info
Including IP configuration info and security credentials
 Monitors received service advertisements for services of interest to higher
layers
Estimates channel quality
 Determines channel allocation/switching schedule to satisfy service
requests
 Data plane
REDES INALÁMBRICAS
 Incorporates standard LLC and IPv6
 Introduces thin WAVE Short Message Protocol (WSMP)
Allows direct control of RF parameters (e.g., power, data rate) by the
higher layer
38
MIC 2009/2010
WAVE Short Message Protocol (WSMP)
 Messages transmitted on request by higher layer
 Dest. MAC address, User Priority, Channel, Data rate, Transmit Power, PSID
 Messages delivered over the air by MAC address
 Unicast or broadcast
 Messages delivered up the stack by protocol and PSID
 EtherType distinguishes WSMP from IP
Higher layer
Peer
MAC
address
Dest_
address
REDES INALÁMBRICAS
Dest
address
User
priority
Priority
Priority
Channel
number
Channel
number
Channel
number
Data
rate
Data
rate
Data
rate
TxPwr_
Level
TxPwr_
Level
TxPwr_
Level
Expiry
Time
PSID
Expiry
Time
Expiry
Time
1
1
DSAP=
0xAA
SSAP=
0xAA
1
3
Length
WSM
data
1
4
Var.
1
2
Var.
WSMP
version
PSID
Ext.
fields
WSM
element
ID
WSM
length
WSM
data
WME-Wave
ShortMessage.req
WSMP
DLUNITDATA.req
LLC
2
Control=
OUI= EtherType
0x03
0x000000 =0x88DC
WSMP Header
WSM
data
MAUNITDATA.req
MAC
LLC header
SNAP header
Data field
39
MIC 2009/2010
“Services”
 Provider role
 Sends out WAVE Service Advertisements (WSAs) on control channel
Includes info on services and channels
May include IP configuration info
In Trial Use, included timing info – now separate
 Operates on identified service channel(s) at designated times for
application data exchange
 User role
REDES INALÁMBRICAS
 Monitors WSAs for services of interest
 May visit identified service channels at designated times for application
data exchange
 Allocation of radio resources to communication channels
performed by 1609 stack based on higher layer request priority,
service availability, device capabilities
40
MIC 2009/2010
WAVE Service Advertisement (WSA) contents
1
1
Var.
1
WAVE
version
Repeats
Extension
fields
Provider Service Table
WAVE Routing Advertisement
Transmit Power Used
2D/3D Location
IP configuration info
Advertiser Identifier
Service Info
Channel Info
1
2
16
1
16
6
16
Var.
WAVE
Element
ID
Router
lifetime
IpPrefix
Prefix
length
Default
gateway
Gateway
MAC
address
Primary
DNS
Extension
fields
Secondary DNS
KEY
KEY
Optional
Optional
Field
Extension fields
Lengths in octets
Lengths in octets
REDES INALÁMBRICAS
Info about available services
PSC
IPv6 Address
1
4
1
WAVE
Element
ID
PSID
Service
Priority
1
Var.
Channel Extension
fields
Number
Info about service channels
1
1
1
1
1
Var.
WAVE
Element
ID
Channel
Number
Adaptable
Data
Rate
TxPwr_
Level
Extension
fields
EDCA Parameter Set
Service Port
Provider MAC Address
May be
repeated
May be
repeated
41
MIC 2009/2010
Example of WAVE Transmit Protocol Layers
 This illustrates content from
the higher layers, processed
by the WAVE stack, and sent
out as a service advertisement
in an 802.11 frame
Higher layer
Service
info
WMEProviderService.req
WME
WSA
Header
PST
SEC-SignWSA.req
WRA
Security
Services
Security
Header
WaveService Advertisement
Security
Trailer
SEC-SignWSA.cfm
IEEE 1609
WME
MLMEX-WSA.req
WSA
MLME
extension
OUI
Content
descr.
MLMEVSPECIFIC.req
WSA
MLME
Cate
gory
OUI
Vendor Specific Content
REDES INALÁMBRICAS
MAC
MAC
Header
Vendor Specific Action frame
IEEE 802.11
MAC
Trailer
PHY
PHY
Header
Air
interface
42
MIC 2009/2010
PSID & PSC
 Provider Service Identifier (PSID)




4 octets; values allocated by IEEE
Used as WSMP recipient address, and
Used as primary identifier of services in WAVE Service Advertisement
Presumably identifies type of information and encoding to be found on the
SCH
 Provider Service Context (PSC)
REDES INALÁMBRICAS
 0-32 octets; meaning determined by PSID
 Used as optional secondary service descriptor in WSA
 May indicate information sub-type, date tag, security context, etc.
Redes Inalámbricas – Tema 5
Vehicular Networking
General overview
Technologies
 WAVE
 CALM
Mobility
Thanks to:
• Knut Evensen - CVIS Chief Architect
•John Moring
•Vinod Kone
•Jeonghoon Mo @ WINE LAB, Information and Communications University
REDES INALÁMBRICAS
Máster de Ingeniería de Computadores-DISCA
44
MIC 2009/2010
CALM - Overall
 Continuous Air interface for Long and Medium distance
REDES INALÁMBRICAS
 ISO TC204/WG16 – Wide Area Communications
 Support user transparent continuous communications
 CALM is the first open way to combine GPRS with vehicleoptimized WLAN technology.
NOT a complicated collection of new, unproven radio
technologies
45
MIC 2009/2010
REDES INALÁMBRICAS
Services defined for 5 GHz medium - 1
CVO - Tractor-Trailer Interface
CVO - Rollover Warning
CVO - Electronic Border Clearance
CVO - Weigh Station Bypass Clearance
CVO - CVO Fleet Management
CVO - Onboard Safety Data Transfer
CVO - Tractor-Trailer Matching
CVO - Transit Vehicle Data Transfer
CVO - Vehicle Safety Inspection
CVO - Drivers Daily Log
OTHER SERVICES - Probe Data Collection
OTHER SERVICES - Access Control
OTHER SERVICES – Vehicle Manufacturer Info
PAYMENTS - Toll Collection
PAYMENTS - ITS Service Payment
PAYMENTS - Other ePayments
PAYMENTS - Rental Car Processing
PAYMENTS - Parking Payment
PAYMENTS - Food Payment
PAYMENTS - Fuel Payment
SAFETY - Vehicle-to-vehicle Data Transfer
SAFETY – Highway-Rail Intersection Warning
Traffic Information - Audio Transfer - Streaming
Traffic Information - Map Updates
Traffic Information - Mobile Internet
Traffic Information - Traffic Data
Traffic Information - Traveller Information
Traffic Information - Vehicle Registration (EVI)
Traffic Information - Transit Vehicle Priority
Traffic Information - Diagnostic Data Transfer
Traffic Information - Video Transfer - Block
Traffic Information - Audio Transfer - Block
Traffic Information - Video Transfer - Streaming
Traffic Information - Repair Service Record
Traffic Information - Vehicle Software Updates
VSC - OBU-to-OBU - Approaching Emergency Vehicle Warning
VSC - OBU-to-RSU - Emergency Vehicle Signal Pre-emption
VSC - OBU-to-RSU - Intersection Emergency Vehicle Approaching
VSC - RSU to OBU - Emergency Scene Data Networking
VSC - OBU-to-OBU - Emergency Scene Data Networking
VSC - OBU-to-OBU - Cooperative Collision Warning
46
MIC 2009/2010
REDES INALÁMBRICAS
Services defined for 5 GHz medium - 2
VSC - RSU to OBU
VSC - RSU to OBU
Navigation
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
Warning
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
VSC - RSU to OBU
- Map Downloads and Updates
- Enhanced Route Guidance and
-
GPS Corrections
Adaptive Headlight Aiming
Adaptive Drivetrain Management
Merge Assistant
Sign Information (warning assistance)
Point-of-Interest Notification
Curve Speed Warning
Highway/Rail Collision Warning
Animal Crossing Zone Information
Low Bridge Warning
Work Zone Warning
Stop Sign Warning
Keep Clear' Warning
Wrong-way Driver Warning
Left Turn Assistant
Infrastructure Intersection Collision
-
Pedestrian Crossing Information
Pedestrian/Children Warning
School Zone Warning
Stop Sign Movement Assistance
Traffic Signal Warning
Low Parking Structure Warning
VSC - OBU-to-OBU - Pre-crash Sensing
VSC - OBU-to-OBU - Intersection Collision Warning
VSC - OBU-to-OBU - Enhanced Differential GPS Corrections
VSC - OBU-to-OBU - Highway/Rail Collision Warning
VSC - OBU-to-OBU - Vehicle-based Road Condition
Warning
VSC - OBU-to-OBU - Road Feature Notification
VSC - OBU-to-OBU - Curve Speed Warning
VSC - OBU-to-OBU - Visibility Enhancer
VSC - OBU-to-OBU - Electronic Brake Lights
VSC - OBU-to-OBU - Hybrid Intersection Collision Warning
VSC - OBU-to-OBU - Instant (Problem) Messaging
VSC - OBU-to-OBU - Blind Merge Warning
VSC - OBU-to-OBU - Post-Crash Warning
VSC - OBU-to-OBU - Merge Assistant
VSC - OBU-to-OBU - Lane Change Assistant
VSC - OBU-to-OBU - Left Turn Assistant
VSC - OBU-to-OBU - Stop Sign Movement Assistant
VSC - OBU-to-OBU - Cooperative Glare Reduction
VSC - OBU-to-OBU - Blind Spot Warning
VSC - OBU-to-OBU - Platooning
VSC - OBU-to-OBU - Cooperative Adaptive Cruise Control
VSC - OBU-to-RSU - Infrastructure-based Traffic Probes
VSC - OBU-to-RSU - SOS Services
VSC - OBU-to-RSU - Post-Crash Warning
VSC - OBU-to-RSU - Just-in-Time Repair Notification
VSC - OBU-to-RSU - Intelligent On-ramp Metering
VSC - OBU-to-RSU - Intelligent Traffic Lights
VSC - OBU-to-RSU - Blind Merge Warning
47
MIC 2009/2010
CALM classic architecture
ISO TC204
ITS APPLICATIONS
Service
QoS
HTTP/
SMTP
Protocols
Stream &
Realtime
Protocols
ISO
DSRC
L7
Interface
Selection
TCP
UDP
L2/UDP
REDES INALÁMBRICAS
IPv6 layer
Handover
Interface
QoS
Init
Hndovr
Secur
MAC
802.11p
WAVE
Init
Hndovr
Secur
MAC
2G/3G
GSM
Init
Hndovr
Secur
MAC
GPS/Galileo
…
48
MIC 2009/2010
CALM System Architecture (21217) (Rev. Geneva)
CME
CALM
Manager
ISO 21210
CME
Registration of
Ingress/Egress
Interfaces
Application
Management
ISO 24101
SAP
SAP
SAP
Convergence Layer
IP socket/
ISO 21210
TCP/UDP/…
INTERNET
STANDARDS
SAP
SAP
CALM-Aware
APPLICATIONS
SAP
SAP
SAP
SAP
NME
Network SAP
Manager
ISO 21210
SAP
SAP
NETWORK INTERFACE
Routing and Media Switching based on IPv6
ISO 21210
SAP
SAP
SAP
SAP
SAP
SAP
ISO 21218
ISO 24xxx
Wired
Manager
CAN
AMIC
Ether
BlueT
Applications
W-USB
Management SAP
SAP
ISO 21218
ISO 24xxx
PAN
Manager
…
SAP
GPS
Data SAP
DAB
External Media CALM Network 21218 = LSAP
SAP
ISO 21218
ISO 24xxx
Broadcast
Manager
…
WiMAX
HC-SDMA
C-DSRC
ISO 21218
ISO 24xxx
W-MAN
Manager
J-DSRC
ISO 21218
ISO 24103
DSRC
ISO15628
MM-E
ISO 21218
ISO 21216
Millimeter
Manager
MM-J
M5
WiFi
…
SAP
IR-A
IR-B
…
UMTS
cdma2k
…
EDGE
GPRS
CALM Media
ISO 21218
ISO 21215
W-LAN
Manager
SAP
…
ISO 21218
ISO 21214
IR
Manager
SAP
K-DSRC
ISO 21218
ISO 21213
3G Cell
Manager
SAP
RADAR
ISO 21218
ISO 21212
2G Cell
Manager
…
REDES INALÁMBRICAS
Non-CALM-aware
IP (Internet)
APPLICATIONS
Convergence Layer
Part of ISO 15628
ISO 21210
SAP
IME SAP
Interface
Manager
ISO 24102
Non-CALM-aware
ISO 15628-based
APPLICATIONS
49
MIC 2009/2010
Vehicle Architecture
CALM
Network
Layer
Ethernet
Ethernet
ITS In-Vehicle Network 100baseT Ethernet
Real-time
Applications
CVIS Integrated Mobile Router
Network
REDES INALÁMBRICAS
C2C-CC
Fast Net
Network
DSRC
CALM LLC
Convergence
CALM MAC
Ethernet
RT
Link
Sensors, HMI
and Control
In-Vehicle App
IVN DLL
IVN DLL
IVN PHY
IVN PHY
In-vehicle OEM networks
CAN/VAN/MOST/AMI-C..
Nomadic device Gateway
CALM Routing
Network
Ethernet
Ref
pt
C2C
Switch
Layer
Firewall
OEM G/W
Real-time
Applications
CALM M5 PHY
DSRC L2/L7
DSRC L1
Comms
gateway
Network
Network
GPRS
Convergence
GPS
Convergence
GPRS Stack
GPS Stack
Bluetooth
GPS PHY
Bluetooth
GPRS PHY
Combined Antenna Pod
CME.
Router
NME.
Router
IME.
Router
50
MIC 2009/2010
Communication Scenarios
 CALM defines 5 communication scenarios:
 0 – V2I Non-IPv6
(WSMP or C2C-CC?)
 1 – V2I/V2V Local IPv6
 2 – V2I MIPv6
 3 – V2I NEMO
 4 – V2V Non-IPv6
(WSMP or C2C-CC?)
HA
CN
Internet
REDES INALÁMBRICAS
Access Router
Mobile Router
LFN LFN LFN
51
MIC 2009/2010
What is CALM M5? US DSRC (WAVE)
 WAVE is IEEE 802.11p, as required by US DoT/VSCC/VII/…
 WAVE is optimised for US channel plan
 WAVE protocols are optimised for current single-radio technology.
 No GSM or other technology is included.
 CALM M5 incorporate WAVE and adds:
REDES INALÁMBRICAS






Global (European) 5 GHz spectrum
Regulatory domain (border) management
Directivity and EMC control
CEN DSRC co-operation
Multiple radio/interface/antenna management
GPRS/UMTS network interconnectivity
52
MIC 2009/2010
CALM M5: C2C-CC & WAVE
Geoaddressed
applications
(e.g. active safety)
IP Applications
(Deployment)
WAVE Short
Message Apps
WSMP
TCP / UDP
IPv6
B
C2C-CC Network Layer
REDES INALÁMBRICAS
A
C2C MAC
B
LLC/MAC (IEEE 802.11p)
PHY (IEEE 802.11p)
C
P1609.4
Redes Inalámbricas – Tema 5
Vehicular Networking
General overview
Technologies
 WAVE
 CALM
Mobility
Thanks to:
• Knut Evensen - CVIS Chief Architect
•John Moring
•Vinod Kone
•Jeonghoon Mo @ WINE LAB, Information and Communications University
REDES INALÁMBRICAS
Máster de Ingeniería de Computadores-DISCA
54
MIC 2009/2010
Mobility
 Mobility is the key issues in Vehicular Networks
 In cellular based networks, handoff is a mature technique
 Handoff in GSM networks
 Handoff in CDMA networks
 In IP based networks, handoff is immature
 WiMax, Wi-Fi
REDES INALÁMBRICAS
 Vertical handoff, NEMO are being pursued…
55
MIC 2009/2010
Different Types of Mobility
 Scale




Pico
Micro
Macro
Global
 Network
 Vertical Handoff
 Horizontal Handoff
REDES INALÁMBRICAS
 Moving Entity




Host mobility
User Mobility
Application Mobility
Network Mobility
56
MIC 2009/2010
REDES INALÁMBRICAS
How to handle Mobility?
 Where can we address this problem?






Physical layer? (sure; very limited)
Link layer
Network layer
Transport layer
“Something higher” (often called session)
Application layer
57
MIC 2009/2010
REDES INALÁMBRICAS
How to handle Mobility?
 Where can we address this problem?






Physical layer? (sure; very limited)
Link layer
Network layer
Transport layer
“Something higher” (often called session)
Application layer
Possible to code many applications to deal with disconnection
It’s all about trying to resume and managing state
But should the burden be placed on every application developer?
58
MIC 2009/2010
Link-layer mobility
 What timescales does it support?
 Pretty durned fast
 Have the link layer mask mobility
 E.g., the campus 802.11 wireless. You can move anywhere and keep the
same MAC and IP address
Completely transparent. No OS/App support needed. Brilliant!
Fast & Local: Only switches near moving client must be updated.
But – only local! Can’t move out of your subnet.
 How about different links, different technologies?
REDES INALÁMBRICAS
 IEEE 802.21
59
MIC 2009/2010
IP Layer Mobility
 Allow hosts to take their “home” IP address with them wherever
they go.
 Advantages:
 Potentially global mobility scope (not limited to subnet like link layer)
 Transparent to applications and layers above IP
REDES INALÁMBRICAS
 How can we do it?
60
MIC 2009/2010
Brute Force: IP routing
 If node leaves home, send out (global?) routing announcement
pointing to new location
 In theory, “just works”
 Example: Boeing’s “Connexion” announced a /24 into BGP for every
supported airplane and moved the announcement to the gateway the plane
was closest to
 Why? Latency concerns over really long flights (start in SF, end in London)
 Already have high latency from using satellites.
 But wouldn’t scale for single IP addresses
REDES INALÁMBRICAS
 Every AS in world would have routing entry for every mobile user in the
world? Ouch!
 Problem: Having the whole world maintain state for every user
 Alternative: Keep state local, by…
61
MIC 2009/2010
Mobile IP (& others):
 Same as other problems in Computer Science
 Add a level of indirection
 Keep some part of the network informed about current location
 Need technique to route packets through this location (interception)
REDES INALÁMBRICAS
 Need to forward packets from this location to mobile host
(delivery)
62
MIC 2009/2010
Mobile IP
 RFC 3220 “IP Mobility Support for IPv4”, C. Perkins, Ed., Nokia
Research Center, January 2002
 has many features:
 home agents, foreign agents, foreign-agent registration, care-of-addresses,
encapsulation (packet-within-a-packet)
 three components to standard:
REDES INALÁMBRICAS
 indirect routing of datagrams
 agent discovery
 registration with home agent
63
MIC 2009/2010
IP Mobility: Principles
 Core network routing transparency
 Routers and switches are un-aware of mobility
 Host-controlled location update to effect routing path change
 Responsibility rests on the Mobile Node (MN)
 Adheres to the “end-to-end” model
REDES INALÁMBRICAS
 Minimal network support
 Intelligent host
64
MIC 2009/2010
Solution Requirements
 Roaming:
 Roaming: Packets need to reach the current location of a Mobile Node
 Handover:
REDES INALÁMBRICAS
 Connection (session) end-point must remain constant even though the IP
address changes
 Connection end-point must be able to handle change of IP address
65
MIC 2009/2010
Mobile IP: indirect routing
foreign-agent-to-mobile packet
packet sent by home agent to foreign
agent: a packet within a packet
dest: 79.129.13.2
dest: 128.119.40.186
dest: 128.119.40.186
REDES INALÁMBRICAS
Permanent address:
128.119.40.186
dest: 128.119.40.186
packet sent by
correspondent
Care-of address:
79.129.13.2
66
MIC 2009/2010
Mobile IP: agent discovery
 agent advertisement: foreign/home agents advertise
service by broadcasting ICMP messages (typefield = 9)
0
type = 9
checksum
=9
standard
ICMP fields
router address
type = 16
length
registration lifetime
REDES INALÁMBRICAS
24
code = 0
=9
H,F bits: home
and/or foreign agent
R bit: registration
required
16
8
sequence #
RBHFMGV
bits
reserved
0 or more care-ofaddresses
mobility agent
advertisement
extension
67
MIC 2009/2010
Mobile IP: registration example
home agent
HA: 128.119.40.7
foreign agent
COA: 79.129.13.2
visited network: 79.129.13/24
ICMP agent adv.
COA: 79.129.13.2
….
registration req.
COA: 79.129.13.2
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 9999
identification: 714
encapsulation format
….
registration req.
COA: 79.129.13.2
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 9999
identification:714
….
REDES INALÁMBRICAS
registration reply
time
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 4999
Identification: 714
encapsulation format
….
registration reply
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 4999
Identification: 714
….
Mobile agent
MA: 128.119.40.186
68
MIC 2009/2010
Mobile IP Issues
 Route Optimization
 In order to always use HoA, packets need to be routed through the Home
Agent
 introduces sub-optimal routing and hence potentially longer delay
 Direct communication between the MN and its correspondents should be
possible
 Authentication
 Registration messages
 Binding cache updates
 Must send updates across network
REDES INALÁMBRICAS
 Handoffs can be slow
69
MIC 2009/2010
Mobile IP Optimization
 Fast Handoff
 Handoff delay is too long
 Can we reduce it?
 FMIP, FMIPv6
 Hierarchical Handoff
REDES INALÁMBRICAS
 Frequent Binding Update incurs burden on
 Let’s handle the local movements inside the local network
REDES INALÁMBRICAS
MIC 2009/2010
70
Handoff Delay Illustration
71
MIC 2009/2010
Fast Handover Protocol
 Allows a MN to learn new Router information when still attached
to the current router
 enables fast movement detection
 expedites new address configuration
 facilitates immediate transmission upon new link establishment
 Allows a MN to receive packets sent to its previous IP address
until
 Binding Update to Home Agent is completed
 Binding Update to the correspondent is completed
REDES INALÁMBRICAS
 Involves tunnel establishment triggered by MN signaling
REDES INALÁMBRICAS
MIC 2009/2010
72
Fast Handover Illustration
REDES INALÁMBRICAS
MIC 2009/2010
73
Delays with Fast Handover
MIC 2009/2010
74
Hierarchical MIP:
Macro Mobility and Micro Mobility
 Macro Mobility
 Domain-level, Mobile IP-based
 Micro Mobility
 Cell area, Hierarchical MIP
REDES INALÁMBRICAS
Home Agent
75
MIC 2009/2010
Transport-layer solution
 TCP Migrate
 Idea: No IP support; just have transport layer dynamically rebind endpoints  MIGRATE
Location Query
(DNS Lookup)
Location Update
(Dynamic DNS Update)
DNS Server
REDES INALÁMBRICAS
Connection Initiation
Connection Migration
Correspondent
Host
Mobile Host
foo.bar.edu
yyy.yyy.yyy.yyy
xxx.xxx.xxx.xxx
76
MIC 2009/2010
Migrate
 Advantages:
 (Mostly) transparent to applications
Unless they know their IP address and use it, e.g., peer-to-peer apps.
 Keeps state and modifications entirely at endpoints
 No triangle routing! All communication is direct
 But:
REDES INALÁMBRICAS
 Requires TCP support / only works for TCP
Not true in general: “Host ID Protocol” – HIP – can work with both, but
requires more invasive IP stack changes
 Slower timescales than link-layer migration (several RTTs)
MIC 2009/2010
REDES INALÁMBRICAS
Other issues: Network Mobility (NEMO) Support
 The vehicle changes its point
of attachment to the
Internet
 Host Mobility
Each node maintains
Internet access
Each host must perform
Mobile IPv6
 Network Mobility
Only the mobile router(MR)
maintains Internet access
Nodes can be located
behind the MR
Host Mobility Support
Mobile Router
Network Mobility Support
7
7
78
MIC 2009/2010
Other issues: Host Identity Protocol (HIP)
 Considerable recent work: Give each host a unique identity
 Simplifies mobility
 Also simplifies multi-homing! (Many related issues)
 Deployment Issue
 Idea:
 IP address: changes with location
 HIP does not change
Application-specific identifiers
REDES INALÁMBRICAS
Pairs <IP address, Port#> +
Transport Protocol ID
Host Identity (HI)
Application Layer
Transport Layer
Host Identity
IP addresses
Network Layer
Link layer addresses
Data Link Layer