3GPP TSG-RAN WG2 Meeting #130	R2-2503379
St. Julian’s, Malta, 19th – 23rd May, 2025
Agenda Item:	8.11.2
Source:	Huawei, HiSilicon
Title:	Impacts on the random access by the evolution of duplex operation	
Document for: Discussion and Decision
1	

Conclusion
Based on the above discussion we have the following observation and proposals: 
Observation 1: RO group is expressed as set of PRACH occasions in MAC spec, and the UE will select the next available set of PRACH occasions for the Msg1 repetition number.
Proposal 1: RAN2 confirms that for RACH configuration Option 1, there is no need to introduce separate featureCombinationPreamblesList configurations for Additional-ROs and Legacy-ROs; and for the RACH configuration Option 2, separate featureCombinationPreamblesList configurations for Additional-ROs and Legacy-ROs can be supported without restriction.
Proposal 2: RAN2 confirms that for RACH configuration Option1, the SBFD RACH resources and legacy RACH resources associated with same feature or feature combination are the same set of RACH resources.
Proposal 3: RAN2 confirms that for RACH configuration Option 2, the SBFD RACH resources and legacy RACH resources associated with same feature or feature combination are treated as the two separate sets of RACH resources.
Proposal 4: After the RO type switching, the UE shall select the set of Random Access resources including different types of RO for the current RACH re-attempt associated with the same feature or feature combination for this Random Access procedure.
Proposal 5: After the RO type switching with preamble repetition, UE needs to select RACH resource set with same or higher Msg1 repetition number, i.e. fallback to lower Msg1 repetition number should be avoided.
Proposal 6: Msg3 based early identification is not supported.
Proposal 7: RAN2 do not optimize on the possible RA-RNTI conflict issue.
4	

3GPP TSG-RAN WG2 Meeting #130	R2-2503386
St Julian’s, Malta, 19-23 May 2025	

Agenda Item:	8.11.2
Source:	NEC
Title:	Remaining open issues on random access in SBFD
Document for:	Discussion, Decision

Conclusion and Proposal
We have the following proposals:
Proposal-1:	Support Msg.3 based early indication for SBFD-aware UE in Rel-19.
Proposal-2:	RA-RNTI calculation is updated to also consider whether the RACH resource belongs to legacy RACH resources or additional RACH resources:
RA-RNTI = 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id + 14 × 80 × 8 x 2 x RACH_config
Proposal-3:	Support LTM cell switch via Random access procedure in SBFD symbols for SBFD-aware UEs.
Proposal-4:	For CFRA triggered RACH-based LTM cell switch, one reserved bit in the LTM Cell Switch Command MAC CE can be used to indicate the RO type.
Proposal-5: When the RO type switch happens, the UE fallbacks to perform: a set of random access selection, RA type selection, initialization of variables and random access resource selection procedure.
Proposal-6: Increase the power ramping counter when a SBFD-aware UE switches RO type (i.e., RO type switches from legacy-ROs to additional ROs or from additional ROs to legacy ROs) in one RACH procedure.
Proposal-7: For RACH configuration Option 2, when RO type switch is performed in one RACH procedure, a power offset is introduced to compensate the power ramping difference. 
Proposal-7a: If the proposal 7 is agreed, the power offset is determined by (PREAMBLE_POWER_RAMPING_COUNTER–1) × (PREAMBLE_POWER_RAMPING_STEP_SBFD – PREAMBLE_POWER_RAMPING_STEP_Legacy)

3GPP TSG-RAN WG2 Meeting #130                                                        R2-2503423
St.Julians, Malta, 19th – 23rd May, 2025	
                                                     
Source:              CATT 
Title:	             Random Access in SBFD symbols
Agenda Item:	8.11.2      
Document for:	Discussion and Decision

