3GPP TSG RAN WG1 #120bis	    R1-2501713
Wuhan, China, April 7th – 11th, 2025
Agenda Item:	9.5.1
Source:	Futurewei
Title:	Discussion of on-demand SSB SCell operation
Document for:	Discussion and decision 

Conclusions
In this contribution, we present our views on the objective of on-demand SSB SCell operation. 
Proposal 1:  If always-on SSB is CD-SSB not on a synchronization raster, the frequency location of on-demand SSB is the same as the frequency location of always-on SSB.
Proposal 2: For the case when the center frequency locations of always-on SSB and on-demand SSB are same, the half frame index can be the same or different for AO-SSB and OD-SSB. 
Proposal 3: PBCH payload for the same SSB index (other than SFN index, half frame index) should be the same for AO-SSB and OD-SSB.
Proposal 4: Do not support indication of time offset between always-on SSB and on-demand SSB (e.g., similar to ssb-TimeOffset).
Proposal 5: For Case #2 (always-on SSB transmission), when the configuration parameters are absent for on-demand SSB, the default values are the values of corresponding parameters of always-on SSB.
Proposal 6: RAN1 to discuss and conclude whether Scenario #3B (on-demand SSB after SCell activation) is supported in Rel-19.
Proposal 7: For determining time instance A, support Option 1, the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication.
Proposal 8: Support Option 2: A CSI report configuration is associated with one of always-on SSB and on-demand SSB.

3GPP TSG RAN WG1 #120b                                                                                R1-2501736                
Wuhan, China, April 7th – April 11st, 2025

Source:	TCL
Title:	Discussion on on-demand SSB Scell operation for NES
Agenda Item:	9.5.1
Document for:	Discussion and Decision

Conclusion
This paper discussed how to design on-demand SSB Scell operation, with the following observation/proposals:
Observation 1: Even if most cases consider semi static-based MAC CE to indicate OD-SSB transmission,  but specific DCI could be used for reducing signaling overhead if multiple UE configured with same SCell, e.g., group common DCI. 
Observation 2: Even DCI 2_9 used for cell DTX/DRX transmission before, as group common for DCI 2_9, it is still introduced for NES-mode indication.

Proposal 1: For the explicit indication of deactivation for on-demand SSB via MAC-CE, scenario #3B at least should be supported. 
Proposal 2: Support option 4 or 4a for OD-SSB deactivation.
Proposal 3: Not support the value of N is implicitly determined using a timer.
Proposal 4: Support at least group common DCI used for indicating OD-SSB transmission.
Proposal 5: UE expects that multiple on-demand SSB is transmitted from time instance A plus potential time offset. 
Proposal 6: Same parameter like frequency, SCS, SSB positions within an on-demand SSB burst could be configured for AO-SSB and OD-SSB for case #2.

Proposal 7: Periodicity of the on-demand SSB/location of on-demand SSB burst need to configure separately for AO-SSB and OD-SSB for case #2.   

Proposal 8: Support multiple OD-SSB configuration and consider how to activate/deactivate each configured  OD-SSB for scenario #2, #2A and #3B.

Proposal 9: Support multiple OD-SSB configurations with same frequency position.

Proposal 10: Support define reference point of OD-SSB for case #2 based on periodicity of AO-SSB.

Proposal 11: Define minimum frequency gap between AO-SSB and OD-SSB during same BWP with regards to UE capability.

Proposal 12: Support same frequency location for AO-SSB and OD-SSB. 

Proposal 13: Support Alt Time-C to consider time domain relationship between OD-SSB and AO-SSB.

Proposal 14: Consider how to handle collision between OD-SSB and AO-SSB, including priority definition or following previous type of SSB to receive SSB when collision happened.

Proposal 15: Consider how to differentiate AO-SSB and OD-SSB by multiplexing similar schemes like priority definition.

Proposal 16: Postpone to discuss aperiodic CSI report until DCI used for indicating OD-SSB transmission being discussed.

Proposal 17: Discussion on the impact of OD-SSB transmission including case #1 and case #2 on BFD reporting periodicity or detection timer.

Proposal 18: Discuss how to handle collision between OD-SSB resource and NR resource and how to handle rate-matching.

3GPP TSG RAN WG1 meeting #120-bis		                                   R1-2501764
Wuhan, China, Apr. 7th – Apr. 11th, 2025
Title: 	Discussion on on-demand SSB for NES 
Source: 	ZTE Corporation, Sanechips
Agenda item:	9.5.1
Document for:	Discussion and decision

Conclusion
In this contribution, we have the following observations and proposals:
Observation 1:	Scenario #3B in conjunction with case #1 can achieve a good trade-off between network energy saving and system performance.
Observation 2:	Using MAC CE based signaling to indicate on-demand SSB transmission for Scenarios #3B is one potential option.
Observation 3:	For scenario #3B, adopting the same signaling with agenda 9.5.3 for on-demand SSB indication (if needed) can reduce the complexity of signaling design.
Observation 4:	Using timer to implicitly indicate the value of N performs the same function as configuring N directly but introduces a large workload.
Observation 5:	Whether half frame index is the same or different for AO-SSB and OD-SSB is related to whether a non-periodic time domain pattern between OD-SSB and AO-SSB (i.e., Alt Time-C2) is supported.
Observation 6:	The processing delay (T_min) is related to both the numerology of both triggering signaling and the on-demand SSB transmission.

Proposal 1:	The periodicity of on-demand SSB can be smaller than or equal to that of the always-on SSB, and can be one of 5ms, 10ms, 20ms, 40ms, 80ms, or 160ms.
Proposal 2:	Support the case where SSB indices within on-demand SSB burst can be subset of SSB indices within always-on SSB burst.
Proposal 3:	Scenario #3B in conjunction with case #1 should be supported.
Proposal 4:	Do not support RRC based signaling to activate on-demand SSB in cases other than RRC configures, activates the SCell and provides on-demand SSB configuration for SCell.
Proposal 5:	Consider either MAC CE based signaling or DCI based signaling discussed in agenda 9.5.3 to indicate the on-demand SSB transmission for scenario #3B.
Proposal 6:	Support Option 1 (i.e., Explicit indication of deactivation for on-demand SSB via MAC-CE for on-demand SSB transmission indication) for all scenarios that support the on-demand SSB feature.
Proposal 7:	Support Option 2 (i.e., Configuration/indication of the number N of on-demand SSB bursts to be transmitted after on-demand SSB is indicated) for all scenarios that support the on-demand SSB feature.
Proposal 8:	Support the combination of option 1 and option 2.
Proposal 9:	Option 4 and 4a are not needed.
Proposal 10:	Introducing timer to implicitly determine the value of N is not supported.
Proposal 11:	The determination of candidate values of N is up to RAN4.
Proposal 12:	Whether half frame index is the same or different for AO-SSB and OD-SSB should be discussed after receiving a reply from RAN4.
Proposal 13:	When the center frequency locations of AO-SSB and OD-SSB are different, there should be no restriction requiring that PBCH payload for the same SSB index (other than SFN index, half frame index) should be the same for AO-SSB and OD-SSB.
Proposal 14:	Do not support to introduce a time offset indication between always-on SSB and on-demand SSB.
Proposal 15:	The od-ssb-absoluteFrequency for case #2 can be absent only when the frequency of the on-demand SSB is same as that of always-on SSB.
Proposal 16:	The od-ssb-PositionsInBurst for case #2 can be absent only when the SSB positions within an SSB burst of the on-demand SSB is same as that of always-on SSB.
Proposal 17:	The number N of on-demand SSB bursts to be transmitted, the SSB positions within an on-demand SSB burst, and the periodicity of the on-demand SSB can comprise more than one candidate values and indicated by the indication signaling.
Proposal 18:	On-demand SSB transmission pattern comprising more than one parameter can be configured as a list for the SCell to UE, to reduce the overhead of indication the UE specific signaling.
Proposal 19:	Confirm the working assumption that T = T_min.
Proposal 20:	Option 2 is supported, that is, the minimum of “the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication” and “the SCS of the active DL BWP where UE receives on-demand SSB”.
Proposal 21:	Do not support to restrict the OD-SSB and always on SSB have same beams.
Proposal 22:	Option 2, a CSI report configuration is associated with one of always-on SSB and on-demand SSB, is supported.

3GPP TSG RAN WG1 #120bis		R1-2501772
Wuhan, China, April 7th – 11th, 2025

Agenda item:		9.5.1
Source:	Nokia, Nokia Shanghai Bell
Title:	On-demand SSB SCell Operation
Document for:		Discussion and Decision

Conclusions
In this contribution, we have the following observations and proposals:
Proposal 1: At least for Case #1 support indication of OD-SSB in Scenario #3B, but may also be supported for Case#2 and Scenario #3B.
Proposal 2: Support configuration of frequency of the on-demand SSB (i.e., od-ssb-absoluteFrequency) also for Case #2.
Observation 1: The od-ssb-periodicity may be configured with multiple values. 
Observation 2: Number of SSB bursts od-ssb-nrofTx may be configured in certain scenarios where OD-SSB is required for a shorter duration.
Proposal 3: RAN1 to consider that one or more parameters may be provided as a list or network may be able to configure more than one SSB pattern. The definition of the structure should be left to RAN2.
Observation 3: The NES gain related to configuration of SSB positions within an on-demand SSB burst in Case #2 may be low and may result in additional signalling overhead.
Proposal 4: For Case#2 transmitted SSB indices within on-demand SSB burst are identical to SSB indices within always-on SSB and the parameter ssb-PositionsInBurst is absent.
Proposal 5: RAN1 to prioritize unified signaling framework that supports on-demand SSB configuration for both Case#1 and Case#2. Hence SFN offset and half-frame index are preferred over ssb-TimeOffset.
Proposal 6: When OD-SSB is on different frequency than always-on SSB and a UE is not capable to measure both of them, the UE is required to measure only OD-SSB frequency for the L1 reporting.   
Observation 4: For simplification of the options and progress towards a feasible solution, we can deprioritize the case when always-on SSB is CD-SSB not in the synchronization raster.
Proposal 7: For Case#2, half-frame index may be same or different for AO-SSB and OD-SSB
Proposal 8: For Case#2, when AO-SSB and OD-SSB are on different frequencies, PBCH payload for same SSB index shall be different due to the k_SSB contents.
Proposal 9: Additional processing/preparation time discussed in RAN4 shall be included in the definition of the value of T
Observation 5: The numerology considered for the T_min calculations are with respect to the carrier on which UE transmits HARQ-ACK information for the MAC-CE reception.
Proposal 10: RAN1 to confirm that the agreement on the T slots apply to the cell in which UE sends HARQ-ACK information for the MAC-CE signaling and applies irrespective of the SCell numerology.
Proposal 11: Besides Option 1 and Option 2 no other options are specified for OD-SSB deactivation
Proposal 12: In Option 2 the duration of OD-SSB transmission can be based on timer and the value of N is then determined implicitly.
Observation 6: The CSI resources are associated with a DL BWP. As per the current specification, the csi-SSB-ResourceList is the list of SSB-Index values which identify an SS-Block within the SSB burst. We do not see the need to modify the Resource setting.
Observation 7: For L1 measurements based on OD-SSB for the activated SCells, the periodic or semi-persistent reporting may be configured with the OD-SSB that is periodically available once being triggered.
Proposal 13: The MAC CE used for triggering OD-SSB transmission can also be considered as the trigger for the CSI reporting associated with OD-SSB resources.
Observation 8: gNB may configure a dedicated CSI report configuration associated with OD-SSB, if network requires L1 reports based on OD-SSB. 
Proposal 14: RAN1 to discuss if OD-SSB based reporting is required for Case#2, and prioritize a solution that effectively addresses both Case #1 and Case #2.
Observation 9: It is still not clear when and for what purpose the gNB may enable aperiodic reporting for on-demand SSB based measurements.
Proposal 15: RAN1 to discuss and clarify the scenario for utilizing OD-SSB based aperiodic reporting.
Proposal 16: On-demand SSB work is intended to enhance SCell operation, and we propose to keep mobility measurements and LTM out of scope of on-demand SSB.

3GPP TSG RAN WG1 #120	bis                                                                 R1-2501810
Wuhan, China, April 7th – 11th, 2025

Source: 	vivo
Title:	Discussions on on-demand SSB SCell operation
Agenda Item:	9.5.1	
Document for:	Discussion and Decision

Conclusion
This contribution focuses on the discussion of on-demand SSB for SCell with the following observations and proposals: 
Observation 1: RAN4 input on the problem of SSB-less Scell is needed to verify the motivation to support on-demand SSB in SSB-less Scell.
Observation 2: SSB is not used for BFD on Scell in legacy.

