Summary based on the input provided by Samsung in RP-220802. This WI introduces enhanced specification support for several key aspects on multi-input multi-output (MIMO) operation where Rel-15 and 16 NR were found deficient in terms of signalling latency, overhead, as well as spectral efficiency and coverage. First, although Rel-15/16 NR supports FR2 deployments via multi-beam operation, signalling latency and overhead especially for beam indication are high for common beam operation. This not only hampers deployments in high-speed scenarios, but also scenarios where the number of configured TCI states is large. In addition, it lacks the support for inter-cell operation, multi-panel UEs, and maximum permissible exposure (MPE) mitigation. Second, although Rel-16 NR introduced mTRP support for PDSCH, it still lacks ample support for PDCCH, PUSCH, and PUCCH. In addition, enhancements for inter-cell mTRP and beam management aspects specific to mTRP are introduced along with features to facilitate high-speed train deployment on single frequency network (HST-SFN). Third, SRS has been a useful tool to acquire UL or DL CSI since Rel-15. However, the triggering mechanism of aperiodic SRS limits its flexibility. Further, antenna switching SRS only supports up to 4 antennas, which limits the performance for use cases requiring larger than 4 receive antennas. In addition, along with the expansion of 5G deployment, the demand to further improve SRS capacity and coverage appears. Fourth, although Rel-16 has enhanced the Rel-15 Type-II to allow improved performance-overhead trade-off, CSI enhancements designed for mTRP non-coherent JT and Type-II assuming FDD (angle-delay) reciprocity can be beneficial to support additional deployment scenarios. Enhancements for multi-beam operation In Rel-15/16, UL beam indication utilizes a different framework from DL beam indication. As DL and UL beam indication share similar characteristics, a unified TCI-based framework for DL and UL beam indication is introduced in Rel-17 where UL TCI is used to represent UL spatial relation. Depending on whether DL and UL share the same TCI (e.g. in relation to the beam correspondence assumption supported by the UE), a UE can be configured with either joint DL/UL TCI (where DL and UL share the same TCI state hence a single TCI state update applies to both) or separate DL/UL TCI (which includes the signalling of DL-only, UL-only, and DL+UL TCI state update). Central to the Rel-17 TCI framework is the use of common beam for UE-dedicated PDCCH and the associated PDSCH intended to streamline multi-beam operation. While Rel-15/16 supports the use of common beam for UE-dedicated PDCCH and the associated PDSCH, beam indication is performed via MAC-CE. The latency and overhead associated with MAC-CE potentially detract the application of NR for high-speed scenarios in the FR2 regime. In Rel-17, such latency and overhead are reduced with the introduction of DCI-based beam indication using the existing DCI formats 1_1/1_2 (with and without DL assignments) via the TCI field. To ensure that the NW and the UE are aligned in terms of TCI state, an ACK mechanism for the beam indication is supported either via the ACK associated with the PDSCH (when beam indication is accompanied with DL assignment) or an ACK mechanism analogous to that used for SPS PDSCH release (when beam indication is not accompanied with DL assignment). When only one TCI state is activated via MAC-CE, the DCI-based beam indication is not used. In this case, beam indication is performed via MAC-CE. The Rel-17 TCI framework also supports auxiliary features such as a common TCI state ID update using a common TCI state pool and/or reference CC for Carrier Aggregation, UL power control setting (including PL-RS) association with TCI state, as well as inter-cell beam management. Inter-cell beam management includes measurement and reporting of L1-RSRP as well as beam indication for TCI states associated with PCIs different from that of the serving cell. In addition, common beam operation can be configured to other signals such as non-UE dedicated reception associated with serving cell PCI, aperiodic CSI-RS, and aperiodic SRS. To better support UEs equipped with multiple panels, UE reporting of the capability associated with the maximum number of SRS ports and its correspondence with CSI-RS or SSB resource indicators (CRI/SSB-RI) is introduced. This reporting is performed in conjunction with the supported beam reporting. Due to adherence to the MPE (maximum permissible exposure) regulation, some UL coverage penalty is incurred as the UE ends up using a sub-optimal UL transmit beam. To alleviate this issue, some enhancement in the existing PHR report is introduced where beam-specific P-MPR along with the associated CRI/SSBRI is added into the MAC-CE-based PHR report. Enhancements for multi-TRP operation In Rel-17, PDCCH repetition is defined by explicit linkage between two search space sets. The two linked search space sets can be associated with corresponding CORESETs with different TCI states, hence, achieving beam-diversity for PDCCH transmission. In Rel-17, only intra-slot PDCCH repetition is supported, and also, PDCCH repetition is only supported for USS or Type3 CSS. In addition, the linkage is specified at the PDCCH candidate level by restricting configurations of two linked search space sets resulting in one-to-one mapping between monitoring occasions and between PDCCH candidates of the two linked search space sets. Two linked PDCCH candidates have the same aggregation level, same coded bits, and the same DCI payload. To avoid ambiguity at the UE, a reference PDCCH candidate is defined for various procedures such as timelines, PUCCH resource determination, PDSCH reception with mapping Type B or mapping Type A, determination of QCL assumption for PDSCH when TCI field is not present in DCI, etc. UE can report whether two blind decodes or three blind decodes are needed for two linked PDCCH candidates. In the case of three blind decodes, overbooking for PDCCH is enhanced accordingly. Furthermore, determination of two QCL-TypeD is specified for FR2 to support time-overlapping PDCCH repetitions. PDCCH repetition is supported also for cross-carrier scheduling through linking two search space sets in both scheduling cell and scheduled cell. In Rel-17, to support multi-TRP PUCCH repetition, up to two sets of power control parameters in FR1 or up to two PUCCH-SpatialRelationInfo in FR2 can be activated per PUCCH resource or per PUCCH resource group via MAC-CE. In addition, multi-TRP PUCCH repetition can be configured by intra-slot PUCCH repetition as well as inter-slot PUCCH repetition for all PUCCH formats. Based on the number of activated PUCCH-SpatialRelationInfo or set of power control parameters for the scheduled PUCCH resource, dynamic switching between single-TRP PUCCH repetition and multi-TRP PUCCH repetition can be supported. Separate power control for multi-TRP PUCCH repetition is supported by two activated PUCCH-SpatialRelationInfo or two activated sets of power control parameters. Furthermore, up to two TPC field for PUCCH can be supported and each TPC field is applied for each closed loop index. In Rel-17, multi-TRP PUSCH repetition is supported with up to two SRS resource sets with usage set to 'codebook' or 'nonCodebook'. If UE is provided by two SRS resource sets with usage set to 'codebook' or 'nonCodebook', the second SRI field, second TPMI field (if CB-based PUSCH is supported), and second PTRS-DMRS association field are indicated by DCI format 0_1 or 0_2 for PUSCH transmission occasion(s) toward the TRP which is related to the second SRS resource set with usage set to 'codebook' or 'nonCodebook' for dynamic grant based PUSCH scheduling. In addition, the new DCI field is defined as 'SRS resource set indicator' with 2 bits to support dynamic switching between single-TRP PUSCH repetition (corresponding to codepoint '00' and '01') and multi-TRP PUSCH repetition (corresponding to codepoint '10' and '11'). Separate power control for multi-TRP PUSCH repetition is supported by linking between two SRI fields and two sets of power control parameters via higher layer parameter. And also up to two TPC field for PUSCH can be supported and each TPC field is applied for each closed loop index. Furthermore, the aforementioned multi-TRP PUSCH repetition is also supported by configured grant type 1 and 2. In Rel-16, multi-TRP PDSCH transmission is supported with two different mechanisms: single-DCI and multi-DCI. In Rel-17, multi-TRP PDSCH transmission is further extended to inter-cell operation. A UE can be configured with SSB associated with PCI which are different from serving cell PCI, known as additional PCI. At most 7 different additional PCI can be configured to the UE, and only one is activated for inter-cell multi-TRP operation. The additional PCI can be associated with one or more TCI states, and gNB can schedule PDSCH dynamically from either TRP by indicating TCI in DCI. In Rel-17, beam reporting and BFR are enhanced for mTRP scenario specifically. For beam reporting enhancement, framework of Rel-15 group based beam reporting is extended to facilitate simultaneous transmission of multiple TRPs. To achieve that, one CSI resource setting including two resource sets corresponding to two TRPs can be configured. In a CSI-report, UE can report N (Nmax = {1, 2, 3, 4}) groups of simultaneously received beams, wherein each reported beam in one group corresponds to one TRP. Differential L1-RSRP reporting across all beam groups is supported, and 1-bit is added to indicate CMR set associated with the largest RSRP value in the first group. For BFR enhancements, both single-DCI and multi-DCI framework are supported. For multi-DCI, two explicit or implicit BFD-RS sets are introduced for two TRPs in one CC. BFRQ can be transmitted if any one of BFD-RS sets fails. BFRQ framework is enhanced based on Rel.16 SCell BFR. The maximum number of PUCCH-SR resources is extended to 2. After UE receives gNB's response, per-TRP beam reset can be performed. When both BFD-RS sets in SpCell fail, CBRA based RACH transmission can be triggered. For single-DCI, only explicit BFD-RS set configuration can be supported. Rel-17 defines two key approaches for frequency offset compensation in HST-SFN scenario: UE-based and TRP-based compensation schemes. For UE-based compensation (scheme A), UE receives additional reference signals transmitted by the TRPs in a non-SFN manner to facilitate more accurate frequency offset compensation. The corresponding non-SFN TRS configurations are provided to the UE by using two TCI states (containing reference to the TRS of two TRPs) using DCI and MAC signalling. The TRP-based compensation (scheme B) relies on frequency offset pre-compensation at the network side, where each TRP estimates the downlink frequency by using uplink signal, e.g., SRS, and compensates the downlink frequency per TRP prior to transmission. For TRP based pre-compensation, UE also receives two TRS transmitted by the TRPs in a non-SFN manner using two TCI states. However, since network pre-compensates the PDCCH and PDSCH by the difference of the frequency offsets observed between two TRPs, frequency offset tracking at the UE is performed using only one TRS transmitted by the reference TRP. SRS enhancements In NR Rel-15/16, aperiodic SRS is triggered by DCI to provide dynamic indication of SRS transmission. However, only one triggering offset value can be configured in RRC per SRS resource set. This limits the valid combinations of the location to send the triggering DCI and the location to transmit SRS, esp. considering TDD slot format, where not all slots are available to transmit SRS. To address this issue, Rel-17 introduces SRS triggering offset enhancement based on available slot definition. Up to 4 offset values can be configured in RRC per SRS resource set, where each value is defined as the number of available slots counting from a reference slot. Reference slot is defined as the slot indicated by legacy triggering offset. In DCI format 0_1/0_2/1_1/1_2, one new field "SRS offset indicator" (SOI) is added to select one available slot offset value from the configured ones. In addition, Rel-15/16 DCI format 0_1/0_2 cannot be indicated to trigger SRS only, i.e., without CSI request and without data. This limitation is removed in Rel-17 by allowing gNB to trigger SRS based on DCI format 0_1/0_2 without CSI request and without data. To ensure performance for uses case with larger than 4 receive antennas, Rel-17 introduces antenna switching SRS to support 1T6R, 1T8R, 2T6R, 2T8R and 4T8R. In addition, to improve flexibility of antenna switching SRS, Rel-17 extends the P/SP configurations by supporting maximum 2 SP SRS resource sets and maximum 1 periodic SRS resource set for antenna switching, and the aperiodic configuration by supporting 1 or 4 aperiodic SRS resource sets for 1T4R and 2 aperiodic resource sets for 1T2R/2T4R. In order to enhance the capacity and coverage for SRS, the following three schemes are specified in Rel-17.

