3GPP TSG-RAN WG1 Meeting #121	R1-2503258
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda Item:	5
Source:	Huawei, HiSilicon
Title:	Discussion on startSFN for positioning UTW
Document for:	Discussion and Decision

Conclusion
This paper discussed the two questions from RAN2, based on the RAN1 discussion/agreements and the current signaling design from RAN2, which leads to the following proposal:
Proposal: Reply to the two questions to RAN2 as follows.

3GPP TSG-RAN WG1 Meeting #121	R1-2503265
St Julian’s, Malta, May 19 – 23, 2025

Agenda Item:	5
Source:	Huawei, HiSilicon
Title:	Discussion on LS on the transient period for SBFD operation
Document for:	Discussion and Decision

Conclusions
In this contribution, the following are proposed:
Proposal: From RAN1 perspective, explicit indication of transition periods between SBFD and non-SBFD symbols is not supported.

3GPP TSG RAN WG1 #121			R1-2503309
St Julian’s, Malta, May 19th – 23rd, 2025

Source: 	ZTE Corporation, Sanechips
Title:	Discussion on LP-WUS UE RF
Agenda item: 	5
Document for:	Discussion and decision

Conclusions 
In this contribution, we have discussed issues on RAN4 LS and make the following proposals:
Proposal 1: Discuss and decide whether to reconsider the LP-WUS SNR target based on RAN4 MR NF assumption

Proposal 2: Capture the following information into the reply LS to RAN4
Chip rate could be 1, 2,4 if it refers to number of OOK symbols in an OFDM symbol 
RM coding and Manchester coding is supported, FFS code rate and details
Information bits for LP-WUS in idle/inactive and connected mode is up to 5bits , 
CRC bits my not be needed

3GPP TSG RAN WG1 #121			R1-2503310
St Julian’s, Malta, May 19th – 23rd, 2025

Title:	Draft reply on LP-WUS UE RF
Response to:	
Release:	Rel-19
Work Item:	NR_LPWUS

Source:	RAN1
To:	RAN4
Cc:	

Contact person:	
Send any reply LS to:	3GPP Liaisons Coordinator, mailto:3GPPLiaison@etsi.org

Attachments:	

1	Overall description
RAN WG1 thanks RAN WG4 for their LS on R1-2501703/ R4-2503003 and would like to provide the following answer:
Question: 
“ Further details on signal configuration of LP-WUS and LP-SS for both idle/inactive and connected modes to facilitate deriving SNR with sufficient coverage are helpful, e.g.,
Chip rate and length of information bits (the number of ON/OFF symbols for the single LP-WUS transmission) of OOK sequence
Coding, if any
Whether CRC will be configured? If CRC is configured, what length of CRC is used?
Any other information relevant to detection sensitivity. ”
Answer:
Chip rate: M=1,2,4 are supported if the chip rate refers to number of OOK symbols in an OFDM symbol.
Length of information bits: up to 5bits in idle/inactive mode and connected mode.
Coding: RM coding and Manchester are supported. 
CRC: CRC bits is not needed in RAN1’s perspective.

2	Actions
To RAN4:
ACTION: 	RAN WG1 kindly asks RAN WG4 to take the information above into account.
3	Dates of next TSG-RAN WG1 meetings
TSG-RAN WG1 Meeting #122 	25 - 29 August 2025	             Bengaluru, IN
TSG-RAN WG1 Meeting #122bis 	13 - 17 October 2025	             Prague, CZ

TDoc file conclusion not found

3GPP TSG-RAN WG1 Meeting #121	R1-2503339
St Julian’s, Republic of Malta, May 19th – 23rd, 2025
Agenda Item:	5
Source:	Ericsson
Title:	Discussion LS on CB-msg3-EDT
Document for:	Discussion

1	

Conclusion
Based on the discussion in the previous sections we propose the following:

Proposal 1	Answer to Q1: For CB-Msg3-EDT in LTE-MTC NTN, the initial transmit power for Msg3 can be supported following the same approach used by PUR, where the legacy “UE transmit power” in clause 5.1.1.1 of TS 36.213 is set to act as an open loop power control.
	The required control parameters (p0-UE-PUSCH-r16 and alpha-r16) are already in “PUR-Config”.
	If for subsequent attempts (if any), a power ramping mechanism were intended to be introduced, then the “powerRampingStep” parameter would need to be included in the pre-configuration, and RAN1 would have to reflect this into the technical specifications. In our view, it is sufficient to rely on the initial transmit power formula using the control parameters already present in “PUR-Config”.
Proposal 2	Answer to Q1: For CB-Msg3-EDT in NB-IoT NTN, the initial transmit power for Msg3 can be supported following the same approach used by PUR, where the legacy open-loop “UE transmit power” in clause 16.2.1.1.1 of TS 36.213 is applied accounting for the path loss estimate regardless of the number of repetitions.
	The required control parameters (p0-UE-NPUSCH-r16 and alpha-r16) are already in “PUR-Config-NB”.
	If for subsequent attempts (if any), a power ramping mechanism were intended to be introduced, then the “powerRampingStep” parameter would need to be included in the pre-configuration, and RAN1 would have to reflect this into the technical specifications. In our view, it is sufficient to rely on the initial transmit power formula using the control parameters already present in “PUR-Config-NB”.
Proposal 3	Answer to Q2: For CB-Msg3-EDT in LTE-MTC NTN and the “MPDCCH configuration”:
	RAN1 confirms that the “TDD parameter” in “PUR-MPDCCH-Config-r16” is not needed (TDD operation is not supported for LTE-MTC NTN).
	On “maybe narrowband configuration should be defined as a set, not one single narrow band”, in LTE-MTC there are 6 PRBs per narrowband, it is unclear the need of defining it as “a set” (In our understanding the need for defining a set is for Msg3 UL since a subcarrier(s) is to be randomly selected by the UE within a set of subcarriers, but not for DL). To avoid incurring in backward compatibility issues, it is recommended keep using legacy definitions.
Proposal 4	Answer to Q3: For CB-Msg3-EDT in LTE-MTC NTN and the “PUSCH configuration”:
	On “Whether pusch-CyclicShift-r16 and pusch-NB-MaxTBS-r16 are needed”:
o	The parameter “pusch-CyclicShift-r16” is not needed since it is only relevant for Shared PUR (i.e., overlapped UL transmissions of up to 2 UEs at low SNR, i.e., CE Mode B).
o	The parameter “pusch-NB-MaxTBS-r16” refers to the support of maximum uplink TBS of 2984 bits when the UE is operating in coverage enhancement mode A, which in our view can be kept unless there were a reason to do the opposite.
	On “Whether prb-AllocationInfo should be defined as a set”. In our understanding, a UE in CB-msg3-EDT will randomly transmit on any of the subcarriers encompassing the resource reserved for UL transmissions, thus for CB-msg3-EDT the parameter “prb-AllocationInfo” likely will require to be redefined as a set of PRBs or subcarriers where the UE is allowed transmit. To facilitate the design, RAN2 can consider using sub-PRB as baseline in such a way that the CB-msg3-EDT resource would be one PRB, where the set to be defined would span from 0 to 11 subcarriers (this would be equivalent to what can be achieved for NB-IoT with 15 kHz SCS). This decision is up to RAN2.
Proposal 5	Answer to Q4: For CB-Msg3-EDT in LTE-MTC NTN and the “PDSCH configuration”:
	PUR stands for Pre-configured Uplink Resources and therefore in Rel-16 the standardization of such feature focused on preconfiguring PUSCH (including a layer-1 or a layer-2/3 signalling response). Thus, there is no PDSCH pre-configuration, the parameters “pur-PDSCH-FreqHopping-r16” and “pur-PDSCH-maxTBS-r17” were included aiming to providing better synergies with uplink.
	On “RAN2 would like to check with RAN1 on whether and how to define the detail PDSCH configuration.” Like in PUSCH, the pre-configuration of PDSCH would need to include essentially the allocation of resources in the frequency-domain and time-domain, modulation scheme, and number of repetitions.
Proposal 6	Answer to Q5: For CB-Msg3-EDT in LTE-MTC NTN and the “PUCCH configuration”:
	PUCCH is used to acknowledge the reception of downlink data (i.e., PDSCH), thus it is not directly related to the pre-configured uplink transmissions. Nonetheless, in our understanding the PUR procedure may involve downlink transmissions that may require to be ACK (e.g., a L2/L3-ACK provided using PDCCH/PDSCH, or a re-configuration), and in those cases “n1PUCCH-AN-r16” and “pucch-NumRepetitionCE-Format1-r16” are relevant.
	On “how to define the detailed PUCCH configuration”, in our understanding the parameter “n1PUCCH-AN-r16” refers to indices utilized to determine the PRB allocated for performing the PUCCH transmission, whereas “pucch-NumRepetitionCE-Format1” configures the number of repetitions for the PUCCH transmission. In our view, both parameters already in “PUR-Config” can be reused for the support of CB-msg3-EDT.
Proposal 7	Answer to Q6: For CB-Msg3-EDT in NB-IoT NTN and the “NPUSCH configuration”:
	For performing a pre-configured allocation of NPUSCH transmission, in principle all the npusch related parameters in “PUR-Config-NB” are relevant, although RAN2 needs to decide if both 3.75 kHz SCS and 15 kHz SCS are intended to be supported, and yet for the latter one whether both single-tone and multi-tone or only single-tone are to be supported. Depending on those decisions, some parameters may not be needed.
	The parameter “npusch-CyclicShift-r16” is not needed since it is only relevant for Shared PUR (i.e., overlapped UL transmissions of up to 2 UEs at low SNR, i.e., when the UL transmission duration is ≥ 64 ms).
	The parameter “npusch-SubCarrierSetIndex-r16” refers to the allocated subcarrier(s) for either 3.75 kHz SCS or 15 kHz SCS within 180 kHz. In our understanding, a UE in CB-msg3-EDT will randomly transmit on any of the subcarriers encompassing the resource reserved for UL transmissions (it can be the 180 kHz or less than that), thus for CB-msg3-EDT the parameter “npusch-SubCarrierSetIndex-r16” likely will require to be redefined as sets of subcarriers where the UE is allowed transmit e.g., in the case of 3.75 kHz SCS the 48 subcarriers could be divided into four sets consisting of 12 subcarriers each. In the case of 15 kHz SCS, the set to be defined would span from 0 to 11 subcarriers. Whether to support 3.75 kHz SCS and 15 kHz SCS (both multi-tone and single-tone or only single-tone), and the definition of the sets is up to RAN2 to decide.
Proposal 8	Answer to Q7: For CB-Msg3-EDT in NB-IoT NTN and the “NPDCCH configuration”:
	In our understanding “NPDCCH-ConfigDedicated-NB-r13” has the parameters that are needed to configure NPDCCH and therefore can be used as baseline for the CB-msg3-EDT feature.
