TS 22.186
Service Requirements for enhanced V2X Scenarios

3GPP‑Page ETSI‑search CONTENT_↓

V18.0.1 (PDF) 2024/03 20 p.

V17.0.0 2022/03 20 p.

V16.2.0 2019/06 20 p.

V15.4.0 2018/09 18 p.

Rapporteur:: Mr. Chun, SungDuck
LG Electronics France

Content for TS 22.186 Word version: 18.0.1

1 Scope p. 5

The present document specifies service requirements to enhance 3GPP support for V2X scenarios in the 3GPP systems (i.e. EPS, 5G).

It includes transport layer support for both safety and non-safety V2X scenarios:

Safety-related V2X scenarios: e.g. automated driving, vehicle platooning
Non-safety-related V2X scenarios: e.g., mobile high data rate entertainment, mobile hotspot/office/home, dynamic digital map update

2 References p. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 22.261: "Service requirements for the 5G system".

[3]

TS 22.185: "Service requirements for V2X services".

[4]

SAE International: "AUTOMATED DRIVING LEVELS OF DRIVING AUTOMATION ARE DEFINED IN NEW SAE INTERNATIONAL STANDARD J3016", December 2016; US Homeland Security Digital Library, "Self-Driving Cars: Levels of Automation", March 2017 https://www.hsdl.org/?view&did=801463.

[5]

ISO TS 17419:2014: "Intelligent Transport Systems - Cooperative systems - Classification and management of ITS applications in a global context".

[6]

IEEE Std 1609.0-2013: "IEEE Guide for Wireless Access in Vehicular Environments (WAVE) architecture".

3 Definitions, symbols and abbreviations p. 5

3.1 Definitions p. 5

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

End-to-end latency:

Time it takes to transfer a given piece of information from a source to a destination, measured at the application level, from the moment it is transmitted by the source to the moment it is received at the destination.

Reliability (%):

The success probability of transmitting X bytes within a certain delay, which is the time it takes to deliver a small data packet from the radio protocol layer 2/3 SDU ingress point to the radio protocol layer 2/3 SDU egress point of the radio interface.

Road Side Unit:

A stationary infrastructure entity supporting V2X applications that can exchange messages with other entities supporting V2X applications.

For the purposes of the present document, the following terms and definitions given in ISO TS 17419 [5] apply:

ITS Application Identifier:

globally unique, registered number identifying an ITS application object

For the purposes of the present document, the following term and definition given in IEEE Std 1609.0 [6] apply:

Provider Service Identifier:

An identifier of an application-service provided by a higher layer entity.

3.2 Abbreviations p. 6

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

ITS

Intelligent Transport Systems

ITS-AID

ITS Application Identifier

LoA

Level of Automation

PSID

Provider Service Identifier

RSU

Road Side Unit

4 Overview p. 6

4.1 Categories of requirements to support eV2X scenarios p. 6

Different V2X scenarios require the transport of V2X messages with different performance requirements for the 3GPP system. This Technical Specification specifies service requirements to enhance 3GPP support for V2X scenarios in the following six areas:

General Aspects: interworking, communication-related requirements valid for all V2X scenarios
Vehicles Platooning
Advanced Driving
Extended Sensors
Remote Driving
Vehicle quality of service Support

Vehicles Platooning enables the vehicles to dynamically form a group travelling together. All the vehicles in the platoon receive periodic data from the leading vehicle, in order to carry on platoon operations. This information allows the distance between vehicles to become extremely small, i.e., the gap distance translated to time can be very low (sub second). Platooning applications may allow the vehicles following to be autonomously driven.

Advanced Driving enables semi-automated or fully-automated driving. Longer inter-vehicle distance is assumed. Each vehicle and/or RSU shares data obtained from its local sensors with vehicles in proximity, thus allowing vehicles to coordinate their trajectories or maneuvers. In addition, each vehicle shares its driving intention with vehicles in proximity. The benefits of this use case group are safer traveling, collision avoidance, and improved traffic efficiency.

