YD/T 3400-2018 English PDF (YDT3400-2018)
YD/T 3400-2018 English PDF (YDT3400-2018)
YD/T 3400-2018: General technical requirements of LTE-basedvehicular communication
COMMUNICATION INDUSTRY STANDARD
OF THE PEOPLE REPUBLIC OF CHINA
General Technical Requirements of LTE-Based
ISSUED ON: DECEMBER 21, 2018
IMPLEMENTED ON: APRIL 01, 2019
Issued by: Ministry of Industry and Information Technology of PRC
Table of Contents
Foreword ... 4
1 Scope ... 5
2 Normative References ... 5
3 Terms, Definitions and Abbreviations ... 5
3.1 Terms and Definitions ... 5
3.2 Abbreviations ... 6
4 Overview ... 7
5 General Service Requirements of LTE-Based Vehicle-to-Everything ... 7 5.1 Basic requirements ... 7
5.2 Effective communication distance ... 9
5.3 Movement speed ... 9
5.4 Communication delay ... 9
5.5 Transmission reliability ... 9
5.6 Requirements for information security ... 9
5.7 Requirements for coverage ... 10
5.8 Requirements for message sending frequency ... 10
5.9 Requirements for message size ... 10
6 Radio Communication System Architecture of LTE-Based Vehicle-to-
Everything ... 11
6.1 Architecture model ... 11
6.2 Introduction of the interface ... 14
6.3 Functional entities ... 15
7 Basic Functional Requirements of LTE-Based Vehicle-to-Everything ... 17 7.1 High-level functional requirements ... 18
7.2 Requirements of the radio function ... 27
7.3 Identification ... 33
7.4 Function description and message flow ... 34
Appendix A (Informative) Application Scenarios and Requirements of the LTE- Based Vehicle-to-Everything ... 41
General Technical Requirements of LTE-Based
This Standard specifies the overall service requirements, system architecture and basic functional requirements of LTE-based vehicular communication.
This Standard is applicable to LTE-based vehicular communication systems. 2 Normative References
The following documents are essential to the application of this document. For the dated documents, only the versions with the dates indicated are applicable to this document; for the undated documents, only the latest version (including all the amendments) is applicable to this document.
3GPP TS 23.246 Multimedia Broadcast/Multicast Service (MBMS) Architecture and Functional Description
3GPP TS 23.303 Proximity-Based Service (ProSe); Stage 2
3GPP TS 23.401 General Packet Radio Service (GPRS) Enhancements for
Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access
3GPP TS 23.468 Group Communication System Enablers for LTE (GCSE_LTE);
3GPP TS 33.185 Security Aspect for LTE Support of V2X Services
3GPP TS 36.331 Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control (RRC); Protocol Specification
3 Terms, Definitions and Abbreviations
3.1 Terms and Definitions
For the purpose of this document, the following terms and definitions apply. 4 Overview
Vehicle-to-Everything (V2X) applications include Vehicle-to-Vehicle (V2V) applications, Vehicle-to-Infrastructure (V2I) applications, Vehicle-to-Network (V2N) applications and Vehicle-to-Pedestrian (V2P) applications.
V2V application refers to the exchange of V2V application information between adjacent on-board UEs. The information exchange is based on the broadcast mode, and the direct mode between UEs may be used, or information may be exchanged between UEs through infrastructure [such as road side unit (RSU), application server]. V2I application refers to the on-board UE sends V2I application information to the RSU or local application server; and the RSU or local application server sends the V2I application information to the on-board UE.
V2N application refers to communication between UE and application server through EPS network.
V2P application refers to the exchange of V2P application information between an on- board UE and a human-held UE. Information exchange may adopt the direct mode between UEs, or exchange information between UEs via infrastructure [such as road side unit (RSU), application server].
The LTE-based vehicular communication system supports Vehicle-to-Vehicle (V2V) applications, Vehicle-to-Infrastructure (V2I) applications, Vehicle-to-Network (V2N) applications, and Vehicle-to-Pedestrian (V2P) applications. These applications may provide users with various services such as road safety, traffic efficiency improvement and infotainment, etc. Appendix A provides application scenarios and demand analysis LTE-based Vehicle-to-Everything.
5 General Service Requirements of LTE-Based Vehicle-
5.1 Basic requirements
Requirement 1: When the sending terminal is served by E-UTRAN that supports V2X, the message transmission shall be controlled by the 3GPP network.
Requirement 2: When the Vehicle-to-Everything terminal fails to be served by the E- UTRAN network that supports V2X, it shall be able to support and use the 3GPP network to pre-configure the system parameters for sending and receiving messages. Requirement 3: Whether or not it is served by the E-UTRAN network that supports 5.2 Effective communication distance
Requirement 16: E-UTRA shall be able to provide sufficient effective communication distance to ensure that the driver has sufficient response time (for instance, 4s). 5.3 Movement speed
Requirement 17: Regardless of whether the Vehicle-to-Everything terminal uses the Vehicle-to-Everything communication service that is provided by E-UTRAN that supports V2X communication, the 3GPP system shall be able to support messages sending between vehicles at a maximum relative speed of 500km/h.
Requirement 18: Regardless of whether the Vehicle-to-Everything terminal or road side unit or pedestrians use the Vehicle-to-Everything communication service that is provided by E-UTRAN that supports V2X communication, the 3GPP system shall be able to support the message sending between vehicles and vehicles at a maximum absolute speed of 250km/h, between vehicles and road side units, as well as between vehicles and pedestrians send messages.
5.4 Communication delay
Requirement 19: For terminals that support vehicle-to-vehicle and vehicle-to- pedestrian communication, whether it is sent directly or forwarded by a road side unit, E-UTRA (N) shall ensure that the maximum communication delay not exceed 100ms. Requirement 20: Only for special use cases (such as collision detection), the maximum delay of sending V2V messages between E-UTRA (N) Vehicle-to-Everything terminals should not exceed 20ms.
Requirement 21: For vehicle-to-road side unit communication, the maximum communication delay between the vehicle and the road side unit does not exceed 100ms.
Requirement 22: For the communication BETWEEN the Vehicle-to-Everything terminal that supports the V2N service and goes through the 3GPP network entity AND the application server, the maximum end-to-end delay shall not exceed 1000ms. 5.5 Transmission reliability
Requirement 23: The E-UTRAN network shall not rely on application layer retransmission to provide highly reliable transmission.
5.6 Requirements for information security
Requirement 24: When the Vehicle-to-Everything terminal uses the service that is provided by E-UTRAN that supports V2X communication, the 3GPP network shall provide a method for the operator to authorize the Vehicle-to-Everything terminal to characteristics (such as delay, message size), and does not pay attention to specific message types.
6 Radio Communication System Architecture of LTE-
6.1 Architecture model
V2X communication has two mutually independent and complementary working modes; namely, V2X communication based on PC5 direct mode and V2X
communication based on LTE-Uu. The working mode based on LTE-Uu may be unicast or MBMS. The UE may use these two working modes to receive and transmit, respectively. For example: A UE may use MBMS to receive V2X messages, but send V2X messages without using LTE-Uu. A UE may also receive V2X messages through LTE-Uu downlink unicast.
The following principles are applicable to these two working modes:
--- Between V2X application servers: may communicate with each other to exchange V2X information;
--- ProSe discovery mechanism is not applicable to V2X services;
--- According to regional control regulations, legal interception is applicable to V2X services.
6.1.2 V2X communication architecture based on PC5 and LTE-Uu
184.108.40.206 V2X communication architecture based on PC5 and LTE-Uu in non-
Figure 1 shows the V2X communication architecture based on PC5 and LTE-Uu in a non-roaming scenario.
--- S1-MME: In the V2X scenario, this interface can transmit V2X service authorization from MME to eNodeB.
--- MB2: The interface between V2X application server and BM-SC.
--- SGmb/SGi-mb/M1/M3: SGmb/SGi-mb/M1/M3 interface in MBMS system.
--- LTE-Uu: The interface between UE and E-UTRAN.
6.3 Functional entities
The UE may support the following functions.
--- Exchange V2X control information between UE and V2X control functions through the V3 interface.
--- Perform V2X communication through PC5 interface or LTE-Uu interface. --- Configure the parameters of V2X communication (such as the destination Layer- 2 ID, radio resource parameters, V2X application server address information, etc., for the specific meaning of these parameters, see sub-clause 7.1.1). These parameters may be pre-configured in the UE; or may be configured by the V2X control function belonging to the PLMN through V3 interface signaling.
--- Obtain V2X USD to receive V2X service information through the MBMS
broadcast mechanism; to obtain V2X USD may use the existing MBMS service announcement mechanism, or be provided by the V2X control function, or be provided by the V2X application server through the V1 interface.
--- Obtain V2X server USD to receive V2X application server information through MBMS broadcast mechanism.
6.3.2 eNode B
The eNode B may send and receive V2X messages in unicast mode through the LTE- Uu interface; and may also send V2X messages by the MBMS mechanism.
For V2X communication based on the PC5 interface, when the UE is in the ?€?using E- UTRAN service?€? scenario, the eNode B may support the following functions: --- Provide UE with relevant radio parameter configuration such as resource pool configuration for PC5 interface communication through broadcast messages; --- Schedule or configure PC5 interface resources (including dynamic scheduling, --- Select the appropriate destination MBMS SAI (Service Area ID) based on the geographic location information for broadcasting data.
--- Select the appropriate 3GPP ECGI (E-UTRAN Cell Global Identifier) according to the geographic location information for broadcasting data.
--- Select the appropriate MBMS SAI according to the ECGI provided by the UE for broadcast data.
--- Provide appropriate ECGI or MBMS SAI to BM-SC.
--- Pre-configure local MBMS-related information (for example: IP multicast address, source specific multicast (SSM), C-TEID).
--- Pre-configure the IP address and port number of the local MBMS user plane. --- Send local MBMS information to BM-SC.
--- Request BM-SC to allocate/de-allocate a group of TMGI.
--- Request BM-SC to activate/de-activate/modify MBMS bearer.
--- For UEs that use the MBMS mechanism to receive V2X service information, provide V2X USD to the V2X control function entity.
In addition to the functions defined in 3GPP TS 23.246 and 3GPP TS 23.468, in the V2X scenario, BM-SC also supports the following functions.
--- Receive L.MBMS information from V2X application server.
--- Send L.MBMS information to MBMS-GW.
In addition to the functions defined in 3GPP TS 23.246, in the case of V2X, MBMS- GW also supports the following functions: If L.MBMS information is received from BM- SC, the distribution process of IP multicast distribution is skipped, such as distribution an IP multicast address.
7 Basic Functional Requirements of LTE-Based
scenario of "not using E-UTRAN service". These radio parameters (such as frequency) are described in 3GPP TS 36.331, which contains instructions to indicate whether these resources are "operator managed" or "non-operator managed." 3GPP TS 36.101 defines "non-operator managed" radio resources for V2X communication. These radio resource parameters may only be used when the UE can locate itself in the corresponding geographic zone, otherwise the UE is not authorized to transmit.
c) Parameters used for V2X communication on the PC5 interface.
--- The mapping relationship between the Destination Layer-2 ID and the V2X services (such as the PSID or ITS-AID, and the like services of the V2X application).
NOTE 1: PLMN operators need to coordinate to configure the destination Layer-2 ID of the V2X services in a consistent manner.
NOTE 2: In the case of pre-configuring UE, at least the corresponding parameters of "not using E-UTRAN service" in a) and b) and the parameters of c) need to be configured.
--- When the independent resources choose the V2X communication, the
mapping relationship between the ProSe Per-Packet Priority (PPPP) and the packet delay budget (PDB).
220.127.116.11.3 Configuration principles for the parameters of the V2X communication on the PC5 interface
For V2X communication based on the PC5 interface, the operator may pre-configure the parameters required for V2X communication to the UE without the need for the UE to connect to the V2X control function to obtain the initial configuration, and follow the following principles.
--- The parameters required for V2X communication may be configured in UICC or ME, or both UICC and ME.
--- USIM removal or replacement shall not delete the V2X communication
configuration parameters in the ME.
--- If a certain group of configuration parameters are saved in both UICC and ME, the group of configuration parameters saved in UICC shall be used first. --- The UE needs to follow the following principles when using the radio resources used for PC5 interface V2X communication.
??? When the UE accesses a cell and is ready to use the radio resources
??? The parameters provided to the UE shall support geographic zone settings. 18.104.22.168 Authorization and provision of the V2X communication on the LTE-Uu interface
For V2X communication on the Uu interface, it may be necessary to provide unicast or MBMS transmission related information to the UE. It may contain the following parameter information.
a) Authorize the use of PLMN information for V2X communication based on MBMS. Including V2X USD that is used to receive MBMS-based V2X services in PLMN. V2X USD may be obtained from the V2X application server through the V2
b) V2X application server address information. Including the FQDN or IP address of the V2X application server related to geographic location information, and the PLMN to which the configuration information is applied.
c) Discovery information of V2X application server using MBMS. Including the PLMN list and the corresponding V2X server USD that receives V2X application server information through MBMS.
d) V2X services, such as the mapping between service identifiers such as PSID or ITS-AID and the following information.
--- A V2X application server address for unicast (including IP address/FQDN and UDP port).
--- V2X USD for MBMS.
7.1.2 Sending and receiving messages on PC5 interface
The PC5 interface (as defined in 3GPP TS 23.303) is used to send and receive V2X messages. V2X communication based on the PC5 interface supports roaming and cross-PLMN operations. The UE may support V2X communication based on the PC5 interface in the scenarios of "using E-UTRAN services" and "not using E-UTRAN services".
The V2X control function of HPLMN authorizes the UE to send and receive V2X messages.
V2X communication is a ProSe direct communication with the following characteristics. --- The V2X communication on the PC5 interface is connectionless, and there is no signaling interaction process for connection establishment on the PC5 control plane.
--- The existing MBMS service announcement mechanism.
--- Configure in accordance with the method specified in subclause 22.214.171.124. --- Information provided by the V2X application server through the V1 interface. In order to reduce the delay of MBMS, it may be achieved by localizing MBMS. 7.1.4 Discovery of V2X application server
When using LTE-Uu mode for V2X communication, the UE needs to discover the V2X application server. The address information of the V2X application server may be configured in the UE or provided by the V3 interface.
When the FQDN is included in the configuration, the UE executes DNS to obtain the address of the V2X application server. The UE shall only use the configured V2X application server information when in the specified geographic zone. The serving PLMN that is changed by the UE or has passed through the configured geographic zone, the UE needs to perform the address acquisition process again.
When MBMS is deployed on the network, other information used for V2X application server discovery may be sent to UE through the MBMS broadcast channel. When the UE is configured to receive V2X application server information through MBMS, the UE can obtain other local V2X application server information through interaction with the network. The priority of the local V2X application server information obtained through MBMS is higher than the V2X application server information in the UE.
126.96.36.199 Discovery and routing of multiple V2X application servers and local V2X application server
There may be multiple V2X application servers in V2X communication, and each V2X application server provides different V2X services or different V2X application servers serve different geographic locations. Therefore, the V2X application server address information may include the information of multiple servers. When multiple V2X application servers are configured, the application layer shall select the appropriate V2X application server.
When a local V2X application server is deployed, the Anycast mechanism may be used to hide server changes from the UE. In this case, a larger area FQDN shall be configured, such as the entire PLMN, and the UE only needs to complete the process of discovering the Anycast address once. The PGW or LGW is responsible for routing data to the correct local V2X application server through the Anycast address. 7.1.5 QoS processing
The subscription information related to the user's V2X service is saved in the HSS. The operator may delete the V2X service-related subscription from the HSS at any time; and revoke the authority to allow the UE to use the V2X service.
The V2X service-related subscription information is defined as follows. a) Is the UE authorized to be a vehicle UE, a pedestrian UE, or both a vehicle UE and a pedestrian UE to perform V2X communication based on the PC5 interface. b) UE-PC5-AMBR for V2X communication on the PC5 interface.
c) A list of PLMNs is authorized to allow the UE to perform V2X communication on the PC5 interface.
HSS provides a) and b) as subscription information to MME, and MME provides a) and b) as UE context information to eNB.
HSS provides c) to the V2X control function.
7.1.8 Support V2X communication under restricted service state
When the UE is in a restricted servic...