8 Advanced V2X support

21.9163GPPRelease 16Release descriptionTS

8.1 Improvement of V2X service Handling

820024

Improvement of V2X service Handling

V2XIMP

S1

SP-181013

SungDuck Chun; LG Electronics

Summary based on the input provided by LG Electronics France in SP-200126.

This WI introduces the requirements related to vehicle quality of service support, which enables a V2X application to be timely notified of expected or estimated change of quality of service (QoS). For example, when the communication packet error is expected to increase or decrease, the V2X application such as platooning application can increase or decrease inter-vehicle distance.

This Work Item has mostly concluded that a standardized interface is needed towards external V2X application servers. Using this standardized interface, the V2X application servers can request a specific QoS requirements (and, optionally, related alternative QoS requirements). It can also be notified when the requested QoS requirements (and/or the alternative QoS requirements) can or cannot be met.

The information that is delivered over the interface can be past statistics or future prediction.

With this information, the V2X applications can adapt its behaviour according to the QoS that can be provided by the 3GPP System.

Stage-2/3 works related to this WI were progressed within eV2XARC WI (see below).

Reference

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820024

[1] TS 22.186: "Enhancement of 3GPP support for V2X scenarios; Stage 1".

8.2 Architecture enhancements for 3GPP support of advanced V2X services

840078

Architecture enhancements for 3GPP support of advanced V2X services

eV2XARC

S2

SP-181121

LaeYoung Kim, LG Electronics

760043

Study on eV2XARC

FS_eV2XARC

S2

SP-180733

LaeYoung Kim, LG Electronics

820018

Stage 2 of eV2XARC

eV2XARC

S2

SP-181121

LaeYoung Kim, LG Electronics

840011

CT aspects of eV2XARC

eV2XARC

ct

CP-191154

Herrero Veron, Christian (Huawei)

840079

CT1 aspects of eV2XARC

eV2XARC

C1

CP-191154

Herrero Veron, Christian (Huawei)

840080

CT3 aspects of eV2XARC

eV2XARC

C3

CP-191154

Herrero Veron, Christian (Huawei)

840081

CT4 aspects of eV2XARC

eV2XARC

C4

CP-191154

Herrero Veron, Christian (Huawei)

840082

CT6 aspects of eV2XARC

eV2XARC

C6

CP-191154

Herrero Veron, Christian (Huawei)

Summary based on the input provided by LG Electronics in SP-200058.

Based on the requirements specified by V2XIMP in TS 22.185 [2] and TS 22.186 [3], the "Architecture enhancements to the 5G System" are specified in TS 23.287 [1] in order to facilitate vehicular communications for Vehicle-to-Everything (V2X) services. The following reference points are defined in the architectural reference models:

– PC5 reference point: NR PC5 RAT, LTE PC5 RAT.

– Uu reference point: NR, E-UTRA.

The Stage 2 of the interworking between EPS V2X and 5GS V2X is also specified .

The various parameters for V2X communications over PC5 and Uu reference points are specified and these parameters may be made available to the UE in following ways:

– pre-configured in the ME; or

– configured in the UICC; or

– preconfigured in the ME and configured in the UICC; or

– provided/updated by the V2X Application Server via PCF and/or V1 reference point; or

– provided/updated by the PCF to the UE.

In addition to PCF initiated Policy Provisioning procedure, the UE may perform UE triggered Policy Provisioning procedure to the PCF when the UE determines the V2X Policy/Parameter is invalid (e.g. Policy/Parameter is outdated, missing or invalid).

Regarding V2X communication over PC5 reference point, two types of PC5 reference points exist: the LTE based PC5 reference point as defined in TS 23.285 [4], and the NR based PC5 reference point as defined in TS 23.287 [1]. A UE may use either type of PC5 or both for V2X communication depending on the services the UE supports. The V2X communication over PC5 reference point supports roaming and inter-PLMN operations. V2X communication over PC5 reference point is supported when UE is "served by NR or E-UTRA" or when the UE is "not served by NR or E-UTRA".

