5 Functional description and information flows

23.2853GPPArchitecture enhancements for V2X servicesRelease 17TS

5.1 Control and user plane stacks

5.1.1 User plane for PC5 reference point supporting V2X services

The PC5-U stack as defined in clause 5.1.2.1 of TS 23.303 [5] is used for the V2X communication over PC5 reference point. IP and Non-IP PDCP SDU types are supported for the V2X communication over PC5.

For IP PDCP SDU type, only IPv6 is supported. The IP address allocation and configuration are as defined in clause 4.5.1.

The Non-IP PDCP SDU contains a Non-IP Type header, which indicates the V2X message family used by the application layer, e.g. IEEE 1609 family’s WSMP [13], ISO defined FNTP [14], CCSA defined DSMP [32], etc.

NOTE: The Non-IP Type header and allowed values are defined in TS 24.386 [27].

5.2 Service authorization and update for V2X communications

5.2.1 Service authorization procedures

The service authorization procedures as specified in clause 5.2.1 of TS 23.303 [5] are reused for the authorization of a UE for V2X communications, with the V2X Control Functions in the corresponding PLMNs acting as the ProSe Functions.

5.2.2 Service authorization update procedures

The service authorization update procedures as specified in clause 5.2.2 of TS 23.303 [5] are reused for the updating of service authorization information in the UE.

5.3 Procedure for V2X communication over PC5 reference point

To perform V2X communication over PC5 reference point, the UE is configured with the related information as described in clause 4.4.1.1.

The procedure for one-to-many ProSe Direct Communication transmission described in clause 5.4.2 of TS 23.303 [5] is applied to V2X communication over PC5 reference point with following differences:

– The source Layer-2 ID is set to the Layer-2 ID described in clause 4.5.1.

– A UE shall be configured with a set of Layer-2 ID corresponding to different type of services.

– A UE shall be configured with the mapping of services types to Tx Profiles as described in clause 4.4.1.1.2, and selects a Tx Profile to use based on the upper layer provided service type (e.g. PSID/ITS-AID/AID).

The procedure for one-to-many ProSe Direct Communication reception described in clause 5.4.3 of TS 23.303 [5] is applied to V2X communication over PC5 reference point.

5.4 Procedure for V2X communication over LTE-Uu reference point

5.4.1 V2X Application Server discovery using MBMS

5.4.1.1 General

This procedure is applicable for local V2X Application Server discovery if supported by the network. It may be used by the UE only when it is configured with the information to receive V2X Application Server information via MBMS, as specified in clause 4.4.1.2.2.

5.4.1.2 Procedures for receiving V2X Application Server information via MBMS

Figure 5.4.1.2-1: V2X Application Server discovery using broadcast

1. When a UE desires V2X communications via LTE-Uu, it attaches to the serving PLMN if it has not done so.

2. If the UE has configuration for receiving V2X Application Server information via MBMS, as specified in clause 4.4.1.2.2, it receives the local Service Information from the corresponding broadcast traffic channel. The local Service Information includes the address information of the local V2X Application Servers, e.g. the FQDNs of the servers. In addition, the local Service Information may include the V2X USD for the corresponding V2X Application Servers, if MBMS downlink is to be used.

NOTE: The UE can be in MBMS receive only mode for obtaining the local Service Information.

3. Based on the information received from step 2, the UE obtains the local V2X Application Server address, e.g. via a query of the DNS with the received FQDN.

4. The UE may establish connection with the V2X Application Server for the service, e.g. obtaining the V2X USD if it is not provided in step 2 to allow the UE to receive V2X messages over MBMS.

5.4.2 Procedure for V2X communication with MBMS

5.4.2.1 MBMS service area mapping

5.4.2.1.1 General

MBMS service areas for V2X services may be configured at the V2X Application Server. Such service areas are not expected to change frequently. V2X Application Server performs the following procedures for managing the MBMS sessions:

• MBMS bearer activation/deactivation procedures specified in TS 23.468 [7] and clause 5.4.2.2 are used for managing MBMS sessions. V2X Application Server acting as the GCS AS uses the configured MBMS Service Area Identities (SAIs) and/or list of Cell IDs (ECGIs) of the target broadcast area for such procedures.

