Received August 19, 2020, accepted August 28, 2020, date of publication October 5, 2020, date of current version October 30, 2020.

Digital Object Identifier 10.1109/ACCESS.2020.3028621

V2X Support in 3GPP Specifications: From 4G to5G and BeyondDAVID GARCIA-ROGER 1, EDGAR E. GONZÁLEZ 1,2, DAVID MARTÍN-SACRISTÁN 3,AND JOSE F. MONSERRAT 1, (Senior Member, IEEE)1Universitat Politècnica de València, ITEAM Research Institute, 46022 Valencia, Spain2Universidad Tecnológica Israel, Quito 170516, Ecuador3Fivecomm, 46022 Valencia, Spain

Corresponding author: David Garcia-Roger (dagarro@iteam.upv.es)

This work was supported in part by the European Union’s H2020 project 5G-CARMEN under Grant 825012, and in part by the Ministeriode Ciencia e Innovación under Grant RTI2018-099880-B-C31.

ABSTRACT The connected car concept is gaining momentum from the point of view, not only of research,but also of standardization and industrial development. Today there are many options for connecting avehicle, in terms of to whom and how. In addition to making use of any conventional cellular technology,and connecting the vehicle to a base station or infrastructure element, vehicles can connect wirelessly anddirectly to each other using different technologies, both from the Institute of Electrical and ElectronicsEngineers (IEEE) and from the 3rd Generation Partnership Project (3GPP). This article offers a rigorousand detailed review of the system architecture aspects involved in the support of vehicular communicationsby the 3GPP fifth-generation (5G) standard, with special emphasis on its most recent iteration: Release 16.

INDEX TERMS Standards, 3GPP Rel-16, multi-connectivity, V2X, C-V2X, sidelink, PC5.

I. INTRODUCTIONThe advent of Vehicle-to-Everything (V2X) communicationtechnologies has made possible new use cases aiming atimproving the living standards for people around the world.V2X, in its purest definition, interconnects a road vehicle toany entity that may concern it. In this sense, experts antici-pate that the application of V2X to the benefit of IntelligentTransportation Systems (ITS) will be one of its most usefulrealizations, with the promise of efficient road traffic man-agement for the reduction of collisions, diminishing drivingtimes, improving fuel efficiency, and pollution prevention,among others. Moreover, V2X technical proposals strive forintegrating disparate Quality of Service (QoS) requirements,and this, in turn, is inspiring new use cases that range fromservices based on vehicular communications to complex sys-tems, for example, the self-driving car, which also will needto be, undoubtedly, a connected car.

Two alternative access layer technologies for ITS havebeen defined by the Institute of Electrical and Electron-ics Engineers (IEEE) and the Third Generation Partner-ship Project (3GPP), respectively. The first approach is

The associate editor coordinating the review of this manuscript and

approving it for publication was Danping He .

Dedicated Short Range Communication (DSRC), which sup-ports vehicular ad-hoc connectivityWireless Local Area Net-work (WLAN) technologies standardized as IEEE 802.11p[1]—which is the basis for the European standard ETSI ITS-G5. The second approach is Cellular-based V2X (C-V2X)[2], a proposal by the 3GPP, based on Long-Term Evolution(LTE), also known as LTE-V2X.

Both ETSI ITS (the current European vehicular commu-nication technology standard) and the American IEEE 1609family of standards, also known as Wireless Access in Vehic-ular Environments (WAVE) may operate with either IEEE802.11p/ITS-G5 or C-V2X as access technologies. In fact,to make the deployment of both approaches possible, theseaccess layers have been standardized as European Stan-dard/Norms (ENs) that specify the operative details for theiruse in the 5.9 GHz ITS band in Europe. Similarly, in the US,the IEEE 1609 and the application layer message standardsof the Society of Automotive Engineers (SAE) Internationaladmit either access layer, with SAE International even defin-ing profiles an testing standards for each access layer. Addingto this is the layered definition of the IEEE 1609 standards,which allow WAVE the use of C-V2X and not only of a802.11p based access layer; and also makes possible thatLTE-V2X may be able to use WAVE security standards such

190946 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ VOLUME 8, 2020

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

as IEEE 1609.2; in fact, the WAVE Network Services stan-dard (IEEE 1609.3) has been updated to operate with DSRCor LTE-V2X, equally.

More recently, New Radio (NR) V2X has been specifiedin Release 16 (Rel-16) as a complementary access technol-ogy defined to better serve sophisticated applications anduse cases with more stringent requirements (e.g. platooning,advanced driving, etc.) [3]. This article provides a detailedanalysis of the status of the Rel-16 standard for C-V2X com-munications based on Fifth Generation (5G) NR technology.The progression of the standard from Fourth Generation (4G)C-V2X to 5G C-V2X will be analyzed, and requirements,specifications and modes of operation will be detailed froman architectural viewpoint. For an examination of 3GPP NRsidelink transmissions, and key knowledge of the Physicallayer (PHY) structure in Rel-16, see [4].

The present paper is organized as follows. Section II cov-ers the support of V2X in 3GPP specifications. Subsec-tion II-A provides an overview of 3GPP releases for V2Xcommunications. Additionally, Subsection II-B deals withspecific aspects of use cases, architectures, communicationmodes/interfaces and Radio Access Network (RAN) featuresdefined in Release 14 (Rel-14) and Release 15 (Rel-15). Sim-ilarly, Subsection II-C details the architecture enhancementsproposed byRel-16, while Subsection II-D covers an exampleof potential use of Rel-16 technology. Section III coversfuture, mid-term and long-term expected enhancements toV2X, with Subsection III-A summarizing planning aspectsof Release 17 (Rel-17) that are directly related to V2X, andSubsection III-B commenting on the state-of-the-art techno-logical vision that will be indispensable for conceiving newV2X applications in a future beyond 5G. Finally, Section IVconcludes the paper.

II. SUPPORT FOR V2X IN 3GPP SPECIFICATIONSA. OVERVIEW OF RELEASESFor the 3GPP, V2X is an all-encompassing concept iden-tifying the list of enhancements developed (radio access,protocols, core network) to support the following categoriesof vehicular communications:

• Vehicle-to-Vehicle (V2V), directly between vehicularUser Equipments (UEs);

• Vehicle-to-Pedestrian (V2P), between a vehicle and theUE of a pedestrian;

• Vehicle-to-Infrastructure (V2I), between a vehicle andfixed road infrastructure, for example, a Roadside Unit(RSU), providing V2X applications with connectivitysupport to other UEs

• Vehicle-to-Network (V2N), wide area communicationover the cellular network between vehicles and a cellularnetwork entities, for the support of V2X traffic opera-tions.

Rel-14 [5] is the first 3GPP standard introducing 4Genhancements for V2X communications. Rel-14 put a spe-cial focus on the support of V2V by the Evolved Packet

System (EPS). The EPS is the 3GPP’s 4G solution bringingtogether LTE (a mobile broadband, high-speed, low-latency,radio communication interface) with the System Architec-ture Evolution (SAE), a non-hierarchical, Internet Protocol(IP) data service-based, control/user plane traffic segregatingarchitecture, whose key element is the Evolved Packet Core(EPC). This effort was specifically aimed at the automotiveuse case verticals, and thus, a working topic of the foremostimportance.

Rel-15 [6] is the first standard dealing with 5G, and itdefines the initial iteration (5G Phase 1) of the 5G System(5GS), its architecture, and functionality. In architecturalterms, Rel-15 specified the service-based approach for the5G Core Network (5GC), the support for data connectivityover NR and LTE access technologies, and functionalitiesfor the enhancement of mobility, QoS, traffic steering, andnetwork slicing. However, note that the 3GPP explicitly statedin Technical Specification (TS) 23.501 that V2X is one of thefunctionalities supported in Rel-14 EPS for which there is nosupport in Rel-15 5GS.

Rel-16 [7] is the second step of 3GPP’s 5G project.Specified from Mar. 2017 to Jun. 2020, Rel-16 extends 5Gspecifications in two broad aspects: i) building up the 5Garchitecture; ii) offering support for new specific servicefunctionalities, putting a special focus on key selected usecases that are expected to be essential for the deploymentsof industry verticals such as V2X. Rel-16 defines the 5Gsupporting role for advanced V2X services and vehicle QoSsupport, as well as coexisting NR and LTE sidelink. Thiscoexistence is detailed later in Section II-C6; through theUu interface, a Next Generation Node B (gNB) may controland manage the LTE sidelink; and it is possible for LTE toconfigure the NR sidelink as stated in TS 23.287 [8]. Thismakes the simultaneous use of multiple 3GPP Radio AccessTechnologies (RAT) for direct sidelink transmissions—bothNR-based, and Evolved Universal Terrestrial Radio Access(E-UTRA) based— possible.

Table 1 list all the most recent versions, for each 3GPPrelease (as of September 2020) of every TS that needed tobe explicitly created so as to address a particular aspect ofV2X. Summaries of key RAN enhancements to RAN WorkGroup (WG) 1/2/3/4 already existing standards are includedin Section II-B5 of the present paper for Rel-14 and Rel-15,and in Section II-C6 for Rel-16.

B. REL-14 AND REL-15 ENHANCEMENTS FOR V2X

Rel-14 and Rel-15 iterations of C-V2X comprise the 3GPPdefinitions and architectural considerations needed to providesupport with LTE technology to the diverse V2X target ser-vices shown in Fig. 1 and explained in Section II-B1 below.The LTE V2X effort covered the requirements laid out by

automotive industry use cases for V2X over 3GPP systems.The enhancements proposed by LTE V2X were also con-ceived to facilitate the use of 3GPP systems by automakers,infrastructure providers, and other stakeholders from the ITS

VOLUME 8, 2020 190947

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

TABLE 1. Most recent versions of 3GPP Technical Specifications on V2X.

FIGURE 1. Summary of V2X service categories targeted by 3GPP Rel-14, Rel-15, and Rel-16 specifications.

industry vertical. Table 2 summarizes the main V2X featuresintroduced by each of the 3GPP releases.