V2X communication over NR based PC5 reference point supports broadcast mode, groupcast mode and unicast mode. For unicast mode, Layer-2 link establishment, Link identifier update, Layer-2 link release, Layer-2 link modification and Layer-2 link maintenance procedures are specified. Per-Flow PC5 QoS Model is introduced for V2X communication over NR based PC5 reference point.

Architecture enhancements for EPS to support V2X communication over NR PC5 reference point are specified in TS 23.285 [4].

For V2X communication over Uu reference point, only unicast is supported. Latency reduction for V2X message transfer via unicast may be achieved by using various mechanisms, including via e.g., edge computing defined in TS 23.501 [5].

Notification on QoS Sustainability Analytics to the V2X Application Server is specified so that the V2X Application Server may request notifications on QoS Sustainability Analytics for an indicated geographic area and time interval in order to adjust the application behaviour in advance with potential QoS change.

To support V2X applications that can operate with different configurations (e.g. different bitrates or delay requirements), the V2X Application Server, acting as the Application Function, can provide, in addition to the requested level of service requirements, Alternative Service Requirements to the 5G System. This enables the 5G System to act on the Alternative Service Requirements and apply them for the extended NG-RAN notification (i.e. Alternative QoS Profiles are provided from SMF to NG-RAN), as described in TS 23.501 [5] and TS 23.503 [6].

In order to facilitate deployment of dedicated network slice for use of, for example, automotive industry and to facilitate roaming support, a new standardized Slice/Service Type (SST) value dedicated for V2X services, i.e. 4 is defined in TS 23.501 [5].

Security aspects of 3GPP support for advanced V2X services are specified in TS 33.536 [7].

Stage 3 normative works made by CT working groups are specified in TS 24.587 [8] and TS 24.588 [9] that are new specifications for V2X as well as many specifications listed in the WID on CT aspects of architecture enhancements for 3GPP support of advanced V2X services [10].

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840078,760043,820018,840011,840079,840080,840081,840082

[1] TS 23.287: "Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services".

[2] TS 22.185: "Service requirements for V2X services; Stage 1".

[3] TS 22.186: "Enhancement of 3GPP support for V2X scenarios; Stage 1".

[4] TS 23.285: "Architecture enhancements for V2X services".

[5] TS 23.501: "System Architecture for the 5G System; Stage 2".

[6] TS 23.503: "Policy and Charging Control Framework for the 5G System; Stage 2".

[7] TS 33.536: "Security aspects of 3GPP support for advanced Vehicle-to-Everything (V2X) services".

[8] TS 24.587: "Vehicle-to-Everything (V2X) services in 5G System (5GS); Stage 3".

[9] TS 24.588: "Vehicle-to-Everything (V2X) services in 5G System (5GS); User Equipment (UE) policies; Stage 3".

[10] 3GPP CP-192078: "WID: CT aspects of architecture enhancements for 3GPP support of advanced V2X services".

8.3 Application layer support for V2X services

840074

Application layer support for V2X services

V2XAPP

S6

SP-180898

Niranth Amogh, Huawei Tel.India

780025

Study on V2XAPP

FS_V2XAPP

S6

SP-171071

Niranth Amogh, Huawei Tel.India

810020

Stage 2 of V2XAPP

V2XAPP

S6

SP-180898

Niranth Amogh, Huawei Tel.India

840010

CT aspects of V2XAPP

V2XAPP

ct

CP-191153

Herrero Veron, Christian (Huawei)

840075

CT1 aspects of V2XAPP

V2XAPP

C1

CP-191153

Herrero Veron, Christian (Huawei)

840076

CT3 aspects of V2XAPP

V2XAPP

C3

CP-191153

Herrero Veron, Christian (Huawei)

840077