• Increased repetition: Rel-17 supports 8, 10, 12 and 14 consecutive repetition symbols in one slot in one SRS resource.
• Partial frequency sounding: Rel-17 supports to transmit SRS only in 1/P_F m_(SRS,B_SRS ) contiguous RBs in one OFDM symbol, where m_(SRS,B_SRS ) indicates the number of RBs configured by BSRS and CSRS. It can be applied on both frequency hopping case and non-frequency hopping case. The scaling factor PF is configured by RRC per SRS resource, which can be 2 or 4. The start RB index of the 1/P_F m_(SRS, B_SRS ) RBs in the m_(SRS, B_SRS ) RBs is N_offset=((k_F+k_hopping ) mod P_F)/P_F m_(SRS,B_SRS ) , where kF is configured by RRC with a value chosen from kF = {0, 1, …, PF-1}. khopping is same for all SRS occasions within a legacy FH period but can hop across legacy FH periods. When the hopping of khopping is not enabled, it is fixed to be 0 for all SRS symbols. When the hopping of khopping is enabled, one hopping pattern is supported for each PF value.
• Comb 8: Rel-17 supports comb-8 for SRS other than for positioning, where the maximum number of cyclic shifts is 6.

CSI for mTRP and FDD reciprocity The Rel-17 eType-II port selection (PS) codebook assumes W_1 W_2 W_f^Hcodebook structure as Rel-16. The key enhancement comes from exploiting angle-delay reciprocity in DL and UL which is applicable for both TDD and FDD. By doing so, spatial domain and frequency domain compression operation inherent in the Rel-16 eType-II PS codebook can be shifted toward the gNB thereby reducing UE computational burden. While the amplitude and phase per channel/ propagation path are generally not DL and UL reciprocal, the gNB can employ angle-delay information obtained from UL measurements to precode UE-specific CSI-RS. Therefore from CSI measurement perspective at the UE, a subset of CSI-RS ports based on beamformed CSI-RS resource are first selected by the UE and represented by W_1, frequency domain compression is represented by Wf giving rise to up to two selected DFT vectors, and lastly linear combination coefficients are quantized in amplitude and phase by W2 with configurable compression factors up to 1 by removing negligible coefficients. Moreover, to improve CSI measurement accuracy over NCJT transmission in Rel-16, Rel-17 NCJT CSI enhancement supports a joint channel measurement at the UE by configuring a CMR pair within the same CSI-RS resource set corresponding to two TRPs respectively. Therefore a CSI-RS resource set is divided as two CMR groups so that each CMR pair consists of one CMR from Group 1 and one CMR from Group 2. From CSI reporting perspective, two modes are supported, whereas Mode 1 is to report X (X=0,1,2) single-TRP CSI and one NCJT CSI versus Mode 2 is to report one single-TRP or NCJT CSI. For the reporting quantity of NCJT CSI (up to rank 4), the main differentiation from legacy releases is that only single CQI/CRI is reported per CMR pair by jointly considering the best companion PMI/RI from two CMRs simultaneously to mitigate TRP interference. Also to use CSI-RS resources and configurations efficiently, sharing mechanism can be enabled by the gNB to reuse a CMR pair (configured for NCJT CSI measurement) for single-TRP CSI measurement if needed.

