| R2-2503376 - O1_V10_Clean.docx |
3GPP TSG-RAN2 Meeting#130 R2-2503376
Malta, Malta, May 19th - May 23rd, 2025
Agenda Item: 8.5.2
Source: OPPO
Title: Discussion on On-Demand SSB
Document for: Discussion, Decision
|
Conclusion
Proposal 1 R2 confirmed the feasibility of RRC-based deactivation.
Proposal 2 For 61-3/4/4a, UE relies on RRC to set initial A/D state of OD-SSB, and relies on MAC-CE for subsequent A/D control.
Proposal 3 R2 agree that MAC-CE can be used for SSB periodicity change, i.e., change the periodicity of an OD-SSB that is being transmitted.
Proposal 4 For OD-SSB MAC-CE, when bit for a cell is set to 1, the associated configuration index is present.
Proposal 5 For OD-SSB MAC-CE, when bit for a cell is set to 1, UE always apply the corresponding OD-SSB configuration and restart N counting (if N is configured for the corresponding configuration ID) or stop/re-set N counting (if N is not configured for the corresponding configuration ID) according to the configuration index.
Proposal 6 For OD-SSB MAC-CE, when bit for a cell is set to 0, the associated configuration index is absent, and OD-SSB is deactivated (if not yet).
Proposal 7 For OD-SSB Case#2, for same-frequency scenario between AO-SSB and OD-SSB, R2 firstly conclude the support of L3 measurement configuration based on a single MO. And wait for further conclusion from R4 on whether to support C2.
Proposal 8 For OD-SSB Case#2, R2 further discuss whether to include it in BWP-DownlinkDedicated as well. Other than that, R2 does not pursue multiple OD-SSBs with different frequencies for a given cell.
Proposal 9 For OD-SSB Case#2, for different-frequency scenario between AO-SSB and OD-SSB, R2 confirm to rely on OD-SSB for the measurement when OD-SSB is being transmitted (which is anyway pending R4 decision on whether to support or not).
Proposal 10 For OD-SSB L3 measurement, the setting of ssb-ToMeasure is up to network implementation.
Proposal 11 For L3 measurement of neighbouring cell based on OD-SSB, R2 not pursue further specification work.
Proposal 12 R2 not pursue OD-SSB A/D MAC-CE triggered MR for OD-SSB.
|
| R2-2503392_On-demand SSB SCell Operation.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503392
St.Julians, Malta, May 19th – 23rd , 2025
Agenda item: 8.5.2
Source: Samsung
Title: On-demand SSB SCell Operation
Document for: Discussion and Decision
|
Conclusion
Proposal 1: If the Cj field is set to 1, configuration index is always included in MAC CE for the SCell with ServCellIndex j. Configuration indexes are included in ascending order of j for which Cj bit is set to 1.
Proposal 2: When UE receives MAC CE with Cj bit set to 1 for an SCell for which OD-SSB is currently deactivated:
OD-SSB is activated for the jth SCell and UE applies the OD-SSB configuration corresponding to configuration index included in the MAC CE. In case the OD-SSB configuration indicated by configuration index includes od-ssb- nrofBurst, UE will start timer/counter for implicit deactivation.
Proposal 3: When UE receives MAC CE with Cj bit set to 0 for an SCell for which OD-SSB is currently activated:
OD-SSB is deactivated for the jth SCell, irrespective of whether od-ssb-nrofBurst is included or not included in configuration applied for the activated OD-SSB. Running timer/counter for implicit deactivation (if any) for the SCell is stopped.
Proposal 4: When UE receives MAC CE with Cj bit set to 1 for an SCell for which OD-SSB is currently activated:
if configuration index is different from the configuration index of the configuration currently applied for the activated OD-SSB, UE applies the new configuration based on new configuration index received in MAC CE. Otherwise, do nothing.
References |
| R2-2503407 Remaining issues on OD-SSB SCell operation_final.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503407
Malta, MT, 19th May – 23th May, 2025
Agenda Item : 8.5.2
Source : LG Electronics Inc.
Title : Remaining issues on OD-SSB SCell operation
Document for : Discussion and Decision
1. |
Conclusion
In this contribution, following statements are proposed:
2-1. Details on MAC CE format
Observation 1 When od-ssb-nrofTx is configured, UE considers that OD-SSB transmission is deactivated when network indicates A/D field as 0 regardless of transmitted number of OD-SSB bursts.
Proposal 1 When od-ssb-nrofTx is configured, network should set A/D field as 1 during OD-SSB transmission.
Observation 2 UE cannot distinguish the network’s intention whether maintaining or re-applying OD-SSB configuration indicated via MAC CE when the OD-SSB configuration contains od-ssb-nrofTx.
Proposal 2 Introduce reserved value into additional octet to indicate that UE maintains previous OD-SSB configuration. FFS how to define reserved value.
2-2. OD-SSB measurement
Observation 3 If activated OD-SSB is QCLed with AO-SSB, UE should not perform measurements on AO-SSB.
Proposal 3 UE performs measurements only on OD-SSB when the activated OD-SSB is QCLed with AO-SSB.
Proposal 4 Even if the servingCellMO is configured for the OD-SSB, UE does not derive the SSB based measurement results of the OD-SSB when the OD-SSB transmission is deactivated.
Proposal 5 Introduce SSB-MTC5 in MeasObjectNR associated with the OD-SSB SCell to configure the measurement timing of AO-SSB.
Proposal 6 Introduce SSB-MTC6List in MeasObjectNR associated with the OD-SSB SCell to configure the measurement timing of OD-SSB.
4. |
| R2-2503414 Consideration on on-demand SSB SCell operation.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503414
St Julian, Malta, 19th – 23rd May, 2025
Source: CATT
Title: Consideration on on-demand SSB SCell operation
Agenda Item: 8.5.2
Document for: Discussion and Decision
|
Conclusion
According to the analysis in section 2, our observations and proposals are summarized as follows:
Observation 1: A fast time window is defined by RAN4, during which UE performs the OD-SSB based fast L3 measurements for deactivated SCell within a measurement period associated with the OD-SSB period.
Observation 2: For Case#2, if there is no valid measurement report, after receiving the OD-SSB transmission indication, UE performs the OD-SSB based fast L3 measurement following OD-SSB periodicity for deactivated SCell within a time window.
OD-SSB measurement of Scell
Proposal 1: For a given SCell, multiple OD-SSBs with different frequencies are not allowed.
Proposal 2: For the measurement of OD-SSB, UE determines the set of OD-SSB to be measured based on od-ssb-PositionsInBurst (i.e., not based on ssb-ToMeasure).
Proposal 3: The RRM measurement of OD-SSB is performed based on OD-SSB pattern while ignoring SMTC when OD-SSB is transmitted.
Proposal 4: In order for UE to quickly report measurement results after receiving the OD-SSB transmission indication, a L3 measurement reporting is triggered after the OD-SSB is activated via MAC CE.
OD-SSB measurement of neighbor cell
Proposal 5: OD-SSB SCell operation has no impact to RRM measurement of neighbor cells.
Handling of OD-SSB measurement after SCell deactivation
Proposal 6: After SCell deactivation, UE stops the OD-SSB measurement and considers the OD-SSB as deactivated.
Mixture of explicit and implicit OD-SSB deactivations
Proposal 7a: The following cases are supported for the mixture of explicit and implicit OD-SSB deactivations:
Case 1: The OD-SSB of SCell A configured with implicit OD-SSB deactivation is still in an active state, while the MAC CE activates/deactivates the OD-SSB of other cell(s) (e.g., SCell B)
Case 2: The OD-SSB of SCell A configured with implicit OD-SSB deactivation is already in a deactivated state, while the MAC CE activates/deactivates the OD-SSB of other cell(s) (e.g.,SCell B)
Case 3: The OD-SSB of SCell A configured with implicit OD-SSB deactivation is still in an active state, while the MAC CE deactivates the OD-SSB of SCell A
Case 4: The OD-SSB of SCell A configured with implicit OD-SSB deactivation is still in an active state, while the MAC CE changes the associated configuration index of the OD-SSB of SCell A
Case 5: The OD-SSB of SCell A configured with implicit OD-SSB deactivation is already in a deactivated state, while the MAC CE activates the OD-SSB of SCell A
Proposal 7b: For a SCell configured with implicit OD-SSB deactivation，NW can indicate UE to keep or change the OD-SSB transmission state in the OD-SSB MAC CE.
Proposal 7c: For a SCell configured with implicit OD-SSB deactivation, UE handles the OD-SSB state according to OD-SSB MAC CE if received. Otherwise, UE handles the OD-SSB state according to the implicit OD-SSB deactivation configuration.
Proposal 7d: If a SCell is configured with implicit OD-SSB deactivation and UE receives OD-SSB MAC CE, the UE shall treat the transmission of OD-SSB of the SCell as unchanged if the content of the MAC CE for the SCell (including the configuration index and activation/deactivation state) is the same as the current activated OD-SSB info for the SCell.
|
| R2-2503573 Discussion on on-demand SSB.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503573
Malta, May 19th –23th , 2025
Agenda Item: 8.5.2
Source: Xiaomi
Title: Discussion on on-demand SSB
Document for: Discussion and Decision
1 |
Conclusion
In this contribution, we discussed the procedures and signalling to support on-demand SSB and have corresponding observations and proposals:
MAC-1: Single MAC CE format for both explicit and implicit OD-SSB deactivation
Proposal 1: (MAC-1) it is up to NW implementation to update the associated number N if NW intends to maintain the OD-SSB transmission on the SCell.
Proposal 2: (MAC-1) Each time UE receives a MAC CE indicating the activation of the OD-SSB on a SCell, UE considers it as a new activation and follows the related configuration index/transmission parameters.
Proposal 3: (MAC-1) For both explicit and implicit deactivation, the OD-SSB MAC-CE includes fixed sized bitmap to indicate whether OD-SSB is activated in each SCell (i.e., similar to legacy SCell A/D MAC-CE) with “1” means activation, “0” means deactivation.
Proposal 4: (MAC-1) For both explicit and implicit deactivation, the OD-SSB MAC-CE supports two formats: one format indicates up to 7 SCells and the other format indicates up to 31 SCells.
RRC-1: OD-SSB configuration index
Proposal 5: (RRC-1) The configuration index is associated with a set of parameters, i.e., od-ssb-Periodicity, od-ssb-PositionsInBurst and od-ssb-nrofBurst.
RRC-3: L3 measurement framework
Proposal 6: (RRC-3) For L3 measurement, unified solution as SSB adaptation is adopted for OD-SSB, e.g., additional SMTC configurations are introduced according to different OD-SSB periodicities.
RRC-4: Which MO to use for measurement
Proposal 7: RAN2 to confirm the WA as agreement “When A-SSB and OD-SSB have different center frequency, introduce a new servingCellMO in ServingCellConfig to indicate MO of OD-SSB.”
Proposal 8: (RRC-4) For case#2, when OD-SSB and AO-SSB are on different frequencies, either MO associated with AO-SSB or MO associated with OD-SSB can be used for measurement.
RRC-5: New measurement report trigger
Proposal 9: (RRC-5) No need to trigger measurement report when OD-SSB is activated.
Neighbour cell measurement
Proposal 10: There is no impact on neighbour cell measurement with OD-SSB, e.g., the OD-SSB status of neighbour cell is transparent to UE.
Indication of OD-SSB SCell
Proposal 11: Upon SCell addition, NW indicates whether the SSB transmission on this SCell is on-demand manner via RRC signalling.
4 |
| R2-2503609 - Discussion on on-demand SSB for NES.docx |
3GPP TSG-RAN WG2 #130 R2-2503609
Malta, May 19th– 23rd, 2025
Agenda Item: 8.5.2
Source: Ericsson
Title: Discussion on on-demand SSB for NES
Document for: Discussion, Decision
1 |
Conclusion
Based on the discussion in the previous sections we propose the following:
Proposal 1 Agree to that network can flexibly configure the parameters of each od-ssbConfig. Each od-ssbConfig can be activated/deactivated by the MAC CE. Use TP1 as ASN1 baseline.
Proposal 2 Agree to have A/D field per od-SSBConfig to be activated.
Proposal 3 Agree to have A/D field and corresponding od-SSBConfig field present only when the Ci field has value ‘1’
Proposal 4 Agree the max value of od-ssbconfigurations per SCell to be 8.
Proposal 5 RAN2 to support MAC CE based trigger of serving cell OD-SSB measurement report.
Proposal 6 RAN2 to reconsider the WA and use the existing serving cell measurement object to support the serving cell measurements of OA-SSB and OD-SSB when these are within the same BWP
Proposal 7 RAN2 to confirm that when network transmits both always-on SSB and on-demand SSB there appears to be no RAN2 issues for UEs to combine always-on SSB and OD-SSB or to use only on-demand SSB for SCell activation procedure.
|
| R2-2503710 - Remaining issues on on-demand SSB for SCell.docx |
3GPP TSG RAN WG2 Meeting #130 R2-2503710
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda item: 8.5.2
Source: Apple
Title: Remaining issues on on-demand SSB for SCell
WID/SID: Netw_Energy_NR_enh-Core– Release 19
Document for: Discussion and Decision
1 |
Conclusion
In this contribution, we discuss remaining issues on-demand SSB for SCell. Our observations are:
Observation 1: According to RAN1 agreement, the requirements for MAC-CE on implicit deactivation include:
The UE determines whether implicit deactivation is enabled by checking if od-ssb-nrofBurst is present in the OD-SSB configuration indicated by the configuration index included in the MAC-CE.
RAN1 may support early deactivation via MAC-CE before N transmissions of OD-SSB are ended.
Observation 2: In legacy RRC, the UE is mandated to perform serving cell measurement when servingCellMO is configured (even if no ReportConfigNR is linked with the servingCellMO).
Observation 3: Existing TS 38.331 doesn’t capture the procedure text on L3 measurement on deactivated SCell. Its only specification impact is in field description of measCycleSCell and it refers to TS 38.133.
Observation 4: After completion of SCell activation (i.e. scenario 3B), it is quite similar to L3 measurement of SSB adaptation because MAC-CE can only change transmission parameter of OD-SSB (e.g. periodicity of OD-SSB) but can’t deactivate OD-SSB.
Observation 5: According to online discussion of RAN2#129b, majority supported the WA because another alternative (i.e. frequency of OD-SSB is added in servingCellMO identified by frequency of AO-SSB) will introduce significant specification impacts.
Observation 6: Measurement reporting triggered by OD-SSB MAC-CE will lead to below issues:
The same motivation (i.e. reduce the transition time from unknown SCell to known SCell) can be achieved by legacy measurement reporting triggered by SCell A/D MAC-CE introduced in Rel-18.
OD-SSB MAC CE is expected to be sent earlier than SCell A/D MAC-CE, and it will cause some unpredictable impacts to RAN4 work on the legacy L3 measurement reporting during SCell activation.
Based on above observations, our proposals are:
MAC-CE format
Proposal 1: To support implicit deactivation of OD-SSB, UE re-interprets the bitmap field per SCell (i.e. Ci with SCellIndex i) in the following way:
If Ci=1, the UE regards OD-SSB is activated in the concerned SCell, applies the corresponding OD-SSB configuration indicated in the MAC-CE (i.e. set/reset od-ssb-nrofBurst) and resets counter to 0.
If Ci=0, the UE regards the OD-SSB configuration in the concerned SCell is not changed (i.e. od-ssb-nrofBurst is same as the one indicated by preceding MAC-CE) and continues the counter.
Proposal 2: If RAN1 agree to support early deactivation via MAC-CE before N transmissions of OD-SSB are ended, it is left to NW implementation (e.g., NW sends MAC-CE with Ci=1 and its configuration index points to one configuration with od-ssb-nrofBurst=0).
L3 measurement in NES case 1
Proposal 3: In L3 measurement in OD-SSB case 1, if RRC based activation / deactivation, no specification change is foreseen because NW can de-configure servingCellMO via RRC when the OD-SSB is deactivated.
Proposal 4: In L3 measurement in OD-SSB case 1, if MAC-CE based activation / deactivation, introduce the following RRC specifications changes:
The UE starts L3 measurement towards the activated OD-SSB based on configured servingCellMO after reception of the activation MAC-CE
The UE stops L3 measurements after it determines the OD-SSB is deactivated implicitly or explicitly.
L3 measurement in NES case 2 when AO-SSB and OD-SSB share the same center frequency
Proposal 5: When AO-SSB and OD-SSB share the same center frequency before completion of SCell activation (i.e. scenario 2/2A), RAN2 leave to RAN4 on L3 measurement on deactivated SCell, and RAN2 assume no RAN2 specification impact is foreseen as legacy.
Proposal 6: When AO-SSB and OD-SSB share the same center frequency after completion of SCell activation (i.e. scenario 3B), the same L3 measurement solution of SSB adaptation is reused:
Multiple additional SMTC configurations are configured to UE via RRC, together with the mapping between OD-SSB configuration and SMTC configuration.
Upon reception of OD-SSB MAC-CE, UE selects one SMTC configuration accordingly for L3 measurement on its serving cell(s).
No spec impact on neighbor cell L3 measurement (i.e. based on legacy SMTC).
L3 measurement in NES case 2 when AO-SSB and OD-SSB have different center frequency
Proposal 7: Confirm the WA on MO configuration of OD-SSB when AO-SSB and OD-SSB have different center frequency.
Proposal 8: In running CR drafting, RAN2 assume that up to one OD-SSB with different frequency from AO-SSB can be configured for a given SCell. This assumption can be re-visited if RAN1 make different conclusion.
Proposal 9: The UE applies the new servingCellMO for L3 measurement when OD-SSB is activated. Otherwise (i.e. when OD-SSB is deactivated), the UE applies the legacy servingCellMO for L3 measurement.
Measurement reporting
Proposal 10: RAN2 not pursue measurement reporting triggered by OD-SSB MAC-CE.
4 |
| R2-2503755_Remaining issues of on demand SSB SCell operation.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503755
St Julian, Malta, 19th– 23rd May 2025
Agenda item: 8.5.2
Title: Remaining issues of on demand SSB SCell operation
Source: ZTE Corporation, Sanechips
Document for: Discussion and Decision
|
Conclusion and proposals
Based on the analysis in previous sections, the following observations and proposals are given:
Proposal 1: Based on the latest input from RAN1, the following parameters should be included in RRC signaling for each on demand SSB configuration:
od-ssb-Periodicity
od-ssb-halfFrameIndex
od-ssb-nrofBurst
od-ssb-absoluteFrequency
od-ssb-PositionsInBurst
od-ssbSubcarrierSpacing
od-ssb-physCellId
od-ss-PBCH-BlockPower
Proposal 2: The SCell addition/modification procedure can be reused to provide the on demand SSB configuration, i.e. the on demand SSB parameters for a SCell can be configured when NW adds or modifies a SCell.
Proposal 3: RAN2 make decision on the maximum number of OD-SSB configuration for each SCell, e.g. 2 or 4, which will decide the size of the configuration index in the on demand SSB MAC CE.
Proposal 4: Clarify the following understanding on explicit activation:
For case#1, the OD-SSB configuration is activated for a SCell when the corresponding bit is set to 1.
For case#2, two options can be considered and need to down select:
Option 1: Switch from always-on SSB to OD-SSB is activated when the corresponding bit is set to 1.
Option 2: OD-SSB is activated in addition to always-on SSB when the corresponding bit is set to 1.
Proposal 5: Clarify the following understanding on explicit deactivation:
For case#1, the OD-SSB configuration is deactivated for a SCell when the corresponding bit is set to 0.
For case#2, UE switch back to always-on SSB when the corresponding bit is set to 0.
Proposal 6: Unified design for explicit activation/deactivation and implicit deactivation and clarify the expected UE behavior:
Scenario 1: No further configuration or activation is provided from NW after N OD-SSB bursts have been transmitted from NW and monitored by UE:
For case#1, UE stop monitor OD-SSB if no further configuration or activation is provided from NW.
For case#2, UE switch back to always-on SSB if no further configuration or activation is provided from NW.
Scenario 2: Another activation via MAC CE with a new N for the same SCell before the old N OD-SSB bursts have been transmitted from NW and monitored by UE:
UE stop counting towards the old N and re-start counting towards the new N for both case#1 and case#2.
Scenario 3: Another activation via MAC CE without N for the same SCell before N OD-SSB bursts have been transmitted from NW and monitored by UE:
UE stop counting towards N and follow the latest activation.
Scenario 4: Deactivation via MAC CE for the same SCell before N OD-SSB bursts have been transmitted from NW and monitored by UE:
UE stop counting towards N and deactivate the on demand SSB immediately.
Proposal 7: RAN2 preference is to keep SMTC based L3 RRM framework and to introduce additional SMTC configuration according to the OD-SSB for L3 RRM measurement on OD-SSB SCell.
|
| R2-2503805_NES_ODSSB_fj.docx |
3GPP TSG-RAN WG2#130 R2-2503805
St. Julians, Malta, May 19th – 23rd, 2025
Source: Fujitsu
Agenda item: 8.5.2
Title: Remaining issues on on-demand SSB SCell operation
Document for: Discussion and decision
|
Conclusion
In this contribution, we have some discussions about on-demand SSB SCell operations, and the following proposals are made:
Framework of L3 measurements
Proposal 1: RAN2 to adopt “Option1: Based on different measurement configuration when OD-SSB is transmitted” as on-demand SSB L3 measurements framework.
Proposal 2: The UE should apply the SMTC window configured for on-demand SSB when the corresponding on-demand SSB transmission is activated.
Proposal 3: RAN2 to confirm the legacy measurement framework (i.e., legacy SMTC) is applied for neighbour cell measurements.
On-demand SSB activation/deactivation MAC CE
Proposal 4: No need to explicitly indicate the candidate values for OD-SSB via MAC CE.
Proposal 5: RAN2 to support that at most two OD-SSB configurations can be configured per SCell in RRC. Inform RAN1 if any concern.
Other on-demand SSB procedure
Proposal 6: NW ensures that OD-SSB deactivation by RRC/MAC CE is only performed during SCell deactivation state. FFS how to capture it in running CR (e.g., Note X in TS 38.321).
|
| R2-2503824.docx |
3GPP TSG-RAN WG2 Meeting #R2-130 R2-2503824 St Julians, Malta, May 19-23, 2025
Agenda Item: 8.5.2
Source: Rakuten
Title: Remaining issues of OD-SSB
Document for: Discussion and decision
|
Conclusion
We have the following proposals:
Proposal 1 UE triggered on-demand SSB operation is supported.
Proposal 2 L3 measurements of OD-SSB are performed based on OD-SSB pattern ignoring SMTC, both in case #1 and case #2.
Proposal 3 The SSB periodicity and the ssb-PositionsInBurst of the OD-SSB are indicated to the UE to enable L3 measurements of OD-SSB.
|
| R2-2503827 Discussion on on-demand SSB SCell operation_cl.DOCX |
3GPP TSG-RAN WG2 Meeting #130 R2-2503827
St. Julians, Malta, May 19th – 23rd, 2025
Agenda item: 8.5.2
Source: Sharp
Title: Discussion on on-demand SSB SCell operation
Document for: Discussion and Decision
|
Conclusions
Based on the discussion above, we have the following proposals:
Proposal 1: For Case 2, RAN2 WG to discuss what additional parameter(s) needs to be provided in the measurement object/report configuration/quantity configuration for on-demand SSB and how UE adapts the additional parameter(s) when on-demand SSB is activated/deactivated.
Proposal 2: For Case 2, RAN2 to discuss the UE behavior for the serving cell measurement when a serving cell is configured to be associated with separate measurement objects of A-SSB and OD-SSB.
Proposal 3: A single MAC CE format is used for both activation/deactivation of OD-SSB and updating OD-SSB parameters.
|
| R2-2503893 On Demand SSB SCell Operation.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503893
Saint Julian’s, Malta, 19 – 23 May 2025
Agenda item: 8.5.2
Source: Nokia, Nokia Shanghai Bell
Title: On-demand SSB SCell operation
WID/SID: Netw_Energy_NR - Release 19
Document for: Discussion and Decision
1 |
Conclusion
Observation 1: During the RAN1#117 meeting, both RRC and MAC-CE based signaling have been agreed to indicate on-demand SSB transmission at least for Scenario#2 and Scenario#2A for both Case#1 and Case#2. During RAN1#120bis meeting, scenario#3B for Case#1 And Case#2 has been agreed.
Proposal 1 : OD-SSB configuration is Cell-specific to avoid overhead and redundant configurations.
Proposal 2 : Physical cell id is not required to be configured for OD-SSB as the PCI configuration is provided in the serving cell configuration. RAN2 to inform RAN1 to remove this parameter from the od-ssb configuration parameters list.
Proposal 3 : RAN2 starts signaling design so that each parameter listed by RAN1 can be signalled for any instance of OD-SSB configuration.
Proposal 4: Possible signaling optimizations can be down prioritized in RAN2 work.
Proposal 5: the RAN2 agreement on “OD-SSB MAC-CE includes a configuration index for each SCell activating OD-SSB” could support the additional adaptive parameters SSB positions, Number N of on-demand SSB bursts on top of periodicity which can configured as different OD-SSB configurations in RRC and MAC indicates which OD-SSB configuration ID to be activated.
Proposal 6: from RAN2 point of view, no restriction of applying counter based implicit deactivation and MAC CE based explicit deactivation whichever comes first. It can be revisited if RAN1 agrees otherwise e.g. to ignore the deactivation bit if N for implicit deactivation is configured for the activated configuration ID.
Proposal 7: the reactivation issue can be solved by reactivating the same OD-SSB configuration ID, for which case the counter does not need to be reset.
Observation 2: Multiple additional SMTC configurations may be configured with SSB adaptation and similar configuration may be applied to OD-SSB when configured with multiple candidate values for periodicity.
Proposal 8: For OD-SSB, multiple additional SMTC configurations are configured to UE via RRC, together with the mapping between SSB burst periodicity and SMTC configuration.
Proposal 9: Upon reception of MAC CE to activate corresponding OD-SSB, UE selects one SMTC configuration accordingly.
Proposal 10 : It should be possible to configure dedicated servingCellMo for each SSB configuration
Annex A: TP for SSB adaptation
– ServingCellConfig
The IE ServingCellConfig is used to configure (add or modify) the UE with a serving cell, which may be the SpCell or an SCell of an MCG or SCG. The parameters herein are mostly UE specific but partly also cell specific (e.g. in additionally configured bandwidth parts). Reconfiguration between a PUCCH and PUCCHless SCell is only supported using an SCell release and add.
ServingCellConfig information element
-- ASN1START
-- TAG-SERVINGCELLCONFIG-START
ServingCellConfig ::= SEQUENCE {
tdd-UL-DL-ConfigurationDedicated TDD-UL-DL-ConfigDedicated OPTIONAL, -- Cond TDD
initialDownlinkBWP BWP-DownlinkDedicated OPTIONAL, -- Need M
downlinkBWP-ToReleaseList SEQUENCE (SIZE (1..maxNrofBWPs)) OF BWP-Id OPTIONAL, -- Need N
downlinkBWP-ToAddModList SEQUENCE (SIZE (1..maxNrofBWPs)) OF BWP-Downlink OPTIONAL, -- Need N
firstActiveDownlinkBWP-Id BWP-Id OPTIONAL, -- Cond SyncAndCellAdd
bwp-InactivityTimer ENUMERATED {ms2, ms3, ms4, ms5, ms6, ms8, ms10, ms20, ms30,
ms40,ms50, ms60, ms80,ms100, ms200,ms300, ms500,
ms750, ms1280, ms1920, ms2560, spare10, spare9, spare8,
spare7, spare6, spare5, spare4, spare3, spare2, spare1 } OPTIONAL, --Need R
defaultDownlinkBWP-Id BWP-Id OPTIONAL, -- Need S
uplinkConfig UplinkConfig OPTIONAL, -- Need M
supplementaryUplink UplinkConfig OPTIONAL, -- Need M
pdcch-ServingCellConfig SetupRelease { PDCCH-ServingCellConfig } OPTIONAL, -- Need M
pdsch-ServingCellConfig SetupRelease { PDSCH-ServingCellConfig } OPTIONAL, -- Need M
csi-MeasConfig SetupRelease { CSI-MeasConfig } OPTIONAL, -- Need M
sCellDeactivationTimer ENUMERATED {ms20, ms40, ms80, ms160, ms200, ms240,
ms320, ms400, ms480, ms520, ms640, ms720,
ms840, ms1280, spare2,spare1} OPTIONAL, -- Cond ServingCellWithoutPUCCH
crossCarrierSchedulingConfig CrossCarrierSchedulingConfig OPTIONAL, -- Need M
tag-Id TAG-Id,
dummy1 ENUMERATED {enabled} OPTIONAL, -- Need R
pathlossReferenceLinking ENUMERATED {spCell, sCell} OPTIONAL, -- Cond SCellOnly
servingCellMO MeasObjectId OPTIONAL, -- Cond MeasObject
...,
[[
lte-CRS-ToMatchAround SetupRelease { RateMatchPatternLTE-CRS } OPTIONAL, -- Need M
rateMatchPatternToAddModList SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPattern OPTIONAL, -- Need N
rateMatchPatternToReleaseList SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPatternId OPTIONAL, -- Need N
downlinkChannelBW-PerSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SCS-SpecificCarrier OPTIONAL -- Need S
]],
[[
supplementaryUplinkRelease-r16 ENUMERATED {true} OPTIONAL, -- Need N
tdd-UL-DL-ConfigurationDedicated-IAB-MT-r16 TDD-UL-DL-ConfigDedicated-IAB-MT-r16 OPTIONAL, -- Cond TDD_IAB
dormantBWP-Config-r16 SetupRelease { DormantBWP-Config-r16 } OPTIONAL, -- Need M
ca-SlotOffset-r16 CHOICE {
refSCS15kHz INTEGER (-2..2),
refSCS30KHz INTEGER (-5..5),
refSCS60KHz INTEGER (-10..10),
refSCS120KHz INTEGER (-20..20)
} OPTIONAL, -- Cond AsyncCA
dummy2 SetupRelease { DummyJ } OPTIONAL, -- Need M
intraCellGuardBandsDL-List-r16 SEQUENCE (SIZE (1..maxSCSs)) OF IntraCellGuardBandsPerSCS-r16 OPTIONAL, -- Need S
intraCellGuardBandsUL-List-r16 SEQUENCE (SIZE (1..maxSCSs)) OF IntraCellGuardBandsPerSCS-r16 OPTIONAL, -- Need S
csi-RS-ValidationWithDCI-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
lte-CRS-PatternList1-r16 SetupRelease { LTE-CRS-PatternList-r16 } OPTIONAL, -- Need M
lte-CRS-PatternList2-r16 SetupRelease { LTE-CRS-PatternList-r16 } OPTIONAL, -- Need M
crs-RateMatch-PerCORESETPoolIndex-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
enableTwoDefaultTCI-States-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
enableDefaultTCI-StatePerCoresetPoolIndex-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
enableBeamSwitchTiming-r16 ENUMERATED {true} OPTIONAL, -- Need R
cbg-TxDiffTBsProcessingType1-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
cbg-TxDiffTBsProcessingType2-r16 ENUMERATED {enabled} OPTIONAL -- Need R
]],
[[
directionalCollisionHandling-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
channelAccessConfig-r16 SetupRelease { ChannelAccessConfig-r16 } OPTIONAL -- Need M
]],
[[
nr-dl-PRS-PDC-Info-r17 SetupRelease {NR-DL-PRS-PDC-Info-r17} OPTIONAL, -- Need M
semiStaticChannelAccessConfigUE-r17 SetupRelease {SemiStaticChannelAccessConfigUE-r17} OPTIONAL, -- Need M
mimoParam-r17 SetupRelease {MIMOParam-r17} OPTIONAL, -- Need M
channelAccessMode2-r17 ENUMERATED {enabled} OPTIONAL, -- Need R
timeDomainHARQ-BundlingType1-r17 ENUMERATED {enabled} OPTIONAL, -- Need R
nrofHARQ-BundlingGroups-r17 ENUMERATED {n1, n2, n4} OPTIONAL, -- Need R
fdmed-ReceptionMulticast-r17 ENUMERATED {true} OPTIONAL, -- Need R
moreThanOneNackOnlyMode-r17 ENUMERATED {mode2} OPTIONAL, -- Need S
tci-ActivatedConfig-r17 TCI-ActivatedConfig-r17 OPTIONAL, -- Cond TCI_ActivatedConfig
directionalCollisionHandling-DC-r17 ENUMERATED {enabled} OPTIONAL, -- Need R
lte-NeighCellsCRS-AssistInfoList-r17 SetupRelease { LTE-NeighCellsCRS-AssistInfoList-r17 } OPTIONAL -- Need M
]],
[[
lte-NeighCellsCRS-Assumptions-r17 ENUMERATED {false} OPTIONAL -- Need R
]],
[[
crossCarrierSchedulingConfigRelease-r17 ENUMERATED {true} OPTIONAL -- Need N
]],
[[
multiPDSCH-PerSlotType1-CB-r17 ENUMERATED {enabled, disabled} OPTIONAL -- Need R
]],
[[
lte-CRS-PatternList3-r18 SetupRelease { LTE-CRS-PatternList-r16 } OPTIONAL, -- Need M
lte-CRS-PatternList4-r18 SetupRelease { LTE-CRS-PatternList-r16 } OPTIONAL, -- Need M
pdcch-CandidateReceptionWithCRS-Overlap-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
cjt-Scheme-PDSCH-r18 ENUMERATED {cjtSchemeA, cjtSchemeB} OPTIONAL, -- Need R
tag2-r18 Tag2-r18 OPTIONAL, -- Need R
cellDTX-DRX-Config-r18 SetupRelease { CellDTX-DRX-Config-r18 } OPTIONAL, -- Need M
positionInDCI-cellDTRX-r18 INTEGER (0..maxDCI-2-9-Size-1-r18) OPTIONAL, -- Need R
cellDTX-DRX-L1activation-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
mc-DCI-SetOfCellsToAddModList-r18 SEQUENCE (SIZE (1..maxNrofSetsOfCells-r18)) OF MC-DCI-SetOfCells-r18 OPTIONAL, -- Need N
mc-DCI-SetOfCellsToReleaseList-r18 SEQUENCE (SIZE (1..maxNrofSetsOfCells-r18)) OF SetOfCellsId-r18 OPTIONAL -- Need N
]],
[[
mimoParam-v1850 SetupRelease {MIMOParam-v1850} OPTIONAL -- Need M
]]
}
Tag2-r18 ::= SEQUENCE {
tag2-Id-r18 TAG-Id,
tag2-flag-r18 BOOLEAN,
n-TimingAdvanceOffset2-r18 ENUMERATED { n0, n25600, n39936, spare1 } OPTIONAL -- Need S
}
UplinkConfig ::= SEQUENCE {
initialUplinkBWP BWP-UplinkDedicated OPTIONAL, -- Need M
uplinkBWP-ToReleaseList SEQUENCE (SIZE (1..maxNrofBWPs)) OF BWP-Id OPTIONAL, -- Need N
uplinkBWP-ToAddModList SEQUENCE (SIZE (1..maxNrofBWPs)) OF BWP-Uplink OPTIONAL, -- Need N
firstActiveUplinkBWP-Id BWP-Id OPTIONAL, -- Cond SyncAndCellAdd
pusch-ServingCellConfig SetupRelease { PUSCH-ServingCellConfig } OPTIONAL, -- Need M
carrierSwitching SetupRelease { SRS-CarrierSwitching } OPTIONAL, -- Need M
...,
[[
powerBoostPi2BPSK BOOLEAN OPTIONAL, -- Need M
uplinkChannelBW-PerSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SCS-SpecificCarrier OPTIONAL -- Need S
]],
[[
enablePL-RS-UpdateForPUSCH-SRS-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
enableDefaultBeamPL-ForPUSCH0-0-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
enableDefaultBeamPL-ForPUCCH-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
enableDefaultBeamPL-ForSRS-r16 ENUMERATED {enabled} OPTIONAL, -- Need R
uplinkTxSwitching-r16 SetupRelease { UplinkTxSwitching-r16 } OPTIONAL, -- Need M
mpr-PowerBoost-FR2-r16 ENUMERATED {true} OPTIONAL -- Need R
]],
[[
srs-PosTx-Hopping-r18 SetupRelease { SRS-PosTx-Hopping-r18 } OPTIONAL, -- Need M
enablePL-RS-UpdateForType1CG-PUSCH-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
powerBoostPi2BPSK-r18 BOOLEAN OPTIONAL, -- Need R
powerBoostQPSK-r18 BOOLEAN OPTIONAL -- Need R
]]
}
DummyJ ::= SEQUENCE {
maxEnergyDetectionThreshold-r16 INTEGER(-85..-52),
energyDetectionThresholdOffset-r16 INTEGER (-20..-13),
ul-toDL-COT-SharingED-Threshold-r16 INTEGER (-85..-52) OPTIONAL, -- Need R
absenceOfAnyOtherTechnology-r16 ENUMERATED {true} OPTIONAL -- Need R
}
ChannelAccessConfig-r16 ::= SEQUENCE {
energyDetectionConfig-r16 CHOICE {
maxEnergyDetectionThreshold-r16 INTEGER (-85..-52),
energyDetectionThresholdOffset-r16 INTEGER (-13..20)
} OPTIONAL, -- Need R
ul-toDL-COT-SharingED-Threshold-r16 INTEGER (-85..-52) OPTIONAL, -- Need R
absenceOfAnyOtherTechnology-r16 ENUMERATED {true} OPTIONAL -- Need R
}
IntraCellGuardBandsPerSCS-r16 ::= SEQUENCE {
guardBandSCS-r16 SubcarrierSpacing,
intraCellGuardBands-r16 SEQUENCE (SIZE (1..4)) OF GuardBand-r16
}
GuardBand-r16 ::= SEQUENCE {
startCRB-r16 INTEGER (0..274),
nrofCRBs-r16 INTEGER (0..15)
}
DormancyGroupID-r16 ::= INTEGER (0..4)
DormantBWP-Config-r16::= SEQUENCE {
dormantBWP-Id-r16 BWP-Id OPTIONAL, -- Need M
withinActiveTimeConfig-r16 SetupRelease { WithinActiveTimeConfig-r16 } OPTIONAL, -- Need M
outsideActiveTimeConfig-r16 SetupRelease { OutsideActiveTimeConfig-r16 } OPTIONAL -- Need M
}
WithinActiveTimeConfig-r16 ::= SEQUENCE {
firstWithinActiveTimeBWP-Id-r16 BWP-Id OPTIONAL, -- Need M
dormancyGroupWithinActiveTime-r16 DormancyGroupID-r16 OPTIONAL -- Need R
}
OutsideActiveTimeConfig-r16 ::= SEQUENCE {
firstOutsideActiveTimeBWP-Id-r16 BWP-Id OPTIONAL, -- Need M
dormancyGroupOutsideActiveTime-r16 DormancyGroupID-r16 OPTIONAL -- Need R
}
UplinkTxSwitching-r16 ::= SEQUENCE {
uplinkTxSwitchingPeriodLocation-r16 BOOLEAN,
uplinkTxSwitchingCarrier-r16 ENUMERATED {carrier1, carrier2}
}
MIMOParam-r17 ::= SEQUENCE {
additionalPCI-ToAddModList-r17 SEQUENCE (SIZE(1..maxNrofAdditionalPCI-r17)) OF SSB-MTC-AdditionalPCI-r17 OPTIONAL, -- Need N
additionalPCI-ToReleaseList-r17 SEQUENCE (SIZE(1..maxNrofAdditionalPCI-r17)) OF AdditionalPCIIndex-r17 OPTIONAL, -- Need N
unifiedTCI-StateType-r17 ENUMERATED {separate, joint} OPTIONAL, -- Need R
uplink-PowerControlToAddModList-r17 SEQUENCE (SIZE (1..maxUL-TCI-r17)) OF Uplink-powerControl-r17 OPTIONAL, -- Need N
uplink-PowerControlToReleaseList-r17 SEQUENCE (SIZE (1..maxUL-TCI-r17)) OF Uplink-powerControlId-r17 OPTIONAL, -- Need N
sfnSchemePDCCH-r17 ENUMERATED {sfnSchemeA,sfnSchemeB} OPTIONAL, -- Need R
sfnSchemePDSCH-r17 ENUMERATED {sfnSchemeA,sfnSchemeB} OPTIONAL -- Need R
}
MIMOParam-v1850 ::= SEQUENCE {
additionalTDDConfig-perPCI-ToAddModList-r18 SEQUENCE (SIZE (1..maxNrofAdditionalPCI-r17)) OF AdditionalTDDConfig-perPCI-ToAddMod-r18
OPTIONAL, -- Cond 2TA-TDD-Only
additionalTDDConfig-perPCI-ToReleaseList-r18 SEQUENCE (SIZE (1..maxNrofAdditionalPCI-r17)) OF AdditionalPCIIndex-r17
OPTIONAL -- Need N
}
AdditionalTDDConfig-perPCI-ToAddMod-r18 ::= SEQUENCE {
additionalTDDConfig-Index-r18 AdditionalPCIIndex-r17,
tdd-UL-DL-ConfigurationCommon-r18 TDD-UL-DL-ConfigCommon
}
MC-DCI-SetOfCells-r18 ::= SEQUENCE {
setOfCellsId-r18 SetOfCellsId-r18,
nCI-Value-r18 INTEGER (0..7),
scheduledCellListDCI-1-3-r18 SEQUENCE (SIZE (2..maxNrofCellsInSet-r18)) OF ServCellIndex OPTIONAL, -- Need R
scheduledCellListDCI-0-3-r18 SEQUENCE (SIZE (2..maxNrofCellsInSet-r18)) OF ServCellIndex OPTIONAL, -- Need R
scheduledCellComboListDCI-1-3-r18 SEQUENCE (SIZE (1..maxNrofCellCombos-r18)) OF ScheduledCellCombo-r18 OPTIONAL, -- Need R
scheduledCellComboListDCI-0-3-r18 SEQUENCE (SIZE (1..maxNrofCellCombos-r18)) OF ScheduledCellCombo-r18 OPTIONAL, -- Need R
antennaPortsDCI1-3-r18 ENUMERATED {type1a, type2} OPTIONAL, -- Cond TypeDCI1-3
antennaPortsDCI0-3-r18 ENUMERATED {type1a, type2} OPTIONAL, -- Cond TypeDCI0-3
tpmi-DCI0-3-r18 ENUMERATED {type1a, type2} OPTIONAL, -- Cond TypeDCI0-3
sri-DCI0-3-r18 ENUMERATED {type1a, type2} OPTIONAL, -- Cond TypeDCI0-3
priorityIndicatorDCI-1-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
priorityIndicatorDCI-0-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
dormancyDCI-1-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
dormancyDCI-0-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
pdcchMonAdaptDCI-1-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
pdcchMonAdaptDCI-0-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
minimumSchedulingOffsetK0DCI-1-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
minimumSchedulingOffsetK0DCI-0-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
pdsch-HARQ-ACK-OneShotFeedbackDCI-1-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
pdsch-HARQ-ACK-enhType3DCI-1-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
pdsch-HARQ-ACK-enhType3DCIfieldDCI-1-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
pdsch-HARQ-ACK-retxDCI-1-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
pucch-sSCellDynDCI-1-3-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
tdra-FieldIndexListDCI-1-3-r18 SEQUENCE (SIZE (1..32)) OF TDRA-FieldIndexDCI-1-3-r18 OPTIONAL, -- Need R
tdra-FieldIndexListDCI-0-3-r18 SEQUENCE (SIZE (1..64)) OF TDRA-FieldIndexDCI-0-3-r18 OPTIONAL, -- Need R
rateMatchListDCI-1-3-r18 SEQUENCE (SIZE (1..16)) OF RateMatchDCI-1-3-r18 OPTIONAL, -- Need R
zp-CSI-RSListDCI-1-3-r18 SEQUENCE (SIZE (1..8)) OF ZP-CSI-DCI-1-3-r18 OPTIONAL, -- Need R
tci-ListDCI-1-3-r18 SEQUENCE (SIZE (1..16)) OF TCI-DCI-1-3-r18 OPTIONAL, -- Need R
srs-RequestListDCI-1-3-r18 SEQUENCE (SIZE (1..16)) OF SRS-RequestCombo-r18 OPTIONAL, -- Need R
srs-OffsetListDCI-1-3-r18 SEQUENCE (SIZE (1..8)) OF SRS-OffsetCombo-r18 OPTIONAL, -- Need R
srs-RequestListDCI-0-3-r18 SEQUENCE (SIZE (1..16)) OF SRS-RequestCombo-r18 OPTIONAL, -- Need R
srs-OffsetListDCI-0-3-r18 SEQUENCE (SIZE (1..8)) OF SRS-OffsetCombo-r18 OPTIONAL -- Need R
}
SetOfCellsId-r18 ::= INTEGER (0..maxNrofSetsOfCells-1-r18)
ScheduledCellCombo-r18 ::= SEQUENCE (SIZE (1..maxNrofCellsInSet-r18)) OF INTEGER (0..maxNrofCellsInSet-1-r18)
RateMatchDCI-1-3-r18 ::= SEQUENCE (SIZE (1..maxNrofCellsInSet-r18)) OF BIT STRING (SIZE (1..2))
ZP-CSI-DCI-1-3-r18 ::= SEQUENCE (SIZE (1.. maxNrofCellsInSet-r18)) OF BIT STRING (SIZE (1..2))
TCI-DCI-1-3-r18 ::= SEQUENCE (SIZE (2.. maxNrofCellsInSet-r18)) OF BIT STRING (SIZE (3))
SRS-RequestCombo-r18 ::= SEQUENCE (SIZE (1.. maxNrofCellsInSet-r18)) OF BIT STRING (SIZE (2..3))
SRS-OffsetCombo-r18 ::= SEQUENCE (SIZE (1.. maxNrofCellsInSet-r18)) OF INTEGER (0..3)
TDRA-FieldIndexDCI-1-3-r18 ::= SEQUENCE (SIZE (2.. maxNrofBWPsInSetOfCells-r18)) OF INTEGER (0..maxNrofDL-Allocations-1-r18)
TDRA-FieldIndexDCI-0-3-r18 ::= SEQUENCE (SIZE (2.. maxNrofBWPsInSetOfCells-r18)) OF INTEGER (0..maxNrofUL-Allocations-1-r18)
-- TAG-SERVINGCELLCONFIG-STOP
-- ASN1STOP
NOTE 1: If the dedicated part of initial UL/DL BWP configuration is absent, the initial BWP can be used but with some limitations. For example, changing to another BWP requires RRCReconfiguration since DCI format 1_0 doesn't support DCI-based switching.
|
| R2-2503916.docx |
3GPP TSG-RAN WG2 Meeting #130 R2- 2503916
St.Julians, Malta, May. 19th – 23rd, 2025
Agenda Item: 8.5.2
Source: Lenovo
Title: Issues on the procedure of on-demand SSB SCell operation
Document for: Discussion and decision
|
Conclusion
In summary, we have following observations and proposals on the operation of on-demand SSB for SCell:
Proposal 1: Reuse existing RRC Reconfiguration message to configure the on-demand SSB related information to UE.
Proposal 2: Use an AddModList to configure the OD-SSB parameters in the RRC configuration and include a corresponding index (config Id) in the MAC CE once RAN1 has determined the detailed RRC parameters for OD-SSB configuration.
Proposal 3: it can be allowed to configure a UE with multiple OD-SSBs with the different frequencies for a given Scelland at most one OD-SSB with the different frequency for each BWP.
Proposal 4: A UE is configured with one MO for a sering cell to measure AO-SSB or OD-SSBs.
|
| R2-2503944 Discussion on on-demand SSB SCell operation for NES.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503944
St. Julian’s, Malta, 19 - 23 May, 2025
Source: Huawei, HiSilicon
Title: Discussion on on-demand SSB SCell operation for NES
Agenda Item: 8.5.2
Document for: Discussion and decision
|
Conclusion
In this contribution, we discussed on-demand SSB for intra/inter-band CA, and propose the following:
Proposal 1: RAN2 to down-select from the following alternatives:
Understanding 1: For SCell using implicit deactivation, A/D bit is set to 0 (deactivation), UE ignores the configuration index and only follows N configured by RRC. No configuration index is included for the SCell.
Understanding 2: For SCell using implicit deactivation, A/D bit is set to 1 (activation), UE restarts counter N for the SCell when receiving the MAC CE, and N is configured by RRC. No configuration index is included for the SCell.
Understanding 3: For SCell using implicit deactivation, A/D bit is set to 1 (activation) and configuration index is included to update the N to the remaining numbers of OD-SSB bursts to be transmitted.
Combined Understanding 1 and 3: For SCell using implicit deactivation, if the A/D bit set to 0 (deactivation) UE ignores the configuration index field, if A/D bit is set to 1 (activation) the UE follows the configuration index field.
Proposal 2: To ensure that OD-SSB is not deactivated after SCell is activated (i.e., Scenario 3B), RAN2 to down-select from the following alternatives:
Option 1: RRC configured N includes a value set to infinity
Option 2: It is up to NW implementation to reconfigure the UE to disable the OD-SSB feature for an SCell when the SCell is activated.
Proposal 3: Use two eLCIDs for the OD-SSB transmission MAC CE, corresponding to 7 SCells and 31 SCells respectively.
Proposal 4: RAN2 will not further discuss the case of multiple OD-SSBs with different frequencies for a given SCell, unless this scenario is agreed by RAN1 or RAN4.
Proposal 5: For serving cell measurements:
In case 1 (no AO-SSB), the serving cell measurements are based on OD-SSB.
In case 2 (with AO-SSB), in intra-frequency cases, OD-SSB can be used for serving cell measurements, how AO-SSB is utilized for serving cell measurements and how to combine AO-SSB and OD-SSB is up to RAN4 discussion; in inter-frequency cases, only OD-SSB is used for serving cell measurements.
Proposal 6: For both Case 1 (no always-on SSB) and Case 2 (always-on SSB), the measurements of OD-SSB is based on OD-SSB pattern rather than SMTC. For deactivated SCell, after the fast window, OD-SSB is measured based on measCycleSCell in combination with OD-SSB pattern.
Proposal 7: On how to utilize the new servingCellMO, RAN2 to down-select from the following:
Option 1: When OD-SSB is activated, UE uses servingCellMO-OD to measure serving cell and intra-f neighbour cells; when OD-SSB is deactivated, UE uses servingCellMO-AO (i.e., legacy servingCellMO) to measure serving cell and intra-f neighbour cells.
Option 2: Regardless of the activation status of OD-SSB, UE uses both servingCellMO-OD and servingCellMO-AO (i.e., legacy servingCellMO) to measure serving cell and intra-f neighbour cells. FFS how the network determines the serving cell measurement results come from which MO.
Proposal 8: For neighbour cell measurements:
OD-SSB status of neighbour cell is transparent to UE, and no spec impact is needed.
When serving cell OD-SSB and AO-SSB are on different frequencies, the UE determines whether neighbour cell measurements is intra-f or inter-f measurements based on AO-SSB servingCellMO when OD-SSB is not transmitted, based on OD-SSB servingCellMO when OD-SSB is transmitted.
Proposal 9: For SSB based intra-f measurement, if gap requirement is not reported by the UE: Other than the initial BWP, if any of the UE configured BWPs do not contain the frequency domain resources of the SSB indicated by OD-SSB servingCellMO when OD-SSB transmission is activated, a measurement gap is always provided.
Proposal 10: RAN2 to discuss how periodical reporting and/or event-triggered reporting is applied to OD-SSB measurements.
Proposal 11: OD-SSB MAC CE can be used to trigger serving cell measurements and reporting.
|
| R2-2503988_odssb MAC.docx |
3GPP TSG-RAN WG2 #130 R2-2503988
St. Julian’s, Malta, 19 – 23 May 2025
Agenda item: 8.5.2 On-demand SSB SCell operation
Title: Remaining issues on On-demand SSB for SCell
Source: NEC
Document for: Discussion and Decision
1. |
Conclusion
In this contribution we discussed remaining issues for new MAC CE for OD-SSB activation/deactivation and made the following proposals.
Proposal 1: Network ensures only one of explicit and implicit OD-SSB deactivation for all the SCells on which OD-SSB is used.
Proposal 2: RAN2 to confirm that RRC configures multiple candidate values of “N” (as per RAN1 agreement).
Proposal 3: RAN2 to assume the MAC CE includes the single value “N” from the configured candidate values, which is applied for all the SCells for which OD-SSB is activated and send an LS to RAN1/4 for confirmation.
Proposal 4: RAN2 to discuss whether the network can change the OD-SSB deactivation method from implicit to explicit, if the P1 is not agreed.
Proposal 5: Do not consider additional measurement report triggered by new MAC CE for OD-SSB activation.
|
| R2-2504036_Remaining issues of on-demand SSB SCell operation.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504036
St.Julian, Malta, May 19th – 23rd, 2025
Agenda Item: 8.5.2
Source: vivo
Title: Remaining issues of on-demand SSB SCell operation
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
RAN1#119
RAN1#118bis
RAN1#118
RAN1#117
RAN1#116bis
RAN1#116
RAN2 Agreements
RAN2#129bis
RAN2#129
Agreements on OD-SSB
RAN2 leave it to RAN4 to conclude whether always-on SSB and/or OD-SSB are measured when both are transmitted in OD-SSB case 2.
RAN2#127bis
RAN2#127
RAN4 Agreements
RAN4#114bis
RAN4#114
RAN4#113
RAN4#112bis
RAN4#112
|
| R2-2504061.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504061
St.Julians, Malta, May 19th – 23rd, 2025
Agenda Item: 8.5.2
Source: Sony
Title: Remaining details on OD-SSB MAC CE
Document for: Discussion
|
Conclusion
We propose RAN2 to discuss following proposals:
Proposal 1: MAC-CE design shall address both implicit and explicit deactivation scenarios and suggest RAN2 to discuss and select one of the options as below.
Option 1: Network configures either implicit or explicit deactivation should be used.
Option 2: Network configures both implicit and explicit deactivation can be used but with some pre-defined rules.
Option 3: After network sends MAC CE to activate a certain SCell, network will not send any other MAC CEs to activate/deactivate SCells if there is any implicit deactivation running for that UE.
|
| R2-2504242_Discussion_on_On-demand_SSB.docx |
3GPP TSG RAN WG2 Meeting #130 R2-2504242
St. Julians, Malta, May 19th – 23rd, 2025
Agenda item: 8.5.2
Source: Qualcomm Incorporated
Title: Discussion on On-demand SSB SCell Operation
WID/SID: Netw_Energy_NR_enh-Core – Release 19
Document for: Discussion
|
Conclusion
In this contribution, we discussed the design details of OD-SSB transmission MAC CE and L3 RRM measurement for OD-SSB Case #2 and concluded with the following observations and proposals.
MAC CE for On-demand SSB transmission
Observation 1. The MAC CE for OD-SSB transmission contains an N value for implicit deactivation of an OD-SSB transmission if at least one value of N is configured by RRC.
Observation 2. The MAC CE for OD-SSB transmission contains the SSB position of an OD-SSB for both Case #1 (without always-on SSB) and for Case #2 if the always-on SSB and OD-SSB have different center frequencies.
Observation 3. The MAC CE for OD-SSB transmission updates the transmission parameters of a transmitted OD-SSB for both Case #1 and Case #2 after an Scell is activated. No new field of the MAC CE is needed for such an update indication.
L3 measurement for OD-SSB Case #1
Observation 4. For Case #2, it’s UE implementation to measure OA-SSB or OD-SSB when AO-SSB and OD-SSB have different center frequencies.
Proposal 1. RAN2 waits for RAN4’s response before RAN2 decides to confirm the following working assumption:
When A-SSB and OD-SSB have different center frequencies, introduce a new servingCellMO in ServingCellConfig to indicate MO of OD-SSB.
Proposal 2. From a UE’s aspect, only one OD-SSB is supported when AO-SSB and OD-SSB have different center frequencies.
|
| R2-2504280 (R19 NES WI AI 8.5.2 on demand SSB).docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504280
Malta, May 19 – 23, 2025
Agenda Item: 8.5.2
Source: InterDigital
Title: On demand SSB transmission for SCell
Document for: Discussion, Decision
|
Conclusion
The following proposals are provided for on demand SSB reception on SCells:
Observation 1: RAN1 agreed to indicate, via a configuration an index, the following OD-SSB parameters: SSB positions within an on-demand SSB burst, the number N of on-demand SSB bursts to be transmitted after on-demand SSB is indicated, and SSB periodicity.
Proposal 1: 1 octet is used to indicate in the OD-SSB MAC CE which configuration index associated with the activated OD-SSB.
Proposal 2: The OD-SSB MAC CE is a variable size MAC CE. For each activated OD-SSB SCell, an additional (optional) octet is added to indicate the applicable OD-SSB configuration index.
Proposal 3: Adopt the text proposal to TS 38.321 in Annex A for the OD-SSB MAC CE.
Observation 2: SCell deactivation timer restarts after the reception of the SCell Activation/Deactivation MAC CE.
Proposal 4: For implicit deactivation of an OD-SSB transmission after the transmission of N occasions, reuse to SCell deactivation timer behaviour: UE (re)-applies the indicated N value in the MAC CE for each activated OD-SSB transmission upon reception of the SCell Activation/Deactivation MAC CE:
Proposal 5: Confirm working assumption: when A-SSB and OD-SSB have different center frequency, introduce a new servingCellMO in ServingCellConfig to indicate MO of OD-SSB
|
| R2-2504386 Discussion on On-demand SSB for SCell.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504386
St.Julians, Malta, May 19th – 23rd , 2025
Agenda item: 8.5.2
Source: CMCC
Title: Discussion on on-demand SSB for SCell
Document for: Discussion, Decision
|
Conclusion
In this contribution, we discuss configuration/indication of OD-SSB transmission and measurement related issues. Following are the proposals and observations made in this contribution:
Observations:
Observation 1: Based on RAN1 agreements, Number N of on-demand SSB bursts to be transmitted after on-demand SSB can be configured by RRC, in other words, implicit deactivation of OD-SSB can be indicated in RRC configuration.
Observation 2: Both RRC and MAC CE can be used for OD-SSB activation/deactivation.
Observation 3: With multiple OD-SSBs with the different frequencies for a given SCell, not only the network scheduling flexibility, but also the signalling overhead will be increased.
Observation 4: No matter in Case#1 or Case#2, the same measurement mechanism is used, that is UE will measure OD-SSB based on SSB pattern within the fast measurement window, and measured based on measCycleSCell as legacy if there’s OD-SSB or AO-SSB before SCell activation.
Proposals:
Proposal 1: If Number N of on-demand SSB bursts to be transmitted after on-demand SSB is configured in RRC configuration, only explicit activation/deactivation is indicated to the UE by MAC CE.
Proposal 2: If Number N of on-demand SSB bursts to be transmitted after on-demand SSB is not configured in RRC configuration, both explicit and implicit activation/deactivation can be used to indicate UE by MAC CE.
Proposal 3: For Scenario#3B, the MAC-CE is used only for updating the transmission parameter of a transmitted OD-SSB for the cell since the OD-SSB has been transmitted according to NW indication.
Proposal 4: It can be further discussed whether OD-SSB can be deactivated during period of the N OD-SSB bursts activated by the configuration or indication of number N.
Proposal 5: The following parameters can be configured in RRC signalling:
Frequency of the on-demand SSB
SSB positions within an on-demand SSB burst by using signaling similar to ssb-PositionsInBurst
Periodicity of the on-demand SSB
Sub-carrier spacing of the on-demand SSB
Time location of on-demand SSB burst
Physical Cell ID of the on-demand SSB
Downlink transmit power of on-demand SSB
Number N of on-demand SSB bursts to be transmitted after on-demand SSB
Proposal 6: Periodicity of the on-demand SSB, SSB positions within an on-demand SSB burst and Number N of on-demand SSB bursts to be transmitted after on-demand SSB can be configured with multiple value.
Proposal 7: Multiple OD-SSBs with the different frequencies for a given SCell is not supported.
Proposal 8: RAN2 confirms the working consumption that when AO-SSB and OD-SSB have different center frequency, introduce a new servingCellMO in ServingCellConfig to indicate MO of OD-SSB.
Proposal 9: For case 1 that AO-SSB and OD-SSB have same center frequency location, the same servingCellMO is used.
Proposal 10: Current SMTC based measurement is used for OD-SSB measurement after SCell activation.
Proposal 11: RAN2 needs to discuss whether multiple SMTC configuration is needed for OD-SSB measurement after SCell activation.
|
| R2-2504417.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504417
St.Julians, Malta, May 19th – 23rd, 2025
Agenda Item: 8.5.2
Source: Panasonic
Title: On-demand SSB SCell operation
Document for: Discussion/Decision
|
Conclusion
Based on the discussion, the following proposals are highlighted:
Proposal 1: sCellConfigCommon and sCellConfigDedicated support multiple candidate values of OD-SSB parameters.
Proposal 2: Scell modification indicates activation/deactivation of OD-SSB.
Proposal 3: Single MAC CE format for both explicit and implicit OD-SSB deactivations. Implicit OD-SSB can be deactivated by MAC CE.
Proposal 4: For same frequency of always on SSB and OD-SSB, additional SMTC can be configured for OD-SSB depending on the UE capability.
Proposal 5: Allow multiple OD-SSBs with different frequencies for a given Scell. For different frequency of always on SSB and OD-SSB, additional SMTC can be configured for OD-SSB depending on the UE capability. When one of SMTC is active in a time, SMTC patterns are configured as not to be overlapped in time domain.
|
| R2-2504418.docx |
3GPP TSG RAN WG2 #130 R2-2504418
St Julians, Malta, May 19th – 23rd, 2025
Source: NTT DOCOMO, INC.
Title: Discussion on on-demand SSB SCell operation
Agenda Item: 8.5.2
Document for: Discussion and Decision
|
Conclusion
In this contribution, we provided the following observations and proposals of on-demand SSB SCell operation for network energy saving.
Proposal 1:
Not support RRC based deactivation of OD-SSB that is already activated.
Proposal 2: (MAC-1)
For signaling design of MAC CE based indication of OD-SSB, the following fields can be considered:
If OD-SSB is configured per BWP not per serving cell, BWP index
If OD-SSB configured with number of N (to be deactivated implicitly) can be deactivated explicitly via MAC CE, 1 bit indication per SCell to represent which SCel is intended on top of 1 A/D bit per SCell.
Observation 1: (RRC-ODSSB-3)
It is expected that NW would determine whether and what property to activate OD-SSB on deactivated SCell for faster / more accurate L3 measurement according to UE’s condition (e.g., UE’s speed).
Proposal 3: (RRC-ODSSB-3)
Introduce a mechanism that measurement object, if this includes time and frequency of OD-SSB, is dynamically changed according to the indicated OD-SSB.
Proposal 4 : (RRC-ODSSB-4)
RAN2 to start discussion on the following issue after RAN1 agrees to support that AO-SSB and OD-SSB with same center frequency can have different ssb-PositionsInBurst.
If the od-ssb-PositionsInBurst of OD-SSB and AO-SSB is different, how the UE adapts the ssb-ToMeasure of MeasObjectNR after OD-SSB is activated.
|
| R2-2504540.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504540
St Julian’s, Malta, May 19th -23rd , 2025
Source: KDDI Corporation
Title: Discussion on On-demand SSB
Tdoc Type: Discussion
Agenda Item: 8.5.2
Document for: Discussion
Release: Rel-19
1 |
Conclusion
We make the following observations and proposals:
Proposal 1: RAN2 to discuss whether multiple OD-SSBs with different frequencies can be configured for a given SCell.
Proposal 2: When the AO-SSB and OD-SSB have the same frequency, they may share the same servingCellMO, but the OD-SSB SMTC should be linked to the adaptive OD-SSB periodicity.
Proposal 3: The UE applies the OD-SSB specific SMTC when the OD-SSB is activated.
Proposal 4: Introducing a new MAC CE-triggered measurement reporting mechanism is beneficial for OD-SSB
4 |