5 Requirements
22.1863GPPRelease 17Service requirements for enhanced V2X scenariosTS
5.1 General Requirements
[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.
NOTE 1: The determination of group membership may be done at the upper layers and/or lower layers (application and/or Layer 2).
[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.
NOTE 2: Example estimate is for worst case US Freeway scenario that does not include arterial roads (i.e. onramps): 5 lanes in each direction or 10 lanes total per highway, for up to 3 highways intersecting = 3,100 to 4,300 cars per square kilometer
[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.
NOTE 3: Different V2X applications can be identified by use of different ITS-AID or PSID.
[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.
NOTE 4: This requirement specifies the number of UEs that RSU should be capable of handling. The requirement is not applied to the number of UE in a platoon.
NOTE 5: This requirement is not applied to UE-type RSU.
[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
[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.
NOTE 1: For group of heavy goods vehicle platooning, the number of UEs in a platoon can be smaller, due to communication range, the length of truck, inter-truck distance, etc.
[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 |
|||||||
|
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 |
[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 |
[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 |
[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
Table 5.3-1 Performance requirements for advanced driving
|
Communication scenario description |
Req # |
Payload (Bytes) |
Tx rate (Message/Sec) |
Max (ms) |
Reliability (%) (NOTE3) |
Data rate (Mbps) |
Min required Communication range (meters) (NOTE 4) |
|
|
Scenario |
Degree |
|||||||
|
Cooperative collision avoidance between UEs supporting V2X applications. |
[R.5.3-001] |
2000 (NOTE 5) |
100 |
10 |
99.99 |
10 (NOTE 1) |
||
|
Information sharing for automated driving between UEs supporting V2X application. |
Lower |
[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 |
[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 |
[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
Table 5.4-1 Performance requirements for extended sensors
|
Communication scenario description |
Req # |
Payload (Bytes) |
Tx rate (Message /Sec) |
Max latency (ms) |
Reliability (%) |
Data rate (Mbps) |
Min required communication range (meters) |
|
|
Scenario |
Degree |
|||||||
|
Sensor information sharing between UEs supporting V2X application |
Lower |
[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 |
[R.5.4-007] |
50 |
90 |
10 |
100 |
||
|
Higher degree of automation |
[R.5.4-008] |
10 |
99.99 |
700 |
200 |
|||
|
[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
[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
[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.
Annex A (informative):
Background information on service Requirements
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] |
Annex B (informative):
Relation between TS 22.185 and this TS
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].
Annex C (informative):
Relationship between V2X applications and V2X requirements
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.
Figure C-1. Relationship between V2X messages and Applications (illustrative purpose only)
Annex D (informative):
Role model for service exposure for Estimation
In relation to the service requirements in section 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.
Annex E (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-01 |
Skeleton |
0.1.0 |
|||||
|
2017-02 |
Update based on agreement in SA1 #77 |
0.2.0 |
|||||
|
2017-03 |
SA#75 |
SP-170158 |
MCC Clean-up |
1.0.0 |
|||
|
2017-03 |
SA#75 |
SP-170250 |
Update based on input from SA#75, including assigned TS number |
1.0.1 |
|||
|
2017-03 |
Raised to v.15.0.0 following SA’s approval |
15.0.0 |
|||||
|
Change history |
|||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
TSG SA# |
SA Doc. |
SA1 Doc |
Spec |
CR |
Rev |
Rel |
Cat |
Subject/Comment |
Old |
New |
Work Item |
|
SP-170444 |
0006 |
4 |
B |
Adding requirement on addressing information of V2X application server(s) |
15.0.0 |
15.1.0 |
|||||
|
SP-170444 |
0003 |
1 |
F |
Clean-up of KPI of eV2X TS |
15.0.0 |
15.1.0 |
|||||
|
SP-170444 |
0008 |
3 |
F |
Consolidate communication range in 5.3 Advanced Driving |
15.0.0 |
15.1.0 |
|||||
|
SP-170444 |
0009 |
2 |
F |
Correction of NOTE 2 UL/DL values in 5.3 Advanced Driving |
15.0.0 |
15.1.0 |
|||||
|
SP-170444 |
0007 |
1 |
D |
Editorial modifications for TS 22.186 |
15.0.0 |
15.1.0 |
|||||
|
SP-170444 |
0012 |
1 |
D |
Global editorial clean-up |
15.0.0 |
15.1.0 |
|||||
|
SP-170444 |
0001 |
2 |
F |
Removal of editor’s NOTE in section 5.1 |
15.0.0 |
15.1.0 |
|||||
|
SP-170444 |
0010 |
2 |
C |
Remove the brakets and Editor’s note in Video sharing of 5.4 Extended Sensors |
15.0.0 |
15.1.0 |
|||||
|
SP-77 |
SP-170693 |
S1-173479 |
22.186 |
0013 |
2 |
Rel-15 |
F |
Correction to information exchange via RSU |
15.1.0 |
15.2.0 |
eV2X |
|
SP-77 |
SP-170693 |
S1-173480 |
22.186 |
0015 |
2 |
Rel-15 |
F |
correction to data rate and transmission rate |
15.1.0 |
15.2.0 |
eV2X |
|
SP-180309 |
0016 |
2 |
F |
Update the note in the RSU definition |
15.2.0 |
15.3.0 |
|||||
|
SP-81 |
SP-180755 |
S1-182626 |
22.186 |
0018 |
1 |
Rel-16 |
A |
SAE International’s Levels of Automation reference link |
15.3.0 |
16.0.0 |
eV2X |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2018-12 |
SP-82 |
SP-181012 |
0019 |
4 |
B |
normative requirements for V2XIMP |
16.1.0 |
|
2018-12 |
SP-82 |
SP-181012 |
0020 |
2 |
B |
Annex Role model for V2XIMP |
16.1.0 |
|
2019-06 |
SA#84 |
SP-190568 |
0023 |
6 |
F |
CR to TS 22.186 on eV2X Requirements |
16.2.0 |
|
2022-03 |
SA#95e |
– |
– |
– |
– |
Updated to Rel-17 by MCC |
17.0.0 |