• If the UE provides its geographic location or Cell ID information over V1 reference point, the V2X Application Server may use such information for the determination of the target broadcast area (e.g. MBMS SAI(s) and/or ECGI(s)) for the downlink broadcast of V2X messages.

• From such procedures, the V2X Application Server knows which TMGI/Flow-ID (i.e. MBMS session) is serving a geographical area. Hence, V2X Application Server forwards a V2X message to the appropriate MBMS session.

NOTE: V2X messages may be broadcasted to an area larger than needed. The V2X application in the UE discards the messages that are not relevant to the UE based on procedures internal to the UE.

5.4.2.1.2 Functional Description

V2X Application Server shall map UE provided location information to a form that is understood by the 3GPP MBMS system, e.g. MBMS SAI(s) and/or ECGI(s).

A UE may include its geographic location information in the V2X message, e.g. as defined ETSI ITS (ETSI TS 102 637‑2 [16], ETSI TS 102 637‑3 [17]) or other ITS specifications. The V2X Application Server shall provide the MBMS broadcast area parameters to BM-SC and BM-SC process the MBMS broadcast area parameters as defined in TS 23.468 [7].

Additionally, a UE may provide its geographic location information in the V2X message and Cell ID (i.e. ECGI) information in the signalling to the V2X Application Sever. The V2X Application Server may use such information for determining the target MBMS broadcast area as defined in TS 23.468 [7].

The BM-SC derives the MBMS Service Area and the SAI list for the availability information from Geographical Area as provided by the V2X Application Server as defined in TS 26.348 [29] when using xMB interface.

NOTE: As specified in TS 23.246 [8], the BM-SC provides both the MBMS SAI(s) and Cell ID(s) towards the downlink signalling path towards the RAN nodes.

5.4.2.2 Local MBMS based MBMS data delivery

For MBMS latency improvements, the V2X Application Server may provide the BM-SC with L.MBMS (Local MBMS) information, i.e., M1 interface information including transport network IP Multicast Address, IP address of multicast source and C-TEID, as well as MB2-U interface information including IP address and UDP port number for the user plane. This L.MBMS information is preconfigured in the V2X Application Server.

Figure 5.4.2.2-1 shows the procedure that the L.MBMS information (both M1 interface information and MB2-U interface information) is provided from the V2X Application Server to the BM-SC, and in turn M1 interface information is provided from BM-SC to MBMS-GW when activating MBMS bearer and V2X message is delivered per the provided L.MBMS information.

Figure 5.4.2.2-1: L.MBMS based MBMS data delivery

0. The L.MBMS information is preconfigured in the V2X Application Server.

1. The V2X Application Server performs the TMGI Allocation procedure as specified in TS 23.468 [7].

2-3. Steps 2 and 3 are similar to in clause 5.1.2.3.2 of TS 23.468 [7], with the following differences:

– In step 2, the V2X Application Server includes L.MBMS information in an Activate MBMS Bearer Request message. The L.MBMS information is preconfigured in the V2X Application Server.

– In step 3, if the BM-SC uses the L.MBMS information from the V2X Application Server then it copies the MB2-U interface information received from step 2 as MB2-U address (i.e., "BM-SC IP address and port number for the user-plane" information element) in the Activate MBMS Bearer Response message to the V2X Application Server.

4-5. Steps 4 and 5 are similar to in clause 8.3.2 of TS 23.246 [8], with the following differences:

– In step 4, the BM-SC includes the M1 interface information of the L.MBMS information received from the V2X Application Server in the Session Start Request message if the BM-SC decided to use the L.MBMS information.

– In steps 4 and 5, if the MBMS-GW uses the M1 interface information received from the BM-SC then it skips the allocation procedure for IP multicast distribution, e.g. allocate an IP multicast address.

6-10. Same to steps 3 to 6 and step 8 in clause 8.3.2 of TS 23.246 [8].

11. The V2X Application Server sends V2X message to the L.MBMS’s IP address via MB2-U.