Extended Sensors enables the exchange of raw or processed data gathered through local sensors or live video data among vehicles, RSUs, devices of pedestrians and V2X application servers. The vehicles can enhance the perception of their environment beyond what their own sensors can detect and have a more holistic view of the local situation.

Remote Driving enables a remote driver or a V2X application to operate a remote vehicle for those passengers who cannot drive themselves or a remote vehicle located in dangerous environments. For a case where variation is limited and routes are predictable, such as public transportation, driving based on cloud computing can be used. In addition, access to cloud-based back-end service platform can be considered for this use case group.

Vehicle quality of service support enables a V2X application to be timely notified of expected or estimated change of quality of service before actual change occurs and to enable the 3GPP System to modify the quality of service in line with V2X application's quality of service needs. Based on the quality of service information, the V2X application can adapt behaviour to 3GPP System's conditions. The benefits of this use case group are offerings of smoother user experience of service.

4.2 Level of Automation p. 7

A relevant aspect of advanced V2X applications is the Level of Automation (LoA), which reflects the functional aspects of the technology and affects the system performance requirements. In accordance with the levels from SAE [4], the LoA are: 0 - No Automation, 1 - Driver Assistance, 2 - Partial Automation, 3 - Conditional Automation, 4 - High Automation, 5 - Full Automation.

A distinction is drawn between lower levels and higher levels based on whether the human operator or the automated system is primarily responsible for monitoring the driving environment.

The 3GPP system provides the performances expected for all levels of automation

5 Requirements p. 7

5.1 General Requirements p. 7

[R.5.1-001]

The 3GPP system shall be able to control the communication range for a message based on the characteristic of the messages transmitted by a UE supporting V2X application.

[R.5.1-002]

The 3GPP system shall be able to optimize the communication between UEs supporting V2X application belonging to the same group and in proximity.

[R.5.1-003]

The 3GPP system shall be able to support the message transfer for group management operations as requested by the application layer.

[R.5.1-004]

The 3GPP system shall be able to support message transfer among a group of UEs supporting V2X application.

[R.5.1-005]

The 3GPP system shall be able to support message transfer between two UEs belonging to the same group of UEs supporting V2X application.

[R.5.1-006]

The 3GPP system shall be able to support confidentiality and integrity of message transfer among a group of UEs supporting V2X application.

[R.5.1-007]

The 3GPP system shall support relative lateral position accuracy of 0.1 m between UEs supporting V2X application.

[R.5.1-008]

The 3GPP system shall support high connection density for congested traffic.

[R.5.1-009]

The 3GPP system shall support efficient coordination of radio resources used for transport of messages to maximize the utilization of the available spectrum and to ensure the required reliability.

[R.5.1-010]

The 3GPP system shall be able to control the UL and DL reliability of transport of V2X communications, depending on the requirement of V2X application

[R.5.1-011]

Impact to E-UTRA(N) by UE supporting only NR based V2X communication shall be minimized.

[R.5.1-012]

Impact to NR by UE supporting only E-UTRA based V2X communication shall be minimized.

[R.5.1-013]

The 3GPP system shall be able to support message transfer between UEs or between a UE and a UE-type RSU, regardless of whether or not they are subscribers of the same PLMN supporting V2X communications. In case they are subscribers to different PLMNs, there shall be no service degradation of the message transfer.

[R.5.1-014]

The 3GPP system shall enable discovery and communication between UEs supporting the same V2X application.

[R.5.1-015]

The 3GPP system shall be able to support the operators to select which 3GPP RAT to use for a V2X application.

[R.5.1-016]

The 3GPP system shall enable a UE supporting a V2X application to obtain network access via another UE supporting V2X application.

[R.5.1-017]

The 3GPP system shall enable a UE supporting a V2X application to discover another UE supporting V2X application that can offer access to the network.

[R.5.1-018]

The 3GPP system shall support switching between direct 3GPP connection and indirect 3GPP connection via a UE supporting a V2X application, for a UE supporting a V2X application.

[R.5.1-019]

The 3GPP system should be able to support confidentiality and integrity of message transfer between a UE supporting a V2X application and network, when the UE is using an indirect 3GPP connection.

