System and method for user equipment (UE) initiated beam management

Abstract

Disclosed is a system and method for performing a UE-initiated beam management procedure, the method comprising: receiving, by a user equipment (UE), configuration information comprising beam quality assessment data for the UE to determine a quality of a current beam and / or a quality of a new beam, and trigger event data, the trigger event data is used by the UE to determine that a condition for performing a UE initiated (UEI) beam management (BM) procedure is satisfied; and transmitting a beam report based on determining by the UE that the condition is satisfied.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 699,039, filed on September 25, 2024, entitled “SYSTEMS AND METHODS FOR USEREQUIPMENT(UE)INITIATED BEAM MANAGEMENT,” U.S. Provisional Application No. 63 / 570,019, filed on March 26, 2024, entitled “UE-INITIATED BEAM MANAGEMENT,” U.S. Provisional Application No. 63 / 548,337, filed on November 13, 2023, entitled “UE-INITIATED BEAM MANAGEMENT,” and U.S. Non-Provisional Patent Application No. 18 / 930,453, filed on October 29, 2024, the entire disclosures of all of which are incorporated herein by reference. Technical Field

[0003] Various aspects of embodiments of the present disclosure relate to wireless communications. For example, various aspects of embodiments of the present disclosure relate to performing UE-initiated beam management. Background Art

[0004] Modern communication devices (e.g., mobile phones, vehicles, laptops, satellites, etc.), also referred to as user equipment (UE), can communicate with a network node (e.g., a base station, also referred to as a gNB) to receive data from a network associated with the network node and to send data to a network associated with the network node. The network node may send multiple beams to select from when communicating with the UE. As part of a beam management (BM) procedure, the UE may perform quality measurements on multiple beams to select the best beam for communicating with the network node.

[0005] The above information disclosed in this Background section is for enhancement of understanding of the background of the present disclosure and therefore it may contain information that does not constitute the prior art. Summary of the invention

[0006] Some beam management procedures may result in relatively high overhead (e.g., signaling overhead) and relatively high power consumption. For example, a network node may configure multiple reference signals (RS) corresponding to different beams, configure corresponding channel state information (CSI) report types, and send the RS to the UE. The UE may measure the RS and provide a report (e.g., CSI report) back to the network node, resulting in additional power consumption on the UE side and additional overhead in terms of resources occupied by the RS.

[0007] To overcome these problems, systems and methods for performing UE-initiated (UEI) beam management are described herein. For example, a UE may determine when a triggering event occurs and perform a UEI BM procedure. As part of the UEI BM procedure, the UE may determine a currently used beam (e.g., a current beam) and candidate beams (e.g., a new beam) from a plurality of beams sent from a network node to the UE. For some BM procedures, the UE may receive a plurality of beams and report beam quality measurements (e.g., detailed beam quality measurements) back to the network node, regardless of whether any triggering event has occurred and regardless of whether the beam quality measurements correspond to a current beam or a candidate beam.

[0008] Aspects of some embodiments of the present disclosure: reducing the amount of RS sent from a network node to a UE for evaluating the quality of a currently used beam; reducing the amount of reports sent from a UE to a network node to maintain an established beam; enabling faster switching between a currently used beam and a second beam when the second beam becomes a better beam for communicating with the network node than the currently used beam; providing a method for avoiding premature switching (e.g., premature switching), which may result in a problematic ping-pong effect; reducing the signaling overhead of measuring reference signals or the overhead of UE reports when the UEI BM process is applied.

[0009] Some embodiments of the present disclosure relate to triggering events that may cause a UE to perform a UEI BM procedure.

[0010] Some embodiments of the present disclosure relate to reporting information provided from a UE to a network node as part of a UEI BM procedure.

[0011] The above method improves upon previous methods by reducing the power consumption and overhead involved in beam management via UEI beam management.

[0012] According to some embodiments of the present disclosure, a method for performing a UE-initiated beam management process includes: receiving, by a user equipment (UE), configuration information including beam quality assessment data and trigger event data, the beam quality assessment data being used by the UE to determine the quality of a current beam and / or the quality of a new beam, the trigger event data being used by the UE to determine whether conditions for performing a UE-initiated (UEI) beam management (BM) process are met; and sending a beam report based on the UE determining that the conditions are met.

[0013] The method may further include: determining, by the UE, that the first beam is a current beam, and / or determining, by the UE, that the second beam is a new beam.

[0014] Determining that the condition is satisfied may include comparing a characteristic of the current beam with a characteristic of the new beam.

[0015] The condition may include that the quality of the new beam is better than the current beam by a threshold, where the threshold is based on reference signal received power (RSRP).

[0016] The UE may determine that the condition is satisfied by determining that a difference between a first RSRP of a current beam and a second RSRP of a new beam is less than a threshold.

[0017] The threshold may be configured via higher layer signaling that complies with the Radio Resource Control (RRC) protocol.

[0018] The condition may include that the quality of the current beam is worse than a threshold, wherein the threshold is determined based on the signal strength of the current beam.

[0019] The condition may include that the quality of the new beam is better than a reference signal (RS) derived from an activated transmission configuration indicator (TCI) state reaching a threshold.

[0020] The UE may implicitly determine that the first beam is the current beam based on an indicated transmission configuration indicator (TCI) state or based on an activated TCI state.

[0021] The current beam may be explicitly configured via the Radio Resource Control (RRC) protocol.

[0022] The UE may implicitly determine that the second beam is a new beam based on an activated transmission configuration indicator (TCI) state.

[0023] The new beam may be explicitly configured via the Radio Resource Control (RRC) protocol.

[0024] The condition may include a threshold number of degradation instances.

[0025] The threshold number of degradation instances may be based on consecutively occurring degradation instances.

[0026] The threshold number of degradation instances may be configured via a radio resource control (RRC) protocol.

[0027] The threshold number of degradation instances may be based on degradation instances occurring within a time window, wherein the time window is configured via a radio resource control (RRC) protocol.

[0028] The time window may begin based on the occurrence of a first degradation instance and may terminate based on the expiration of a timer or based on the occurrence of a threshold number of degradation instances.

[0029] The threshold number of degradation instances may be based on a beam failure recovery (BFR) procedure.

[0030] The method may also include sending, by the UE as part of a UE capability signaling procedure, information indicating that the UE is capable of supporting the UEIBM procedure.

[0031] According to other embodiments of the present disclosure, a user equipment (UE) configured to support a UE-initiated beam management process includes a processing circuit, which is configured to: receive configuration information including beam quality assessment data and trigger event data, the beam quality assessment data is used by the UE to determine the quality of a current beam and / or the quality of a new beam, and the trigger event data is used by the UE to determine whether conditions for performing a UE-initiated (UEI) beam management (BM) process are met; and send a beam report based on determining that the conditions are met.

[0032] According to other embodiments of the present disclosure, a method for performing a UE-initiated beam management process includes: receiving, by a user equipment (UE), configuration information including report data and trigger event data, the report data being used by the UE to report information about the quality of a current beam and / or the quality of a new beam, the trigger event data being used by the UE to determine whether a condition is met for performing a UE-initiated (UEI) beam management (BM) process; and sending a beam report based on the UE determining that the condition is met, the beam report including information about the quality of the current beam and / or the quality of the new beam.

[0033] The method may further include: determining, by the UE, that the first beam is a current beam, and / or determining, by the UE, that the second beam is a new beam.

[0034] Determining that the condition is satisfied may include comparing a characteristic of the current beam with a characteristic of the new beam.

[0035] The beam report can be associated with a periodic reference signal (RS) such as a synchronization signal block (SSB) or a periodic channel state information reference information (P-CSI-RS).

[0036] The beam report may include a measurement of the layer 1 reference signal received power (L1-RSRP) and the corresponding reference signal (RS) identifier.

[0037] The beam report may include: an absolute reference signal received power (RSRP) for a best beam among multiple beams including a current beam and a new beam, the best beam having the maximum measured RSRP among the reported RSRP measurements associated with the multiple beams; and one or more differential RSRP measurements for remaining beams in the multiple beams, the remaining beams including the current beam, the one or more differential RSRP measurements calculated based on the difference from the absolute RSRP of the best beam.

[0038] The method may also include sending, by the UE, a first UL channel as a scheduling request (SR) based on degradation of quality of a current beam to request an uplink (UL) grant for a second UL channel as a physical uplink shared channel (PUSCH) to carry a beam report.

[0039] The network node can link the SR to the current beam or a new beam.

[0040] The method may also include sending, by the UE, a first channel to notify that a second channel carries a beam report, wherein the first channel comprises a physical uplink shared channel (PUCCH), and wherein the second channel comprises an uplink (UL) channel.

[0041] Sending a beam report may include: carrying the beam report on a configured granted physical uplink shared channel (CG PUSCH) or a configured PUCCH based on periodic CSI reporting.

[0042] The first channel and the second channel may be separated by a number of symbols in the time domain.

[0043] The timing of CG PUSCH or the timing of PUCCH can be used to send beam reports.

[0044] The beam report may include measurements of several reported beams among a plurality of beams, the plurality of beams including the current beam and the new beam, the number of reported beams being configured by a radio resource control (RRC) protocol.

[0045] The beam report may include a first portion having a fixed payload, and a second portion having a variable payload determined based on the content of the first portion.

[0046] The method may also include indicating, by the UE, a number of beam measurements to be included in the beam report, and one or more events to be included in the beam report from among the one or more configured events.

[0047] Sending a beam report may include treating a container carrying the beam report as an aperiodic channel state information (CSI) report carrying beam management L1-RSRP or L1-SINR for CSI multiplexing priority determination.

[0048] Sending the beam report may include sending the beam report in a second cell different from the first cell in which the measurement is performed.

[0049] A beam report may occupy the same computational processing unit as a channel state information (CSI) report with a reporting amount of "None", and a beam report may occupy the same computational processing unit for the same duration as a CSI report with a reporting amount of "None".

[0050] The method may further include indicating, by the UE as part of a capability signaling procedure, a reporting amount to be reported for the UEI BM procedure.

[0051] According to other embodiments of the present disclosure, a user equipment (UE) configured to support a UE-initiated beam management process includes a processing circuit, wherein the processing circuit is configured to execute: receiving, by the user equipment (UE), configuration information including report data and trigger event data, the report data is used by the UE to report information about the quality of a current beam and / or the quality of a new beam, and the trigger event data is used by the UE to determine whether conditions for performing a UE-initiated (UEI) beam management (BM) process are met; and based on the UE determining that the conditions are met, sending a beam report including information about the quality of the current beam and / or the quality of the new beam. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The above and other aspects of the present disclosure will be more clearly understood from the following detailed description of illustrative, non-limiting embodiments with reference to the accompanying drawings.

[0053] Figure 1 is a block diagram depicting a system for performing a UE-initiated beam management process according to some embodiments of the present disclosure.

[0054] Figure 2 is a block diagram depicting multiple beams in a system for performing UE-initiated beam management procedures according to some embodiments of the present disclosure.

[0055] Figure 3 is a diagram depicting the operation of a first method (hereinafter referred to as “method 1 ” or method 3000 ) of the overall framework for UEI BM according to some embodiments of the present disclosure.

[0056] Figure 4 is a diagram depicting the operation of a second method (hereinafter referred to as "method 2" or method 4000) of the overall framework for UEI BM according to some embodiments of the present disclosure.

[0057] Figure 5 is a diagram depicting the operation of a third method (hereinafter referred to as “Method 3” or Method 5000 ) of the overall framework for UEI BM according to some embodiments of the present disclosure.

[0058] Figure 6 is a diagram depicting a fixed window for counting triggering instances according to some embodiments of the present disclosure.

[0059] Figure 7 is a diagram depicting a moving window for counting triggering instances according to some embodiments of the present disclosure.

[0060] Figure 8 is a diagram depicting an example of CPU occupancy of a periodic RS for detecting degradation of a currently used beam according to some embodiments of the present disclosure.

[0061] Fig. 9 is a diagram depicting an example of CPU occupancy for PDCCH triggered UE initiated reporting for aperiodic RS according to some embodiments of the present disclosure.

[0062] Fig.10 is a diagram depicting an example of a UL channel for carrying potential requests (eg, potential reports) according to some embodiments of the present disclosure.

[0063] Fig.11 is a diagram illustrating the use of CFRA to send an indication from a UE to a network node that the quality of a currently used beam has degraded according to some embodiments of the present disclosure.

[0064] Fig.12 is a diagram depicting an example of sending an indication of a preferred beam (or TCI state) from a UE to a network node using CFRA when a currently used beam is downgraded according to some embodiments of the present disclosure.

[0065] Fig.13 is a diagram depicting a modification of a cyclic shift (CS) in a PUCCH format for reporting UEI-BM information according to some embodiments of the present disclosure.

[0066] Fig.14 is a diagram depicting a CSI reporting configuration for Method 2 according to some embodiments of the present disclosure.

[0067] Fig.15 is a flow chart depicting a method for handling a collision between a container carrying a request (eg, a report) and another UL channel (eg, a signal) according to some embodiments of the present disclosure.

[0068] Fig.16 is a diagram illustrating an example of configuring a window indicating when multiplexing of a PUSCH and a container carrying a request (eg, a report) from a UE is allowed according to some embodiments of the present disclosure.

[0069] Fig.17 is a diagram depicting an example of using CFRA (as discussed above) to indicate a preferred TCI state according to some embodiments of the present disclosure.

[0070] Fig.18 is a flow chart depicting a method for performing a UE-initiated beam management process according to some embodiments of the present disclosure.

[0071] Fig.19is a flow chart depicting a method for performing a UE-initiated beam management process according to some embodiments of the present disclosure.

[0072] Fig. 20 is a block diagram of an electronic device in a network environment according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0073] In the following detailed description, many specific details are set forth in order to provide a thorough understanding of the present disclosure. However, those skilled in the art will appreciate that the disclosed aspects can be practiced without these specific details. In other examples, well-known methods, processes, components and circuits are not described in detail to avoid obscuring the subject matter disclosed herein.

[0074] References throughout this specification to "one embodiment" or "an embodiment" mean that the specific features, structures, or characteristics described in conjunction with the embodiment may be included in at least one embodiment disclosed herein. Therefore, the phrases "in one embodiment" or "in an embodiment" or "according to an embodiment" (or other phrases with similar meanings) that appear in various places throughout this specification may not necessarily all indicate the same embodiment. In addition, specific features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In this regard, as used herein, the word "exemplary" means "used as an example, instance, or illustration." Any embodiment described herein as "exemplary" should not be interpreted as necessarily being preferred or advantageous over other embodiments. In addition, specific features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In addition, depending on the context discussed herein, a singular term may include a corresponding plural form, and a plural term may include a corresponding singular form. Similarly, hyphenated terms (e.g., "two-dimensional", "predetermined", "pixel-specific", etc.) may occasionally be used interchangeably with corresponding non-hyphenated versions (e.g., "two-dimensional", "predetermined", "pixel-specific", etc.), and capitalized terms (e.g., "Counter Clock", "Row Select", "PIXOUT", etc.) may be used interchangeably with corresponding non-capitalized versions (e.g., "counter clock", "row select", "pixout", etc.). Such occasionally interchangeable usages should not be considered inconsistent with each other.

[0075] In addition, depending on the context discussed herein, singular terms may include corresponding plural forms, and plural terms may include corresponding singular forms. It should also be noted that the various drawings (including component drawings) shown and discussed herein are for illustrative purposes only and are not drawn to scale. For example, for clarity, the size of some elements may be exaggerated relative to other elements. In addition, if deemed appropriate, reference numerals are repeated in the drawings to indicate corresponding and / or similar elements.

[0076] The terms used herein are only used for the purpose of describing some example embodiments and are not intended to limit the claimed subject matter. As used herein, the singular forms "a", "an", and "the" are intended to also include the plural forms, unless the context clearly indicates otherwise. It will be further understood that the terms "include" and / or "comprise" when used in this specification specify the presence of the features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0077] It will be understood that when an element or layer is referred to as being on, "connected to" or "coupled to" another element or layer, it can be directly on, connected to or coupled to another element or layer, or there may be intermediate elements or layers. In contrast, when an element is referred to as being "directly on," "directly connected to" or "directly coupled to" another element or layer, there are no intermediate elements or layers. The same reference numerals always indicate the same element. As used herein, the terms "or" and "and / or" include any and all combinations of one or more of the associated listed items.

[0078] As used herein, the terms "first," "second," and the like are used as labels for the nouns that follow them and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless explicitly so defined. In addition, the same reference numerals may be used across two or more figures to indicate parts, components, blocks, circuits, units, or modules having the same or similar functions. However, this usage is only for simplicity of illustration and ease of discussion; it does not mean that the construction or architectural details of such components or units are the same across all embodiments, or that such commonly referenced components / modules are the only way to implement some example embodiments disclosed herein.

[0079] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the subject matter belongs. It will be further understood that terms (such as those defined in commonly used dictionaries) should be interpreted as having a meaning consistent with their meaning in the context of the relevant art, and will not be interpreted in an idealized or overly formal sense unless explicitly so defined herein.