Proposal 1: For on-demand SSB SCell operation, do not support Scenario #3B, i.e., on-demand SSB should not be indicated by gNB after SCell activation is complete.
Proposal 2: Do not discuss support of on-demand SSB in SSB-less SCell where reference cell is configured until more RAN4 input is available. 
Proposal 3: Further clarify that the restriction ‘AO-SSB and OD-SSB are located in the same BWP’ means that there only needs to be one BWP within the configured BWPs where both always-on SSB and on-demand SSB are present simultaneously.
Proposal 4: The center frequency gap between always-on SSB and on-demand SSB is smaller than a pre-defined threshold.
Proposal 5: For the case when the center frequency locations of always-on SSB and on-demand SSB are different, other than SFN index, half frame index,  and pdcch-ConfigSIB1 could also be different between always-on SSB and on-demand SSB in PBCH payload for the same SSB index.
Proposal 6：For the case when the center frequency locations of always-on SSB and on-demand SSB are same，the half frame index of AO-SSB and OD-SSB should be same in Alt Time C1 and could be different in Alt Time-C2.
Proposal 7: For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerology, when UE determines time instance A, the SCS to determine the value of T is the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication, i.e. Option 3.
Proposal 8: Option 1 is not applied to Case #1.
Proposal 9: Support Option 4 and 4a for Case #1 in addition to Option 2.
Proposal 10: A nonnumerical indication of N indicates that on-demand SSB transmission is deactivated along with the deactivation of SCell.
Proposal 11: Do not support that the value of N can be implicitly determined using a timer.
Proposal 12: The time offset between always-on SSB and on-demand SSB is not introduced.
Proposal 13: The Parameter, frequency of the on-demand SSB and SSB positions within an on-demand SSB burst could be absent for Case #2 when they are the same as always-on SSB.
Proposal 14: The parameter list could be composed of the following parameters:
Periodicity
SSB positions within an on-demand SSB burst
SFN offset
Half frame index
Number N of on-demand SSB bursts
Proposal 15: For UE to perform L1 measurement based on on-demand SSB when always-on SSB is periodically transmitted on the cell, Option 2, i.e. a CSI report configuration is associated with one of always-on SSB and on-demand SSB, is supported.
Proposal 16: Semi-persistent and aperiodic CSI report configuration can be associated with any kind of on-demand SSB.
Proposal 17: Periodic CSI report configuration can only be associated with on-demand SSB that is activated through RRC signalling and will be deactivated along with the deactivation of SCell.
Proposal 18: Deprioritize the discussion on support of LTM based on OD-SSB before OD-SSB for Scell measurement and activation is finalized.
Proposal 19: To support on-demand SSB operation, prioritize the on-demand SSB transmission if there is collision between on-demand SSB and other transmission.
Proposal 20: Do not support on-demand SSB for BFD on Scell.

3GPP TSG RAN WG1 #120bis		                        R1-2501872
Wuhan, China, 07th – 11th April 2025
Agenda Item:	9.5.1
Source:	Spreadtrum, UNISOC
Title: 	Discussion on on-demand SSB SCell operation
Document for:	Discussion and decision

Conclusion
We have the following observations and proposals.
Whether to define OD-SSB procedure dedicated for Scenario #3B and Case #1/2 depends on termination of OD-SSB.
When UE determines time instance A, the SCS of  is the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for OD-SSB transmission indication.
For OD-SSB deactivation, Option 1 can be used for Scenarios #2 and #2A.
Option 1: Explicit indication of deactivation for on-demand SSB via MAC-CE for on-demand SSB transmission indication
For OD-SSB deactivation Option 2, not support the value of N can be implicitly determined using a timer.
For the case when AO-SSB is CD-SSB and not on a synchronization raster, the frequency location of OD-SSB and AO-SSB subject to network configuration.

3GPP TSG RAN WG1 #120bis		R1-2501952
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.1
Source:	Google
Title:	On-demand SSB for SCell
Document for:	Discussion/Decision

Conclusion
In this contribution, we provided discussion on on-demand SSB for SCell. Based on the discussion, the following proposals are provided.
Proposal 1: For MAC CE based on-demand SSB indication, confirm the first working assumption that T is not less than T_min and revert the second working assumption that T is T_min.
Proposal 2: Support the MAC CE based on-demand SSB indication for SCell to provide the following information in addition to the periodicity of the on-demand SSB:
SCell index
Activation/deactivation status for each on-demand SSB for the SCell
The value of the action delay T
Proposal 3: Support option 2 below to determine the SCS for the action delay for MAC CE based OD-SSB indication
Option 2: the minimum of “the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication” and “the SCS of the active DL BWP where UE receives on-demand SSB”
Proposal 4: The following parameters can be absent for OD-SSB for Case #2 
Frequency of the on-demand SSB
If absent, its value is the same as the always-on SSB
SSB positions within an on-demand SSB burst 
If absent, its value is the same as the always-on SSB
Proposal 5: Clarify whether the network can configure the on-demand SSB for the neighbor cell when inter-cell mTRP or LTM is configured
Proposal 6: For non-UE dedicated signals, the rate matching pattern should be based on the activated SSBs.
Proposal 7: For UE-dedicated signals, the rate matching pattern should be based on SSB configured in ssb-positionInBurst.
Proposal 8: Support to configure the on-demand SSB for RLM/BFD/CBD.
Proposal 9: For L1-RSRP/L1-SINR report based on on-demand SSB, support the UE to report the SSBRI based on the activated SSBs.
Proposal 10: Support to dynamically activate/deactivate the CSI report configuration with on-demand SSB configured.
Proposal 11: Support the on-demand SSB based L1-RSRP measurement and report for LTM
Proposal 12: When always-on SSB and on-demand SSB are in the same serving cell with different central carrier frequency, SS/PBCH blocks with the same SSB indexes for always-on SSB and on-demand SSB are quasi co-located with respect to Doppler spread, Doppler shift, average gain, average delay, delay spread, and when applicable, spatial RX parameters

3GPP TSG RAN WG1 #120bis                                                                           R1-2501996
Wuhan, China, April 7th – 11th, 2025