Proposal 9	Answer to Q8: For CB-Msg3-EDT in NB-IoT NTN and LTE-MTC:
	If a power ramping mechanism were intended to be introduced for Msg3, then the “powerRampingStep” would need to be included and there will be a RAN1 spec impact. So, as stated in the response to question 1, in our view it is sufficient to rely on the initial transmit power formula using the control parameters already present in “PUR-Config/ PUR-Config-NB”.
	Thus, given the feedback provided to the questions in the LS, at this point no additional L1 parameters are identified as needed for CB-Msg3-EDT.
Proposal 10	RAN1 to include in the LS reply to RAN2 the responses to Questions 1 to 8 accounting for the feedback provided from proposal 1 to 9, which aim at minimizing the impact on the technical specifications for the support of CB-Msg3-EDT.

5	

3GPP TSG RAN WG1 #121			R1-2503340
St Julian’s, Malta, May 19th – 23th, 2025

Title:	Draft reply on UL Tx switching for TEI19
Response to:	R4-2505221
Release:	Release 19
Work Item:	TEI-19

Source:	RAN1
To:	RAN4
Cc:	

Contact Person:	 
Name:	
E-mail Address:	


Attachments:	None
1	Discussion
RAN1 would like to thank RAN4 for the LS on UL Tx switching, where three scenarios are described. RAN1 discussed scenarios 1a and 2 in the LS as listed below.
RAN1 specification supports 4Tx codebook based and non-codebook based UL transmission for PUSCH in Rel-15. RAN1 further specified 3Tx codebook based and non-codebook based UL transmission for PUSCH in Rel-19. From RAN1 perspective 3Tx and 4Tx UL transmission is supported for a single carrier, and it is not in the scope of RAN1 to discuss/specify the necessary requirements including required ‘gap’ for uplink Tx switching. RAN1 does not have the necessary expertise and knowledge on the implications of uplink Tx switching hence cannot provide meaningful reply on whether to support scenario 1a and/or scenario 2 as described in the LS.
Please find RAN1 answer for the question below.
Question: Decide at RAN1#121 whether to support scenario 1a and/or scenario 2 in Rel-19 as part of TEI-19, and feedback to RAN4 the decision. 

Answer: RAN1 has agreed that it does not have the necessary expertise and knowledge on the implications of uplink Tx switching hence cannot provide meaningful reply on whether to support scenario 1a and/or scenario 2.
RAN1 respectfully ask RAN4 to take above answer into account in the future work.
2	Actions
To RAN4
ACTION:   RAN1 respectfully asks RAN4 to take above answer into account in the future work.
3	Dates of next TSG RAN WG1 meetings
TSG-RAN2 Meeting #122	25-29 August, 2025	             Bengaluru, India
TSG-RAN2 Meeting #122b	13 - 17 October, 2025	             Prague, Czech Republic

TDoc file conclusion not found

3GPP TSG-RAN WG1 Meeting #121							         R1-2503341
St Julian's, Malta, 19 - 23 May, 2025

Source:	vivo
Title:	Discussion on the transient period for SBFD operation
Agenda Item:	5
Document for:	Discussion and Decision

Conclusion
The proposals for the discussion on the transient period for SBFD operation are summarized as follows.

Proposal 1: RAN1 supports that the transient period for Case B or Case C is handled by gNB implementation.  
For Case B, the transient period can be reserved only in the DL part(s) of SBFD symbol(s) or in the whole channel bandwidth, up to gNB implementation
For Case C, it is up to gNB implementation that Option 1 (guard symbols reserved in non-SBFD DL symbol(s)) or Option 2 (blanked SBFD symbols in the beginning of SBFD UL transmission) is adopted for the transient period

TDoc file reading error

3GPP TSG RAN WG1 #121			R1-2503344
St Julian’s, Malta, May 19th – 23th, 2025

Title:	Draft reply LS on differentiation of sDCI mTRP, mDCI mTRP and sTRP
Response to:	R2-2411244
Release:	Release 18
Work Item:	NR_MIMO_evo_DL_UL-Core

Source:	RAN1
To:	RAN2
Cc:	

Contact Person:	
Name:	
E-mail Address:	


Attachments:	None
1	

TDoc file conclusion not found

3GPP TSG RAN WG1 #121	R1-2503431
St Julian’s, Malta, 19 - 23 May 2025

Agenda item: 		5
Source:	Nokia
Title:	On UL Switching for TEI19
WI:	TEI19
Document for:		Discussion and Decision

TDoc file conclusion not found

3GPP TSG RAN WG1 #121			R1-2503504
St Julian’s, Malta, May 19th – 23th, 2025

Title:	Draft reply on  UL Tx switching for TEI19
Response to:	LS on UL Tx switching for TEI19 (R1-2503217/R4-2505221)
Release:	Rel-19
Work Item:	TEI-19

Source:	Spreadtrum, UNISOC, [RAN1]
To:	RAN4
Cc:	RAN2

Contact person:	
Name:	
E-mail Address:	

Send any reply LS to:	3GPP Liaisons Coordinator, mailto:3GPPLiaison@etsi.org

Attachments: None
Overall discussion
RAN1 thanks RAN4 for the LS on UL Tx switching.
For issue 2, decide at RAN1#121 whether to support scenario 1a and/or scenario 2 in Rel-19 as part of TEI-19, and feedback to RAN4 the decision.
RAN1 consider there is only one meeting left and limited TU for Rel-19 TEI, Scenario 1a and Scenario 2 will not be specified as part of TEI19.
	Actions
To RAN4
ACTION: 	RAN1 respectfully asks RAN4 to take the reply above into account.
Dates of next TSG RAN WG1 meetings
RAN1#122										25th -29th Aug. 2025											Bengaluru	
RAN1#122bis									13th – 17th Oct. 2025											Prague

TDoc file conclusion not found

3GPP TSG RAN WG1 #121			    R1-2503540
St Julian's, Malta, 19th – 23th May, 2025

Title:	Draft reply LS on UL TX switching for TEI19
Response to:	R4-2505221
Release:	Release 19
Work Item:	TEI19

Source:	RAN1
To:	RAN4
Cc:	RAN2

Contact Person:	
Name:	
E-mail Address:	

Send any reply LS to:	3GPP Liaisons Coordinator, mailto:3GPPLiaison@etsi.org

Attachments:	None
1	Overall description
RAN4 would like to inform RAN1 that RAN4 discussed the following scenarios of Tx switching enhancement for 2 configured UL bands in Rel-19 TEI. 
Scenario 1. Switching between the following 2 cases for 3Tx UEs configured with uplinkTxSwitchingOption set to 'dualUL’ 
Case 1-1: Two antenna ports on Band A and one antenna port on Band B 
Case 1-2: One antenna port on Band A and two antenna ports on Band B
Scenario 1a. Switching between the following 2 cases for 3Tx UEs configured with uplinkTxSwitchingOption set to ‘switchedUL’ 
Case 2-1: Three antenna ports on Band A and zero antenna port on Band B 
Case 2-2: Zero antenna port on Band A and three antenna ports on Band B
Scenario 2. Switching between the following 2 cases for 4Tx UEs configured with uplinkTxSwitchingOption set to ‘switchedUL’
Case 3-1: Four antenna ports on Band A and zero antenna port on Band B 
Case 3-2: Zero antenna port on Band A and Four antenna ports on Band B
RAN4 agreed to support at least scenario 1 in Rel-19 TEI. Whether RAN4 will support scenario 1a and scenario 2 in Rel-19 TEI is pending on RAN1 decision in RAN1#121 meeting. 
The related UE capabilities will be addressed later together with Rel-19 feature list.
RAN4 respectfully asks RAN1 to:
Introduce UL Tx switching functionalities for scenarios 1 in Rel-19 RAN1 specifications as part of TEI-19.
Decide at RAN1#121 whether to support scenario 1a and/or scenario 2 in Rel-19 as part of TEI-19, and feedback to RAN4 the decision. 

Answer: According to RP-240858 (including RP-191602), cross-WG TEI CRs are strongly discouraged, and there is no definition on possible RAN1 impact of RAN4-led TEI CRs. Hence, both 1) and 2) from RAN4 should not be accepted from RAN1 perspective.
2	Actions
To RAN4
ACTION:   RAN1 respectfully request RAN4 to take the above answers into account while discussing on TEI-19.
3	Dates of next TSG RAN WG1 meetings
TSG-RAN1 Meeting #122	25 - 29 August 2025	             Bangalore, India
TSG-RAN1 Meeting #122bis	13 - 17 October 2025	             Prague, Czech

TDoc file conclusion not found

3GPP TSG RAN WG1 #121   		                           R1-2503541
St Julian's, Malta, May 19th – 23th, 2025 
Agenda item:		5
Source:			Samsung
Title:			Discussion on RAN4 reply LS for LP-WUS UE RF
Document for:		Discussion and decision

TDoc file conclusion not found

3GPP TSG RAN WG1 #121		R1-2503542
St Julian's, Malta, 19 - 23 May, 2025
Agenda item:	5
Source:	Samsung
Title:	Discussion on the startSFN parameter for positioning SRS with TX frequency hopping
Document for:	Discussion and decision

Conclusion
The contribution discusses the time period determination, and the proposal is summarized below.
Proposal 1: RAN1 adopts following answers to RAN2 LS questions and feedback to RAN2:
Q1: Is the parameter startSFN needed for the UTW?
A: yes.
Q2: If answer to Q1 is ‘yes’, how this parameter should be interpreted?
A: such parameter indicates that starting from which SFN the determination/derivation of the UTW will conducted.

3GPP TSG RAN WG1 #121			R1-2503543
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda Item:	5
Source:	Samsung
Title:	Discussion on RAN4 LS on the transient period for SBFD operation
Document for:	Discussion
1. 

Conclusions
In this contribution, we discussed the impacts of RAN4’s transient period between SBFD symbols and non-SBFD symbols. Our observations and proposal are 

Observation 1. In legacy TDD systems, the TDD BS transmitter transient period is ensured by the explicit guard symbols between DL symbols and UL symbols and the timing advance.
Observation 2. For Case-A, B, and D, the transient period does not overlap with DL symbol and UL symbol.
Observation 3. For Case-C, UE cannot know which symbols are impacted by the transient period.

Proposal 1. RAN1 to consider the following two alternatives to avoid incorrect reception and HARQ combining by the UE or any unnecessary transmission from the UE.
Alt. 1: gNB ensures no overlapping occurs by scheduling
Alt. 2: gNB configures which option is implemented and which symbols are impacted.

3GPP TSG RAN WG1 #121	R1-2503632
St Julian’s, Malta, May 19th – 23th, 2025

Title 	:  Discussion on the LS on CB-Msg-3 EDT
Source 	:  ZTE Corporation, Sanechips
Agenda item	:  5
Document for	:  Discussion

