3GPP TSG RAN WG1 Meeting #121	R1-2503237
St. Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	9.2.1
Source:	Futurewei
Title:	Remaining Issues for UE-initiated/Event-driven Beam Management
Document for:	Discussion and decision 

Conclusions
Based on above discussions, we have the following observations and proposals:
Proposal 1: If UE has not sent any first PUCCH associated for UEI/ED beam reporting, UE does not expect to receive an uplink grant triggering the UEI/ED beam reporting. 
Proposal 2: Support Candidate#1 and Option-1B, but only for mode-A.
Candidate#1: To introduce a prohibit timer for mode-A and/or mode-B
Option-1A: In the case that triggering-event associated with the CSI report configuration is determined [by the same triggering beams(s) as the last transmitted PUCCH], if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer
Option-1B: In the case that triggering-event associated with the CSI report configuration is determined, if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the first PUCCH transmission, the UE starts the prohibit timer
If the prohibit timer is running, the first PUCCH is not allowed to be transmitted.
Proposal 3: Support Option-3.
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
FFS: If the PUSCH should be with UL-SCH or not for UEI beam report
Proposal 4: In addition to Candidate #2, support at least Candidate#1 and Candidate#5.
Candidate#1: RS reconfiguration/update or MAC-CE signaling (if supported) for new beam is received
FFS: whether to reset the counting for all new beams.
FFS: whether to maintain the counting whose new beam is NOT updated.
Candidate#5: The time window expires

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

Agenda Item:	9.2.1
Source:	Huawei, HiSilicon
Title:	On UE initiated/event-driven beam management
Document for:  Discussion and Decision 

Summary and conclusion

Proposal 1: In addition to revised Candidate#2, support the following conditions of resetting the counter:
The new beam RS corresponding to a counter is removed from the new beam resource set by RRC reconfiguration or, if supported, by MAC-CE signaling;
In this case, only the counter corresponding the removed new beam RS is reset.
UEI beam report is transmitted;
In this case, only reset the counting of new beam(s) fulfilling triggering condition and reported by the UEI beam report.
A time window expires. 
In this case, only the counter corresponding to the associated new beam should be reset.
The threshold for event evaluation is re-configured by RRC signaling
In this case, the counters corresponding to all new beams should be reset.

Proposal 2: Regarding the prohibit timer for both Mode-A and Mode-B, support Option-1A with the following modification:
In the case that triggering-event associated with the CSI report configuration is determined by the same triggering beam(s) as the last transmitted PUCCH, if the prohibit timer is NOT running, the UE can transmit the first PUCCH;
At the first symbol after the end of the second PUSCH transmission, the UE starts the prohibit timer

Proposal 3: When the prohibit timer starts running, only the counter of the triggering beam should be reset to zero while the other counters should continue counting.
Proposal 4: Regarding the time window for report initiation, adopt TP #1.
Proposal 5: Support to introduce an RRC parameter to enable/disable the RSRP report of new beams for Event-1.
Proposal 6: Support to introduce the ‘1-bit’ condition met indicator for Event 7.
Same interpretation on the ‘1-bit’ condition met indicator as Event-2 can be reused.
Proposal 7: When the 1-bit first PUCCH is collided/overlapped with a PUSCH, PUSCH should be dropped.
Proposal 8: When 1-bit first PUCCH is collided/overlapped with a PUCCH format 2/3/4 carrying HARQ-ACK information and/or CSI report,  bits are appended to HARQ-ACK information bits or prepended to CSI report bits to indicate one of the L 1-bit PUCCHs configured in the same slot as the PUCCH format 2/3/4.
Proposal 9: When 1-bit first PUCCH is collided/overlapped with a PUCCH format 2/3/4 carrying HARQ-ACK information and/or CSI report and SR/LRR,  bits are prepended to  bits for K SR/LRRs to indicate one of the L first 1-bit PUCCHs configured in the same slot as the PUCCH format 2/3/4 and the SR/LRR.
Proposal 10: UE does not expect that SR/LRR and the first 1-bit PUCCH are configured in the same slot where PUCCH format 0/1 carrying HARQ-ACK information is configured.
Proposal 11: When the number of configured trigger states is larger than 2n-1 where n is the length of CSI request field in DCI, UE should not transmit a first PUCCH if its associated trigger state is not activated.
Proposal 12: For Mode-A, the multiple CSI report configurations associated with the same CSI-AperiodicTriggerState should be associated with a same PUCCH resource.
Proposal 13: Support one or multiple events to be associated with one CSI report configuration. 
Event ID should be included in the report when the CSI report configuration is associated with multiple events.
Proposal 14: In CSI report configuration for UEI beam report, introduce an RRC parameter to indicate SpCell or a PUCCH-SCell as the cell of the configured PUCCH.
Note: This has a similar functionality as pucch-Cell used in PDSCH-ServingCellConfig to indicate whether HARQ-ACK PUCCH is on the SpCell or a specific PUCCH-SCell.

Proposal 15: UE initiated beam reports should have a higher priority than legacy periodic and semi-persistent CSI reports.
Proposal 16: Mode A based beam report should have a higher priority than both Mode B based report and legacy aperiodic CSI reports.
Proposal 17: Legacy aperiodic CSI reports should be prioritized over Mode B based beam report.
Proposal 18: Support the following priorities in the descending order for CSI reports: Mode A based beam report, aperiodic CSI reports carried on PUSCH, Mode B based beam report, semi-persistent CSI reports carried on PUSCH, semi-persistent CSI reports carried on PUCCH, periodic CSI reports carried on PUCCH.
Proposal 19: The end of CPU occupancy time for UEI beam reporting can be determined based on whether the notification/request is transmitted on the first PUCCH resource.
If the notification/request is sent on the first PUCCH resource, the end of CPU occupancy time can be the last symbol of the scheduled or pre-configured PUSCH carrying the report. 
If notification/request is not transmitted on the first PUCCH resource, the end of CPU occupancy time can be the last symbol of the first PUCCH resource.

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

Agenda Item:       9.2.1
Source:                 MediaTek Inc.
Title:                     Enhancements for UE-initiated/event-driven beam management
Document for:     Discussion and Decision

Conclusion
Based on the discussion in the previous sections, we made the following proposals and observations:
Counting evaluation within a time window
Observation 1: Specifying UE behaviour in TS38.214 based on a timer instead of a window is much clearer, since the timer is exactly how UE implement the window in real time system.
Observation 2: Multiple non-overlapping timers for one single RS between two transmission occasions of the first PUCCH could be possible, and counting evaluation based on one of non-overlapping timers can triggering the UEI/ED beam reporting. 
Observation 3: To ensure that counted event(s) instance(s) after resetting condition is met will not be consider anymore, UE needs to not only reset the counting but also stop the running timer.
Text Proposal 1: To adopt the following changes in section 5.2.1.5.4.1 in TS 38.214.
Proposal 1:  Regarding triggering event determination for Event-2, if the measured current beam RS is updated based on indicated TCI state (i.e., supported Candidate#2), UE resets the counting and stops the timer(s) for all the new beam(s): 

Proposal 2:  Regarding triggering event determination for Event-2, further support Candidate#1 and Candidate#7: 
Candidate#1: RS reconfiguration for new beam is received, 
Candidate#7 (combining Candidate#6): The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured, where The RRC parameters consists of the event threshold, the length of the time window (i.e., eventDetectionTimeWindowLength-r19) if provided and the maximum counting number (i.e., eventInstanceCount-r19) if provided,
If one of the above resetting conditions is met, UE resets the counting(s) and stops the timer(s) for all the new beam(s).
Note: Candidate#5 has been supported according to the RAN1#120bis agreement.
CSI processing unit occupancy
Observation 4: Processing of triggering evaluation of UEI/ED beam reporting will periodically occupy one CPU for each evaluation occasion.
Observation 5: CPU occupy time for triggering evaluation of UEI/ED beam reporting cannot be determined according to CSI reference resource or the second PUSCH resource which are not available or not defined during event evaluation.
Observation 6: Different length of the CPU occupy time may be assumed depending on counting evaluation within the window is enabled, because UE may require additional time for timer/counting processing. 
Proposal 3: For triggering evaluation for a UEI/ED beam reporting, UE periodically occupies one CSI processing unit for  symbols every evaluation occasion, starting from the first symbol of the earliest one of each measurement RS resource respective latest measurement RS occasion no later than an evaluation occasion. 
FFS: The value of   is subject to UE capability or specified as a certain value. 
FFS: Whether to apply different value of   depending on counting evaluation within the window is enabled
CSI reference resource definition 
Proposal 4: On CSI reference resource definition for a UEI/ED beam report, support the following: 
In transmission mode A, support to reuse legacy CSI reference definition of aperiodic CSI reporting for UEI/ED beam reporting.
In transmission mode B, support to reuse legacy CSI reference definition of semi-persistent CSI reporting for UEI/ED beam reporting.
Transmission procedure for UE-initiated/event-driven beam reporting
Proposal 5: For the transmission the first PUCCH, support Option-1 in Candidate#1 for both transmission mode A and B:
Option-1: In the case that triggering-event associated with the CSI report configuration is determined, if the prohibit timer is NOT running, the UE can transmit first PUCCH.
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer.
Note: If the prohibit timer is running, the first PUCCH is not allowed to be transmitted.
Proposal 6: On UEI/ED beam reporting in Mode A, regarding priority rules for CSI reports, UEI/ED beam reporting has the same priority as aperiodic beam reporting (i.e., y=0). 
The above is applied to the CSI report configuration(s) for L1-RSRP/L1-SINR reporting.
Proposal 7: On UEI/ED beam reporting in Mode B, regarding priority rules for CSI reports, UEI/ED beam reporting has lower priority than aperiodic beam reporting but higher priority than priority than periodic/semi-persistent beam reporting (i.e., y=0.5).
The above is applied to the CSI report configuration(s) for L1-RSRP/L1-SINR reporting.
Proposal 8: For the multiplexing/dropping rule of the first PUCCH, for the case that the PUCCH carrying 1-bit indication for an UEI/ED beam report configuration is collided/overlapped with a PUSCH, support Option-3 if the PUSCH is not allocated for an UEI/ED beam report configuration. 
If the PUSCH is not for the UEI/ED beam report configuration, UE multiplexes the 1-bit indication into PUSCH; otherwise, the 1-bit indication in the PUCCH is dropped.
Proposal 9: For the multiplexing/dropping rule of the second PUSCH in Mode A, support to reuse the intra-UE multiplexing/prioritization rules of PUSCH for aperiodic CSI reporting.

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

Source:	vivo
Title:	Remaining issues on UE-initiated/event-driven beam management
Agenda Item:	9.2.1
Document for:	Discussion and Decision

Conclusion
For UE-initiated/event-driven L1/L2 beam reporting, we have the following proposals:
Support dynamic update of the measurement RS in the new beam measurement resource set by a new MAC CE.
Based on the agreements, the following TP is proposed.
Support Canidate#1, i.e., when new beam RS is updated by RRC or MAC CE, the counting value of the new beam RS(s) that are not included in the new beam RS set should be reset, and the counting value of the new beam RS is not updated should be maintained.
Support Candidate#6, i.e., when the threshold for event evaluation is reconfigured by RRC signaling, the counting value of all new beam RS(s) should be reset.
Based on the above agreement, the following TP is proposed.
For Event-7, besides N reported new beams, support the introduction of the 1-bit condition met indicator and a bitmap of active TCI states used to indicate which active TCI state(s) could be replaced by reported new beam(s) that meets the event trigger condition.
If UE has not sent any first PUCCH associated with UE-initiated/event-driven beam reporting but receives a PDCCH scheduling a PUSCH to carry a UE-initiated/event-driven beam report, the scheduling DCI may be ignored by UE if no HARQ-ACK or transport block is multiplexed on the PUSCH.
Support Option-2A, i.e., for a first PUCCH transmission occasion, if there is a transmission of another second PUSCH corresponding to the CSI report determined by the same triggering beam(s) as the first PUCCH within a configurable time interval before the first PUCCH transmission occasion, the UE should not transmit the first PUCCH.
Only when the event trigger condition is satisfied, and the associated resource for the second UL channel is available, the corresponding first PUCCH channel can be transmitted in Mode B.
If UE supports the first PUCCH channel and the second UL channel in different PUCCH groups, a new RRC parameter should be introduced to indicate the CC that corresponds to the configured first PUCCH resource(s) in the CSI report configuration(s) in the CC where the RRC parameter is configured. 
When the first PUCCH channel overlaps with the PUSCH in the time domain, the 1-bit PUCCH indication is multiplexed and transmitted on the PUSCH by puncturing regardless of whether the UE-initiated/event-driven beam report procedure is triggered and the information type carried in the PUSCH.
The 1-bit indication is set to “1” when the UE-initiated/event-driven beam report procedure is triggered, otherwise, the 1-bit indication is set to “0”.
The priority index of the first PUCCH indication is 0 and the multiplexing/dropping rule of SR can be reused when the PUCCH carrying the first PUCCH indication overlaps with other UCI with different priority indexes.
When the Type-1 CG PUSCH carrying the beam report in Mode B overlaps with PUSCH with SP CSI in the time domain, the PUSCH with SP CSI should be dropped.
Support reuse of the intra-UE multiplexing/prioritization rules of PUSCH with AP-CSI for the PUSCH with UEI-BR for Mode A.
UE doesn’t expect that the PUSCH with UEI-BR for Mode A overlaps with the PUSCH carrying AP CSI in the time domain.
Support the following TP.
The multiple CSI report configurations associated with the same CSI-AperiodicTriggerState don't have to be associated with the same PUCCH resource for Mode A. 
The report content included in the PUSCH, including the reported RS ID(s) and corresponding measurement results, should be acquired before the corresponding PUCCH indication, regardless of Mode A and Mode B.
In mode A, the transmission slot of the PUSCH should be determined by mapping the TDRI field value to the resource allocation table when the UE receives a DCI scheduling a PUSCH used to carry only UE-initiated/event-driven beam report(s).
In Mode A, the CSI computation time of UE-initiated/event-driven beam report should be optimized.
An available transmission occasion corresponds to a configured PUSCH resource for UEIBR in Mode B that does not overlap with a DL semi-static configured symbol or flexible symbol and does not conflict with a channel of higher priority, such as PRACH.
The minimum value of X in Mode B, i.e., the number of symbol(s) between the last symbol of the first PUCCH indication and the first symbol of the available transmission occasion of the pre-configured CG PUSCH can be {0, 1, …, N}, where the value of N needs further discussion.
To ensure UE can process NW-initiated CSI report and UE-initiated/event-driven beam report orderly, the occupied CPU number and occupation time for the UE-initiated/event-driven beam report should be defined.
If a UE-initiated/event-driven beam report is determined based on the time window-based event evaluation procedure, regardless of Mode A and Mode B,
The number of occupied CPUs is determined based on the number of time windows,
The corresponding CPU(s) are occupied from the RRC configuration of the UE-initiated/event-driven beam report is configured and to the RRC configuration of the UE-initiated/event-driven beam report is released.
For the one-shot event evaluation procedure, regardless of Mode A and Mode B, whether the trigger condition is met or not should be determined based on the latest measurement RS occasion before the CSI reference resource, where the CSI reference resource is determined based on the first PUCCH channel.
Support the following TP.
If a UE-initiated/event-driven beam report is determined based on the one-shot event evaluation procedure, regardless of Mode A and Mode B,
The number of occupied CPUs is 1;
the first symbol of the earliest one of each CSI-RS/SSB resource for UE-initiated/event-driven beam reporting, respectively latest CSI-RS/SSB occasion no later than the corresponding CSI reference resource.
If a UE-initiated/event-driven beam report is determined based on the one-shot event evaluation procedure and configured with Mode A,  the occupied time of the corresponding CPU ends at the last symbol of a duration after the first PUCCH channel if UE does not detect the PDCCH scheduling a PUSCH to carry the beam report within the duration, or end at the last symbol of the PUSCH carrying the beam report if the PDCCH is detected within the duration.
If a UE-initiated/event-driven beam report is determined based on the non-time window-based event evaluation procedure and configured with Mode B, the occupied CPU for the UE-initiated/event-driven beam report is released at the last symbol of the CG-PUSCH occasion carrying the UE-initiated/event-driven beam report.

3GPP TSG RAN WG1 #121																     R1-2503433
Malta, MT, May 19th – 23rd, 2025


Agenda Item: 		9.2.1
Source:				InterDigital, Inc.
Title:						Remaining Details of Rel-19 UE/Event-Driven Beam Management
Document for: 		Discussion and Decision

Conclusions
In this contribution, we presented and discussed our views on this topic, including discussions on event definition, UL signaling contents, and UL signaling medium. Based on the presented discussion, we make the following observations and proposals:

Observation 1: For the agreed Event-2 (indicated TCI-state as a current beam), it is observed that the main use case of Event-2 is for the indicated TCI-state switching, e.g., among a set of activated TCI-states.

Proposal 1: For the agreed Event-2, to reduce UE measurement complexity, support an additional configuration choice such that the RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s) as a dynamic update way along with the existing TCI-activation command.

Observation 2: The agreed association between one PUCCH resource and one or multiple CSI report configurations is for the same event, e.g., Event-2, where it is for obtaining the configuration flexibility such as the cross-carrier UEIBR case.

Proposal 2: Regarding concurrent events, to enable event identification at the gNB, support association of different PUCCH resources with different event combinations, where each PUCCH resource is linked to a different CSI report configuration and the UE uses the PUCCH resource for the first channel transmission upon the event triggered.

Observation 3: Configuration for UE-driven beam management can include a resource setting such as a set of RSs to measure on, event cases, and corresponding thresholds, where a type of reporting content, e.g., quality metric, can also be configured to the UE for each event case.

Proposal 3: Support flexible UE-driven beam reporting configuration for each target event case by configuring corresponding resource settings, thresholds, reporting contents including a flag for the corresponding event.

Observation 4: Upon detecting an event where a UE generates reporting information about the determined event, the UE needs to report this information quickly after detecting the event, as the UE requires a network action before entering beam failure or radio link failure.

Proposal 4: Support a maximum duration parameter to be configured to a UE, where upon satisfaction of a triggering event
if the UE finds an available UL resource among pre-configured resources within the maximum duration, the UE transmits the beam reporting using the available UL resource.
Otherwise, a contention-based transmission can be used for the UE-initiated beam reporting.

Observation 5: The first UL channel as a new UCI type for both Mode-A (dynamically scheduling UCI by gNB) and Mode-B (UCI in pre-configured resource(s) for second UL channel) should be allowed to be retransmitted by the UE based on a rule similar to the case of existing SR.

Proposal 5: Support retransmissions of the first UL channel, analogous to the case of existing SR, where UE can re-transmit the first UL channel unless a prohibit timer is running, according to the max allowed number of re-transmissions, if an appropriate second UL channel resource is not indicated.
Support Option-1B: At the first symbol after the end of the first PUCCH transmission, the UE starts the prohibit timer

Observation 6: At least for the UE-initiated beam reporting via the second UL channel, it is beneficial to introduce at least a confirmation mechanism to respond to the UE’s beam reporting on whether gNB successfully received it or not. If the UE receives the acknowledge information, no retransmission is performed by the UE.

Proposal 6: Support at least a confirmation mechanism to respond to the UE-initiated beam reporting on whether gNB successfully received the reporting, where receiving a DCI updating an indicated TCI state can be regarded as such an acknowledge information in response to the transmitted UEIBR.

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

