Event evaluation for UE-initiated beam reporting

Abstract

A user equipment (UE) can perform an event evaluation procedure in response to detecting an event associated with UE-initiated beam reporting (UEIBR) being triggered. The UE can generate in response to the at least one event, a 1 -bit uplink control information (UCI) indicator to request resources for an UEIBR transmission. The UE can transmit the UCI during an initial physical uplink control channel (PUCCH) occasion, and the UE can perform retransmission of the UCI in a PUCCH retransmission occasion to request the resources for the UEIBR transmission. These and many other features and examples are described herein.

Description

Attorney Docket No.: 106842260540 (P71556WO1) EVENT EVALUATION FOR UE-INITIATED BEAM REPORTINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 779,615, filed March 28, 2025, the content of which is herein incorporated by reference in its entirety for all purposes.FIELD

[0002] This disclosure relates to wireless communication networks and mobile device capabilities.BACKGROUND

[0003] Wireless communication networks and wireless communication services are becoming increasingly dynamic, complex, and ubiquitous. For example, some wireless communication networks can be developed to implement fifth generation (5G) or new radio (NR) technology, sixth generation (6G) technology, and so on. Such technology can include solutions for enabling user equipment (UE) and network devices, such as base stations, to communicate with one another. Such communications can involve evaluating and managing wireless channels, signals, and resources.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present disclosure will be readily understood and enabled by the detailed description and accompanying figures of the drawings. Like reference numerals can designate like features and structural elements. Figures and corresponding descriptions are provided as non-limiting examples of aspects, implementations, etc., of the present disclosure, and references to "an" or “one” aspect, implementation, etc., may not necessarily refer to the same aspect, implementation, etc., and can mean at least one, one or more, etc.

[0005] Fig. l is a diagram of an example of an overview according to one or more implementations described herein.

[0006] Fig. 2 is a diagram of an example network according to one or more implementations described herein.

[0007] Fig. 3 is a diagram of an example process for event evaluation for UE-initiated beam reporting according to one or more implementations described herein.

[0008] Fig. 4 is a diagram of an example of retransmission of a physical uplink control14938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) channel (PUCCH) following expiration of a transmission timer according to one or more implementations described herein.

[0009] Fig. 5 is a diagram of an example of implementing a transmission timer for PUCCH transmissions following a physical uplink shared channel (PUSCH) carrying a channel state information (CSI) report according to one or more implementations described herein.

[0010] Fig. 6 is a diagram of an example of retransmission of a physical uplink control channel (PUCCH) following an event evaluation window according to one or more implementations described herein.

[0011] Fig. 7 is a diagram of an example of determining an evaluation window for event trigger determination according to one or more implementations described herein.

[0012] Fig. 8 is a diagram of another example of applying a timing window to event evaluation according to one or more implementations described herein.

[0013] Fig. 9 is a diagram of another example for resetting a counter for an event evaluation procedure according to one or more implementations described herein.

[0014] Fig. 10 is a diagram of an example of components of a device according to one or more implementations described herein.

[0015] Fig. 11 is a diagram of example interfaces of baseband circuitry according to one or more implementations described herein.

[0016] Fig. 12 is a block diagram illustrating components, according to one or more implementations described herein, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

[0017] Fig. 13 is a diagram of an example process for event evaluation for UE-initiated beam reporting according to one or more implementations described herein.DETAILED DESCRIPTION

[0018] The following detailed description refers to the accompanying drawings. Like reference numbers in different drawings can identify the same or similar features, elements, operations, etc. Additionally, the present disclosure is not limited to the following description as other implementations can be utilized, and structural or logical changes made, without departing from the scope of the present disclosure.

[0019] Wireless communication networks can include user equipment (UE) capable of communicating with base stations and / or other network devices. The UE and base station can communicate with one another using time and frequency resources allocated for uplink and24938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) downlink communications. Examples of such communications can involve beam reporting procedures, such as UE-initiated beam reporting (UEIBR).

[0020] UEIBR can include a procedure by which beams between a base station and UE are measured and evaluated to determine which beams are suitable for communications between the UE and the base station. A base station can communicate reference signals to a UE using one or more beams. The UE can measure the reference signals to determine a layer 1 (LI) received power reference signal (RSRP) for each beam. The UE can evaluate the measurements to determine whether a current serving beam is the best, or is adequate, for ongoing communications between the UE and the base station. Evaluation of the measurements can result in an event trigger configured to cause the UE to generate a beam report (e.g., a UEIBR report) corresponding to the event trigger detected by the UE. In an Event- 1 scenario, the UEIBR report can indicate that a quality of the current serving beam (e.g., the Ll-RSRP) is worse than a beam quality threshold. In an Event-2 scenario, the UEIBR report can indicate that a quality of at least one new beam (e.g., the Ll-RSRP) is at least a threshold value better than the current serving beam. In an Event-7 scenario, the UEIBR report can indicate that a quality of at least one new beam (e.g., the Ll-RSRP) is at least a threshold value better than a reference signal derived from an activated transmission configuration indication (TCI) state with an M-th best quality. The UE can respond to an event trigger by generating a UEIBR report and transmitting the report to the base station via a physical uplink control channel (PUCCH) transmission.

[0021] While currently available technologies enable UEIBR via a PUCCH transmission, currently available technologies fail to provide any, or adequate, solutions for generating and communicating an UEIBR report via one or more PUCCH retransmissions, including how PUCCH retransmissions can be used in combination with a channel state information (CSI) report being generated and communicated to the base station.

[0022] One or more of the techniques, described herein, include solutions for event evaluation for UE-initiated beam reporting (UEIBR). In some implementations, one or more of these techniques can include performing a PUCCH retransmission when an event is triggered and a PUCCH is transmitted by the UE. Additionally, or alternatively, one or more of these techniques can include implementing a PUCCH retransmission occasion between an initial PUCCH transmission and a physical uplink shared channel (PUSCH) occasion. One or more of these techniques can also include different alternatives for determining measured results to be included in a PUSCH when at least one retransmission occurs for a PUCCH channel. Other aspects of the techniques, described herein, can include solutions for determining a time window for event evaluation and / or solutions for resetting a counter used in the event evaluation process.34938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1)

[0023] Fig. 1 is a diagram of an example 100 of an overview according to one or more implementations described herein. As shown, example 100 can include UE 110 and base station 120. UE 110 can measure reference signals transmitted by base station 120 and can detect an event associated with UEIBR being triggered (at 1.1). UE 110 can detect the event being triggered based on the measurements. UE 210 can generate uplink control information (UCI) that includes a 1 -bit indication of the detected event (at 1.2). The 1 -bit indicator can function as a request for resources for a UEIBR transmission. UE 210 can transmit the 1 -bit UCI during an initial PUCCH occasion and can perform retransmission of the 1 -bit UCI during one or more PUCCH retransmission occasions (at 1.2). Base station 120 can receive the UCI, determine to provide UE 110 with an uplink grant, and communicate the uplink grant to UE 110 (at 1.3). UE 110 can receive the uplink grant and generate a channel state information (CSI) report for UEIBR and can communicate the CSI report to base station 120 during a PUSCH occasion (at 1.3). These and many other features and examples are described below with reference to the remaining Figures.

[0024] Fig. 2 is an example environment 200 in which one or more of the techniques described herein can be implemented. Example environment 200 can include UEs 210-1, 210-2, etc. (referred to collectively as “UEs 210” and individually as “UE 210”), a radio access network (RAN) 220, a core network (CN) 230, application servers 240, external networks 250.

[0025] The systems and devices of example environment 200 can operate in accordance with one or more communication standards, such as 2nd generation (2G), 3rd generation (3G), 4th generation (4G) (e.g., long-term evolution (LTE)), and / or 5th generation (5G) (e.g., new radio (NR)) communication standards of the 3rd generation partnership project (3GPP). Additionally, or alternatively, one or more of the systems and devices of example environment 200 can operate in accordance with other communication standards and protocols discussed herein, including future versions or generations of 3GPP standards (e.g., sixth generation (6G) standards, seventh generation (7G) standards, etc.), institute of electrical and electronics engineers (IEEE) standards, and more.

[0026] As shown, UEs 210 can include smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more wireless communication networks). Additionally, or alternatively, UEs 210 can include other types of mobile or non-mobile computing devices capable of wireless communications, such as personal data assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, etc. In some implementations, UEs 210 can include Internet of Things (loT) devices (or loT UEs) that can implement narrowband (NB)4938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) communications and that can comprise, for example, a network access layer designed for low-power loT applications utilizing short-lived UE connections.

[0027] Additionally, or alternatively, an loT UE can utilize one or more types of technologies, such as machine-to-machine (M2M) communications or machine-type communications (MTC) (e.g., to exchanging data with an MTC server or other device via a public land mobile network (PLMN)), proximity -based service (ProSe) or device-to-device (D2D) communications, sensor networks, loT networks, and more. Depending on the scenario, an M2M or MTC exchange of data can be a machine-initiated exchange, and an loT network can include interconnecting loT UEs (which can include uniquely identifiable embedded computing devices within an Internet infrastructure) with short-lived connections. In some scenarios, loT UEs can execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the loT network.

[0028] UEs 210 can communicate and establish a connection with one or more other UEs 210 via one or more wireless channels 212, each of which can comprise a physical communications interface / layer. The connection can include an M2M connection, MTC connection, D2D connection, SL connection, etc. The connection can involve a PC5 interface. In some implementations, UEs 210 can be configured to discover one another, negotiate wireless resources between one another, and establish connections between one another, without intervention or communications involving RAN node 222 or another type of network node. In some implementations, discovery, authentication, resource negotiation, registration, etc., can involve communications with RAN node 222 or another type of network node.

