ITS Standardization

JNCT: Les Journées Nationales des Communication dans les Transports 29 Mai 2013

Oyunchimeg Shagdar, Inria Thierry Ernst, Mines Paris Tech

Overview of the talk

“Systems in which information and communication technologies are applied in the field of road transport, including infrastructure, vehicles and users, and in traffic management and mobility management, as well as for interfaces with other modes of transport”. EU Directive 2010/40/EU

2

•  ITS applications •  ITS standards in USA, Europe, and Japan • Cooperative ITS • Harmonization of ITS Standards

“ITS: Intelligent Transportations Systems”

ITS Applications

3

•  Road safety applications

•  Traffic efficiency applications

•  Infotainment applications

Ernst – Cooperative ITS – April 2013 2

Cooperative ITS: Application Diversity

Ernst – Cooperative ITS – April 2013 2

Cooperative ITS: Application Diversity

Ernst – Cooperative ITS – April 2013 2

Cooperative ITS: Application Diversity

ITS applications (cont’)

4

ITS Standards are to enable interoperability by specifying

5

•  Who communicate with whom (vehicle, pedestrian, road-side infrastructure, central servers)

•  Using what type of message •  Which media (wireless frequency band) and which protocol (MAC/IP/..) •  For which application?

ITS standards developing organizations (SDO)

6

ITS Standards Developing Organisations

ISO TC204: ITS (1993) CEN TC278: RTTT (1992)

New TC starting

TC ITS (2007) IEEE 802.11p IEEE P1609

J2735 J2945

Challenge: SDOs are overlapping and partly competing Proliferation of standards

ITS Standards Developing Organisations

ISO TC204: ITS (1993) CEN TC278: RTTT (1992)

New TC starting

TC ITS (2007) IEEE 802.11p IEEE P1609

J2735 J2945

Challenge: SDOs are overlapping and partly competing Proliferation of standards

ITS Standards Developing Organisations

ISO TC204: ITS (1993) CEN TC278: RTTT (1992)

New TC starting

TC ITS (2007) IEEE 802.11p IEEE P1609

J2735 J2945

Challenge: SDOs are overlapping and partly competing Proliferation of standards

ITS Standards Developing Organisations

ISO TC204: ITS (1993) CEN TC278: RTTT (1992)

New TC starting

TC ITS (2007) IEEE 802.11p IEEE P1609

J2735 J2945

Challenge: SDOs are overlapping and partly competing Proliferation of standards

ITS Standards Developing Organisations

ISO TC204: ITS (1993) CEN TC278: RTTT (1992)

New TC starting

TC ITS (2007) IEEE 802.11p IEEE P1609

J2735 J2945

Challenge: SDOs are overlapping and partly competing Proliferation of standards

•  Regularity constraints (e.g., radio frequency) are different depending on the country/region.

•  Standardization activities •  USA: IEEE, SAE (Society of Automotive Engineers) •  Japan: ITS Info-Communications Forum, ARIB

(Association for radio industry and business), ISO •  Europe: CEN (European committee for

standardization), ETSI (European telecommunications standards Institute), ISO

Radio spectrum dedicated to ITS Communications

7

6 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION

5,900

5,925

Frequency (MHz)

5,925

5,800

700 MHz Band

5,875

1,000

5,905

5,725

5,815

5,795

5,855

5,875

5,850

500

902

5,850 928

5,770

10 MHz expected in this band

Europe

North America

Japan

ITU-R

In use

Allocated

Potential

Fig. 1. DSRC frequency band specifications in Europe, North America and Japan, based on [33].

the dynamic nature of users and roadway environment. The

specification of the protocols has not adequately consideredthat the transmitter and receiver are in motion relative to

each other. In particular, the DSRC/WAVE standards and

the resulting radio communication implementations need to

be refined and should include measures such signal quality,for UDP and IP-based two way transaction, an improved

services design logic, improved management of applications

and arbitration of competing services from nearby providers.

