TS 22.185
★
Service Requirements for V2X Services
Use "3GPP‑Page" to get the Word version,
and "ETSI‑search" to get the PDF version
V16.0.0 (PDF)
2020/06 16 p.
V15.0.0
2018/06 16 p.
V14.4.0
2018/06 16 p.
- Rapporteur:
- Dr. Lee, Ki-Dong LG Electronics Inc.
Content for TS 22.185 Word version: 16.0.0
1 Scope Word‑p. 5
The present document provides 3GPP support for V2X service requirements to be supported by LTE transport. These requirements are identified by taking into account the V2X service requirements defined in other SDOs, e.g. ETSI ITS, US SAE. The specification includes requirements of safety and non-safety aspects.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
3 Definitions and abbreviations
3.1 Definitions
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.
Road Side Unit:
A stationary infrastructure entity supporting V2X applications that can exchange messages with other entities supporting V2X applications.
Pseudonymity:
The condition when the processing of personally identifiable information is such the data can no longer be attributed to a specific subscriber without the use of additional information, as long as such additional information is kept separately and subject to technical and organisational measures to ensure non-attribution to an identified or identifiable subscriber.
3.2 Abbreviations
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.
RSU
Road Side Unit
V2I
Vehicle-to-Infrastructure
V2N
Vehicle-to-Network
V2P
Vehicle-to-Pedestrian
V2V
Vehicle-to-Vehicle
V2X
Vehicle-to-Everything
4 Overview on V2X (informative) Word‑p. 6
4.1 Types of V2X application support in 3GPP
4.1.1 General
The V2X applications in the present specification, referred to as Vehicle-to-Everything (V2X), contain the following four different types:
-
Vehicle-to-Vehicle (V2V)
-
Vehicle-to-Infrastructure (V2I)
-
Vehicle-to-Network (V2N)
-
Vehicle-to-Pedestrian (V2P)
[not reproduced yet]
Figure 4.1.1-1: Types of V2X applications (V2V, V2P, V2N and V2I)
These four types of V2X applications can use "co-operative awareness" to provide more intelligent services for end-users. This means that entities, such as vehicles, roadside infrastructure, application server and pedestrians, can collect knowledge of their local environment (e.g., information received from other vehicles or sensor equipment in proximity) to process and share that knowledge in order to provide more intelligent services, such as cooperative collision warning or autonomous driving.
These intelligent transportation services and the associated message sets have been defined in automotive SDOs outside 3GPP. Three basic classes of applications for providing ITS services: road safety, traffic efficiency, and other applications can be found in e.g., [3].
3GPP only handles the transport of these messages to support different types of V2X applications. The message transport expectations are described in requirements defined in this specification.
4.1.2 Vehicle-to-Vehicle (V2V) application
V2V applications expect UEs that are in proximity of each other to exchange V2V application information. 3GPP transport of messages containing V2V application information requires the UE to have a valid subscription and authorization from a network operator. Transport for a valid subscriber is provided whether the UE is served or not served by E-UTRAN.
The UE supporting V2V applications transmits messages containing V2V application information (e.g. location, dynamics, and attributes). The message payloads may be flexible in order to accommodate varying amount of information.
3GPP transport of message containing V2V application information is predominantly broadcast-based as illustrated in Figure 4.1-2. Such 3GPP transport includes the transport between UEs directly and/or, due to the limited direct communication range, the transport between UEs via infrastructure supporting V2X communication, e.g., RSU, application server, etc.
[not reproduced yet]
Figure 4.1.2-1: Broadcast-based V2V communications
4.1.3 Vehicle-to-Infrastructure (V2I) application Word‑p. 7
The UE supporting V2I applications transmits messages containing V2I application information to an RSU or locally relevant application server. The RSU and/or the locally relevant application server transmit messages containing V2I application information to one or more UEs supporting V2I applications.
A locally relevant application server serves a particular geographic area. There can be multiple application servers serving overlapping areas, providing the same or different applications.
4.1.4 Vehicle-to-Network (V2N) application
The UE supporting V2N applications communicates with an application server supporting V2N applications. Both parties communicate with each other via EPS.
4.1.5 Vehicle-to-Pedestrian (V2P) application
V2P applications expect UEs that are in proximity of each other to exchange V2P application information. 3GPP transport of messages containing V2P application information requires the UE to have a valid subscription and authorization from a network operator. Transport for a valid subscriber is provided whether the UE is served or not served by E-UTRAN.
The UE supporting V2P applications transmits messages containing V2P application information. It is expected that V2P application information can be transmitted either by a UE supporting V2X application in a vehicle (e.g., warning to pedestrian), or by a UE supporting V2X application associated with a vulnerable road user (e.g., warning to vehicle).
3GPP transport of messages containing V2P application information includes the transport between UEs directly and/or, due to the limited direct communication range, the transport between UEs via infrastructure supporting V2X communication, e.g., RSU, application server, etc.
4.2 Relative priority of V2X communication Word‑p. 8
Subject to regional/national regulatory requirements and operator policies, certain mission critical services (e.g. Public Safety, MPS) can be relatively prioritized over transport of V2X application information. Transport of safety-related V2X application information can be prioritized over transport of non-safety-related V2X application information.
However, in general, it is expected that operator can control relative priorities of different services.
5 Requirements
5.1 Overall Requirements
[R-5.1-001]
The message transmission shall be under control of the 3GPP network when the transmitting UE is served by the E-UTRAN.
[R-5.1-002]
A UE supporting V2X application shall be able to be pre-configured by the 3GPP network with parameters to be used for the transmission and reception of messages when not served by E-UTRAN supporting V2X communication.
[R-5.1-003]
A UE supporting V2X application shall be able to transmit and receive messages when served or not served by E-UTRAN supporting V2X communication.
[R-5.1-004]
An RSU shall be able to transmit/receive messages to/from a UE supporting V2X application.
[R-5.1-005]
The 3GPP system shall be able to support message transfer between UEs when served or not served by the same PLMN supporting V2X communications.
[R-5.1-006]
The 3GPP system shall be able to provide means to prioritize message transmission among UEs supporting V2X application
[R-5.1-007]
The 3GPP system shall be able to provide means to prioritize transmission of messages according to their type (e.g. safety vs. non-safety).
[R-5.1-008]
The 3GPP system shall be able to vary the transmission rate and range of the V2X communication based on service conditions (e.g., UE speed, UE density).
[R-5.1-009]
The 3GPP system shall be able to distribute information in a resource efficient way to large numbers of UEs supporting V2X application.
[R-5.1-010]
A UE supporting V2X application shall be able to identify whether E-UTRAN supports V2X communication.
[R-5.1-011]
The 3GPP system shall be able to provide means for an application server and the RSU to control the area and the size of the area where the messages are being distributed.
[R-5.1-011a]
The 3GPP system shall be able to provide means for distribution of messages from a UE supporting V2X application to locally relevant application servers.
[R-5.1-012]
The E-UTRA(N) shall be able to support a high density of UEs supporting V2X application.
[R-5.1-013]
Both the HPLMN and VPLMN operators shall be able to charge for network resource usage when messages are transferred by a UE supporting V2X application.
[R-5.1-014]
For UE supporting V2X application with limited resources (e.g., battery), the impact on its resources (e.g., battery consumption) due to message transfer should be minimized.
[R-5.1-015]
The 3GPP network should make available any supported positional accuracy improvement techniques (e.g., DGPS and/or OTDOA) in a resource efficient way to a subscribed UE supporting V2X application.
5.2 Specific Service Requirements Word‑p. 9
5.2.1 Latency/ Reliability Requirements
[R-5.2.1-001]
The E-UTRA(N) shall be capable of transferring messages between two UEs supporting V2V/P application, directly or via an RSU, with a maximum latency of 100ms.
[R-5.2.1-002]
For particular usage (i.e., pre-crash sensing) only, the E-UTRA(N) should be capable of transferring messages between two UEs supporting V2V application with a maximum latency of 20ms.
[R-5.2.1-003]
The E-UTRA(N) shall be capable of transferring messages between a UE supporting V2I application and an RSU with a maximum latency of 100ms.
[R-5.2.1-004]
The E-UTRAN shall be capable of transferring messages via 3GPP network entities between a UE and an application server both supporting V2N application with an end-to-end delay no longer than 1000 ms.
[R-5.2.1-005]
The E-UTRA(N) shall be able to support high reliability without requiring application-layer message retransmissions.
5.2.2 Message Size Requirements
[R-5.2. 2-001]
The E-UTRA(N) shall be capable of transferring periodic broadcast messages between two UEs supporting V2X application with variable message payloads of 50-300 bytes, not including security-related message component.
[R-5.2. 2-002]
The E-UTRA(N) shall be capable of transferring event-triggered messages between two UEs supporting V2X application with variable message payloads which can be up to 1200 bytes, not including security-related message component.
5.2.3 Frequency Requirements
[R-5.2.3-001]
The E-UTRA(N) shall be able to support a maximum frequency of 10 messages per second per transmitting UE .
5.2.4 Range Requirements
[R-5.2.4-001]
The E-UTRAN shall be capable of supporting a communication range sufficient to give the driver(s) ample response time (e.g. 4 seconds).
5.2.5 Speed Requirements
[R-5.2.5-001]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V application, while the maximum relative velocity of the UEs is 500 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
[R-5.2.5-002]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V and V2P application, respectively, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
[R-5.2.5-003]
The 3GPP system shall be capable of transferring messages between a UE and an RSU both supporting V2I application, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE or the RSU is served or not served by E-UTRAN supporting V2X communication.
5.3 Security Requirements Word‑p. 10
[R.5.3-001]
The 3GPP network shall provide a means for the MNO to authorize a UE supporting V2X application to perform V2X communication when served by E-UTRAN supporting V2X communication.
[R.5.3-002]
The 3GPP network shall provide a means (e.g., pre-authorization) for the MNO to authorize a UE supporting V2X application to perform V2X communication when not served by E-UTRAN supporting V2X communication.
[R.5.3-003]
The 3GPP network shall provide a means for the MNO to authorize UEs supporting V2X application separately to perform V2N communication.
[R.5.3-004]
The 3GPP system shall support integrity protection of the transmission for a V2X application.
[R.5.3-005]
Subject to regional regulatory requirements and/or operator policy for a V2X application, the 3GPP system shall support pseudonymity and privacy of a UE using the V2X application, by ensuring that a UE identity cannot be tracked or identified by any other UE beyond a certain short time-period required by the V2X application.
[R.5.3-006]
Subject to regional regulatory requirements and/or operator policy for a V2V/V2I application, the 3GPP system shall support pseudonymity and privacy of a UE in the use of a V2V/V2I application, such that no single party (operator or third party) can track a UE identity in that region.
A Background Information on Service Requirement Word‑p. 11
The basic categories of V2X services for V2X decribed in the TR 22.885 can be grouped into the following main categories based on ITS defintion of basic set of services [3] :
-
Road Safety Requirements e.g Queue warning use case related requirements
-
Mutual Vehicle Awarness - Information only e.g forward collision warning requirements
-
Vehicle Related Application Requirements e.g Automated parking system requirement
Clause 5.2 refers to specific service requirements which are categoried as:
Latency/Reliability Requirements:
Maximum tolerable elapsed time from the instant a data packet is generated at the source application to the instant it is received by the destination application. Low Latency values are provided to support services in the case of mutual awareness of vehicle or to send warning messages as defined in the some use cases in TR 22.885
Reliability:
Maximum tolerable packet loss rate at the application layer, a packet is considered lost if it is not received by the destination application within the maximum tolerable end-to-end latency for that application.
Message Size Requirements:
Messages sizes are important when multicast or broadcast messages are being sent to vehicles within range to either warn them for collision prevention or when an event occurs to inform other vehicle about an accident.
Frequency Requirements:
Minimum required bit rate for the application to function correctly. The sending rates i.e frequency of messages is relatively important especially for critical vehicular safety application.
Range Requirements:
Maximum distance between source and destination(s) of a radio transmission within which the application should achieve the specified reliability
Speed Requirements:
Maximum relative and absolute speed under which the specified reliability should be achieved.
With this brief description of the service categories, the table suggested below is used to reference the specific requirements in clause 5.2 to some of the use cases in the TR which makes for easy understanding and for better clarification of the suggested application of the services:
TS requirement
Requirement
Potential V2X service
Use case Requirement in TR 22.885
Latency Requirement
[R-5.2.1-001]
The E-UTRA(N) shall be capable of transferring messages between two UEs supporting V2V/P application, directly or via an RSU, with a maximum latency of 100ms.
Typical use case is for Mutual Vehicle Awareness and Road safety
[CPR-014]
[R-5.2.1-002]
For particular usage (i.e., pre-crash sensing) only, the E-UTRA(N) should be capable of transferring messages between two UEs supporting V2V application with a maximum latency of 20ms.
Requirement applies in Road safety use cases
[CPR-015]
[R-5.2.1-003]
The E-UTRA(N) shall be capable of transferring messages between a UE supporting V2I application and an RSU with a maximum latency of 100ms.
Requirement applys in Road safety use cases
[CPR-016]
[R-5.2.1-004]
The E-UTRAN shall be capable of transferring messages via 3GPP network entities between a UE and an application server both supporting V2N application with an end-to-end delay no longer than 1000 ms.
Applys to Mutual Vehicle Awareness use case
[CPR-017]
[R-5.2.1-005]
The E-UTRA(N) shall be able to support high reliability without requiring application-layer message retransmissions.
Mutual Vehicle Awareness and Road safety cases
[CPR-027]
Message Size
[R-5.2. 2-001]
The E-UTRA(N) shall be capable of transferring periodic broadcast messages between two UEs supporting V2X application with variable message payloads of 50-300 bytes, not including security-related message component.
Supports all three use case categories
[CPR-019]
[R-5.2. 2-002]
The E-UTRA(N) shall be capable of transferring event-triggered messages between two UEs supporting V2X application with variable message payloads which can be up to 1200 bytes, not including security-related message component.
Mostly Road safety applications
[CPR-020]
Frequency
[R-5.2.3-001]
The E-UTRA(N) shall be able to support a maximum frequency of 10 messages per second per UE or per RSU.
Road safety and Mutual Vehicle Awareness
[CPR-011]
Range Requirement
[R-5.2.4-001]
The E-UTRAN shall be capable of supporting a communication range sufficient to give the driver(s) ample response time (e.g. 4 seconds).
[CPR-005]
Speed Requirement
[R-5.2.5-001]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V application, while the maximum relative velocity of the UEs is 500 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
Road Safety, Mutual Vehicle Awareness
[CPR-030]
[R-5.2.5-002]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V and V2P application, respectively, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
Road Safety, Mutual Vehicle Awareness
[CPR-031]
[R-5.2.5-003]
The 3GPP system shall be capable of transferring messages between a UE and an RSU both supporting V2I application, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE or the RSU is served or not served by E-UTRAN supporting V2X communication.
Road Safety, Mutual Vehicle Awareness
[CPR-031]
$ Change history Word‑p. 14
3.1 Definitions
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.
Road Side Unit:
A stationary infrastructure entity supporting V2X applications that can exchange messages with other entities supporting V2X applications.
Pseudonymity:
The condition when the processing of personally identifiable information is such the data can no longer be attributed to a specific subscriber without the use of additional information, as long as such additional information is kept separately and subject to technical and organisational measures to ensure non-attribution to an identified or identifiable subscriber.
3.2 Abbreviations
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.
RSU
Road Side Unit
V2I
Vehicle-to-Infrastructure
V2N
Vehicle-to-Network
V2P
Vehicle-to-Pedestrian
V2V
Vehicle-to-Vehicle
V2X
Vehicle-to-Everything
4.1 Types of V2X application support in 3GPP
4.1.1 General
The V2X applications in the present specification, referred to as Vehicle-to-Everything (V2X), contain the following four different types:
- Vehicle-to-Vehicle (V2V)
- Vehicle-to-Infrastructure (V2I)
- Vehicle-to-Network (V2N)
- Vehicle-to-Pedestrian (V2P)
[not reproduced yet]
Figure 4.1.1-1: Types of V2X applications (V2V, V2P, V2N and V2I)
These four types of V2X applications can use "co-operative awareness" to provide more intelligent services for end-users. This means that entities, such as vehicles, roadside infrastructure, application server and pedestrians, can collect knowledge of their local environment (e.g., information received from other vehicles or sensor equipment in proximity) to process and share that knowledge in order to provide more intelligent services, such as cooperative collision warning or autonomous driving.
These intelligent transportation services and the associated message sets have been defined in automotive SDOs outside 3GPP. Three basic classes of applications for providing ITS services: road safety, traffic efficiency, and other applications can be found in e.g., [3].
3GPP only handles the transport of these messages to support different types of V2X applications. The message transport expectations are described in requirements defined in this specification.
4.1.2 Vehicle-to-Vehicle (V2V) application
V2V applications expect UEs that are in proximity of each other to exchange V2V application information. 3GPP transport of messages containing V2V application information requires the UE to have a valid subscription and authorization from a network operator. Transport for a valid subscriber is provided whether the UE is served or not served by E-UTRAN.
The UE supporting V2V applications transmits messages containing V2V application information (e.g. location, dynamics, and attributes). The message payloads may be flexible in order to accommodate varying amount of information.
3GPP transport of message containing V2V application information is predominantly broadcast-based as illustrated in Figure 4.1-2. Such 3GPP transport includes the transport between UEs directly and/or, due to the limited direct communication range, the transport between UEs via infrastructure supporting V2X communication, e.g., RSU, application server, etc.
[not reproduced yet]
Figure 4.1.2-1: Broadcast-based V2V communications
4.1.3 Vehicle-to-Infrastructure (V2I) application Word‑p. 7
The UE supporting V2I applications transmits messages containing V2I application information to an RSU or locally relevant application server. The RSU and/or the locally relevant application server transmit messages containing V2I application information to one or more UEs supporting V2I applications.
A locally relevant application server serves a particular geographic area. There can be multiple application servers serving overlapping areas, providing the same or different applications.
4.1.4 Vehicle-to-Network (V2N) application
The UE supporting V2N applications communicates with an application server supporting V2N applications. Both parties communicate with each other via EPS.
4.1.5 Vehicle-to-Pedestrian (V2P) application
V2P applications expect UEs that are in proximity of each other to exchange V2P application information. 3GPP transport of messages containing V2P application information requires the UE to have a valid subscription and authorization from a network operator. Transport for a valid subscriber is provided whether the UE is served or not served by E-UTRAN.
The UE supporting V2P applications transmits messages containing V2P application information. It is expected that V2P application information can be transmitted either by a UE supporting V2X application in a vehicle (e.g., warning to pedestrian), or by a UE supporting V2X application associated with a vulnerable road user (e.g., warning to vehicle).
3GPP transport of messages containing V2P application information includes the transport between UEs directly and/or, due to the limited direct communication range, the transport between UEs via infrastructure supporting V2X communication, e.g., RSU, application server, etc.
4.2 Relative priority of V2X communication Word‑p. 8
Subject to regional/national regulatory requirements and operator policies, certain mission critical services (e.g. Public Safety, MPS) can be relatively prioritized over transport of V2X application information. Transport of safety-related V2X application information can be prioritized over transport of non-safety-related V2X application information.
However, in general, it is expected that operator can control relative priorities of different services.
5 Requirements
5.1 Overall Requirements
[R-5.1-001]
The message transmission shall be under control of the 3GPP network when the transmitting UE is served by the E-UTRAN.
[R-5.1-002]
A UE supporting V2X application shall be able to be pre-configured by the 3GPP network with parameters to be used for the transmission and reception of messages when not served by E-UTRAN supporting V2X communication.
[R-5.1-003]
A UE supporting V2X application shall be able to transmit and receive messages when served or not served by E-UTRAN supporting V2X communication.
[R-5.1-004]
An RSU shall be able to transmit/receive messages to/from a UE supporting V2X application.
[R-5.1-005]
The 3GPP system shall be able to support message transfer between UEs when served or not served by the same PLMN supporting V2X communications.
[R-5.1-006]
The 3GPP system shall be able to provide means to prioritize message transmission among UEs supporting V2X application
[R-5.1-007]
The 3GPP system shall be able to provide means to prioritize transmission of messages according to their type (e.g. safety vs. non-safety).
[R-5.1-008]
The 3GPP system shall be able to vary the transmission rate and range of the V2X communication based on service conditions (e.g., UE speed, UE density).
[R-5.1-009]
The 3GPP system shall be able to distribute information in a resource efficient way to large numbers of UEs supporting V2X application.
[R-5.1-010]
A UE supporting V2X application shall be able to identify whether E-UTRAN supports V2X communication.
[R-5.1-011]
The 3GPP system shall be able to provide means for an application server and the RSU to control the area and the size of the area where the messages are being distributed.
[R-5.1-011a]
The 3GPP system shall be able to provide means for distribution of messages from a UE supporting V2X application to locally relevant application servers.
[R-5.1-012]
The E-UTRA(N) shall be able to support a high density of UEs supporting V2X application.
[R-5.1-013]
Both the HPLMN and VPLMN operators shall be able to charge for network resource usage when messages are transferred by a UE supporting V2X application.
[R-5.1-014]
For UE supporting V2X application with limited resources (e.g., battery), the impact on its resources (e.g., battery consumption) due to message transfer should be minimized.
[R-5.1-015]
The 3GPP network should make available any supported positional accuracy improvement techniques (e.g., DGPS and/or OTDOA) in a resource efficient way to a subscribed UE supporting V2X application.
5.2 Specific Service Requirements Word‑p. 9
5.2.1 Latency/ Reliability Requirements
[R-5.2.1-001]
The E-UTRA(N) shall be capable of transferring messages between two UEs supporting V2V/P application, directly or via an RSU, with a maximum latency of 100ms.
[R-5.2.1-002]
For particular usage (i.e., pre-crash sensing) only, the E-UTRA(N) should be capable of transferring messages between two UEs supporting V2V application with a maximum latency of 20ms.
[R-5.2.1-003]
The E-UTRA(N) shall be capable of transferring messages between a UE supporting V2I application and an RSU with a maximum latency of 100ms.
[R-5.2.1-004]
The E-UTRAN shall be capable of transferring messages via 3GPP network entities between a UE and an application server both supporting V2N application with an end-to-end delay no longer than 1000 ms.
[R-5.2.1-005]
The E-UTRA(N) shall be able to support high reliability without requiring application-layer message retransmissions.
5.2.2 Message Size Requirements
[R-5.2. 2-001]
The E-UTRA(N) shall be capable of transferring periodic broadcast messages between two UEs supporting V2X application with variable message payloads of 50-300 bytes, not including security-related message component.
[R-5.2. 2-002]
The E-UTRA(N) shall be capable of transferring event-triggered messages between two UEs supporting V2X application with variable message payloads which can be up to 1200 bytes, not including security-related message component.
5.2.3 Frequency Requirements
[R-5.2.3-001]
The E-UTRA(N) shall be able to support a maximum frequency of 10 messages per second per transmitting UE .
5.2.4 Range Requirements
[R-5.2.4-001]
The E-UTRAN shall be capable of supporting a communication range sufficient to give the driver(s) ample response time (e.g. 4 seconds).
5.2.5 Speed Requirements
[R-5.2.5-001]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V application, while the maximum relative velocity of the UEs is 500 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
[R-5.2.5-002]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V and V2P application, respectively, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
[R-5.2.5-003]
The 3GPP system shall be capable of transferring messages between a UE and an RSU both supporting V2I application, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE or the RSU is served or not served by E-UTRAN supporting V2X communication.
5.3 Security Requirements Word‑p. 10
[R.5.3-001]
The 3GPP network shall provide a means for the MNO to authorize a UE supporting V2X application to perform V2X communication when served by E-UTRAN supporting V2X communication.
[R.5.3-002]
The 3GPP network shall provide a means (e.g., pre-authorization) for the MNO to authorize a UE supporting V2X application to perform V2X communication when not served by E-UTRAN supporting V2X communication.
[R.5.3-003]
The 3GPP network shall provide a means for the MNO to authorize UEs supporting V2X application separately to perform V2N communication.
[R.5.3-004]
The 3GPP system shall support integrity protection of the transmission for a V2X application.
[R.5.3-005]
Subject to regional regulatory requirements and/or operator policy for a V2X application, the 3GPP system shall support pseudonymity and privacy of a UE using the V2X application, by ensuring that a UE identity cannot be tracked or identified by any other UE beyond a certain short time-period required by the V2X application.
[R.5.3-006]
Subject to regional regulatory requirements and/or operator policy for a V2V/V2I application, the 3GPP system shall support pseudonymity and privacy of a UE in the use of a V2V/V2I application, such that no single party (operator or third party) can track a UE identity in that region.
5.2.1 Latency/ Reliability Requirements
[R-5.2.1-001]
The E-UTRA(N) shall be capable of transferring messages between two UEs supporting V2V/P application, directly or via an RSU, with a maximum latency of 100ms.
[R-5.2.1-002]
For particular usage (i.e., pre-crash sensing) only, the E-UTRA(N) should be capable of transferring messages between two UEs supporting V2V application with a maximum latency of 20ms.
[R-5.2.1-003]
The E-UTRA(N) shall be capable of transferring messages between a UE supporting V2I application and an RSU with a maximum latency of 100ms.
[R-5.2.1-004]
The E-UTRAN shall be capable of transferring messages via 3GPP network entities between a UE and an application server both supporting V2N application with an end-to-end delay no longer than 1000 ms.
[R-5.2.1-005]
The E-UTRA(N) shall be able to support high reliability without requiring application-layer message retransmissions.
5.2.2 Message Size Requirements
[R-5.2. 2-001]
The E-UTRA(N) shall be capable of transferring periodic broadcast messages between two UEs supporting V2X application with variable message payloads of 50-300 bytes, not including security-related message component.
[R-5.2. 2-002]
The E-UTRA(N) shall be capable of transferring event-triggered messages between two UEs supporting V2X application with variable message payloads which can be up to 1200 bytes, not including security-related message component.
5.2.3 Frequency Requirements
[R-5.2.3-001]
The E-UTRA(N) shall be able to support a maximum frequency of 10 messages per second per transmitting UE .
5.2.4 Range Requirements
[R-5.2.4-001]
The E-UTRAN shall be capable of supporting a communication range sufficient to give the driver(s) ample response time (e.g. 4 seconds).
5.2.5 Speed Requirements
[R-5.2.5-001]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V application, while the maximum relative velocity of the UEs is 500 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
[R-5.2.5-002]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V and V2P application, respectively, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
[R-5.2.5-003]
The 3GPP system shall be capable of transferring messages between a UE and an RSU both supporting V2I application, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE or the RSU is served or not served by E-UTRAN supporting V2X communication.
[R.5.3-001]
The 3GPP network shall provide a means for the MNO to authorize a UE supporting V2X application to perform V2X communication when served by E-UTRAN supporting V2X communication.
[R.5.3-002]
The 3GPP network shall provide a means (e.g., pre-authorization) for the MNO to authorize a UE supporting V2X application to perform V2X communication when not served by E-UTRAN supporting V2X communication.
[R.5.3-003]
The 3GPP network shall provide a means for the MNO to authorize UEs supporting V2X application separately to perform V2N communication.
[R.5.3-004]
The 3GPP system shall support integrity protection of the transmission for a V2X application.
[R.5.3-005]
Subject to regional regulatory requirements and/or operator policy for a V2X application, the 3GPP system shall support pseudonymity and privacy of a UE using the V2X application, by ensuring that a UE identity cannot be tracked or identified by any other UE beyond a certain short time-period required by the V2X application.
[R.5.3-006]
Subject to regional regulatory requirements and/or operator policy for a V2V/V2I application, the 3GPP system shall support pseudonymity and privacy of a UE in the use of a V2V/V2I application, such that no single party (operator or third party) can track a UE identity in that region.
A Background Information on Service Requirement Word‑p. 11
The basic categories of V2X services for V2X decribed in the TR 22.885 can be grouped into the following main categories based on ITS defintion of basic set of services [3] :
-
Road Safety Requirements e.g Queue warning use case related requirements
-
Mutual Vehicle Awarness - Information only e.g forward collision warning requirements
-
Vehicle Related Application Requirements e.g Automated parking system requirement
Clause 5.2 refers to specific service requirements which are categoried as:
Latency/Reliability Requirements:
Maximum tolerable elapsed time from the instant a data packet is generated at the source application to the instant it is received by the destination application. Low Latency values are provided to support services in the case of mutual awareness of vehicle or to send warning messages as defined in the some use cases in TR 22.885
Reliability:
Maximum tolerable packet loss rate at the application layer, a packet is considered lost if it is not received by the destination application within the maximum tolerable end-to-end latency for that application.
Message Size Requirements:
Messages sizes are important when multicast or broadcast messages are being sent to vehicles within range to either warn them for collision prevention or when an event occurs to inform other vehicle about an accident.
Frequency Requirements:
Minimum required bit rate for the application to function correctly. The sending rates i.e frequency of messages is relatively important especially for critical vehicular safety application.
Range Requirements:
Maximum distance between source and destination(s) of a radio transmission within which the application should achieve the specified reliability
Speed Requirements:
Maximum relative and absolute speed under which the specified reliability should be achieved.
With this brief description of the service categories, the table suggested below is used to reference the specific requirements in clause 5.2 to some of the use cases in the TR which makes for easy understanding and for better clarification of the suggested application of the services:
TS requirement
Requirement
Potential V2X service
Use case Requirement in TR 22.885
Latency Requirement
[R-5.2.1-001]
The E-UTRA(N) shall be capable of transferring messages between two UEs supporting V2V/P application, directly or via an RSU, with a maximum latency of 100ms.
Typical use case is for Mutual Vehicle Awareness and Road safety
[CPR-014]
[R-5.2.1-002]
For particular usage (i.e., pre-crash sensing) only, the E-UTRA(N) should be capable of transferring messages between two UEs supporting V2V application with a maximum latency of 20ms.
Requirement applies in Road safety use cases
[CPR-015]
[R-5.2.1-003]
The E-UTRA(N) shall be capable of transferring messages between a UE supporting V2I application and an RSU with a maximum latency of 100ms.
Requirement applys in Road safety use cases
[CPR-016]
[R-5.2.1-004]
The E-UTRAN shall be capable of transferring messages via 3GPP network entities between a UE and an application server both supporting V2N application with an end-to-end delay no longer than 1000 ms.
Applys to Mutual Vehicle Awareness use case
[CPR-017]
[R-5.2.1-005]
The E-UTRA(N) shall be able to support high reliability without requiring application-layer message retransmissions.
Mutual Vehicle Awareness and Road safety cases
[CPR-027]
Message Size
[R-5.2. 2-001]
The E-UTRA(N) shall be capable of transferring periodic broadcast messages between two UEs supporting V2X application with variable message payloads of 50-300 bytes, not including security-related message component.
Supports all three use case categories
[CPR-019]
[R-5.2. 2-002]
The E-UTRA(N) shall be capable of transferring event-triggered messages between two UEs supporting V2X application with variable message payloads which can be up to 1200 bytes, not including security-related message component.
Mostly Road safety applications
[CPR-020]
Frequency
[R-5.2.3-001]
The E-UTRA(N) shall be able to support a maximum frequency of 10 messages per second per UE or per RSU.
Road safety and Mutual Vehicle Awareness
[CPR-011]
Range Requirement
[R-5.2.4-001]
The E-UTRAN shall be capable of supporting a communication range sufficient to give the driver(s) ample response time (e.g. 4 seconds).
[CPR-005]
Speed Requirement
[R-5.2.5-001]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V application, while the maximum relative velocity of the UEs is 500 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
Road Safety, Mutual Vehicle Awareness
[CPR-030]
[R-5.2.5-002]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V and V2P application, respectively, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
Road Safety, Mutual Vehicle Awareness
[CPR-031]
[R-5.2.5-003]
The 3GPP system shall be capable of transferring messages between a UE and an RSU both supporting V2I application, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE or the RSU is served or not served by E-UTRAN supporting V2X communication.
Road Safety, Mutual Vehicle Awareness
[CPR-031]
$ Change history Word‑p. 14
- Road Safety Requirements e.g Queue warning use case related requirements
- Mutual Vehicle Awarness - Information only e.g forward collision warning requirements
- Vehicle Related Application Requirements e.g Automated parking system requirement
Maximum tolerable elapsed time from the instant a data packet is generated at the source application to the instant it is received by the destination application. Low Latency values are provided to support services in the case of mutual awareness of vehicle or to send warning messages as defined in the some use cases in TR 22.885
Reliability:
Maximum tolerable packet loss rate at the application layer, a packet is considered lost if it is not received by the destination application within the maximum tolerable end-to-end latency for that application.
Message Size Requirements:
Messages sizes are important when multicast or broadcast messages are being sent to vehicles within range to either warn them for collision prevention or when an event occurs to inform other vehicle about an accident.
Frequency Requirements:
Minimum required bit rate for the application to function correctly. The sending rates i.e frequency of messages is relatively important especially for critical vehicular safety application.
Range Requirements:
Maximum distance between source and destination(s) of a radio transmission within which the application should achieve the specified reliability
Speed Requirements:
Maximum relative and absolute speed under which the specified reliability should be achieved.
With this brief description of the service categories, the table suggested below is used to reference the specific requirements in clause 5.2 to some of the use cases in the TR which makes for easy understanding and for better clarification of the suggested application of the services:
TS requirement
Requirement
Potential V2X service
Use case Requirement in TR 22.885
Latency Requirement
[R-5.2.1-001]
The E-UTRA(N) shall be capable of transferring messages between two UEs supporting V2V/P application, directly or via an RSU, with a maximum latency of 100ms.
Typical use case is for Mutual Vehicle Awareness and Road safety
[CPR-014]
[R-5.2.1-002]
For particular usage (i.e., pre-crash sensing) only, the E-UTRA(N) should be capable of transferring messages between two UEs supporting V2V application with a maximum latency of 20ms.
Requirement applies in Road safety use cases
[CPR-015]
[R-5.2.1-003]
The E-UTRA(N) shall be capable of transferring messages between a UE supporting V2I application and an RSU with a maximum latency of 100ms.
Requirement applys in Road safety use cases
[CPR-016]
[R-5.2.1-004]
The E-UTRAN shall be capable of transferring messages via 3GPP network entities between a UE and an application server both supporting V2N application with an end-to-end delay no longer than 1000 ms.
Applys to Mutual Vehicle Awareness use case
[CPR-017]
[R-5.2.1-005]
The E-UTRA(N) shall be able to support high reliability without requiring application-layer message retransmissions.
Mutual Vehicle Awareness and Road safety cases
[CPR-027]
Message Size
[R-5.2. 2-001]
The E-UTRA(N) shall be capable of transferring periodic broadcast messages between two UEs supporting V2X application with variable message payloads of 50-300 bytes, not including security-related message component.
Supports all three use case categories
[CPR-019]
[R-5.2. 2-002]
The E-UTRA(N) shall be capable of transferring event-triggered messages between two UEs supporting V2X application with variable message payloads which can be up to 1200 bytes, not including security-related message component.
Mostly Road safety applications
[CPR-020]
Frequency
[R-5.2.3-001]
The E-UTRA(N) shall be able to support a maximum frequency of 10 messages per second per UE or per RSU.
Road safety and Mutual Vehicle Awareness
[CPR-011]
Range Requirement
[R-5.2.4-001]
The E-UTRAN shall be capable of supporting a communication range sufficient to give the driver(s) ample response time (e.g. 4 seconds).
[CPR-005]
Speed Requirement
[R-5.2.5-001]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V application, while the maximum relative velocity of the UEs is 500 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
Road Safety, Mutual Vehicle Awareness
[CPR-030]
[R-5.2.5-002]
The 3GPP system shall be capable of transferring messages between UEs supporting V2V and V2P application, respectively, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication.
Road Safety, Mutual Vehicle Awareness
[CPR-031]
[R-5.2.5-003]
The 3GPP system shall be capable of transferring messages between a UE and an RSU both supporting V2I application, while the UE's maximum absolute velocity is 250 km/h, regardless of whether the UE or the RSU is served or not served by E-UTRAN supporting V2X communication.
Road Safety, Mutual Vehicle Awareness
[CPR-031]