1) SUPPORTED USE CASE GROUPSRel-14 defines the main application areas firstly consideredto benefit fromLTEV2X in TS 22.185 [2] (Fig. 1, highlightedwith green background):• Road Safety for the reduction of traffic collisions,with the network honoring strict reliability and latencyrequirements. In LTE V2X, road safety services makeuse of short messages that vehicles broadcast periodi-cally to neighbors at a locally geographical level.

• Traffic Efficiency for the optimization of route plan-ning (for example, for vehicle platooning) by meansof traffic congestion reduction. It assumes that vehiclescollect data from their sensors and send this informationto remote management servers in charge of planningthe route. For the network, the reliability and latency

requirements are less stringent, but high-speed situationsstill need to keep the packet loss and delay in check.

• Infotainment, which groups together classic and futureInternet services for the general improvement of thepassengers’ travel experience (traditional web browsing,data sharing and downloading, social networks), this is,by far, the most flexible category in terms of networkconstraints.

Rel-14 V2X (LTE-V2X) solves these basic safety servicesfrom the data transport point of view, allowing for the trans-mission of messages known as Cooperative Awareness Mes-sage (CAM) or Basic Safety Message (BSM), DecentralizedEnvironmental NotificationMessage (DENM). CAMs/BSMsgenerate messages periodically, and broadcast vehicle infor-mation such as its heading, speed, and geographical coordi-nates. DENMs are triggered by particular events, such as asudden braking, an impending collision, or a traffic jam, and

190948 VOLUME 8, 2020

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

TABLE 2. Distinguishing features of V2X in 3GPP Rel-14, Rel-15, and Rel-16 specifications.

TABLE 3. An example of QoS levels support for V2X communication.

may include diverse messages, according to the reasons fortheir transmission.

An example of QoS levels support for V2X communica-tion, compiled in TS 22.185, is shown in Table 3. The rangeis defined in terms of allotting enough response time for thedriver, as a reasonable safety buffer. Note that the maximumvehicle speed of 500 km/h assumesV2V; this value is reducedto 250 km/h when the communicating actors use V2P or V2I.Finally, the most stringent latency value addresses communi-cations in especially demanding situations, for example pre-crash sensing warning messages.

Building on this success, the Rel-15 effort extends 3GPP’ssupport to enhancedV2X (eV2X), four sets of more advancedlow-latency communication scenarios (Fig. 1, highlightedwith green background), with NR V2X in mind, as stated inTS 22.186 [9]:• Vehicle Platooning for driving a group of vehiclestogether, and the proper management of such groups(addition, removal of vehicles) as and when required.To this end, the lead vehicle periodically transmits datato other vehicles in the platoon, so as to control theoperations of the ensemble of vehicles satisfactorily.Platoon management algorithms allow many vehiclesto accelerate or brake at the same time, thus short-ening the required reacting distance far below human

standards, which reduces the distance between carsor trucks. This closer headway between vehicles hasa beneficial effect in the capacity of roads and fueleconomy.

• Advanced Driving for the support of semi-automatedand full self-driving. This service assumes that vehiclesand road infrastructures, such as RSUs are sharing thedata collected from their local sensors, as well as theirdriving plans with other nearby vehicles. This infor-mation is in turn used by vehicles so as to coordinatemaneuvers and adjust the course of vehicles for safety,Cooperative Collision Avoidance (CCA) and road effi-ciency.

• Extended Sensors for allowing a vehicle to exchange rawor processed data from local sensors (even live videofeeds) with another element present on the road such asanother car, a RSU, a pedestrian’s UE and a V2X Appli-cation Server (V2X AS) (defined in Section II-B2). Thisresults in an enhanced awareness of the extended roadenvironment, which reaches far beyond what mere localsensors may discern.

• Remote Driving for allowing a distant driver or aV2X application to control a remote vehicle. This isof interest in applications such as public transporta-tion or hazardous environments. When the routes arepredictable, the 3GPPs deems interesting to resort toa cloud-based platform offering back-end services andcomputing resources for the proper implementation ofthis use case group.

• General Aspects, an umbrella category for the assistanceof eV2X scenarios, which deals with features commonto all services, such as interwork and communication-related requirements.

VOLUME 8, 2020 190949

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

TABLE 4. Range of performance requirements of each eV2X scenario [9].

Additionally, TS 22.186 is also the first specification cov-ering the particular performance requirements that must bematched by the 5GS—as well as by the EPS. As far asQoS is concerned, the specification compiles an exhaustivelist of use cases for each service, defining the demands forthe transport of their respective V2X messages. The keyrequirements for each communication scenario are shown inTable 4. TS 22.186 covers several degrees of automation.TS 22.186 indicates the scenarios, and the most stringentrequirements are a maximum range of 1 km, a maximumthroughput of 1 Gbps, a smallest maximum latency of 3 ms,a maximum reliability of 99.999%, and a maximum trans-mission rate of 100 messages/second. The corresponding usecases are covered in Technical Report (TR) 22.886.

FIGURE 2. EPS Architecture for V2X.

2) LTE ARCHITECTURE FOR V2X COMMUNICATIONSFigure 2 offers an overview of the V2X architecture overthe EPC as defined by the Rel-14, and Rel-15 iterations ofTS 23.285 [10]. The specification describes the EPC entitiestaking part in V2X communications, their roles, as well as theinvolved interfaces. It also introduces a new functional entity,a dedicated V2X Control Function, for the management ofthe V2X-related parameters of UEs, the parameters that mustbe supplied, and the details on the procedures used.

As stated in TS 23.285, there are four different options forconfiguring the V2X policy/parameters of the UE: i) stored

in the Universal Integrated Circuit Card (UICC); ii) precon-figured on the Mobile Equipment (ME); iii) provisioned bythe V2X Control Function via interface V3; iv) configured bythe Application Server (AS) via interface V1. Elaborating onthe configuration provisioned by the V2X Control Function(for illustrative purposes only), the configuration is initiatedby the UE when the UE connects to the EPS through aPacket Data Network (PDN) connection. In general terms, theconfiguration actions performed by the logical V2X ControlFunction deal with provisioning of the required V2X parame-ters and the authorization procedure specified by the protocolin TS 24.386 [11] between the UE and the V2X ControlFunction.

Figure 3 illustrates several connectivity examples for V2XLTE over the EPC network. As, shown, the architecture inTS 23.285 serves as a framework for vehicles, RSUs andUEs for the exchange of the information collected abouttheir surroundings among each other, or with a V2X AS.On the whole, after Rel-15, the 3GPP LTE C-V2X standardis able to offer adequate support for the development of ITSapplications providing messaging and other services throughLTE/EPC. As introduced in Fig. 2, to accomplish this, Rel-14specifies a single cellular technology with two V2X commu-nication modes over the:• PC5 interface, which connects UEs directly• LTEUu interface, which usually connects UEs to an LTEEvolved Node B (eNB).

A UE may transmit and receive using these communicationmodes independently. As stated in TS 23.285 [10], from3GPP’s viewpoint, the choice of LTE-Uu or PC5 for theservice is up to the application layer, and the 3GPPV2X layerdoes not perform the path selection.

TS 23.285 also defines the system architecture, and alsospecifies both an inter-Public LandMobile Network (PLMN)and a roaming architecture. There are protocols over the V4interface for authorization between theV2XControl Functionand the Home Subscriber Server (HSS); an also over theV6 interface between V2X Control Functions belonging todifferent PLMNs. The goal of this authorization procedureis ascertaining whether a UE is authorized as a Vehicle UEand/or a Pedestrian UE. For its proper operation, the V2X

190950 VOLUME 8, 2020

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

FIGURE 3. Overview of pre-Rel-16 V2X Architecture over EPC.

Control Function may require the service authorization infor-mation concerning a particular UE from theV2X subscriptiondata stored in the HSS. The HSS informs the specific PLMNswhether PC5 based communications are allowed for the UEin question. TS 29.388 [12] describes the procedures relatedto the V4 interface and the Information Elements (IEs) beingexchanged between the V2X Control Function and the HSS.When two PLMNs are involved, the V2X Control Functionin the home PLMNmay ask the V2X Control Function at thevisited PLMN about authorization information concerning aparticular UE. In turn, the V2X Control Function in the vis-ited PLMNmay inform about the UE permissions to performPC5 based or communications over Multimedia BroadcastMulticast Service (MBMS) via interfaceM1 between an eNBand the EPC (as detailed in Section II-B4) when in the visitedPLMN, and other V2X AS information, like its IP addressor Fully Qualified Domain Name (FQDN). Note that MBMSrequires the involvement of the Broadcast Multicast ServiceCentre (BM-SC) entity, for QoSmanagement, announcementof multicast/broadcast sessions, etc. and assumes the pres-ence of a MBMS-Gateway (GW).

TS 29.389 [13] describes the procedures related to theV6 interface and the exchanges between two V2X ControlFunctions. Both the V4 andV6 interface procedures are basedon the Diameter protocol for authentication, authorization,and accounting [14].

There exist configurable parameters in UE mediating theV2X communication configuration of the UE governing thediscovery of the V2X Control Function, and the communica-tions via LTE PC5, or via LTE Uu. These parameters comefrom either of the following three sources:• stored in advance in the ME;• previously configured in the Universal Subscriber Iden-tity Module (USIM) application running at the UICC,in accordance with the USIM Service Table added to thestandard [15];

• provided by the V2X Control Function to the MEvia V3.

In turn, the UE adopts the V2X configuration parametersfollowing a set of rules covered in TS 24.385 [16] thatestablish a specific, hierarchical order of precedence. Thisspecification also defines a set of Management Objects (MO)that might be stored at the USIM; however, the configurationvia USIM is optional, and the use of USIM itself is optionaltoo for V2X.

In general, the standard offers comprehensive detail onthe configuration parameters expected from all of the ele-ments participating in the V2X communication, includingthose exclusive of Uu and PC5 interfaces, service-relatedconfigurations, radio frequencies established for in-coverageand out-of-coverage modes, and parameters belonging to theradio interface.

VOLUME 8, 2020 190951

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

3) PC5 INTERFACE COMMUNICATIONSWith Rel-14, PC5 based, device-to-device communicationswere extended to support C-V2X PC5 realizes the deliveryof messages to several UEs in the vicinity of a transmittingUE via, what could be conceived as a ‘‘sidelink’’, from aPHY perspective, aside from the cellular network. In fact,the PC5 interface is key in supporting extra V2X servicessuch as V2P and makes feasible novel functional scenariosfor V2V services using the LTE sidelink. With Rel-15 V2X,only enhancements to PC5 are provided, all within the scopeof the EPS.

