3GPP TSG RAN WG1 Meeting #120bis	R1-2501716
Wuhan, China, April 7th – 11th, 2025
Agenda Item:	9.2.1
Source:	Futurewei
Title:	Enhancements for UE-initiated/Event-driven Beam Management
Document for:	Discussion and decision 

Conclusions
Based on above discussions, we have the following observations and proposals:
Observation 1: The reported new beam(s) in the UEI/ED beam report that satisfy event conditions should be used as soon as possible to update the activated TCI state list/preconfigured TCI state pool as delays in utilization may render the QCL properties stored by the UE obsolete.
Observation 2: Alt-1 can significantly reduce signaling overhead and beam application latency for both cases of reported new beam(s) being within and outside preconfigured TCI state pool.
Observation 3: For Alt-2 and Alt-3, the latency and overhead are higher than those of Alt-1, especially for the case of reported new beam(s) being outside preconfigured TCI state pool.
Proposal 1: All reported new beams should be assumed to be synchronized, as UE determines the reported new beams/RS(s) based on its beam measurements.
Proposal 2: To reduce beam application latency after sending UE-initiated beam report, a unified solution, for both cases of reported new beam(s) being outside and within the preconfigured TCI state pool, is preferred.
Proposal 3: To reduce beam application latency after sending UE-initiated 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 
Proposal 4: The confirmation for the UEI/ED beam report can either leverage the confirmation procedure of the beam failure recovery procedure of the SpCell or utilize a new MAC CE (or an enhancement of the legacy TCI state activation/deactivation command MAC CE).
Proposal 5: Support that each of the new beam(s) can be preconfigured with an associated TCI state and the confirmation from NW can indicate one or multiple beams of the reported new beam(s). The TCI state(s) associated with the confirmed reported new beam(s) are used to update the activated TCI state list and the TCI state pool, if applicable.
Proposal 6: 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 7: Both Option-1 and Option-2 are viable considerations, whereas Option-3 is not preferred.
Option-1: It is up to UE implementation to select one of configuration.
Option-2: The UEI beam report with highest priority is reported
Option-3: The report triggered in the latest measurement is reported in PUSCH
Proposal 8: Confirm the Working Assumption: For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.
Proposal 9: DO NOT support Alt-2.
Alt-2: Multiple UEI beam reports associated with the same PUCCH resource for first PUCCH can be transmitted in the second PUSCH
Proposal 10: 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 11: Option-1 and Option-2 can be considered for further discussions.
Option-1: The measurement window is from T_PUCCH – T_proc – T_window to T_PUCCH – T_proc, where T_PUCCH is a transmission occasion of a first PUCCH, and T_proc is RRC configured.
Option-2: The measurement window is from T_Instance – T_window to T_Instance, where T_Instance is an evaluation occasion of event instance, and T_proc is RRC configured.
The UEI beam report in the second PUSCH is based on the most recent measurement for new/current beam RS(s).

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


Agenda Item: 		9.2.1
Source:				InterDigital, Inc.
Title:						On Specifications 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.

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 Meeting #120bis	R1-2501780
Wuhan, China, April 7th – 11th, 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: On beam report transmission procedure for UE-initiated/event-driven beam reporting in both Mode-A and Mode-B, support to introduce a prohibit-timer for first PUCCH.
In the case that triggering-event associated with a 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 second PUSCH transmission, the UE starts the prohibit timer.
Proposal 2: 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.
Proposal 3: Regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH for the Case-3 that multiple 1-bit first PUCCHs corresponding to different CSI configuration for UE-initiated/event-driven beam reporting are overlapping in the time domain, support that it is up to UE implementation to transmit only one of the 1-bit first PUCCHs.
Proposal 4: Regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH for the Case-4 that the 1-bit first PUCCH is collided/overlapped with a PUCCH format 0/1 carrying HARQ-ACK information, support that the PUCCH resource of the 1-bit first PUCCH is to carry the multiplexing of the 1-bit indication and the HARQ-ACK information via cyclic shift when using PUCCH format 0, and the PUCCH resource of the 1-bit first PUCCH is to carry the HARQ-ACK information only when using PUCCH format 1.
Proposal 5: 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 indicates a positive/negative SR or BRI.
Proposal 6: On beam report transmission procedure for UE-initiated/event-driven beam reporting, in order to clarify that the Type-1 CG PUSCH for carrying the beam report can carry any other UCI in Mode-B, support to down-select one of the following alternatives:
Alt-1: UE multiplexes the HARQ-ACK information, 1-bit indication in first PUCCH, SR or CSI report on the Type-1 CG PUSCH for carrying the beam report based on collision handling rules.
Alt-2: UE always can multiplex the HARQ-ACK information, 1-bit indication in first PUCCH, SR and/or CSI report on the Type-1 CG PUSCH for carrying the beam report in case of overlapping occurs.
Proposal 7: 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 and other UCI in Mode-B, support to leverage the legacy UCI multiplexing/dropping rules as much as possible, i.e., 
UE can multiplex HARQ-ACK information and BRI in the pre-configured Type-1 CG PUSCH carrying the beam report.
UE does not transmit the Type-1 CG-PUSCH carrying UEI beam reports when a PUCCH carrying positive SR overlaps with the Type-1 CG-PUSCH.
UE does not multiplex CSI reports from the PUCCH in the pre-configured Type-1 CG PUSCH carrying the beam report.
Proposal 8: On beam report transmission procedure for UE-initiated/event-driven beam reporting, in case that one PUCCH resource of first PUCCH can be associated with one or multiple CSI report configurations and multiple UEI beam reports occur, support that only a single UEI beam report with the highest priority is carried in the second PUSCH (Option 2).
The priority of a UEI beam report is determined based on a formula independent to the formula defined for legacy CSI reports.
Proposal 9: On cross-CC beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, support to introduce new RRC parameter to indicate the CC in which the indicated TCI state associated with the CSI reporting configuration is applied.
Proposal 10: On cross-CC beam report transmission procedure for UE-initiated/event-driven beam reporting, support that CSI report configurations in a given CC can be associated with same or different trigger event type(s).
Proposal 11: Regarding triggering event determination within a time window for Event 2, on condition(s) of resetting the counting of trigger event instances, support Candidate#7. 
Candidate#7: The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured.
RRC parameter(s) at least comprise RS configuration for new beam and the threshold for event evaluation.
FFS: Other RRC parameter(s).
Proposal 12: Regarding time window triggering event determination for Event 2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, support Option-4. 
Proposal 13: Regarding additional indication of whether the CRI/SSBRI satisfies the condition of Event-2, support  the 2-bit field of additional indication as follows:
The codepoint is ‘11’ if triggering event condition is met for the reported L1-RSRP value of the corresponding RS and event instances of the corresponding RS is greater than the configured counting number.
The codepoint is ‘10’ if triggering event condition is met for the reported L1-RSRP value of the corresponding RS and event instances of the corresponding RS is not greater than the configured counting number.
The codepoint is ‘01’ if triggering event condition is not met for the reported L1-RSRP value of the corresponding RS and event instances of the corresponding RS is greater than the configured counting number.
The codepoint is ‘00’ if triggering event condition is not met for the reported L1-RSRP value of the corresponding RS and event instances of the corresponding RS is not greater than the configured counting number. 
Proposal 14: Regarding additional indication of whether the CRI/SSBRI satisfies the condition of Event-2, support the following clarification if the additional indication is 1-bit field:
Bit value is 0 if event instances of the corresponding RS is not greater than the configured counting number or triggering event condition is not met for the reported L1-RSRP value of the corresponding RS.
Bit value is 1 if event instances of the corresponding RS is greater than or equal to the configured counting number and triggering event condition is met for the reported L1-RSRP value of the corresponding RS. 
Proposal 15: On UE-initiated/event-driven beam reporting, regarding UL signaling content(s) of L1-RSRP report depending on Event-7, the option-3 on Event-2 is taken as a starting point with the following additional updates:
Differential L1-RSRP value of the Q-th best activated TCI state as well as its corresponding TCI codepoint index should always be reported in addition to the N new beams.
Other activated TCI state(s) in addition to the Q-th best activated TCI state are reported for facilitating the subsequent TCI activation/deactivation.
Proposal 16: On UE-initiated/event-driven beam reporting depending on Event-1, support the following L1-RSRP report format by reusing the report format for Event-2. 
Differential L1-RSRP #2~#N is determined based on the difference between measured L1-RSRP corresponding to the CRI/SSBRI #2~#N and the measured L1-RSRP corresponding to CRI/SSBRI #1
L1-RSRP#1 is the largest measured RSRP among reported ones, and an absolute L1-RSRP.
Differential L1-RSRP value for current beam is determined based on the difference between measured L1-RSRP corresponding to the current beam and the configured certain threshold.
Proposal 17: Regarding beam application latency reduction after transmission of UE-initiated/event-driven beam report, support Alt-3.
Alt-3: After sending a UE-initiated beam report for Event-7, 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 if the activated TCI state is QCLed with the SSB associated with the reference signal reported in the beam report.
Proposal 18: On beam report transmission procedure for UE-initiated/event-driven beam reporting, support to introduce an RRC parameter in a CSI report configuration to enable either mode-A or mode-B.
Note: UE expects that the CSI report configurations for UE-initiated/event-driven beam reporting across all CCs are configured with a same mode.
Proposal 19: 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 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.4.3 in CR38.214.