Agenda Item:     9.2.1
Source:	Spreadtrum, UNISOC
Title:	             Discussion on UE-initiated/event-driven beam management
Document for:	Discussion and decision

Conclusion 
In this contribution, we provide our proposals on the UE-initiated/event-driven beam management:
Proposal 1:
Support Candidate #1 for triggering event determination for Event-2, i.e. the RS reconfiguration/update for new beam is received. 
Maintain the counting whose new beam is not updated.
Proposal 2:
It is not necessary to introduce MAC CE to update new beam RS in Candidate #1.
Proposal 3:
Regarding triggering event determination for Event-1, the Event instance counting is for current beam.
Proposal 4: 
On resetting the counting for Event-1, support modifying Candidate #2 as follows
Candidate #2: the measured current beam based on the indicated TCI state is updated.
In such case, the UE needs to reset the counting for current beam.
Proposal 5:
Regarding triggering event determination for Event-7, the Event instance counting is per new beam.
Proposal 6:
On resetting the counting per new beam for Event-7, support modifying Candidate #1 and Candidate #2 as follows
Candidate #1: RS reconfiguration/update for new beam is received. 
Maintain the counting whose new beam is not updated.
Candidate #2: the measured current beam RS is updated based on the activated TCI state with Q-th best quality.
In such case, the UE needs to reset the counting for all new beams.
The activated TCI state with Q-th best quality is determined up to UE implementation.
Proposal 7:
Similar to the report format of Event-2, support introducing the 1-bit condition met indicator for Event-7.
Proposal 8:
Similar to Event-2, one PUCCH resource of first PUCCH can be associated with one or multiple CSI report configurations for Event-1 and Event-7.
Proposal 9:
When multiple CSI report configurations are associated with different event respectively, if multiple UE initiated beam report procedures occur, the UEI beam report with higher priority is reported, where the priority is based on event type, e.g. Event-2>Event-1>Event-7.
Proposal 10:
Support configuring one CSI report configuration associated with a single RS resource set for multiple events to reduce the overhead of RS resource and configuration signaling.
Proposal 11:
When one CSI report configurations is associated with multiple events, 
if an event occurs, the event ID corresponding to the occurred event is carried in UEI beam report,
if multiple events occur, the event ID corresponding to the event with highest priority is carried in the UEI beam report.
Proposal 12:
Support Option-4 when the first PUCCH is collided/overlapped with a PUSCH, i.e. reuse the SR dropping rules and the first PUCCH is dropped.
Proposal 13:
The UE initiated beam report should have a higher priority than the legacy CSI report.
Proposal 14:
Define the number of CPUs and the CSI computation time for the UE initiated beam management as follows:
OCPU=1,
the UE initiated beam report occupies CPU(s) from the first symbol after the RRC configuring the report until the last symbol of the second PUSCH carrying the report.

3GPP TSG RAN WG1 #121			   R1-2503554
St. Julian’s, Malta, May 19th – 23rd, 2025
Agenda item:	9.2.1
Source: 	Samsung
Title: 	Views on Rel-19 UE-initiated/event-driven beam management 
Document for:	Discussion and Decision

Conclusions 
In this contribution, we provide our views on various design aspects related to Rel-19 UE-initiated beam reporting. In particular, we present the following proposals and observations focusing on event(s) and the corresponding triggering condition(s), measurement RS(s) configuration/determination for the Event-2, UL signaling content(s)/report format(s) and UCI based UL signaling procedure(s) designs:

Observation 1: For a new beam RS of a CSI report configuration, there can be multiple determined time windows before a PUCCH transmission occasion, where 
The multiple determined time windows are not overlapping in time domain.
The number of instances for one same new beam may or may not greater than or equal to a configurable number M within a time window
The UE should store the evaluation results for the multiple determined time windows to decide whether to transmit a first PUCCH.

Observation 2: The end of a time window with a number of instances for one same new beam being no less than M should not be far before the first PUCCH transmission to ensure real-time indication of UEI-BR.

Proposal 1: For a CSI report configuration, if a UE determines that a number of event instances for one same new beam is no less than M within a time window, the UE transmits the first PUCCH in an earliest transmission occasion T_proc after the end of the time window, where T_proc is configured by higher layer signalling.

Proposal 2: For determining an event instance for Event-1 and Event-2, the measured occasions for the current beam RS and the new beam RS(s) should be within the same periodicity.

Proposal 3: For a single CC case and for a UEI-BR carried in a second PUSCH of a CSI report configuration, the current beam RS is the same as the RS derived by the TCI state indicated in a latest PDCCH before a first PUCCH associated with the second PUSCH.

Proposal 4: For a multi-CC case and for a UEI-BR carried in a second PUSCH of a CSI report configuration, the current beam RS is the same as the RS derived by the TCI state, indicated in a latest PDCCH, for the serving cell of the new beam RS, where the latest PDCCH is before a first PUCCH associated with the second PUSCH. 

Observation 3: Regarding triggering event determination for Event 2, other candidates than Candidate #2 do not have immediate impact on event evaluation.

Proposal 5: Based on Observation 2, deprioritize selection/determination of other candidate(s) than Candidate #2 for resetting the counting.

Observation 4: Retransmission of the first PUCCH cannot ensure the real-time indication of the UEI-BR.

Proposal 6: Do not support retransmission of the first PUCCH for both Mode A and Mode B.

Proposal 7: Do not support prohibit timer.

Proposal 8: Regarding the RS periodicity for Event determination, 
For Event-2, do not support different periodicities of the current beam RS and the candidate/new beam RS(s).
For Event-1, only support the same periodicity of the current beam RS and the candidate/new beam RS(s).
For Event-7, only support the same periodicity of measured occasions for the RS(s) associated with all activated TCI state(s) and the candidate/new beam RS(s).
Observation 5: Supporting counting more than one event instance for evaluating or determining Event-7 could (1) increase the measurement latency, which is not aligned with the objective of the WID for latency reduction, and (2) complicate UE’s implementations.

Proposal 9: Do not support counting more than one event instance for evaluating or determining Event-7.

Proposal 10: On UE-initiated/event-driven beam reporting, support inter-cell SSBs (associated with the serving cell PCI or PCI(s) other than the serving cell PCI) as current beam RSand candidate beam RS(s) for event evaluations.

Proposal 11: Regarding explicit RS configuration for candidate beam measurement in evaluating Event 2 (Option-1 in the RAN1#118 agreement), do not support updating the RS in the RS resource set by a new MAC CE.

Proposal 12: Regarding Event 2 evaluation, a UE can be enabled to evaluate the L1-RSRP(s) of the RS(s) in the RS resource set (as in Option-1) that has the same value(s) as the RS(s) in the activated TCI state(s) as the candidate beam measurement results.

Observation 6: For a given current beam of a serving cell, measuring a subset of surrounding new beams can be beneficial for latency reduction.

Proposal 13: For a given current beam of a serving cell, support current beam specific measurement for UEI-BR. The following options can be further considered,
Option 1: Multiple CSI report configurations where each configuration corresponds to a current beam RS
Option 2: One CSI report configuration consists of multiple sets of new beam RSs where each set 
corresponds to a current beam RS

Proposal 14: On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 of Event-2, if N is not provided by RRC, only one L1-RSRP and CRI/SSBRI are reported. 

Proposal 15: For a first PUCCH transmission occasion for both Mode A and Mode B, if there has already been transmission(s) of another first PUCCH(s) within a time window associated with the first PUCCH transmission occasion, the UE would not transmit the first PUCCH.

Proposal 16: Regarding Mode B, the RRC configured value X symbols for determining the first available transmission occasion of the second UL channel after sending the last symbol of report notification on the first PUCCH channel to carry the actual UEI beam report is subject to a corresponding UE capability.
X is based on the SCS of PUCCH.
Proposal 17: For Mode A, the UE multiplexes the UEI-BR of a CSI report configuration in the PUSCH indicated by a DCI format in a PDCCH reception if the PDCCH reception starts no earlier than T after the end of the first PUCCH transmission associated with the same CSI report configuration.

Proposal 18: For Mode-A, further study the measurement window for UEI reporting content.

Proposal 19: Regarding UEI-BR processing timeline for Mode A, the legacy A-CSI reporting timeline as defined in TS 38.214 clause 5.4 should be supported as baseline and the legacy UL-SCH preparation time as defined in TS 38.214 clause 6.4 should be supported based on additional UE capability.

Proposal 20: On beam report transmission procedure for UE-initiated/event-driven beam reporting,
For the case where the first PUCCH is collided/overlapped with a PUSCH, support Option-3, i.e., the 1-bit indication of first PUCCH is multiplexed into the PUSCH.
Support joint coding with HARQ-ACK by appending the UEIRI to HARQ-ACK information bits.
Proposal 21: On beam report transmission procedure for UE-initiated/event-driven beam reporting,
The PHY priority of PUCCH is determined as the same rule for SR and the PUSCH and PUCCH resources are of the same PHY priority.
Reuse Rel-16 rules for prioritization for UL overlapping channels with different PHY priorities. 
Observation 7: The intra-UE multiplexing/prioritization rules of PUSCH with A-CSI can be reused for PUSCH with UEI-BR for Mode A.

Proposal 22: RAN1 to conclude to reuse the intra-UE multiplexing/prioritization rules of PUSCH with A-CSI for PUSCH with UEI-BR for Mode A.

Proposal 23: On cross-CC beam report measurement for UE-initiated/event-driven beam reporting, regarding Event-2, clarify condition(s) of not providing the RRC parameter to indicate the CC in which the indicated TCI state is applied.

Observation 8: There is no clear motivation to support an indication of the cell that corresponds to the configured first PUCCH resource in CSI report config.

Proposal 24: For the determination of a priority value of a UEI-BR, in case of a PUCCH resource is associated with only one CSI report configuration 
For UEI-BR for Mode A, reuse the same rule for AP CSI report 
For UEI-BR for Mode B, reuse the same rule for SP CSI report on PUSCH
Observation 9: In case of the same PUCCH resource is associated with multiple CSI report configurations, NW may not know which CSI report is transmitted if the UEI-BR overlaps with another CSI report if the priority value of a UEI-BR is based on the reported CSI report configuration.

Proposal 25: In case of the same PUCCH resource is associated with multiple CSI report configurations, a priority value of a UEI-BR is determined by the CSI report configuration with highest priority from the multiple CSI report configurations.

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

Agenda Item:	9.2.1
Source:	Ericsson
Title:	Remaining issues for UE-initiated beam management 
Document for:	Discussion
1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	When a UE is scheduled using DCI format 0_3, the UCI is transmitted on one of the scheduled cells.
Observation 2	Candidates #1 and #2 directly address the WID objective on overhead reduction.
Observation 3	In legacy, the UE may drop the SR also when no UL data can be transmitted.
Observation 4	The performance of a UEIRI multiplexed into a PUSCH is unclear.
Based on the discussion in the previous sections we propose the following:
Proposal 1	The event instance counting is reset for all new beams when the parameters associated with event-driven reporting are reconfigured.
Proposal 2	The event instance counter is reset when the timer expires.
Proposal 3	The UL-grant DCI format comprises DCI format 0_1/0_2/0_3.
Proposal 4	Support option-1A: In the case that triggering-event associated with the CSI report configuration is determined [by the same triggering beams(s) as the last transmitted PUCCH], if the prohibit timer is NOT running, the UE can transmit first PUCCH; - At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer
Proposal 5	When only UEIRI PUCCH resource overlaps with a PUSCH (i.e. no overlapping CSI and/or A/N PUCCH resources), if a UEIRI collides with a PUSCH, the UEIRI is dropped.
Proposal 6	For the case where UEIRI overlaps with HARQ-ACK or CSI on PUCCH format 3 or 4, append  to the PUCCH carrying HARQ ACK/NAK or CSI.
Proposal 7	For the case where UEIRI overlaps with SR/LRR and HARQ-ACK or CSI on PUCCH format 2, 3 or 4, append  to the PUCCH carrying HARQ ACK/NAK or CSI.
Proposal 8	The report triggered in step-2 of mode A reuses properties from a normal aperiodic beam report, when it comes to configuration, CSI processing criteria and report priorities.
Proposal 9	The UE sends the step-2 beam report of mode A in response to the CSI request from the NW even when no event has occurred.

3GPP TSG RAN WG1 Meeting #121	R1-2503668
St Julian’s, Malta, May 19th – 23rd, 2025
Source:	ZTE Corporation, Sanechips
Title:	Discussion on enhancements for UE-initiated/event-driven beam management
Agenda Item:	9.2.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss the potential candidate solutions to support UE-initiated beam management with the following proposals and text proposals.
Proposal 1: Regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH for the Case-2 that the 1-bit first PUCCH is collided/overlapped with a PUSCH, support Option-3 that piggyback 1-bit indication of first PUCCH into the PUSCH.
The 1-bit indication is always multiplexed in the PUSCH, regardless of whether UEI beam report procedure is triggered or not.
Proposal 2: Regarding the multiplexing/dropping rule(s) in case that the 1-bit first PUCCH with PUCCH format 0 is collided/overlapped with a PUCCH format 0 carrying HARQ-ACK information, support that the PUCCH resource of the 1-bit first PUCCH is transmitted based on legacy cyclic shift values.
Proposal 3: Regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH for the Case-5 that the 1-bit first PUCCH is overlapped with a PUCCH format 2/3/4 carrying HARQ-ACK information and/or CSI report(s), support to multiplex the 1-bit indication with the HARQ-ACK information and/or legacy CSI report via a UCI bit sequence.
The UCI bit sequence generation reuses the legacy rule for SR with the following modification.
The UCI bit sequence is generated based on a first ascending order of the values of SR ID associated with the SRs and a second ascending order of the values of PUCCH resource ID associated with the first PUCCHs.
The UCI bit sequence is to indicate a positive/negative SR or UEIRI.
Proposal 4: Regarding collision handling in case that legacy CSI reports and UEI beam reports are overlapped, support the following priority rule.
UEIBR configured with Mode A > UEIBR configured with Mode B > AP CSI report > SP CSI report on PUSCH > SP CSI report on PUCCH > P CSI report.
Proposal 5: On beam report transmission procedure for UE-initiated/event-driven beam reporting in both Mode-A and Mode-B, support Option-1A without the condition in the bracket.
In the case that triggering-event associated with the CSI report configuration is determined, if the prohibit timer is NOT running, the UE can transmit first PUCCH.
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer.
Proposal 6: Regarding triggering event determination within a time window for Event 2, on condition(s) of resetting the counting of trigger event instances, support Candidate#3 and Candidate#7. 
Candidate#3: UEI beam report is transmitted.
Candidate#7: The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured.
RRC parameter(s) at least include RS configuration for new beam and the threshold for event evaluation.
Proposal 7: Regarding UE-initiated/event-driven beam reporting procedure, supports that UE transmits first PUCCH and second PUSCH based on a new beam-specific report triggering status indicator.
UE determines UEI report triggering being pending for a new beam RS when the counter of event instances determined for the RS is greater than eventInstanceCount-r19.
UE transmits the first PUCCH and the second PUSCH when UEI report triggering is pending for at least one reference signal corresponding to UEI report configuration(s) associated with the first PUCCH and second PUSCH. 
UE cancels UEI report triggering for a reference signal after UE transmits a CSI report including fields for the reference signal.
Proposal 8: Regarding report timeline for a UE initiated beam report in both Mode-A and Mode-B, support the following rules.
UE can transmit the first PUCCH if the first uplink symbol of the first PUCCH starts no earlier than an uplink symbol starting after the end of the last symbol of the CSI-RS resource occasion.
CSI reference resource for a UEI-CSI report is defined to be a downlink slot with reference to the uplink slot in which the first PUCCH is transmitted. 
UE can transmit the UEI-CSI report in a PUSCH if the PUSCH occasion satisfies the PUSCH processing time.
Legacy definition on number of occupied CPUs and activate CSI-RS resources are reused.
Proposal 9: Regarding the UL reserved/configured-grant resources used as uplink signaling container for UE-initiated//event-driven report (e.g., first PUCCH in both modes and Type-1 CG PUSCH in Mode-B), support that transmission occasion for reserved UL resource (as an indispensable part for UL signal medium/container) can be updated simultaneously via indicated TCI state to balance dynamic beam update and NW resource overhead.

Text proposal 1: To adopt the following changes in section 9.2.5.1 in TS 38.213.
Text Proposal 2: To adopt the following changes in section 9.2.5.1 in TS 38.213.
Text Proposal 3: To adopt the following changes in section 5.2.5 in TS 38.214.
Text Proposal 4: To adopt the following changes in section 5.2.1.5.4.1 in CR 38.214.
Text Proposal 5: To adopt the following changes in section 6.3.1.1.2 in CR 38.212.

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

Agenda item:		9.2.1
Source:		Ofinno
Title:			Discussion on UE-initiated/event-driven beam management
Document for:	Discussion and Decision

Conclusion
This contribution has discussed the remaining issues related to the physical layer aspects of UE-initiated/event-driven beam management. The following are our observations and proposals: 
Proposal 1. Regarding the triggering event determination for Event 2, in addition to Candidate #2, the following conditions are supported for resetting the counting:
Candidate#1: RS reconfiguration/update or MAC-CE signaling (if supported) for new beam is received:
Reset a new beam removed by the RS reconfiguration/update (the new beam not in the updated list any longer).
Do not reset a new beam in both old and new list (the new beam is not changed in the updated list).
Start counting for a new beam added to the list (the new beam not in the updated list).
Candidate#3 Transmission of UE-initiated CSI report
Only reset the counting of new beams fulfilling triggering condition and reported by the UEI beam report.
Candidate#5: The time window expires
Candidate#6: The threshold for event evaluation is re-configured by RRC signaling
Candidate#7: The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured:
The RRC parameter(s) include at least time window and maximum event instance count.
Proposal 2. The following conditions can be considered for cancellation of a triggered UE-initiated/event-driven beam reporting for Event 2:
Update of the indicated TCI state
Transmission of UE-initiated CSI report 
BWP switching
Proposal 3. Regarding the triggering event determination for Event 1 and Event 7, the following conditions can be considered for resetting the counter for Event 1 and Event 7:
For Event 1: Update of the indicated TCI state
For Event 7: Update/change of the activated TCI state with the Q-th best quality
In Event 7, the event instance(s) counting is per new beam.
Proposal 4. Specify necessary enhancements to address beam failure recovery when UE is configured with UE-initiated/event-driven beam report procedure at least based on Event 1 or Event-2. 
For example, the UE-initiated/event-driven beam report procedure is not performed (or is suspended) during an ongoing beam failure recovery procedure. (e.g., no condition evaluation, no first PUCCH and/or second PUSCH transmissions) until the beam failure recovery is completed. 
Proposal 5. Specify UE behavior of UE-initiated/event-driven beam report procedure (e.g., condition evaluation, first PUCCH transmission, second PUSCH transmission, and so on) from a completion of a beam failure recovery procedure until the indicated TCI is updated.
Option 1: the UE-initiated/event-driven beam report procedure is not performed (or is suspended) until a new TCI state is indicated.
Option 2: The candidate beam of the beam failure recovery is used for current beam in UEBIR. 
Proposal 6. The current beam RS is further clarified as follows.
The current beam RS is the same as the RS derived by the latest applied indicated TCI state before the first PUCCH associated with the second PUSCH.
Proposal 7. On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format of Event-2, if N is not configured by RRC, only one L1-RSRP and CRI/SSBRI are reported by default. 
Proposal 8. For Mode-A, the multiple CSI report configuration associated with the same CSI-AperiodicTriggerState should be associated with a same PUCCH resource.
Proposal 9. Periodic PUCCH resource configuration (e.g. firstPUCCHResourceConfig-UEIBR) is configured with a priority index to handle PHY prioritization/multiplexing of the first PUCCH transmission.
If the priority index of the periodic PUCCH resource configuration for the first PUCCH is not configured, it is assumed as zero. 
Proposal 10. On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, support Option 3 for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH, 
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH if the PUSCH is with UL-SCH or not for UEI beam report, otherwise drop the 1-bit first PUCCH.
Proposal 11. Support introducing a prohibit timer for mode-A and mode-B.
At the first symbol after the end of the first PUCCH transmission, the UE starts the prohibit timer.
Proposal 12. On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) the 1-bit first PUCCH is collided/overlapped with a PUCCH format 2/3/4 carrying HARQ/CSI/SR, support option 1.
Option-1: To follow legacy SR multiplexing rule.
Proposal 13. On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-B, the value of X symbols is determined based on one of the following:
Alt1: subcarrier spacing of the CC of the first PUCCH.
Alt2: subcarrier spacing of the CC of the second PUSCH.
Alt3: Smallest or largest subcarrier spacing among subcarrier spacings of the CC of the first PUCCH and the CC of the second PUSCH.
Proposal 14. On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A, reuse the multiplexing rules of PUSCH with aperiodic CSI report for PUSCH with UE-initiated CSI report. 
For PUSCH repetition Type B, when a UE is scheduled to transmit a transport block and UE-initiated CSI report(s) on PUSCH by a 'CSI request' field on a DCI, the CSI report(s) is multiplexed only on the first actual repetition.
When a DCI format 0_1 schedules two PUSCH allocations, the UE-initiated CSI report is carried on the second scheduled PUSCH. When a DCI format 0_1 schedules more than two PUSCH allocations, the UE-initiated CSI report is carried on the penultimate scheduled PUSCH.
Proposal 15. RAN1 agrees to support one of the following approaches to ensure that the UE can transmit the first PUCCH and/or second PUSCH for UEI-based CSI reporting:
Option 1: If the required resources for the first PUCCH and/or second PUSCH are not configured in the active UL BWP(s), the UE is required to perform BWP switching to an UL BWP where the first PUCCH and/or second PUSCH are configured. 
Option 2: The CSI report configuration for UEIBM is configured with a set of first PUCCH and/or second PUSCH resources, one per UL BWP, such that the UE can perform the reporting within the active UL BWP without requiring BWP switching
Option 3: If the required resources for the first PUCCH and/or second PUSCH are not configured in the active UL BWP(s), UE does not perform event-instance evaluation.
Proposal 16. On cross-CC beam report measurement for UE-initiated/event-driven beam reporting, regarding Event-2, introduce an RRC parameter to indicate one from {SpCell, PUCCH-Scell} as the cell of the configured PUCCH, and indicate the corresponding UL BWP ID.
Observation 1. Alt-2 may require less capability of UE to store QCL properties than Alt-1/3.
Observation 2. Alt-1 may have a risk of an unsynchronized set of activated TCI states between the UE and the gNB.
Observation 3. It may be worth clarifying a time window that UE expects to receive a MAC CE after a UEIBR report has been transmitted.
Proposal 17. Support:
Alt-3 subject to additional UE capability (e.g., UE can store the QCL properties)
If no MAC CE is received within the time window, UE is allowed to flush the stored QCL properties 
Alt-2 as a default option.

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