The PC5 solution evolves the reference point between UEsused for Proximity-based Services (ProSe) Direct Communi-cation (already available in Rel-12) with enhancements forits use for V2X. PC5 explicitly addresses UEs high speed(up to 250 Km/h) and high density of UEs, that is, thousandsof vehicles. PC5 mode works in the ITS band at 5.9 GHz,and, by its local nature, is appropriate for periodic notificationof information such as speed, location, etc. With this, V2Vand V2P sidelink transmissions avoid the need to cross thenetwork, thus yielding significant improvements on latency.

Rel-14 V2X communications are ‘‘connectionless’’ anddo not use signaling over the PC5 Control Plane (CP) forconnection establishment, operating only on broadcast in thePHY layer as the best approach for the delivery of BSM,CAM, and DENM traffic. In broadcast, the UE exchangesV2X messages to every neighboring vehicle within rangeover the PC5 User Plane (UP). This also compensates for thetransient nature of the connectivity in such communicationscenarios when attempting to exchange safety messages fastand reliably. Note that in Media Access Control layer (MAC)implementation, a broadcast address may be mapped to anindividual UE or a group of UEs; the implementation ofthese mappings is not covered by the standard, and thereforetransparent to the PHY.

There is support for IP-based messages, but only IP v6applies. Non-IP based V2X messages are also allowed to rundirectly on top of Layer-2 so as to avoid the implications onlatency of an IP overhead.

Figure 3 illustrates the two high level deployment configu-rations depending on the resource allocation mode used whenoperating on the sidelink:

• Mode 3, with centralized scheduling of the resources,which are managed at the eNBs by the network. This is‘‘network scheduled mode’’ that must be performed in-coverage with the UEs controlled or served by the RANnode.

• Mode 4, with autonomous scheduling of the resourcesupported by distributed algorithms based on con-stant channel monitoring by every UE to decrease thechance of packet collisions. This is ‘‘UE autonomousresource selection’’ and may be performed in-coverageor out-of-coverage, i.e. with the UEs beyond the range(and thus also of the management) of any RANnode.

These modes, introduced by Rel-14, are justified from keyneeds from the automotive industry identified also in TS22.185.

For in-coverage V2X communications via PC5, mode 3,and mode 4 are valid options. When using the network man-aged mode, the UE is scheduled and regulated by the cellularinfrastructure. The PC5 interface also has associated packetpriority profiles to select from, and a simple way to allow forcertain degree of prioritization among different PC5 transmis-sions. In this sense, the resource scheduling procedure at thebase stationmakes use of ProSe Per-Packet Priority (PPPP)—a particular scalar value from one to eight, configured by theapplication layer for each Protocol Data Unit (PDU)—so as toadjust latency and prioritization aspects of the transmission ofthe V2X message being scheduled through the sidelink. Forthe configuration of the network scheduled operation mode,apart from pre-storing the parameters, there is the option forthe network to configure the device when the UE is connectedvia Uu and assisted by a eNB in the setup of PC5 transmissionresources.

For out-of-coverage PC5 used for V2V and V2P servicecategories, only the autonomous resource selection modeis available, and the UE must be configured in advance touse the allocated frequency or RAT. It must be noted thatthe 3GPP standard also honors the fact that UEs must beconfigured to work in cooperation with PLMN operators.This is essential when the vehicle opts for PLMN managedconnectivity, because the use of direct communications viathe PC5 interface by the UE does not preclude the right ofthe operator to manage the radio resource usage fairly andenforce prioritization. This cooperation is absolutely neces-sary because once the resources are preconfigured for out-of-coverage, there is nothing the network can do.

As covered by TS 24.386, the V2X message over the PC5interface is composed of the data PDU, the IP or non-IP natureof the Layer-3 protocol, the source Layer-2 ID, the destinationLayer-2 ID (the broadcast address previously noted), the V2Xmessage family—only if non-IP, for example IEEE 1609WAVE Short Message Protocol (WSMP), ISO or ETSI-ITS.The UE sets the Layer-2 ID autonomously. The destinationLayer-2 ID is chosen according to the mapping of a Layer-2 ID with the specific V2X service identifier and the defaultdestination Layer-2 ID from the configuration.

4) LTE UU INTERFACE COMMUNICATIONSAs shown in Fig. 3, V2X communications over LTE Uu areonly supported when the UE is in-coverage. Apart from theusual Uu operation mode for connecting via EPC and LTE,Uu interface communications in Rel-14 may use standard-ized EPS connectivity to relay communications using 3GPPMBMS. With this, UEs may have the option to connect viaUu towards the V2X AS and other UEs. As usual, the uplinkis used for transmissions, and through the downlink, the UEmay receive either broadcast V2X messages, or unicast V2Xmessages coming from another UE and intended only for thatparticular UE.

190952 VOLUME 8, 2020

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

In the downlink, the network may utilize Single Cell PointToMulti-point (SC-PTM) or Multicast/Broadcast Single Fre-quency Network (MBSFN) as the transmission method forV2X messages. The delivery of V2X messages in the down-link may be carried out through Guaranteed Bit Rate (GBR)bearer (an IP path with guaranteed bitrate) and Non-GBRbearer (an IP path without bitrate guarantees). To this end,TS 23.203 [17] defines dedicated QoS Class Identifier (QCI)values for V2Xmessages: unicast delivery may use GBR andnon-GBR, while broadcast delivery can only resort to GBRbearers. Those definitions provide a vehicle with efficientways to communicate with a substantially bigger set of UEs intheir immediate vicinity—as well as the possibility of reach-ing more distant UEs well beyond the current geographicalimmediacy where the vehicle is located at.

The LTE Uu interface admits IP V2X messages. It allowsnon-IP messages too, but unlike PC5 the UE encapsulatesthem in IP packets prior to their transmission. For the config-uration of V2I and V2N service categories through Uu inter-face, either a previous configuration or network configurationare allowed, and specific QCIs are defined to carry out V2Xcommunication features over Uu. Apart from this, the con-nectivity via Uu interface of the UE to the V2X AS definedin TS 23.285 may be used by the V2X AS to configure a UEwith compulsory parameters. Note again that, the UE usesUser Datagram Protocol (UDP) and IP for non-IP based V2Xmessages—the only exception is if the use of TransmissionControl Protocol (TCP) is explicitly stated—and sends themto the specific V2X AS address.

For Uu communications there are also subscription mech-anisms on the V2XControl Function for V2X and support fortargeting a geographically relevant V2X AS serving clustersof nearby UEs on a given physical location. The V2X AS inturn delivers the V2Xmessages using either unicast or broad-cast using MBMS delivery. As covered by TS 24.386, theaddress of the V2X AS may be obtained during the V2X ASdiscovery procedure, either from V2X AS information pre-viously configured or using the MBMS procedure. All theneeded user subscription information to make V2X possibleis also included in the definition of the Uu interface also forauthorization and policy enforcement of its PC5 counterpartif it is in use.

Further improvements on latency may be achieved throughthe use of localized MBMS to further delimit the routing ofV2X messages to their destination UEs. Localized MBMSis achieved through deployment options because no pro-tocol enhancement is defined for the support of V2X; infact, TS 23.285 [10] reuses two already introduced inter-faces: xMB and MB2. The configuration information regard-ing local MBMS is previously stored at the V2X AS. Thispre-configuration includes the IP Multicast Address, theMBMS-GW IP Address, the BM-SC IP Address, etc. TS23.285 covers the localized MBMS deployment options; theV2X AS sends the local MBMS information to the BM-SCvia either MB2 interface or xMB interface. The BM-SC inturn, during the activation of the MBMS bearers, delivers it

to the MBMS-GW via the SGmb interface. The activationof the local MBMS bearer is triggered by the local MBMSinformation, and the V2X AS may use the MBMS bearer tosend the V2X message to the UE. For further information onlocalMBMS protocols between the V2X AS and the BM-SC,TS 29.116 [18] covers the xMB interface and TS 29.468[19] the MB2 interface. The protocols between BM-SC andMBMS-GW are covered in TS 29.061 [20].

5) KEY RAN FEATURES OF LTE-BASED V2XRel-14 introduces several essential technological functional-ities in RAN for the proper support of V2X services by LTE:

• Defining band 47 (5855–5925 MHz) for the operationof V2X via PC5 interface [21].

• Introduction for the sidelink of the following physi-cal channels: a Physical Sidelink Broadcast Channel(PSBCH), for high-level control information; a PhysicalSidelink Control Channel (PSCCH), for control dataregarding time and frequency resource allocation for thecontrol plane; and a Physical Sidelink Shared Channel(PSSCH), for user data—transmissions on these chan-nels use Single-Carrier Frequency-Division MultipleAccess (SC-FDMA). It also specifies a DemodulationReference Signal (DMRS) associated to each physicalchannel, for radio channel estimation purposes [22].

• Defining a SideLink Synchronization Signal (SLSS),which uses sidelink signals/channels for aligning theirtime and frequency references before transmission andreception, when operating out of coverage from theeNB or a Global Navigation Satellite System (GNSS).Since, typically, the GNSS or the eNB are deemed as thebest sources of synchronization, the SLSS allows UEsto achieve sidelink synchronization when they do nothave a better source of synchronization available. Thetransmission and reception of SLSS is optional, and theUEs transmitting SLSS is known as SyncRef UE.

• Support of cellular V2V services via LTE Uu interfaceuplink/downlink. Such communications will reach anAS, but note that ASs are out of the scope of 3GPPspecifications, introduce delays and intrinsically preventany centralized scheduling. Cellular V2V also takesadvantage of inter-cell communications. As stated inSection II-B4, the support of broadcast transmissions viaSC-PTM and MBSFN may be used for V2X messages.

• LTE Uu Uplink and PC5 sidelink Semi-PersistentScheduling (SPS) enhancements [23], which allow theeNB to adapt its SPS in accordance with changes in therate of creation of V2X messages. This is achieved withthe availability of several SPS parameter configurationsat the eNB that can be activated and released accordingto the assistance information provided by the UE to theeNB informing the desired message periodicity, maxi-mum size, timing, etc.