3GPP TSG RAN WG1 #120bis	R1-2501799
Wuhan, China, April 7th – 11th, 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.
Support introducing an RRC parameter to indicate the CC on which the indicated TCI state is applied.
Support the following TP.
Support Option-1, i.e., the measurement window is from T_PUCCH – T_proc – T_window to T_PUCCH – T_proc, where T_PUCCH is a transmission occasion of a first PUCCH, and T_proc is RRC configured.
Only when the measured current beam RS based on the indicated TCI state is updated, the counting value of all new beam RS(s) should be reset.
Support the following TP.
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 re-configured by RRC signaling, the counting value of all new beam RS(s) should be reset.
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 UE may ignore the scheduling DCI if the number of triggered reports is one, which is the UE-initiated/event-driven beam report, and no HARQ-ACK or transport block is multiplexed on the PUSCH;
Otherwise, the UE is not required to update the CSI for the triggered UE-initiated/event-driven beam report.
Do not support reporting of the RSRP value of the current beam for Event-1.
Whether the new beam RS set includes RSs corresponding to inactive TCI states should be clarified for Event-7 first,
If not, the same report mechanism of Even-2 can be reused for Event-7; 
Otherwise, besides N reported new beams, a bitmap of active TCI states used to indicate which active TCI state(s) could be replaced by reported new beams can be introduced.
Retransmission of the first PUCCH indication in Mode A can be performed on the next PUCCH resource occasion of the first PUCCH channel if the following criteria are satisfied:
Trigger condition of the associated event is still satisfied;
UE does not detect a DCI scheduling an uplink resource for the UE-initiated/event-driven beam report before the next PUCCH resource occasion.
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.
When the first PUCCH resource overlaps with the PUSCH resource in the time domain, the 1-bit PUCCH indication is multiplexed and transmitted on the PUSCH by puncturing.
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
Support to confirm the following working assumption.
If multiple UE-initiated beam report procedures occur, the UEI beam report with the highest priority is reported, where the priority can be determined based on the corresponding CSI report configuration ID.
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.
For Mode A, the CPU for a UE-initiated/event-driven beam report is occupied from the beam measurement to the end 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 to the last symbol of the PUSCH carrying the beam report if the PDCCH is detected within the duration.
For Mode B, the CPU for a UE-initiated/event-driven beam report is occupied from the beam measurement to the last symbol of the CG-PUSCH occasion associated with UE-initiated/event-driven beam report.
For the beam measurement time, 
If the event evaluation procedure is performed within a time window, it is started from the first symbol of the time window, whose last symbol should be no later than the timing determined based on the first PUCCH channel and PUCCH preparation time;
Otherwise, it is started from 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 determined based on the first PUCCH channel.
The number of CPU occupied by a UE-initiated/event-driven beam report is 1.
Prioritize Alt-3, i.e., UE could store the QCL properties of the SSB associated with the reference signal reported in the beam report after sending a UE-initiated/event-driven beam report, to reduce TCI state activation latency.   
Following parameter should be introduced:

3GPP TSG RAN WG1 #120bis		R1-2501850
Wuhan, China, April 7th – 11th, 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:
Enhancement for beam application/activation latency reduction
Proposal 1: (Combining Alt-2 and Alt-3) To reduce beam application latency after a UEI/ED beam report is sent, support that UE could store the QCL properties of the SSB associated with the RS(s) reported in the UEI/ED beam report, subject to UE capability.
At the reception Unified TCI States Activation/Deactivation MAC CE to activates the TCI state(s) corresponding to the RS which UE has QCL properties of the SSB(s) associated with, the UE activates the TCI state(s) without additional SSB reception.
For each reported RS in the UEI/ED beam reporting, UE reports 1-bit indicator to indicate whether UE has stored the QCL properties of the SSB(s) associated with the reported RS.
Trigger-event detection of UEI/ED beam reporting
Observation 1: The global time window (e.g., Option-1 or Option-3) has worse resolution to identify the triggering beam(s) and that doesn’t align the pre-beam operation adopted in the RAN1#117 agreement. Moreover, adopting global window needs carefully handle the relationship between CSI reference resource and window duration.
Observation 2: If adopting beam-specific window for a new beam (e.g., Option-2 or Option-4), it is more efficient to define the beam-specific window according to each determined event instance for the new beam instead of each evaluation occasion for the new beam. 
Observation 3: On Option-4, the current wording doesn’t make sense, where the timer will re-start when determining an event instance such that the timer never expire. 
Proposal 2: On time window definition for counting evaluation, support either the updated Option-2 or the updated Option-4:
Updated Option-2: The measurement window for a new beam is from T_Instance – T_window to T_Instance, where T_Instance is the time when an event instance for the new beam is determined.
Update Option-4: If an Event-2 instance for a new beam is obtained and the timer for the new beam is not running or expiry, UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window.
Proposal 3:  Regarding triggering event determination for Event 2, besides of Candidate#1, further support Candidate#7 as follows:
Candidate#7: The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured.
The RRC parameters consists of the RS resource set of new beams, the event threshold, the length of the time window if provided and the maximum counting number M if provided.
Proposal 4:  Support the triggering evaluation is captured in RAN2 specification (i.e., MAC specification)
Signaling content of UEI/ED beam report
Observation 4:  Since Event-1 condition is purely based on the quality of current beam, it is possible that the current beam has higher RSRP than the reported new beam(s).
Proposal 5:  On Event-1 based beam reporting, support to leverage Event-2 report content but report the absolute RSRP instead of differential RSRP for current beam reporting if enabled.
Note: Whether to always report the quality of the current beam is configurable by RRC, analogues to Event-2 based beam reporting. 
Observation 5:  Even-2 report content can support to report the other activated beam(s) beside of the activated beam with Q-th best quality, by reporting the new beam RS(s) corresponding to the activated beam(s).
Proposal 6:  On Even-7 based UEI/ED beam reporting, support to leverage Event-2 report content and additionally indicate the codepoint of the activated beam with Q-th best quality if reported.
Transmission procedure for UE-initiated/event-driven beam reporting
Proposal 7: 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 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 first PUCCH, for the case if the first PUCCH for a UEI/ED beam report configuration overlap with the first PUCCH(s) for the other UEI/ED beam report configuration(s), support that UE transmits the first PUCCH with higher priority (i.e., PUCCH resource with lower PUCCH resource ID).
Proposal 10: 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 11: 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 12:  To support cross-carrier reporting for Mode A and Mode B, a CSI report configuration configured in serving cell c is provided with a RRC parameter which indicates the CC that the indicated TCI state for current beam measurement is from.
If the RRC parameter is not present, the CC where the CSI report configuration is configured in is assumed. 
The current beam RS derived from the indicated TCI state and new beam RS(s) associated with the same CSI report configuration shall be from the same CC.
Note: the RRC parameter is an additional parameter besides of the legacy RRC parameter carrier.

3GPP TSG RAN WG1#120bis	                                       	 R1-2501862
Wuhan, China, April 7th – 11th, 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:
It is not necessary to introduce MAC CE to update new beam RS.
Proposal 2:
Revise Candidate #2 to: The measured current beam based on indicated TCI state is updated.
Proposal 3:
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 4:
For the report format of Event-1, the L1-RSRP of current beam always is included, where the absolute L1-RSRP value is quantized.
Proposal 5:
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 6:
Support configuring one CSI report configuration associated with multiple events.
If an event occurs, the UE initiated beam report and event ID corresponding to the occurred event are carried in the second PUSCH.
If multiple events occur, the UE initiated beam report and event ID corresponding to the event with highest priority are carried in the second PUSCH.
Proposal 7:
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 8:
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 9:
It can be avoided by gNB implementation that multiple first PUCCHs corresponding to different CSI configurations for UE-initiated/event-driven beam reporting are overlapping in the time domain.
Proposal 10:
The UE initiated beam report in second PUSCH should have a higher priority than the legacy CSI report.
Proposal 11:
When the 1-bit first PUCCH is collided/overlapped with a PUCCH format 0/1 carrying HARQ or with a PUCCH format 2/3/4 carrying HARQ/CSI, the 1-bit first PUCCH has a higher priority than the legacy CSI, and the HARQ-ACK has a higher priority than the 1-bit first PUCCH.
Proposal 12:
On Mode-A in UE initiated beam report, DCI format 0_3 in Step-2 can be supported.
Proposal 13:
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 #120bis                                                                            R1-2501985
Wuhan, China, April, 7th – 11th, 2025

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