[0029] UEs 210 can communicate and establish a connection with RAN 220, which can involve one or more wireless channels 214-1 and 214-2, each of which can comprise a physical communications interface / layer. In some implementations, a UE can be configured with dual connectivity (DC) as a multi-radio access technology (multi-RAT) or multi-radio dual connectivity (MR-DC), where a multiple receive and transmit (Rx / Tx) capable UE can use resources provided by different network nodes (e.g., 222-1 and 222-2) that can be connected via non-ideal backhaul (e.g., where one network node provides NR access and the other network node provides either E-UTRA for LTE or NR access for 5G). A network node can be referred to herein as a base station 222. In such a scenario, one network node can operate as a master node (MN) and the other as the secondary node (SN). The MN and SN can be connected via a network interface, and at least the MN can be connected to the CN 230. In some implementations, a base54938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) station (as described herein) can be an example of network node 222. In some scenarios, RAN 220 can coordinate with core network 230 via interfaces 224, 226, and / or 228.

[0030] As shown, UE 210 can also, or alternatively, connect to access point (AP) 216 via connection interface 218, which can include an air interface enabling UE 210 to communicatively couple with AP 216. AP 216 can comprise a wireless local area network (WLAN), WLAN node, WLAN termination point, etc. The connection interface 218 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, and AP 216 can comprise a wireless fidelity (Wi-Fi®) router or other access point device. While not explicitly depicted in Fig. 2, AP 216 can be connected to another network (e.g., the Internet) without connecting to RAN 220 or CN 230.

[0031] One or more of the techniques described herein include solutions for event evaluation for UEBR. UE 210 can perform an event evaluation procedure in response to detecting an event being triggered based on the measurements. UE 210 can generate, in response to the event, a UCI to request resources for an UEIBR transmission. UE 210 can transmit the UCI during an initial PUCCH occasion and can perform retransmission of the UCI in a PUCCH retransmission occasion to request the resources for the UEIBR transmission. These and many other features and examples are described herein.

[0032] RAN 220 can include one or more RAN nodes 222-1 andr-r(referred to collectively as RAN nodes 222, and individually as RAN node 222) that enable channels 214-1 and 214-2 to be established between UEs 210 and RAN 220. RAN nodes 222 can include network access points configured to provide radio baseband functions for data and / or voice connectivity between users and the network based on one or more of the communication technologies described herein (e.g., 1G, 3G, 4G, 5G, WiFi, etc.). As examples therefore, a RAN node can be an E-UTRAN Node B (e.g., an enhanced Node B, eNodeB, eNB, 4G base station, etc.), a next generation base station (e.g., a 5G base station, NR base station, next generation eNBs (gNB), etc.). RAN nodes 222 can include a roadside unit (RSU), a transmission reception point (TRxP or TRP), and one or more other types of ground stations (e.g., terrestrial access points). In some scenarios, RAN node 222 can be a dedicated physical device, such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells or the like having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells. A RAN node can generally be referred to herein as base station 222.

[0033] Some or all of RAN nodes 222, or portions thereof, can be implemented as one or more software entities running on server computers as part of a virtual network, which can be referred to as a centralized RAN (CRAN) and / or a virtual baseband unit pool (vBBUP). In these implementations, the CRAN or vBBUP can implement a RAN function split, such as a packet64938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) data convergence protocol (PDCP) split wherein radio resource control (RRC) and PDCP layers can be operated by the CRAN / vBBUP and other Layer 1 (LI) protocol entities can be operated by individual RAN nodes 222; a media access control (MAC) / physical (PHY) layer split wherein RRC, PDCP, radio link control (RLC), and MAC layers can be operated by the CRAN / vBBUP and the PHY layer can be operated by individual RAN nodes 222; or a “lower PHY” split wherein RRC, PDCP, RLC, MAC layers and upper portions of the PHY layer can be operated by the CRAN / vBBUP and lower portions of the PHY layer can be operated by individual RAN nodes 222. This virtualized framework can allow freed-up processor cores of RAN nodes 222 to perform or execute other virtualized applications.

[0034] In some implementations, an individual RAN node 222 can represent individual gNB-distributed units (DUs) connected to a gNB-control unit (CU) via individual Fl or other interfaces. In such implementations, the gNB-DUs can include one or more remote radio heads or radio frequency (RF) front end modules (RFEMs), and the gNB-CU can be operated by a server (not shown) located in RAN 220 or by a server pool (e.g., a group of servers configured to share resources) in a similar manner as the CRAN / vBBUP. Additionally, or alternatively, one or more of RAN nodes 222 can be next generation eNBs (i.e., gNBs) that can provide evolved universal terrestrial radio access (E-UTRA) user plane and control plane protocol terminations toward UEs 210, and that can be connected to a 5G core network (5GC) 230 via an NG interface.

[0035] Any of the RAN nodes 222 can terminate an air interface protocol and can be the first point of contact for UEs 210. In some implementations, any of the RAN nodes 222 can fulfill various logical functions for the RAN 220 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. UEs 210 can be configured to communicate using orthogonal frequency-division multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 222 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an OFDMA communication technique (e.g., for downlink communications) or a single carrier frequency-division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink (SL) communications), although the scope of such implementations may not be limited in this regard. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0036] In some implementations, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 222 to UEs 210, and uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid (e.g., a resource grid or time-frequency resource grid) that represents the physical resource for downlink in each slot. Such a timefrequency plane representation is a common practice for OFDM systems, which makes it74938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest timefrequency unit in a resource grid is denoted as a resource element. Each resource grid comprises resource blocks, which describe the mapping of certain physical channels to resource elements (REs). Each resource block can comprise a collection of resource elements; in the frequency domain, this can represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0037] Further, RAN nodes 222 can be configured to wirelessly communicate with UEs 210, and / or one another, over a licensed medium (also referred to as the “licensed spectrum” and / or the “licensed band”), an unlicensed shared medium (also referred to as the “unlicensed spectrum” and / or the “unlicensed band”), or combination thereof. A licensed spectrum can correspond to channels or frequency bands selected, reserved, regulated, etc., for certain types of wireless activity (e.g., wireless telecommunication network activity), whereas an unlicensed spectrum can correspond to one or more frequency bands that are not restricted for certain types of wireless activity.

[0038] The PDSCH can carry user data and higher layer signaling to UEs 210. The physical downlink control channel (PDCCH) can carry information about the transport format and resource allocations related to the PDSCH channel, among other things. The PDCCH can also inform UEs 210 about the transport format, resource allocation, and hybrid automatic repeat request (HARQ) information related to the uplink shared channel. Typically, downlink scheduling (e.g., assigning control and shared channel resource blocks to UE 210 within a cell) can be performed at any of the RAN nodes 222 based on channel quality information feedback from any of UEs 210. The downlink resource assignment information can be sent on the PDCCH used for (e.g., assigned to) each of UEs 210.

[0039] The RAN nodes 222 can be configured to communicate with one another via interface 223. In implementations where the system is an LTE system, interface 223 can be an X2 interface. In NR systems, interface 223 can be an Xn interface. The X2 interface can be defined between two or more RAN nodes 222 (e.g., two or more eNBs / gNBs or a combination thereof) that connect to evolved packet core (EPC) or CN 230, or between two eNBs connecting to an EPC. As shown, RAN 220 can be connected (e.g., communicatively coupled) to CN 230. CN 230 can comprise a plurality of network elements 232, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UEs 210) who are connected to the CN 230 via the RAN 220. In some implementations, CN 230 can include an84938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) evolved packet core (EPC), a 5G CN (5GC), and / or one or more additional or alternative types of CNs.

[0040] As shown, CN 230, application servers 240, and external networks 250 can be connected to one another via interfaces 234, 236, and 238, which can include IP network interfaces. Application servers 240 can include one or more server devices or network elements (e.g., virtual network functions (VNFs) offering applications that use IP bearer resources with CN 230 (e.g., universal mobile telecommunications system packet services (UMTS PS) domain, LTE PS data services, etc.). Application servers 240 can also, or alternatively, be configured to support one or more communication services (e.g., voice over IP (VoIP sessions, push-to-talk (PTT) sessions, group communication sessions, social networking services, etc.) for UEs 210 via the CN 230. Similarly, external networks 250 can include one or more of a variety of networks, including the Internet, thereby providing the mobile communication network and UEs 210 of the network access to a variety of additional services, information, interconnectivity, and other network features.

[0041] Fig. 3 is a diagram of an example process 300 for event evaluation for UE-initiated beam reporting according to one or more implementations described herein. As shown, process 300 can be implemented by UE 210 and / or base station 222. In some implementations, some or all of process 300 can be performed by one or more other systems or devices, including one or more of the devices of Fig. 2 and / or baseband circuitry of UE 210 and / or base station 222.Additionally, process 300 can include one or more fewer, additional, differently ordered and / or arranged operations than those shown in Fig. 3. In some implementations, some or all of the operations of process 300 can be performed independently, successively, simultaneously, etc., of one or more of the other operations of process 300. As such, the techniques described herein are not limited to the number, sequence, arrangement, timing, etc., of the operations or processes depicted in Fig. 3.

[0042] As shown, process 300 can include base station 222 communicating configuration information to UE 210 (block 305). The configuration information can cause or enable UE 210 to perform UEIBR, which can include performing beam measurements, generating beam reports, and communicating the beam reports to base station 222. The configuration information can indicate one or more event triggers for UE 210 to monitor and in response to the event triggers, perform UEIBR. The configuration information can cause or enable UE 210 to measure beams or reference signals from base station 222, generate beam reports (e.g., UEIBRs), implement retransmission timers, determine event evaluation windows, generate subsequent UEIBRs, determine uplink resources (e.g., PUCCH resources) for communicating UEIBRs, retransmit UEIBRs, and more. The configuration information can configure / activate frequent periodic or94938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) semi-persistent beam reporting (e.g., reporting of N best beams and corresponding layer 1 (LI) received signal reference power (RSRP) measurements) and / or trigger frequent aperiodic beam reporting to timely acquire the best / preferred beam for data / control transmissions. Base station 222 can communicate the configuration to UE 210 using RRC signaling.

[0043] Process 300 can include base station 222 communicating reference signals (RS) to UE 210 (block 310). For example, base station 222 can use multiple beams to transmit RSs to UE 210. UE 210 can perform measurements of the beams as part of a beam management procedure, which can include UEIBR. UE 210 can determine a signal strength and beam quality of the beams used by base station 222. The beam management procedure can include LI -RSRP measurements and reporting.

[0044] Process 300 can include UE 210 detecting that one or more events have been triggered (block 320). For example, UE 210 can monitor for one or more event triggers, which can be indicated by the configuration information received from base station 222. Examples of an event trigger can include when UE 210 is moving across different beams of a cell, UE 210 is first configured by base station 222 to continue monitoring the Ll-RSRPs of new candidate beams. UE 210 can initiate a report once UE 210 detects a triggered event based on conditions configured by base station 222 (e.g., Ll-RSRP values can be a threshold RSRP more than the LI -RSRP of a current serving beam) to ensure a quick report. In some implementations, an event trigger can include a number of instances of a particular type of signal-related event or condition exceeding a threshold number of instances. UE 210 can perform beam measurements according to scheduling and beam pattern information received from base station 222. In some implementations, the event trigger can further be particular to a specified duration or time window. For example, in some implementations, the number of instances must occur within a specified duration of one another in order to exceed the threshold number of instances). In some implementations, an event trigger can include a measured beam or reference signal strength exceeding (or failing to exceed) a threshold beam or signal strength or quality.