• Sidelink transmission mode 3 (centralized schedulingassisted by the network eNB). Mode 3 is envisioned

VOLUME 8, 2020 190953

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

for the transmission of messages that are periodical,with explicit support for sidelink SPS, although dynamicsidelink grants are also supported.

• Sidelink transmission mode 4 (distributed schedulingat each UE), allows autonomous resource selection,based on sensing within a preconfigured resource pool,which resources are not being used. After selecting theresources, the UE may use SPS to perform a specificnumber of periodic transmissions, or an arbitrary num-ber until one of multiple reasons for resource reselectionhappens (for the prevention of prolonged resource hog-ging, of an inadequate resource share of the resourcesfor type of traffic, etc.)

• Support in mode 4, for resource re-use targeting a spe-cific geographical area, by means of dividing the areainto zones with preconfigurable width and height, forthe management of interference and improving spectralefficiency. For mode 4, the UEmust make transmissionsusing the resource pools associated with the zone it islocated at. Adjacent zones use different resource pools,and the resources are reused in a spatially periodical way.

• Defining in mode 4, a supplementary, power-saving,resource allocation procedure targeting pedestrian UEs,which may use random resource selection to transmittheir V2Xs messages. Partial sensing in a subset of sub-frames, which consumes more power, is also supported.

• Quicker message transmission intervals in downlinkand sidelink, to broadcast V2X messages with stringentlatency needs. Both downlink and sidelink communi-cations may configure control and data transmissionperiods as short as 20 ms.

• Sidelink congestion control to handle high traffic loadconditions, based on the measurement of the ChannelBusy Ratio (CBR) and Channel Usage Ratio (CR) by theUE [24] in time intervals of 4 ms. The CBR indicatesthe fraction of time/frequency resources that are beingperceived as occupied by other UEs’ strong signal trans-missions. CR is total number of subchannels a UE trans-mits during a window of up to 1000 ms including thecurrent subframe, this summarizes how much resourcesa UE is presently, and will soon, claim. Significant CBRvalues will typically trigger reactions from the conges-tion control algorithm so as to modify transmit power orresource size from the UEs involved either in a central-ized or distributed manner. For example, in a distributedway, the UE may be preconfigured with several CBRranges associated to CR limits. When a UE perceivesthat the CR is above the CBR range being measured,its CR must be decreased. The specific mechanismsare implementation-specific, and can include reducingresource occupation, skipping transmissions, etc.

• Support for cross-PLMN C-V2X sidelink communica-tions [25]. This brings support for simultaneous V2Xoperations over multiple carriers. This is useful forexpanding the available bandwidth or for allowing inter-PLMN operation among multiple operators offering

V2X services on different carriers. With this a UE hasthe option to communicate over LTE Uu and PC5 indifferent carriers; alternatively, it may use two differentcarriers at the same time PC5 interface communications.

• Support for V2X transmission and reception during han-dover and cell reselection [26].

• Uses Turbo codes and supports HARQ retransmissionsto enhance communication reliability on PC5 interface.

Rel-15 introduces additional, and Rel-14 compatible, keyenhancements in RAN for the appropriate support of eV2Xservices by LTE:

• Support for 64-Quadrature Amplitude Modulation(QAM) is the most important technological addition,together with new transport block sizes, as per [27].

• Mode 3 supports Carrier Aggregation (CA), allowingmultiple MAC PDUs to be transmitted in parallel ondifferent carriers (TS 36.321), offering a throughputincrease comparable to Uu CA. Another aspect of CA,Packet Data Convergence Protocol (PDCP) duplication,helps in enhancing reliability because it makes possiblethe transmission of the same PDCP packet simultane-ously over multiple sidelink carriers [28].

• Sidelink transmission mode 4 now supports CA, withsynchronization mechanisms for the multiple carrierforming part of the Component Carrier (CC) [27]. It alsocontributes with new rules for power sharing, and theimplementation of priorities for the synchronization ofresources. To improve reliability, sidelink packet dupli-cation is explicitly introduced for CA.

• SinceV2XCC addition and release, and source selectionand reselection of the V2X synchronization referenceimply interruptions, the standard covers constraints onthe maximum delay produced by those actions.

• Even faster message transmission intervals, which arereduced from 20 ms to 10 ms.

• Mode 3 and mode 4 UEs have the option to share theradio resource pool. Sidelink Control Information (SCI)messages are tweaked for optimized behavior underresource pool sharing. Mode 3 UEs have the capabilityto sense and report.

• Transmit diversity is incorporated [27], the techniqueused is small-delay Cyclic Delay Diversity (CDD).

C. REL-16 ENHANCEMENTS FOR V2XRel-16 lays out the fundamentals of a 5G V2X architec-ture, defining the V2X support in 5GS, with the possi-bility to interwork and coexistence with EPS based V2X,which includes LTE V2X. Rel-16 5GS based V2X has alsodifferent (and stricter) design goals and architectural fac-tors than those of Rel-14 and Rel-15 C-V2X. Additionally,Rel-16 also defines NR V2X as the new RAT for PC5based V2X. It also reuses generic existing technologies, likeUltra-Reliable Low-Latency Communications (URLLC) andMobile Edge Computing (MEC), that are not specific forV2X. Particularly, MEC brings the opportunity to build at

190954 VOLUME 8, 2020

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

the edge of the mobile network, closer to UEs, a cloudenvironment with computing and storage resources for V2Xapplications, for extra latency reduction.

July 2020 marked the functional freeze of Rel-16. It isnot clear, how much impact will have Rel-16 in current5G rollouts, which are based on Rel-15. One reason forthis uncertainty is that as a preliminary 5G standard, Rel-15significantly depends on the LTE network as the backboneto offer 5G services in non-standalone mode. However, theremarkable recent trend of Rel-15 standalone deployments incertain strategic regions like China may contribute to clearmany doubts.

1) VEHICLE QOS SUPPORTRel-16 defines in TS 22.186 [3] a new set of service require-ments placed on the 5GS in its entirety: Vehicle QoS Support.This empowers the 5GS ability to provide QoS monitoringand handling features for a better management of the trafficfrom V2X services over the Uu interface. By compiling QoSdata, and generating either historical statistics or future esti-mations of impendingQoS fluctuations, Vehicle QoS Supportexchanges with the V2X AS the byproduct of such QoSanalysis, and it notifies the V2X applications with enoughanticipation about the alterations to be expected in the QoSlevels.With this, the V2X applicationmay adjust its operatingparameters to the QoS to be expected of the network.

The specification enhances an already existing interface,that in turn may be used for V2X Vehicle QoS Support—although this interface is not exclusive to V2X. This is away for the V2X AS to express the target QoS demands thatmust be met, as well as alternative QoS demands, for V2Xapplications that may operate with different configurationvalues (bit rate, latency, etc.) The interface then allows theV2X AS to ask for notifications informing about whethertheir particular QoS demands may be satisfied or not. Thedetails on the estimation mechanism running at the entityin charge of the estimations or the accuracy level of suchestimations is left out of the standard.

2) 5GS ARCHITECTURE FOR V2X COMMUNICATIONSFigure 4 offers an overview of the 5GS architectural enhance-ments for the support of 5G NR V2X as defined in Rel-16 TS23.287 [8], including all the Network Functions (NFs) of the5GC involved.

The 3GPP specifies the 5GS architectures for V2X over thefollowing interfaces:

• LTE PC5, backwards compatible with Rel-15 PC5 ref-erence point

• E-UTRA Uu, backwards compatible with Rel-15 Uureference point

• NR PC5, which connects UEs with support for NR V2Xcommunications;

• NR Uu, which connects UEs with a Next-Generation(NG)-RAN node.

FIGURE 4. 5GS Architecture for V2X.

The 5GS specifies also the architecture for the provisioningof service parameters by the Application Function (AF) forV2X communications. Typically, the role of the AF is playedby the V2X AS.

In general, the 5G V2X architecture agrees with the fun-damentals already established for LTE V2X in Rel-14 andRel-15. One of the motivations is backward interoperabilitywith LTE C-V2X. In this sense, TS 23.287 also defines anarchitecture reference model for internetworking betweenEPS V2X and 5GS V2X. The 5G architecture also allowscross RAT scheduling (for example, LTE-PC5 and NR-PC5).

Figure 5 shows several connectivity examples, and howNRbased V2X scenarios may be mapped onto the architecturedefined in TS 23.287 (reference points, NFs, etc.). As shown,the architecture makes use of 5GC (for illustrative purposes,only some ofNFs involved inV2X are included in green). Theuplink, downlink and sidelink of communication scenariosoperating via 5G NR V2X interfaces are marked with redarrows. There is no LTE V2X Control Function in 5G, butthis entity may be present when interworking with 5G nodesoffering LTE connectivity (ng-eNB) is required, or cross RATscheduling is supported. Figure 5 also shows a typical usecase (truck platooning) for the standardized way of handlinggroupcast mode. Note that groupcast address managementis always provided by the upper layer and never handled atMAC layer.

One of the tasks of the 5GC is sending the authorizationstatus of a UE to the NG-RAN node. With no LTE V2XControl Function, its authorization and provisioning func-tionalities are distributed among the 5GC entities (shownin Fig. 4) that play a role in V2X [3], [29], [30]. Specifi-cally, the Policy Control Function (PCF) provides V2X pol-icy/parameters configuration (Police Provisioning) such asQoS, radio parameters, and NR Uu and NR PC5 configu-ration parameters supported by the PLMN over CP planeNon-Access Stratum (NAS) signaling. Note that, when the

VOLUME 8, 2020 190955

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

FIGURE 5. Rel-16 5G NR V2X architecture.

UE concludes that the policy or parameters supplied by thePCF for V2X communications are not valid (for examplemissing, obsolete or illogical), the UE may initiate a UEinitiated Policy Provisioning procedure to contact the PCFand fix them.

The standard offers support for the following ways of sup-plying or updating the V2X configuration parameters medi-ating the V2X communication over PC5 and Uu interfaces tothe UE:

• previously stored in the ME• configured in the UICC• previously stored in the ME and configured in the UICCat the same time;

