Vehicular Networking Slides-P1

Vehicular

Networking

Bookdesign©2014CambridgeUniversityPress

Overview

▪  VehicularNetworking

▪  Part1:...incars▪  Overviewandusecases

▪  Architectures

▪  Bussystems

▪  ElectronicControlUnits

▪  Securityandsafety

▪  Part2:...ofcars▪  Overviewandusecases

▪  Architectures

▪  CommunicaIonsystems

▪  ApplicaIons

▪  Securityandsafety

Vehicular Networking 2

IllustraIon©2010ChristophSommer

Aboutthisslidedeck

▪  Theseslidesaredesignedtoaccompanyalecturebasedonthetextbook“VehicularNetworking”byChristophSommerandFalkoDressler,publishedinDecember2014byCambridgeUniversityPress.

▪  Exceptwhereotherwisenoted(e.g.,logosandcitedworks)thisslidedeckisCopyright©2009-2015ChristophSommer,butmadeavailabletoyouunderaCrea%veCommonsA-ribu%on-ShareAlike4.0Interna%onalLicense.

▪  Inbrief,thismeansyoucanshareandadapttheslidesaslongasyoufollowthetermssetoutinthislicense[1].IfyousplitthisslidedeckintomulIpleparts,makesuretoincludeappropriateaZribuIonineachpart.

▪  ThisslidedeckwouldnothavebeenpossiblewithoutthecontribuIonsofFalkoDressler,DavidEckhoff,ReinhardGerman,andKai-SteffenJensHielscher.

▪  Pleaseleavethisslideintact,butindicatemodificaIonsbelow.▪  Version2015-02

▪  Improvedversionforreleaseonbookwebsite(ChristophSommer)

▪  Updatedversionsoftheoriginalslidedeckareavailableonline[2].


[1]hZp://creaIvecommons.org/licenses/by-sa/4.0/

[2]hZp://book.car2x.org/

CourseMaterial


Bookdesign©2014CambridgeUniversityPress

Title VehicularNetworking

Authors ChristophSommerandFalkoDressler

Publisher CambridgeUniversityPress

Date December2014

Format Hardback(alsoavailableaseBook)

ISBN-10 1107046718

ISBN-13 9781107046719

Website hZp://book.car2x.org

AShortIntroducIon

…toVehicularNetworking


IntroducIon–Electronicsincars


DataSource:U.Weinmann:AnforderungenundChancenautomobilgerechterSokwareentwicklung,3.EUROFORUM-Fachkonferenz,StuZgart,Juli2002

1970s

• ElectronicFuelInjecIon• CentralizedWarningLights

• CruiseControl• CentralLocking• ...

1980s

• Electronictransmissioncontrol

• Electronicclimatecontrol

• ASC(AnISlipControl)• ABS(AnIlockBrakingSystem)

• Phone• Seatheatercontrol• AutomaIcallydimmingrearviewmirror

• ...

1990s

• navigaIonsystem

• CDchanger• ACC(AcIveCruiseControl)• Airbags• DSC(DynamicStabilityControl)

• AdapIveTransmissionControl

• RollstabilizaIon• Xenonlight• BMWAssist

• RDS/TMC

• VoiceRecogniIon• Emergencycall

• ...

2000s

• ACCStop&Go• BFD• ALC• KSG• 42voltsystem

• InternetPortal• GPRS,UMTS

• TelemaIcs

• OnlineServices• Bluetooth• CarOffice

• LocalHazardWarning

• IntegratedSafetySystem

• Steer/Brake-By-Wire

• I-Drive• Lanekeepingsupport• PersonalizaIon• SWupdate

• ForceFeedbackPedal• ...

ElectronicsneedcommunicaIon


DataSource:U.Weinmann:AnforderungenundChancenautomobilgerechterSokwareentwicklung,3.EUROFORUM-Fachkonferenz,StuZgart,Juli2002

Complexity

EmbeddedControlUnits(n)

Numberofsignals(k*n) NumberofpotenIalcommunicaIonpartners(n*(n-1))

CoordinaIonoverhead(q*n*(n-1))

Componentfailurerate


DataSource:ADACVehicleBreakdownStaIsIcs2005-2008

35.0%

18.8%

14.6%

7.7%

6.0%

6.2%

5.6%

4.1%

2.0%

38.6%

14.0%

13.6%

7.9%

6.6%

6.7%

6.0%

4.1%

2.2%

39.7%

13.6%

12.7%

7.8%

6.8%

7.1%

5.8%

4.6%

1.9%

40.0%

16.0%

10.0%

8.0%

8.0%

7.0%

5.0%

4.0%

2.0%

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

Electronics

Misce

llaneous

IgniIo

n

Engin

e

FuelinjecI

on

Tiresandw

heels

HeaIng,co

oling,A/C

Clutch

,gearsh

ik

Exhaustsys

tem

2005 2006 2007 2008

Bussystems

▪  UnIltheendofthe80s▪  Cars‘controlunitsareisolated,non-networked▪  dedicatedwiresconnectsensorsandactors

▪  StarIngwiththe90s▪  digitalBussystems

▪  CAN-Bus▪  Today

▪  Risingdemandsonbussystems

▪  networkedfuncIonalityrequiresmorethanonecontrolunit▪  Turnsignal:>8disInctcontrolunits

▪  RealImeconstraints

▪  MulImedia


Bussystems

▪  Complexityiseverincreasing

▪  From5ECUsina1997AudiA6

▪  Toover50ECUsina2007AudiA4▪  Currentmiddleandupperclassvehicles

carry80..100networkedElectronicControlUnits(ECUs)

▪  TradiIonally:onetask⬄oneECU

▪  Newtrends:▪  distribuIonoffuncIonsacrossECUs▪  integraIonofmulIplefuncIonsononeECU


MulIplebussystems

Gateway

CAN1

RearView ClimateA/C

MulIFuncIonDisplay

CAN2

Engine Airbag

Gearbox LIN

Seatoccupancy

Flexray

Radar Video

ESP

MOST

FrontDisplay DVDPlayer

RadioTuner MP3System


Electronicstoday

▪  Upto100ECUs▪  Upto30%ofvaluecreaIon▪  Upto90%ofInnovaIons▪  Upto3kmofwiringforpoweranddata

▪  Upto3800interfacepoints


Electronicstomorrow


IllustraIon©2010ChristophSommer

▪  Datawillleaveconfinesofsinglecar:inter-vehiclecommunicaIon

VisionaryApplicaIons

▪  Laneassistant▪  SimpleroadsidebeaconssupportlanedetecIon

▪  Lateralcollisionavoidance▪  Moreadvancedbeaconsoncarsandmotorcycleshelpmaintainminimum

separaIon

▪  AccidentreporIng▪  BrokendowncarscanautomaIcallysendsimplereporttocentralserver

▪  IntersecIonassistance▪  PairsofcarsautomaIcallycoordinatecomplexmaneuversatintersecIons

▪  CooperaIvedriving▪  ThefutureevoluIonofautonomousdriving:vehiclesacIvelysupporteach

other’srouteplanning,navigaIng,driving


VisionaryApplicaIons

▪  ...andmuch(much)more:Emergency Brake Light Warning, Accident Warning, Emergency Flashlights, Traffic Jam Warning, Weather Warning, Emergency Vehicle, Slow Vehicle, Moving and Static Road Works, Obstacle Warning, Intersection Maneuvering Assistance, Intersection Traffic Lights, Lane Change, Maneuvering Assistance, Longitudinal Maneuvering Assistance, Floating Car Data Collection, Free-Flow Tolling, Breakdown Call, Remote Diagnostics, Theft Detection, Emergency Call, Just-In-Time Repair Notification, Roadside Traffic Camera pull, In-vehicle signing pull, Regional Information pull, Car-specific Software Application Download pull, Electronic Payment pull, Logistic for goods being loaded and unloaded, Traffic Information Service pull, Traffic Information Service push, Electronic Payment push, Roadside Traffic Camera push, In-vehicle signing push, Car specific Software Application Download push, Telemetric Onboard/Off-board Diagnostics, Remote Vehicle Status Control, Fleet Management, Server based navigation, Remote lock-down, Remote entry, Mobile Office, Videophone, Personal Data Synchronization at home, General Map Downloads and Updates, Instant Messaging, General internet services, Internet Audio, continuous feed, Web Browsing, Movie rental, Remote Home Activation/Deactivation pull, Remote Home Control pull, Remote Home Activation/Deactivation push, Remote Home Control push, Voice Chat, Games, Electronic Toll Collection, Parking Unit Fee Payment (drive through payment), Goods and services discovery and payment, Guided Tour, Interactive Lights Dimming, Emergency Traffic Light Pre-emption, Traffic Light Assistant, …


Source:C2CCC,AkIv-AS/VM

ChallengesofcommunicaIon

▪  Basicchallenges▪  Timeliness

▪  Throughput▪  CommunicaIoninvehicles:stresses...

▪  Robustness▪  Cost

▪  CommunicaIonacrossvehicles:alsoneeds...▪  Interoperability▪  Reachability▪  Security▪  Privacy


Part2Car-to-XNetworking

Car-to-X(C2X)communicaIonpaZerns

▪  Vehicle-to-X

(V2X),

▪  Inter-VehicleCommunicaIon

(IVC),

▪  Vehicular

ad-hocnetwork