[0045] Process 300 can include UE 210 generating UCI to request resources for UEIBR (block 330). For example, UE 210 can generate UCI that includes an indication of the detected event having been triggered. The indication can include a 1 -bit field for each of the beams or reference signals measured by UE 210. The 1 -bit field can be configured to indicate whether a detected event has been triggered for a corresponding beam or reference signal. In some implementations, the indication can be more than a single bit. Base station 222 can be configured to interpret the UCI as a request for resources (e.g., a grant request) for a UEIBR transmission.

[0046] Process 300 can include UE 210 communicating the UCI to base station 222 via an initial PUCCH transmission (block 340). For example, UE 210 can be configured to transmit the104938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) UCI to base station 222 on an earliest or next PUCCH occasion. The PUCCH occasion can be referred to herein as an initial PUCCH occasion. The UCI can include a 1 -bit indicator for each beam or reference signal monitor by UE 210. When the UCI indicates that an event has been triggered for one or more beams or reference signals, base station 222 can be configured to interpret the UCI as a request for resources (e.g., a grant request) for a UEIBR transmission.

[0047] Process 300 can include determining or implementing a transmission timer (block 350). For example, UE 210 can determine a timer for transmitting or retransmitting the UCI. The timer can be a period of time between the initial PUCCH occasion and a PUCCH retransmission occasion for retransmission of the UCI. Additionally, or alternatively, the transmission timer can be a duration of time between two consecutive PUCCH occasions during which the UCI is retransmitted (e.g., between a first PUCCH retransmission and a second PUCCH retransmission). In some implementations, the transmission timer can be an amount of time between a PUSCH transmission carrying a CSI report and a next PUCCH transmission. In some implementations, configuration information received from base station 222 can indicate a duration of the transmission timer.

[0048] Process 300 can include determining an event evaluation window (block 360). For example, UE 210 can determine an event evaluation window for determining or detecting that one or more events have been triggered. The event evaluation window can include a duration of time, number of consecutive measurements that exceed a corresponding threshold, one or more monitoring occasions for a beam or reference signal, a number of measurement or monitoring occasions relative to an event detection timer, and more. An event evaluation window can occur before a transmission timer begins, after a transmission timer expires, or between transmission timers. In some implementations, the event evaluation window can correspond to event triggers prerequisite to a retransmission of the UCI via a PUCCH. This can include a first retransmission, a second retransmission, and / or one or more other retransmissions. While not shown in Fig. 3, in some implementations, UE 210 can be configured to determine, implement, and monitor an event evaluation window as part of detecting event triggers (see, block 320) leading to generating and transmitting the UCI (see, blocks 330 and 340). UE 210 can determine when the event evaluation window begins and / or how long the event evaluation windows lasts, based on the configuration information received from base station 222.

[0049] An evaluation window can include an amount of time within which a threshold number of events or event triggers are to be detected. In some implementations, the type, number, and degree of events can be the same for communicating the UCI during an initial PUCCH transmission and one or more retransmissions of the UCI. In some implementations, the type, number, and degree of events can be the different for causing the initial transmission and114938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) one or more retransmissions. In some implementations, the type, number, and degree of trigger events can be different for causing different retransmissions. For example, the type, number, and degree of trigger events that cause the initial UCI transmission can be more, greater, etc., than the type, number, and degree of trigger events that cause a UCI retransmission. Similarly, the duration of an evaluation window for the initial transmission and / or for one or more retransmissions can be the same or can vary.

[0050] Process 300 can include detecting one or more trigger events (block 370). A trigger event can include a threshold number of specified events occurring within an event evaluation window, within an event evaluation timer, etc. UE 210 can monitor for one or more event triggers, which can be indicated by the configuration information received from base station 222. Examples of an event trigger can include that at least one of the measured Ll-RSRPs associated with new candidate beams is a threshold amount greater or better than the Ll-RSRP of a current serving beam or that the Ll-RSRP of a current beam is lower than a threshold value. In some implementations, an event trigger can include a number of instances of a particular type of signal-related events or conditions exceeding a threshold number of instances. UE 210 can perform beam measurements according to scheduling and beam pattern information received from base station 222. Trigger events associated with a PUCCH retransmission of UCI can be the same, the same types, different, or different types of event triggers associated with the initial PUCCH transmission of the UCI. In some implementations, the event trigger can further be particular to a specified duration or time window. For example, in some implementations, the number of instances must occur within a specified duration of one another in order to exceed the threshold number of instances. In some implementations, an event trigger can include a measured beam or reference signal strength, quality, or reliability.

[0051] Process 300 can include UE 210 generating a UEIBR (block 375). For example, UE 210 can generate a UEIBR report in response to detecting that one or more events have been triggered. The UEIBR report can include a beam report indicating measurements, beam or signal strengths, and other types of information regarding communication conditions between UE 210 and base station 222. The UEIBR report can include, or be part of, a CSI report for one or more beams or reference signals transmitted by base station 222. The UEIBR report can include information describing a quality, condition, strength, or other characteristics of one or more beams or channels between UE 210 and base station 222. In some implementations, UE 210 can generate the UEIBR report in response to receiving an uplink grant for transmitting the UEIBR report and / or a CSI report during a PUSCH occasion.

[0052] Process 300 can include UE 210 communicating the UEIBR to base station 222 via a PUCCH retransmission (block 380). For example, the configuration information received from124938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) base station 222 can include time and frequency resources for retransmitting information to base station 222 via a PUCCH. UE 210 can use the PUCCH to retransmit UCI to base station 222, in response to detecting one or more events associated with a UEIBR procedure. In some implementations, UE 210 can forego generating an additional or new UCI for a retransmission and instead retransmit the same UCI as was transmitted during the initial PUCCH occasion or a PUCCH retransmission occasion. As described below, the UEIBR procedure can include one or more additional, or alternative, operations, which can include PUCCH retransmissions, retransmission timers, event evaluation windows, additional UEIBRs, etc. Process 300 can include multiple retransmissions of the UCI via a PUCCH occasion. In some scenarios, each, some, or none of the retransmissions are preceded by one, all, or any combination of determining and implementing a transmission timer, determining an event evaluation window, detecting one or more event triggers, and / or generating UCI (see, blocks 350-375).

[0053] Process 300 can include UE 210 receiving an uplink grant from base station 222 (block 385). For example, base station 222 can receive the UCI transmitted or retransmitted by UE 210. Base station 222 can interpret the UCI as a request for resources for a UEIBR procedure. Base station 222 can allocate uplink resources to UE 210 and can generate downlink control information (DCI) indicating the allocation of uplink resources (e.g., an uplink grant), and can communicate the DCI to UE 210. The uplink resources can correspond to a PUSCH occasion.

[0054] Process 300 can include UE 210 transmitting a CSI report (block 390). For example, UE 210 can generate a CSI report and transmit the CSI report to base station 222. The CSI report can be transmitted via a PUSCH (as opposed to a PUCCH used for UEIBR transmissions). In some implementations, UE 210 can receive DCI that includes an uplink grant and / or request for the CSI report. In such scenarios, UE 210 can generate and transmit the CSI report in accordance with the DCI. In some implementations, time and frequency resources for the PUSCH can be configured by the base station 222 via RRC signaling or another type of configuration or grant transmission. One or more of the examples described herein can also, or alternatively, be part of process 300. In some implementations, the CSI report can include some, or all, of the measurement information and / or other types of information included in the UEIBR. The CSI report can include measurement results from one or more event triggers associated with the UCI of an initial PUCCH transmission, a UCI of a PUCCH retransmission, UCI of a most recent PUCCH retransmission, or a combination thereof. In some implementations, UE 210 can forego transmission of the CSI when an initial PUCCH transmission is successful, an PUCCH retransmission is successful, or a combination thereof.