Conclusion
According to the analysis in section 2, it is proposed:
LTM related RA can use SBFD symbols [Open issue number RRC-2]
Proposal 1: (RRC-2) LTM related RA can be supported in SBFD symbols for reducing the UL synchronization time.
RO type indication for CFRA
Proposal 2: For CFRA triggered by PDCCH order, follow RAN1 agreement, the RO type is indicated in the DCI of PDCCH order.
Proposal 3: (RRC-2) If Proposal1 is agreed, for CFRA triggered by early UL synchronization with an LTM candidate cell and RACH-based LTM cell switch, the RO type is indicated in the EarlyUL-SyncConfig.
RO type selection for CFRA/CBRA fallback
Proposal 4:  If CFRA is triggered, UE always uses the RO type indicated for CFRA even if CFRA/CBRA fallback is performed.
Order of RA type selection
Proposal 5:  Confirm the working assumption that for SBFD-aware UE, the selection of RO type is suggested to be performed before the selection of the set of Random Access resources.
Random Access resources set during RO type fallback for CBRA [Issue MAC-2]
Proposal 6: (MAC-2) RAN2 confirms that the RA re-attempts should be within the same set of Random Access resources as the initial RA attempt with the introduction of SBFD.
Msg1 repetition number fallback within SBFD RO [Issue MAC-3]
Proposal 7: (MAC-3) Msg1 repetition number fallback can be supported within SBFD RO. 
Order of RO type fallback and msg1 repetition number fallback
Proposal 8: Once RO type fallback condition is met, UE should first perform RO type fallback and determine the Msg1 repetition number based on the new RO type.
Early identification in Msg3
Proposal 9: Follow RAN1 agreement, if legacy RO is selected, early identification via Msg3 is not supported.

TDoc file reading error

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

Agenda item:		8.11.2 (NR_duplex_evo)
Source:	LG Electronics Inc.
Title: 	Remaining issues on Random Access procedure for SBFD
Document for:	Discussion and Decision
1.	

Conclusion
In this contribution, it is discussed about RAN2 aspects on Random Access operation for SBFD. This document includes following proposals.
Proposal 1. The explicit indication to indicate whether RACH configuration Option 1 is enabled or not (i.e., sbfd-RACHSingleConfig) is indicated per RACH configuration (e.g., in RACH-ConfigCommon IE).
Proposal 2. Confirm the working assumption: For SBFD-aware UE, the selection of RO type is suggested to be performed before the selection of the set of Random Access resources.
Proposal 3. From RAN2 perspective, CSI-RS based CFRA in SBFD symbol is supported. Send an LS to RAN4 whether there is any issue to support CSI-RS based CFRA, if needed.
Proposal 4. For PRACH transmission re-attempt in one RA procedure, UE is allowed to switch between SBFD RO and non SBFD-RO only in the same feature combination and the same repetition number.
Proposal 5. After the RO type switch, same RA type is selected for the current Random Access procedure, i.e., no re-select the RA type upon RO type switch.
Proposal 6. Support the Msg1 repetition number fallback, i.e., fallback from low Msg1 repetition number to high Msg1 repetition number in SBFD RO.
Proposal 7. RO type switch is performed prior to Msg1 repetition number fallback.
Proposal 8. It is up to network implementation to handle the RA-RNTI collision issue for RACH configuration Option 2.

4.	

3GPP TSG-RAN WG2 Meeting #130											R2-2503513
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.11.2
Source: 	Sharp
Title:  	Open Issues on SBFD Random Access
Document for: 	Discussion

Conclusions
Based on the discussion above, RAN2 is requested to agree the following proposals:
Msg3-based early indication with using LCID field in legacy ROs during RA procedure is supported to indicate UE’s SBFD capability.
Feature combination preamble configurations are provided separately for Additional ROs and Legacy ROs in RACH configuration Option 1.
RA resource set reselection is supported after RO type switching.
Early UL synchronization with an LTM candidate cell is supported in SBFD symbols.
1-bit indication of RO type is introduced in LTM Cell Switch Command MAC CE.
RAN2 to confirm that 2-step RACH in SBFD symbols is not supported.