[0080] As used herein, the term "module" indicates any combination of software, firmware, and / or hardware configured to provide the functionality described herein in conjunction with the module. For example, software may be embodied as a software package, code, and / or instruction set or instructions, and the term "hardware" as used in any embodiment described herein may include, for example, individually or in any combination, components, hardwired circuits, programmable circuits, state machine circuits, and / or firmware storing instructions executed by programmable circuits. Modules may be collectively or individually embodied as circuits forming part of a larger system, such as, but not limited to, an integrated circuit (IC), a system on a chip (SoC), a component, and the like.

[0081] The electronic or electrical devices and / or any other related devices or components according to the embodiments of the present disclosure described herein can be implemented using any suitable hardware, firmware (e.g., application specific integrated circuit (ASIC)), software, or a combination of software, firmware and hardware. For example, the various components of these devices can be formed on an integrated circuit (IC) chip or on separate IC chips. In addition, the various components of these devices can be implemented on a flexible printed circuit film, a tape carrier package (TCP), a printed circuit board (PCB), or formed on a substrate. In addition, the various components of these devices can be processes or threads running on one or more processors in one or more computing devices, which execute computer program instructions and interact with other system components for performing the various functions described herein. The computer program instructions are stored in a memory, wherein the memory can be implemented in a computing device using a standard memory device (such as, for example, a random access memory (RAM)). The computer program instructions can also be stored in other non-temporary computer-readable media, such as, for example, a CD-ROM, a flash drive, etc. In addition, it should be appreciated by those skilled in the art that, without departing from the spirit and scope of the exemplary embodiments of the present disclosure, the functions of various computing devices can be combined or integrated into a single computing device, or the functions of a particular computing device can be distributed across one or more other computing devices.

[0082] Figure 1 is a block diagram depicting a system for performing a UE-initiated beam management process according to some embodiments of the present disclosure.

[0083] refer to Figure 1 , system 1 may include a UE 105 and a network node 110 (e.g., a gNodeB, also referred to as a “base station”) in communication with each other. UE 105 may include a radio 115 and means for processing. The means for processing may include a processing circuit 120, which may perform various methods disclosed herein (e.g., Figures 3 to 19 The radio 115 may correspond to the communication module 2090 (see Fig. 20 ). The processing circuit 120 may correspond to the processor 2020 (see Fig. 20 ). The processing circuit 120 may receive transmissions from the network node 110 via the radio 115, and the processing circuit 120 may send signals to the network node 110 via the radio 115. Transmissions from the network node 110 may be provided to the UE 105 via downlink (DL) transmissions 10. Transmissions from the UE 105 may be provided to the network node 110 via uplink (UL) transmissions 20.

[0084] Figure 2 is a block diagram depicting multiple beams in a system for performing UE-initiated beam management procedures according to some embodiments of the present disclosure.

[0085] refer to Figure 2 , the network node 110 may send a plurality of beams B to the UE 105. The plurality of beams B may include a first beam B1 to an nth beam Bn. One or more beams of the plurality of beams B may be used for DL ​​transmission 10 (see Figure 1 ) and / or for UL transmission 20. In some embodiments, the UE 105 may determine a current beam from among a plurality of beams. In some embodiments, the UE 105 may determine a new beam (e.g., a candidate beam) from among a plurality of beams B. For example, the UE 105 may perform quality measurements on one or more beams among the plurality of beams B to determine when a triggering event has occurred. Based on determining that a triggering event has occurred, the UE 105 may send a report (e.g., a beam report) to the network node 110. By initiating beam management using a triggering event detected by the UE 105, signaling overhead and power consumption may be reduced. For example, the UE may reduce (e.g., may avoid) the risk of unnecessarily requesting an RS and may report a reduced amount of information based on determining which beam among the plurality of beams B is the current beam and determining which beam among the plurality of beams B is (e.g., will be) the new beam.

[0086] In some embodiments, the UE 105 may indicate a downgrade of the current beam. In some embodiments, the UE may indicate a downgrade of the current beam and may request the RS to further evaluate the beam quality and potential replacement beams.

[0087] The following discussion is provided in four parts, including: (I) a discussion of the overall framework for UEI beam management; (II) a discussion of defined trigger conditions that UE 105 can use to determine whether to perform UEI beam management; (III) a discussion of the process for sending a request (e.g., a report); and (IV) a discussion of receiving a response (e.g., action-based) from network node 110.

[0088] I. Overall Framework for the UEI BM Process

[0089] Figure 3 is a diagram depicting the operation of a first method (hereinafter referred to as “method 1 ” or method 3000 ) of the overall framework for UEI BM according to some embodiments of the present disclosure.

[0090] Figure 4 is a diagram depicting the operation of a second method (hereinafter referred to as “method 2” or method 4000 ) of the overall framework for UEI BM according to some embodiments of the present disclosure.

[0091] Figure 5 is a diagram depicting the operation of a third method (hereinafter referred to as “Method 3” or Method 5000 ) of the overall framework for UEI BM according to some embodiments of the present disclosure.

[0092] refer to Figure 3 , method 3000 (method 1) may include one or more of the following operations. UE 105 may indicate to network node 110 via capability signaling that UE 105 supports UE-initiated beam management (operation 3001). Based on the indicated capability signaling, network node 110 may provide UE 105 with a configuration (e.g., beam quality assessment data) for facilitating the assessment of the quality of the beam. For example, the configuration may facilitate the assessment of the quality of the currently used beam and the corresponding quality of the potential candidate beam for replacement (operation 3002). For example, if the assessment is based on measuring RS, network node 110 may provide RS configuration (e.g., RS configuration) and trigger event data to UE 105. The RS configuration may be used by UE 105 to assess the quality of the current beam B and one or more new beams B. Network node 110 may provide UE 105 with any suitable trigger condition that may be used to reflect (e.g., determine) the quality of the beam. When the quality of the currently used beam deteriorates below a certain level, the network node 110 may provide the UE 105 with a necessary configuration for sending a report (e.g., an indication) to the network node 110. In some embodiments, if necessary, the network node 110 may send an RS for evaluating the quality of the beam (operation 3003). In some embodiments, the evaluation process may be performed without an RS. For example, other metrics including hybrid automatic repeat request (HARQ) acknowledgement / negative acknowledgement (Ack / NACK) may be used to determine beam quality.

[0093] UE 105 may monitor beam quality (operation 3004). For example, UE 105 monitors beam quality based on RS or other metrics. When a triggering event occurs (e.g., when the beam quality level is below a threshold), UE 105 may send a request to network node 110 (operation 3005). For example, UE 105 may send a request to network node 110 based on determining degradation of beam quality. In some embodiments, the request may include a measurement report. In some embodiments, the request may include an indication of a triggering event (e.g., beam quality has dropped below (e.g., is below) a certain level (e.g., a threshold)). When network node 110 receives the request, network node 110 may respond by performing an action to address the degradation of beam quality (operation 3006). In some embodiments, network node 110 may send a confirmation (e.g., an explicit confirmation or an implicit confirmation) to UE 105 (operation 3007). UE 105 may monitor the response of network node 110 (operation 3008). The operations of method 3000 (method 1) are discussed in further detail below.

[0094] refer to Figure 4 , method 4000 (method 2) may include one or more of the following operations. UE 105 may indicate to network node 110 via capability signaling that UE 105 supports UE-initiated beam management (operation 4001). In method 2, unlike method 1, network node 110 may not configure RS for evaluating beam quality. Instead, network node 110 may configure a triggering event (e.g., triggering condition) and may provide UE 105 with a configuration for sending a report (e.g., indication) to network node 110 when the triggering event occurs (e.g., when the quality of the currently used beam deteriorates below a certain level (e.g., a threshold)) (operation 4002). UE 105 may monitor beam quality (operation 4003). When the triggering event occurs (e.g., when the quality of the currently used beam deteriorates below a threshold), UE 105 may send a request to network node 110 to send RS to further evaluate the currently used beam and / or evaluate other candidate beams (operation 4004). The network node 110 may receive the request and perform appropriate actions to address the degradation of the beam quality (operation 4005). For example, the network node 110 may send an RS (operation 4006). In some embodiments, the UE 105 may measure the sent RS to evaluate the beam quality (operation 4007). The UE 105 may report the configured reporting amount to the network node 110 (operation 4008). The operations of method 4000 (method 2) are discussed in further detail below.

[0095] One difference between Method 1 and Method 2 is the nature of the request. The request of Method 1 may include the UE 105 sending an indication to the network node 110 that the currently used beam has degraded and providing additional information (e.g., a measurement report). The request of Method 2 may include the UE 105 requesting the network node 110 to send the RS itself.

[0096] refer to Figure 5 , method 5000 (method 3) may include one or more of the following operations. UE 105 may receive a beam measurement configuration and a report configuration from network node 110 (operation 5001). In some embodiments, the configuration may include a configuration of multiple BM schemes (e.g., a gNB-initiated BM scheme and / or a UE-initiated BM scheme) with index numbers. UE 105 may determine (e.g., may detect) that the quality of DL reception has degraded (e.g., deteriorated) (operation 5002). UE 105 may detect a condition for DL ​​reception improvement (operation 5003). UE 105 may determine a preferred BM process (e.g., a gNB-initiated BM scheme or a UE-initiated BM scheme) (operation 5004). UE 105 may send a request to network node 110 to perform BM for DL ​​improvement (operation 5005). Network node 110 may respond to UE 105 (based on the request) and perform a DL BM process and a UL BM process (operation 5006). The BM process may result in the selection of a new beam pair. One or more operations of method 3 may be similar to one or more operations of method 1 and / or method 2. The operations of method 5000 (method 3) are discussed in further detail below.

[0097] II. Trigger conditions for determining whether to execute UEI BM

[0098] The common operation in the schemes of Method 1 and Method 2 is that UE 105 can detect the degradation of the currently used beam based on the occurrence of an event (e.g., a trigger event or a trigger condition) to determine whether to perform UEI BM (e.g., whether to perform the next operation of UEI BM, such as sending a report or indication to the network node 110).

[0099] The triggering event may be based on (e.g., may depend on) UE implementation. In some embodiments, the network node 110 may not configure the UE 105 with a dedicated configuration for detecting a triggering event. For example, the network node 110 may not configure a specific threshold as a triggering event, and may not configure or send an additional RS to evaluate whether the event has occurred. Such an approach may be beneficial in reducing signaling overhead and reducing the configuration that the network node 110 may provide to the UE 105. In some embodiments, the UE 105 may indicate to the network node 110 that the UE 105 is capable of autonomously detecting the occurrence of one or more triggering events for determining whether to perform UEIBM. For example, the UE 105 may indicate through a capability signaling process that the UE 105 is capable of performing UEI BM.

[0100] In method 1, although the network node 110 may not configure (e.g., may not send) RS to enable the UE to detect degradation of the currently used beam, the network node 110 may still configure the UE 105 with additional RS to enable the UE 105 to detect one or more candidate beams (e.g., to detect new beams other than the currently used beam).

[0101] In method 2, the network node 110 may not configure a dedicated RS for evaluating the currently used beam or for identifying the candidate beam. Figure 4 After operation 4004 of the present invention, the network node 110 may send an RS to the UE 105 for evaluating the currently used beam and / or for identifying the candidate beam (e.g., for identifying potential candidate beams). For example, in some embodiments, the UE 105 may monitor the RS sent by the network node 110 and may identify the currently used beam and / or the candidate beam based on the RS. Based on the RS, the UE 105 may also determine the quality of the currently used beam and / or determine the quality of the candidate beam based on the RS.

[0102] In some embodiments, the network node 110 may configure the UE 105 with trigger event data (e.g., different thresholds and / or conditions), and the UE may use the trigger event data to determine whether to perform UEI BM. In some embodiments, such trigger event data may be provided via high-layer signaling such as a radio resource control (RRC) protocol. For example, the threshold may be RRC configured (e.g., configured for event-1, event-2, or event-7 of the radio access network radio layer 1 (RAN1) agreement). Trigger event data (e.g., threshold) may be used in different ways in different events. In some embodiments, trigger event data (e.g., trigger value) may be provided by a standard (e.g., may be provided in a 3GPP specification) and may be applied in the absence of a configured one (e.g., in the absence of a configured trigger event). For example, the network node 110 may send RS (e.g., channel state information RS (CSI-RS), synchronization signal block (SSB), demodulation reference signal (DMRS), etc.), and the UE 105 may measure the transmitted RS to compare the measurement with a threshold (e.g., a configured or predefined threshold).

[0103] In some embodiments, the UEI BM trigger threshold may include a measured signal strength. For example, layer 1 RSRP (L1-RSRP) may be supported as a quality metric for determining whether a trigger event has occurred. For example, a trigger event may include determining that the quality of at least one new beam (e.g., based on L1-RSRP) has become better than the current beam to reach a threshold, determining that the quality of the current beam is worse than a certain threshold (e.g., based on L1-RSRP), or determining that the quality of at least one new beam (based on L1-RSRP) has become better than one of the beams associated with one or more activated TCI states. In some embodiments, the trigger threshold may include a measured reference signal received power (RSRP), a reference signal strength indicator (RSSI), and / or a signal to interference and noise ratio (SINR). In some embodiments, the trigger threshold may include an absolute threshold. For example, if the RSRP of the serving beam drops below a specific threshold, the UE 105 may assume that an event related to the degradation of the currently used beam has been detected (e.g., it may be assumed that a trigger event has occurred). Such a trigger event may be reflected by the following formula (2.01):

[0104] Measured RSRP of the currently used beam <RSRP_th1。

[0105] RSRP_th1 refers to a first triggering threshold for determining whether to perform UEI BM (eg, whether to perform the next operation of UEI BM).

[0106] In some embodiments, the trigger threshold may be relative to the candidate beams. For example, the trigger event detection for beam reporting may include the quality of at least one new beam (such as L1-RSRP) becoming better than the current beam to reach a threshold. In some embodiments, if the difference between the RSRP of the currently used beam and the RSRP of the candidate beam becomes less than the RSRP threshold, the UE 105 may assume that an event related to the degradation of the currently used beam is detected. Such a trigger event may be reflected by the following formula (2.02):

[0107] (Measured RSRP of the currently used beam) - (Measured RSRP of a specific candidate beam) <RSRP_th2。

[0108] RSRP_th2 refers to a second triggering threshold for determining whether to perform UEI BM.

[0109] In some embodiments, the measured signal strength (e.g., RSRP, RSSI, and / or SINR) may include an instantaneous measurement based on each individual RS. In some embodiments, the measured signal strength may be measured via post-processing to reduce measurement fluctuations due to noise and fading. For example, post-processing may include infinite impulse response (IIR) filtering of the raw measurement values, as shown in the following formula (2.03):

[0110] F n =(1–a)*F n-1 +a*M n .

[0111] Among them: F n refers to the nth updated filtered measurement result, which is used to assess whether an event is triggered (e.g., whether a triggering event has occurred); a refers to the filter coefficient; F n-1 refers to the n-1th old filter measurement result; and M n Refers to the nth physical measurement. In some embodiments, the formula (e.g., formula 2.03 above) may be defined by a standard (e.g., a 3GPP specification), and the value of a may be configured by the network node 110. In some embodiments, the formula and / or the value of a may be determined based on the UE implementation. For example, the UE 105 may determine the formula and / or the value of a.

[0112] In some embodiments, the formula for calculating the degradation of the current beam may include an additional hysteresis parameter (e.g., Hys) to reduce the risk of a problematic ping-pong effect (e.g., to reduce the risk of generating a ping-pong effect). The ping-pong effect may occur based on a temporary change in signal strength. For example, a temporary decrease in signal strength may trigger the following back-and-forth determination: at one moment the first beam is superior to the second beam, and at the next moment the second beam is superior to the first beam. For the degradation condition of the currently used beam, the formula using the additional hysteresis parameter may include the following formula (2.04):

[0113] (RSRP+Hys of the currently used beam measured) <RSRP_th1。

[0114] In some embodiments, the trigger condition based on comparing the relatively weak current beam with the candidate beams may include the following formula (2.05):

[0115] (Measured RSRP of the currently used beam) - (Measured RSRP of a specific candidate beam) <RSRP_th2。

[0116] In some embodiments, the formula for calculating the degradation of the current beam may include one or more additional offsets (e.g., offsets Ob, Oc, and / or Of) per bandwidth part (BWP), per cell, or per frequency. In some embodiments, the network node 110 may configure the offset values ​​based on the properties of different environments. For example, beams in higher frequency environments may vary more. For example, measurements of beams in higher frequency environments may fluctuate more than measurements of beams in lower frequency environments. The formula for calculating the degradation of the current beam with additional offsets may include the following formula 2.06:

[0117] (measured RSRP of the currently used beam) + Hys + Ob + Oc + Of <RSRP_th1。

[0118] Wherein: Hys refers to the hysteresis parameter; Ob refers to the offset per BWP; Oc refers to the offset per cell; and Of indicates the offset per frequency band.

[0119] In some embodiments, the formula based on the condition including the comparison of the relative weakness of the current beam and the candidate beams may include the following formula (2.07):

[0120] (Measured RSRP of the currently used beam) - (Measured RSRP of a specific candidate beam) + Ob + Oc + Of <RSRP_th2。

[0121] Triggering UEI BM based on comparing the measurement to a certain threshold may be suitable for use with Method 1. For example, such a triggering event may include causing the network node 110 to send an RS for measuring the quality of a serving beam (e.g., a current beam) and / or for measuring the quality of other beams (e.g., candidate beams).

[0122] As discussed above, if the quality of the currently used beam recovers quickly again, the premature triggering of the UEI BM (e.g., by detecting only a single instance that satisfies the triggering condition) may lead to a ping-pong effect. To avoid such a scenario, the network node 110 may indicate to the UE 105 how many degradation instances (e.g., the number of degradation instances or degraded instances) after which the UE may perform the next action (e.g., take the next step) in the process (e.g., send a request to the network node 110), indicating that the currently used beam has degraded. Such an indication (e.g., the number of degradation instances after which the event is triggered) may be carried by a higher layer (e.g., via higher layer signaling, such as RRC). For example, the number of instances in which the UE 105 determines that the quality of at least one new beam (e.g., based on L1-RSRP) has become better (e.g., stronger) than the current beam reaches a threshold, the quality of the current beam is worse than a threshold (e.g., based on L1-RSRP), or the quality of at least one new beam (based on L1-RSRP) becomes better than one of the beams associated with the activated TCI state of at least one of the same new beams reaches a threshold can be set to be greater than or equal to a configurable number (e.g., a threshold number of degradation or degraded instances). In some embodiments, in the absence of such information about the number of degradation instances, the UE 105 can apply a value associated with a beam failure recovery (BFR) procedure. For example, the UE 105 can apply the same value as in the BFR procedure (e.g., beamFailureInstanceMaxCount).

[0123] In some embodiments, counting beam degradation instances into configured limits can be based on counting consecutive instances. For example, the configured limit can be set to three instances, and periodic RS can be used to evaluate (e.g., identify and / or assess) the beam currently in use. In this example, three consecutive periods of RS can satisfy the trigger condition so that UE105 can proceed to the next operation in the scheme (e.g., sending a request to network node 110). In some embodiments, degradation instances may not necessarily be continuous (e.g., there may be intervention measurements that do not satisfy the trigger condition). For example, it may be sufficient for UE 105 to detect the number of discontinuous degradation instances exceeding the configured limit within a time window (to trigger the next operation of UEI BM). In some embodiments, the time window can be a fixed time window that starts when the first instance occurs, and the duration of the time window can be configured by high-level signaling (e.g., by RRC).

[0124] Figure 6 is a diagram depicting a fixed window for counting triggering instances according to some embodiments of the present disclosure.

[0125] refer to Figure 6 , an example of a periodic RS for evaluating whether a triggering event has occurred is provided. The number of triggering instances INS required for the triggering event is equal to three instances within a fixed counting window CW starting from a first event (e.g., a second instance of the RS). After the triggering instance INS occurs three times within the counting window CW, even if the triggering instances are non-continuous (e.g., occurring at the second, fourth, and fifth instances of the RS, and not occurring at the third instance), the UE may proceed to the next operation in the process, such as sending an indication to the network node after the third occurrence at the fifth instance of the RS (e.g., after the third triggering instance INS occurs). In some embodiments, the UE may wait until the configured window ends. For example, once a window timer (e.g., a counting window CW) expires, the window may terminate regardless of whether the event is triggered. In some embodiments, the window may be terminated by the occurrence of a window timer expiration or based on the UE sending an indication to the network node before the window timer expires. In some embodiments, a new window may start from the first occurrence of an event (e.g., a triggering instance INS) after the previous window is terminated to ensure that there is at least one window between any two transmissions of an indication made by the UE to the network node.

[0126] Figure 7 is a diagram depicting a moving window for counting triggering instances according to some embodiments of the present disclosure.

[0127] refer to Figure 7In some embodiments, the UE may apply a moving window (e.g., a moving counting window CW) that restarts after receiving each trigger instance INS, such as Figure 7 As shown above. Figure 6 The fixed window discussed above can be configured via high-level signaling to configure the duration of the moving window. Figure 7 As shown, multiple overlapping counting windows CW (e.g., CW1 to CW4) can be started by the occurrence of each triggering instance INS (e.g., at the second, fifth, seventh and eighth instances of the RS). Once the number of triggering instances INS for the triggering event condition is met (e.g., three triggering instances), the UE can send an indication to the network node in the first available opportunity after reaching (e.g., meeting) the triggering condition (e.g., three triggering instances occur within one counting window CW) or after the counting window CW ends (e.g., after the counting window CW expires). When the triggering condition is met over a longer period of time, such an embodiment can enable more indications to be sent to the network node. In some embodiments, the counting window CW can be terminated once the window timer expires, regardless of whether the triggering event has occurred. In some embodiments, the counting window CW can be terminated by the expiration of the window timer or by the UE sending an indication to the network node before the window timer expires.

[0128] In some embodiments, the counting window CW associated with a specific RS instance may start after a certain delay from the transmission instance of the specific RS instance. In such an embodiment, the UE may be provided with time to receive the RS instance, process the RS instance, and check whether the trigger condition is met. In some embodiments, the UE may indicate a suitable gap (e.g., a timing gap) to the network node via capability signaling. In some embodiments, a suitable gap may be predefined. For example, a gap may be provided in a standard (e.g., a 3GPP specification), or a gap may be provided similar to a CSI processing timeline.

[0129] In some embodiments, to mitigate the ping-pong effect (in addition to counting instances), the condition for event triggering can be based on an average of a metric. For example, the average of a metric can include an average of measurements for consecutive RSs and / or can be similar to the above discussion. Figure 6 and Figure 7 Occurs within the counting window CW of the counting window CW.

[0130] In some embodiments, the UE request procedure may be based on physical layer measurements only. In some embodiments, the UE request procedure may be based on initial physical layer measurements followed by a medium access control (MAC) procedure, wherein higher layer counters and timers are defined to reduce the likelihood of false alarm event detection at the UE. The counter may count the number of events (e.g., trigger instances) detected by physical layer measurements at the UE, and the timer may be initiated by the first event detected by the UE. In some embodiments, the timer may have some periodicity that will include a specific semi-statistically configured time such that the event detection counter reaches a specific semi-statistically configured value.

[0131] In some embodiments, there may be other specific events (eg, conditions) for the UE to determine (eg, detect) the suitability of DL reception improvement (eg, see above). Figure 5 Operations 5002 and 5003). In operation 5002, the UE 105 may evaluate the DL reception strength and quality of one or more or all active beam pairs being used. To this end, the UE 105 may use the selected receiver (Rx) beam (from the initial beam management process) to receive transmissions from the network node 110, which employs the transmit (Tx) beam(s) indicated in the configuration phase in operation 5001. The UE 105 may measure multiple reception metrics, including a channel quality indicator (CQI), RSRP, reference signal received quality (RSRQ), signal-to-noise ratio (SNR), and / or SINR. The UE 105 may share these measurements (possibly in the form of CSI) with the network node 110, which may convert the shared measurements into reports on beam quality. In some embodiments, the UE may continuously or periodically monitor the reception of the current beam pair and other beam pairs. For example, the UE 105 may frequently measure the active beam pair at intervals (e.g., at set intervals), while some or all other available beam pairs may be monitored at less frequent intervals. The monitoring may be scheduled periodically or initiated by the network node 110 and / or the UE 105 as needed. For example, in response to a measurement result of an active beam (e.g., as a result of the measured active beam quality being below a threshold), a full beam scan measurement of all available beam pairs may be performed. In some embodiments, measurements of the active beam pair and a subset or all of the available beam pairs may be performed in response to movement of the UE 105 or in response to an activity of the user (e.g., when the UE 105 rotates or when the user initiates a particular application).