Summary based on the input provided by CAICT, OPPO, vivo in RP-221384. Radiated multi-antenna reception performance is one of the most important characteristics to verify the MIMO receiver of the UE under conditions more closely resembling the end user's interaction with the device. This NR MIMO OTA core part WI specifies test parameters and channel models for MIMO OTA performance testing based on the outcome of the Rel-16 SI in TR 38.827. In addition, the channel model validation reference values and pass/fail limits to ensure the correct implementation of channel models have also been specified. The outcome of this WI is captured in a new technical specification TS 38.151. The objective of this core part WI is to specify test parameters, channel models, and pass/fail limits for channel model validation for NR MIMO OTA requirement testing, including both FR1 and FR2. Based on the outcome in TR 38.827, the following aspects in this core part WI have been investigated and specified:

• Figure of Merits: Define the Figure of Merits for FR1 and FR2 MIMO OTA performance requirements for: FR1: Total Radiated Multi-antenna Sensitivity (TRMS) @ 70% throughput; FR2: MIMO Average Spherical Coverage (MASS) @ 50% CDF
• Measurement setup: Specify the test system for FR1 MIMO OTA requirements measurement: 16-probe Multi-Probe Anechoic Chamber (MPAC) ; Specify the test system for FR2 MIMO OTA requirements measurement: 3D Multi-Probe Anechoic Chamber (3D-MPAC)
• Test parameters: Down-select the test parameters for FR1 and FR2 MIMO OTA requirements
• Channel models: Define the FR1 and FR2 channel models for MIMO OTA requirement testing for FR1 UMi CDL-C and UMa CDL-C and FR2 UMi CDL-C; Refine the FR1 and FR2 Base Station beam configurations
• Channel model validation: Define the reference values and pass/fail limits for FR1 and FR2 channel model validation and Refine the measurement setups and procedures for FR1 and FR2 channel model validation
• Preliminary measurement uncertainty assessment: define the preliminary measurement uncertainty (MU) budget for FR1 and FR2 MIMO OTA test systems