(VANET),

▪  …


IllustraIon:ETSI

…toinfrastructure

…tocar

…tohome

UseCases


IllustraIon:CVIS

Illustration: CVIS

TaxonomyofUseCases


Vehicle-to-X

Non-Safety

Comfort

ContextualInformaIon Entertainment

TrafficInformaIonSystems

OpImalSpeedAdvisory

CongesIon,Accident

InformaIon

Safety

SituaIonAwareness

AdapIveCruiseControl

BlindSpotWarning

WarningMessages

TrafficLightViolaIon

ElectronicBrakeLight

TaxonomyofUseCases


Vehicle-to-X

Non-Safety

Comfort



OpImalSpeedAdvisory

CongesIon,Accident

InformaIon

Safety

SituaIonAwareness


BlindSpotWarning

WarningMessages


ElectronicBrakeLight

Vehicle-to-X

Non-Safety

Manymessages

Highdatarate

Lowlatencydemands

Lowreliabilitydemands

Safety

Fewmessages

Smallpacketsize

Highlatencydemands

Highreliabilitydemands

TaxonomyofUseCases


Diversityofusecases

Applica@on Distance Time Recipient

Hazardwarning 250m 10s All

LocaIonbasedservice 1..5km Weeks Subscribers

Citywidealarm 20km Hours All

TravelImeinformaIon 5km Minutes All

Filesharing 250mMinutes(Index)Days(Content)

Subscribers(Index)Peers(Content)

InteracIveServices 1..5km Minutes Subscribers


[1]Bai,F.andKrishnamachari,B.,"ExploiIngtheWisdomoftheCrowd:Localized,DistributedInformaIon-CentricVANETs,"IEEECommunicaIonsMagazine,vol.48(5),pp.138-146,May2010

Diversityofrequirements

Applica@on Latency Reliability #Vehicles Area Persistence

InformaIonQuery � � ��

HazardWarning

ACC,el.BrakeLight

CooperaIveAwareness

IntersecIonAssistance

Platooning


[1]T.L.Willke,P.Tientrakool,andN.F.Maxemchuk,"ASurveyofInter-VehicleCommunicaIonProtocolsandTheirApplicaIons,"IEEECommunicaIonsSurveysandTutorials,vol.11(2),pp.3-20,2009




HazardWarning ��

ACC,el.BrakeLight

��

CooperaIveAwareness


Platooning







ACC,el.BrakeLight

��

CooperaIveAwareness


Platooning







ACC,el.BrakeLight

��

CooperaIveAwareness

��


��

Platooning ��



MoIvaIon

▪  1970s:boldideas▪  Veryvisionary,infrastructure-lesssoluIons

▪  Unsupportedbycurrenttechnology

▪  Earlyinterestofgovernmentandindustry▪  workingprototypesin:JapanCACS(1973–1979),

EuropePrometheus(1986–1995),U.S.PATH(1986–1992)▪  Nocommercialsuccess

▪  1980s:paradigmshik▪  FromcompletehighwayautomaIon�driver-advisoryonly▪  Infrastructure-less�infrastructure-assisted▪  chicken-and-eggtypeofstandoff

▪  Newtechnologyre-ignitesinterest▪  latest-generaIoncellularcommunicaIon�early“Car-to-X”systems

▪  e.g.,OnStar(1995),BMWAssist(1999),FleetBoard(2000),andTomTomHDTraffic(2007).▪  SharpincreaseincompuIngpower

▪  Supportsfully-distributed,highlyreacIveadhocsystems


[1]W.Zimdahl,“GuidelinesandsomedevelopmentsforanewmodulardriverinformaIonsystem,”in34thIEEEVehicularTechnologyConference(VTC1984),vol.34.,PiZsburgh,PA:IEEE,May1984,pp.178–182.

Renewedinterestofgovernmentandindustry

▪  NumerousfieldoperaIonaltests▪  simTD(€69M),AkIv(€60M),SmartHighway(€57M),

DriveC2X(€19M),TeleFOT(€15M),SafeTrip(€10M),…

▪  DedicatedspectruminU.S.,Europe,Asia


IllustraIon:FOT-NETWiki

?

MoIvaIon

▪  TradiIonalNetwork▪  ConnecIon:wired▪  Nodes:non-moving

▪  ConfiguraIon:staIc

▪  MobileAdHocNetwork(MANET)▪  ConnecIon:wireless

▪  Nodes:mobile

▪  ConfiguraIon:dynamic

▪  (Infrastructure:opIonal)

▪  VehicularAdHocNetwork(VANET)▪  Not:“MANETonwheels”

▪  Differenttopologydynamics,communicaIonpaZerns,infrastructure,...


[1]M.ScoZCorsonandJosephMacker,"MobileAdhocNetworking(MANET):RouIngProtocolPerformanceIssuesandEvaluaIonConsideraIons,“RFC2501,January1999

IMPORTANTINFORMATION

▪  ThemissedClasswillbegiveninEarlyNovember(Date

TBD)

▪  PleaseSignupwithyoure-mailonthePaper

▪  YouwillbesubscribedtoaGoogleGroup


Freeway�Urban


Freeway�Urban

▪  1Dmobility

▪  BimodalconnecIvity

▪  StableconnecIon(vehiclesonsamelane)

▪  AND▪  unstableconnecIon(vehiclesonoppositelane)

▪  Highspeed▪  …


•  2Dmobility

•  BipolarconnecIvity– Manyneighbors

(whenstanding)

–  OR–  Fewneighbors(whendriving)

•  Obstacles•  …

Levelsofinfrastructuresupport

▪  PureadhoccommunicaIon

▪  StaIonarySupportUnits(SSU)▪  Radio-equippedautonomouscomputer

▪  InexhausIblestorage,energysupply▪  KnownposiIon,highreliability

▪  RoadsideUnits(RSU)▪  SSUplus…▪  EthernetNIC,UMTSradio,...

▪  ConnectedtootherRSUs

▪  TrafficInformaIonCenter(TIC)▪  CentralserverconnectedtoRSUs


Infrastructure�NoInfrastructureHERE!!!!!!!!!

▪  CentralcoordinaIon▪  Resourcemanagement

▪  Security▪  Highlatency▪  Highloadoncorenetwork

▪  …


•  Selforganizingsystem

–  Channelaccess–  AuthenIcaIon

•  Lowlatency•  Lowdatarate•  …

Source: AKTIV CoCar

Convergencetowardsheterogeneousapproaches

▪  SamesystemneedstoworkinmulIpleenvironments

▪  Vehiclestartstodriveincitywithinfrastructuresupport▪  ConInuesdrivingonfreeway(sIllwithinfrastructuresupport)▪  Losesinfrastructuresupportwhenturningontolocalhighway▪  Finishesdrivingincitywithoutinfrastructuresupport


AdopIon

▪  Prognosis(ofproviders!)inGermanyandtheU.S.

▪  14..15yearsto100%marketpenetraIon

▪  ComparetonavigaIonsystemsinGermancars

▪  13yearsto14%marketpenetraIon

▪  And:itisveryeasytoretrofitasatnav!


[1]Bai,F.andKrishnamachari,B.,"ExploiIngtheWisdomoftheCrowd:Localized,DistributedInformaIon-CentricVANETs,"IEEECommunicaIonsMagazine,vol.48(5),pp.138-146,May2010

[2]UlrichDietz(ed.),“CoCarFeasibilityStudy:Technology,BusinessandDisseminaIon,”CoCarConsorIum,PublicReport,May2009.

[3]VerbandderAutomobilindustriee.V.,“Auto2007–JahresberichtdesVerbandsderAutomobilindustrie(VDA),“,July2007.

ChallengesofC2XcommunicaIon


•  HighlyvaryingchannelcondiIons•  HighcongesIon,contenIon,interference•  Tightlylimitedchannelcapacity

CommunicaIon

•  UnidirecIonalLinks• MulI-Radio/MulI-Network

•  HeterogeneousequipmentNetworking

•  Highlydynamictopology

•  But:predictablemobility

•  HeterogeneousenvironmentMobility

•  No(ornoreliable)uplinktocentralinfrastructure•  Ensuringprivacy•  Heterogeneoususerbase

Security

Technology


CommunicaIonparadigmsandmedia

WirelessCommunicaIonTechnologies

Infrastructure-based

Broadcast

FMRadio,DAB/DVB,

…

Cellular

GSM

2GCellular

UMTS3G

Cellular

LTE/WiMAX

4GCell.

Infrastructureless

ShortRange

Millimeter,Infrared,Visible

802.15.1Bluetooth

802.15.4ZigBee

MediumRange

802.11Wi-Fi

DSRC/WAVE


[1]Dar,K.etal.,"WirelessCommunicaIonTechnologiesforITSApplicaIons,"IEEECommunicaIonsMagazine,vol.48(5),pp.156-162,May2010

BroadcastMedia

▪  TrafficMessageChannel(TMC)

▪  CentralmanagementoftrafficinformaIon

▪  Datasourcesarevaried▪  Federal/local/citypolice,roadoperator,radio,…

▪  TransmissioninRDSchannelofFMradio

▪  BPSKmodulatedsignalat57KHz,datarate1.2kBit/s

▪  RDSgroupidenIfier8A(TMC),approx.10bulleInsperminute