[0132] exist( Figure 5In operation 5003 of ), the UE 105 may identify opportunities to potentially enhance reception performance based on the above-mentioned measurements from operation 5001 and preconfigured trigger conditions (e.g., trigger conditions). For example, the UE 105 may determine the degraded condition of the current beam pair or possible improvements in other beam pairs (e.g., replacement beam pairs). In some embodiments, the UE 105 may compare measured metrics such as signal strength and quality (e.g., RSRP, RSRQ, SINR, SNR, CQI) with one or more thresholds (e.g., one or more predefined or dynamically set thresholds) to evaluate channel quality. For example, if the RSRP of an existing beam pair drops below a certain threshold, the UE 105 may identify opportunities for DL ​​reception improvement. In some embodiments, changes in other monitored beams, such as one of K other monitored beams having greater signal strength than the current beam, may trigger the UE 105 to perform DL reception enhancement. As used herein, unless otherwise noted, the variable "K" refers to an integer greater than zero. In some embodiments, the rate of change of the measurement (such as, a rapid change of one or more measurement beams) can be a triggering event for the UE 105 to perform DL reception enhancement. In some embodiments, the movement of the UE (such as a change in position or orientation) can also be used as a trigger. In some embodiments, the trigger condition may include an SNR level below one or more specific thresholds of all DL RSs in the current transmission configuration indication (TCI) table and the maximum L1-RSRP becomes weaker than a threshold. In some embodiments, the number of beams (e.g., a count of beams) with L1-RSRP measurements exceeding a first threshold falling below a beam number threshold can be another triggering condition. In some embodiments, the trigger condition may include a physical downlink shared channel (PDSCH) SNR and / or a physical downlink control channel (PDCCH) SNR. For example, if the most recent PDSCH SNR measurement and / or the most recent PDCCH SNR measurement is below a threshold of one or more (e.g., all) received DL RSs, a triggering event may occur.

[0133] In some embodiments, the trigger condition may include the maximum L1-RSRP of all beam pairs measured by the UE being less than (e.g., less than) a threshold. For example, the strongest beam pair link of the currently active beam pair becoming weaker than (e.g., less than) a threshold may be a trigger event. In some embodiments, the threshold may be preconfigured by RRC (e.g., via an RRC protocol).

[0134] In some embodiments, the triggering condition may include a new beam among the K monitored beams being (eg, becoming) stronger than one or more (eg, stronger than all) of the K monitored beam pair links.

[0135] In some embodiments, the trigger condition may include that the current beam (eg, the previously strongest beam) is no longer the strongest beam among the set of K monitored beam-pair links.

[0136] In some embodiments, the trigger condition may include one or more (e.g., all) of the K monitored beam pair links becoming weaker than a threshold. The threshold may be preconfigured by RRC. Such a trigger condition may serve as a warning (e.g., early warning) of future beam failure events.

[0137] In some embodiments, the trigger condition may include motion of the UE 105. For example, a rotation, a change in orientation, and / or a change in position (e.g., a change in location) may be a triggering event.

[0138] In some embodiments, new quantities may be introduced for indicating the amount of reporting to be reported by the UE 105 to the network node 110. For example, the new quantity may be introduced as "UE initiated reporting" or similar. When the network node 110 indicates such reporting amounts to the UE 105, the UE 105 may not report any amount of the CSI-reportConfig unless a trigger condition similar to one or more of the trigger conditions discussed above is met (e.g., occurs) or any other suitable (e.g., related) condition occurs. As part of the request (e.g., report) details, what the UE may report and which channel may carry the report is discussed in further detail below.

[0139] In conventional New Radio (NR), there are supported combinations of CSI reporting configurations and CSI-RS configurations, depending on their temporal behavior as periodic, semi-persistent or aperiodic. Such combinations may be updated. For example, Table 1 below provides an example of an update to supported combinations from NR.

[0140] Table 1: Triggering (eg, activation) of CSI reporting for possible CSI-RS configurations:

[0141]

[0142] Updates to supported combinations from NR may be associated with Method 1, where RS may be sent to evaluate the currently used beam and potential candidate replacement beams. In some embodiments, periodic or semi-periodic (P or SP) CSI-RS may be associated with UE-initiated reporting, where the UE 105 may evaluate the triggering condition. Once met, the UE may initiate reporting. For example, L1-RSRP may be supported as a measurement quantity on SSB and periodic CSI-RS for beam management. In some embodiments, a combination of aperiodic (AP-) CSI-RS and UE-initiated reporting may not be supported, and existing legacy signaling supporting AP-CSI-RS and AP-CSI reporting may be used. In some embodiments, instead of AP-CSI-RS and AP-CSI reporting combinations, AP-CSI-RS and UE-initiated reporting may be supported, where the UE 105 may not report any quantity unless one or more of the triggering conditions discussed above are met or unless any other conditions are met, which may save power by reducing (e.g., avoiding) the risk of sending unnecessary reports.

[0143] In legacy NR, the UE indicates to the gNB via capability signaling (e.g., simultaneousCSI-ReportsPerCC and simultaneousCSI-ReportsAllCC) the total number of available computational processing units (CPUs) of the UE within a component carrier (CC) and across all CCs. The duration that the CPU is occupied may depend on whether the reporting is periodic, semi-persistent, or aperiodic. In some embodiments, based on the introduction of a new amount of UE-initiated reporting, and in order to avoid increasing UE complexity, a definition may be provided as to how much CPU is occupied (e.g., indicated by the UE 105 or provided by the standard). As used herein, unless otherwise specified, "CPU" refers to a computational processing unit of the UE.