[0055] Fig. 4 is a diagram of an example 400 of transmission and retransmission of a134938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) physical uplink control channel (PUCCH) following expiration of a transmission timer according to one or more implementations described herein. As shown, example 400 includes time represented along a horizontal axis, upward pointing arrows indicating uplink transmissions, downward arrows indicating downlink transmissions, and other events or operations that can occur at UE 210. For example, UE 210 can measure one or more reference signals or beams from base station 222, detect that an event has been triggered (e.g., based on the measurements), and generate UCI for a UEIBR procedure. UE 210 can communicate the UCI via an initial PUCCH transmission. UE 210 can determine and initiate a retransmission timer at or near the same time as the initial PUCCH transmission. A retransmission timer can also be referred to herein as a PUCCH retransmission timer, a transmission timer, a PUCCH transmission timer, and so on.

[0056] As shown, while UE 210 can be configured or scheduled for additional PUCCH occasions, UE 210 can forego using one or more PUCCH occasions so long as the retransmission timer is still running. Upon expiration of the retransmission timer, UE 210 can be configured to retransmit the UCI using a next PUCCH scheduled for UE 210. Subsequent to retransmitting the UEIBR, UE 210 can reinitiate the retransmission timer, which can cause UE 210 to forego retransmitting the UCI until after the retransmission timer expires. However, as shown, UE 210 can additionally, or alternatively, receive DCI from base station 222. The DCI can be received while the retransmission timer is still running or after the retransmission timer has expired. The DCI can include instructions or information, including an uplink grant, to enable UE 210 to communicate a PUSCH carrying a CSI report to base station 222. UE 210 can discontinue the retransmission timer upon receiving the DCI, upon transmitting the CSI report, upon natural expiration of the retransmission timer, or in response to another condition.

[0057] Fig. 5 is a diagram of an example 500 of implementing a transmission timer for PUCCH transmissions following a PUSCH carrying a CSI report according to one or more implementations described herein. As shown, example 500 includes time represented along a horizontal axis, upward pointing arrows indicating uplink transmissions, downward arrows indicating downlink transmissions, and other events or operations that can occur at UE 210. As shown, UE 210 can be configured with periodic PUCCH resources for communicating a 1 -bit Uplink Control Information (UCI) to base station 222 to either request a PUSCH resource for UEIBR report transmission or notify base station 222 of the pre-configured PUSCH resource to be used for the UEIBR report transmission. UE 210 can detect that one or more events are triggered based on the measurement results performed on one or more RSs or beams from base station 222 and can generate a UEIBR based on the measurements. UE 210 can communicate the 1 -bit UCI via an initial PUCCH transmission following detection of the trigger events. UE 210144938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) can retransmit the 1 -bit UCI during one or more subsequent PUCCH retransmission occasions before transmitting the associated UEIBR report on the PUSCH, resulting in many UCI bit retransmissions over a relatively short period of time.

[0058] UE 210 can additionally, or alternatively, receive DCI from base station 222. The DCI can include instructions or information, including an uplink grant, to enable UE 210 to communicate a PUSCH carrying the UEIBR report to base station 222. UE 210 can discontinue retransmission of the 1 -bit UCI upon receiving the DCI, generating the UEIBR report, and / or transmitting the UEIBR report via the PUSCH. Following the transmission of the UEIBR report, UE 210 can initiate a retransmission timer, and while the retransmission timer is still running, UE 210 can refrain from using PUCCH resources for communicating more UEIBRs. Once the PUCCH retransmission timer expires, UE 210 can start to perform the measurements on the one or more RSs used by DL beams from base station 222 to evaluate whether the associated event(s) are triggered.

[0059] Fig. 6 is a diagram of an example 600 of retransmission of a PUCCH following an event evaluation window according to one or more implementations described herein. As shown, example 600 includes time represented along a horizontal axis, upward pointing arrows indicating uplink transmissions, and other events or operations that can occur at UE 210. As shown, UE 210 can be configured with periodic PUCCH resources for communicating UCI for a UEIBR procedure to base station 222. UE 210 can detect one or more trigger events that can cause UE 210 to measure one or more RSs or beams from base station 222 and generate a UEIBR based on the measurements. UE 210 can communicate the UCI via an initial PUCCH transmission following detection of the trigger events.

[0060] UE 210 can determine an evaluation window for determining whether to use a PUCCH retransmission to send the UCI to base station 222. UE 210 can determine a starting time of the evaluation window, a duration of the evaluation window, a number of events occurring within the evaluation window, and time and frequency resources associated with each event. UE 210 can do so based on, at least in part, configuration information received from base station 222 via RRC signaling or another type of signaling or information. As shown, UE 210 can determine that an event evaluation window is disposed between the initial PUCCH transmission and a PUCCH retransmission occasion, and that the event evaluation window includes four measurement occasions (MOs) that UE 210 can use to measure and evaluate a signal strength or other beam characteristics of base station 222. In some implementations, UE 210 can compare the measurements with thresholds or other criteria (e.g., whether just one, all, or a threshold number of measured beams exceed a measurement threshold) to determine whether to use a PUCCH retransmission to send the UCI to base station 222. In some154938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) implementations, the UCI of the PUCCH retransmission can be the same as the UCI of the initial PUCCH transmission. In some implementations, UE 210 can generate a new UCI based, at least in part, on the measurements of the event evaluation window and can use the PUCCH retransmission to send the new UCI to base station 222.

[0061] As shown, UE 210 can proceed to perform similar operations for an event evaluation window between the PUCCH retransmission and another PUCCH retransmission, and so on until UE 210 performs a configured number of PUCCH retransmission, UE 210 receives DCI for an unlink grant and communicates a CSI report via a PUSCH transmission, or another specified event occurs. Additionally, or alternatively, when UE 210 determines that the measurements derived from a measurement occasion fail to satisfy a corresponding set of thresholds or criteria, UE 210 can be configured to discontinue transmissions of a UCI via a PUCCH transmission, use a next PUCCH retransmission to transmit the same UCI as a prior PUCCH transmission (instead of generating new UCI), or skip the next PUCCH transmission and perform an evaluation of events in the following event evaluation window, which could lead to transmission of a new or previous UCI in the following PUCCH transmission occasion.

[0062] Fig. 7 is a diagram of an example 700 of determining an evaluation window for event trigger determination according to one or more implementations described herein. As shown, example 700 includes time represented along a horizontal access, upward pointing arrows indicating uplink transmissions, and other events or operations that can occur at UE 210. As shown, UE 210 can be configured with periodic PUCCH resources for communicating UCI to base station 222. UE 210 can detect one or more trigger events that can cause UE 210 to measure one or more RSs or beams from base station 222 and generate UCI based on the measurements. UE 210 can communicate the UCI via a PUCCH transmission following detection of the trigger events.

[0063] UE 210 can determine a timing window for event evaluation. The timing window can include an amount of time associated with an event evaluation window. UE 210 can determine the timing window for a given PUCCH retransmission (zA) as a time gap according to the following expressions.Start Time of TWt = tt - TPROC - WEnd Time of TWt = tt - TPROC

[0064] 7'IFis a timing window associated with PUCCH transmission or retransmission occasion ti. TPROC is a processing time for the PUCCH transmission, and JU is a length of the164938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) event evaluation window in units of measurement resource occasions (e.g., a number of measurement occasions). W can be determined, at least in part, based on configuration information received by UE 210 from base station 222.

[0065] As shown, UE 210 events (e.g., MOs) outside of the timing window can be disregarded for UEIBR purposes, while events within the timing window can be evaluated. This can include UE 210 measuring beams or signals from base station 222 to determine a quality or strength of each beam or signal. The measurements can be compared to one or more thresholds and / or rules to determine whether a trigger event has occurred. As described herein, a trigger event can cause UE 210 to generate UCI and use a PUCCH transmission to provide base station 222 with the UCI. While example 700 provides an instance of a timing window and trigger event leading to a PUCCH retransmission, a similar technique can be used leading up to the PUCCH transmission or a subsequent (e.g., second, third, etc.) PUCCH retransmission.

[0066] Fig. 8 is a diagram of another example 800 of applying a timing window to event evaluation according to one or more implementations described herein. Example 800 includes time represented along a horizontal axis, upward pointing arrows indicating uplink transmissions, and other events or operations that can occur at UE 210. As shown, UE 210 can be configured with periodic PUCCH resources for communicating UCI to base station 222. UE 210 can detect one or more trigger events that can cause UE 210 to measure one or more RSs or beams from base station 222 and generate UCI based on the measurements. UE 210 can communicate the UCI via a PUCCH transmission or PUCCH retransmission following detection of a trigger event.

[0067] UE 210 can determine a timing window for event evaluation. For example, configuration information received from base station 222 can indicate an event detection timer, an event counter, and an event count maximum or threshold. As shown, UE 210 can be configured to evaluate each event for whether the event amounts to a trigger event (e.g., whether a measured beam or signal exceeds a measurement threshold). Each time UE 210 detects an event trigger, UE 210 can initiate an event detection timer and increase an event counter by one.

[0068] When UE 210 determines that a MO does not amount to an event trigger, UE 210 can forego initiating an event detection timer for the MO and forego increasing the event counter by one. When an event detection timer expires without the event counter reaching or exceeding the event count maximum or threshold, the event counter is decreased by one to account for the expiration of the detection timer. When the value of the event counter reaches or exceeds the event count maximum or threshold, before a corresponding event detection timer has expired, UE 210 can determine that a trigger event has occurred. In such a scenario, UE 210 can generate a UCI based, at least in part, on the measurements collected and proceed to use a next PUCCH174938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) transmission to communicate the UCI to base station 222.