[R.5.1-020]

The 3GPP system shall allow UEs supporting V2X application to use NR for direct communication when the UEs are not served by a RAN using NR.

[R.5.1-021]

The 3GPP system shall allow UEs supporting V2X application to use E-UTRA for direct communication when the UEs are not served by a RAN using E-UTRA.

[R.5.1-022]

An RSU shall be able to communicate with up to 200 UEs supporting a V2X application.

[R.5.1-023]

The 3GPP system shall be able to support confidentiality and integrity of message transfer between a UE supporting V2X application and a V2X application server.

[R.5.1-024]

The 3GPP system shall provide a mechanism to provide addressing information (e.g. IP address or FQDN) of V2X application server(s) to the UEs supporting V2X applications.

[R.5.1-025]

The 3GPP system shall allow the UE to use multiple 3GPP RATs (i.e. NR & E-UTRA) simultaneously for direct communication.

5.2 Requirements to support Vehicles Platooning p. 8

[R.5.2-001]

The 3GPP system shall be able to support up to 5 UEs for a group of UEs supporting V2X application.

[R.5.2-002]

For Vehicle Platooning, the 3GPP system shall be able to support reliable V2V communications between a specific UE supporting V2X applications and up to 19 other UEs supporting V2X applications.

[R.5.2-003]

The 3GPP system shall support relative longitudinal position accuracy of less than 0.5 m for UEs supporting V2X application for platooning in proximity.

Table 5.2-1: Performance requirements for Vehicles Platooning

Communication scenario description		Req #	Payload (Bytes)	Tx rate (Message/ Sec)	Max end-to-end latency (ms)	Reliability (%) (NOTE 5)	Data rate (Mbps)	Min required communication range (meters) (NOTE 6)
Scenario	Degree	Req #	Payload (Bytes)	Tx rate (Message/ Sec)	Max end-to-end latency (ms)	Reliability (%) (NOTE 5)	Data rate (Mbps)	Min required communication range (meters) (NOTE 6)
Cooperative driving for vehicle platooning Information exchange between a group of UEs supporting V2X application.	Lowest degree of automation	[R.5.2-004]	300-400 (NOTE 2)	30	25	90
	Low degree of automation	[R.5.2-005]	6500 (NOTE 3)	50	20			350
	Highest degree of automation	[R.5.2-006]	50-1200 (NOTE 4)	30	10	99.99		80
	High degree of automation	[R.5.2-007]			20		65 (NOTE 3)	180
Reporting needed for platooning between UEs supporting V2X application and between a UE supporting V2X application and RSU.	N/A	[R.5.2-008]	50-1200	2	500
Information sharing for platooning between UE supporting V2X application and RSU.	Lower degree of automation	[R.5.2-009]	6000 (NOTE 3)	50	20			350
	Higher degree of automation	[R.5.2-0010]			20		50 (NOTE 3)	180
NOTE 2: This value is applicable for both triggered and periodic transmission of data packets. NOTE 3: The data that is considered in this V2X scenario includes both cooperative manoeuvres and cooperative perception data that could be exchanged using two separate messages within the same period of time (e.g., required latency 20ms). NOTE 4: This value does not including security related messages component. NOTE 5: Sufficient reliability should be provided even for cells having no value in this table NOTE 6: This is obtained considering UE speed of 130km/h. All vehicles in a platoon are driving in the same direction.

5.3 Requirements to support Advanced Driving p. 10

Table 5.3-1: Performance requirements for advanced driving

Communication scenario description		Req #	Payload (Bytes)	Tx rate (Message/ Sec)	Max end-to-end latency (ms)	Reliability (%) (NOTE 3)	Data rate (Mbps)	Min required communication range (meters) (NOTE 4)
Scenario	Degree	Req #	Payload (Bytes)	Tx rate (Message/ Sec)	Max end-to-end latency (ms)	Reliability (%) (NOTE 3)	Data rate (Mbps)	Min required communication range (meters) (NOTE 4)
Cooperative collision avoidance between UEs supporting V2X applications		[R.5.3-001]	2000 (NOTE 5)	100 (NOTE 5)	10	99.99	10 (NOTE 1)
Information sharing for automated driving between UEs supporting V2X application	Lower degree of automation	[R.5.3-002]	6500 (NOTE 1)	10	100			700
	Higher degree of automation	[R.5.3-003]			100		53 (NOTE 1)	360