• provided by the V2X AS via PCF or via V1;• provided by the PCF to the UE.

TS 24.587 [31] and TS 24.588 [32] specify the particularimplementation of the protocols for V2X services in 5GS, andUE policies, respectively, and the description of the operativeof the functional elements that are mapped to physical ele-ments in Rel-16.

3) NR PC5 INTERFACE COMMUNICATIONSRel-16 specifies communications over the two types of PC5interfaces (NR PC5 and LTE PC5), supporting roaming and

inter-PLMN operation. The PC5 reference point may be usedwhen in-coverage by NR or E-UTRA or out-of-coverage.

The specification brings forth improvements regarding NRPC5 interface communications with respect to LTE PC5,as well as additional configuration options for UEs.

In addition to broadcast, NR V2X introduces groupcastand unicast, building a more complete V2X system. ThePHY support for unicast communications via the NR PC5interface, may be initiated via PC5 signaling (proceduresfor Layer-2 link establishment, Layer-2 link modification,Layer-2 link maintenance, Layer-2 link release, and Linkidentifier update are defined). Those procedures are alsouseful to negotiate additional aspects of the V2X application.The mechanism for the discovery of unicast users for sidelinkcommunication can use broadcast-and-response to discoverother neighboring UEs and set up direct Peer-to-Peer (P2P)unicast communications.

NR PC5 also supports groupcast communications, where aUE may transfer messages to one or more surrounding UEs.In Rel-16 the management of the groupcast groups is a taskof the application layer. Both broadcast and groupcast modestake advantage of configuration parameters like ApplicationID, or source and destination Layer 2 ID. The standard intro-duces Connectionless Groupcast, providing Minimum Com-munication Range (MCR) as a sidelink parameter, so that

190956 VOLUME 8, 2020

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

only vehicles within the MCR of the transmitting vehiclewill respond, as a way to achieve low latency and highreliability.

V2X applications may use Per-Flow PC5 QoS Model,a PC5 QoS profile tailored to their requirements for differentQoS flows, although they can resort to preconfigured infor-mation when absent; besides, PC5 QoS support is enhancedand aligned to Uu QoS by means of specific values of the 5GQoS Identifier (5QI) parameter defined for V2X services.

Note that Rel-16 does not preclude the use of legacy LTEPC5 by a UE. In fact, a UE may select NR PC5 and/or LTEPC5 for V2X communications depending on several factors.For example, resorting to LTE PC5 may be motivated by ser-vice availability, or by subscription or authorization reasons.It may also be a mechanism to address the communicationcapabilities of the V2X application, like interoperating witholder vehicles. In this sense, the Rel-16 upgrade of TS 23.285[29] specifies the architecture additions to EPS so as to allowV2X communications over the NR PC5 interface.

Moreover, a UEwith support for NRV2Xmay use unicast,groupcast, and broadcast simultaneously. An example is truckplatooning: the UE located at the lead vehicle could makeuse of groupcast transmissions for communications with themembers of the line of closely following vehicles, use uni-cast transmissions to contact the truck immediately behind,and use broadcast transmissions to contact other surroundingvehicles not belonging to the convoy of trucks.

The design criteria behind the V2X architecture for NRPC5 proposed by the 3GPP was developed to be in agreementwith the features offered by the novel 5GC. The UE V2Xconfiguration parameters for NR PC5 communications comefrom a sessionless-oriented policy management mechanism,and, as said, they use policy provisioning via PCF. The pro-cedure parts from a list of V2X capabilities supplied to the5GC by the UE, which, in turn, elicits the PCF to activate theconfiguration of V2X policies on the UE. Such policies coverparameters that deal with radio-related aspects, for exam-ple, the appropriate frequencies, authorized RAT (NR and/orLTE), application-related information, QoS parameters forNR PC5, and so on.

4) NR UU INTERFACE COMMUNICATIONSV2X communications over the Uu interface support unicastonly. The Broadcast/Multicast (BC/MC) functionality for NRwas left out of Rel-16. Since having this enhancement wouldbe essential for future proofing the development of new andemerging V2X services, the 3GPP plans the introduction ofthis functionality in Rel-17, with V2X applications as oneof its planned use cases. Meanwhile, the consequence is thatthe support for Uu-based broadcast services usingmechanismlikeMBMS is not present in Rel-16 5GNRV2X architecture,and broadcast services based on Uu are not possible.

The system architecture for the 5G in TS 23.501 [33]considers the assistance of advanced features of 5GS, likeMEC to reduce the latency of V2Xmessage transmissions viaunicast. Further improvement in UP performance is expected

when resorting also to the mechanisms provided by the 5GCto discern the traffic that needs to be routed to applications inthe local data network. This allows greater levels of serviceexposure, such as the ability of the AF to influence UPrelocation, selection and reselection, directly via the PCF orindirectly via the Network Exposure Function (NEF); it alsoallows for breakout near the UE location, Local Area DataNetwork (LADN) and Local Routing for optimal location,and Traffic Steering (supported by Uplink Classifiers work-ing on a group of traffic filters matching the traffic, or alter-natively by IP Version 6 (v6) multi-homing, with multiple IPv6 prefixes associated to the specific PDU session).

There are extra configuration details in the 5GS explic-itly supporting V2X communications over the NR Uu inter-face. IP and Unstructured PDU Session Type are allowed.In Rel-16 the transport protocol is not limited to UDP onlyand the application has the responsibility of determining themost suitable transport protocol for the particular V2X appli-cation. The Data Network Name (DNN), Session and ServiceContinuity (SSC) Mode, and Single Network Slice SelectionAssistance Information (S-NSSAI) may be configured too,and 5QIs with similar features to those of EPS are present in5GS. Additionally, to assist with the mobility of UEs acrossseveral different operators, and to facilitate roaming support,there is a way to simplify the deployment of a dedicatednetwork slice for the automotive industry use case: a newstandardized Slice Service Type (SST) value of 4 is definedby TS 23.501 for the deployment of a specific slice for V2Xservices covering those PLMNs.

V2X communications via Uu interface include enhance-ments for better V2X experience that are directly linkedto the operation of Vehicle QoS Support as outlined inSection II-C1. The V2X AS may request to be notified ofQoS Sustainability Analytics to be able to modify, before-hand, the behavior of the V2X application according to theprospective variation in the QoS level. This empowers theV2X AS to trigger geographically precise QoS monitoringfor a specific period of time. In turn, the Network DataAnalytics Function (NWDAF) merges such historical dataand offers QoS statistical prediction analytics to the V2X AS.The analysis is then used by theV2X application toweight themost probable adjustment required for a smooth adaptation tothe potential fluctuation on the network conditions.

Another enhancement improving the V2X experience isthe support for V2X applications that have different setsof configuration parameters depending on the QoS profile(Alternative Service Requirements). The V2X AS, function-ing as AF may supply the Alternative Service Requirementsto the 5GS (apart from the target service requirements). Thestandard also includes the option to provide the gNB withAlternative QoS Profiles (AQPs) for NG-RAN. AQPs areprovided by the V2X AS via the PCF. The Session Manage-ment Function (SMF) is aware by signaling of whether theNG-RAN node supports AQP or not. In the positive case,the SMF supplies the AQPs to the NG-RAN, as stated in TS23.501 and TS 23.503 [34]. As a result, the RAN is more

VOLUME 8, 2020 190957

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

FIGURE 6. V2X application layer functional model.

versatile in adapting to the V2X service radio conditions, andhas extra QoS profile candidates for carrying out the service.

5) APPLICATION LAYER SUPPORT FOR V2XAPPIn the immediate future, mobile operators, the automotiveindustry, service providers, car owners, and government bod-ies with responsibility for road safety will be involved ina plethora of V2X applications for the connected vehicle.The need for the harmonious operation between diverse V2Xapplication layer protocols marks the specification in Rel-16of Application layer support for V2X services (V2XAPP), forsupporting the joint operation of V2X services. Introducedin TS 23.286 [35], V2XAPP is envisioned as a systematicway to achieve interoperability between V2X services onthe application layer over 3GPP systems. The framework forV2XAPP is based on the concept of the V2X ApplicationEnabler (VAE) functional model. The standard specifies thenecessary support for V2XAPP to be able to: i) distributeV2X messages; ii) ensure service continuity; iii) manageresources at the application level; iv) realize dynamic groupmanagement; v) provide VAE server Application ProgramInterfaces (APIs) over the EPS.

Figure 6 depicts the V2X application layer functionalmodel and the interrelation between the VAE, and the func-tional components in the V2X application and the V2X AS.As shown in Fig. 6, and specified in TS 23.286, the VAE hasclient and server components offering support for client-sideand server-side functionalities. The VAE client supports mes-saging, abstraction of network monitoring events, a way forswitching the communication mode of the network, enhancedlocation, dynamic group management, etc. The VAE server

supports abstraction of the inbuilt network mechanisms forthe management of networks resources, location tracking,distribution of messages, network monitoring, group, config-uration and identity management, etc.

The advantages of defining a common VAE layer are:

• Other actors have a simpler mechanism to accessadvanced capabilities for their network connections,like QoS, MBMS, notifications, knowledge about thenetwork status, and network events—which normallyrequire the level of technical expertise of a Mobile Net-work Operatorss (MNOs).

• By providing all the common typical functionalities,which are essential for V2X applications (provisioningof the configuration parameters of the communication,management of network resources, QoS monitoring,etc.), it contributes to reduce the cost of creating V2Xsolutions.

• Replaces proprietary interfaces between different partswith an unified enabler layer, reducing the overallcost and contributing to a more scalable internetwork-ing, interoperation and information exchange betweenV2X AS.

The VAE layer is built on top of the functionalities offeredby the Service Enabler Architecture Layer (SEAL), which isalso introduced in Rel-16 TS 23.434 [36], and supports manyother vertical applications apart from V2X.

6) KEY RAN FEATURES OF NR-BASED V2XRel-16 introduces several key technological functionalities inRAN for the proper support of NR V2X:

190958 VOLUME 8, 2020

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