Positioning: Positioning functionality is required, but thespecific provisioning means should not be prescribed since notall terminals may be able to include GPS positioning system

for economic reasons. The position requirements must be

refined and extended to take into account the variations understatic and dynamic environments. Furthermore, significantwork has to be done to improve position accuracy and position

availability in all circumstances, meaning that GPS based and

non-GPS based solutions should be investigated.

Security: The VII tests demonstrated that the basic securityfunctions can be implemented and work in the context of the

system. However, more work has to be performed in analyzing

security threats and understand how to detect and solve such

threats and attacks. Furthermore, it is recommended that the

anonymous signing scheme be further analyzed, simulated and

implemented. The message signing and verification strategyfor the high rate messages, such as the Heartbeat messages

should be refined and analyzed to accomplish an optimal blendfor security and system throughput.

Advisory Message Delivery Services (AMDS): The AMDSperformed well during the VII POC tests, but it could be

improved to be more robust and more easy to use. It is

recommended that the system should be improved such that

it is clear how priority of messages should be interpreted in

the context of other user activities. In particular, the activation

criteria, e.g., which message is relevant, needs to be refined.Furthermore, the overall management of system in terms of

properly setting configuration parameters and defining AMDVparameters should be refined.Probe Data Service (PDS): This service was shown to work,

but it was not clear if the huge amount of data from all vehicles

was necessary, since under most conditions, messages sent

from vehicles on the same roadway are strongly redundant.

Furthermore, the rules used to prevent the availability to track

a vehicle and to maintain privacy are quite complex. It is

recommended that the probe data collected during the VII

proof of concept be analyzed and that representative models

of probe data user applications are developed to asses the

mathematically requirements on vehicle density and the scope

of the sampled vehicle parameters. The privacy rules used for

PDS need also to be integrated in the data collection process,

such that it could be understood and controlled when PDS

should be used and when not.

Vehicle Safety Communications (VSC): The VSC

consortium specified several performance requirements

derived from the traffic safety applications, see [17]. Fromthese requirements, the most significant ones are: (1) safetymessages should have a maximum latency of 100 ms, (2) a

generation frequency of 10 messages per second and (3) they

should be able to travel for a minimum range of 150 meters.

3) ITS architecture and protocol standards: This sectiondescribes two ITS architectures.

The first ITS architecture introduced in this section is theone that is defined by US DOT and is denoted as National

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

ITS Standards in USA

IEEE WAVE

8

IEEE and SAE standards (USA)

9

IEEE�WAVE/802.11p

PHY�layer

MAC�sublayer extension

Network (IPv6)

Transport�(TCP/UDP)

Application

WSMP

Message sublayer

Safety applicationsublayer

1609.2�Security

SAE�J2735

IEEE�1609.3

IEEE�1609.4

IEEE�802.11p

IEEE�802.2

IETF�RFC�2460

IETF�RFC�793/768

Safety applications NonͲSafety applications

WAVE�=�Wireless Access�in�Vehicular Environment

LLC�sublayer

MAC�sublayer

WAVE: Application to Middle layers

10

• SAE J2735: • Defines message sets, message formats for

especially safety applications

•  IEEE 1609.3 WSMP (WAVE short message protocol) for safety application

• Reduced overhead: WSMP has 11 bytes of overhead

• Allows applications directly control lower-layer parameters

The primary motivation for developing the WSMP is to reduce the overload. A WSMP packet is shown in Fig. 4. The overhead is 11 bytes, compared to a minimum of 52 bytes of a UDP/IPv6 packet. If a device receives a WSMP packet that has a WSM Version number not supported by the device, the received WSMP packet shall be discarded. The Security Type identifies if the packet is Unsecured, Signed or Encrypted. The Channel Number, Data Rate and TX Power allow the WSMP to directly control the radio parameters. The purpose of the provider service ID (PSID) field serves the similar role as the port number of the UDP/TCP packet, i.e., to identify the application that will process the WSM Data. The Length field indicates the number of bytes in the WSM Date, which might have been security-protected as specified in IEEE1609.2.

