TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130	R2-2504094
Malta, Malta, 19th – 23rd May, 2025	


Agenda item:	8.19.1
Source:	Samsung, Google
Title:	Redirection from TN to IoT NTN and NR NTN
WID/SID:	TEI19
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss proposals related to Release with re-direction to an NTN frequency:
Observation 1: A lot of effort have been put in mobility enhancements for NTN, but TN to NTN mobility is still not fully supported.      
Observation 2: Redirection from LTE TN to NR NTN is supported in Release 19.      
Observation 3: Redirection from NR TN to NR NTN cannot really be considered supported without procedural clarification and a capability in Release 19.      
Observation 4: In the current IoT NTN capability framework, the UE reports capabilities according to network type, making redirection to NTN difficult.      

Proposal 1: RAN2 to discuss options to support redirection to NR NTN: 
Option A: UE uses the frequency received in redirectedCarrierInfo and matches it to frequencies in SIB19 to determine whether the frequency is an NTN band and its associated NTN assistance information. A new capability is introduced to support this for the NTN bands UE indicates support of. 
Option B: The UE is configured with an indicator whether the frequency is NTN and and/or with NTN assistance information. A new capability is introduced to support this for the NTN bands the UE indicates support of.  
Option C: The UE is configured with satellite ephemeris in the release message. This serves as an indication of NTN band and a new capability is introduced to support this for the NTN bands the UE indicates support of. 
Proposal 2: RAN2 to consider the text proposal in Appendix A1, B1 and C1 as baseline, depending on Option A, B or C in Proposal 1. 
Proposal 3: To support TN to IoT NTN redirection, the capabilities related to redirection from TN to IoT NTN are considered TN-capabilities, and are thus signalled to the terrestrial network.  
Proposal 4: The required capabilities for redirection from TN to NTN is the capability to perform the redirection as well as the supported bands.  
Proposal 5: To support TN to IoT NTN redirection, the LTE TN to NR NTN solution may be reused: Release message contains a list of satellite IDs, which refers to satellite elements in SIB33.  

3GPP TSG-RAN WG2 #130	R2-2504345
St. Julians, Malta, May 19th – 23rd, 2025						    	 

Agenda item:	8.19.1
Source: 	Ericsson
Title:  	Scheduling Request (SR) to Random Access (RA) Fallback Enhancements
Document for:	Discussion and Decision

Conclusion
In the previous sections we made the following observations: 
Observation 1	Only a limited number of SRs can be processed in a scheduling instance.
Observation 2	Continuous SR attempts from UEs to a highly loaded or congested gNB results in an early or unnecessary fallback to the RA procedure. In a cyclic fashion, subsequent RA attempts would increase the load on the RACH and in turn gNB load/congestion.
Observation 3	Reconfiguration of PUCCH SR resources for several UEs in a high loaded system will reduce the overall performance and introduce time delays/latency spikes.
Observation 4	Always configuring a longer SR prohibit timer leads to unnecessary delays even when the gNB is not congested.
Observation 5	When the gNB is not congested, low latency services like TCC should be configured with a shorter prohibit timer to avoid unnecessary delays. This of course has a high risk of reaching the maximum SR attempts if the gNB experiences congestion.
Observation 6	Delay the fallback to the RA procedure with an additional (longer) prohibit timer and a corresponding threshold (number of failed SR attempts) as trigger to use this timer, thereby reducing the frequency of SR attempts. This enables the gNB to recover from congestion/high loading whilst allowing the UE to maintain the PUCCH SR resources i.e., it prevents early/unnecessary fallback to the RA procedure.
Observation 7	Network configuration of the threshold of number of failed SR attempts can ensure that the second prohibit timer is applied only at congestion/high loading in the gNB.
Based on the discussion in the previous sections we propose the following:
Proposal 1	Address the issue in the current SR mechanism of early/unnecessary fallback to the RA procedure.
Proposal 2	gNB can configure an additional prohibit timer along with a threshold for the number of failed SR attempts to apply this timer.
Proposal 3	UE can revert to the configured sr-ProhibitTimer for the next SR attempts once the UE has received a grant for scheduling UL/DL data.

3GPP TSG-RAN WG2 Meeting #130	R2-2504507
Malta, MT, 19th – 23rd May, 2025

