Entity | Concept 1 | Concept 2 | Concept 3 | Concept 4 | Concept 5 | Concept 6 | Concept 7 | Concept 8 |
---|---|---|---|---|---|---|---|---|
3GPP TSG RAN WG1 (R1-2302255) | Meeting registration deadline: April 10, 8:00 am UTC [R1-2302255] | Tdoc request deadline: April 7, 3:00 pm UTC [R1-2302255] | Tdoc submission deadline: April 7, 11:59 pm UTC [R1-2302255] | Agenda approval [R1-2302255] | Minutes approval from previous meetings [R1-2302255] | Incoming Liaison Statements [R1-2302255] | E-UTRA Maintenance: essential corrections only [R1-2302255] | Moderator and co-sourcing companies for final endorsed CR [R1-2302255] |
Entity | Concept 1 | Concept 2 | Concept 3 | Concept 4 | Concept 5 | Concept 6 | Concept 7 | Concept 8 |
---|---|---|---|---|---|---|---|---|
ETSI MCC | Report of RAN1#112 [R1-2302256] | 3GPP TSG RAN WG1 [R1-2302256] | Athens, Greece [R1-2302256] | 27th February – 3rd March 2023 [R1-2302256] | Athenaeum InterContinental hotel [R1-2302256] | EF3 hosted meeting [R1-2302256] | Approval document [R1-2302256] | Main facts summary [R1-2302256] |
Entity | Contention Window Adjustment Procedures (R1-2302453, R1-2302454, R1-2302455, R1-2302528) | PUCCH Resource Determination and HARQ-ACK Reporting (R1-2302646) | Physical Random Access Channel (PRACH) (R1-2302647, R1-2302648, R1-2302649) | Type-2 HARQ-ACK Codebook (R1-2302677, R1-2302678) | Transport Block Size (TBS) Determination (R1-2302768) | Radio Link Monitoring (RLM) (R1-2302956) | PDSCH-to-HARQ_feedback Timing Indicator (R1-2303099, R1-2303100, R1-2303287, R1-2303289) | Type-1 HARQ-ACK Codebook (R1-2303564, R1-2303664) |
---|---|---|---|---|---|---|---|---|
vivo | Defined contention window adjustment procedures (R1-2302453); draft on procedures for DL transmissions by gNB (R1-2302454, R1-2302455) | |||||||
OPPO | Correction to CWS adjustment for channels without explicit HARQ feedback (R1-2302528) | |||||||
CATT | PUCCH transmission with HARQ-ACK information (R1-2302646) | Clarifications and corrections on PRACH (R1-2302647, R1-2302648, R1-2302649) | Type-2 HARQ-ACK codebook grouping and retransmission (R1-2302677, R1-2302678) | Correction on the mapping of PDSCH-to-HARQ_feedback timing indicator field values (R1-2303287, R1-2303289) | ||||
Ericsson | Transport block size determination for PUSCH scheduled by RAR UL grant (R1-2302768) | |||||||
xiaomi | Correction on indication period for RLM for DRX mode (R1-2302956) | |||||||
Samsung | Draft CR for default value of PDSCH-to-HARQ_feedback (R1-2303099, R1-2303100); correction on HARQ-ACK codebook for SPS PDSCH receptions (R1-2303101); discussion on Type-1 HARQ-ACK codebook with a new RRC parameter (R1-2303102) | |||||||
Nokia, Nokia Shanghai Bell | Clarification on the switching gap location of UL Tx Switching (R1-2303171) | |||||||
NEC Corporation | Corrections on Channel Structure for 2-step RACH (R1-2303664) | |||||||
Qualcomm Incorporated | Discussion on Type1 HARQ-ACK CB issue with more than one PDSCH per slot (R1-2303564) | |||||||
Huawei, HiSilicon | Discussion on the multiplexing between SR/SPS A/N and CSI (R1-2303802) |
Entity | Two TAs for multi-DCI | Uplink Transmissions | Initial TAC Signaling | Unified TCI Framework | UE Implementation | RACH Enhancement | Associating TAGs |
---|---|---|---|---|---|---|---|
InterDigital, Inc. [R1-2302300] | Enhanced mTRP operation with multiple TA | ||||||
FUTUREWEI [R1-2302312] | Two TAs for UL multi-DCI for multi-TRP operation | ||||||
Huawei, HiSilicon [R1-2302371] | TA enhancement for UL M-TRP transmission | ||||||
Ericsson [R1-2302412] | Two TAs for multi-DCI | ||||||
ZTE [R1-2302417] | TA enhancement for multi-DCI-based MTRP operation | ||||||
vivo [R1-2302470] | Two TAs for multi-DCI-based multi-TRP operation | Unified TCI framework extension for M-DCI based MTRP | |||||
OPPO [R1-2302533] | Two TAs for multi-DCI based multi-TRP operation | ||||||
Spreadtrum Communications [R1-2302586] | Two TAs for UL multi-DCI for multi-TRP | ||||||
CATT [R1-2302681] | Two TAs for UL multi-DCI for multi-TRP operation | ||||||
Lenovo [R1-2302724] | Two TAs for multi-DCI UL transmission | ||||||
Intel Corporation [R1-2302781] | On two TAs for multi-DCI | Associating TAGs to uplink channels/signals | |||||
xiaomi [R1-2302960] | Two TAs for multi-TRP operation | ||||||
Nokia, Nokia Shanghai Bell [R1-2303006] | Two TAs for UL multi-DCI multi-TRP operation | ||||||
TCL Communication Ltd. [R1-2303040] | Two TAs for multi-DCI based on multi-TRP operation | ||||||
Samsung [R1-2303111] | Views on two TAs for m-DCI | ||||||
Sharp [R1-2303179] | Two TAs for multi-DCI | Initial TAC signaling | |||||
CMCC [R1-2303217] | Discussion on two TAs for multi-DCI | ||||||
MediaTek Inc. [R1-2303360] | UL Tx Timing Management for MTRP Operation | UE implementation issue | RACH enhancement for both intra-cell and inter-cell MTRP | ||||
Transsion Holdings [R1-2303373] | Two TAs for multi-DCI based multi-TRP operation | ||||||
Apple [R1-2303468] | Views on two TAs for multi-DCI Uplink Transmissions | ||||||
Google [R1-2303517] | Discussion on two TAs for multi-DCI | ||||||
Qualcomm Incorporated [R1-2303574] | Supporting two TAs for multi-DCI based mTRP | ||||||
NEC [R1-2303666] | Discussion on two TAs for multi-DCI | ||||||
NTT DOCOMO, INC. [R1-2303698] | Discussion on two TAs for multi-DCI |
Concept | InterDigital, Inc. (R1-2302302) | FUTUREWEI (R1-2302313) | Huawei, HiSilicon (R1-2302373) | ZTE, China Telecom (R1-2302419) | New H3C Technologies (R1-2302428) | OPPO (R1-2302535) | Spreadtrum Communications (R1-2302588) | Fraunhofer IIS (R1-2302634) |
---|---|---|---|---|---|---|---|---|
DMRS Enhancements | Rel-18 MIMO WID, uplink and downlink transmission (R1-2302302) | Increase number of orthogonal DM-RS ports for MU-MIMO (R1-2302313) | DMRS enhancement for larger number of orthogonal DMRS ports, 8Tx UL (R1-2302373) | UL/DL MU-MIMO, 8 Tx UL SU-MIMO (R1-2302419) | Increased number of orthogonal DMRS ports in Rel.18 NR MIMO evolution (R1-2302428) | Rel-18 DMRS enhancement, dynamic switching not supported (R1-2302535) | Increase max number of DMRS ports for PDSCH/PUSCH for CP-OFDM (R1-2302588) | Enhancement of DMRS ports in downlink and uplink in Rel. 18 (R1-2302634) |
UL/DL MU-MIMO | Rel. 18 NR_MIMO_evo_DL_UL WID (R1-2302313) | Targeting both UL and DL (R1-2302419) | Introduce MU-MIMO restriction (R1-2302535) | |||||
8 Tx UL SU-MIMO | More than 4 layers SU-MIMO PUSCH for 8TX UL operation (R1-2302373) | Enhancements for both UL and DL (R1-2302419) | ||||||
Antenna Ports Indication | Rel.18 eType1 DMRS ports with maxLength=1 for PDSCH, S-TRP case (R1-2302535) | |||||||
Dynamic Switching | Not supported in Rel-18 (R1-2302535) | |||||||
DMRS Capacity Enhancement | ||||||||
CSI Reporting Enhancement |
Entity | Enhancements on SRS | SRS Interference Randomization | Capacity Enhancement | 8Tx Operation | TDD CJT | UL MIMO | Mapping Pattern |
---|---|---|---|---|---|---|---|
InterDigital, Inc. [R1-2302303] | Uplink reference signals, CJT, 8TX UEs | ||||||
FUTUREWEI [R1-2302314] | SRS enhancements, TDD CJT, 8TX operation | ||||||
Huawei, HiSilicon [R1-2302374] | SRS enhancement, TDD CJT, UL 8Tx operation | CS hopping, comb offset hopping | 8 ports in 1 symbol | ||||
ZTE [R1-2302420] | SRS enhancement, TDD CJT, 8 TX operation | ||||||
OPPO [R1-2302536] | SRS enhancement, TDD CJT, 8 TX operation | ||||||
New H3C Technologies Co., Ltd. [R1-2302580] | SRS enhancement, TDD CJT, UL 8Tx operation | ||||||
Spreadtrum Communications [R1-2302589] | SRS enhancement, TDD CJT, 8 TX operation | ||||||
CATT [R1-2302684] | Rel-18 SRS enhancement, TDD CJT, UL 8Tx | ||||||
Lenovo [R1-2302727] | SRS enhancement, large antenna array | ||||||
Oy LM Ericsson AB [R1-2302776] | SRS enhancements, TDD CJT, 8 TX operation | ||||||
Intel Corporation [R1-2302784] | SRS enhancement, Rel-18 | ||||||
Xiaomi [R1-2302963] | SRS enhancement, Rel-18 | ||||||
Nokia, Nokia Shanghai Bell [R1-2303009] | SRS enhancement, TDD CJT, 8Tx operation | ||||||
Google [R1-2303046] | SRS enhancement | ||||||
Samsung [R1-2303116] | SRS enhancement, TDD CJT, 8 Tx UL operation | ||||||
KDDI Corporation [R1-2303170] | SRS enhancement, TDD CJT, 8 TX operation | ||||||
Sharp [R1-2303181] | SRS enhancement, TDD CJT, 8 TX operation | ||||||
ETRI [R1-2303192] | SRS enhancement, TDD CJT | ||||||
CMCC [R1-2303220] | SRS enhancement, TDD CJT, 8 TX operation | ||||||
Apple [R1-2303471] | Rel-18 MIMO SRS enhancement | ||||||
Qualcomm Incorporated [R1-2303577] | SRS enhancement, TDD CJT, 8 Tx operation | ||||||
NEC [R1-2303679] | SRS enhancement | ||||||
NTT DOCOMO, INC. [R1-2303701] | SRS enhancement, M-TRP CJT, 8TX UL |
Concept | Qualcomm Incorporated (Ref R1-2303580) |
---|---|
AI/ML Framework | Stages of Machine Learning, Collaboration levels, ML model Life Cycle Management (4.1, 4.2, 4.3) |
Use Cases | CSI feedback enhancement, Beam Management, Positioning accuracy enhancements (5.1, 5.2, 5.3) |
Evaluations | Common evaluation methodology, KPIs, Performance results (6.1, 6.2.1, 6.2.2, 6.3.1, 6.3.2, 6.4.1, 6.4.2) |
Potential Specification Impact Assessment | General observations, Physical layer, Protocol aspects, Interoperability and testability aspects (7.1, 7.2, 7.3, 7.4) |
Physical Layer Aspects | Common framework, CSI feedback enhancement, Beam management, Positioning accuracy enhancements (7.2.1, 7.2.2, 7.2.3, 7.2.4) |
Protocol Aspects | Common framework, CSI feedback enhancement, Beam management, Positioning accuracy enhancements (7.3.1, 7.3.2, 7.3.3, 7.3.4) |
Interoperability and Testability Aspects | Common framework, CSI feedback enhancement, Beam management, Positioning accuracy enhancements (7.4.1, 7.4.2, 7.4.3, 7.4.4) |
Entity | Common AI/ML Characteristics (R1-2302318) | General Aspects of AI/ML Framework (R1-2302357) | Common AI PHY Framework (R1-2302436) | AI/ML Framework Discussions (R1-2302476) | General Aspects of AI/ML Framework (R1-2302539) | General Aspects of AI/ML Framework (R1-2302592) | General Aspects of ML for Air-interface (R1-2302627) | AI/ML Framework for NR air interface (R1-2302694) |
---|---|---|---|---|---|---|---|---|
FUTUREWEI | Common AI/ML characteristics, operations, RAN1 meeting agreements (R1-2302318) | - | - | - | - | - | - | - |
Huawei, HiSilicon | - | Terminology, model identification, performance monitoring, previous RAN1 agreements (R1-2302357) | - | - | - | - | - | - |
ZTE | - | - | Common AI PHY framework, general aspects, air interface, new SID approval (R1-2302436) | - | - | - | - | - |
vivo | - | - | - | General aspects of AI/ML framework, agreements and conclusions, appendix D, further discussions (R1-2302476) | - | - | - | - |
OPPO | - | - | - | - | General aspects of AI/ML framework from previous RAN1 meetings (R1-2302539) | - | - | - |
Spreadtrum Communications | - | - | - | - | - | General aspects of AI/ML framework, SID approval, air interface (R1-2302592) | - | - |
Nokia, Nokia Shanghai Bell | - | - | - | - | - | - | Further discussion on general aspects of AI/ML for air interface, agreements from RAN WG#1 (R1-2302627) | - |
CATT | - | - | - | - | - | - | - | AI/ML framework for NR air interface, non-linear issue solving (R1-2302694) |
Entity | AI/ML Positioning | Evaluation Methodology | KPIs | Training Strategy and Generalization | Data Modelling and Generation | Performance Improvement | Model Operation |
---|---|---|---|---|---|---|---|
Ericsson [R1-2302335] | Positioning accuracy enhancement | Statistical models for link and system simulations | Target horizontal positioning accuracy | Separating training, validation, and testing data | 3GPP evaluation methodology and channel modeling | Performance improvements with AI/ML-based positioning | Latency, complexity, hardware requirements, memory, power |
Huawei, HiSilicon [R1-2302362] | Direct AI/ML positioning and AI/ML assisted positioning | Evaluation methodology, KPIs, evaluation results | Positioning accuracy enhancement KPIs | Training strategy for AI/ML positioning | 3GPP evaluation methodology extensions | Performance improvements in various AI/ML positioning use cases | Model operation KPIs |
ZTE [R1-2302441] | AI positioning enhancement | Methodology based on statistical models | Positioning accuracy enhancement KPIs | AI/ML model training strategy | Extensions to 3GPP evaluation methodology | AI/ML-based positioning improvements | AI/ML model operation metrics |
vivo [R1-2302481] | Positioning accuracy enhancement with AI/ML | Methodology based on statistical models | Target positioning accuracy for IIoT and commercial use cases | AI/ML model training strategy | 3GPP evaluation methodology and channel modeling | Positioning accuracy improvements | Model operation KPIs |
OPPO [R1-2302544] | AI/ML solutions for positioning accuracy enhancement | Evaluation methodology and preliminary results | Positioning accuracy enhancement KPIs | Training strategy for AI/ML positioning | Data modeling and generation for AI/ML positioning | Improved positioning accuracy with AI/ML solutions | Model operation metrics |
Nokia, Nokia Shanghai Bell [R1-2302632] | ML for positioning accuracy enhancement | Statistical models for link and system simulations | Positioning accuracy enhancement KPIs | Training strategy for ML positioning | 3GPP evaluation methodology and channel modeling | ML-based positioning improvements | Model operation KPIs |
CATT [R1-2302699] | AI/ML-based positioning enhancement | Evaluation methodology and evaluation results | Positioning accuracy enhancement KPIs | AI/ML model training strategy | Data modeling and generation for AI/ML positioning | Improved positioning accuracy with AI/ML-based solutions | Model operation metrics |
Fujitsu [R1-2302908] | AIML positioning accuracy enhancement | Performance evaluation under different scenarios and configurations | Positioning accuracy enhancement KPIs | Training strategy and model generalization | Data modeling and generation for AIML positioning | Performance improvements with AIML-based positioning | Model operation metrics |
Entity | Data Collection | Model Inference | Model Monitoring | AI/ML Operation Modes | Spec Impacts | Sub-use Cases | Positioning Methods |
---|---|---|---|---|---|---|---|
Ericsson [R1-2302336] | Positioning accuracy enhancements | ||||||
Huawei, HiSilicon [R1-2302363] | Data collection for AI/ML model training | Model inference for positioning accuracy enhancement | Model performance monitoring | AI/ML operation modes for positioning enhancement | Potential specification impacts for AI/ML-based positioning | Direct and assisted AI/ML-based positioning sub-use cases | |
ZTE [R1-2302442] | AI positioning enhancement | ||||||
vivo [R1-2302482] | Positioning accuracy enhancement for commercial and IIoT use cases | ||||||
OPPO [R1-2302545] | AI/ML-based solutions for various areas (e.g., computer vision, NLP) | Positioning accuracy enhancement | |||||
Spreadtrum Communications [R1-2302597] | Positioning accuracy enhancement using AI/ML for Air interface | ||||||
Nokia, Nokia Shanghai Bell [R1-2302633] | ML for positioning accuracy enhancement in NR air interface | ||||||
CATT [R1-2302700] | Potential spec impacts for AI/ML-based positioning enhancement | ||||||
Baicells [R1-2302739] | Data collection for AI/ML model training in supervised learning | Positioning accuracy enhancement using AI-ML | |||||
Sony [R1-2302844] | AI-ML for positioning accuracy enhancement in air interface | ||||||
Fujitsu [R1-2302909] | Specification impacts for AI/ML positioning | Two granularities of sub-use cases for AI/ML positioning | |||||
xiaomi [R1-2302980] | Data collection for AI-based positioning | Performance monitoring for AI-based positioning | AI/ML-based positioning accuracy enhancement | ||||
Google [R1-2303055] | AI/ML-based positioning enhancements | ||||||
Samsung [R1-2303125] | Representative sub-use cases for Positioning | ||||||
CAICT [R1-2303188] | AI/ML for positioning accuracy enhancement | ||||||
CMCC [R1-2303229] | AI/ML for positioning accuracy enhancement | ||||||
MediaTek Inc. [R1-2303341] | Sub-use cases and positioning methods | Corresponding spec impact for AI/ML-based positioning enhancement | |||||
Fraunhofer IIS, Fraunhofer HHI [R1-2303413] | Model monitoring for AI/ML solutions | Potential specification impact for AI/ML positioning | Selection of sub-use cases for AI/ML positioning | Model considerations for AI/ML positioning | |||
NVIDIA [R1-2303440] | AI and ML for positioning enhancement in 5G Advanced evolution | ||||||
InterDigital, Inc. [R1-2303451] | Designs and potential specification impacts of AI/ML for positioning | ||||||
Apple [R1-2303480] | AI/ML for positioning accuracy enhancement in different scenarios (e.g., heavy NLOS conditions) | ||||||
Lenovo [R1-2303529] | AI/ML positioning use cases | Associated impacts for AI/ML positioning | |||||
Qualcomm Incorporated [R1-2303587] | AI/ML for positioning accuracy enhancement | ||||||
NEC [R1-2303675] | AI/ML for positioning accuracy enhancement in air interface | ||||||
NTT DOCOMO, INC. [R1-2303709] | AI/ML for positioning accuracy enhancement in NR air interface |
Entity | Concept 1: NR Duplex Operation | Concept 2: SLS Calibration Results | Concept 3: SBFD | Concept 4: TR 38.858 | Concept 5: TSG Approval | Concept 6: Document Versioning | Concept 7: RAN Plenary Meetings | Concept 8: Working Groups |
---|---|---|---|---|---|---|---|---|
CMCC | Evolution study, TR 38.858 v0.4.0, TSG produced [R1-2303230] | Updated summary, NR duplex evolution, R1-2303231, discussion [R1-2303231] | - | Authorship, v0.4.0, study on NR duplex evolution [R1-2303230] | Subject to TSG approval, possible changes, change control [R1-2303230] | Version x.y.z, first digit for TSG info/approval, change control [R1-2303230] | RAN plenary #94-e approval, RAN plenary #97 SID update [R1-2303231] | 3GPP TSG RAN WG1, R1-2303230, R1-2303231 documents [R1-2303230, R1-2303231] |
CATT | - | - | TP on SBFD, R1-2303639, TR 38.858 endorsement [R1-2303639] | Co-authorship, TP for TR 38.858, R1-2303639 [R1-2303639] | - | - | - | 3GPP TSG RAN WG1, R1-2303639 document [R1-2303639] |
Samsung | - | - | TP on SBFD, R1-2303639, TR 38.858 endorsement [R1-2303639] | Co-authorship, TP for TR 38.858, R1-2303639 [R1-2303639] | - | - | - | 3GPP TSG RAN WG1, R1-2303639 document [R1-2303639] |
Entity | Evaluation Methodologies and Assumptions (R1-2302347) | Deployment Scenarios (R1-2302483) | Channel Model, Interference Model, Traffic Model (R1-2302598) | Performance Metrics (R1-2302735) | Subband Full Duplexing (SBFD) (R1-2303015) | Time Division Duplexing (TDD) (R1-2303261) | System Level Evaluation (R1-2303458) |
---|---|---|---|---|---|---|---|
Huawei, HiSilicon | Evolution of NR duplex operation, RAN1#112 progress (R1-2302347) | ||||||
New H3C Technologies Co., Ltd. | Rel.18 NR duplex evolution discussion, RAN1 #112 meeting (R1-2302427) | ||||||
vivo | NR full duplex evaluation, RAN1#112 meeting agreements (R1-2302483) | ||||||
InterDigital, Inc. | Rel-18 study item, NR duplex operation objectives (R1-2302521) | ||||||
OPPO | NR duplex evaluation assumptions, past meetings (R1-2302546) | ||||||
Spreadtrum Communications, BUPT, New H3C | Deployment scenarios, evaluation methodology for duplex enhancement (R1-2302598) | ||||||
CATT | Consensuses on NR duplex evolution, RAN1#112 meeting (R1-2302701) | ||||||
MediaTek Inc. | SBFD evaluation compared to legacy TDD, RAN#94e study item (R1-2302735) | ||||||
ZTE | SBFD prototype and preliminary simulation results, RAN#95 meeting endorsed SID (R1-2302756) | ||||||
Ericsson | Rel-18 study item objectives, SBFD and dynamic TDD evaluation (R1-2302769) | ||||||
Intel Corporation | 3GPP TSG RAN Meeting #94 SID approval, NR duplex operation evolution (R1-2302794) | ||||||
xiaomi | Remaining issues for SLS and LLS, RAN1#112 meeting discussion (R1-2302981) | ||||||
Nokia, Nokia Shanghai Bell | SBFD simulation results, case 1, FR1 Urban Macro, FR1 Dense Urban Macro layer, FR1 and FR2-1 Indoor Office scenarios (R1-2303015) | ||||||
Samsung | RAN#94-e endorsed SID, "Study on evolution of NR duplex operation" (R1-2303126) | ||||||
CMCC | Comprehensive SLS evaluation methodology, RAN1#112 meeting (R1-2303232) | ||||||
Panasonic | SLS calibration results, Urban Macro (FR1) and Dense Urban Macro Layer (FR2-1) (R1-2303261) | ||||||
Sharp | Initial system level evaluation results, Case 1 with Indoor office scenario, RAN1 agreements (R1-2303458) | ||||||
Apple | Study on Evolution of NR Duplex Operation, RAN#94 e-meeting, evaluation scenarios, and assumptions (R1-2303481) | ||||||
Qualcomm Incorporated | Deployment scenarios, evaluation methodology for NR duplex evolution, RAN plenary #94e SID approval (R1-2303588) | ||||||
NTT DOCOMO, INC. | RAN#94e meeting approved SID, "Study on evolution of NR duplex operation" (R1-2303710) | ||||||
ZTE (revised) | SBFD Prototype and Preliminary Simulation Results, RAN#95 endorsed SID (R1-2303892) |
Entity | Subband Configuration | UL/DL Resource Allocation | UE-UE CLI Mitigation | Collision Handling | SBFD Operation | Frequency Domain Allocation | Performance Analysis | Legacy Operation Impact | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Huawei, HiSilicon [R1-2302348] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TCL Communication Ltd. [R1-2302407] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New H3C Technologies Co., Ltd. [R1-2302426] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
vivo [R1-2302484] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
InterDigital, Inc. [R1-2302522] | UL and DL resource allocations | UE-to-UE CLI mitigation | Collision handling | SBFD operations | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
OPPO [R1-2302547] | Subband non-overlapping full duplex | Performance, implementation complexity, switching latency comparison | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Spreadtrum Communications [R1-2302599] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CATT [R1-2302702] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MediaTek Inc. [R1-2302736] | BWP configuration in SBFD | Downlink and uplink frequency domain resource allocation | UE-UE CLI measurement enhancements | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NEC [R1-2302746] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ZTE [R1-2302757] | Subband non-overlapping full duplex | Feasibility and impact analysis | Legacy operation impact | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ericsson [R1-2302770] | Subband non-overlapping full duplex | Impact on legacy operation | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Intel Corporation [R1-2302795] | SBFD operation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sony [R1-2302845] | Subband full duplex TDD operations | Performance, implementation complexity, switching latency comparison | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Fujitsu [R1-2302910] | Subband indication | Subband non-overlapping full duplex | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
xiaomi [R1-2302982] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Nokia, Nokia Shanghai Bell [R1-2303016] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Samsung [R1-2303127] | SBFD for NR duplex evolution | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ETRI [R1-2303197] | UL/DL subband configuration and indication | SBFD enhancements | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CMCC [R1-2303233] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Panasonic [R1-2303262] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CEWiT [R1-2303303] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
FGI [R1-2303408] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sharp [R1-2303459] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Apple [R1-2303482] | Subband non-overlapping full duplex | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Lenovo [R1-2303530] | Subband non-overlapping full duplex | Performance, implementation complexity, switching latency comparison | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Qualcomm Incorporated [R1-2303589] | Subband
TDoc comparison: R1-2303459 (Sharp) R1-2303482 (Apple) R1-2303589 (Qualcomm Incorporated) R1-2303742 (LG Electronics) TDoc R1-2303459: - Proposes three alternatives for enhancement to configured PUSCH, including a common frequency resource allocation for each symbol type, different frequency resource allocations for each symbol type, and restricting configured PUSCH transmission to only one symbol type. - Observes that for SBFD-aware UEs, there is no difference in implementation complexity between Option 1 and Option 2 in terms of RF filtering adaptation aspect, assuming RAN4 decided that RF filtering bandwidth adaptation to SBFD subbands is not required. - Notes that Alt.3 solves the uplink resource fragmentation issue. TDoc R1-2303482: - Agrees to further study whether a slot can consist of both SBFD and non-SBFD symbols and considers benefits, use cases, scheduling flexibility, implementation complexity, and compatibility with legacy TDD DL/UL configuration. - Believes that collisions between UE behavior in non-SBFD and SBFD symbols should be limited to scenarios where at least one resource is a higher configured resource (e.g. SPS, CSI-RS). - Suggests that a UE can be configured with a single CSI-RS resource, with configuration parameters potentially applicable to both legacy TDD and SBFD symbols. - Proposes scheduling the PUSCH for aggressor UE through DCI indication. TDoc R1-2303589: - Suggests that a UE has enough information to handle CORESET in SBFD symbols, given that the frequency resources of the CORESET and UL/DL subbands are based on semi-static configuration. - Considers whether RO in SBFD symbols can be used for only SBFD-aware Inter-UE CLI (SBFD specific). - Notes that common solutions for inter-UE CLIR for SBFD and dynamic/flexible TDD should be discussed in agenda 9.3.3, while SBFD specific schemes for both inter-UE and inter-gNB CLI should be handled at AI 9.3.2. - Highlights the potential for utilizing spatial Tx/Rx beamform nulling in massive deployment to provide self-interference and clutter mitigation. TDoc R1-2303742: - Provides an example of slot composition for SBFD operation and non-SBFD operation in TDD-UL-DL-ConfigCommon, where a slot can consist of DL, gap symbol, and UL, and gNB with SBFD capability may operate SBFD in symbols used as DL. - Suggests that if the frequency resources assigned for UL subband and guard band are considered as a rate-matched resource within contiguous DL resources, wideband precoder with non-contiguous DL subbands can be assumed for PRB bundling for SBFD symbol. - Proposes an alternative where UE can determine the frequency location where reception for DL signal/channel is permitted. Example snippets from the original TDocs include: - Observation 1: For SBFD-aware UEs, for a symbol configured as DL in TDD-UL-DL-ConfigCommon, difference in implementation complexity in terms of RF filtering adaptation aspect among Option 1 and Option 2 is not observed in a case that RAN4 decided that RF filtering bandwidth adaptation to SBFD subbands are not required. (TDoc R1-2303459) - In our view, such collision should be limited to the scenarios that at least one of the resources is a higher configured resource, e.g. a SPS, CSI-RS etc for DL or UL-CG, periodic PUCCH, periodic SRS, ETC FOR UL. (TDoc R1-2303482) - In massive deployment, the large number of digital and analog degrees of freedom can be utilized to provide spatial Tx/Rx beamform nulling for self-interference and clutter mitigation. (TDoc R1-2303589) - If a slot is configured as flexible in TDD-UL-DL-ConfigCommon, it would be possible that the slot can consist of DL, gap symbol and UL, similar with special slot in LTE TDD, and that gNB with capability of SBFD operation may operates SBFD in the symbols used as DL. (TDoc R1-2303742) TDoc comparison: R1-2303530 (Lenovo) R1-2303711 (NTT DOCOMO, INC.) R1-2303825 (ASUSTEK COMPUTER (SHANGHAI)) R1-2303830 (WILUS Inc.) Proposal 13: Allows for the reuse of PUCCH resources across SBFD and non-SBFD symbols/slots, as long as the resource is within the frequency range of the UL subband. Example snippet: "the PUCCH resources configured for the active BWP can be reused in case the resources is within the frequency range of the UL subband." Option 2: Allows for separate frequency domain resources to be determined for PUSCH transmissions of PUSCH repetition type A or TBoMS at SBFD and non-SBFD symbols/slots, with the frequency domain resource for SBFD symbol/slot restricted to within the UL subband. Example snippet: "Two different frequency domain resource could be determined separately for the PUSCH transmissions of PUSCH repetition type A or TBoMS at SBFD and non-SBFD symbols/slots with the frequency domain resource for SBFD symbol/slot restricted to within the UL subband." Proposal 8: Supports non-equal consecutive PRBs in each PRG for SBFD-aware UEs and PRGs that overlap with subband boundary, providing higher resource utilization efficiency compared to option 1. Example snippet: "the actual number of consecutive PRBs in each PRG can be one or more and not always equal to the configured precoding granularity." Proposal 7: Studies potential enhancements to support UL transmissions and DL receptions across SBFD and non-SBFD symbols/slots. Separate parameters for transmissions/receptions on SBFD symbols and non-SBFD symbols may be beneficial with option 2. Example snippet: "when the transmissions/receptions across SBFD and non-SBFD symbols, separate parameters (e.g. FDRA, FH, power control, etc.) for transmissions/receptions on SBFD symbols and on non-SBFD symbols may be beneficial." TDoc R1-2303825: Considers whether signalling of guardbands is needed, and whether the symbol can be converted to a DL-only symbol. DL receptions within DL subbands are allowed in the symbol for both options. Example snippet: "DL receptions within DL subband(s) are allowed in the symbol." TDoc R1-2303830: Allows for RBs outside UL subband in a symbol configured as flexible in TDD-UL-DL-ConfigCommon to be used as either UL or DL excluding guardbands, according to option 2. Example snippet: "RBs outside UL subband in a symbol configured as flexible in TDD-UL-DL-ConfigCommon can be used as either UL, or DL excluding guardband(s) according to the Option 2 in the agreement at RAN1#111 meeting." TDoc comparison: R1-2302910 (Fujitsu) R1-2303016 (Nokia, Nokia Shanghai Bell) R1-2303127 (Samsung) R1-2303303 (CEWiT) - TDoc R1-2302910 proposes a symbol level configuration for SBFD symbols to be compatible with legacy TDD DL/UL configurations, but this increases implementation complexity. For cell-common resource configuration, transmission direction collision can occur between SBFD aware UE and legacy UE, and the scheduler should avoid it. The scheduler should also avoid densely configuring non-contiguous SBFD symbols to prevent wasting time domain resources. For UE-specific resource configuration, the scheduler should consider collisions between SBFD aware UEs and legacy UEs. The signal for indication should include bandwidth and location information. Example snippet: "The scheduler should carefully configure the SBFD symbols not to occur the densely configured with non-contiguous SBFD symbols (i.e., frequent change between UL subband and other symbols) since it causes wasting the time domain resources due to the fact that every UL subband essentially requires the guard period." - TDoc R1-2303016 suggests that UEs measuring and reporting their own leakage on a specific subband could be useful in SBFD and dynamic TDD. UEs with persistent scheduling might not be aware of changes in dynamically scheduled symbols, potentially causing interference or considering a different set of resources for CSI-RS measurements. For semi-static configuration of subband frequency location, the frequency location of DL or UL subband is with reference to the common resource block (CRB) grid. Example snippet: "only the UEs that are dynamically scheduled in that symbol would be aware of the change, and other UEs with a persistent scheduling (for UL transmission, or periodic DL receptions, such as CSI-RS) might not be aware of it, potentially causing interference or considering a different set of resources for the CSI-RS measurements." - TDoc R1-2303127 notes that using SBFD antenna configuration Option 1 could make it difficult to adjust DL EPRE across non-SBFD and SBFD symbols of the same allocation. One solution is to introduce separately configured RB offset values for PUSCH and PUCCH frequency hopping for SBFD aware UEs. Different CSI-RS may also be needed for SBFD operation in TDD networks. Example snippet: "One solution with low design impact and specification effort is to introduce one or two separately configured RB offset values for PUSCH and PUCCH frequency hopping for the SBFD aware UEs such that the hops in the normal UL slot can be shifted outside the UL subband subject to the UE UL BWP configuration (Options 2a/2b in Figure 10)." - TDoc R1-2303303 suggests that DL BWPs allocated to UEs can overlap with the UL SB and cause unnecessary monitoring at the UE. The proposal is to support explicit indication of SBFD configuration to the UE, including UL SB, SBFD active time resource, and priority level to enable or skip UL SB operation. The indication can also configure the SBFD operation for a set of time resources. Example snippet: "If BWP of a UE is overlapping with the subband for SBFD operation, then SBFD operation can create conflicts with signals configured for the UE in the overlapping portion. Further, the explicit indication helps is conflict resolution by setting the priority level for the indication." 3GPP-R1-112-bis-e Agenda Item 9.4.1.2 : Physical channel design framework
TDoc comparison: R1-2302290 (Nokia, Nokia Shanghai Bell) R1-2302325 (FUTUREWEI) R1-2302354 (Huawei, HiSilicon) R1-2302487 (vivo) R1-2302550 (OPPO) R1-2302602 (Spreadtrum Communications) R1-2302705 (CATT, GOHIGH) R1-2302798 (Intel Corporation) R1-2302923 (LG Electronics) R1-2302985 (xiaomi) R1-2303130 (Samsung) R1-2303199 (ETRI) R1-2303236 (CMCC) R1-2303368 (MediaTek Inc.) R1-2303375 (Transsion Holdings) R1-2303401 (ZTE, Sanechips) • TDoc R1-2302290: For the mapping between subchannel and PRBs in SL-U, there can be “remaining PRBs” after the mapping either due to the total number of PRBs in the RP that cannot be divided by the configured subchannel size or due to the PRBs of subchannel are overlapped with the configured Guard Band PRBs between RB sets. In addition, configurations on additional PSFCH resources can increase the successful probability of HARQ feedback. • TDoc R1-2302325: The objective on sidelink in unlicensed spectrum is to study and specify support of sidelink on unlicensed spectrum for both mode 1 and mode 2 where Uu operation for mode 1 is limited to licensed spectrum only. Channel access mechanisms from NR-U shall be reused for sidelink unlicensed operation. • TDoc R1-2302354: PRBs within intra-cell guard band of two adjacent RB sets are not used for PSFCH/S-SSB transmission. Moreover, the duration for decoding 1st stage SCI is a number of slots depending on SCS. • TDoc R1-2302487: The required spec efforts are acceptable to support the communication between different UEs capable of TDoc comparison: R1-2303324 (Ericsson) R1-2303539 (Fraunhofer HHI, Fraunhofer IIS) - TDoc R1-2303324 proposes the need for Tx UE to receive the radio access capability of the Rx UE and configure logical channels accordingly, whereas the set of channels is determined from the Rx UE capability information. Example snippet from the original TDoc: "Furthermore, to enable communication between UEs with different bandwidth capabilities, it is important that the Tx UE receives the radio access capability of the Rx UE (in a unicast pair) and configures the logical channels associated with the Rx UE with a set of channels, whereas the set of channels is determined from the Rx UE capability information." - TDoc R1-2303324 discusses AGC symbol design with multiple starting positions in a slot, motivated by the need to adjust the AGC loop to an unknown RX power that may greatly vary in every slot depending on the distance(s) between the TX UE(s) and the RX UE. Example snippet from the original TDoc: "The presence of an AGC symbol in SL is motivated by the need at the RX UE side to adjust the AGC loop to an unknown RX power that may greatly vary in every slot depending on the distance(s) between the TX UE(s) and the RX UE." - TDoc R1-2303324 does not recommend having a predefined channel for S-SSB transmission as it would result in asymmetric utilization of the channel. Example snippet from the original TDoc: "In our view, having a predefined channel for S-SSB transmission (and potentially many other pieces of signalling) is not desirable as it would result in an asymmetric utilization of the channel." - TDoc R1-2303324 introduces SCI, which indicates the number of PSFCH occasions to acknowledge a PSCCH/PSSCH. Example snippet from the original TDoc: "SCI indicates the number of PSFCH occasions to acknowledge a PSCCH/PSSCH." - TDoc R1-2303539 discusses the incorporation of interlaced resources in SL-U for the transmission of PSCCH and PSSCH, noting that a single resource pool does not necessarily span the entire frequency of the SL BWP. Example snippet from the original TDoc: "In order to use the concept of interlaced resources in SL-U for the transmission of PSCCH and PSSCH, it has to incorporate the fact that multiple resource pools are defined within a SL BWP, and a single resource pool does not necessarily span the entire frequency of the BWP." - TDoc R1-2303539 highlights the challenge of fixed slot structures and well-defined slot boundaries for Rel-16/17 sidelink UEs carrying out sensing and identifying the location of the PSCCH for decoding control information. Example snippet from the original TDoc: "The main challenge here is that Rel-16/17 sidelink UEs that carry out sensing rely on fixed slot structures and well-defined slot boundaries in order to identify the location of the PSCCH so as to decode the control information." - TDoc R1-2303539 notes that higher layer configurations are used to determine the exact resources used for a transmission based on the way interlaces are configured in NR-U. Example snippet from the original TDoc: "Based on the way interlaces are configured in NR-U, higher layer configurations are used to determine the exact resources used for a transmission." TDoc comparison: R1-2303314 (Lenovo) R1-2303769 (Sharp) R1-2303820 (ITL) R1-2303833 (WILUS Inc.) Technical Differences among TDocs: [TDoc R1-2303314]: - COT structure includes remaining channel duration, CAPC or logical channel priority value, over-riding configuration to override gap symbol, AGC symbol, and PSFCH symbol, and dedicated configuration for placement location of gap symbol and CP-Ext symbol. - Proposal 1: RAN1 should discuss how to use remaining PRBs in RB set. - Proposal 2: Support PSFCH interlace design containing L PSFCH interlace equals one PSCCH/PSSCH subchannel, placement of common interlace, and content to be transmitted in common interlace. - Proposal 3: 2 RB-based interlaces specified for subcarrier spacing of 60kHz for sidelink transmission in FR1 unlicensed spectrum. [TDoc R1-2303769]: - Proposal 5: Enhance R16 NR-SL time resource assignment to support more than 3 slot consecutive transmission for multi-consecutive slots transmission in SL-U. - TBS determination impacted by REs used for two (re)transmissions of a TB, RBs in intra-cell guard-band, and S-SSB transmission. - Alt: S-SSB transmission can be considered short and temporary, exempting OCB requirement. [TDoc R1-2303820]: - Proposal 3: Indicate by SCI whether AGC/Gap symbols on two adjacent slots present for SL data transmission or not when MCSt is scheduled. - TBS determination made with working assumption regarding 2 candidate starting symbols for PSCCH/PSSCH transmission. - Proposal 4: Confirm working assumption for TBS determination in SL-U. [TDoc R1-2303833]: - RB-based interlaced PSFCH design should consider PRBs in multiple RB sets for PSFCH transmission. - Proposal 2: Determine whether to use PRBs within intra-cell guard band of two adjacent RB sets for S-SSB and/or PSFCH transmission. - Additional candidate S-SSB occasions not included in resource pool for SL PSCCH/PSSCH transmission resources. Example snippets from original TDocs: - "The frequency domain location of DMRS should be designed based on interlace-based structure." (TDoc R1-2303314) - "Due to the reuse of sub-channel mapping in legacy SL, there may be a case that one or more RBs of the lowest sub-channel in the lowest RB set are in an intra-cell guard-band, and are not suitable for PSCCH transmission." (TDoc R1-2303769) - "The proper number of reference symbols in a slot can be configured for the TBS determination, which has different purposes and usages from the current existing RRC parameters (e.g., sl-LengthSymbols)." (TDoc R1-2303820) - "After conclusion of the method regarding the transmission of S-SSB within the RB set to satisfy OCB and PSD, it may be desirable to determine whether to use PRBs within intra-cell guard band of two adjacent RB sets." (TDoc R1-2303833) TDoc comparison: R1-2302520 (National Spectrum Consortium) R1-2302848 (Sony) R1-2302952 (InterDigital, Inc.) R1-2303169 (Panasonic) - TDoc R1-2302520 proposes two options for S-PSS/S-SSS/PSBCH transmission: using interlaced RB transmission for all or transmitting them N times by repetition in frequency domain with a gap to meet OCB requirement. Option 1-1 is not preferred due to its impact on legacy S-SSB acquisition implementation and lack of precedent in NR-U, while Option 3-1 has a PAPR problem but is simpler if temporary OBW relaxation allowance and multiplexing by scheduling are insufficient. - TDoc R1-2302848 discusses four options to meet OCB and PSD requirement for S-SSB transmission in SL-U: interlaced RB transmission, S-SSB multiplexing with other SL transmissions in the same slot, repetition of S-PSS/S-SSS/PSBCH in frequency domain, and S-PSS/S-SSS/PSBCH with wider bandwidth. SSB can be multiplexed with other DL transmissions in NR-U, but in SL transmission, S-SSB multiplexing with other SL channels in frequency domain is not beneficial due to half-duplex restrictions. - TDoc R1-2302952 suggests that supporting S-SSB transmission on multiple RB sets can help keep the COT after S-SSB slots and avoid starting LBT type 1 to transmit in the subsequent slots. It proposes two alternatives for PSFCH transmission: resources can be (pre-)configured or dynamically indicated, and a combination of these alternatives is possible. - TDoc R1-2303169 proposes a combination of four options for additional candidate S-SSB occasions and Alt 1 to improve resource utilization, and suggests that slots configured for additional S-SSB could also be used for PSCCH/PSSCH transmission when no additional S-SSB is transmitted. - Interlaced mapping was introduced for NR-U PUSCH/PUCCH to meet OCB regulation and maximize the transmission power with satisfying maximum mean e.i.r.p. density. - For frequency domain, both sub-channel index(s) and RB set index(s) should be indicated to identify the subchannel location. Example snippets from the original TDocs: - TDoc R1-2302520: "Option 3-1 has a PAPR problem but is the simpler approach if temporary OBW relaxation allowance and multiplexing by scheduling are not sufficient" - TDoc R1-2302848: "SSB can be multiplexed with other DL transmissions including DL signals, e.g. CSI-RS, and DL channels, e.g. PDCCH/PDSCH to meet OCB and PSD requirement for SSB in NR-U" - TDoc R1-2302952: "Instead, supporting S-SSB transmission on multiple RB sets can help keeping the COT after S-SSB slots and avoiding starting LBT type 1 to transmit in the subsequent slots" - TDoc R1-2303169: "Proposal 7: The legacy PSFCH and additional PSFCH should be located on same symbols and PSFCH occasion(s) are (pre-)configured" 3GPP-R1-112-bis-e Agenda Item 9.5.1.2 : Measurements and reporting for SL positioning
TDoc comparison: R1-2302294 (Nokia, Nokia Shanghai Bell) R1-2302327 (FUTUREWEI) R1-2302378 (Huawei, HiSilicon) R1-2302491 (vivo) R1-2302554 (OPPO) R1-2302606 (Spreadtrum Communications) R1-2302709 (CATT, GOHIGH) R1-2302802 (Intel Corporation) R1-2302852 (Sony) R1-2302927 (LG Electronics) R1-2303134 (Samsung) R1-2303264 (Lenovo) R1-2303277 (ZTE) R1-2303307 (CEWiT) - The anchor UE may indicate the need for switching between single-sided RTT and double-sided SL RTT based on measurement error expectations. - The target UE needs to report used ARP/panel information to transmit SL PRS for angle measurement. - SL positioning measurement can be used for method selection or to compute corrections. - SL PRS-RSRP is defined as the linear average over power contributions of resource elements carrying SL PRS reference signals. - The reference point for SL PRS-RSRP in frequency range 1 is the antenna connector of the UE. - Alt 1 is proposed for SL-SRS to cope with changing subframe timing. - SL-PRS transmission between anchor UEs can reduce synchronization error impact. - Hybrid positioning methods combining SL and Uu measurements can improve accuracy. - SL Rx-Tx measurements are defined as actual reception and transmission times for alignment with double-sided RTT. - AdditionalPathList can be included in a sidelink positioning report. - SL AoA measurement report reuses UL-AoA definition. - A single measurement report between reference and target UEs is insufficient for SL-only absolute positioning. - Latency control is important for minimizing the impact of clock drift and UE movement in RTT measurement. - The Rx-Tx difference time reporting range can be 1msec. - The report structure in TS 38.455 can be reused for SL measurement report. - SL PRS-RSRP reference point in frequency range 1 is the antenna connector of the UE. - Anchor UEs should be allowed to receive SL-PRS from each other for synchronization error estimation and calibration. - LCS may suffice for SL-AoA computed for relative direction/orientation. - The presence of time stamp, timing quality, and SL PRS identification information should be mandatory in SL measurement report. TDoc comparison: R1-2302989 (xiaomi) R1-2303064 (Sharp) R1-2303240 (CMCC) R1-2303596 (Qualcomm Incorporated) Summary of Technical Differences Among TDocs on Sidelink Positioning: - TDoc R1-2302989: This TDoc discusses the collection of measurement report content for in coverage RRC connected UEs and UEs out of coverage. The SL measurement report can be provided to LMF for in coverage UEs to calculate the target UE position, while out of coverage UEs provide the measurement report to the SL positioning server UE to calculate ranging/positioning results. The duration of SL synchronization source measurement could be longer than the duration of SL-PRS transmission. Proposal 5 suggests that the sidelink positioning measurement report is transmitted in the same way as UE data, and a definition similar to DL RSTD can be considered. - TDoc R1-2303064: This TDoc highlights the priority of the SL positioning measurement report based on the priority of the measured SL-PRS to match the desired priority of the positioning service for which the SL-PRS and corresponding measurement reports are transmitted. The SL-PRS resource set is not considered for SL-PRS resource allocation/reservation. - TDoc R1-2303240: This TDoc discusses the high-level agreements on measurement reporting achieved during the last RAN1 meeting. UE-based and UE-/RAN-assisted positioning were specified for NR positioning, where the target UE itself calculates the location for UE-based positioning, and UE and/or gNB report measurements to LMF for UE-/RAN-assisted positioning. Proposal 11 discusses whether UE-based positioning is applicable to UL-like SL absolute positioning methods such as UL-like SL TDOA and SL AoA, and if supported, the corresponding measurement reporting from anchor UEs to the target UE should be further discussed. - TDoc R1-2303596: This TDoc notes that a mix of releases and device generations can be supported in the same resource pool, and UEs can discard reports and requests for unsupported or unknown methods. - TDoc R1-2303064: This TDoc discusses the time-domain behavior of the measurement report and the layer used to report it. A measurement report requires significant computations on the UE side, and the measuring process itself has processing time comparable or longer than that required to process lower layer signals. The report should contain identification information for the resource pool where SL-PRS is received, in addition to any source, destination, and session identifiers. Differentiating the different SL-PRS transmissions for measurements and reports is important when double-sided RTT transmissions without order are supported. Examples from the original TDocs: - TDoc R1-2302989: "However, the duration of SL synchronization source measurement could be much longer than the duration of SL-PRS transmission." - TDoc R1-2303064: "The SL-PRS resource set is not considered for SL-PRS resource allocation/reservation." - TDoc R1-2303240: "UE-based and UE-/RAN-assisted positioning were specified for NR positioning, where the target UE itself calculates the location for UE-based positioning, and UE and/or gNB report measurements to LMF for UE-/RAN-assisted positioning." - TDoc R1-2303596: "Ues can discard reports and requests for unsupported or unknown methods." - TDoc R1-2303064: "A measurement report requires significant computations on the UE side, and the measuring process itself has processing time comparable or longer than that required to process lower layer signals." TDoc comparison: R1-2303415 (Fraunhofer IIS, Fraunhofer HHI) R1-2303444 (InterDigital, Inc.) R1-2303551 (Ericsson) R1-2303842 (MediaTek (Chengdu) Inc.) - TDoc R1-2303415 proposes to consider successive Rx-Tx measurements in a single report and introduces a UE procedure to support double-sided RTT. It also includes enhancements for NLOS and critical LOS scenarios. The proposal suggests including information on the Tx periodicity and the measured Rx periodicity, which can be useful for frequency offset compensation. The double-sided RTT operation has no specific spec impact related to the order of transmission and the measurement accuracy of the relative frequency offset depends on the periodicity. Example snippet from the TDoc: "Beside the Tx-RX difference information on the Tx periodicity and the measured Rx periodicity (Tx-Tx delays and Rx-Rx delays or time stamps (with high resolution) for each measurement may be useful for mitigation of the frequency offset between two devices or other purposes." - TDoc R1-2303444 mentions that the relative movement of a target UE and/or reference anchor UE between the SL-PRS transmission and reception may cause errors, especially for high-speed vehicle UEs. The proposal suggests including information on SL-PRS resources, uncertainty information associated with each positioning method, and quality information or uncertainties associated with the reported measurements. It also proposes support for at least the following measurements for AoA positioning method: AoA, ZoA, RSRP, RSRPP. Example snippet from the TDoc: "Since a SL UE can obtain location information based on the methods of GNSS, Uu-based positioning, SL-based positioning, it can be useful to have uncertainty information associated with each described method." - TDoc R1-2303551 proposes measuring SL PRS-RSRPP in frequency range 2 based on the combined signal from antenna elements corresponding to a given receiver branch. It also suggests SL PRS based AoA/ZoA measurement and discusses the need for synchronization of SL reference timing for regular anchor UEs. Example snippet from the TDoc: "For frequency range 2, SL PRS-RSRPP shall be measured based on the combined signal from antenna elements corresponding to a given receiver branch." - TDoc R1-2303842 highlights the main difference between Alt 1 and Alt 3, which is that Alt 1 applies actual SL-PRS transmission timing, and Alt 3 applies the intended transmission closest in time to the reception timing. The proposal discusses the need for considering the actual transmission timing, which depends on the measurement combination. Example snippet from the TDoc: "In our view, the actual transmission timing depends on the measurement combination." Overall, these TDocs discuss various technical differences and proposals related to sidelink positioning, including enhancements for NLOS and critical LOS scenarios, frequency offset compensation, uncertainty information, synchronization of SL reference timing, and measurement combination. 3GPP-R1-112-bis-e Agenda Item 9.5.3 : LPHAP (Low Power High Accuracy Positioning)
TDoc comparison: R1-2302381 (Huawei, HiSilicon) R1-2302431 (Quectel) R1-2302494 (vivo) R1-2302609 (Spreadtrum Communications) R1-2302712 (CATT) R1-2302805 (Intel Corporation) R1-2302854 (Sony) R1-2302935 (Nokia, Nokia Shanghai Bell) R1-2302992 (xiaomi) - TDoc R1-2302381 proposes that Option 1a should be the only valid solution for the design of SRS spatial relation, and UE should perform Tx beam sweeping for the purpose SRS transmission in the SRS positioning validity area. It also proposes that for the power control of positioning SRS in multiple cells, support Option 2: Pathloss RS is provided in the configuration. - Example snippet: "Therefore, we think Option 1a should be the only valid solution for the design of SRS spatial relation..." - TDoc R1-2302431 proposes that sequence ID in SRS configuration should be configured commonly across cells. It also states that spatial relation information of SRS is UE location dependent. - Example snippet: "Proposal 1: Sequence Id in SRS configuration should be configured commonly across cells. If the max number of SSB indexes are equal and the relation between SSB indexes and Tx directions are the same among the camping cell and neighbour cells, only one set of relation is informed to UE." - TDoc R1-2302494 proposes that for the UL timing advance to transmit SRS for positioning within the SRS positioning validity area, it is feasible for UE to autonomously adjust the TA (Option 2) based on old cell TA and RSTD measurement from SSB of new cell and old cell. It also proposes that Option 1a should be supported for TA validation. - Example snippet: "For the UL timing advance to transmit SRS for positioning within the SRS positioning validity area, Option 2 combined with the conclusion of UE-based TA measurement in Rel-18 Mobility Enhancement WI should be supported..." - TDoc R1-2302609 proposes three options for managing UL interference: UE maintains the TA obtained from the last serving cell within the validity area (Option 1), UE autonomously adjusts the TA (Option 2), or UE maintains multiple TA values (Option 3). It also states that the spatial relation information needs to be updated when UE moves and/or performs cell reselection. - Example snippet: "Option 1: UE maintains the TA obtained from the last serving cell within the validity area" - TDoc R1-2302712 proposes introducing a new RACH procedure for a UE to obtain SRS-Pos configurations. It also suggests that if multiple cells within the validity area coordinate to preserve the pre-configured SRS resources, the UL transmission interference can be avoided. - Example snippet: "Proposal 4: Support introducing a new RACH procedure for a UE to obtain SRS-Pos configurations..." - TDoc R1-2302805 proposes that interference issues due to the configuration of SRS across multiple cells within a validity area can be handled by gNB implementation. It also proposes that for option 1, the UE can use the SSB for camped cell PBCH decoding as the path loss reference signal. - Example snippet: "Proposal 3: Interference issues, if any, due to the configuration of SRS across multiple cells within a validity area can be handled by gNB implementation." - TDoc R1-2302935 proposes that when UE leaves the SRS valid cell, it can remain in the inactive state and use the similar method as the positioning report to require updated SRS configuration. It also suggests that the gNB may be able to provide the UE with multiple candidates of a spatial relation information for each SRS resource. - Example snippet: "For instance, when UE leaves the SRS valid cell, it can remain in the inactive state and use the similar method as the positioning report (e.g., via SDT) to require updated SRS configuration..." - TDoc R1-2302992 proposes Option 2 for determining the UL timing advance to transmit SRS for positioning by UEs in RRC_INACTIVE state within the SRS positioning validity area, which is to have spatial relation information provided in the configuration. It also suggests further studying how the UE adjusts the TA. - Example snippet: "Option 2: Spatial relation information is provided in the configuration" - TDoc R1-2302854 discusses multiple options for determining the UL timing advance value. It also proposes that after the paging reception, the UE performs RACH procedure in which the timing advance acquiring information can be used to validate the SRS configuration. - Example snippet: "In RAN1#112 meeting, it was discussed that for the determination of UL timing to transmit SRS for positioning by UEs in RRC_INACTIVE state within the SRS positioning validity area, there are multiple options on determining the UL timing advance value." TDoc comparison: R1-2303243 (CMCC) R1-2303554 (Ericsson) R1-2303599 (Qualcomm Incorporated) R1-2303676 (NEC) TDoc R1-2303243: - SRS parameters are independent of UE location. - Additional configurations for SRS positioning in RRC_INACTIVE state are conveyed in RRCRelease messages. - BWP information, TA timer, and RSRP change threshold are provided in addition to Rel-16 SRS positioning configurations. - The RS used to measure the increase/decrease of RSRP is the downlink pathloss reference RS. Example snippet: "The configuration of SRS positioning in Rel-16 contains the following parameters: SRS positioning resource set SRS positioning resource." TDoc R1-2303554: - SRS resource allocation to a UE across the validity area leads to low efficiency of resource usage. - Interference caused by over-use of the same SRS resources in multiple cells degrades the positioning accuracy. - Each cell within the validity area must assume the UE is using the SRS resource and allocate the SRS configuration in the cell, even when the UE is not present. Example snippet: "When the UE is not in the connected mode and preserves its SRS configuration across a validity area, to maintain an acceptable level of interference, each cell within the validity area must assume the UE is using the SRS resource and allocate the SRS configuration in the cell, even when the UE is not present." TDoc R1-2303599: - The network can decide whether to configure a spatial relation/pathloss reference to a UE. - The UE could always use the QCL Type D of the strongest SSB from the camping cell as a default mode. - Network implementation can decide whether to use the same sequenceId for all SRS transmissions of a UE within the cells of an area. Example snippet: "We believe that it makes sense to allow the network to decide whether to configure a spatial relation / pathloss reference to a UE, since a different UE behavior may be expected in each case." TDoc R1-2303676: - SRS positioning validity areas are introduced to avoid frequent RRC connections for SRS (re)configuration. - Enhancement of TA timer mechanism is proposed to solve the issue of frequent RRC connections. - Power consumption implications of any solution must be considered and minimized for LPHAP device. Example snippet: "To effectively solve the issue of frequent RRC connection for SRS (re)configuration in scenarios where a positioning valid area is introduced, RAN should prioritize the enhancement of TA timer mechanism, especially for the outdoor scenario." TDoc comparison: R1-2303137 (Samsung) R1-2303280 (ZTE) R1-2303492 (Apple) R1-2303745 (LG Electronics) - TDoc R1-2303137 proposes the use of Option 2 for pathloss RS and an enhanced unified TCI state framework for power control of SRS in multiple cells. The UE can automatically provide the configuration for pathloss RS, and if it's not valid, the passloss can be calculated based on RS resources obtained from the last SSB measurement from the new camping cell. The UE can reuse the value of p0 and alpha if the SS-RSRP difference between the last serving cell and new camping cell is within a threshold; otherwise, the UE can request an updated value of p0 and/or alpha. - TDoc R1-2303280 introduces a method for PRS based positioning measurement in RRC_IDLE. The UE can select its spatial relation when camping on different cells in the SRS for positioning configuration validity area. If spatial relation is provided in the configuration, a spatial relation list can be included, and the UE can choose several reference signals from the configured spatial relation list as its spatial relation. The UE may calculate the parameter using a RS resource obtained from the SSB of the serving cell that the UE uses to obtain MIB. - TDoc R1-2303492 proposes supporting both Option 1 and Option 2 for the spatial relation of an SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state. If the TA is invalid, the UE obtains the TA using RACH. - TDoc R1-2303745 suggests reusing the existing mechanism for SRS configuration for multiple cells by providing the pathloss reference signal of Rel-17 SRS for positioning in the configuration. The pathloss RS is provided in the configuration for all or a subset of cells within the validity area. FFS details which pathloss RS is used at cells where pathloss RS is not provided in the configuration. - TDoc R1-2303137, R1-2303492, and R1-2303745 propose different variations of power control for SRS in multiple cells. TDoc R1-2303137 proposes reusing the value of p0 and alpha for the UE, while TDoc R1-2303745 suggests considering how to determine p0 and alpha value for SRS transmission power control. TDoc R1-2303492 suggests supporting different values of p0 and alpha for individual cells within the validity area. - TDoc R1-2303492 and R1-2303745 both propose supporting both Options 1 and 2 for the spatial relation of an SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state. TDoc R1-2303137 and R1-2303280 provide details on how the spatial relation is selected and used for PRS-based positioning measurement. - TDoc R1-2303137 proposes a method for determining the pathloss if the configured pathloss RS is not valid by using RS resources obtained from the last SSB measurement from the new camping cell. TDoc R1-2303492 suggests obtaining the TA using RACH if it's invalid. TDoc comparison: R1-2302330 (FUTUREWEI) R1-2303447 (InterDigital, Inc.) • TDoc R1-2302330 proposes two options for UE transmission of SRS for positioning resources, one using a fixed spatial domain transmission filter and the other with spatial relation configuration provided in the configuration. The pathloss reference parameters are specific to each gNB. Example: "UE transmits SRS for positioning resource(s) using a fixed spatial domain transmission filter (for FR1 UE only), or, Option 2: Spatial relation configuration is provided in the configuration." • Proposal 3 in TDoc R1-2302330 offers two options for power control of SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state, one with the pathloss RS absent in the configuration and the other with the pathloss RS provided in the configuration. Example: "Proposal 3: For the power control of an SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state, support Option 1: Pathloss RS is absent in the configuration, or Option 2: Pathloss RS is provided in the configuration." • TDoc R1-2303447 presents two options for providing pathloss RS configurations to the UE, one with the UE provided with pathloss RS configurations and the other with the UE determining pathloss RS autonomously. Example: "In Option 2, the UE is provided with the pathloss RS configurations based on which the UE can determine transmission power of SRSp. In Option 1, the UE is not provided with configuration for the pathloss RS and the UE needs to determine pathloss RS." • TDoc R1-2303447 notes that in Option 1, the network does not have knowledge of the newly determined TA value, which may cause dropped receptions of SRSp by the network. Whether the CN can handle the measurement reports from the UE in RRC_CONNECTED while the positioning measurement was performed in RRC_IDLE can be evaluated in the WI phase with SA2 involved. Example: "One potential shortcoming of the option is that the network does not have any knowledge of the newly determined TA value, which may cause dropped receptions of SRSp (SRS for positioning) by the network. Whether the CN can handle the measurement reports from the UE in RRC_CONNECTED, while the positioning measurement was performed in RRC_IDLE, can be evaluated in the WI phase with SA2 involved." • TDoc R1-2302330 notes that the spatial relation between the LPHAP UE and the serving gNB may change as the UE moves across different cells within the positioning validity area. Example: "As a result of UE moving across different cells within the positioning validity area, the spatial relation between the LPHAP UE and the serving gNB may be different from the newly selected gNB (or the camp-on cell) after cell reselection." In summary, the technical differences among the TDocs include options for UE transmission of SRS for positioning resources, power control of SRS for positioning configuration, and providing pathloss RS configurations to the UE. The spatial relation between the LPHAP UE and the serving gNB may also change as the UE moves across different cells within the positioning validity area. These differences offer various options for optimizing the positioning process for UEs and improving network efficiency. 3GPP-R1-112-bis-e Agenda Item 9.5.4 : Bandwidth aggregation for positioning measurements
TDoc comparison: R1-2302382 (Huawei, HiSilicon) R1-2302495 (vivo) R1-2302558 (OPPO) R1-2302610 (Spreadtrum Communications) R1-2302713 (CATT) R1-2302806 (Intel Corporation) R1-2302936 (Nokia, Nokia Shanghai Bell) R1-2302993 (Xiaomi) R1-2303138 (Samsung) R1-2303244 (CMCC) R1-2303267 (Lenovo) R1-2303281 (ZTE) - [TDoc R1-2302382]: Power control: To ensure the same Tx PSD across the aggregated carriers, only one set of power control parameters is configured for the aggregated SRS resources. Carrier aggregation for communication and bandwidth aggregation for positioning should be decoupled. UL-SRS bandwidth aggregation depends on communication carrier aggregation. - [TDoc R1-2302495]: For SRS bandwidth aggregation, SRS resource sets can be configured to associate with multiple cells or an indication of co-scheduling cells. Location request and reporting information includes PFL aggregation request/indication. - [TDoc R1-2302558]: Power control on SRS resources linked for bandwidth aggregation is enhanced to apply the same power per subcarrier to all linked SRS resources. Different SRS resources for positioning in the same set might be targeted to different cells through the configuration of spatial relation and pathloss RS. SRS Bandwidth Aggregation requires same subcarrier spacing, same cyclic prefix, same slot and symbol locations. - [TDoc R1-2302610]: SRS resource sets or resources from different carriers/PFLs can be configured to be linked. SRS carrier aggregation indication is reported along with the measurement results. - [TDoc R1-2302713]: Same Tx PSD is required for SRS bandwidth aggregation. SRS with RE-offset configuration maintains contiguous SRS pattern across aggregated bandwidths. - [TDoc R1-2302806]: Single DCI scheduling positioning SRS across linked carriers is studied. MIMO SRS can be supported for bandwidth aggregation. Relationship between UL communication CA and SRS bandwidth aggregation is studied. - [TDoc R1-2302936]: Joint measurement and report for SRS resources across aggregated carriers is supported. RSRP or RSRPP is reported individually for each carrier. - [TDoc R1-2302993]: Joint measurement and report for SRS resources across aggregated carriers is supported. UE needs to inform NW measurement results are obtained based on remaining PRS resource/set in reporting instance. - [TDoc R1-2303138]: Priority of aggregated SRS across CCs is determined. To enable PRS/SRS bandwidth aggregation, same periodicity, slot offset, number of resources, spatial relation information, pathloss RS, Po and alpha are required. - [TDoc R1-2303267]: Joint measurement and report for SRS resources across aggregated carriers is supported for UL-TDOA and Multi-RTT positioning methods. Carrier indication may be included in the report. - [TDoc R1-2303281]: On-demand PRS configuration can include group information for aggregation. Joint RSRP and RSRPP can be calculated based on equivalently larger bandwidth PRS. Example snippets: - "Therefore, positioning and communication are independent processes from the perspective of requirements and services, and thus carrier aggregation used for communication and bandwidth aggregation used for positioning should be decoupled" (TDoc R1-2302382) - "For SRS bandwidth aggregation, SRS resource set can be configured to associate the multiple cells or an indication of co-scheduling cells reusing the agreement" (TDoc R1-2302495) - "SRS Bandwidth Aggregation For two SRS resources for positioning that can be aggregated, the system shall configure the following same parameters" (TDoc R1-2302610) - "Single DCI scheduling positioning SRS across the linked carriers, and check whether the conclusion/agreements in agenda of multi-cell PUSCH/PDSCH scheduling with a single DCI can be reused" (TDoc R1-2302806) - "Joint measurement and report for the SRS resources across the aggregated carriers for UL-TDOA and Multi-RTT positioning methods" (TDoc R1-2302993) TDoc comparison: R1-2303201 (ETRI) R1-2303600 (Qualcomm Incorporated) R1-2303927 (Qualcomm Incorporated) - TDoc R1-2303201 introduces the concept of aggregated SRS resource transmission and its configuration for narrowband SRS. It also mentions the issue of unaligned PRB in some BWP and the need for additional offset, which affects inter-user multiplexing. Example snippet: "The aggregated SRS resource can be transmitted when all narrowband SRS are transmitted, and the UE is configured to apply the same spatial relation and the transmission timing for all narrowband SRS." - TDoc R1-2303600 proposes enhancements for location request and measurement report, including the inclusion of information on whether the UE should perform aggregated measurements or not in the LMF. It also suggests support for aperiodic SRS for positioning. Example snippet: "Support aperiodic SRS for positioning to be used for SRS BW aggregation, without however introducing any additional/further enhancement than what is already specified for the purpose of triggering the aperiodic SRS." - Proposal 14 (TDoc R1-2303927) reiterates the proposed enhancements for location request and measurement report from TDoc R1-2303600, including the inclusion of information on whether the UE should perform aggregated measurements or not in the LMF. It also suggests support for aperiodic SRS for positioning. Example snippet: "We believe that the LMF should include in the location information request message whether the UE should perform aggregated measurements or not, and not in the assistance data." TDoc comparison: R1-2303448 (InterDigital, Inc.) R1-2303493 (Apple) R1-2303555 (Ericsson) R1-2303746 (LG Electronics) [TDoc R1-2303448]: - Proposal 7: Automatic frequency layer aggregation of PRS when carrier aggregation for data communication is enabled, given association between Scells and PRS frequency layers. - Support for power measurement for aggregated PFLs as an optional measurement. Example snippet: "Thus, as optional measurement, the power measurement for aggregated PFLs should be supported" [TDoc R1-2303493]: - Use of the same NR-DL-PRS-SFN0-Offset to maintain contiguous PRS pattern across aggregated bandwidths even in the presence of guard tones. - Support for SRS bandwidth aggregation with the same periodicityAndOffset, slotOffset, and pathloss RS, Po, and alpha. Example snippet: "For SRS bandwidth aggregation, the following additional conditions should be satisfied: The same periodicityAndOffset, and slotOffset to simplify the design while satisfying the RAN4 study" [TDoc R1-2303555]: - Support for joint measurement and reporting based on aggregated PRSs. - Support for SRS bandwidth aggregation with contiguous SRS pattern across aggregated bandwidths and indication of Tx timing error difference with UE Tx TEG ID. Example snippet: "Support joint measurement and report for the PRS resources aggregated across the PFLs for DL-TDOA and multi-RTT positioning methods" [TDoc R1-2303746]: - Support for PFL aggregation indication in a measurement report for PRS measurement. - Configuration of sets of SRS resources for UE to transmit with a single Tx chain for SRS bandwidth aggregation. Example snippet: "Proposal 2: Support PFL aggregation indication in a measurement report to indicate whether/which PFLs are aggregated for the PRS measurement" 3GPP-R1-112-bis-e Agenda Item 9.5.5 : Positioning for RedCap UEs
TDoc comparison: R1-2302329 (FUTUREWEI) R1-2302383 (Huawei, HiSilicon) R1-2302496 (vivo) R1-2302559 (OPPO) R1-2302807 (Intel Corporation) R1-2302855 (Sony) TDocs R1-2302329, R1-2302383, R1-2302496, R1-2302559, R1-2302807, and R1-2302855 discuss technical differences in SRS frequency hopping for RedCap UE positioning. Some of the key differences are: - Instantaneous SRS bandwidth configuration for frequency-hopping RedCap UE: TDoc R1-2302329 explains that the instantaneous bandwidth corresponds to the maximum number of PRBs for a given SCS and hop switching time. It also notes that a smaller instantaneous bandwidth can increase the positioning measurement delay over the overall bandwidth. Example snippets from the TDoc include table 6, which provides an example of instantaneous SRS bandwidth configuration for frequency-hopping RedCap UE. - SRS Tx hopping for RedCap UEs in RRC_INACTIVE state: TDoc R1-2302383 discusses agreements on SRS transmission during Rel-17 RAN1#107-e for RRC_INACTIVE UE, as well as potential enhancements of pos-SRS configuration to achieve Tx frequency hopping within an SRS resource or across SRS resources. It also suggests decoupling pos-SRS configuration from the existing BWP configuration. Example snippets include the design of pos-SRS configuration for Tx frequency hopping and the agreement on switching time delay of the existing BWP switching mechanism. - Potential adaptive modification on the formulas of SRS resource mapping: TDoc R1-2302496 proposes potential adaptive modifications on the formulas of SRS resource mapping based on the framework of MIMO SRS frequency hopping and considers SRS for positioning hopping configurations. It also suggests using inter-slot repetition for a SRS resource to support inter-slot frequency hopping. Example snippets include the potential enhancements of pos-SRS configuration and the configuration of multiples ‘virtual BWPs’ for SRS frequency hopping. - Positioning support for RedCap UE: TDoc R1-2302559 focuses on the positioning support for RedCap UE and highlights the need for support of SRS frequency hopping across multiple BWPs with multiple SRS resources. It notes that the support of positioning for RedCap UE should not increase the cost of UEs. Example snippets include the R18 positioning SI and the evaluation of existing positioning methods for RedCap UEs. - Agreement for Positioning enhancements for RedCap UEs: TDoc R1-2302807 discusses agreements for UL SRS Tx and DL PRS Rx frequency hopping for RedCap UE positioning. It suggests that short switching time may be beneficial in terms of accuracy and latency performance and that periodic, semi-persistent and aperiodic SRS transmission can be supported for SRS for positioning with frequency hopping for RedCap. Example snippets include the reuse of existing signalling mechanisms and the configuration of SRS resource set within a carrier. - The configurability of hopping parameters: TDoc R1-2302855 discusses the configurability of hopping parameters for SRS frequency hopping and notes that there is a random phase offset between sub-bands that can lead to performance loss. It suggests that hopping across multiple PRS resources or hopping across multiple resource-set may be more feasible to reduce switching frequency and support low latency positioning. Example snippets include the use of overlapping PRBs to estimate frequency offset and the balance between phase offset estimation and overall bandwidth usage. Overall, these TDocs highlight the technical challenges and considerations involved in implementing SRS frequency hopping for RedCap UE positioning, including the need for short switching time, configurability of hopping parameters, and decoupling of pos-SRS configuration from existing BWP configuration. They also provide examples of how various technical issues can be addressed and potential enhancements for future releases. TDoc comparison: R1-2302937 (Nokia, Nokia Shanghai Bell) R1-2303139 (Samsung) R1-2303720 (NTT DOCOMO, INC.) R1-2303840 (MediaTek (Chengdu) Inc.) • TDoc R1-2302937: UE may be configured with PRS processing windows across the DL BWPs for PRS frequency hopping, and each PRS processing window configuration can indicate the priority of PRS reception. The UE hops within a DL PRS resource, and may need to align the phase of multiple frequency chunks. The number of allowable frequency hops may be different depending on the MG-less mode and MG-based mode. Example snippet: "As part of PRS frequency stitching/hopping the UE may need to align the phase of multiple frequency 'chunks' in order to remove errors due to phase offsets between the chunks." • TDoc R1-2303139: If UE is unable to finish the complete PRS resource, some of the PRS FH reception is interrupted by RACH related signal/channels, UE could still report the measurement on the measured FH part. Each RE may experience different frequency selective fading, and the method of using the overlap REs for phase offset estimation and compensation need more study. Example snippet: "Rx reception should be studied to determine in which condition the FH part of the PRS could be received, e.g., the overlapping with RACH related signal or the RAR window used for the msg2 reception." • TDoc R1-2303720: RAN1 should check whether current MG length can accommodate all necessary components within a single MG instance to measure DL PRS with FH, such as duration of measuring each hop of PRS resources, switching time between hops and at beginning/ending of measurement. Proposal 5 suggests considering LS reply from RAN4 regarding the switching time values to support UL SRS hopping within a SRS resource. Example snippet: "Proposal 5: LS reply from RAN4 regarding the switching time values should be taken into account, and considering that RAN1 agreed DL PRS Rx hopping within a DL PRS resource at the last meeting." • TDoc R1-2303840: The suitable UE capability for reception frequency hopping could consider RF retuning time, not the total measurable BW, since it could depend on the DL-PRS structure. For SRS transmission frequency hopping, it was agreed to apply a configuration separate from existing BWP configuration. Example snippet: "Proposal 2-3: The suitable UE capability for reception frequency hopping could consider RF retuning time, not the total measurable BW, since it could depend on the DL-PRS structure." TDoc comparison: R1-2302611 (Spreadtrum Communications) R1-2303282 (ZTE) R1-2303601 (Qualcomm Incorporated) R1-2303822 (IIT Kanpur, CEWiT) TDoc R1-2302611: - Scheme 1 allows for SRS frequency hopping transmission between different symbols within one instance of SRS resource - Scheme 2 allows for frequency hopping transmission between different transmission instance of the same SRS resource, when the SRS repetition factor is equal to the number of SRS symbols - UE performs PRS frequency hopping reception during different transmission periodicity of the same PRS resource - Existing specifications allow for a PRS resource to be configured with a maximum of 32 repetitions, with a minimum time interval between adjacent PRS repeated transmissions of 1 time slot - Proposal 7 specifies the number of overlapping frequency resources in adjacent hops required for the UE to perform phase offset compensation for DL PRS Rx frequency hopping, which is a UE capability TDoc R1-2303282: - Proposal 1 requires network configuration of the number of hops for positioning for RedCap UE, with UE reporting a capability on the maximum number of supporting frequency hops to network, with candidates of 2, 3, 4, or 5 hops - UE is not expected to process other DL channels or signals within one measurement gap instance for DL-PRS processing - Configuration for number of frequency hops should consider both UE complexity and positioning performance requirement TDoc R1-2303601: - Two options for SRS frequency hopping pattern were considered, with a configurable parameter for the amount of overlap between frequency-consecutive hops - Proposal 5 supports Rx frequency hopping for MG-less PRS processing, with consideration for required retune time before and after each hop in specified PRS prioritization/collision rules - Total BW is 325 MHz with overlapping tones TDoc R1-2303822: - Proposal 1 suggests that effects of time and phase offset, and UE speed should be considered when designing hopping patterns for RedCap UE - Proposal 6 suggests defining a new set of resources for frequency hopping scheme for RedCap positioning to ensure all measurements are performed within coherence time window - Proposal 7 suggests supporting a mechanism to avoid collision of high-priority signal with UL SRS transmission and DL PRS reception for positioning purposes in FDD mode Examples from the original TDocs: - "Scheme 2: When the SRS repetition factor is equal to the number of SRS symbols, frequency hopping transmission between different transmission instance of the same SRS resource can be realized, as shown in the Figure 3.1-2." (TDoc R1-2302611) - "For instance, if UE reports that the supported maximum PRS bandwidth is 20MHz in FR 1, and UE reports the supported maximum number of frequency hops is 4 or 5, then network may configure at least 4 frequency hops to achieve measurement results which is equivalent to the result based on about 80MHz PRS bandwidth." (TDoc R1-2303282) - "Proposal 5: Support Rx frequency hopping for MG-less PRS processing using the following principle as a starting point: A UE may perform Rx frequency hopping within a PPW instance under the condition that the required retune time before and after each hop is taken into account in the specified PRS prioritization/collision rules." (TDoc R1-2303601) - "Proposal 6: To enable the frequency hopping scheme for RedCap positioning, a new set of resources should be defined, which ensures that all the measurements are performed within the coherence time window." (TDoc R1-2303822) TDoc comparison: R1-2303245 (CMCC) R1-2303556 (Ericsson) R1-2303674 (NEC) R1-2303747 (LG Electronics) TDoc R1-2303245: - Maximum active BWP for RedCap UE limited to 20MHz - SRS frequency hopping configuration enhancements needed for positioning - SRS for positioning frequency hopping is configured per BWP set - UE switches across multiple BWPs within set to transmit SRS for positioning resources for frequency hopping - Partial overlap between hops in frequency domain can lead to performance degradation - Two methods for configuring frequency hopping for SRS positioning resource set Example snippet: "In such a case, the SRS for positioning frequency hopping is configured per a BWP set and when the BWP set is activated to perform SRS for positioning frequency hopping, the UE will switch across multiple BWPs within this set to transmit SRS for positioning resources for frequency hopping." TDoc R1-2303556: - Configuration of SRS frequency hopping with partial overlap - Similar to DL-PRS frequency hopping - If one hop in the SRS frequency hopping is dropped, network can only use hops before dropped hop - UE is operating outside BWP framework when transmitting SRS for positioning with bandwidth hopping - Specific parameters for SRS with bandwidth hopping must be used independently from configured BWP bandwidth - Configuration beneficial for latency and resource utilization perspective Example snippet: "When the UE is transmitting the SRS for positioning with bandwidth hopping, it is thus operating outside of the BWP framework, and specific parameters to the SRS with bandwidth hopping must be used, independently from the configured BWP bandwidth." TDoc R1-2303674: - Corresponding muting mechanism for disabling one or some of the frequency hopping sub-bands should be further studied - Number of PRS REs included in overlapped bandwidth for phase error estimation can be reduced for channel with high quality - Three options for granularity of muting pattern configuration for hops Example snippet: "Option 1: Muting pattern is configured by considering all the hops as a whole, and it’s expected to be applied for all the hops, and legacy muting pattern configuration is used for PRS resource; Option 2: A dedicated muting pattern is configured for all the hops, and an additional bitmap is used to indicate which hop is to be muted via the configured muting pattern; Option 3: Muting pattern is configured per hops, and each hop applies the unique muting pattern separately, as shown in Figure 1." TDoc R1-2303747: - Collision handling for UL Tx and frequency hopping SRS-Pos - Configuration for transmission of frequency hopped SRS-pos performed inter-slot - Performance evaluation for different mobility cases and frequency hopping patterns Example snippet: "When the transmission of frequency hopped SRS-pos is performed inter-slot, i.e., single SRS transmission occasion in single slot, time duration to complete the frequency hopped SRS-pos will be identical to the number of hops." 3GPP-R1-112-bis-e Agenda Item 9.8 : XR Enhancements for NR
TDoc comparison: R1-2302500 (vivo, MediaTek, Google, Qualcomm, Panasonic, Meta, Ericsson, China Unicom, Huawei, HiSilicon, Xiaomi, Apple, China Telecom) R1-2303312 (Nokia, Nokia Shanghai Bell) Summary of Technical Differences between TDoc R1-2302500 and TDoc R1-2303312 1. PDCCH Monitoring Resumption After NACK - TDoc R1-2302500: UE resumes PDCCH monitoring after transmitting a PUCCH or PUSCH providing a NACK value and detecting a DCI format indicating PDCCH monitoring skip for the duration on the active DL BWP of the serving cell. - Example snippet: "after the UE detects a DCI format providing the PDCCH monitoring adaptation field indicating to the UE to skip PDCCH monitoring for the duration on the active DL BWP of the serving cell, the UE resumes PDCCH monitoring, starting from the beginning of a first slot that is after a last symbol of the PUCCH or PUSCH transmission in the serving cell." - TDoc R1-2303312: No changes to this procedure. 2. PDCCH Monitoring with Pending SR - TDoc R1-2302500: UE monitors PDCCH regardless of PDCCH skipping indication on all serving cells of the corresponding Cell Group when a positive SR is pending and before detecting a DCI format indicating PDCCH monitoring skip for the duration on the active DL BWP of the serving cell. - Example snippet: "If the UE transmits a PUCCH providing a positive SR before the UE detects a DCI format providing the PDCCH monitoring adaptation field indicating to the UE to skip PDCCH monitoring for the duration on the active DL BWP of the serving cell, the UE shall monitor PDCCH regardless of PDCCH skipping indication on all serving cells of the corresponding Cell Group when the SR is pending." - TDoc R1-2303312: No changes to this procedure. 3. PDCCH Monitoring Resumption After SR Cancellation - TDoc R1-2302500: No mention of resuming PDCCH monitoring after SR cancellation. - TDoc R1-2303312: UE resumes PDCCH monitoring in all serving cells of the corresponding Cell Group after detecting a DCI format indicating PDCCH monitoring skip for the duration on the active DL BWP of a serving cell and cancellation of a pending SR. - Example snippet: "After the UE detects a DCI format providing the PDCCH monitoring adaptation field indicating to the UE to skip PDCCH monitoring for the duration on the active DL BWP of a serving cell, when a pending SR is cancelled, the UE resumes PDCCH monitoring in all serving cells of the corresponding Cell Group." 4. PDCCH Monitoring Resumption After Contention Resolution - TDoc R1-2302500: UE resumes PDCCH monitoring on the SpCell after detecting a DCI format indicating PDCCH monitoring skip for the duration on the active DL BWP of the SpCell and successful contention resolution. - Example snippet: "After the UE detects a DCI format providing the PDCCH monitoring adaptation field indicating to the UE to skip PDCCH monitoring for the duration on the active DL BWP of a SpCell, when contention resolution is successful, the UE resumes PDCCH monitoring on the SpCell." - TDoc R1-2303312: No changes to this procedure. TDoc comparison: R1-2302676 (CATT) R1-2302946 (ZTE, Sanechips) - TDoc R1-2302676 highlights the trade-off between power saving and XR capacity performance when using PDCCH skipping. It suggests that longer skipping duration can provide higher power saving but significantly degrade the XR capacity performance. - Example snippet: "Although the longer skipping duration of PDCCH skipping can provide similar or slightly higher UE power saving with 31.5% power saving gain comparing to that of PDCCH skipping enhancement with MAC-CE based go-to-sleep signaling, the XR capacity performance would suffer significant loss." - TDoc R1-2302676 proposes a PDCCH skipping scheme enhanced with continuous PDCCH skipping and go-to-sleep indication as a way to achieve power saving without significant capacity degradation. - Example snippet: "The PDCCH skipping scheme enhanced with continuous PDCCH skipping and go-to-sleep indication can achieve 29.4% power saving gain with negligible capacity degradation compared with that of always-on." - TDoc R1-2302676 warns against using PDCCH skipping with resuming PDCCH monitoring after NACK transmission, as it can result in severe capacity performance degradation with long skipping duration. - Example snippet: "The PDCCH skipping with resuming PDCCH monitoring after NACK transmission will have the results of power saving performance with short skipping duration or degrading the capacity performance severely with long skipping duration." - TDoc R1-2302946 suggests that PDCCH skipping indication (with a long skipping duration) can save power and reduce activation delay of PDCCH monitoring adaption, especially if applied directly to UE instead of using MAC CE. - Example snippet: "Regarding the PDCCH skipping indication (e.g., configure a long skipping duration), the PDCCH monitoring during time interval between detection of initial PDCCH/ re-transmission PDCCH and NACK/ACK transmission can be skipped, and less activation delay of the PDCCH monitoring adaption is needed, thus these reasons contributes to saving power." - TDoc R1-2302946 proposes that UE should resume PDCCH monitoring after reporting NACK as a way to ensure successful retransmission and avoid degradation of performance. - Example snippet: "In a case, if UE can resume PDCCH monitoring for retransmission, the problem can be resolved assuming a long skipping duration is configured for saving UE power." 3GPP-R1-112-bis-e Agenda Item 9.8.1 : XR-specific capacity enhancements
TDoc comparison: R1-2302317 (FUTUREWEI) R1-2302346 (Huawei, HiSilicon) R1-2302399 (Ericsson) R1-2302429 (New H3C Technologies Co., Ltd.) R1-2302501 (vivo) R1-2302563 (OPPO) R1-2302615 (Spreadtrum Communications) R1-2302718 (CATT) R1-2302811 (Intel Corporation) R1-2302856 (Sony) R1-2302879 (Google Inc.) R1-2302893 (Panasonic) R1-2302947 (ZTE, Sanechips) R1-2302997 (xiaomi) R1-2303023 (InterDigital, Inc.) R1-2303190 (CAICT) Summary of Technical Differences Among TDocs: - TDoc R1-2302317: In legacy CG, the HARQ process ID associated with the first symbol of the single CG PUSCH occasion is derived based on a regular periodicity of CG resources in the legacy Type 1 CG and Type 2 CG. Retransmissions of multiple CG PUSCH transmission occasions are based on dynamic uplink grants via dynamic grant resources. The formula-based HARQ determination includes an alternative. - TDoc R1-2302346: The HARQ process ID for the first configured/valid PUSCH in a period is determined based on the legacy CG procedure when cg-RetransmissionTimer is not configured, and applying the period duration divided by X instead of the period TDoc comparison: R1-2303249 (CMCC) R1-2303311 (Nokia, Nokia Shanghai Bell) R1-2303498 (Apple) R1-2303672 (NEC) - TDoc R1-2303249: TDRA determines multiple CG PUSCHs in Alt-C2 based on Rel-17 single DCI scheduling, with separate SLIV, mapping type, and extendedK2-r17 parameter for each PUSCH. Option 1 has less signaling overhead but cannot indicate unused CG PUSCH at the beginning of a CG period. The principle of configuring different SLIVs for multiple PUSCHs in a CG period is unclear. - Example snippet: "Compared to Option 2, Option 1 has less signaling overhead when a large number of CG PUSCH transmission occasions are configured in a CG period, however, it can not indicate the unused CG PUSCH occasion(s) at the beginning of a CG period when the UL jitter of XR traffic is considered." - TDoc R1-2303311: Investigates options to support different MCSs over multi-PUSCHs within a CG period, such as explicit indication of utilized MCS or delta value configuration. NR-U based Option 3 has unclear benefits and reduces spectral efficiency. - Example snippet: "One straightforward way is via explicit indication of the utilized MCS (e.g., following table 6.1.4.1-1 and Table 6.1.4.1-2 of TS 38.214) for each individual CG PUSCH occasion." - TDoc R1-2303498: Proposes support for using occasions starting from any occasion within a CG period with a common reference timing for the provided information. UCI payload is identical from multiple occasions. - Example snippet: "Proposal 10: to support the use of occasion starting from any occasion within a CG period, consider With a common reference timing for the provided information from multiple occasions (e.g., the common reference timing is the start of the first occasion in a CG period), the UCI payload is identical from multiple occasions." - TDoc R1-2303672: Semi-static method allows same HP ID for different CG occasions within a CG period, but may lead to confusion in HARQ retransmission. PUSCH preparation time overlap between DG-PUSCH and CG-PUSCH is an issue. Enhancement based on existing resource allocation mechanisms can be a starting point. - Example snippet: "For the semi-static method, allowing same HP ID for different CG occasions within a CG period (and in two consecutive CG periods if the periodicity is relatively small) may lead to confusion in the HARQ retransmission procedure." TDoc comparison: R1-2303409 (FGI) R1-2303460 (Sharp) R1-2303533 (Lenovo) R1-2303724 (NTT DOCOMO, INC.) - TDoc R1-2303409 proposes support for UE to decide HARQ IDs for the first CG PUSCH transmission occasions and indicate them to gNB when multiple HARQ processes are used for multiple CG PUSCH transmissions in a single CG PUSCH configuration. - The HARQ process ID for remaining PUSCHs in the period is determined by incrementing the HARQ process ID of the preceding PUSCH in the period. - The HARQ process ID for the first configured/valid PUSCH in a period is determined based on the legacy CG procedure when cg-RetransmissionTimer is not configured, and applying "the period duration divided by X" instead of the period duration. - TDoc R1-2303460 proposes the same support as TDoc R1-2303409. - Both TDocs consider multiple CG PUSCH transmission occasions in a period of a single CG PUSCH configuration, HARQ process ID determination, and dynamic indication of unused CG PUSCH transmission occasion(s) based on UCI by the UE. - TDoc R1-2303533 proposes UCI to indicate unused CG occasions within a time duration defined by a length and start time, and the applicable time window does not include symbols for reception of SS/PBCH blocks and/or DL symbols indicated by tdd-UL-DL-ConfigurationCommon and/or symbols corresponding to a measurement gap. - Unused occasions can be mapped in a code-point or bitmap manner, wherein the bitmap imposes a certain structure on how to map CG occasions for indication, whereas the codepoints can be configured for every UCI occasion. - TDoc R1-2303724 proposes support for Alt 1 for HP ID determination of multiple CG PUSCHs in one CG period, where the HARQ process ID for the first valid PUSCH in a period is determined based on the legacy CG procedure when cg-RetransmissionTimer is not configured, and applying "the period duration divided by X" instead of the period duration. - The HP ID for the first configured/valid CG PUSCH in the next CG period is also equal to N+1. - Both TDocs consider the case of one TB map to multiple PUSCHs is not considered here. - Examples from the original TDocs include various proposals and alternatives for time domain and frequency domain resource allocation, unused occasion mapping, and UCI indication design. TDoc comparison: R1-2303143 (Samsung) R1-2303356 (MediaTek Inc.) R1-2303605 (Qualcomm Incorporated) R1-2303827 (DENSO CORPORATION) - TDoc R1-2303143: For TDD operation, a bitmap is unnecessary as there is no ambiguity between gNB and UE for consecutive CG-PUSCH TOs. Alt-C1 flexibility is unnecessary. SLIVs are semi-statically configured for a video frame size that is not known in advance. - Example snippet: "Alt-C1 is unnecessary particularly when considering that after few CG-PUSCH transmissions, the gNB can obtain BSR and switch to DG-PUSCH to improve spectral efficiency" - TDoc R1-2303356: UCI can be transmitted in a separate PUCCH or multiplexed in PUSCH that carries XR UL data. Dynamic indication of unused PUSCH TOs is beneficial for reallocating resources and saving power. - Example snippet: "The motivation behind dynamic indication of unused PUSCH is essentially to help network be informed about unnecessary pre-configured UL resources with sufficient time in advance such that network can react and re-purpose these resources for another user in the system, potentially." - TDoc R1-2303605: Proposal to add rules for UCI when multiplexed and sent on the CG PUSCH UE is requesting to skip. Three alternatives proposed for transmitting UCI. - Example snippet: "Proposal 5: Support the following proposals" - TDoc R1-2303827: UE may not know the amount of UL data to indicate unused occasions in the first configured PUSCH occasion within a CG period due to UL jitter and mismatch between CG periodicity and XR frame rate. It is effective to allow UE to select HARQ process IDs to avoid reserving too many HARQ process IDs. - Example snippet: "Considering UL jitter and the mismatch between CG periodicity and XR frame rate, the UE may not know the amount of UL data to indicate unused occasion(s) in the first configured PUSCH occasion within a CG period." 3GPP-R1-112-bis-e Agenda Item 9.9 : NTN (Non-Terrestrial Networks) enhancements
Entities and Technical Concepts
3GPP-R1-112-bis-e Agenda Item 9.9.3 : Disabling of HARQ feedback for IoT NTN
TDoc comparison: R1-2302366 (Huawei, HiSilicon) R1-2302566 (OPPO) R1-2302617 (Spreadtrum Communications) R1-2302721 (CATT) R1-2302837 (Nokia, Nokia Shanghai Bell) R1-2303000 (xiaomi) R1-2303357 (MediaTek Inc.) R1-2303419 (Mavenir) - TDoc R1-2302366 proposes a dynamic enabling/disabling mechanism for HARQ-ACK feedback using a single bit in the scheduling DCI, regardless of RRC bitmap configuration. - TDoc R1-2302566 discusses how to handle HARQ feedback state when some of the HARQ processes of the scheduled TBs are feedback disabled, with different approaches depending on the disabled HARQ process configuration/indication method. - TDoc R1-2302617 proposes a new mechanism to enable/disable HARQ feedback using DCI signaling, with different options for multiple TBs scheduled by single DCI. - TDoc R1-2302721 defines the agreement for HARQ feedback for eMTC SPS PDSCH, including the first SPS PDSCH after activation. - TDoc R1-2302837 raises concerns about the impact of disabling HARQ feedback on NPRACH capacity and link adaptation, proposing solutions that strive for UE power saving and efficient use of UL resource. - TDoc R1-2303000 discusses the issue of whether the DCI-based overridden mechanism should signal to reverse the HARQ feedback enable/disable from per-HARQ process RRC configuration or directly indicate it. - TDoc R1-2303357 introduces new indication alternatives for enabling/disabling HARQ feedback for downlink transmission in IoT NTN, depending on the configuration of RRC per-HARQ process bitmap and DCI solution. - TDoc R1-2303419 proposes different options for enabling/disabling HARQ feedback, with observation 2 stating that configuring Option 3 for HARQ ACK disabled HARQ process makes more sense. - Example snippets from the original TDocs are provided to support the differences highlighted, including diagrams and observations from RAN meetings. TDoc comparison: R1-2302859 (Sony) R1-2303627 (Lenovo) R1-2303642 (Sharp) • TDoc R1-2302859 proposes two options for indicating by DCI whether HARQ feedback is enabled or disabled. Option 1 is the explicit indication by adding a new DCI field, while Option 2 is the reuse/reinterpretation of an existing field in DCI, such as the HARQ-ACK resource field in the DCI for NB-IoT. • TDoc R1-2303627 discusses the preference for using a 1-bit indication in DCI to override the RRC-based configuration for enabling or disabling HARQ feedback for all scheduled HARQ processes. If there is mixed scheduling by a single DCI, the DCI-based overridden indication should only be adopted for the enabled/disabled HARQ processes to avoid complicating the configuration. • Proposal 3 suggests the direct indication of HARQ enabling/disabling for multiple TBs scheduled by a single DCI to all scheduled HARQ processes. Potential indication methods for candidate are also listed. • Proposal 4 proposes that for NB-IoT, if two TBs are scheduled by a single DCI, ACK is assumed/reported for the downlink transmission with HARQ process disabled, regardless of decoding results of the corresponding transmission. • Proposal 5 suggests that for eMTC FDD/HD-FDD, when multiple TBs are scheduled by a single DCI without HARQ bundling, ACK is assumed/reported for the downlink transmission with HARQ process disabled, regardless of decoding results of the corresponding transmission. • Overall, these TDocs focus on DCI-based solutions for indicating and overriding the RRC-based configuration for enabling/disabling HARQ feedback. The proposals aim to simplify the configuration and improve the efficiency of HARQ feedback in various scenarios. TDoc comparison: R1-2303501 (Apple) R1-2303542 (InterDigital, Inc.) R1-2303608 (Qualcomm Incorporated) R1-2303685 (NEC) - TDoc R1-2303501 proposes that Alt 2 be configured for DCI-based overridden to apply to both semi-statically HARQ enabled and disabled processes, with DCI directly indicating the HARQ feedback regardless of per-HARQ process configuration. - Proposal 3 for NB-IoT NTN and eMTC NTN for CE Mode B supports DCI-based overriding mechanism for a single DCI scheduling multiple TBs, with the mechanism applied to all applicable TBs. - Proposal 4 for NB-IoT NTN and eMTC NTN for CE Mode B, under DCI-based overridden mechanism, supports Alt 2 configuration for DCI directly indicating the HARQ feedback, regardless of per-HARQ process configuration. - TDoc R1-2303542 suggests that Alt-1 is equivalent to DCI direction indication mode of operation, assuming DCI-based overridden indication exists in the DCI always. The document discusses further details on applying the DCI-based overridden mechanism and indication method for DCI-based overridden/direct indication. - TDoc R1-2303608 states the UE behavior would be the same if Option 1 was configured with a HARQ mask of {disabled, disabled}. One of the points for further study is only allowing DCI override for RRC-disabled HARQ processes and not for RRC-enabled HARQ processes. - Proposal 4 discusses the impact of introducing feedback-less HARQ processes on multi-TB scheduling for eMTC and NB-IoT, including a single DCI scheduling feedback-enabled and feedback-disabled TBs, HARQ-ACK transmission timeline, and determining bundled HARQ-ACK feedback when some TBs have feedback enabled while others have feedback disabled. - TDoc R1-2303685 supports UE following the per-process HARQ feedback enabled/disabled configuration for associated HARQ processes except for the first SPS PDSCH after activation. Option 1 allows ACK/NACK reporting by the UE for the first SPS PDSCH after activation if HARQ feedback for SPS activation is additionally enabled, with the UE following per-process configuration otherwise. Option 2 includes N bits in the DCI with bitmap method indication for HARQ-ACK feedback for each scheduled TB. The eNB can disable HARQ-ACK feedback for one group of configured or predefined M HARQ feedback processes through DCI dynamically, with the 1 bit disabled HARQ-ACK feedback indication applied to all scheduled TBs of the DCI. TDoc comparison: R1-2303146 (Samsung) R1-2303175 (Nordic Semiconductor ASA) R1-2303251 (CMCC) R1-2303296 (ZTE) - TDoc R1-2303146 proposes three alternatives for selecting whether semi-static HARQ processes are enabled or disabled, based on criteria such as DCI overhead and UE implementation complexity. - Proposal 2 postpones discussion on how to support DCI-based signalling for transmission of multiple TBs scheduled by a single DCI until after the design of DCI scheduling for a single TB is complete. - The main purpose of this feature is to disable HARQ-ACK feedback for IoT NTN. - TDoc R1-2303175 proposes that if HARQ feedback is enabled for a process via RRC-configuration, the UE transmits ACK/NACK responses for all allocated (N)PDSCH, regardless of whether DCI-based override is configured or not. - The UE transmits just ACK/NACK information using subcarrier index 0 when transmission parameters are about correct in relation to the measured channel quality. - TDoc R1-2303251 proposes two options for DCI indication of HARQ feedback, either introducing a new DCI field or reusing an existing one to indicate enabling/disabling feedback for NB-IoT NTN and eMTC NTN. - For CE mode B with one or two HARQ processes, it is reasonable to reinterpret an existing DCI field to indicate enabling/disabling of HARQ feedback. - TDoc R1-2303296 proposes defining a new bit field in DCI for DCI-based overridden/direct indication of disabled HARQ feedback for the TB scheduled by this DCI. - Separate indications for each scheduled TB can provide more scheduling flexibility, but a single indication applying to all scheduled TBs is a straightforward way with low complexity and is preferred. 3GPP-R1-112-bis-e Agenda Item 9.9.4 : Improved GNSS operations for IoT NTN
TDoc comparison: R1-2302367 (Huawei, HiSilicon) R1-2302567 (OPPO) R1-2302722 (CATT) R1-2302838 (Nokia, Nokia Shanghai Bell) - TDoc R1-2302367 proposes that if UE fails GNSS position fix in the measurement gap, it should not transmit UL on the UL resource schedule by eNB, and adds the expiration of TAT into the criteria to initiate the timer for autonomous GNSS position fix. - Example snippet: "If UL transmission is allowed additionally based on TAT of TAC after GNSS validity duration expires, as discussed in section 2.3, the expiration of TAT should also be added into the criteria to initiate the timer for autonomous GNSS position fix." - TDoc R1-2302567 discusses UE PDCCH monitoring within GNSS measurement gap and proposes reporting implicit information to the network to inform the success of GNSS re-acquisition. For Alt-1, reporting is based on network scheduling and it is important for the UE to define a clear NPDCCH monitoring within the measurement gap. - Example snippet: "When UE is triggered to perform GNSS re-acquisition within the measurement gap, it may terminate the measurement before the gap end, in this case, in last meeting RAN1 agrees to let UE report implicit information to the network to inform the network about the success of GNSS re-acquisition." - TDoc R1-2302722 proposes that UE should follow GNSS validity duration guidance instead of eNB indication to perform GNSS measurement immediately. - Example snippet: "Since the GNSS validity duration is one effective timer to help UE and network to determine when the GNSS position is expired, UE should follow GNSS validity duration guidance, not following eNB indication to perform GNSS measurement immediately." - TDoc R1-2302838 proposes to postpone the discussion on whether the UE can reacquire the GNSS position fix outside the Connected DRX Active Time and suggests that RAN1 should first specify the basic GNSS measurement functionality during a long connection. - Example snippet: "Our view is that RAN1 shall first specify the basic GNSS measurement functionality during a long connection, i.e. the configuration and use of measurement gaps, and then RAN1 may discuss whether there is a need for GNSS measurements outside the Connected DRX Active Time as a potential next step Proposal 14: RAN1 to postpone the discussion on whether the UE can reacquire the GNSS position fix outside the Connected DRX Active Time." - Observation 17 in TDoc R1-2302838 notes that UE may need to reacquire SIB31 during the inactive state of Connected DRX and is therefore not able to perform the GNSS measurement. - Example snippet: "UE may need to reacquire SIB31 during the inactive state of Connected DRX and is therefore not able to perform the GNSS measurement." TDoc comparison: R1-2302749 (NEC) R1-2303147 (Samsung) R1-2303543 (InterDigital, Inc.) R1-2303628 (Lenovo) Possible technical differences among the listed TDocs related to GNSS measurements in RRC connected mode are as follows: - TDoc R1-2302749 proposes that a UE can re-acquire GNSS position fix with a gap if eNB aperiodically triggers connected UE to make GNSS measurement. The UE may also re-acquire GNSS autonomously based on configured timing. The intention of configuring new timing is to prevent a UE from going to IDLE mode in case it doesn’t receive a command in time, and/or misses a command and GNSS validity has expired. Closed loop time and frequency correction, with potential enhancements, for IoT-NTN can reduce the need for UE to update GNSS position fix in long connection time and, therefore, reduce UE power consumption. At least for the case when frequency error is within frequency error requirements, study the mechanisms and conditions to allow UL transmission after original GNSS validity duration expires without GNSS re-acquisition for some duration. - TDoc R1-2303147 suggests studying and specifying improved GNSS operations for a new position fix for UE pre-compensation during long connection times and for reduced power consumption. The following alternatives can be considered to inform eNB the success of GNSS measurement at UE side after GNSS measurement in RRC connected. Aperiodic GNSS measurement should be triggered in the case that GNSS measurement validation is out-dated and UL synchronization is lost. Possible optimizations on GNSS operation are discussed, but closed loop frequency correction is not supported in current specification. - TDoc R1-2303543 proposes defining a new GNSS acquisition assistance information MAC CE and corresponding reporting framework to support multiple report triggering conditions. On when the GNSS measurement gap starts, which is aperiodically triggered by eNB with MAC CE, RAN1 can down select one of the following alternatives: the start time should be at n+ X, where n is the end of MAC CE receiving subframe/slot, or the start time should be based on the current GNSS validity duration with delay or without delay. UE reports only one GNSS position fix time duration for GNSS measurement at least when moving to RRC connected state. To support connected mode reporting, the UE may optionally include GNSS position fix duration within the GNSS acquisition assistance information MAC CE along with validity duration. - TDoc R1-2303628 argues that there is no need to explicitly indicate the success/completion of GNSS position fix, and the reception of any UL transmission from the UE at eNB side after the GNSS measurement can be an implicit way to report the success/completion of GNSS position fix. For NBIoT and eMTC, PUSCH transmission is always configured with large repetition, and UE may not have the opportunity to monitor the PDCCH. The closed loop frequency correction in MAC CE is not available, and UE still may not have the opportunity to perform time/frequency synchronization and corresponding adjustment during the uplink transmission except the configured gap duration. For aperiodic triggering GNSS measurement, the new scheduling gap can be configured for GNSS measurement in advance to the data scheduling based on the UE reported validity duration. Example snippets from the original TDocs are: - "The UE may re-acquire GNSS autonomously (when configured by the network) if UE does not receive eNB trigger to make GNSS measurement FFS based on configured timing" [TDoc R1-2302749] - "To support connected mode reporting, the UE may optionally include GNSS position fix duration within the GNSS acquisition assistance information MAC CE along with validity duration" [TDoc R1-2303543] - "For NBIoT and eMTC, PUSCH transmission is always configured with large repetition, UE may not have the opportunity to monitor the PDCCH, the closed loop frequency correction in MAC CE is not available and UE still may not have the opportunity to perform time/frequency synchronization and corresponding adjustment during the uplink transmission except the configured gap duration" [TDoc R1-2303628] TDoc comparison: R1-2302618 (Spreadtrum Communications) R1-2303001 (xiaomi) R1-2303502 (Apple) R1-2303609 (Qualcomm Incorporated) - TDoc R1-2302618 proposes that UE can perform UL transmission after GNSS validity duration expires without GNSS re-acquisition for some duration, as long as frequency and timing errors are within requirements, or can be adjusted through closed-loop mechanism. The UE would then conduct GNSS measurement with configured periodic gaps. - TDoc R1-2303001 discusses two alternatives for the start time of GNSS measurement, based on either a predefined or current GNSS validity duration. The proposal emphasizes the eNB's configuration for GNSS measurement. - TDoc R1-2303502 suggests UE reporting of the success of GNSS measurement to inform eNB of GNSS validity duration, and proposes triggering aperiodic and periodic GNSS measurements together with UL resource requests for validity duration reports. - TDoc R1-2303609 presents two alternatives for the start time of GNSS measurement gap after triggering, with Alt 1 suggesting alignment through MAC-CE triggering and Alt 2 based on GNSS validity duration. The proposal favors Alt 1 for better alignment between UE and eNB. Example snippets: - "If the frequency error is within frequency error requirements and the timing error is also within timing error requirements, or the timing error can be adjusted through the existing closed-loop adjustment mechanism, then UE can also perform UL transmission after original GNSS validity duration expires without GNSS re-acquisition for some duration." - "In our understanding, the start time of the GNSS measurement should be up to the eNB’s configuration, it is not needed to associate the start time of the GNSS validity duration to avoid any possible interruptions to the UE’s transmission." - "UE reporting To align the common understanding between the eNB and UE on the GNSS validity duration, the following alternatives can be considered to inform eNB the success of GNSS measurement at UE side after GNSS measurement in RRC connected." - "Regarding when the GNSS measurement gap starts after triggering, the two alternatives agreed in the previous meeting are: Alt 1: the start time should be at n+ X, where n is the end of MAC CE receiving subframe/slot Alt 2: the start time should be based on the current GNSS validity duration with delay or without delay" TDoc comparison: R1-2303176 (Nordic Semiconductor ASA) R1-2303252 (CMCC) R1-2303297 (ZTE) R1-2303432 (Ericsson Limited) Technical differences among the TDocs related to improved GNSS operation for IoT NTN can be summarized as follows: - TDoc R1-2303176 proposes that the GNSS measurement gap should be configured in such a way that the extra delay due to measurement is minimized while ensuring the UE is not unnecessarily dropped off. The gap duration can be configured by the eNB or can be equal to the latest reported GNSS position fix time duration. Example snippet: "the configuration of the GNSS measurement gap should be such that the extra delay due to measurement is minimized and, on the other hand, the UE is not unnecessarily dropped off due to failure in acquiring a new position fix in the configured measurement gap." - TDoc R1-2303252 suggests that the GNSS measurement gap can be configured periodically by the network without any triggering signaling, and the configuration can be indicated by RRC signaling. The GNSS validity duration can be updated by the UE if needed, and the length of the gap can be determined based on the updated validity duration. Example snippet: "the GNSS measurement gap can also be configured periodically by network without any triggering signalling, and the configuration can be indicated by RRC signalling to enable UE acquire new GNSS position fix during long connection times." - TDoc R1-2303297 recommends that the GNSS position fix acquisition should be performed just before the switch from inactive to active time to obtain fresh GNSS information. Reporting GNSS validity duration only once during initial access is preferred to save signaling overhead. The start and length of the GNSS measurement timer are similar to the GNSS measurement gap. Example snippet: "in order to achieve consensus on GNSS validity and maximize the usage of GNSS information, GNSS position fix acquisition should be performed just before the switch from inactive to active time so that a fresh GNSS information can be obtained by UE." - TDoc R1-2303432 agrees that the UE may re-acquire GNSS autonomously if configured by the network or if it does not receive eNB trigger to make GNSS measurement. The start time of the gap can be at n+X or based on the current GNSS validity duration with delay or without delay. The gap duration should be equal to or larger than the latest reported GNSS position fix time duration, and the UE will report the new GNSS validity duration. Example snippet: "the gap duration should be equal to or larger than the latest UE reported GNSS position fix time duration." Overall, these TDocs propose different approaches to improve GNSS operation for IoT NTN, taking into account factors such as measurement gap configuration, signaling overhead, and GNSS validity duration. They highlight the importance of minimizing delay and ensuring reliable positioning for connected UE while maximizing the usage of GNSS information. 3GPP-R1-112-bis-e Agenda Item 9.10.2 : Timing advance management to reduce latency
TDoc comparison: R1-2302316 (FUTUREWEI) R1-2302369 (Huawei, HiSilicon) R1-2302424 (ZTE) R1-2302505 (vivo) R1-2302620 (Spreadtrum Communications) R1-2302814 (Intel Corporation) R1-2302831 (Nokia, Nokia Shanghai Bell) R1-2302869 (CATT) R1-2302967 (xiaomi) R1-2303083 (LG Electronics) R1-2303260 (CAICT) - TDoc R1-2302316: PDCCH ordered RACH may introduce wasted RACH activities and low resource utilization efficiency of RACH. UE-based TA solution involves configuring a TA network adjustment factor for compensation in asynchronous scenarios and letting the cell switch command be issued after the source serving cell notified or obtained the target AT to avoid HO failure. Legacy random access indicates the best DL beam selected by the UE. - TDoc R1-2302369: UE with limited RF chains should consider a delay factor related DL synchronization adjustment for UL interruption on the serving cell when transmitting PRACH for a candidate cell with a different BW from those in the serving cell. RAR from candidate cell can be considered if TA/RAR coordination is not possible. Intra-frequency cell switch case may require UE to adjust DL timing from serving to candidate cell before PRACH transmission if RTD exceeds CP length. TA indication methods are discussed. - TDoc R1-2302424: UE should not operate UL synchronization for all configured candidate cells to avoid processing complexity. The number of configured candidate cells should not exceed UE's maximum number of memorized TA values. PRACH transmission power control should be considered for Alt 1. A default mapping rule for TA maintenance by UE should be introduced. - TDoc R1-2302505: If the number of configured cells with the reception of TA value is larger than the maximum number of TAs UE can maintain, the network cannot judge the validity of TA for the target cell when transmitting cell switch command. A pre-defined window for UE to monitor dedicated signaling should be considered, and a default mapping rule for TA maintenance by UE should be introduced to avoid confusion. - TDoc R1-2302620: gNB can provide information for UE to modify TA. UE-based TA measurement through Rx timing difference needs to discuss when UE has to do the TA acquirement and under what conditions. RACH-based and RACH-less mechanisms for TA acquisition of candidate target cell are supported. - TDoc R1-2302814: TAG ID within the candidate cell for which the given TA is applicable might be useful for UE. PDCCH ordered RACH for LTM may require coordination between source and candidate cells. TA maintenance includes UE autonomous re-transmission of PRACH and UE-based TA measurement including UE based TA measurement with one TAC from serving cell. - TDoc R1-2302869: In the legacy mechanism, UE increases preamble_transmission_counter by 1 and retransmits the PRACH preamble with a ramping up power when it doesn't receive RAR within ra_responseWindow. UE should not re-transmit PRACH when reception of RAR is not configured/indicated in Alt 1. - TDoc R1-2302967: UE should not re-transmit the preamble with power ramping according to the legacy procedure for PDCCH ordered RACH for serving cell since the TA value of candidate cell is only indicated by serving cell in cell switch command. UE should not re-transmit PRACH when reception of RAR is not configured/indicated. Different ra_PreambleIndex can be included in PDCCH order for different candidate cell. - TDoc R1-2303083: Additional type-1 PDCCH CSS should be configured for a candidate cell to receive RAR from the candidate cell. TA acquisition/maintenance for candidate serving cell is targeted for enhancement on timing advance management. - TDoc R1-2303260: UE should not re-transmit PRACH when reception of RAR is not configured/indicated for PDCCH ordered RACH for serving cell since the TA value of candidate cell is only indicated by serving cell in cell switch command. Alt 1: UE autonomous re-transmission of PRACH is not allowed is preferred. TDoc comparison: R1-2303381 (Transsion Holdings) R1-2303504 (Apple) R1-2303519 (Google) R1-2303611 (Qualcomm Incorporated) 1. Proposal 4 allows UL grant to be carried in RAR to indicate UL resource for PUSCH transmission toward the target cell to confirm the cell switch command. (TDoc R1-2303381) Example snippet: "If reception of RAR is configured/indicated, regarding the content of RAR, UL grant can be carried in RAR to indicate UL resource for PUSCH transmission toward the target cell to confirm the cell switch command." 2. Legacy CBRA is not supported for PDCCH-order based RACH for TA measurement for candidate cells. (TDoc R1-2303381) 3. The need of candidate cell ID in RAR is unclear if parallel CFRA operation would NOT be supported by LTM. (TDoc R1-2303504) Example snippet: "If parallel CFRA operation would NOT be supported by LTM, there is one-to-one mapping between a candidate cell and the ongoing RAR reception for a given UE and the need of candidate cell ID in RAR is unclear." 4. RAR is supposed to contain a TA value and UE maintains TA for the corresponding candidate cell and applies the TA once cell switching is triggered. (TDoc R1-2303504) Example snippet: "In addition, one more discussion point is whether TA value needs to be included in a cell switch command for the case of ‘with RAR’ being enabled." 5. Forwarding RAR from target DU to the serving DU may cause a large latency and is against the goal of LTM operation. (TDoc R1-2303504) 6. There is one issue related to TA indication timing, i.e., when to indicate TA value for a candidate/target cell. (TDoc R1-2303519) Example snippet: "Moreover, there is one issue related to TA indication timing, i.e., when to indicate TA value for a candidate/target cell." 7. UE-based TA measurement could be inaccurate when the serving cell and target cell are not well synchronized. (TDoc R1-2303519) Example snippet: "When the serving cell and target cell are not well synchronized, the UE-based TA measurement could be inaccurate, since the start timing for the DL signals for both cells could be quite different." 8. The maximum number of simultaneously maintained TAs should be up to UE capability. (TDoc R1-2303611) Example snippet: "For UE based TA acquisition, the maximum number of simultaneously maintained TAs should be up to UE capability." 9. The UE based TA acquisition can have periodic TA update for the candidate cell, where the UE measures the Rx timing difference periodically and updates the derived TA based on the latest TAC for the serving cell as well. (TDoc R1-2303611) Example snippet: "As the baseline, the UE based TA acquisition can have periodic TA update for the candidate cell, where the UE measures the Rx timing difference periodically and updates the derived TA based on the latest TAC for the serving cell as well." 10. SRS carrier switching can interrupt UL Tx of certain serving cells with PUCCH/PUSCH, which are indicated by gNB based on UE capability report. (TDoc R1-2303611) Example snippet: "Similar issue exists for SRS carrier switching, where the SRS Tx on a serving cell without PUCCH/PUSCH will interrupt UL Tx of certain serving cells with PUCCH/PUSCH, which are indicated by gNB based on UE capability report." 11. The necessities of functionalities associated with candidate fields need to be discussed and concluded first. (TDoc R1-2303504) Example snippet: "On the FFS aspects, RAN1 needs to first discuss and conclude the necessities of functionalities associated with candidate fields." 12. Different power control mechanisms are specified for the initial PRACH transmission and retransmission in NR, based on a tradeoff between cell access delay and inter-cell interference. (TDoc R1-2303504) Overall, these TDocs discuss technical differences related to TA acquisition, RAR content, candidate cell ID, periodic TA updates, and power control mechanisms in NR, among other topics. The example snippets provided above support the key differences highlighted in the bullet point summary. TDoc comparison: R1-2302414 (Ericsson) R1-2302569 (OPPO) R1-2303254 (CMCC) • TDoc R1-2302414 proposes the use of an explicit TPC command in the PDCCH order to trigger the RACH procedure and instruct the UE to adjust the transmit power of the PRACH preamble. This approach eliminates the need for RAR to stop subsequent transmissions of the PRACH preamble. Example snippet: "With explicit control of the PRACH transmit power, each PDCCH order would include a TPC command, which would instruct the UE how to adjust the transmit power." • TDoc R1-2302569 suggests calculating the offset of TA for the candidate cell with respect to the TA value of the serving cell, instead of having the UE report DL timing information of the candidate cell to the system. It also proposes indicating the TA value of the target cell before the UE starts the HO procedure. Example snippet: "If the candidate cell and serving cell are not synchronized, the offset between DL timing of the serving cell and the candidate value shall be provided to the UE so that the UE can compensate that in the calculation of TA of the candidate cell." • TDoc R1-2303254 proposes confirming that the UE has derived the TAs of the candidate cells before cell switching and extending the Rx timing difference solutions to cover more scenarios. It also suggests discussing the identification of subsequent PRACH triggered by PDCCH order and the need to indicate an increase in transmit power of PRACH. Example snippet: "After the DL synchronization before cell switch, the UE with the capability can be considered that it has acquired the timing differences between the multiple candidate cells and current serving cell during synchronization procedure." Overall, these TDocs address technical differences in the RACH procedure, such as the explicit control of PRACH transmit power, calculation of TA offset for candidate cells, and confirmation of UE capability before cell switching. They also propose enhancements to improve the efficiency and accuracy of the procedure. TDoc comparison: R1-2302731 (Lenovo) R1-2303362 (MediaTek Inc.) R1-2303456 (InterDigital, Inc.) R1-2303728 (NTT DOCOMO, INC.) - TDoc R1-2302731: Differences in timing advance (TA) command application between serving cell and candidate cell. TA command for candidate cell can only be applied after UE is switched to candidate cell. Example snippet: "the TA command associated with a candidate cell can only be applied for UL transmission after the UE is switched to the candidate cell regardless whether it is indicated before or in the cell switch command." - TDoc R1-2303362: Configuration options for power ramping and retransmission in PDCCH ordered-RACH for candidate cells without reception of RAR. Example snippet: "UE transmits PRACH for N times, where the value of N is configured in RRC or indicated in the PDCCH ordered and Whether the UE should perform power ramping is configured in RRC or indicated in the PDCCH ordered." - TDoc R1-2303456: Use of PDCCH order for TA acquisition and RACH resource configuration for candidate cells. Subset of configured cells may be activated for measurement to reduce overhead. Example snippet: "UE may autonomously keep track of the PRACH retransmissions and add a power offset to the previously used PRACH transmit power...Furthermore, the reserved bit(s) in DCI format 1_0 for PDCCH order can be used for indication of cell identity." - TDoc R1-2303728: Configuration of reference cell and offset values for UE-based TA measurement. PreambleTransMax parameter should not be used for candidate cell that may become serving cell. Example snippet: "For UE based TA measurement, the reference cell and the offset values should be configured as part of candidate configuration." 3GPP-R1-112-bis-e Agenda Item 9.11.1 : Evaluation on low power WUS
TDoc comparison: R1-2302339 (Huawei, HiSilicon) R1-2302506 (vivo) R1-2302621 (Spreadtrum Communications) R1-2302827 (InterDigital, Inc.) - TDoc R1-2302339 proposes setting the FAR target within a duration for different modulation/waveform or operation mode to align power saving gain and maintain proper FAR target within the same duration for fair comparison of other metrics. UE performs inter-frequency measurement and the MR goes back to ultra-deep sleep. - TDoc R1-2302506 presents initial simulation results of power consumption and latency for different LP-WUR/WUS schemes. Observation 4 shows that LP-WUR/WUS scheme with continuously monitoring configuration can achieve around 50%~98% power saving gain when the relative power of LP-WUR "ON" state is no more than 1 unit, with marginal latency increase. Observation 11 shows that different LP-WUR duty cycle lengths have no or less impact on UE power consumption of LP-WUS scheme, and the difference is due to the number of LP-WUR ON-OFF transition. Observation 12 shows that for LP-WUS scheme, latency will be reduced with the increase of duty cycle ratio of LP-WUS monitoring, while UE power consumption will increase accordingly. - TDoc R1-2302621 provides power consumption results for different LP-WUR transition energies and LP-WUS monitoring schemes. For Alt 2, i.e. transition energy 40000, when the LP-WUS indicates to monitor PO, the power consumption is about 46270. For Alt 2, i.e. transition energy 40000, when the LP-WUS indicates to monitor PO, the power consumption is about 50110. For Alt 1, i.e. transition energy 15000, when the LP-WUS indicates to monitor PO, the power consumption is about 21670. - TDoc R1-2302827 discusses LP-WUR frequency and time errors and proposes defining three categories of candidate values for relative power unit of LP-WUR on state. The agreed power consumption assumptions for Option 3/4 are also discussed. - Table 2 in TDoc R1-2302621 shows the relative power values for the LP-WUR. - The baseline scheme, i.e. R17 PEI RRM measurement, is illustrated in Figure 1 of TDoc R1-2302621, with neighboring-cell measurement relaxation assumed. - TDoc R1-2302339 highlights the importance of minimizing the number of MR transition from/to ultra-deep sleep since the transition costs much energy. - TDoc R1-2302506 notes that the current agreed power model for LP-WUR is typically considered for OOK or FSK detection. TDoc comparison: R1-2302331 (FUTUREWEI) R1-2302687 (CATT) R1-2302815 (Intel Corporation) R1-2302861 (Sony) - TDoc R1-2302331 proposes to study the impact of defining a shorter DRX cycle on latency and overall paging resource overhead for the evaluation of group-addressed LP-WUS. - Example snippet: "For the evaluation of group-addressed LP-WUS, study the impact of defining a shorter DRX cycle (<320 ms), i.e., for the MR to monitor POs after waking up due to reception of LP-WUS, on latency and overall paging resource overhead." - TDoc R1-2302687 presents an alternative design procedure for IDLE/INACTIVE UEs using LP-WUS, where LP-WUS replaces the function of both PEI and Paging as the direct paging indication to the UE. - Example snippet: "Figure 2 shows another design alternative of procedure for IDLE /INACTIVE UEs using LP-WUS, which the LP-WUS replaces the function of both PEI and Paging as the direct paging indication to the UE." - TDoc R1-2302815 observes significant power saving benefits for LP-WUS operation compared with IDRX and eDRX for idle/inactive mode, except when LP-WUS is always ON with ON power of e.g., 4 units. - Example snippet: "Significant benefit on power saving in LP-WUS operation are observed for both IDRX and eDRX, except when LP-WUS is always ON with ON power of e.g., 4 units." - TDoc R1-2302861 compares the power consumption of the reference scheme and the LP-WUS/WUR for different duty-cycle lengths and three paging rates and notes that the associated performance loss compared to the main receiver needs to be taken into account in the design of LP-WUS/WUR scheme. - Example snippet: "Additionally, even though the power consumption of LP-WUR is much lower than the main receiver, the associated performance loss compared to the main receiver needs to be taken into account in the design of LP-WUS/WUR scheme." - Observation 5 in both TDoc R1-2302815 and TDoc R1-2302861 notes that LP-WUS length, the amount of information it carries, and the technique used for its multiplexing in an OFDM transmitter impact the number of resources for LP-WUS transmission and its associated system overhead. - Example snippet: "LP-WUS length, the amount information it carries, and the technique used for its multiplexing in an OFDM transmitter impact the number of resources for LP-WUS transmission and its associated system overhead." - TDoc R1-2302331 and TDoc R1-2302861 provide information on the latency of LP-WUS operation, with TDoc R1-2302331 presenting a detailed formulation for latency_1, the time interval between the time for gNB transmitting LP-WUS and the time of LP-WUR detecting the LP-WUS successfully by the UE. - Example snippet: "Latency_1 is the time interval between the time for gNB transmitting LP-WUS and the time of LP-WUR detecting the LP-WUS successfully by the UE, which depends on the paging strategy in the registration area and activating MR with the detailed formulation in the following: Latency_1 = 4." TDoc comparison: R1-2302890 (Nokia, Nokia Shanghai Bell) R1-2303150 (Samsung) R1-2303429 (LG Electronics) R1-2303505 (Apple) - TDoc R1-2302890 highlights the vast difference in SNR requirements (up to 20dB) depending on the reference chosen and suggests carefully weighing the cost of reaching higher coverage against the benefits of utilizing LP-WUS at full cell coverage. The latency benefit of increasing the frequency of paging occasions associated with LP-WUS is restricted by MR wake-up related procedures if MR is assumed to be in ultra-deep sleep. LP-WUS detection performance needs to be several dBs better than that of 1RX RedCap to reach similar DL coverage. Example snippet: "Depending on the reference chosen the SNR requirement (and related NF assumption) could be vastly different, e.g. in order of 20dB. Thus, the cost (for LR and LP-WUS design) of reaching higher coverage should be carefully weigted against the benefits of being able to utilize the LP-WUS at full cell coverage." - TDoc R1-2303150 suggests that if larger drifted timing/frequency error is expected or LP-WUS is designed for high bit-rate, finer sliding granularity of LP-WUS detection should be assumed to achieve certain levels of detection performance. The on-state power of LR for OFDMA-based signal needs to satisfy relative power level within 4, and various options for reducing power consumption should be considered. Example snippet: "However, if the larger drifted timing/frequency error is expected or LP-WUS designed for high bit-rate, the finer sliding granularity of LP-WUS detection should be assumed to satisfy the requirement and achieve the certain level of detection performance." - TDoc R1-2303429 notes that LP-WUS detection and functionalities can differ for IDLE/INACTIVE and CONNECTED modes, and explicitly stating latency requirements of each use case is helpful for evaluations. LP-WUS for CONNECTED mode might be more suitable for different monitoring behavior of LP-WUR, and evaluation assumption/methodology should consider this. Example snippet: "Therefore, when deciding evaluation assumption/methodology and evaluating the LP-WUS performance, it may need to consider that LP-WUS for CONNECTED mode might be beneficial to be used for different purpose with different procedure from that for IDLE/INACTIVE mode." - TDoc R1-2303505 suggests that pushing down the power consumption of LP-WUR to a very low level depends on the required ON duration of LP-WUR and other aspects such as sensitivity and overhead. Careful consideration of mechanisms that can reduce MR wake-up probability is important, such as UE-specific WUS and offloading RRM measurement. The power saving gain relative to the baseline is provided in Figure 1 for transition energy of 15000 and 40000. Example snippet: "Whether it is necessary to push down the power consumption of LP WUR to a very low level depends on the required ON duration of LP WUR (depending on the design), and of course the other aspects should also be considered such as sensitivity and overhead." TDoc comparison: R1-2302570 (OPPO) R1-2302968 (xiaomi) R1-2303537 (Nordic Semiconductor ASA) R1-2303759 (Ericsson) - TDoc R1-2302570: Observation that LP-WUR monitoring LP-WUS under "continuously monitoring" manner has no power saving gain compared to I-DRX with PEI. - TDoc R1-2302968: Assumptions for relative power, main ratio, ultra-deep sleep, and paging cycle for LP-WUR and LP-WUS. Preliminary simulation results on impacts from frequency domain configurations for 700MHz scenario. Evaluation results for energy consumption for LP-WUS with legacy and enhanced paging mechanisms. Probability of data arrival for the first iDRX cycle. - TDoc R1-2303537: Reduction in MR+WUR consumption to <1% with offloaded measurements and reduced FAR. Suggestion to collect average energy consumption across whole DRX or eDRX. LP-WUS may have hard time matching coverage of PDCCH. Design criteria of 100ms to 10s for industrial IoT use-case latency. - TDoc R1-2303759: Resource overhead of LP-WUS candidates and examples of resources used to match paging PDCCH link budget. Overall latency depends on various parameters including WUR duty cycle, potential WUS missed detection performance, and configuration of paging occasions. Power saving evaluations for specific scenarios with different latency targets. Example snippets from original TDocs: - TDoc R1-2302570: "LP-WUR monitor LP-WUS under 'continuously monitoring' manner have not power saving gain compared to I-DRX with PEI" - TDoc R1-2302968: "Assumptions not listed are the same as TR 38.840 Table 6: Evaluation assumptions for RRC idle/inactive" - TDoc R1-2303537: "When measurements are offloaded, FAR is reduced from 1%->0.1%, and with comparable latency, it is possible to reduce consumption of MR+WUR down to <1% of MR." - TDoc R1-2303759: "When assuming additional WUR synchronization signal resources, the total overhead will be increased." 3GPP-R1-112-bis-e Agenda Item 9.11.2 : Low power WUS receiver architectures
TDoc comparison: R1-2302891 (Nokia, Nokia Shanghai Bell) R1-2302949 (ZTE, Sanechips) R1-2303506 (Apple) R1-2303613 (Qualcomm Incorporated) - TDoc R1-2302891 proposes a standard model for the baseband section to ensure fair comparison of power consumption between receiver architectures. - Observation 3 highlights that the reference oscillator uncertainty affects the ability of the Zero-IF and Heterodyne receivers with IF Envelope detection to maintain the ideal center frequency. - LP-WUR hardware aspects for maintaining timing and frequency synchronization and accommodating fading in mobility are considered. - The study assumes flexible multi-band support for LP-WUS functionality in different bands. - TDoc R1-2302949 discusses the link level performance of sequence-based modulation based on two different receivers. - Observation 4 states that the frequency to amplitude conversion receiver architecture must ensure an obvious amplitude difference between multiple frequency ranges to detect FSK signal caused by frequency drift of LO. - Observation 7 notes that the use of a lower power consumption oscillator as LO may degrade the reception performance of FSK receivers using a quadrature frequency discriminator. - TDoc R1-2303506 describes the architecture for multi-tone OOK-3 as different from other OOK options due to its inability to rely on envelope detection within a contiguous bandwidth. - The interference suppression for interference from legacy NR signals and/or other LP WUS on adjacent subcarriers requires very high-Q matching network and/or RF BPF, which is challenging due to the high Q values and may require off-chip components. - The Goertzel processing used in the non-coherent detector simplifies the processing compared to FFT-based detectors. - TDoc R1-2303613 suggests that LP-WUR study is a good choice for LAN environments that require less strict requirements in terms of sensitivity, selectivity, clock accuracy, etc. - Observation 1 highlights that the degraded sensitivity of RF-ED receiver could limit the coverage of LP-WUS and that RF-ED receiver has difficulty supporting multi-band due to the necessity of band-specific high Q RF filter, which is challenging to achieve. Example snippets from the original TDocs: - From TDoc R1-2302891: "... a standard model for the baseband section should be applied in the current consumption budget, that defines what functional blocks are to be assumed (e.g., AGC, time/frequency control)." - From TDoc R1-2302949: "For the detection of ZC-sequence based signal, if DL synchronization can be ensured for sequence-based OFDM signal receiver, FFT process is not necessary in digital BB processing." - From TDoc R1-2303506: "The architecture for multi-tone OOK-3 is somewhat different from that of the other OOK options, as it cannot rely on envelope detection within a contiguous bandwidth." - From TDoc R1-2303613: "Having LP-WUR for only cell center UE (i.e., mismatch case) will increase the battery life imbalance even further, resulting in very uneven user experience in terms of battery life." TDoc comparison: R1-2302391 (Panasonic) R1-2302816 (Intel Corporation) R1-2303333 (MediaTek Inc.) R1-2303760 (Ericsson) Technical Differences among TDocs: - TDoc R1-2302391 proposes that for the design of LP-WUS, only heterodyne and homodyne/zero-IF architecture should be taken into account for power model and requirement study. UE with RF envelope detector architecture is not prevented in implementation. - TDoc R1-2302816 highlights that interference suppression for interference from legacy NR signals and/or other LP WUS on adjacent subcarriers, if performed in RF, requires very high-Q matching network and/or RF BPF, which is challenging due to the high Q values and may require off-chip components. The agreed OOK receiver architectures for study in RAN1#110bis-e can be captured in the TR. - TDoc R1-2303333 suggests that the potential power reduction compared to the main radio may come from lower performance LNA/amplifier, oscillator/PLL with relaxed performance requirements, ADC with lower sampling rate and smaller bit-width, and reduced BB processing complexity compared to the MR. The agreed OOK receiver architectures for study in RAN1#110bis-e can be captured in the TR. - TDoc R1-2303760 highlights the need to FFS the support of band and/or carrier tuning and further study the receiver architectures for FSK. The agreed OOK receiver architectures for study in RAN1#110bis-e can be captured in the TR. Examples: - TDoc R1-2302391: Example 1 for FSK modulation suggests that each path can be implemented using either the architecture with RF envelope detection, heterodyne architecture with IF envelope detection, or homodyne/zero-IF architecture with baseband envelope detection. - TDoc R1-2302816: A homodyne architecture receiver with frequency to amplitude conversion requires I/Q branches for frequency to amplitude conversion in digital BB. - TDoc R1-2303333: RAN1 should consider adding I/Q branches in the homodyne/zero-IF architecture with baseband envelope detection to improve the system's robustness and handle multi-path channels and frequency errors caused by low accuracy LO and not using PLL. - TDoc R1-2303760: Example 1 for FSK modulation suggests that each path can be implemented using either the architecture with RF envelope detection, heterodyne architecture with IF envelope detection, or homodyne/zero-IF architecture with baseband envelope detection. Interference suppression for interference from legacy NR signals and/or other LP WUS on adjacent subcarriers may require off-chip components. TDoc comparison: R1-2302571 (OPPO) R1-2303729 (NTT DOCOMO, INC.) [TDoc R1-2302571]: - RAN4 wants clarifications from RAN1 on LP-WUR design for IoT/wearables/smartphone UE types - Power consumption, coverage, and SNR targets need to be specified - Max occupied RB number in channel bandwidth for LP-WUS for 1.4MHz and 5MHz RF bandwidth case - Possible supported SCS for LP-WUS - Whether WUS can be located in a separate band from UE's NR band - FR1 is considered as first priority frequency range - In-band power boosting of LP-WUS is considered from RAN1 perspective Example snippet: "Whether IoT/wearables/smartphone UE types are all considered for LP-WUR design" [TDoc R1-2303729]: - Different LP-WUR architectures and corresponding signal design provide different coverage performance - LP-WUS deployment scenarios should be clarified for further de-prioritization of LP-WUR architecture - Existing ACS requirement should be reused as a start point for further LP-WUR performance evaluation - LP-WUS/WUR may provide higher UE power saving gain and cost/complexity is one of the important aspects to study further Example snippet: "LP-WUS/WUR may provide higher UE power saving gain and cost/complexity is one of the important aspects to study further." TDoc comparison: R1-2302507 (vivo) R1-2302688 (CATT) R1-2302828 (InterDigital, Inc.) R1-2303151 (Samsung) TDoc R1-2302507: - Table 1 summarizes differences in receiver architectures for OOK detection, including hardware, power consumption, sensitivity, interference rejection, guardband requirements, and multi-band capability. - Heterodyne architecture with IF envelope detection has a reported sensitivity of -83dBm~-97dBm with data rates of tens of kbps to several Mbps and power consumption in the hundreds of uw. - Homodyne/zero-IF architecture with BB envelope detection uses a matching network and a BPF at RF to filter the input RF signal. TDoc R1-2302688: - ACI and ACSI may be suppressed differently in three types of LP-WUR architectures. - The ASK and FSK modulation with CP-OFDM waveform have lower interference injection capability. - MC-ASK with CP-OFDM waveform is more sensitive to PAPR than FSK with CP-OFDM waveform and OFDM-based signal waveform. - OOK modulation scheme has a simple receiver architecture for low power consumption and feasible for all three types of LP-WUR architectures. TDoc R1-2302828: - Utilizing lower performance components such as lower performance amplifier, oscillator, and reduced BB processing complexity can potentially reduce power consumption. - A dual-IF wake-up receiver OOK modulated and centered at 2.4GHz achieved -97dBm of sensitivity with an average power consumption of 100μW. - A receiver-based frequency locked loop achieved a sensitivity of -83 dBm at 227 μW. - Using a low-power ring oscillator for the heterodyne receiver can significantly reduce the LO stage power consumption at the cost of an increase in frequency error/offset. - The performance impact from power reduction and degree of power reduction in the OFDMA receiver is not clear. TDoc R1-2303151: - The heterodyne architecture with IF envelope detection architecture and the homodyne/zero-IF architecture with baseband envelope should be evaluated based on a tradeoff between power consumption and performance. - Further study is needed on the relative power consumption and noise figure of the LP-WUS based on the value defined for evaluation according to different types of receiver architecture. - The LNA dominates in terms of power consumption, and the value can be 27~35 μW. 3GPP-R1-112-bis-e Agenda Item 9.12.1 : PRACH coverage enhancements
TDoc comparison: R1-2302350 (Huawei, HiSilicon) R1-2302509 (vivo) R1-2302573 (OPPO) R1-2302623 (Spreadtrum Communications) R1-2302690 (CATT) R1-2302759 (ZTE) R1-2302818 (Intel Corporation) R1-2302863 (Sony) R1-2302970 (xiaomi) R1-2303034 (China Telecom) R1-2303090 (Lenovo) R1-2303209 (Quectel) R1-2303353 (MediaTek Inc.) R1-2303508 (Apple) - TDoc R1-2302350 proposes reusing the Rel-17 framework of feature combination and additional RACH configuration to realize the PRACH resource partitioning of separate preamble solution, where different repetition levels of multiple PRACH transmissions are regarded as different feature IEs in the RRC FeatureCombination-r17. It also points out that different and unknown phase rotation makes it impossible to detect the coherent combining of multiple PRACH receptions. - TDoc R1-2302509 suggests that for shared RO configuration, the time span of one RO group is a multiple of SSB to RO mapping cycles, which could be much larger than the channel coherent time or the RAR monitoring time. It proposes supporting the combination of PRACH repetition and Msg3 repetition to achieve a robust random access procedure for coverage-constraint UEs. - TDoc R1-2302573 proposes that Msg3 transmission power can be calculated based on the power ramping of one or all the PRACHs of multiple PRACH transmission in a RACH attempt. - TDoc R1-2302623 suggests that RO/preamble resource partitioning is required to differentiate the multiple PRACH transmissions with single PRACH transmission. It also proposes using consecutively available UL slots associated with the same SSB index for transmitting consecutive PRACH repetitions for low latency and complexity. - TDoc R1-2302690 proposes introducing a PRACH frequency offset to determine the frequency position of two hops along with the offset of the lowest PRACH transmission occasion in the frequency domain relative to PRB 0 when PRACH hopping is enabled. It also suggests separating the SSB-RSRP thresholds used to determine the number of PRACH transmissions from the SSB-RSRP thresholds used for SSB selection. - TDoc R1-2302759 proposes using multiple SSB-RSRP thresholds to determine the number of multiple PRACH transmissions, with the thresholds associated with the values for the number of multiple PRACH transmissions. It also suggests considering multiple PRACH transmissions with different beams for PRACH coverage enhancement. - TDoc R1-2302818 suggests that configuring shared ROs with separate PRACH preambles for the differentiation of single and multiple PRACH transmissions can reduce the RO overhead and improve spectrum efficiency. - TDoc R1-2302970 proposes reducing random access delay by properly configuring SSB-to-RO mapping ratio, PRACH configuration index, FDMed ROs, and the number of SSBs in SSB burst. - TDoc R1-2303209 proposes mapping SSB indexes to ROGs for multiple PRACH transmissions in increasing order of preamble indexes within a ROG, increasing order of frequency resource indexed for frequency multiplexed ROGs, increasing order of time resource indexed for time multiplexed ROGs within a PRACH slot group, and increasing order of indexes for PRACH slot groups. It also introduces a set of new RACH resources for multiple PRACH transmissions in a single configuration period. - TDoc R1-2303508 suggests determining the RA-RNTI according to the last preamble transmission and transmitting multiple PRACH with separate preamble on shared ROs to differentiate them from TDoc comparison: R1-2302880 (Nokia, Nokia Shanghai Bell) R1-2302885 (Panasonic) R1-2302915 (Fujitsu) R1-2303661 (Ericsson) [TDoc R1-2302880]: - The blue UE experiences a larger degree of frequency diversity compared to the other 3 UEs. - The current framework for mapping ROs-to-SSB indices does not allow configurations of consecutively available UL slots associated to a same SSB index for transmitting consecutive PRACH repetitions. - One way for optimization of the SSB-to-RO mapping enabling consecutively available UL slots for transmitting the multiple PRACH transmissions while limiting the number of SSB indexes per time occasion would be to somehow make sure that the mapping occurs firstly in the time domain and, only when a certain time occupation is reached, continue the mapping in the frequency domain. - This may impact the number of the ROs actually used in a RO group and reduce the overall effective number of PRACH repetitions. [TDoc R1-2302885]: - When only one RAR window for all of the multiple PRACH transmissions is applied based on the agreement, a single RA-RNTI candidate for the multi-PRACH transmission can be calculated based on the alternatives. - The purpose of scheme 2 is to achieve a combined detection gain, hence it can be applied to a scenario of using the same beam for the multi-PRACH transmission. - For unpaired spectrum, there can be 2 alternatives for a separate RO. - FFS on detailed indication. [TDoc R1-2302915]: - The shared ROs case may have severe high contention rate and lack of preamble to be transmitted in both transmissions, especially in FR2 case due to the larger number of corresponding SSBs. - For the calculation of the RA-RNTI, the first or last PRACH of the multiple PRACHs in one RACH attempt should be referred. - The gNB has a difficulty to configure the RAR window start timing when the gNB misses one or more PRACHs in the multiple PRACH transmissions from UE. - Therefore, the power ramping should be firstly performed prior to increase the number of the multiple PRACH transmission at the second and further RACH attempt. [TDoc R1-2303661]: - Another solution is to configure both SSB RSRP thresholds and power headroom thresholds, a UE can determine a number of PRACH transmissions based on each of the two criteria and select the smaller value. - It is beneficial from the perspective of configuration complexity and resource efficiency that RACH resources for legacy partitions and Rel-18 features can be configured with a unified solution. - With the same measured SSB RSRP and pathloss, UEs of different power classes may transmit a single PRACH with different output power, resulting in divergent PRACH performances. Example snippets: - "One way for optimization of the SSB-to-RO mapping enabling consecutively available UL slots for transmitting the multiple PRACH transmissions while limiting the number of SSB indexes per time occasion would be to somehow make sure that the mapping occurs firstly in the time domain and, only when a certain time occupation is reached, continue the mapping in the frequency domain." (TDoc R1-2302880) - "For the calculation of the RA-RNTI, the first or last PRACH of the multiple PRACHs in one RACH attempt should be referred." (TDoc R1-2302915) - "It is beneficial from the perspective of configuration complexity and resource efficiency that RACH resources for legacy partitions and Rel-18 features can be configured with a unified solution." (TDoc R1-2303661) TDoc comparison: R1-2303086 (Mavenir) R1-2303453 (InterDigital, Inc.) R1-2303731 (NTT DOCOMO, INC.) - TDoc R1-2303086 proposes separation of preambles for multiple PRACH transmissions and legacy single PRACH transmission on additional ROs by configuring FeatureCombinationPreambles-r17. - Example snippet: "the ‘RO group’ should be configured within the additional RACH configuration." - TDoc R1-2303086 suggests that the starting position of 2 PRACH transmissions can be the first RO or third RO in the ‘RO group’. - Example snippet: "if these ROs are valid." - Proposal 3 of TDoc R1-2303086 suggests that if RAR window starts after the end of the last PRACH transmission, RA_RNTI could correspond to any one PRACH transmission, and for simplicity, the first or the last valid RO in one RO group. - TDoc R1-2303453 proposes using at least SSB-RSRP threshold to determine the number of PRACH transmissions. - Example snippet: "The gNB can configure the UE with multiple SSB-RSRP thresholds where each threshold is associated with different number of PRACH transmissions." - TDoc R1-2303453 suggests considering options to differentiate multiple PRACH transmissions with single PRACH transmission. - Example snippet: "For multiple PRACH transmissions with same Tx beam, RA-RNTI association with multiple PRACH resources needs to be discussed." - TDoc R1-2303453 proposes the use of "RO group" for multiple PRACH transmissions with separate preamble on shared ROs and/or multiple PRACH transmissions on separate ROs. - TDoc R1-2303731 proposes that if gNB can only perform joint detection for multi-PRACH, it needs to try to detect multi-PRACH in multiple RO groups with different preamble resource. - Example snippet: "gNB is not certain about the exact RO group location before decoding the preamble." - Proposal 8 of TDoc R1-2303731 suggests that for multiple PRACH transmissions with same Tx beam in one RACH attempt, transmission power is the same during the multiple PRACH transmissions. TDoc comparison: R1-2303153 (Samsung) R1-2303206 (ETRI) R1-2303256 (CMCC) R1-2303411 (FGI) - TDoc R1-2303153: Discusses the need to keep the same calculated Tx power for all PRACH transmissions in one attempt, and proposes determining the RO group pattern based on the RO pattern for each associated SSBs within the SSB-RO association pattern period. Example snippet: "In order to keep the same calculated Tx power for all PRACH transmissions in one attempt, the same measurement of the same reference signal to calculate the pathloss should be applied." - TDoc R1-2303206: Discusses the behavior of a UE not decoding Msg2 PDSCH before PRACH transmission is completed, and proposes utilizing multiple PRACH transmissions for contention resolution and coverage extension. Example snippet: "The UE can change the PRACH beam during multiple transmissions, then it is beneficial for both contention resolution and coverage extension." - TDoc R1-2303256: Discusses the relationship between legacy RO and RO used to transmit PRACH repetitions, and proposes studying PRACH transmissions with different beams for 4-step RACH procedure. Example snippet: "The second issue is to study, and if justified, specify PRACH transmissions with different beams for 4-step RACH procedure." - TDoc R1-2303411: Discusses the determination of the actual number of times for multiple PRACH transmissions, and proposes reserving and configuring multiple sets of ROs for potential multiple PRACH transmission for different number of times' cases. Example snippet: "UE needs to be reserved and configured with multiple sets of ROs for potential multiple PRACH transmission for different number of times’ cases." 3GPP-R1-112-bis-e Agenda Item 9.12.2 : Power domain enhancements
TDoc comparison: R1-2302351 (Huawei, HiSilicon) R1-2302510 (vivo) R1-2302574 (OPPO) R1-2302624 (Spreadtrum Communications) R1-2302691 (CATT) R1-2302864 (Sony) R1-2302881 (Nokia, Nokia Shanghai Bell) R1-2302916 (Fujitsu) R1-2302971 (Xiaomi) R1-2303035 (China Telecom) R1-2303154 (Samsung) Technical Differences among TDocs: - TDoc R1-2302351: Compares the number of sequences containing zero elements in approach A1 and approach A2 when the inband+extension length is less than 30. Approach B (Type 2 DMRS) has the same demodulation performance as approach A2. The power density of REs cannot be regarded as random variables with the same expectation due to the used filter. The gNB should indicate the RB allocation of non-extension spectrum, spectrum extension ratio, and MCS index to UEs. - TDoc R1-2302510: Type 1 DMRS sequence has similar and slightly higher power boost for Per-RB and Per-RE solutions for QPSK modulated PUSCH. Per-RE solution has the best DMRS CM performance for QPSK modulated PUSCH. FDSS with spectrum extension is proposed to improve demodulation performance. - TDoc R1-2302574: Type 1 DMRS sequence is preferred due to BLER performance degradation and additional limitations in Type 2 DMRS sequence. DMRS sequence is per RB extended in Approach A.1 for FDSS-SE. - TDoc R1-2302624: Approach A.1-c changes the correlation performance of the sequence, leading to a negative impact on PAPR/CM. Low PAPR Type 1 DMRS sequence is generated based on computer-generated sequences (CGS) when RB allocations result in DMRS sequence length smaller than 30 before extension of the sequence. - TDoc R1-2302691: Evaluates PAPR and CM performance for DMRS and data considering different DMRS sequence generation approaches. Type 2 DMRS sequence leads to BLER performance degradation and additional limitations compared to Type 1 DMRS sequence. Approach A.1 with per RB extension and Approach B.1 lead to higher PAPR and CM of DMRS compared to that of data for FDSS-SE. - TDoc R1-2302864: In tone reservation, some tones are reserved for the UE to reduce the amplitudes of any peaks in its output OFDM symbol waveform. A tone puncturing pattern is known by the gNB to declare erasures when TR PAPR is active for the data bits originally meant to be transmitted in the punctured tones. The UE iteratively selects N tones and tests the effect of reserving these in the PAPR. - TDoc R1-2302881: Several possibilities for UE power class reporting are sustainable duty cycle, duration of evaluation period for the transmitted UL symbol percentage, UE-recommended maxUplinkDutyCycle value, and PHR-triggered evaluation of transmitted UL symbols exceeding a configured threshold lower than the duty cycle limit. - TDoc R1-2302916: Energy headroom report provides remaining available power information considering the SAR and can avoid the occurrence of PC fallback and P-MPR by gNB scheduling. Further standardization of increasing gNB awareness of UE’s Tx power is proposed. P-MPR reporting in FR1 due to SAR requirements and UE-recommended maxUplinkDutyCycle value are meaningful approaches. - TDoc R1-2303035: Type 2 FDSS and higher modulations are proposed for better MPR/PAR reduction gain. The repeated data can be combined with original signals in the MMSE receiver for FDSS type 2. DMRS and data are generated and extended separately, increasing the generation process complexity. - TDoc R1-2303154: Aspects related to increased transmit power corresponding to PAPR gains, availability of coverage-limited UE to transmit at a higher power, and potential impact on gNB implementation are discussed. Further discussion on gains of MPR/PAR reduction techniques and potential impact on gNB implementation is proposed. SAR evaluation for UEs capable of transmitting with an aggregated power over two component carriers would be a RAN4 discussion. Example snippets from original TDocs: - TDoc R1-2302351: "The gNB should indicate the RB allocation of non-extension spectrum, spectrum extension ratio, MCS index to UEs, based on which the UEs calculate the size of transport block." - TDoc R1-2302510: "For Type 1 DMRS sequence, it is observed that Approach A.1 with per RB extension and Approach B.1 lead to higher PAPR and CM of DMRS compared with that of data for FDSS-SE." - TDoc R1-2302574: "Considering the BLER performance degradation and the additional scheduling restriction of Type 2 DMRS sequence, Type 1 DMRS sequence is preferred." - TDoc R1-2302624: "Low PAPR Type 1 DMRS sequence is generated based on computer-generated sequences (CGS) when RB allocations result in DMRS sequence length smaller than 30 before extension of the sequence." - TDoc R1-2302691: "Type 2 DMRS sequence leads to BLER performance degradation and additional limitation that the number of PRBs in the inband and extension band must be valid DFT sizes compared with Type 1 DMRS sequence." - TDoc R1-2302864: "The UE iteratively selects a given N tones and tests the effect of reserving these in the PAPR by calculating a figure of merit such as EVM for the resulting peak clipped OFDM symbol." - TDoc R1-2302881: "UE recommended maxUplinkDutyCycle value that would prevent triggering a power class fallback." - TDoc R1-2302916: "It reports the remaining available power information considering the SAR and then it can avoid the occurrence of PC fallback and P-MPR by gNB scheduling." - TDoc R1-2303035: "DMRS and data will be generated and extended separately, which increases the complexity of the generation process." - TDoc R1-2303154: "Further discuss the gains of MPR/PAR reduction techniques, and potential impact on gNB implementation." TDoc comparison: R1-2303257 (CMCC) R1-2303616 (Qualcomm Incorporated) R1-2303662 (Ericsson) R1-2303767 (Sharp) [TDoc R1-2303257]: - UE may report how much energy it has left to transmit during a period based on power class, SAR limitation, and UL scheduling. - A UE can support a different power class than the default for the band, and if the percentage of uplink symbols transmitted in a certain evaluation period is larger than 50%, it may fallback to the default power class. - Introducing a scheme for a UE to report uplink symbol evaluation period and starting timing could be helpful but would have significant spec impacts and workload. [TDoc R1-2303616]: - The UE can determine available RF exposure for a certain period, and use this exposure limit in a flexible manner while adhering to power control settings. - Classical techniques reduce a waveform's PAPR and other characteristics for lower modulation order waveforms. [TDoc R1-2303662]: - In order to determine the net performance benefit of MPR reduction schemes, it is necessary to consider both the effects of non-linearities in RF simulation and of baseband aspects like channel estimation, code rates, and spectrum shaping. - Results of RF simulations with the impact of BLER accounted for were shown for transparent schemes to study the behavior of MPR reduction and the factors it depends on. - A two-step approach is used where RF simulations are first run to determine the amount of backoff in dB needed by the PA to meet various transmit signal quality requirements. [TDoc R1-2303767]: - P-MPR provides more information to the network compared to reporting only the current power class or power class change. - The SE defined outside of the frequency resource allocated by FDRA would lead to different spectrum masking for with and without the spectrum extension. - Compliance with SAR and PD regulatory requirements requires taking into account transmissions with all the RATs that the UE has used in all frequencies below or above 6GHz. TDoc comparison: R1-2302760 (ZTE) R1-2302787 (Intel Corporation) R1-2302886 (Panasonic) R1-2303777 (Indian Institute of Tech (H)) • TDoc R1-2302760 introduces the use of Type 2 DMRS sequence with approach A to reduce UE complexity for FDSS operations. It also provides PAPR/CM evaluation results for 40RBs (after extension) with SE=1/4. Example snippet: "But Type 2 DMRS sequence with approach A ensures the same extension operation between DMRS and data which can reduce UE complexity for FDSS operations. PAPR/CM evaluation results for 40RBs (after extension) with SE=1/4." • TDoc R1-2302787 discusses the design trade-off between various DMRS options for low PAPR Type 1 and Type 2 sequences. It notes that both the number of PRBs in the inband and the number of PRBs in the inband+extension must be valid DFT sizes as per NR specification. It also provides simulation assumptions for DMRS design extension. Example snippet: "Based on the observations, it is evident that certain design trade-off exists between various DMRS design options for low PAPR Type 1 and Type 2 sequences, especially considering the PAPR/CM and link level performance...Note: if type 2 is used then both the number of PRBs in the inband and the number of PRBs in the inband+extension must be valid DFT sizes as per NR specification...Simulation assumptions for DMRS design extension." • TDoc R1-2302886 discusses the possibility of using the current values of bandwidth configuration of the FDSS in the existing specifications for the FDSS with SE. It provides examples of the diagram of NR UL transmitter supporting FDSS and SE and the determination of the SE part and non-SE part. Example snippet: "For simplicity, we can select the possibility B such that the current values () of bandwidth configuration of the FDSS in the existing specifications can be reused to the FDSS with SE by just using the calculations of and when a feature of the FDSS with SE is configured/triggered...For instance, Fig. 1 shows an example of diagram of NR UL transmitter supporting FDSS and SE, wherein the whole bandwidth of the SE part and non-SE part is expressed as , where denotes the bandwidth of non-SE part, named as possibility A." • TDoc R1-2303777 reiterates the requirement for valid DFT sizes when using Type 2 DMRS sequence with approach A and approach B. It also provides performance metrics for PAPR, CM, OBO, and 10% BLER SNR for data. Example snippet: "Note: if type 2 is used then both the number of PRBs in the inband and the number of PRBs in the inband+extension must be valid DFT sizes as per NR specification...Performance metrics considered for the study are PAPR, CM[, and OBO] for DMRS and 10% BLER SNR for data (to measure channel estimation accuracy)." • TDoc R1-2302760 and R1-2303777 share the same example snippet regarding performance metrics considered for the study. Example snippet: "Performance metrics considered for the study are PAPR, CM[, and OBO] for DMRS and 10% BLER SNR for data (to measure channel estimation accuracy)." • TDoc R1-2302787 includes figures and observations on Approach A with cyclic extension and symmetric extension for DMRS sequence generation, as well as the performance metrics considered for the study. Example snippet: "From the figures, it can be observed that For both low PAPR Type 1 and Type 2 DMRS sequences, Approach A with SE and Approach B with PSF can achieve better PAPR and CM performance than Approach A with CE based on the agreed assumption of spectrum shaping filters. Figure 3 illustrates Approach A with cyclic extension and symmetric extension for DMRS sequence generation, respectively...Performance metrics considered for the study are PAPR, CM [, and OBO] for DMRS and 10% BLER SNR for data (to measure channel estimation accuracy)." • TDoc R1-2302760 includes a subsection providing evaluation results in case the sequence length before extension is less than 30. Example snippet: "In this subsection, we provide the evaluation results in case the sequence length before extension is less than 30, i.e., the number of PRBs after extension is 6." • TDoc R1-2302760 and R1-2303777 share the same note regarding the use of Type 2 DMRS sequence with approach A and approach B. Example snippet: "Note: if type 2 is used then both the number of PRBs in the inband and the number of PRBs in the inband+extension must be valid DFT sizes as per NR specification...Note: Other sequences are not precluded for Approach A and Approach B." • TDoc R1-2302760 includes a PHR reporting enhancement with a certain duration for the applicability of power classes. Example snippet: "PHR reporting enhancement with a certain duration for the applicability of one among {the fallback power class ∆PPowerClass (potentially with a finer granularity), the default power class, or Pc,max}. Note that, it is not preferred to specify a certain duration for the applicability of the power class other than the default UE power class (e.g., PC2)." • TDoc R1-2302787 includes the observation that the extension factor α can be considered as a tradeoff between the achievable reduction of MPR/PAR and the achievable spectral efficiency. Example snippet: "Observation 1: The extension factor α can be considered as a tradeoff between the achievable reduction of MPR/PAR and the achievable spectral efficiency." • TDoc R1-2303777 includes a comparison of the baseline QPSK data (without FDSS_SE) and the gain of around 2.8dB for the 3-tap filter for RS. Example snippet: "Compared to the baseline QPSK data (without FDSS_SE), there is a gain of around 2.8dB for the 3-tap filter for RS. The spectrum for the above-mentioned filters is presented in Fig. 1." TDoc comparison: R1-2303091 (Lenovo) R1-2303354 (MediaTek Inc.) R1-2303509 (Apple) R1-2303732 (NTT DOCOMO, INC.) • TDoc R1-2303091: - Two approaches for DMRS when sequence length is ≥30 PRBs. - Approach A generates DMRS sequence based on number of PRBs in inband, with potential extension. - Discussion needed on how DMRS sequence extension should be done. - Example snippet: "DMRS sequence is generated considering the number of PRBs in the inband (no extension)...how the DMRS sequence is extended should be discussed further." • TDoc R1-2303354: - Proposal 1 suggests discussing FDSS without spectrum extension in RAN4. - No significant link performance loss expected in FDSS without spectrum extension. - Different spectrum extension types and factors considered by companies. - Example snippet: "No significant link performance loss is expected in FDSS without spectrum extension as coding rate remains the same...Different spectrum extension types and factors were considered by companies." • TDoc R1-2303509: - Two non-transparent solutions for MPR/PAR reduction currently under discussion in RAN1. - PAPR/CM of DMRS being studied with tone reservation as candidate enhancement for MPR/PAR reduction in Rel-18. - DMRS sequence extension approach considered when sequence length is <30 PRBs. - Example snippet: "The following non-transparent solutions for MPR/PAR reduction are currently under discussion in RAN1...If FDSS-SE is supported in Rel-18, and RB allocations resulting in DMRS sequence length smaller than 30 before extension of the sequence, if any, are supported..." • TDoc R1-2303732: - UE may or may not be able to perform inter-band CA and inter-band EN-DC with summation of maximum transmit powers, depending on percentage of uplink symbols transmitted in a certain evaluation period. - Objective of RAN1 work needs to be clarified. - Observation of RAN4 specifications regarding high power transmission in single band and across multiple bands. - Example snippet: "It means, depending on 'the average percentage of uplink symbols transmitted in a certain evaluation period', UE may or may not be able to perform inter-band CA and inter-band EN-DC with the summation of maximum transmit powers for the aggregated band." 3GPP-R1-112-bis-e Agenda Item 9.13.1 : UE capability and RRC signaling for UAV beamforming
TDoc comparison: R1-2303511 (Apple) R1-2303734 (NTT DOCOMO, INC.) Meeting [TDoc R1-2303511]: - Proposal 2 suggests supporting height-threshold for triggering TCI states for uplink beam indication in FR1 for UAV UEs. Below the threshold, omni-directional beamforming is expected. Timing related parameters for beamforming in FR2 will need to be reevaluated for FR1, especially for lower SCS such as 15kHz and 30kHz. - Proposal 1 suggests considering height-dependent indication of beams based on beam switching among fixed directional antennas for UAV UEs in FR1. It also recommends using the Rel-17 unified TCI framework as the baseline for indication of beams. - The enhancements proposed in RAN2 include UE-triggered measurement report based on configured height thresholds, reporting of height, location and speed in measurement report, flight path reporting, and measurement reporting based on a configured number of cells fulfilling the triggering criteria simultaneously. This builds upon the work done in LTE as a starting point for this objective. [TDoc R1-2303734]: - It was agreed to study extending FR2-only beam management parameters, such as spatial relation and beam correspondence, to FR1 for UAV UEs. - Proposal 2 suggests discussing a suitable range of values for minBeamApplicationTime-r17 for FR1 UAV UE, taking into account FR1 SCSs and fast beam application requirements. Capabilities for unified TCI with joint DL/UL TCI update are available and can be used for FR1 UAV UE. Large values are mainly for large SCSs, so candidate values can be limited to smaller values for FR1 UAV UE assuming smaller SCSs. - It is not yet clear how to utilize beam characteristics information, such as number of beams, beamwidth, beam center, radiated EIRP, etc., at the network level. Example snippets from the original TDocs: - "The height-threshold based trigger for UAV UE may be supported in FR1 where the UE may perform only omni-directional beamforming below a certain height-threshold, and the UE may support triggering activation/indication of TCI states for uplink beam indication when UE is above the height-threshold." (TDoc R1-2303511) - "In order to support the indication of beams for UAV UEs in FR1, a height-dependent indication of beams using beam switching among fixed directional antennas can be considered." (TDoc R1-2303511) - "UE-triggered measurement report based on configured height thresholds can be considered for UAV UEs in FR1, in addition to reporting of height, location and speed in measurement report, flight path reporting, and measurement reporting based on a configured number of cells fulfilling the triggering criteria simultaneously." (TDoc RAN2) - "The unified TCI framework with joint DL/UL TCI update can be used to support the minimum beam application time for FR1 UAV UE." (TDoc R1-2303734) - "It is not clear yet on how to utilize such beam characteristics information, and further study is needed." (TDoc R1-2303734) TDoc comparison: R1-2302345 (Huawei, HiSilicon) R1-2302866 (Sony) R1-2303298 (ZTE) Technical Differences among TDocs on UE Capability Signaling for Beam Management: [TDoc R1-2302345]: - Agreement on supporting new UAV UE beamforming capabilities and considering Rel-17 unified TCI framework as baseline - Introducing directional antenna indication enabling beam switching as a candidate direction for UAV UE capability signaling for beam characteristics - Spec-transparent Rx beam sweeping and reporting largest RSRP corresponding to best Rx beam during handover - Spec-transparent directional antenna architecture with narrower beamwidth can be considered to enlarge handover range and confine interference [TDoc R1-2302866]: - Proposal to support FR1 capability information containing number of beams, beam center directions, and post-antenna connector gain of UAV UEs - Proposal to support reporting of UAV UE's orientation to network as part of location information - Refinement of beam management procedure and extension to FR1 in future 3GPP UAV releases with dedicated RAN1, RAN2, and RAN4 involvement - Orientation information can enhance network performance in FR2 [TDoc R1-2303298]: - Coupling of beam and antenna to enable beam management - Use of "spatial domain transmission filter" to describe beam used at UE side and corresponding switching of beam specified as behavior according to indicated QCL or spatial relationship for DL and UL - Update of beam capability and configuration for beam management can be considered in height-dependent way Example Snippets from Original TDocs: - "If the target scenarios and the potential issues are justified and ineffectiveness of existing techniques are proved, new UAV UE beamforming capabilities can be supported" (TDoc R1-2302345) - "UAV can perform spec-transparent Rx beam sweeping and report the largest RSRP corresponding to its best Rx beam during handover" (TDoc R1-2302345) - "The proposed UE capability and associated RRC signaling for UAV beamforming in 3GPP RAN1 on UAV can provide a standardized approach for enabling this feature" (TDoc R1-2302866) - "The update of the beam capability, e.g., number of support beam, along with following configuration for beam management can be considered in height-dependent way" (TDoc R1-2303298) TDoc comparison: R1-2302732 (Lenovo) R1-2303785 (Ericsson) • TDoc R1-2302732 discusses the Rx beam changes that a UE can conduct during a slot across the whole band CC. It includes three technical differences: - CSI-RS beam switching timing: This refers to the minimum time between the DCI triggering of AP-CSI-RS and aperiodic CSI-RS transmission. - PDSCH beam switching: This involves the time duration required to determine and apply spatial QCL information for corresponding PDSCH reception. - Beam application time: This refers to the minimum beam application time between HARQ-ACK of the beam indication DCI and the first slot to apply the indicated TCI state. Example snippets from the original TDoc to support the difference highlighting: - "The time duration to determine and apply spatial QCL information for corresponding PDSCH reception is referred to as PDSCH beam switching time." - "The minimum beam application time between HARQ-ACK of the beam indication DCI and the first slot to apply the indicated TCI state is referred to as the Beam application time." • TDoc R1-2303785 proposes not to introduce new UE capabilities to support beam switching among fixed directional antennas of a UE. The technical difference discussed in this TDoc is the maximum number of Tx. Example snippets from the original TDoc to support the difference highlighting: - "Based on the above analysis, we propose not to introduce new UE capabilities to support beam switching among fixed directional antennas of a UE." - "The maximum number of Tx to be supported is different for FR1 and FR2." • The WID (work item description) includes an objective for UE capability signaling to indicate UAV beamforming. RAN1#112 made the following agreements: - "In this contribution we present our views on the open issues." - "Another open issue is whether new UE capabilities need to be introduced in FR1 to support beam switching among fixed directional antennas of the UAV." Example snippets from the original TDoc to support the difference highlighting: - "The objective of this work item is to specify the necessary UE capability signaling to indicate UAV beamforming support and related parameters." - "The open issues include establishing the requirements for UE capability signaling to indicate UAV beamforming support, as well as the necessary UE capabilities to support beam switching among fixed directional antennas of the UAV in FR1." TDoc comparison: R1-2302512 (vivo) R1-2303418 (Nokia, Nokia Shanghai Bell) R1-2303618 (Qualcomm Incorporated) - TDoc R1-2302512 proposes adding a parameter for Rel-17 related to beam misalignment between DL source RS in the TCI state and PL-RS to support beamforming for UAV UE in FR1. It also suggests removing the restriction that some UE capability parameters are applicable only to FR2 and discusses beamforming-related RRC parameters. The function of spatial relation for FR2 is moved to a joint TCI state or a UL TCI state to determine the UL Tx spatial filter. - TDoc R1-2303418 shows that an antenna configuration with a minimum of 2 UAV beams is sufficient for harnessing benefits and suggests extending only a subset of the existing FR2-only capabilities and parameters from unified TCI state operation for UE UAV beamforming capabilities for FR1 based on beam switching among fixed directional antennas at the UE side. It proposes specifying UE capability to report at least UAV UE orientation to the network. - TDoc R1-2303618 discusses beam selection for UAV with different antenna configurations and emphasizes the importance of gNB scheduling and selecting uplink beams of aerial UEs by considering the interference impact. It suggests that UE reporting of beam information is beneficial for gNB power control and interference management. Example snippets from the original TDocs to support the differences highlighted: - From TDoc R1-2302512: "In unified TCI framework, the function of spatial relation for FR2 is moved to a joint TCI state or a UL TCI state which indicates the RS configured with QCL Type D to determine the UL Tx spatial filter." - From TDoc R1-2303418: "Proposal 2: RAN1 to consider extending only subset of the existing FR2 only capabilities and parameters from unified TCI state operation, for the purpose of the UE UAV beamforming capabilities for FR1 based on beam switching among fixed directional antennas at UE side." - From TDoc R1-2303618: "Although UE reports the capability of one or multiple antenna configurations, gNB may not know the antenna configuration of the UL beam applied by the UE for real-time transmission/reception. With the beam information reported by the UE, gNB can apply appropriate power control for the UAV, e.g., to increase power of the selected directional antenna with controlled interference to the terrestrial UEs in the shared spectrum." 3GPP-R1-112-bis-e Agenda Item 9.15 : Study on Self-Evaluation towards the 3GPP submission of a IMT-2020 Satellite Radio Interface Technology
3GPP-R1-112-bis-e Agenda Item 9.15.1 : Evaluation methodology
Entity and Technical Concepts Table
TDoc comparison: R1-2302384 (Huawei, HiSilicon) R1-2302693 (CATT,CAICT) R1-2303346 (MediaTek Inc.) R1-2303626 (Panasonic) Proposal 9: - Reuses the evaluation methodology defined in section 7.1.4 of Report ITU-R to evaluate mobility. - Uses the same evaluation parameters and configurations selected for the evaluation of average spectral efficiency. - Uses a speed of 250 km/h. - Example snippet: "The evaluation method for mobility assessment should follow the principles outlined in § 7.1.4 of Report ITU-R." Proposal 10: - Adds additional parameters listed in Table 3 on top of example parameters in section 8.2.3 of Report ITU-R M.2514 for Rural-HRC-s evaluation, as that for Rural-eMBB-s. - Example snippet: "The requirements below are defined for the purpose of the evaluation in the Rural-eMBB-s test environment, applicable to handheld devices." Proposal 11: - Reuses the generic formula defined in TR 37.910 for peak spectral efficiency assessment. - Takes into consideration the highest coding rate, maximum modulation order, and maximum number of layers based on link budget analysis of CNR for achievable values. - Uses the link level channel model in section 6.9 of TR 38.811 as an adaptation of the CDL and TDL models in Report ITU-R M.2412 Annex 1 for performance evaluated by link level simulations. - Example snippet: "For the peak spectral efficiency assessment, the generic formula defined in TR 37.910 can be reused." TDoc R1-2302693: - Provides self-evaluation results towards IMT-2020 submission to ITU-R WP 4B against the technical performance requirements defined by Report ITU-R M.2514. - Uses the evaluation criteria defined in the report. - Completes the related compliance template and description templates. - Associate channel models with deployment scenarios in clause 6.10 of TR 38.821. - Example snippet: "Observation 1: As analyzed in NTN, the CDL and TDL model are proper to evaluation of S band, and the flat fading model is preferred to Ka band." TDoc R1-2303346: - Provides basic simulation assumptions for the self-evaluation for IoT NTN for fulfilment of the “Connection Density” requirement. - Uses full-buffer system-level simulation for determining the uplink SINRi for each percentile i=1…99 of the distribution over users and recording the average allocated user bandwidth Wuser. - Follows the principles outlined in § 7.1.3 of Report ITU-R with needed adaptations for the evaluation methodology for the systems simulations for determining the connection density. - Confirms the application of the 10 second latency bound for IMT-2020 satellite submission as part of the 3GPP simulation methodology definition if non-full buffer is used. - Example snippet: "Step 1: Perform full-buffer system-level simulation using the evaluation parameters for Rural-mMTC test environment." TDoc R1-2303626: - Considers both non-full buffer model (FTP 3) and full buffer model for the traffic model. - Defines the requirements for the evaluation in the Rural-eMBB-s test environment, applicable to handheld devices. - Uses Satellite parameter set 1 in Table 6.1.1.1-1 of TR38.821 for the evaluation of IMT-2020 satellite radio interface. - Example snippet: "Regarding the traffic model, although non-full buffer model (FTP 3) is described in TR38.821, full buffer model should also be considered." TDoc comparison: R1-2302435 (Nokia, Nokia Shanghai Bell) R1-2303157 (Samsung) R1-2303299 (ZTE) - TDoc R1-2302435: The importance of time correlation in radio channel modelling for mobility - Example snippet: "When modelling mobility, the modelling of the radio channel and especially the time correlation is important." - TDoc R1-2302435: Consideration of satellite characteristics in evaluation guidelines for IMT-2020 - Example snippet: "Given the similarities and differences between terrrestial and non-terrestial, the requirements and evaluation guidelines developed previously for the terrestrial component of IMT-2020 may be considered for the development of satellite radio interface(s) of IMT-2020 and modified considering specific satellite characteristics." - TDoc R1-2303157: Data rate and spectral efficiency calculations based on MCS level - Example snippet: "Example of data rate and spectral efficiency per MCS level based 64QAM MCS table" - TDoc R1-2303299: Proposal to use Rural channel model for self-evaluation test environment - Example snippet: "Proposal 1: The test environment is Rural for all usage scenarios, and channel model for Rural in sector 6.6.6 and 6.6.7.2 in [3] can be used." - TDoc R1-2303299: Focus on handheld terminals for self-evaluation against technical performance requirements - Example snippet: "We can focus the self-evaluation on handheld terminals to evaluate against technical performance requirements defined in [2], thus the carrier frequency is assumed to be 2 GHz (S-band), and the bandwidth is up to 30 MHz." TDoc comparison: R1-2302873 (Ericsson) R1-2303619 (Qualcomm Incorporated) 1. TDoc R1-2302873 proposes simulation assumptions for UL evaluations for peak data rate and peak spectral efficiency, with Table 2 providing the specific parameters. The assumptions are endorsed for use in evaluations. Example snippet: "Table 2 shows simulation assumptions for UL evaluations for the peak data rate and peak spectral efficiency. In order to move forward with the evaluations, the following is proposed: The evaluation assumptions in the enclosed tables are endorsed." 2. TDoc R1-2303619 focuses on simulation assumptions for SLS related to eMBB spectral efficiency. It provides a basic set of evaluation parameters and values captured in ITU-R Report M.2514 for handheld devices and eMBB-s Rural environment, as well as additional parameters adapted from NR-NTN spectral efficiency simulations. Example snippets: "This section focuses on system-level simulation parameters and assumptions required to evaluate the following two Technical Performance Requirements, defined in ITU-R M.2514" and "Based on simulation parameters and assumptions used for the 3GPP IMT-2020 self-evaluation of eMBB spectral efficiency for 5G terrestrial NR, the following additional parameters can be considered and adapted for NR-NTN spectral efficiency simulations." 3. Both TDocs reference ITU-R Report M.2514 for evaluation assumptions related to satellite and UE configuration parameters. TDoc R1-2302873 also references TR 38.821. Example snippets: "Further evaluation assumptions related to the satellite and UE configuration parameters can be found in the ITU-R Report M.2514, as well as TR 38.821" and "The ITU-R Report M.2514 includes a certain set of example parameters related to UE configuration, satellite configuration and other specific parameters for the evaluation of TPRs in the eMBB-s Rural environment, including spectral efficiency TPRs." 4. TDoc R1-2303619 specifically includes UE parameters and tables for SE and eMBB. Example snippets: "UE parameters Table 2. SE Parameters Table 3. eMBB Table 4. eMBB" 3GPP-R1-112-bis-e Agenda Item 9.16 : TEIs
TDoc comparison: R1-2302385 (Huawei, HiSilicon, Ericsson, China Unicom) R1-2303851 (Ericsson, Verizon, Qualcomm) Summary of TDoc R1-2302385: - Scheduling restriction on PDSCH explained in contribution [2] - Two interpretations: - gNB can't schedule PUCCH transmission in same slot as PUSCH scheduled by UL DCI, unless they don't overlap in time - DAI size aligned between gNB and UE according to PDCCH scheduled/received and assumption that UE won't miss consecutive 4 DCI formats - Possible solutions proposed, but not always effective and may introduce more restrictions on gNB scheduling - Codebook size aligned between gNB and UE Example snippet from TDoc R1-2302385: "After UL DCI, gNB cannot schedule a PUCCH transmission to carry HARQ information in the slot of PUSCH transmission scheduled by the UL DCI, unless the PUSCH and PUCCH transmissions are not overlapped in time." Summary of TDoc R1-2303851: - Extension to UL for multi-PUSCH important for XR video traffic in DL with variable and large packets, arriving in bursts - Feature agnostic to subcarrier spacing, frequency range, and shared spectrum access - Develop during WI for FR2-2, but large variations in deployment scenarios experienced - Supports TEI-18 for UE feature for multi-PUSCH scheduling with single DCI 0_1 for non-contiguous slots in FR1 for all defined SCSs - Limitation to contiguous slots problematic for transmission over TDD bands Example snippet from TDoc R1-2303851: "With respect to the comments raised in the previous meeting, we would like to provide the following clarifications: The features under discussion here, were developed during the WI for FR2-2." TDoc comparison: R1-2302400 (Nokia, Nokia Shanghai Bell) R1-2302762 (ZTE, China Telecom, Sanechips) R1-2302973 (xiaomi) plane and user plane of 5G New Radio (NR) systems - Technical Specification, provides the technical specifications for the physical layer procedures for control plane and user plane in 5G NR systems. [TDoc R1-2302400] proposes adapting drx-HARQ-RTT-TimerUL/drx-HARQ-RTT-TimerDL to the number of PUSCH/PUCCH repetitions dynamically indicated, to provide a good balance between power-saving and latency control. However, reducing drx-HARQ-RTT-TimerUL is crucial for avoiding significant latency increase in case it starts after the last repetition. [TDoc R1-2302762] suggests observing the improvements brought by PUSCH repetition type A for a PUSCH scheduled by DCI format 0_0 with CRC scrambled by C-RNTI. It points out the lack of support for repetition transmission after a UE performing 4-step RACH procedure in Rel-18, making Msg5 PUSCH the coverage bottleneck. It proposes using the same transmission schemes as Msg3 re-transmission, including repetition indication, RV determination, available slot determination, and frequency hopping, and RLC segmentation to improve Msg5 PUSCH coverage. [TDoc R1-2302973] discusses the update of pathloss reference signal for Type 1 CG-PUSCH in Rel-16, following the agreement in RAN1#99 on the update of pathloss reference for PUSCH via MAC-CE. It points out that the pathloss reference signal for Type 2 CG-PUSCH and dynamic-grant PUSCH can be updated by the SRI field in DCI, and proposes updating the pathloss reference signal for Type 1 CG-PUSCH in Rel-16. In summary, these TDocs highlight technical differences in adapting drx-HARQ-RTT-TimerUL/drx-HARQ-RTT-TimerDL to the number of PUSCH/PUCCH repetitions dynamically indicated, improving Msg5 PUSCH coverage through PUSCH repetition type A and RLC segmentation, and updating the pathloss reference signal for Type 1 CG-PUSCH in Rel-16. These proposals aim to enhance power-saving, reduce latency, and improve coverage in 5G NR systems. TDoc comparison: R1-2302513 (vivo) R1-2303620 (Qualcomm Incorporated) has proposed several technical differences between TDoc R1-2302513 and R1-2303620: TDoc R1-2302513: - In FDD, if antenna switching SRS is not configured for the UE, the network can configure two 1/2-port SRS resources. - A "gap symbol" is introduced between two SRS resources for codebook enhancement. - For 1Tx, 4Rx UE, if antenna switching SRS is not configured for the UE, four 1-port SRS resources are needed with a gap symbol in between, and SRI is indicated in DCI. - Antenna switching for SRS and PUSCH is partially possible. - The proposal is to support more than 2 SRS resources in a set for usage codebook. PUSCH antenna switching is not supported. Example snippet from original TDoc: "in FDD, SRS antenna switching may not be supported/configured, however two (four) SRS resources for CB can be configured." TDoc R1-2303620: - RAN4 specification allows for some relaxation of SRS transmit power for any ports other than the first port, given by a parameter, ∆TRxSRS. - The capability to process DL DCIs or UL DCIs was not extended accordingly for the doubled number of BDs / CCEs specified in Rel-16 for multi-DCI based multi-TRP. - The larger number of BDs / CCEs specified in Rel-16 for multi-DCI based multi-TRP cannot be utilized in practice to actually transmit more DL / UL DCIs from the two TRPs. Example snippet from original TDoc: "Even though the number of BDs / CCEs that the UE monitors is doubled (and number of CORESETs is increased to 5) in Rel-16, the capability to process DL DCIs or UL DCIs was not extended accordingly." 3GPP-R1-112-bis-e Agenda Item 9.17.4 : UE features for NR NCR
TDoc comparison: R1-2303158 (Samsung) R1-2303208 (ETRI) R1-2303259 (CMCC) R1-2303862 (Huawei, HiSilicon) - Proposal 1 suggests identifying mandatory and optional features for NCR-MT, similar to IAB-MT. - Proposal 2 introduces an additional capability for power allocation and power sharing among C-link and backhaul link for simultaneous UL transmission. - Proposal 3 identifies three independent optional features with NCR-MT capability signaling: periodic beam indication including priority flag, semi-persistent beam indication including priority flag, and aperiodic beam indications. - Proposal 5 suggests reporting the value of parameter k, which represents the process time of NCR, as a capability to gNB. - Proposal 6 introduces a capability for defining the offset between the slot that NCR-MT receives the DCI carrying aperiodic beam indication and the reference of slot offset for the time resource for aperiodic beam indication. - The default capability for NCR is TDMed UL transmission of C-link and backhaul link. - NCR-Fwd related features include optional simultaneous UL transmission and adaptive beams of C-link and backhaul link with capability signaling. - SUL and SRS related aspects are not considered for NCR-MT configured output power calculation if the same mechanism with IAB-MT is applied for NCR-MT. - Option 1 for simultaneous UL transmission of C-link and backhaul link suggests applying higher priority to uplink transmission in backhaul link and reducing transmission power of C-link accordingly. - Option 2 for simultaneous UL transmission of C-link and backhaul link suggests applying higher priority to uplink transmission in C-link and reducing transmission power of backhaul link accordingly. - Slot offset for aperiodic beam indication is defined as the reference of slot offset for each time resource, and the capability of beam is based on the design of the antenna panel. TDoc comparison: R1-2302898 (Nokia, Nokia Shanghai Bell) R1-2303177 (RAN1, Comba) TDoc R1-2302898: - This TDoc is focused on initial views on UE features for Network Controlled Repeaters (NCR). - It proposes Table 1 as a starting point for further discussion on NCR feature groups. - It references RP-223505, "Revised WID on NR network-controlled repeaters," from ZTE and Sanechips. - Example snippet: "Hence, in this contribution we provide our initial views on UE features for Network Controlled Repeaters [1]." TDoc R1-2303177: - This TDoc discusses side control information to enable NR network-controlled repeaters and UE features for NCR relevant to RAN1. - Proposal 1 is for HARQ-ACK feedback for PDCCH carrying side control information to be supported and enabled/disabled as needed. - The NCR-MT capability includes capabilities related to beams in C-link and can reuse the legacy capability reporting mechanism. - Proposal 2 is for NCR-MT capabilities to be informed to NW via RRC signalling and NCR-Fwd capabilities to be informed to NW via OAM. - Example snippet: "Proposal 1: HARQ-ACK feedback for PDCCH carrying side control information is supported, and the network can enable/disable this feature as needed." TDoc comparison: R1-2302514 (vivo) R1-2302917 (Fujitsu) R1-2303293 (Rapporteur(ZTE)) - FG 1-1 and FG 1-3 are mandatory for NCR-MT due to its support for initial access and radio link monitoring, respectively. (TDoc R1-2302514) - Only one of FG 2-5/2-6 is sufficient for DL DMRS in NCR-MT due to its less complicated scheduling scheme for DL data transmission. (TDoc R1-2302514) - Basic DL control channel reception and monitoring of DCI format 5-0 should be mandatory for NCR-MT. (TDoc R1-2302514) - At least one of periodic, semi-persistent, and aperiodic AC-link beam indication is supported or mandatory for NCR. (TDoc R1-2302917) - Revised beam management related UE features for NCR-MT from TR38.822: mandatory features should be changed to optional. (TDoc R1-2303293) - Side control information and associated signaling for NCR have been specified, including periodic, semi-persistent, and aperiodic beam indication for access link and dedicated MAC CE signaling for backhaul link. (TDoc R1-2303293) - FG 43-4 Adaptive beam for NCR backhaul link/C-link should be added in the prerequisite feature group. (TDoc R1-2303293) Example snippets from the original TDocs: - "For FG 1-1/1-3, considering the NCR-MT also supports initial access, FG 1-1 should be mandatory" (TDoc R1-2302514) - "since the NCR-MT DL does not require complicated scheduling scheme considering normal data transmission is not expected in the C-link, only one of the FG 2-5/2-6 is sufficient for DL DMRS" (TDoc R1-2302514) - "DCI format 5-0 is defined to carry side control information, monitoring of DCI format 5-0 should also be mandatory for NCR-MT" (TDoc R1-2302514) - "At least one of periodic, semi-persistent and aperiodic AC-link beam indication is supported or mandatory for NCR" (TDoc R1-2302917) - "The beam management related UE features (i.e., FG 2-21~FG 2-31 and FG 2-59~FG 2-62 in Rel-15) as defined in TR38.822 should be revised for NCR-MT" (TDoc R1-2303293) - "Side control information and associated signaling for NCR have been specified, including periodic, semi-persistent, and aperiodic beam indication for access link and dedicated MAC CE signaling for backhaul link" (TDoc R1-2303293) 3GPP-R1-112-bis-e Agenda Item 9.17.10 : UE features for MC enhancements
TDoc comparison: R1-2302515 (vivo) R1-2302577 (OPPO) - TDoc R1-2302515 highlights that existing UE capabilities can be reused for the feature and corresponding DCI field for mc-DCI monitoring. This can be reported along with the basic capability of mc-DCI monitoring. Example snippet: "Existing UE capabilities for the feature can be directly reused to indicate the support of this feature and the corresponding DCI field for mc-DCI when the UE capabilities are reported together with the basic capability of mc-DCI monitoring." - The support of Type-1 HARQ-ACK generation for mc-scheduling can be considered a basic capability since all co-scheduled cells have the same SCS and PUCCH resource. Example snippet: "the generation procedure of Type-1 HARQ-ACK codebook for mc-scheduling is almost identical to that of for sc-scheduling, which is mandatorily supported with capability signalling reporting in R15. Thus, the support of Type-1 HARQ-ACK generation for mc-scheduling can be considered a basic capability." - There is a need for further discussion on whether support for fields and corresponding features in mc-DCI should be mandatory or optional. Example snippet: "Further discussion is needed regarding whether support of those fields and corresponding features in mc-DCI should be mandated or optional." - TDoc R1-2302577 clarifies the details of DCI 0_X/1_X payload size derivation for FDRA-reuse based cell combination indication before determining the selected method as optional. Example snippet: "RAN1 clarifies details of the DCI 0_X/1_X payload size derivation for the FDRA-reuse based cell combination indication, before determining which method is selected as optional." - There was a discussion on whether/how to have UE capability indication for support of table-based indication and FDRA-reuse-based indication for indicating co-scheduled cell combinations. Example snippet: "There was a brief discussion in RAN1 #112 regarding to whether/how to have UE capability indication for UE’s support of two mechanisms to indicate the co-scheduled cell combinations: table-based indication and FDRA-reuse-based indication." - The maximum number of co-scheduled cells by a DCI format 0_X and 1_X for a UE can be the same or different, and can be smaller than or equal to 4. FFS whether to introduce multiple combinations of values for these capability parameters. Example snippet: "the maximum number of co-scheduled cells by a DCI format 0_X and the maximum number of co-scheduled cells by a DCI format 1_X for a UE can be the same or different, and can be smaller than or equal to 4. FFS whether to introduce multiple combinations of values for these capability parameters." TDoc comparison: R1-2303621 (Qualcomm Incorporated) R1-2303735 (NTT DOCOMO, INC.) - TDoc R1-2303621: - Monitoring legacy non-fallback DCI formats should be split into two cases: (i) monitoring legacy non-fallback DCI formats for the reference cell and (ii) monitoring legacy non-fallback DCI formats for any cell of the set of cells. - Example snippet: "Monitoring legacy non-fallback DCI formats for any cell of the set of cells effectively increases the number of BDs/CCEs/DCI-sizes that a UE has to support for a cell in the set." - UE reports support for one or multiple combinations of {a band for scheduling cell, a set of band(s) for scheduled cells} for multi-cell scheduling by a single DCI format. - Example snippets: "UE reports support for multiple combinations" and "multi-cell scheduling by a single DCI format." - TDoc R1-2303735: - Inclusion of SCell dormancy indication, PDCCH monitoring adaptation indication, and minimum applicable scheduling offset indicator in DCI format 0_X/1_X is configurable. - Example snippet: "Inclusion of SCell dormancy indication in DCI format 0_X/1_X is configurable." - UL Tx switching scheme is discussed across 3 or 4 bands at RAN1#109-e meeting. - Example snippet: "Evaluation results on UL Tx switching across 3 or 4 bands at RAN1#109-e meeting." - Appendix B: - EN-DC cases are out of scope for Rel-18 UL Tx switching. - Example snippet: "EN-DC cases are out of scope for Rel-18 UL Tx switching." - UL only cell cases are out of scope for Rel-18 UL Tx switching. - Example snippet: "UL only cell cases are out of scope for Rel-18 UL Tx switching." - RAN1 Observation: - Four contributions from three companies show their evaluation results on UL Tx switching across 3 or 4 bands at RAN1#109-e meeting. - Example snippet: "Four contributions from three companies show their evaluation results on UL Tx switching across 3 or 4 bands." - GTW Agreement: - For a single-TAG case, RAN4 agrees to reuse the Rel-16/17 approach and discuss further details for Rel-18 Tx switching scenario in RAN1. - Example snippet: "RAN4 agrees to reuse the Rel-16/17 approach." TDoc comparison: R1-2302897 (Nokia, Nokia Shanghai Bell) R1-2303159 (Samsung) R1-2303736 (NTT DOCOMO, INC.) R1-2303762 (Ericsson) In TDoc R1-2302897, discussions on multi-cell PDSCH/PUSCH scheduling are highlighted, and potential specific UE capabilities that need to be considered are: - Separate capabilities for multi-cell PDSCH and multi-cell PUSCH - Indication of the scheduled cell combination - Maximum number of set of cells supported by the UE for multi-cell PDSCH/PUSCH scheduling Example snippet: "Two different ways for indicating the scheduled cell combination (which also affects on the DCI content) have been agreed in RAN1." In TDoc R1-2303159, the following parameters can be potentially considered as UE capability: - Maximum number of cells in a/any configured cell combination from a set of cells - Maximum number of sets of cells in a PUCCH group (i.e., across all scheduling cells) Example snippet: "Maximum value of 4 cells in each set of cells, as already agreed, can be assumed for all Rel-18 UEs that support multi-cell scheduling." In TDoc R1-2303736, supporting maximum number of set of cells should be the unified value for UL and DL, and supporting maximum number of co-scheduled cells can be separately reported between UL and DL. HARQ-ACK codebook type as a basic feature also needs to be supported by a UE which supports multi-cell scheduling feature. Example snippet: "Similar to the UE features for legacy cross-carrier scheduling, support of multi-cell scheduling can be reported separately." In TDoc R1-2303762, if UE indicates support for both multi-cell scheduling via DCI 1_X/0_X and cross-carrier scheduling, the UE should support DL/UL reception on a cell in the set also using legacy DCI formats with CIF. Alt 1: Explicit field for indication of co-scheduled cells. Alt 2: Indication Via FDRA field. Example snippet: "RAN1 also agreed to support multiple sets of serving cells that can be scheduled using DCI 1_X/0_X from a same scheduling cell." In summary, the technical differences among the TDocs relate to the specific UE capabilities that need to be considered for multi-cell scheduling, including the indication and maximum number of cells and sets of cells. These differences are supported by example snippets from the original TDocs. TDoc comparison: R1-2302763 (ZTE) R1-2303512 (Apple) R1-2303863 (Huawei, HiSilicon) - TDoc R1-2302763 introduces the UE feature for indication of switchedUL and dualUL for each band pair, which is agreed upon by RAN2. - No need to introduce new UE capability to indicate the number of ports for PUSCH transmission for Rel-18 UL Tx switching. - RAN4 has agreed that for Rel-18 UE, the switching period reported by UE for Rel-18 3/4-band Tx switching can be the same or different from the switching period for Rel-16/17 2-band switching operations. - Proposal 3 in TDoc R1-2302763 considers two alternatives for introducing a separate UE feature to indicate the support of UL Tx switching among 3/4 bands. - TDoc R1-2303512 proposes introducing an optional UE capability to indicate support of transmission during the switching period for the band on which UL Tx chain remains unchanged. - Proposal 1 in TDoc R1-2303863 suggests introducing a new capability to indicate the support of multi-cell scheduling using a single DCI format. - Proposal 2 in TDoc R1-2303863 proposes introducing a new capability to indicate the support of the number of sets of cells that can be scheduled by the same scheduling cell. - Proposal 3 in TDoc R1-2303863 suggests introducing a new capability to indicate the supported option for indicating the co-scheduled cells within a set of cells. - There is a baseline UE capability for Rel-18 UE RF management, which is to support the case of the configured band combination where the aggregated number of configured Tx across all bands is no more than 4 (TDoc R1-2303863). - Simultaneous use of cross-carrier scheduling by legacy DCI format with multi-carrier scheduling can have different implementations, UE complexity, and commercial support compared to multi-cell scheduling together with a legacy DCI for self-scheduling (TDoc R1-2303863). Example snippets: - "The UE capability of switchedUL and dualUL for each band pair is needed for UL Tx switching among 3 or 4 bands." (TDoc R1-2302763) - "For Rel-18 UE, the switching period reported by UE for Rel-18 3/4-band Tx switching can be the same or different from the switching period for Rel-16/17 2-band switching operations." (TDoc R1-2302763) - "The support of multi-cell scheduling for the band combination is not sufficient to cover the UL Tx switching among 3 or 4 bands." (TDoc R1-2302763) - "A new capability should be introduced to indicate the support of number of sets of cells that can be scheduled by the same scheduling cell." (TDoc R1-2303863) - "The simultaneous use of cross-carrier scheduling by legacy DCI format with multi-carrier scheduling can have different implementations, UE complexity and commercial support compared to multi-cell scheduling together with a legacy DCI for self-scheduling." (TDoc R1-2303863) 3GPP-R1-112-bis-e Agenda Item 9.17.14 : UE features for eDSS
TDoc comparison: R1-2302578 (OPPO) R1-2302764 (ZTE) TDoc R1-2302578: - Support of reception of a PDCCH candidate having a DMRS RE overlapping with LTE CRS RE - UE assumes that the RE overlapping between the PDCCH candidate and LTE CRS did not occur - Example snippet from TDoc: "UE may assume that the RE overlapping between this PDCCH candidate and LTE CRS did not occur." TDoc R1-2302764: - Whether to limit the number of LTE CRS patterns for PDCCH reception in symbols with LTE CRS REs were discussed - Proposal for a mandatory feature for a UE supporting Rel-18 DSS: "CE on clean symbols only" - Maximum number of LTE-CRS rate matching patterns for PDSCH supported by a UE is unchanged - Example snippet from TDoc: "If RAN4 concludes that new RAN4 performance requirements are needed for legacy CE, ‘CE on clean symbols only’ should be a mandatory feature for a UE supporting Rel-18 DSS." Overall, the technical differences in these TDocs relate to the support and requirements for PDCCH monitoring in overlapping with CRS, as well as potential limitations on the number of LTE CRS patterns. In TDoc R1-2302578, the UE assumes no RE overlapping between the PDCCH candidate and LTE CRS, while in TDoc R1-2302764, there are discussions around limiting the number of LTE CRS patterns for PDCCH reception and the potential mandatory feature of "CE on clean symbols only" for UE supporting Rel-18 DSS. Example snippets from the original TDocs show the specifics of these differences, such as the assumption made by the UE in TDoc R1-2302578 and the proposal for a mandatory feature in TDoc R1-2302764. These differences highlight the ongoing discussions and considerations in the development and implementation of PDCCH monitoring and LTE CRS patterns for PDSCH reception in UE. TDoc comparison: R1-2302896 (Nokia, Nokia Shanghai Bell) R1-2303160 (Samsung) R1-2303342 (MediaTek Inc.) R1-2303513 (Apple) - [TDoc R1-2302896]: Legacy UEs drop PDCCH candidates with REs overlapping with LTE CRS, while new UEs are able to process such candidates with a CORESET configuration that has all symbols overlapping with LTE CRS REs. - Example snippet: "Already with Rel-15 UEs can be configured with a CORESET that doesn’t have clean symbols as long as the UE is not aware of the presence of the LTE CRS in the system, in which case the UE would happily process the PDCCH candidate without ever bothering to worry about what the CRS REs are doing to the PDCCH channel estimate or demodulation performance." - [TDoc R1-2303160]: UEs can improve PDCCH BLER with reduced network operation requirements by adjusting LLRs and weighting of DM-RS symbols in REs overlapping with LTE CRS REs. - Example snippet: "To improve PDCCH BLER with reduced requirements on network operation, a first UE capability is to receive/decode DCI formats by adjusting the LLRs for symbols in REs overlapping with LTE CRS REs (e.g. exclude those LLRs from use in decoding)." - [TDoc R1-2303342]: If the feature "Reception of NR PDCCH candidates that overlap with LTE CRS REs" is supported, UE assumes a regular legacy DMRS pattern in frequency dimension for channel estimation. Two channel estimation assumptions are supported for Rel-18 eDSS feature: legacy channel estimation assumption and channel estimation on PDCCH symbols not overlapped with LTE CRS. - Example snippet: "Furthermore, to resolve companies concern on the channel estimation complexity based on punctured PDCCH DMRS by LTE CRS, two channel estimation assumptions are supported for Rel-18 eDSS feature from RAN1 point of view, which are legacy channel estimation assumption and channel estimation on PDCCH symbols not overlapped with LTE CRS." - [TDoc R1-2303513]: UEs can support and be configured with two overlapping CRS rate matching patterns regardless of support or configuration of multi-TRP. Legacy channel estimation assumption is that all PDCCH DMRS REs are used for channel estimation, but UEs are not required to monitor PDCCH candidate with REs overlapping with CRS REs from more than one LTE CRS pattern. - Example snippet: "The legacy channel estimation assumption is that all the PDCCH DMRS REs are used for channel estimation, and this is the basic capability and mandatory feature for UE implementation. For the number of LTE CRS patterns overlapping with NR PDCCH, according to the WID, the objective is to investigate the performance gain of NR PDCCH punctured by LTE CRS." TDoc comparison: R1-2303622 (Qualcomm Incorporated) R1-2303763 (WI Rapporteur(Ericsson)) • TDoc R1-2303622 assumes that no new parameter is introduced to indicate LTE-CRS pattern(s)/pattern list(s) for NR-PDCCH reception overlapping with LTE CRS REs, and existing LTE-CRS pattern(s)/pattern list(s) parameters are re-used. Example snippet: "For NR-PDCCH reception with a CORESET with one value of coresetPoolIndex, the UE assumes LTE-CRS pattern list associated with the coresetPoolIndex for NR-PDCCH reception." • TDoc R1-2303622 states that if a UE is configured with two different values of coresetPoolIndex for CORESETs, it takes into account LTE-CRS patterns/pattern lists configured by lte-CRS-PatternList1-r16 or lte-CRS-PatternList3-r18 for NR PDCCH reception in CORESET with coresetPoolIndex =0 and by lte-CRS-PatternList2-r16 or lte-CRS-PatternList4-r18 for NR PDCCH reception in CORESET with coresetPoolIndex = 1. Example snippet: "If a UE is configured with CORESETs with different coresetPoolIndex, for NR-PDCCH reception with a CORESET with one value of coresetPoolIndex, the UE assumes LTE-CRS pattern list associated with the coresetPoolIndex for NR-PDCCH reception." • TDoc R1-2303763 applies both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 for a UE not configured with two CORESET pools two different values of coresetPoolIndex in ControlResourceSet and configured with both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18. Example snippet: "For case when UE is not configured with two CORESET pools two different values of coresetPoolIndex in ControlResourceSet, and configured with lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18, both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are applied." • TDoc R1-2303763 applies lte-CRS-PatternList3-r18 if the PDSCH is associated with coresetPoolIndex set to ‘0’, and lte-CRS-PatternList4-r18 if the PDSCH is associated with coresetPoolIndex set to ‘1’, if UE is configured with crs-RateMatch-PerCoresetPoolIndex. Example snippet: "If UE is configured with crs-RateMatch-PerCoresetPoolIndex, lte-CRS-PatternList3-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘0’, and lte-CRS-PatternList4-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘1’." • The Rel-16 UE capability overlapRateMatchingEUTRA-CRS-r16 is subject to support of multiDCI-Multi-TRP-r16 in Rel-18 ASN.1, as clarified by Working Assumption(RAN1#109e). Overall, these TDocs highlight technical differences in the application of LTE-CRS pattern(s)/pattern list(s) and coresetPoolIndex for NR-PDCCH reception and PDSCH rate-matching in different UE configurations. TDoc comparison: R1-2302516 (vivo) R1-2302626 (Spreadtrum Communications) R1-2303737 (NTT DOCOMO, INC.) R1-2303764 (Ericsson) • TDoc R1-2302516 proposes the use of CE based on clean symbol(s) PDCCH-DMRS only when the PSD ratio of CRS and PDCCH is 1:1 to improve PDCCH performance for legacy receivers. • TDoc R1-2302626 considers the granularity of NR-PDCCH reception with LTE-CRS per band and proposes UE support for two overlapping CRS rate matching patterns. • TDoc R1-2303737 discusses the impact of puncturing DMRS REs overlapping with CRS on UE performance and proposes gNB transmission schemes. • TDoc R1-2303764 proposes a capability indication for UE support of reception of NR PDCCH candidates that overlap with LTE CRS REs using ‘legacy channel estimation’. - TDoc R1-2302516 suggests a set of candidate values for the supported PDCCH-DMRS channel estimation to indicate the optimal CE option for the UE. - TDoc R1-2302626 proposes to differentiate between FR1 and FR2, and to signal the mandatory/optional components. - TDoc R1-2303737 proposes two options for PDCCH-DMRS channel estimation, one that follows legacy assumption/behavior and another that performs CE on clean symbol(s) only. - TDoc R1-2303764 proposes a UE capability indication for reception of NR PDCCH candidates that overlap with LTE CRS REs using ‘legacy channel estimation’, regardless of CORESET duration. Example snippets from the original TDocs: - TDoc R1-2302516: "When the PSD ratio of CRS and PDCCH is 1:1, the PDCCH performance of legacy receivers (i.e., legacy PDCCH decoding+legacy CE) deteriorates significantly compared with R17, thus CE based on clean symbol(s) PDCCH-DMRS only is preferred in this case." - TDoc R1-2302626: "Consider following components PDCCH candidates and PDCCH-DMRS RE mapping are based on that of R15 from UE side. UE performing channel estimation with a regular legacy DMRS pattern in frequency dimension." - TDoc R1-2303737: "On the other hand, if UE supports “CE on clean symbol(s) only”, gNB can apply either “puncturing DMRS REs overlapping with CRS” or “superposition transmission of DMRS/PDCCH and CRS” since anyway the UE in this case performs CE on clean symbol(s) only." - TDoc R1-2303764: "A capability indication for UE support of reception of NR PDCCH candidates that overlap with LTE CRS REs using ‘legacy channel estimation’ (and all possible CORESET durations) should be supported." 3GPP-R1-112-bis-e Agenda Item 9.17.15 : UE features for BWP without restriction
TDoc comparison: R1-2302895 (Nokia, Nokia Shanghai Bell) R1-2303623 (Qualcomm Incorporated) R1-2303865 (Huawei, HiSilicon) B-1-1, and Opt. C should be supported. Proposal 2: Clarify that the SSB outside the active DL BWP is still within a bandwidth of at least one DL BWP of the carrier for Opt. B-1-1. Example snippet: "Supporting measurements based on SSB outside the active BWP without interruptions requires a UE to either keep larger bandwidth than the active BWP to receive SSB and other DL transmission within the active BWP simultaneously, or use separate RFs as discussed in RAN4." [TDoc R1-2311651]: Discussion on UE features for BWP without restriction Proposal 1: Allow the UE to report the maximum number of SSBs it can monitor simultaneously. Proposal 2: Clarify that the UE should be able to detect the location of the SSB within a bandwidth of at least one DL BWP of the carrier, regardless of its support for CD-SSB or NCD-SSB. Proposal 3: Introduce a new IE in RRC signaling to indicate the number of SSBs that can be monitored simultaneously. Example snippet: "Therefore, it is suggested that the UE should be able to detect the location of the SSB within a bandwidth of at least one DL BWP of the carrier, regardless of its support for CD-SSB or NCD-SSB." [TDoc R1-2312578]: Discussion on UE features for BWP without restriction Proposal 1: Introduce a new IE in RRC signaling to indicate the UE's support for BWP without restriction. Proposal 2: Clarify that the UE should support at least one DL BWP and should be able to detect the location of the SSB within a bandwidth of at least one DL BWP of the carrier. Proposal 3: Allow the UE to report the maximum number of SSBs it can monitor simultaneously. Example snippet: "In order to ensure interoperability and avoid confusion among vendors, it is proposed to introduce a new IE in RRC signaling to indicate the UE's support for BWP without restriction." TDoc comparison: R1-2302765 (ZTE) R1-2303738 (NTT DOCOMO, INC.) summary: • TDoc R1-2302765 proposes a new UE capability for Option A, which allows for BM/RLM/BFD based on CSI-RS within the active BWP without the need for additional measurement gap. This proposal is considered complete from a functional perspective. • TDoc R1-2302765 also proposes two new UE capabilities for Option B-1, which allows for the use of a larger bandwidth covering SSB outside the active BWP. Option B-1-1 does not have interruptions, while Option B-1-2 has interruptions. These proposals aim to address the issue of UE capability "bwp-WithoutRestriction." • TDoc R1-2303738 further discusses the necessary UE features for Options B-1-1 and B-1-2, which include a new UE capability signaling support for BM/RLM/BFD based on SSB outside the active BWP. Examples from the original TDocs: • TDoc R1-2302765: "UE’s capability not requiring additional measurement gap for BM/RLM/BFD." • TDoc R1-2302765: "Clarification of bwp-WithoutRestriction." • TDoc R1-2303738: "For Option B-1-1, a new UE capability signaling to report the support of BM/RLM/BFD based on SSB outside the active BWP without interruption is necessary." • TDoc R1-2303738: "For Option B-1-2, a new UE capability signaling to report the support of BM/RLM/BFD based on SSB outside the active BWP with interruptions is necessary." • TDoc R1-2303738: "If a UE supports SSB based BFD/BM and this capability, the UE supports BM/BFD based on SSB outside the active BWP without interruption." TDoc comparison: R1-2302415 (Ericsson) R1-2302517 (vivo) R1-2303350 (MediaTek Inc.) 1. TDoc R1-2302415 proposes three options to support RLM/BM/BFD measurements outside of the BWP: - Option A: Perform measurements based on CSI-RS within active BWP. - Option B: Perform measurements based on SSB outside active BWP. - Option C: Use NCD-SSB approach, compatible with existing UE hardware architectures and RAN4 specifications. Example snippet from TDoc R1-2302415: "According to the discussion in RAN, RAN4 and RAN1, the following potential solutions were identified in [2]: ..." 2. TDoc R1-2302517 proposes two components within Option B-1-1: - UE-specific RRC configured BWP may not include BW of CORESET#0 and SSB for PCell/PSCell. - UE performs RLM/BM/BFD measurements based on SSB without interruptions, outside active DL BWP but within corresponding carrier(s) to be measured. Example snippet from TDoc R1-2302517: "Introduce FGX-1 of 'Support RLM/BM/BFD measurements based on SSB outside active BWP without interruptions' for Option B-1-1, with following components: ..." 3. TDoc R1-2303350 proposes multiple NCD-SSBs for a UE across different BWPs in a cell, but only one SSB per BWP. Example snippet from TDoc R1-2303350: "For Option C with NCD-SSB, as agreed for RedCap UEs (see below), we propose that a normal UE may be configured with multiple NCD-SSBs provided that for each BWP the UE is configured with only one SSB." 4. TDoc R4-2214355 suggests two ways for UE to support RLM/BM/BFD measurements using CD-SSB outside active BWP: - Use larger BW covering SSB outside active BWP. - Utilize an additional separate RF chain. Example snippet from TDoc R4-2214355: "Finally, to support RLM/BM/BFD measurements using CD-SSB outside active BWP without any interruption, as discussed in RAN4 previously [R4-2214355], UE can operate using larger BW covering SSB outside active BWP or UE can utilize a additional separate RF chain." 3GPP-R1-112-bis-e Agenda Item 9.17.16 : Other
3GPP-R1-112-bis-e Agenda Item 9.18 : Other
TDoc comparison: R1-2302518 (vivo) R1-2302579 (OPPO) R1-2302740 (Ericsson LM) R1-2302741 (Ericsson LM) R1-2302743 (Ericsson LM) R1-2302820 (Intel Corporation) R1-2302884 (Nokia, Nokia Shanghai Bell) R1-2303012 (Nokia, Nokia Shanghai Bell) R1-2303013 (Nokia, Nokia Shanghai Bell) R1-2303019 (Nokia, Nokia Shanghai Bell) R1-2303166 (Spreadtrum Communications) R1-2303292 (Rapporteur(ZTE)) R1-2303327 (MediaTek Inc.) R1-2303404 (ZTE) R1-2303431 (LG Electronics) R1-2303514 (Apple) Technical differences among the various TDocs are as follows: [TDoc R1-2302518]: UE cannot handle a configuration where the total number of different DCI sizes configured to monitor is more than 4 for the cell, or the total number of different DCI sizes with C-RNTI configured to monitor. Example snippet: "Otherwise, the number of HARQ-ACK information bits for each DCI format 1_X that schedules the cell set is equal to N." [TDoc R1-2302579]: Two restrictions regarding PDCCH reception in overlapping with CRS exist in the current 38.213, from UE behavior and gNB configuration perspectives. Example snippet: "Quite some remaining issues relate to the “clean symbol” which shows up in the following RAN1 #110 agreement but has not been clearly defined in RAN1 even for discussion purpose." [TDoc R1-2302740]: CCE-to-REG mapping for a control-resource set can be interleaved or non-interleaved and is described by REG bundles. Example snippet TDoc comparison: R1-2303740 (NTT DOCOMO, INC.) R1-2303766 (Ericsson) R1-2303804 (Huawei, HiSilicon) R1-2303858 (Huawei, HiSilicon) - TDoc R1-2303740: Separate fields are configured for each cell for Type-2 DCI fields. The total payload size of DCI is fixed for the set of cells while the association between cell and a certain per-cell field of Type-2 DCI field can be changed depending on the combination of co-scheduled cell when co-scheduled cells are indicated via co-scheduled cell indicator in DCI. Example snippet: "Configurable fields (Antenna ports, precoding information and number of layers and SRS resource indicator), and the total payload size of DCI is fixed for the set of cells while the association between cell and a certain per-cell field of Type-2 DCI field can be changed depending on the combination of co-scheduled cell when co-scheduled cells are indicated via co-scheduled cell indicator in DCI." - TDoc R1-2303766: The range of the configurable periodicities for periodic beam configurations should cover a wide range of periodic signals supported by NR. The periodicity of a periodic NCR beam configuration should also be given in unit of either slot or ms. Support a single field that is commonly applicable to all cells in a set of cells. Example snippet: "For minimum applicable scheduling offset indicator in DCI format 0_X/1_X, Support a single field that is commonly applicable to all cells in a set of cells. RAN1 can confirm that the RRC configured bit-width of the beam indication field in DCI format 5_0 is determined by the number of beams used for access link which is provided by the OAM." - TDoc R1-2303804: Each field is mapped in the order in which it appears in the description. The most significant bit of each field is mapped to the lowest order information bit for that field. Example snippet: "Table 7.3.1-1: DCI formats The fields defined in the DCI formats below are mapped to the information bits to as follows. If the number of information bits in a DCI format is less than 12 bits, zeros shall be appended to the DCI format until the payload size equals 12. The most significant bit of each field is mapped to the lowest order information bit for that field." - TDoc R1-2303858: If only a single time resource list is configured for each aperiodic indication, the required DCIs of controlling NCR forwarding will be linear with the number of supported UEs and forwarded signals, which leads to high overhead for the gNB. The maximum duration for each time domain resource, the maximum number of , reference of slot offset k (whether k is defined by NCR-MT capability and/or declared by vendor), the forwarding resource index indication, and the indication within a PDCCH monitoring periodicity are remaining issues. Example snippet: "If only a single time resource list is configured for each aperiodic indication, the required DCIs of controlling NCR forwarding will be linear with the number of supported UEs and forwarded signals, which leads to high overhead for the gNB. Similar to NR, the reduction in power can be based on the signal priorities of C-link and backhaul link." TDoc comparison: R1-2303284 (ZTE) R1-2303624 (Qualcomm Incorporated) R1-2303765 (WI Rapporteur(Ericsson)) R1-2304003 (Nokia) TDoc R1-2303284: - Both dl-PRS-MutingOption1 and dl-PRS-MutingOption2 can be configured at the same time. - NR-DL-PRS-SFN0-Offset defines the time offset of the SFN0 slot 0 for the DL PRS resource set. - dl-PRS-ResourceList determines the DL PRS resources within one DL PRS resource set. - dl-PRS-CombSizeN defines the comb size of a DL PRS resource. - dl-PRS-ResourceBandwidth defines the number of resource blocks configured for DL PRS transmission. Example snippet: "Both dl-PRS-MutingOption1 and dl-PRS-MutingOption2 may be configured at the same time in which case the logical AND operation is applied to the bit maps." TDoc R1-2303624: - UE expects that Antenna port(s) field refers to the common/same Table for all the cells in the set of cells for DCI format 1_X. - The number of bits for antenna port(s) field depends on various RRC parameters for DCI formats 0_1 and 0_2. - If TPMI field is configured as Type-1A, the UE expects that single Table from Tables 7.3.1.1.2-2 to 7.3.1.1.2-5A in TS38.212 is used for PUSCH transmissions scheduled by the DCI format 0_X. Example snippet: "UE expects that Antenna port(s) field, when it is configured as Type-1A, refers to the common/same Table from Tables 7.3.1.2.2-1, 7.3.1.2.2-2, 7.3.1.2.2-3, or 7.3.1.2.2-4, for all the cells in the set of cells for DCI format 1_X." TDoc R1-2303765: - For a UE not configured with two CORESET pools and configured with lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18, both patterns are applied. - If UE is configured with crs-RateMatch-PerCoresetPoolIndex, lte-CRS-PatternList3-r18 or lte-CRS-PatternList4-r18 is applied based on the PDSCH association with a specific coresetPoolIndex value. - If UE is not configured with crs-RateMatch-PerCoresetPoolIndex, both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are applied. Example snippet: "If UE is configured with crs-RateMatch-PerCoresetPoolIndex, lte-CRS-PatternList3-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘0’, and lte-CRS-PatternList4-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘1’." TDoc R1-2304003: - nrofPorts in CSI-RS-ResourceMapping defines the number of CSI-RS ports. - cdm-Type in CSI-RS-ResourceMapping defines CDM values and pattern. - resourceMapping in ZP-CSI-RS-Resource defines the OFDM symbol and subcarrier occupancy of the ZP CSI-RS resource within a slot. - periodicityAndOffset in ZP-CSI-RS-Resource defines the ZP-CSI-RS periodicity and slot offset. - p-ZP-CSI-RS-ResourceSet can be configured for multicast reception in pdsch-ConfigMulticast for GC-PDSCH rate matching. Example snippet: "nrofPorts in CSI-RS-ResourceMapping defines the number of CSI-RS ports, where the allowable values are given in Clause 7.4.1.5 of [4, TS 38.211]." TDoc comparison: R1-2303161 (Samsung) R1-2303162 (Samsung) R1-2303164 (Samsung) R1-2303803 (Huawei, HiSilicon) - The UE is provided with PDSCH-CodeBlockGroupTransmission and is scheduled for a PUSCH transmission by DCI format with a DAI field and no PDCCH within monitoring occasions for a DCI format scheduling PDSCH reception providing a transport block with enabled HARQ-ACK information. The UE does not multiplex HARQ-ACK information for the first or second sub-codebook in the PUSCH transmission. [R1-2303161] - The UE does not expect to multiplex HARQ-ACK information in a same Type-2 HARQ-ACK codebook that is in response to detection of DCI formats with different number of bits for the counter DAI field. [R1-2303161] - When precoderGranularity = allContiguousRBs, the UE does not expect to be configured a set of resource blocks of a CORESET that includes more than four sub-sets of resource blocks that are not contiguous in frequency. [R1-2303162] - The UE does not transmit PUSCH, PUCCH, PRACH, or SRS in a set of symbols of a slot that would overlap with any symbol from the set of symbols received for SS/PBCH blocks configured for L1 beam measurement/reporting. [R1-2303164] - The UE is not expected to handle a configuration with more than four total different DCI sizes configured to monitor for a cell or with more than four total different DCI sizes with C-RNTI configured to monitor. [R1-2303803] - The UE may assume the quasi co-location information indicated in both of the two TCI states for the PDCCH reception in a CORESET associated with a Type3-PDCCH CSS set. [R1-2303162] Example snippets: - "If a UE is provided PDSCH-CodeBlockGroupTransmission and the UE is scheduled for a PUSCH transmission by DCI format that includes a DAI field with first value or with second value and the UE has not received any PDCCH within the monitoring occasions…" [R1-2303161] - "The UE does not expect to multiplex, in a same Type-2 HARQ-ACK codebook, HARQ-ACK information that is in response to detection of DCI formats with different number of bits for the counter DAI field." [R1-2303161] - "When precoderGranularity = allContiguousRBs, a UE does not expect - to be configured a set of resource blocks of a CORESET that includes more than four sub-sets of resource blocks that are not contiguous in frequency…" [R1-2303162] - "For operation on a single carrier in unpaired spectrum, for a set of symbols of a slot indicated to a UE for reception of SS/PBCH blocks by ssb-PositionsInBurst in SIB1 or by ssb-PositionsInBurst in ServingCellConfigCommon or, if the UE is not provided dl-OrJointTCI-StateList, by ssb-PositionsInBurst in SSB-MTCAdditionalPCI associated to physical cell ID with active TCI states for PDCCH or PDSCH, or for a set of symbols of a slot corresponding to SS/PBCH blocks configured for L1 beam measurement/reporting, the UE does not transmit PUSCH, PUCCH, PRACH in the slot if a transmission would overlap with any symbol from the set of symbols and the UE does not transmit SRS in the set of symbols of the slot." [R1-2303164] - "The UE is not expected to handle a configuration that, after applying the above steps, results in - the total number of different DCI sizes configured to monitor is more than 4 for the cell; or - the total number of different DCI sizes with C-RNTI configured to monitor…" [R1-2303803] - "If a UE is provided two TCI states indicating quasi co-location information of the DM-RS antenna port for PDCCH reception in a CORESET associated with a Type3-PDCCH CSS set, the UE may assume the quasi co-location information indicated in both of the two TCI states for the PDCCH reception in the CORESET." [R1-2303162] |