Conclusions
In this contribution, we provide our views on the enhancements for UE-initiated beam management, including triggering events, RS resources used for beam measurement, UL report contents, UL report container and cross-CC configuration. We have the following proposals:
Proposal 1: Regarding the evaluation periodicity for determining Event-2 instance, support Alt-2_4: The evaluation periodicity is the maximum of {X ms, shortest periodicity of the current beam RS and new beam RS(s)}.
Proposal 2: Regarding triggering event determination for Event 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 resetting the counting for Event-1, at least support candidate#2.
Proposal 4: Regarding resetting the counting for Event-1, support candidate#1 if the RS for the current beam is change due to the update of the RS for new beam.
Proposal 5: 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 6: Regarding triggering event determination for Event-2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, one of the following options is supported:
Option-1: The measurement window is from T_PUCCH – T_proc – T_window to T_PUCCH – T_proc, where T_PUCCH is a transmission occasion of a first PUCCH, and T_proc is RRC configured.
Option-4: If an Event-2 instance for a new beam is obtained at the time , UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window).
Proposal 7: Regarding triggering event determination for Event-2, support to capture the timing window for counting Event-2 instance in RAN1 spec.
Proposal 8: For Event-7 in UE-initiated/event-driven beam management with the optional measurement when the counting is performed M times, down-select from the following options for the beam report content:
Option1: A common counter is maintained for all RS associated with the activated TCI states, the counter is increased by 1 if Q-th best RS satisfies the triggering condition. The report is triggered when the common counter is increased to M.
 Option2: A counter is maintained for each RS associated with the activated TCI states. The counter is increases by 1 only if the RS of the corresponding activated TCI state satisfies the triggering condition. The report is triggered when one of the counter is increased to M.
Option-3: The triggering event determination that number of event instance(s) for at least one same new beam is greater than or equal to a configurable number M within a time window is not supported for Event-7.
Proposal 9: For the differential L1-RSRP report in UE-initiated/event-driven beam management, support that the RSRP of the current beam is always reported for Event-1.
Proposal 10: For the differential L1-RSRP report in UE-initiated/event-driven beam management, support that the absolute RSRP value of the current beam is reported for Event-1.
Proposal 11: 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-4: Reuse the SR dropping rules, i.e., the first PUCCH is dropped.
Proposal 12: On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the Case-3: The 1-bit first PUCCHs corresponding to different CSI configuration for UE-initiated/event-driven beam reporting are overlapping in the time domain, support that it can be avoided by NW/UE implementation.
Proposal 13: When multiple UE initiated beam report procedures occur, support Option-1: It is up to UE implementation to select one of configuration.
Proposal 14: On prohibit timer for Mode-A and/or Mode B for UE-initiated/event-driven beam reporting for CSI report configuration, support candidate#1, option-1:
Candidate#1: To introduce a prohibit timer for mode-A and mode-B
Option-1: 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 15: Regarding cross-CC framework for UEIBM, it is not necessary to introduce an RRC parameter to indicate the CC on which the indicated TCI state is applied.
Proposal 16: Adopt the following TP in section 5.2.1.5.4.1 of the draft CR for TS 38.214:

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

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

Conclusion
In this contribution, we make the following proposals:
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.
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
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.
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. 
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. 
On UE-initiated/event-driven beam reporting for Event 1, the differential L1-RSRP value of the current beam relative to the threshold is always reported.
For a CSI report configuration for Event 1, the UE expects the RRC parameter (e.g., enabledCurrentBeam) of the CSI report configuration to be enabled.
Regarding triggering event determination for Event 2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, support option 4.
Option 4: if an Event-2 instance for a new beam is obtained at the time , UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window). 
On UE-initiated/event-driven beam reporting, for L1-RSRP report format of Event-7, support to include an additional field to indicate the codepoint of the activated beam with Q-th best quality. 
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. 
Confirm the following working assumption.
Working Assumption: For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with the same CSI-AperiodicTriggerState.
If multiple UE initiated beam report procedures occur, support Option 3:
Option-3: The report triggered in the latest measurement is reported in PUSCH
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. 
Regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH with Case 3 (The 1-bit first PUCCHs corresponding to different CSI configurations for UE-initiated/event-driven beam reporting are overlapping in the time domain), specify collision handling such that the UE prioritizes the CSI configurations based on a priority order of event types (e.g., Event 2 > Event 1 > Event 7).
For prioritization of CSI configurations associated with the same event, this can be up to UE implementation or based on PUCCH resource IDs. 
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.
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.
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.
On cross-CC beam report measurement for UE-initiated/event-driven beam reporting, regarding Event-2, introduce a new RRC parameter to indicate the CC on which the indicated TCI state is applied. Down-select one of the options:
Alt1: The UE expects the RRC parameter cell, in each RRC configured TCI state of the CC indicated by the new RRC parameter, to indicate the CC where the new beams are configured. 
Alt2: If the new beams and the current beam associated with the indicated TCI state of the CC indicated by the new RRC parameter are not in the same CC, the UE stops trigger-event detection. 
Remove servCellIndex-r19 and ul-BWP-Id-r19 from resourceForSecondChannelOfModeB-r19.
Alt-2 may require less capability of UE to store QCL properties than Alt-1/3.
Alt-1 may have a risk of an unsynchronized set of activated TCI states between the UE and the gNB.
It may be worth clarifying a time window that UE expects to receive a MAC CE after a UEIBR report has been transmitted.
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 Meeting #120bis	Tdoc R1-2502053
Wuhan, China, April 7th – 11th, 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	The agreement does not include any limitation of the window over which the UE counts event-2 instances.
Observation 2	When a UE is scheduled using DCI format 0_3, the UCI is transmitted on one of the scheduled cells.
Observation 3	The UE retransmits the BEI even if the event condition is no longer fulfilled.
Observation 4	In legacy, the UE may drop the SR also when no UL data can be transmitted.
Observation 5	The performance of a BEI multiplexed into a PUSCH is unclear.
Based on the discussion in the previous sections we propose the following:
Proposal 1	Support option-4’ to handle the counter and window.
Proposal 2	The event evaluation for UE-initiated beam reporting is captured in a RAN2 specification.
Proposal 3	The event instance counting is reset for all new beams when the parameters associated with event-driven reporting are reconfigured.
Proposal 4	The event instance counter is reset when the timer expires.
Proposal 5	For event-7, it should be possible to configure the UE to report up to 8 RSs.
Proposal 6	The UL-grant DCI format comprises DCI format 0_1/0_2/0_3.
Proposal 7	The UE retransmits the BEI until it receives a DCI format that indicates a resource for a second UL channel.
Proposal 8	The retransmissions for the BEI are controlled as the scheduling request: a prohibit timer that controls the interval between the retransmissions, and a maximum number of retransmissions that controls the maximum number of retransmissions.
Proposal 9	Once the UE transmitted the BEI, it resumes frequent PDCCH monitoring.
Proposal 10	When only BEI PUCCH resource overlaps with a PUSCH (i.e. no overlapping CSI and/or A/N PUCCH resources), if a BEI collides with a PUSCH, the BEI is dropped.
Proposal 11	If multiple BEIs collide, it is up to UE implementation which one to transmit.
Proposal 12	Use additional phase offsets to multiplex ACK/NAKs, LRR and positive BEI in PUCCH format 0.
Proposal 13	For the case where BEI overlaps with HARQ-ACK or CSI on PUCCH format 3 or 4, append  to the PUCCH carrying HARQ ACK/NAK or CSI.
Proposal 14	For the case where BEI overlaps with SR/LRR and HARQ-ACK or CSI on PUCCH format 2, 3 or 4, append  to the PUCCH carrying HARQ ACK/NAK.
Proposal 15	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 16	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.
Proposal 17	It is up to the UE to determine which indicated TCI state is used to determine the current beam RS that is on the same CC as the new beams.
Proposal 18	To reduce the TCI state activation time, support Alt-2 or Alt-3.

