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

《TR 38.885 V1.0.2 (2019-02) NR Study on Vehicle-to-Everything》由會(huì)員分享，可在線閱讀，更多相關(guān)《TR 38.885 V1.0.2 (2019-02) NR Study on Vehicle-to-Everything（25頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

3GPP TR 38.885 V1.0.2 (2019-02) Technical Report 3rd 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) 25 Release 16 Keywords 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No 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 members 3GPP? is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTE? is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM and the GSM logo are registered and owned by the GSM Association Contents Foreword 5 1 Scope 6 2 References 6 3 Definitions, symbols and abbreviations 6 3.1 Definitions 6 3.2 Symbols 7 3.3 Abbreviations 7 4 Introduction 7 4.1 Operation scenarios 8 5 Sidelink (PC5) aspects 10 5.1 NR sidelink unicast, groupcast, and broadcast design 10 5.1.1 Physical layer structures 11 5.1.1.1 Waveform 11 5.1.1.2 Subcarrier spacing and cyclic prefix 11 5.1.1.3 Modulation 11 5.1.1.4 Scrambling 11 5.1.1.5 Channel coding 11 5.1.1.6 SL bandwidth parts and resource pools 12 5.1.1.7 PSSCH 12 5.1.1.8 RE mapping and rate matching 12 5.1.1.9 Reference signals 12 5.1.2 Physical layer procedures 12 5.1.2.1 Multiplexing of physical channels 12 5.1.2.2 HARQ procedures 13 5.1.2.2.1 General HARQ procedure 13 5.1.2.2.2 HARQ procedure details for Mode 1 resource allocation 13 5.1.2.2.3 HARQ procedure details for Mode 2 resource allocation 13 5.1.2.3 CSI acquisition and link adaptation 14 5.1.2.4 Power control 14 5.1.2.5 Multi antenna transmission scheme 14 5.2 Synchronization 14 5.2.1 S-PSS, S-SSS, PSBCH 14 5.2.2 Synchronization procedure 14 5.3 Resource allocation 14 5.3.1 Resource allocation Mode 2 15 5.3.1.1 Sensing and resource (re-)selection 15 5.3.1.2 Mode 2(a) 15 5.3.1.3 Mode 2(c) 15 5.3.1.4 Mode 2(d) 15 5.4 L2/L3 protocols 16 5.4.1 MAC 16 5.4.2 RLC 17 5.4.3 PDCP 17 6 Uplink and downlink (Uu) aspects 17 6.1 Advanced V2X use cases over Uu interfaces 17 6.1.1 LTE Uu evaluation and enhancement 17 6.1.2 NR Uu evaluation and enhancement 17 6.2 Uu-based SL resource allocation/configuration 17 6.2.1 Control of NR SL by NR 18 6.2.1.1 RRC 18 6.2.2 Control of NR SL by LTE 18 6.2.3 Control of LTE SL by NR 19 7 QoS management 19 8 RAT and interface selection 19 9 Coexistence 19 9.1 TDM solutions 19 9.2 FDM solutions 20 10 Network aspects 20 10.1 V2X service authorization 20 10.2 UE SL aggregate maximum bit rate 20 10.3 Impacts on the F1 interface 20 10.4 Slicing aspects 20 11 Evaluations and measurement results 20 11.1 Latency 20 11.2 mmWave SL performance 22 12 Conclusions 22 Annex A: Evaluation assumptions 22 A.1 Simulation profiles 22 A.2 Link-level simulation parameters 23 Annex : Change history 25 Foreword This 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.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. 1 Scope The 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. 2 References The 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. [1] 3GPPTR21.905: "Vocabulary for 3GPP Specifications". [2] 3GPP RP-181480: "New SID: Study on NR V2X". [3] 3GPP TR 22.186: "Enhancement of 3GPP support for V2X scenarios; Stage 1". [4] 3GPP TR 38.913: "Study on Scenarios and Requirements for Next Generation Access Technologies". [5] 3GPP TR 37.885: "Study on evaluation methodology of new Vehicle-to-Everything V2X use cases for LTE and NR". [6] 3GPP TR 37.910: "Study on self evaluation towards IMT-2020 submission". [7] 3GPP TR 38.800: "NR and NG-RAN Overall Description; Stage 2". [8] R1-190046: "Field trial results from 39GHz vehicle to vehicle communications", AT&T [9] R1-1805914: "V2X sidelink channel model", Huawei, HiSilicon 3 Definitions, symbols and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in 3GPP TR21.905[1] 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.905[1]. 3.2 Symbols For the purposes of the present document, the following symbols apply: 3.3 Abbreviations For the purposes of the present document, the abbreviations given in 3GPP TR21.905[1] 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.905[1]. 5GC 5G Core Network CBR Channel busy ratio CU Centralised unit DU Distributed unit EN-DC E-UTRA-NR Dual Connectivity FR Frequency range GNSS Global navigation satellite system ITS Intelligent transport systems MR-DC Multi-Radio Dual Connectivity NE-DC NR-E-UTRA Dual Connectivity NGEN-DC NG-RAN E-UTRA-NR Dual Connectivity OLPC Open-loop power control OS OFDM symbol PSBCH Physical SL broadcast channel PSCCH Physical SL control channel PSSCH Physical SL shared channel RE Resource element RSU Road side unit SCS Subcarrier spacing SL Sidelink V2B Vehicle to base station V2I Vehicle to infrastructure V2P Vehicle to pedestrian V2R Vehicle to road side unit V2V Vehicle to vehicle V2X Vehicle to everything 4 Introduction Support 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.1 Operation scenarios The 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 1 Figure 4.1-2: Scenario 2 Figure 4.1-3: Scenario 3 Figure 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 4 Figure 4.1-5: Scenario 5 Figure 4.1-6: Scenario 6 5 Sidelink (PC5) aspects 5.1 NR sidelink unicast, groupcast, and broadcast design SL 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 ID For 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 ID Discovery procedure and related messages for the unicast and groupcast transmission are up to upper layers. 5.1.1 Physical layer structures In 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.1 Waveform A 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.2 Subcarrier spacing and cyclic prefix In 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.3 Modulation 5.1.1.4 Scrambling 5.1.1.5 Channel coding The 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.6 SL bandwidth parts and resource pools BWP 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.7 PSSCH Resource allocation for PSSCH is based on the concept of sub-channels in the frequency domain. 5.1.1.87 RE mapping and rate matching 5.1.1.98 Reference signals DM-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.2 Physical layer procedures In this section, physical layer procedures are studied. For procedures related to SL synchronization, refer to Section 5.2 5.1.2.1 Multiplexing of physical channels For 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.2 HARQ feedbackprocedures 5.1.2.2.1 General HARQ procedure For 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