Conclusion
In this contribution, according to the discussion above, the following proposals are made:
Observation 1: The support of power ramping is beneficial for the CB-Msg3 transmission with additional spec impacts in both RAN1 and RAN2.
Proposal 1: From RAN1’s perspective, the following aspects should be confirmed and feedback to RAN2.
Proposal 2: From RAN1’s perspective, the following aspects should be confirmed and feedback to RAN2.
Proposal 3: From RAN1’s perspective, the following aspects should be confirmed and feedback to RAN2.
Proposal 4: From RAN1’s perspective, the following aspects should be confirmed and feedback to RAN2.
Proposal 5: From RAN1’s perspective, the following aspects should be confirmed and feedback to RAN2.
Proposal 6: From RAN1’s perspective, the following aspects should be confirmed and feedback to RAN2.
Proposal 7: From RAN1’s perspective, the following aspects should be confirmed and feedback to RAN2.

3GPP TSG RAN WG1 Meeting #121	R1-2503665
St Julian’s, Malta, May 19th – 23th, 2025

Title:	Draft reply LS on UL Tx switching for TEI19
Response to:	R1-2503217 (R4-2505221)
Release:	Rel-19
Work Item:	TEI-19

Source:	ZTE, [RAN1]
To:	RAN4
Cc:	

Contact person:	
Name:			Xianghui Han
E-mail address:	han.xianghui@zte.com.cn
	
Send any reply LS to:	3GPP Liaisons Coordinator, mailto:3GPPLiaison@etsi.org

Attachments:	None

1	Overall description
RAN1 thanks RAN4 for the LS R1-2503217 (R4-2505221) on UL switching for 2 configured UL bands in Rel-19 TEI with the following requests. 

For 1), RAN1 supports scenario 1 and will specify it as part of Rel-19 TEI. 
For 2), RAN1 has identified more specification impacts if scenario 1a and/or scenario 2 are introduced, and RAN1 decides not to support scenario 1a and scenario 2 in Rel-19.  
2	Actions
To RAN4:
ACTION: 	RAN1 respectfully requests RAN4 to take the above information into account.
3	Dates of next TSG RAN1 meetings
RAN1#122	                               25th - 29th August 2025	                          Bengaluru, IN
RAN1#122bis	                               13th - 17th October 2025	                          Prague, CZ

TDoc file conclusion not found

3GPP TSG RAN WG1 #121                                                                                           R1-2503666
St Julian’s, Malta, May 19th – 23th, 2025
Source:	ZTE Corporation, Sanechips
Title:	Discussion on RAN4 LS on UL Tx switching for TEI19
Agenda item:	5
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our analysis on UL switching with two uplink bands for 3Tx/4Tx UEs with the following proposals and observations.
#Scenario 1
Proposal 1: The following switching cases need to be introduced to support scenario 1 in Rel-19.
-	when the UE is to transmit a 2-port transmission on one uplink carrier on one band and if the preceding uplink transmission was a 1-port transmission on a carrier on the same band and the UE is under the operation state in which 2-port transmission cannot be supported in the same band, then the UE is not expected to transmit for the duration of  on any of the carriers.
-	when the UE is to transmit a 2-port transmission on one uplink carrier on one band and if the preceding uplink transmission is a 2-port transmission on another uplink carrier on another band, then the UE is not expected to transmit for the duration of  on any of the carriers.
-	when the UE is to transmit a 2-port transmission on one uplink carrier on one band and if the preceding uplink transmission was a 1-port transmission on another uplink carrier on another band and the UE is under the operation state in which 2-port transmission can be supported in the same band, then the UE is not expected to transmit for the duration of  on any of the carriers. 
Note: the last switching case is a new case compared to previous release. 
Proposal 2: Adopt the following TP to TS 38.214 for support of scenario 1 for 3Tx UEs. 
Whether to introduce a new RRC parameter for switching period is subject to RAN4 decision. 

#Scenario 1a/2
Observation 1: If scenario 1a is supported, additional five new switching cases need to be introduced.
-	When the UE is to transmit a 3-port transmission on one uplink carrier on one band and if the preceding uplink transmission is a 3-port transmission on another uplink carrier on another band, then the UE is not expected to transmit for the duration of  on any of the carriers.
-	When the UE is to transmit a 3-port transmission on one uplink carrier on one band and if the preceding uplink transmission is a 2-port transmission on another uplink carrier on another band, then the UE is not expected to transmit for the duration of  on any of the carriers.
-	When the UE is to transmit a 3-port transmission on one uplink carrier on one band and if the preceding uplink transmission is a 1-port transmission on another uplink carrier on another band, then the UE is not expected to transmit for the duration of  on any of the carriers.
-	When the UE is to transmit a 1-port transmission on one uplink carrier on one band and if the preceding uplink transmission is a 3-port transmission on another uplink carrier on another band, then the UE is not expected to transmit for the duration of  on any of the carriers.
-	When the UE is to transmit a 2-port transmission on one uplink carrier on one band and if the preceding uplink transmission is a 3-port transmission on another uplink carrier on another band, then the UE is not expected to transmit for the duration of  on any of the carriers.
Proposal 3: Do NOT support Scenario 1a and Scenario 2 in Release 19. If needed, support all 3Tx/4Tx switching cases with both ‘switchedUL’ and ‘dualUL’ in a subsequent release.

3GPP TSG RAN WG1 #121	R1-2503676
St Julian’s, Malta, May 19th – 23rd, 2025

Source:	ZTE Corporation, Sanechips
Title:	Discussion on differentiation of sDCI mTRP, mDCI mTRP and sTRP
Agenda Item:	5
Document for:	Discussion and Decision

Conclusion
In this contribution, we discussed alternatives on differentiation of sDCI mTRP and sTRP. Upon that, we have the following proposal.
Proposal 1: To differentiate the cells operated as sTRP vs sDCI mTRP, Option-1 is supported.
Option-1: For each list, the network ensures that either at least one of the following RRC parameters is configured for all BWPs of all serving cells or none of the following RRC parameters is configured in any BWP of any serving cell.
“applyIndicatedTCI-State-r18” in ConfiguredGrantConfig, ControlResourceSet, PUSCH-Config, SRS-ResourceSet, PDCCH-ConfigCommon, PUCCH-ResourceExt-v1610, or
“applyIndicatedTCI-State-r18” and “applyIndicatedTCI-State2-r18” in CSI-AssociatedReportConfigInfo, or
“applyIndicatedTCI-StateDCI-1-0-r18” in TCI-InDCI-r18.
mappingPattern-r17”, “multipanelSchemeSDM-r18”, “multipanelSchemeSFN-r18” in PUSCH-Config
“repetitionSchemeConfig-r16” in PDSCH-Config
“searchSpaceLinkingId-r17” in searchSpace
“sfnSchemePDCCH-r17” and “sfnSchemePDSCH-r17” in MIMOParam-r17
“cjt-Scheme-PDSCH-r18” in ServingCellConfig
Two SRS resource sets configured in srs-ResourceSetToAddModList or srs-ResourceSetToAddModListDCI-0-2 with higher layer parameter usage in SRS-ResourceSet set to 'codebook' or ‘noncodebook’

3GPP TSG RAN WG1 #121                                        R1-2503700
St Julian’s, Malta, May 19th – 23th, 2025

Source:	ZTE Corporation, Sanechips
Title:	Discussion on RAN2 LS on the startSFN parameter for positioning SRS FH
Agenda item:	5
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on the parameter of startSFN positioning SRS with Tx frequency hopping and we support the following proposals:
Proposal 1: Parameter startSFN is needed for UTW for positioning SRS FH.
Proposal 2: UTW occasions is allocated with regards to SFN#0 slot#0 and UE(s) can start to utilize the UTW from the configured startSFN.

3GPP TSG-RAN WG1 Meeting #121	  R1-2503765
St Julian's, Malta, 19 - 23 May, 2025 

Agenda Item:	5
Source:	CATT 
Title:	         Discussion on LS reply on CB-msg3-EDT 
Document for:	Discussion and Decision

Conclusion
In this contribution, we analyzed relevant procedures and provided the answers to each quesitons regarding CB-msg3-EDT operation. In general, RAN1 can confirm RAN2 understanding for some questions, howerver, still there are some disucsisons needed for detailed parameters configuration. The listed answers can be taken as the baseline for contention bsaed msg3-EDT transmission.

3GPP TSG RAN WG1 #121                                                                                  R1-2503768
St Julian’s, Malta, May 19th – 23rd, 2025

Source:	CATT
Title:	Discussion on LS on differentiation of sDCI based mTRP and sTRP
Agenda Item:	5
Document for:	Discussion and Decision

Conclusion
In this contribution, we have discussed the remaining issue raised by RAN2 regarding the differentiation of sDCI based mTRP and sTRP in the same CC list. Based on the discussion, we have the following proposal and a draft reply LS is provided in [3]:
Proposal 1: To differentiate the cells operated as sTRP vs sDCI based mTRP, support the following option:
RAN1 agrees that whether RRC parameter applyIndicatedTCI-State is configured in ControlResourceSet can be used to indicate whether a serving cell is in sDCI based mTRP operation or sTRP operation. However, for each list, the network ensures that either at least one of the following RRC parameters is configured for all BWPs of all serving cells or none of the following RRC parameters is configured in any BWP of any serving cell.
“applyIndicatedTCI-State-r18” in ControlResourceSet, or
“applyIndicatedTCI-State-r18” in PUCCH-ResourceExt-v1610.

3GPP TSG RAN WG1 #121                                                                          	       R1-2503807
St Julian’s, Malta, May 19th – 23rd, 2025

Source:	CATT
Title:	Discussion on the startSFN parameter for positioning SRS with TX frequency hopping
Agenda Item:	5
Document for:	Discussion and Decision

Conclusions
In this contribution, we have discussed the responses to RAN2’s questions, and present the following observation and proposal.
Observation 1: Including the startSFN parameter in the UL time window for UL SRS positioning with Tx hopping may allow the network to configure the UE to start using Option 1 at a different time than the start of the periodic FH SRS for positioning. However, the benefit of this flexibility is unclear.
Proposal 1: Provide the following response to RAN2’s questions:
Q1: Is the parameter startSFN needed for the UTW?
RAN1’s answer: The original intention of the startSFN parameter was to allow the network to configure the UE to start using UTW for collision handling at a time different from the start of the periodic SRS for positioning with frequency hopping. However, after further discussion at RAN1#121, RAN1 concluded that this functionality is no longer needed, and therefore the startSFN parameter can be removed from the UTW configuration.
Q2: If answer to Q1 is ‘yes’, how this parameter should be interpreted?
RAN1’s answer: See RAN1’s response to Q1.

3GPP TSG RAN WG1 #121			                                                             R1-2503818
St Julian’s, Malta, May 19th – 23th, 2025

Source: 	CMCC
Title:	Discussion on Reply LS on soft satellite switch with re-sync
Agenda item:	5
Document for:	Discussion & Decision

Conclusions
In this contribution, we provide our views on questions of RAN4 for the soft satellite switching. The proposals and the observation are as below. 

Proposal 1
Answer to RAN4 Question 1:
According to the understanding of Option 1, the ssb-TimeOffset can only be configured as multiples of 5ms, which would be aligned with RAN1’s specifications.