3GPP TSG RAN WG1 #120bis		 R1-2502065
Wuhan, China, April 7th – 11st, 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, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, consider the following option:
Option-5: If an Event-2 instance for a new beam is obtained at the time t, UE (re)starts the timer for the new beam at the next transmission occasion of a first PUCCH after t, where,
the expiry time of the timer is the NW-configured T_window
T_PUCCH is a transmission occasion of a first PUCCH, and T_proc is RRC configured.
Proposal 2: Regarding the measurement window T_window for initiating the UE-initiated/event-driven beam reporting procedure, 
A measurement window T_window contains at least one transmission occasions of the first PUCCH.
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: If there is more than one PUCCH occasion in a time window, only one PUCCH at most can be transmitted. 
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: The overlapping rules should be studied in case of collision between a transmission of the UEIBR over carrier c1 and transmission of a physical signal/channel over a carrier of a serving cell in set S(c2)
Proposal 7: On the UEIBR triggered by Event-2, regarding Alt-1 in which a single UEI beam report is carried in the second PUSCH, if multiple UE initiated beam report procedures occur, 
The UEI beam report with highest priority is reported. 
For the UEI beam reports with the same priority, the latest triggered one is reported.
Proposal 8: On the UEIBR triggered by Event-2, regarding Alt-2 in which multiple UEI beam report is carried in the second PUSCH, 
The report format in Alt-1 can be reused. 
The payload size of the multiple UEI beam report is determined according to the maximum of {X, the total of multiple payload size associated CSI report configurations}.
If the total of multiple payload size associated CSI report configurations exceeds the threshold, 
the UEI beam report with lower priority is dropped. 
for the UEI beam report with the same priority, the earlier triggered one is reported.
Proposal 9: Additional signaling can be introduced to enable/disable the UE-initiated beam reporting. 

4		

3GPP TSG RAN WG1 #120bis										R1-R1-2502079
Wuhan, China, April 7th – 11th, 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:	Support the endorsed draft CR of TS38.214 (R1-251669) capturing the configurable time window and the configurable number M for event triggering in RAN1.
Proposal 2:	For time window, support Option-3 (The length, slot offset and periodicity of a measurement window are configured per CSI report configuration by NW) as first preference. And 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 3:	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 4:	Regarding the triggering event determination for Event 2, for the evaluation periodicity for determining Event-2 instance when DRX is not configured, support Alt-2_3: The evaluation periodicity is the same as shortest periodicity of the current beam RS and new beam RS(s).
Proposal 5:	Regarding the triggering event determination for Event 2, for the evaluation periodicity for determining Event-2 instance when DRX is configured, DRX_cycle_length should be considered for event determination.
Proposal 6:	To avoid frequent report, support Candidate#3 (UEI beam report is transmitted) for resetting the counting, at least for triggering event determination for Event 2.
Proposal 7:	The threshold for event can be configured by network device or reported by UE, and at least for different measurement resources (e.g. CSI-RS or SSB), the threshold for event can be different.
Proposal 8:	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 9:	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 10:	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 11:	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 12:	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 13:	For event-1, support reusing report format of event-2, with differential RSRP for current beam of event-1 with a reference to the configured threshold for event-1, as in following table.

Proposal 14:	Regarding RS measurement for new beam, support the RS set can be updated by MAC CE.
Proposal 15:	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 16:	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 17:	Do not support UEI beam report with a periodicity less than or equal to one slot.
Proposal 18:	In case of multiple UE initiated beam report procedures occur, support option-2 (The UEI beam report with highest priority is reported).
Proposal 19:	Support a configurable Alt-2 (multiple UEI beam reports can be transmitted in second PUSCH) only if the payload is limited and not variable, such as with a configuration on the number (e.g. S reports, S

3GPP TSG RAN WG1 #120bis   	                	      	R1-2502103
Wuhan, China, April 7th – 11th, 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
Case-3: First PUCCH for Event 1 has higher priority than first PUCCH for other events
Proposal#3: For the case that 1st PUCCH resource is associated with multiple CSI report configuration, if at least one of the UEI beam reports satisfy the triggering condition, UE reports all of them in 2nd PUSCH.
Proposal#4: CSI reporting priority of second PUSCH should be set higher than normal CSI/beam report considering its event-driven nature.
Proposal#5: To reduce beam application latency after second PUSCH transmission, Alt-1 can be considered.

3GPP TSG RAN WG1#120bis                                                             R1-2502107
Wuhan, China, Apr 07th – 11th, 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 the following conditions to reset the counting for event-2:
Candidate#1: RS reconfiguration/update or MAC-CE signaling (if supported) for new beam is received;
Candidate#2: The measurement current beam based on indicated TCI state is updated.
Proposal 2: Do not support different periodicity for current beam RS and new beam RS(s).
Proposal 3: Support Option-3b for the RS determination/configuration on RS measurement for the new beam for Event-2.
Option-3b: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Proposal 4: 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 5: Support Option-2 if multiple UEI beam report procedures occur, i.e., the UEI beam report with highest priority is reported, and the legacy CSI report priority rule based on  is used by setting y=0 for the CSI report corresponding to the CSI report configuration for UEI beam report.
Proposal 6: For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource can be associated with different CSI-AperiodicTriggerState.
Proposal 7: Support NW’s acknowledgement with response to the PUSCH carrying the beam report.
Proposal 8: Support Option-4 on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure as follow:
If an Event-2 instance for a new beam is obtained at the time , UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window).
Proposal 9:  The time window and the counter for the event evaluation for event-2 should be captured in RAN1 spec.
Proposal 10: 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 11:  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 12:  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 13: Determine the slot of the indicated TCI state when receiving the first UL resource and second UL resource for Event 2. 
Proposal 14: 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 15: Further study the determination of RS occasions for the event triggered beam report. 

3GPP TSG RAN WG1 Meeting #120bis	R1-2502119
Wuhan, China, April 7th – 11st, 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 event-driven beam report. The proposals are summarized as below. 
Proposal 1: For the RS configuration for the new beams in Event 2, it is not preferred to support updating the RSs for the new beams by MAC-CE.
Proposal 2: 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-2 is preferred.
Option-2: 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: 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 4: As for Case-3 where multiple first PUCCHs corresponding to multiple CSI report configurations overlap, the following UCI dropping rule is supported.
The first PUCCH with the highest priority is transmitted and the other first PUCCHs are not transmitted.
Proposal 5: 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.
If one of the K1 first PUCCHs is indicated as positive by the K bits, it should have the highest priority among the triggered first PUCCHs.
Proposal 6: For the UCI type priority used in the case where a PUCCH overlaps with a PUCCH with repetitions, it should be also defined for the first PUCCH.
Especially, the priority order between the first PUCCH and the SR should be specified, to handle at least the case where a PUCCH with repetitions overlaps with a first PUCCH and an SR.
To this end, the UCI type priority order can be defined as HARQ-ACK > SR = first PUCCH > CSI with higher priority > CSI with lower priority.
Proposal 7: To determine the time window for Event 2, the following principle given by the sub-bullet of Option-2 should be supported no matter which option is finally supported.
The UEI beam report in the second PUSCH is based on the most recent measurement for new/current beam RS(s).
Proposal 8: The principle of Option-2 is preferred, and it is suggested that Option-2 is revised as follows.
Revised Option-2: The measurement window is from T_Instance to T_Instance + T_window, where T_Instance is an evaluation occasion of event instance.
Proposal 9: It should be specified how to determine the one-to-one mapping between PUCCH and PUSCH in Mode-B, especially when some of PUCCHs or PUSCHs are invalid.
Proposal 10: In Mode-B, the first PUCCH and the second PUSCH can have different periodicities.
Proposal 11: For Event 1, L1-RSRP of the current beam is reported as an absolute L1-RSRP value.
Proposal 12: 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 event-driven beam reporting occurs.
Proposal 13: If multiple reports associated with a first PUCCH satisfy the triggering conditions, only a single report is transmitted, and the following Option-2 is supported to transmit the report.
Option-2: The UEI beam report with the highest priority is reported.
Proposal 14: For the case where multiple reports are associated with a same first PUCCH, the following working assumption should be confirmed.
Working Assumption: For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.
Proposal 15: 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 16: For the event-driven 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.
Alt1: 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.
Alt2: The first symbol after the PDCCH scheduling the second PUSCH.
Alt3: The first symbol after the first PUCCH.
Proposal 17: Regarding active CSI-RS resource or CSI-RS port counting for the event-driven 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. 
Proposal 18: It should be supported that the event-driven beam report and the legacy CSI report are simultaneously configured for a UE.