3GPP TSG RAN2 Meeting#130                                                                R2-2503606
St. Julians, Malta, 19th – 23rd May, 2025 
                                             	
Agenda item:	8.11.2
Source:	Samsung
Title:	Random access in SBFD
Document for:	Discussion & Decision

Conclusion
RAN2 is requested to discuss and agree to the following proposals:

Proposal 1. RAN2 supports the Msg3-based Early Indication for Rel-19 SBFD-aware UEs.
Proposal 2. RAN2 confirms the WA: For SBFD-aware UE, the selection of RO type is performed before the selection of the set of Random Access resources.
Proposal 3. RA resource set change is not supported for RO type switching.
Proposal 4. Fallback of Msg1 repetition number is supported for SBFD RO without further optimization.

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

Agenda Item:	8.11.2
Source: 	OPPO
Title:  	Remaining issues of SBFD RACH procedure
Document for:	Discussion and Decision

Conclusion
According to the analysis provided above, we have the following observations and proposals:
Observation 1: For SBFD RACH configuration Option 2, the power ramping step of additional RO can be different from the power ramping step of the legacy RO.
Observation 2: The power ramping offset (i.e. POWER_OFFSET_2STEP_RA) for the fallback between 2-step RACH and 4-step RACH is introduced, as the power ramping step of 2-step RACH can be different from the power ramping step of 4-step RACH.
Observation 3: Using 1-bit Msg3 indication of SBFD cannot help the gNB to provide the correct SBFD configuration, as a few UE capability bits will be introduced for indicating which sub-feature of SBFD function is supported.
Observation 4: When additional RO overlaps with legacy RO, the RA-RNTI may/may not be collided, depending on the number of RACH procedures triggered at the same time.
Observation 5: When the number of legacy ROs and the number of additional ROs are large, the probability of RA-RNTI collision is low.
Observation 6: When the RA-RNTI is collided, the UE can still re-access by sending a new preamble, which encounters less RA-RNTI collision due to the randomization of BI.
Observation 7: The configuration of the legacy RO for 2-step RACH and the additional RO for 4-step RACH in the same symbol can be supported. The MSGB-RNTI of legacy RO is not collided with the RA-RNTI of additional RO.

Proposal 1: RACH in SBFD symbols is not supported for LTM in Rel-19, including both LTM early sync and LTM cell switch.
Proposal 2: Alike the fallback between 2-step RACH and 4-step RACH, power ramping offset is introduced for the fallback between legacy RO and additional RO.
Proposal 3: Msg3 indication for SBFD is not supported.
Proposal 4: Whether/how to handle the RA-RNTI collision for the case that additional RO overlaps with legacy RO is up to the network implementation.

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

Agenda item:	8.11.2
Source:	Nokia
Title:	Random Access Operation of SBFD
WID/SID:	NR_duplex_evo-Core - Release 19
Document for:	Discussion and Decision

Conclusion
Observation 1:  A 1-bit indication in RACH-ConfigCommon is not suitable for dynamically distributing  the RA attempts from the SBFD UEs in legacy and additional RO type. 
Observation 2: In PRACH configuration Option 2, RA-RNTI collision may happen when the SBFD ROs configured by the additional configurations overlap with the legacy ROs in flexible symbols.  
Proposal 1: For Option 2, in case the legacy ROs and the additional ROs have the same value for one of the RACH configuration mandatory parameters, only the legacy RACH configuration will be configured with this parameter.  For Option 2, in case the SBFD aware UEs did not receive a dedicated mandatory parameter in the additional RACH configuration, the SBFD-aware UEs determine this dedicated parameter from the legacy RACH configuration. 