[0069] Fig. 9 is a diagram of another example 900 for resetting a counter for an event evaluation process according to one or more implementations described herein. The event evaluation process can be part of an UEIBR procedure. As shown, example 900 includes timelines represented along horizontal axes, upward pointing arrows indicating uplink transmissions, and other events or operations that can occur at UE 210. Each timeline includes resources for UE 210 to receive a RS (RS#1 and RS#2) and determine corresponding RSRPs for each RS. Base station 222 can use higher layers to provide UE 210 with a measurement RS list, which can include indications of the RSs, the resources of the RSs, the beams of the RSs, etc. In some implementations, one or more of these types of information can be indicated through another type of configuration.

[0070] Base station 222 can transmit the RSs, and UE 210 can be configured to receive and measure the RSs to determine an RSRP and / or one or more other types of characteristics of the RSs. UE 210 can be configured to maintain a counter for each RS and / or beam used to transmit the RS. The measurements can be part of an event evaluation procedure for an UEIBR operation. An event evaluation procedure can include one or more of the operations described herein, such as determining and detecting one or more trigger events, determining an event evaluation window, performing RS measurements, transmitting a PUCCH, implementing a PUCCH retransmission timer, retransmitting a PUCCH, communicating one or more CSI reports via a PUSCH, or any combination thereof. Each time a measurement is taken or an event evaluation procedure is completed, UE 210 can increment a counter for the corresponding RS or beam.

[0071] Base station 222 can use higher layers to provide UE 210 with configuration information that includes a new, updated, or different measurement RS list. In some implementations, UE 210 can be configured to reset counters associated with an RS that is newly added or newly removed by the received measurement RS list. In such a scenario, UE 210 can be configured to refrain from modifying (e.g., can be configured to maintain) the counter for an RS that is not modified by a measurement RS list. Base station 222 can provide UE 210 with a UL grant that allocates resources to a next (e.g., a second) PUSCH in response to a PUCCH carrying a 1 -bit UCI that indicates the associated event(s) are triggered and the corresponding UEIBR report is generated by UE 210. In some implementations, UE 210 can be configured to reset all counters associated with any RS resources configured by RRC signaling for candidate beams. In other implementations, UE 210 can be configured to reset only the counters associated with the UEIBR CSI report(s) that fulfill a corresponding event trigger (or event triggering condition(s)).

[0072] As an example of some implementations, base station 222 can provide UE 210 with configuration information for two RS resources (RS#1 and RS#2) for candidate beam184938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) measurement. The configuration information can be provided via higher layers using RRC signaling. The configuration information can include a counter, or instructions for maintaining a counter, for one or more of the RS resources. For example, UE 210 can be configured with a counter for RS#1 and a counter for RS#2. UE 210 can maintain the counters for RS#1 and RS#2 during event evaluation procedures involving RS#1 and RS#2.

[0073] Upon receiving a new measurement RS list that replaces RS#2 with RS#3, UE 210 can be configured to reset the counter associated with RS#2 but maintain (or refrain from resetting) the counter for RS#1. While not shown, UE 210 can also begin receiving and monitoring RSs from a third beam for RS#3. In some scenarios, CSI reports for RS#1 and RS#2 can be included in a second PUSCH. However, when only the RSRP of RS#1 fulfills the corresponding event triggering criteria (e.g., RSRP is lesser than, equal to, greater than a signal strength threshold), UE 210 can be configured to reset the counter for RS#1 but maintain the counter for RS#3.

[0074] Fig. 10 is a diagram of an example of components of a device according to one or more implementations described herein. In some implementations, device 1000 can include application circuitry 1002, baseband circuitry 1004, RF circuitry 1006, front-end module (FEM) circuitry 1008, one or more antennas 1010, and power management circuitry (PMC) 1012 coupled together at least as shown. In some implementations, device 1000 can include fewer elements (e.g., a RAN node may not utilize application circuitry 1002 and can instead include a processor / controller to process data received from a core network. In some implementations, device 1000 can include additional elements such as, for example, memory / storage, display, camera, sensor (including one or more temperature sensors, such as a single temperature sensor, a plurality of temperature sensors at different locations in device 1000, etc.), or input / output (I / O) interface. In other implementations, the components described below can be included in more than one device (e.g., said circuitries can be separately included in more than one device for cloud-RAN (C-RAN) implementations).

[0075] Application circuitry 1002 can include one or more application processors. For example, application circuitry 1002 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors can be coupled with or can include memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on device 1000. In some implementations, processors of application circuitry 1002 can process data packets received from a core network.

[0076] Baseband circuitry 1004 can include circuitry such as, but not limited to, one or more194938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) single-core or multi-core processors. Baseband circuitry 1004 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of RF circuitry 1006 and to generate baseband signals for a transmit signal path of RF circuitry 1006. Baseband circuity 1004 can interface with application circuitry 1002 for generation and processing of the baseband signals and for controlling operations of RF circuitry 1006. For example, in some implementations, baseband circuitry 1004 can include a 3G baseband processor 1004A, a 4G baseband processor 1004B, a 5G baseband processor 1004C, or other baseband processor(s) 1004D for other existing generations, generations in development or to be developed in the future (e.g., 5G, 6G, 7G, etc.). Baseband circuitry 1004 (e.g., one or more of baseband processors 1004A-D) can handle various radio control functions that enable communication with one or more radio networks via RF circuitry 1006. In other implementations, some or all of the functionality of baseband processors 1004A-D can be included in modules stored in memory 1004G and executed via a central processing unit (CPU) 1004E. The radio control functions can include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some implementations, modulation / demodulation circuitry of baseband circuitry 1004 can include Fast-Fourier Transform (FFT), precoding, or constellation mapping / de-mapping functionality. In some implementations, encoding / decoding circuitry of baseband circuitry 1004 can include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity check (LDPC) encoder / decoder functionality. Implementations of modulation / demodulation and encoder / decoder functionality are not limited to these examples and can include other suitable functionality in other implementations.

[0077] In some implementations, memory 1004G can receive and / or store information and instructions for event evaluation for UEBR. For example, UE 210 can perform an event evaluation procedure in response to detecting an event associated with UEIBR being triggered. UE 210 can generate, in response to the event, an UCI to request resources for an UEIBR transmission. UE 210 can transmit the UCI during an initial PUCCH occasion and can perform retransmission of the UCI in a PUCCH occasion to request the resources for the UEIBR transmission. These and many other features and examples are described herein.

[0078] In some implementations, baseband circuitry 1004 can include one or more audio digital signal processor(s) (DSP) 1004F. Audio DSP 1004F can include elements for compression / decompression and echo cancellation and can include other suitable processing elements in other implementations. Components of baseband circuitry 1004 can be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some implementations. In some implementations, some or all of the constituent components of204938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) baseband circuitry 1004 and application circuitry 1002 can be implemented together such as, for example, on a system on a chip (SOC).

[0079] In some implementations, baseband circuitry 1004 can provide for communication compatible with one or more radio technologies. For example, in some implementations, baseband circuitry 1004 can support communication with a NG-RAN, an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN), etc. Implementations in which baseband circuitry 1004 is configured to support radio communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

[0080] RF circuitry 1006 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various implementations, RF circuitry 1006 can include switches, filters, amplifiers, etc., to facilitate the communication with the wireless network. RF circuitry 1006 can include a receive signal path which can include circuitry to down-convert RF signals received from FEM circuitry 1008 and provide baseband signals to baseband circuitry 1004. RF circuitry 1006 can also include a transmit signal path which can include circuitry to up-convert baseband signals provided by baseband circuitry 1004 and provide RF output signals to FEM circuitry 1008 for transmission.

[0081] In some implementations, the receive signal path of RF circuitry 1006 can include mixer circuitry 1006 A, amplifier circuitry 1006B and filter circuitry 1006C. In some implementations, the transmit signal path of RF circuitry 1006 can include filter circuitry 1006C and mixer circuitry 1006 A. RF circuitry 1006 can also include synthesizer circuitry 1006D for synthesizing a frequency for use by mixer circuitry 1006 A of the receive signal path and the transmit signal path. In some implementations, mixer circuitry 1006 A of the receive signal path can be configured to down-convert RF signals received from FEM circuitry 1008 based on the synthesized frequency provided by synthesizer circuitry 1006D. Amplifier circuitry 1006B can be configured to amplify the down-converted signals and filter circuitry 1006C can be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals can be provided to baseband circuitry 1004 for further processing. In some implementations, the output baseband signals can be zero-frequency baseband signals, although this may not be a requirement. In some implementations, mixer circuitry 1006A of the receive signal path can comprise passive mixers, although the scope of the implementations is not limited in this respect.

[0082] In some implementations, mixer circuitry 1006A of the transmit signal path can be configured to up-convert input baseband signals based on the synthesized frequency provided by214938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) synthesizer circuitry 1006D to generate RF output signals for FEM circuitry 1008. The baseband signals can be provided by baseband circuitry 1004 and can be filtered by filter circuitry 1006C. In some implementations, mixer circuitry 1006 A of the receive signal path and mixer circuitry 1006A of the transmit signal path can include two or more mixers and can be arranged for quadrature down conversion and up conversion, respectively. In some implementations, mixer circuitry 1006 A of the receive signal path and mixer circuitry 1006 A of the transmit signal path can include two or more mixers and can be arranged for image rejection. In some implementations, mixer circuitry 1006 A of the receive signal path and mixer circuitry 1006 A can be arranged for direct down conversion and direct up conversion, respectively. In some implementations, mixer circuitry 1006 of the receive signal path and mixer circuitry 1006 A of the transmit signal path can be configured for super-heterodyne operation.