Fig. 4. The Format of a WSMP Packet

4 Further Research Ideas

In this section we look at how the DSCR/WAVE technologies can be used to solve practical problems and specially safety applications. We identify the areas that need further research and verification.

4.1 Latency and Capacity Requirement

There have been a lot of safety applications proposed and studied in many projects. However a full scientific analysis of the latency and capacity requirements imposed to DSRC systems is still lacking. Currently the IEEE 1609.4 specifies the reoccurrence of the CCH at the rate of every 100 ms. If the OBU on each vehicle can capture the CCH during each CCH time, It can send its beacon and update its status to its neighbors at the rate of 10 Hz. The question is if the capacity of the DSRC system is large enough to accommodate all vehicles with a 10 Hz beacon. Additionally, have the latency requirements of all safety applications been met if the DSRC system can guarantee that all vehicles can update their beacons at 10 Hz? We believe that these questions have not been properly answered.

Fig. 5 shows the current WAVE over-the-air frame format. Let’s assume that we can pack the 46 ms of CCH time with frames one after another with 58µs distributed inter-frame space (DIFS) between them. The combination of DIFS, Preamble and Signal fields takes 98µs, which can be considered as the minimum overhead to send a frame over the air. The Payload fields of Service, PSDU, Tail and Pad in Fig. 5 take a variable time depending on the size of the protocol service data unit (PSDU) and the

WAVE: MAC/PHY

11

•  IEEE 802.11p •  PHY: IEEE 802.11a: OFDM (3 to 27 Mbps) at 5.9 GHz • MAC: IEEE 802.11e (CSMA/CA) for QoS, No access point

functionality

•  IEEE 1609.4 • Multichannel operation: CCHs •  Time-division channel coordination

IEEE�WAVE/802.11p

• 1609.4�Multichannel operation– One Control�channel (CCH)– Six Service�channels (SCH)

SCH SCH SCH CCH SCH SCH SCH

5.855

5.865

5.875

5.885

5.895

5.905

5.915

5.925

Spectrum (GHz)802.11p�PHY

802.11p�MAC

802.21609.4

1609.3WSMP

SAE�J2735

Safety applicationsublayer

1609.2�Security

Ongoing�work�in�the�US• SAE�J2945.1�Minimum�Performance Requirements– To�ensure interoperability between nodes– E.g.,�define BSMs sending rate,�transmit power control,�adaptive�message rate�control

• Update of 1609.4�multichannel operation– Move all�road�traffic safety data�to one SCH

CCH�interval

SCH�interval

Guard

interval

Guard

interval

100�ms

50�ms 50�ms

CCH�interval

SCH�interval

Guard

interval

Guard

interval

100�ms

50�ms 50�ms

CCH�interval

SCH�interval

Guard

interval

Guard

interval

100�ms

50�ms 50�ms time

CCH�=�Control�Channel,�SCH�=�Service�Channel

ITS Standards in Japan ARIB

12

Support multi-types of applications by DSRC

13

•  Main concern: safety applications •  Fast (single/multi hop) message dissemination •  Allows internet applications.

•  DSRC protocol stack •  No presentation/session/transport/network layers

•  Application Sub Layer (ASL) •  For various types of, IP-based, Non-IP-based applications

is needed. Its main functionality is to provide communication support to OBUs via the 5.8 GHz DSRC radio communication link and to communicate with network entities, e.g., servers and car navigation systems used by the service provider and by road administrators, located far away and that are using the Internet infrastructure. Note that the DSRC communication link is synchronous and it uses as medium access, the TDMA/FDD (Time Division Multiple Access – Frequency Division Duplex), which is different then the medium access used by the IEEE 802.11p.