[1]ISO62106,„SpecificaIonoftheradiodatasystem(RDS)forVHF/FMsoundbroadcasInginthefrequencyrangefrom87,5to108,0MHz“

f (in KHz) l+r l-r l-r

0 15 19 23 38 53 57

BroadcastMedia

▪  TrafficMessageChannel(TMC)▪  Contents(ALERT-Ccoded):

▪  Validityperiod▪  Re-rouIngrequired?▪  North-eastorsouth-west?▪  SpaIalextent▪  Codeineventtable

▪  InternaIonal▪  CodeinlocaIontable

▪  Country/regionspecific▪  Mustbeinstalledinend

device

▪  No(real)securitymeasures


[1]ISO14819-1,„TrafficandTravellerInformaIon(TTI)-TTImessagesviatrafficmessagecoding-Part1:CodingprotocolforRadioDataSystem(RDS-TMC)usingALERT-C“

[2]ISO14819-2,„TrafficandTravellerInformaIon(TTI)-TTImessagesviatrafficmessagecoding-Part2:EventandinformaIoncodesforRadioData

System-TrafficMessageChannel(RDS-TMC)“

101 Standingtraffic(generic)

102 1kmofstandingtraffic

103 2kmofstandingtraffic

394 Brokendowntruck

1478 Terroristincident

1 Deutschland

264 Bayern

12579 A8AnschlussstelleIrschenberg

BroadcastMedia

▪  TrafficMessageChannel(TMC)▪  Regionalvalueaddedservices

▪  NavteqTrafficRDS(U.S.),trafficmaster(UK),V-Trafic(France)

▪  Ex:TMCpro▪  PrivateserviceofNavteqServicesGmbH

▪  Financedbyper-decoderlicensefee▪  DatacollecIonandprocessing

▪  FullyautomaIc

▪  Deploymentof4000+sensorsonoverpasses

▪  UseoffloaIngcardata▪  DownlinkfromtrafficinformaIoncenters

▪  EventpredicIon▪  Expertsystems,neuronalnetworks

▪  Earlywarningsofpredictedevents▪  Restrictedtomajorroads


BroadcastMedia

▪  TransportProtocolExpertsGroup(TPEG)▪  PlannedsuccessorofRDS-TMC/Alert-C

▪  PublishedApril2000▪  Principles:

▪  Extensibility▪  Mediaindependence

▪  Goals:▪  Builtfor“DigitalAudioBroadcast”(DAB)▪  UnidirecIonal,byteorientedstream

▪  Modularconcept

▪  Hierarchicalapproach▪  Integratedsecurity


[1]ISO18234-x,„TrafficandTravelInformaIon(TTI)—TTIviaTransportProtocolExpertsGroup(TPEG)data-streams“

BroadcastMedia

▪  TransportProtocolExpertsGroup(TPEG)▪  InformaIontypesdefinedby“TPEGApplicaIons”

▪  RTM-RoadTrafficMessage

▪  PTI-PublicTransportInformaIon▪  PKI-ParkingInformaIon

▪  CTT-CongesIonandTravel-Time

▪  TEC-TrafficEventCompact

▪  WEA-WeatherinformaIonfortravelers

▪  Modularconcept:


TransportProtocolExpertsGroup(TPEG)


[1]ISO24530-x,„TrafficandTravelInformaIon(TTI)—TTIviaTransportProtocolExpertsGroup(TPEG)ExtensibleMarkupLanguage(XML)“

▪  tpegML:XMLvariantofregular(binary)TPEG

TransportProtocolExpertsGroup(TPEG)

▪  Hybridapproachtogeo-referencing:oneormoreof

▪  WGS84basedcoordinates

▪  ILOC(IntersecIonLocaIon)▪  Normalized,shortenedtextualrepresentaIonof

streetnamesintersecIngatdesiredpoint

▪  Humanreadableplaintext

▪  CodeinhierarchicallocaIontable


CommunicaIonparadigmsandmedia

WirelessCommunicaIonTechnologies

Infrastructure-based

Broadcast

FMRadio,DAB/DVB,

…

Cellular

GSM

2GCellular

UMTS3G

Cellular

LTE/WiMAX

4GCell.

Infrastructureless

ShortRange

Millimeter,Infrared,Visible

802.15.1Bluetooth

802.15.4ZigBee

MediumRange

802.11Wi-Fi

DSRC/WAVE


[1]Dar,K.etal.,"WirelessCommunicaIonTechnologiesforITSApplicaIons,"IEEECommunicaIonsMagazine,vol.48(5),pp.156-162,May2010

CellularNetworks

▪  Concept▪  Divideworldintocells,eachservedbybasestaIon▪  Allows,e.g.,frequencyreuseinFDMA

f0

f1

f2

f0

f2

f1

f2

f0

f1

f0

f1

f2

f0

f1

f2

f0

f1

f2

f0

f2

f0

f2

f0

f2

f0

f1

f2

f0


Concept

▪  Stricthierarchyofnetworkcomponents

UE

Core Network

RNC

Cell

NodeB

Cell Cell Cell Cell

NodeB

Cell

RNC

Cell

NodeB

Cell Cell Cell Cell

NodeB

Cell


CellularNetworks

▪  CanUMTSsupportCar-to-XcommunicaIon?▪  Ex:UTRAFDDRelease99(W-CDMA)

▪  SpeedofvehiclesnotalimiIngfactor▪  FieldoperaIonaltestsat290km/hshowsignaldropsonlyakersuddenbraking(�handoverpredicIonfailures)

▪  OpenquesIons▪  Delay▪  Capacity

▪  ChannelsinUMTS▪  Sharedchannels

▪  E.g.RandomAccessChannel(RACH),uplinkandForwardAccessChannel(FACH),downlink

▪  Dedicatedchannels▪  E.g.DedicatedTransportChannel(DCH),up-/downlink


CellularNetworks

▪  FACH▪  TimeslotsmanagedbybasestaIon

▪  Delayontheorderof10msper40ByteandUE

▪  Capacityseverelylimited(innon-mulIcastnetworks)

▪  NeedtoknowcurrentcellofUE▪  RACH

▪  SloZedALOHA–randomaccessbyUEs▪  PowerrampingwithAcquisiIonIndicaIon

▪  Delayapprox.50msper60ByteandUE

▪  MassiveinterferencewithotherUEs


CellularNetworks

▪  DCH▪  Delay:approx.250ms/2s/10sforchannelestablishment

▪  Dependsonhowfine-grainedUEposiIonisknown▪  MaintainingaDCHisexpensive

▪  Closed-LoopPowerControl(nointerferenceofotherUEs)▪  Handoverbetweencells▪  ...

▪  Upperlimitofapprox.100UEs


CellularNetworks

▪  So:canUMTSsupportCar-to-XcommunicaIon?

▪  AtlowmarketpenetraIon:yes

▪  Eventually:▪  Needtoinvestinmuchsmallercells(e.g.,alongfreeways)

▪  NeedtoimplementmulIcastfuncIonality(MBMS)

▪  MainusecaseforUMTS:centralizedservices

▪  Ex.:GoogleMapsTraffic

▪  CollectinformaIonfromUMTSdevices

▪  Storageofdataoncentralserver▪  DisseminaIonviaInternet(�idealforcellularnetworks)


IEEE802.11p

▪  IEEE802.11{a,b,g,n}forCar-to-XcommunicaIon?▪  Can’tbeininfrastructuremodeandadhocmodeatthesameIme

▪  SwitchingImeconsuming

▪  AssociaIonImeconsuming

▪  Nointegralwithin-networksecurity▪  (Massively)sharedspectrum(�ISM)

▪  NointegralQoS▪  MulI-patheffectsreducerangeandspeed


IEEE802.11p

▪  IEEE802.11p▪  PHYlayermostlyidenIcaltoIEEE802.11a

▪  VariantwithOFDMand16QAM

▪  Higherdemandsontolerances

▪  ReducIonofintersymbolinterferencebecauseofmulI-patheffects

▪  DoubleImingparameters

▪  Channelbandwidthdownto10MHz(from20MHz)

▪  Throughputdownto3...27Mbit/s(from6...54Mbit/s)

▪  Rangeupto1000m,speedupto200km/h

▪  MAClayerofIEEE802.11aplusextensions▪  RandomMACAddress

▪  QoS(EDCApriorityaccess,cf.IEEE802.11e,...)▪  MulI-FrequencyandMulI-RadiocapabiliIes

▪  NewAdHocmode

▪  ...


IEEE802.11p

▪  ClassicIEEE802.11BasicServiceSet(BSS)▪  Dividesnetworksintologicalunits

▪  Nodesbelongto(exactlyone)BSS▪  PacketscontainBSSID▪  Nodesignorepacketsfrom“foreign”BSSs

▪  ExcepIon:Wildcard-BSSID(-1)forprobes

▪  Adhocnetworksemulateinfrastructuremode

▪  JoiningaBSS▪  AccessPointsendsbeacon▪  AuthenIcaIondialogue▪  AssociaIondialogue▪  NodehasjoinedBSS

BSS SSID “A”

BSS SSID “B”

BSS SSID “C”


IEEE802.11p

▪  New:802.11WAVEMode

▪  Defaultmodeofnodesin

WAVE

▪  Nodesmayalwaysuse

WildcardBSSinpackets

▪  NodeswillalwaysreceiveWildcardBSSpackets

▪  MayjoinBSSandsIlluse