Proposal 2:
From RAN1’s perspective, the indication of half-frame and SFN indication can follow the current specification. No additional RAN1 update is needed. 

Proposal 3:
Answer to RAN4 Question 2:
Legacy indication of the half-frame indication and SFN indication can be reused during the [t-ServiceStart, t-Service]. 

Observation 1:
Either replying RAN4’s questions with similar answers or no response to RAN4’s question will not impact the understanding of RAN4. 

3GPP TSG RAN WG1 #121 	                                           R1-2503819 
St Julian’s, Malta, May 19th – 23th, 2025

Source: 	CMCC
Title:	Discussion on LS on UL Tx switching for TEI19
Agenda item:	5
Document for:	Discussion & Decision

Conclusions
In this contribution, we provide our views on UL Tx switching cases for 3Tx UE in scenario 1, scenario 1a and 4Tx UE in scenario 2. The proposals are provided in below.
Proposal 1: The switching cases for 3Tx UEs configured with uplinkTxSwitchingOption set to ‘dualUL’ can be captured in TS38.214 Section 6.1.6.2.0. 
Proposal 2: From RAN1 perspective, it is possible to support scenario 1a and/or scenario 2 in Rel-19 as part of TEI-19.

3GPP TSG RAN WG1 #121			      R1-2503868
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda item:	5
Source:	Xiaomi
Title:	Discussion on simultaneous configuration of SBFD and DC
Document for:	Decision

Conclusions
In this contribution, we discussed potential RAN1 impact to support simultaneous configuration of SBFD and DC with the following observation and proposal.
Observation: If simultaneous configuration of SBFD and DC is supported, UL power control for DC in TS38.213 Clause 7.6 needs to be updated considering potential UL transmission in SBFD symbols configured as DL in tdd-UL-DL-ConfigurationCommon.

Proposal: Discuss and decide whether to support simultaneous configuration of SBFD and DC. If supported, discuss how to update UL power control for DC in TS38.213 Clause 7.6 considering potential UL transmission in SBFD symbols configured as DL in tdd-UL-DL-ConfigurationCommon.

TDoc file reading error

3GPP TSG RAN WG1 #121		R1-2503870
St Julian’s, Malta, May 19th – 23rd, 2025


Source: 	     Xiaomi
Title:	Discussion on RAN2 LS on CB-msg3-EDT 
Agenda item:       5
Document for:    Discussion and Decision

Conclusion  
In this contribution, we discuss several issues in the incoming LS from RAN2 on CB-Msg3-EDT. Based on the discussion, our views are summarized as follows.


Proposal 1: Support power ramping for CB-Msg3-EDT. 
Proposal 2: For CB-Msg3-EDT NPUSCH format 1 power control, reuse the legacy Msg3 EDT power control procedure with some parameters and calculation formula updates.
Proposal 3: For MPDCCH, PDSCH, and PUCCH configurations of eMTC devices, and for NPDCCH configuration of NB-IoT devices, reuse the RRC parameters of Msg4's MPDCCH, PDSCH, PUCCH, and NPDCCH for CB-MSG3-EDT.
Proposal 4: For the (N)PUSCH configuration of eMTC and NB-IoT UEs, configure the L1 parameters signalled by the RAR UL grant via SIB messages.
Proposal 5: For NB-IoT NPUSCH format 1, configure the maximum TBS for each CE level.
Proposal 6: Support the configuration of a set of frequency domain resources for (N)PUSCH transmission.
Proposal 7: Support separate configuration of multi-tone and single-tone resources for a given CE level.
Proposal 8: For the TBS determination of CB-MSG3-EDT NPUSCH format 1, reuse the legacy specification for EDT with RACH procedure.

3GPP TSG RAN WG1 #121	                              	          R1-2503871
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda Item:	5
Source:	Xiaomi
Title:	Discussion on LS on differentiation of sDCI mTRP and sTRP
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on some issues for the DL sTRP/UL mTRP scenario, and the following are our proposals, 
Proposal 1:  Regarding RAN2 LS Question 2a, RAN1 understanding is that the RRC parameter applyIndicatedTCI-State configured in ControlResourceSet can be used to indicate whether a serving cell is in sDCI mTRP operation or sTRP operation. And the answer to Question 2a is No.

3GPP TSG RAN WG1 #121			R1-2504003
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda Item:	5
Source:	Samsung
Title:	Discussion on RAN2 LS on simultaneous configuration of SBFD and DC
Document for:	Discussion
1. 

Conclusions
In this contribution, we discussed SBFD operation with DC. Our observations and proposal are:

Observation 1: Support of Rel-19 with DC would require RAN3 involvement but the current approved WID objectives don’t include RAN3 impacts other than gNB-gNB information exchange. Thus, SBFD with DC is considered as out-of-scope.
Observation 2: SBFD operation with DC does not provide the same UL coverage gains as SBFD single-carrier operation when the UE UL transmission power is semi-statically split for MCG and SCG.
Observation 3: EN-DC is the most typical commercial DC scenario, where EUTRA is usually deployed in the lower FDD band and can provide UL coverage.
Observation 4: SBFD operation with DC does not provide latency gain due to semi-static DC path split and non-ideal backhaul delays.

Proposal 1: No support in Rel-19 Duplex enhancements for simultaneous configuration of SBFD and DC.

3GPP TSG RAN WG1 #121 	R1- 2504036
St Julian’s, Malta, May 19th – 23th, 2025

Agenda item:		5
Source:	Nokia, Nokia Shanghai Bell
Title:	Discussion on LS from RAN2 on CB-Msg3-EDT
Document for:		Discussion and Decision

Conclusion
In this contribution, we discussed our view on CB-Msg3-EDT. Our observations and proposals are as follows:
Observation 1: Legacy specification defines the UE determines the MPDCCH narrowband to monitor based on the Msg1 preamble index, but an alternative is needed for CB-Msg3.
Observation 2: the n1PUCCH-AN cannot be signaled as a UE-specific value in the CB-Msg3 configuration and may therefore result in PUCCH collisions. 
Observation 3: RAN1 specification needs to reflect the CB-RNTI is used for scrambling the CB-Msg3.
Observation 4: During the Ms4 monitoring window a UE which transmitted CB-Msg3-EDT may need to detect PDCCH and decode PDSCH multiple times with the same CB-RNTI and corresponding to the same CB-Msg3 resource window.
Observation 5: There will be much power waste on Msg4 detection as UE may only find its own Msg4 or even not find its own Msg4 after multiple times detection of PDCCH/PDSCH with other UEs’ CR ID.

Proposal 1: The UE shall only apply power ramping between CB-Msg3 windows in case of unsuccessful contention resolution or, that is, CB-Msg3 reattempt.
Proposal 2: For CB-Msg3 power ramping a new counter is needed for the number of CB-Msg3 attempts per CE level, while the powerRampingStep can be reused. RAN1 may discuss whether a new Initial Received Target Power parameter is needed.
Proposal 3: The PUR MPDCCH configuration can be used as a baseline for Msg4 monitoring, but it shall be defined for the common search space type 2, be per CE level, and provide narrowband as a set.
Proposal 4: RAN1 to discuss how the UE determines which MPDCCH narrowband to monitor.  
Proposal 5: pusch-CyclicShift-r16 and pusch-NB-MaxTBS-r16 are supported for CB-Msg3. 
Proposal 6: prb-AllocationInfo can be configured as a set for CB-Msg3. 
Proposal 7: the pur-PDSCH-maxTBS and pur-PDSCH-FreqHopping are adopted to be supported for CB-Msg3/4.
Proposal 8: if the UE supports the CB-Msg3 procedure the UE shall also support the CB-Msg3/4 counterpart of pur-PDSCH-maxTBS and pur-PDSCH-FreqHopping features.
Proposal 9: RAN1 to discuss how to ensure there are no PUCCH transmission collisions when UEs respond to CB-Msg4, e.g. by successRAR containing a “HARQ Feedback Timing Indicator to allocate the UEs to different PUCCH time domain resource. 
Proposal 10: The parameters related to the number of resource units, number of repetitions, and MCS configuration can be adopted from the pur-PhysicalConfig to a corresponding CB-Msg3 configuration for NB-IoT.
Proposal 11: The NPUSCH subcarriers for CB-Msg3 can be provided as a non-contiguous set.
Proposal 12: The PUR NPDCCH configuration can be used as a baseline for Msg4 monitoring, but it shall be defined for the common search space type 2 and be per CE level.
Proposal 13: The CB-Msg3 configuration shall support a TBS per CE level. 
Proposal 14: The network may provide assistance information to help the UE determine whether/how to monitor for CB-Msg4 during the Msg4 monitoring window. 

3GPP TSG RAN WG1 #121	R1-2504124  
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda item:		5
Source:				Nokia, Nokia Shanghai Bell
Title:					Discussion on RAN4 LS on transient period for SBFD operation
Document for:		Discussion and Decision

Conclusion
In this document we have discussed the LS R4-2504767 from RAN4 regarding transient period for SBFD operation. The following observations and proposals were made:
Observation 1:	On the location of the UE transient period, RAN1 TS 38.211 specifies a maximum requirement for UE Tx-Rx and Rx-Tx transition time. It is the responsibility of the gNB scheduler and configuration to ensure that the specified requirement is respected for each UE Tx-Rx and Rx-Tx transition.
Observation 2:	It is not properly justified to introduce explicit indication of transient period for the transition between DL to SBFD symbols considering that, within the SBFD symbols, the UE may also switch between UL and DL at any SBFD symbol based on gNB configured/scheduled transmissions/receptions.
Proposal 1:	 RAN1 does not specify explicit indication of transient period for the transition between DL to SBFD symbols. Agreements on this issue can be communicated in a LS reply to RAN4.

3GPP TSG RAN WG1 #121	R1-2504125  
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda item:		5
Source:				Nokia, Nokia Shanghai Bell
Title:					Discussion on RAN2 LS on simultaneous configuration of SBFD and DC
Document for:		Discussion and Decision

Conclusion
In this document we have discussed the R2-2503191 from RAN2 regarding simultaneous configuration of SBFD and DC. The following proposal was made:
Proposal 1. RAN1 would like to answer RAN2 as follows.

3GPP TSG RAN WG1 #121	R1-2504127
St Julian’s, Malta, May 19th – 23th, 2025
Agenda item:	5
Source: 	ETRI
Title:	Discussion on the transient period for SBFD operation
Document for:	Discussion/Decision

Conclusion
In this contribution, ETRI’s views on the transient period for SBFD operation were shown and the following proposals were made:
Proposal 1. RAN1 to down-select one of the following options:
Option 1: For collision Case 6 (Dynamic or semi-static DL vs. valid RO), transient period (i.e.,  or ) is considered as in legacy specification
Option 2: For collision Case 6 (Dynamic or semi-static DL vs. valid RO), transient period (i.e.,  or ) is NOT considered
Proposal 2. Send an LS to RAN4, if the following is agreed in RAN1:
Option 1: For collision Case 6 (Dynamic or semi-static DL vs. valid RO), transient period (i.e.,  or ) is considered as in legacy specification