The protocol suite used in Japan is depicted in Figure 9. Similar to the WAVE protocol suite two types of protocol suites can be distinguished. In the left part of the protocol suite the applications are supported directly by the DSRC protocol, which is specified in the ARIB standard [56]. On the right side of the protocol suite applications are supported via the ASL (Application Sub-Layer), which is specified in the ARIB standard [57]. In Figure 10, an overview of the service interfaces and the protocols of the DSRC-ASL protocol suite are given. The ARIB STD-T75 is composed of three protocol layers: OSI Layer 1 provides the physical layer functionalities, OSI Layer 2 provides the data link layer functionalities and OSI Layer 7 provides the application layer functionalities. Note that if needed, layer 7 could also provide the functionalities of the OSI Layers 2, 4, 5 and 6. The ARIB STD-T88 layer provides some extension to the link layer protocol, and the network control protocol.

Figure 8: Smartway architecture: positioning, mapping

and communication, from [55]

Figure 9: ITS protocol suite applied in Japanese programs

and projects, from [43]

C. ITS Projects, architecture and standards in Europe The scope of many European programs and projects is to

provide the ability to its citizens that use European roads to benefit from improved traffic safety, reduced traffic congestion, and more environmentally friendly driving. This can be realized by providing standardized and common communication means between vehicles driving on these roads as well as between vehicles and road infrastructure.

1) ITS standardization Three bodies are responsible for planning, development and adoption of the European standards [58]. These are: (1) the European Committee for Standardization (CEN), which is a general standardization body and is responsible for all sectors excluding the electro-technical sector, (2) the European Committee for Electro-technical Standardization (CENELEC), which is responsible for the electro-technical part of the standardization, (3) ETSI (European Telecommunications Standards Institute), which is responsible for the standardization in the telecommunications sector.

DSRC layer 2

ARIB STD-T75

Service primitives + ASDU

Service primitives + ASDU

LPDU MPDU

PHYPD

APDU

DSRC layer 1

DSRC layer 7

DSRC layer 2

DSRC layer 1

DSRC layer 7

ARIB STD-T88

Service primitives + NCP-SDU

Service primitives + NCP-SDU

ASL-PDU

NCP-PDU

Extended link protocol

Network control protocol

Extended link protocol

Network control protocol

Upper layer PDU Upper layer

protocol Upper layer

protocol

Figure 10: Overview of DSRC – ASL protocols and service

interfaces

CEN is currently standardizing the European ITS DSRC 5.9 GHz radio communication technology. ETSI ITS Technical Committee (TC) has several working groups: (1) WG1, which describes the basic set of application requirements, (2) WG2, which provides the architecture specification, (3) WG3, which provides the 5.9 GHz network and transport protocols, (4) WG4, which provides the European profile investigation of 802.11p, (5) WG5, which provides the security architecture. The European standardization bodies are heavily cooperating with international standardizations, such as the ISO (International Organization for Standardization), the IEC

May 9 - 13, 2004, GSC-9/GRSC-2, Seoul, Korea 9

3.2 Characteristic of existing DSRCCommunication Architecture of existing DSRC*(*Existing DSRC: In 1992, standardization for the DSRC started in European Committee for Standardization)

Because of constraints specific to a DSRC link,i.e., "Limited Transmission Capacity," "Discontinuous Coverage," “Random Arrival / Exit of the Vehicles in the Area” etc. using the full OSI model was considered unsuitable to the DSRC field.

- Network layer is eliminated:Real-time End-to-end Routing is difficult.

- Transport layer is eliminated:As real-time routing is eliminated, real-time end-to-endcommunication is also eliminated.- Session layer is eliminated:

As tasks sharing by various vehicles or distant hosts are not considered, sessions between them need not be established.- Presentation layer is eliminated:

Implicit or pre-set data formats are used. Data encryption,data certification, terminal authentication etc. can beperformed in layer 7.

DSRC protocol stack

Application layer (L7)

Physical layer (L1)

Data link layer (L2)

Network layer (L3)

Transport layer (L4)

Session layer (L5)

Presentation layer (L6)

ITS communications media and Access Control