WildcardBSS


BSS SSID “A”

BSS SSID “B”

IEEE802.11p

▪  New:802.11WAVEBSS▪  NostrictseparaIonbetweenHostandAccessPoint(AP)▪  Instead,looseclassificaIonaccordingto:

▪  Equipment:RoadsideUnit(RSU)/On-BoardUnit(OBU)

▪  Roleindataexchange:Provider/User▪  NotechnicaldifferencebetweenProviderandUser▪  ProvidersendsOn-DemandBeacon

▪  Analogoustostandard802.11-Beacon▪  BeaconcontainsallinformaIonandparametersneededtojoin

▪  Userconfigureslowerlayersaccordingly▪  Startsusingprovidedservice▪  NoaddiIonalexchangeofdataneeded

▪  BSSmembershipnowonlyimplied▪  BSSconInuestoexistevenakerproviderleaves


WAVEBSSInternalstatemachine

▪  NodewillnotjoinmorethanoneWAVEBSS


[1]IEEEVehicularTechnologySociety,"IEEE1609.3(NetworkingServices),"IEEEStd,April,2007

WAVE Mode only

in WAVE BSS

§ ApplicaIonlayerstartsnewservice§ On-Demand-Beaconreceived

§ ApplicaIonlayerstopsservice§ Timeout

§ Securityerror

§ ApplicaIonlayerstartsnew,higherpriorityservice§ On-Demand-Beaconforknown,higherpriorityservicerecvd

IEEE802.11p

▪  IEEE802.11DistributedCoordinaIonFuncIon(DCF)▪  aka“ContenIonPeriod”

▪  PriorityaccessviaSIFS(ACK,CTS,...)andDIFS(payload)▪  WaitunIlmediumhasbeenfreeforduraIonofDIFS

▪  Ifmediumbusy,waitunIlidle,thenwaitDIFSplusrandombackoffIme

Mediumbusy TXstarts

SIFS, PIFS, DIFS

Time slots in contention period


IEEE802.11p

▪  IEEE802.11DistributedCoordinaIonFuncIon(DCF)▪  Backoffif

a)  Nodeisreadytosendandchannelbecomesbusy

b)  Ahigherpriorityqueue(�nextslides)becomesreadytosend

c)  Unicasttransmissionfailed(noACK)

d)  Transmissioncompletedsuccessfully

▪  Backoff:Randomslotcountfrominterval[0,CW]

▪  Decrementbyoneakerchannelwasidleforoneslot(onlyincontenIonperiod)

▪  Incasesb)andc),doubleCW(butnolargerthanCWmax)

▪  Incased),setCWtoCWmin


IEEE802.11p

▪  QoSin802.11p(HCF)▪  cf.IEEE802.11eEDCA▪  DIFS�AIFS(ArbitraIonInter-FrameSpace)

▪  DCF�EDCA(EnhancedDistributedChannelAccess)

▪  Classifyuserdatainto4ACs(AccessCategories)▪  AC0(lowestpriority)▪  …▪  AC3(highestpriority)

▪  EachACshasdifferent...▪  CWmin,CWmax,AIFS,TXOPlimit(max.conInuoustransmissions)

▪  ManagementdatausesDIFS(notAIFS)


IEEE802.11p

▪  QoSin802.11p(HCF)▪  Map8userprioriIes�4accesscategories�4queues

▪  Queuescompeteindependentlyformediumaccess

AC0

AC1

AC2

AC3

virtu

al c

ollis

ion


IEEE802.11p

▪  QoSin802.11p(HCF)▪  ParameterizaIon

▪  SamplequeueconfiguraIon

Parameter Value

SlotTime 13µs

SIFS 32µs

CWmin 15

CWmax 1023

Bandwidth 3..27mbit/s

Parameter AC_BK AC_BE AC_VI AC_VO

CWmin CWmin CWmin (CWmin+1)/2-1 (CWmin+1)/4-1

CWmax CWmax CWmax CWmin (CWmin+1)/2-1

AIFSn 9 6 3 2


AC_VO AC_VI AC_BE AC_BK

ChannelAccess

Backoff:0 0 0 0

IEEE802.11p



Backoff:0 0 0 0

Channelbusy?

StartContenIon

WaitforIdle

IEEE802.11p

ChannelAccess



0 0 0

Backoff0?

WaitAIFS(SIFS+AIFSn*Slotlen)

Waitforbackoff=0

Backoff:0

IEEE802.11p

ChannelAccess


Backoff:0


Backoff:2 0 0 0

TransmissionOver

PostTransmitBackoff

IEEE802.11p

ChannelAccess


2


Backoff:2 0 0 0

AC_VIQueuereadytosend…waitAIFS Backoff

Chbecomesbusy

IEEE802.11p

ChannelAccess


Backoff:2 21


Backoff:1 0 0Channelidle

Channelbusy

[SlotImepassed]/DecrementBackoff

Channelstatechanges

Backoff:0 0

IEEE802.11p

ChannelAccess


3Backoff:0 0


0 0

Queuereadytosend

InternalContenIon

Backoff

Higherpriority

queueready

IEEE802.11p

ChannelAccess


IEEE802.11p

▪  QoSinWAVE▪  meanwaiIngImeforchannelaccess,given

sampleconfiguraIon(andTXOPLimit=0�singlepacket)

▪  whenchannelidle:

▪  whenchannelbusy:


FigureSource:Eichler,S.,"PerformanceevaluaIonoftheIEEE802.11pWAVEcommunicaIonstandard,"Proceedingsof66thIEEEVehicularTechnologyConference(VTC2007-Fall),BalImore,USA,October2007,pp.2199-2203

AC CWmin CWmax AIFS TXOP tw(inμs)

0 15 1023 9 0 264

1 7 15 6 0 152

2 3 7 3 0 72

3 3 7 2 0 56

UMTS/LTEvs.802.11p

▪  ProsofUMTS/LTE+  Easyprovisionofcentralizedservices+  QuickdisseminaIonofinformaIoninwholenetwork

+  Pre-deployedinfrastructure+  EasymigraIonto(andintegraIoninto)smartphones

▪  ConsofUMTS/LTE-  Highshortrangelatencies(mightbetoohighforsafety)

-  Networkneedsfurtherupgrades(smallercells,mulIcastservice)

-  Highdependenceonnetworkoperator-  Highloadincorenetwork,evenforlocalcommunicaIon


UMTS/LTEvs.IEEE802.11p

▪  Prosof802.11p/Adhoc+  Smallestpossiblelatency

+  CansustainoperaIonwithoutnetworkoperator/provider+  Networkloadhighlylocalized+  BeZerprivacy(�laterslides)

▪  Consof802.11p/Adhoc-  Needsgatewayforprovisionofcentralservices(e.g.,RSU)

-  Nopre-deployedhardware,andhardwareissIllexpensive

▪  ThesoluIon?▪  hybridsystems:

deploybothtechnologiestovehiclesandroad,decidedependingonapplicaIonandinfrastructureavailability


HigherLayerStandards:CALM

▪  Mixed-mediacommunicaIon

▪  „CommunicaIonsaccessforlandmobiles“

▪  ISOTC204WorkingGroup16

▪  IniIaIvetotransparentlyusebestpossiblemedium

▪  Integrates:▪  GPRS,UMTS,WiMAX

▪  Infrared,MillimeterWave

▪  Wi-Fi,WAVE

▪  UnidirecIonaldatasources(DAB,GPS,...)▪  WPANs(BlueT,W-USB,...)

▪  AutomoIvebussystems(CAN,Ethernet,...)


[1]ISO21210,“Intelligenttransportsystems--CommunicaIonsaccessforlandmobiles(CALM)--IPv6Networking“

HigherLayerStandardsforIEEE802.11p

▪  Channelmanagement▪  Dedicatedfrequencybandat5.9GHzallocatedtoWAVE

▪  ExclusiveforV2VundV2IcommunicaIon

▪  Nolicensecost,butstrictrules▪  1999:FCCreserves7channelsof10MHz(“U.S.DSRC”)

▪  2reservedchannels,1+4channelsforapplicaIons▪  ETSIEuropereserves5channelsof10MHz


[1]ETSIES202663V1.1.0(2010-01):IntelligentTransportSystems(ITS);EuropeanprofilestandardforthephysicalandmediumaccesscontrollayerofIntelligentTransportSystemsoperaInginthe5GHzfrequencyband

U.S.allocaIon …

CriIcalSafetyof

LifeSCH SCH

ControlChannel(CCH)

SCH SCH

Hi-PowerPublicSafety

…

EuropeanallocaIon SCH SCH SCH SCH CCH SCH SCH

IEEEChannel 172 174 176 178 180 182 184

Centerfrequency 5.860GHz 5.870GHz 5.880GHz 5.890GHz 5.900GHz 5.910GHz 5.920GHz

HigherLayerStandardsforIEEE802.11p

▪  Needforhigherlayerstandards▪  Unifiedmessageformat

▪  UnifiedinterfacestoapplicaIonlayer

▪  U.S.▪  IEEE1609.*▪  WAVE(„WirelessAccessinVehicularEnvironments“)

▪  Europe▪  ETSI▪  ITSG5(“IntelligentTransportaIonSystems”)


IEEE1609.*upperlayers(buildingonIEEE802.11p)

▪  IEEE1609.2:Security