3GPP TSG RAN WG1 #120bis			                           R1-2502153
Wuhan, China, April 7th – 11th, 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#1: RS reconfiguration/update for new beam is received
When the RS reconfiguration/update for new beam is received, the counting of the updated beam is reset while the counting whose new beam is not updated is maintained.
Candidate#2:  Indicated TCI state is updated
In such case, UE needs to reset the counting for all new beams.
Candidate#6: The threshold for event evaluation is re-configured by RRC signaling
Proposal 2: For Event-2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, support the Option-3: The length, slot offset and periodicity of a measurement window are configured per CSI report configuration by NW.
Proposal 3: For Event-1, the L1-RSRP of current beam should be reported as absolute value and whether to report the L1-RSRP of current beam can be enabled or disabled by RRC.
Proposal 4: For Event-7, additional field to indicate the codepoint of the activated TCI state with Q-th best quality is needed.
Proposal 5: 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 Candidate#1.
Proposal 6: If multiple UE initiated beam report procedures occur, support the Option-2: The UEI beam report with highest priority is reported.
Proposal 7: Regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, support Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.
Proposal 8: To reduce beam application latency after a UEI/ED beam report is sent, support Alt-3 for Event-7 and support Alt-1 for Event-2 with further clarification:
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 
apply the reported new beam as the QCL assumption for DL reception and UL transmission update TCI state(s) with the reported new beam(s)
activate new beam(s) without additional SSB reception

7. 

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

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

Summary #4 on UEIBM, RAN1#120, February 17-21, 2025.
[6] 3GPP TS 38.214 version 18.5.0. 

3GPP TSG RAN WG1 #120bis		R1-2502293
Wuhan, China, April 7th – 11th, 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: The triggering event determination for Event 1, 2 and 7 is captured in RAN1 specification.
Proposal 2: For Event-7, only support the basic feature of the triggering event determination. 
Proposal 3: The candidate #2 for Event 2 shall be that the current beam RS based on current indicated TCI state is changed.
Proposal 4: In addition to candidate #2, candidate #6 shall be supported for Event 2.
Proposal 5: Candidate #2 and #6 shall be supported for Event 1.
Proposal 6: Support Option-2 for the measurement window for triggering event determination for Event 2 and the same Option-2 is supported for Event 1.
Proposal 7: For Event 1, the reported differential L1-RSRP of current beam RS is with reference to the configured L1-RSRP threshold in Event 1.
Proposal 8: For Event 7, the UE shall report the indicators of activated TCI states with Q-th best quality and worse quality in addition to the report fields agreed for Event 2.
Proposal 9: Support one prohibit Timer in Mode-A:
The prohibit timer is started after the 1st PUCCH in Mode-A is transmitted and the UE is not allowed to re-transmit the 1st PUCCH channel before the prohibit timer expires.
The UE removes the prohibit timer when the UE receives the PUSCH scheduling DCI for UEI beam reporting in Mode-A.
Proposal 10: Do not support prohibit timer in Mode-B.
Proposal 11: When one first PUCCH resource is associated with multiple CSI report configurations for Event 2 and if multiple UEI beam reports happen, it is up to UE implementation to choose one UEI beam report (i.e., Option-1).
Proposal 12: Confirm the WA that for Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.
Proposal 13:  Do not support that report multiple UEI beam reports associated with the same first PUCCH resource in the second PUSCH (i.e., Alt-2).
Proposal 14: For the Case-2 of that the first PUCCH collides with a PUSCH, support Option-3 and the PUSCH can be any PUSCH, either UL-SCH or for UEI beam report.
Proposal 15: The case that the first PUCCHs of different UEI beam report CSI report configuration collide can be handled by system implementation.

3GPP TSG RAN WG1 #120bis	        	R1-2502312
Wuhan, China, April 7th – 11th, 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.
: Confirm working assumption (On UE-initiated/event-driven beam reporting, regarding trigger events, besides for Event-2, Event-1 and Event-7 are both supported.).
: 	If multiple UE initiated beam report procedures occur, support option-2: The UEI beam report with highest priority is reported

3GPP TSG RAN WG1 #120bis	        		             R1-2502356
Wuhan, China, April 7th – 11th, 2025 
Agenda item:	9.2.1
Source: 	Samsung
Title: 	UE-initiated (UEI) beam management enhancements
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: The end of a time window for event evaluations should not be far before the nearest available first PUCCH transmission to ensure real-time indication of UEI-BR.

Proposal 1: Regarding triggering event determination for Event-2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, support Option-1.

Proposal 2: 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 3: 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 2: Regarding triggering event determination for Event 2, other candidates than Candidate #2 do not have immediate impact on event evaluation.

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

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

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

Proposal 6: Regarding Event-2 determination, do not support different periodicities of the current beam RS and the candidate/new beam RS(s). 

Proposal 7: Support to capture Event-2 evaluation condition(s) and procedure(s) in RAN1 specification.  

Observation 4: 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 8: Do not support counting more than one event instance for evaluating or determining Event-7.

Proposal 9: 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 RS and candidate beam RS(s) for event evaluations.

Proposal 10: 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 11: 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 5: For a given current beam of a serving cell, measuring a subset of surrounding new beams can be beneficial for latency reduction.

Proposal 12: 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 13: Support to set each of the codepoints of the 1-bit condition met indicator as follows:
‘0’ – indicating that the corresponding CRI/SSBRI does not satisfy the condition of Event-2
‘1’ – indicating that the corresponding CRI/SSBRI satisfies the condition of Event-2.
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: Regarding current beam reporting in Event-1,
support differential RSRP reporting wherein the differential RSRP is determined with respect to the configured threshold for Event-1 evaluation
support the same RRC parameter as in Event-2 to configure presence of the current beam in the report.  
Proposal 16: 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 17: 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 18: 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 19: For Mode-A, further study the measurement window for UEI reporting content.

Proposal 20: 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 21: On beam report transmission procedure for UE-initiated/event-driven beam reporting, and for one PUCCH resource of first PUCCH associated with multiple CSI report configurations, regarding Event-2, support to confirm the WA:
Working Assumption: For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.
Proposal 22: On beam report transmission procedure for UE-initiated/event-driven beam reporting, and for one PUCCH resource of first PUCCH associated with multiple CSI report configurations, regarding Event-2, support Option-1:
If multiple UE initiated beam report procedures occur, it is up to UE implementation to select one of configurations.
Proposal 23: On beam report transmission procedure for UE-initiated/event-driven beam reporting, and for one PUCCH resource of first PUCCH associated with multiple CSI report configurations, regarding Event-2, do not support Alt-2.

Proposal 24: 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.
For the case where first PUCCHs corresponding to different CSI configuration for UE-initiated/event-driven beam reporting are overlapping in the time domain, it is up to UE implementation to transmit one of the first PUCCH.
Proposal 25: 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 6: The intra-UE multiplexing/prioritization rules of PUSCH with A-CSI can be reused for PUSCH with UEI-BR for Mode A.

Proposal 26: 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 27: Reuse the intra-UE multiplexing/prioritization rules of PUSCH with SP-CSI for Type-1 CG PUSCH with UEI-BR for Mode B.

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

3GPP TSG RAN WG1 Meeting #120-bis 	R1-2502414
Wuhan, China, April 7th – 11th, 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 sections we propose the following: 
Proposal 1: Regarding triggering event determination for Event 2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, support Option-4
Option-4: If an Event-2 instance for a new beam is obtained at the time , UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window)
Note: T_window is the agreed time window parameter for measurement.
Proposal 2: If multiple UE initiated beam report procedures occur, support Option-1
Option-1: It is up to UE implementation to select one of configuration.
Proposal 3: On beam report transmission procedure for UE-initiated/event-driven beam reporting, one PUCCH resource of first PUCCH can be associated with one or multiple CSI report configurations, regarding Event-2, confirm the following Working Assumption:
Proposal 4: 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

3GPP TSG RAN WG1 #120bis                                       	      R1-2502434
Wuhan, China, April 7th – 11th, 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: Counting can be reset when the threshold is reconfigured to be larger.
Proposal 2: Regarding the measurement window, support Option -1, i.e., from T_PUCCH – T_proc – T_window to T_PUCCH – T_proc.
Proposal 3: Reuse the legacy CSI reference resource to derive the UEI beam report.
Proposal 4: For Event-1, reuse the L1-RSRP report format of Event 2 but differential L1-RSRP for current beam with a reference to the threshold of Event 1 is reported if report mode that current beam is always reported is enabled by RRC.
Proposal 5: Report the RS ID of the activated TCI state with the Q-th best quality in the beam report of Event-7.
Proposal 6: Regarding the 1st UL channel of Mode A, reuse retransmission mechanism of legacy SR.
Proposal 7: In order to reduce the retransmission number of the beam report triggered by the same triggering beam(s), support following: 
For both mode-A and mode-B: In the case that triggering-event associated with the CSI report configuration is determined because of same triggering beam(s), if the prohibit timer is NOT running, the UE can transmit first PUCCH;
At the first symbol after the end of the second PUSCH transmission, the UE starts the prohibit timer
Proposal 8: If multiple UE initiated beam report procedures occur, support Option-2, i.e., the UEI beam report with highest priority is reported.
Proposal 9: Confirm the WA, i.e., For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.
Proposal 10: 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 11: UEI BR occupies CPU at least from the time window before available 1st PUCCH, until the last symbol of the available 1st PUCCH.
Proposal 12: The priority of UEI BR can be higher than normal aperiodic beam report.
Proposal 13: Support the following TPs on UEI BR to 38.214.