14

2

Background Activities in Japan International harmonization Summary

Contents

3

Failure to recognize a hazard in time

Errors in judgment

Errors in operation

Collisions with cross traffic at intersections

26%

14% 70% Rear-end collisions

Other 9%

32%

[ Types of traffic accidents] [ Types of human error]

Right-turn or left-turn collisions

Collisions with pedestrians

Non-Line-of-Sight Communications will be effective for Safe driving support systems.

80% of traffic accidents occur at intersections or locations with poor visibility. 70% of traffic accidents are caused by failure to recognize a hazard in time.

Analysis of Traffic Accidents in Japan

4

•  80% of traffic accidents in Japan occur at intersections •  DSRC over 5.8GHz band, CSMA/CA,

•  Considering the compatibility with IEEE 802.11p

•  Use of 700 MHz •  Compared to 5.8GHz, 700 MHz has larger coverage and “bends” well

fits better to Intersection scenarios

•  Design of V2V and R2V Time division access

6

ARIB STD-T109 V2V and R2V Time Division Access

11

R2V interval

R2V interval

Time

V2V communications zone

V2V and R2V communications zone

Background Activities in Japan International harmonization Summary

Contents

12

System architecture

15

5

System Architecture

PHY

MAC Sub Layer

LLC Sub Layer

IVC-RVC Integrated Access Control

IVC-RVC Integrated Access Control Information

L7：Application Layer

PHY_SAP

MAC_SAP

LLC_SAP

IVRI_SAP

APP1

PHY Sub-layer Management Entity (PLME)

MLME Extension

System Management

MAC Sub-layer Management Entity (MLME)

IVC-RVC Management

Entity (IVRLME)

APP3 APP2

IP extension （TCP/IP

UDP/IP）

PLM

E _S

AP

MLM

E _S

AP

MLM

EX

_SAP

IV

RLM

E _S

AP

LLC_SAP

SEC

_S

AP

SME

_SAP

SME

_SAP

Security

Management

SEC

_S

AP

SEC

_S

AP

APP4

The red dashed line indicates the scope of the new ARIB standard for advanced ITS radiocommunications in Japan.

9

ARIB STD-T109 700MHz Band Intelligent Transport Systems

Basic Parameters

Operating frequency: 760MHz (Single channel)

Occupied bandwidth: Less than 9MHz

Modulation: BPSK/OFDM, QPSK/OFDM, 16QAM/OFDM

Number of subcarriers: 52

Error correction: Convolution code R = 1/2, 3/4

Data transmission rate: 3, 4.5, 6, 9, 12, 18Mbps

Media access control: CSMA/CA

10

http://www.arib.or.jp/english/html/overview/doc/5-STD-T109v1_0-E1.pdf

ITS Standards in Europe ETSI

16

ETSI TC ITS (Europe)

17

• A new layer: “facilities layer” • Geonetworking in Networking & Transport Layer

ETSI -- Applications

18

• Basic set of applications • Road safety

• Emergency vehicle, slow vehicle, wrong way driving, etc.

•  Traffic efficiency • Speed limits notifications,

enhanced route guidance

ETSI�TC�ITS�protocol stack

• Adds a�facilities layer inͲbetween transport�and�applications

• The�access�technologiesdo�not�only focus�on�ad�hoc networking

Access�Technologies

Network &Transport

Facilities

Applications

Managem

ent

Security

Applications

Facilities (Application Support)

19

•  ITS stations (vehicle, roadside, central, personal) exchange information used by several applications

• Managed in the facilities layer • CAM (Cooperate awareness

message): status information of ITS stations, e.g., position, speed, moving direction

• DENM (Decentralized Environmental Notification Message): information of road traffic event, e.g., traffic accident, road work, traffic jam

ETSI�TC�ITS�protocol stack

• Adds a�facilities layer inͲbetween transport�and�applications

• The�access�technologiesdo�not�only focus�on�ad�hoc networking

Access�Technologies

