R2-2504001.zip |
TDoc file unavailable |
|
R2-2504025 Discussion on eDRX operation with emergency PDU session.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504025
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda item: 6.1.3.1
Title: Discussion on eDRX operation with emergency PDU session
Source: ZTE Corporation
Document for: Discussion and Decision
|
Conclusion
Based on the above, RAN2 is requested to discuss and agree on the following observations and proposals:
Observation 1: According to reply LSs, both SA2 and RAN3 confirm that RAN node can be aware of the presence of emergency PDU session based on the reserved ARP value.
Observation 2: Based on RAN3 endorsed stage 2 CR, if the UE is configured with emergency PDU session, RAN node cannot release the UE to RRC_INACTIVE state with RAN eDRX configuration.
Observation 3: Even if the gNB cannot recognize emergency PDU session and mistakenly releases the UE to RRC_INACTIVE state with RAN eDRX configured, there is no benefit to ask the UE to ignore the RAN eDRX configuration and it will waste UE’s power.
Proposal 1: RAN2 confirm that the RRC_INACTIVE UE does not need to ignore the RAN eDRX (if configured) when the UE has emergency PDU session (no spec change is needed).
Proposal 2: RAN2 confirm that if gNB is able to recognize the presence of emergency PDU session, the gNB can also keep the UE in RRC_CONNECTED state for fast emergency callback (this is not forbidden by the endorsed RAN3 CR).
Proposal 3: Approve the reply LS to SA2 and RAN3 in [4].
|
R2-2504203 correction on eventD1D2_v2.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504203
St. Julian’s, Malta, May 19th – 23rd , 2025
Agenda item: 6.1.3.1
Source: Samsung
Title: Corrections on measurement with (cond)EventD1/D2/T1
WID/SID: NR_NTN_solutions, NR_NTN_enh-Core
Document for: Discussion and Decision
|
Conclusion
In this contribution we discussed the following proposals.
Observation 1: For eventD1/D2 distance measurement and condEventT1 time measurement, layer 3 filtering is also not applicable, thus, should be clarified as an exceptional case.
Proposal 1: Clarify in clause 5.5.3.1 that UE does not apply the layer 3 filtering as specified in 5.5.3.2 to derive distance measurements and time measurements.
Observation 2: Trigger quantity and measurement quantity are not defined for eventD1/D2 or condEventD1/D2/T1. It is not clear for UE how to derive cell measurement results for measurement configuration with eventD1/D2 or with condEventD1/D2/T1.
Proposal 2: Clarify that UE doesn’t derive cell measurement results based on SSB or CSI-RS measurements for distance measurements and time measurements, considering trigger quantity or measurement quantity cannot be configured in these cases.
Observation 3: For CHO with condEventD1/D2/T1 only, it is not clear whether/how UE performs cell measurement based on SSB/CSI-RS when no RRM event is configured and how to determine applicable cell.
Proposal 3: To determine applicable cell for CHO with only condEventD1/D2/T1, clarify in clause 5.3.5.13.4 that UE considers the cell detected on the associated measObject which has a physical cell identity matching the value in CHO configuration.
Observation 4: For event-triggered measurement with eventD1/D2, it is not clear how UE determines applicable cell to be included in the measurement report.
Proposal 4: Capture a note that it is up to UE implementation to determine the applicable cell(s) for event-triggered measurement with eventD1/D2.
|
R2-2504456 Discussion on rsrp-ThresholdSSB-r17 in TS 38.331.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504456
St. Julians, Malta, May 19th – 23rd, 2025
Agenda item: 6.1.3.1
Source: Huawei, HiSilicon, Qualcomm, MediaTek, ZTE, Xiaomi, Vivo, Ericsson
Title: Discussion on rsrp-ThresholdSSB-r17 in TS 38.331
Document for: Discussion and Decision
1. |
Conclusion
In this contribution, we have following proposal:
Proposal 1: RAN2 to discuss for 4-step Case 1 (Rel-15):
If the rsrp-ThresholdSSB (without suffix) is absent in rach-ConfigCommon (without suffix);
Option 1a: The UE shall not apply any threshold for SSB selection in the 4-step RA procedure (majority).
Option 1b: The network should always include rsrp-ThresholdSSB in rach-ConfigCommon.
Proposal 2: RAN2 to agree for 4-step Case 2 and case 3 (Rel-17):
If the rsrp-ThresholdSSB-r17 is absent in FeatureCombinationPreambles included in rach-ConfigCommon(without suffix) or rach-ConfigCommon-r17, the UE shall apply the corresponding parameter (i.e. rsrp-ThresholdSSB without suffix) included in the RACH-ConfigCommon which includes the FeatureCombinationPreambles.
Furthermore, if the rsrp-ThresholdSSB-r17 is absent in FeatureCombinationPreambles and the rsrp-ThresholdSSB (without suffix) is absent in the RACH-ConfigCommon which includes the FeatureCombinationPreambles, the UE shall not apply any threshold for SSB selection in the 4-step RA procedure, i.e. NO parameter selection fallback from the rach-ConfigCommon-r17 in AdditionalRACH-Config-r17 to rach-ConfigCommon (without suffix).
Proposal 3: RAN2 to discuss for 2-step Case 4 (Rel-16):
If the msgA-RSRP-ThresholdSSB-r16 is absent in msgA-ConfigCommon-r16;
Option 4a: The UE shall not apply any threshold for SSB selection in the 2-step RA procedure (majority).
Option 4b: The network should always include msgA-RSRP-ThresholdSSB-r16 in msgA-ConfigCommon-r16.
Proposal 4: RAN2 to discuss for 2-step Case 5 (Rel-17):
If the rsrp-ThresholdSSB-r17 (i.e. msgA-RSRP-ThresholdSSB for 2-step RA procedure) is absent in FeatureCombinationPreambles-r17 included in msgA-ConfigCommon-r16 or msgA-ConfigCommon-r17.
Option 5a: The UE shall apply the rsrp-ThresholdSSB-r17 if included in rach-ConfigCommon for the same feature combination. If there is no rsrp-ThresholdSSB-r17 in rach-ConfigCommon for the same feature combination, the UE shall apply the msgA-RSRP-ThresholdSSB-r16 if included in msgA-ConfigCommon-r16 or msgA-ConfigCommon-r17 including the FeatureCombinationPreambles-r17.
Option 5b: The UE shall apply the msgA-RSRP-ThresholdSSB-r16 if included in the msgA-ConfigCommon-r16 or msgA-ConfigCommon-r17 including the FeatureCombinationPreambles-r17. (slight Majority)
Proposal 5: RAN2 to discuss for 2-step Case 6 (Rel-17):
If the msgA-RSRP-ThresholdSSB-r16 is absent in msgA-ConfigCommon-r17 and rsrp-ThresholdSSB-r17 (i.e. msgA-RSRP-ThresholdSSB for 2-step RA procedure) is absent in FeatureCombinationPreambles-r17 included in the msgA-ConfigCommon-r17;
Option 6a: The UE shall not apply any threshold for SSB selection in the 2-step RA procedure, i.e. NO parameter selection fallback from the msgA-ConfigCommon-r17 in AdditionalRACH-Config-r17 to msgA-ConfigCommon-r16 (Majority).
Option 6b: The network should always include either msgA-RSRP-ThresholdSSB-r17 in msgA-ConfigCommon-r16 or rsrp-ThresholdSSB-r17 (i.e. msgA-RSRP-ThresholdSSB for 2-step RA procedure) is included in FeatureCombinationPreambles-r17 which is included in the msgA-ConfigCommon-r17.
A TP is provided for the proposal in the annex and company can check whether or not the specification change is needed. We can discuss/review them after we have some agreement on the proposals at the online meeting.
4. |