CT4 aspects of V2XAPP

V2XAPP

C4

CP-191153

Herrero Veron, Christian (Huawei)

Summary based on the input provided by Huawei in SP-200938.

The V2X application layer can be divided primarily into a V2X application specific layer which consists of V2X specific applications (e.g. Platooning, Vehicle safety) and a V2X application support layer which consists of V2X enabler services (e.g. V2X service discovery, message delivery, service continuity) and common enabler services (e.g. Group management, configuration management, location management).

The following figure provides the high level illustration of the V2X application layer.

Figure 1: Application layer support for V2X services

In Release 16, in order to ensure efficient use and deployment of V2X applications on 3GPP network (EPS), a V2X application layer architecture is specified with primary focus on the V2X application support aspects consisting of V2X application enabler (VAE) as specified in TS 23.286 [5] and Service Enabler Architecture Layer (SEAL) as specified in TS 23.434 [6].

In this clause, the enabler services utilized by V2X application specific layer are summarized. The V2X application enabler capabilities takes into consideration the study in TR 23.795 [4], the existing stage 1 and stage 2 work within 3GPP related to V2X in TS 22.185 [1], TS 22.186 [2] and TS 23.285 [3], as well as V2X application standards defined outside 3GPP (e.g. ETSI, SAE).

The V2X application specific layer utilizes the enabler services provided by VAE layer or SEAL. The architecture allows for flexible deployments considering V2X application support layer being deployed centrally or deployed in a distributed manner by either a V2X service provider or PLMN operator or both.

The following features are specified in Rel.16 for the support of V2X application specific layer:

a. The following VAE capabilities are specified in TS 23.286 [5], the related detailed procedures over HTTP protocol between VAE client (V2X UE) and VAE server are specified in TS 24.486 [7] and the RESTful APIs provided by VAE server towards the V2X application specific server is specified in TS 29.486 [8]:

• V2X service discovery to enable V2X UE to discover V2X services provided by V2X application servers via VAE server, V2X UE register at VAE server for receiving V2X services from V2X application specific servers and V2X message distribution/delivery (including group communication) for V2X messages originated from the V2X application specific layer (Uplink and/or Downlink).

• Application level location tracking of the V2X UE(s) as per the geographical information provided by the V2X application specific layer.

• V2X service continuity by dynamically receiving local service information and discovery of appropriate VAE server to serve the V2X UE as per the geographical area corresponding to V2X UE mobility.

• Dynamic group management for scenarios like Platooning where the groups are enabled by V2X application specific server and the related V2V configurations/provisioning to the V2X UE are enabled by VAE server.

• V2X UE subscription and notification of network situation information to support V2X UE level application adaptations.

• Communication of V2X application specific layer requirement to the EPC by translating the application requirements to the network requirements.

• Supporting file distribution from V2X application specific server to the V2X UEs using xMB APIs as specified in TS 26.348 [9].

b. The following SEAL capabilities specified in TS 23.434 [6] are used by V2X application layer and more details about the following services are provided in clause 9.4:

• Group management service

• Configuration management service

• Location management service

• Network resource management service

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840074,780025,810020,840010,840075,840076,840077

[1] TS 22.185: "Service requirements for V2X services; Stage 1".

[2] TS 22.186: "Enhancement of 3GPP support for V2X scenarios; Stage 1".

[3] TS 23.285: "Architecture enhancements for V2X services".

[4] TR 23.795: "Study on application layer support for V2X services".

[5] TS 23.286: "Application layer support for Vehicle-to-Everything (V2X) services; Functional architecture and information flows".

[6] TS 23.434: "Service enabler architecture layer for verticals; Functional architecture and information flows".

[7] TS 24.486: "Vehicle-to-Everything (V2X) Application Enabler (VAE) layer; Protocol aspects; Stage 3".

[8] TS 29.486: "V2X Application Enabler (VAE) Services; Stage 3".