Summary based on the input provided by Qualcomm Incorporated, Samsung in RP-221178. This WI builds on Rel-16 "IAB for NR", which introduced wireless backhauling of F1 over NR to enable flexible and dense deployment of 5G cells while reducing the need for wireline transport infrastructure. The enhancements to IAB introduced in Rel-17 improve on various aspects over Rel-16 IAB such as robustness, degree of load-balancing, spectral efficiency, and backhaul performance. The Rel-17 IAB enhancements support the following new functionality:

• Introduction of inter-donor migration of the IAB-MT to increase robustness and allow for more refined load-balancing and topology management.
• Reduction of service interruption during IAB-node migration and BH RLF recovery to improve network performance, allow the network deployment to undergo more frequent topology changes, and provide more stable backhaul performance.
• Enhancements to scheduling as well as flow and congestion control to improve end-to-end performance as well as spectral efficiency to the IAB network.
• Duplexing enhancements to increase spectral efficiency and reduce latency through the support of SDM/FDM-based resource management and through simultaneous transmissions and/or reception on IAB-nodes.

With Rel-17 enhancements, IAB remains transparent to the UE. At the same time, legacy UEs can benefit from the enhancement provided by Rel-17. The Rel-17 IAB enhancements are further applicable to FR1 and FR2. Inter-donor IAB-MT migration and connectivity Inter-donor IAB-MT migration and recovery To enhance robustness and load balancing, Rel-17 IAB introduces the inter-donor partial migration and RLF recovery. For inter-donor partial migration, the IAB-MT performs handover or conditional handover to migrate from the source IAB-donor to the target IAB-donor. For inter-donor RLF recovery, the IAB-MT performs the RRC Reestablishment procedure at the target IAB-donor. During these procedures, the IAB-MT obtains new IP addresses from the target IAB-donor that are anchored at the target IAB-donor-DU to enable IP connectivity via this target IAB-donor-DU. The F1 and non-F1 traffic of the migrating IAB-node and its descendent nodes is then routed via a new BAP path that uses the target IAB-donor-DU. The F1 connections, however, remain terminated at the source IAB-donor. This traffic migration is facilitated via coordination between source and target IAB-donors using the XnAP IAB Transport Migration Management/Modification procedures introduced in Rel-17 for this purpose. In these procedures, the source IAB-donor sends QoS information of the traffic to be migrated to the target IAB-donor, so that the target IAB-donor can establish the backhaul transport on RLC and BAP sublayers on the target path. The target IAB-donor informs the source IAB-donor about all layer-2 and IP information needed by the source IAB-donor to configure the necessary end-to-end transport. The XnAP IAB Transport Migration Management/Modification procedures are also used to allocate IP addresses for descendent nodes, and to ensure proper QoS and connectivity support via the target IAB-donor-DU over time, e.g., due to configuration or release of new F1-U GTP-tunnels. Rel-17 introduces the concept of the IAB-topology, which contains all IAB-nodes and IAB-donor-DUs as well as all backhaul links that are controlled by the same IAB-donor via RRC and/or F1AP. After inter-donor partial or RLF recovery, all descendent node traffic has to pass through two IAB topologies controlled by separate IAB-donors. The migrating IAB-node is referred to as the boundary IAB-node since it is controlled by both IAB-donors and therefore resides in both topologies. The concept of the IAB-topology is necessary to coordinate the L2 configurations across an IAB-network controlled by two IAB-donors. Each IAB-donor can independently use the full name space of BAP addresses, BAP path IDs and BH RLC CH IDs for the transport in its own IAB topology. Descendent-node traffic that travels across two IAB-topologies uses a separate BAP routing IDs for each of these two topologies. At the boundary node, the BAP routing ID used by a BAP PDU in one topology is rewritten to the BAP routing ID the BAP PDU uses in the other topology. The BAP routing ID mapping is coordinated between both IAB-donors during traffic migration. Rel-17 enhancements also allow for the revocation of the traffic migration caused by inter-donor partial migration. For this purpose, the target IAB-donor conducts an Xn handover of the IAB-MT in reverse direction, i.e., back to the former source IAB-donor. The source IAB-donor can request the revocation of this traffic migration. Source and target IAB-donors can further coordinate the use of radio resources used on parent and child links via the XnAP IAB Resource Coordination procedure introduced in Rel-17 for this purpose. Inter-donor topological redundancy For the enhancement of load balancing, Rel-17 IAB further introduces inter-donor topological redundancy. For this purpose, the IAB-MT executes the NR DC procedure to concurrently connect to two IAB-donors. The collocated IAB-DU can establish F1 with either of these two IAB-donors. Inter-donor topological redundancy also interconnects two IAB-topologies where the dual-connected IAB-node assumes the role of the boundary node. F1 and non-F1 traffic of the dual-connected IAB-node and its descendent nodes can be gradually migrated between the two paths via either the MN's or the SN's IAB-donor-DU. The XnAP IAB Transport Migration Management/Modification procedures are used for the coordination between MN and SN IAB-donors for this traffic migration. The boundary node applies BAP header rewriting for all traffic that passes through both IAB-topologies. The MN and SN further coordinate the use of radio resources used on the parent links and child links of the dual-connecting IAB-node. CP-UP separation For the enhancement of robustness, Rel-17 IAB introduces CP-UP separation for an IAB-node that is dual-connected with an IAB-donor and a gNB, which does not assume IAB-donor role. In this case, the IAB-node's F1-C can be exchanged via the backhaul with the IAB-donor or, alternatively, via the path containing the access link between IAB-node and gNB and the Xn connection between gNB and IAB-donor. For CP-UP separation, the gNB can either assume MN or SN role. In the former case, SRB2 is used on the NR access link for the passing of F1-C traffic, and split SRB in the latter case. Reduction of service interruption Intra-donor migration with parallel migration of descendent nodes For the reduction of service interruption during intra-donor IAB-node migration, Rel-17 introduces enhancements to enable concurrent traffic migration by the descendent nodes and the migrating IAB-node. For this purpose, the IAB-donor sends the RRC Reconfiguration messages to the descendent nodes prior to migration. It includes an indicator in the F1AP Transfer message for the descendant's parent node to withhold the RRC message from delivery until the migration has succeeded. When the migration succeeds, all RRC messages withheld are released in a top-down sequence through the tiers of the subtree. In this manner, all IAB-nodes affected can conduct the migration of F1-C in a concurrent rather than sequential manner. Support of inter-donor-DU local re-routing For the reduction of packet loss due to link unavailability, Rel-17 introduces inter-donor-DU local re-routing for UL traffic. The NR dual-connected IAB-node can perform inter-donor-DU re-routing in case its parent backhaul links connect to separate IAB-donor-DUs, but do not share a single route to a common IAB-donor-DU. When one of the parent links is not available, the IAB-node can re-route the UL traffic via the other parent link to the alternative IAB-donor-DU. To ensure proper routing on the BAP sublayer, the IAB-node rewrites the BAP header of these re-routed UL PDUs with a BAP routing ID that contains the BAP address of this alternative IAB-donor-DU. The alternative IAB-donor-DU can forward the traffic to the peer IAB-donor-DU, which was the packet's original destination, via a statically configured GTP-U tunnel. The alternative IAB-donor-DU selects a packet for tunneling by matching the packet's source IP address with a IAB-donor-configured IP address list. In case the alternative IAB-donor-DU and its peer belong to separate IAB-donor-CUs, the IP address list is forwarded between the IAB-donors. Enhancements to BH RLF indications For the reduction of packet loss due to BH RLF, Rel-17 introduces the BH RLF detection indication and the RLF recovery indication. In case an IAB-node attempts RRC Reestablishment due to BH RLF, it can send the RLF detection indication to each child node. If the child node has an alternative backhaul path available, it can apply UL rerouting for upstream packets. If it has no such alternative backhaul path, it can propagate the BH RLF detection indication to the next tier. When the IAB-node has recovered from the BH RLF, it can send the RLF recovery indication to each child node, which revokes all behaviour triggered by the BH RLF detection indication before. The BH RLF recovery indication is propagated in the same manner as the BH RLF detection indication. Performance enhancements in BH transport and scheduling Enhancements to QoS For the improvement of UL QoS scheduling on the backhaul, Rel-17 introduces an extension of the LCG space. The extended LCG space supports 256 instead of just 8 LCGs. Extended LCGs can be signalled via new short and long BSR MAC CEs. The extended LCGs can also be used for pre-emptive BSR. Enhancements to congestion mitigation For the improvement of congestion mitigation, Rel-17 introduces DL local re-routing based on flow-control feedback on BAP sublayer as well as DL congestion reporting to the IAB-donor-CU-CP. The IAB-node can apply DL local re-routing for a BAP destination when the congestion control feedback for this destination exceeds an IAB-donor-configured threshold. The IAB-DU can report congestion with child BH RLC channel granularity to the IAB-donor-CU-CP. This allows the IAB-donor-CU-CP to apply congestion mitigation measures such as the configuration of routing changes, topology adaptation, or changes to the radio-resource configuration. Enhancements in multiplexing The following enhancements to physical layer procedures have been made in Rel-17 in the context of enhanced multiplexing: FDM of IAB-MT and IAB-DU operation is enabled by extending the concept of Hard, Soft and Unavailable IAB-DU symbol resources to Hard, Soft, and Unavailable IAB-DU sets of RBs within a component carrier, provided through a Rel-17 IAB-DU frequency domain resource configuration in addition to the Rel-16 IAB-DU time domain resource configuration. The DCI 2_5 mechanism is extended to support explicit release of Soft resources with RB set granularity. Similarly, the rules for implicit determination of availability of a Soft RB set are extended for FDM operation. Interference mitigation is facilitated by the ability to exchange of semi-static Rel-16 IAB-DU time domain resource configuration information and the Rel-17 IAB-DU frequency domain resource configuration information among neighbouring IAB-nodes and IAB-donors. SDM of IAB-MT and IAB-DU operation is facilitated by the introduction of two new timing alignment modes for IAB-MT transmit timing: Case 6 timing aligns the IAB-MT transmit timing with the IAB-DU transmit timing, facilitating SDM Tx at the IAB-node. Case 7 timing aligns the IAB-DU receive timing with the IAB-MT receive timing, facilitating SDM Rx at the IAB-node. The provision for over-the-air synchronization, introduced in Rel-16 to enable an IAB-node to derive its IAB-DU Tx timing from the received DL signal by the collocated IAB-MT, is updated to account for the newly introduced Case 6 and Case 7 timing modes. Simultaneous operation of the IAB-MT and the IAB-DU is further facilitated by the ability of an IAB-node to indicate to a parent node a list of preferred IAB-MT beams with the associated conditions under which such beam preference applies, and by the ability of a parent node to indicate to the IAB-node a list of restricted IAB-DU beams with the associated conditions under which such beam restriction applies. Additionally, concurrent IAB-MT and IAB-DU operation, is aided by the ability of the IAB-node to indicate to a parent node a desired DL power adjustment and/or a desired IAB-MT Tx power spectral density range, where each indication includes the associated conditions for the desired adjustments. Optimizations for dual-connectivity operation of an IAB-node are introduced by supporting coordination of IAB-MT's TDD configuration to avoid conflicts from the two parent nodes, by supporting the exchange of IAB-DU resource configurations between parent nodes, by applying Rel-16 CA TDD prioritization rules, and by supporting a per-child MT link Unavailable resource configuration. RF and RRM requirements RAN4 decided to adopt following update to RF and RRM requirements for IAB enhancement: RF perspective: the requirement applicability for simultaneous operation is agreed to be included in specification with clarification that the different declaration on transmission power in simultaneous transmission is allowed for ACLR and Modulation quality. Timing error between IAB-DU and IAB-MT of the same IAB-Node is also defined for transmission mode case 6. RRM perspective: No impact is identified for RRM aspect to enable Rel-17 IAB enhancement except update with applicability clarification that existing transmit timing and timing adjust requirements of IAB-MTs apply when transmission mode is set to "case 1".

