TR 38.885 V1.0.2 (2019-02) NR Study on Vehicle-to-Everything

3GPP TR 38.885 V1.0.2 (2019-02)Technical Report3rd Generation Partnership Project;Technical Specification Group Radio Access Network;NR;Study on Vehicle-to-Everything (Release 16) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.This Report is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners Publications Offices.3GPP TR 38.885 V1.0.2 (2019-02)25Release 16Keywords3GPPPostal address3GPP support office address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16Internethttp:/www.3gpp.orgCopyright NotificationNo part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media. 2018, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).All rights reserved.UMTS is a Trade Mark of ETSI registered for the benefit of its members3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational PartnersLTE is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational PartnersGSM and the GSM logo are registered and owned by the GSM AssociationContentsForeword51Scope62References63Definitions, symbols and abbreviations63.1Definitions63.2Symbols73.3Abbreviations74Introduction74.1Operation scenarios85Sidelink (PC5) aspects105.1NR sidelink unicast, groupcast, and broadcast design105.1.1Physical layer structures115.1.1.1Waveform115.1.1.2Subcarrier spacing and cyclic prefix115.1.1.3Modulation115.1.1.4Scrambling115.1.1.5Channel coding115.1.1.6SL bandwidth parts and resource pools125.1.1.7PSSCH125.1.1.8RE mapping and rate matching125.1.1.9Reference signals125.1.2Physical layer procedures125.1.2.1Multiplexing of physical channels125.1.2.2HARQ procedures135.1.2.2.1General HARQ procedure135.1.2.2.2HARQ procedure details for Mode 1 resource allocation135.1.2.2.3HARQ procedure details for Mode 2 resource allocation135.1.2.3CSI acquisition and link adaptation145.1.2.4Power control145.1.2.5Multi antenna transmission scheme145.2Synchronization145.2.1S-PSS, S-SSS, PSBCH145.2.2Synchronization procedure145.3Resource allocation145.3.1Resource allocation Mode 2155.3.1.1Sensing and resource (re-)selection155.3.1.2Mode 2(a)155.3.1.3Mode 2(c)155.3.1.4Mode 2(d)155.4L2/L3 protocols165.4.1MAC165.4.2RLC175.4.3PDCP176Uplink and downlink (Uu) aspects176.1Advanced V2X use cases over Uu interfaces176.1.1LTE Uu evaluation and enhancement176.1.2NR Uu evaluation and enhancement176.2Uu-based SL resource allocation/configuration176.2.1Control of NR SL by NR186.2.1.1RRC186.2.2Control of NR SL by LTE186.2.3Control of LTE SL by NR197QoS management198RAT and interface selection199Coexistence199.1TDM solutions199.2FDM solutions2010Network aspects2010.1V2X service authorization2010.2UE SL aggregate maximum bit rate2010.3Impacts on the F1 interface2010.4Slicing aspects2011Evaluations and measurement results2011.1Latency2011.2mmWave SL performance2212Conclusions22Annex A:Evaluation assumptions22A.1Simulation profiles22A.2Link-level simulation parameters23Annex : Change history25ForewordThis Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:Version x.y.zwhere:xthe first digit:1presented to TSG for information;2presented to TSG for approval;3or greater indicates TSG approved document under change control.ythe second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.zthe third digit is incremented when editorial only changes have been incorporated in the document.1ScopeThe present document captures the findings of the study item, Study on NR Vehicle-to-Everything 2. The purpose of this TR is to is to study how to support advanced V2X use cases identified in 3, among other matters. However, this does not imply that NR V2X capability is necessarily restricted to advanced services. It is up to the regional regulators and the stakeholders involved (i.e. car OEMs and the automotive ecosystem in general) to decide on the technology of choice for the services and use cases.This document addresses NR SL design for V2X; Uu enhancements for advanced V2X use cases; Uu-based SL resource allocation/configuration by LTE and NR; RAT and interface selection; QoS management; and non-cochannel coexistence between NR and LTE SLs. The study addresses unlicensed ITS bands and licensed bands in frequency ranges below and above 6 GHz, i.e. FR1 and FR2, up to 52.6 GHz.This document is a living document, i.e. it is permanently updated and presented to TSG-RAN meetings.2ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present document.-References are either specific (identified by date of publication, edition number, version number, etc.) or nonspecific.-For a specific reference, subsequent revisions do not apply.-For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.13GPPTR21.905: Vocabulary for 3GPP Specifications.23GPP RP-181480: New SID: Study on NR V2X.33GPP TR 22.186: Enhancement of 3GPP support for V2X scenarios; Stage 1.43GPP TR 38.913: Study on Scenarios and Requirements for Next Generation Access Technologies.53GPP TR 37.885: Study on evaluation methodology of new Vehicle-to-Everything V2X use cases for LTE and NR.63GPP TR 37.910: Study on self evaluation towards IMT-2020 submission.73GPP TR 38.800: NR and NG-RAN Overall Description; Stage 2.8R1-190046: Field trial results from 39GHz vehicle to vehicle communications, AT&T9R1-1805914: V2X sidelink channel model, Huawei, HiSilicon3Definitions, symbols and abbreviations3.1DefinitionsFor the purposes of the present document, the terms and definitions given in 3GPP TR21.9051 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR21.9051.3.2SymbolsFor the purposes of the present document, the following symbols apply:3.3AbbreviationsFor the purposes of the present document, the abbreviations given in 3GPP TR21.9051 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR21.9051.5GC5G Core NetworkCBRChannel busy ratioCUCentralised unitDUDistributed unitEN-DCE-UTRA-NR Dual ConnectivityFRFrequency rangeGNSSGlobal navigation satellite systemITSIntelligent transport systemsMR-DCMulti-Radio Dual ConnectivityNE-DCNR-E-UTRA Dual ConnectivityNGEN-DCNG-RAN E-UTRA-NR Dual ConnectivityOLPCOpen-loop power controlOSOFDM symbolPSBCHPhysical SL broadcast channelPSCCHPhysical SL control channelPSSCHPhysical SL shared channelREResource elementRSURoad side unitSCSSubcarrier spacingSLSidelinkV2BVehicle to base stationV2IVehicle to infrastructureV2PVehicle to pedestrianV2RVehicle to road side unitV2VVehicle to vehicleV2XVehicle to everything4IntroductionSupport for V2V and V2X services has been introduced in LTE during Releases 14 and 15, in order to expand the 3GPP platform to the automotive industry. These work items defined an LTE SL suitable for vehicular applications, and complementary enhancements to the cellular infrastructure.Further to this work, SA WG1 have defined Stage 1 requirements for support of enhanced V2X use cases, which are broadly arranged into four use case groups 3:1)Vehicles Platooning enables the vehicles to dynamically form a platoon travelling together. All the vehicles in the platoon obtain information from the leading vehicle to manage this platoon. These information allow the vehicles to drive closer than normal in a coordinated manner, going to the same direction and travelling together. 2)Extended Sensors enables the exchange of raw or processed data gathered through local sensors or live video images among vehicles, road site units, devices of pedestrian and V2X application servers. The vehicles can increase the perception of their environment beyond of what their own sensors can detect and have a more broad and holistic view of the local situation. High data rate is one of the key characteristics.3)Advanced Driving enables semi-automated or full-automated driving. Each vehicle and/or RSU shares its own perception data obtained from its local sensors with vehicles in proximity and that allows vehicles to synchronize and coordinate their trajectories or manoeuvres. Each vehicle shares its driving intention with vehicles in proximity too. 4)Remote Driving enables a remote driver or a V2X application to operate a remote vehicle for those passengers who cannot drive by themselves or remote vehicles located in dangerous environments. For a case where variation is limited and routes are predictable, such as public transportation, driving based on cloud computing can be used. High reliability and low latency are the main requirements.In TSG RAN, a set of corresponding 5G RAN requirements, channel models, etc. for NR have been defined in TR 38.913 4 and TR 37.885 5.This study investigates the RAN aspects of supporting these advanced use cases and requirements in NR, as phase 3 of V2X support in the 3GPP platform. This TR reports the studys findings on: NR SL design for V2X; Uu enhancements for advanced V2X use cases; Uu-based SL resource allocation/configuration by LTE and NR; RAT and interface selection; QoS management; and non-cochannel coexistence between NR and LTE SLs. The study addresses unlicensed ITS bands and licensed bands in frequency ranges below and above 6 GHz, i.e. FR1 and FR2, up to 52.6 GHz. As can be seen from these aspects, NR V2X will complement LTE V2X for advanced V2X services and support interworking with LTE V2X.In the remainder of this document, the NR SL or the LTE SL may be referred to specifically. When no RAT is indicated, the NR SL is meant.4.1Operation scenariosThe scenarios considered in the study are captured in the following figures. The scenarios can be categorized into standalone and MR-DC scenarios regarding the architecture. The study prioritised Scenarios 1 and 2, and MN controlling/configuring both NR SL and LTE SL in Scenario 5 and 6 which is covered by Scenario 1 and 2.Figure 4.1-1, Figure 4.1-2 and Figure 4.1-3 illustrate the standalone scenarios to support V2X SL communication. Particularly:1) In scenario 1, a gNB provides control/configuration for a UEs V2X communication in both LTE SL and NR SL;2) In scenario 2, an ng-eNB provides control/configuration for a UEs V2X communication in both LTE SL and NR SL;3) In scenario 3, an eNB provides control/configuration for a UEs V2X communication in both LTE SL and NR SL.Figure 4.1-1: Scenario 1Figure 4.1-2: Scenario 2Figure 4.1-3: Scenario 3Figure 4.1-4, Figure 4.1-5 and Figure 4.1-6 illustrate the MR-DC scenarios to support V2X SL communication. Particularly:1) In scenario 4, a UEs V2X communication in LTE SL and NR SL is controlled/configured by Uu while the UE is configured with EN-DC;2) In scenario 5, a UEs V2X communication in LTE SL and NR SL is controlled/configured by Uu while the UE is configured in NE-DC;3) In scenario 6, a UEs V2X communication in LTE SL and NR SL is controlled/configured by Uu while the UE is configured in NGEN-DC. Figure 4.1-4: Scenario 4Figure 4.1-5: Scenario 5Figure 4.1-6: Scenario 65Sidelink (PC5) aspects5.1NR sidelink unicast, groupcast, and broadcast designSL broadcast, groupcast, and unicast transmissions are supported for the in-coverage, out-of-coverage and partial-coverage scenarios.The AS protocol stack for the control plane in the PC5 interface consists of at least RRC, PDCP, RLC and MAC sublayers, and the physical layer. The protocol stack of PC5-C is shown in Figure 5.1-1.Figure 5.1-1: PC5 control plane (PC5-C) protocol stack.The AS protocol stack for user plane in the PC5 interface consists of at least PDCP, RLC and MAC sublayers, and the physical layer. The protocol stack of PC5-U is shown in Figure 5.1-2.Error! Objects cannot be created from editing field codes.Figure 5.1-2: PC5 user plane (PC5-U) protocol stack.For the purposes of physical layer analysis, it is assumed that higher layers decide if unicast, groupcast, or broadcast transmission is to be used for a particular data transfer, and they correspondingly inform the physical layer. When considering a unicast or groupcast transmission, it is assumed that the UE is able to establish which unicast or groupcast session a transmission belongs to, and that the following information is known to the physical layer:-Identities:-The layer-1 source and destination IDs, conveyed in SCIvia PSCCH-Additional layer-1 ID(s), conveyed via PSCCH, at least for the purpose of identifying which transmissions can be combined in reception when HARQ feedback is in use (see Section 5.1.2.2)-HARQ process IDFor the purpose of Layer 2 analysis, it is assumed that upper layers (i.e. above AS) provide the information on whether it is a unicast, groupcast or broadcast transmission for a particular data transfer. For the unicast and groupcast transmission in SL, the following information is known to Layer 2:-Identities:-Unicast: destination ID, source ID-Groupcast: destination Group ID, source IDDiscovery procedure and related messages for the unicast and groupcast transmission are up to upper layers.5.1.1Physical layer structuresIn this section, the design of a physical SL control channel (PSCCH), a physical SL shared channel (PSSCH), a physical SL feedback channel (PSFCH) insert others later, and other matters related to physical layer structures are studied. For design of the physical SL broadcast channel (PSBCH), refer to Section 5.2.Editors note: The arrangement of the following sections may be updated depending on further agreements in RAN1.5.1.1.1WaveformA single waveform is used for all the SL channels in a carrier. The waveform supported in the study is CP-OFDM, at least. For DFT-S-OFDM, aspects to study include: coverage enhancement of SL synchronization, PSCCH, and PSFCH. In case specifications support multiple waveforms, (pre-)configuration will determine which is in use.5.1.1.2Subcarrier spacing and cyclic prefixIn FR1, 15 kHz, 30 kHz and 60 kHz SCS are supported with normal CP, and 60 kHz SCS with extended CP. In FR2, 60 and 120 kHz SCS are supported. In a given carrier, a UE is not required to receive simultaneously SL transmissions with more than one combination of SCS and CP, nor transmit simultaneously SL transmissions with more than one combination of SCS and CP. The numerology configuration is part of the SL BWP configuration (see Section 5.1.1.6).5.1.1.3Modulation5.1.1.4Scrambling5.1.1.5Channel codingThe channel coding defined for data and control in NR Uu are respectively the starting points for data and control on the NR SL.5.1.1.6SL bandwidth parts and resource poolsBWP is defined for SL, and the same SL BWP is used for transmission and reception. In specification terms, in a licensed carrier, SL BWP would be defined separately, and have separate configuration signalling, from Uu BWP. One SL BWP is (pre-)configured for RRC IDLE and out-of-coverage NR V2X UEs in a carrier. For UEs in RRC_CONNECTED mode, one SL BWP is active in a carrier. No signalling is exchanged over SL for the activation or deactivation of a SL BWP.Only one SL BWP is configured in a carrier for a UE, and a UE is not expected to use different numerologies in the SL BWP than an active UL BWP. (Editors note: this is a RAN1 working assumption).A resource pool is a set of time-frequency resources that can be used for SL transmission and/or reception. From the UE point of view, a resource pool is inside the UEs bandwidth, within a SL BWP and has a single numerology. Time domain resources in a resource pool can be non-contiguous. Multiple resource pools can be (pre-)configured to a UE in a carrier.5.1.1.7PSSCHResource allocation for PSSCH is based on the concept of sub-channels in the frequency domain.5.1.1.87RE mapping and rate matching5.1.1.98Reference signalsDM-RS associated with PSSCH are transmitted in one of several possible patterns in the time domain. In FR2, a PT-RS for PSSCH is also supported.Other Ccandidate reference signals are: DM-RS (starting from the Rel-15 NR Uu design), PT-RS, CSI-RS, SRS, and AGC training signal.5.1.2Physical layer proceduresIn this section, physical layer procedures are studied. For procedures related to SL synchronization, refer to Section 5.25.1.2.1Multiplexing of physical channelsFor the purposes of this section, a PSSCH is said to be associated to a PSCCH when the PSCCH carries at least the SL control information (SCI) necessary to decode the PSSCH. The following options for multiplexing of a PSCCH and associated PSSCH are studied:Option 1: PSCCH and the associated PSSCH are transmitted using non-overlapping time resources.-Option 1A: The frequency resources used by the two channels are the same.-Option 1B: The frequency resources used by the two channels can be different.Option 2: PSCCH and the associated PSSCH are transmitted using non-overlapping frequency resources in the all the time resources used for transmission. The time resources used by the two channels are the same.Option 3: Part of PSCCH and the associated PSSCH are transmitted using overlapping time resources in non-overlapping frequency resources, but another part of the associated PSSCH and/or another part of the PSCCH are transmitted using non-overlapping time resources.Figure 1: Illustration of multiplexing options for PSCCH and associated PSSCH.Of the options described above, at least Option 3 is supported. (Editors note: this is a RAN1 working assumption).5.1.2.2HARQ feedbackprocedures5.1.2.2.1General HARQ procedureFor SL unicast and groupcast, HARQ feedback and HARQ combining in the physical layer are supported. HARQ-ACK feedback for a PSSCH is carried in SL feedback control information (SFCI) format(s) via PSFCH.When SL HARQ feedback is enabled for unicast, in the case of non-CBG operation the receiver UE generates HARQ-ACK if it successfully decodes the corresponding TB. It generates HARQ-NACK if it does not successfully decode the corresponding TB after decoding the associated PSCCH targeted to the r