[9] TS 26.348: "Northbound Application Programming Interface (API) for Multimedia Broadcast/Multicast Service (MBMS) at the xMB reference point".

8.4 5G V2X with NR sidelink

830078

5G V2X with NR sidelink

5G_V2X_NRSL

R1

RP-190984

LG Electronics

830178

Core part: 5G V2X with NR sidelink

5G_V2X_NRSL-Core

R1

RP-190766

LG Electronics

830278

Perf. part: 5G V2X with NR sidelink

5G_V2X_NRSL-Perf

R4

RP-190766

LG Electronics

Summary based on the input provided by LG Electronics in RP-200855.

3GPP RAN technology for sidelink communication based on 5G NR was specified through this WI to define the means for providing the advanced V2X services identified by 3GPP SA1. This WI corresponds to 3GPP V2X phase 3, which is the evolution of LTE V2X in Release 14 (phase 1) and 15 (phase 2).

This section provides a summary of the key functionalities of NR sidelink.

Physical layer structure

Sidelink bandwidth part (BWP) is defined to support the flexible numerologies in operating on various spectrum band such as the intelligent transport system (ITS) dedicated band and the licensed band of frequency range 1 (FR1) and FR2. For sidelink synchronization, GNSS, gNB/eNB and the NR sidelink UE can be used as a synchronization reference source of a UE.

The NR V2X sidelink uses the following physical channels and signals:

– Physical sidelink broadcast channel (PSBCH) and its de-modulation reference signal (DMRS)

– Physical sidelink control channel (PSCCH) and its DMRS

– Physical sidelink shared channel (PSSCH) and its DMRS

– Physical sidelink feedback channel (PSFCH)

– Sidelink primary and secondary synchronization signals (S-PSS and S-SSS)

– Phase-tracking reference signal (PT-RS) in FR2

– Channel state information reference signal (CSI-RS)

Sidelink control information (SCI) in NR V2X is transmitted in two stages. The first-stage SCI is carried on PSCCH and contains information to enable sensing operations, as well as information about the resource allocation of the PSSCH. PSSCH transmits the second-stage SCI and the sidelink shared channel (SL-SCH) transport channel. The second-stage SCI carries information needed to identify and decode the associated SL-SCH, as well as control for hybrid automatic repeat request (HARQ) procedures, and triggers for channel state information (CSI) feedback, etc. SL-SCH carries the transport block (TB) of data for transmission over SL.

PSCCH and PSSCH are multiplexed in time and frequency within a slot for short latency and high reliability. DRMS is frequency multiplexed with PSCCH or PSSCH in the corresponding DMRS symbols. PSFCH, which is used for sidelink HARQ feedback for unicast and groupcast, is transmitted at the end of a slot, which is preceded by an additional guard symbol and an automatic gain control (AGC) symbol. Two multiplexing examples are shown in Figure 1(a) and 1(b).

Figure 1(a) Example slot format of 2-symbol PSCCH, 2-symbol PSSCH-DMRS, and no PSFCH.

Figure 1(b) Example slot format of 3-symbol PSCCH, 3-symbol PSSCH-DMRS, and PSFCH.

Resource allocation

There are two resource allocation modes: mode 1 and mode 2. Mode 1 for resource allocation by gNB and Mode 2 for UE autonomous resource selection are very similar to Mode 3 and Mode 4 in LTE sidelink respectively. For mode 1, gNB schedules to UE the dynamic grant resources by downlink control information (DCI), or the configured grant resource type 1 and type 2 by radio resource control (RRC) signalling and DCI respectively.

In Mode 2, the sensing operation to determine transmission resources by UE comprises 1) sensing within a sensing window, 2) exclusion of the resources reserved by other UEs, and 3) select the final resources within a selection window. In Mode 2, shortly before transmitting in a reserved resource, a sensing UE re-evaluates the set of resources to check whether its intended transmission is still suitable, considering a possible aperiodic transmission after the resource reservation. If the reserved resources would not be part of the set for selection at this time, then new resources are selected from the updated resource selection window. In addition to the re-evaluation, pre-emption is also introduced such that a UE selects new resources even after it announces the resource reservation when it observes resource collision with a higher priority transmission from another UE.