Proposal 2.1: For CBRA RO type indication, that NW includes a value  between 0 and 1 based on the NW load in RACH-ConfigCommon. FFS the granularity of the value generated (how many bits). 
Proposal 2.2: Upon receiving the indicated value, the UE generate a uniformly distributed random number between 0 and 1(using pseudo random number generator algorithm), and if the generated value is less than the value indicated by the NW, the UEs use the SBFD RO for random access.
Proposal 3: RAN2 to confirm that RA-RNTI collision may happen when the SBFD ROs configured by the additional configurations overlap with the legacy ROs in flexible symbols.  
Proposal 4: To avoid RA-RNTI collision scenario described above, RAN2 to down select a solution from the option 1 and option 2 listed below 
Option 1: Defining a new rule for indexing of f_id when there is overlapping without modifying the existing RA-RNTI formula. When there is overlapping, the SBFD-aware UE determines the frequency index (f_id) by: 
Firstly, determining the frequency index of the legacy ROs by ignoring the SBFD ROs (i.e., aiming at keeping the same legacy index for the legacy ROs).
Secondly, determining the frequency index of SBFD ROs by continuing the indexing starting from the index used for the last legacy RO plus one (and ignoring the legacy ROs).
Option 2: When there is an overlap between the SBFD ROs and additional ROs in flexible symbols (RACH configuration Option 2), the SBFD UEs uses  s_id + 1 for the calculation of the RA-RNTI. 
Proposal 5: The fallback from legacy RO to an additional RO in SBFD symbols is supported only when the contention resolution is not succeeded for the SBFD-aware UEs for its RA attempts in legacy RO. 
Proposal 6: Discuss whether to allow the NW to indicate to the SBFD UEs  via RAR message to switch the RO type.

3GPP TSG-RAN WG2 Meeting #130                                      R2-2503874
St Julian's, Malta, 19 - 23 May 2025	

Source:        ZTE Corporation
Title:           Discussion on random access procedure in SBFD
Agenda item:   8.11.2
Document for:  Discussion and Decision

Conclusion
In this contribution, we propose the following observation and proposals:
SBFD RACH configuration in NUL carrier
Proposal 1: RAN2 confirms that SBFD RACH configuration option 1 and option 2 should only be configured in NUL carrier, no matter the SBFD RACH configuration is in SIB or in dedicated signaling.

CBRA in SBFD ROs
Proposal 2: Support both legacy 4-step RO and legacy 2-step RO to fall back to 4-step SBFD RO. The maximum failure number threshold should be configured in both RACH-ConfigCommon and RACH-ConfigCommonTwoStepRA.
Proposal 3: For 2-step legacy RO fallback to 4-step SBFD RO, RAN2 should discuss how to handle the co-existence between this new maximum failure number threshold and the legacy msgA-TransMax-r16. Considering one of the following options:
gNB should not configure this maximum failure number threshold and msgA-TransMax-r16 together.
gNB can configure this maximum failure number threshold and msgA-TransMax-r16 together , but this value should not be equal to msgA-TransMax-r16.
Proposal 4: RAN2 should discuss whether fallback from 2-step RACH resource -> 4-step RACH resource -> 4-step SBFD RACH resource in one RA process can be supported.
Proposal 5: When UE switches from RO type 1 to RO type 2, RAN2 to confirm which of the following is the desired UE behavior of set reselection:
UE should perform a set re-selection on the RO type 2 thoroughly, using all the wanted features/feature combinations;
UE should just check the set availability in RO type 2, using the final feature/feature combination associated with the already selected set of the RO type 1. If such set exists within RO type 2, UE can fallback to use that set; if does not exist, UE cannot fallback.
Proposal 6: Do NOT support Msg3 based early identification for SBFD-aware UE.
Proposal 7: Send LS to RAN1 to ask whether there is a need to solve the RA-RNTI collision issue for RRC SBFD RACH configuration option 2, and if yes, what the recommended solution is.

LTM in SBFD ROs
Observation 1: SBFD RO and LTM share same intention to reduce handover latency.
Observation 2: The RAN2 specification impact of supporting SBFD RO and LTM is small. There is no RAN3 spec impact on LTM+SBFD since current F1AP transfers RAN2 CFRA configuration signaling as a container.