Summary based on the input provided by China Telecom in RP-220564. Coverage is one of the key factors that an operator considers when commercializing cellular communication networks due to its direct impact on service quality as well as CAPEX and OPEX. The Rel-17 study item 860036 "Study on NR coverage enhancements" evaluated the baseline performance and identified the potential bottleneck channels for both FR1 and FR2 [1]. This work item [2] specifies enhancements for PUSCH, PUCCH and Msg3 PUSCH, including enhancements on PUSCH repetition Type A, TB processing over multiple slots PUSCH, DMRS bundling for PUSCH/PUCCH, dynamic PUCCH repetition factor indication and Type A PUSCH repetitions for Msg3. The following key functionalities are introduced as part of the Work Item: Enhancements on PUSCH repetition Type A For PUSCH repetition Type A, the maximum number of repetitions is increased up to 32. The increased maximum number of repetitions is applicable to PUSCH repetition Type A scheduled by DCI format 0_1 and DCI format 0_2 as well as PUSCH repetition Type A with Type 1 and Type 2 configured grant. In addition, PUSCH repetition Type A supports the repetitions counted based on available slots, and the maximum of repetitions for counting based on available slots is 32. When the counting based on available slots is enabled, a UE follows the 2-step procedure to perform PUSCH transmissions: in the first step, the UE determines available slots for K PUSCH repetitions; in the second step the UE determines whether to drop each of the K PUSCH repetition or not according to PUSCH dropping rules, where the PUSCH repetition is still counted in the K repetitions even if it is dropped. TB processing over multiple slots PUSCH (TBoMS) A single Transport Block (TB) using a resource allocated over multiple slots is introduced for PUSCH except Msg3. A UE scheduled to perform a TBoMS transmission, via either dynamic or configured grant (Type 2), uses the resource allocated across multiple slots to calculate the transport block size (TBS) for the transmission. Advantages of this approach as compared to single-slot PUSCH operations are in the form of lower effective coding rate and/or energy per resource element (EPRE) increase, both advantages leading to coverage enhancement. A TBoMS transmission can be performed w/ or w/o repetition, where a TBoMS transmission w/o repetition is referred to as single TBoMS transmission. The number of slots allocated for TBoMS is counted based on available slots. The UE transmits the TB across the slots determined as available for the TBoMS transmission, applying the same symbol and PRBs allocation in each slot, regardless of whether TBoMS is scheduled w/ or w/o repetition. Collision handling rules of Type A PUSCH repetition apply for TBoMS. TBS of a single TBoMS transmission is calculated using the resource in all the slots allocated for the single TBoMS transmission. The maximum supported TBS for TBoMS does not exceed legacy maximum supported TBS in Rel-15/16, for the same number of layers. TBoMS supports the transmission of only one layer and one code block. A single redundancy version (RV) is used for the transmission of a single TBoMS, irrespective of the number of slots allocated for a single TBoMS transmission, as per Figure 11.4-1. RV cycling is used across repetitions of a single TBoMS, as per Figure 11.4-2 . Rate Matching (RM) for TBoMS is performed per slot.

