Content for TS 23.285 Word version: 18.0.0

5.1 Control and user plane stacks 5.2 Service authorization and update for V2X communications 5.3 Procedure for 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.2 Procedure for V2X communication with MBMS
...

5 Functional description and information flows p. 24

5.1 Control and user plane stacks p. 24

5.1.1 User plane for PC5 reference point supporting V2X services p. 24

The PC5-U stack as defined in clause 5.1.2.1 of TS 23.303 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.

5.2 Service authorization and update for V2X communications p. 25

5.2.1 Service authorization procedures p. 25

The service authorization procedures as specified in clause 5.2.1 of TS 23.303 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 p. 25

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

5.3 Procedure for V2X communication over PC5 reference point p. 25

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 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 is applied to V2X communication over PC5 reference point.

5.4 Procedure for V2X communication over LTE-Uu reference point p. 25

5.4.1 V2X Application Server discovery using MBMS p. 25

5.4.1.1 General p. 25

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 p. 26

Copy of original 3GPP image for 3GPP TS 23.285, Fig. 5.4.1.2-1: V2X Application Server discovery using broadcast

Figure 5.4.1.2-1: V2X Application Server discovery using broadcast
(⇒ copy of original 3GPP image)

Step 1.

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

Step 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.

Step 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.

Step 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 p. 26

5.4.2.1 MBMS service area mapping p. 26

5.4.2.1.1 General p. 26

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, and clause 5.4.2.2 of TS 23.285, 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.

5.4.2.1.2 Functional Description p. 27

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.

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.

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 when using xMB interface.

5.4.2.2 Local MBMS based MBMS data delivery p. 27

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.

Copy of original 3GPP image for 3GPP TS 23.285, Fig. 5.4.2.2-1: L.MBMS based MBMS data delivery

Figure 5.4.2.2-1: L.MBMS based MBMS data delivery
(⇒ copy of original 3GPP image)

Step 0.

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

Step 1.

The V2X Application Server performs the TMGI Allocation procedure as specified in TS 23.468.

Step 2-3.

Steps 2 and 3 are similar to in clause 5.1.2.3.2 of TS 23.468, 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.

Step 4-5.

Steps 4 and 5 are similar to in clause 8.3.2 of TS 23.246, 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.

Step 6-10.

Same to steps 3 to 6 and step 8 in clause 8.3.2 of TS 23.246.

Step 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. 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.

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. 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.