Proposal 8: Support using SBFD RO in LTM cell switch and LTM early sync CFRA case.
Proposal 9: Include 1-bit RO type indication in the LTM cell switch MAC CE.
Proposal 10: For LTM early sync, include the SBFD time and frequency resource of each candidate cell in the RRC signaling EarlyUL-SyncConfig. 

CFRA in SBFD ROs
Observation 3: Even if with the same RACH-ConfigGeneric and same TDD/SBFD time/frequency location, RRC SBFD RACH configuration option 1 and option 2 will derive different additional RO location for SBFD-aware UE.

Proposal 11: If a CFRA configuration indicates UE to use SBFD RO, UE should know the SBFD RACH configuration type (option 1 or option 2). FFS how UE knows SBFD RACH configuration type in each CFRA cases.
Proposal 12: Support using CSI-RS beam for SBFD RO in BFR and ReconfigurationWtihSync kind of CFRA, and there is no need to design separate SSB-RSRP or CSI-RSRP threshold than legacy.
Proposal 13: If a CFRA case indicates to use SBFD RO, when selecting set for the CFRA, UE should:
If common RACH parameters of the same BWP provides SBFD ROs, UE selects set within the RACH partition of SBFD RO;
If common RACH parameters of the same BWP does not provide SBFD ROs, UE selects set within the RACH partition of legacy RO.

Msg1 repetition in SBFD ROs
Proposal 14: Support fallback from lower Msg1 repetition number to higher Msg1 repetition number on SBFD ROs, and such fallback should be associated with the same feature/feature combination.
Proposal 15: Support UE firstly perform Msg1 repetition on one RO type for several times and fallback from low Msg1 repetition number to higher Msg1 repetition number, then fallback to another RO type to continue Msg1 repetitions.

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

Agenda Item:	8.11.2
Source:	vivo
Title:	Remaining issues on RACH procedure in SBFD
Document for:	Discussion and Decision

Conclusion
Based on the discussion, we have the following observation and proposals:
Proposal 1: Msg1 repetition number fallback can be supported with SBFD RO, e.g. Msg1 repetition number can fallback from 2 to 4, or from 4 to 8 as legacy, if the corresponding Msg1 repetition number in SBFD is applicable.
Proposal 2: RAN2 to discuss and down-select from the following 2 way-forwards to address the issue of Msg1 repetition number inapplicability after RO type fallback:
Way-forward 1: RO type fallback is not allowed if the current Msg1 repetition number is not applicable after RO type fallback; Otherwise, the UE can perform RO type fallback.
Way-forward 2: RO type fallback is always allowed. If the current Msg1 repetition number is not applicable after RO type fallback, the UE select the corresponding RA resource set of the highest applicable Msg1 repetition number of the target RO type.
Proposal 3: RO type fallback can be either before or after Msg1 repetition number fallback. Follow the current running CR that RO type fallback is before Msg1 repetition number fallback.
Proposal 4: If the NW does not provide RO type indication, the NW will at least configure an SSB RSRP threshold for RO type selection in the SBFD RACH configuration.
Proposal 5: Legacy SSB/CSI-RS selection procedure is reused for random access procedure with SBFD operation.
Observation 1: If the SBFD-aware UE chooses legacy RO, it reflects the fact that SBFD-based transmission may not be a good choice from scheduling point of view within some upcoming duration. The NW will anyway know the UE supports SBFD when the RRC establishment procedure is completed.
Proposal 6: Do not support Msg3-based early identification for SBFD-aware UE.

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

Agenda Item:	8.11.2
Source: 	Sony
Title:	Remaining issues for Random Access in SBFD Operation 
Document for:	Discussion and Decision

Conclusions
In this contribution, we have discussed some remaining issues for random access in SBFD operation and we have the following proposals.