[0144] In some embodiments, a traditional CPU pool may be used for UE-initiated reports. Since the network node 110 may not know whether the UE 105 can send a report, from a CPU occupancy perspective, the UE-initiated report may be treated similarly to a CSI report with a CSI-ReportConfig, where the high-level parameter reportQuantity is set to "None". In other words, a beam report may occupy the same CPU as a channel state information (CSI) report with a reporting quantity of "None", and a beam report may occupy the same CPU for the same duration as a CSI report with a reporting quantity of "None". For example, the CPU may be occupied starting from the first or last symbol of a periodic RS (e.g., the earliest one of a periodic RS or a semi-persistent RS) for detecting beam degradation for a duration (e.g., a duration) or for identifying other candidate beams. The duration may be predefined. For example, the duration may be provided by a standard (e.g., in a 3GPP specification), indicated to the network node 110 by UE capability signaling, or may be equal to Z'3, Z3, or a function of Z'3, Z3 (e.g., max(Z'3, Z3)), where Z'3, Z3 are used to define the processing time of CSI reports for beam management in legacy NR (e.g., reportQuantity is set to "cri-RSRP", "ssb-Index-RSRP", etc.). The duration may also be equal to Z1, Z'1, or a function of Z1, Z'1 (e.g., max(Z'1, Z1)), where Z'1, Z1 are used to define the processing time of CSI reports for beam management based on SINR reports in legacy NR (e.g., reportQuantity is set to "cri-SINR", "ssb-Index-SINR", etc.).

[0145] Figure 8 is a diagram depicting an example of CPU occupancy of a periodic RS for detecting degradation of a currently used beam according to some embodiments of the present disclosure.

[0146] refer to Figure 8 , the CPU is occupied Z'3 symbols from the first or last symbol of each transmission opportunity of the RS (e.g., the first, second, and third instances of the RS). For example, the CPU of the UE 105 may be occupied for a first duration D1 corresponding to the first instance of the RS, a second duration D2 corresponding to the second instance of the RS, and a third duration D3 corresponding to the third instance of the RS. In some embodiments, the possible reporting opportunity 80 may occur after the first instance of the RS and / or after the third instance. The UE 105 may or may not use a given possible reporting opportunity 80.

[0147] In some embodiments, if a combination of aperiodic CSI-RS and UE-initiated reporting is supported, the occupied CPU may be defined relative to the channel that triggers the DCI and relative to the channel that carries the request (e.g., report) from the UE 105 to the network node 110. Channel requests (e.g., channel reports) and their contents are discussed in further detail below.

[0148] Fig. 9 is a diagram depicting an example of CPU occupancy for PDCCH triggered UE initiated reporting for aperiodic RS according to some embodiments of the present disclosure.

[0149] refer to Fig. 9 In some embodiments, the CPU may be configured to receive a maximum of 10000 ... 3 ,Z 3 ) (e.g., duration D) is occupied. Because the report is a non-periodic report, the CPU occupation starts from triggering the DCI, not from the RS itself. The possible reporting opportunity 80 that the UE 105 may or may not use may correspond to the end of the duration D.

[0150] In some embodiments, the number of occupied CPUs may be one, regardless of the number of RSs configured to evaluate the current beam (or multiple) and / or evaluate the new beam. In some embodiments, the number of occupied CPUs may be a function of the number of RSs configured to evaluate the current beam (or multiple) and / or evaluate the new beam. For example, the number of occupied CPUs may be equal to the number of RSs configured to evaluate the current beam and / or evaluate the new beam.

[0151] In some embodiments, similar to the CPU concept in CSI reporting, the UE 105 may indicate its ability to support multiple simultaneous computations corresponding to UE-initiated reports through the processing unit (PU) occupancy in the component carrier and across all component carriers. For example, the UE may not be expected to be configured with a number of report settings greater than its reported processing unit capability. In some embodiments, the traditional N-bits may be shared between CSI reporting and UE-initiated reporting. CPU This may include some additional signaling in the legacy capabilities of signaling about the UE's occupancy of processing units reserved for such UE-initiated reports.

[0152] In some embodiments, a new capability may be specifically defined (e.g., may be used) for processing unit occupancy for UE-initiated reporting. The number of PUs occupied for such reporting may be defined as a function of the number of DL RSs requested by the UE 105 to be sent for such reporting for measurement.

[0153] In legacy NR, the UE is able to indicate to the gNB via capability signaling additional information about the maximum number of simultaneous "active" CSI-RS and CSI-RS ports per CC that the UE is able to handle. For example, via maxNumberSimultaneousNZP-CSI-RS-PerCC and totalNumberPortsSimultaneousNZP-CSI-RS-PerCC. The definition of when a CSI-RS is considered active varies depending on its nature as follows.

[0154] For A-CSI-RS, the CSI-RS is considered active starting from the end of the PDCCH containing the request and ending at the end of the Physical Uplink Shared Channel (PUSCH) containing the report associated with the A-CSI-RS. For SP-CSI-RS, the CSI-RS is considered active starting from the end of the activation command being applied and ending at the end of the deactivation command being applied. For P-CSI-RS, the activation duration starts when the P-CSI-RS is configured and ends when the P-CSI-RS configuration is released.

[0155] In some embodiments, the CSI-RS resources and / or ports used for detecting beam degradation in UE-initiated beam management reporting may be counted towards the maximum number of active CSI-RS resources and ports per CC or across all CCs for traditional CSI reporting as indicated by UE capability signaling.

[0156] In some embodiments, for PC CSI-RS and / or SP CSI-RS used to detect beam degradation, the determination of active CSI-RS resources and / or ports may follow conventional definitions that do not depend on the reporting type. For example, the determination of active CSI-RS resources and / or ports may depend on when the PC CSI-RS and / or SP CSI-RS are activated (e.g., configured) and deactivated (e.g., released).

[0157] In some embodiments, if a combination of aperiodic (AP) CSI-RS and UE-initiated reporting is supported, it may be interesting to define an activity period in this case because the UE may not send reports. In some embodiments, the traditional definition of the activity period for an aperiodic CSI-RS for traditional CSI reporting may be followed, differing from the traditional definition in that the channel carrying the UE-initiated reports may be different from the PUSCH, as discussed in further detail below. In such embodiments, the definition may be modified as follows. For an aperiodic CSI-RS used to detect beam degradation or identify other candidate beams, the activity duration may start at the end of the PDCCH containing the request and may end at the end of the scheduling channel containing the request (e.g., report) associated with the aperiodic CSI-RS, regardless of whether the UE sends a request (e.g., report).

[0158] In some embodiments, the activation duration of the aperiodic CSI-RS used to detect beam degradation or identify other candidate beams can be decoupled from its reporting, as the UE 105 can depend on the triggering condition and not transmit. In such an embodiment, the active duration for the CSI-RS can be defined relative to the triggering PDCCH and CSI-RS. For example, the active duration can be max(Z'3, Z3), where Z3 starts from the first or last symbol of the triggering PDCCH and Z'3 starts from the first or last symbol of the aperiodic CSI-RS.

[0159] In terms of processing timeline, in some embodiments, even if UE 105 decides not to transmit because the triggering conditions are not met, the traditional definition of CSI reference resources Z and Z' can be applied based on the assumption that UE 105 sends a request (eg, a report).

[0160] It should be understood that the values ​​(e.g., traditional values) of Z1, Z2, Z3, Z'1, Z'2, and Z'3 (Z1, Z3, Z'1, and Z'3 discussed above) are examples for determining the duration of CPU occupancy, active resources, or processing timeline. However, the present disclosure is not limited to this. For example, in some embodiments, the UE 105 may indicate to the network node 110 via capability signaling that the values ​​(e.g., new values) may be different from the traditional values ​​of Z1, Z2, Z3, Z'1, Z'2, and Z'3.

[0161] In some embodiments, the UE 105 may use HARQ information for a threshold to evaluate the quality of the currently used beam (e.g., to determine whether a triggering event has occurred). In such an embodiment, the network node 110 may not need to configure a dedicated RS for evaluating the currently used beam and identifying candidate beams. For example, the network node 110 may configure the threshold via high-layer signaling (e.g., via RRC). In some embodiments, the threshold may be predefined (e.g., may be provided in a 3GPP specification). In some embodiments, the threshold may be a percentage of the HARQ-ACK value corresponding to the PDSCH in a particular window. For example, if the HARQ-ACK values ​​of 80% of the PDSCHs within the window are determined to be NACK, the UE 105 may assume that a triggering event has occurred and proceed to the next operation in the process.

[0162] In some embodiments, the window may start at (or after) n time slots (e.g., n symbols) or other time units (e.g., milliseconds (ms)) before a time slot (e.g., symbol) carrying an uplink (UL) channel that carries a potential request (e.g., report) for a UE-initiated beam management procedure. For example, the potential reporting opportunity 80 may be determined based on a given time period that has passed. In some embodiments, the window may end at m time slots (e.g., m symbols) before a time slot (e.g., symbol) carrying an UL channel with a potential request (e.g., report) for a UE-initiated beam management procedure. In some embodiments, the UE 105 may expect to have sufficient processing time to decode the PDSCH(s) within the window to make a decision as to whether to send a request (e.g., report) to the network node 110. For example, if the UL channel carrying the request (e.g., report) is in symbol L, the window (e.g., the last PDSCH in the window) may be at least T before the beginning of symbol L and its cyclic prefix (CP). proc,1 End at, where T proc,1 Indicates the amount of time (e.g., time span) that the UE 105 takes to process the received PDSCH. In some embodiments, the network node 110 may provide the value of n or m to the UE 105 via higher layer signaling (e.g., RRC). In some embodiments, the value of n or m may be predefined (e.g., provided in a 3GPP specification or set to another value, such as m=T proc,1 ). In some embodiments, the UE 105 may indicate to the network node 110 the minimum and / or maximum values ​​of n or m that the UE 105 may support.

[0163] Fig.10 is a diagram depicting an example of a UL channel for carrying potential requests (eg, potential reports) according to some embodiments of the present disclosure.

[0164] refer to Fig.10 , the PDSCH (e.g., PD5) in slot #0 (e.g., SL0) in subframe #3 (e.g., SF3) is not included in window W because UE 105 may not have enough time to decode it before the transmission opportunity of the UL channel carrying the potential request (e.g., potential report). In some embodiments, UE 105 may count the number of ACKs or NACKs corresponding to the PDSCH within window W to determine whether a triggering event has occurred.

[0165] Aspects of embodiments involving UL channels and multiple PDSCHs for determining whether a triggering event has occurred are discussed in further detail below.

[0166] In some embodiments, additional conditions may be applied to determine whether a HARQ-ACK corresponding to a PDSCH can contribute to evaluating a trigger condition, even if the PDSCH falls within a time window dedicated to such calculations.In some embodiments, any combination of the following conditions may be applied.

[0167] In some embodiments, determining whether the HARQ-ACK corresponding to the PDSCH can contribute to the evaluation of the triggering condition can be based on whether the PDSCH is a dynamic PDSCH or a semi-persistent scheduling (SPS) PDSCH. For example, only the dynamic PDSCH within the window can contribute to the evaluation of the condition. In some embodiments, determining which of the dynamic PDSCH or SPS PDSCH to use can be configured by high-level signaling or can be predefined (e.g., can be provided in the 3GPP specification).

[0168] In some embodiments, determining whether the HARQ-ACK corresponding to the PDSCH can contribute to the evaluation of the trigger condition can be based on the beam used to send the PDSCH. For example, the UE 105 can determine the beam (or TCI state) used for most PDSCHs within the scheduling window. The UE 105 can use the HARQ-ACK corresponding to the PDSCH associated with the identified beam (or identified TCI state) to evaluate the trigger condition, and can exclude other PDSCHs associated with different beams (or different TCI states). In some embodiments, other rules (e.g., additional rules) can be applied. For example, the network node 110 can indicate the beam (or TCI state) to which the corresponding PDSCH can contribute in the evaluation of the trigger condition. The indication can be configured via high-level signaling (e.g., via RRC, media access control-control element (MAC-CE), or dynamically via downlink control information (DCI)).

[0169] In some embodiments, determining whether a HARQ-ACK corresponding to a PDSCH can contribute to evaluating a trigger condition can be based on a priority level. For example, the UE 105 can use a PDSCH belonging to a certain priority level (e.g., a low priority level or a high priority level) to evaluate whether the trigger condition is met. The priority level can be configured by high-level signaling (e.g., by RRC) or predefined (e.g., provided in a 3GPP specification).

[0170] In summary, in some embodiments, the measurements and conditions used to determine whether a triggering event has occurred can be based on monitoring the degraded beam by directly measuring the RSRP, RSRQ or SINR associated with the beam or by the HARQ statistics of the associated PDSCH. In some embodiments (e.g., in some special scenarios), beam switching can be based on other metrics that are not directly associated with the beam.

[0171] For example, in some embodiments, the network node 110 may perform beam management based on the location of the UE 105 (e.g., including indoor factory environments, high-speed trains, or certain geostationary orbit (GEO) non-terrestrial network (NTN) deployments). In some embodiments, the event may be triggered by the location of the UE 105, wherein the location of the UE 105 may be obtained by the UE 105 based on an NR positioning method. In some embodiments, the location of the UE 105 may be obtained by the UE 105 based on methods other than 3GPP signaling (e.g., based on a global navigation satellite system (GNSS)).

[0172] In some embodiments, a location-triggered event may be based on one or two location measurements M11 / M12 and one or two location thresholds Los. Thresh1 / Los Thresh2 and the associated hysteresis.

[0173] For example, the trigger condition is based on a single threshold, where M11 may be a function of the distance between the UE 105 and the reference location 1, as in the following formula (2.08):

[0174] Ml1-Hys1>Los Thresh1

[0175] A trigger condition based on two thresholds, where M11 may be a function of the distance between the UE 105 and a reference location 1, and where M12 may be a function of the distance between the UE 105 and a reference location 2:

[0176] Ml1-Hys1>Los Thresh1

[0177] Ml2+Hys1>Los Thresh2

[0178] The moving direction and speed of UE 105 may be a byproduct of information from a location service such as GNSS. In some embodiments, the moving direction and speed of UE 105 may be used as a condition or additional condition for triggering an event.

[0179] In some embodiments, a built-in micro-electromechanical system (MEMS) of the UE 105, which may perform gyroscope-like functions and may provide good accuracy of UE rotation angle information, may include (eg, may generate) metrics that may be used to trigger beam switching for certain scenarios.

[0180] III. Sending Request

[0181] Once an event is triggered according to method 1 or method 2 (eg, once a triggering event has occurred), the UE 105 may send a report or request to the network node 110 (see Figure 3 Operation 3005 and Figure 4 Operation 4004). As used herein, the terms "report" and "request" are used interchangeably unless otherwise specified.

[0182] In some embodiments, although the report can be initiated by UE 1 05, as shown in Table 1 above, possible opportunities for carrying such a request (e.g., carrying such a report) may include (e.g., may be) periodic opportunities or semi-persistent opportunities, and if the triggering condition is not met, the UE may not use the opportunity.

[0183] In some embodiments, as discussed above, a new reporting quantity may be introduced. For example, the new reporting quantity may be referred to as "UE initiated reporting". A UE initiated reporting may indicate that the UE may send a request (or report) when a trigger condition is met. In some embodiments, based on reportQuantity being set to UE initiated reporting, the information to be reported may be any combination of the following.

[0184] In some embodiments, the reporting information (e.g., reporting information) may include an indication of the degradation of the currently used beam, the preferred TCI state or the preferred beam, RSRP, SINR, RSSI, etc. In some embodiments, the network node 110 may additionally indicate the reporting amount via high-layer signaling, such as UE-initiated-report-degardationIndication, UE-initiated-report-preferredTCI, UE-initiated-report-cri-RSRP, UE-initiated-report-ssb-RSRP, etc. For example, DL RS resource indicator and LR-RSRP may be supported. In some embodiments, the information to be reported may be predefined (e.g., provided in a 3GPP specification). In some embodiments, the UE 105 may indicate to the network node 110 via UE capability signaling which reporting method (e.g., which reporting combination) is supported by the UE 105.

[0185] In some embodiments, based on the RS sent by the network node 110 for evaluating the currently used beam and the candidate beam, as in method 1 (see Figure 3 , operation 3003), any of the following containers discussed below (in subsections AF) may be used to carry any made request (or report) to the network node 110.

[0186] A. Using PRACH as a container

[0187] In some embodiments, the UE 105 may use a physical random access channel (PRACH) to indicate that the quality of a currently used beam has degraded and / or to inform the network node 110 of candidate beams for replacing the currently used beam.

[0188] In some embodiments, to indicate that the quality of the currently used beam has degraded (e.g., the measured RSRP has become less than a threshold), the UE 105 may send a contention-free random access (CFRA). In some embodiments, the network node 110 may provide the UE 105 with one or more RACH opportunity (RO) IDs (e.g., identifiers or identifications) that can be used. In some embodiments, the network node 110 may indicate to the UE 104 which preamble index to use. In some embodiments, the network node 110 may provide such information to the UE 105 via high-layer signaling. For example, the high-layer signaling may include RRC, such as ra-occionlist-beam-degeration and preambleIndex-beam-degeration, which may be selected from the configured RO and preamble. In some embodiments, when the beam used (e.g., the currently used beam) changes, the same RO and / or preamble index may be used. For example, the network node 110 may dedicate the RO and / or preamble index to indicate the degradation of the currently used beam. For example, in the unified TCI state framework, the currently used beam may be defined as the beam used as indicated by the unified TCI state framework. In other words, the currently used beam may be determined as the beam indicated by the unified TCI state framework. Even if the network node 110 changes the beam, the same RO and / or preamble index may be used. For example, the "current beam" may be the beam corresponding to the indicated TCI state.

[0189] In some embodiments, different beams (or TCI states) may be associated with different ROs or preamble indices that the UE 105 may use to indicate to the network node 110 that the corresponding beam (or TCI state) has been downgraded.

[0190] Fig.11 is a diagram illustrating the use of CFRA to send an indication from the UE 105 to the network node 110 that the quality of a currently used beam has degraded according to some embodiments of the present disclosure.

[0191] refer to Fig.11, the network node 110 may configure two TCI states (e.g., TC0 and TC1) to be used in a unified TCI state framework, and may associate the TCI state with a specific RO to be used for PRACH transmission when the quality of a currently used beam deteriorates (operation 11001). TCI state #0 (e.g., TC0) is associated with RO-0 and RO-1, while TCI state #1 (e.g., TC1) is associated with RO-2 and RO-3. When TC0 is indicated via the unified TCI state framework (operation 11002), and the quality of the corresponding beam degrades, the UE may select RO-1 to send a PRACH indicating that a trigger condition is met (operation 11003). When the network node 110 switches to TC1 (operation 11004) and when the quality of the associated beam degrades, the UE 105 may use RO-2 to send a PRACH indicating that the trigger condition is met and that the beam quality has degraded (operation 11005).

[0192] In some embodiments, to establish such an association between a TCI state and a RO for PRACH transmission, the network node 110 may include, as part of a TCI state configuration or RS configuration used as a source quasi co-location (QCL) for any TCI state, a RO index or preamble index that the UE 105 may use when beam quality degrades. The association between a TCI state (or beam) and a RO index or preamble index may be one-to-one, one-to-many, or many-to-one.

[0193] In some embodiments, the UE 105 may indicate to the network node 110 a preferred candidate beam (or TCI state), not just that the currently used beam (or TCI state) has been degraded.

[0194] Fig.12 is a diagram illustrating an example of sending an indication of a preferred beam (or TCI state) from the UE 105 to the network node 110 using CFRA when a currently used beam is degraded according to some embodiments of the present disclosure.

[0195] refer to Fig.12In some embodiments, the UE 105 may indicate a preferred TCI state (or beam) to the network node 110, rather than merely indicating that the currently used beam has been downgraded. In such an embodiment, the RO may be associated with the TCI state, and TCI state #3 (e.g., TC3) may be associated with both RO-2 and RO-3 (e.g., a one-to-many association) (operation 12001). When an event is triggered (e.g., when the currently used beam (e.g., TC0) corresponding to TCI state #0 triggers a condition) (operation 12002), the UE 105 may indicate a preferred beam (e.g., TC1) corresponding to TCI state #1 by sending a PRACH in RO-1 (operation 12003). Later, the UE may indicate a beam corresponding to TC3 by sending a PRACH in RO-2 (operation 12004).

[0196] In some embodiments, contention-based random access (CBRA) may be used instead of CFRA. In such an embodiment, a new MAC-CE may be introduced to indicate degradation of a currently used beam or to indicate a preferred beam (or TCI state). The new MAC-CE may be sent in Msg3 or MsgA. The new MAC-CE may directly carry an index of a preferred TCI state or a preferred RS ID that may be used as a QCL source RS, and the UE 105 may indicate a preferred TCI state or a preferred RS by, for example, indicating their IDs. In some embodiments, the MAC-CE may include (e.g., may be) a bitmap in which each bit corresponds to a configured TCI state or to a configured RS ID that may be used as a QCL source RS, and the UE 105 may indicate a preferred TCI state or a preferred RS, for example, by setting the corresponding bit to one. In some embodiments, the MAC-CE may be used to provide some measurements that the UE 105 performs to evaluate trigger conditions, such as L1-RSRP, L1-SINR, RSSI, etc. The reporting of these quantities is discussed in further detail below.

[0197] B. Use PUCCH carrying SR as a container

[0198] In some embodiments, a scheduling request (SR) may be sent from the UE 105 to the network node 110 via a physical uplink control channel (PUCCH) to indicate a degradation of a currently used beam and / or to indicate a preferred TCI state (or preferred beam). For example, the associated method discussed above for using PRACH as a container may be extended to using PUCCH carrying SR as a container. In some embodiments, if the UE 105 only indicates degradation of a currently used beam, the network node 110 may associate the TCI state or the RS used as a QCL source with a scheduling request configuration to be used by the UE 105 when the quality of the corresponding beam degrades. For example, as part of the configuration of the TCI state or RS, the network node 110 may include SchedulingRequestId-beamDegradation pointing to a specific scheduling request configuration.

[0199] In some embodiments, the UE 105 may indicate to the network node 110 a preferred candidate beam (or preferred candidate TCI state) instead of just indicating that the currently used beam (or currently used TCI) has been degraded. In this case, the network node 110 may associate the TCI state or the RS used as the QCL source with the scheduling request configuration to be used when the UE selects the preferred TCI state or RS ID. For example, as part of the configuration of the TCI state or as part of the configuration of the RS, the network node 110 may include SchedulingRequestId-beamDegradation pointing to a specific scheduling request configuration.

[0200] In some embodiments, similar to the CBRA discussed above, the UE 105 may send an SR to obtain a grant for the PUSCH, wherein a new MAC-CE or piggyback uplink control information (UCI) may be sent to indicate degradation of the currently used beam and / or to indicate a preferred beam (or preferred TCI state). As used herein, "piggyback UCI" refers to a UCI that may be used to carry a report and sent on the PUSCH instead of the PUCCH. In some embodiments, the MAC-CE or piggyback UCI may directly carry an index of a preferred TCI state or an RS ID that may be used as a QCL source RS, and the UE 105 may indicate a preferred TCI state or a preferred RS by indicating their IDs. In some embodiments, the MAC-CE or piggyback UCI may include (e.g., may be) a bitmap, wherein each bit corresponds to a configured TCI state or an RSID that may be used as a QCL source RS, and the UE 105 may indicate a preferred TCI state or a preferred RS by, for example, setting the corresponding special bit to one. In some embodiments, the MAC-CE or piggyback UCI may be used to provide some measurements that the UE 105 makes to evaluate trigger conditions, such as L1-RSRP, L1-SINR, RSSI, etc. Reporting of these quantities is discussed in further detail below.

[0201] Fig.13 is a diagram depicting a modification of a cyclic shift (CS) in a PUCCH format for reporting UEI-BM information according to some embodiments of the present disclosure.

[0202] In some embodiments, the UE 105 may send a report (e.g., UEI-BM information) to the network node 110 via SR based on the repurposed PUCCH format (PF). For example, in some embodiments, PF0 and PF1 may be repurposed by allowing a greater number of bits to be transmitted.

[0203] refer to Fig.13 In some embodiments, in the case of PF0, 12 CSs can be used to transmit up to two bits (e.g., b0 and b1) and to multiplex signals from up to three different UEs (e.g., UE 1, UE 2, and UE 3). Fig.13 In some embodiments, the network node 110 may configure the UE 105 with SR resources for UE-initiated beam reporting (e.g., Fig.13One or more of the resources R1 to R12 in the SR (e.g., SR resources dedicated to UE-initiated beam reporting). In some embodiments, the SR resources can be used to send up to three bits. The mapping between bits and CS values ​​can be specified by a standard (e.g., in a 3GPP specification). In such an embodiment, the SR resources can be repurposed (e.g., modified) so that one or more SR resources are not used to multiplex different UEs and / or are not used to multiplex HARQ-ACK and SR for the same UE. Conversely, in such an embodiment, one or more SR resources (e.g., R1, R2 and / or R3) can be dedicated to UE-initiated beam reporting. The information conveyed by the bits in the SR can be similar to the information discussed above for indicating a degradation of a currently used beam and / or indicating a preferred TCI state (or preferred beam).

[0204] In some embodiments, a similar method may be used to send up to two bits in an SR resource with a PUCCH format to send two information bits. For example, an SR resource with PF1 may be configured for the purpose of UE-initiated beam reporting and may be used to send two bits to the network node 110. The information conveyed by the two bits may be similar to the information discussed above for indicating a degradation of a currently used beam and / or indicating a preferred TCI state (or preferred beam).

[0205] In addition, in some embodiments, some SR resources may be used to indicate which event is triggered when multiple events are configured. For example, when multiple triggering events are configured for continuing UEI BM, one or more SR resources may be used to indicate which triggering events have occurred.

[0206] C. Use PUCCH or PUSCH carrying UCI as a container

[0207] In some embodiments, the PUCCH or PUSCH carrying UCI may be used as a container. In such embodiments, the PUCCH or PUSCH carrying a request (e.g., report) from the UE 105 may be configured similar to traditional periodic CSI or semi-persistent CSI reporting on the PUCCH or PUSCH. In some embodiments, the PUSCH may be similar to one of the timings for a configured grant PUSCH type 1 or 2. In some embodiments, the PUSCH may be a PUSCH scheduled by an uplink grant. As discussed above, the UE 105 may use only PUCCH timings, or may use only PUSCH timings, when the triggering conditions are met.

[0208] In some embodiments, a single bit may be used to indicate degradation of a currently used beam (eg, a beam indicated via the unified TCI status framework).

[0209] In some embodiments, to indicate a preferred TCI state, a bitmap having the length of an activated TCI state may be used, wherein each bit corresponds to a specific TCI state. For example, the most significant bit (MSB) (e.g., the first MSB) may be mapped to a TCI state that is mapped to the lowest code point in the TCI field in the scheduling DCI or activation DCI; the second MSB may be mapped to a TCI state that is mapped to the second lowest code point in the TCI field in the scheduling DCI or activation DCI; and so on. The size (e.g., length) of the bitmap may be equal to the number of activated TCI states, or may be equal to the size of the TCI field in the scheduling DCI or activation DCI, as depicted in Table 2 below. Although the example of Table 2 depicts the bitmap method as being applied to an activated TCI state, in some embodiments, the bitmap method may be applied to all configured TCI states. In such an embodiment, the first MSB may be mapped to the TCI state with the lowest ID, the second MSB may be mapped to the TCI state with the second lowest ID, and so on. In such an embodiment, the size (e.g., length) of the bitmap may be equal to the number of configured TCI states. This approach may be beneficial in allowing the UE 105 to indicate multiple preferred TCI states.

[0210] Table 2: Mapping of UCI bitmap to activated TCI states:

[0211]

[0212] In some embodiments, to indicate the preferred TCI state ID, the UCI may carry an index (or multiple indices) of the preferred TCI state. For example, a field of the UCI may indicate an absolute index of the TCI state. For example, in some embodiments, if the network node 110 configures N TCI states (N is an integer greater than zero), the size of the field may be log 2 (N) (e.g., the base-two logarithm of N). In some embodiments, the field may indicate a relative index of a TCI state within a set of activated TCI states. For example, if the number of activated TCI states mapped to distinct code points in a TCI field in a scheduling DCI or an activation DCI is M (M is an integer greater than zero), the size (e.g., length) of the field may be log(N). 2 (M) (e.g., the base 2 logarithm of M).

[0213] In some embodiments, in order to provide more flexibility to the network node 110, the UE 105 can use traditional beam reporting to indicate RSRP, SINR, RSSI, etc. (e.g., when reportQuantity is set to cri-RSRP, ssb-Index-RSRP, etc.). For example, when the trigger condition is met, the UE 105 can report differential RSRP or differential SINR and the corresponding resource ID. In some embodiments, similar to the traditional method, the RSRP or SINR of the best beam (e.g., the strongest beam) can be defined by seven bits, and the differential report relative to the best beam can be defined by four bits.

[0214] In some embodiments, with respect to the overhead of such UE-initiated reporting, and based on the metrics included in the report, some alphabets may be defined for amplitude and phase quantization. In some embodiments, quantization may be provided differentially for amplitude relative to a reference amplitude, and a separate indicator may be used to determine the DLRS corresponding to the reference amplitude. In some embodiments, some reporting metrics (e.g., some reporting parameters) may be based only on quantized amplitude reporting, while some other metrics may be based on quantized phase reporting in addition to quantized amplitude reporting. In some embodiments, the granularity of phase quantization and amplitude quantization may be the same. In some embodiments, the granularity of phase quantization and amplitude quantization may be defined separately for each reported quantity.

[0215] In some embodiments, when MAC-CE is used for reporting, the solutions discussed above may also be applied.

[0216] In some embodiments, the UE 105 may be configured with a single event or multiple events associated with different reporting amounts and / or report sizes. Similar to the aforementioned triggering events, an event (e.g., a triggering event for a report) may include an indication that the quality of the currently used beam has degraded (e.g., the measured RSRP has fallen below a certain threshold). In some embodiments, the report may include only a single bit. In some embodiments, the report may include some measurements associated with the beam, such as the corresponding RSRP. In some embodiments, the report may include only seven bits representing the absolute RSRP value of the beam (e.g., a degraded beam).

[0217] In some embodiments, the triggering event may be that the new beam becomes better than the current beam (e.g., the new beam may become better than the current beam by a certain threshold). In such an embodiment, the report may include only a single bit indicating that the event has occurred. In some embodiments, the report may include multiple measurements, such as measurements of the new beam (or multiple new beams) and / or measurements of the currently used beam. For example, an absolute value measurement of the currently used beam (e.g., RSRP) and one or more differential measurements of the new beam (or multiple beams) (e.g., RSRP measurements) may be reported to give an accurate measurement of the quality of the currently used beam. In some embodiments, the UE 105 may report an absolute value measurement of the best new beam (e.g., RSRP) and one or more differential measurements (e.g., RSRP) of the current beam and one or more other new beams that are not the best new beam (e.g., one or more remaining beams).

[0218] In some embodiments, the beam ID may be included in the report. In some embodiments, the report may include report information that may be used to derive the beam ID according to certain rules, which will be discussed in further detail below.

[0219] In some embodiments, a similar kind of reporting may occur if an event (e.g., a triggering event) is defined as the quality of a new beam becoming better than a certain threshold. In such embodiments, the report may include only a single bit indicating that the event has occurred. In some embodiments, the index of the new beam (or multiple new beams) and / or its corresponding measurements may be reported.

[0220] In some embodiments, the current beam may be implicitly determined for the events discussed above, or for any other suitable event. For example, in some embodiments, the current beam may be a beam indicated by a unified TCI state framework. For example, the RS of the current beam may be implicitly derived from the QCL RS of the indicated TCI state. In some embodiments, among the configured TCI states or the activated TCI states, the current beam may be the beam associated with the lowest TCI or with the highest TCI. In some embodiments, the current beam may be a beam determined by the QCL assumption of the control resource set (CORESET) with the lowest ID.

[0221] In some embodiments, the new beam may be determined implicitly. For example, in some embodiments, the new beam may be one of the beams associated with a configured TCI or with an activated TCI that is not a currently used beam. For example, under the unified TCI framework, if there are eight activated TCI states and the beam associated with the first activated TCI state is indicated as the currently used beam, the remaining beams associated with the remaining seven activated TCI states may be considered as candidate beams. In some embodiments, one or more beams associated with a TCI state other than the lowest TCI or the highest TCI may be implicitly determined as candidate beams when used to indicate the current beam. In some embodiments, the one or more new beams may include one or more beams other than the beam with the lowest ID determined by the QCL assumption for the CORESET (if the beam with the lowest ID is used to indicate the current beam).

[0222] In some embodiments, one or more current beams and one or more new beams may be explicitly indicated (e.g., may be explicitly configured). For example, in some embodiments, the network node 110 may configure two sets for RSs. The first set may include RSs associated with the current beam, and the second set may include RSs associated with the new beam. For example, the CSI-ResourceConfig for resourcesForChannelMeasurement linked to the CSI-ReportConfig for UE-initiated beam management may include two sets of RSs for the current beam (or multiple) and the new beam (or multiple). In some embodiments, a single set of RSs may be configured, wherein the current beam (or multiple) may be a specific beam (or multiple) in the set (e.g., the first beam may be the current beam, and the remaining beams may be considered to be new beams).

[0223] In some embodiments, if the reporting occasion is associated with a single event, both the UE 105 and the network node 110 may have a common understanding of the amount to be reported and the report size. For example, the report size may be fixed and associated with an event (e.g., a triggering event), as shown in Table 3.

[0224] Table 3: Size of UE initiated beam management report:

[0225]

[0226]

[0227]

[0228] In some embodiments, instead of using a predefined size for UE-initiated beam management reports, the network node 110 may indicate information as part of the event configuration such that the report size is fixed and known to both the UE 105 and the network node 110. For example, in event-2 (see Table 3 above), the network node 110 may indicate the number of new beams to be reported. For example, higher layer signaling, such as nrofReportedRS, may be repurposed to indicate the number of new beams to be reported, or new parameters may be used. For example, one or more beams may be reported in a reporting instance (e.g., N is greater than or equal to one beam), where at least one of the N reported beams meets the condition of event-2, and N is configured by the network node 110. The value of N may include {1, 2, 3, 4}.

[0229] In some embodiments, if a PUCCH opportunity or PUSCH opportunity carrying a possible UE-initiated beam management report is provided according to a semi-persistent CSI reporting framework or according to a configured authorized PUSCH type 1 or 2, and there are multiple events associated with the configuration, the activation DCI or MAC-CE may select one of the events. For example, if the CSI-ReportConfig for SP CSI reporting is linked to event 1 and event 2, the activation DCI or MAC-CE may select one from event 1 and event 2, or may select both event 1 and event 2. For example, if event 1 is selected, and when it is triggered, the report payload (e.g., report data) may include information based on event 1 and according to its predefined (e.g., configured) size. If both event 1 and event 2 are selected, when any one of them (e.g., when either one) is triggered, the report payload may include information based on the triggered event (or multiple) and according to its predefined (e.g., configured) size. Selecting both event 1 and event 2 may increase the burden on network node 110 because network node 110 may not know which event is triggered (e.g., may not have data indicating which event is triggered). In some embodiments, a new field may be introduced to indicate the event to be used. For example, if there are four events, two bits may be used to indicate the event to be used.

[0230] In some embodiments, if the reporting occasion is associated with multiple events or a single event where the payload (e.g., reporting data) can vary (e.g., reporting different numbers of beams and / or their corresponding measurements), blind decoding (e.g., blind decoding nature) at the network node 110 may increase because the network node 110 may not know which event is triggered (e.g., may not have data indicating which event is triggered). To address this issue, a concept similar to UCI Part 1 and UCI Part 2 in the CSI framework may be used. For example, in this framework, UCI Part 1 may have a fixed size and information may be provided to enable the network node 110 to determine the size of UCI Part 2. This two-part reporting concept can be applied to either of the first and second UL channels, as defined in Mode A and Mode B of operation and agreed upon in RAN1#116b, as shown below:

[0231] Agreement@RAN1#116b

[0232] In the beam report transmission procedure for UE-initiated / event-driven beam reporting, the following modes are supported:

[0233] Mode A (UCI is dynamically scheduled by gNB):

[0234] Step 1: UE sends a first PUCCH (one bit / multiple bits) to request resources for the second UL channel carrying beam report

[0235] FFS: Request format, such as SR or new UCI type.

[0236] • Step 2: The UE detects the DCI format to indicate the resources used for the second UL channel carrying the beam report.

[0237] Step 3: Send a beam report in the second UL channel.

[0238] FFS: Details about the second UL channel, for example, whether the second UL channel is PUCCH, PUSCH, or both

[0239] • This mode is a basic UE capability (i.e. all UEs supporting UE-initiated / event-driven beam reporting should support this feature).

[0240] No new DCI format is introduced.

[0241] Mode B (UCI in preconfigured resource(s) for the second UL channel):

[0242] Step 1: UE sends the first PUCCH (one bit / multiple bits) to notify the second UL channel to carry the beam report

[0243] FFS: Notification format, for example, SR or new UCI type.

[0244] Step 2: The UE sends a beam report in the second UL channel.

[0245] FFS: Details about the second UL channel, for example, whether the second UL channel is PUCCH, PUSCH, or both

[0246] The notification in step 1 is in a separate reporting instance from the beam reporting in step 2.

[0247] FFS: Whether the UE receives confirmation information in response to each step for all modes

[0248] For the above process, cross-CC beam reporting is supported for both modes.

[0249] FFS: Details.

[0250] Wherein, the first part of the UEI report with a fixed size is located in the first UL channel, and the second part of the UEI report with a variable size is located in the second UL channel. Alternatively, such two aforementioned parts of the report may both be located only in the second UL channel. The former may be applicable to the scenario where the first UL channel is multi-bit, and the latter may be applicable to the scenario where the first UL channel is only one bit.

[0251] In some embodiments, the first UL channel (e.g., PUCCH or CG-PUSCH) and the second UL channel (e.g., PUCCH or CG-PUSCH) may be separated by several symbols (e.g., one or more symbols) in the time domain. In some embodiments, the timing of the CG-PUSCH or the timing of the PUCCH may be used to send a beam report only when a trigger condition is met.

[0252] As discussed above, the UE may be configured with a single event or multiple events associated with different reporting amounts and / or reporting sizes. Similarly, the UE may be configured for UEI reporting on one CC or multiple CCs, where each CC has a different reporting amount and / or reporting size. In some embodiments (e.g., in all such scenarios), the network node 110 may have some ambiguity regarding the decoding of the UEI report in terms of the content and size of the report.

[0253] If the first PUCCH channel in step 1 of mode A only provides a one-bit indication to request resources for the second UL channel to carry the beam report, or the first PUCCH channel in step 1 of mode B only provides a one-bit indication to notify the second UL channel to carry the beam report, the beam report can include two parts in the second UL channel, wherein the first part can have a fixed size and can provide information to enable the network node 110 to determine the size of the second part.

[0254] For illustration, the first part may indicate that the second part carries UEI information associated with an event type (or multiple) (e.g., one or more triggering event types) and / or associated with a CC. For example, a bitmap structure may be used in the first part of the report to indicate that a report of an event type (or multiple) or CC (or multiple) will be carried in the second part of the report. Alternatively, the first part of the report may carry an index of the event type (or multiple) or associated CC to be reported in the second part of the report.

[0255] For example, in some embodiments, a bitmap of the size of events (including event type and / or CC) may be linked to reporting opportunities, where the most significant bit may correspond to the event with the lowest id (e.g., lowest ID), the second most significant bit may correspond to the event with the second lowest ID, and so on. In some embodiments, the size of the first part of the report may be log 2 (M), where M indicates the total number of events (including event type and / or CC) when only one event can be reported at each reporting opportunity. In some embodiments, the size of the first part of the report can be in, Indicates the combination of m among M when m events can be reported at each reporting occasion, where m=1, .., M. In some embodiments, when up to M' events are reported at each reporting occasion, the size of the first part of the report may be Among them, M′=1, .., M will be determined at UE 105.

[0256] In some embodiments, assuming that the report associated with each event (including event type and / or CC) is a fixed or preconfigured payload size, the first part of the report may additionally include at least one UEI report. Such specific report (or multiple) reported in the first part may be determined based on a predefined constant rule, based on a predefined priority rule, semi-statically configured to the UE 105, or dynamically indicated to the UE 105. In some embodiments, such dynamic indication to the UE 105 may be indicated as part of the DCI in step 2 of mode A of operation. In some embodiments, the rules may dictate that the event with the lowest ID may be included in the first part.

[0257] If the first PUCCH channel in step 1 of mode A provides a multi-bit indication to request resources for the second UL channel to carry the beam report, or the first PUCCH channel in step 1 of mode B provides a multi-bit indication to notify that the second UL channel carries the beam report, the first part of the beam report may be included in the first UL channel, as discussed above, and the second part of the beam report may be included in the second UL channel. The first part may have a fixed size and may provide information to enable the network node 110 to determine the size of the second part.

[0258] In some embodiments, for the case of multiple events (including event types and / or CCs) associated with the same reporting opportunity, UCI part 1 (e.g., the first part of a beam report) may indicate which events are reported. For example, a bitmap of sizes associated with (e.g., based on) events linked to the reporting opportunity (including event types and / or CCs) may indicate which events may be carried in UCI part 2 (e.g., the second part of a beam report). In some embodiments, the MSB (e.g., the first MSB) may correspond to the event with the lowest ID, the second MSB may correspond to the event with the second lowest ID, and so on. In some embodiments, assuming that the report associated with each event has a fixed (e.g., configured) payload size, the network node 110 may determine the size of UCI part 2. In some embodiments, UCI part 1 may carry an index of an event (or multiple events) to be reported in UCI part 2 (among all possible event types and / or CCs). In some embodiments, when only one event can be reported at each reporting opportunity, the size of UCI part 1 may be log 1. 2 (number of events) (e.g., the base 2 logarithm of the number of events), or, alternatively, may be in, Indicates the combination of m among M when m events can be reported at each reporting occasion, where m=1, .., M. In some embodiments, when up to M' events are reported at each reporting occasion, the size of UCI part 1 may be Where M′=1, .., M will be determined at UE 105.

[0259] In some embodiments, UCI part 1 may additionally include at least one UEI report, where the report associated with each event (including event type and / or CC) is of a fixed or preconfigured payload size. Such specific report(s) reported in UCI part 1 may be determined based on a predefined constant rule, determined based on a predefined priority rule, semi-statically configured to the UE 105, or dynamically indicated to the UE 105. For example, the event with the lowest ID or associated with the CC with the lowest ID may be included in UCI part 1.

[0260] In some embodiments, the order of UEI reporting of triggering events (including event type and / or CC) may be semi-statically configured or dynamically indicated to the UE 105. In some embodiments, the order of UEI reporting of triggering events (including event type and / or CC) may be determined based on a predefined constant rule, such as all CCs of event-2, all CCs of event-1, and all CCs of event-7, as in the following RAN1 protocol:

[0261] Agreement@RAN1#116b

[0262] On UE-initiated / event-driven beam reporting, regarding trigger event detection for beam reporting, at least Event-2 is supported: the quality of at least one new beam, such as L1-RSRP becomes better than the current beam reaching a threshold.

[0263] - At least L1-RSRP is supported as a quality metric for event-2

[0264] FFS: How L1-RSRP is used to determine trigger events (e.g. timers, counters, filter coefficients)

[0265] FFS: Whether the network controls how L1-RSRP is used to determine trigger events

[0266] - Regarding RS measurement for new beam for event-2, select one or more of the following items:

[0267] Option-3a (Explicit): RS(s) for the new beam(s) are explicitly configured by RRC (e.g., reusing the legacy configuration of RS measurements or in TCI-State) or MAC-CE

[0268] Option-3b (implicit way): RS(s) for new beam(s) are implicitly derived from the QCL RS(s) of the activated TCI state(s).

[0269] Option-3c (implicit way): RS(s) for new beam(s) are implicitly derived from the QCL RS(s) of the configured TCI state(s).

[0270] - Note-1: "New / Current Beam" is used for discussion purposes.

[0271] - NOTE-2: Other triggering events / quality metrics (eg, L1-SINR) are not excluded.

[0272] - Note-3: For the above implicit approach(es), if there are two QCL RSs in the TCI state, the measured RS is derived from the RS for QCL-TypeD, if applicable.

[0273] Working Assumption@RAN1#118

[0274] On UE-initiated / event-driven beam reporting, regarding triggering events, in addition to event-2, both event-1 and event-7 are supported.

[0275] - Event-1: The quality of the current beam is worse than a certain threshold.

[0276] - Event-7: The quality of at least one new beam, such as L1-RSRP, becomes better than the RS derived from the activated TCI state with the Mth best quality reaching a threshold.

[0277] • M is configured by RRC according to UE capability signaling ◆ The UE may indicate only a single candidate value or not support event-7.

[0278] - Additional supported events will reuse the same design as event 2 - unless consensus is reached otherwise

[0279] - Additional supported events will have lower priority compared to event 2.

[0280] In some embodiments, the predefined constant rule for the order of UEI reporting of triggered events may be (event-2, event-1, event-7) for the first CC, (event-2, event-1, event-7) for the second CC, etc. The above example may be extended to include any suitable order of event types and CC IDs.

[0281] In some embodiments, priority rules for events (including event types and / or CCs) may be specified. Such priorities may be established based on the content of the report. For example, in some embodiments, the priority may be based on: the total size of the report corresponding to each event type, the number of configured beams for each event (including event type and / or CC), whether the report also contains L1-RSRP measurements, and / or some priority CCs and cell IDs (e.g., first the serving cell ID, then additional PCIs with some predefined or configured rules (such as index order), etc.). In some embodiments, such a reporting order may be dynamically indicated to the UE 105 based on the size of the report, the given configured number of beams to be reported, and the available resources at the network node 110.

[0282] In some embodiments, when the same reporting opportunity 80 is associated with a single event with a variable payload (e.g., reporting a different number of beams and / or their corresponding measurements), UCI part 1 may indicate information about what data is to be reported in UCI part 2 to derive its size. For example, if event 2 (discussed above) is used and the quality of multiple new beams becomes better than the current beam, the UE 105 may indicate the number of beam indices and / or corresponding measurements to be reported in UCI part 2 to the network node 110 in UCI part 1. In some embodiments, the network node 110 may configure the UE 105 with a set of the number of beams that can be reported (e.g., a set such as {n1, n2, n3, n4}) via higher layer signaling. In such an embodiment, UCI part 1 may have two bits indicating the number of beams to be reported in UCI part 2 (e.g., the value of the two bits may be mapped to one of n1, n2, n3, or n4). In some embodiments, the possible number of beams to be reported may be determined based on the size of the determined (e.g., configured) set of new beams. For example, if the network node 110 configures eight new beams, the possible number of beams may be {n1, n2, n3, n4, n5, n6, n7, n8}, and UCI part 1 may have 3 bits to select one of these values. In some embodiments, other rules may be applied, such as half the size of the candidate beams. For example, the number of bits in UCI part 1 indicating the number of beams to be reported in UCI part 2 may be equal to (e.g., based on) the base 2 logarithm of the quotient of the number of new beams divided by 2 (e.g., ).

[0283] In some embodiments, an indication of a skipped PUCCH resource or a skipped PUSCH resource may be provided by the UE 105 to the network node 110. For example, if the UE 105 is in a condition where it uses PUCCH resources more frequently to send UE-initiated reports than it skips PUCCH resources, it may be beneficial for the UE 105 to indicate to the network node 110 that the next PUCCH opportunity is skipped rather than indicating that the next opportunity is used. In some embodiments, the UE 105 may declare a capability for such a feature. In some embodiments, the network node 110 may configure the UE 105 with SR resources for indicating a skipped opportunity. In such an embodiment, a positive SR may indicate to the network node 110 that the next PUCCH opportunity (or multiple) or PUSCH opportunity is skipped. In some embodiments, there may be a common understanding between the UE 105 and the network node 110 about which and how many of the next PUCCH opportunities or PUSCH opportunities are skipped. In some embodiments, information about which and how many of the next PUCCH opportunities or PUSCH opportunities are skipped may be established by defining a skip window. In some embodiments, the skip window may be a time T from the end of the SR PUCCH. skip (“skip time”) and may end after a certain duration, which may be configured by the network node 110 or fixed in a standard (e.g., a 3GPP specification). For example, the duration may include a specific number of time slots or a specific number of PUCCH opportunities. In some embodiments, the skip time T skip It may be configured by the network node 110 according to the number of orthogonal frequency division multiplexing (OFDM) symbols or time slots and the subcarrier spacing (SCS) of the PUCCH cell.

[0284] In some embodiments, to enable both skipping and indication of use, the UE 105 may indicate to the network node 110 via a single bit in the UCI which mode the UE 105 is in, indicating, for example, mode 1 or mode 2. In some embodiments, after a certain amount of time after transmitting the PUCCH carrying the UCI, the network node 110 may assume that future indications by the UE 105 may be provided according to the indicated mode. For example, in some embodiments, if the UE 105 indicates mode 1 to the network node 110, future indications via the SR may indicate one or more use opportunities. In some embodiments, if the UE 105 indicates mode 2 to the network node 110, future indications via the SR may indicate one or more skip opportunities. For example, a one-bit indication in the first PUCCH channel for notifying that the second UL channel carries a beam report may be supported.

[0285] In some embodiments, the indication of the used PUCCH opportunities or the skipped PUCCH opportunities may be accomplished using a single SR resource (e.g., PF0 or PF1) configured for this specific purpose. For example, in some embodiments, if PF0 is used to send two bits with certain CS values ​​to the network node 110, one CS may be used to indicate the used opportunities and another CS may be used to indicate the skipped opportunities.

[0286] In some embodiments, the indication of the skipped PUCCH opportunities or PUSCH opportunities may be implicit. For example, in some embodiments, when the UE 105 sends a UE-initiated report with or without a priori indication to the network node 110 using a periodic PUCCH opportunity or a periodic PUSCH opportunity, the next M PUCCH resources or the next M PUSCH opportunities or all PUCCH resources or all PUSCH opportunities within the time window may be skipped. In such an embodiment, the time window may be defined as from the end of the used PUCCH resources or from the beginning of the first PUCCH resource after the used resources. For example, in some embodiments, if the PUCCH periodicity is one slot and the UE 105 uses the PUCCH in slot 0 to send UE-initiated beam reports, then for M=2, the PUCCH opportunities in slots 1 and 2 may be skipped. The M value or attribute of the time window may be configured by the network node 110 according to the UE capabilities. Such an embodiment may be useful in an environment where the attributes of the best beam do not change rapidly in time and where the small periodicity of the PUCCH is configured to provide (e.g., to ensure) low reporting latency.

[0287] In some embodiments, an indication of unused PUCCH opportunities may be carried in the most recently transmitted PUCCH carrying a UE-initiated beam management report. For example, in some embodiments, a bitmap may be used to indicate whether a future PUCCH opportunity is used. The size of the bitmap may be fixed and may be referred to as N (e.g., N may be provided by higher layer signaling or predefined). In some embodiments, the bitmap may apply to N consecutive and valid PUCCHs starting from the end of the PUCCH carrying the indication. In some embodiments, the first MSB may correspond to the first valid PUCCH opportunity after the PUCCH carrying the indication, the second MSB may correspond to the second valid PUCCH opportunity after the PUCCH carrying the indication, and so on.

[0288] In some embodiments, a valid PUCCH opportunity may be defined as a PUCCH that does not collide with one or more DL symbols indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated or SSB.

[0289] In some embodiments, a PUCCH opportunity indicated by the UE 105 as unused may not be indicated as anything other than an unused PUCCH opportunity. In other words, in some embodiments, if the UE 105 indicates that a particular PUCCH opportunity is unused, the UE may also indicate that the particular PUCCH opportunity will remain unused.

[0290] In some embodiments, the bitmap indication may be carried in each transmitted PUCCH opportunity. In addition, in some embodiments, the bitmap indication may be carried in UCI part 1, since its size may be fixed and it may always be present.

[0291] In some embodiments, a bitmap may be carried in a second UCI part (e.g., in UCI part 2), where a potential indication in the UCI part is used to indicate whether the bitmap is present. This solution may be beneficial because it may enable the UE 105 to not carry a bitmap if the UE 105 cannot provide useful information to the network node 110. In other words, if the UE 105 cannot predict future PUCCH opportunities that are not used, then not including the bitmap may be beneficial. In such an embodiment, a single bit in UCI part 1 may indicate whether the bitmap is present or not.

[0292] In some embodiments, a joint indication of the timing of skipping and / or use and the UCI report size may be provided.

[0293] In some embodiments, if SR PUCCH or a newly defined dedicated PUCCH (still referred to as SRPUCCH in the following) is used to indicate to the network node 110 the future UE-initiated beam report PUCCH opportunities to be used or skipped, the UE 105 may additionally indicate to the network node 110 in the SR PUCCH information related to the payload size of the UE-initiated beam report PUCCH opportunity. For example, in some embodiments, the UE 105 may indicate in the SR PUCCH the event that is triggered and the beam report is initiated. In some embodiments, there may be a one-to-one mapping between an event (e.g., the type of event) and a report payload size. For example, some types of triggering events may result in a larger report payload size.

[0294] In some embodiments, because the amount of information that needs to be sent in the SR PUCCH may be greater than two bits, a new dedicated PUCCH may be configured for the UE 105 via RRC to transmit the above information (e.g., used or skipped future UE-initiated beam report PUCCH opportunities and information related to the payload size of the UE-initiated beam report PUCCH opportunities) to the network node 110. In some embodiments, the payload of such a PUCCH format may include (i) an indication of the used or skipped PUCCH opportunities (1 bit) and (ii) information related to the size of the UE-initiated beam report.

[0295] In some embodiments, the methods discussed in this subsection may be applied to periodic PUSCH resources (eg, Grant (CG) PUSCH of Type 1 or Type 2 configuration).

[0296] D. Use PUSCH as a container

[0297] In some embodiments, a PUSCH (e.g., a dynamic PUSCH or a CG PUSCH) may be used to carry the reports discussed above. For example, the UE 105 may use a CG PUSCH opportunity to carry a MAC-CE or piggyback UCI, which includes a report configured by the network node 110. To determine which CG PUSCH may be used, the network node 110 may indicate a CGPUSCH index to the UE 105 as part of the CSI reporting configuration. In some embodiments, the traditional timeline may be met except for the earliest CG PUSCH opportunity after the transmission of the associated RS.

[0298] E. Using RRC as a container

[0299] In some embodiments, similar to the methods discussed above, the RRC may carry a report indicating that the degradation of the currently used beam is equivalent to indicating that the currently used TCI state is not good enough (eg, not good enough for proper transmission and / or communication).

[0300] In some embodiments, different combinations of the channels discussed above (e.g., PUSCH and PUCCH) may be used to carry UE-initiated beam management reports. For example, the UE 105 may send an SR to obtain a dynamic PUSCH to carry UE-initiated beam management reports. In some embodiments, the UE 105 may send a PUCCH to indicate the timing of a CG PUSCH type 2 or another periodic / semi-persistent PUCCH to carry UE-initiated beam management reports.

[0301] In some embodiments, it is assumed that the network node 110 does not transmit an RS for evaluating the currently used beam and the potential candidate beam, or the network node 110 transmits an RS for evaluating the currently used beam but not for evaluating the potential candidate beam, which may be applicable to method 2 (see Figure 4 ), the network node 110 may send RS to evaluate the quality of the currently used beam or to identify candidate beams. Therefore, any one of the following containers may be used to carry any one of the requests (eg, reports) to the network node 110.

[0302] In some embodiments, the network node 110 may provide the UE 105 with a single or multiple CSI-ReportConfigs with reportQuantity set to the new report quantity: UE-initiated-report, UE-initiated-report-preferredTCI, UE-initiated-report-cri-RSRP, UE-initiated-report-ssb-RSRP, etc. In some embodiments, unlike conventional operations, some or all of the RSs associated with the report may not be sent. For example, in some embodiments, the network node 110 may not send the RSs associated with the currently used beam and the candidate beams. In some embodiments, the network node 110 may send the RSs associated with the currently used beam and the candidate beams, which may keep changing as the currently used beam changes. The currently used beam may be the beam indicated by the unified TCI status framework.

[0303] In some embodiments, the traditional CSI reporting configuration on PUCCH or PUSCH may be used based on the understanding (e.g., between UE 105 and network node 110) that UE 105 may use PUCCH or PUSCH opportunities when a trigger condition is met. Based on meeting the trigger condition, UE 105 may send a request to network node 110 to cause network node 110 to start sending RS.

[0304] Fig.14 is a diagram depicting a CSI reporting configuration for Method 2 according to some embodiments of the present disclosure.

[0305] refer to Fig.14In some embodiments, the network node 110 may configure a CSI report on a PUCCH or PUSCH, the CSI report being associated with a periodic RS or with a semi-persistent RS, and the report amount being set to a UE-initiated report (operation 14001). After a request is sent by the UE 105, the RS associated with the report may be sent by the network node 110 (operation 14002). The RS may be sent in the first opportunity of the RS after the request is sent by the UE 105 (operation 14003). In order to provide the network node 110 with some time to receive the request from the UE 105 and to avoid unnecessary monitoring by the UE 105, the resumption of RS transmission (e.g., multiple RS transmissions) may occur after a specific duration D. In some embodiments, the duration D may be predefined (e.g., provided in a 3GPP specification), configured by higher layer signaling from the network node 110 to the UE 105, or indicated via UE capability signaling.

[0306] In some embodiments, a timeline associated with the RS type may be applied after the request is sent by UE 105 (operation 14002). For example, in some embodiments, if the report is associated with a semi-persistent RS, UE 105 may send a request in the time slot 14004) , wherein n is the time slot in which the UE 105 sends its request, and μ may be the SCS for request transmission (e.g., for transmission of a request from the UE 105) or for RS transmission. In some embodiments, the UE 105 may not expect the RS to be sent before the UE 105 sends its request. After a single or multiple cycles of RS transmission and corresponding reports (e.g., after another duration D') (operation 14004), the network node 110 may stop sending RS and / or the UE 105 may stop sending reports unless a triggering condition is met. The duration D' may occur just after the nth report is received by the network node 110 from the UE 105, wherein n equals 1 indicating the first report after the RS transmission, wherein n equals 2 indicating the second report after the RS transmission, and so on. In some embodiments, the value of n may be predefined (e.g., may be provided in a 3GPP specification), configured by higher layer signaling, or indicated via UE capability signaling. In some embodiments, the duration D' may correspond to (eg, may be) a certain window configured by higher layer signaling (eg, by RRC). In some embodiments, the duration D' may be a predefined duration (eg, may be provided in 3GPP specifications).

[0307] In terms of what is reported by the UE 105 to the network node 110, when the trigger condition is met, in some embodiments, the report may be a single bit indicating that the UE 105 is requesting the network node 110 to send the RS associated with the report. In some embodiments, the reporting configuration may not be shared across different CSI-ReportConfigs. In such embodiments, the network node 110 may determine which CSI-ReportConfig is associated with which to send the RS.

[0308] In some embodiments, the reporting configuration may be shared across different CSI-ReportConfigs in order to reduce decoding overhead at the network node 110. In such embodiments, the UE 105 may report additional information such as required reportConfigId, CSI-ResourceConfigId, nzp-CSI-ResourceSetId, nzp-CSI-RS-ResourceId, CSI-AperiodicTriggerState, CSI-SemiPersistentOnPUSCH-TriggerState, etc.

[0309] For example, in some embodiments, the report on the UCI or MAC-CE may be similar to the report as depicted in Table 4 below. For example, the UE 105 may indicate 4 reportConfigIds to the network node 110. In some embodiments, a bitmap may be used, and its width may be equal to the number of configured CSI-ReportConfigs, where the first MSB may be mapped to the CSI-ReprotConfig with the lowest ID, the second MSB may be mapped to the CSI-ReprotConfig with the second lowest Id, and so on. For example, a bit set to 1 may indicate which CSI-ReportConfig is requested by the UE 105.

[0310] In some embodiments, in order to reduce reporting overhead, since not all CSI-ReprotConfigs may set reportQuantity to UE-initiated-report, the process discussed above may only be applied to CSI-ReportConfigs that set reportQuantity to UE-initiated-report, etc.

[0311] Table 4: Report format for indicating requested reportConfigId:

[0312] reportConfigId#1 reportConfigId#2 reportConfigId#3 reportConfigId#4

[0313] In some embodiments, CFRA and SR may be associated with reportConfigId, CSI-ResourceConfigId, nzp-CSI-ResourceSetId, nzp-CSI-RS-ResourceId, CSI-AperiodicTriggerState, CSI-SemiPersistentOnPUSCH-TriggerState, etc. In some embodiments, the process discussed above for associating CFRA and SR with TCI states or RSs may be extended to this case. For example, as part of the CSI-ReportConfig, the network node 110 may configure an RO index or a preamble index that the UE 105 may use to request the network node 110 to send the RS associated with the CSI-ReportConfig. Similarly, as part of the CSI-ReportConfig, the network node 110 may configure SchedulingRequestId-beamDegradation, which points to a specific scheduling request configuration that the UE 105 may use to request the network node to send the RS associated with the CSI-ReportConfig.

[0314] In some embodiments, periodic and semi-persistent RSs may be sent by the network node 110, but may not be sent frequently, which may prevent the UE 105 from accurately evaluating the currently used beam or candidate beam. To solve this problem, the network node 110 may configure such periodic and semi-persistent RSs to have two or more periodicities (e.g., repeated twice or more times). In the initial stage, the RS may be sent infrequently. Once the UE 105 determines that the current serving beam has been degraded, the UE 105 may request the network node 110 to use another periodicity so that the RS is sent more frequently. The same concept may be applied to the periodicity of the report configuration. In some embodiments, the reporting techniques and associations discussed above may be extended to enable the UE 105 to indicate a preferred periodicity when a trigger condition is met.

[0315] In some embodiments, the request from UE 105 may include corresponding trigger information for configured DL RS resources for UE-initiated beam management (e.g., reporting) purposes, wherein, when the request is received at the network node 110, the DL resources may be sent without traditional DCI transmission in order to trigger the transmission of such DL resources.

[0316] In some embodiments, a new RRC configuration may be introduced as a measurement configuration for reporting, which reports a list of all DL RSs belonging to a serving cell that can be measured to derive UE-initiated reports (e.g., a concept similar to CSI-MeasConfig). The information element (IE) may also include a trigger state for dynamically selecting one or more aperiodic configurations and / or for triggering one or more aperiodic DL resource sets for measurement. In some embodiments, the trigger state (e.g., trigger condition) may be included in the UE request for DL ​​transmission, implicitly indicating to the network node 110 that a specific measurement configuration may be used at the UE 105 for UE-initiated reporting.

[0317] In some embodiments, for method 1 and method 2 (discussed above), a request (e.g., report) may be sent in other CCs than the CC in which beam quality degradation is detected. The network node 110 may indicate to the UE 105 which cell may be used to send such a request (report). For example, the network node 110 may use a higher layer to indicate a cell ID at which the request (e.g., report) is to be sent. In a cross-CC scenario, the UEI report may additionally include a cell ID (e.g., cell ID) in which an event has been triggered (e.g., in which a triggering event has occurred).

[0318] In some embodiments, for a request (e.g., report) sent in a cell in which no beam degradation is detected, and assuming that this cell uses a unified TCI status framework, the UE 105 may send a request (e.g., report) to another cell using the beam indicated by the unified TCI status framework.

[0319] In some embodiments, for a request (e.g., report) sent in the same cell in which beam degradation is detected, the UE 105 may send the request (e.g., report) using one of the preferred TCI states (or beams) carried in the request (e.g., report).

[0320] F. Define container priorities

[0321] In some embodiments, a container of requests (e.g., reports) may conflict with other UL channels (e.g., with other signals) that overlap with the container in the time domain. Defining UE behavior in this case may be beneficial. In some embodiments, any combination of the following definitions of UE behavior may apply.

[0322] In some embodiments, the network node 110 may indicate a priority level (e.g., a low priority level or a high priority level) of the container as part of the associated configuration (e.g., via higher layer signaling). In some embodiments, the container may have a predefined priority (e.g., the priority may be provided in the 3GPP specification). In some embodiments, the container may be high level to prioritize detection of degradation of beam quality on other UL channels (e.g., other signals).

[0323] Fig.15 is a flow chart depicting a method for handling a collision between a container carrying a request (eg, a report) and another UL channel (eg, a signal) according to some embodiments of the present disclosure.

[0324] refer to Fig.15 In some embodiments, the network node 110 may determine whether the request conflicts with another UL channel (e.g., another UL signal) (operation 15001). If the container has a higher priority than the other channels, the UE 105 may discard the other channels and may send the request (e.g., report) container (operation 15003). If the request (e.g., report) container has the same or lower priority level as the other UL channels (e.g., signals), and if the container can be multiplexed with the other UL channels (e.g., signals) (operation 15004), the UE 105 may multiplex the request (e.g., report) container with the other UL channels (e.g., signals) (operation 15005). Otherwise, if multiplexing cannot occur, but the request (e.g., report) container has the same priority level as the other UL channels (e.g., signals) (operation 15005), the UE 105 may prioritize the transmission of the container carrying the request (report) (operation 15007). Otherwise, if the container has a lower priority (operation 15006) and cannot be multiplexed with other UL channels / signals), the container carrying the request (report) may be discarded and other UL channels (eg, signals) may be sent (operation 15008).

[0325] G. Priority Rules for CSI Multiplexing

[0326] In some embodiments, a container carrying a request (e.g., a report) may be considered a CSI report, but the network node 110 may not know when the UE 105 may send a request (e.g., may not have information about when the UE 105 may send a request). To address this issue, in some embodiments, priority rules for CSI multiplexing may be defined, where containers (e.g., containers carried by UCI) will be multiplexed with other CSI reports.

[0327] In some embodiments, a conventional equation for determining the priority of a report may be used. In some embodiments, to provide higher priority to containers carrying requests, a conventional CSI reporting equation may be used and set such that the container is treated as an aperiodic CSI report carrying L1-RSRP and L1-SINR (e.g., where y in the equation below is set to 0), where k in the equation below is set to 0. Such an approach may be beneficial because it provides higher priority to containers carrying requests (e.g., reports).

[0328] For example, the priority value can be expressed by the conventional CSI reporting equation Pri CSI (y, k, c, B) = 2N cells M sy +N cells M s k+M s c+s, where c indicates the serving cell index, N cells indicates the maximum number of serving cells (e.g., the value of the higher-level parameter maxNrofServingCells), s indicates the ID of the calibration assistance report configuration, M s indicates the maximum number of calibration assistance report configurations, k indicates the priority of reports carrying L1-RSRP or L1-SINR, which can be zero (k=0) for UE-initiated reports, and y indicates the reporting priority based on the temporal characteristics of the report. For example, y=0 indicates aperiodic reporting, y=1 indicates semi-persistent reporting on PUSCH, y=2 indicates semi-persistent reporting on PUCCH, and y=3 indicates periodic reporting on PUCCH. However, for UE-initiated reporting, y can be set to zero (e.g., y=0). Therefore, in such an embodiment, the priority value can be calculated as M s c + s. That is, the priority value may be based on the product of the maximum number of calibration assistance report configurations, the serving cell index, and the ID (eg, identifier) ​​of the calibration assistance report configuration.

[0329] In some embodiments, the network node 110 may configure the value of "y" or the value of "k" to have greater flexibility than setting the values ​​of y and k to zero. For example, in some embodiments, a container carrying a request (e.g., a report) may be considered another CSI report type. For example, a container may be considered a semi-persistent CSI report on PUCCH or PUSCH, may be considered a periodic report on PUCCH, etc.

[0330] In some embodiments, new priority rules may be defined specifically for UE initiated reports, while the priority of such reports compared to CSI reports may be semi-statically configured, dynamically indicated, and / or determined based on predetermined rules. In some embodiments, the predetermined rules may indicate that UE initiated reports have a higher priority when compared to CSI reports.

[0331] H. Selective multiplexing can occur on dynamic PUSCH or CG PUSCH

[0332] In some embodiments, the network node 110 may not know whether the UE 105 intends to send a container carrying a request (e.g., a report) (e.g., may not have information about whether the UE 105 intends to send a container carrying a request (e.g., a report)). Therefore, when the container carrying the request is multiplexed with the PUSCH, the blind decoding workload may increase on the network node 110 side. To address this issue, the network node 110 may indicate to the UE 105 whether the container can be multiplexed on the dynamic PUSCH and / or on the CG PUSCH. The indication may be provided via higher layer signaling (e.g., RRC). In some embodiments, predefined rules may be applied (e.g., rules may be provided in the 3GPP specification).

[0333] In some embodiments, when a container carrying a request (e.g., a report) exists and collides with a PUSCH, the network node 110 may indicate to the UE which PUSCH may be used for multiplexing. In some embodiments, the network node may indicate a time pattern in which multiplexing may occur. For example, the network node 110 may configure a periodicity and duration for each period in which multiplexing between a container and another PUSCH may occur.

[0334] Fig.16 is a diagram depicting an example of configuring a window indicating when multiplexing of a PUSCH and a container carrying a request (eg, a report) from a UE is allowed according to some embodiments of the present disclosure.

[0335] refer to Fig.16, an example where the periodicity T is equal to three time slots SL and multiplexing is allowed only in one time slot (e.g., one time slot SL per period T, such as SL3 and SL6). Container CN1 to be transmitted in time slot #0 (e.g., SL3) in subframe #1 (SF1) overlaps with PUSCH (PU1) in the time domain, and both container CN1 and PUSCH (PU1) fall within the window where multiplexing is allowed. Therefore, UE 105 can multiplex container CN1 in PUSCH (PU1). On the other hand, for container CN2 to be transmitted in time slot #1 (e.g., SL8) in subframe #3 (SF3), multiplexing may not be allowed. Therefore, other priority determination rules similar to the priority determination rules discussed above can be applied to determine which one between container CN2 and PUSCH (PU2) will be transmitted and which one will be discarded when multiplexing is not allowed in a given time slot SL.

[0336] Although the method discussed in this section is for a PUSCH that collides with a container carrying a UE request (eg, a report), the present disclosure is not limited thereto. For example, the method may also be applied to a PUCCH.

[0337] IV. Receive responses from network nodes

[0338] In method 1 in which the network node 110 transmits an RS for evaluating a currently used beam and candidate beams, after the UE 105 transmits a container carrying a request (eg, a report) to the network node 110 , any of the following methods may be applied.

[0339] In some embodiments, after the UE 105 indicates a preferred TCI state (or beam) as discussed, or using any other process, and after a certain duration t (and, in some embodiments, after one or more additional conditions), the UE 105 may apply the indicated preferred TCI state for receiving or transmitting subsequent DL reception and UL transmission, respectively, which may be beneficial when a unified TCI state framework is used. The duration t may be configured by higher layer signaling (e.g., RRC), may be predefined (e.g., provided by a standard), indicated to the network node 110 via UE capability signaling, or may be equal to other parameters, such as: timeDurationForQCL, beam application time of the unified TCI state framework, etc. The duration t may start after a container transmission (e.g., immediately after a container transmission), or may start after a certain gap.

[0340] Fig.17 is a diagram depicting an example of using CFRA (as discussed above) to indicate a preferred TCI state according to some embodiments of the present disclosure.

[0341] refer to Fig.17, in some embodiments, the network node 110 may associate a TCI state with an RO index (operation 17001). The network node 110 may indicate TCI state #0 (e.g., via a unified TCI state framework) as the current beam (operation 17002). The UE 105 may monitor a trigger condition associated with TCI state #0 and may select RO-1 associated with TCI state #1 to transmit a PRACH indicating a preference for TCI state #1 based on the occurrence of a trigger event (operation 17003). After a duration t, the UE 105 may apply the preferred TCI state (e.g., TCI state #1) to DL reception and UL transmission (operation 17004).

[0342] In some embodiments, as discussed above, the UE 105 may apply the indicated preferred TCI state for receiving or sending subsequent DL receptions and UL transmissions after one or more additional conditions. In some embodiments, the one or more additional conditions may be in the form of an explicit ACK / NACK sent from the network node 110 to the UE 105. The ACK / NACK may be sent via a DCI carried in a PDCCH, the CRC of the DCI being scrambled by a cell radio network temporary identifier (C-RNTI) or any other RNTI. In some embodiments, the ACK / NACK may be a one-bit field in the DCI. In some embodiments, a dedicated search space may be configured for monitoring such a PDCCH after the UE 105 sends a container carrying a request (e.g., a report). For example, the dedicated search space may be configured via a RACH (e.g., via a CFRA RACH). Once the ACK is received or decoded by the UE 105 (for decoding the PDCCH carrying the ACK), the duration t may terminate and the UE 105 may apply the preferred TCI state (e.g., Fig.17 If a NACK is received, the UE 105 may continue to use the old (eg, previous) TCI state (eg, Fig.17 TCI state #0 in the example).

[0343] If the duration t expires without the UE 105 receiving any response from the network node 110, the UE 105 may assume that it will revert back to the previous TCI state. In some embodiments, when the duration t expires without the UE 105 receiving any response from the network node 110, the UE 105 may apply the newly indicated preferred beam. For example, this approach may be effectively equivalent to the network node 110 sending a NACK only for the duration t, and if the NACK is not sent by the network node 110 (or is not received by the UE 105), then an ACK is assumed at the end of the duration t.

[0344] In some embodiments, assuming that the new TCI is applied based on the preferred TCI state indicated by the UE 105, after a duration t, the UE 105 may monitor for explicit ACK / NACK. As discussed above, a dedicated search space may be used for this purpose. The UE 105 may monitor the dedicated search space after the duration t. If an ACK is received by the UE 105, the UE 105 may continue to use the indicated preferred TCI state. If a NACK is indicated, the UE 105 may revert back to the previous TCI state.

[0345] In some embodiments, an implicit ACK may be used, in which case the UE 105 may wait to receive a PDCCH activating one of the indicated preferred TCI states or to receive a MAC-CE activating a different set of TCI states.

[0346] In some embodiments, the implicit ACK2 may take the form of any transmission received from the network node 110 using the indicated preferred TCI state. For example, the UE 105 may apply the indicated preferred TCI state and may wait to receive a DL transmission (e.g., the DL transmission may include a scheduled PDCCH) from the network node 110 using the preferred TCI state. In some embodiments, when the UE 105 receives the explicit or implicit ACK, the UE 105 may assume that the process completed successfully.

[0347] In method 2, in which the network node 110 does not send an RS for evaluating the currently used beam and the candidate beam, or the network node 110 sends an RS for evaluating the currently used beam instead of the candidate beam, the network node 110 may send an RS to evaluate the quality of the currently used beam or to identify the candidate beam. In some embodiments, as a response to a UE request (report), the network node 110 may send an RS associated with reportConfigId, CSI-ResourceConfigId, nzp-CSI-ResourceSetId, nzp-CSI-RSs-ResourceId, CSI-AperiodicTriggerState, CSI-SemiPersistentOnPUSCH-TriggerState, etc., as indicated by the request (e.g., report) sent by the UE 105, as discussed above, or using any other suitable procedure to send the above. In such an embodiment, the UE 105 may assume that the process is successfully completed based on receiving such an RS from the network node 110.

[0348] Fig.18 is a flow chart depicting a method for performing a UE-initiated beam management process according to some embodiments of the present disclosure.

[0349] refer to Fig.18 , the method 18000 for performing UE-initiated BM may include one or more of the following operations. UE 105 may receive configuration information (operation 18001, including operations 18001A and 18001B). The configuration information may include (i) beam quality assessment data for UE 105 to determine the quality of the current beam or the quality of the new beam (operation 18001A) and (ii) trigger event data for UE 105 to determine that a condition for performing a UE-initiated BM process (e.g., the next operation of the UEI BM process) is met (operation 18001B). Based on the determination by UE 105 that the condition is met, UE 105 may send a beam report including information about the quality of the current beam and / or the quality of the new beam (operation 18002).

[0350] Fig.19 is a flow chart depicting a method for performing a UE-initiated beam management process according to some embodiments of the present disclosure.

[0351] refer to Fig.19 , the method 19000 for performing UE-initiated BM may include one or more of the following operations. UE 105 may receive configuration information (operation 19001, including operations 19001A and 19001B). The configuration information may include: (i) report data for UE 105 to report information about the quality of the current beam or the quality of the new beam (operation 19001A); and (ii) trigger event data for UE 105 to determine that a condition for performing a UE-initiated BM process (e.g., the next operation of the UEI BM process) is met (operation 19001B). Based on the determination by UE 105 that the condition is met, the UE may send a beam report including information about the quality of the current beam and / or the quality of the new beam (operation 19002).

[0352] Fig. 20 is a block diagram of an electronic device in a network environment according to some embodiments of the present disclosure.

[0353] refer to Fig. 20, the electronic device 2001 in the network environment 2000 may communicate with the electronic device 2002 via the first network 2098 (e.g., a short-range wireless communication network), or communicate with the electronic device 2004 or the server 2008 via the second network 2099 (e.g., a long-range wireless communication network). The electronic device 2001 may communicate with the electronic device 2004 via the server 2008. The electronic device 2001 may include a processor 2020, a memory 2030, an input device 2050, a sound output device 2055, a display device 2060, an audio module 2070, a sensor module 2076, an interface 2077, a haptic module 2079, a camera module 2080, a power management module 2088, a battery 2089, a communication module 2090, a subscriber identification module (SIM) card 2096, and / or an antenna module 2097. In one embodiment, at least one component (e.g., display device 2060 or camera module 2080) may be omitted from electronic device 2001, or one or more other components may be added to electronic device 2001. Some of the components may be implemented as a single integrated circuit (IC). For example, sensor module 2076 (e.g., fingerprint sensor, iris sensor, or illumination sensor) may be embedded in display device 2060 (e.g., display).

[0354] The processor 2020 may execute software (eg, program 2040 ) to control at least one other component (eg, hardware or software component) of the electronic device 2001 coupled to the processor 2020 , and may perform various data processing or calculations.

[0355] As at least part of data processing or calculation, the processor 2020 may load commands or data received from another component (e.g., the sensor module 2076 or the communication module 2090) into the volatile memory 2032, may process the commands or data stored in the volatile memory 2032, and may store the resultant data in the non-volatile memory 2034. The processor 2020 may include a main processor 2021 (e.g., a central processing unit or an application processor (AP)) and an auxiliary processor 2023 (e.g., a graphics processing unit (GPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)) that may operate independently of the main processor 2021 or in conjunction with the main processor 2021. Additionally or alternatively, the auxiliary processor 2023 may be adapted to consume less power than the main processor 2021, or to perform a specific function. The auxiliary processor 2023 may be implemented to be separate from the main processor 2021 or to be a part of the main processor 2021.

[0356] The auxiliary processor 2023 may control at least some of the functions or states related to at least one component (e.g., the display device 2060, the sensor module 2076, or the communication module 2090) instead of the main processor 2021 while the main processor 2021 is in an inactive (e.g., sleep) state, or together with the main processor 2021 while the main processor 2021 is in an active state (e.g., executing an application). The auxiliary processor 2023 (e.g., an image signal processor or a communication processor) may be implemented as a part of another component (e.g., the camera module 2080 or the communication module 2090) that is functionally related to the auxiliary processor 2023.

[0357] The memory 2030 may store various data used by at least one component of the electronic device 2001 (e.g., the processor 2020 or the sensor module 2076). The various data may include, for example, software (e.g., program 2040) and input data or output data for commands related thereto. The memory 2030 may include a volatile memory 2032 or a non-volatile memory 2034.

[0358] The program 2040 may be stored as software in the memory 2030 , and may include, for example, an operating system (OS) 2042 , middleware 2044 , or an application 2046 .

[0359] The input device 2050 may receive a command or data to be used by another component (eg, the processor 2020) of the electronic device 2001 from outside (eg, a user) of the electronic device 2001. The input device 2050 may include, for example, a microphone, a mouse, or a keyboard.

[0360] The sound output device 2055 can output sound signals to the outside of the electronic device 2001. The sound output device 2055 may include, for example, a speaker or a receiver. The speaker may be used for general purposes, such as playing multimedia or recording, and the receiver may be used to receive incoming calls. The receiver may be implemented as a part of the speaker or as a separate speaker.

[0361] The display device 2060 can visually provide information to the outside of the electronic device 2001 (e.g., to a user). The display device 2060 may include, for example, a display, a hologram device, or a projector, and may include a control circuit to control a corresponding one of the display, the hologram device, and the projector. The display device 2060 may include a touch circuit suitable for detecting a touch, or may include a sensor circuit (e.g., a pressure sensor) suitable for measuring the strength of a force caused by a touch.

[0362] The audio module 2070 can convert sound into an electrical signal, and vice versa. The audio module 2070 can obtain sound via the input device 2050, or can output sound via the sound output device 2055 or via headphones of an external electronic device 2002 directly (e.g., wired) or wirelessly coupled to the electronic device 2001.

[0363] The sensor module 2076 can detect the operating state (e.g., power or temperature) of the electronic device 2001 or the environmental state (e.g., the state of the user) outside the electronic device 2001. Then, the sensor module 2076 can generate an electrical signal or data value corresponding to the detected state. The sensor module 2076 can include, for example, a gesture sensor, a gyroscope sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biometric sensor, a temperature sensor, a humidity sensor, and / or an illumination sensor.

[0364] The interface 2077 may support one or more designated protocols for coupling the electronic device 2001 directly (e.g., wired) or wirelessly to the external electronic device 2002. The interface 2077 may include, for example, a high-definition multimedia interface (HDMI), a universal serial bus (USB) interface, a secure digital (SD) card interface, or an audio interface.

[0365] The connection terminal 2078 may include a connector via which the electronic device 2001 may be physically connected to the external electronic device 2002. The connection terminal 2078 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).

[0366] The haptic module 2079 may convert an electrical signal into a mechanical stimulus (eg, vibration or movement) or an electrical stimulus, which may be recognized by a user via a sense of touch or kinesthetic sense. The haptic module 2079 may include, for example, a motor, a piezoelectric element, or an electrical stimulator.

[0367] The camera module 2080 may capture still images or moving images. The camera module 2080 may include one or more lenses, an image sensor, an image signal processor, or a flash. The power management module 2088 may manage the power provided to the electronic device 2001. The power management module 2088 may be implemented as at least a portion of a power management integrated circuit (PMIC), for example.

[0368] The battery 2089 may supply power to at least one component of the electronic device 2001. The battery 2089 may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0369] The communication module 2090 may support establishing a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device 2001 and an external electronic device (e.g., electronic device 2002, electronic device 2004, or server 2008), and may support performing communication via the established communication channel. The communication module 2090 may include one or more communication processors that may operate independently of the processor 2020 (e.g., AP), and may support direct (e.g., wired) communication or wireless communication. The communication module 2090 may include a wireless communication module 2092 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 2094 (e.g., a local area network (LAN) communication module or a power line communication (PLC) module). A corresponding one of these communication modules can communicate with an external electronic device via a first network 2098 (e.g., a short-range communication network such as Bluetooth™, Wireless Fidelity (Wi-Fi) Direct, or Infrared Data Association (IrDA) standards) or via a second network 2099 (e.g., a long-range communication network such as a cellular network, the Internet, or a computer network (e.g., a LAN or a wide area network (WAN))). These various types of communication modules can be implemented as a single component (e.g., a single IC), or can be implemented as multiple components separated from each other (e.g., multiple ICs). The wireless communication module 2092 can use the user information (e.g., International Mobile Subscriber Identity (IMSI)) stored in the user identification module 2096 to identify and authenticate the electronic device 2001 in a communication network (such as the first network 2098 or the second network 2099).

[0370] The antenna module 2097 may transmit a signal or power to or receive a signal or power from the outside of the electronic device 2001 (e.g., an external electronic device). The antenna module 2097 may include one or more antennas. The communication module 2090 (e.g., the wireless communication module 2092) may select at least one of the one or more antennas suitable for the communication scheme used in the communication network (such as the first network 2098 or the second network 2099). Then, a signal or power may be transmitted or received between the communication module 2090 and the external electronic device via the selected at least one antenna.

[0371] A command or data may be sent or received between the electronic device 2001 and the external electronic device 2004 via a server 2008 coupled to the second network 2099. Each of the electronic devices 2002 and 2004 may be a device of the same type or a different type as the electronic device 2001. All or some of the operations to be performed at the electronic device 2001 may be performed at one or more of the external electronic devices 2002, 2004, or 2008. For example, if the electronic device 2001 should automatically perform a function or service, or in response to a request from a user or another device, the electronic device 2001 may request one or more external electronic devices to perform at least a portion of the function or service instead of or in addition to performing the function or service. The one or more external electronic devices receiving the request may perform at least a portion of the requested function or service, or additional functions or additional services related to the request, and transmit the result of the execution to the electronic device 2001. The electronic device 2001 may provide the result as at least a portion of the reply to the request with or without further processing the result. For this purpose, for example, cloud computing, distributed computing, or client-server computing techniques may be used.

[0372] The subject matter and the embodiments of the operation described in this specification can be implemented in digital electronic circuits, or in computer software, firmware or hardware (including the structures disclosed in this specification and their structural equivalents), or in a combination of one or more of them. The embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, which are encoded on a computer storage medium for execution by a data processing device or for controlling the operation of a data processing device. Alternatively or additionally, program instructions can be encoded on an artificially generated propagation signal, for example, a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device for execution by a data processing device. A computer storage medium can be or be included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination thereof. In addition, although a computer storage medium is not a propagation signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagation signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices). In addition, the operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0373] Although this specification may include many specific implementation details, the implementation details should not be interpreted as a limitation on the scope of any claimed subject matter, but rather as a description of features specific to a particular embodiment. Certain features described in the context of a separate embodiment in this specification may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination (e.g., sub-combination). In addition, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from the claimed combination may be excluded from the combination in some cases, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0374] Similarly, although operations may be depicted in the accompanying drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequence, or that all of the operations shown be performed, to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0375] Thus, specific embodiments of the subject matter have been described herein. Other embodiments are within the scope of the following claims. In some cases, the actions set forth in the claims can be performed in a different order and still achieve the desired results. Additionally, the processes depicted in the accompanying drawings do not necessarily require the particular order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing can be advantageous.