▪  IEEE1609.3:Networkservices

▪  IEEE1609.4:Channelmgmt.

▪  IEEE1609.11:ApplicaIon“electronicpayment”


[1]Jiang,D.andDelgrossi,L.,"IEEE802.11p:TowardsaninternaIonalstandardforwirelessaccessinvehicularenvironments,"Proceedingsof67thIEEEVehicularTechnologyConference(VTC2008-Spring),MarinaBay,Singapore,May2008

[2]Uzcátegui,RobertoA.andAcosta-Marum,Guillermo,"WAVE:ATutorial,"IEEECommunicaIonsMagazine,vol.47(5),pp.126-133,May2009

TCP/UDP

WAVEPHY

ChannelCoordinaIon,WAVEMAC

IPv6WSMP

Management

Security

LLC

802.

11p 16

09.4

16

09.3

1609

.2

WAVEPHY

IEEE1609

▪  Channelmanagement▪  WAVEallowsforbothsingleradiodevices&mulIradiodevices

▪  DedicatedControlChannel(CCH)formgmtandsafetymessages�singleradiodevicesneedtoperiodicallylistentoCCH

▪  Timeslots▪  SynchronizaIonenvisionedviaGPSreceiverclock▪  Standardvalue:100mssyncinterval(with50msonCCH)▪  ShortguardintervalatstartofImeslot

▪  Duringguard,mediumisconsideredbusy(�backoff)

CCH interval

CCH interval

“SCH” interval

“SCH” interval

[1] IEEE Vehicular Technology Society, "IEEE 1609.4 (Multi-channel Operation)," IEEE Std, November, 2006

t = n × 1s


IEEE1609

▪  Packettransmission▪  SortintoACqueue,basedonWSMP(orIPv6)EtherTypefield,desInaIonchannel,anduserpriority

▪  Switchtodesiredchannel,setupPHYpoweranddatarate

▪  Startmediumaccess

CC

H

SC

H

AC0

AC1

AC2

AC3 virt.

Col

lisio

n

AC0

AC1

AC2

AC3 virt.

Col

lisio

n

Cha

nnel

Rou

ter

Cha

nnel

sel

ectio

n an

d se

tup

Cha

nnel

acc

ess


IEEE1609

▪  Channelmanagement

▪  ControlChannel(CCH):▪  DefaultchanneluponiniIalizaIon▪  WAVEserviceadverIsements(WSA),

WAVEshortmessages(WSM)

▪  Channelparameterstakefixedvalues

▪  ServiceChannel(SCH):▪  OnlyakerjoiningWAVEBSS

▪  WAVEshortmessages(WSM),

IPdatatraffic(IPv6)

▪  Channelparameterscanbechangedasneeded


IEEE1609

▪  WAVEserviceadverIsement(WSA)▪  BroadcastonControlChannel(CCH)▪  IdenIfiesWAVEBSSsonServiceChannels(SCHs)

▪  CanbesentatarbitraryImes,byarbitrarynodes

▪  OnlypossibilitytomakeothersawareofdatabeingsentonSCHs,aswellastherequiredchannelparameterstodecodethem

NodeA NodeB WSA (on CCH)

Data (on S-CH)

Data (on S-CH)


IEEE1609

▪  WAVEserviceadverIsement(WSA)▪  WAVEVersion(=0)

▪  ProviderServiceTable(PST)▪  n×ProviderServiceInfo

▪  ProviderServiceIdenIfier(PSID,max.0x7FFFFFFF)

▪  ProviderServiceContext(PSC,max.31chars)

▪  ApplicaIonpriority(maxpriority:63)▪  (opt.:IPv6addressandport,ifIPservice)▪  (opt.:SourceMACaddress,ifsender≠datasource)

▪  Channelnumber(max.200)

▪  1..n×ChannelInfo(foreachchannelusedinPSTtable)▪  Datarate(fixedorminimumvalue)▪  Transmissionpower(fixedormaximumvalue)

▪  (opt.:WAVERouIngAnnouncement)

[1] IEEE Vehicular Technology Society, "IEEE 1609.3 (Networking Services)," IEEE Std, April, 2007


WAVEserviceadverIsement(WSA)

0x0000000 system 0x000000D private 0x0000001 automaIc-fee-collecIon 0x000000E mulI-purpose-payment 0x0000002 freight-fleet-management 0x000000F dsrc-resource-manager 0x0000003 public-transport 0x0000010 aker-thek-systems 0x0000004 traffic-traveler-informaIon 0x0000011 cruise-assist-highway-system 0x0000005 traffic-control 0x0000012 mulI-purpose-informaIonsystem 0x0000006 parking-management 0x0000013 public-safety 0x0000007 geographic-road-database 0x0000014 vehicle-safety 0x0000008 medium-range-preinformaIon 0x0000015 general-purpose-internet-access 0x0000009 man-machine-interface 0x0000016 onboarddiagnosIcs 0x000000A intersystem-interface 0x0000017 securitymanager 0x000000B automaIc-vehicle-idenIficaIon 0x0000018 signedWSA 0x000000C emergency-warning 0x0000019 ACI


▪  ProviderServiceIdenIfier(PSID)definedinIEEEStd1609.3-2007

IEEE1609

▪  WAVEShortMessage(WSM)

▪  Header(11Byte)▪  Version(=0)▪  Contenttype:plain,signed,encrypted▪  Channelnumber(max.200)

▪  Datarate▪  Transmissionpower

▪  ProviderServiceIdenIfier(Servicetype,max.0x7FFFFFFF)

▪  Length(max.typ.1400Bytes)

▪  Payload


IEEE1609

▪  IPtraffic(UDP/IPv6orTCP/IPv6)▪  Header(40+nByte)

▪  Version▪  TrafficClass

▪  FlowLabel▪  Length▪  NextHeader▪  HopLimit

▪  Sourceaddress,desInaIonaddress▪  (opt.:ExtensionHeaders)

▪  Payload

▪  NoIPv6-Neighbor-Discovery(Highoverhead)▪  AllOBUslistentohostmulIcastaddress,

allRSUslistentoroutermulIcastaddress


IEEE1609

▪  Channelqualitymonitoring▪  NodesstorereceivedWSAs,knowSCHoccupancy

▪  ReceivedChannelPowerIndicator(RCPI)polling▪  NodescansendRCPIrequests▪  ReceiveranswerswithReceivedSignalStrength(RSS)ofpacket

▪  TransmitPowerControl(TPC)▪  NodescansendTPCrequests▪  ReceiveranswerswithcurrenttransmissionpowerandLQI

▪  DynamicFrequencySelecIon(DFS)▪  Nodesmonitortransmissionsonchannel(acIvelyandpassively)

▪  Ifhigherprioritythirdpartyuse(e.g.,RADAR)isdetected,nodesceasetransmiçng


IEEE1609

▪  SecurityinWAVE▪  NatureofWAVEmessagesmandatestrustbetweennodes

▪  Ex:Greenwaveforemergencyvehicles

▪  SecurityisbuiltintoWAVE(IEEE1609.2)

▪  WAVEcantransparentlysign,verify,encrypt/decryptmessageswhensendingandreceiving

▪  Ex:WSAàSecureWSA

▪  AuthorizaIonofmessagesneeded▪  Byrole:CA,CRL-Signer,RSU,PublicSafetyOBU(PSOBU),OBU▪  ByapplicaIonclass(PSID)and/orinstance(PSC)▪  ByapplicaIonpriority▪  BylocaIon▪  ByIme

[1] IEEE Vehicular Technology Society, "IEEE 1609.2 (Security Services)," IEEE Std, July, 2006


IEEE1609

▪  Securityconcepts▪  Basicsecuritygoals

▪  Integrity,ConfidenIality,AuthenIcity▪  Non-RepudiaIon

▪  Mechanisms▪  SymmetricencrypIon

▪  SecretKeyCryptography▪  Ex:Caesarcipher,Enigma,AES

▪  AsymmetricencrypIon▪  PublicKeyCryptography▪  Ex:RSA,ElGamal,ECC

▪  (cryptographic)hashing▪  Ex:MD5,SHA-1

m E(m)

K

K

m E(m)

K+

K-

m h(m)


IEEE1609

▪  AsymmetricCryptography▪  ReliesoncertainmathemaIcalproceduresbeingveryhardtoinvert▪  Product⬄factorizaIon(RSA)

▪  Nthpower⬄Nthlogarithm(DH,ElGamal)

▪  Twokeys:PublicKey(K+),PrivateKey(K-)

▪  CanbeusedinbothdirecIons▪  EncrypIon:E(K+,m),Signing:E(K-,h(m))

▪  Drawback:▪  Muchslowerthansymmetriccryptography

m

E(K-,m) K+

E(K+,m)

K-

K-

K+


IEEE1609

▪  AsymmetricCryptographyExample:RSA▪  Chosetwoprimes:q,pwithq!=p

▪  Calculaten=p·q▪  Calculateφ(n)=(p−1)·(q−1) φ(x)givesnumberof(smaller)co-primesforx.

Basedonφ(a·b)=φ(a)·φ(b)·(d/φ(d))withd=gcd(a,b)

Ifxisprime,thisisx−1.

▪  Chooseeco-primetoφ(n)with1<e<φ(n)

▪  CalculatedusingEEA,sothate·dmodφ(n)=1