If BM-SC does not use L.MBMS information received from V2X Application Server, then BM-SC allocates the addresses related to MB2-U interface as currently specified in TS 23.468 [7]. V2X Application Server is aware that the BM-SC is not using L.MBMS information when the MB2-U address received from step 3 is different than the one in the L.MBMS information provided in step 2. In this case, V2X Application Server shall continue with procedure as defined in TS 23.468 [7].

The L.MBMS support using xMB interface requires same information to be provided via xMB-C using Service Management Procedures as defined in TS 26.348 [29]. For MBMS latency improvements, the V2X Application Server may provide the BM-SC with L.MBMS (Local MBMS) information, i.e., M1 interface information including transport network IP Multicast Address, IP address of multicast source and C-TEID, as well as xMB-U interface information including IP address and UDP port number for the user plane. This L.MBMS information is preconfigured in the V2X Application Server.

5.5 V2X impacts to EPC procedures

5.5.1 E-UTRAN attach procedure for UE

The E-UTRAN attach procedure for UE is performed as defined in TS 23.401 [6] with the following additions:

– The UE includes the V2X capability indication as part of the "UE Network Capability" in the Attach Request message. The MME stores this information for V2X operation. The V2X capability can indicate whether the UE is capable of supporting V2X communication over PC5 reference point.

– If the UE indicated V2X capability, and the UE is authorized to use V2X communication over PC5 reference point based on the subscription data, then the MME shall include a "V2X services authorized" indication in the S1-AP Initial Context Setup Request, indicating the UE is authorized to use V2X communication over PC5 reference point as Vehicle UE, Pedestrian UE or both.

– The MME obtains the UE-PC5-AMBR from the HSS as part of the subscription data and includes it in the S1-AP Initial Context Setup Request to the eNodeB, which use it in resource management of UE’s PC5 transmission for V2X services in network scheduled mode.

5.5.2 Service Request procedures for UE

The Service Request procedures for UE are performed as defined in TS 23.401 [6] with the following additions:

– If the UE is V2X capable, and the UE is authorized to use V2X communication over PC5 reference point based on the subscription data, then the MME shall include a "V2X services authorized" indication in the S1-AP Initial Context Setup Request, indicating the UE is authorized to use V2X communication over PC5 reference point as Vehicle UE, Pedestrian UE or both.

– The MME includes the UE-PC5-AMBR in the S1-AP Initial Context Setup Request to the eNodeB which stores it as part of the UE context and may use it in resource management of UE’s PC5 transmission for V2X services in network scheduled mode.

5.5.3 S1 Handover procedures for UE

The Intra-E-UTRAN S1-based handover or the Inter-RAT to E-UTRAN handover procedures for UE are performed as defined in TS 23.401 [6] with the following additions:

– If the UE is V2X capable, and the UE is authorized to use V2X communication over PC5 reference point based on the subscription data, then the target MME shall send the "V2X services authorized" indication and UE-PC5-AMBR to the target eNodeB as follows:

– For the intra MME handover, the "V2X services authorized" indication and UE-PC5-AMBR are included in the S1-AP Handover Request message. If after the handover procedure, the "V2X services authorized" indication or the UE-PC5-AMBR or both are changed, the updated "V2X services authorized" indication or the updated UE-PC5-AMBR or both are included in the S1-AP UE Context Modification Request message sent to the target eNodeB.

– For the inter MME handover or Inter-RAT handover to E-UTRAN, the "V2X services authorized" indication and UE-PC5-AMBR are included in the S1-AP UE Context Modification Request message sent to the target eNodeB after the handover procedure.

The "V2X services authorized" indication sent to target eNodeB denotes the UE is authorized to use V2X communication over PC5 reference point as Vehicle UE, Pedestrian UE or both.

5.5.4 X2 Handover procedures for UE

For the X2-based handover, the "V2X services authorized" indication and the UE-PC5-AMBR are sent to target eNodeB as follows:

– If the source eNodeB is V2X-enabled and the "V2X services authorized" indication is included in the UE context, then the source eNodeB shall include a "V2X services authorized" indication and UE-PC5-AMBR in the X2-AP Handover Request message to the target eNodeB.