Source:	CATT
Title:	Discussion on on-demand SSB SCell operation
Agenda Item:	9.5.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss on-demand SSB SCell operation, and give the following observations and proposals:
Observation 1: In the current system, after UE receives SCell activation command, for a known SCell, UE acquires SSB for fine time tracking. For an unknown SCell, UE acquires SSB to perform AGC, synchronization and L1 measurement report.
Observation 2: Since the new MAC CE for OD-SSB transmission indication and the legacy MAC CE for SCell activation/deactivation are two independent MAC CEs, the gNB can trigger OD-SSB when needed via the new MAC CE, irrespective of the timing relationship with SCell activation/deactivation.
Observation 3: In order to support scenario 2A, the new MAC CE for OD-SSB transmission indication and the legacy MAC CE for SCell activation/deactivation can be sent together in one PDSCH.
Observation 4: The motivation of supporting OD-SSB for CD-SSB located on sync-raster is not clear.
Proposal 1: Regarding the relation in terms of periodicity between always-on SSB and OD-SSB, the periodicity of on-demand SSB should be equal to or smaller than that of always-on SSB.
Proposal 2: For the case when the center frequency locations of always-on SSB and on-demand SSB are the same, half frame index should be the same for AO-SSB and OD-SSB.
Proposal 3: For the case when the center frequency locations of always-on SSB and on-demand SSB are different, it is up to the gNB implementation whether PBCH payload for the same SSB index (other than SFN index, half frame index) is the same or different for AO-SSB and OD-SSB.
Proposal 4: There is no need to introduce additional conditions for the following Alt 1 in the agreement in RAN1#120:
Alt 1: If always-on SSB is CD-SSB on a synchronization raster, the frequency location of on-demand SSB is different from the frequency location of always-on SSB.
On-demand SSB is not on sync raster
AO-SSB and OD-SSB are located in the same BWP
Subject to separate UE capability
Note: UE is not required to measure both AO-SSB and OD-SSB
Proposal 5: RAN1 should clarify the meaning of the note: UE is not required to measure both AO-SSB and OD-SSB in the agreement in RAN1#120.
Possible meaning Alt-1: the UE is not required to measure both AO-SSB and OD-SSB after UE received RRC or MAC CE based signaling indicating OD-SSB transmission.
Possible meaning Alt-2: the UE is not required to measure both AO-SSB and OD-SSB during the actual transmission of OD-SSB.
Proposal 6: The following Alt A in the agreement in RAN1#119 should be supported.
Alt A: If always-on SSB is CD-SSB and not on a synchronization raster, the frequency location of on-demand SSB can be same or different from the frequency location of always-on SSB, subject to its configuration. 
Proposal 7: Regarding the spatial relation between the always-on SSB and OD-SSB, it is up to the gNB implementation whether SSB indices within the on-demand SSB burst are a subset of or not a subset of the SSB indices within always-on SSB burst.
Proposal 8: For the identified scenarios and cases (as per RAN1#116-bis agreements), on-demand SSB can be triggered by gNB for the following scenarios/cases:
Scenario #3B and Case #1
Scenario #3B and Case #2
Proposal 9: It is up to gNB implementation when OD-SSB is triggered, irrespective of the timing relationship with SCell activation/deactivation.
Proposal 10: Deprioritize the discussion of additional support of OD-SSB for CD-SSB located on sync-raster in Rel-19.
Proposal 11: A unified group-common DCI could be designed to indicate on-demand SSB transmission.
Proposal 12: Deactivation for on-demand SSB via MAC-CE can be applied for all scenarios/cases.
Proposal 13: Deactivation for on-demand SSB via MAC-CE could also be applied to Option 2 (Configuration/indication of the number N of on-demand SSB bursts to be transmitted after on-demand SSB is indicated).
Proposal 14: In addition to Option 2, support the following options: 
Option 4: On-demand SSB transmission, if any, is deactivated when UE receives SCell deactivation MAC-CE for the activated SCell.
Option 4A: On-demand SSB transmission, if any, is deactivated when the timer for SCell deactivation is expired.
Proposal 15: More than one on-demand SSB configurations can be configured for the cell to UE.
Proposal 16: Besides periodicity, for the following parameters, multiple candidate values can also be configured by RRC:
Number N of on-demand SSB bursts to be transmitted.
SSB positions within an on-demand SSB burst.
Proposal 17: For the 5ms periodicity case, the time domain information of on-demand SSB should be revised. One possible solution is to ignore the parameter half frame index.
Proposal 18: For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerologies, the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication is used to determine the value of T (Option 1).
Proposal 19: The approach used to define time instance A for MAC-CE activation could be reused for determining time instance B for MAC-CE deactivation. 
Proposal 20: Deprioritize the discussion of LTM based on on-demand SSB in Rel-19.
Proposal 21: Consider two candidate solutions to add on-demand SSB resource configuration to existing CSI resource configuration.
Alt-1: The existing IE CSI-ResourceConfig should include the on-demand SSB resource configuration information.
Alt-2: A new dedicated resource configuration IE for on-demand SSB resource configuration should be introduced, e.g. CSI-ResourceConfig-NES.
Proposal 22: Consider two candidate solutions to add on-demand SSB reporting configuration to existing CSI reporting configuration.
Alt-1: The existing IE CSI-ReportConfig should include the on-demand SSB reporting configuration information.
Alt-2: A new dedicated reporting configuration IE for on-demand SSB reporting configuration should be introduced, e.g. CSI-ReportConfig-NES.
Proposal 23: For a cell supporting OD-SSB SCell operation and for Case #2, both the following options should be supported for UE to perform L1 measurement based on OD-SSB:
Option 1: A CSI report configuration is associated with both of OD-SSB and always-on SSB.
Option 2: A CSI report configuration is associated with one of always-on SSB and OD-SSB.
Proposal 24: In order to support both the two options in the agreement in RAN1#118-bis using a single CSI-ReportConfig IE, the reporting configuration for AO-SSB and OD-SSB in the CSI-ReportConfig IE should be optional.
Proposal 25: It is up to gNB implementation whether OD-SSB and always-on SSB have same beam or not.
Proposal 26: Consider two candidate solutions to activate and deactivate semi-persistent L1 measurement reporting on PUCCH for on-demand SSB.
Alt-1: The existing SP CSI reporting on PUCCH Activation/Deactivation MAC CE should include the activation and deactivation of SP CSI reporting on PUCCH for on-demand SSB, e.g., one of the reserved bits can be used to indicate whether the MAC CE applies to SP CSI reporting on PUCCH Activation/Deactivation for on-demand SSB or not.
Alt-2: A new dedicated MAC CE should be introduced for activation and deactivation of semi-persistent L1 measurement reporting on PUCCH for on-demand SSB.
Proposal 27: Consider two candidate solutions to trigger semi-persistent L1 measurement reporting on PUSCH for on-demand SSB.
Alt-1: The existing DCI field CSI request is reused to trigger semi-persistent L1 measurement reporting on PUSCH for on-demand SSB, and the existing DCI field Transform precoding indicator is used to indicate the DCI is used to trigger semi-persistent L1 measurement reporting on PUSCH for on-demand SSB, or for legacy MIMO/LTM.
Alt-2: A new dedicated RNTI (e.g., OD-SSB-SP-Reporting-RNTI) for DCI format 0_1 and 0_2 should be introduced for triggering of semi-persistent L1 measurement reporting on PUSCH for on-demand SSB.
Proposal 28: Consider two candidate solutions to support the semi-persistent L1 measurement reporting on PUSCH for multiple on-demand SSBs from multiple SCells.
Alt-1: The existing IE CSI-SemiPersistentOnPUSCH-TriggerState should include multiple CSI-ReportConfigIds. Each CSI-ReportConfigId is associated with one on-demand SSB resource configuration information.
Alt-2: A new dedicated trigger state IE for on-demand SSB should be introduced, e.g. CSI-SemiPersistentOnPUSCH-TriggerState-NES.
Proposal 29: Consider the following solution to trigger aperiodic L1 measurement reporting on PUSCH for on-demand SSB.
A new dedicated RNTI (e.g., OD-SSB-Aperiodic-Reporting-RNTI) for DCI format 0_1 and 0_2 should be introduced for triggering of aperiodic L1 measurement reporting on PUSCH for on-demand SSB.
Proposal 30: Both Mux-Case #1 and Mux-Case #2 in the agreement in RAN1#118-bis should be supported in Rel-19.
If always-on SSB and on-demand SSB overlap in both time domain and frequency domain, always-on SSB should be prioritized over on-demand SSB to avoid the collision between always-on SSB and on-demand SSB.
Proposal 31: Rate-matching issue needs to consider on-demand SSB transmission of both serving cell and neighboring cell.

3GPP TSG RAN WG1 #120-bis          					                R1-2502010
Wuhan, China, April 7th – 11, 2025
Source:	Tejas Networks Ltd
Title:	On demand SSB SCell operation for NES
Agenda item:	9.5.1	
Document for:	Discussion and Decision

Conclusions

 For the case when the centre frequency locations of always-on SSB(AO-SSB) and on-demand SSB(OD-SSB) are same, half frame index can be same or different for AO-SSB and OD-SSB.

 For the case when the center frequency locations of always-on SSB and on-demand SSB are different, the PBCH payload for AO-SSB and OD-SSB can be same or different.

Support Option 1: the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication.

Supporting option 2: A CSI report configuration is associated with one of always-on SSB and on-demand SSB.

Supporting Mux-Case #1: No time-domain overlap between always-on SSB and on-demand SSB.

Collision handling of OD-SSB with other channels should be discussed.

3GPP TSG RAN WG1 #120bis		R1-2502026
Wuhan, China, Apr 7th – 11th, 2025
Agenda Item:	9.5.1
Source:	China Telecom
Title:	Discussion on on-demand SSB operation for SCell 
Document for:	Discussion and Decision

Conclusion
In this paper, we discuss on-demand SSB operation and have the following observations and proposals.
Observation 1: The indication signal for supporting Scenario #3B and Case #1 is also needed for Scenario #2/#2A.
Observation 2: There is no benefit to support DCI based initial indication for on-demand compared with RRC/MAC CE based signalling for scenario #2 and #2A.
Observation 3: For the re-indication of on-demand SSB for SCell operation, DCI based signalling can be more beneficial with high efficiency.
Observation 4: OD-SSB and always-on SSB transmitted close to each other in time domain should also be avoided to save energy. 
Observation 5: There is no need to configure/update the parameters already configured with RRC configuration for on-demand SSB in Info-Set 2 in the MAC CE indication.

Proposal 1: Scenario #3B and Case #1 for on-demand SSB for SCell operation should be supported in Rel-19.
Proposal 2: Support Scenario #3B and Case #2 for on-demand SSB for SCell operation.
Proposal 3: Support DCI based signalling for on-demand SSB indication if scenario #3B is supported.
Proposal 4: There should be no on-demand SSB and always-on SSB transmitted within a specific time period so that the largest NES gain can be acquired. 
The AO-SSB should be terminated to transmit when such situation happens.
Proposal 5: For OD-SSB Case #2, frequency of the on-demand SSB and SSB positions within an on-demand SSB can be absent, the value of the absent parameters is the same as that of AO-SSB.
Proposal 6: Only support periodicity of the on-demand SSB and SSB positions within an on-demand SSB burst to be configured as a list.
The default value of the parameters can be further discussed.
Proposal 7: For the RRC-indicated on-demand SSB, there should be only one value of RRC configurations for on-demand SSB.
Proposal 8: Not support the parameters in Info-Set 1 to be carried in the MAC CE signalling for on-demand SSB transmission indication.
Proposal 9: Only index of on-demand SSB config and parameters related to the deactivation of on-demand SSB should be carried by MAC CE signalling for on-demand SSB indication, i.e., number of SSB bursts and deactivation of OD-SSB.
Proposal 10: For the deactivation of on-demand SSB, Option 1, i.e., Explicit indication of deactivation for on-demand SSB via MAC-CE, can be applied to all the scenarios. 
Proposal 11: For the deactivation of on-demand SSB, Option 4 and 4A, i.e., the deactivation of SCell, can be sued as the deactivation signal in addition to Option 2. 
Proposal 12: For the deactivation of on-demand SSB, there is no need to further support to indicate value of N can be implicitly using a timer for Option 2. 
Proposal 13: For a cell supporting on-demand SSB SCell operation and for Case #2, CSI report configuration can be associated with both of n-demand SSB and always-on SSB or only with on-demand SSB.

3GPP TSG RAN WG1 #120bis	R1-2502044
Wuhan, China, April 7th – April 11th, 2025

Agenda item:		9.5.1
Source:				Ofinno
Title:					Discussion on on-demand SSB SCell operation
Document for:		Discussion and Decision

Conclusion
This contribution has discussed the remaining issues related to the on-demand SSB SCell operation. The following are our proposals: 
Proposal 1: RAN1 to agree “The periodicity of OD-SSB is equal to or smaller than that of AO-SSB in Case #2”.
Proposal 2: For the case when frequency locations of AO-SSB and OD-SSB are the same, the half frame index can be the same or different for AO-SSB and OD-SSB.
Proposal 3: For the case when frequency locations of AO-SSB and OD-SSB are different, PBCH payload for the same SSB index (other than SFN index, half frame index) does not have to be the same for AO-SSB and OD-SSB.
Proposal 4: We propose the following changes to the previous agreement as follows:
Regarding the relation in terms of frequency location (i.e., center frequency) between the always-on SSB and on-demand SSB,
Alt 1: If always-on SSB is CD-SSB on a synchronization raster, the frequency location of on-demand SSB is different from the frequency location of always-on SSB.
On-demand SSB is not on sync raster
Active AO-SSB and OD-SSB are located in an active the same BWP
OD-SSB is NCD-SSB
FFS: Additional conditions
Subject to separate UE capability
Note: UE is not required to measure both AO-SSB and OD-SSB
Proposal 5: Other potential conditions are left for RAN4 to decide, e.g., intra-frequency measurement.
Proposal 6: OD-SSB transmission is supported in Scenario # 3B and Case # 1, and in Scenario # 3B and Case # 2.
Proposal 7: There is no strong motivation to support OD-SSB for CD-SSB is located on sync-raster. If supported, then proper restriction should be studied to minimize the impact on the UE initial cell search.
Proposal 8: Deactivation of OD-SSB via MAC-CE (Option 1) is supported in all the scenarios in supported for OD-SSB.
Proposal 9: Support Option 4/4a.
Proposal 10: Option 3, Option 5 and Option 6 are not supported.
Proposal 11: The time offset between OD-SSB and AO-SSB is indicated by using similar parameter (e.g., ssb-TimeOffset) used for indicating the time offset between CD-SSB and the NCD-SSB.
Proposal 12: All the agreed list of the parameters are included in the OD-SSB configuration.
Proposal 13: The frequency of the OD-SSB (i.e., od-ssb-absoluteFrequency) and the SSB positions within the OD-SSB burst (i.e., od-ssb-PositionsInBurst) can be absent in Case #2.
Proposal 14: We support that the configuration of the OD-SSB is cell specific.
Proposal 15: For the case where an SCell with on demand SSB transmission and cell with signaling transmission have different numerology, when UE determines time instance A, Option 1 for the SCS used to determine the value of T is adopted.
Proposal 16: The UE expects that OD-SSB is not transmitted T_min slots from the slot receiving the MAC CE for deactivating on-demand SSB. The definition of T_min slots is reused from the definition of T_min slots agreed for indicating the time instance A.
Proposal 17: A CSI report configuration associated with both OD-SSB and AO-SSB is supported. 
Proposal 18: A CSI report configuration associated with OD-SSB or AO-SSB is supported. 
Proposal 19: Periodic, aperiodic and semi-persistent reporting of the L1 measurements on OD-SSB are supported.
Proposal 20: When OD-SSB is deactivated while a semi-persistent reporting based on OD-SSB is not being deactivated, study the following options:
The UE falls back to AO-SSB for semi-persistent reporting (e.g., for case 2 where AO-SSB are configured).
The UE suspends/deactivates the semi-persistent reporting (e.g., for case 1 where AO-SSB are not configured), same as defined for BWP switching in the current standard.
Proposal 21: The beam failure detection (BFD) based on OD-SSB is supported in Case # 1 and Case # 2.
Proposal 22: The candidate beam detection (CBD) based on OD-SSB is supported in Case # 1 and Case # 2.
Proposal 23: The UE does not expect that the OD-SSB is transmitted when OD-SSB overlaps with AO-SSB in time and frequency domains.
Proposal 24: Rate matching on OD-SSB should consider active OD-SSB transmission for the UE, potential OD-SSB transmission to other UE(s), and optionally non-serving cell.
Proposal 25: Further discuss how to handle uplink transmission (e.g., PRACH, Msg A PUSCH) with OD-SSB
Proposal 26: TCI state/PL-RS: in case TCI state has OD-SSB as RS source, how to address when OD-SSB is deactivated.
Proposal 27: RAN1 to discuss whether the OD-SSB can be used as a PL-RS/QCL RS and associated with a TCI state.
Proposal 28: RAN1 to discuss whether to use OD-SSB for pathloss fallback in the case of using OD-SSB for time and frequency synchronization of the SCell.

3GPP TSG RAN WG1 #120bis			R1-2502092
Wuhan, China, April 7th – 11th, 2025

Agenda item:	9.5.1
Source:	KT Corp.
Title:	Discussion on on-demand SSB SCell operation
Document for:	Discussion and decision


1. 

Conclusion
We give our proposals in this contribution as follows:

Proposal 1: Proposal #4-1 in [2] is supported, i.e., for a cell supporting on-demand SSB SCell operation, explicit indication of deactivation for on-demand SSB via MAC-CE for on-demand SSB transmission indication is supported for all scenarios/cases.

Proposal 2: Support DCI based signalling to indicate on-demand SSB transmission on the cell with group-common DCI.

Proposal 3: A CSI report configuration is NOT associated with both of on-demand SSB and always-on SSB.

Proposal 4: Proposal #7-2 in [2] is supported, i.e., for a cell supporting on-demand SSB SCell operation and for L1 measurement based on on-demand SSB,
For on-demand SSB indicated by RRC,
Periodic, semi-persistent, and aperiodic CSI report are supported.
For on-demand SSB indicated by MAC-CE,
Semi-persistent and aperiodic CSI report are supported.
Periodic CSI report is not supported.

Proposal 5: Support beam failure based on on-demand SSB for both Case #1 and Case #2.

Proposal 6: Proposal #9-1 in [2] is supported, i.e., for a cell supporting on-demand SSB SCell operation, support the following rate-matching behavior.
Rate-matching for PDSCH around on-demand SSB is applied from time instance A when UE receives on-demand SSB activation signalling.

Proposal 7: OD-SSB has less priority of transmission than the previously configured periodic signals, like RACH and CSI-RS.

Proposal 8: Consider the inter-operatible RRC configuration for the periodicity and positions in burst for on-demand-SSB with always-on-SSB.

Proposal 9: Adaptation of period is supported for on-demand SSB.


5. 

3GPP TSG RAN WG1 #120bis	R1- 2502127
Wuhan, China, April 17th – 11th, 2025
Agenda Item:	9.5.1
Source: 	Fujitsu
Title:	Discussion on on-demand SSB SCell operation
Document for:	Discussion/Decision

Conclusions
In this contribution, we discussed on-demand SSB for SCell. The following observations and proposals are provided.
Proposal 1: For the case where the center frequency locations of AO-SSB and OD-SSB are same, half frame index can be the same or different for AO-SSB and OD-SSB.
Proposal 2: When the center frequency locations of AO-SSB and OD-SSB are different, the PBCH payload for the same SSB index may be different for AO-SSB and OD-SSB.
Proposal 3: Regarding the scenario(s) at which Option 1 (explicit deactivation indication for on-demand SSB via MAC-CE) is used, at least support the following scenario
Case#1: the scenario when/after the SCell deactivation is completed. 
Case#2: all SCell activation/deactivation scenarios 
Proposal 4: Regarding option 2 (configuration/indication of the number of N for on-demand SSB bursts to be transmitted)
Do not support using SCell deactivation MAC CE (option 4) and/or SCell deactivation timer (option 4A) as implicit indication for on-demand SSB deactivation.
Support implicit determination of the value of N based on a timer which is provided by on-demand SSB configuration.
Proposal 5: Regarding the SCS to determine the value of T, support option 3, i.e., the SCS of the active UL BWP where the UE transmits HARQ-ACK information corresponding to the MAC-CE for on-demand SSB transmission indication.
Proposal 6: Indicating time offset between always-on SSB and on-demand SSB (e.g., similar to ssb-TimeOffset) is not supported.
Proposal 7: 
Regarding the frequency of the on-demand SSB, 
This parameter should be present if its value is different from that of always-on SSB, e.g., when always-on SSB is CD-SSB on sync-raster. Otherwise, it can be absent.
Regarding SSB positions within an on-demand SSB burst,
This parameter should be present if its value is different from that of always-on SSB, e.g., if SSB indices within on-demand SSB burst are a subset of SSB indices within always-on SSB burst. Otherwise, it can be absent. 
Proposal 8：For on-demand SSB configuration, at least the following should be a list:
Periodicity of on-demand SSB 
Number N of on-demand SSB bursts 
Proposal 9: Configure a list of parameter sets within on-demand SSB configuration with each set representing a combination for periodicity of on-demand SSB and number N of on-demand SSB bursts. The gNB can indicate one of combinations via MAC CE. 
Proposal 10: RAN1 to consider either one or both options of CSI report configuration:
If both SSBs have the same or similar properties except time domain location, both option 1 and option 2 can be supported.
Otherwise, only option 2 can be supported.
Proposal 11: 
For option 1 where a CSI report configuration is associated with both on-demand SSB and always-on SSB, the following solutions for CSI resource configuration can be considered:
The existing CSI resource configuration is re-interpreted to indicate both on-demand SSB and always-on SSB.
The CSI resource configuration enhancement is introduced to differentiate on-demand SSB and always-on SSB.
For Option 2 where a CSI report configuration is associated with one of on-demand SSB and always-on SSB, the following solution for CSI resource configuration can be considered:
 The CSI resource configuration enhancement is introduced to differentiate on-demand SSB and always-on SSB.
Proposal 12: For CSI resource configuration enhancement for on-demand SSB associated with CSI report configuration, the following two options can be considered. 
Option A: CSI resource enhancement at the level of the resource set list
 To specify a dedicated resource set list for on-demand SSB.
Option B: CSI resource enhancement at the level of CSI-SSB resource set
To introduce an on-demand SSB indicator within the CSI-SSB-ResoureSet.
Proposal 13: If a newly defined resource set parameter, e.g., CSI-OD-SSB-ResourceSet, is supported, the corresponding enhancement in the aperiodic trigger state list should be considered as well.
E.g., CSI-OD-SSB-ResourceSet should be included in CSI-AperiodicTriggerStateList.
Proposal 14: Regarding L1 measurement based on on-demand SSB,
For RRC based on-demand SSB,
If Number N of on-demand SSB bursts (a positive integer) is configured, 
Semi-persistent and aperiodic CSI report are supported.
Periodic CSI report is not supported.
If Number N of on-demand SSB bursts is not configured,
Periodic, semi-persistent, and aperiodic CSI report are supported.
For MAC-CE based on-demand SSB,
Semi-persistent and aperiodic CSI report are supported.
Periodic CSI report is not supported.
Observation 1: In the existing spec on SCell, only periodic CSI-RS can be configured for beam failure detection purposes, while either SSB or periodic CSI-RS can be configured for beam failure recovery.
Proposal 15: At least support candidate beam selection based on on-demand SSB in Case#1.

3GPP TSG RAN WG1 #120-bis																      R1-2502164
Wuhan, China, April 7th–11th, 2025

Source: 	CMCC
Title:	Discussion on on-demand SSB SCell operation
Agenda item:	9.5.1
Document for:	Discussion & Decision

Conclusion
In this contribution, we discussed the applicable scenario, indication method and L1 measurement of on-demand SSB in SCell for connected UEs, and the following proposals are made.
Proposal 1: On-demand SSB SCell operation in Scenario #3B and Case #1/Case #2 can be supported.

Proposal 2: For on-demand SSB SCell operation in Scenario #3B, DCI 2_9 and/or UE-specific DCI can be considered to indicate on-demand SSB on NES SCell.

Proposal 3: For Case 2, the following parameters can be absent for Case 2.
Frequency of the on-demand SSB
SSB positions within an on-demand SSB burst

Proposal 4: When SCell with on demand SSB transmission and PCell with MAC CE transmission have different numerology, the SCS to determine the value of T is the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication.

Proposal 5: For a cell supporting on-demand SSB SCell operation, option 4 and 4A are not supported to deactivate on-demand SSB transmission.
Option 4: On-demand SSB transmission, if any, is deactivated when UE receives SCell deactivation MAC-CE for the activated SCell
Option 4A: On-demand SSB transmission, if any, is deactivated when the timer for SCell deactivation is expired

Proposal 6: The case where always-on SSB is CD-SSB and not on a synchronization raster is not supported.

Proposal 7: When the center frequency locations of AO-SSB and OD-SSB are same, there is no need to restrict the half frame index to be same or different.

Proposal 8: When the center frequency locations of AO-SSB and OD-SSB are different, there is no need to restrict the PBCH payload for the same SSB index (other than SFN index, half frame index) to be same or different.

Proposal 9: Update the previous RAN1 agreement as follows.
At least support L1 measurement based on on-demand SSB 
For L1 measurement based on on-demand SSB, periodic, semi-persistent, [and aperiodic] L1 measurement reports based on existing CSI framework are supported.
FFS on potential enhancements of CSI report configuration and/or triggering/activation mechanisms for L1 measurement based on on-demand SSB
The support of LTM is a separate discussion point

Proposal 10: For Case 2, when both always-on SSB and on-demand SSB are transmitted, L1 measurement is at least based on on-demand SSB. Whether L1 measurement can be based on both always-on SSB and on-demand SSB is up to RAN4 discussion.

Proposal 11: For Case 2, both of the following options are considered for L1 measurement based on on-demand SSB.
Option 1: A CSI report configuration is associated with both of on-demand SSB and always-on SSB
Option 2: A CSI report configuration is associated with one of always-on SSB and on-demand SSB 

Proposal 12: For Case 2, with CSI report configuration Option 1, two alternatives are considered for the association of CSI report configuration and SSB.
Alt 1: separate resource set are configured for always-on SSB and on-demand SSB, different resource set is associated with different reporting periodicity
Alt 2: one resource set is associated with always-on SSB or on-demand SSB implicitly, different SSB is associated with different reporting periodicity

Proposal 13: The collision of on-demand SSB and DL/UL signals needs further discussion.

3GPP TSG RAN1#120bis Meeting	R1-2502198
Wuhan, China, April 7th – 11th, 2025
Agenda item:	9.5.1
Source:	NEC
Title:	Discussion on on-demand SSB for SCell operation
Document for:	Discussion 

Conclusion
From the discussion, we have the following proposals:
Observation 1: For Scenario #3B and Case#2, on-demand SSB transmission can improve the beam management performance for an activated SCell when the always-on SSB is transmitted with longer periodicity.
Proposal 1: Support on-demand SSB operation for Scenario #3B Case #1 and Scenario #3B Case#2. 
Observation 2: For Case#1, gNB does not need to newly trigger on-demand SSB for a UE if the SCell is already active for another UE (FFS: indication).
Observation 3: For Case#1, on-demand SSB is not expected to be deactivated as long as at least one UE is active on the Cell even when the SCell is deactivated for a UE for which the network triggered the on-demand SSB.
Observation 4: On-demand SSB would be transmitted periodically for a while as long as at least one UE is active on the cell, as SCell is a capacity cell and traffic on the capacity cell would not be low.
Proposal 2: When on-demand SSB is transmitting periodically, NES cell can be used as an SCell for non-NES UEs irrespective of whether on-demand SSB is CD-SSB.
Proposal 3: At least for case#1, on-demand SSB can be CD-SSB and transmitted on synch-raster with assumption the network ensures periodic CD-SSB transmission when the NES cell is activated for any UE.
Observation 5: Legacy UEs, connected to an NES cell, may show unpredictable behaviour and potential synchronization loss if on-demand SSB share the same frequency as always-on SSBs.

Proposal 4: Support Alt A: If always-on SSB provides a CORESET for Type0-PDCCH CSS set  but is not on a synchronization raster, the frequency location of on-demand SSB can be same or different from the frequency location of always-on SSB, subject to its configuration.
Proposal 5: Support on-demand SSB indication via group-common DCI for Scenario#2 and Scenario#3.
Proposal 6: On-demand SSB for SCell may be enabled via DCI format 1_x on PCell with a carrier indication field to indicate the applicable carrier.
Proposal 7: Support Option 4 or Option 4A in addition: On-demand SSB transmission, is deactivated when UE receives SCell deactivation MAC-CE for the activated SCell or when the timer for SCell deactivation is expired.
Proposal 8: For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerology, when UE determines time instance A, the SCS to determine the value of T is selected as
Option 1: the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication
Proposal 9: For Case#2, when on-demand SSB and always-on SSB overlap in time domain, consider always-on SSB is given higher priority than on-demand SCell SSB request. 
Proposal 10: For Case#1 and Case#2, within a time window, combine multiple on-demand SSB transmissions due to multiple on-demand SSB requests into one in order to maximize network energy saving.
Proposal 11: Support Option 2: A CSI report configuration is associated with one of always-on SSB and on-demand SSB.
Proposal 12: The on-demand SSB indication shall be provided to the UE before the start of the corresponding CSI report transmissions.
Proposal 13: Before SCell activation, gNB to indicate one of on-demand SSB or always-on SSB for all configured periodic SSB measurements.
Proposal 14: After SCell activation, only aperiodic on-demand SSB measurements are supported for NES SCell operation.
Proposal 15: For aperiodic CSI reporting based on on-demand SSB consider one of the following options:
-Option-1: Support group-common based DCI indication for on-demand SSB indication
-Option-2: Support indication of on-demand SSB within the CSI report trigger indication
Proposal 16: Discuss other cases (e.g. RACH initiation upon TAT expiry) for which on-demand SSB transmission may be required. 
Proposal 17: Discuss the UE behaviour for the case of failure to receive or detect the on-demand SSB. The following options can be considered: 
- On-demand SSB failure indication may be sent to the network.
-UE can reinitiate the on demand SSB procedure by sending the UE request for on-demand SSB
Proposal 18: RAN1 to discuss UE behaviour on PDSCH rate matching around on-demand SSB.
Proposal 19: Frequency of on-demand SSB and SSB positions within an on-demand SSB burst can be absent from the od-ssb-config for Case#2 when they have the same values as always-on SSB.
Proposal 20: Following parameters can be provided as a list within the od-ssb-config, where one of the values is selected within the MAC CE indication of start of on-demand SSB.
Periodicity of the on-demand SSB (i.e., od-ssb-Periodicity)
SSB positions within an on-demand SSB burst by using signaling similar to ssb-PositionsInBurst (i.e., od-ssb-PositionsInBurst)
Number N of on-demand SSB bursts to be transmitted after on-demand SSB is indicated (i.e., od-ssb-nrofTx)

3GPP TSG-RAN WG1 Meeting #120bis	R1-2502229 
Wuhan, China, April 7 – 11, 2025
 
Agenda Item:	9.5.1
Source:	Huawei, HiSilicon
Title:	On-demand SSB SCell operation for eNES
Document for:	Discussion and Decision

Conclusion
This paper discussed how to design on-demand SSB operation for SCell, with the following proposals:
For the case when the centre frequency locations of AO-SSB and OD-SSB are same, half frame indices for AO-SSB and OD-SSB can be configured to be same or different.
For the case when the centre frequency locations of AO-SSB and OD-SSB are different, PBCH payload for the same SSB index (other than SFN index, half frame index) can be same or different for AO-SSB and OD-SSB. FFS scenarios and benefits if PBCH payload of OD-SSB is known to the UE by configuration. 
Introduce priority-based rules for collision handling between OD-SSB and AO-SSB.
When AO-SSB and OD-SSB are on a same frequency, AO-SSB is prioritized over OD-SSB when collision happens. 
At least when the UE is not required (or not configured) to measure both OD-SSB and AO-SSB, the configuration of SSB indices within OD-SSB burst can be independent with SSB indices within AO-SSB burst i.e., ssb-PositionsInBurst of OD-SSB can be separately configured.
The QCL relationship between SS/PBCH blocks with the same SSB indexes of AO-SSB and OD-SSB can be configured by RRC, at least for the case when the centre frequency locations of AO-SSB and OD-SSB are not the same.
No specification complication is needed regarding which specific scenario(s) the OD-SSB deactivation MAC-CE can or cannot be sent upon. 
For Option 2, support that the value of N can be implicitly determined using a timer, and this OD-SSB deactivation timer is to set the maximum expected transmission window of OD-SSB bursts after on-demand SSB is indicated.
For the deactivation of OD-SSB on an SCell, further support:
Option 4. OD-SSB transmission, if any, is deactivated when UE receives SCell deactivation MAC-CE for the activated SCell.
Option 4A. OD-SSB transmission, if any, is deactivated when the timer for SCell deactivation is expired.
Support that multiple candidate values can be configured for each of the below parameters:
Frequency
Periodicity
The expiry timer for OD-SSB
SSB positions within a burst
The exact design is up to RAN2.  
Support Option 3, i.e., the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication.
Further discuss whether legacy rate matching framework is sufficient for OD-SSB operation.

3GPP TSG RAN WG1 #120bis		R1-2502261
Wuhan, China, April 7th - 11th, 2025 

Source:	OPPO
Title:	Discussion on the enhancement to support on demand SSB SCell operation
Agenda Item:	9.5.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on OD-SSB SCell operation for Rel-19 NES. The following proposals are listed.
Proposal 1: Support Option 4A and Option 5 in addition to Option 2 for deactivation of OD-SSB transmission.
Proposal 2: Support the value of N being implicitly determined using a timer. 
Proposal 3: For case #1, all of the above parameters should be included in the list of od-ssb-config except for PCID and number N which can be optionally configured.
Proposal 4: For case #2, all of the above parameters can be optionally included in the list of od-ssb-config. 
Proposal 5: Support GC-PDCCH for OD-SSB indication for Scenario #2.
Proposal 6: Support the same half frame index for always-on SSB and OD-SSB for the case when the center frequency locations of always-on SSB and OD-SSB are same.
Proposal 7: PBCH payload for the same SSB index (other than SFN index, half frame index) can be different for always-on SSB and OD-SSB for the case when the center frequency locations of always-on SSB and OD-SSB are different. 
Proposal 8: Support Option 2 (A CSI report configuration is associated with one of always-on SSB and on-demand SSB) for L1 measurement based on OD-SSB.
Proposal 9: Support SSB indexes within OD-SSB burst being subset of SSB indexes within always-on SSB burst.
Proposal 10: Support using the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication to determine time instance A.

3GPP TSG RAN WG1 #120bis		                                       R1-2502334 
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.1
Source:	InterDigital Inc.
Title:	Discussion on on-demand SSB SCell operation
Document for:	Discussion 

Conclusion
In this contribution, the following observations are made:
Observation 1: Since the SCell can be transitioned to NES mode after SCell activation is completed, triggering OD-SSB transmission can be beneficial to improve synchronization, timing reference and AGC at the UE, especially when last AO-SSB transmission is outdated. 
The following proposals are made:
Proposal 1: Support on-demand SSB transmission in Scenario #3B at least for Case #2
Proposal 2: For the case when the center frequency locations of AO-SSB and OD-SSB are different, no restriction on the PBCH payload for the same SSB index to be the same for both AO-SSB and OD-SSB
Proposal 3: For Case #2 OD-SSB SCell operation, a time offset parameter for indicating an offset between AO-SSB and OD-SSB bursts is not supported  
Proposal 4: Support explicit indication of deactivation for OD-SSB via MAC-CE for all supported scenarios
Proposal 5: Deactivation of OD-SSB when receiving SCell deactivation (Option 4) or expiry of SCell deactivation timer (Option 4A) are not supported 
Proposal 6: An additional timer for implicitly determining the value of N for the number of OD-SSB bursts is not introduced  
Proposal 7: Indication of the number N of OD-SSB bursts is not supported in the MAC CE for OD-SSB  
Proposal 8: Support a CSI report configuration that is associated with 
one of OD-SSB and AO-SSB (Option 1) when the SSBs are configured with different parameters (e.g. different center frequency location), or 
both OD-SSB and AO-SSB (Option 2) when the SSBs are configured with same parameters (e.g. same center frequency, same SSB positions in bursts)

Proposal 9: Support configuring the same set of beams when both OD-SSB and AO-SSB are configured for L1 measurements  
Appendix: Agreements on OD-SSB SCell operation
RAN1#120 Agreements

RAN1#119 Agreements

RAN1#118bis Agreements

RAN1#118 Agreements

RAN1#117 Agreements
RAN1#116bis Agreements

RAN1#116 Agreements

3GPP TSG RAN WG1 #120bis		R1-2502372
Wuhan, Hubei, China, April 7th – 11th, 2025
Agenda item:	9.5.1
Source:	Samsung
Title:	On-demand SSB SCell operation
Document for:	Discussion and Decision

Conclusion
The proposals from this contribution are summarized below: 
Proposal 1: The indication of activating/deactivating on-demand SSB transmission by RRC and/or MAC CE shall be in a group of UEs manner.
Send an LS to RAN2.
RAN1 can revisit the need of group common DCI format based indication of on-demand SSB if such indication cannot be achieved by RAN2 design.
Proposal 2: For time instance A, the SCS to determine the value of T is by Option 3: 
Option 3: the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication.

Proposal 3: For deactivation of on-demand SSB, other than Option 1A to be discussed in RAN2, there is no need to support additional options in addition to Option 1 and Option 2. 
For Option 1, the time instance B corresponds to the end of the slot containing the last actually transmitted SSB within the first “possible” on-demand SSB burst which is at least T slots after the slot where UE receives the MAC CE.

Proposal 4: For the case when the center frequency locations of always-on SSB and on-demand SSB are same: 
Do not support other cases than “PBCH payload for the same SSB index (other than SFN index, half frame index) is the same for always-on SSB and on-demand SSB”;
When always-on SSB and on-demand SSB are configured to transmit in the same candidate SSB occasion, it is up to gNB implementation to choose one of them for actual transmission, and the UE does not need to distinguish always-on SSB and on-demand SSB since they are the same. 
Proposal 5: For the case when the center frequency locations of always-on SSB and on-demand SSB are different: 
On-demand SSB is a NCD-SSB;
No need to restrict “PBCH payload for the same SSB index (other than SFN index, half frame index) is the same for always-on SSB and on-demand SSB”. 

Proposal 6: For Case 2 (i.e., with always-on SSB), the resource and reporting configuration for L1 measurement can be associated with the cell ID and SSB index, without differentiating the resource is an always-on SSB or on-demand SSB.
How to select resource to perform L1 measurement is up to RAN4. 
Proposal 7: For L1 measurement based on on-demand SSB: 
Before on-demand SSB is indicated to be transmitted, the UE is not required to perform L1 measurement or CSI reporting even though it receives the configuration on L1 measurement and reporting; 
When on-demand SSB is indicated to be transmitted in Scenario #2, the UE can be required to perform CSI reporting in Scenario #2. 

3GPP TSG RAN WG1 #120bis                                	R1-2502403
Wuhan, China, April 7th – 11th, 2025	
	
Agenda item:	9.5.1
Source: 	Sharp
Title: 	Discussion on remaining details of on-demand SSB operation on SCell
Document for:	Discussion

Conclusions
Based on the discussion, we have the following observation and proposals:
Support Scenario 3B and at least Case #1 for on-demand SSB for SCell operation.
Support L3 measurement based on OD-SSB for SCell operation in Scenario 3B and Case #1.
RAN1 to study whether and how to support OD-SSB-based L1 measurement in scenario 3B, taking BWP aspects into account.
For L1 measurement based on on-demand SSB, both Option 1 and Option 2 shall be supported depending on different deployment scenarios.
For L1 measurement based on on-demand SSB, if Option 1 is supported, the report periodicity for OD-SSB based measurement is introduced within the CSI report configuration that is associated with both OD-SSB and always-on SSB.
For L1 measurement based on on-demand SSB, regardless of Option 1 or Option 2, multiple report periodicities for OD-SSB based measurement are introduced within the CSI report configuration that is associated with OD-SSB.
OD-SSB based BFD is supported for both Case 1 and Case 2.
Support that OD-SSB can be CD-SSB located on sync raster.

3GPP TSG RAN WG1 #120bis		                      R1- 2502445
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.1
Source:	Xiaomi 
Title:                     Discussion on on-demand SSB SCell operation
Document for:	Decision

Conclusion

In this contribution, we discussed the procedures and signallings to support on-demand SSB and the impacts of on-demand SSB on UE behaviours were analysed. The proposes are summarized as following:

Proposal 1: On-demand SSB can be CD-SSB located on sync-raster.
Proposal 2: On-demand SSB can be triggered by gNB for the following scenario/cases wherein gNB explicitly indicates UE whether SSB is on or off:
Scenario #3B and Case #1
Scenario #3B and Case #2
Proposal 3: For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerology, when UE determines time instance A, option 3 is adopted to determine the value of T.
Option 3: the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication
Proposal 4: Upon the reception of MAC CE for deactivating on-demand SSB, UE expects that on-demand SSB is NOT transmitted after time instance B.
Time instance B is the first slot after slot , where slot n+m is the slot indicated for PUCCH transmission with HARQ-ACK information when the UE receives MAC CE signalling to indicate deactivation of OD-SSB transmission in slot n, and  is as defined in current specification. The SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for deactivating on-demand SSB is used to determine the SCS of m and  for time instance B.
Proposal 5: For other cases other than the following case, support RRC based signaling to indicate on-demand SSB transmission.
This RRC also configures the SCell, activates the SCell, and provides on-demand SSB configuration.
Proposal 6: For a SCell supporting on-demand SSB operation, Option 1 can be used to deactivate on-demand SSB transmission in scenario 2, 2A and 3B. 
Proposal 7: For a SCell supporting on-demand SSB operation, Option 4, 4A are not supported. 
Option 4: On-demand SSB transmission, if any, is deactivated when UE receives SCell deactivation MAC-CE for the activated SCell
Option 4A: On-demand SSB transmission, if any, is deactivated when the timer for SCell deactivation is expired
Proposal 8: For the parameters of OD-SSB configuration, the following principles are adopted. 

Proposal 9: For Case#2, time offset between AO-SSB and OD-SSB can be used to determine the time domain location of OD-SSB. 
Proposal 10: For Case#2, the periodicity of on-demand SSB should be equal to or smaller than that of always-on SSB.
Proposal 11: For AO-SSB and OD-SSB with same SSB index, SFN index and half frame index can be same or different. In addition, the ssb-SubcarrierOffset can also be same or different for OD-SSB and AO-SSB if their centre frequency are different. 
Proposal 12: When the centre frequency locations of always-on SSB and OD-SSB are different, SS/PBCH blocks with the same SSB indexes for always-on SSB and on-demand SSB are quasi co-located.
Proposal 13: SSB indices within on-demand SSB burst can be subset or same as that set of SSB indices within always-on SSB burst, which is subject to its configuration.
Proposal 14: UE should preclude measurement result associated to a SSB which is turned off by gNB.
Proposal 15: For a cell supporting on-demand SSB SCell operation and for Case #2 (i.e., Always-on SSB is periodically transmitted on the cell), both option 1 and option 2 are supported for UE to perform L1 measurement.
Option 1: A CSI report configuration is associated with both of on-demand SSB and always-on SSB
Option 2: A CSI report configuration is associated with one of always-on SSB and on-demand SSB 
Proposal 16: Beam failure detection based on OD-SSB is not supported for Case #1 and Case #2.
Proposal 17: Beam failure recovery based on OD-SSB is supported for both Case #1 and Case #2.
Proposal 18: PDSCH is rate-matched around OD-SSB when OD-SSB is transmitted.

3GPP TSG RAN WG1 #120bis			                 R1-2502478
China, Wuhan, April 7th – April 11st, 2025

Agenda Item:	9.5.1
Source: 	LG Electronics
Title: 	On-demand SSB SCell operation
Document for:	Discussion and decision

Conclusions

In this contribution, on-demand SSB SCell operation for NES was discussed, and the followings were proposed.

Proposal #1: Support on-demand SSB configuration per BWP similar to NCD-SSB configured with the higher layer parameter nonCellDefiningSSB. 

Proposal #2: In addition to agreed scenarios and cases, on-demand SSB can be indicated by gNB at least for the following scenarios/cases.
Scenario #3B and Case #1
Scenario #3B and Case #2

Proposal #3: Discuss how to handle the case that on-demand SSB is indicated in Scenario #3A.

Proposal #4: Consider the infinite/non-numerical value as one of candidate N values. 
If a UE is configured/indicated with this infinite/non-numerical value for N, the UE expects continuous and periodic transmission of on-demand SSB.

Proposal #5: When on-demand SSB transmission is indicated by a RRC, UE expects that the value of N is NOT provided by the RRC or provided but set to infinite (or non-numerical) value.  
The on-demand SSB activated by RRC signaling can be deactivated by applying Option 1 (Explicit indication of deactivation for on-demand SSB via MAC-CE for on-demand SSB transmission indication) and cannot be deactivated by applying Option 2 (Configuration/indication of the number N of on-demand SSB bursts to be transmitted after on-demand SSB is indicated). 

Proposal #6: Adopt Alt A.
Alt A: If always-on SSB is CD-SSB and not on a synchronization raster, the frequency location of on-demand SSB can be same or different from the frequency location of always-on SSB, subject to its configuration.

Proposal #7: For Case #2, support Alt B (i.e., Based on a single parameter which is to indicate the time offset between always-on SSB and on-demand SSB (e.g., similar to ssb-TimeOffset)), in addition to Alt A (i.e., Based on two parameters, where one is to indicate SFN offset from a reference point and the other is to indicate half frame index). 
If the single parameter (e.g., od-ssb-TimeOffset) is NOT configured, 
UE assumes Alt. A.

Proposal #8: The SCS for the value of T is the minimum of “the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication”, “the SCS of the (active) DL BWP where UE receives on-demand SSB” and “the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication”. 

Proposal #9: If a UE receives MAC CE in slot n for deactivating on-demand SSB via MAC-CE, the UE expects that on-demand SSB is not transmitted after slot n+Y.
Further discuss the value of Y. 

Proposal #10: When on-demand SSB and always-on SSB overlap both in time domain and frequency domain, on-demand SSB is dropped.  

Proposal #11: Support more than one on-demand SSB configurations that are provided by RRC signalling. 
One index of multiple on-demand SSB configurations is indicated by signaling for on-demand SSB transmission indication.
One on-demand SSB configuration includes a set of the following parameters for which multiple candidate values can be configured by RRC and the applicable value can be indicated by MAC CE for on-demand SSB transmission indication
On-demand SSB periodicity
Time domain location (i.e., SFN offset and half frame index for Case #1 and offset between always-on SSB and on-demand SSB for Case #2) of on-demand SSB burst
SSB positions within an on-demand SSB burst

Proposal #12: In MAC CE which indicates/activates on-demand SSB, the number N of on-demand SSSB bursts to be transmitted is indicated directly and separately from the index of on-demand SSB configuration

Proposal #13: For a cell supporting on-demand SSB SCell operation and for Case #2 (i.e., Always-on SSB is periodically transmitted on the cell), take Option 2 (i.e., A CSI report configuration is associated with one of always-on SSB and on-demand SSB) as the baseline for CSI report configuration for L1 measurement. 

Proposal #14: Discuss the relationship between the frequency position of on-demand SSB and the frequency range of the first active BWP given by the higher layer parameter firstActiveDownlinkBWP-Id.  

Proposal #15: Discuss UE behaviour to perform the measurement/report based on on-demand SSB after the on-demand SSB is deactivated.

Proposal #16: Discuss how to utilize SSB transmitted after on-demand SSB procedure, for the purposes of time/frequency synchronization, path-loss estimation, QCL reference signal, beam failure, and so on.

Proposal #17: Discuss how UE performs RACH occasion validation, PDCCH monitoring, and DL/UL signals/channels reception/transmission, if the SSB transmission can be (de)activated based on on-demand SSB procedure.

3GPP TSG RAN WG1 Meeting #120bis			    			             R1-2502513
Wuhan, China, April 7th – 11th, 2025

Source:	ETRI
Title:		Discussion on On-demand SSB SCell operation
Agenda item:	9.5.1
Document for:	Discussion/Decision

Summary
In this contribution, we made the following proposals on on-demand SSB SCell operation.

Scenarios for on-demand SSB SCell operation
Proposal 1: It is proposed not to support on-demand SSB transmission in Scenario 3B.
Proposal 2: It is proposed that a separate indication dedicated to triggering on-demand SSB transmission should not be introduced.

Time/Frequency/Spatial relation between always-on SSB and on-demand SSB
Proposal 3: Regarding whether on-demand SSB is cell-defining or not, additional support of CD-SSB located on sync-raster as OD-SSB is not necessary.
Proposal 4: It is proposed not to impose any restriction requiring the half frame index of on-demand SSB to be the same as that of always-on SSB when their center frequency locations are the same.
Proposal 5: It is proposed not to require the PBCH payload to be identical between always-on SSB and on-demand SSB when they are transmitted at different frequency locations.
Proposal 6: It is proposed that when a conflict occurs due to overlapping of always-on SSB and on-demand SSB in both time and frequency domains, the network should prioritize the transmission of the always-on SSB and drop the on-demand SSB.
Proposal 7: It is proposed not to support the case where the SSB indices within on-demand SSB burst are a subset of those within always-on SSB burst.

Signaling of on-demand SSB operation Contents of on-demand SSB configuration/indication
Proposal 8: It is proposed not to support DCI-based indication for indicating on-demand SSB transmission.
Proposal 9: It is proposed to configure od-ssb-absoluteFrequency even for Case #2 where always-on SSB is periodically transmitted on the cell.
Proposal 10: It is proposed that the parameter od-ssb-PositionsInBurst should not be configured for Case #2 separately.
Proposal 11: It is proposed to introduce an explicit indication to inform the UE that the existing configuration for always-on SSB in SCell configuration is not valid in Case #1.

Signaling methods for on-demand SSB TX indication
Proposal 12: It is proposed to support Option 2 as the default operation and Option 1 as supplementary mechanism for Option 2.
Option 1 is supported when the number of N for on-demand SSB bursts is not configured.
Proposal 13: It is not necessary to support Option 4, 4A in addition to Option 2.
Proposal 14: For Option 2, it is not necessary to use timer instead of the number of N.
Proposal 15: For Option 2, it is proposed to include the value of N for on-demand SSB bursts in the on-demand SSB configuration information.

TX behavior of on-demand SSB burst
Proposal 16: It is proposed to confirm the working assumptions on Time instance A for MAC CE-based signaling according to RAN4 LS reply.
Proposal 17: It is proposed to support Option 3, where the SCS for calculating Time instance A is based on the active UL BWP where the UE transmits the HARQ-ACK corresponding to the MAC-CE for on-demand SSB transmission indication.

Measurement based on on-demand SSB
Proposal 18: It is proposed to support both options for CSI report configuration depending on the multiplexing behavior between always-on SSB and on-demand SSB.
Option 1: A CSI report configuration is associated with both of on-demand SSB and always-on SSB
Option 2: A CSI report configuration is associated with one of always-on SSB and on-demand SSB 

3GPP TSG RAN WG1 #120bis		                        R1-2502542
Wuhan, China, April 7th -11th, 2025
Source: 	Transsion Holdings
Title:	Discussion on on-demand SSB SCell operation
Agenda item:	9.5.1
Document for:	Discussion & Decision

Conclusions
In this contribution,some views about on-demand SSB SCell operation are discussed, and the following proposals are made.
Proposal 1  Scenarios 3B and Case #1 and Scenario #3B and Case #2 should be supported.
Proposal 2  On-demand SSB for CD-SSB located on synchronization raster cannot be supported.
Proposal 3  For the case when the center frequency locations of always-on SSB and on-demand SSB are same, the union of AO-SSB transmission and OD-SSB transmission has a periodic time domain pattern should be  supported.
Proposal 4  It is recommended to support Alt C: Do not support the case where always-on SSB is CD-SSB and not on a synchronization raster.
Proposal 5  DCI based signaling to indicate on-demand SSB transmission can be supported.
Proposal 6  If DCI based signaling support on-demand SSB transmission, DCI is UE-specific.
Proposal 7  Option 4, 4A can be used to deactivate on-demand SSB transmission.
Proposal 8  For case #2, using time offset between always-on SSB and on-demand SSB to define time domain location of on-demand SSB should be supported.
Proposal 9  The SCS to determine the value of T should be the subcarrier spacing of the PUCCH for which the UE transmits ACK corresponding to the MAC-CE indicating the on-demand SSB transmission.

3GPP TSG RAN WG1 #120bis	R1-2502569
Wuhan, China, April 7th – 11th, 2025
Agenda item:	9.5.1
Source: 	Lenovo
Title: 	On-demand SSB SCell operation
Document for:	Discussion and Decision

Conclusion
In summary, we have following proposals for on-demand SSB for SCell:
Proposal 1: Support OD-SSB for Scenario #3B at least for Case 2.
Proposal 2: In addition to the agreed RRC and MAC CE based signaling methods, support group common DCI based signalling to indicate on-demand SSB transmission at least for Scenario #2 and Scenario #3B. 
Proposal 3: Option 1 of using explicit indication of deactivation for on-demand SSB can be used for L3 measurement in at least scenario #2 and #3B. 
Proposal 4: From a UE perspective, if deactivation signaling of on-demand SSB is not received, UE can assume on-demand SSB is still available after SCell is deactivated.
Proposal 5: Support the case where SSB indices within on-demand SSB burst can be subset of SSB indices within always-on SSB burst. 

3GPP TSG RAN WG1 #120bis			R1-2502578
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.1
Source:	Panasonic
Title:	Discussion on on-demand SSB SCell operation
Document for:	Discussion/Decision

Conclusion
The following combination of scenarios and cases for indicating OD-SSB are not supported in Rel-19
Scenario #3A and Case #1
Scenario #3A and Case #2
Above does not impact discussion on SSB periodicity adaptation in time domain

Agreement
Regarding the relation in terms of frequency location (i.e., center frequency) between the always-on SSB and on-demand SSB,
Alt 1: If always-on SSB is CD-SSB on a synchronization raster, the frequency location of on-demand SSB is different from the frequency location of always-on SSB.
On-demand SSB is not on sync raster
AO-SSB and OD-SSB are located in the same BWP
FFS: Additional conditions
Subject to separate UE capability
Note: UE is not required to measure both AO-SSB and OD-SSB

Agreement
Regarding the relation in terms of time location between the always-on SSB and on-demand SSB,
For the case when the center frequency locations of always-on SSB and on-demand SSB are same,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
From RAN1 perspective,
Alt Time-C1: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a periodic time domain pattern is supported (the interval between SSB bursts is even and supported in legacy specification).
Alt Time-C2: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a non-periodic time domain pattern is supported.
It is up to RAN4 to define requirements, if any, corresponding to both or either of Alt Time-C1 or Alt Time-C2
At least the following is supported: PBCH payload for the same SSB index (other than SFN index, half frame index) is the same for AO-SSB and OD-SSB 
FFS: Whether half frame index is the same or different for AO-SSB and OD-SSB
For the case when the center frequency locations of always-on SSB and on-demand SSB are different,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
UE assumes that frequency resources of always-on SSB are not overlapped with those of on-demand SSB in frequency domain.
AO-SSB and OD-SSB are located in the same BWP
FFS: PBCH payload for the same SSB index (other than SFN index, half frame index) should be the same for AO-SSB and OD-SSB 
NOTE: AO-SSB periodicity is not adapted
Send an LS to RAN4 to inform them of the above agreement. Final LS in R1-2501633.

Agreement
For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerology, when UE determines time instance A, the SCS to determine the value of T is down selected among the following options
Option 1: the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication
Option 2: the minimum of “the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication” and “the SCS of the active DL BWP where UE receives on-demand SSB”
Option 3: the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication

3GPP TSG RAN WG1 #120bis		R1-2502612
Wuhan, China, April 7th – 11th, 2025


Agenda Item:	9.5.1
Source:	Apple
Title:	On-demand SSB SCell Operation
Document for:	Discussion/Decision
 

Conclusion
The following combination of scenarios and cases for indicating OD-SSB are not supported in Rel-19
Scenario #3A and Case #1
Scenario #3A and Case #2
Above does not impact discussion on SSB periodicity adaptation in time domain

Agreement
Regarding the relation in terms of frequency location (i.e., center frequency) between the always-on SSB and on-demand SSB,
Alt 1: If always-on SSB is CD-SSB on a synchronization raster, the frequency location of on-demand SSB is different from the frequency location of always-on SSB.
On-demand SSB is not on sync raster
AO-SSB and OD-SSB are located in the same BWP
FFS: Additional conditions
Subject to separate UE capability
Note: UE is not required to measure both AO-SSB and OD-SSB

TDoc file reading error

3GPP TSG RAN WG1 #120bis           	                                  R1-2502708
Wuhan, China, April 7th – 11th, 2025
Agenda Item: 9.5.1
Source: MediaTek Inc.
Title: On-demand SSB SCell operation
Document for: Discussion and decision

Conclusion
In this contribution, we focus on the discussions of on-demand SSB SCell operation and have the following proposals: 

Proposal 1: When there is always-on SSB transmitted in the cell, use "SFN offset" and "half frame index" to indicate the time domain position of on-demand SSB. No need to indicate time offset between always-on SSB and on-demand SSB.

Proposal 2: At least ssb-SubcarrierOffset (k_ssb, see Fig. 1) inside MIB would be different for AO-SSB and OD-SSB when center frequency locations of always-on SSB and on-demand SSB are different.

3GPP TSG RAN WG1 #120bis			R1- 2502770
Wuhan, China, April 7th – 11st, 2025

Source:	NTT DOCOMO, INC.
Title:	Discussion on on-demand SSB SCell operation
Agenda Item:	9.5.1
Document for: 	Discussion and Decision

Conclusions
In this contribution, we provided the following observations and proposals of on-demand SSB SCell operation for network energy saving.
Proposal 1:
Support OD-SSB for CD-SSB located on sync-raster. 
Proposal 2:
Support, half frame index can be the same or different for AO-SSB and OD-SSB. It is up to NW implementation.
Proposal 3:
In terms of the content of PBCH payload for both OD-SSB and AO-SSB with same or different center frequency,
We do not support the restriction that the PBCH payload for the same SSB index (other than SFN index, half frame index) should be the same for AO-SSB and OD-SSB
E.g., the value of PDCCHConfig-SIB1, k_ssb and cell barring information can be different. 
Proposal 4:
When AO-SSB is CD-SSB, 
No additional condition should be added to the Alt. 1
We support Alt. A for the case when
OD-SSB and AO-SSB are located on the same frequency.
OD-SSB and AO-SSB are not located on the same frequency with the restriction that UE does not require to do RF tuning.
Observation 1: 
It seems unclear which combinations b/w AO and OD-SSB are supported when AO-SSB is NCD-SSB in case #2.
Proposal 5:
Support the following combinations when AO-SSB is NCD-SSB in case #2.
Table. 1 combination for the case when AO-SSB is NCD-SSB
Same restriction that was already agreed for the case of Alt. 1 should be applied to the supported combinations.
Proposal 6:
For the applicable SSB-index arrangements for OD-SSB in case #2, we support at least following options.
Option 1: The set of SSB indices of AO-SSB and those of OD-SSB are identical. 
Option 2: The set of SSB indices of OD-SSB becomes a subset of the set of SSB indices of AO-SSB. 
Proposal 7:
For the spatial relationship between AO-SSB and OD-SSB,
When AO-SSB and OD-SSB have the same center frequency, support the QCL assumption for the same SSB-index regardless of whether the SSB indices within OD-SSB burst are identical to those within AO-SSB or not.
When AO-SSB and OD-SSB do not have the same center frequency, QCL assumption should not always be assumed.
Study whether/how to use OD-SSB as QCL source RS on behalf of/in addition to AO-SSB in case #1 and case #2.
Proposal 8:
For each OD-SSB parameters, support following to be a list
SSB positions within a burst, periodicity, time location, Number N of OD-SSB bursts to be transmitted
Proposal 9:
For each parameter in OD-SSB, 
Support all the parameters can be absent. When each parameter is absent, legacy SSB parameter should be referred.
Proposal 10:
For determination of the number/duration of OD-SSB bursts, we support the following mechanism:
The candidate values of OD-SSB TX duration are RRC-configured, integer multiple of SMTC periodicity
Error cases handling should be specified (e.g., performance degradation in RAN4, UE assumption of no-deactivation in RAN1 or RAN2) in deactivation of OD-SSB which is being measurement.
Proposal 11:
Support at least MAC CE based OD-SSB transmission indication in scenario #3B and case #1 and case #2.
Proposal 12:
For OD-SSB periodicity adaptation,
Support OD-SSB periodicity adaptation in both case #1/#2.
Group-common DCI (agreed in agenda 9.5.3) can be a starting point.
Proposal 13:
For MAC-CE deactivation indication, support all the scenarios and cases.
In addition to the above, we support option 4/4a.
Proposal 14:
For the case when OD-SSB transmissions and cell with signaling transmissions have different numerology, 
Support option 3 for SCS determination related to T 
Proposal 15:
In terms of CSI report configuration for L1 measurement,
We support both option 1 and option 2, which option to use is up to NW implementation. 
For option 1, when OD-SSB transmission is indicated, L1 meas. should be done using both AO-SSB and OD-SSB.
For option 2, it is useful to fix one to one association b/w CSI report config and either AO or OD-SSB when SSB properties (e.g., SSB TX power) are different b/w AO and OD-SSB.
Observation 2:
In order for NW to know which configured SCell and beam is best to be activated with minimizing NW TX, L1 meas. based on OD-SSB is beneficial.
Proposal 16:
Support L1 meas. based on OD-SSB in scenario #2/case #1 by reusing the existing LTM mechanism.
Proposal 17:
Study restriction on time domain behavior of OD-SSB and L1 reporting
It can be considered to follow the legacy CSI framework, e.g., Periodic L1 meas. should be as-sociated with periodic on-demand SSB only.
FFS: relationship of indication signaling and time domain behavior of OD-SSB for L1 measurement.

TDoc file reading error

3GPP TSG-RAN WG1 Meeting #120-bis	Tdoc R1-2502802 
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.5.1
Source:	Ericsson 
Title:	On-demand SSB SCell operation
Document for:	Discussion

1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	The functionality of Option 4 can be realized by Option 1 if a MAC CE that deactivates the on-demand SSB can also deactivate the SCell.
Observation 2	The functionality of Option 4A can be realized by Option 2 if the on-demand-SSB transmission is restarted when the SCell deactivation timer is restarted.
Observation 3	Each on-demand SSB MAC CE indication is for the monitoring behavior of a specific UE, what that specific UE can expect. The actual gNB transmission of on-demand SSBs may be more often than what is indicated to that UE.
Observation 4	NW can save energy by transmitting on-demand SSB only in the direction(s) of the configured UE(s).
Observation 5	From a functional perspective, the OD-SSB frequency is not necessary for Case #2 since it is the same frequency as the always-on SSB.
Observation 6	From a functional perspective, the OD-SSB positions in burst can be absent in scenarios where the SSB indices within on-demand SSB burst are identical to SSB indices within always-on SSB burst.
Observation 7	If an always-on SSB burst collides with an on-demand SSB burst, all SSBs in the always-on SSB burst must be transmitted to not confuse legacy UEs.

Based on the discussion in the previous sections we propose the following:
Proposal 1	Support Option 1 for both deactivated and activated SCells.
Proposal 2	Support restarting or prolonging an on-demand SSB transmission at the same time as the SCell deactivation timer is restarted.
Proposal 3	Support NW providing on-demand SSB transmission indication (i.e., that SSB is turned ON or OFF) and on-demand SSB configuration indication (e.g., SSB periodicity) at the same time.
Proposal 4	An on-demand SSB transmission indication for an SCell (e.g., ON/OFF or parameter change) overrides a potentially ongoing on-demand SSB transmission configuration for that SCell.
Proposal 5	Support adaptation of on-demand SSB periodicity via MAC CE while SCell is in an activated state (Scenario #3B).
Proposal 6	Multiple candidate values of SSB positions in burst can be configured by RRC and the applicable value can be indicated by MAC CE for on-demand SSB transmission indication for the cell.
Proposal 7	On-demand candidate SSB positions in a burst are restricted to legacy candidate SSB positions in a burst.
Proposal 8	Multiple candidate values of number of SSB bursts (or length of timer) can be configured by RRC and the applicable value can be indicated by MAC CE for on-demand SSB transmission indication for the cell.
Proposal 9	It is up to RAN2 whether higher layer parameter for OD-SSB frequency and/or OD-SSB positions in burst can be absent with reference to the corresponding parameters for always-on SSB.
Proposal 10	The network preconfigures the UE with a number M of OD-SSB configurations with RRC signaling. FFS: The maximum value of M.
Proposal 11	None of the following higher layer parameters is a list: od-ssb-absoluteFrequency, od-ssb-PositionsInBurst, od-ssb-Periodicity, od-ssbSubcarrierSpacing, od-ssb-physCellId, od-ssb-sfn-Offset, od-ssb-halfFrameIndex, od-ssb-nrofTx.
Proposal 12	To indicate or adapt OD-SSB transmission, the network indicates the OD-SSB configuration index and SCell index to be applied.
Proposal 13	If an SSB in an on-demand SSB burst fully overlap in frequency and time with an SSB in an always-on SSB burst, then the SSB in the on-demand SSB burst is identical to the corresponding SSB in the always-on SSB burst.
Proposal 14	On-demand SSB positions in burst can be the same or a subset of always-on SSB positions in burst.
Proposal 15	Further discuss collision between on-demand SSB and always-on SSB that are fully overlapping in time but not overlapping or partially overlapping in frequency.
Proposal 16	On-demand SSB burst patterns are restricted to legacy SSB burst patterns.
Proposal 17	A CSI report configuration can be associated with one or both of always-on SSB and on-demand SSB depending on NW configuration.
Proposal 18	Use the SCS of the active UL BWP where the UE transmits ACK to determine the value of T (Option 3).
Proposal 19	Do not support to indicate time offset between always-on SSB and on-demand SSB for Case #2.

3GPP TSG RAN WG1 #120bis			           R1-2502843
Wuhan, China, April 7th – 11th, 2025
Agenda item:	9.5.1
Source: 	Qualcomm Incorporated
Title: 	On-demand SSB operation for Scell
Document for:	Discussion/Decision

Conclusion
The contribution has discussed our views on remaining aspects to support on-demand SSB operation for Scell. In particular, we make the following observations and proposals:
Observation 1: Having on-demand SSB configured as cell-defining SSB has negative impact to both legacy idle/inactive UEs and R19 idle/inactive UEs.
Observation 2: At least for Case #2, the adaptation of SSB burst periodicity via DCI 2_9 in AI 9.5.3 can already achieve the same purpose of DCI based signaling to indicate on-demand SSB transmission.
Observation 3: For Option 2 in Case #1, gNB may not be able to configure the value of N properly to ensure sufficient SSB transmission in activated cell. Therefore, Option 4 or Option 4A should be used in addition to Option 2.

Proposal 1: On-demand SSB for cell defining SSB located on synchronization raster is not supported
Proposal 2: DCI based signaling to indicate on-demand SSB transmission on the cell is not supported.
Proposal 3: For the case when the center frequency locations of always-on SSB and on-demand SSB are same,
For Alt Time C-1, the half-frame index is different for AO-SSB and OD-SSB if the union of AO-SSB transmission and OD-SSB transmission has a periodic time domain pattern of 5ms periodicity. Otherwise, the half-frame index is identical for AO-SSB and OD-SSB.
For Alt Time C-2, the half-frame index may be different for AO-SSB and OD-SSB.
Proposal 4: For the case when the center frequency locations of always-on SSB and on-demand SSB are different, PBCH payload (other than SFN index, half frame index) is the same for AO-SSB and OD-SSB for the same SSB index.
Proposal 5: Support indication of time offset between always-on SSB burst and on-demand SSB burst.
Proposal 6: The case where always-on SSB is CD-SSB that is not on sync raster (Alt. C) is not supported.
Proposal 7: in T is a number of slots per subframe for the SCS configuration  of the PUCCH transmission carrying ACK in responding to reception of PDSCH carrying MAC-CE with OD-SSB transmission indication signaling (i.e., Option 3).
Proposal 8: For MAC-CE based deactivation of OD-SSB transmission in Case #1, the deactivation is only signaled in Scenario 2. The timing of the deactivation is 
Before the time UE receives the Scell activation signaling, or
At the same time or later than the time that UE receives the Scell deactivation signaling or timer for SCell deactivation is expired. 
Proposal 9: For the MAC-CE based deactivation of OD-SSB transmission in Case #2, the deactivation can be signaled in Scenario 2 or Scenario 3B. In particular, the timing of the deactivation is before the time UE receives the Scell activation signaling or after the Scell activation is completed (e.g., after the UE successfully sends the first CSI report).
Proposal 10: For Option 2 in Case #1, UE assumes OD-SSB transmission is deactivated when UE receives SCell deactivation MAC-CE for the activated SCell (Option 4) or the timer for SCell deactivation is expired (Option 4A) if the Nth SSB transmission is after Scell activation completion and before the time UE receives Scell deactivation command or the timer for SCell deactivation is expired.
Proposal 11: Upon the reception of MAC-CE deactivating on-demand SSB transmission, UE assumes that on-demand SSB is not transmitted from time instance B.
Time instance B is the beginning of the first slot containing the first actually transmitted SSB index “possible” on-demand SSB burst which is at least T slots after the slot where UE receives the MAC-CE deactivating on-demand SSB transmission 
The value of T is similar to the value of T defined for time instance A.
Proposal 12: Introduce an RRC parameter to indicate whether Option 1 (MAC-CE based deactivation) or Option 2 (deactivation based on N SSB bursts) is used for determining deactivation of OD-SSB transmission. 
Proposal 13: A CSI report configuration can be associated with one or both of always-on SSB and on-demand SSB. If both on-demand SSB and always-on SSB are configured, it is up to UE implementation on whether the UE measures one of always-on SSB and on-demand SSB or both. 
Proposal 14: For OD-SSB Case #1, the following is considered for PRACH occasion validation rules and SSB-RO mapping rules:
For RRC based indication of OD-SSB transmission, the PRACH occasion validation rules and SSB-RO mapping rules are determined based on OD-SSB configuration in the RRC.
For MAC-CE based indication of OD-SSB transmission, the PRACH occasion validation rules and SSB-RO mapping rules are determined based on OD-SSB configuration in RRC and the latest MAC-CE indicating OD-SSB transmission at or before the time UE receives Scell activation command.
Proposal 15: For OD-SSB Case #2, PRACH occasion validation rules and SSB-RO mapping rules are not impacted by OD-SSB transmission.
Proposal 16: For OD-SSB Scell operation, the UE is not expected to transmit PRACH in a valid PRACH occasion if the occasion precedes a SS/PBCH block in the PRACH slot and does not start at least  symbols after a last SS/PBCH block reception symbol where 
 is provided in Table 8.1-2 of TS 38.213, and 
SS/PBCH block is the SS/PBCH block that is transmitted in response to RRC/MAC-CE based indication of OD-SSB transmission.
Proposal 17: Adopt the following update to Clause 10 of TS 38.213 for PDCCH monitoring.


Proposal 18: Adopt the following update to Clause 5.1.4 of TS 38.214 for PDSCH resource mapping.

Proposal 19: od-ssb-PositionsInBurst to indicate SSB positions within an on-demand SSB burst is based on a full bitmap as provided in ServingCellConfigCommon i.e.,
od-ssb-PositionsInBurst        CHOICE { 
shortBitmap              BIT STRING (SIZE (4)), 
mediumBitmap        BIT STRING (SIZE (8)), 
longBitmap               BIT STRING (SIZE (64))}

3GPP TSG RAN WG1 Meeting #120-bis	                                  R1-2502917
Wuhan , China, April 7th – April 11th, 2025

Agenda Item:	9.5.1
Source:	CEWiT
Title:	Discussion on on-demand SSB Scell operation.
Document for:	Discussion 

Conclusion
In this contribution, we discussed the techniques required for on-demand SSB SCell operation and following proposals are made,
Observation 1: SSB indices within on-demand SSB equal to SSB indices within always-on SSB burst cause unnecessary SSB transmissions in areas with non uniform UE density.
Observation 2: If both AO-SSB and on-demand SSB are configured for L1 measurement, the UE generates a single tracking process to determine SSB locations based on legacy starting symbol indices.
Proposal 1: Support the actual transmitted SSB indices within on-demand SSB burst as a subset of actual transmitted SSB indices within always-on SSB burst.
Observation 3: The indication of the SFN offset and half-frame index is sufficient to determine the time locations of on-demand SSB.
Proposal 2: Indication of time offset between always-on SSB and on-demand SSB is not needed.
Proposal 3: Support both option 1 and option 2 for deactivation of on-demand-SSB.
Observation 4: On-demand SSB impacts the need and validity of periodic RACH occasions and their association with SSBs, requiring adjustments to ensure efficient RRC connection establishment.
Proposal 4: Support handling the impacts of on-demand SSB on RACH occasions for RRC connection establishment.
Observation 5: UE not receiving the SSB after on-demand SSB operation leads to unnecessary monitoring by the UE and negative impacts on performance.
Proposal 5: Support handling of the case where the UE cannot receive SSB after the on-demand SSB operation.

3GPP TSG RAN WG1 #120bis			R1-2503045
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.1
Source: 	Moderator (LG Electronics)
Title: 	Summary #1 of on-demand SSB for NES
Document for:	Discussion and decision

Conclusion
The following combination of scenarios and cases for indicating OD-SSB are not supported in Rel-19
Scenario #3A and Case #1
Scenario #3A and Case #2
Above does not impact discussion on SSB periodicity adaptation in time domain

Agreement
Regarding the relation in terms of frequency location (i.e., center frequency) between the always-on SSB and on-demand SSB,
Alt 1: If always-on SSB is CD-SSB on a synchronization raster, the frequency location of on-demand SSB is different from the frequency location of always-on SSB.
On-demand SSB is not on sync raster
AO-SSB and OD-SSB are located in the same BWP
FFS: Additional conditions
Subject to separate UE capability
Note: UE is not required to measure both AO-SSB and OD-SSB

Agreement
Regarding the relation in terms of time location between the always-on SSB and on-demand SSB,
For the case when the center frequency locations of always-on SSB and on-demand SSB are same,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
From RAN1 perspective,
Alt Time-C1: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a periodic time domain pattern is supported (the interval between SSB bursts is even and supported in legacy specification).
Alt Time-C2: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a non-periodic time domain pattern is supported.
It is up to RAN4 to define requirements, if any, corresponding to both or either of Alt Time-C1 or Alt Time-C2
At least the following is supported: PBCH payload for the same SSB index (other than SFN index, half frame index) is the same for AO-SSB and OD-SSB 
FFS: Whether half frame index is the same or different for AO-SSB and OD-SSB
For the case when the center frequency locations of always-on SSB and on-demand SSB are different,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
UE assumes that frequency resources of always-on SSB are not overlapped with those of on-demand SSB in frequency domain.
AO-SSB and OD-SSB are located in the same BWP
FFS: PBCH payload for the same SSB index (other than SFN index, half frame index) should be the same for AO-SSB and OD-SSB 
NOTE: AO-SSB periodicity is not adapted
Send an LS to RAN4 to inform them of the above agreement. Final LS in R1-2501633.

Agreement
For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerology, when UE determines time instance A, the SCS to determine the value of T is down selected among the following options
Option 1: the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication
Option 2: the minimum of “the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication” and “the SCS of the active DL BWP where UE receives on-demand SSB”
Option 3: the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication

3GPP TSG RAN WG1 #120bis			R1-2503046
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.1
Source: 	Moderator (LG Electronics)
Title: 	Summary #2 of on-demand SSB for NES
Document for:	Discussion and decision

Conclusion
The following combination of scenarios and cases for indicating OD-SSB are not supported in Rel-19
Scenario #3A and Case #1
Scenario #3A and Case #2
Above does not impact discussion on SSB periodicity adaptation in time domain

Agreement
Regarding the relation in terms of frequency location (i.e., center frequency) between the always-on SSB and on-demand SSB,
Alt 1: If always-on SSB is CD-SSB on a synchronization raster, the frequency location of on-demand SSB is different from the frequency location of always-on SSB.
On-demand SSB is not on sync raster
AO-SSB and OD-SSB are located in the same BWP
FFS: Additional conditions
Subject to separate UE capability
Note: UE is not required to measure both AO-SSB and OD-SSB

Agreement
Regarding the relation in terms of time location between the always-on SSB and on-demand SSB,
For the case when the center frequency locations of always-on SSB and on-demand SSB are same,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
From RAN1 perspective,
Alt Time-C1: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a periodic time domain pattern is supported (the interval between SSB bursts is even and supported in legacy specification).
Alt Time-C2: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a non-periodic time domain pattern is supported.
It is up to RAN4 to define requirements, if any, corresponding to both or either of Alt Time-C1 or Alt Time-C2
At least the following is supported: PBCH payload for the same SSB index (other than SFN index, half frame index) is the same for AO-SSB and OD-SSB 
FFS: Whether half frame index is the same or different for AO-SSB and OD-SSB
For the case when the center frequency locations of always-on SSB and on-demand SSB are different,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
UE assumes that frequency resources of always-on SSB are not overlapped with those of on-demand SSB in frequency domain.
AO-SSB and OD-SSB are located in the same BWP
FFS: PBCH payload for the same SSB index (other than SFN index, half frame index) should be the same for AO-SSB and OD-SSB 
NOTE: AO-SSB periodicity is not adapted
Send an LS to RAN4 to inform them of the above agreement. Final LS in R1-2501633.

Agreement
For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerology, when UE determines time instance A, the SCS to determine the value of T is down selected among the following options
Option 1: the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication
Option 2: the minimum of “the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication” and “the SCS of the active DL BWP where UE receives on-demand SSB”
Option 3: the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication

3GPP TSG RAN WG1 #120bis			R1-2503047
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.1
Source: 	Moderator (LG Electronics)
Title: 	Summary #3 of on-demand SSB for NES
Document for:	Discussion and decision

Conclusion
The following combination of scenarios and cases for indicating OD-SSB are not supported in Rel-19
Scenario #3A and Case #1
Scenario #3A and Case #2
Above does not impact discussion on SSB periodicity adaptation in time domain

Agreement
Regarding the relation in terms of frequency location (i.e., center frequency) between the always-on SSB and on-demand SSB,
Alt 1: If always-on SSB is CD-SSB on a synchronization raster, the frequency location of on-demand SSB is different from the frequency location of always-on SSB.
On-demand SSB is not on sync raster
AO-SSB and OD-SSB are located in the same BWP
FFS: Additional conditions
Subject to separate UE capability
Note: UE is not required to measure both AO-SSB and OD-SSB

Agreement
Regarding the relation in terms of time location between the always-on SSB and on-demand SSB,
For the case when the center frequency locations of always-on SSB and on-demand SSB are same,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
From RAN1 perspective,
Alt Time-C1: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a periodic time domain pattern is supported (the interval between SSB bursts is even and supported in legacy specification).
Alt Time-C2: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a non-periodic time domain pattern is supported.
It is up to RAN4 to define requirements, if any, corresponding to both or either of Alt Time-C1 or Alt Time-C2
At least the following is supported: PBCH payload for the same SSB index (other than SFN index, half frame index) is the same for AO-SSB and OD-SSB 
FFS: Whether half frame index is the same or different for AO-SSB and OD-SSB
For the case when the center frequency locations of always-on SSB and on-demand SSB are different,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
UE assumes that frequency resources of always-on SSB are not overlapped with those of on-demand SSB in frequency domain.
AO-SSB and OD-SSB are located in the same BWP
FFS: PBCH payload for the same SSB index (other than SFN index, half frame index) should be the same for AO-SSB and OD-SSB 
NOTE: AO-SSB periodicity is not adapted
Send an LS to RAN4 to inform them of the above agreement. Final LS in R1-2501633.

Agreement
For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerology, when UE determines time instance A, the SCS to determine the value of T is down selected among the following options
Option 1: the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication
Option 2: the minimum of “the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication” and “the SCS of the active DL BWP where UE receives on-demand SSB”
Option 3: the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication

3GPP TSG RAN WG1 #120bis			R1-2503048
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.1
Source: 	Moderator (LG Electronics)
Title: 	Summary #4 of on-demand SSB for NES
Document for:	Discussion and decision

Conclusion
The following combination of scenarios and cases for indicating OD-SSB are not supported in Rel-19
Scenario #3A and Case #1
Scenario #3A and Case #2
Above does not impact discussion on SSB periodicity adaptation in time domain

Agreement
Regarding the relation in terms of frequency location (i.e., center frequency) between the always-on SSB and on-demand SSB,
Alt 1: If always-on SSB is CD-SSB on a synchronization raster, the frequency location of on-demand SSB is different from the frequency location of always-on SSB.
On-demand SSB is not on sync raster
AO-SSB and OD-SSB are located in the same BWP
FFS: Additional conditions
Subject to separate UE capability
Note: UE is not required to measure both AO-SSB and OD-SSB

Agreement
Regarding the relation in terms of time location between the always-on SSB and on-demand SSB,
For the case when the center frequency locations of always-on SSB and on-demand SSB are same,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
From RAN1 perspective,
Alt Time-C1: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a periodic time domain pattern is supported (the interval between SSB bursts is even and supported in legacy specification).
Alt Time-C2: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a non-periodic time domain pattern is supported.
It is up to RAN4 to define requirements, if any, corresponding to both or either of Alt Time-C1 or Alt Time-C2
At least the following is supported: PBCH payload for the same SSB index (other than SFN index, half frame index) is the same for AO-SSB and OD-SSB 
FFS: Whether half frame index is the same or different for AO-SSB and OD-SSB
For the case when the center frequency locations of always-on SSB and on-demand SSB are different,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
UE assumes that frequency resources of always-on SSB are not overlapped with those of on-demand SSB in frequency domain.
AO-SSB and OD-SSB are located in the same BWP
FFS: PBCH payload for the same SSB index (other than SFN index, half frame index) should be the same for AO-SSB and OD-SSB 
NOTE: AO-SSB periodicity is not adapted
Send an LS to RAN4 to inform them of the above agreement. Final LS in R1-2501633.

Agreement
For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerology, when UE determines time instance A, the SCS to determine the value of T is down selected among the following options
Option 1: the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication
Option 2: the minimum of “the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication” and “the SCS of the active DL BWP where UE receives on-demand SSB”
Option 3: the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication

3GPP TSG RAN WG1 #120bis			R1-2503119
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.1
Source: 	Moderator (LG Electronics)
Title: 	Summary #5 of on-demand SSB for NES
Document for:	Discussion and decision

Conclusion
The following combination of scenarios and cases for indicating OD-SSB are not supported in Rel-19
Scenario #3A and Case #1
Scenario #3A and Case #2
Above does not impact discussion on SSB periodicity adaptation in time domain

Agreement
Regarding the relation in terms of frequency location (i.e., center frequency) between the always-on SSB and on-demand SSB,
Alt 1: If always-on SSB is CD-SSB on a synchronization raster, the frequency location of on-demand SSB is different from the frequency location of always-on SSB.
On-demand SSB is not on sync raster
AO-SSB and OD-SSB are located in the same BWP
FFS: Additional conditions
Subject to separate UE capability
Note: UE is not required to measure both AO-SSB and OD-SSB

Agreement
Regarding the relation in terms of time location between the always-on SSB and on-demand SSB,
For the case when the center frequency locations of always-on SSB and on-demand SSB are same,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
From RAN1 perspective,
Alt Time-C1: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a periodic time domain pattern is supported (the interval between SSB bursts is even and supported in legacy specification).
Alt Time-C2: The case that, during OD-SSB transmission, the union of AO-SSB transmission and OD-SSB transmission has a non-periodic time domain pattern is supported.
It is up to RAN4 to define requirements, if any, corresponding to both or either of Alt Time-C1 or Alt Time-C2
At least the following is supported: PBCH payload for the same SSB index (other than SFN index, half frame index) is the same for AO-SSB and OD-SSB 
FFS: Whether half frame index is the same or different for AO-SSB and OD-SSB
For the case when the center frequency locations of always-on SSB and on-demand SSB are different,
Alt Time-C: RAN1 specification has no restriction with regards to overlapping
UE assumes that frequency resources of always-on SSB are not overlapped with those of on-demand SSB in frequency domain.
AO-SSB and OD-SSB are located in the same BWP
FFS: PBCH payload for the same SSB index (other than SFN index, half frame index) should be the same for AO-SSB and OD-SSB 
NOTE: AO-SSB periodicity is not adapted
Send an LS to RAN4 to inform them of the above agreement. Final LS in R1-2501633.

Agreement
For the case where SCell with on demand SSB transmission and cell with signalling transmission have different numerology, when UE determines time instance A, the SCS to determine the value of T is down selected among the following options
Option 1: the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication
Option 2: the minimum of “the SCS of the active DL BWP where UE receives MAC CE for on-demand SSB transmission indication” and “the SCS of the active DL BWP where UE receives on-demand SSB”
Option 3: the SCS of the active UL BWP where the UE transmits ACK corresponding to the MAC-CE for on-demand SSB transmission indication