[0083] In some implementations, the output baseband signals, and the input baseband signals can be analog baseband signals, although the scope of the implementations is not limited in this respect. In some alternate implementations, the output baseband signals, and the input baseband signals can be digital baseband signals. In these alternate implementations, RF circuitry 1006 can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and baseband circuitry 1004 can include a digital baseband interface to communicate with RF circuitry 1006.

[0084] In some dual-mode implementations, a separate radio integrated circuitry can be provided for processing signals for each spectrum, although the scope of the implementations is not limited in this respect. In some implementations, synthesizer circuitry 1006D can be a fractional -N synthesizer or a fractional N / N+l synthesizer, although the scope of the implementations is not limited in this respect as other types of frequency synthesizers can be suitable. For example, synthesizer circuitry 1006D can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0085] Synthesizer circuitry 1006D can be configured to synthesize an output frequency for use by mixer circuitry 1006 A of RF circuitry 1006 based on a frequency input and a divider control input. In some implementations, synthesizer circuitry 1006D can be a fractional N / N+l synthesizer. In some implementations, frequency input can be provided by a voltage-controlled oscillator (VCO). Divider control input can be provided by either baseband circuitry 1004 or the applications circuitry 1002 depending on the desired output frequency. In some implementations, a divider control input (e.g., N) can be determined from a look-up table based on a channel indicated by the applications circuitry 1002.

[0086] Synthesizer circuitry 1006D of RF circuitry 1006 can include a divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some implementations, the224938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) divider can be a dual modulus divider (DMD), and the phase accumulator can be a digital phase accumulator (DPA). In some implementations, the DMD can be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example implementations, the DLL can include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these implementations, the delay elements can be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0087] In some implementations, synthesizer circuitry 1006D can be configured to generate a carrier frequency as the output frequency, while in other implementations, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some implementations, the output frequency can be a LO frequency (fLO). In some implementations, RF circuitry 1006 can include an in-phase / quadrature (I / Q) / polar converter.

[0088] FEM circuitry 1008 can include a receive signal path which can include circuitry configured to operate on RF signals received from one or more antennas 1010, amplify the received signals and provide the amplified versions of the received signals to RF circuitry 1006 for further processing. FEM circuitry 1008 can also include a transmit signal path which can include circuitry configured to amplify signals for transmission provided by RF circuitry 1006 for transmission by one or more of the one or more antennas 1010. In various implementations, the amplification through the transmit or receive signal paths can be done solely in RF circuitry 1006, solely in FEM circuitry 1008, or in both RF circuitry 1006 and FEM circuitry 1008.

[0089] In some implementations, FEM circuitry 1008 can include a transmit / receive switch to switch between transmit mode and receive mode operation. FEM circuitry 1008 can include a receive signal path and a transmit signal path. The receive signal path of FEM circuitry 1008 can include a low noise amplifier to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to RF circuitry 1006). The transmit signal path of FEM circuitry 1008 can include a power amplifier to amplify input RF signals (e.g., provided by RF circuitry 1006), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of one or more antennas 1010).

[0090] In some implementations, PMC 1012 can manage power provided to baseband circuitry 1004. In particular, PMC 1012 can control power-source selection, voltage scaling, battery charging, or direct current (DC) to DC (DC-to-DC) conversion. PMC 1012 can often be included when device 1000 is capable of being powered by a battery, for example, when device234938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) 1000 is included in a UE. PMC 1012 can increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[0091] While Fig. 10 shows PMC 1012 coupled only with baseband circuitry 1004.However, in other implementations, PMC 1012 can be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 1002, RF circuitry 1006, or FEM circuitry 1008.

[0092] In some implementations, PMC 1012 can control, or otherwise be part of, various power saving mechanisms of device 1000. For example, if device 1000 is in an RRC Connected state, where device 1000 is still connected to the RAN node as device 1000 expects to receive traffic shortly, then device 1000 can enter a state known as discontinuous reception mode (DRX) after a period of inactivity. During this state, device 1000 can power down for brief intervals of time and thus save power.

[0093] If there is no data traffic activity for an extended period of time, then device 1000 can transition off to an RRC Idle state, where device 1000 disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. Device 1000 can go into a very low power state and device 1000 can perform paging where again device 1000 periodically can wake up to listen to the network and then power down again. Device 1000 may not receive data in this state; in order to receive data, device 1000 can transition back to RRC Connected state.

[0094] An additional power saving mode can allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device 1000 can be unreachable to the network and can power down completely. Any data sent during this time can incur a large delay and device 1000 can assume the delay is acceptable.

[0095] Processors of application circuitry 1002 and processors of baseband circuitry 1004 can be used to execute elements of one or more instances of a protocol stack. For example, processors of baseband circuitry 1004, alone or in combination, can be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of baseband circuitry 1004 can utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 can comprise a radio resource control layer. As referred to herein, Layer 2 can comprise a medium access control layer, a radio link control layer, and a packet data convergence protocol layer, described in further detail below. As referred to herein, Layer 1 can comprise a physical layer of a UE / RAN node.

[0096] Fig. 11 is a diagram of example interfaces 1100 of baseband circuitry according to one or more implementations described herein. One or more components or features of example244938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) interfaces 1100 can correspond to one or more components or features described above or elsewhere. Baseband circuitry 1104 can comprise processors 1104A, 1104B, 1104C, 1104D, and 1104E and a memory 1104G utilized by said processors. Each of processors 1104 A, 1104B, 1104C, 1104D, and 1104E can include a memory interface, 1106 A, 1106B, 1106C, 1106D, and 1106E, respectively, to send / receive data to / from memory 1104G. Baseband circuitry can be a component of a UE and / or another type of device or system capable of transmitting and / or receiving wireless signals.

[0097] Baseband circuitry 1104 can further include one or more interfaces to communicatively couple to other circuitries / devices, such as memory interface 1112 (e.g., an interface to send / receive data to / from memory external to baseband circuitry 1104), an application circuitry interface 1114 (e.g., an interface to send / receive data to / from the application circuitry as described herein), an RF circuitry interface 1116, a wireless hardware connectivity interface 1118 (e.g., an interface to send / receive data to / from near field communication components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 1120 (e.g., an interface to send / receive power or control signals to / from a PMC).

[0098] Fig. 12 is a block diagram illustrating components, according to some example implementations, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Fig. 12 shows a diagrammatic representation of hardware resources 1200 including one or more processors 1210 (or processor cores), one or more memory / storage devices 1220, and one or more communication resources 1230, each of which can be communicatively coupled via a bus 1240. For implementations where node virtualization or network function virtualization is utilized, a hypervisor can be executed to provide an execution environment for one or more network slices / sub-slices to utilize hardware resources 1200. Hardware resources 1200 can interact with hypervisor 1202. For example, hypervisor 1202 can schedule or otherwise manage hardware resource 1200.

[0099] Processors 1210 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) can include, for example, a processor 1212 and a processor 1214.

[0100] Memory / storage devices 1220 can include main memory, disk storage, or any suitable combination thereof. Memory / storage devices 1220 can include, but are not limited to254938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) any type of volatile or non-volatile memory such as dynamic random-access memory (DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage, etc.

[0101] In some implementations, memory / storage devices 1220 receive and / or store information and instructions 1255 for event evaluation for UEBR. For example, UE 210 can perform an event evaluation procedure in response to detecting an event associated with UEIBR being triggered. UE 210 can generate, in response to the event, an UCI bit to request resources for an UEIBR transmission. UE 210 can transmit the UCI bit during an initial PUCCH occasion and can perform retransmission of the UCI bit in a PUCCH occasion to request the resources for the UEIBR transmission. These and many other features and examples are described herein.

[0102] Communication resources 1230 can include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1204 or one or more databases 1206 via a network 1208. For example, communication resources 1230 can include wired communication components (e.g., for coupling via a universal serial bus), cellular communication components, near field communication components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

[0103] Instructions 1250A, 1250B, 1250C, 1250D, and / or 1250E can comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of processors 1210 to perform any one or more of the methodologies discussed herein. Instructions 1250 can reside, completely or partially, within at least one of processors 1210 (e.g., within a cache memory), memory / storage devices 1220, or any suitable combination thereof.Furthermore, any portion of instructions 1250A-E can be transferred to hardware resources 1200 from any combination of peripheral devices 1204 or databases 1206. Accordingly, memory of processors 1210, memory / storage devices 1220, peripheral devices 1204, and databases 1206 are examples of computer-readable and machine-readable media.

[0104] Fig. 13 is a diagram of an example process 1300 for event evaluation for UE-initiated beam reporting according to one or more implementations described herein. As shown, process 1300 can be implemented by UE 210 and / or baseband circuitry 1004. In some implementations, some or all of process 1300 can be performed by one or more other systems or devices, including one or more of the devices of Fig. 2. Additionally, process 1300 can include one or more fewer, additional, differently ordered and / or arranged operations than those shown in Fig. 13. In some implementations, some or all of the operations of process 1300 can be performed independently, successively, simultaneously, etc., of one or more of the other operations of process 1300. As264938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) such, the techniques described herein are not limited to the number, sequence, arrangement, timing, etc., of the operations or processes depicted in Fig. 13.

[0105] As shown, process 1300 can include detecting a trigger event associated with UE-initiated beam reporting (UEIBR) (block 1310). Process 1300 can include generating, in response to the trigger even being detected, a UEIBR transmission for an initial physical uplink control channel (PUCCH) occasion (block 1320). Process 1300 can include generating a UEIBR retransmission for a PUCCH retransmission occasion (block 1330). One or more of the examples described herein can also, or alternatively, be part of process 1300.