• Introduction for the sidelink of a PSBCH, a PSCCH,and a PSSCH, with associated DMRS [37]. Also ofa Physical Sidelink Feedback Channel (PSFCH), aPhase-tracking reference signal (PT-RS) and a Chan-nel state information reference signal (CSI-RS). TheCyclic Prefix Orthogonal Frequency-Division Multi-plexing (CP-OFDM) waveform is used, and the densestmodulation is 256-QAM.

• Defining a SLSS for SyncRef UE, similar to LTE-basedV2X [38].

• Support for Hybrid Automatic Repeat Request (HARQ)based on transmission of positive and negativeacknowledgments for sidelink unicast and groupcastservices, and blind re-transmission schemes. Addition-ally, it introduces a negative acknowledgment HARQscheme for groupcast services, which reduces theresource demand in scenarios where only the clos-est UEs are relevant when receiving the same infor-mation (for example, from extended sensors) andretransmissions must happen only for the handfulof nearby UEs that do not decode the transmissionsuccessfully.

• Definition of sidelink Bandwidth Parts (BWPs). The UEis configured with one active sidelink BWP when inconnected mode to a gNB, and the same used for idlemode or out-of-coverage operation.

• Mode 1 for resource allocation by the gNB. This isintended for periodic and aperiodic messages. The gNBprovides dynamic grants of sidelink resources, as well assidelink configured semi-statically. InMode 1 operation,the authorization status sent by the 5GC to the NG-RANallows the UE to initiate V2X sidelink communication,and influences in the way resources are provided to UEsfor each service considered.

• Mode 2 for autonomous resource selection by UE. Sim-ilar to LTE V2X the UE senses the resources not inuse by other, higher-priority UEs from a configuredresource pool. Then, the UE selects an adequate amountof resources for its own transmissions. Either a numberof transmissions and retransmissions is granted or trans-missions are allowed until a resource reselection condi-tion is triggered. The resources selected by the UE maybe used for diverse reasons: blind transmissions, HARQ-feedback-based transmissions, initial transmission of atransport block, etc.

• Sidelink congestion control similar to LTE V2X, to beused with mode 2 in NR V2X. A difference is that inPHY each packet has an associated single priority valuepropagated from upper layers, like PPPP in LTE V2X.Measures of CBR and CR are broadly equivalent, butfor reasons of procuring a faster adaptation to dynamicchanges in the congestion because of aperiodic traffic,NRV2X reduces their computation to up to 1ms or 2ms,in comparison with LTE V2X 4 ms.

• Support for performing NR sidelink transmission andreception during handover and cell reselection.

• Enabling the option that the UE may assist the networkfor the configuration of scheduling grants by sending areporting message with information on traffic patterns,including the periodicity, time offset, message size, QoSinfo and destination.

• Definition of prioritization and multiplexing rules toavoid overlapping between NR uplink and sidelinktransmissions. The rules are similar to those from the Uuinterface and are based on the priority of each specifictransmission [39].

• Per flow based QoS model for sidelink unicast,groupcast, and broadcast either in-coverage or out-of-coverage.

• Support for advanced V2X applications that must oper-ate via a cellular network’s NR Uu interface. Thisassumes that the V2X AS processing information fromthe UEs at the vehicles, and sending commands back tothem is located at the Internet (for example remote driv-ing). The Uu interface can activate multiple periodicalresource grants configured by Radio Resource Control(RRC) to manage simultaneously traffic sources withdifferent QoS requirements, and other enhancements forthe purpose of reducing uplink latency.

• Introduction of concurrent operation of LTE V2X andNRV2X within the same device. When the frequencyspacing between the two RAT is not enough, a singleRadiofrequency (RF) chain is advisable to avoid inter-ference, as well as resorting to half-duplex sidelink,where the two RATs cannot transmit or receive at thesame time.

• Introduction of cross-RAT operation of LTE V2X andNR V2X, making sidelink communications possiblebetween a cross-RAT UE in an LTE or NR cellularnetwork, and UEs lacking one of the sidelink RATs.For dual-RAT UEs this is achieved by mechanismsthat allow one RAT to play a role in controlling theresource allocation for the other RAT, and vice versa.One example is that LTE Uu may control the allocationof NR resources for mode 1 via LTE RRC signaling, andprovide configurations for NR V2X mode 2 to freelyselect from. Similarly, NR Uu may control the dynamicallocation of resources of LTE sidelink mode 3 via NRDownlink Control Information (DCI), which is handledinternally by the UE before resuming the usual operationof LTE; similarly, it may provide configurations for LTEV2X mode 4 to freely select from them.

• Definition of three 5G standalone scenarios for the jointoperation of LTE V2X and NR V2X, with either a gNB,a Next Generation eNB (ng-eNB) or an eNB control-ling and configuring the UE for V2X communicationsthrough any sidelink RAT.

• Definition of three Multi-RAT Dual Connectivity(MR-DC) scenarios for the joint operation of LTE V2Xand NR V2X, with the Uu interface controlling andconfiguring the UE for the LTE sidelink, and eitherNR-E-UTRA Dual Connectivity (NE-DC), NG-RAN

VOLUME 8, 2020 190959

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

E-UTRA-NR Dual Connectivity (NGEN-DC), or E-UTRAN NR Dual Connectivity (EN-DC) configuringthe NR sidelink.

The performance boost derived from the use of the pre-vious technological enhancements has begun to be evalu-ated recently at the PHY level in studies like, for example,[40], [41], which corroborate that NR V2X may satisfy thestringent requirements of V2X use cases. For example, thetheoretical analysis in [41] shows that NR V2X may achieveminimum transmission latency in the range 0.25–1 ms, whileLTE V2X is unable to achieve a latency below 1 ms. Theaverage data rates of 13–30 Mb/s (there are better for largepacket sizes, and short distances) for NR V2X are remark-able [41], and their simulations for an urban non line-of-sightscenario confirm that it may be up to 60% higher than LTEV2X; however, it must be noted that the range and reliabilityof LTE V2X and NR V2X seem to be similar.

D. POTENTIAL USE OF REL-16: REALIZING HYBRIDNETWORKINGThe virtually completed Rel-16 standard is in position ofmaking hybrid V2X networks a tangible reality, thus becom-ing the tool of choice for certain research initiatives whensolving the issues of complex real-world V2X scenarios.An example of such initiatives is the 5G-CARMEN project[42], focused on addressing some of the key challengesin the automotive field, such as automated driving, roadsafety, green mobility, and entertainment for future self-driving vehicles. 5G-CARMEN deals with trials of coopera-tive, connected and automated cross-border mobility acrossa 5G-enabled corridor from Bologna to Munich, span-ning 600 km of roads across three countries. 5G-CARMENapproach starts from the premise that 5G, with its very highdata-rates, extremely low-latency, and ubiquitous and reliablecoverage may be part of a multi-RAT solution addressingsome of the major challenges of this type of deployments.

The key enhancements of 5G-CARMEN revolve aroundthe concept of combining direct short range V2V andV2I communications with long-range V2N communications,using a platform employing different enabling technolo-gies such as 5G NR, C-V2X, and secure, multi- domain,multi-tenant, and cross-border service orchestration system.An interesting use case with issues is the application of Coop-erative Maneuvering to Back-Situation Awareness. Coopera-tive Maneuvering is the coordination of vehicles navigatingthrough intersections, changing lanes, overtaking, enteringand exiting highways, etc. in a safe and efficient way. Thecombination with Back-Situation Awareness, is essential forsharing the information concerning a detected, approach-ing emergency vehicle among C-V2X nodes, and allowingdrivers to create a safety corridor earlier and limit theirobstruction to approaching emergency vehicle, saving criticaltime for the emergency response team.

Fig. 7 shows a typical cross-border scenario with issues.Here, Cooperative Maneuvering procedures are expected to

FIGURE 7. Joint Cooperative Maneuvering and Back-Situation Awarenessinvolving multiple RATs.

begin among road vehicles 2, 000 m ahead (some of themdriving on the opposite side of the transnational border)within 1 minute of the reception of a Back-situation aware-ness message concerning the arrival of an emergency vehicle.Assuming that multiple technology interfaces may be poten-tially involved (such as E-UTRA Uu, LTE PC5, and even5G V2X), the Cooperative Maneuvering action requires thatseveral vehicles attached to diverse networks would be ableto determine, in advance, in a fast way, and at a certain pointin time, whether they are in risk of reselecting or switch-ing to another network technology. Besides, unforeseen cir-cumstances, like transient radio coverage fluctuations, etc.reasonably exacerbate the complexity of the problem ofpredicting in a timeline the likely future onset of such networkevents.

A solution envisioned to solve this challenging scenario isusing an approach where vehicles, for example, can use NRPC5 in addition to Uu interface communications to achievecertain degree of robustness by means of redundancy duringCooperative Maneuvering negotiation (simultaneous trans-missions via PC5 and Uu interface). Rel-16 interwork withthe EPS based V2X may open the possibility also to extendthis redundant approach to LTE V2X too, which increasesthe inherent importance of being able to ascertain trustwor-thiness of the redundant interface from QoS data, messagearrival times, or timestamps, etc. This adds a resilient dimen-sion because, even when Vehicle QoS Support is present,it seems reasonably less complex to approach the problemfrom the redundancy point of view instead of predictingthe current and future connectivity state of a neighboringvehicle, and whether the vehicle attached to the same networkis about to lose its connection or reselect to another net-work. This approach requires range-extension interworkingthat will make use of MR-DC for redundant communicationsassuring critical QoS parameters and Key Performance Indi-cators (KPIs).Managing this seems also natural because thereare potential mechanisms (for example marking the packetsas redundant via enhancements in the protocol stack) thatallow to discard a redundant packet that no longer serves itspurpose.

190960 VOLUME 8, 2020

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