Source:	CATT
Title:	Remaining issues on UE-initiated/event-driven beam report
Agenda Item:	9.2.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on the enhancements for UE-initiated beam report, including triggering events, RS resources used for beam measurement, UL report container and cross-CC configuration. We have the following proposals:
Proposal 1: Regarding the evaluation periodicity for determining Event-2 instance, Alt-2_4: The evaluation periodicity is the maximum of {X ms, shortest periodicity of the current beam RS and new beam RS(s)} is also supported.
Proposal 2: Regarding triggering event determination for Event-2, besides candidate#2, support the following candidates for resetting the counting:
Candidate#1: RS reconfiguration/update or MAC-CE signaling (if supported) for new beam is received;
Reset the counter corresponding the removed new beam RS and maintain the counting whose new beam is NOT updated.
Candidate#5: The time window expires
Reset the counter corresponding to the associated new beam.
Candidate#6: The threshold for event evaluation is re-configured by RRC signaling
Proposal 3: Regarding triggering event determination for Event-1, besides candidate#2, support the following candidates for resetting the counting:
Candidate#5: The time window expires
Reset the counter corresponding to the associated new beam.
Candidate#6: The threshold for event evaluation is re-configured by RRC signaling.
Proposal 4: Regarding triggering event determination for Event-7, do not support candidates#2 for resetting the counting.
Proposal 5: Regarding triggering event determination for Event-7, support the following candidate for resetting the counting:
Candidate#8: The measured RS derived from the activated TCI state is updated. 
Proposal 6: Regarding triggering event determination for Event-7, support the following candidates for resetting the counting:
Candidate#1: RS reconfiguration/update or MAC-CE signaling (if supported) for new beam is received;
Reset the counter corresponding the removed new beam RS and maintain the counting whose new beam is NOT updated.
Candidate#5: The time window expires
Reset the counter corresponding to the associated new beam.
Candidate#6: The threshold for event evaluation is re-configured by RRC signaling.
Proposal 7: Regarding explicit RS configuration for new beam management for Event-2, support updating the RS resources in the RS resource set for new beam by MAC-CE.
Proposal 8: On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH for Case-2, support Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
Proposal 9: When one PUCCH resource of first PUCCH is associated with one or multiple CSI report configurations, and if multiple UE initiated beam report procedures occur, support to report an Event-ID associated with CSI report configurations to distinguish between the different CSI report configurations.
Proposal 10: On beam report transmission procedure for UE-initiated/event-driven beam reporting for CSI report configuration, support the modified candidate#1, option-1A, i.e.:
Candidate#1: To introduce a prohibit timer for mode-A and mode-B
Option-1A: In the case that triggering-event associated with the CSI report configuration is determined, if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer.
Proposal 11: On cross-CC beam report measurement for UE-initiated/event-driven beam reporting, regarding Event-2, introduce an RRC parameter to indicate the cell that corresponds to the configured first PUCCH resource in CSI report config. 
Proposal 12: Regarding the evaluation periodicity for determining Event-2 instance for cross-CC configuration, Alt-2_4: The evaluation periodicity is the maximum of {X ms, shortest periodicity of the current beam RS and new beam RS(s)} is supported.

3GPP TSG-RAN WG1 Meeting #121	R1-2503816
Malta, May 19 – May 23, 2025

Source:	Panasonic
Title: 	Enhancements for UE-initiated/event-driven beam management 
Agenda Item:	9.2.1
Document for:	Discussion

Conclusions
Based on the discussion above, we propose the following:
A trigger from a NW perspective carries only information about 
the type of event that occurred and 
the CSI-ReportConfig that triggered this event (the latter is inferred from the assigned “first PUCCH” resources used for notifying the NW). 

Within the new beam set in a CSI-reportConfig, the UE declare an event at the following time instance:
Option 1: at the time the first beam in the set meets the event triggering criterion. 
Option 2: at the time the latest beam before the occurrence of the upcoming “first PUCCH” meets the event triggering criterion. 
Option 3: based on a certain priority between all the triggers invoked by the new beam set. 
Within a CSI-reportConfig, after an event has been triggered, the event trigger expires according to one or more of the following options:
Option 1: an event trigger expires after a timer or counter expires, where the counter or timer is started when the event is triggered. FFS: other timer definitions
Option 2: an event trigger expires after the UE transmits the 1-bit notification on the “first PUCCH”. 
Option 3: an event trigger expires after the UE transmits the corresponding UE-initiated beam report on the “second PUSCH.” 

When the event trigger has not expired yet, the UE notifies the NW about the event on the upcoming “first PUCCH” for both modes A and B. 
 
Regarding triggering event determination for Event 2, the following are supported for resetting the counting.
Candidate#1: RS reconfiguration/update or MAC-CE signaling (if supported) for new beam is received;
			FFS: whether to reset the counting for all new beams.
			FFS: whether to maintain the counting whose new beam is NOT updated.
Candidate#5: The time window expires
Candidate#6: The threshold for event evaluation is re-configured by RRC signaling

Do not support MAC-CE update of the RS(s) for new beam measurement. 
Panel switching information should be also reported for UEs with multiple panels. 
On UE-initiated/event-driven beam reporting, the UE decides whether the ‘1-bit’ indicating whether for a particular beam the Event-2 instances doesn’t reach the configured number M according to the following monitoring window:  
Option 1: The UE decides this field at the time of triggering of the event 2. 
Option 2: The UE decides this field at the time reporting the trigger on PUCCH (subject to a time gap with respect to first PUCCH). 
Option 3: The UE decides this field at the time of transmitting the report on PUSCH (subject to a time gap with respect to second PUSCH). 