[0106] Examples herein can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including executable instructions that, when performed by a machine (e.g., a processor (e.g., processor, etc.) with memory, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or the like) cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to implementations and examples described.

[0107] In example 1, which can also include one or more of the examples described herein, a user equipment (UE) can comprise: a memory configured to store one or more instructions; and one or more processors configured to, when executing the one or more instructions, cause the UE to: detect that at least one event associated with UE-initiated beam reporting (UEIBR) is triggered; generate, in response to the at least one event, uplink control information (UCI) to request resources for an UEIBR transmission; transmit the UCI during an initial physical uplink control channel (PUCCH) occasion; and perform at least one retransmission of the UCI in a PUCCH retransmission occasion to request the resources for the UEIBR transmission.

[0108] In example 2, which can also include one or more of the examples described herein, the one or more processors are configured to: initiate, in response to transmission of the UCI in the initial PUCCH occasion, a PUCCH retransmission timer during which the UCI associated with the UEIBR transmission is not retransmitted in any PUCCH retransmission occasion, and the at least one retransmission of the UCI in the PUCCH retransmission occasion is performed upon expiration of the PUCCH retransmission timer.

[0109] In example 3, which can also include one or more of the examples described herein, a UEIBR report associated with the retransmitted UCI is transmitted in a physical uplink shared channel (PUSCH) occasion while the PUCCH retransmission timer is running.

[0110] In example 4, which can also include one or more of the examples described herein, the one or more processors are configured to: initiate, in response to the UEIBR transmission using a physical uplink shared channel (PUSCH) occasion after the UCI transmission in the274938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) initial PUCCH occasion, a PUCCH retransmission timer during which the UCI associated with the UEIBR transmission is not retransmitted in any PUCCH retransmission occasion.[oni] In example 5, which can also include one or more of the examples described herein, multiple PUCCH retransmission occasions of the UCI occur after the initial PUCCH occasion and before the PUSCH occasion carrying the UEIBR associated with the UCI, conditional upon detection of an additional trigger event for a PUCCH retransmission occasion or without detection of an additional trigger event for a PUCCH retransmission occasion.

[0112] In example 6, which can also include one or more of the examples described herein, the UEIBR transmission, corresponding to the at least one event, is transmitted using a physical uplink shared channel (PUSCH) associated with an uplink grant that is requested by the UCI.

[0113] In example 7, which can also include one or more of the examples described herein, the one or more processors are configured to: determine whether to generate the at least one UCI retransmission in a PUCCH retransmission occasion by performing an event evaluation procedure comprising a determination of whether one or more trigger events occur within a corresponding evaluation window that is associated with the PUCCH retransmission occasion.

[0114] In example 8, which can also include one or more of the examples described herein, the UEIBR transmission, corresponding to the at least one event, is transmitted using a physical uplink shared channel (PUSCH) associated with an uplink grant, and a channel state information (CSI) report of the PUSCH comprises measurement results that are obtained during an event evaluation procedure that is associated with the initial PUCCH occasion.

[0115] In example 9, which can also include one or more of the examples described herein, the event evaluation procedure is associated with the initial PUCCH occasion of the UCI is the only event evaluation procedure for the PUCCH retransmission when the UCI is transmitted in a subsequent PUCCH retransmission occasion.

[0116] In example 10, which can also include one or more of the examples described herein, the at least one measurement result included in the UEIBR transmission corresponds to measurement results that are obtained during the event evaluation procedure associated with a most recent PUCCH retransmission occasion satisfying the one or more event conditions of the event.

[0117] In example 11, which can also include one or more of the examples described herein, the UEIBR transmission is not transmitted using the PUSCH when at least of the measurement results that are obtained during the event evaluation procedure associated with the most recent PUCCH retransmission occasion before the uplink grant do not fulfil the one or more event conditions.

[0118] In example 12, which can also include one or more of the examples described herein,284938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) the measurement results of the UEIBR report comprise one or more layer 1 (LI) reference signal received power (RSRP) measured on a corresponding reference signal (RS) used by a candidate beam.

[0119] In example 13, which can also include one or more of the examples described herein, the CSI report comprises a 1 -bit indication for a beam that indicates whether a measured Ll-RSRP of a corresponding reference signal of the beam satisfies the one or more trigger events associated with the most recent PUCCH retransmission.

[0120] In example 14, which can also include one or more of the examples described herein, a time window for the event evaluation procedure is determined based on the PUCCH retransmission occasion and a processing time of the PUCCH retransmission.

[0121] In example 15, which can also include one or more of the examples described herein, a time window for the event evaluation procedure is determined based on the one or more trigger events being satisfied, satisfaction of the event evaluation procedure is based on an event counter for the one or more trigger events being equal to or greater than an event counter threshold, and the at least one UCI retransmission occurs in response to satisfaction of the event evaluation procedure.

[0122] In example 16, which can also include one or more of the examples described herein, the one or more trigger events are associated with a first reference signal used by a beam indicated in a measurement reference signal list and the event counter is reset in response to receiving an updated measurement reference signal list that does not include the first reference signal.

[0123] In example 17, which can also include one or more of the examples described herein, the one or more trigger events are associated with measuring a reference signal (RS) in a reference signal list and the event counter associated with any RS in the list is reset in response to receiving radio resource control (RRC) signaling comprising configuration information for any RS in the RS list.

[0124] In example 18, which can also include one or more of the examples described herein, the one or more trigger events are associated with measuring a reference signal, an uplink grant that allocates resources for a physical uplink shared channel (PUSCH) is received in response to the at least one UCI retransmission, and the event counter(s) that are associated with the UEIBR report(s) in the PUSCH that fulfils the event triggering condition(s) is reset.

[0125] In example 19, which can also include one or more of the examples described herein, the one or more processors are configured to: determine whether to generate the at least one UCI retransmission by performing an event evaluation procedure comprising a determination of whether one or more trigger events occur within a corresponding evaluation window that is294938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) subsequent to a prior UCI retransmission.

[0126] In example 20, which can also include one or more of the examples described herein, a first evaluation window is used for determining whether to generate a first UCI retransmission, a second evaluation window is used for determining whether to generate a second UCI retransmission, and the first evaluation window and the second evaluation window are equal in duration and number of measurement occasions associated with the triggered events.

[0127] In example 21, which can also include one or more of the examples described herein, a first evaluation window is used for determining whether to generate a first UCI retransmission, a second evaluation window is used for determining whether to generate a second UCI retransmission, and the first evaluation window and the second evaluation window are different in duration and / or number of measurement occasions associated with the triggered events.

[0128] In example 22, which can also include one or more of the examples described herein, a first UCI retransmission occasion occurs prior to a second UCI retransmission occasion, a first evaluation window is used for determining whether to generate a first UCI retransmission for the first UCI retransmission occasion, a second evaluation window is used for determining whether to generate a second UCI retransmission for the second UCI retransmission occasion, and the second evaluation window is used for determining whether to generate the second UCI retransmission regardless of whether the first UCI retransmission is generated.

[0129] In example 23, which can also include one or more of the examples described herein, a first UCI retransmission occasion occurs prior to a second UCI retransmission occasion, a first evaluation window is used for determining whether to generate a first UCI retransmission for the first UCI retransmission occasion, a second evaluation window is used for determining whether to generate a second UCI retransmission for the second UCI retransmission occasion, and the second evaluation window is used for determining whether to generate the second UCI retransmission when the first UCI retransmission is not generated.

[0130] In example 24, which can also include one or more of the examples described herein, the UCI comprises a 1 -bit indication to request the resources for the UEIBR transmission.

[0131] In example 25, which can also include one or more of the examples described herein, baseband circuitry can comprise: one or more processors configured to cause the baseband circuitry to: detect that at least one event associated with UE-initiated beam reporting (UEIBR) is triggered; generate, in response to the at least one event, uplink control information (UCI) to request resources for an UEIBR transmission; transmit the UCI during an initial physical uplink control channel (PUCCH) occasion; and perform at least one retransmission of the UCI in a PUCCH retransmission occasion to request the resources for the UEIBR transmission.

[0132] In example 26, which can also include one or more of the examples described herein,304938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) a method, performed by a user equipment (UE), can comprise: detecting that at least one event associated with UE-initiated beam reporting (UEIBR) is triggered; generating, in response to the at least one event, uplink control information (UCI) to request resources for an UEIBR transmission; transmitting the UCI during an initial physical uplink control channel (PUCCH) occasion; and performing at least one retransmission of the UCI in a PUCCH retransmission occasion to request the resources for the UEIBR transmission.

[0133] The above description of illustrated examples, implementations, aspects, etc., of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed aspects to the precise forms disclosed. While specific examples, implementations, aspects, etc., are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such examples, implementations, aspects, etc., as those skilled in the relevant art can recognize.

[0134] In this regard, while the disclosed subject matter has been described in connection with various examples, implementations, aspects, etc., and corresponding Figures, where applicable, it is to be understood that other similar aspects can be used or modifications and additions can be made to the disclosed subject matter for performing the same, similar, alternative, or substitute function of the subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single example, implementation, or aspect described herein, but rather should be construed in breadth and scope in accordance with the appended claims below.

[0135] In particular regard to the various functions performed by the above described components or structures (assemblies, devices, circuits, systems, etc.), the terms (including a reference to a “means”) used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations. In addition, while a particular feature can have been disclosed with respect to only one of several implementations, such feature can be combined with one or more other features of the other implementations as can be desired and advantageous for any given application.

[0136] As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended314938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms “including”, “includes”, “having”, “has”, “with”, or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising.” Additionally, in situations wherein one or more numbered items are discussed (e.g., a “first X”, a “second X”, etc.), in general the one or more numbered items can be distinct, or they can be the same, although in some situations the context can indicate that they are distinct or that they are the same.