Sidelink HARQ feedback, sidelink CSI and PC5-RRC for unicast and groupcast

NR sidelink supports sidelink HARQ-ACK for sidelink unicast and groupcast services for improved reliability. Two sidelink HARQ feedback operations are defined, HARQ-ACK with ACK and NACK, and HARQ-ACK with NACK only. When ACK/NACK operation is used, the sidelink HARQ-ACK procedure is similar to that of Uu for non-codeblock group feedback, i.e. the HARQ-ACKis transmitted based on the success or failure of the whole transport block. NACK-only operation is defined for groupcast to allow a a larger number of Rx UEs to share a single PSFCH resource by sending feedback only when a Rx UE receives SCI but fails to decode the transport block. The transmission of NACK-only feedback can be restricted to UEs within given a radius, and any UE beyond it does not provide any HARQ-ACK. This minimum range requirement of a service is provided together with the associated QoS parameters from service layers. For mode 1, sidelink HARQ-ACK information is reported to gNB to indicate whether additional retransmission resources are required or not.

In sielink unicast transmission, Tx UE can configure aperiodic sidelink CSI reporting from the Rx UE to get information it can use for sidelink link adaptation and rank adaptation. CQI and RI are reported via MAC layer signalling, in a PSSCH transmission for this purpose. In addition, radio link monitoring is adopted to manage a sidelink connection.

Figure 2 PC5 control plane (PC5-C) protocol stack for RRC.

To support exchange of the AS layer configuration and UE capability information between UEs, PC5-RRC is defined for unicast sidelink communication. The AS protocol stacks of the control plane for RRC is depicted in Figure 2.

Cross-RAT and in-device coexistence between LTE V2X and NR V2X sidelinks

Depending on the NR V2X and LTE V2X deployment, it is envisaged that an optional UE design can be supported where a device has both an LTE-V2X RAT and an NR-V2X RAT which are able to inter-communicate. 5G V2X defines two Cross-RAT operations. LTE Uu can control NR resource allocation mode 1 by providing configured grant Type 1 configurations via LTE RRC signalling, and resource allocation mode 2 by LTE Uu RRC providing the semi-static configurations relevant to resource pools, sensing, etc. NR Uu can control LTE resource allocation mode 3 by transmitting an NR DCI which contains the information needed to dynamically control the LTE sidelink, and resource allocation mode 4 by NR Uu RRC providing the necessary semi-static configurations within which the LTE-V2X RAT autonomously selects resources for sidelink transmission.

It is envisaged that there will exist devices that support both LTE-V2X and NR-V2X, and which will be operating in both systems concurrently. If the two RATs are widely spaced in frequency, e.g. being in different bands, then there need be no particular issues to consider since it is assumed that a separate RF chain will be provided for each band. If, however, a sufficiently close frequency spacing is deployed, then it is desirable to enable a single RF chain to be used in the implementation. In this case, the simultaneous transmission on both RATs is prevented by the UE’s single power budget, and one RAT cannot be received/transmitted while the other RAT is doing the opposite. In this case, one of the RATs may be dropped at times when both occur simultaneously, but that in some cases where the priority of the V2X service on both RATs is known, the higher priority one is automatically selected.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830078,830178,830278

– RP-200129, “Revised WID on 5G V2X with NR sidelink”

– TR37.985, “Overall description of Radio Access Network (RAN) aspects for Vehicle-to-everything (V2X) based on LTE and NR (Release 16).”

– TR38.886, “V2X Services based on NR; User Equipment (UE) radio transmission and reception.”

– Last status report in RP-200854