3GPP TSG RAN WG1 #120bis				 	   R1-2502505
Wuhan, China, April 7th – 11th, 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: Support Candidate #1(new beam RS update), #3(second report transmission), #6(threshold update) and further discuss Candidate #5 (time window expire).
Proposal 4: Support the same periodicity of the current beam RS and candidate beam RS(s).
Proposal 5: Remove the [at least when DRX is not configured] in the 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: The measurement quantity is updated before the second report while it may not satisfy the trigger condition.
Proposal 8: Discuss T_Instance with T_PUCCH, i.e., associate evaluation occasions with first report timing.
Proposal 9: Introduce the behavior if a UE failed to re-confirm the Event-2.
Proposal 10: Multiple events are reported in a second report, where only detected events are included.
Proposal 11: Support event id or serving cell id in the second report.
Proposal 12: Further study that multiple events let overlapped time resources for a first or a second report.
Proposal 13: For Event-1, allow absence of a current beam in the second report, and the current beam can be represented by differential value with respect to the strongest candidate beam.
Proposal 14: For Event-7, number of reported beams can be configured to up to 8.
Proposal 15: Discuss whether event information can be reported and the way of indication if reported i.e., explicitly or implicitly.
Proposal 16: Discuss priority rule between multiple triggered events.
Proposal 17: Support further the Option-1 or Option-1b for variable sized reporting in Event-2.
Proposal 18: Event-1/-7 also support Option 3 (N beam reporting).
Proposal 19: Relax the condition of satisfying the Event-2 condition for at least one beam, i.e., remove ‘at least one of N reported beam(s) should satisfy the condition of Event-2.’
Proposal 20: For Event-2, increase up to 8 which is the number of activated TCI states because all TCI states can be updated/modified at once.
Proposal 21: Support UEI reporting related to multiple events in the same second channel.
Proposal 22: Piggyback UEI into the PUSCH (Option-3) regardless of UL-SCH presence/absence.
Proposal 23: No further optimization of priority index of a first report.
Proposal 24: For ModeB, support different periodicity between first report and the second report.
Proposal 25: Introduce an RRC parameter that describes the serving cell index for applying the TCI state.

3GPP TSG-RAN WG1 Meeting #120bis														R1-2502524 
Wuhan, China, 7 – 11 April 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.
Proposal 2:	At least for Mode A, support the UE initiating RACH procedure if the UE reaches a configured max number of attempts for first PUCCH channel without receiving a response from the network.
Proposal 3:	For a UE configured with one first PUCCH associated with multiple CSI report configurations regarding Event-2, with only a single UEI beam report carried in the PUSCH, if multiple UE initiated beam report procedures occur, the UE reports on PUSCH the latest triggered report (Option-3).
Proposal 4:	For a UE configured with one first PUCCH associated with multiple CSI report configurations regarding Event-2, with only a single UEI beam report carried in the PUSCH, confirm the WA in Mode A, where the multiple CSI report configurations are associated with a same CSI-AperiodicTriggerState.
Proposal 5:	For a UE configured with one first PUCCH associated with multiple CSI report configurations regarding Event-2, if multiple UE initiated beam report procedures occur, support that the UE can transmit more than one triggered UEI beam reports in the PUSCH.
Proposal 6:	Support that multiple events can be configured simultaneously.
Proposal 7:	Regarding Case 2 where the 1-bit first PUCCH overlap with a PUSCH, we support Option-4, where SR dropping rule is reused by dropping the first PUCCH.
Proposal 8:	Regarding Case 3 where the 1-bit first PUCCHs corresponding to different CSI report configurations for UE-initiated/event-driven beam reporting overlap in the time domain, allow overlap where only dropping is supported (i.e., no multiplexing). For the purpose of determining which PUCCH to drop/prioritize, downselect one of the following options:
a) based on rules,
b) based on gNB configuration,
c) left up to UE implementation.
Proposal 9:	Regarding Case 4, the 1-bit first PUCCH is collided/overlapped with a PUCCH format 0/1 carrying HARQ, and Case 5, 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 10:	For Mode B, we 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 11:	Regarding the triggering event determination within a time window for Event-2, for resetting the counting support in addition to Candidate#2 (update of the indicated TCI state) also Candidate#7 in the following form:
-	RRC parameters associated with the CSI report configuration for UEI beam report are reconfigured. In such case, the UE needs to reset the counting for all new beams.
Proposal 12:	Regarding triggering event determination for Event 2, on the measurement window support having a sliding window as in Option-4:
-	If an Event-2 instance for a new beam is obtained at the time t, UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window).
Observation 1:	All the solutions developed so far for Event-2 regarding time window for trigger-event detection, candidates for resetting the counting within a time window, and cross-CC measurement and reporting can be applied to Event-1 without the need of any further enhancement.
Proposal 13:	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 (Option-1).
Observation 2:	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 14:	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 15:	Regarding the triggering event determination within a time window, send LS to RAN2 informing that the counter-based mechanisms are captured in RAN1 specifications and indicate the RAN1 CR document for their reference.
Proposal 16:	On report format for all events, support reporting absolute RSRP value of the current beam.
Proposal 17:	On 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 18:	On report format for Event-1, support that current beam is always reported.
Proposal 19:	On report format for Event-7, specify that the current beam is the RS associated to the activated TCI state with the Q-th best quality.
Proposal 20:	On report format for Event-7, support that the UE indicates the current beam index, for example in the form of the codepoint of the activated TCI state with Q-th best quality.
Proposal 21:	On report format for Event-7, do not support that the UE further reports other activated beam(s), e.g., from {Q+1}-th best quality to the worst one.
Proposal 22:	On report format for Event-7, specify N≥Q: as the maximum value of Q is 8, then it should be allowed to report up to N=8 beams.
Proposal 23:	On cross-CC beam report transmission procedure, regarding Event-2, we support to introduce an RRC parameter to indicate the CC on which the indicated TCI state is applied, but we also acknowledge that RAN2 may prefer their signaling design.
Proposal 24:	On beam application latency reduction, further study Alt-1 on automatic update of the active TCI state list with reported new beams, considering for example if new beams are just added to the active TCI state list or if we should allow replacing some actual beams in the active TCI state list. For Alt-2 and Alt-3, send an LS to RAN4.
Proposal 25:	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#120bis                               R1-2502538
Wuhan, China, April 7th – 11th, 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 the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, support Option-2: 
Option-2: The measurement window is from T_Instance – T_window to T_Instance, where T_Instance is an evaluation occasion of event instance, and T_proc is RRC configured.
The UEI beam report in the second PUSCH is based on the most recent measurement for new/current beam RS(s).
Proposal 2: To report L1-RSRP of current beam for Event-1, the following two options can be considered:
Option-1: A differential L1-RSRP of current beam is reported, where the differential L1-RSRP is determined based on difference between measured L1-RSRP of current beam and a configured certain threshold.
Option-2: Absolute L1-RSRP of current beam is reported.
Proposal 3: Regarding UL signaling content(s) of L1-RSRP report of Event-7, support to introduce additional field to indicate the activated TCI state with Q-th best quality.
Proposal 4: 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 5: 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 6: Regarding the first PUCCH transmission of Mode-A and/or Mode-B, the following UCI multiplexing cases can be considered:
The 1-bit indication can be multiplexed in PUCCH using PUCCH format 0 and/or PUCCH format 1 if the first PUCCH overlaps with a PUCCH carrying HARQ-ACK information.
Proposal 7: Since the 1-bit indication of first PUCCH is associated with PUCCH-ResourceID instead of SchedulingRequestId, the negative or positive 1-bit indication bits can be encoded based on the values of PUCCH-ResourceID.
Proposal 8: To further reduce preparation time for UEI beam report, preparation time of PUSCH with UL-SCH can be reused as a starting point.
Proposal 9: 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 10: When multiple UE initiated beam report procedures occur, support Option-2: 
Option-2: The UEI beam report with highest priority is reported.
Proposal 11: 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 #120bis                                             R1-2502545
Wuhan, China, April 7th – 11th, 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 report format of Event-1 should include CRI or SSBRI for new beams, L1-RSRP for new beams and current beam. 
All L1-RSRP for new beams and current beam of Event-1 are the differential L1-RSRP(s) and the reference value is the threshold of Event-1.
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 