DMRS bundling for PUSCH/PUCCH DMRS bundling to enable improved channel estimation is introduced for PUSCH repetition Type A scheduled by DCI format 0_1 or 0_2, for PUSCH repetition Type A with configured grant, for PUSCH repetition Type B, for TB processing over multiple slots PUSCH and for PUCCH repetitions of PUCCH formats 1, 3, and 4. A UE can report the maximum duration, in number of consecutives slots, during which the UE is able to maintain power consistency and phase continuity under certain tolerance level. With the duration of the nominal TDWs (Time Domain Windows), not longer than the maximum duration, configured by gNB, one or multiple nominal TDWs can be determined for PUSCH transmissions or PUCCH repetitions. A nominal TDW consists of one or multiple actual TDWs. Events, which cause power consistency and phase continuity not to be maintained across PUSCH transmissions or PUCCH repetitions within the nominal TDW, are defined. An actual TDW is terminated in case an event occurs. A new actual TDW is created in response to semi-static events not triggered by DCI or MAC-CE. Whether a new actual TDW is created in response to dynamic events triggered by DCI is subject to UE capability. Frequency hopping and UL beam switching for multi-TRP operation are regarded as semi-static events. The UE shall maintain power consistency and phase continuity within an actual TDW across PUSCH transmissions or PUCCH repetitions. Inter-slot frequency hopping with DMRS bundling to enable improved channel estimation within the same frequency hop is introduced for PUSCH repetition Type A, PUSCH repetition Type B, TBoMS and PUCCH repetitions. With the frequency hopping interval, N consecutive slots, configured by gNB, the UE performs inter-slot frequency hopping every N consecutive slots for PUSCH transmissions or PUCCH repetitions. Dynamic PUCCH repetition factor indication Dynamic repetition factor indication is introduced for PUCCH. This feature allows network to adjust PUCCH repetition factor in a flexible fashion based on channel conditions and traffic load. The mechanism to support this feature is an enhanced RRC configuration to configure different repetition factor per PUCCH resource. With this configuration, network can use existing PRI (PUCCH resource indicator) in DCI to point to a PUCCH resource where the associated repetition factor will be applied to the PUCCH transmission. By pointing to a different PUCCH resource via PRI, a different PUCCH repetition factor could apply, which implements the dynamic PUCCH repetition factor indication. Type A PUSCH repetitions for Msg3 Up to 16 repetitions is introduced for a Msg3 PUSCH transmission scheduled by RAR UL grant or DCI format 0_0 with CRC scrambled by TC-RNTI. This is beneficial to enhance the coverage on both NUL and SUL. After carrier selection and BWP selection during the RACH initialization procedure, a UE requests repetition of Msg3 PUSCH scheduled by RAR UL grant via separate PRACH resource when the RSRP of DL path-loss reference fulfils a configured threshold. If requested by the UE, gNB decides whether or not to schedule repetition of the Msg3 PUSCH transmission. If scheduled, the number of repetitions N is indicated by the 2 MSBs of the MCS field in the RAR UL grant or in the DCI format 0_0; and the MCS index used for the PUSCH transmission is indicated by the 2 LSBs of the MCS field in the RAR UL grant or by the 3 LSBs of the MCS field in the DCI format 0_0. The Msg3 PUSCH transmission is performed over N slots, which is counted based on available slots. Only inter-slot frequency hopping is supported if N>1 is indicated for the PUSCH transmission.