Proposal 1: For initial RA transmission, the network indicates in SIB1 the RO type (legacy RO or additional RO) to the SBFD-aware UEs for the case of CBRA, where indication is 2-bits representing four different values: {100%, 80%, 50%, 0%}.

Proposal 2: To avoid RNTI collision/confusion, simply introduce a configurable offset for the symbol index (s_id) in the RNTI equation, and the offset is signalled in SIB1 as a part of PRACH resource configuration for SBFD-aware UEs.

TDoc file reading error

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

Agenda item:	8.11.2
Source:	Qualcomm Incorporated
Title:	Views on random access for SBFD 
WID/SID:	NR_duplex_evo-Core – Release 19
Document for:	Discussion and Decision

Conclusion
We have the following observations, and we’d recommend RAN2 to discuss and adopt the following proposals:
Observation 1: After the number of PRACH attempts on one type of RACH resource exceeds a threshold, the RO type switch from legacy-RO to additional-RO or from additional-RO to legacy-RO are both supported, and the RO type switch within one RACH procedure is only allowed once.

Proposal 1: An RO type indication is added in LTM cell switch command MAC CE to indicate whether RACH triggered by MAC CE can be performed on additional-RO. 
Proposal 2: For PRACH configuration option 1, when a feature combination is configured using preamble partitioning of the RACH-ConfigCommon, using the shared ssb-SharedRO-MaskIndex configuration for Additional-ROs and Legacy-ROs.
Proposal 3: Separate featureCombinationPreamblesList configuration for Additional-ROs and Legacy-ROs is not supported.
Proposal 4: When UE switches to the other type of RO from the initial selected type of RO, a power offset given by the difference between the two quantities of preamble power step sizes is added.
Proposal 5: RAN2 confirms that the RO type selection between the additional-ROs and legacy-ROs should be performed before the selection on the set of RACH resources associated with the feature combinations.
Proposal 6: Upon the RACH initiation, if UE has met the conditions of selection on one type of RO, UE does not need to evaluate the set of RACH resources of the feature combinations configured in the other type of ROs.
Proposal 7: When RO type switches from one type of RO to the other type of RO, UE should evaluate the set of RACH resources of the feature combinations configurated in the other type of RO.
Proposal 8: For RACH fallback from one type of RO to the other type of RO, at least UE is allowed to switch the type of RO configured with the same feature combinations. FFS the case of no same feature combination configured on the other type of RO when performing RACH fallback.
Proposal 9: After UE selects one type of RO and determines the number of preamble repetition for the first PRACH transmission, UE is allowed to fall back to a higher repetition number in the same type of RO but not exceed the threshold of the PRACH transmission attempts for RACH type switch.
Proposal 10: If Msg1 based SBFD-aware indication is not supported, Msg3 based SBFD-aware indication should be supported from RAN2 perspective.
Proposal 11: RAN2 to study the RA-RNTI collision issue for RACH configuration Option 2.
Proposal 12: From RAN2 perspective, the CSI-RS based CFRA on SBFD resource is supported.

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

Agenda Item:	8.11.2
Source:	Ericsson
Title:	SBFD RA remaining aspects
Document for:	Discussion
1	

Conclusion
Based on the discussion in the previous sections we propose the following:
Observation 1	Support SBFD awareness early indication via Msg3 or Msg5 would require RAN2 to introduce an indicator in either MAC layer or RRC signalling, which would increase unnecessary design efforts for RAN2.
Observation 2	With early indication via Msg3 or Msg5, the gNB may be only feasible to schedule SBFD resources to subsequent signalling transmissions. The achieved latency reduction or other performance enhancements would be marginal given that the gNB will anyway receive the UE capability from UE or CN after the RACH procedure.
Observation 3	If the UE sees no need to apply SBFD RA (to exploit latency reduction or coverage extension), the UE would not choose SBFD RO for Msg1 transmission.
Observation 4	For a RO across SBFD symbols and non-SBFD symbols, the RO may be overlapping with a legacy RO on 2nd symbol or beyond, in such case, at least the s_id would be different, which would be sufficient to distinguish RA-RNTIs between the SBFD RO and the legacy RO which are overlapping.
Observation 5	A configured RO starting from non SBFD symbols and ending in SBFD symbols, is invalid.