3GPP TSG RAN WG1 #121	R1-2504128
St Julian’s, Malta, May 19th – 23th, 2025
Agenda item:	5
Source: 	ETRI
Title:	Discussion on simultaneous configuration of SBFD and DC
Document for:	Discussion/Decision

Conclusion
In this contribution, ETRI’s views on simultaneous configuration of SBFD and DC were shown and the following proposals were made:
Proposal 1. RAN1 to agree on the following response to RAN2:
SBFD and DC can be configured simultaneously
From RAN1 perspective, no issues have been identified to configure SBFD and DC simultaneously

3GPP TSG RAN WG1 #121		                                      R1-2504186
St Julian’s, Malta, May 19th–23rd, 2025

Source:	OPPO
Title:	Discussion on LS on differentiation of sDCI mTRP, mDCI mTRP and sTRP
Agenda Item:	5
Document for:	Discussion and Decision

Conclusion
With above being said, we suggest the following response to RAN2. 
Proposal 1: Please kindly consider our answers into the response LS to RAN2. 
Answer 1b: Not Applicable.
Answer 2a: Yes, there is. The parameter, i.e. applyIndicatedTCI-State for ControlResourcesSet seems not sufficient to separate sTRP and sDCI mTRP. 
Answer 2b: Network ensures that either all applyIndicatedTCI-State are configured for all PDCCH/PDSCH/PUCCH/PUSCH in all BWPs of all serving cells or there is not any applyIndicatedTCI-State configured for any PDCCH/PDSCH/PUCCH/PUSCH of any BWP of any serving cell.

3GPP TSG RAN WG1 #121		                                           R1-2504191
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	5
Source: 	OPPO
Title:	Draft reply LS on LP-WUS in RRC_CONNECTED
Document for:	Discussion & Decision

Conclusion
We have following proposals regarding the questions in the LS:
Proposal1: RAN1 can reply the Working Assumption for Option 1-2 is feasible in RAN1 perspective.
Proposal 2: For the LP-WUS, the LR can be able to monitor in any time without restriction. It is up to RAN2 to allow UE to monitor LR and MR simultaneously.
Proposal 3: In RRC CONNECTED mode, support UE capability report one value among 3 candidate values for minimum time gap between LP-WUS reception and MR to start PDCCH monitoring.
3 ms, 13ms and 33 ms are the candidature values.
UE could additionally report as UAI with another smaller gap than its capability report and among the candidature values.

3GPP TSG RAN WG1 #121		R1-2504204
St Julian’s, Malta, May 19th – 23th, 2025

Source:	OPPO
Title:	Discussion on LS on CB-msg3-EDT
Agenda Item:	5
Document for:	Discussion and Decision

Conclusion
In this contribution, we discussed the RAN2 LS on the signaling design for CB-Msg3-EDT procedure. The following proposals are made:
Proposal 1: Power ramping can be supported for eMTC for CB-Msg3-EDT, and the MSG3_RECEIVED_TARGET_POWER and powerRampingStep should be signaled from higher parameters.
Proposal 2: If enhanced random access power control is not applied, for a repetition level other than the lowest configured repetition level, PNPUSCH is set to  and power ramping is not needed. Otherwise, power ramping can be supported for NB-IoT for CB-Msg3-EDT, and the MSG3_RECEIVED_TARGET_POWER and powerRampingStep should be signaled from higher parameters.
Proposal 3: For MPDCCH configuration for CB-Msg3-EDT procedure, a new common search space (e.g., Type3-MPDCCH common search space) may need to be defined, and the MPDCCH configuration for Type2-MPDCCH common search space should be taken as baseline.
Proposal 4: The pusch-CyclicShift-r16, pusch-NB-MaxTBS-r16 and pur-PUSCH-FreqHopping-r16 are not needed for CB-Msg3-EDT PUSCH configuration.
Proposal 5: The prb-AllocationInfo can be defined as a “set” format to provide a set of shared frequency-domain resources to alleviate the collision issue.
Proposal 6: The pur-PDSCH-FreqHopping and pur-PDSCH-maxTBS are not needed for CB-Msg3-EDT PDSCH configuration.
Proposal 7: For CB-Msg3-EDT PUCCH configuration, the n1PUCCH-AN-r16 and pucch-NumRepetitionCE-Format1-r16 in PUR PUCCH configuration can be reused.
Proposal 8: The npusch-SubCarrierSetIndex can be defined as a “set” format to provide a set of shared subcarriers to alleviate the collision issue.
Proposal 9: For NPDCCH configuration for CB-Msg3-EDT procedure, a new common search space (e.g., Type3-NPDCCH common search space) may need to be defined.

3GPP TSG RAN WG1 #121		R1-2504213
St Julian’s, Malta, May 19th – 23rd, 2025

Source:	OPPO
Title:	Discussion on RAN2 LS for simultaneous configuration of SBFD and DC
Agenda Item:	5
Document for:	Discussion and Decision

Conclusion
This contribution concludes with following proposals:
Proposal 1: If RAN1 assesses that SBFD and DC can be configured to a UE simultaneously in Rel-19, the following should be included in the response to RAN2.
Such simultaneous configuration should exclude the case where SBFD is individually configured on both MCG carrier and SCG carrier.
Such simultaneous configuration should exclude at least EN-DC. 
RAN1 assumes that RAN4 would evaluate whether the legacy UE capability FG2-5 and capability signaling “simultaneousRxTxInterBandCA” apply to SBFD+DC.      

3GPP TSG RAN WG1 #121			                  R1-2504242
St Julian, Malta, May 19th – 23rd, 2025

Agenda Item:	5
Source: 	LG Electronics
Title: 	Discussion on RAN2 LS on LP-WUS in RRC_CONNECTED
Document for:	Discussion and decision
Discussion
In [1], RAN2 asked RAN1 to take the following agreements and working assumptions into account and provide feedback on the following questions for LP-WUS in RRC_CONNECTED modes.

Cases/scenarios on when the UE is not able to monitor LP-WUS
From the above RAN1 agreement, it is observed that the UE is not able to monitor LP-WUS during C-DRX active time. For RRC_CONNECTED modes, the UE monitors only LP-WUS not LP-SS. Thus, when the UE is in C-DRX active time is the only case where the UE is not able to monitor LP-WUS.

Case when the UE is not able to monitor LR and MR simultaneously
This question is whether MR and LP-WUR can operate simultaneously. It is an issue of whether the UE can monitor LP-WUS during the time where MR transmits and receives signals/channels. RAN1 already discussed this scenario. A number of companies provided their views on this issue. The main argument that MR and LP-WUR cannot operate at the same time is hardware implementation of sharing Rx branches between MR and LP-WUR. Following this approach, decoupling of Rx branches for simultaneous operation may lead to performance degradation. On the other hand, LP-WUR can have separate Rx branch following the legacy CA that multiple CCs transmit signals and different CCs share some component. In this framework, UE can monitor LP-WUS during the time MR transmits and receives signals without performance degradation. 
There are cases other than the UE in C-DRX active time where the UE monitors LP-WUS while transmitting or receiving signals/channels by MR. For example, the UE monitors LP-WUS while reporting periodic CSI/L1-RSRP, performing RRM measurement, and transmitting CG-PUSCH.
However, RAN1 concluded that C-DRX active time is only considered due to time limit. If time permits, we suggest that other cases of CSI/L1-RSRP, RRM measurement and CG-PSUCH should be discussed as well and reply LS should reflect the discussion on this meeting. If the other cases cannot be discussed in this meeting due to the lack of time, reply LS should be made that all the cases have been considered in RAN1 perspective. 

Further conclusions on what information the preferred time offset via UAI should provide
In this meeting, RAN1 will discuss and conclude the values of capability report of the minimum time gap. Based on these values, UAI signaling can be determined. For example, the UE signals the one of three values (the largest or smallest value) of capability reporting as the preferred value. In our view, the one of the three values of capability reporting is the most appropriate. The UE reports three values that the UE can support, and the UE can select the preferred value for power saving or latency reduction purposes and signal it via UAI.
This issue is not addressed yet, so RAN1 need to discuss in this meeting. Thus, RAN1can discuss what information is sent by UAI and RAN1 responds to RAN2 based on the agreements made in this meeting.

Proposal #1: Regarding questions on the cases/scenarios on when the UE is not able to monitor LP-WUS, send a reply LS to RAN2 including the following responses.
There is no other case than the UE in C-DRX active time from RAN1 perspective.

Proposal #2: Regarding questions on the case when the UE is not able to monitor LR and MR simultaneously send a reply LS to RAN2 including the following responses.
RAN1 considers only C-DRX active time.
The other cases such as reporting periodic CSI/L1-RSRP, performing RRM measurement, and transmitting CG-PUSCH are not fully discussed.

Proposal #3: Regarding questions on what information the preferred time offset via UAI should provide, send a reply LS to RAN2 including the following responses after RAN1 discuss and make an agreement.
As a preferred value via UAI, the UE can provide one of the three time offset values reported by the UE.

Conclusion
Therefore, as the response to RAN2 LS, the following proposals can be made.
Proposal #1: Regarding questions on the cases/scenarios on when the UE is not able to monitor LP-WUS, send a reply LS to RAN2 including the following responses.
There is no other case than the UE in C-DRX active time from RAN1 perspective.

Proposal #2: Regarding questions on the case when the UE is not able to monitor LR and MR simultaneously send a reply LS to RAN2 including the following responses.
RAN1 considers only C-DRX active time.
The other cases such as reporting periodic CSI/L1-RSRP, performing RRM measurement, and transmitting CG-PUSCH are not fully discussed.

Proposal #3: Regarding questions on what information the preferred time offset via UAI should provide, send a reply LS to RAN2 including the following responses after RAN1 discuss and make an agreement.
As a preferred value via UAI, the UE can provide one of the three time offset values reported by the UE.

References
 R1-2503616, “LS on LP-WUS in RRC_CONNECTED,” RAN2, InterDigital, RAN1#121

TDoc file conclusion not found

3GPP TSG-RAN WG1 #121	R1-2504284
St Julian's, Malta, 19th -23rd May, 2025               



Agenda Item:	5
Source:	MediaTek Inc.
Title:	Discussion on reply LS on CB-msg3-EDT
Document for:	Discussion & Decision 


1. 

Conclusions:
Question Q1:

Proposal 1: RAN1 can discuss support of power ramping for CB-msg3-EDT.

Question Q6:

Proposal 2: RAN1 can re-use pur-PhysicalConfig-r16 configuration for CB-msg3-EDT as baseline.

Proposal 3: The following fields in CB-msg3-EDT configuration are supported: 
npusch-SubCarrierSetIndex-r16 with khz15 and khz3dot75 
npusch-NumRUsIndex-r16
npusch-NumRepetitionsIndex-r16
npusch-SubCarrierSetIndex-r16
npusch-MCS-r16	with singleTone and multitone
npdcch-Config-r16