Also important, when solving this type of problems withhybrid network technologies, is aligning the solution to cur-rent 3GPP specifications, and formulating them as an exten-sion to existing management and control layer procedures incurrent standards. In fact, when managing such hybrid V2Xnetworks, trustworthiness on the available network interfacesimpacts on the communication problem, for this would meancooperating with vehicles that can disappear from the localdynamic map of vehicles on the move at any given moment,and how to manage the vehicles that disappear. We anticipatethe existence of ‘‘robust’’ road areas that will ensure auto-mated driving, for example, where the MEC will be servingthe vehicles through theUu interface uninterruptedly, assistedby a dependable PC5 interface, assuring an up-to-date map ofneighboring vehicles; but also ‘‘degraded’’ areas will exist,where the quality of the redundant communication channelswill drop and may trigger lowering a degree of maneuveringassistance, losing any assistance at all, resorting to on-boardsensors, or to manual driving. Since the standard allowsannouncing, from a certain point on, that you use mode 3 ormode 4, so the network may inform the vehicles that from acertain point on they are going to be either managed by thenetwork or lose coverage and autonomously manage betweenthemselves. There is also the option to study how to fine-tune the borders between these areas to optimizemanagementand we conceive this research as a matter of resorting to: i) agood road map; ii) an updated map of surrounding vehicles;iii) collective, rich information and knowledge of all partnersinvolved in the cooperative maneuver; iv) clear definitions ofthe criteria for activating one mode or the other, just in casethe vehicles do not have continuity in service; and v) the reuseof alternative paths to the MEC to MEC communications,in case this would be necessary.

III. FUTURE V2X COMMUNICATIONSA. REL-17 ENHANCEMENTS FOR V2XThe Work Items (WIs) approved by 3GPP in Rel-17 are ori-ented to introduce improvements to the specifications alreadystandardized in Rel-16. With respect to V2X communica-tions, improvements are incorporated to the sidelink,

Rel-17 will consider new technological improvementsin sidelink communications for the application of V2X topublic-safety, and the support of related their related newrequirements and use case scenarios. Additionally, the use ofsidelink communications in commercial applications is con-templated. In this sense, it is considered the need to study thefunctionality of sidelink-based relaying, in order to improvecoverage and power efficiency of the devices. Such improve-ments will allow the use of sidelink communications in envi-ronments without coverage through the multi-hop approach.Thus, the use of sidelink-based relaying technologies, alreadystandardized in Rel-16, will be analyzed to be used in theNR architectures. Other key requirements to be optimized arerelated to improve network reliability and latency reductionin new URLLC scenarios.

The positioning enhancements to be incorporated in Rel-17consist basically of optimizing the latency and accuracy ofpositioning data with respect to the indicators defined inRel-16. Thus, in Rel-16, accuracy requirements of less than3 meters for indoor environments and less than 10 meters foroutdoor environments were specified. Therefore, in Rel-17,position resolution accuracy of less than 0.2 meters isexpected to be achieved in Internet of Things (IoT) appli-cations, with a desired latency of 10 ms. Such requirementsare essential for the new use cases defined for V2X services,including autonomous vehicle applications, where high net-work reliability and low communications latency is desired.

Regarding NRBroadcast andMulticast, Rel-15 and Rel-16do not contemplate the incorporation of NR-based MBMSservices. Thus, one of the objectives of Rel-17 will be toincorporate Multicast Broadcast Services (MBSs) using 5GSarchitectures so as to develop new V2X services and applica-tions using these improvements.

Additionally, other technologies that will be improvedin future Rel-17 specifications and that can be appliedin V2X communications are NR Multiple-Input Multiple-Output (MIMO), URLLC enhancements, power saving, NRcoverage enhancements, NR XR, (for example, Virtual Real-ity and Augmented Reality), and multi-radio dual connectiv-ity/cell aggregation enhancements [43].

B. BEYOND 5G V2XCurrent long-term research topics aim at anticipating thecomplex requirements emerging in in beyond 5G V2X sce-narios. The state of the art indicates that new technologies willbe improved and perfected in future Sixth Generation (6G)network standards [44]–[47], and likely applied to ITS. Suchtechnologies are related to intelligent systems based on DeepLearning (DL),Machine Learning (ML) andArtificial Intelli-gence (AI), for example extreme URLLC enabled by ML/AI.Other technologies are focused on the use of high frequencybands, for example, terahertz communications, can be used tosupport mobile ultra-broadband. Additionally, very importantaspects that the next networks will include are related to newsecurity, privacy and trust paradigms of communications.

With regard to vehicular communications, three ML per-spectives for vehicular networks are defined in [48], whichshould be improved in the future 6G networks: ML forvehicular communication, ML for vehicular networking, MLfor vehicular security. Therefore, it is indicated the need tostudy mechanisms of multi-radio access, intelligent radioconfiguration, adaptive tracking and beamforming, intelli-gent network resource allocation, and intelligent networktraffic control, among others.

IV. CONCLUSIONC-V2X standards are gaining traction across numerousregions and industry sectors. Thus, it has been from standardscompletion to independent field testing to initial deploymentsin North America, Europe, China, Korea, Japan and Aus-tralia. The world’s leading manufacturer of C-V2X chipsets

VOLUME 8, 2020 190961

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

is Qualcomm, which introduced the first chipset in 2017,and has been used to perform V2X standards evaluationsaccording to the latest Releases [49]. On the other hand, in astep towards making hybrid networks possible, Autotalks,a company with great presence in the market of devices forV2X communications (both for on-board units, and RSUs)presented the first Dual mode V2X chipset, which integratesboth DSRC and C-V2X technology. Thus, through a simpleconfiguration switching between these two technologies [50]is possible.

The forecasts for the use of V2X standards in the worldare promising, with market research reports predicting thatV2X will represent a 1.2 billion market [51] by 2022—theyear anticipated by Ericsson Mobility Report 2019 [52] forLTE to reach its highest point globally. After that, LTE willdecline by the end of 2025, when 5G is expected to cover upto 65% of the global population and handle 45% of globalmobile data traffic [52], and by 2028 the global automotiveV2X market is predicted to grow to 12 billion [53].

This article has provided a comprehensive review of theevolution of the architectural approach to LTE V2X fromRel-14 and Rel-15 up to the fundamentals of the currentstate of the 5G V2X technology as of Rel-16, as well aselaborating on the distinguishing features added to V2X overthe successive 3GPP iterations of the standard. As explained,the advancements derive from the race towards the supportof increasingly complex V2X service categories, with morestringent requirements of latency, reliability and throughput.This objective has motivated the design of two coexistingcommunication modes via a sidelink PC5 interface and a cel-lular Uu interface for downlink and uplink, and also the defi-nition of cross-RAT operation of LTEV2X and NRV2X. Thepaper also highlights how the completion of Rel-16 makeshybrid V2X networks a readily available tool for solvingcomplex V2X scenarios of the real world. One example, is thereliable coordination of the trajectories of vehicles on theroad, sharing sensor information, and mutually agreeing onlimiting their obstruction to an approaching emergency vehi-cle. Finally, the article enumerates the next steps establishedfrom research and standardization points of view, in Rel-17,and also beyond 5G, supported by both the fact that theconnected car is already a tangible reality, and the convictionthat it will be always essential to investigate the application toV2X of new wireless communication technologies, to ensurethat vehicles reach new levels of safety and efficiency.

REFERENCES[1] Wireless LAN Medium Access Control (MAC) Phys. Layer(PHY) Spec-

ifications Amendment 6: Wireless Access VehicularEnvironments, IEEEStandard 802.11p-2010, 2010.

[2] TSG SA, Service Requirements for V2X Services, document TS 22.185V14.4.0, 3GPP, Jun. 2018.

[3] TSG SA, Service Requirements for Enhanced V2X Scenarios, documentTS 22.186 V16.2.0, 3GPP, Jun. 2019.

[4] R. Molina-Masegosa and J. Gozalvez, ‘‘LTE-V for sidelink 5G V2Xvehicular communications: A new 5G technology for short-range Vehicle-to-Everything communications,’’ IEEE Veh. Technol. Mag., vol. 12, no. 4,pp. 30–39, Dec. 2017.

[5] TSG SA, Release Description; Release 14, document TR 21.914 V14.0.0,3GPP, Jun. 2018.

[6] TSG SA, Release Description; Release 15, document TR 21.915 V15.0.0,3GPP, Oct. 2019.

[7] TSG SA, Release Description; Release 16, document TR 21.916 V0.4.0,3GPP, Mar. 2020.

[8] TSG SA, Architecture Enhancements for 5G System (5GS) to SupportVehicle-to-Everything (V2X) Services, document TS 22.287 V16.2.0,3GPP, Mar. 2020.

[9] TSG SA, Service Requirements for Enhanced V2X Scenarios,document TS 22.186 V15.4.0, 3GPP, Sep. 2018.

[10] TSG SA, Architecture Enhancements for V2X Services,document TS 23.285 V15.4.0, 3GPP, Dec. 2019.

[11] TSG CT, User Equipment (UE) to V2X Control Function; ProtocolAspects; Stage 3, document TS 24.386 V15.2.0, 3GPP, Dec. 2018.

[12] TSG CT, V2X Control Function to Home Subscriber Server (HSS) aspects(V4); Stage 3, document TS 29.388 V15.1.0, 3GPP, Sep. 2019.

[13] TSG CT, Inter-V2X Control Function Signalling Aspects (V6); Stage 3,document TS 29.389 V15.1.0, 3GPP, Sep. 2019.

[14] V. Fajardo, J. Arkko, J. Loughney, and G. Zorn, Diameter Base Proto-col, document RFC 6733, Internet Requests for Comments, RFC Editor,Oct. 2012. [Online]. Available: https://www.rfc-editor.org/rfc/rfc6733.txt

[15] TSG CT, Characteristics of the Universal Subscriber Identity Module(USIM) Application, document TS 31.102 V15.9.0, 3GPP, Mar. 2020.

[16] TSG CT, V2X services Management Object (MO), document TS 24.385V15.1.0, 3GPP, Sep. 2018.

[17] TSG SA, Policy and Charging Control Architecture, document TS 23.203V16.2.0, 3GPP, Dec. 2019.

[18] TSG CT, Representational State Transfer Over xMB Reference PointBetween Content Provider and BM-SC, document TS 29.116 V15.2.0,3GPP, Dec. 2019.

[19] TSG CT, Group Communication System Enablers for LTE (GCSE LTE);MB2 Reference Point; Stage 3, document TS 29.468 V15.8.0, 3GPP,Dec. 2019.

[20] TSG CT, Interworking Between the Public Land Mobile Network (PLMN)Supporting Packet Based Services and Packet Data Networks (PDN),document TS 29.061 V15.5.0, 3GPP, Dec. 2018.