Information sharing for automated driving between UE supporting V2X application and RSU	Lower degree of automation	[R.5.3-004]	6000 (NOTE 1)	10	100			700
	Higher degree of automation	[R.5.3-005]			100		50 (NOTE 1)	360
Emergency trajectory alignment between UEs supporting V2X application		[R.5.3-006]	2000 (NOTE 5)		3	99.999	30	500
Intersection safety information between an RSU and UEs supporting V2X application		[R.5.3-007]	UL: 450	UL: 50			UL: 0. 25 DL: 50 (NOTE 2)
Cooperative lane change between UEs supporting V2X applications	Lower degree of automation	[R.5.3-008]	300-400		25	90
	Higher degree of automation	[R.5.3-009]	12000		10	99.99
Video sharing between a UE supporting V2X application and a V2X application server		[R.5.3-010]					UL: 10
NOTE 1: This includes both cooperative manoeuvers and cooperative perception data that could be exchanged using two separate messages within the same period of time (e.g., required latency 100ms). NOTE 2: This value is referring to a maximum number of 200 UEs. The value of 50 Mbps DL is applicable to broadcast or is the maximum aggregated bitrate of the all UEs for unicast. NOTE 3: Sufficient reliability should be provided even for cells having no values in this Table. NOTE 4: This is obtained considering UE speed of 130km/h. Vehicles may move in different directions. NOTE 5: These values are based on calculations for cooperative maneuvers only.

5.4 Requirements to support Extended Sensors p. 11

Table 5.4-1: Performance requirements for extended sensors

Communication scenario description		Req #	Payload (Bytes)	Tx rate (Message/ Sec)	Max end-to-end latency (ms)	Reliability (%)	Data rate (Mbps)	Min required communication range (meters)
Scenario	Degree	Req #	Payload (Bytes)	Tx rate (Message/ Sec)	Max end-to-end latency (ms)	Reliability (%)	Data rate (Mbps)	Min required communication range (meters)
Sensor information sharing between UEs supporting V2X application	Lower degree of automation	[R.5.4-001]	1600	10	100	99		1000
	Higher degree of automation	[R.5.4-002]			10	95	25 (NOTE 1)
		[R.5.4-003]			3	99.999	50	200
		[R.5.4-004]			10	99.99	25	500
		[R.5.4-005]			50	99	10	1000
		[R.5.4-006] (NOTE 2)			10	99.99	1000	50
Video sharing between UEs supporting V2X application	Lower degree of automation	[R.5.4-007]			50	90	10	100
	Higher degree of automation	[R.5.4-008]			10	99.99	700	200
	Higher degree of automation	[R.5.4-009]			10	99.99	90	400
NOTE 1: This is peak data rate. NOTE 2: This is for imminent collision scenario.

5.5 Requirements to support Remote Driving p. 11

[R.5.5-001]

The 3GPP system shall support message exchange between a UE supporting V2X application and V2X application server for an absolute speed of up to 250 km/h.

Table 5.5-1: Performance requirements for remote driving

Communication scenario description	Req #	Max end-to-end latency (ms)	Reliability (%)	Data rate (Mbps)
Information exchange between a UE supporting V2X application and a V2X Application Server	[R.5.5-002]	5	99.999	UL: 25 DL: 1

5.6 Requirements to support vehicle quality of service p. 11

[R.5.6-001]

The 3GPP system shall be able to provide a standardized interface to V2X applications to enable the V2X application to adjust its service offerings based on the quality of service of the ongoing connection or on the estimated quality of service.

[R.5.6-002]

The 3GPP system shall be able to authenticate and authorize V2X application for requesting information on the quality of service of the ongoing connection or on the estimated quality of service.

[R.5.6-003]