▪  PublicKey:K+={e,n},PrivateKey:K-={d,n}.▪  En/DecrypIon: Memodn=C

Cdmodn=M


IEEE1609

▪  CerIficates▪  EncrypIonisuselesswithoutauthenIcaIon

▪  Alice⬄Eve⬄Bob

▪  EvecanpretendtobeAlice,replaceK+AwithownkeyK

+E

▪  SoluIon:useTrustedThirdParty(TTP)andcerIficates▪  TTPsigns(Name,Key)tuple,vouchesforvalidityandauthorizaIon:“AlicehasPublicKeyK+A,mayparIcipateasOBUunIl2019”

▪  not:“whoeversendsthispacketisAlice”▪  not:“whoeversendsthispackethasPublicKeyK+A”

▪  SendK+AtogetherwithcerIficatevouchingfortuple


IEEE1609

▪  ImplementaIoninWAVE▪  CerIficatesignaturechains

▪  RootcerIficate�cerIficate�cerIficate�payload▪  RootcerIficatespre-installedwithsystem▪  OthercerIficatescannotbeassumedtobepresent

▪  NodesmustdownloadcerIficatesalongwithsignedmessage▪  IncludechainofcerIficates▪  …orSHA-256offirstcerIficateinchain(ifreceivercanbeassumedtohaveallrequiredcerIficates)


IEEE1609

▪  ImplementaIoninWAVE▪  X.509formatstoolarge�newWAVEcerIficateformat

▪  Version▪  CerIficate

▪  Role(RSU,PSOBU,OBU,...)▪  IdenIty(dependentonrole)▪  RestricIons(byapplicaIonclass,priority,locaIon,…)▪  ExpiraIondate▪  ResponsibleCRL▪  PublicKeys

▪  Signature

▪  New:RestricIonbylocaIone.g.:none,inheritedfromCA,circle,polygon,setofrectangles

▪  PublicKeyalgorithms(moIvatedbykeysize):ECDSA(NISTp224),ECDSA(NISTp256),ECIES(NISTp256),...


CompletepacketformatofaWSM:


Length Field

1 WSMversion

1 SecurityType=signed(1)

1 ChannelNumber

1 DataRate

1 TxPwr_Level

4 PSID

1 PSCFieldLength

7 PSC

2 WSMLength

1

WSMData

signertype=cerIficate

125 cerIficate

2

unsigned_wsm

messageflags

32 applicaIon_data

8 transmission_Ime

4

transmission_locaIon

laItude

4 longitude

3 elevaIon_and_confidence

28signature ecdsa_signature

r

28 s

� next slide

Ex: Signed WSM of an OBU, Certificate issuer is known

CompletepacketformatofaWSM(cerIficatepart):


Length Field

1 cerIficate_version=1

1

unsigned_cerIficate

subject_type=obu_idenIfied

8 signer_id

1

scope

subject_namelength

8 subject_name

2applicaIons

lengthofapplicaIonsfield

1 type=from_issuer

4 expiraIon

4 crl_series

1

public_key

lengthofpublickeyfield

1 algorithm=ecdsanistp224..

29 public_key point

32signature ecdsa_signature

r

32 s

DrawbacksofChannelSwitching

▪  1)Goodput▪  UserdatamustonlybesentonSCH,i.e.duringSCHinterval

�goodputcutinhalf


Picturesource:DavidEckhoff,ChristophSommerandFalkoDressler,"OntheNecessityofAccurateIEEE802.11pModelsforIVCProtocolSimulaIon,"Proceedingsof75thIEEEVehicularTechnologyConference(VTC2012-Spring),Yokohama,Japan,May2012.

Goo

dput

>

Road traffic density >


▪  2)Latency▪  UserdatageneratedduringCCHintervalisdelayedunIlSCHintv.




▪  3)Collisions▪  DelayofdatatonextstartofSCHinterval�increasedfrequencyofchannelaccessesdirectlyakerswitch

�increasedcollisions,packetloss



Msggenerated

Msgsent

ETSIITSG5

▪  MoIvaIon

▪  EuropeanstandardizaIoneffortbasedonIEEE802.11p▪  StandardizaIontoincludelessonslearnedfromWAVE

▪  DifferentinstrumentaIonoflowerlayers

▪  Differentupperlayerprotocols▪  Fine-grainedservicechannelassignment

▪  ITS-G5A(safety)▪  IST-G5B(nonsafety)


ETSIITSG5

▪  Protocolstack▪  PHYandMACbasedonIEEE802.11p

▪  Mostprominentchange:

crosslayerDecentralizedCongesIonControl(DCC)


AccessLayer

Networking&TransportLayer

FaciliIesLayer

ApplicaIonsLayer

Management

DCC

Security

ETSIITSG5

▪  Channelmanagement▪  MulIradio,mulIantennasystem

▪  NoalternaIngaccess�CircumventsproblemswithsynchronizaIon�NoreducIoningoodput

▪  DirectresultofexperienceswithWAVE

▪  OneradiotunedtoCCH▪  ServiceAnnouncementMessage(SAM)

▪  Periodic:CooperaIveAwarenessMessages(CAM)

▪  Eventbased:DecentralizedEnvironmentNoIficaIonMessage(DENM)

▪  Addl.radiotunedtoSCH▪  Userdata


ETSIITSG5

▪  Mediumaccess▪  SeparateEDCAsystems

▪  Differentdefaultparameters:

▪  Conten%onWindow–lessdistancetolowerpriorityqueues�lessstarvaIonoflowerpriorityqueues

Parameter AC_BK AC_BE AC_VI AC_VO

CWmin CWmin (CWmin+1)/2-1 (CWmin+1)/4-1 (CWmin+1)/4-1

CWmax Cwmax CWmax (CWmin+1)/2-1 (CWmin+1)/2-1

AIFSn 9 6 3 2


ETSIITSG5

▪  DCC▪  CorefeatureofETSIITSG5▪  AdapIveparameterizaIontoavoidoverload

▪  ConfigurableparametersperAC:▪  TXpower▪  Minimumpacketinterval

▪  SensiIvityofCCA(ClearChannelAssessment)

▪  Datarate▪  Statemachinedetermineswhichparametersareselected;availablestates:

▪  Relaxed▪  AcIve(mulIplesubstates)

▪  RestricIve


▪  DCC▪  StatemachineforControlChannel:

▪  min/maxChannelLoad(x):recordfracIonofImein[tnow-x..tnow]thatchannelwassensedbusysubdivideintervalintoequalparts(e.g.50ms),takemin/max

▪  Channelbusy⬄measuredreceivedpower(signalornoise)aboveconfiguredsensibility

ETSIITSG5


relaxed acIve restricIve

minChannelLoad(1s) >= 15% minChannelLoad(1s) >= 40%

maxChannelLoad(5s) < 15% maxChannelLoad(5s) < 40%

ETSIITSG5

▪  DCC▪  SelecIonofparameterswhenchangingstates

▪  ServiceChannel:AcIvestatehasfoursub-configuraIons▪  ControlChannel:SingleconfiguraIonforacIvestate▪  Example(“ref”:Valueremainsunchanged)

StateRelaxed AcIve RestricIve

AC_VI AC_VO AC_BE AC_BK

TXpower 33dBm ref 25dBm 20dBm 15dBm -10dBm

Minpktinterval 0,04s ref ref ref ref 1s

Datarate 3Mbit/s ref ref ref ref 12Mbit/s

SensiIvity -95dBm ref ref ref ref -65dBm


ETSIITSG5

▪  CooperaIveAwarenessMessage▪  Periodic(upto10Hz)safetymessage

▪  InformaIononstateofsurroundingvehicles:▪  Speed,locaIon,…

▪  Messageagehighlyrelevantforsafety▪  Needmechanismstodiscardoldmessages

▪  SafetyapplicaIonsrelyonCAMs:▪  Tailendofjam

▪  Rearendcollision▪  IntersecIonassistance…

▪  SentonCCH▪  Generatedevery100ms..1s,butonlyif∆angle(>4°),∆posiIon(>5m),∆speed(>1m/s)


ETSIITSG5

▪  CAMformatLength[byte] Field

1 messageId(0=CAM,1=DENM)

8 generaIonTime

4 StaIonId

1

StaIonCharacterisIcs

mobileITSStaIon

1 privateITSStaIon

1 physicalRelevantITSStaIon

8+8+4

ReferencePositon

Longitude/Longitude/ElevaIon

4 Heading

32+4 Streetname/RoadSegmentID

1 PosiIon/HeadingConfidence

1

CamParameters vehicleCommonParameters

vehicleType

2+2 Length/Width

4 Speed

2 AcceleraIon

1 AcceleraIonControl(break,throZle,ACC)…

1 exteriorLights

1 Occupancy

1+1 crashStatus/dangerousGoods


ETSIITSG5

▪  DecentralizedEnvironmentalNoIficaIonMessage(DENM)

▪  Eventtriggered(e.g.,byvehiclesensors)▪  Hardbraking▪  Accident▪  Tailendofjam

▪  ConstrucIonwork▪  Collisionimminent

▪  Lowvisibility,highwind,icyroad,…▪  Messageshave(Ight)localscope,relaybasedon

▪  Area(definedbycircle/ellipse/rectangle)▪  Roadtopology▪  DrivingdirecIon


DENMformat(excerpt)


Length[byte] Field

1 messageId(0=CAM,1=DENM)