Based on the discussion in the previous sections we propose the following:
Proposal 1	SBFD awareness early indication via Msg3 or Msg5 is not pursued for SBFD aware UE.
Proposal 2	Random access procedure in SBFD symbols is not supported for LTM.
Proposal 3	RAN2 to confirm that for SBFD-aware UE, the selection of RO type is suggested to be performed before the selection of the set of Random Access resources.
Proposal 4	Update the RA-RNTI formula for SBFD RA configuration is not pursued.

4	

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

Agenda Item:	8.11.3
Source:	Ericsson
Title:	CSI-RS measurements in SBFD
Document for:	Discussion
1	

Conclusion
Based on the discussion in the previous sections we propose the following:
Observation 1	Configuration 1 and Configuration 2 on UL transmissions and DL reception across SBFD symbols and non-SBFD symbols in different slots are not applicable to CSI-RS resources configuration and CSI-RS based RLM/BFD/CBD measurement.
Observation 2	UE can provide separate CSI reports to the gNB according to the configured valid symbol type in the corresponding CSI-ReportConfig.
Observation 3	RAN1 doesn’t indicate whether the valid symbol type can be included in RadioLinkMonitoringConfig and BeamFailureRecoveryConfig.
Observation 4	If SSB is configured as the measurement RS, there is no impact on handover due to SBFD operation.

Based on the discussion in the previous sections we propose the following:
Proposal 1	No enhancement is needed for CSI-RS based RLM/BFD/CBD measurements.
Proposal 2	Keep the legacy RLM, BFD and BFR procedure in the MAC layer, i.e., no need for the MAC entity to trigger RLF, BFD and BFR for non SBFD symbols and SBFD symbols separately.
Proposal 3	Enhancement for L3 mobility CSI-RS measurement is not pursued.

4	

3GPP TSG-RAN WG2 Meeting #130	R2-2504327
St.Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.11.2
Source:	InterDigital, Inc.
Title:	Discussion on RACH aspect in SBFD
Document for:	Discussion
1. 

Conclusion
Proposal 1. Support to switch from SBFD-ROs to legacy-ROs upon reaching maximum power of PRACH transmission during performing re-attempts with power ramping, regardless of the remaining possible counts of the configured max number of re-attempts.
Proposal 2. Support to separately configure a parameter of the maximum transmission power (Pcmax) of PRACH for SBFD-ROs using SBFD symbols, from that for legacy-ROs.
Proposal 3. Do not support RA procedure using SBFD symbols with LTM procedure in Rel-19. 
Proposal 4. Support early indication for SBFD-aware UE in RRC-Idle/Inactive states to indicate UE’s support of SBFD operation via MSG3.
4. 

3GPP TSG RAN WG2 Meeting #130	R2-2504397
Malta, May 19th – 23rd, 2025
Agenda Item:	8.11.2
Source:	CMCC	
Title:	Discussion on random access in SBFD
Document for:	Discussion 