Network &Transport

Facilities

Applications

Managem

ent

Security

CAM DENM

Facilities: LDM (Local Dynamic Map)

20 17

Cooperative ITS: Facilities

● LDM: Local Dynamic Map

ETSI – Network and Transport

21

ETSI�– Network and�transport

Access�Technologies

Network &Transport

Facilities

Applications

Basic�Transport�Protocol

Transmission�Control�Protocol

User DatagramProtocol

Transport

Network

Geonetworking Internet�Protocol(IPv4,�IPv6)�

•  Geonetworking •  Information delivery to particular geographical destination area •  BTP – UDP-like protocol for Geonetworking

•  IP networking •  Information delivery using IP addresses •  UDP/TCP

GeoNetworking: Network layer message dessimination protocol

22

7

Communication Scenarios (2)

• Geo-Unicast: from one node to a single node• Geo-Multicast: from one node to a set of nodes• Geo-Anycast: from one node to any node in an area • Geo-Broadcast: from one node to all nodes in an area

Geo-Broadcast towards target area

  Information dissemination to a particular geographical region.   Geobroadcast: to all nodes in an area   Geounicast: to a node   Geomulticast: to a set of nodes   GeoAnycast: to any node in an area

  Functionalities   Building neighbor location table based on periodical beacons (or use

CAMs)   Geonetworking forwarding decision utilizing the neighbor location table

ETSI

ETSI TS 102 636-4-1 V1.1.1 (2011-06) 19

• The GeoNetworking header is the header of the GeoNetworking packet as defined in the present document and extended for media-dependent GeoNetworking functionality, such as for ITS-G5A specified in TS 102 636-4-2 [i.2].

• The optional GeoNetworking security header.

NOTE 2: The specification of the GeoNetworking security header is outside the scope of the present document.

• The optional payload represents the user data that are created by upper protocol entities, i.e. the T-SDU or GN6-SDU. It is passed to the GeoNetworking protocol entity for transmission.

NOTE 3: The general packet structure is shown as seen by the MAC protocol of the ITS Access Layer.

NOTE 4: Some GeoNetworking packet do not carry a payload, such as Beacon.

MAC Header LLC Header GeoNetworking

Header

GeoNetworking Security Header

(optional)

Payload (optional)

Figure 4: GeoNetworking packet structure

8.2.3 Maximum Transmit Unit The Maximum Transmit Unit (MTU), which the GeoNetworking protocol supports via the GN_SAP, i.e. the MTU_GN depends on the MTU of the access layer technology (MTU_AL) over which the GeoNetworking packet is transported. In particular, MTU_GN shall be less or equal to MTU_AL reduced by the size of the largest GeoNetworking protocol header (GEO_MAX) and by the size of the largest GeoNetworking Security header (GEOSEC_MAX):

MAXGEOSECMAXGEOALMTUGNMTU ____ !!"

GEO_MAX is set by the MIB attribute itsGnMaxGeoNetworkingHeaderSize.

The value of GEOSEC_MAX is beyond the scope of the present document.

8.3 GeoNetworking header structure The GeoNetworking header shall be comprised of a Common Header and an Extended Header (figure 5).

Common Header

Extended

Header

Figure 5: GeoNetworking header structure

Common Header and Extended Header are specified in clauses 8.5 and 8.6, respectively.

8.4 Position vector

8.4.1 Overview For simplicity, a set of position-related fields of the GeoNetworking header are subsumed to a position vector (PV). Two types of PV are defined:

• Long position vector.

• Short position vector.

ETSI

ETSI TS 102 636-4-1 V1.1.1 (2011-06) 19

• The GeoNetworking header is the header of the GeoNetworking packet as defined in the present document and extended for media-dependent GeoNetworking functionality, such as for ITS-G5A specified in TS 102 636-4-2 [i.2].

• The optional GeoNetworking security header.

NOTE 2: The specification of the GeoNetworking security header is outside the scope of the present document.