[0376] As will be appreciated by those skilled in the art, the innovative concepts described herein may be modified and varied over a wide range of applications. Therefore, the scope of the claimed subject matter should not be limited to any specific exemplary teachings discussed above, but rather to the appended claims, wherein functional equivalents of the claims are included therein.

Claims

1. A method comprising: Configuration information is received by a user equipment (UE), the configuration information including: Beam quality assessment data, used by the UE to determine the quality of the current beam and / or the quality of a new beam; and Trigger event data for the UE to determine that conditions for performing a UE-initiated (UEI) beam management (BM) procedure are met; and Based on the conditions being determined by the UE, a beam report is sent.

2. The method according to claim 1, further comprising: Determining, by the UE, that the first beam is the current beam; and / or The UE determines that the second beam is a new beam.

3. The method according to claim 1, wherein: Determining that the condition is satisfied includes comparing a characteristic of the current beam with a characteristic of the new beam.

4. The method according to claim 1, wherein: The conditions include that the quality of the new beam is better than the current beam by reaching a threshold, which is based on the reference signal received power (RSRP).

5. The method according to claim 4, wherein: The UE determines that the condition is met by determining that a difference between a first RSRP of the current beam and a second RSRP of the new beam is less than a threshold.

6. The method according to claim 4, wherein: The threshold is configured via higher layer signaling, which complies with the Radio Resource Control (RRC) protocol.