Agenda Item:	8.19.1
Source:	Huawei, HiSilicon, Nokia, Ericsson
Title:	Discussion and TP for band specific capability for paging [Per_Band_Paging_Cap]
Document for: Discussion and Decision 
1	

Conclusion
This contribution makes the following proposals:
 Observation 1a:	The last meeting agreed “issue of band specific capability” should apply to any legacy features, which is per band capability and follows the feature specific cell barring check (including (2Rx XR UE, NES UE).
Observation 1b:	For the (e)RedCap UE Rx branches, which is FSPC capability, the network implementation determines the (e)RedCap UE Rx per band capability based on maxNumberMIMO-LayersPDSCH.
Observation 2:	The two TEI issues discussed in last meeting:
The TEI feature for “band specific capability” is for legacy UE capabilities, which was agreed to not impact UE behaviour, i.e. no new UE capability introduced.
The TEI feature for “paging container” is for new R19 UE capabilities, which requires new UE radio capabilty signaling added.
Proposal 1a:	Agree the R19 TEI: add per band UE paging capability information in UERadioPagingInformation for the legacy features, which is band related capability and follows the feature specific cell barring check (including (e)RedCap UE, 2Rx XR UE, NES UE).
Proposal 1b:	Suggest to use “[Per_Band_Paging_Cap]” as the R19 TEI identifier.
Proposal 2:	RAN2 to further discuss the attached Text Proposal of the R19 TEI CR for [Per_Band_Paging_Cap].
Proposal 3:	RAN2 to further discuss whether the legacy 2Rx XR and NES features can be added in UE-RadioPagingInfo-r19 as new fields.

 

4	Text Proposal
11.2.2	Message definitions
–	UERadioPagingInformation
This message is used to transfer radio paging information, covering both upload to and download from the 5GC, and between gNBs.
Direction: gNB to/ from 5GC and gNB to/from gNB
UERadioPagingInformation message
-- ASN1START
-- TAG-UE-RADIO-PAGING-INFORMATION-START

UERadioPagingInformation ::= SEQUENCE {
    criticalExtensions                  CHOICE {
        c1                                  CHOICE{
            ueRadioPagingInformation            UERadioPagingInformation-IEs,
            spare7 NULL,
            spare6 NULL, spare5 NULL, spare4 NULL,
            spare3 NULL, spare2 NULL, spare1 NULL
        },
        criticalExtensionsFuture            SEQUENCE {}
    }
}

UERadioPagingInformation-IEs ::=    SEQUENCE {
    supportedBandListNRForPaging        SEQUENCE (SIZE (1..maxBands)) OF FreqBandIndicatorNR    OPTIONAL,
    nonCriticalExtension                UERadioPagingInformation-v15e0-IEs                      OPTIONAL
}

UERadioPagingInformation-v15e0-IEs ::= SEQUENCE {
    dl-SchedulingOffset-PDSCH-TypeA-FDD-FR1     ENUMERATED {supported}          OPTIONAL,
    dl-SchedulingOffset-PDSCH-TypeA-TDD-FR1     ENUMERATED {supported}          OPTIONAL,
    dl-SchedulingOffset-PDSCH-TypeA-TDD-FR2     ENUMERATED {supported}          OPTIONAL,
    dl-SchedulingOffset-PDSCH-TypeB-FDD-FR1     ENUMERATED {supported}          OPTIONAL,
    dl-SchedulingOffset-PDSCH-TypeB-TDD-FR1     ENUMERATED {supported}          OPTIONAL,
    dl-SchedulingOffset-PDSCH-TypeB-TDD-FR2     ENUMERATED {supported}          OPTIONAL,
    nonCriticalExtension                UERadioPagingInformation-v1700-IEs          OPTIONAL
}

UERadioPagingInformation-v1700-IEs ::= SEQUENCE {
    ue-RadioPagingInfo-r17                 OCTET STRING (CONTAINING UE-RadioPagingInfo-r17)     OPTIONAL,
    inactiveStatePO-Determination-r17      ENUMERATED {supported}                               OPTIONAL,
    numberOfRxRedCap-r17                   ENUMERATED {one, two}                                OPTIONAL,
    halfDuplexFDD-TypeA-RedCap-r17         SEQUENCE (SIZE (1..maxBands)) OF FreqBandIndicatorNR OPTIONAL,
    nonCriticalExtension                   UERadioPagingInformation-v1800-IEs                   OPTIONAL
}

UERadioPagingInformation-v1800-IEs ::= SEQUENCE {
    numberOfRxERedCap-r18                  ENUMERATED {one, two}                                OPTIONAL,
    supportOf2RxXR-r18                     ENUMERATED {supported}                               OPTIONAL,
    nonCriticalExtension                   UERadioPagingInformation-v1840-IEs                   OPTIONAL
}

UERadioPagingInformation-v1840-IEs ::= SEQUENCE {
    dl-SchedulingOffset-PDSCH-TypeA-FDD-FR2-NTN-r18    ENUMERATED {supported}                   OPTIONAL,
    dl-SchedulingOffset-PDSCH-TypeB-FDD-FR2-NTN-r18    ENUMERATED {supported}                   OPTIONAL,
    nonCriticalExtension                                                             OPTIONAL
}









-- TAG-UE-RADIO-PAGING-INFORMATION-STOP
-- ASN1STOP

3GPP TSG-RAN WG2 Meeting #130	R2-2504541
St.Julians, Malta, May 19th – 23rd, 2025

Agenda item:		8.19
Source:				Samsung
Title:						Leftover issue on ANR reporting of HSDN cells in INM
measurement
Document for:		Discussion 
1 

Conclusion
In section 2, the following observations are made:
Observation 1: Since the UE can only be configured with a single reportCGI configuration from either MN or SN, configuration of ANR requires coordination between MN and SN for MR-DC. 
Observation 2: For (NG)EN-DC and NR-DC, HSDN indication for the NR neighbour cell is transferred from MN to SN if reported by UE as part of report CGI procedure. 
Observation 3: For NE-DC, HSDN indication for the E-UTRA neighbour cell is NOT transferred from MN to SN even if reported by UE as part of report CGI procedure. 
Based on above, RAN2 is requested to discuss and agree on the following proposal:
Proposal 1: RAN2 to confirm that HSDN indication for the NR neighbour cell is transferred from MN to SN if reported by UE as part of report CGI procedure for (NG)EN-DC and NR-DC. No specification change is needed. 
Proposal 2: RAN2 to discuss whether to transfer HSDN indication for E-UTRA neighour cell from MN to SN i.e. introduce hsdn-Cell-r19 in CG-ConfigInfo-v1900-IEs.
4 

3GPP TSG-RAN WG2 Meeting #130	R2-2504576
Malta, 19th-23rd May, 2025

Agenda item:	8.19.1
Source: 	Huawei, HiSilicon, China Unicom, Sony, Turkcell, NTT Docomo INC., Meta, Ericsson, Reliance Jio, Vodafone, ZTE Corporation, British Telecom, Deutsche Telekom, Vivo, LG Electronics Inc.
Title: 	Support early CSI acquisition for L3 Handover
Document for:	Discussion and Decision

Conclusions
In this contribution, we analysed the throughput degradation issue during handover and made the following observation:
Observation 1: During handover, it typically takes tens of milliseconds (e.g. up to 80ms) for target cell to receive the first CSI report from the UE. Only after receiving the CSI report the target can increase MCS for data transmission. This delay results in a degradation of throughput during handover.
We further discussed the RAN1 agreements for early CSI acquisition for LTM and propose the following for L3 handover.
Proposal 1: RAN2 to address the throughput degradation issue for L3 handover, and adapt the mechanism of early CSI acquisition and CSI reporting, as agreed for LTM, to L3 handover as part of TEI19.
Proposal 2: RAN2 adapts the following framework for early CSI acquisition and CSI reporting for L3 handovers:
CSI-RS configuration provided in handover command. (details as in 5.1 of Appendix)
Measures CSI-RS upon reception of handover command.
CSI reporting re-uses LTM solution framework.

3GPP TSG RAN WG2#130	R2-2504600
St Julian’s, Malta, 19th - 23rd May 2025

Agenda Item:	8.19.1
Source:	Nokia 
Title:	Discussion on UE capability change 
Document for: Discussion and Decision 
1	

Conclusion
Based on the discussion the following is proposed:
Proposal 1: The UE informs the gNB of its intention to leave RRC_CONNECTED due to a UE capability change 
Proposal 2: Consider using UAI or new RRC message to inform the gNB UEs intention to leave RRC_CONNECTED due to a UE capability change