Summary based on the input provided by Qualcomm in RP-220544. This work item defines RF requirements for NR repeaters. These repeaters are network nodes designed to supplement/extend the coverage provided by base stations by simply amplifying and forwarding the signals from the input port without performing any other signal processing. Repeater types: RF requirements for repeater types 1-C and 2-O are defined. Repeater type 1-C covers the conducted requirements for FR1 while type 2-O covers the radiated requirements for FR2. Other types of repeaters are not covered in this Release. Repeater classes: Different repeater classes were introduced to cover different deployment scenarios and are differentiated for DL and UL as follows: DL classes:

• Wide Area repeaters are characterised by requirements derived from Macro Cell scenarios with a repeater to UE minimum distance along the ground equal to 35 m.
• Medium Range repeaters are characterised by requirements derived from Micro Cell scenarios with a repeater to UE minimum distance along the ground equal to 5 m.
• Local Area repeaters are characterised by requirements derived from Pico Cell scenarios with a repeater to UE minimum distance along the ground equal to 2 m.

UL classes:

• Wide Area repeaters are characterised by requirements derived from Macro Cell and/or Micro Cell scenarios.
• Local Area repeaters are characterised by requirements derived from Pico Cell and/or Micro Cell scenarios.

Repeater Operating Bands: NR repeater is designed to operate in the operating bands in FR1 and FR2-1 which are defined in TS 38.104. New bands added to 38.104 [] which are in these frequency ranges will automatically be applicable to the repeaters also. TDD Operation: NR repeaters specifications also cover operation in the TDD bands. In these bands, the repeaters are assumed to be synchronized to the base station in whose coverage they are deployed follow the UL/DL frame configuration that the base station is using.