• The optional payload represents the user data that are created by upper protocol entities, i.e. the T-SDU or GN6-SDU. It is passed to the GeoNetworking protocol entity for transmission.

NOTE 3: The general packet structure is shown as seen by the MAC protocol of the ITS Access Layer.

NOTE 4: Some GeoNetworking packet do not carry a payload, such as Beacon.

MAC Header LLC Header GeoNetworking

Header

GeoNetworking Security Header

(optional)

Payload (optional)

Figure 4: GeoNetworking packet structure

8.2.3 Maximum Transmit Unit The Maximum Transmit Unit (MTU), which the GeoNetworking protocol supports via the GN_SAP, i.e. the MTU_GN depends on the MTU of the access layer technology (MTU_AL) over which the GeoNetworking packet is transported. In particular, MTU_GN shall be less or equal to MTU_AL reduced by the size of the largest GeoNetworking protocol header (GEO_MAX) and by the size of the largest GeoNetworking Security header (GEOSEC_MAX):

MAXGEOSECMAXGEOALMTUGNMTU ____ !!"

GEO_MAX is set by the MIB attribute itsGnMaxGeoNetworkingHeaderSize.

The value of GEOSEC_MAX is beyond the scope of the present document.

8.3 GeoNetworking header structure The GeoNetworking header shall be comprised of a Common Header and an Extended Header (figure 5).

Common Header

Extended

Header

Figure 5: GeoNetworking header structure

Common Header and Extended Header are specified in clauses 8.5 and 8.6, respectively.

8.4 Position vector

8.4.1 Overview For simplicity, a set of position-related fields of the GeoNetworking header are subsumed to a position vector (PV). Two types of PV are defined:

• Long position vector.

• Short position vector.

  Common header: 36 bytes. Contains geographical location of the sender (24 bytes).   Extended header: depends on the dissemination type. GeoUnicast: 52 byes

IP networking

23

•  Internet based and E2E service between ITS stations •  Maintaining information flow over any available media (11p,

11n, cellular, satellite, …) •  Inter-operability between various ITS and non-ITS sectors

Combination of IP and Geonetworking IP tunneling / IP over Geonetworking

24 14Ernst – Cooperative Mobility Workshop – Versailles June 2012

GeoNet: IPv6 & GeoNetworking

ETSI Access technology (ITS-G5)

25

• Use of IEEE 802.11p (MAC/PHY)over the European spectrum ES 202 663

• Decentralized Congestion Control TS 102 687 • Motivation: Channel congestions can largely degrade

communication performance • Cross layer congestion control at  Access layer (E.g., Transmit power/rate control)  Network & Transport  Facilities  Management plays a central role

ITS New Paradigm: Cooperative ITS Harmonization activities

- 26

Traditional ITS

- 27

• Often designed for a single use case / application (silo)

• Built in with a specific communication box/media

Facilities

Networking & Transport

Access Technologies

...

Man

agem

ent

Secu

rity

Applications•  ITS reference architecture (ISO/

ETSI) supporting diversity of •  ITS stations (vehicle,

roadside, central, personal) • Media (802.11p, 2G/3G,

802.11n) • Applications (road safety,

traffic efficiency, comfort) • Communications protocols:

Internet protocol (IPv6) and non-IP protocols

Cooperative ITS

ITS Standards Harmonization (USA – EU – JP) -Summary-

28

• Protocol stack: ETSI/ISO ITS reference architecture • Use of various media: Common understanding • 5.8-5.9 GHz : CSMA/CA: Harmonized • Channel coordination

• A number of CCHs and SCHs: USA and EU •  Switching between CH and SH: Only USA •  R2V and V2V Time division access: Only JP

• Congestion control • Cross layer congestion control: Only EU (details are not clear)

• Non-IP and IP communications: Same consensus •  Large difference in handling Non-IP messages • Geonetworking on Network layer: Only EU •  Use of IPv6 for Internet applications: common understanding,

needs more effort

Thank you

29