Proposal 4: RAN1 can discuss whether to re-use the following fields for CB-msg3-EDT configuration:
npusch-CyclicShift-r16
carrierConfig-r16

Question Q7:

Proposal 5: NPDCCH-ConfigDedicated-NB-r13 IE can be used as baseline for NPDCCH configuration for indication of msg4 on NPDSCH for CB-msg3-EDT.

Proposal 6: npdcch-NumRepetitions-r13 field in CB-msg3-EDT for NPDCCH configuration is supported.

Proposal 7: RAN1 can discuss whether to re-use the following fields in CB-msg3-EDT for NPDCCH configuration with CSS:
npdcch-StartSF-USS-r13
npdcch-Offset-USS-r13

Question Q8:
Proposal 8: RAN1 can discuss specification impact for CB-Msg4 monitoring and CB-Msg3 scrambling with a new CB-RNTI.

7. Appendix A
In RAN2#129
RAN2 #129 Agreements:
1.	RAN2 assumes that at least the following will be part of the shared resources configuration for CB-msg3 (FFS on other aspects)
	-	Time domain resources for (N)PUSCH occasions: periodicity and start time (e.g., start subframe, start SFN)
	-	Frequency domain resources for (N)PUSCH occasions 
	-	repetition number
	-	(N)PDCCH resource
	-	MCS
6.	As Signalling design Baseline RAN2 assumes the PUR config and the NPRACH config for shared (N)PUSCH config can be used and some of the parameters can be included in a new CB EDT config.

In RAN2#129bis

Agreements;
4.	We don’t introduce support for eMTC CE mode B case (it will not be possible to signal resources to be used for this case)
5.	We specify support for NB-IoT with 15kHz with no specific enhancements, leaving to NW implementation whether to implement this or not, accepting potential performance degradation.
7.	The start of CB-msg3 EDT transmission window is aligned with the start of time domain (N)PUSCH resource.
8.	The CB-msg3 EDT transmission window length and periodicity may be different. FFS on possible signalling optimization in case the length and periodicity are the same.
9.	RAN2 assumes power ramping should be supported for CB-msg3-EDT (for both eMTC and NB-IoT) should be supported and will ask RAN1 for confirmation and in case which parameters should apply

(CB-Msg3-EDT configuration for eMTC)
10.	For eMTC, introduce a new IE (e.g. CB-Msg3-ConfigSIB-r19) for shared resources configuration of CB-Msg3 in SIB2.
11.	For eMTC, introduce MPDCCH configuration in shared resources configuration. The fields in IE PUR-MPDCCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters (e.g. whether additional narrow band is needed).
12.	We will not support TDD related parameters.
13.	For eMTC, introduce PUSCH configuration in shared resources configuration. The fields in IE PUR-PUSCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters. (e.g. whether pusch-CyclicShift-r16, pusch-NB-MaxTBS-r16 are needed, whether prb-AllocationInfo should be defined as a “set” format with intention to provide a set of shared frequency-domain resources).
14.	For eMTC, check with RAN1 if anything is needed for PDSCH configuration in shared resources configuration
15.	For eMTC, introduce PUCCH configuration in shared resources configuration. The fields in IE PUR-PUCCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters.

(CB-Msg3 configuration for NB-IoT)
16.	For NB-IoT, introduce a new IE (e.g. CB-Msg3-ConfigSIB-NB-r19) for shared resources configuration of CB-Msg3 in SIB2-NB and SIB22-NB for non-anchor carrier.
17.	For NB-IoT, introduce below physical layer parameters in shared resources configuration as below: 
	-	Number of resource units for NPUSCH (as in npusch-NumRUsIndex-r16)
	-	Number of repetitions for NPUSCH (as in npusch-NumRepetitionsIndex-r16)
	-	Set of subcarriers (similar to npusch-SubCarrierSetIndex but change it to a “set”), FFS whether subcarriers are provided as a contiguous set.
	-	MCS configuration for NPUSCH (as in npusch-MCS-r16).  
	-	PDCCH parameters (as in NPDCCH-ConfigDedicated-NB-r13)
	-	The non-anchor carrier index for monitoring Msg4. If this field is absent, anchor carrier is assumed to be used.
	NOTE: confirm with RAN1 is needed

Agreements (part3):
1.	The CB-msg3-EDT configuration (e.g., number of replicas, number of time resources and number of frequency resources) is CE level specific.



8. Appendix B
According to the specifications in TS 36.213 Clause 16.5.1.1 Resource allocation
The resource allocation information in uplink DCI format N0 for NPUSCH transmission or configured by higher layers for NPUSCH transmission using preconfigured uplink resource indicates to a scheduled UE
a set of contiguously allocated subcarriers () of a resource unit determined by the Subcarrier indication field, or by the higher layer parameter npusch-SubCarrierSetIndex in PUR-Config-NB
a number of resource units () determined by the resource assignment field according to Table 16.5.1.1-2, or by the higher layer parameter npusch-NumRUsIndex in PUR-Config-NB
a repetition number () determined by the repetition number field according to Table 16.5.1.1-3, and for a NPUSCH transmission using preconfigured uplink resource, the UE shall use the repetition number configured by higher layers; except for NPUSCH with 16QAM where .
For NPUSCH transmission with subcarrier spacing, where  is the subcarrier indication field and is reserved, or nsc is configured by higher layers parameter npusch-SubCarrierSetIndex in PUR-Config-NB for NPUSCH transmissions using preconfigured uplink resources.
For NPUSCH transmission with subcarrier spacing, the subcarrier indication field () in the DCI or npusch-SubCarrierSetIndex in PUR-Config-NB for NPUSCH transmissions using preconfigured uplink resources determines the set of contiguously allocated subcarriers () according to Table 16.5.1.1-1.

Table 16.5.1.1-1: Allocated subcarriers for NPUSCH with .


Table 16.5.1.1-2: Number of resource units () for NPUSCH.

Table 16.5.1.1-3: Number of repetitions () for NPUSCH.


9. 

3GPP TSG-RAN WG1 Meeting #121	R1-2504291
St Julian’s, Malta, May 19th-23th, 2025

Agenda Item:	5
Source:	Huawei, HiSilicon
Title:	Discussion on LP-WUS in CONNECTED mode
Document for:	Discussion and Decision

Conclusions
In this contribution, the procedures and functionalities of LP-WUS in CONNECTED mode are discussed. Based on the analysis, the following observations and proposals are provided:
Proposal 1:	For connected mode, it is subject to UE capability whether a UE is capable of simultaneously monitoring LP-WUS in parallel with reception or transmission of legacy NR downlink signals/channels. For the case when LR and MR cannot able to receive/transmit simultaneously, LP-WUR is NOT able to receive signal(s) during the time where MR transmits/receives signals/channels, including when
LP-WUS monitoring collides with measurements and/or periodic CSI/L1-RSRP transmission.
LP-WUS monitoring collides with SPS/CG resources.
LP-WUS monitoring collides with interruption caused by RAR window monitoring for BFR.
Proposal 2:	The value indicated by UAI is not smaller than the duration reported in the UE capability reporting and the candidate values of UAI are the same as those of UE capability.

3GPP TSG-RAN WG1 Meeting #121	R1-2504292
St Julian's, Malta, 19 - 23 May, 2025

Agenda Item:	5
Source:	Huawei, HiSilicon
Title:	Discussion on LS rely on CB-msg3-EDT
Document for:	Discussion and Decision

Conclusion
Based on the discussion above, we had following proposals:
Proposed response to Q1: Power ramping for CB-msg3-EDT is not necessary.
Proposed response to Q2: One single narrow band is enough for MPDCCH configuration, no need to define the narrowband configuration as a set.
Proposed response to Q3: For eMTC, no need to keep pusch-CyclicShift-r16 and pusch-NB-MaxTBS-r16 for PUSCH configuration. prb-AllocationInfo can be defined as a “set”.
Proposed response to Q4: For eMTC, no need to keep pur-PDSCH-FreqHopping and pur-PDSCH-maxTBS within IE PUR-Config-r16 for PDSCH configuration for shared resource configuration.
Proposed response to Q5: More detail is required from RAN2 on how the HARQ feedback is used for each response in Msg4. 
Proposed response to Q6: For NB-IoT, set of subcarriers should be contained in physical layer parameters and the value can be changed to a “set”. p0-UE-NPUSCH-r16 and alpha-r16 are no need to be updated, npusch-CyclicShift-r16 can be removed.
Proposed response to Q7: For NB-IoT, RAN1 agree with RAN2 to reuse the parameters from PUR PDCCH configuration as baseline to have NPDCCH configuration.
Proposed response to Q8: From RAN1 perspective, no other L1 parameter is needed for CB-Msg3-EDT procedure for eMTC and NB-IoT based on the current RAN2 agreements. 

3GPP TSG-RAN WG1 Meeting #121	R1-2504293
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda Item:	5
Source:	Huawei, HiSilicon
Title:	Discussion on LS on UL Tx Switching for TEI19
Document for:	Discussion and Decision

Conclusions
In this contribution, the following observations and proposals are made:
Observation 1: UL Tx switching of scenario 2 could bring 31.7%-77.7% gain of UL peak throughput [2].
Observation 2: No spec change is needed to support scenario 1a and scenario 2 when one of the bands is SUL band.
Observation 3: RAN1 spec changes are needed to support scenario 1a and scenario 2 when switching band combination configured with uplink carrier aggregation.
Observation 4: In addition to specification changes required by scenario 1a/2, more RAN1 spec changes are needed to support scenario 1.
Proposal: Reply the questions of RAN4 LS as following
For scenario 1a and 2 with UL Tx switching between SUL and NUL, no RAN1 specification change is needed according to subclause 6.1.6.3 of TS 38.214.
For scenario 1a and 2 with UL Tx switching between NUL and NUL, RAN1 specification changes are needed according to subclause 6.1.6.2 of TS 38.214
For scenario 1, in addition to specification changes required by scenario 1a/2, more RAN1 specification changes are needed according to subclause 6.1.6 of TS 38.214.

3GPP TSG-RAN WG1 Meeting #121	R1-2504294
St Julian’s, Malta, May 19 – 23, 2025

Agenda Item:	5
Source:	Huawei, HiSilicon
Title:	Discussion on LS on simultaneous configuration of SBFD and DC
Document for:	Discussion and Decision

Conclusions
In this contribution, the following are proposed:
Proposal: From RAN1 perspective, SBFD and DC can be configured simultaneously but an SBFD-aware UE can only be configured with SBFD operation on one TDD cell from either PCG or SCG in Rel-19.

3GPP TSG RAN WG1 #121		             R1-2504303
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda Item:	5
Source:	Apple
Title:	Discussion on the LS on UL Tx switching for TEI19
Document for:	Discussion/Decision

Conclusion
In this contribution, we made the following observations/proposals related to the RAN4 LS on the TEI for enhancements to UL Tx switching:
Observation 1: Currently, we don’t identify deployments with UL Tx switching for band combinations of TDD+TDD and TDD+FDD bands, where 3 or 4 Tx are associated with one band, particularly not with FDD
Therefore, we don’t see the benefit to support scenario 1a and scenario 2