[21] TSG RAN, Evolved Universal Terrestrial Radio Access (E-UTRA); UserEquipment (UE) Radio Transmission and Reception, document TS 36.101V14.14.0, 3GPP, Jan. 2020.

[22] TSG RAN, Evolved Universal Terrestrial Radio Access (E-UTRA); Phys-ical Channels and Modulation, document TS 36.211 V14.14.0, 3GPP,Apr. 2020.

[23] TSG RAN, Evolved Universal Terrestrial Radio Access (E-UTRA);Medium Access Control (MAC) Protocol Specification, document TS36.321 V14.13.0, 3GPP, Oct. 2020.

[24] TSG RAN, Evolved Universal Terrestrial Radio Access (E-UTRA); Physi-cal layer; Measurements, document TS 36.214 V14.4.0, 3GPP, Jan. 2018.

[25] TSG RAN, Evolved Universal Terrestrial Radio Access (E-UTRA); RadioResource Control (RRC); Protocol Specification, document TS 36.331V14.14.0, 3GPP, Mar. 2020.

[26] TSG RAN, Evolved Universal Terrestrial Radio Access (E-UTRA); RadioResource Control (RRC); Protocol Specification, document TS 36.331V15.9.0, 3GPP, Mar. 2020.

[27] TSG RAN, Evolved Universal Terrestrial Radio Access (E-UTRA); UserEquipment (UE) Radio Transmission and Reception, document TS 36.101V15.10.0, 3GPP, Apr. 2020.

[28] TSG RAN, Evolved Universal Terrestrial Radio Access (E-UTRA); PacketData Convergence Protocol (PDCP) Specification, document TS 36.214V15.6.0, 3GPP, Jul. 2020.

[29] TSG RAN, Architecture Enhancements for V2X Services, document TS23.285 V16.2.0, 3GPP, Dec. 2019.

[30] TSG RAN, Study on Architecture Enhancements for the Evolved PacketSystem (EPS) and the 5G System (5GS) to Support Advanced V2X Services,document TS 23.786 V16.1.0, 3GPP, Jun. 2019.

[31] TSG CT, Vehicle-to-Everything (V2X) Services in 5G System (5GS); Stage3, document TS 24.587 V16.0.0, 3GPP, Mar. 2020.

[32] TSG CT, Vehicle-to-Everything (V2X) Services in 5G System (5GS); UserEquipment (UE) Policies; Stage 3, document TS 24.588 V16.0.0, 3GPP,Mar. 2020.

[33] TSG SA, System Architecture for the 5G System (5GS); Stage 2,document TS 23.501 V16.4.0, 3GPP, Mar. 2020.

[34] TSG SA, Policy and Charging Control Framework for the 5G System(5GS); Stage 2, document TS 23.503 V16.4.1, 3GPP, Apr. 2020.

190962 VOLUME 8, 2020

D. Garcia-Roger et al.: V2X Support in 3GPP Specifications

[35] TSG SA, Application Layer Support for Vehicle-to-Everything(V2X) Services; Functional Architecture and Information Flows,document TS 22.287 V16.3.0, 3GPP, Mar. 2020.

[36] TSG SA, Service Enabler Architecture Layer for Verticals (SEAL); Func-tional Architecture and Information Flows, document TS 23.434 V16.3.0,3GPP, Mar. 2020.

[37] TSG RAN NR, Physical Channels and Modulation, document TS 38.211V16.1.0, 3GPP, Apr. 2020.

[38] TSG RAN NR, Radio Resource Control (RRC); Protocol Specification,document TS 38.331 V16.0.0, 3GPP, Apr. 2020.

[39] TSG RAN NR, Medium Access Control (MAC) Protocol Specification,document TS 38.321 V16.0.0, 3GPP, Apr. 2020.

[40] W. Anwar, A. Trasl, N. Franchi, and G. Fettweis, ‘‘On the reliability ofNR-V2X and IEEE 802.11bd,’’ in Proc. IEEE 30th Annu. Int. Symp. Pers.,Indoor Mobile Radio Commun. (PIMRC), Sep. 2019, pp. 1–7.

[41] W. Anwar, N. Franchi, and G. Fettweis, ‘‘Physical layer evaluation of V2Xcommunications technologies: 5G NR-V2X, LTE-V2X, IEEE 802.11bd,and IEEE 802.11p,’’ in Proc. IEEE 90th Veh. Technol. Conf. (VTC-Fall),Sep. 2019, pp. 1–7.

[42] D. Amendola et al., ‘‘Deliverable D2.1. 5G CARMEN use cases andrequirements,’’ European Project ‘5G for Connected and Automated RoadMobility in the European UnioN’ (5G-CARMEN), Tech. Rep. Deliv-erable D2.1, Apr. 2019. [Online]. Available: https://5gcarmen.eu/wp-content/uploads/2020/03/5G_CARMEN_D2.1_FINAL.pdf

[43] TSG RAN, Release 17 Package for RAN Outcome From RAN#86,document TSG RAN 86 Meeting, 3GPP, 2017.

[44] G. Wikstrom, J. Peisa, P. Rugeland, N. Johansson, S. Parkvall, M. Girnyk,G. Mildh, and I. L. Da Silva, ‘‘Challenges and technologies for 6G,’’ inProc. 2nd 6G Wireless Summit (6G SUMMIT), Mar. 2020, pp. 1–5.

[45] L. Zhang, Y.-C. Liang, and D. Niyato, ‘‘6G visions: Mobile ultra-broadband, super Internet-of-Things, and artificial intelligence,’’ ChinaCommun., vol. 16, no. 8, pp. 1–14, Aug. 2019.

[46] H. Viswanathan and P. E. Mogensen, ‘‘Communications in the 6G era,’’IEEE Access, vol. 8, pp. 57063–57074, 2020.

[47] V. Ziegler and S. Yrjola, ‘‘6G Indicators of Value and Performance,’’ inProc. 2nd 6G Wireless Summit (6G SUMMIT), 2020, pp. 1–5.

[48] F. Tang, Y. Kawamoto, N. Kato, and J. Liu, ‘‘Future intelligent and securevehicular network toward 6G:Machine-learning approaches,’’ Proc. IEEE,vol. 108, no. 2, pp. 292–307, Feb. 2020.

[49] J. Ellis and S. Patil, ‘‘How NR based sidelink expands 5G C-V2X tosupport new advanced use cases,’’ Qualcomm Technol. Inc., San Diego,CA, USA, Tech. Rep., Mar. 2020. [Online]. Available: https://www.qualcomm.com/media/documents/files/nr-c-v2x-webinar-march-2020-presentation.pdf

[50] Autotalks. Dual Mode Chipsets Can Enable Large-Scale V2X Deploymentin the US and End the Standards War. Accessed: Oct. 20, 2020. [Online].Available: https://www.auto-talks.com/autotalks-cto-dual-mode-chipsets-can-enable-large-scale-v2x-deployment-in-the-us-and-end-the-standards-war/

[51] SNS Telecom & IT, The V2X (Vehicle-to-Everything) CommunicationsEcosystem: 2019–2030—Opportunities, Challenges, Strategies & Fore-casts, document, Mar. 2019.

[52] Ericsson. Ericsson Mobility Report. Accessed: Jun. 2019. [Online].Available: https://www.ericsson.com/49d1d9/assets/local/mobility-report/documents/2019/ericsson-mobility-report-june-2019.pdf

[53] Markets andMarkets,Automotive V2XMarket by Connectivity (DSRC, andCellular), Communication (V2V, V2I, V2P, V2G, V2C, and V2D), Vehicle(Passenger Car, and Commercial Vehicle), Propulsion (ICE and EV), Unit,Offering, Technology, and Region—Global Forecast to 2028, document AT5947, Feb. 2020.

DAVID GARCIA-ROGER received the Ph.D.degree in telecommunications from the UniversitatPolitècnica de València (UPV), Spain, in 2007.He has been a Researcher with ITEAM, UPV,since 2012, and an Adjunct Professor with theUniversitat de València, since 2020. He has par-ticipated as a Researcher in European projectsALPHA, METIS-II, and 5G-CARMEN. He haspublished about 40 articles. His research interestsinclude the evaluation of 5G candidate technolo-

gies and vehicular communication systems.

EDGAR E. GONZÁLEZ received the M.S. degreein communication technologies, systems and net-works from the Universitat Politècnica de Valèn-cia, Spain, in 2018, where he is currently pursuingthe Ph.D. degree, with a focus on internetworkingmechanisms for V2X services through a multi-RAT approach. Since April 2019, he has been afull-time Teacher/Researcher with the UniversidadTecnológica Israel, Quito, Ecuador.

DAVID MARTÍN-SACRISTÁN received theM.Sc. and Ph.D. degrees in telecommunicationsengineering from the Universitat Politècnica deValència (UPV), Spain, in 2006 and 2016, respec-tively. From 2006 to 2020, he was a Researcherwith the ITEAM Research Institute, UPV. He hasbeen involved in European projects such asWINNER+, which was an External Evaluator ofthe IMT-Advanced Technologies for the ITU or theEuropean projects METIS and METIS-II involved

in the development of 5G, as well as the 5G-CARMEN project focusedon 5G for connected and automated road mobility. He is currently theChief Technology Officer at Fivecomm and also an Adjunct Professor withthe Universitat de València since 2020. His research interests are focusedon the modeling and simulation of communication networks, resourcemanagement, massive MIMO, and vehicular communications.

JOSE F. MONSERRAT (Senior Member, IEEE)is currently a Full Professor with the Universi-tat Politècnica de València, Spain. His researchfocuses on the design of future 5G wireless sys-tems and their performance assessment. He hasbeen involved in several European Projects, i.e.,METIS/METIS-II, where he led the simula-tion activities, or currently 5G-CARMEN and5G-SMART. He has co-edited the book ‘‘Mobileand wireless communications for IMT-Advanced

and Beyond’’ (Wiley) and ‘‘5G Mobile and Wireless Communications Tech-nology’’ (Cambridge). He has published more than 60 journal articles. Hiscurrent research team consists of five postdoctoral fellows, eight Ph.D.students, and two master’s students.

VOLUME 8, 2020 190963