7. The method according to claim 1, wherein: The condition includes a quality of the current beam being worse than a threshold, wherein the threshold is determined based on a signal strength of the current beam.

8. The method according to claim 1, wherein: The conditions include the quality of the new beam being better than a reference signal (RS) derived from the activated transmission configuration indicator (TCI) state reaching a threshold.

9. The method according to claim 1, wherein: The UE implicitly determines that the first beam is the current beam based on an indicated transmission configuration indicator (TCI) state or based on an activated TCI state.

10. The method according to claim 1, wherein: The current beam is explicitly configured via the Radio Resource Control (RRC) protocol.

11. The method according to claim 1, wherein: The UE implicitly determines that the second beam is a new beam based on the activated transmission configuration indicator (TCI) state.

12. The method according to claim 1, wherein: The new beam is explicitly configured via the Radio Resource Control (RRC) protocol.

13. The method according to claim 1, wherein: The condition includes a threshold number of degradation instances.

14. The method according to claim 13, wherein: The threshold number of degradation instances is based on consecutively occurring degradation instances.

15. The method according to claim 13, wherein: The threshold number of degradation instances is configured via the Radio Resource Control (RRC) protocol.

16. The method according to claim 13, wherein: The threshold number of degradation instances is based on degradation instances occurring within a time window, the time window being configured via a radio resource control (RRC) protocol.

17. The method according to claim 16, wherein: Time Window: starts upon occurrence of a first degradation instance; and Termination based on expiration of a timer or based on occurrence of a threshold number of degradation instances.

18. The method according to claim 13, wherein: The threshold number of degradation instances is based on a beam failure recovery (BFR) procedure.

19. The method of claim 1, further comprising: As part of the UE capability signalling procedure, information is sent by the UE indicating that the UE is capable of supporting the UEIBM procedure.

20. A user equipment (UE) comprising a processing circuit, the processing circuit being configured to perform: Receive configuration information, including: Beam quality assessment data, used by the UE to determine the quality of the current beam and / or the quality of the new beam; and Trigger event data, used by the UE to determine that conditions for performing a UE-initiated (UEI) beam management (BM) procedure are met; as well as Based on determining that the conditions are met, a beam report is sent.

Images