[0137] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.324938-6638-2233, v. 3

Claims

Atorney Docket No.: 106842260540 (P71556WO1)CLAIMSWhat is claimed is:

1. A user equipment (UE) comprising:a memory configured to store one or more instructions; andone or more processors configured to, when executing the one or more instructions, cause the UE to:detect that an event associated with UE-initiated beam reporting (UEIBR) is triggered; generate, in response to the event being triggered, uplink control information (UCI) to request resources for an UEIBR transmission;transmit the UCI during an initial physical uplink control channel (PUCCH) occasion; andperform a retransmission of the UCI in a PUCCH retransmission occasion to request the resources for the UEIBR transmission.

2. The UE of claim 1, wherein the one or more processors are configured to:initiate, in response to transmission of the UCI in the initial PUCCH occasion, a PUCCH retransmission timer during which the UCI associated with the UEIBR transmission is not retransmitted in any PUCCH retransmission occasion, and the retransmission of the UCI in the PUCCH retransmission occasion is performed upon expiration of the PUCCH retransmission timer.

3. The UE of claim 2, wherein a UEIBR report associated with the retransmitted UCI is transmited in a physical uplink shared channel (PUSCH) occasion while the PUCCH retransmission timer is running.

4. The UE of claim 1, wherein the one or more processors are configured to:initiate, in response to the UEIBR transmission using a physical uplink shared channel (PUSCH) occasion after the UCI transmission in the initial PUCCH occasion, a PUCCH retransmission timer during which the UCI associated with the UEIBR transmission is not retransmitted in any PUCCH transmission occasion.

5. The UE of claim 4, wherein multiple PUCCH retransmission occasions of the UCI occur after the initial PUCCH occasion and before the PUSCH occasion carrying the UEIBR associated with the UCI, conditional upon detection of an additional trigger event for a PUCCH334938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) retransmission occasion or without detection of an additional trigger event for a PUCCH retransmission occasion.

6. The UE of claim 1, wherein the UEIBR transmission, corresponding to the event, is transmitted using a physical uplink shared channel (PUSCH) associated with an uplink grant that is requested by the UCI.

7. The UE of claim 1, wherein the one or more processors are configured to:determine whether to generate the UCI retransmission in a PUCCH retransmission occasion by performing an event evaluation procedure comprising a determination of whether one or more trigger events occur within a corresponding evaluation window that is associated with the PUCCH retransmission occasion.

8. The UE of claim 7, wherein the UEIBR transmission, corresponding to the event, is transmitted using a physical uplink shared channel (PUSCH) associated with an uplink grant, and a channel state information (CSI) report of the PUSCH comprises measurement results that are obtained during an event evaluation procedure that is associated with the initial PUCCH occasion.

9. The UE of claim 8, wherein the event evaluation procedure associated with the initial PUCCH occasion of the UCI is an only event evaluation procedure for the PUCCH retransmission when the UCI is transmitted in a subsequent PUCCH retransmission occasion.

10. The UE of claim 8, wherein at least one measurement result included in the UEIBR transmission corresponds to measurement results that are obtained during the event evaluation procedure associated with a most recent PUCCH retransmission occasion satisfying one or more event conditions of the event.

11. The UE of claim 10, wherein the UEIBR transmission is not transmitted using the PUSCH when at least one of the measurement results that are obtained during the event evaluation procedure associated with the most recent PUCCH retransmission occasion before the uplink grant does not fulfil the one or more event conditions.344938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) 12. The UE of claim 10, wherein the measurement results of the UEIBR report comprise one or more layer 1 (LI) reference signal received power (RSRP) measured on a corresponding reference signal (RS) used by a candidate beam.

13. The UE of claim 10, wherein the CSI report comprises a 1 -bit indication for a beam that indicates whether a measured Ll-RSRP of a corresponding reference signal of the beam satisfies the one or more trigger events associated with the most recent PUCCH retransmission.

14. The UE of claim 7, wherein a time window for the event evaluation procedure is determined based on the PUCCH retransmission occasion and a processing time of the PUCCH retransmission.

15. The UE of claim 7, wherein a time window for the event evaluation procedure is determined based on the one or more trigger events being satisfied, satisfaction of the event evaluation procedure is based on an event counter for the one or more trigger events being equal to or greater than an event counter threshold, and the UCI retransmission occurs in response to satisfaction of the event evaluation procedure.

16. The UE of claim 15, wherein the one or more trigger events are associated with a first reference signal used by a beam indicated in a measurement reference signal list and the event counter is reset in response to receiving an updated measurement reference signal list that does not include the first reference signal.

17. The UE of claim 15, wherein the one or more trigger events are associated with measuring a reference signal (RS) in a reference signal list and the event counter associated with any RS in the list is reset in response to receiving radio resource control (RRC) signaling comprising configuration information for any RS in the RS list.

18. The UE of claim 15, wherein the one or more trigger events are associated with measuring a reference signal, an uplink grant that allocates resources for a physical uplink shared channel (PUSCH) is received in response to the UCI retransmission, and the event counter(s) that are associated with the UEIBR report(s) in the PUSCH that fulfils the event triggering condition(s) is reset.354938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) 19. The UE of claim 1, wherein the one or more processors are configured to:determine whether to generate the UCI retransmission by performing an event evaluation procedure comprising a determination of whether one or more trigger events occur within a corresponding evaluation window that is subsequent to a prior UCI retransmission.

20. The UE of claim 1, wherein a first evaluation window is used for determining whether to generate a first UCI retransmission, a second evaluation window is used for determining whether to generate a second UCI retransmission, and the first evaluation window and the second evaluation window are equal in duration and number of measurement occasions associated with the triggered events.

21. The UE of claim 1, wherein a first evaluation window is used for determining whether to generate a first UCI retransmission, a second evaluation window is used for determining whether to generate a second UCI retransmission, and the first evaluation window and the second evaluation window are different in duration and / or number of measurement occasions associated with the triggered events.

22. The UE of claim 1, wherein a first UCI retransmission occasion occurs prior to a second UCI retransmission occasion, a first evaluation window is used for determining whether to generate a first UCI retransmission for the first UCI retransmission occasion, a second evaluation window is used for determining whether to generate a second UCI retransmission for the second UCI retransmission occasion, and the second evaluation window is used for determining whether to generate the second UCI retransmission regardless of whether the first UCI retransmission is generated.

23. The UE of claim 1, wherein a first UCI retransmission occasion occurs prior to a second UCI retransmission occasion, a first evaluation window is used for determining whether to generate a first UCI retransmission for the first UCI retransmission occasion, a second evaluation window is used for determining whether to generate a second UCI retransmission for the second UCI retransmission occasion, and the second evaluation window is used for determining whether to generate the second UCI retransmission when the first UCI retransmission is not generated.

24. The UE of claim 1, wherein the UCI comprises a 1 -bit indication to request the resources for the UEIBR transmission.364938-6638-2233, v. 3Attorney Docket No.: 106842260540 (P71556WO1) 25. A method, performed by a user equipment (UE), the method comprising:detecting that an event associated with UE-initiated beam reporting (UEIBR) is triggered; generating, in response to the event being triggered, uplink control information (UCI) to request resources for an UEIBR transmission;transmitting the UCI during an initial physical uplink control channel (PUCCH) occasion; and performing a retransmission of the UCI in a PUCCH retransmission occasion to request the resources for the UEIBR transmission.

26. Baseband circuitry comprising:one or more processors configured to cause the baseband circuitry to:detect that an event associated with user equipment (UE)-initiated beam reporting (UEIBR) is triggered;generate, in response to the event being triggered, uplink control information (UCI) to request resources for an UEIBR transmission;transmit the UCI during an initial physical uplink control channel (PUCCH) occasion; andperform a retransmission of the UCI in a PUCCH retransmission occasion to request the resources for the UEIBR transmission.

27. The baseband circuitry of claim 26, the one or more processors further configured to cause the baseband circuitry to:initiate, in response to transmission of the UCI in the initial PUCCH occasion, a PUCCH retransmission timer during which the UCI associated with the UEIBR transmission is not retransmitted in any PUCCH retransmission occasion, and the retransmission of the UCI in the PUCCH retransmission occasion is performed upon expiration of the PUCCH retransmission timer.

28. The baseband circuitry of claim 26, the one or more processors further configured to cause the baseband circuitry to:initiate, in response to the UEIBR transmission using a physical uplink shared channel (PUSCH) occasion after the UCI transmission in the initial PUCCH occasion, a PUCCH retransmission timer during which the UCI associated with the UEIBR transmission is not retransmitted in any PUCCH transmission occasion.374938-6638-2233, v. 3Atorney Docket No.: 106842260540 (P71556WO1) 29. The baseband circuitry of claim 26, wherein the UEIBR transmission, corresponding to the event, is transmitted using a physical uplink shared channel (PUSCH) associated with an uplink grant that is requested by the UCI.

30. The baseband circuitry of claim 26, the one or more processors further configured to cause the baseband circuitry to:determine whether to generate the UCI retransmission by performing an event evaluation procedure comprising a determination of whether one or more trigger events occur within a corresponding evaluation window that is subsequent to a prior UCI retransmission.

31. The baseband circuitry of claim 26, wherein the UEIBR transmission, corresponding to the event, is transmitted using a physical uplink shared channel (PUSCH) associated with an uplink grant, and a channel state information (CSI) report of the PUSCH comprises measurement results that are obtained during an event evaluation procedure that is associated with the initial PUCCH occasion.

32. The baseband circuitry of claim 31, wherein the UCI comprises a 1 -bit indication to request the resources for the UEIBR transmission.384938-6638-2233, v. 3

Images