After first detection of an event based on a specific CSI-ReportConfig, the UE uses measurements up to the “second PUSCH” following the “first PUCCH” where the corresponding trigger has been sent, where the minimum time gap between the CSI report compilation and the second PUSCH is up to a UE capability. 
Study whether/how to support the configuration of multiple events simultaneously and if needed determining the priority order of the events reporting. 
Mode A and Mode B are not configured together. If simultaneous configuration together is supported, then multiple CSI-ReportConfig can be associated with the same PUCCH resource but distinct for Modes A and Mode B.
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH, support:
Option-1: Prioritize first PUCCH over PUSCH, i.e., PUSCH is dropped.
When the UE receives the DCI with a CSI request that matches the CSI-ReportConfig which the UE is using for reporting, the UE can use this as an Ack for the success of step 1. Otherwise, the UE can retransmit step 1. 
For Mode A reporting, the UE should be configured with a first timer that it starts after sending the request bit in step 1 on PUCCH. If the UE does not receive a scheduling DCI for the requested UE-initiated beam reporting in Step 1 before the timer expires, the UE retransmits step 1. 
For Mode A reporting, when the UE transmits step 1, the UE starts the second timer, which was configured before. If the UE sends the report in step 3, and did not receive a CSI retransmission request from the NW by the time this timer expires, the UE is not required to store the report contents and does not report the triggering event anymore.
Regarding reporting mode B when the pre-configured Type-1 CG PUSCH does not carry the beam report, legacy procedure is followed where the NW can schedule dynamic grant UL transmission on the pre-configured Type-1 CG PUSCH for UE-initiated beam reporting. 
UE is not expected to multiplex UE-initiated beam report with the dynamic grant UL transmission for reporting mode B.
Study whether to allow the retransmission of the report for Mode B and whether a timer for mode B is needed after the transmission of the request bit on PUCCH.
Support a prohibit timer for mode A (Candidate #1 – Option 1C). 
Do not support any prohibit timer for mode B.
We support an event expiration timer for both mode A and B that enables the UE to stop reporting the event.  
N ≥ 0 beam(s) are reported in the report instance where the candidate value of ‘N’ at least comprises {0,1, 2, 3, 4}. The new beams reported are beams that are above a certain threshold. When N=0, the UE only transmits step 1 in Modes A and B.
Regarding the triggering event determination for Event 1:
If within a time window (which is configurable), the number of Event-1 instance(s) is greater than or equal to a configurable number M, UE initiated beam report occurs.

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

Agenda item:	9.2.1
Title:	Discussion on enhancements for UE-initiated/event-driven beam management
Source:	CMCC
Document for:	Discussion and Decision

1. 

Conclusion
Based on the above discussions, the proposals are as follows:
Proposal 1: Regarding triggering event determination for Event 2, support the following condition(s) of resetting the counting:
Candidate#7: The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured.
In such case, for RRC parameters, this may include: the event thresholds, the length of the time window, and the maximum counting number M.
Proposal 2: For Event-2, on beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, support the Option-1 of Candidate1.
Proposal 3: Regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, support Option-1: Prioritize first PUCCH over PUSCH, i.e., PUSCH is dropped.
Proposal 4: For Event-7, the definition and processing rules of its 1-bit indicator should remain completely consistent with those of Event-2.

5. 

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

Agenda Item:	9.2.1
Source:	Xiaomi 
Title:                     Discussion on enhancements for UE-initiated/event-driven beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss about UE initiated/event-driven beam reporting. Based on above discusses, we provide the following proposals.
Proposal 1: For resetting the counting, support the following candidates with revision.
Candidate#1: RS reconfiguration/update for new beam is received;
reset the counting for all new beams.

Candidate#5: The time window expires
Candidate#6: The threshold for event evaluation is re-configured by RRC signaling
Proposal 2: To derive the UEI beam report, L1-RSRP should be based on the measurement results of the latest instance before CSI reference resource.
Proposal 3: The time window used to determine ‘1-bit’ condition met indication needs to be specified or reported by UE if there are multiple time windows before 1st PUCCH/2nd PUSCH.
Proposal 4: If the time gap between the Mth time instance and the 1st PUCCH is larger than X symbols, the 1st PUCCH will be not triggered.
Proposal 5: In order to reduce the retransmission number of the beam report, support candidate#1 with Option-1A for both mode-A and mode-B and support Option-1B for mode-A.
Proposal 6: For Mode-A, the multiple CSI report configurations associated with the same CSI-AperiodicTriggerState should be associated with a same PUCCH resource.
Proposal 7: Support Option 3 when the 1-bit first PUCCH is collided/overlapped with a PUSCH, i.e., Piggyback 1-bit indication of first PUCCH into the PUSCH.
Proposal 8: UEI BR occupation time can be defined as following:
For mode A, 
Part 1: time from the first symbol after PDCCH to the last symbol of PUSCH carrying beam report. 
Part 2: for other transmission occasions, the CPU occupation time starts from the first symbol of the earliest one of each CSI-RS/SSB resource and ends at the N1 symbols after the last symbol of the last one of each CSI-RS/ SSB resource.
For mode B, 
Part 1: for the latest transmission occasion before the reference resource, the CPU occupation time starts from the first symbol of the earliest one of each CSI-RS/SSB resource and ends after the PUSCH resource carrying beam report. 
Part 2: for other transmission occasions, the CPU occupation time starts from the first symbol of the earliest one of each CSI-RS/SSB resource and ends at the N1 symbols after the last symbol of the last one of each CSI-RS/ SSB resource.
Proposal 9: The priority of UEI BR can be higher than normal aperiodic beam report.

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

Agenda Item:	9.2.1
Source:	Lenovo
Title:	Enhancements for UE-initiated/event-driven beam management
Document for:	Discussion

Conclusion
In this contribution, we provide the following proposals: 

Proposal 1: Support Option-3 when the 1-bit PUCCH is collided/overlapped with a PUSCH.
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
Proposal 2: Support Candidate#3 that no further enhancement is needed for the first PUCCH transmission.
Proposal 3: Support NW’s acknowledgement with response to the PUSCH carrying the beam report.
Proposal 4: Regarding UL signaling content for Event 1 and Event-7, the UE can be indicated to report N new beam(s) as well as the L1-RSRP of the current beam.
Proposal 5:  For Event-1, the NW can indicate the UE to additionally report the number of Event-1 instances between the latest two first PUCCH resources in the corresponding beam report according to UE capability.
Proposal 6:  For Event 7, the NW can indicate the UE to additionally report the beam quality of all the activated TCI states in the beam report according to UE capability.
Proposal 7: Determine the slot of the indicated TCI state when receiving the first UL resource and second UL resource for Event 2 according to the slot of the first UL resource. 
Proposal 8: The time domain resource of CSI reference resource is determined according to the slot of the first UL resource for Event-2 for both mode A and mode B. 
Proposal 9: Further study the determination of RS occasions for the event triggered beam report. 

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

Agenda item:	9.2.1
Source:	NEC
Title: 	Discussion on enhancements for UE-initiated or event-driven beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, we provided our views on Rel-19 MIMO work on enhancements for UE-initiated/event-driven beam management, and we have the following proposals:
Proposal 1:	The time window can be a duration containing L transmission occasions of new beam RS or current beam RS, with the value L configured as the value for time window by RRC.
Proposal 2:	Clarify whether the event assessment should be based on the latest occasion of new beam RS or can be based on any transmission occasion prior to one transmission occasion of first PUCCH in case of time window not configured.
Proposal 3:	To avoid frequent report, support Candidate#1 Option-1A (a prohibit timer started after PUSCH transmission).
Proposal 4:	For Event 2 and Event 7, the UE applies the threshold to the L1-RSRP measurement obtained for the new beam after scaling received L1-RSRP of the new beam with the difference between Tx power of the current beam and the new beam.
Proposal 5:	Definition or timing for current beam and the new beam should be clarified. And FFS whether to update reporting contents after the event is triggered.
Proposal 6:	Support configuration on whether the reported L1-RSRP is based on M measurement instances or the most recent measurement, if a configurable time window and a configurable number M are used for UEI beam report.
Proposal 7:	For event-7, support the Q-th best quality TCI state to be assessed for each event instance. And it can be configurable or based on UE capability.
Proposal 8:	Clarify that the reported L1-RSRP is based on the most recent measurement instance for beams not satisfying the condition, and the reported L1-RSRP is based on the M-th instance with measurement result satisfying the condition or the most recent measurement instance for beams satisfying the condition.
Proposal 9:	Regarding RS measurement for new beam, support the RS set can be updated by MAC CE.
Proposal 10:	If the RS(s) for new beam are CSI-RS configured in a CSI-RS resource set configured with repetition, UE expects the repetition set to ‘off’.
Proposal 11:	For mode A, the UEI report configuration contains reportConfigType with both periodic (for first PUCCH) and aperiodic (for second PUSCH). Support to add the corresponding IE in RRC list as follows:
Proposal 12:	Do not support UEI beam report with a periodicity less than or equal to one slot.
Proposal 13:	Clarify the CSI processing timeline and CPU for UEI beam report, such as Z/Z’ (which can be 0 as there is no further processing after first PUCCH channel transmission); number of CPUs; priority of the CPUs; and also the timing to release the occupied CPUs by UEI beam report should be discussed.
Proposal 14:	At least for mode A, when and where to monitor the DCI (i.e. step 2) for scheduling and confirmation of beam report or when to terminate the beam report transmission should be studied.
Proposal 15:	Support Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH, if 1-bit first PUCCH is collided/overlapped with a PUSCH.
Proposal 16:	The triggered UE-initiated/event-driven beam report may be cancelled or dropped if colliding with other procedures like BFD/BFR and legacy NW-configured/triggered beam measurement and report.
Proposal 17:	Consider to support that UE applies the reported beam without further RRC reconfiguration.
Proposal 18:	Cell DTX/DRX active time period should also include the time while the first PUCCH is sent and corresponding DCI is not received.

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

Source:	   RUijie networks
Title:	   Discussion on enhancements for UE-initiated/event-driven beam management
Agenda Item: 	   9.2.1
Document for: 	Discussion and decision 

Conclusions
In this contribution, we have presented our views on UE-initiated/event-driven beam management. Based on the discussions in the previous section we propose the following: 
Proposal 1: On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, support Option-1A in Candidate#1.
Candidate#1: To introduce a prohibit timer for mode-A and/or mode-B
Option-1A: In the case that triggering-event associated with the CSI report configuration is determined [by the same triggering beams(s) as the last transmitted PUCCH], if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer
Proposal 2: On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH, support Option-3,
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
The PUSCH can be with UL-SCH or not for UEI beam report.
FFS: The 1-bit indication is always multiplexed in the PUSCH, regardless that UEI beam report procedure is triggered.

3GPP TSG RAN WG1 #121   	                	      	    R1-2503985
St Julian’s, Malta, May 19th – 23st, 2025
Agenda item:		9.2.1
Source:		LG Electronics
Title:			UE-initiated beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, the following proposals are provided.
Proposal#1: For first PUCCH (re)transmission, introduce prohibit timer; one starts at the first symbol after the end of the PUCCH transmission and another starts at the first symbol after the end of the PUSCH transmission. 
if the both prohibit timers are NOT running, the UE can transmit first PUCCH
Proposal#2: For the multiplexing/dropping rule(s) of first PUCCH, support the following priority: 
Case-2: Support piggyback 1-bit indication of first PUCCH into the PUSCH
Proposal#3: For CPU occupation for UEI beam report, one CPU is occupied per UEI beam report and occupation time starts when the UEI beam report is configured and ends when it is released.
Proposal#4: For Mode A with Event-1, legacy Z and Z’ can be reused. For Mode A with Event-2 and 7, reduce Z and Z’ for latency reduction of aperiodic beam report.
Proposal#5: Legacy approach for active P-CSIRS counting can be reused, i.e., active when P-CSIRS is configured until it is released.
Proposal#6: For second PUSCH with Mode A, same priority rule for legacy AP CSI is applied and for second PUSCH with Mode B, same priority rule for legacy SP CSI on PUSCH is applied

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

Agenda Item:					    9.2.1
Source:	Sony
Title:	Enhancements for UE-initiated/event-driven beam management
Document for:	Discussion

Conclusions
Finally, allow us to repeat our proposals to draw attention.
: On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, support Candidate#1 and option-1B for both mode-A and mode-B:
Candidate#1: To introduce a prohibit timer
Option-1A: In the case that triggering-event associated with the CSI report configuration is determined [by the same triggering beams(s) as the last transmitted PUCCH], if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer
If the prohibit timer is running, the first PUCCH is not allowed to be transmitted.
: On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH, support -	Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH

3GPP TSG-RAN WG1 Meeting #121															R1-2504076 
Malta, MT, 19 – 23 May 2025

Agenda item:		9.2.1
Source:	Nokia
Title:	Enhancements to facilitate UE-initiated/event-driven beam management
Document for:		Discussion and Decision

Conclusions
Based on the discussion above we made the following observations and proposals:
Proposal 1:	For both Mode A and Mode B, do not support introducing a prohibit timer for the first PUCCH (Candidate#3).
Proposal 2:	For a UE configured with one first PUCCH associated with multiple CSI report configurations regarding Event-2, do not support that the multiple CSI report configurations associated with the same CSI-AperiodicTriggerState should also be associated with a same PUCCH resource.
Proposal 3:	For a UE configured with one first PUCCH associated with multiple CSI report configurations, support that different event types can be configured simultaneously.
Proposal 4:	For a UE configured with one first PUCCH associated with multiple CSI report configurations associated with different event types, in case the conditions of more than one CSI report configurations are met, the UE reports the UEI beam report with highest priority, for example based on the lowest CSI-ReportConfigId or legacy CSI report priority rules.
Proposal 5:	Regarding Case 2, where the 1-bit first PUCCH overlap with a PUSCH, support Option-4, where SR dropping rule is reused by dropping the first PUCCH.
Proposal 6:	Regarding Case 5, where the 1-bit first PUCCH is collided/overlapped with a PUCCH format 2/3/4 carrying HARQ/CSI, the 1-bit first PUCCH is a new UCI type that can be treated as SR, i.e., similar multiplexing/dropping rules as for SR can be used for the 1-bit first PUCCH.
Proposal 7:	For Mode B, do not support that the value of X symbols for determining the available transmission occasion of the second UL channel is subject to a UE capability.
Proposal 8:	For UE-initiated reporting, 1 CPU is occupied until
-	the last symbol of the first PUCCH resource, if an event has not been triggered, i.e., the UE has not transmitted the 1-bit first PUCCH, else
-	the last symbol of the PUSCH resource carrying the CSI report, if an event has been triggered, i.e., the UE has transmitted the 1-bit first PUCCH.
Proposal 9:	For UE-initiated reporting, 1 CPU is occupied from the first symbol of the earliest beam/RS associated with the CSI reference resource, where the CSI reference resource is determined based on the first PUCCH of the CSI report configuration. The beam/RS may be either one of the configured new beams or the current beam.
Observation 1:	The agreed Candidate#2 solution for resetting the counter for Event-2 when the indicated TCI state is updated is not applicable to Event-7 where the current beam is associated to the activated TCI state with the Q-th best quality (and not to the indicated TCI state as in Event-2).
Proposal 10:	Regarding triggering event determination for Event-7, when the time window and counter are configured, support resetting the counter for all new beams when the active TCI state list is updated.
Proposal 11:	On beam report format for all events, support reporting absolute RSRP value of the current beam.
Proposal 12:	On beam report format, support introducing the ‘1-bit’ condition met indicator also for Event-7, reusing the same design of Event-2.
Proposal 13:	On beam report format for Event-2, support the network to configure the UE to indicate/report the current beam index in the UE-initiated beam report.
Proposal 14:	On cross-CC beam report transmission procedure, regarding Event-2, do not support introducing an RRC parameter to indicate the CC corresponding to the configured first PUCCH resource.
Proposal 15:	On beam application latency reduction, send an LS to RAN4 to further study Alt-1, Alt-2 and Alt-3.
Proposal 16:	After sending a UE-initiated beam report, the UE stops monitoring the new beams included in the UE-initiated beam report but not included in the subsequent TCI states Activation/Deactivation MAC-CE.

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

Source:	Fujitsu
Title:	Discussion on enhancements for UE-initiated/event-driven beam management
Agenda item:	9.2.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we have expressed our views on the UEI beam report. The proposals are summarized as below. 
Proposal 1: It is supported to apply the prohibit timer and the maximum number of (re)transmissions for the first PUCCH. As for when to start the prohibit timer, the following Option-1B is preferred.
Option-1B: In the case that triggering-event associated with the CSI report configuration is determined, if the prohibit timer is NOT running, the UE can transmit first PUCCH.
At the first symbol after the end of the first PUCCH transmission, the UE starts the prohibit timer.
Proposal 2: As for Case-2 where the first PUCCH overlaps with a PUSCH, the following Option-3 is supported. Under the assumption of Option-3, the following Alt.1 and Alt.2 can be down-selected.
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
Alt.1: UCI of the first PUCCH is multiplexed on the PUSCH.
Alt.2: If overlapping with the PUSCH with UL-SCH, UCI of the first PUCCH is multiplexed on the PUSCH. Otherwise, if overlapping with the PUSCH without UL-SCH, the first PUCCH is transmitted and the PUSCH is not transmitted.
Proposal 3: When K1 (K1>0) first PUCCHs and K2 (K2≥0) PUCCHs carrying SRs overlap with a PUCCH format 2/3/4 carrying HARQ-ACK/CSI, the following UCI multiplexing rule is supported.
 bits and the HARQ-ACK/CSI bits are transmitted by using a PUCCH format 2/3/4, where the K bits indicate one of the K1+K2 PUCCHs is positive or all the K1+K2 PUCCHs are negative.
Proposal 4: For Event 2 with the time window configured, the timer is considered as expired when the current beam RS is updated based on the indicated TCI state or when the counting is reset.
Proposal 5: For the available PUSCH occasion in Mode-B, the following should be clarified.
Even if the first PUCCH is not transmitted, it is still mapped to an available PUSCH occasion.
Whether SBFD should be considered when defining the available PUSCH occasion.
Proposal 6: For Event 7, the time window can be supported as follows.
Within a time window, if a new beam is a threshold value better than the current beam larger than or equal to M times, and the new beam is a threshold value better than the latest current beam, the UEI beam reporting occurs.
Proposal 7: The design for supporting multiple CSI report configurations for Event 2 is reused to support the case where a UE is configured with multiple CSI report configurations associated with different events.
Proposal 8: For the case where multiple reports are associated with a same first PUCCH, the following is supported.
For Mode-A, the multiple CSI report configurations associated with the same CSI-AperiodicTriggerState should be associated with a same PUCCH resource.
Proposal 9: For the UEI beam report, the CPU occupation duration is determined as follows. 
The ending time is the last symbol of the second PUSCH. 
The starting time is determined as one of the following alternatives.
Alt.1: The first symbol of the earliest one of each CSI-RS/SSB resource for channel measurement, respective latest CSI-RS/SSB occasion no later than t1, where t1 is a time instance with a time interval T earlier than the first PUCCH.
Alt.2: The first symbol after the PDCCH scheduling the second PUSCH.
Alt.3: The first symbol after the first PUCCH.
Proposal 10: Regarding active CSI-RS resource or CSI-RS port counting for the UEI beam report, it is defined that the CSI-RS resources referred by this report include the RS resource for current beam, i.e., the QCL RS in the indicated TCI state or in the activated TCI state. 

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

Agenda Item:	9.2.1
Source:	HONOR
Title:	Discussion on the UE-initiated/event-driven beam management
Document for:	Discussion and Decision

Conclusions
In this paper, our views on the UE-initiated/event-driven beam management for Rel-19 are discussed. Based on the discussion, we list the following proposals:
Observation 1: For periodic, semi-persistent and aperiodic CSI report, the CPU occupancy time is clearly defined in clause 5.2.1.6 of TS 38.214, which is related to CMR/CMI reception time, CSI reference resource, PDCCH reception and transmission time of PUCCH/PUSCH that carries CSI report.
Observation 2: For Mode-B, the CSI processing criteria is not clear as the first UL channel and second UL channel are transmitted only when UE detects the corresponding event(s).

Proposal 1: Support Candidate #1 by resetting the counting for all new beams.
Proposal 2: Support Candidate #7 by supporting the threshold for event evaluation only.
Proposal 3: Support Option-1A to introduce a prohibit timer for the same triggering beams(s) as the last transmitted PUCCH for both modes.
Proposal 4: Support Option-1 to prioritize first PUCCH over PUSCH without UL-SCH, and dropping first PUCCH when colliding/overlapping with PUSCH with UL-SCH. 
Proposal 5: Support Option-1 to add additional one bit to extend the field of  bits representing at most one of positive SR or positive new UCI bit, which increasing maximum number of PUCCH resources to 16.
Proposal 6: Follow the priority order of LRR > first PUCCH > normal SR to order the values of SR ID and new UCI type ID.
Proposal 7: For Mode-A, a UEI CSI report occupies CPU(s) from the first symbol after the PDCCH triggering the UEI CSI report until the last symbol of the UEI CSI report carried by PUSCH.
Proposal 8: For Mode-B, regardless of whether the triggering event for a UEI CSI report is satisfied, the UE/network assumes that one CPU is occupied for a UEI CSI report, where the CPU is occupied from the first symbol of the earliest one of each CSI-RS/SSB resource for channel measurement, respective latest CSI-RS/SSB occasion no later than the corresponding CSI reference resource, until the last symbol of the UEI CSI report carried by PUSCH.
Proposal 9: During the event evaluation procedure, a UEI CSI report occupies CPU(s) from the first symbol of the earliest one of each transmission occasion of periodic CSI-RS/SSB resource for channel measurement for L1-RSRP computation, until  symbols after the last symbol of the latest one of the CSI-RS/SSB resource for channel measurement for L1-RSRP computation in each transmission occasion.
Proposal 10: At least for Mode-A, when multiple CSI report configurations are associated with the same first UL channel, UE/network only assumes one CPU is occupied during the CPU occupancy time when preparing a UEI CSI report carried in the second UL channel.
Proposal 11: Support Alt-3 to store QCL properties of the SSB associated with the reference signal reported in the beam report [in a certain valid period] to reduce beam application latency.

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

Agenda item:	9.2.1
Source: 	Hyundai Motor Company
Title:	Discussion on enhancements for UE-initiated/event-driven beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, the following conclusions were made:
Observation #1:
Regarding triggering event determination for Event 2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, the current design may require the UE to run multiple timers simultaneously.

Proposal #1:
When timer capacity is exceeded, the UE should apply a beam-quality-based eviction policy to retain higher-priority beam candidates.

Proposal #2:
On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, adopt Option-1B (timer starts after first PUCCH) as the default operation.

Observation #2:
It is needed to define the design for scenarios where multiple beam reporting configurations might utilize the same uplink resources.

Proposal #3:
Support Option-2A and Option-2B for coordinated first PUCCH handling in configurations that share uplink resources.

Proposal #4:
Define a configurable maximum retry count for the first PUCCH, and allow the UE to retransmit until either successful acknowledgment or retry exhaustion.

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

Source: 	ETRI
Title: 	Enhancements for UE-initiated/event-driven beam management
Agenda Item:	9.2.1	
Document for:	Discussion

Conclusion
We address our view about UE initiated reporting.
Proposal 1: Multiple events can be activated for a UE perspective.
Proposal 2: In addition to L1-RSRP, support L1-SINR with no further restriction.
Proposal 3: For Event-2 counting reset, support Candidate #1(new beam RS update), #3(second report transmission), #6(threshold update).
Proposal 4: Remove the bracket, i.e., with the same periodicity configured by the newBeamResourceSet-r19.
Proposal 5: Remove the [at least when DRX is not configured] in the earlier agreement, i.e., the evaluation periodicity does not depend on C-DRX status.
Proposal 6: Clarify the timeline of testing the condition of Event(s), and discuss whether/how to cancel some or both of UEI reports.
Proposal 7: Evaluation instance uses formal L1-RSRP (or L1-SINR if supported) that satisfies CSI reference resource definition.
Proposal 8: The measurement quantity is updated before the second report while it may not satisfy the trigger condition.
Proposal 9: The earliest available PUCCH resource is used for a first report after an event is detected.
Proposal 10: Introduce an preemption rule for a same PUCCH resource if multiple events are detected.
Proposal 11: A single trigger state may associate two or more PUCCH resources for ModeA.
Proposal 12: The bitmap regarding whether the CRI/SSBRI satisfies the condition of Event-7 in the report format is introduced for Event-7.
Proposal 13: Support the prohibit timer where consecutive PUCCHs are prevented (Option-1B).
Proposal 14: For Case-2, piggyback UEI into the PUSCH (Option-3) regardless of UL-SCH presence/absence.
Proposal 15: For Case-2, no further optimization of priority index of a first report.
Proposal 16: For CPU occupation, detecting events consumes a CPU budget.
Proposal 17: For a first report, CPU occupation begins with the CMR, and ends after the transmitted PUCCH.
Proposal 18: For ModeA, CPU occupation begins with the UL grant for a second report, and ends after the transmitted PUSCH.
Proposal 19: For ModeB, CPU occupation begins with the CMR of a second report, and ends after the transmitted PUSCH.

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

Agenda Item:	9.2.1
Source:	Transsion Holdings
Title:	Enhancements for UE-initiated/event-driven beam management
Document for:	Discussion and decision

Conclusion
In this contribution, we discuss potential enhancements on UE-initiated/event-driven beam management. Based on the discussion above, we provide the following proposals:
Proposal 1: Regarding triggering event determination for Event-7, when the time window and counter are configured, support the event instance(s) counting per new beam as in Event-2.
Proposal 2: If 1-bit indication of first PUCCH is overlapped with a PUCCH format 2/3/4 carrying HARQ-ACK information and/or CSI report(s), the UCI bit sequence generation reuses the legacy rule for SR with the following enhancement:
The first M value(s) in the field is generated based on a first ascending order of the values of SR ID associated with the SRs and the remaining N value(s) in the field is generated based on a second ascending order of the values of PUCCH resource ID associated with the first PUCCHs.
Proposal 3: Regarding how to associate a CSI trigger state dedicated to UE-initiated/event-driven beam reporting, the following alternatives can be considered:
Alt-1: The existing CSI-AssociatedReportConfigInfo IE can be reused to provide CSI report configuration dedicated to UE-initiated/event-driven beam reporting
FFS: How to differentiate between aperiodic CSI reporting configurations and CSI report configuration for UE-initiated/event-driven beam reporting
Alt-2: A new UE-initiated/event-driven CSI report configuration information IE can be introduced to provide CSI report configuration dedicated to UE-initiated/event-driven beam reporting
Proposal 4: If the 1-bit first PUCCH is collided/overlapped with a PUSCH, support Option-3:
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
FFS: If the PUSCH should be with UL-SCH or not for UEI beam report
Proposal 5: To further reduce preparation time for UEI beam report, preparation time of PUSCH with UL-SCH can be reused as a starting point.
Proposal 6: The CSI reference resource could be enhanced based on the first PUCCH, otherwise, the UEI beam report could be generated based on the CSI-RS/SSB no later than occasion of the first PUCCH.
Proposal 7: Regarding the reduction of beam application latency after a UEI/ED beam report, support Alt-1:
Alt-1: After confirmation/acknowledgement from NW, apply new beam without RRC configuration signaling or MAC-CE signaling
after sending a UE-initiated beam report, the UE could store the QCL properties of the SSB associated with the reference signal reported in the beam report 
update TCI state(s) with the reported new beam(s)
activate new beam(s) without additional SSB reception 
4 

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

Source:	OPPO
Title:	Discussions on UE-initiated/event-driven beam management
Agenda Item:	9.2.1
Document for:	Discussion and Decision

Conclusions
In this contribution, we present our views on UE-initiated beam reporting and the following proposals are made:
Proposal 1: For Event-7, only support the basic feature of the triggering event determination. 
Proposal 2: In addition to candidate #2, candidate #6 shall be supported for Event 2.
Proposal 3: Candidate #2 and #6 shall be supported for Event 1.
Proposal 4: The ‘1-bit’ condition met indicator is not applicable to Event 1 and Event 7.
Proposal 5: For the configuration of 1st PUCCH resource in CSI report configuration for UEIBM, reuse the PUCCH resource configuration for periodic and semi-persistent CSI reporting.
Proposal 6: Support Candidate #2 and Option-2B for Mode A only.
Proposal 7: Do not support prohibit timer or time interval for Mode-B.
Proposal 8: For Mode-A, the multiple CSI report configuration associated with the same CSI trigger state shall be associated with the same 1st PUCCH resoure.
Proposal 9: For the Case-2 of that the first PUCCH collides with a PUSCH, support Option-3. The 1-bit indication is always multiplexed in the PUSCH, and the PUSCH can be any PUSCH, either UL-SCH or for UEI beam report.

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

Agenda Item:	9.2.1
Source:	Google
Title:	Discussion on enhancements for UE-initiated or event-driven beam management
Document for: 	Discussion

Conclusion
According to the above discussion(s), we have the following observation(s) and/or proposal(s). 
Proposal 1: UE initiated beam reporting can be triggered only when BFR/BFRQ transmission is not performed. 
Proposal 2: Adopt Text Proposal 1 for capturing the timer in TS 38.214. 

Proposal 3: On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, support the following updated option: 
Option-3A: Piggyback 1-bit indication of first PUCCH into the PUSCH, if the PUSCH is not for UEI beam report. 
FFS: If the PUSCH is for UEI beam report. 
Proposal 4: RAN1 to discuss whether it is allowed to configure different CC with different UEI-BR mode. 
Proposal 5: Further study whether/how to resolve collisions between two first PUCCHs, if UE can be configured with different CC with different UEI-BR mode.
Proposal 6: On UE-initiated/event-driven beam reporting, regarding Event-2, ‘current beam’ can also correspond to the serving beam applied for DL channels/RSs not following indicated TCI state.
Note: This reflects the fact that not all DL channels/RSs follows indicated TCI state. 
Proposal 7: On triggering event determination for Event 2, the event instance(s) counting is reset if one of the following candidate conditions is fulfilled: 
Candidate#1: RS reconfiguration/update for new beam is received
Note: UE maintains the counting whose new beam is NOT updated
Candidate#3: UEI beam report is transmitted
Only reset the counting of new beams fulfilling triggering condition and reported by the UEI beam report  
Candidate#6: The threshold for event evaluation is re-configured by RRC signalling 
Proposal 8: Support L1-SINR as the unit of the threshold for triggering UE-initiated/event-driven beam reporting, in addition to L1-RSRP.  
Proposal 9: On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, RAN1 does not pursue the default value when ‘N’ is not RRC configured.  
Proposal 10: On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, support a prohibit timer for mode-A and/or mode-B
In the case that triggering-event associated with the CSI report configuration is determined by the same triggering beams(s) as the last transmitted PUCCH, if the prohibit timer is NOT running, the UE can transmit first PUCCH; 
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer
Proposal 11: After receiving a TCI state activation command to activate a TCI state(s), if the new beam(s) associated with the TCI state(s) is determined as synchronized in the UEI beam report, the TCI state(s) becomes applicable for DL reception without additional SSB reception. 
Note: A reported new beam is determined as synchronized by UE, if the UE stores the QCL properties associated with the reported new beam(s) after the UEI beam report is sent
Proposal 12: UE only stores the QCL properties associated with the reported new beam(s) satisfying the triggering condition, after the UEI beam report is sent. 

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


Source: 	Apple Inc.
Title:                     Remaining issues for UE-initiated beam management
Agenda item:	9.2.1
Document for:	Discussion and Decision
1 

Conclusion 
In this contribution, we have presented our views on how to support UE-initiated/Event-Triggered beam reporting and propose the following: 
Proposal 1:
The RS in the RS resource set for candidate beam in Event-2 and Event-7 can be updated by MAC-CE. 
Proposal 2: The event evaluation counter is reset if any of the following conditions is met: 
Condition #1: A configuration for a corresponding measurement RS list for a new beam is provided by higher layers.
A UE only resets the counter corresponding to the newly-configured RS resource.   
Condition #3: UEI beam report is transmitted
A UE only resets the counter corresponding to the new beams that fulfils the event triggering condition and reported by the UEIBR. 
Condition #6: The threshold for event evaluation is re-configured by RRC signaling. 
A UE resets all event evaluation counters. 
Proposal 3: 
Denoting  as periodicities of RS for current/new beam and event evaluation Instance
When DRX is not configured,  where X=10ms. 
When DRX is configured, 
If , , where 
If , . 
Proposal 4: On Event-7 report, consider the following additional report content 
The TCI-State ID of the ‘activated TCI-State with the ‘M-th’ best quality’. 
A bitmap to indicate which activated TCI-States can be updated by the qualified L1-RSRP reports 
Proposal 5: Introduce a prohabit timer to control the first PUCCH retransmission for Mode-A. 
Configuration #1: The timer starts after the first PUCCH channel is transmitted. 
Configuration #2: The timer starts after receiving the second PUSCH channel. 
It is up to NW to select one configuation for Event-2.
A UE shall not transmit the first PUCCH channel when the prohabit timer is running. 
Proposal 6: The UEIR-I bits overlapped with PUSCH are always piggybacked on PUSCH. 
Proposal 7: When one or multiple UEIR-I bits overlapped with PUCCH format 2/3/4 carrying HARQ-ACK/SR/CSI, joint encoding of SR and UEIR-I bits is used and then appended to the HARQ-ACK bits. 
Proposal 8: Different codepoint of the shared field are associated with different combinations
Proposal 9:  is applied for UEIBR report. 
Proposal 10: For a UEIBR report, two CPU counting are applied: 
CPU counter #1: Counting for each CSI measurement occasion starting from the first symbol of the earliest one of each CSI-RS/SSB resource for channel measurement and ends at the symbol ‘’, where  is the last symbol of last CSI-RS/SSB resource.  
CPU counter #2: countering for each PUSCH occasion. Assuming the last symbol ‘’ of PUSCH, the CPU counter #2 starts from ‘’ symbol and ends at the last PUSCH symbol ‘’.   

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

Agenda item:	9.2.1
Source: 	Qualcomm Incorporated
Title: 	Enhancements for UE-initiated/event-driven beam management
Document for:	Discussion/Decision

Conclusions
In this contribution, we presented our views on UE-initiated/event-driven beam management enhancements, focusing on event definitions, UL signaling channels, UL signaling contents, and associated procedures. Specifically, the following observations and proposals were made:
Proposal 1: For Event-7, when window-based triggering event determination (i.e., M>1) is configured:
The event instance counting is per new beam (as Event-2).
When the quality order of the activated TCI states varies within the time window, it is up to UE implementation to choose the one corresponding to the “Q-th” best quality across the Event-7 instances.
Proposal 2: As an additional condition for resetting the event instance counter for Event-2, Candidate#7 should be supported.
Proposal 3: Regarding the detailed triggering event determination and beam reporting procedure:
Once a triggering event is determined, a UE-initiated beam report is triggered and remains pending.
The pending beam report triggers the first PUCCH transmission, subject to a prohibit timer, if configured.
After the beam report is transmitted in the second PUSCH, the pending beam report is cancelled. If a prohibit timer is configured, the timer is also stopped.
Proposal 4: For UE-initiated/event-driven beam reporting, the RS(s) for the indicated TCI state (Event-2 and Event-1) and activated TCI state(s) (Event-7) should belong to the same RS resource set as the RS(s) for the new beam(s), associated with the CSI report configuration.
The RS resource set can be either a CSI-RS resource set for beam management (Scheme-1) or an SS/PBCH block resource set (Scheme-2).
Observation 1: For UE-initiated/event-driven beam reporting according to Event-2,
The new beam with the strongest reported L1-RSRP may not satisfy the condition of Event-2.
When the mandatory inclusion of the current beam in the report is enabled, even the current beam may be reported as the one with the strongest L1-RSRP.
Proposal 5: For UE-initiated/event-driven beam reporting according to Event-2 and Event-7, an absolute L1-RSRP of the current beam should be reported, if the current beam is configured to always be reported.
Proposal 6: If a UE has not sent a first PUCCH but receives DCI with a CSI request field indicating a second PUSCH for Mode-A beam reporting, the UE should send a valid beam report even if the event triggering condition has not been satisfied.
Proposal 7: When a pre-configured first PUCCH resource overlaps with other UCI or UL-SCH, the 1-bit indication (either positive or negative) is multiplexed with the other transmissions.
Case 2: The 1-bit indication is piggybacked into the PUSCH with UL-SCH (Option-3).
If the PUSCH is without UL-SCH, the UE does not transmit the PUSCH and transmits only the first PUCCH.
Case 5: The 1-bit indication is multiplexed with the UCI in PUCCH format 2/3/4.
If there are more than one (e.g., ) first PUCCH and SR resource overlapping,  bits are multiplexed.
Proposal 8: For the first PUCCH transmission according to Mode-A and Mode-B, introduce a prohibit timer: At the first symbol after the end of the first PUCCH transmission, the UE starts the prohibit timer (Option-1B).
Proposal 9: If a prohibit timer is introduced for the first PUCCH transmission, the timer should apply per first PUCCH resource.
If multiple CSI report configurations are associated with the same first PUCCH resource, they should share the same prohibit timer.
Observation 2: To synchronize CPU occupancy status between the UE and the network, the CPU occupancy duration of UE-initiated/event-driven beam reporting can only start after the first PUCCH transmission.
Proposal 10: For UE-initiated/event-driven beam reporting,  CPU is occupied
from the first symbol of the earliest one of each transmission occasion of periodic CSI-RS/SSB resource for channel measurement for L1-RSRP computation, until  symbols after the last symbol of the latest one of the CSI-RS/SSB resource for channel measurement for L1-RSRP computation in each transmission occasion, and
from the first symbol after the PDCCH triggering the CSI report until the last symbol of the scheduled PUSCH carrying the report for Mode-A, or from the first symbol after the first PUCCH transmission until the last symbol of the PUSCH carrying the report for Mode-B.
Proposal 11: For UE-initiated/event-driven beam reporting, the same CSI reference resource definition as legacy aperiodic CSI reporting is applied.
Proposal 12: For UE-initiated/event-driven beam reporting Mode-B, the UE capability for the value of X symbols reuses the legacy UE capability beamReportTimine and beamReportTimine-v1710.

3GPP TSG RAN WG1 #121	R1-2504444
St Julian’s, Malta, May 19th – 23th, 2025
Source:	Sharp
Title:	Enhancements for UE-initiated/event-driven beam management
Agenda Item:	9.2.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we have the following proposal:
Proposal 1: Regarding Event-2, a new RRC parameter should be introduced to indicate the number of timers for counting event instances for new beam RS(s).
Proposal 2: Regarding Event-2, when multiple timers are configured, the same expire time of the multiple timers should be configured by the time window.
Proposal 3: Regarding Event-2, in case that the number of timers is smaller than the number of new beam RSs, when using all timers for a part of new beam RSs, the UE should ignore an event instance for other new beam RSs.
Proposal 4: Even if the other  UEI beam reports are cancelled, K2 value should be determined as the maximum of  slot offset values. (No spec impact)
Proposal 5: In a case that the first PUCCH is overlapped with a PUSCH, we support the piggyback 1-bit indication of the first PUCCH into the PUSCH (Option-3).
Proposal 6: For only Mode-A, we support that the prohibit timer starts after the first PUCCH transmission (i.e., Option-2).

3GPP TSG RAN WG1 #121		 R1- 2504453
Malta, MT, May 19th – 21st, 2025

Agenda Item:	9.2.1
Source:	China Telecom
Title:	Discussions on UE-initiated/event-driven beam management
Document for:	Discussion
1		

Conclusion
In this contribution, we discuss the potential design of synchronization, random access and scheduling, and have the following observations and proposals: 
Proposal 1: Regarding triggering event determination for Event 2, besides for Candidate#2, at least Candidate #1 and Candidate #7 is also supported for the reset the counting, 
Candidate#1: RS reconfiguration/update or MAC-CE signaling (if supported) for new beam is received, the UE reset the counting for the updated new beams.
Candidate#7: The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured, the UE need to reset the counting for all new beams.
Proposal 2: On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, at least Candidate#1is supported.
Candidate#1: To introduce a prohibit timer for mode-A and/or mode-B
Proposal 3: On beam report transmission procedure for UEIBR for a CSI report configuration, two types of prohibit timers is feasible for the UEIBR. 
The first prohibit timer is used to disable some PUCCH transmission occasions, thus to avoid the frequent transmissions of the first PUCCH for the same new beam. 
The second prohibit timer is used to delay the transmission of the first PUCCH. if the UEIBR has been triggered within a measuring time window.
Proposal 4: Regarding the prohibit timer in the beam report transmission procedure of UEIBR for a CSI report configuration, the UE reset the prohibit timer if
Candidate#1: RS reconfiguration/update or MAC-CE signaling (if supported) for all the new beam is received.
Candidate#2: The measured current beam RS is updated based on indicated TCI state;
Candidate#3: The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured.
Proposal 5: For the multiplexing/dropping rule(s) of Case-2, when the 1-bit first PUCCH is collided/overlapped with a PUSCH,	
If the PUSCH should be with UL-SCH or not for UEI beam report, the UE transmits the PUSCH and drop the first PUCCH. 
Otherwise,
If the PUSCH is transmitted in repetition, the UE transmits the first PUCCH of UEIBR and does not transmit the overlapping actual PUSCH repetitions.
Otherwise, the UE piggyback 1-bit indication of first PUCCH into the PUSCH.
Proposal 6: If UE received the DCI that indicating the second UL channel for the UEIBR and the UE has not sent the first PUCCH, the UE may check the measure result, 
If the trigger event has been triggered, the UE can report the UEI beam report;
Otherwise, the UE does not send the beam report on the second UL channel.
Proposal 7: On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the value of X for Mode-B, Option-3 is supported, that is, 
UEI beam report is carried on a first available transmission occasion of the second UL channel after sending the last symbol of report notification on the first PUCCH channel.

4		

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

Agenda item:	9.2.1
Source: 	Moderator (ZTE)
Title: 	Moderator Summary #1 on UE-initiated/event-driven beam management 
Document for:	Discussion and Decision

Conclusion
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A, there is no RAN1 consensus on additionally supporting that the DCI format in Step-2 comprises DL-grant DCI format, and the second channel in Step-3 is PUCCH.

[118] Agreement
On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, the candidate value of ‘N’ at least comprises {1, 2, 3, 4}  
FFS: additional candidate value(s) of {5, 6, 7, 8}
FFS: If ‘N’ is not RRC configured, only one L1-RSRP and CRI/SSBRI are reported by default. 

[118] Agreement
Regarding RS measurement for the current beam for Event 2, for Option-2a, besides for scheme-1 and scheme-2, further down-select one of the following for handling the case that only one TRS is configured in the indicated TCI state in RAN1#118bis
Option-1: Introducing additional scheme: the RS for current beam can be a CSI-RS for beam management derived from the QCL RS in the indicated TCI state;
Option-2: Further support TRS as measurement RS of current beam for determining L1-RSRP
Option-3: Introducing additional scheme: The RS for current beam is explicitly configured by RRC or MAC-CE (Option-2C in RAN1 116b agreement).
Option-4: No further enhancement 
Note: If there is no consensus in RAN1 on one of Options 1/2/3, Option 4 will be taken. 

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, for the case the pre-configured Type-1 CG PUSCH carry the beam report, for the second UL channel in Mode-B, at least one or both of the following should be supported:
Option-1: The same Type-1 CG PUSCH can carry UL-SCH and the beam report.
Option-2: The Type-1 CG PUSCH is a dedicated type-1 CG PUSCH for carrying the beam report
Note: This PUSCH can NOT carry UL-SCH. This PUSCH can NOT carry any other UCI.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-B, UEI beam report is carried on a first available transmission occasion of the second UL channel X symbols after sending the last symbol of report notification on the first PUCCH channel.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding resource mapping/configuration between first and second channel in Mode-B, for a given CSI report configuration, the following is provided for down-selection.
Option-1 (one-to-one): Only one first PUCCH resource and only one pre-configured resource for second UL channel can be associated with the CSI report configuration for UE-initiated/event-driven beam reporting.
Option-1A: Same periodicity between first PUCCH resource and pre-configured resource for second UL channel.
Option-1B: No restriction in terms of periodicity.
Option-2 (one-to-M): Only one first PUCCH resource and one or more pre-configured resource(s) for second UL channel can be associated with CSI report configuration for UE-initiated/event-driven beam reporting.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, for at least Mode-B, the beam report should be carried in the second UL channel in the CC where the corresponding CSI report configuration is configured.
Above applies to both cross-CC and same-CC beam report. 
Note: Above is applied to the case that second UL channel is PUSCH. 
FFS: Whether the first and second channels can be from the same/different CC. 

[118] Working Assumption
On UE-initiated/event-driven beam reporting, regarding trigger events, besides for Event-2, Event-1 and Event-7 are both supported.
Event-1: Quality of the current beam is worse than a certain threshold.
Event-7: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the M-th best quality.
M is RRC configured with subjective to UE capability signalling
UE may only indicate a single candidate value or not support Event-7. 
The additionally supported events will reuse the same design as event 2 – unless there is consensus to do otherwise
The additionally supported events will be lower priority compared to event 2.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A and/or Mode-B, further study the following for first PUCCH transmission
UCI multiplexing/dropping/prioritization rule
Conditions for the transmission of the first PUCCH.
Whether the PUCCH resource in the first PUCCH channel can be associated with multiple CSI report configurations for UE-initiated/event-driven beam reporting from one or multiple CC(s).
Whether/how to re-transmit the first PUCCH channel.
Whether/how to apply prohibit-timer or maximum number of (re)transmission(s) for first PUCCH channel.
RAN1#117
[117] Agreement
On UE-initiated/event-driven beam reporting, regarding UL signaling content(s) of L1-RSRP report depending on Event-2, in a report instance, at least Option-3 is supported
Option-3: N ≥ 1 beam(s) are reported in the report instance,  
At least one of N reported beam(s) should satisfy the condition of Event-2
N is configured by gNB
FFS: candidate value of ‘N’.  
FFS: RRC can enable or disable whether current beam is always reported in addition to the N beams 
FFS: Option-1/1a/1b/2.  
Above applies at least for the single CC case

[117] Working Assumption
On beam report transmission procedure for UE-initiated/event-driven beam reporting
For mode-A, at least support one-bit indication in the first PUCCH channel to request a resource for a second UL channel to carry beam report.
In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.  
For mode-B, at least support one-bit indication in the first PUCCH channel to notify a second UL channel to carry beam report.
In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.  
FFS: Whether/how to support multi-bit indication in the first PUCCH for mode-A and mode-B, e.g., when multi-event(s) are approved.
FFS: details on the dedicated RRC signaling
Above applies at least for the single CC case.

[117] Agreement
Regarding RS measurement for the current beam for Event 2, for Option-2a, support the both schemes as follows. 
Scheme-1: RS for current beam is the QCL RS in the indicated TCI state
FFS: Whether/How to handle the case if only one TRS is configured in the indicated TCI state.
Scheme-2: the RS for current beam is the SSB which is QCLed with the QCL RS in the indicated TCI state.
Enabling one of either Scheme-1 or Scheme-2 is selected by NW.
FFS: The above selection is via an explicit RRC parameter or an implicit manner, e.g., if the RS(s) for new beam are CSI-RS, Scheme-1 is enabled; otherwise, Scheme-2 is enabled.
(Working Assumption) Enabling of either Scheme-1 or Scheme-2 should ensure the same RS type for RS measurement for current beam and new beam.
The above QCL RS is the RS w.r.t. QCL-TypeD, if there are two QCL RSs in the indicated TCI state. 

[117] Agreement
Regarding RS measurement for the new beam for Event 2, at least Option-3a is supported
Option-3a (explicit manner): The RS(s) for new beam(s) are explicitly configured
FFS: Option-3b/3c
Option-3b: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Option-3c: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of TCI state(s) in a configured subset of the legacy RRC-configured TCI state list

[117] Agreement
On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, for a report instance where N ≥ 1 beam(s) are reported, the following is supported.
RRC can enable or disable whether current beam is always reported
When enabled by RRC, the current beam + N beams from the measurement RSs for new beam(s) are reported
Note: The reported current beam is NOT counted in the N reported beams.
When disabled by RRC, N beams are reported.

[117] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A, the DCI format in Step-2 comprises UL-grant DCI format, and the second channel in Step-3 is at least PUSCH.
The UL-grant DCI format at least comprises DCI format 0_1/0_2.
FFS: DCI format 0_3
FFS: How to trigger the UEI beam report by the UL-grant DCI format
FFS: the DCI format in Step-2 comprises DL-grant DCI format, and the second channel in Step-3 is PUCCH.
1-bit field in the DL-grant DCI format is introduced to indicate the transmission of the UEI beam report
The PUCCH resource for HARQ-ACK transmission can be reused to carry both the HARQ-ACK and UEI beam report.
The DL-grant DCI format at least comprises DCI format 1_1/1_2.
FFS: DCI format 1_3
 
[117] Agreement
Regarding the triggering event determination for Event 2:
If within a time window (which is configurable), the number of Event-2 instance(s) for at least one same new beam is greater than or equal to a configurable number M, UE initiated beam report occurs.
Note: Event-2 instance for a new beam is determined if the L1-RSRP of the new beam becomes a threshold value better than the current beam
Above feature is subject to UE capability.
Basic feature: Once the L1-RSRP of the new beam becomes a threshold value better than the current beam, UE initiated beam report occurs
FFS: Whether the above is captured in RAN1 or RAN2 specification.

[117] Agreement
On UE-initiated/event-driven beam reporting, regarding trigger events, the following Event-1 and 7a/7b, are provided for down-selection or combination in RAN1#118 (possible outcome is that no new event is supported)
Event-1: Quality of the current beam is worse than a certain threshold.
Event-7a: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the worst quality.
Event-7b: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the best quality.

[117] Agreement
Regarding explicit RS configuration for new beam measurement for Event 2, down-select the following options in the RAN1#118:
Option-1: The RS(s) for new beam(s) are explicitly configured in one RS resource set associated with an CSI reporting configuration;
FFS: The RS in the RS resource set can be updated by MAC-CE. 
Option-2: A list of RS(s) for new beam measurement can be configured by RRC, and a subset can be activated for new beam measurement by MAC-CE.
FFS: If a list size is small, MAC-CE activation is not needed
Option-3: A list of RS resource (s) for new beam measurement can be configured by RRC, and a subset of RS resource(s) in the list can be provided for new beam measurement by indicated TCI state.
Others are not precluded.
FFS: Each RS for new beam measurement should be associated with a configured joint/DL TCI state which can be used as the indicated TCI state

[117] Agreement
Regarding RS measurement for the current beam for Event 2, for Option-2a, besides for scheme-1 and scheme-2, further study the following for handling the case that only one TRS is configured in the indicated TCI state. 
Option-1: Introducing additional scheme: the RS for current beam can be a CSI-RS for beam management derived from the QCL RS in the indicated TCI state;
Option-2: Further support TRS as measurement RS of current beam for determining L1-RSRP 
Option-3: Introducing additional scheme: The RS for current beam is explicitly configured by RRC or MAC-CE (Option-2C in RAN1 116b agreement).
Option-4: No further enhancement (i.e., in such case, Scheme-2 is used)
Others are not precluded.

RAN1#116-bis
[116b] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, following modes are supported:
Mode A (dynamically scheduling UCI by gNB):
Step 1: UE transmits a first PUCCH (one-bit/multi-bit) to request a resource for a second UL channel to carry beam report
FFS: Request format, e.g., SR or a new UCI type.
Step 2: UE detects the DCI format to indicate a resource for a second UL channel to carry beam report. 
Step 3: Beam report is transmitted in second UL channel.
FFS: Details on the second UL channel, e.g., whether the second UL channel is PUCCH, PUSCH or both
This mode is basic UE capability (i.e. all UE supporting UE-initiated/event-driven beam reporting should support this feature).
No new DCI format is introduced.
Mode B (UCI in pre-configured resource(s) for second UL channel):
Step 1: UE transmits a first PUCCH (one-bit/multi-bit) notifying a second UL channel to carry beam report
FFS: Notification format, e.g., SR or a new UCI type.
Step 2: UE transmits the beam report in the second UL channel. 
FFS: Details on the second UL channel, e.g., whether the second UL channel is PUCCH, PUSCH or both
The notification in Step1 is in a separate reporting instance from the beam report in Step 2. 
FFS: Whether UE receives acknowledge information with response to each step for all modes
For above procedures, cross-CC beam reporting is supported for both modes.
FFS: Details.

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding trigger-event detection for beam reporting, at least support Event-2: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the current beam.
At least L1-RSRP is supported as quality metrics used for Event-2 
FFS: How the L1-RSRP is used to determine the triggering event (e.g. timer, counter, filter coefficient)
FFS: Whether the network controls how the L1-RSRP is used to determine the triggering event 
Regarding RS measurement for the new beam for Event-2, down-select one or more of the following:
Option-3a (explicit manner): The RS(s) for new beam(s) are explicitly configured by RRC (e.g., reusing legacy configuration of RS measurement or in TCI-State) or MAC-CE
Option-3b (implicit manner): The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Option-3c (implicit manner): The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of configured TCI state(s).
Note-1: ‘New/current beam’ is for discussion purpose. 
Note-2: Other trigger events/quality metrics (e.g., L1-SINR) are not precluded.
Note-3: For above implicit manner(s), if there are two QCL RSs in a TCI state, the measurement RS is derived from RS w.r.t. QCL-TypeD, if applicable.

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding Event-2, the threshold value is RRC configured  

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding Event-2, ‘current beam’ is a beam corresponding to the indicated TCI state.
Regarding RS measurement for the current beam for Event-2, Option-2a is supported:
Option-2a (implicit manner): The RS for current beam is implicitly derived from a QCL RS of indicated TCI state.
FFS: The RS for current beam can be either the QCL RS in the indicated TCI state or the SSB which is QCLed with the QCL RS in the indicated TCI state.
FFS: Option-2c (explicit manner): The RS for current beam is explicitly configured by RRC or MAC-CE.
Note: SSB or CSI-RS can be configured

[116b] Agreement
On UE-initiated/event-driven beam reporting, further study the following trigger events: 
Event-1: Quality of the current beam is worse than a certain threshold.
Event-3: Quality of a new beam is better than a certain threshold. 
Event-4: Quality of the current beam is worse than a threshold 1, and quality of at least one new beam is better than a threshold 2.
Event-5: Absolute value of the difference between the quality of the current beam and the quality of at least one new beam is lower than a threshold.
Event-6: When the current beam is not in the best K>1 beams (out of configured beams for measurement and reporting).
Event-7a: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the worst quality.
Event-7b: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the best quality.
Event-8: Quality of M>1 new beams, such as L1-RSRP, become a threshold value better than the current beam.
Event-9: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the configured reference RS (can be SSB or CSI-RS).

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding UL signaling content(s) of L1-RSRP report depending on Event-2, in a report instance, the following options are provided for down-selection (other options are not precluded) in RAN1#117
Option-1 (variable size): N beam(s) are reported in the report instance, where N  {1, 2, ..., Nmax}
The N beam(s) should satisfy the condition of Event-2
Nmax is configured by gNB 
FFS: Whether the indication of payload size should be provided additionally.
Option-1a (variable size): N beam(s) are reported in the report instance, where N  {1, 2, ..., Nmax}
At least one of N reported beam(s) should satisfy the condition of Event-2
Nmax is configured by gNB 
FFS: Whether the indication of payload size should be provided additionally.
FFS: Details on how value of N is determined by the UE
Option-1b: N beam(s) are reported in the report instance, where N  {1, 2, ..., Nmax}
The N beam(s) should satisfy the condition of Event-2
Nmax is configured by gNB 
Payload size does not vary as a function of N
FFS: Zero-padding can be provided if N is less than Nmax.
Option-2: Only N=1 beam is reported in the report instance 
The reported beam should satisfy the condition of Event-2
Option-3: N ≥ 1 beam(s) are reported in the report instance,  
At least one of N reported beam(s) should satisfy the condition of Event-2
N is configured by gNB 
Other options are not precluded.
FFS: Whether the measurement results for current beam is always reported or can be enabled by RRC.
FFS: When current beam is reported, whether the current beam is counted in the N reported beams.  
The selected option shall satisfy Event-2.
RAN1#116
[116] Agreement
On UE-initiated/event-driven beam report, at least of following aspects should be included:
Trigger-event detection for beam reporting by UE
UE monitors RS to assess if a beam-reporting trigger condition has been met
FFS: Trigger condition for declaring beam-reporting event
Beam-report transmission by UE
Signaling contents in the beam report
Down-selection one or more options (strive for one) between the following options as signaling medium/container for beam report transmission
MAC-CE
UCI
Others are not precluded.
On UE-initiated/event-driven beam report, the following aspects may be included:
UE requesting UL resource(s) for the beam report
UE notifying transmission of beam report
gNB preconfigured resources
Other procedure(s) as required

[116] Agreement
On UE-initiated/event-driven beam reporting, regarding trigger-event detection for beam reporting, RAN1 further study at least the following aspects: quality metrics, event-definition and threshold.
Further study trigger events, including the following example as a starting point
Event-1: Quality of the current beam is worse than a certain threshold.
Event-2: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the current beam. 
Event-3: Quality of a new beam is better than a certain threshold. 
Event-4: Quality of the current beam is worse than a threshold 1, and quality of at least one new beam is better than a threshold 2.
Others are not precluded.
Note: Companies are encouraged to provide details on procedure (e.g. how it is used) related to their preferred event

[116] Agreement
On UE-initiated/event-driven beam reporting, at least support L1-RSRP as a measurement quantity on SSB for intra-cell and inter-cell, and periodic CSI-RS for beam management
Notes: measurement results may be contained in the beam report and/or used as quality metric(s) to initiate/trigger the reporting. 
FFS: Semi-persistent CSI-RS and aperiodic CSI-RS.
FFS: Whether/how to support L1-SINR measurement, assuming legacy RS or RS combination (e.g., CMR only, CMR+ZP/NZP-IMR) for Rel-16 SINR is reused. 
FFS: Whether/how to specify filtering operation for L1-RSRP.

[116] Agreement
On UE-initiated/event-driven beam reporting, regarding signaling content(s), at least support DL RS resource indicator and L1-RSRP 
FFS: Study and decide whether additional contents can be supported.
FFS: L1-RSRP format, e.g., absolute and/or differential value.
Note: Above does not imply to preclude discussion on L1-RSRP filtering.
The actual reported content depends on the triggering event
Support of one or multiple events will be discussed separately 

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

Agenda item:	9.2.1
Source: 	Moderator (ZTE)
Title: 	Moderator Summary #2 on UE-initiated/event-driven beam management 
Document for:	Discussion and Decision

Conclusion
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A, there is no RAN1 consensus on additionally supporting that the DCI format in Step-2 comprises DL-grant DCI format, and the second channel in Step-3 is PUCCH.

[118] Agreement
On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, the candidate value of ‘N’ at least comprises {1, 2, 3, 4}  
FFS: additional candidate value(s) of {5, 6, 7, 8}
FFS: If ‘N’ is not RRC configured, only one L1-RSRP and CRI/SSBRI are reported by default. 

[118] Agreement
Regarding RS measurement for the current beam for Event 2, for Option-2a, besides for scheme-1 and scheme-2, further down-select one of the following for handling the case that only one TRS is configured in the indicated TCI state in RAN1#118bis
Option-1: Introducing additional scheme: the RS for current beam can be a CSI-RS for beam management derived from the QCL RS in the indicated TCI state;
Option-2: Further support TRS as measurement RS of current beam for determining L1-RSRP
Option-3: Introducing additional scheme: The RS for current beam is explicitly configured by RRC or MAC-CE (Option-2C in RAN1 116b agreement).
Option-4: No further enhancement 
Note: If there is no consensus in RAN1 on one of Options 1/2/3, Option 4 will be taken. 

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, for the case the pre-configured Type-1 CG PUSCH carry the beam report, for the second UL channel in Mode-B, at least one or both of the following should be supported:
Option-1: The same Type-1 CG PUSCH can carry UL-SCH and the beam report.
Option-2: The Type-1 CG PUSCH is a dedicated type-1 CG PUSCH for carrying the beam report
Note: This PUSCH can NOT carry UL-SCH. This PUSCH can NOT carry any other UCI.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-B, UEI beam report is carried on a first available transmission occasion of the second UL channel X symbols after sending the last symbol of report notification on the first PUCCH channel.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding resource mapping/configuration between first and second channel in Mode-B, for a given CSI report configuration, the following is provided for down-selection.
Option-1 (one-to-one): Only one first PUCCH resource and only one pre-configured resource for second UL channel can be associated with the CSI report configuration for UE-initiated/event-driven beam reporting.
Option-1A: Same periodicity between first PUCCH resource and pre-configured resource for second UL channel.
Option-1B: No restriction in terms of periodicity.
Option-2 (one-to-M): Only one first PUCCH resource and one or more pre-configured resource(s) for second UL channel can be associated with CSI report configuration for UE-initiated/event-driven beam reporting.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, for at least Mode-B, the beam report should be carried in the second UL channel in the CC where the corresponding CSI report configuration is configured.
Above applies to both cross-CC and same-CC beam report. 
Note: Above is applied to the case that second UL channel is PUSCH. 
FFS: Whether the first and second channels can be from the same/different CC. 

[118] Working Assumption
On UE-initiated/event-driven beam reporting, regarding trigger events, besides for Event-2, Event-1 and Event-7 are both supported.
Event-1: Quality of the current beam is worse than a certain threshold.
Event-7: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the M-th best quality.
M is RRC configured with subjective to UE capability signalling
UE may only indicate a single candidate value or not support Event-7. 
The additionally supported events will reuse the same design as event 2 – unless there is consensus to do otherwise
The additionally supported events will be lower priority compared to event 2.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A and/or Mode-B, further study the following for first PUCCH transmission
UCI multiplexing/dropping/prioritization rule
Conditions for the transmission of the first PUCCH.
Whether the PUCCH resource in the first PUCCH channel can be associated with multiple CSI report configurations for UE-initiated/event-driven beam reporting from one or multiple CC(s).
Whether/how to re-transmit the first PUCCH channel.
Whether/how to apply prohibit-timer or maximum number of (re)transmission(s) for first PUCCH channel.
RAN1#117
[117] Agreement
On UE-initiated/event-driven beam reporting, regarding UL signaling content(s) of L1-RSRP report depending on Event-2, in a report instance, at least Option-3 is supported
Option-3: N ≥ 1 beam(s) are reported in the report instance,  
At least one of N reported beam(s) should satisfy the condition of Event-2
N is configured by gNB
FFS: candidate value of ‘N’.  
FFS: RRC can enable or disable whether current beam is always reported in addition to the N beams 
FFS: Option-1/1a/1b/2.  
Above applies at least for the single CC case

[117] Working Assumption
On beam report transmission procedure for UE-initiated/event-driven beam reporting
For mode-A, at least support one-bit indication in the first PUCCH channel to request a resource for a second UL channel to carry beam report.
In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.  
For mode-B, at least support one-bit indication in the first PUCCH channel to notify a second UL channel to carry beam report.
In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.  
FFS: Whether/how to support multi-bit indication in the first PUCCH for mode-A and mode-B, e.g., when multi-event(s) are approved.
FFS: details on the dedicated RRC signaling
Above applies at least for the single CC case.

[117] Agreement
Regarding RS measurement for the current beam for Event 2, for Option-2a, support the both schemes as follows. 
Scheme-1: RS for current beam is the QCL RS in the indicated TCI state
FFS: Whether/How to handle the case if only one TRS is configured in the indicated TCI state.
Scheme-2: the RS for current beam is the SSB which is QCLed with the QCL RS in the indicated TCI state.
Enabling one of either Scheme-1 or Scheme-2 is selected by NW.
FFS: The above selection is via an explicit RRC parameter or an implicit manner, e.g., if the RS(s) for new beam are CSI-RS, Scheme-1 is enabled; otherwise, Scheme-2 is enabled.
(Working Assumption) Enabling of either Scheme-1 or Scheme-2 should ensure the same RS type for RS measurement for current beam and new beam.
The above QCL RS is the RS w.r.t. QCL-TypeD, if there are two QCL RSs in the indicated TCI state. 

[117] Agreement
Regarding RS measurement for the new beam for Event 2, at least Option-3a is supported
Option-3a (explicit manner): The RS(s) for new beam(s) are explicitly configured
FFS: Option-3b/3c
Option-3b: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Option-3c: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of TCI state(s) in a configured subset of the legacy RRC-configured TCI state list

[117] Agreement
On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, for a report instance where N ≥ 1 beam(s) are reported, the following is supported.
RRC can enable or disable whether current beam is always reported
When enabled by RRC, the current beam + N beams from the measurement RSs for new beam(s) are reported
Note: The reported current beam is NOT counted in the N reported beams.
When disabled by RRC, N beams are reported.

[117] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A, the DCI format in Step-2 comprises UL-grant DCI format, and the second channel in Step-3 is at least PUSCH.
The UL-grant DCI format at least comprises DCI format 0_1/0_2.
FFS: DCI format 0_3
FFS: How to trigger the UEI beam report by the UL-grant DCI format
FFS: the DCI format in Step-2 comprises DL-grant DCI format, and the second channel in Step-3 is PUCCH.
1-bit field in the DL-grant DCI format is introduced to indicate the transmission of the UEI beam report
The PUCCH resource for HARQ-ACK transmission can be reused to carry both the HARQ-ACK and UEI beam report.
The DL-grant DCI format at least comprises DCI format 1_1/1_2.
FFS: DCI format 1_3
 
[117] Agreement
Regarding the triggering event determination for Event 2:
If within a time window (which is configurable), the number of Event-2 instance(s) for at least one same new beam is greater than or equal to a configurable number M, UE initiated beam report occurs.
Note: Event-2 instance for a new beam is determined if the L1-RSRP of the new beam becomes a threshold value better than the current beam
Above feature is subject to UE capability.
Basic feature: Once the L1-RSRP of the new beam becomes a threshold value better than the current beam, UE initiated beam report occurs
FFS: Whether the above is captured in RAN1 or RAN2 specification.

[117] Agreement
On UE-initiated/event-driven beam reporting, regarding trigger events, the following Event-1 and 7a/7b, are provided for down-selection or combination in RAN1#118 (possible outcome is that no new event is supported)
Event-1: Quality of the current beam is worse than a certain threshold.
Event-7a: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the worst quality.
Event-7b: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the best quality.

[117] Agreement
Regarding explicit RS configuration for new beam measurement for Event 2, down-select the following options in the RAN1#118:
Option-1: The RS(s) for new beam(s) are explicitly configured in one RS resource set associated with an CSI reporting configuration;
FFS: The RS in the RS resource set can be updated by MAC-CE. 
Option-2: A list of RS(s) for new beam measurement can be configured by RRC, and a subset can be activated for new beam measurement by MAC-CE.
FFS: If a list size is small, MAC-CE activation is not needed
Option-3: A list of RS resource (s) for new beam measurement can be configured by RRC, and a subset of RS resource(s) in the list can be provided for new beam measurement by indicated TCI state.
Others are not precluded.
FFS: Each RS for new beam measurement should be associated with a configured joint/DL TCI state which can be used as the indicated TCI state

[117] Agreement
Regarding RS measurement for the current beam for Event 2, for Option-2a, besides for scheme-1 and scheme-2, further study the following for handling the case that only one TRS is configured in the indicated TCI state. 
Option-1: Introducing additional scheme: the RS for current beam can be a CSI-RS for beam management derived from the QCL RS in the indicated TCI state;
Option-2: Further support TRS as measurement RS of current beam for determining L1-RSRP 
Option-3: Introducing additional scheme: The RS for current beam is explicitly configured by RRC or MAC-CE (Option-2C in RAN1 116b agreement).
Option-4: No further enhancement (i.e., in such case, Scheme-2 is used)
Others are not precluded.

RAN1#116-bis
[116b] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, following modes are supported:
Mode A (dynamically scheduling UCI by gNB):
Step 1: UE transmits a first PUCCH (one-bit/multi-bit) to request a resource for a second UL channel to carry beam report
FFS: Request format, e.g., SR or a new UCI type.
Step 2: UE detects the DCI format to indicate a resource for a second UL channel to carry beam report. 
Step 3: Beam report is transmitted in second UL channel.
FFS: Details on the second UL channel, e.g., whether the second UL channel is PUCCH, PUSCH or both
This mode is basic UE capability (i.e. all UE supporting UE-initiated/event-driven beam reporting should support this feature).
No new DCI format is introduced.
Mode B (UCI in pre-configured resource(s) for second UL channel):
Step 1: UE transmits a first PUCCH (one-bit/multi-bit) notifying a second UL channel to carry beam report
FFS: Notification format, e.g., SR or a new UCI type.
Step 2: UE transmits the beam report in the second UL channel. 
FFS: Details on the second UL channel, e.g., whether the second UL channel is PUCCH, PUSCH or both
The notification in Step1 is in a separate reporting instance from the beam report in Step 2. 
FFS: Whether UE receives acknowledge information with response to each step for all modes
For above procedures, cross-CC beam reporting is supported for both modes.
FFS: Details.

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding trigger-event detection for beam reporting, at least support Event-2: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the current beam.
At least L1-RSRP is supported as quality metrics used for Event-2 
FFS: How the L1-RSRP is used to determine the triggering event (e.g. timer, counter, filter coefficient)
FFS: Whether the network controls how the L1-RSRP is used to determine the triggering event 
Regarding RS measurement for the new beam for Event-2, down-select one or more of the following:
Option-3a (explicit manner): The RS(s) for new beam(s) are explicitly configured by RRC (e.g., reusing legacy configuration of RS measurement or in TCI-State) or MAC-CE
Option-3b (implicit manner): The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Option-3c (implicit manner): The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of configured TCI state(s).
Note-1: ‘New/current beam’ is for discussion purpose. 
Note-2: Other trigger events/quality metrics (e.g., L1-SINR) are not precluded.
Note-3: For above implicit manner(s), if there are two QCL RSs in a TCI state, the measurement RS is derived from RS w.r.t. QCL-TypeD, if applicable.

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding Event-2, the threshold value is RRC configured  

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding Event-2, ‘current beam’ is a beam corresponding to the indicated TCI state.
Regarding RS measurement for the current beam for Event-2, Option-2a is supported:
Option-2a (implicit manner): The RS for current beam is implicitly derived from a QCL RS of indicated TCI state.
FFS: The RS for current beam can be either the QCL RS in the indicated TCI state or the SSB which is QCLed with the QCL RS in the indicated TCI state.
FFS: Option-2c (explicit manner): The RS for current beam is explicitly configured by RRC or MAC-CE.
Note: SSB or CSI-RS can be configured

[116b] Agreement
On UE-initiated/event-driven beam reporting, further study the following trigger events: 
Event-1: Quality of the current beam is worse than a certain threshold.
Event-3: Quality of a new beam is better than a certain threshold. 
Event-4: Quality of the current beam is worse than a threshold 1, and quality of at least one new beam is better than a threshold 2.
Event-5: Absolute value of the difference between the quality of the current beam and the quality of at least one new beam is lower than a threshold.
Event-6: When the current beam is not in the best K>1 beams (out of configured beams for measurement and reporting).
Event-7a: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the worst quality.
Event-7b: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the best quality.
Event-8: Quality of M>1 new beams, such as L1-RSRP, become a threshold value better than the current beam.
Event-9: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the configured reference RS (can be SSB or CSI-RS).

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding UL signaling content(s) of L1-RSRP report depending on Event-2, in a report instance, the following options are provided for down-selection (other options are not precluded) in RAN1#117
Option-1 (variable size): N beam(s) are reported in the report instance, where N  {1, 2, ..., Nmax}
The N beam(s) should satisfy the condition of Event-2
Nmax is configured by gNB 
FFS: Whether the indication of payload size should be provided additionally.
Option-1a (variable size): N beam(s) are reported in the report instance, where N  {1, 2, ..., Nmax}
At least one of N reported beam(s) should satisfy the condition of Event-2
Nmax is configured by gNB 
FFS: Whether the indication of payload size should be provided additionally.
FFS: Details on how value of N is determined by the UE
Option-1b: N beam(s) are reported in the report instance, where N  {1, 2, ..., Nmax}
The N beam(s) should satisfy the condition of Event-2
Nmax is configured by gNB 
Payload size does not vary as a function of N
FFS: Zero-padding can be provided if N is less than Nmax.
Option-2: Only N=1 beam is reported in the report instance 
The reported beam should satisfy the condition of Event-2
Option-3: N ≥ 1 beam(s) are reported in the report instance,  
At least one of N reported beam(s) should satisfy the condition of Event-2
N is configured by gNB 
Other options are not precluded.
FFS: Whether the measurement results for current beam is always reported or can be enabled by RRC.
FFS: When current beam is reported, whether the current beam is counted in the N reported beams.  
The selected option shall satisfy Event-2.
RAN1#116
[116] Agreement
On UE-initiated/event-driven beam report, at least of following aspects should be included:
Trigger-event detection for beam reporting by UE
UE monitors RS to assess if a beam-reporting trigger condition has been met
FFS: Trigger condition for declaring beam-reporting event
Beam-report transmission by UE
Signaling contents in the beam report
Down-selection one or more options (strive for one) between the following options as signaling medium/container for beam report transmission
MAC-CE
UCI
Others are not precluded.
On UE-initiated/event-driven beam report, the following aspects may be included:
UE requesting UL resource(s) for the beam report
UE notifying transmission of beam report
gNB preconfigured resources
Other procedure(s) as required

[116] Agreement
On UE-initiated/event-driven beam reporting, regarding trigger-event detection for beam reporting, RAN1 further study at least the following aspects: quality metrics, event-definition and threshold.
Further study trigger events, including the following example as a starting point
Event-1: Quality of the current beam is worse than a certain threshold.
Event-2: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the current beam. 
Event-3: Quality of a new beam is better than a certain threshold. 
Event-4: Quality of the current beam is worse than a threshold 1, and quality of at least one new beam is better than a threshold 2.
Others are not precluded.
Note: Companies are encouraged to provide details on procedure (e.g. how it is used) related to their preferred event

[116] Agreement
On UE-initiated/event-driven beam reporting, at least support L1-RSRP as a measurement quantity on SSB for intra-cell and inter-cell, and periodic CSI-RS for beam management
Notes: measurement results may be contained in the beam report and/or used as quality metric(s) to initiate/trigger the reporting. 
FFS: Semi-persistent CSI-RS and aperiodic CSI-RS.
FFS: Whether/how to support L1-SINR measurement, assuming legacy RS or RS combination (e.g., CMR only, CMR+ZP/NZP-IMR) for Rel-16 SINR is reused. 
FFS: Whether/how to specify filtering operation for L1-RSRP.

[116] Agreement
On UE-initiated/event-driven beam reporting, regarding signaling content(s), at least support DL RS resource indicator and L1-RSRP 
FFS: Study and decide whether additional contents can be supported.
FFS: L1-RSRP format, e.g., absolute and/or differential value.
Note: Above does not imply to preclude discussion on L1-RSRP filtering.
The actual reported content depends on the triggering event
Support of one or multiple events will be discussed separately 

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

Agenda item:	9.2.1
Source: 	Moderator (ZTE)
Title: 	Moderator Summary #3 on UE-initiated/event-driven beam management 
Document for:	Discussion and Decision

Conclusion
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A, there is no RAN1 consensus on additionally supporting that the DCI format in Step-2 comprises DL-grant DCI format, and the second channel in Step-3 is PUCCH.

[118] Agreement
On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, the candidate value of ‘N’ at least comprises {1, 2, 3, 4}  
FFS: additional candidate value(s) of {5, 6, 7, 8}
FFS: If ‘N’ is not RRC configured, only one L1-RSRP and CRI/SSBRI are reported by default. 

[118] Agreement
Regarding RS measurement for the current beam for Event 2, for Option-2a, besides for scheme-1 and scheme-2, further down-select one of the following for handling the case that only one TRS is configured in the indicated TCI state in RAN1#118bis
Option-1: Introducing additional scheme: the RS for current beam can be a CSI-RS for beam management derived from the QCL RS in the indicated TCI state;
Option-2: Further support TRS as measurement RS of current beam for determining L1-RSRP
Option-3: Introducing additional scheme: The RS for current beam is explicitly configured by RRC or MAC-CE (Option-2C in RAN1 116b agreement).
Option-4: No further enhancement 
Note: If there is no consensus in RAN1 on one of Options 1/2/3, Option 4 will be taken. 

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, for the case the pre-configured Type-1 CG PUSCH carry the beam report, for the second UL channel in Mode-B, at least one or both of the following should be supported:
Option-1: The same Type-1 CG PUSCH can carry UL-SCH and the beam report.
Option-2: The Type-1 CG PUSCH is a dedicated type-1 CG PUSCH for carrying the beam report
Note: This PUSCH can NOT carry UL-SCH. This PUSCH can NOT carry any other UCI.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-B, UEI beam report is carried on a first available transmission occasion of the second UL channel X symbols after sending the last symbol of report notification on the first PUCCH channel.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding resource mapping/configuration between first and second channel in Mode-B, for a given CSI report configuration, the following is provided for down-selection.
Option-1 (one-to-one): Only one first PUCCH resource and only one pre-configured resource for second UL channel can be associated with the CSI report configuration for UE-initiated/event-driven beam reporting.
Option-1A: Same periodicity between first PUCCH resource and pre-configured resource for second UL channel.
Option-1B: No restriction in terms of periodicity.
Option-2 (one-to-M): Only one first PUCCH resource and one or more pre-configured resource(s) for second UL channel can be associated with CSI report configuration for UE-initiated/event-driven beam reporting.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, for at least Mode-B, the beam report should be carried in the second UL channel in the CC where the corresponding CSI report configuration is configured.
Above applies to both cross-CC and same-CC beam report. 
Note: Above is applied to the case that second UL channel is PUSCH. 
FFS: Whether the first and second channels can be from the same/different CC. 

[118] Working Assumption
On UE-initiated/event-driven beam reporting, regarding trigger events, besides for Event-2, Event-1 and Event-7 are both supported.
Event-1: Quality of the current beam is worse than a certain threshold.
Event-7: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the M-th best quality.
M is RRC configured with subjective to UE capability signalling
UE may only indicate a single candidate value or not support Event-7. 
The additionally supported events will reuse the same design as event 2 – unless there is consensus to do otherwise
The additionally supported events will be lower priority compared to event 2.

[118] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A and/or Mode-B, further study the following for first PUCCH transmission
UCI multiplexing/dropping/prioritization rule
Conditions for the transmission of the first PUCCH.
Whether the PUCCH resource in the first PUCCH channel can be associated with multiple CSI report configurations for UE-initiated/event-driven beam reporting from one or multiple CC(s).
Whether/how to re-transmit the first PUCCH channel.
Whether/how to apply prohibit-timer or maximum number of (re)transmission(s) for first PUCCH channel.
RAN1#117
[117] Agreement
On UE-initiated/event-driven beam reporting, regarding UL signaling content(s) of L1-RSRP report depending on Event-2, in a report instance, at least Option-3 is supported
Option-3: N ≥ 1 beam(s) are reported in the report instance,  
At least one of N reported beam(s) should satisfy the condition of Event-2
N is configured by gNB
FFS: candidate value of ‘N’.  
FFS: RRC can enable or disable whether current beam is always reported in addition to the N beams 
FFS: Option-1/1a/1b/2.  
Above applies at least for the single CC case

[117] Working Assumption
On beam report transmission procedure for UE-initiated/event-driven beam reporting
For mode-A, at least support one-bit indication in the first PUCCH channel to request a resource for a second UL channel to carry beam report.
In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.  
For mode-B, at least support one-bit indication in the first PUCCH channel to notify a second UL channel to carry beam report.
In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.  
FFS: Whether/how to support multi-bit indication in the first PUCCH for mode-A and mode-B, e.g., when multi-event(s) are approved.
FFS: details on the dedicated RRC signaling
Above applies at least for the single CC case.

[117] Agreement
Regarding RS measurement for the current beam for Event 2, for Option-2a, support the both schemes as follows. 
Scheme-1: RS for current beam is the QCL RS in the indicated TCI state
FFS: Whether/How to handle the case if only one TRS is configured in the indicated TCI state.
Scheme-2: the RS for current beam is the SSB which is QCLed with the QCL RS in the indicated TCI state.
Enabling one of either Scheme-1 or Scheme-2 is selected by NW.
FFS: The above selection is via an explicit RRC parameter or an implicit manner, e.g., if the RS(s) for new beam are CSI-RS, Scheme-1 is enabled; otherwise, Scheme-2 is enabled.
(Working Assumption) Enabling of either Scheme-1 or Scheme-2 should ensure the same RS type for RS measurement for current beam and new beam.
The above QCL RS is the RS w.r.t. QCL-TypeD, if there are two QCL RSs in the indicated TCI state. 

[117] Agreement
Regarding RS measurement for the new beam for Event 2, at least Option-3a is supported
Option-3a (explicit manner): The RS(s) for new beam(s) are explicitly configured
FFS: Option-3b/3c
Option-3b: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Option-3c: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of TCI state(s) in a configured subset of the legacy RRC-configured TCI state list

[117] Agreement
On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, for a report instance where N ≥ 1 beam(s) are reported, the following is supported.
RRC can enable or disable whether current beam is always reported
When enabled by RRC, the current beam + N beams from the measurement RSs for new beam(s) are reported
Note: The reported current beam is NOT counted in the N reported beams.
When disabled by RRC, N beams are reported.

[117] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A, the DCI format in Step-2 comprises UL-grant DCI format, and the second channel in Step-3 is at least PUSCH.
The UL-grant DCI format at least comprises DCI format 0_1/0_2.
FFS: DCI format 0_3
FFS: How to trigger the UEI beam report by the UL-grant DCI format
FFS: the DCI format in Step-2 comprises DL-grant DCI format, and the second channel in Step-3 is PUCCH.
1-bit field in the DL-grant DCI format is introduced to indicate the transmission of the UEI beam report
The PUCCH resource for HARQ-ACK transmission can be reused to carry both the HARQ-ACK and UEI beam report.
The DL-grant DCI format at least comprises DCI format 1_1/1_2.
FFS: DCI format 1_3
 
[117] Agreement
Regarding the triggering event determination for Event 2:
If within a time window (which is configurable), the number of Event-2 instance(s) for at least one same new beam is greater than or equal to a configurable number M, UE initiated beam report occurs.
Note: Event-2 instance for a new beam is determined if the L1-RSRP of the new beam becomes a threshold value better than the current beam
Above feature is subject to UE capability.
Basic feature: Once the L1-RSRP of the new beam becomes a threshold value better than the current beam, UE initiated beam report occurs
FFS: Whether the above is captured in RAN1 or RAN2 specification.

[117] Agreement
On UE-initiated/event-driven beam reporting, regarding trigger events, the following Event-1 and 7a/7b, are provided for down-selection or combination in RAN1#118 (possible outcome is that no new event is supported)
Event-1: Quality of the current beam is worse than a certain threshold.
Event-7a: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the worst quality.
Event-7b: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the best quality.

[117] Agreement
Regarding explicit RS configuration for new beam measurement for Event 2, down-select the following options in the RAN1#118:
Option-1: The RS(s) for new beam(s) are explicitly configured in one RS resource set associated with an CSI reporting configuration;
FFS: The RS in the RS resource set can be updated by MAC-CE. 
Option-2: A list of RS(s) for new beam measurement can be configured by RRC, and a subset can be activated for new beam measurement by MAC-CE.
FFS: If a list size is small, MAC-CE activation is not needed
Option-3: A list of RS resource (s) for new beam measurement can be configured by RRC, and a subset of RS resource(s) in the list can be provided for new beam measurement by indicated TCI state.
Others are not precluded.
FFS: Each RS for new beam measurement should be associated with a configured joint/DL TCI state which can be used as the indicated TCI state

[117] Agreement
Regarding RS measurement for the current beam for Event 2, for Option-2a, besides for scheme-1 and scheme-2, further study the following for handling the case that only one TRS is configured in the indicated TCI state. 
Option-1: Introducing additional scheme: the RS for current beam can be a CSI-RS for beam management derived from the QCL RS in the indicated TCI state;
Option-2: Further support TRS as measurement RS of current beam for determining L1-RSRP 
Option-3: Introducing additional scheme: The RS for current beam is explicitly configured by RRC or MAC-CE (Option-2C in RAN1 116b agreement).
Option-4: No further enhancement (i.e., in such case, Scheme-2 is used)
Others are not precluded.

RAN1#116-bis
[116b] Agreement
On beam report transmission procedure for UE-initiated/event-driven beam reporting, following modes are supported:
Mode A (dynamically scheduling UCI by gNB):
Step 1: UE transmits a first PUCCH (one-bit/multi-bit) to request a resource for a second UL channel to carry beam report
FFS: Request format, e.g., SR or a new UCI type.
Step 2: UE detects the DCI format to indicate a resource for a second UL channel to carry beam report. 
Step 3: Beam report is transmitted in second UL channel.
FFS: Details on the second UL channel, e.g., whether the second UL channel is PUCCH, PUSCH or both
This mode is basic UE capability (i.e. all UE supporting UE-initiated/event-driven beam reporting should support this feature).
No new DCI format is introduced.
Mode B (UCI in pre-configured resource(s) for second UL channel):
Step 1: UE transmits a first PUCCH (one-bit/multi-bit) notifying a second UL channel to carry beam report
FFS: Notification format, e.g., SR or a new UCI type.
Step 2: UE transmits the beam report in the second UL channel. 
FFS: Details on the second UL channel, e.g., whether the second UL channel is PUCCH, PUSCH or both
The notification in Step1 is in a separate reporting instance from the beam report in Step 2. 
FFS: Whether UE receives acknowledge information with response to each step for all modes
For above procedures, cross-CC beam reporting is supported for both modes.
FFS: Details.

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding trigger-event detection for beam reporting, at least support Event-2: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the current beam.
At least L1-RSRP is supported as quality metrics used for Event-2 
FFS: How the L1-RSRP is used to determine the triggering event (e.g. timer, counter, filter coefficient)
FFS: Whether the network controls how the L1-RSRP is used to determine the triggering event 
Regarding RS measurement for the new beam for Event-2, down-select one or more of the following:
Option-3a (explicit manner): The RS(s) for new beam(s) are explicitly configured by RRC (e.g., reusing legacy configuration of RS measurement or in TCI-State) or MAC-CE
Option-3b (implicit manner): The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Option-3c (implicit manner): The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of configured TCI state(s).
Note-1: ‘New/current beam’ is for discussion purpose. 
Note-2: Other trigger events/quality metrics (e.g., L1-SINR) are not precluded.
Note-3: For above implicit manner(s), if there are two QCL RSs in a TCI state, the measurement RS is derived from RS w.r.t. QCL-TypeD, if applicable.

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding Event-2, the threshold value is RRC configured  

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding Event-2, ‘current beam’ is a beam corresponding to the indicated TCI state.
Regarding RS measurement for the current beam for Event-2, Option-2a is supported:
Option-2a (implicit manner): The RS for current beam is implicitly derived from a QCL RS of indicated TCI state.
FFS: The RS for current beam can be either the QCL RS in the indicated TCI state or the SSB which is QCLed with the QCL RS in the indicated TCI state.
FFS: Option-2c (explicit manner): The RS for current beam is explicitly configured by RRC or MAC-CE.
Note: SSB or CSI-RS can be configured

[116b] Agreement
On UE-initiated/event-driven beam reporting, further study the following trigger events: 
Event-1: Quality of the current beam is worse than a certain threshold.
Event-3: Quality of a new beam is better than a certain threshold. 
Event-4: Quality of the current beam is worse than a threshold 1, and quality of at least one new beam is better than a threshold 2.
Event-5: Absolute value of the difference between the quality of the current beam and the quality of at least one new beam is lower than a threshold.
Event-6: When the current beam is not in the best K>1 beams (out of configured beams for measurement and reporting).
Event-7a: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the worst quality.
Event-7b: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the best quality.
Event-8: Quality of M>1 new beams, such as L1-RSRP, become a threshold value better than the current beam.
Event-9: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the configured reference RS (can be SSB or CSI-RS).

[116b] Agreement
On UE-initiated/event-driven beam reporting, regarding UL signaling content(s) of L1-RSRP report depending on Event-2, in a report instance, the following options are provided for down-selection (other options are not precluded) in RAN1#117
Option-1 (variable size): N beam(s) are reported in the report instance, where N  {1, 2, ..., Nmax}
The N beam(s) should satisfy the condition of Event-2
Nmax is configured by gNB 
FFS: Whether the indication of payload size should be provided additionally.
Option-1a (variable size): N beam(s) are reported in the report instance, where N  {1, 2, ..., Nmax}
At least one of N reported beam(s) should satisfy the condition of Event-2
Nmax is configured by gNB 
FFS: Whether the indication of payload size should be provided additionally.
FFS: Details on how value of N is determined by the UE
Option-1b: N beam(s) are reported in the report instance, where N  {1, 2, ..., Nmax}
The N beam(s) should satisfy the condition of Event-2
Nmax is configured by gNB 
Payload size does not vary as a function of N
FFS: Zero-padding can be provided if N is less than Nmax.
Option-2: Only N=1 beam is reported in the report instance 
The reported beam should satisfy the condition of Event-2
Option-3: N ≥ 1 beam(s) are reported in the report instance,  
At least one of N reported beam(s) should satisfy the condition of Event-2
N is configured by gNB 
Other options are not precluded.
FFS: Whether the measurement results for current beam is always reported or can be enabled by RRC.
FFS: When current beam is reported, whether the current beam is counted in the N reported beams.  
The selected option shall satisfy Event-2.
RAN1#116
[116] Agreement
On UE-initiated/event-driven beam report, at least of following aspects should be included:
Trigger-event detection for beam reporting by UE
UE monitors RS to assess if a beam-reporting trigger condition has been met
FFS: Trigger condition for declaring beam-reporting event
Beam-report transmission by UE
Signaling contents in the beam report
Down-selection one or more options (strive for one) between the following options as signaling medium/container for beam report transmission
MAC-CE
UCI
Others are not precluded.
On UE-initiated/event-driven beam report, the following aspects may be included:
UE requesting UL resource(s) for the beam report
UE notifying transmission of beam report
gNB preconfigured resources
Other procedure(s) as required

[116] Agreement
On UE-initiated/event-driven beam reporting, regarding trigger-event detection for beam reporting, RAN1 further study at least the following aspects: quality metrics, event-definition and threshold.
Further study trigger events, including the following example as a starting point
Event-1: Quality of the current beam is worse than a certain threshold.
Event-2: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the current beam. 
Event-3: Quality of a new beam is better than a certain threshold. 
Event-4: Quality of the current beam is worse than a threshold 1, and quality of at least one new beam is better than a threshold 2.
Others are not precluded.
Note: Companies are encouraged to provide details on procedure (e.g. how it is used) related to their preferred event

[116] Agreement
On UE-initiated/event-driven beam reporting, at least support L1-RSRP as a measurement quantity on SSB for intra-cell and inter-cell, and periodic CSI-RS for beam management
Notes: measurement results may be contained in the beam report and/or used as quality metric(s) to initiate/trigger the reporting. 
FFS: Semi-persistent CSI-RS and aperiodic CSI-RS.
FFS: Whether/how to support L1-SINR measurement, assuming legacy RS or RS combination (e.g., CMR only, CMR+ZP/NZP-IMR) for Rel-16 SINR is reused. 
FFS: Whether/how to specify filtering operation for L1-RSRP.

[116] Agreement
On UE-initiated/event-driven beam reporting, regarding signaling content(s), at least support DL RS resource indicator and L1-RSRP 
FFS: Study and decide whether additional contents can be supported.
FFS: L1-RSRP format, e.g., absolute and/or differential value.
Note: Above does not imply to preclude discussion on L1-RSRP filtering.
The actual reported content depends on the triggering event
Support of one or multiple events will be discussed separately 

3GPP TSG RAN WG1 #121	R1-2504476
St Julian’s, Malta, May 19th – 23rd, 2025
Source:		KDDI Corporation
Title:		Remaining issues on enhancements for UE-initiated/event-driven beam management
Agenda Item:	9.2.1	Enhancements for UE-initiated/event-driven beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, we showed our views on the enhancements for UE-initiated/event-driven beam management. Based on above discussions, we have the following observations and proposals: 

Observation 1:
On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, if introducing prohibit timer or time interval is supported, a unified solution should be supported for both mode-A and mode-B. 

Observation 2:
On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, multiplexing/dropping rule(s) of 1-bit first PUCCH, for the Case-2, always piggyback 1-bit indication of first PUCCH into the PUSCH can avoid blind decoding in the gNB. 

Observation 3:
Regarding the definition of “the available transmission occasion of the second UL channel”, the multiplexing/dropping rules for the first PUCCH are still under discussion, so these results also need to be taken into account.

Proposal 1:
On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, if introducing prohibit timer or time interval is supported, a unified solution should be supported for both mode-A and mode-B. 

Proposal 2:
On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, the following candidate #1 (i.e., prohibit timer) should be supported. 
Candidate#1: To introduce a prohibit timer for mode-A and/or mode-B
Option-1A: In the case that triggering-event associated with the CSI report configuration is determined [by the same triggering beams(s) as the last transmitted PUCCH], if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer
Option-1B: In the case that triggering-event associated with the CSI report configuration is determined, if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the first PUCCH transmission, the UE starts the prohibit timer

Proposal 3:
On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, in candidate # 1 (i.e., prohibit timer), the following Option-1A should be supported. 
Candidate#1: To introduce a prohibit timer for mode-A and/or mode-B
Option-1A: In the case that triggering-event associated with the CSI report configuration is determined [by the same triggering beams(s) as the last transmitted PUCCH], if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer

Proposal 4:
On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, in candidate # 1 (i.e., prohibit timer), the following Option-1B should be supported. 
Candidate#1: To introduce a prohibit timer for mode-A and/or mode-B
Option-1B: In the case that triggering-event associated with the CSI report configuration is determined, if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the first PUCCH transmission, the UE starts the prohibit timer

Proposal 5:
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, the following rule should be supported for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
FFS: The 1-bit indication is always multiplexed in the PUSCH, regardless that UEI beam report procedure is triggered.
FFS: If the PUSCH should be with UL-SCH or not for UEI beam report

Proposal 6: 
On UE-initiated/event-driven beam reporting, there is no further enhancement on the case that UE has not sent any first PUCCH while UE detects the DCI format to indicate a resource for second PUSCH to carry UE-initiated/event-driven beam reporting, for Mode-A.

Proposal 6: 
On UE-initiated/event-driven beam reporting, on the case that UE has not sent any first PUCCH while UE detects the DCI format to indicate a resource for second PUSCH to carry UE-initiated/event-driven beam reporting, for Mode-A, the UE does not send anything.

Proposal 7: 
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the value of X symbols for determining available transmission occasion of the second UL channel on Mode-B, at least X=0 should be supported. 

Proposal 8: 
On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the value of X symbols for determining available transmission occasion of the second UL channel on Mode-B, the ‘available’ transmission occasion of the second UL channel is clarified as ‘an available transmission occasion corresponds to a configured PUSCH resource for UEIBR is within uplink symbols, and does not collide with a channel with a higher priority (at least SSB and PRACH)’. 
Note: RAN1 can revisit this clarification when the multiplexing/dropping rules for the first PUCCH are determined. 

Proposal 9:
On UE-initiated/event-driven beam reporting with Event-1, the second beam report can be skipped. 

Proposal 10:
On UE-initiated/event-driven beam reporting with Event-7, 'the activated TCI state with the Q-th best quality' should be determined for each measurement occasion.

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

Source:	NTT DOCOMO, INC.
Title:	Discussion on Enhancements for UE-initiated/event-driven beam management
Agenda Item:	9.2.1
Document for: 	Discussion and Decision

Conclusion
In this contribution, we discussed the enhancements for UE-initiated/event-driven beam management. Based on the discussion, we made following observations and proposals.
Trigger-event detection
Proposal 1
On RS measurement for new beam, do not support Option-3b/3c.
Option-3b: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Option-3c: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of TCI state(s) in a configured subset of the legacy RRC-configured TCI state list.

Proposal 2
For RS resources in a RS resource set for UEIBR, support MAC CE to update RS resource(s) in a RS resource set for UEIBR.

Proposal 3
For resetting conditions of counter, support at least following all conditions.
Candidate#5: The time window expires;
Candidate#7: The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured or update by MAC CE (if supported).



Proposal 4
For cross-CC beam reporting, support Alt-1.
Alt-1: The periodicity of the current beam RS should be the same as that of the new beam RS(s).
The evaluation periodicity is the same as the periodicity of the current and new beam RS(s).

Proposal 5
When the counter and timer is configured for Event-7, support Option-1.
Option-1: The event instance(s) counting is per new beam (as Event-2).

UL signal content
Proposal 6
Regarding report format for event-2, the following condition should be limited to Mode B.
“at least one of N reported beam(s) should satisfy the condition of Event-2”.

Observation 1
RAN1 needs to consider the solution (i.e., other than additional report contents) to achieve the use case of Event-7.

Proposal 7
For report format of Event-7, to identify the TCI states to be activated/deactivated by NW, support the following:
RSs configured in current activated TCI states should be configured in new beam RS configuration.
When N RSs are configured to be reported in a single report instance,
(N-X) new beam RSs and X RSs are reported.
X is determined by UE based on the measurement results. i.e., up to UE implementation
The X RSs are derived from the worst X current activated TCI states.

Proposal 8
Support L1-SINR as measurement quantity.
For L1-SINR, RS combination configuration (i.e., CMR only or CMR+ZP-IMR or CMR+NZP-IMR) for Rel-16 L1-SINR is reused.
Support semi-persistent CSI-RS and aperiodic CSI-RS for measurement RS configuration for UE-initiated beam report.

UL signal medium/container
Observation 2
Candidate#1 should be focused considering definition of time window agreed in the last meeting.

Proposal 9
Regarding prohibit timer for Mode A and Mode B, support Option-1A.
Option-1A: In the case that triggering-event associated with the CSI report configuration is determined [by the same triggering beams(s) as the last transmitted PUCCH], if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer
Observation 3
For case-2: The 1-bit first PUCCH is collided/overlapped with a PUSCH, down-selection should be based on how often this collision case happens.

Proposal 10
Regarding dropping/multiplexing rule for first PUCCH of Mode A and B in case-2: The 1-bit first PUCCH is collided/overlapped with a PUSCH, 
Option-3 is slightly preferred.
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
If it is identified that the collision case does not happen frequently, okay to support Option-1.
Option-1: Prioritize first PUCCH over PUSCH, i.e., PUSCH is dropped.

Proposal 11
Regarding the multiplexing/dropping rule(s) the 1-bit first PUCCH is collided/overlapped with a PUCCH format 2/3/4 carrying HARQ/CSI/SR, support Option-1.
Option-1: To follow legacy SR multiplexing rule.
FFS: how to extend the field of  bits representing at most one of positive SR or positive new UCI bit
For example, a codepoint in the field is generated based on a first ascending order of the values of SR ID associated with the SRs and a second ascending order of the values of PUCCH resource ID associated with the first PUCCHs.

Proposal 12
When a Type-1 CG-PUSCH with UEIBR for Mode-B collides with only SR on a PUCCH, transmit the Type-1 CG-PUSCH with UEIBR for Mode-B and do not transmit the PUCCH (i.e., drop SR).
When a Type-1 CG-PUSCH with UEIBR for Mode-B collides with SR and HARQ-ACK/CSI on a PUCCH, transmit the Type-1 CG-PUSCH with UEIBR for Mode-B multiplexing HARQ-ACK (if any) and do not transmit the PUCCH (i.e., drop SR and CSI, if any).

Proposal 13
To clarify whether the agreement of ‘reuse the intra-UE multiplexing/prioritization rules of PUSCH with SP-CSI for Type-1 CG PUSCH with UEI-BR for Mode B’ implies following
Reuse the collision handling between PUSCH with SP-CSI and PUSCH with data/UL-SCH for the collision handling between Type-1 CG-PUSCH with UEIBR for Mode-B and PUSCH with data/UL-SCH.
When a Type-1 CG-PUSCH with UEIBR for Mode-B and PUSCH with SP-CSI collide, transmit the Type-1 CG-PUSCH with UEIBR for Mode-B and do not transmit the PUSCH with SP-CSI.

Proposal 14
On beam report transmission procedure for UE-initiated/event-driven beam reporting, for the second UL channel in Mode-A, reuse the intra-UE multiplexing/prioritization rules of scheduled PUSCH with AP-CSI for scheduled PUSCH with UEIBR for Mode-A. 







Proposal 15
On acknowledge information,
Mode A:
No need acknowledge information to second UL channel.
Mode B:
Support acknowledge information to first UL channel.
Whether to receive acknowledge information with response to first UL channel of Mode B is configured by NW.
Support acknowledge information to second UL channel.
If no acknowledge information is received at UE after corresponding transmission of second UL channel, UE retransmits first UL channel.

Proposal 16
For the definition of the CSI reference resource for UEIBR, reuse the definition in the legacy specification of aperiodic CSI reporting, where n' is the uplink slot in which the UE transmits the second PUSCH.

Proposal 17
The number of CPUs occupied by the processing of a UEIBR  should be equal to 1.

Proposal 18
The start timing and the end timing of the CPU occupancy duration for UEIBR should be defined as follows:
The starting timing
The first symbol of the earliest CMR resource for UEIBR measurement/evaluation after either RRC configuration including corresponding UEIBR config or UEIBR transmission on second PUSCH
The ending timing
The last symbol of corresponding second PUSCH transmission

Cross-CC beam reporting
Proposal 19
Support to introduce an RRC parameter to indicate ServCellIndex that corresponds to the configured first PUCCH resource in CSI report config.

Beam application latency reduction
Proposal 20
To reduce beam application latency after a UEIBR is sent, support original Alt-3.
Alt3: After sending a UE-initiated beam report, the UE could store the QCL properties of the SSB associated with the reference signal reported in the beam report. 
In such case, at the reception of a subsequent reception of Unified TCI States Activation/Deactivation MAC CE, the UE activates new beam(s) without additional SSB reception 

3GPP TSG RAN WG1 #121		   		 	         	    	         R1-2504535  
St Julian’s, Malta, May 19th – 23th, 2025
Agenda Item:  9.2.1
Source:	ITRI, Acer Incorporated
Title:	Discussion on UE-initiated/event-driven beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, we have the following proposals:
Proposal 1: If a triggering event is detected and the prohibit timer is not running, the UE can transmit the first PUCCH and then start the prohibit timer at the first symbol after the end of the PUSCH transmission.
Proposal 2: When the 1-bit first PUCCH is collided/overlapped with a PUSCH, Piggyback 1-bit indication of first PUCCH into the PUSCH.
Proposal 3: Regarding the evaluation periodicity of Event-2 instances, the evaluation periodicity is the same as shortest periodicity of the current beam RS and new beam RS(s).
Proposal 4: For resetting the counting of Event-2 instances, the UE should reset the event instance counting if any of the following conditions are met: the new beam RS is reconfigured, or the number of beam report transmissions exceeds a threshold.
Proposal 5: Regarding explicit RS configuration for new beam measurement for Event-2, if the RS(s) for new beam(s) are configured in one RS resource set associated with an CSI reporting configuration, the CSI reporting configuration is configured with a new reportConfigType to indicate the reporting type is UE-initiated.

3GPP TSG RAN WG1 #121	R1-2504572
St Julian’s, Malta, May 19th – 23th, 2025
Agenda Item:	9.2.1
Source: 	ASUSTeK
Title:  	Discussion on UE initiated beam report
Document for:	Discussion and Decision

Conclusion
In this contribution, we have following proposals:
Proposal 1: RAN1 supports Option-1 or Option-3 for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH.
Proposal 2: For case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH, regarding different priority index between PUCCH and PUSCH.
If option-1 is agreed, RAN1 supports new UCI type has higher priority than PUSCH except PUSCH with priority index 1, if configured.
If option-3 is agreed, reusing legacy prioritization rule for different priority index

3GPP TSG RAN WG1 #121	R1-2504579
St Julian’s, Malta, May 19th – 23th, 2025
Source:	NICT
Title:	Discussion on Enhancements for UE-initiated/event-driven beam management
Item:	9.2.1
Document for:	Discussion

Conclusion
In this contribution, we presented the following proposals:
Proposal 1: As for the contents of the beam report, L1-SINR can be carried in the beam report.
Proposal 2: Regarding a prohibit timer for Mode A and Mode B, support Option-1A.
Option-1A: In the case that triggering-event associated with the CSI report configuration is determined [by the same triggering beams(s) as the last transmitted PUCCH], if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer
Proposal 3: On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH, support Option-3,
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
The PUSCH can be with UL-SCH or not for UEI beam report.
FFS: The 1-bit indication is always multiplexed in the PUSCH, regardless that UEI beam report procedure is triggered.

3GPP TSG RAN WG1 #121                                                  R1-2504607
Malta, MT, May 9th – 23th, 2025

Agenda Item:	9.2.1
Source:			TCL
Title:			Discussion on UE-initiated/event-driven beam management
Document for:	Discussion and Decision
1 

Conclusion
In these contributions, our opinions on UE-initiated/event-driven beam management are listed as follows.
Support PUCCH as the second channel.
Support option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
The activated beam corresponding to the Q-th best activated TCI state should be indicated to UE. 
The higher parameter used to indicate the Q-th best activated TCI state can be included in CSI-reportConfig.
One-bit indication with short PUCCH will result in the difficulty of multiplexing.
For beam reporting, multi-bit indication in the first PUCCH should also be supported.
Support Alt-3: After sending a UE-initiated beam report, the UE could store the QCL properties of the SSB associated with the reference signal reported in the beam report.
Support option-2: RS resource set for new beam is configured in the CSI reporting configuration, and the following implicit manner for enabling one of either scheme-1 or scheme-2 is used.
4