3GPP TSG RAN WG1 #120bis		R1-2502598
Wuhan, China, April 7th – 11th, 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: The measurement window is from T_PUCCH – T_proc – T_window to T_PUCCH – T_proc, where T_PUCCH is a transmission occasion of a first PUCCH, and T_proc is RRC configured.
Proposal 5: 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 6: On Event-1 report, RRC signal is used to indicate whether RSRP of the current beam is reported. 
Proposal 7: For Event-1, the L1-RSRP of current beam is encoded using absolute value in the CSI report.  
Proposal 8: 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 9: The new UCI type is piggyback on PUSCH when it is overlapped with PUSCH. 
Proposal 10: A UE does not expect the overlapping between two first PUCCH channels for UEIBR configurations.  
Proposal 11: Add a priority indicator into a CSI report configuration if more than one CSI report configurations are associated with a single first PUCCH resource. 

3GPP TSG RAN WG1 #120bis	R1-2502665
Wuhan, China, April 7th – 11th, 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 triggering event determination for Event-2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, we support the following options:
(1st preference) Option-3: Slot offset and periodicity
(2nd preference) Option-1: Measurement window per first-PUCCH transmission occasion
(3rd preference) Option-4: Legacy BFD
Proposal 2: The counting should be reset if the following condition is satisfied:
Candidate#1: RS reconfiguration/update for new beam is received;
Candidate#2: The measurement current beam based on the indicated TCI state is updated; or
Candidate#6: Threshold for event evaluation is reconfigured by RRC signaling.
Proposal 3: If one first-PUCCH resource is associated with multiple CSI report configurations, and multiple UEI beam report procedures occur, it should be up to UE implementation to select one of configurations (i.e., Option-1).
Proposal 4: We support to confirm the following WA:
Working Assumption: For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.
Proposal 5: We do NOT support to transmit a second-PUSCH with multiple UEI beam reports associated with the same PUCCH resource.
Proposal 6: 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 7: 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 8: For only Mode-A, we support that the prohibit timer starts after the first PUCCH transmission (i.e., Option-2).
Proposal 9: In Event-1, differential L1-RSRP of current beam should be reported compared with the configured Event-1 threshold.
Proposal 10: In Event-1, the higher layer parameter to indicate always reporting L1-RSRP of the current beam should be reused.
Proposal 11: In Event-7, we support both following options:
Option 1: Additional field to indicate the codepoint of the activated TCI state with Q-th best quality.
Option 2: Extending the maximum number of reported RS(s) to 8.

3GPP TSG-RAN WG1 Meeting #120bis                                   R1-2502687
Wuhan, China, April 7th – 11th, 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:
Proposal 1: On condition(s) of resetting the counting, Candidate#1 for triggering event determination within a time window for Event 2 is also supported. i.e., Resetting all new counters when part of new beam(s) or indicated TCI state is changed under the setting of a fixed time window.
Proposal 2: Support Option-4 for initiating the UE-initiated/event-driven beam reporting procedure.
Proposal 3: Support Option-1 for determining event instance(s) counting for Event-7.
Proposal 4: For Event-1, the L1-RSRP of current beam is reported as a differential value relative to the certain threshold,
Proposal 5: Support Option-2 of Candidate#1 to introduce a prohibit timer for both mode-A and mode-B.
Proposal 6: Support Option-2 of reporting the UEI beam report with highest priority is supported.
Proposal 7: CSI report priority among event types should be defined as Event-2 > Event-7 > Event-1.
Proposal 8: Confirm the WA for the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.
Proposal 9: Support Option-4 to follow SR’s rule as the baseline when UEII is collided/overlapped with a PUSCH.
Proposal 10: Addressing SR related collisions first when they collide/overlap with a PUSCH.
Proposal 11: Support Option-3 to transmit the first PUCCH with higher priority.
Proposal 12: Support Alt-3 to store QCL properties of the reported RSs to reduce beam application latency.

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

Agenda item:	9.2.1
Source: 	Moderator (ZTE)
Title: 	Offline summary for Rel-19 MIMO UEIBM (9.2.1) pre-RAN1#120b
Document for:	Discussion and Decision



Priority for RAN1#120-bis

Trigger-event detection 


Table 1A Trigger-event detection


Table 1B Trigger-event detection: inputs from companies

UL signaling content(s)


Table 2A UL signaling content(s)


Table 2B UL signaling content(s): inputs from companies


UL signaling medium/container


Table 3A UL signaling medium/container: issues


Table 3B UL signaling medium/container: views from companies

Cross-CC measurement/report


Table 4A Cross-CC measurement/report


Table 4B Cross-CC measurement/report: inputs from companies

TDoc file conclusion not found

3GPP TSG RAN WG1#120-bis			    R1-2502745
Wuhan, China, April 7th – 11th, 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#120-bis			    R1-2502746
Wuhan, China, April 7th – 11th, 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#120-bis			    R1-2502747
Wuhan, China, April 7th – 11th, 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 #120bis			R1-2502759
China, Wuhan, Apr. 7th – 11th, 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
For the definition of time window, support Option-4.
Option-4: If an Event-2 instance for a new beam is obtained at the time 𝑡, UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window)

Proposal 6
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 7
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”.

Proposal 8
Regarding report format for event-1, absolute RSRP with 7-bit quantization of current beam is always reported.

Proposal 9
For report format of Event-7, support to extend the maximum number of reported RS(s) to 8.

Proposal 10
For report format of Event-7, to identify the TCI states to be activated/deactivated by NW, support the following:
When N RSs are reported in a single report instance,
(N-X) new beam RSs and X current beam 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 11
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
Proposal 12
Regarding prohibit timer for Mode A and Mode B, support function of Option-1 with the alternative of defining corresponding UE behaviour without introducing timer.
Option-1: For both mode-A and mode-B: 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

Observation 1
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 13
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 14
Regarding multiplexing rule for first PUCCH of Mode A and Mode B in the case of collision with CSI and/or HARQ, legacy multiplexing rule for SR should be supported for first PUCCH.

Proposal 15
Regarding collision of multiple first PUCCHs associated with different CSI report configuration for UEIBR, support dropping based on the priority rule determined by PUCCH resource ID.

Proposal 16
Regarding the case that multiple URIBR procedure occur for one first PUCCH resource, support Option-2.
Option-2: The UEI beam report with highest priority is reported.
The priority rule is based on the CSI report configuration ID for UEIBR.

Proposal 17
Deprioritize that multiple UEIBR associated with the same PUCCH resource for first PUCCH can be transmitted in the second PUSCH.

Proposal 18
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 19
Confirm the following working assumption:
Working Assumption: For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.

Cross-CC beam reporting
Proposal 20
Support to introduce an RRC parameter to indicate ServCellIndex on which the indicated TCI state is applied.
The RRC parameter is configured in the CSI-Report configuration for UEIBR.

Beam application latency reduction
Proposal 21
To reduce beam application latency after a UEIBR is sent, support 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 #120bis		   		 	         	    	         R1-2502793  
Wuhan, China, April 7th – 11th, 2025
Agenda Item:  9.2.1
Source:	ITRI
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: When the 1-bit first PUCCH is collided/overlapped with a PUSCH, Piggyback 1-bit indication of first PUCCH into the PUSCH
Proposal 2: Regarding Event-2 with multiple CSI report configurations, it is up to UE implementation to select one of configuration, if multiple UE initiated beam report procedures occur
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.
Proposal 6: For the transmission procedure mode B, if triggering condition is met, UE persistently transmits UCI until either a new unified beam is applied by the UE or an acknowledgment is received from the gNB.

3GPP TSG-RAN WG1 Meeting #120b	R1-2502812
Wuhan China, April 7 – April 11, 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:
Proposals regarding the issue of latency reduction has been studied since RAN1#119. 
Support Alt-3 where 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 
Study the feasibility, as a UE capability, of UE-initiated Beam switching after the UE identifies a favorable beam and it is reported successfully to the gNB.
Regarding the triggering for Event 2, support Option 4:
A time window’s starting point with respect to beam of index j is when the UE detects that the L1-RSRP of the new beam of index j becomes a threshold value better than the current beam for the first time (i.e. Event 2 instance w.r.t. beam of index j). 
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. 
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. 
Confirm the WA:
For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.
Regarding event 2, for the case when only a single UEI beam report is carried in the second PUSCH, if multiple UE initiated beam report procedures occur, support: 
Upon receiving a CSI request in the UL scheduling DCI, for at least mode A, the UE can append one or multiple UE-initiated beam reports that have been triggered by one or multiple events.
Based on the assigned resources in the DCI carrying the CSI request, the UE multiplexes the reports to be carried on the assigned resources subject to certain priority ordering and subject to dropping some of the triggered reports if the assigned resources are not enough. The resources assigned are up to NW implementation.
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.
For event 1, whether to transmit the current beam RSRP in the report is RRC configured.
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.
If Event 1 is supported, then both signalling modes A and B are supported for Event 1