Summary based on the input provided by Ericsson in RP-220191. This work item specifies downlink 1024QAM for NR PDSCH operation in FR1, which provides higher downlink peak rate compared with Release-15 NR, with the high downlink SINR and better channel condition (e.g., LOS or LOS-like channel), and with no mobility or very low mobility environment. Beside specifying the downlink 1024QAM mapping function, the WI also defines the corresponding MCS/CQI tables and RRC signalling, as well as the corresponding BS/UE RF requirements to transmit/receive the signals with 1024QAM [2]. Introduction of the modulation mapping function of 1024QAM It was introduced the modulation mapping function of 1024QAM for PDSCH, where 10 tuples of bits, {b_i,…,b_(i+9) } are mapped to complex-valued modulation symbols d(i), according to Introduction of MCS table supporting 1024QAM For supporting 1024QAM for PDSCH, a new five-bit MCS table with 1024QAM entries was introduced by removing 5 MCS entries and adding 5 new entries for 1024QAM from the existing MCS index table 2. The removed MCS indexes are 2, 4, 6, 8, and 10. The added MCS entries for 1024QAM are given as follows:

New RRC signalling was also introduced to indicate use of 1024QAM MCS table. Introduction of CQI table supporting 1024QAM For supporting 1024QAM for PDSCH, a new CQI table with 1024QAM entries was introduced by reusing LTE CQI table with 1024QAM entries as follows:

New RRC signalling was also introduced to indicate use of 1024QAM CQI table. BS Tx EVM for DL 1024QAM The Error Vector Magnitude (EVM) is a measure of the difference between the ideal symbols and the measured symbols after the equalization. The required gNB Tx EVM for 1024QAM is set to 2.5% for frequencies equal to or below 4.2GHz and 2.8% for frequencies above 4.2GHz in FR1.

Summary based on the input provided by Ericsson in RP-220464. Dynamic spectrum sharing (DSS) provides a very useful migration path from LTE to NR by allowing LTE and NR to share the same carrier. DSS was included already in Rel-15 and further enhanced in Rel-16. As the number of NR devices in a network increases it is important that sufficient scheduling capacity for NR UEs on the shared carriers is ensured. This is addressed by this WI, which introduces the support for cross-carrier scheduling from SCell to PCell/PSCell. When cross-carrier scheduling from an SCell to sPCell is configured:

• PDCCH on that SCell can schedule sPCell's PDSCH and PUSCH,
• PDCCH on the sPCell can schedule sPCell's PDSCH and PUSCH but cannot schedule PDSCH and PUSCH on any other cell.

Only one SCell can be configured to be used for cross-carrier scheduling to sPCell. The maximum number of monitoring candidates and non-overlapping CCEs for PDCCH monitoring (to schedule the sPCell) are split between the sPCell and the SCell used for scheduling the sPCell. The split is indicated via an RRC configured scaling factor.