The 3GPP system shall be able to provide quality of service information to the V2X application in a resource efficient way.

[R.5.6-004]

The 3GPP system shall be able to support an efficient and secure mechanism to gather information (e.g. location information, reliability information, timing information, latency information, velocity information), in order to generate information about quality of service in a resource efficient way.

[R.5.6-005]

The 3GPP system shall be able to support continuity of reporting estimated quality of service for a UE even when the PLMN serving the UE changes.

[R.5.6-006]

The 3GPP system shall be able to provide V2X applications with estimated quality of service information for a certain geographic area and time.

[R.5.6-007]

The 3GPP system shall be able to provide a V2X application with quality of service parameters that can be provisioned for connection for a certain geographic area in a certain time.

[R.5.6-008]

The 3GPP system shall be able to notify V2X applications with updated estimation of unfulfillment (or re-fulfilment) of quality of service for a certain geographic area, at least a certain amount of time before when the actual change occurs.

[R.5.6-009]

On request by the V2X application, the 3GPP system shall be able to provide information on whether connectivity with specific quality of service is expected to be fulfilled in a certain geographical area and at a certain time.

[R.5.6-010]

The 3GPP network shall notify a V2X application that the current quality of service of a UE's ongoing communication might be unfulfilled (or re-fulfilled) in the future.

[R.5.6-011]

The 3GPP system shall be able to support negotiating quality of service alternatives with the V2X application.

[R.5.6-012]

The 3GPP system shall be able to provide V2X applications with updated quality of service from the quality of service alternatives previously negotiated by the V2X application, when the quality of service of the UE's ongoing connection changes.

[R.5.6-013]

The 3GPP system shall be able to support a V2X application to request connectivity with specific quality of service parameter for a certain geographic area and time.

[R.5.6-014]

The 3GPP system shall be able to provide a V2X application with response on whether the request of connectivity service with specific quality of service parameter for a certain geographic area and a certain time is accepted or not.

A Background information on service Requirements p. 13

For each requirement in this specification, Table A-1 indicates reference to the consolidated potential requirements in TR 22.886:

Table A-1: Reference information for requirements

Requirement # in this specification	CPR # in TR 22.886
[R.5.1-001]	[CPR.G-001]
[R.5.1-002]	[CPR.G-002]
[R.5.1-003]	[CPR.G-003]
[R.5.1-004]	[CPR.G-004]
[R.5.1-005]	[CPR.G-005]
[R.5.1-006]	[CPR.G-006]
[R.5.1-007]	[CPR.G-007]
[R.5.1-008]	[CPR.G-009]
[R.5.1-009]	[CPR.G-010]
[R.5.1-010]	[CPR.G-011]
[R.5.1-011]	[CPR.G-012]
[R.5.1-012]	[CPR.G-013]
[R.5.1-013]	[CPR.G-014]
[R.5.1-014]	[CPR.G-016]
[R.5.1-015]	[CPR.G-017]
[R.5.1-016]	[CPR.G-018]
[R.5.1-017]	[CPR.G-019]
[R.5.1-018]	[CPR.G-020]
[R.5.1-019]	[CPR.G-021]
[R.5.1-020]	[CPR.G-022]
[R.5.1-021]	[CPR.G-022]
[R.5.1-022]	[CPR.G-023]
[R.5.1-023]	[CPR.G-025]
[R.5.2-001]	[CPR.P-001]
[R.5.2-002]	[CPR.P-002]
[R.5.2-003]	[CPR.P-003]
[R.5.2-004]	[CPR.P-005]
[R.5.2-004]	[CPR.P-007]
[R.5.2-005]	[CPR.P-009]
[R.5.2-006]	[CPR.P-008]
[R.5.2-006]	[CPR.P-004]
[R.5.2-007]	[CPR.P-010]
[R.5.2-008]	[CPR.P-006]
[R.5.2-009]	[CPR.P-011]
[R.5.2-010]	[CPR.P-012]
[R.5.3-001]	[CPR.A-001]
[R.5.3-002]	[CPR.A-002]
[R.5.3-003]	[CPR.A-003]
[R.5.3-004]	[CPR.A-004]
[R.5.3-005]	[CPR.A-005]
[R.5.3-006]	[CPR.A-006]
[R.5.3-007]	[CPR.A-007]
[R.5.3-008]	[CPR.A-008]
[R.5.3-009]	[CPR.A-009]
[R.5.3-010]	[CPR.A-010]
[R.5.4-001]	[CPR.E-002]
[R.5.4-002]	[CPR.E-001]
[R.5.4-003]	[CPR.E-003]
[R.5.4-004]	[CPR.E-004]
[R.5.4-005]	[CPR.E-005]
[R.5.4-006]	[CPR.E-006]
[R.5.4-007]	[CPR.E-007]
[R.5.4-008]	[CPR.E-008]
[R.5.4-009]	[CPR.E-008]
[R.5.5-001]	[CPR.R-001]
[R.5.5-002]	[CPR.R-001] [CPR.R-002] [CPR.R-003] [CPR.R-004]
[R.5.6-001]	[CPR.Q-015]
[R.5.6-002]	[CPR.Q-009]
[R.5.6-003]	[CPR.Q-002]
[R.5.6-004]	[CPR.Q-002]
[R.5.6-005]	[CPR.Q-004]
[R.5.6-006]	[CPR.Q-001]
[R.5.6-007]	[CPR.Q-006]
[R.5.6-008]	[CPR.Q-017]
[R.5.6-009]	[CPR.Q-011]
[R.5.6-010]	[CPR.Q-018]
[R.5.6-011]	[CPR.Q-007]
[R.5.6-012]	[CPR.Q-019]
[R.5.6-013]	[CPR.Q-012]
[R.5.6-014]	[CPR.Q-013]