3GPP TSG-RAN WG1 #120bis	R1-2502833
Wuhan, China, April 7th – 11th, 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, window-based triggering event determination (i.e., M>1) is optionally supported:
If within a time window, the number of Event-7 instances for at least one same new beam is greater than or equal to a configured number M, UE initiated beam report occurs.
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: The event evaluation for UE-initiated/event-driven beam reporting, including Event-2, Event-1, and Event-7, should be handled by the MAC layer.
The details of the triggering event determination procedures should be captured in the MAC specification.
Proposal 3: Regarding the window operation for UE-initiated/event-triggered beam reporting, Option-4 should be supported:
Option-4: If an Event-2 instance for a new beam is obtained at time , the UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window).
Proposal 4: For UE-initiated/event-driven beam reporting where the CC on which the indicated TCI state is applied and the CC in which the new beam RS(s) are different, no new RRC parameter is necessary to link the two CCs: The indicated TCI state in the CC where the TCI state is configured can be used for the current beam RS determination.
Proposal 5: 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 6: For UE-initiated/event-driven beam reporting according to Event-2, to address the case that the reported quality of the current beam has the highest value, it is recommended to revise the previous agreement(s) in RAN1 #117 and RAN1 #118.
Proposal 7: 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.
Observation 2: The issue of the reported quality of the current beam being the highest is common for both Event-2 and Event-1.
Proposal 8: For UE-initiated/event-driven beam reporting, the same reporting contents and format should be used across all events, namely Event-1, Event-2, and Event-7.
Note: Proposal 6.
Observation 3: For Event-7, based on the same N-beam reporting as Event-2 without any additional identifier for the Q-th best activated TCI state, the UE can allow the network to identify which activated TCI state needs updating.
Proposal 9: For UE-initiated/event-driven beam reporting according to Event-7, support reporting up to N=8 beams in a single report.
Proposal 10: The procedures for the first PUCCH (re-)transmission, including initiation of transmission and retransmission with a prohibit timer, should be managed by the MAC layer.
The details of the procedures are captured in the MAC specification.
Proposal 11: 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.
The 1-bit indication is multiplexed with other UCI in the PUCCH.
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.
Proposal 12: When multiple UE-initiated/event-driven beam report configurations are supported in a CC, they can be associated with the same first and second UL channel resources: 
The first PUCCH is transmitted when at least one of the associated events is triggered.
In the second UL channel, all the associated beam reports are multiplexed (Alt-2).
Proposal 13: In Rel-19, the discussion on beam application latency reduction should be deprioritized.

3GPP TSG RAN WG1 #120bis	R1-2502877
Wuhan, China, April 7th – 11th, 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:
Observation 1: According to previous RAN1 agreements, for mode-B, only one periodic PUCCH resource and only one periodic type-1 UL CG resource can be associated with one CSI report configuration for UEI beam reporting.
Observation 2: In case of same CC for mode-B, one pair of periodic PUCCH resource and one periodic type-1 UL CG resource are configured only in one UL BWP.
Observation 3: In case of same CC for mode-B, when the UE receives a signal from gNB, during the time gap between step-1 and step-2, indicating active UL BWP change after the UE transmits step-1, UE needs to retransmit UEI beam report since the new active UL BWP cannot provide corresponding step-2 resource to UE.
Proposal 1: In case of same CC for mode-B, RAN1 down-selects one alternative:
Alt1: Clarify that the one periodic PUCCH resource in a first timing is across BWPs and the one periodic type-1 UL CG resource in a second timing is across BWPs
Note: Any BWP’s step-1 resource in a first timing is associated with any BWP’s step-2 resource in a second timing
Alt2: gNB avoids to signal the UL BWP change indication during the time gap if receiving step-1.
Proposal 2: Support Option-4 for measurement window for UEI beam reporting procedure.
Proposal 3: If multiple UE initiated beam report procedures occur, support Option-2.
Proposal 4: If RAN1 supports Alt2 (i.e., to transmit multiple UEI beam reports on second PUSCH), we think gNB should avoid configure Alt2 and original Alternative simultaneously.
Proposal 5: RAN1 supports new UCI type has higher priority than PUSCH except PUSCH with priority index 1, if configured.

3GPP TSG RAN WG1 #120bis			R1-2502888
Wuhan, China, April 7th – 11th, 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: On beam report transmission procedure for UE-initiated/event-driven beam reporting, if the 1-bit first PUCCH is collided/overlapped with a PUSCH, 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 3: RAN1 to discuss whether it is allowed to configure different CC with different UEI-BR mode. 
Proposal 4: 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 5: 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 6: 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 7: On UE-initiated/event-driven beam reporting for Event 1, support L1-RSRP of current beam is reported with absolute L1-RSRP value. 
Proposal 8: On UE-initiated/event-driven beam reporting for Event 1, whether RSRP value of the current beam is reported is dependent on a RRC parameter. 
Proposal 9: Support L1-SINR as the unit of the threshold for triggering UE-initiated/event-driven beam reporting, in addition to L1-RSRP.  
Proposal 10: 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 11: On UE-initiated/event-driven beam reporting for a CSI report configuration, support introducing a prohibit timer for mode-A and mode-B: 
In case that triggering-event associated with the CSI report configuration is determined by the same triggering beams(s) as the last transmitted PUCC], if the prohibit timer is NOT running, the UE can transmit first PUCCH.  
Proposal 12: On beam report transmission procedure for UE-initiated/event-driven beam reporting, if multiple UE initiated beam report procedures occur, support Option-2: 
Option-2: The UEI beam report with highest priority is reported. 
FFS: Priority determination rule of UEI beam reports. 
Proposal 13: On beam report transmission procedure for UE-initiated/event-driven beam reporting, do not confirm the following Working Assumption: 
Working Assumption: For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState. 
Proposal 14: On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Alt-2 (multiple UEI beam reports), support the following alternative:
All the reported UEI beam reports should satisfy the triggering condition. 
Additional indications of ‘CSI report configuration id’ are provided. 
Maximum number of CSI reports in the 2nd PUSCH is configurable by RRC signaling. 
Proposal 15: 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/ED 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/ED beam report is sent
Proposal 16: UE only stores the QCL properties associated with the reported new beam(s) satisfying the triggering condition, after the UEI/ED beam report is sent. 

3GPP TSG RAN WG1 #120-bis	R1-2502897
Wuhan, China, April 7th – 11th, 2025
Source:		KDDI Corporation
Title:		Discussions 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 proposals:

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

Proposal 2:
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.

Proposal 3:
When reporting the RSRP of the current beam in Event-1, RSRP of the current beam is expressed as the differential RSRP from the event threshold of Event-1. 
FFS: Whether/How to handle the cases where the reported RSRP exceeds the threshold at the reporting timing.
Report format for Event-1

Proposal 4:
Regarding UE-initiated/event-driven beam reporting, for Event-7, the following option as an extension on report format for Event-2 should be supported. 
Option-1: Additional field to indicate the codepoint of the activated TCI state with Q-th best quality.
FFS: Further report other activated beam(s) to be updated, e.g., from {Q+1}-th best quality to the worst one;

Proposal 5:
Regarding UE-initiated/event-driven beam reporting, for Event-7, the following option as an extension on report format for Event-2 should be supported. 
Option-2: Extending the maximum number of reported RS(s) to 8.

Proposal 6:
On UE-initiated/event-driven beam management, to reduce beam application latency after a UEI/ED beam report is sent, Alt-1 should be supported. 
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 

Proposal 7:
On UE-initiated/event-driven beam management, to reduce beam application latency after a UEI/ED beam report is sent, Alt-2 should be supported. 
Alt-2: 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 reported as synchronized in the UEI/ED 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/ED beam report is sent
FFS: How to inform a reported new beam in a UEI/ED beam report (i.e., introducing one-bit indicator for each reported new beam or all the reported new beam are assumed to be synchronized)

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

Agenda item:	9.2.1
Source: 	Moderator (ZTE)
Title: 	Moderator Summary #4 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