6 generaIonTime

4

Management

OriginatorID Whosentthis?

2 SequenceNumber

1 DataVersion IsthisanupdateonasituaIon?

6 ExpiryTime IsthissIllvalid?

1 Frequency WhencanIexpectanupdate?

1 Reliability ShouldItrustasinglenoIficaIon?

IsNegaIon DoesthiscancelanearliernoIficaIon?

1

SituaIon

CauseCode

1 SubCauseCode

1 Severity

4

LocaIonContainer

SituaIon_LaItude

4 SituaIon_Longitude

2 SituaIon_AlItude

4 Accuracy

N-40 RelevanceArea

ETSIITSG5

▪  ServiceAnnouncement

▪  MessageonControlChanneltoadverIseservicesofferedon

ServiceChannels

▪  Channelnumber

▪  Typeofservice▪  …

▪  SimilartoWAVEServiceAnnouncement(WSA)

▪  Receivercantune(itssecondradio)toadverIsedchannel


ETSIITSG5

▪  Securityandprivacy▪  NopublishedspecificaIon(yet)

▪  KerberosorWAVE-likePKI

▪  RestrictparIcipaIontoauthorizedvehicles▪  Signmessages

▪  LimitV2IandI2Vtrafficwherepossible

▪  Usepseudonymstoprotectprivacy

▪  UsebaseidenIty(inpermanentstorage)toauthenIcatewith

infrastructure

▪  Infrastructuregeneratespseudonymforvehicle


ETSIITSG5:AnalysisandProblems

▪  OscillaIngchannelload(bothlocalandglobal!)▪  …causedbychannelaccessbeingtoorestricIve(standardparameters)


Picturesource:DavidEckhoff,NikoleZaSofraandReinhardGerman,"APerformanceStudyofCooperaIveAwarenessinETSIITSG5andIEEEWAVE,"Proceedingsof10thIEEE/IFIPConferenceonWirelessOndemandNetworkSystemsandServices(WONS2013),Banff,Canada,March2013.


▪  Latencies▪  Choosingminimumpacketintervals(TRC)toohighcan

introducehighlatencies




▪  Updatefrequency▪  StandardparametersaretoorestricIve

▪  ChannelresourcesarenotusedopImally



MainTakeaways

▪  BroadcastMedia▪  TMC,TPEG

▪  UMTS▪  Channels,Pros/Cons

▪  DSRC/WAVElowerlayers▪  802.11pvs.old802.11:commonaliIesanddifferences

▪  HCF(EDCAQoS)

▪  IEEE1609.*upperlayers▪  Channelmanagement

▪  Security/CerIficates

▪  ETSIITSG5▪  Channelmanagement

▪  DCC:DecentralizedCongesIonControl

▪  Messagetypes▪  CommonaliIesanddifferenceswrt.IEEE1609.*


Broadcast,Geocast,RouIng


RouIng

▪  ClassicalapproachestorouIng▪  DistanceVectorRouIng

▪  NodeskeepvectorofknowndesInaIons,storedistanceandnexthop

▪  Ex:DSDV

▪  LinkStateRouIng▪  Nodeskeeptrackofofalllinksinnetwork

▪  Pro:fastandguaranteedconvergence

▪  Con:highoverhead▪  Ex:OLSR


RouIng

▪  ClassicalapproachestorouIng(II)▪  ReacIve(ondemand)rouIng

▪  Routesestablishedwhenneeded▪  RouIngmessagesonlyexchangedif(orwhile)userdataisexchanged

▪  Unusedroutesexpire▪  Ex:AODV,DYMO

▪  ProacIve(tabledriven)rouIng▪  RoutesareestablishedandmaintainedconInuously

▪  Noroutesetupdelaywhendataneedstobesent

▪  Highoverhead▪  Ex:OLSR,DSDV

i

?

i i

? ?


RouIng

▪  ClassicalapproachestorouIng(III)▪  Hop-by-HopRouIng

▪  EachpacketcontainsdesInaIonaddress

▪  DuringrouIng,eachhopchosesbestnexthop

▪  Ex:AODV

▪  SourceRouIng▪  EachpacketcontainscompleteroutetodesInaIon

▪  DuringrouIng,nodesrelyonthisinformaIon

▪  Ex:DSR


RouIng

▪  GeorouIng▪  Primarymetrics:posiIon/distancetodesInaIon

▪  RequiresnodeposiIonstobeknown(atleastforthedesInaIon)

▪  TwooperaIonmodes(typ.):▪  Greedymode:choosenexthopaccordingtomaxprogress▪  Recoverymode:escapedeadends(localmaxima)

▪  Mustensurethatmessagenevergetslost


RouIng

▪  GeorouIng:CBF▪  „ContenIonBasedForwarding“▪  ReducIon(orcompleteavoidance)ofduplicates

▪  Outline▪  Given:posiIonofmessagedesInaIon,posiIonoflasthop

▪  Donotforwardmessageimmediately,butwaitforImeT

▪  ChoosewaitImeTaccordingtosuitabilityofnode

▪  Donotforwardmessageifanotherforwardwasoverheard

▪  Problem▪  PotenIalforwardersmustbeabletooverheareachothers’transmissions


[1]Füßler,HolgerandWidmer,JörgandKäsemann,MichaelandMauve,MarInandHartenstein,Hannes,"Conten@on-basedforwardingformobileadhocnetworks,"AdHocNetworks,vol.1(4),pp.351-369,2003

RouIng

▪  GeorouIng:CBF▪  PotenIalforwardersarecontainedinReuleauxtriangle(1)(useesImatedcommunicaIonrangeforthicknessoftriangle)

▪  WaiIngImeisT=1-P�(z:desInaIon,f:lasthopforwarder)

▪  Iflasthopoverhearsnonodeforwardingthemessage,messageisre-sentfornodesin(2),then(3)


IllustraIonsource:Füßler,HolgerandWidmer,JörgandKäsemann,MichaelandMauve,MarInandHartenstein,Hannes,"Conten@on-basedforwardingformobileadhocnetworks,"AdHocNetworks,vol.1(4),pp.351-369,2003

RouIng

▪  ReflecIononclassicalrouIngapproaches▪  Q:Can(classical)rouIngworkinVANETs?

▪  A:Onlyinsomecases.

▪  CommonlyneedmulIcastcommunicaIon,lowload,lowdelay

▪  AddiIonalchallengesandopportuniIes:networkparIIoning,dynamictopology,complexmobility,…


[1]Toor,YasserandMühlethaler,PaulandLaouiI,AnisandFortelle,ArnauddeLa,"VehicleAdHocNetworks:Applica@onsandRelatedTechnicalIssues,"IEEECommunicaIonsSurveysandTutorials,vol.10(3),pp.74-88,2008

Car-to-X

Non-Safety

Comfort



OpImalSpeedAdvisory

CongesIon,Accident

InformaIon

Safety

SituaIonAwareness


BlindSpotWarning

WarningMessages


ElectronicBreakLight

<!> <!>

<!>

<!>

<!>

<!>

<!>

<!>

idle send

rcv dup

Flooding

▪  Flooding(MulI-HopBroadcast)▪  Simplestprotocol:„SmartFlooding“:

▪  Problem:BroadcastStorm▪  Superfluousre-broadcastsoverloadchannel


Flooding

▪  Consequencesofabroadcaststorm

▪  Interference àimpactonothersystems

▪  Collision àimpactonotherusers

▪  ContenIon àimpactonotherapplicaIons


Flooding

▪  Solvingthebroadcaststormproblem

▪  Classicalapproaches▪  LightweightsoluIons(e.g.,probabilisIcflooding)▪  ExchangeofneighborinformaIon,cost/benefitesImaIons

▪  TopologycreaIonandmaintenance(Cluster,Cord,Tree,…)

▪  Drawbacks▪  Blindguessing(orscenariodependentparameterizaIon)

▪  AddiIonalcontrolmessageoverhead

▪  ConInuousmaintenanceoftopology


Flooding

▪  VANETspecificsoluIon:BroadcastSuppression▪  NeedsnoneighborinformaIon

▪  Needsnocontrolmessages

▪  Maximizesdistanceperhop

▪  Minimizespacketloss

▪  Approach▪  Nodereceivesmessage,esImatesdistancetosender

▪  SelecIvelysuppressesre-broadcastofmessage

▪  AlternaIves▪  weightedp-persistence▪  sloZed1-persistence▪  sloZedp-persistence


[1]Wisitpongphan,NawapornandTonguz,OzanK.andParikh,J.S.andMudalige,PriyanthaandBai,FanandSadekar,Varsha,"BroadcastStormMi@ga@onTechniquesinVehicularAdHocNetworks,"IEEEWirelessCommunicaIons,vol.14(6),pp.84-94,December2007

Flooding