B Relation between TS 22.185 and this TS p. 15

3GPP Technical Specification on Service Requirements for V2X Services [3] was developed with focus on basic safety aspect and non-safety aspect using LTE-based technology. This Technical Specification on Enhancement of 3GPP Support for V2X Services was developed with focus on enhancements of V2X Use Case scenarios, including more rigorous functional requirements for advanced features that cannot be achieved by [3].

C Relationship between V2X applications and V2X requirements p. 16

In this specification, performance requirements for various scenarios are defined. KPIs of the various scenarios are not mutually exclusive. When several V2X applications are simultaneously running in the vehicle, total performance requirement to serve that vehicle is not the sum of individual performance requirement of each V2X application:

Different use cases or applications may use and share same V2X message. For example, according to ETSI TS 102.637, information included in a DENM message can be used by multiple applications such as emergency electronic brake lights, wrong way driving warning and so on. Thus, there is no need for each application to generate separately V2X messages.
According to ETSI EN 302.665, V2X application layer is separated from V2X Facilities layer. V2X applications do not have V2X message handling capabilities, and this is left to V2X Facilities layer. Because V2X Facilities layer serves all V2X applications, the V2X Facilities layer can optimize V2X message handling, by considering overall requirements of different V2X applications.

Figure C-1 shows one of example configuration where multiples V2X applications and one common V2X message handling entity exist. Because only one driving wheel, one accelerator and one brake exist in a vehicle, the applications in a vehicle may either be combined or operate in a harmonized fashion. Then, V2X messages are also used in a harmonized fashion.

Reproduction of 3GPP TS 22.186, Fig. C-1: Relationship between V2X messages and Applications (illustrative purpose only)

Figure C-1: Relationship between V2X messages and Applications (illustrative purpose only)

D Role model for service exposure for Estimation p. 17

In relation to the service requirements in clause 5.6, following figure shows the role model for the involved entities. Data gathering entity gathers relevant data that can be used as an input to estimation entity. The data can be statistical data, historical data and etc. Based on the data provided by data gathering entity, estimation entity makes an estimation that is requested by third parties. The result of estimation is provided from 3GPP system to third party. While interface from 3GPP system toward third party and interface among entities within 3GPP system is standardized, how actual estimation mechanism is performed within estimation entity or how much the estimation is accurate is out of 3GPP scope.