– If the UE is V2X capable, and the UE is authorized to use V2X communication over PC5 reference point based on the subscription data, then the MME shall send the "V2X services authorized" indication and the UE-PC5-AMBR to the target eNodeB in the Path Switch Request Acknowledge message. If, after the handover procedure, the "V2X services authorized" indication or the UE-PC5-AMBR or both are changed, the updated "V2X services authorized" indication or the updated UE-PC5-AMBR or both are included in the S1-AP UE Context Modification Request message sent to the target eNodeB.

The "V2X services authorized" indication sent to target eNodeB denotes the UE is authorized to use V2X communication over PC5 reference point as Vehicle UE, Pedestrian UE or both.

The UE-PC5-AMBR is sent to target eNodeB for the resources management of UE’s PC5 transmission in V2X communication.

5.5.5 Tracking Area Update procedure for UE

The Tracking Area Update procedures for UE are performed as defined in TS 23.401 [6] with the following additions:

– The UE includes the V2X capability indication as part of the "UE Network Capability" in the Tracking Area Update Request message. The MME stores this information for the V2X operation.

– If the MME determines to re-establish the radio and S1 bearers for all active EPS bearer contexts due to the "active" flag included in the Tracking Area Update Request message or the pending downlink data or signalling, the UE is V2X capable, and the UE is authorized to use V2X communication over PC5 reference point based on the subscription data, then the MME shall include a "V2X services authorized" indication and UE-PC5-AMBR in the S1-AP Initial Context Setup Request. The "V2X services authorized" indication sent to eNodeB denotes the UE is authorized to use V2X communication over PC5 reference point as Vehicle UE, Pedestrian UE or both.

5.5.6 Insert Subscriber Data procedure for UE

The Insert Subscriber Data procedures for UE are performed as defined in TS 23.401 [6] with the following additions:

– If the "V2X services authorized" indication or the UE-PC5-AMBR or both need to be changed due to the changed subscription data and the S1 bearer is established, then the MME shall notify the eNodeB the updated "V2X services authorized" indication or the UE-PC5-AMBR or both via the S1-AP UE Context Modification Request message.

5.5.7 Delete Subscriber Data procedure for UE

Delete Subscriber Data procedure for UE is performed as defined in TS 29.272 [15] with the same additions as in clause 5.5.6.

5.5.8 V2X capability indication and V2X related information per PC5 RAT

A UE may support multiple PC5 RATs (i.e. LTE PC5 and NR PC5). For such UE, the V2X capability indication for NR PC5 and V2X related information (i.e. "V2X services authorized" indication and UE-PC5-AMBR) described in clauses 5.5.1 to 5.5.7 is per PC5 RAT.

5.5.9 Support of V2X communication over NR PC5 reference point

To support V2X communication over NR PC5 reference point, the EPC procedures described in clauses 5.5.1 to 5.5.7 are applied with the following differences:

– The PC5 QoS parameters may be included in the S1-AP Initial Context Setup Request, S1-AP Handover Request, S1-AP UE Context Modification Request, X2-AP Handover Request, and Path Switch Request Acknowledge messages.

NOTE: Non-UE specific PC5 QoS parameters, e.g. default PC5 QoS parameters, can also be locally configured in E-UTRAN. How such configuration is performed is out of scope of this specification.

Annex A (informative):
Road Side Unit (RSU) implementation options

This Annex presents examples how RSU can be implemented. With reference to the architectural reference models defined in clause 4.2, the RSU can receive V2X messages via SGi, PC5 or LTE-Uu interface depending on implementation option.

Figure A-1 shows a UE-type RSU, which combines a UE with the V2X application logic.

Figure A-1: RSU includes a UE and the V2X application logic

Figure A-2 shows one example of eNB-type RSUs. In this example, the RSU comprises an eNB, a collocated L-GW, and a V2X Application Server.

Figure A-2: RSU includes an eNB, L-GW and a V2X Application Server

Annex B (informative):
Localized MBMS deployment options