▪  BroadcastSuppression▪  EsImatedistancetosenderasbasedon("approximate

transmissionradius")

▪  Variant1:GPSbased

▪  Variant2:RSSbased


Flooding

▪  BroadcastSuppression▪  Weightedp-persistence

▪  ProbabilisIcfloodingwithvariablepijforre-broadcast▪  Thus,higherprobabilityforlargerdistanceperhop

pij


Flooding

▪  BroadcastSuppression▪  Weightedp-persistence

▪  WaitWAIT_TIME(e.g.,2ms)

▪  choosep=min(pij)=min(ρij)ofallreceivedpackets

(probabilityforre-broadcastofpacket)

▪  Ensurethatatleastoneneighborhasre-broadcastpacket

idle wait 2ms rcv

dup

send p

wait 2.1ms

¬p

dup expired

dup


Flooding

▪  BroadcastSuppression▪  SloZed1-persistence

▪  SuppressionbasedonwaiIngandoverhearing▪  Dividelengthofroadintoslots▪  Moredistantslotssendsooner

▪  Closerslotssendlater(orifmoredistantslotsdidnotre-broadcast)

▪  Thus,higherprobabilitytotransmitoverlongerdistance

pij t=0 t=τ t=2τ t=3τ


Flooding

▪  BroadcastSuppression▪  SloZed1-persistence

▪  Divide“communicaIonrange“intoNsslotsoflengthτ

▪  Nodeswaitbeforere-broadcast,waiIngImeTij=τ×⎡Ns(1-ρij)⎤

▪  DuplicateeliminaIontakescareofsuppressionofbroadcasts

idle wait Tij rcv

dup

send ¬dup

dup


Flooding

▪  BroadcastSuppression▪  SloZedp-persistence

▪  Cf.sloZed1-persistence▪  Fixedforwardingprobabilityp(insteadof1)

pij t=0 t=τ t=2τ t=3τ


Flooding

▪  BroadcastSuppression▪  SloZedp-persistence

▪  WaitforTij(insteadoffixedWAIT_TIME)

▪  Useprobabilityp(insteadof1)▪  Ensurethatatleastoneneighborhasre-broadcastthepacketbywaiIngforδ’>max(Tij)

idle wait Tij rcv

dup

send p

wait δ’

¬p

dup expired dup


Flooding

▪  BroadcastSuppression▪  SolvesBroadcastStormProblem

▪  Maximizesdistanceperhop

▪  Minimizespacketloss

▪  But:Muchhigherper-messagedelay


Remainingproblems

▪  TemporarynetworkfragmentaIon

▪  UndirectedmessagedisseminaIon



<!>

Flooding+X

▪  DV-CAST▪  Idea:detectcurrentscenario,switchbetweenprotocols▪  Checkforfragmentednetwork

▪  Networkconnectedàperformbroadcastsuppression

▪  NetworkfragmentedàperformStore-Carry-Forward

[1]Tonguz,OzanK.andWisitpongphan,N.andBai,F.,"DV-CAST:Adistributedvehicularbroadcastprotocolforvehicularadhocnetworks,"IEEEWirelessCommunicaIons,vol.17(2),pp.47-57,April2010

Flooding+X

▪  DV-CAST:Mechanism▪  NodesperiodicallysendHellobeaconscontainingposiIon,speed▪  Nodesmaintain3neighbortables

▪  SamedirecIon,ahead

▪  SamedirecIon,drivingbehind

▪  OppositedirecIon▪  MessagescontainsourceposiIonandRegionofInterest(ROI)

▪  Foreachmessagereceived,evaluate3Flags:▪  DesInaIonFlag(DFlg):VehicleinROI,approachingsource

▪  MessageDirecIonConnecIvity(MDC):�neighbordrivinginsamedirecIon,furtherawayfromsource

▪  OppositeDirecIonConnecIvity(ODC):�neighbordrivinginoppositedirecIon


Flooding+X


Picturesource:Tonguz,OzanK.andWisitpongphan,N.andBai,F.,"DV-CAST:Adistributedvehicularbroadcastprotocolforvehicularadhocnetworks,"IEEEWirelessCommunicaIons,vol.17(2),pp.47-57,April2010

▪  DV-CAST▪  Algorithm:

Flooding+X


▪  DV-CAST▪  Decisionmatrix:

MDC ODC DFlg DerivedScenario Ac@onsTakenbyDV-CASTProtocol

1 × 1 WellConnected BroadcastSuppression

1 × 0 WellConnected Helprelaythepacketbydoingbroadcastsuppression

0 1 1 SparselyConnected

RebroadcastandassumethattheODNwillhelprelayorrebroadcast

0 1 0 SparselyConnected

Rebroadcastandhelpcarry&forwardthepackettothefirstnewneighborintheoppositedirecIonorin

themessagedirecIonencountered

0 0 × TotallyDisconnected WaitandforwardthepackettothefirstneighborintheoppositedirecIonorinthemessagedirecIon

encountered.

Flooding+X

▪  DV-CAST▪  SimulaIonresultsshowthat(onfreewayswithlowtomedium

nodedensiIes)DV-CASTbeatssimplefloodingintermsofbroadcastsuccessrateanddistancecovered


IntermediateSummary

▪  Remainingproblems

▪  TemporarynetworkfragmentaIon(solved)

▪  UndirectedmessagedisseminaIon

✓


Geocast

▪  TO-GO▪  „Topology-AssistedGeo-OpportunisIcRouIng“▪  NodesperiodicallysendHellobeacons;Contents:

▪  Numberofneighbors

▪  BloomfilterofneighborIDs

▪  IDsofneighborsfurthestdowntheroad/roads▪  Thus,nodesknowaboutall2-hopneighbors


[1]Lee,K.C.andLee,U.andGerla,M.,"Geo-Opportunis@cRou@ngforVehicularNetworks,"IEEECommunica%onsMagazine,vol.48(5),pp.164-170,May2010

Geocast

▪  BloomFilter▪  Idea:

▪  BloomfilterisabitfieldX

▪  HashfuncIonsh1tohkmapinputdataxàonebit(each)inX

▪  InserIonofx:Set X[hi(x)]←1 �i�[1..k]

▪  Testforx�X:Check X[hi(x)]�1 �i�[1..k]

▪  ProbabilisIctestfor“x�X”▪  Possibleresults:no/maybe(àchanceoffalseposiIves)

▪  AllowsforverycompactrepresentaIonofX


[1]Bloom,BurtonH.,"Space/@metrade-offsinhashcodingwithallowableerrors,"Communica%onsoftheACM,vol.13(7),pp.422-426,1970

0 1 0 0 0 1 0 1

“foo”

h1 h2 h3

Geocast

▪  TO-GO▪  Step1:Findbestnexthop(TargetNode,T)

▪  FindN:FurthestneighbortowardsdesInaIon▪  FindJ:FurthestneighbortowardsdesInaIon,currentlyonjuncIon▪  FindNJ:FurthestneighbortowardsdesInaIon,asseenbyJ

▪  ifN,NJareonthesameroad(andrunningingreedymode),pickNelse,pickJ

N

NJ

J


Geocast

▪  TO-GO▪  Step2:FindForwardingSet(FS)

▪  NodesintheFSwillcompeteforrelayingofthemessage

▪  OnlyonenodeinFSshouldrelaythus,allnodesinFSmustheareachother

▪  FindingopImalsoluIonisNPcomplete▪  TO-GOusesapproximaIon:

▪  Bloomfilterentriesindicatewhocanhearwhom

▪  GiventhetargetnodeT,finditsneighborMwiththemaximumnumberofneighbors

▪  IncludeallthoseneighborsinFS,which▪  canhearM,and

▪  areheardbyM,and▪  areheardbyallcurrentmembersofFS


Geocast

▪  TO-GO▪  Step3:MulIcastmessagetoallnodesinFS

▪  NodesintheFScompeteforrelayingofthemessage

▪  EnsuremaximumprogresswithinFS

▪  Delayre-broadcastbyt▪  Suppressre-broadcastifanothernodesforwardswithint▪  t=τ×dT/dmax

with:

▪  τ:Maximumdelayperhop

▪  dT:DistancetoTargetNode▪  dmax:DistancefromlasthoptoTargetNode


IntermediateSummary

▪  Remainingproblems

▪  TemporarynetworkfragmentaIon(solved)

▪  UndirectedmessagedisseminaIon(solved)

✓ ✓


Scalability

▪  Dothepresentedapproachesscale?▪  AnalyIcalevaluaIon[1]:

▪  Capacityofwirelesschannelislimited

▪  AmountofinformaIontransportedacrossany(arbitrary)bordermustbeupper-bounded


[1]B.Scheuermann,C.Lochert,J.Rybicki,andM.Mauve,“AFundamentalScalabiliyCriterionforDataAggrega@oninVANETs,”inACMMobiCom2009.Beijing,China:ACM,September2009

Σ≤ξr

Scalability

▪  SoluIon?▪  DefinemaximumdisseminaIonrangeofanyinformaIon

▪  Reduceupdatefrequencywithincreasingdistance▪  AggregateinformaIonasdistanceincreases

▪  Pre-condiIonforscalabilityofdisseminaIonapproach?▪  Usedbandwidthreducesasdistancetosourceincreases▪  Upperbound:1/d2

distance d

used bandwidth B � 1 / d2


MainTakeaways

▪  ClassicinformaIondisseminaIon

▪  Distancevs.link-state▪  ReacIvevs.proacIve▪  Hop-by-hopvs.sourcerouIng▪  Geo-rouIng(CBF)

▪  ExamplesofVANET-centricinformaIondisseminaIon

▪  Flooding(Weighted/SloZed1/p-Persistence)

▪  FragmentaIon(DV-Cast)

▪  Directedness(To-Go)▪  Scalability


Vehicular Networking Slides-P1

Documents

Transcript of Vehicular Networking Slides-P1