Proposal 1: For scenario 1, avoid supporting same port combinations for both case 1-1 and case 1-2.


Proposal 2: Switching is needed for the following scenarios in which UE is not expected to transmit on any of the bands during the switching gap:
When the UE is to transmit a 2-port transmission on one uplink carrier and if the preceding uplink transmission was a 2-port transmission on another uplink carrier
When the UE is to transmit a 2-port transmission on one uplink carrier and if the preceding uplink transmission was a 1-port transmission on another uplink carrier and the UE is under the operation state in which 2-port transmission can be supported on the same uplink carrier
When the UE is to transmit a 2-port transmission on one uplink carrier and if the preceding uplink transmission was a 1-port transmission on the same uplink carrier and the UE is under the operation state in which 2-port transmission cannot be supported in the same uplink carrier

Proposal 3: Scenario 1a and scenario 2 are not supported for TEI19 on enhancements to UL Tx switching

3GPP TSG RAN WG1 #121		             R1-2504304
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda Item:	5
Source:	Apple
Title:	Discussion on RAN4 LS on RRM agreements on LB CA via switching
Document for:	Discussion/Decision

Conclusion
In this contribution, we made the following proposal on low-band carrier aggregation via switching:
Proposal 1: Only a single switching pattern is configured to UE via UE specific RRC configuration
No further discussion/consideration on additional patterns, as the configuration is only applicable when SCell is activated, as per RAN4 agreement

3GPP TSG RAN WG1 #121							   R1-2504305
St Julian’s, Malta, May 19th – 23th, 2025

Agenda item: 	5
Source: 	Apple
Title:	Discussion on LS on LP-WUS in RRC CONNECTED
Document for:	Discussion/Decision
 

Conclusion
In this contribution, the following proposals are made based on RAN2’s questions in the LS: 
Proposal 1: Considering UE implementation on the LR and MR, basic assumption is that UE cannot monitor LR and MR simultaneously.
Proposal 2: Confirm that UE is also not able to monitor LP-WUS in the cases/scenarios where UE is not able to monitor DCP.
Proposal 3: The cases/scenarios where UE is not able to monitor LP-WUS for both Option 1-1 and Option 1-2 also include the following:
When MR is ON, e.g. 
When drx-HARQ-RTT-TimerDL, drx-HARQ-RTT-TimerUL is running
When UE is monitoring Paging or SIB1
When UE is performing synchronization before C-DRX ON 
When UE is performing CSI measurement during time defined by drx-OnDurationTimer but outside DRX active time when parameter ‘lpwus-TransmitPeriodicL1-RSRP’ or ‘lpwus-TransmitOtherPeriodicCSI’ is configured
During LR and MR switching time
Proposal 4: RAN1 considers that for Option 1-2, when the UE is not able to monitor the LP-WUS occasion(s) the UE should start the WUS-PDCCHMonitoringTimer (as if LP-WUS was detected).

Observations 1: UE would report a larger value in the UE capability report for a better power saving gain, assuming UE is in a deeper sleep state, while indicating to the network a smaller value in UAI, assuming that if there are time-sensitive traffic needs, UE could sacrifice the power saving for a shorter latency.
Proposal 5: No restriction on the the UAI values and values reported in UE capability is needed. 
 

3GPP TSG RAN WG1 #121			R1-2504376
St Julian’s, Malta, May 19th – 23th, 2025
	
Agenda item:	5
Source: 	Qualcomm Incorporated
Title: 	UL Tx switching for TEI19
Document for:	Discussion and Decision

Summary of proposals
In this contribution we presented our views on the LS R4-2505221. We made the following observations and proposals:
Observation 1: The decision of introducing scenarios 1a/2 is split between RAN1 and RAN4. According to guiding principles in RP-191602, in this case “cross WG interaction is too much for a TEI”.
Proposal 1: Do not specify scenarios 1a/2 under TEI19 in RAN1.

Observation 2: The impact in RAN1 specifications of introducing scenario 1 is substantial.
Proposal 2: Do not specify scenario 1 under TEI19 in RAN1.

3GPP TSG RAN WG1 #121			R1-2504377
St Julian’s, Malta, May 19th – 23th, 2025
	
Agenda item:	5
Source: 	Qualcomm Incorporated
Title: 	CB-msg3-EDT for IOT NTN
Document for:	Discussion and Decision

Summary of proposals
In this contribution we provided our proposed replies to the questions in RAN2 LS R2-2503175. We propose to reply to the RAN2 LS as in Section 2.
Proposal: RAN1 endorses the replies in Section 2 for the reply LS to R2-2503175.


Appendix: RAN2 agreements
In RAN2#129
RAN2 #129 Agreements:
1.	RAN2 assumes that at least the following will be part of the shared resources configuration for CB-msg3 (FFS on other aspects)
	-	Time domain resources for (N)PUSCH occasions: periodicity and start time (e.g., start subframe, start SFN)
	-	Frequency domain resources for (N)PUSCH occasions 
	-	repetition number
	-	(N)PDCCH resource
	-	MCS
6.	As Signalling design Baseline RAN2 assumes the PUR config and the NPRACH config for shared (N)PUSCH config can be used and some of the parameters can be included in a new CB EDT config.

In RAN2#129bis

Agreements;
4.	We don’t introduce support for eMTC CE mode B case (it will not be possible to signal resources to be used for this case)
5.	We specify support for NB-IoT with 15kHz with no specific enhancements, leaving to NW implementation whether to implement this or not, accepting potential performance degradation.
7.	The start of CB-msg3 EDT transmission window is aligned with the start of time domain (N)PUSCH resource.
8.	The CB-msg3 EDT transmission window length and periodicity may be different. FFS on possible signalling optimization in case the length and periodicity are the same.
9.	RAN2 assumes power ramping should be supported for CB-msg3-EDT (for both eMTC and NB-IoT) should be supported and will ask RAN1 for confirmation and in case which parameters should apply

(CB-Msg3-EDT configuration for eMTC)
10.	For eMTC, introduce a new IE (e.g. CB-Msg3-ConfigSIB-r19) for shared resources configuration of CB-Msg3 in SIB2.
11.	For eMTC, introduce MPDCCH configuration in shared resources configuration. The fields in IE PUR-MPDCCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters (e.g. whether additional narrow band is needed).
12.	We will not support TDD related parameters.
13.	For eMTC, introduce PUSCH configuration in shared resources configuration. The fields in IE PUR-PUSCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters. (e.g. whether pusch-CyclicShift-r16, pusch-NB-MaxTBS-r16 are needed, whether prb-AllocationInfo should be defined as a “set” format with intention to provide a set of shared frequency-domain resources).
14.	For eMTC, check with RAN1 if anything is needed for PDSCH configuration in shared resources configuration
15.	For eMTC, introduce PUCCH configuration in shared resources configuration. The fields in IE PUR-PUCCH-Config-r16 could be reused as baseline. Confirm with RAN1 on the detail parameters.

(CB-Msg3 configuration for NB-IoT)
16.	For NB-IoT, introduce a new IE (e.g. CB-Msg3-ConfigSIB-NB-r19) for shared resources configuration of CB-Msg3 in SIB2-NB and SIB22-NB for non-anchor carrier.
17.	For NB-IoT, introduce below physical layer parameters in shared resources configuration as below: 
	-	Number of resource units for NPUSCH (as in npusch-NumRUsIndex-r16)
	-	Number of repetitions for NPUSCH (as in npusch-NumRepetitionsIndex-r16)
	-	Set of subcarriers (similar to npusch-SubCarrierSetIndex but change it to a “set”), FFS whether subcarriers are provided as a contiguous set.
	-	MCS configuration for NPUSCH (as in npusch-MCS-r16).  
	-	PDCCH parameters (as in NPDCCH-ConfigDedicated-NB-r13)
	-	The non-anchor carrier index for monitoring Msg4. If this field is absent, anchor carrier is assumed to be used.
	NOTE: confirm with RAN1 is needed

Agreements (part3):
1.	The CB-msg3-EDT configuration (e.g., number of replicas, number of time resources and number of frequency resources) is CE level specific.

​3GPP TSG RAN WG1 #121			R1-2504378
St Julian’s, Malta, May 19th – 23th, 2025
	
Agenda item:	5
Source: 	Qualcomm Incorporated
Title: 	Discussion on response to RAN4 LS on LP-WUS UE RF
Document for:	Discussion and Decision

Conclusions
In this contribution, we have provided the following observations and proposals:
Observation 1: Entry/exit condition for LP-WUS monitoring in idle/inactive mode and UE specific signal allow network to control the actual coverage of LP-WUS irrespective of the targeted coverage.
Proposal 1: RAN1 does not need to consider new target SNR for LP-WUS and LP-SS design.
Proposal 2: RAN1 responds to RAN4 questions based on the following assumptions
Set 1 value for OOK based LP-WUR
Set 2 value for OFDM based LP-WUR
Proposal 3: Answers to RAN4 questions:
Chip rate for OOK modulation
For SCS 30kHz, the OOK chip rate is 28k, 56k and 112k OOK chips/sec for M=1, 2, and 4 respectively. For the other SCS values, the OOK chip rate can be scaled accordingly.
Length of LP-WUS
For the OOK LP-WUS design based on Set 1 assumption, to achieve 1% FAR and 1% MDR at SNR = -3dB in TDL-C channels
For SCS 30kHz, 16 OFDM symbols are needed for M=4, 2 and 1 with power pooling, and 64 OFDM symbols are needed for M= 1 without power pooling.
For the overlaid OFDM sequence LP-WUS design based on Set 2 assumption, to achieve 1% FAR and 1% MDR at SNR = 0dB in TDL-C channels
For SCS 30kHz, 2 repetitions are needed for M=4, and 1 repetition is needed for M = 2 and 1, which corresponds to 1 OFDM symbol.
Coding
For OOK LP-WUS, the raw information (codepoint value) is encoded by
For more than 2 information bits: RM coding as in section 5.3.3.3 of 38.212
For 2 information bits: coding as in section 5.3.3.2 of 38.212
For 1 information bit: repetition as in section 5.3.3.1 of 38.212
For overlaid sequence based LP-WUS, there is no encoding to the raw information.
Whether CRC is configured
CRC is not adopted for LP-WUS.

3GPP TSG-RAN WG1 Meeting #121	R1-2504452
St Julian’s, Malta, May 19th- 23rd, 2025
Agenda Item:	5
Source:	Ericsson
Title:	Discussion on LS on differentiation of sTRP and sDCI mTRP 
Document for:	Discussion, Decision
1	

TDoc file conclusion not found

3GPP TSG-RAN WG1 Meeting #121	R1-2504469
St. Julian’s, Malta, May 19th – May 23rd, 2025

Agenda Item:	5
Source:	Ericsson
Title:	Discussion on RAN4 LS on LP-WUS UE RF
Document for:	Discussion
1	