Conclusion
Based on the discussions mentioned above, in this contribution we provide some discussions on random access in SBFD:
Observation 1: Supporting SBFD operation for early UL sync can help to reduce UE’s handover latency.
Observation 2: There are more specification impacts, rather than just adding an RO type indication to EarlyUL-SyncConfig IE, if SBFD operation is also supported for LTM.
Observation 3: There is no consensus whether to support 2-step RACH or not in RAN1.
Observation 4: Both the scheme that RO type selection before the selection of set of random access resources and the scheme that RO type selection after RA type selection can work, but may result in different specification impacts and performances.
Observation 5: The remaining issue of the RO type indication for CFRA is related to whether RAN2 supports SBFD operation in LTM.
Observation 6: There are two alternatives for the RO type determination when fallback from CFRA to CBRA is performed:
Alt 1: SBFD-aware UE uses the CBRA resource with same RO type as that indicated in CFRA resource.
Alt 2: SBFD-aware UE selects the RO type based on the RO type indication of CBRA or configured RSRP threshold and corresponding rule (below/above the RSRP threshold) or its implementation (if both RO type indication and RSRP threshold are absent).
Observation 7: Higher MSG1 repetition number in addition RO can also bring better uplink coverage performance for SBFD-aware UEs.
Observation 8: With Msg3-based early indication, there is almost no impact on PRACH capacity of non SBFD-aware UEs. 
Observation 9: If Msg3-based early indication is not supported, network can only identify a SBFD-aware UE through UE capability transfer which is later than that through Msg3-based early indication. 
Observation 10: There are many solutions to solve RA-RNTI collision issue:
Solution 1: It is up to network implementation to solve this.
Solution 2: A configurable offset of symbol index (s_id) or frequency index (f_id) can be introduced.
Solution 3: An additional offset can be introduced to the formula for computing RA-RNTI, such as:
Observation 11: When designing the offset value in the formula for computing RA-RNTI in additional ROs, it is necessary to avoid collisions with the legacy RA-RNTI and MSGB-RNTI. 

Proposal 1: We are open to discuss whether to support SBFD operation for LTM.
Proposal 2: RAN2 is asked to confirm that SBFD operation in 2-step random access procedure is not supported in R19. 
Proposal 3: RAN2 confirms that the SBFD-aware UE can determine the RACH configuration option in one cell based on the CBRA RACH configuration option of that cell. 
Proposal 4: The work assumption that for SBFD-aware UE, the selection of RO type is suggested to be performed before the selection of the set of Random Access resources, can be confirmed.
Proposal 5: RAN2 is asked to discuss whether the direct fallback from 2-step RACH to 4-step RACH with additional RO is supported or not.
Proposal 6: RAN2 is asked to support that SBFD-aware UE uses the CBRA resource with same RO type as that indicated in CFRA resource when fallback from CFRA to CBRA is performed.
Proposal 7: RAN2 is asked to support the fallback from transmission with lower MSG1 repetition number to higher MSG1 repetition number in addition RO.
Proposal 8: The fallback from transmission with lower MSG1 repetition number to higher MSG1 repetition number in addition RO is restricted to RACH resources with the same feature/feature combination.
Proposal 9: When RO switch is performed, the SBFD-aware UE uses the minimum repetition number that is not lower than the MSG1 repetition number before RO type switch and is also configured for the other RO type.
Proposal 10: After RO type switch, SBFD-aware UE can continue increasing the number of MSG1 repetitions until reaches the maximum configured Msg1 repetition number configured for the RO type.
Proposal 11: RAN2 is proposed to support Msg3-based early indication for SBFD-aware UEs. 
Proposal 12: If RAN2 agrees to address the RA-RNTI collision issue, introducing an additional offset to the formula for computing RA-RNTI in additional RO is preferred.

3GPP TSG-RAN2#130	R2-2504602
St. Julian, Malta, May 19th-23rd, 2025

Agenda item:		8.11.2
Source:		Lenovo
Title:		 Random Access in SBFD
Document for:		Discussion and Decision

Conclusion

This document discusses some aspects of Random Access for SBFD. Following are the proposals and observations made in this document:
Proposal 1: (RRC-2) Early UL Synchronization with an LTM Candidate Cell and RACH-based LTM are not supported on SBFD symbols.
Proposal 2: If the network indicates additional RO for initial RA in the case of CBRA, SSB RSRP threshold is configured as an additional criterion. 
Proposal 3: RAN2 to agree that a different SSB RSRP threshold is indicated/configured for an SSB or a group of SSBs to limit inter-UE CLI and achieve a better load balancing between additional RO type and legacy RO type.