Conclusions
In this document we discuss the RAN4 LS on UE RF [1] and propose the following
RAN1 can keep the -3dB SNR for signal design and support LP-WUS repetitions to compensate for any SNR difference due to different implementations and impairments.
For the RAN4 question on signal configuration details of LP-WUS and LP-SS for both idle/inactive and connected modes, provide the relevant RAN1 agreements (including any additional relevant agreements made in RAN1#121) in LS reply to [1]. 
4	

3GPP TSG-RAN WG1 Meeting #121	R1-2504470
St Julian’s, Malta, May 19 – 23, 2025

Agenda Item:	5
Source:	Ericsson
Title:	Discussion on RAN2 LS on LP-WUS in RRC_CONNECTED
Document for:	Discussion
1	

Conclusions
In this document we discuss the RAN2 LS on LP-WUS in RRC_CONNECTED [1] and propose the following
Proposal 1 
Provide following reply to RAN2 question “1. Whether there are any cases/scenarios on when the UE is not able to monitor LP-WUS?”
RAN1 agreed (in RAN1#120) that UE does not monitor LP-WUS during C-DRX active time for RRC connected mode.
RAN1 understanding is that for LP-WUS monitoring in RRC Connected mode, UE is not able to monitor LP-WUS in MO(s) that collide with the following
measurement gap, interruption caused by BWP switching, and RAR window monitoring for BFR.
Proposal 2 
Provide following reply to RAN2 question “2. Is there any case when the UE is not able to monitor LR and MR simultaneously?”
RAN1 assumes RAN2 intention of above question is - Is there any case when the UE is not able to monitor operate LR and MR simultaneously?
RAN1 understanding is that the specifications would capture any relevant collision handling between specific UE procedures associated with LR and MR operation (e.g., RAN2 working assumption for Option 1-1), and would not explicitly capture interaction between LR and MR which are UE internal components.
RAN1 has agreed/concluded the following about UE procedures associated with LR and MR interaction
UE does not monitor LP-WUS during C-DRX active time for RRC connected mode (agreement in RAN1#120).
When LP-WUS monitoring (option 1-1 or option 1-2) is enabled for RRC CONNECTED mode, it is supported that SR, PRACH and CG-PUSCH triggers MR PDCCH monitoring according to the legacy UE behaviour (conclusions in RAN1#120 and RAN1#120bis)

Proposal 3 
Provide following reply to RAN2 question “RAN2 would like to know whether there were any further conclusions in RAN1 on what information the preferred time offset via UAI should provide (e.g. in relation to the minimum time offset provided as a UE capability)?”
RAN1 understanding is as follows
Preferred time offset should be larger than or equal to the minimum time offset capability indicated by the UE
For option 1-1, the candidate values for preferred time offset should have same value range as Time_offset_CONNECTED_Option1-1 (i.e., time offset2 as in RAN1#120 agreement) 
For option 1-2, the candidate values for preferred time offset should have same value range as Time_offset_CONNECTED_Option1-2 (i.e., time offset4 as in RAN1#120 agreement).
4	

3GPP TSG RAN WG1 #121			R1-2504477
St Julian’s, Malta, May 19th – 23rd, 2025

Source:	Sharp
Title:	Discussion on Reply to LS on simultaneous configuration of SBFD and DC
Agenda Item:	5
Document for:	Discussion and Decision

Conclusion
In this contribution, we have the following proposals:
Proposal 1: Support SBFD operation on one carrier in EN-DC, NE-DC, and NR-DC.
Proposal 2: Reply to RAN2 that:
There is no issue to prevent us from supporting simultaneous configuration of SBFD and DC. 
However, the number of carriers with SBFD configuration should be one across cell groups. 

3GPP TSG RAN WG1 #121			R1-2504486
St Julian's, Malta, 19 - 23 May, 2025

Source:	NTT DOCOMO, INC.
Title:	Discussion on LS on UL Tx switching for TEI19
Agenda Item:	5
Document for: 	Discussion and Decision

Conclusion
In this contribution, we discussed on RAN4 TEI19 regarding UL Tx switching. Based on the discussion we made the following proposals.
Proposal 1: RAN1 should discuss and agree on the necessary draft CR for TS38.214 to support Scenario 1 based on the TP in RP-243003 as starting point.
In the first sentence, UE capability name “BandCombination-UplinkTxSwitch” may need to be changed to new capability name for indicating the support of Scenario 1.
In the first main bullet, RRC parameter name “uplinkTxSwitching” may need to be changed to new parameter name for differentiating Scenario 1 from other existing scenarios in Rel-16/17 UL Tx switching across two bands.
The first sub-bullet under the first main bullet may not be necessary. If a 3Tx UE supports only switchedUL, it can be covered by Rel-16/17 UL Tx switching (i.e., descriptions in 6.1.6.2.0) unless Scenario 1a is supported.
Proposal 2: Support of Scenario 1a and/or 2 should be discussed in RAN4 or RAN, not in RAN1.
RAN4 should discuss the feasibility of performing simultaneous switching on 3 or 4 Tx chains and the necessary switching period.
There are additional RAN1 impacts and concerns regarding the workload if it is treated as TEI19.

3GPP TSG RAN WG1 #121			R1-2504487
St Julian’s, Malta, May 19th – 23th, 2025

Source:	NTT DOCOMO, INC.
Title:	Discussion on reply LS on L1 based UE-to-UE CLI measurement and reporting
Agenda Item:	5
Document for: 	Discussion and Decision

Conclusion
In this contribution, we discussed L1 CLI measurement and reporting based on the reply LS from RAN4. Based on the discussion, we made the following proposals.
Proposal 1: Confirm the following RAN1 working assumption.

Proposal 2: Support out-of-range or infinity reporting for L1 SRS-RSRP.
If the number of reported L1-SRS-RSRP measurement resources is M, and the number of L1-SRS-RSRP measurements which are either >=-44dBm or infinity (infinity means UE cannot detect SRS due to too strong signal to measure) is X (X<=M),
An indicator corresponding to a codepoint mapping to out-of-range (L1-SRS-RSRP >= -44 dBm) or infinity: 7 bits 
A list of “out-of-range” indications based on differential measurement reporting table are reported for each of the X-1 L1-SRS-RSRP measurement: (X-1)*4bits
A codepoint defined as ‘out-of-range’ is introduced in the differential measurement reporting table
For the M-X L1-SRS-RSRP measurements which are within the reporting range (L1-SRS-RSRP <-44Bm), a differential reporting method is adopted using -44dbm as the reference: (M-X)*4bits

3GPP TSG RAN WG1 #121			R1-2504488
St Julian’s, Malta, May 19th – 23th, 2025

Source:	NTT DOCOMO, INC.
Title:	Discussion on LS on simultaneous configuration of SBFD and DC
Agenda Item:	5
Document for: 	Discussion and Decision

Conclusion
In this contribution, we discussed on support of simultaneous configuration of SBFD and DC. Based on the discussion we made the following proposal.
Proposal 1: Simultaneous configuration of SBFD and DC is supported, as one of multi-carrier scenarios.

3GPP TSG RAN WG1 Meeting #121                                               R1-2504586
St Julian's, Malta, 19th – 23rd May, 2025
Agenda item:		5
Source:	MediaTek Inc.
Title:	Discussion on RAN4 LS on UL Tx switching for TEI19
Document for:		Discussion and Decision

Conclusion
In this contribution, we provide our views on LS from RAN4 regarding UL Tx switching for TEI-19.
For Scenario#1 in RAN4 LS, RAN1 should adopt a CR to capture the following switching cases in TS38.214;

For Scenario#1 in RAN4 LS, adopt the followng TP for TS38.214 to support Scenario#1 in RAN1 specs.
RAN1 to discuss and decide at RAN1#121 whether to support Scenario#1a and/or Scenario#2 in Rel-19 as part of TEI-19.

3GPP TSG-RAN WG1 Meeting #121	R1-2504612
St. Julian’s, Malta, May 19th – 23rd 2025

Agenda Item:	5
Source:	Ericsson
Title:	On RAN4 LS on the transient period for SBFD operation
Document for:	Discussion, Decision

Conclusion
In the previous sections we made the following observations: 
Observation 1	For interference reasons, it would be beneficial to separate DL and UL spectrum in the intersection between DL and SBFD symbols, i.e., to introduce a guard band in the first symbol(s) of the UL subband.
Observation 2	Since RAN4 has agreed on explicit and unambiguous guard periods, it is convenient if a UE leverages the same guard period for its own reconfiguration.

Based on the discussion in the previous sections we propose the following:
Proposal 1	Introduce a guard subband in the first symbol(s) of the UL subband. FFS: guard subband duration.
Proposal 2	In an RO across SBFD and non-SBFD symbols, a UE is not expected to transmit a PRACH preamble in the guard (transient) period immediately preceding UL symbols.

3GPP TSG-RAN WG1 Meeting #121	R1-2504613
St. Julian’s, Malta, May 19th – 23rd 2025

Agenda Item:	5
Source:	Ericsson
Title:	Discussion on RAN2 LS on simultaneous configuration of SBFD and DC
Document for:	Discussion, Decision

Conclusion
In the previous sections we made the following observations: 
Observation 1	Supporting intraband DC will require a full duplex UE.
Observation 2	Supporting interband DC will require a substantial specification effort in RAN4.
Observation 3	The need for power sharing among bands in DC will affect SBFD UL performance.
Observation 4	Neither RAN1 nor RAN2 should not commit to simultaneous SBFD and DC without inquiring with RAN4.

Based on the discussion in the previous sections we propose the following:
Proposal 1	Simultaneous operation of SBFD and DC is not supported in Rel-19.
 

3GPP TSG-RAN WG1 Meeting #121	R1-2504619
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	5
Source:	Ericsson
Title:	On RAN4 TEI Uplink Tx Switching Scenarios
Document for:	Discussion, Decision
1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	Inclusion of additional scenarios expands the scope of TX switching enhancements TEI such that it is not justified as TEI, but rather a WI, if pursued.
Observation 2	Considering the limited time to the completion of Rel-19 in RAN1, we expect limited discussion on the needed CR to support the RAN4 agreement for Scenario 1.

Based on the discussion in the previous sections we propose the following:
Proposal 1	Discuss the needed CR to support the RAN4 agreement for Scenario 1, if the discussion is limited in time.
Proposal 2	If the discussion for support of Scenarios 1a and 2 is not quickly concluded, refrain from further discussions to support these scenarios.
Proposal 3	Inform RAN4 about the above observations and discussion outcomes in RAN1.

3GPP TSG-RAN WG1 Meeting #121	R1- 2504622
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	5
Source:	Ericsson
Title:	Discussion on LS on the startSFN parameter for positioning SRS with TX frequency hopping
Document for:	Discussion

TDoc file conclusion not found

3GPP TSG-RAN WG1 Meeting #121	R1- 2504623
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	5
Source:	Ericsson
Title:	Discussion on LS on non-RedCap UE UL SRS frequency hopping for positioning
Document for:	Discussion

TDoc file conclusion not found