User equipment-initiated beam reporting for multiple event types

Abstract

The present application relates to devices and components including apparatuses, systems, and methods for user equipment (UE)-initiated beam reporting for multiple events.

Description

USER EQUIPMENT-INITIATED BEAM REPORTING FOR MULTIPLE EVENT TYPESTECHNICAL FIELD

[0001] This application relates generally to communication networks and, in particular, to user equipment-initiated beam reporting for multiple event types.BACKGROUND

[0002] Third Generation Partnership Project (3GPP) Technical Specifications (TSs) define standards for wireless networks. These TSs describe aspects related to signaling traffic through systems that incorporate wireless networks.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1 illustrates a network environment in accordance with some embodiments.

[0004] FIG. 2 illustrates a user equipment (UE) -initiated beam reporting (UEIBR) operation in accordance with some embodiments.

[0005] FIG. 3 illustrates another UEIBR operation in accordance with some embodiments.

[0006] FIG. 4 illustrates another UEIBR operation in accordance with some embodiments.

[0007] FIG. 5 illustrates another UEIBR operation in accordance with some embodiments.

[0008] FIG. 6 illustrates another UEIBR operation in accordance with some embodiments.

[0009] FIG. 7 illustrates another UEIBR operation in accordance with some embodiments.

[0010] FIG. 8 illustrates another UEIBR operation in accordance with some embodiments.

[0011] FIG. 9 illustrates another UEIBR operation in accordance with some embodiments.

[0012] FIG. 10 illustrates another UEIBR operation in accordance with some embodiments.

[0013] FIG. 11 illustrates another UEIBR operation in accordance with some embodiments.

[0014] FIG. 12 illustrates another UEIBR operation in accordance with some embodiments.

[0015] FIG. 13 illustrates another UEIBR operation in accordance with some embodiments.

[0016] FIG. 14 illustrates a physical uplink shared channel (PUSCH) transmission in accordance with some embodiments.

[0017] FIG. 15 illustrates another PUSCH transmission in accordance with some embodiments.

[0018] FIG. 16 illustrates another UEIBR operation in accordance with some embodiments.

[0019] FIG. 17 illustrates an operational flow / algorithmic structure in accordance with some embodiments.

[0020] FIG. 18 illustrates another operational flow / algorithmic structure in accordance with some embodiments.

[0021] FIG. 19 illustrates another operational flow / algorithmic structure in accordance with some embodiments.

[0022] FIG. 20 illustrates another operational flow / algorithmic structure in accordance with some embodiments.

[0023] FIG. 21 illustrates a user equipment in accordance with some embodiments.

[0024] FIG. 22 illustrates a network device in accordance with some embodiments.DETAILED DESCRIPTION

[0025] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrases “A or B” and “A / B” mean (A) , (B) , or (A and B) ; and the phrase “based on A” means “based at least in part on A, ” for example, it could be “based solely on A” or it could be “based in part on A. ”

[0026] The following is a glossary of terms that may be used in this disclosure.

[0027] The term “circuitry” as used herein refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group) , an application specific integrated circuit (ASIC) , a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a complex PLD (CPLD) , a high-capacity PLD (HCPLD) , a structured ASIC, or a programmable system-on-a-chip (SoC) ) , digital signal processors (DSPs) , etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

[0028] The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, or transferring digital data. The term “processor circuitry” may refer an application processor, baseband processor, a central processing unit (CPU) , a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, or functional processes.

[0029] The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I / O interfaces, peripheral component interfaces, network interface cards, or the like.

[0030] The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term “user equipment” or “UE” may include any type of wireless / wired device or any computing device including a wireless communications interface.

[0031] The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” or “system” may refer to multiple computer devices or multiple computing systems that are communicatively coupled with one another and configured to share computing or networking resources.

[0032] The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor / CPU time, processor / CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input / output operations, ports or network sockets, channel / link allocation, throughput, memory usage, storage, network, database and applications, workload units, or the like. A “hardware resource” may refer to compute, storage, or network resources provided by physical hardware element (s) . A “virtualized resource” may refer to compute, storage, or network resources provided by virtualization infrastructure to an application, device, system, etc. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices / systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0033] The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with or equivalent to “communications channel, ” “data communications channel, ” “transmission channel, ” “data transmission channel, ” “access channel, ” “data access channel, ” “link, ” “data link, ” “carrier, ” “radio-frequency carrier, ” or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices for the purpose of transmitting and receiving information.

[0034] The terms “instantiate, ” “instantiation, ” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.

[0035] The term “connected” may mean that two or more elements, at a common communication protocol layer, have an established signaling relationship with one another over a communication channel, link, interface, or reference point.

[0036] The term “network element” as used herein refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to or referred to as a networked computer, networking hardware, network equipment, network node, virtualized network function, or the like.

[0037] The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content. An information element may include one or more additional information elements.

[0038] FIG. 1 illustrates a network environment 100 in accordance with some embodiments. The network environment 100 may include a UE 104 coupled with a base station (BS) 108 of a radio access network (RAN) 110 that provides one or more serving cells. In some embodiments, the BS 108 is a gNB that provides one or more 3GPP NR cells. The air interface over which the UE 104 and the base station 108 communicate may be compatible with 3GPP technical specifications (TSs) , such as those that define 5G NR or later system standards (e.g., Sixth Generation (6G) standards) . RAN 110 may include a number of base stations (e.g., the base stations 108 and 118) that provide services to various UEs through serving cells.

[0039] Operations described herein as being performed by a device (for example, the UE 104 or the base station 108) may be fully, substantially, or partially performed by processor circuitry of the device.

[0040] The network environment 100 may further include a core network 112 to couple the RAN 110 to an external data network 120. For example, the core network 112 may comprise a 5th Generation Core network (5GC) or later generation core network. The core network 112 may be coupled to the base station 108 via a fiber optic or wireless backhaul. The core network 112 may provide functions for the UE 104 via the base station 108. These functions may include managing subscriber profile information, subscriber location, authentication of services, or switching functions for voice and data sessions.

[0041] In embodiments, the UE 104 supports carrier aggregation (CA) , whereby the UE 104 may connect and exchange data simultaneously over multiple component carriers (CCs) with the base station 108 and / or the base station 118. The CCs may belong to the same frequency band, in which case they are referred to as intra-band CCs. Intra-band CCs may be contiguous or non-contiguous. The CCs may also belong to different frequency bands, in which case they are referred to as inter-band CCs. A serving cell may be configured for the UE 104 to use a CC. A serving cell may be a primary cell (PCell) , a primary secondary cell (PSCell) , or a secondary cell (SCell) . Multiple SCells may be activated via an SCell activation procedure. The CCs of these serving cells may be intra-band contiguous, intra-band non-contiguous, or inter-band. The serving cells may be collocated or non-collocated.

[0042] The RAN 110 and UE 104 may perform various beam management procedures to identify and maintain a set of desired beams for uplink and downlink communications. Beam management may be performed using various reference signals. Downlink reference signals may include, for example, synchronization signal blocks (SSBs) and / or channel state information (CSI) -reference signals (CSI-RSs) . Uplink reference signals may include, for example, sounding reference signals (SRSs) .

[0043] In legacy beam management procedures, a network may configure / activate frequent periodic or semipersistent beam reporting (for example, to report the N best beams and corresponding layer 1 (L1) -reference signal received powers (RSRPs) ) or trigger frequent aperiodic beam reporting to timely acquire the best / preferred beam for data / control transmissions. However, this may result in a large overhead in terms of both uplink reporting and control signaling. Furthermore, if less frequent beam reporting is configured, the network may not be able to acquire the ‘best / preferred’ beam (s) as the beam reporting by the UE may be outdated, thus leading to performance degradation.

[0044] Given that the UE 104 has better and more timely knowledge of beam quality changes, some embodiments describe a UE-initiated beam reporting (UEIBR) procedure that can lead to more timely beam reports and reduce reporting overhead. Two modes for UEIBR may be supported, referred to as Mode A and Mode B. In Mode A, the UE 104 use a first uplink (UL) channel (e.g., a physical uplink control channel (PUCCH) ) to transmit an indication that one or more triggering events have occurred and to request a resource for a second UL channel to carry corresponding beam reports, e.g., channel state information (CSI) reports. As used herein, the first UL channel may also be referred to as a trigger indication (TI) channel and the second UL channel may be referred to CSI reporting (CR) channel. The TI channel transmission may include a single bit or multiple bits to provide the trigger indication (s)  / request, and may include any suitable format, such as a scheduling request (SR) or a new uplink control information (UCI) type. The UE 104 then detects a downlink control information (DCI) format (e.g., transmitted by the base station 108) that indicates the resource for the CR channel. The UE 104 then transmits the beam report in the CR channel. The CR channel may be, for example, a PUCCH and / or a physical uplink shared channel (PUSCH) . Accordingly, Mode A enables dynamic scheduling of the beam report by the base station.

[0045] In Mode B, the UE 104 uses a pre-configured resource for the CR channel. The CR channel of Mode B operation may include, for example, a configured grant (CG) -PUSCH. The UE 104 may use the TI channel to transmit trigger indication (s) to the base station 108 and the base station 108 will the expect beam report (s) to be transmitted using the CR channel. The UE 104 then transmits the beam report (s) using the CR channel. The UE 104 may receive configuration information to configure resources for reporting occasions in which the UE 104 may send the beam report (s) . However, the UE 104 may not send beam report (s) in a given reporting occasion unless corresponding triggering event (s) occur. Accordingly, the notification in the TI channel indicates to the base station 108 that the reporting occasion will actually be used. The base station 108 may use this information for scheduling decisions. For example, if a reporting occasion will not be used for a beam report, the base station 108 may schedule another communication with the UE 104 and / or another UE in the corresponding resource.

[0046] The UE 104 may initiate a beam report based on occurrence of one or more triggering events. For example, the UE 104 may measure multiple beams of a serving cell, including an active beam and one or more candidate beams. Different triggering events may have different event types. An event having a first event type, referred to as Event-1, may occur if a quality of a current beam is worse than a certain threshold. An event having a second event type, referred to as Event-2, may occur if a quality of at least one new beam becomes a threshold value better than a current beam. An event having a third event type, referred to as Event-7, may occur if a quality of at least one new beam becomes a threshold value better than a reference signal (RS) derived from an activated transmission configuration indicator (TCI) state with the Mth best quality, which may be configured by RRC signal. The beam qualities may be based on measurements such as, for example, Layer 1 (L1) –reference signal received power (RSRP) measurements.

[0047] As discussed above, the UE 104 may communicate simultaneously with multiple serving cells, e.g., using CA. This may lead to a scenario in which a beam report may be triggered based on one or more events distributed across multiple cells during a same time period. Various embodiments herein provide techniques for supporting UEIBR when multiple events are simultaneously triggered for multiple serving cells in a CA deployment scenario. While some embodiments describe the events being configured, monitored, or triggered across multiple CCs in a CA case, the disclosed concepts are equally applicable to embodiments in which multiple events are configured, monitored, or triggered on a single CC.

[0048] FIG. 2 illustrates a UEIBR operation 200 in accordance with some embodiments. For the UEIBR operation 200, the UE 104 may be configured for CA with a primary serving cell (PCell) and additional serving cells added to enhance capacity, for example, serving cell #1 and serving cell #2. Each serving cell may be configured on a respective CC. Serving cells #1 and #2 may be, for example, SCells. The UE 104 may receive a UEIBR configuration that configures a plurality of events across the serving cells. In particular, as shown, the PCell and serving cell #1 may each be configured with two events, while serving cell #2 may be configured with one event. Thus, the UE 104 may be configured with five events distributed across three serving cells: <Event-1, PCell> ; <Event-2, PCell> ; <Event-2, Serving cell #1> ; <Event-7, Serving cell #1> ; and <Event-1, Serving cell #2> .

[0049] When one or more of the events are triggered, the UE 104 may generate a PUCCH transmission 204 within the TI channel that is sent to indicate one or more events have been triggered. Subsequently, the UE 104 may generate a PUSCH transmission 208 within the CR channel to provide the network with at least one CSI report corresponding to the one or more triggered events.

[0050] A variety of approaches may be considered for UEIBR when multiple events are configured either on a single CC or on different CCs in a CA use case.

[0051] According to a first aspect of the disclosure, the TI channel may have a PUCCH format 2, 3, or 4. This may allow the PUCCH transmission 204 to carry K bits, where each bit is associated with an event. Each event may be identified based on an event-type index X and a serving cell index Y, e.g., <Event type index X, Serving cell index Y>. The value K may correspond to the total number of UEIBR events configured to be monitored across a group of CCs, e.g., K = 5 in FIG. 2.

[0052] In some embodiments, a group of CCs or a group of events may be associated with the TI channel through a TI channel mapping. If multiple groups of CCs / events are defined, they may be mapped to more than one TI channel as will be described in further detail herein. The TI channel mapping may be predefined or configured by radio resource control (RRC) signaling. If a TI channel mapping is not configured, all events / CCs may be associated with one TI channel.

[0053] In some embodiments, the mapping between the events / CCs and a bitmap of the K bits in the PUCCH transmission 204 may be determined in accordance with one or more of the following options.

[0054] In a first option, the mapping may be implicitly defined based on an ordering rule predefined in, for example, a 3GPP TS. For example, the events may be ordered first in increasing order of CC index and second in increasing order of event type index. For example, with respect to the five events depicted in FIG. 2, they would be ordered as: <Event-1, PCell> ; <Event-2, PCell> ; <Event-2, Serving cell #1> ; <Event-7, Serving cell #1> ; and <Event-1, Serving cell #2> .

[0055] In a second option, the mapping between events / CCs and the bitmap may be explicitly configured in RRC signaling for each event (e.g., each pair of <event type index X, serving cell index Y> ) .

[0056] In the bitmap of the PUCCH transmission 204, a value of ‘1’ may indicate the associated event (e.g., <event type index X, serving cell index Y> ) is triggered; and a value of ‘0’ may indicate the associated event is not triggered.

[0057] FIG. 3 illustrates a UEIBR operation 300 in accordance with some embodiments. In UEIBR operation 300, the UE 104 may be configured in a manner similar to that described above with respect to UEIBR operation 200. For example, a UEIBR configuration may configure five events to monitor over three serving cells. The UE 104 may generate PUCCH transmission 304 using the TI channel. The PUCCH transmission may include a bitmap 306. In this embodiment, no CC grouping is configured, so the bitmap 306 may include bits that correspond to each event the UE 104 is configured to monitor. Assuming the mapping between the events and the bitmap 306 is as described above, for example, events are ordered first in increasing order of CC index and second in increasing order of event type index, the first event ( <Event-1, PCell> ) may correspond to b1, the second event ( <Event-2, PCell> ) may correspond to b2, the third event ( <Event-2, Serving cell #1> ) may correspond to b3, the fourth event ( <Event-7, Serving cell #1> ) may correspond to b4, and the fifth event ( <Event-1, Serving cell #2> ) may correspond to b5.

[0058] FIG. 4 illustrates a UEIBR operation 400 in accordance with some embodiments. In UEIBR operation 400, the UE 104 may be configured in a manner similar to that described above with respect to UEIBR operation 200. For example, a UEIBR configuration may configure five events to monitor over three serving cells. In this embodiment, the three CCs may be grouped into two groups (CC group #1 and CC group #2) for TI channel mapping. CC group #1 may correspond to the PCell and include the first two events (for example, <Event-1, PCell> and <Event-2, PCell> ) ; and CC group #2 may correspond to the other serving cells and include the last three events (for example, <Event-2, Serving cell #1> , <Event-7, Serving cell #1> , and <Event-1, Serving cell #2> .

[0059] The TI channel mapping may map CC group #1 to TI channel #1 and map CC group #2 to TI channel #2. The UE 104 may then generate different PUCCH transmissions with different bitmaps for the two different CC groups. For example, the UE 104 may generate a 1st PUCCH transmission 404 with bitmap 406 corresponding to CC group #1 and may generate 2nd PUCCH transmission 408 with bitmap 410 corresponding to CC group #1. Assuming the mapping between the events and the bitmap 306 is as described above, for example, events are ordered first in increasing order of CC index and second in increasing order of event type index, the first event ( <Event-1, PCell> ) may correspond to b1 of bitmap 406; the second event ( <Event-2, PCell> ) may correspond to b2 of bitmap 406; the third event ( <Event-2, Serving cell #1> ) may correspond to b3 of the bitmap 410, the fourth event ( <Event-7, Serving cell #1> ) may correspond to b4 of bitmap 410, and the fifth event ( <Event-1, Serving cell #2> ) may correspond to b5 of bitmap 410.

[0060] For transmission of the report using the CR channel, different techniques may be used for embodiments that use Mode A reporting as opposed to those that use Mode B reporting.

[0061] FIG. 5 illustrates a UEIBR operation 500 using Mode A reporting in accordance with some embodiments. In UEIBR operation 500, the UE 104 may be configured in a manner similar to that described above with respect to UEIBR operation 200. For example, a UEIBR configuration may configure five events to monitor over three serving cells. Further, like UEIBR operation 300, no CC grouping is configured and all five events are associated with PUCCH transmission 504 of the TI channel. For UEIBR operation 500, the TI channel is mapped to the CR channel in a one-to-one manner. Thus, the PUSCH transmission 508 will carry CSI reports corresponding to each event that is indicated as triggered by the bitmap 506 of the PUCCH transmission 504. For example, the PUSCH transmission 508 may include O CSI reports, where O equals a number of ‘1’ values in the K-bit bitmap 506 transmitted in the associated PUCCH transmission 504. As shown, the PUSCH transmission 508 may include CSI report #1, CSI report #2, ..., CSI report #O, where CSI report #O is associated with the Oth bit by its ordinal positions among all the bits set to ‘1’ in the bitmap 506.

[0062] For Mode B reporting, one or more of the following options may be considered for the PUSCH transmission of the CR channel. As described above, in Mode B reporting, the CR channel may be a CG-PUSCH.

[0063] In a first option, the TI channel is mapped to the CR channel in a one-to-one manner similar to that described above with respect to the UEIBR operation 500. With the first option, the PUCCH transmission may include a K-bit bitmap with O bits set to ‘1. ’ Then, the associated CG-PUSCH transmission may carry O CSI reports respectively corresponding to the O triggered events. In the first option, the CR channel may permit data being multiplexed with the CSI report. For example, uplink-shared channel (UL-SCH) data may be multiplexed in the CG-PUSCH with the CSI reports to increase resource utilization.

[0064] The second option for Mode B reporting may use a 1-to-N mapping between the trigger indications of the TI channel and CR channels. In some embodiments, the mapping may be configured by RRC signaling. In accordance with a first sub-option of the second option, the value N is mandated to be equal to K. In accordance with a second sub-option of the second option, the value N may be set equal to or less than K.

[0065] FIG. 6 illustrates a UEIBR operation 600 using Mode B reporting according to the first sub-option of the second option in accordance with some embodiments. In UEIBR operation 600, the UE 104 may be configured with a UEIBR configuration that configures four events to monitor over a plurality of serving cells. Thus, the PUCCH transmission 604 may include an K-bit bitmap 606, where K=4, to indicate which of the four events are triggered.

[0066] As illustrated in FIG. 6, N = K = 4 and each bit of the bitmap 606 is associated with a respective CR channel. Thus, the UE 104 expects four CG-PUSCH to be configured for Mode B and a 1-to-1 mapping between the four bits of the bitmap 606 and the four CR channels. For example, b1 may correspond to CR channel #1, b2 may correspond to CR channel #2, b3 may correspond to CR channel #3, and b4 may correspond to CR channel #4. If all events are triggered (e.g., all bits of bitmap are set to ‘1’ ) , then the CSI report for each of the four events may be carried by respective PUSCH transmissions, e.g., CSI report for first event may be carried by PUSCH transmission 608a, CSI report for second event may be carried by PUSCH transmission 608b, CSI report for third event may be carried by PUSCH transmission 608c, and CSI report for fourth event may be carried by PUSCH transmission 608d. If one or more of the events are not triggered, the network may re-assign the resources of the corresponding CR channel to the UE 104 for another purpose or to another UE.

[0067] FIG. 7 illustrates a UEIBR operation 700 using Mode B reporting according to the second sub-option of the second option in accordance with some embodiments. In UEIBR operation 700, the UE 104 may be configured with a UEIBR configuration that configures four events to monitor over a plurality of serving cells, similar to UEIBR operation 600. Thus, the PUCCH transmission 704 may include an K-bit bitmap 706, where K = 4, to indicate which of the four events are triggered.

[0068] Given that N ≤ K in the second sub-option, each CR channel may be associated with one or more bits of the bitmap. For example, if N < K, at least one CR channel is associated with more than one bit of the bitmap 706. As shown in FIG. 7, K = 4, N = 2, and a first pair of bits 706a of the bitmap 706 is associated with CR channel #1 and a second pair of bits 706b of the bitmap 706 is associated with CR channel #2. If all events are triggered (e.g., all bits of bitmap 706 are set to ‘1’ ) , then the CSI report for each of the first two events may be carried by PUSCH transmission 708a and the CSI report for each of the last two events may be carried by PUSCH transmission 708b.

[0069] In some embodiments, RRC signaling may be used to formulate the groups of bits and the mapping of the groups to CR channels. In other embodiments, set groupings / mappings may be predefined.

[0070] The second sub-option may reduce overhead, as compared to the first sub-option, which may be based on event probability.

[0071] According to a second aspect of the disclosure, the TI channel may have a PUCCH format 0 or 1. In some embodiments, a second PUCCH format 0 / 1 resources may be configured by RRC signal for TI channel transmissions. This may be done in accordance with one or more of the following options.

[0072] In a first option, each PUCCH resource may be associated with an event (e.g., <event-type #X, serving cell #Y>) and the associations may be configured, for example, by RRC signaling. This may enable use of a one-bit payload for each TI channel transmission and a unified design with a single CC case. The PUCCH format may be limited to PUCCH format 0 and 1 to carry one uplink control information (UCI) bit.

[0073] FIG. 8 illustrates UEIBR operation 800 of the first option of the second aspect in accordance with some embodiments of the disclosure. In UEIBR operation 800, the UE 104 may be configured to monitor five events over a plurality of serving cells.

[0074] FIG. 8 also includes a mapping 810 that respectively maps five PUCCH resources #1–#5 to five configured events. For example, PUCCH resource #1 is mapped to <Event-1, PCell> , PUCCH resource #2 is mapped to <Event-2, PCell> , PUCCH resource #3 is mapped to <Event-2, Serving cell #1> , PUCCH resource #4 is mapped to <Event-7, Serving cell #1> , and PUCCH resource #5 is mapped to <Event-1, Serving cell #2> . Each of the PUCCH resources may correspond to a respective TI channel.

[0075] For a Mode A operation, when a PUCCH transmission is transmitted in an TI channel, indicating a corresponding event has been triggered, the TI channel may be considered as pending. If the CR channel is granted and valid for a UEIBR report, the UEIBR CSI reports associated with the pending TI channels may be concatenated using an ordering that is predefined in a specification or otherwise configured. The UE 104 may then transmit the concatenated CSI reports in a PUSCH transmission of the CR channel.

[0076] With reference to FIG. 8, assume four events are triggered, e.g., those associated with PUCCH resources #1, 3, 4, and 5. In this case, PUCCH transmissions 804a, 804c, 804d, and 804e are each sent using respectively channel resources. PUCCH transmission 804b is not sent as <Event-2, PCell> is not triggered. In this case, the TI channels corresponding to PUCCH resources #1, #3, #4, and #5 are considered pending after associated PUCCH transmissions are sent. The UE 104 may concatenate the four CSI reports corresponding to the triggered events and, once the UE 104 receives an uplink grant from the network, the UE 104 may send the PUSCH transmission 808 with the four CSI reports using the CR channel.

[0077] For Mode B operation of the second aspect, one or more of the following three sub-options may be used.

[0078] In a first sub-option, the UE 104 may utilize a single CG PUSCH for the CR channel to convey CSI reports associated with the pending TI channels. In some embodiments, as described with respect to FIGs. 9 or 10, for example, the CG-PUSCH may be dedicated for UEIBR reports. That is, the UE 104 may not be allowed to multiplex UL-SCH data on the CG-PUSCH. This may enable the base station 108 to receive the PUSCH transmission without having to rely on blind decoding.

[0079] FIG. 9 illustrates a UEIBR operation 900 in accordance with some embodiments. Like UEIBR operation 800, the UE 104 may be configured to monitor five events, each event may be associated with a respective TI channel, and four events may be triggered. In this embodiments, a single CG PUSCH may be used to convey the CSI reports associated with the pending TI channels.

[0080] In this embodiment, a set of CG-PUSCH resources may be configured to the UE 104, for example, CG-PUSCH #1 and CG-PUSCH #2. To transmit all of the UEIBR CSI report bits for the pending TI channels, the UE 104 may select whichever CG-PUSCH resource of the set of configured CG-PUSCH resources that meets the following conditions. The first condition may be that it has the smallest number of resource blocks (RBs) needed to transmit all the UEIBR CSI report bits. For example, if the UEIBR CSI reports require 10 RBs, CG-PUSCH #1 has 15 RBs and CG-PUSCH #2 has 20 RBs, the UE 104 will select CG-PUSCH #1 because it has less RBs that CG-PUSCH #2, but still accommodates the UEIBR CSI reports. The second condition may be that the code rate of the CG-PUSCH is not larger than a threshold configured by an RRC signal received from the network.

[0081] FIG. 10 illustrates a UEIBR operation 1000 in accordance with some embodiments. Like UEIBR operation 900, the UE 104 may be configured to monitor five events, each event may be associated with a respective TI channel, and four events may be triggered. In this embodiment, a single CG PUSCH may be used to convey the CSI reports associated with the pending TI channels.

[0082] In this embodiment, in contrast to UEIBR operation 900, the UE 104 may be provided a single CG-PUSCH #1. However, CG-PUSCH #1 may be configured with a scalable number of RBs as shown in FIG. 10. Similar to UEIBR operation 900, the actual number of RBs of the CG PUSCH #1 may be determined based on the actual UEIBR CSI report bits for the pending TI channels and may fulfill the two conditions above.

[0083] While FIGs. 9 and 10 describe embodiments in which a UE is not allowed to multiplex UL-SCH on the CG-PUSCH, other embodiments may allow the CG-PUSCH to be used for UL-SCH transmissions on the condition that at least one associated PUCCH resource is used for UEIBR transmission.

[0084] In a second sub-option of the second aspect for Mode B operation, a 1-to-1 mapping may be used between each TI channel and CR channel.

[0085] FIG. 11 illustrates a UEIBR operation 1100 of the second sub-option in accordance with some embodiments. The UE 104 may be configured to monitor five events, each event may be associated with a respective TI channel, and four events may be triggered. In this embodiment, each TI channel may be associated with a respective CR channel. For example, TI channel #1 may be associated with CR channel #1, TI channel #2 may be associated with CR channel #2, TI channel #3 may be associated with CR channel #3, TI channel #4 may be associated with CR channel #4, and TI channel #5 may be associated with CR channel #5. As events 1, 3, 4, and 5 are triggered, PUCCH transmissions 1104a, 1104c, 1104d, and 1104e will be sent, and corresponding CSI reports will be sent in PUSCH transmissions 1108a, 1108c, 1108d, and 1108e. As event 2 is not triggered, neither PUCCH transmission 1104b nor PUSCH transmission 1108b are sent.

[0086] In a third sub-option of the second aspect for Mode B operation, the association between the TI channel (s) and CG-PUSCH resources of the CR channel (s) may be configured by RRC signaling. It may be up to the network scheduler (in base station 108, for example) to configure a 1-to-1 mapping or an N-to-1 mapping between the TI channels and the CR channels. In operation, the 1-to-1 mapping may be similar to that described above with respect to UEIBR operation 1100.

[0087] FIG. 12 illustrates a UEIBR operation 1200 of the third sub-option in accordance with some embodiments. The UE 104 may be configured to monitor five events, each event may be associated with a respective TI channel, and four events may be triggered. In this embodiment. In the UEIBR operation 1200, the network may configure the UE 104 with N-to-1 mappings between the TI channels and the CR channels. In particular, a first group that includes the first two TI channels may be mapped to the first CR channel (in a 2-to-1 mapping) while a second group that includes the last three TI channels may be mapped to the second CR channel (in a 3-to-1 mapping) . The CSI reports for the first group (for example, the CSI report associated with PUCCH 1204a) will be sent in PUSCH transmission 1208a using CG-PUSCH #1, and the CSI reports for the second group (for example, the CSI reports associated with PUCCHs 1204c, 1204d, and 1204e) will be concatenated and sent in PUSCH transmission 1208b using CG PUSCH #2.

[0088] In a second option of the second aspect (for example, utilizing PUCCH format 0 or 1 for the TI channel for multiple CC / event configurations) , each PUCCH resource may be associated with K > 1 events (e.g., pairs of <event-type X, serving cell Y>) . The payload size for the CSI report (s) included in the corresponding CR channel may be a fixed size and determined based on a total number of associated events across CCs that are configured by RRC signaling, regardless of the actual number of triggered events for a given transmission in the CR channel. For a single event, the UE 104 may set the corresponding CSI report content as a predefined value (for example, all zeros) if the event is not triggered at the UE side.

[0089] FIG. 13 illustrates a UEIBR operation 1300 that describes utilizing PUCCH format 0 or 1 for the TI channel for multiple CC / event configurations in accordance with some embodiments. The UE 104 may be configured with five events over three CCs similar to UEIBR operation 200. In this embodiment, the TI channel may include a single PUCCH format 0 / 1 resource to carry a 1-bit payload. The TI channel may be paired with one CR channel. As long as one long as at least one event is triggered, the UE 104 transmits 1-bit on the TI channel to notify the network that at least one event has been triggered. The total bits of CSI reports on the PUSCH resource of the CR channel may be computed as OT = O0, 1 +O0, 2 + O1, 2 + O1, 7 + O2, 1, Ox, y represents the CSI report size associated with cell ‘x’ and event-type ‘y’ . PCell is represented as ‘Cell 0. ’A ssuming only Event-1 on PCell and Event-2 on Serving cell #1 are triggered, the UE 104 may set O0, 2, O1, 7, and O2, 1 as all zeros to indicate the events are not triggered.

[0090] In a third option of the second aspect (for example, utilizing PUCCH format 0 or 1 for the TI channel for multiple CC / event configurations) , each PUCCH resource may be associated with K > 1 events (e.g., pairs of <event-type X, serving cell Y>) similar to the second option. However, with the third option, a cap may be set on the number of CSI reports that may be sent in a CR channel. For example, the cap may be set at M CSI reports such that M CSI reports may be selected when O events are triggered at the UE side, where O is less than or equal to K. The value of M may be predefined in, for example, a 3GPP TS, or may be configured by RRC signaling.

[0091] When O > M, a rule may be applied to select the M CSI reports from the O triggered CSI reports. The rule may be set according to one or more of the following options.

[0092] In a first option, a priority order value may be configured by RRC signaling for a CSI report when it is associated with a TI channel that is linked with more than CSI report.

[0093] In a second option, a prioritization rule may be predefined by, for example, a 3GPP TS, for selection of one or more CSI reports from a plurality of CSI reports corresponding to triggered events. The prioritization rule may be defined based on the event-type ID values, CSI report ID values, or cell IDs associated with the triggered report. For example, in one embodiment, , the priority orders for one or more events are determined as follows: (1) first, the event-type ID with smaller value has higher priority; 2) second, for a same event-type ID, the smaller Cell ID has higher priority..

[0094] If the TI channel includes a one-bit indicator, and the associated CR channel includes a subset of the triggered CSI reports, the network may need additional information to determine which CSI reports are actually being transmitted through the CR channel. FIGs. 14 and 15 provide two examples of PUSCH transmissions that may be used to convey CSI reports in accordance with this option.

[0095] FIG. 14 includes PUSCH transmission 1400 in accordance with some embodiments. The PUSCH transmission 1400 includes a bitmap field 1406 and a CSI report section 1408 with up to M CSI reports. The bitmap of the bitmap field 1406 may include a bit for each event (for example, <event-type X, serving cell Y>) that is associated with the corresponding TI channel, for example, K bits. Each bit of the bitmap may indicate whether the CSI report section 1408 includes a CSI report corresponding to the associated event. As the PUSCH transmission 1400 will be limited to carrying M CSI reports, the bitmap will not include more than M bits set to ‘1, ’ or another value to indicate that a corresponding CSI report is included in the CSI reporting section 1408.

[0096] FIG. 15 includes PUSCH transmission 1500 in accordance with some embodiments. The PUSCH transmission 1500 includes an ID field associated with each CSI report. For example, ID field may provide an indication of the event that is associated with the corresponding CSI report. In various embodiments, the ID field may include an event ID or a CSI report ID to indicate the corresponding event. The size of the IDF field may be determined based on a total number of events associated with the TI channel.

[0097] Given that each CSI report may be associated with different report content and payload sizes, and since the network has no idea regarding which M of O events are triggered at the UE side, the network would need to perform blind detection with different hypothetical assumptions. In order to avoid this extra burden on the network, consideration may be given to formatting the total payload size of the CSI reports in addition to bitmap or ID field (s) in order to allow the base station to efficiently receive the transmission.

[0098] In some embodiments, a processor at the UE 104 may first determine a total number of bits of CSI reports transmitted on the 2nd PUSCH is determined as where C1, ..., CM represents the CSI reports in a descending order of CSI report payload sizes across all the reports associated with a single TI channel. For example, C1 is the largest CSI report payload size, C2 is the next largest CSI report payload size, etc.

[0099] The processor may then perform a concatenation of the selected CSI report. For example, up to M selected CSI reports may be concatenated based on the priority order starting from the highest priority, for example, CSI report with first priority order, then second priority order, etc. The number of bits number of the up to M CSI reports that are to be reported may be denoted as Creported.

[0100] The processor may then perform a zero padding operation. For example, the processor may append CP = CT -Creported zero bits to the concatenated CSI report bits, Creported, so that the payload size equals CT. In this manner, blind detection on the CSI reports size may be avoided at the network side.

[0101] FIG. 16 illustrates a UEIBR operation 1600 of the third option of the second aspect in accordance with some embodiments. The UE 104 may be configured with three events over three CCs. All three events may be associated with one TI channel. As shown, the priority order is configured consistent with CC number, with the PCell event having the highest priority and the Serving cell #2 event having the lowest priority.

[0102] When at least one of the configured events is triggered, the UE 104 may transmit PUCCH transmission 1606 having one bit set to indicate at least one of the associated events is triggered. In this embodiment, M = 2 is configured, for example, no more than two CSI reports are to be included in a single CG-PUSCH occasion. The CSI report size for each configured event is as follows: C1 = 20 for <Event-2, PCell>; C2 = 12 for <Event-1, Serving #1>; and C3 = 30 for <Event-7, Serving cell #2>.

[0103] Consider, for example, a situation in which only the events on Serving cell #1 and Serving cell #2 are triggered. In this case, assuming a bitmap is used as the event indicator in the PUSCH transmission 1608, the 3-bit bitmap may be set to ‘011’ to indicate <Event-1, Serving cell #1> and <Event-7, Serving cell #2> are triggered and have CSI reports reported in the PUSCH transmission 1608.

[0104] The processor of the UE 104 may first determine the total bits for CSI reports based on the M largest CSI payload sizes of the configured events. The two largest CSI payload sizes are C1 = 20 and C3 = 30. Thus, the total bits for CSI reports may be set as CT = C1 + C3 = 50 bits. Next, the processor of the UE 104 may concatenate CSI reports that are actually to be reported, that is, the CSI reports for <Event-1, Serving cell #1> and <Event-7, Serving cell #2>. The payload size of the CSI reports that are to be reported (up to M CSI reports) may then be determined as Creported = C2 + C3 = 42 bits. The processor may then determine the zero padding bits to be added as follows: CP = CT -Creported = 8 bits. Thus, 8 zero padding bits are added to the 42 bits to get the 50-bit CSI payload. The total payload of the PUSCH transmission 1608 may then be the 50-bit CSI payload plus the 3-bit event indicator = 53 bits.

[0105] FIG. 17 is an operational flow / algorithmic structure 1700 for UEIBR with plural serving cells and events in accordance with some embodiments. The operational flow / algorithmic structure 1700 may be implemented by a UE such as, for example, UE 104, UE 2100 (shown in FIG. 21 and discussed further below) , or components thereof; for example, a baseband processor 2104A.

[0106] The operational flow / algorithmic structure 1700 may include, at 1704, receiving a UEIBR configuration. The UEIBR configuration may be received from a network via RRC signaling. The UEIBR configuration may configure the UE / processor to monitor a plurality of events on one or component carriers. The UIEBR configuration may associate the plurality of events with one TI channel, and the one TI channel may be associated with one SR channel. In this embodiment, the TI channel may be a PUCCH format 0 / 1.

[0107] The operational flow / algorithmic structure 1700 may further include, at 1708, monitoring the plurality of events based on the UEIBR configuration. The events may be Event-1, Event-2, or Event-7 events distributed over various serving cells (e.g., PCells and one or more SCells) .

[0108] The operational flow / algorithmic structure 1700 may further include, at 1712, identifying a maximum number of CSI reports to report. The maximum number, which may be predefined or configured by RRC signaling, may limit a number of CSI reports that can be reported in one SR channel.

[0109] The operational flow / algorithmic structure 1700 may further include, at 1716, determining one or more events are triggered. The one or more events may be events of the plurality of events that are being monitored based on the UIEBR configuration.

[0110] The operational flow / algorithmic structure 1700 may further include, at 1720, selecting a number of events for reporting. The number of events for reporting may be equal to or less than the maximum number. Consider, for example, that five events are to be monitored and the maximum number is set at three. If the UE / processor determines that three or less events are triggered, then the UE / processor may be able to select all of the events for reporting. However, if the UE / processor determines that more than three events are triggered, the UE / processor will have to select a subset of the triggered events for reporting. In some embodiments, selection of the subset may be based on priority values associated with each event. The priority values may be based on a predefined prioritization rule or a priority order value configured by RRC signaling.

[0111] The operational flow / algorithmic structure 1700 may further include, at 1724, generating a PUCCH transmission for the TI channel. After generating the PUCCH transmission, the UE / processor may output it for transmission to the network. The PUCCH transmission for the TI channel may be a PUCCH format 0 / 1 and, therefore, only have a one-bit indicator. This bit may indicate that at least one of the plurality of events monitored by the UE / processor has been triggered.

[0112] The operational flow / algorithmic structure 1700 may further include, at 1728, generating a PUSCH transmission for the SR channel that is associated with the TI channel. After generating the PUSCH transmission, the UE / processor may output it for transmission to the network. The PUSCH transmission may include the CSI reports corresponding the number of events selected for reporting. The PUSCH transmission may also include one or more event indicator fields to indicate which CSI reports are included in the PUSCH transmission. The one or more event indicator fields may include a bitmap that includes a plurality of bits that respectively correspond to the plurality of events that are monitored. In this case, each bit of the plurality of bits is set to indicate whether a CSI report of a corresponding event is included in the PUSCH transmission. In another embodiment, the one or more event indicator fields includes a number of event indicator fields that respectively correspond to the number of CSI reports. In this case, each event indicator field includes an identifier (ID) that identifies the event of the number of events that corresponds to the associated CSI report.

[0113] In some embodiments, UE / processor may determine the CSI payload size of the PUSCH transmission based on the maximum number of events associated with largest CSI payload sizes. For example, if five events are monitored and the maximum number is three, the UE / processor may select the three events that are associated with the largest CSI payload sizes and set the CSI payload to accommodate those reports (even if those reports are not the ones actually selected for transmission) . If the selected reports do not take up the entire CSI payload size, the UE / processor may add padding bits (for example, bits set to zero) in order to fill out the CSI payload size. The total payload size of the PUSCH transmission may include the CSI payload size and the bits for the one or more event indicator fields.

[0114] FIG. 18 is an operational flow / algorithmic structure 1800 for UEIBR with plural serving cells and events in accordance with some embodiments. The operational flow / algorithmic structure 1800 may be implemented by a UE such as, for example, UE 104, UE 2100 (shown in FIG. 21 and discussed further below) , or components thereof; for example, a baseband processor 2104A.

[0115] The operational flow / algorithmic structure 1800 may include, at 1804, receiving a UEIBR configuration. The UEIBR configuration may be received from a network via RRC signaling. The UEIBR configuration may configure the UE / processor to monitor a plurality of events on one or more component carriers. The UIEBR configuration may associate the plurality of events with one or more TI channels, and the one or more TI channels may be associated with one or more SR channels. In this embodiment, a TI channel may be a PUCCH format 2, 3, or 4.

[0116] The operational flow / algorithmic structure 1800 may further include, at 1808, monitoring the plurality of events based on the UEIBR configuration. The events may be Event-1, Event-2, or Event-7 events distributed over various serving cells (e.g., PCells and one or more SCells) .

[0117] The operational flow / algorithmic structure 1800 may further include, at 1812, determining a first event is triggered. This determination may be based on monitoring the plurality of events.

[0118] The operational flow / algorithmic structure 1800 may further include, at 1816, generating a PUCCH transmission for the TI channel. After generating the PUCCH transmission, the UE / processor may output it for transmission to the network. The PUCCH transmission for the TI channel may be a PUCCH format 2, 3, or 4 and, therefore, may have a plurality of bits. In some embodiments, each event of the plurality of events includes an event type and a serving cell index, and the plurality of bits are mapped to the plurality of events in a predefined (or configured) manner based on event types and serving cell indexes.

[0119] The plurality of bits of the PUCCH transmission may respectively correspond to the plurality of events that are monitored. An individual bit may indicate whether a corresponding event is triggered.

[0120] The operational flow / algorithmic structure 1800 may further include, at 1828, generating a PUSCH transmission for the SR channel that is associated with the TI channel. After generating the PUSCH transmission, the UE / processor may output it for transmission to the network. The PUSCH transmission may be generated to include the CIS reports corresponding to the triggered events. For example, if the plurality of bits in the PUCCH transmission include O bits set to indicate O events are triggered, where O is a positive integer, the PUSCH transmission may be generated to include O CSI reports that respectively correspond to the O events that are triggered.

[0121] In some embodiments, the operational flow / algorithmic structure 1800 may corresponding to a Mode A reporting in which the UE / processor receives a dynamic grant for the PUSCH transmission. In other embodiments, the operational flow / algorithmic structure 1800 may corresponding to a Mode B reporting in which the UE / processor uses a configured grant for the PUSCH transmission.

[0122] In some embodiments, for Mode B reporting, if the plurality of bits of the PUCCH transmission include O bits set to indicate O events are triggered, the UE / processor may generate O CSI reports that respectively correspond to the O events that are triggered and generate O PUSCH transmissions to include the O CSI reports.

[0123] In some embodiments, for Mode B reporting, the UE / processor may provide different sets of CSI reports in different PUSCH transmissions. For example, if the plurality of bits of the PUCCH transmission include O bits set to indicate O events are triggered, the UE / processor may generate O CSI reports that respectively correspond to the O events that are triggered, generate a first PUSCH transmission to include a first set of the O CSI reports, and generate a second PUSCH transmission to include a second set of the O CSI reports. The sets could have the same or different number of CSI reports. Further, more than two sets or PUSCH transmissions may be used in different embodiments.

[0124] FIG. 19 is an operational flow / algorithmic structure 1900 for UEIBR with plural serving cells and events in accordance with some embodiments. The operational flow / algorithmic structure 1900 may be implemented by a UE such as, for example, UE 104, UE 2100 (shown in FIG. 21 and discussed further below) , or components thereof; for example, a baseband processor 2104A.

[0125] The operational flow / algorithmic structure 1900 may include, at 1904, receiving a UEIBR configuration. The UEIBR configuration may be received from a network via RRC signaling. The UEIBR configuration may configure the UE / processor to monitor a plurality of events on a least two component carriers when the UE / processor is operating in a CA deployment. The UIEBR configuration may associate the plurality of events with a plurality of TI channels, and the plurality of TI channels may be associated with one or more SR channels. In this embodiment, a TI channel may be a PUCCH format 0 / 1.

[0126] The operational flow / algorithmic structure 1900 may further include, at 1908, monitoring the plurality of events based on the UEIBR configuration. The events may be Event-1, Event-2, or Event-7 events distributed over various serving cells (e.g., PCells and one or more SCells) .

[0127] The operational flow / algorithmic structure 1900 may further include, at 1912, determining two or more events are triggered. The two or more events may be events of the plurality of events that are being monitored based on the UIEBR configuration.

[0128] The operational flow / algorithmic structure 1900 may further include, at 1916, generating a first / second PUCCH transmissions for first / second TI channels. After generating the PUCCH transmissions, the UE / processor may output them for transmission to the network. Each PUCCH transmission may be a PUCCH format 0 / 1 and, therefore, only have a one-bit indicator. Each event may be associated with its own PUCCH resource. For example, if a first event is triggered, the UE / processor may generate the first PUCCH transmission (using the PUCCH resource associated with the first event) to include an indication that the first event was triggered. If an event is not triggered, the corresponding PUCCH transmission may not be sent (or may be sent with a trigger indication indicating that it is not triggered) .

[0129] The operational flow / algorithmic structure 1900 may further include, at 1928, generating one or more PUSCH transmissions for one or more SR channels that are associated with the plurality of TI channels. After generating the one or more PUSCH transmissions, the UE / processor may output them for transmission to the network.

[0130] In some embodiments, for Mode A reporting, the UE / processor may receive a dynamic grant of PUSCH resources and generate a payload by concatenating CSI reports for the triggered events in a predefined order based on event types and serving cell indexes of the triggered events. One PUSCH transmission may be generated with the payload using PUSCH resources.

[0131] In some embodiments, for Mode B reporting, the UE / processor may select a CG-PUSCH resource that is dedicated for UEIBR CSI reports. The PUSCH transmission may then be generated using the CG-PUSCH resource. The UE / processor may select the CG-PUSCH resource by determining a payload of CSI reports for the triggered events and determine a maximum payload of each CG PUSCH resource based on a respective code rate threshold . The CG-PUSCH resource may then be selected from a plurality of CG-PUSCH resources based on the CG-PUSCH resource having a smallest number of resource blocks needed to accommodate the payload of CSI reports.

[0132] In some embodiments, for Mode B reporting, the UE / processor may determine a payload of CSI reports for the triggered events. The UE / processor may determine a number of RBs needed to accommodate the payload based on the code rate threshold for the CG-PUSCH resource and generate the PUSCH transmission using a CG-PUSCH resource with a scalable number of RBs that is set to be equal to the number of RBs needed to accommodate the payload.

[0133] The predetermined code rate threshold of the CG-PUSCH resource may be based on RRC signaling received from the network.

[0134] In some embodiments, the PUSCH transmission may be generated using a CG-PUSCH resource. The PUSCH transmission may be generated to include UL-SCH data based on with the CSI reports for the one or more events also being included in the PUSCH transmission. Thus, in some embodiments, the UL-SCH may only be transmitted when at least one CSI report is included; otherwise, the UL-SCH cannot be transmitted.

[0135] In some embodiments, the UE / processor may generate, using a first CG-PUSCH resource, a first PUSCH transmission to include a first triggered CSI report; and generate, using a second CG-PUSCH resource, a second PUSCH transmission to include a second triggered CSI report.

[0136] In some embodiments, the UE / processor may determine a mapping between PUCCH resources that carry the trigger indication and CG-PUSCH resources that carry the associated CSI reports. This mapping may be based on RRC signaling received from the network.

[0137] FIG. 20 is an operational flow / algorithmic structure 2000 for UEIBR with plural serving cells and events in accordance with some embodiments. The operational flow / algorithmic structure 2000 may be implemented by a base station such as, for example, base station 108, network device 2200 (shown in FIG. 22 and discussed further below) , or components thereof; for example, a baseband processor 2204A.

[0138] The operational flow / algorithmic structure 2000 may include, at 2004, generating a UEIBR configuration. After generating the UEIBR configuration, the configuration may be output for transmission to a UE to configure the UE to monitor a plurality of events of at least two different event types on one or more component carriers. The UIEBR configuration may associate the plurality of events with a TI channel, and the TI channel may be associated with one SR channel. In this embodiment, a TI channel may be a PUCCH format 0 / 1 and the plurality of events may include a first event with a first event type and a second event with a second event type that is different from the first event type.

[0139] The operational flow / algorithmic structure 2000 may further include, at 2008, processing a PUCCH transmission received from the UE. The PUCCH transmission may include one bit to indicate that at least one event of the monitored events is triggered.

[0140] The operational flow / algorithmic structure 2000 may further include, at 2012, processing a PUSCH transmission received from the UE. The PUSCH transmission may include at least one CSI report from a triggered event. In processing the PUSCH transmission, the base station / processor may determine that it includes a payload sufficient to accommodate CSI reports from all of the plurality of events that are associated with the TI channel that corresponds to the SR channel of the PUSCH transmission. The PUSCH transmission may include first bits associated with events of the plurality of events that are not triggered set to zero and second bits associated with the triggered events set to indicate information of the corresponding CSI reports.

[0141] FIG. 21 illustrates a UE 2100 in accordance with some embodiments. The UE 2100 may be similar to and substantially interchangeable with UE 104.

[0142] The UE 2100 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, inventory sensors, electric voltage / current meters, or actuators) , video surveillance / monitoring devices (for example, cameras or video cameras) , wearable devices (for example, a smart watch) , or Internet-of-things devices.

[0143] The UE 2100 may include processors 2104, RF interface circuitry 2108, memory / storage 2112, user interface 2116, sensors 2120, driver circuitry 2122, power management integrated circuit (PMIC) 2124, antenna 2126, and battery 2128. The components of the UE 2100 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 21 is intended to show a high-level view of some of the components of the UE 2100. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

[0144] The components of the UE 2100 may be coupled with various other components over one or more interconnects 2132, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, or optical connection that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0145] The processors 2104 may include processor circuitry such as, for example, baseband processor circuitry (BB) 2104A, central processor unit circuitry (CPU) 2104B, and graphics processor unit circuitry (GPU) 2104C. The processors 2104 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 2112 to cause the UE 2100 to perform UEIBR operations as described herein (e.g., in accordance with FIGs. 17–19) . The processors 2104 may also include interface circuitry 2104D to enable communication by, for example, communicatively coupling the processor circuitry with one or more other components of the UE 2100.

[0146] In some embodiments, the baseband processor circuitry 2104A may access a communication protocol stack 2136 in the memory / storage 2112 to communicate over a 3GPP compatible network. In general, the baseband processor circuitry 2104A may access the communication protocol stack 2136 to: perform user plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a NAS layer. In some embodiments, the PHY layer operations may additionally / alternatively be performed by the components of the RF interface circuitry 2108.

[0147] The baseband processor circuitry 2104A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some embodiments, the waveforms for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

[0148] The memory / storage 2112 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 2136) that may be executed by one or more of the processors 2104 to cause the UE 2100 to perform various delay-adaptive operations described herein.

[0149] The memory / storage 2112 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 2100. In some embodiments, some of the memory / storage 2112 may be located on the processors 2104 themselves (for example, memory / storage 2112 may be part of a chipset that corresponds to the baseband processor circuitry 2104A) , while other memory / storage 2112 is external to the processors 2104 but accessible thereto via a memory interface. The memory / storage 2112 may include any suitable volatile or non-volatile memory such as, but not limited to, 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 memory, or any other type of memory device technology.

[0150] The RF interface circuitry 2108 may include transceiver circuitry and a radio frequency front module (RFEM) that allows the UE 2100 to communicate with other devices over a radio access network. The RF interface circuitry 2108 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, and control circuitry.

[0151] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna 2126 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that down-converts the RF signal into a baseband signal that is provided to the baseband processor of the processors 2104.

[0152] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna 2126.

[0153] In various embodiments, the RF interface circuitry 2108 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0154] The antenna 2126 may include antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna 2126 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna 2126 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, or phased array antennas. The antenna 2126 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0155] The user interface 2116 includes various input / output (I / O) devices designed to enable user interaction with the UE 2100. The user interface 2116 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes (LEDs) and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays (LCDs) , LED displays, quantum dot displays, and projectors) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 2100.

[0156] The sensors 2120 may include devices, modules, or subsystems whose purpose is to detect events or changes in their environment and send the information (sensor data) about the detected events to some other device, module, or subsystem. Examples of such sensors include inertia measurement units comprising accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems comprising 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (for example, thermistors) ; pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; and microphones or other like audio capture devices.

[0157] The driver circuitry 2122 may include software and hardware elements that operate to control particular devices that are embedded in the UE 2100, attached to the UE 2100, or otherwise communicatively coupled with the UE 2100. The driver circuitry 2122 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within, or connected to, the UE 2100. For example, driver circuitry 2122 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 2120 and control and allow access to sensors 2120, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0158] The PMIC 2124 may manage power provided to various components of the UE 2100. In particular, with respect to the processors 2104, the PMIC 2124 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0159] A battery 2128 may power the UE 2100, although in some examples the UE 2100 may be deployed in a fixed location and may have a power supply coupled to an electrical grid. The battery 2128 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 2128 may be a typical lead-acid automotive battery.

[0160] FIG. 22 illustrates a network device 2200 in accordance with some embodiments. The network device 2200 may be similar to and substantially interchangeable with base station 108 or a device of the core network 112 or external data network 120.

[0161] The network device 2200 may include processors 2204, RF interface circuitry 2208 (if implemented as a base station) , core network (CN) interface circuitry 2214, memory / storage circuitry 2212, and antenna structure 2226.

[0162] The components of the network device 2200 may be coupled with various other components over one or more interconnects 2228.

[0163] The processors 2204, RF interface circuitry 2208, memory / storage circuitry 2212 (including communication protocol stack 2210) , antenna structure 2226, and interconnects 2228 may be similar to like-named elements shown and described with respect to FIG. 21.

[0164] The processors 2204 may include processor circuitry such as, for example, baseband processor circuitry (BB) 2204A, central processor unit circuitry (CPU) 2204B, and graphics processor unit circuitry (GPU) 2204C. The processors 2204 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage circuitry 2212 to cause the network device 2200 to perform UEIBR operations described herein (e.g., in accordance with FIG. 20) . The processors 2204 may also include interface circuitry 2204D to enable communication by, for example, communicatively coupling the processor circuitry with one or more other components of the network device 2200.

[0165] The CN interface circuitry 2214 may provide connectivity to a core network, for example, a 5th Generation Core network (5GC) using a 5GC-compatible network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the network device 2200 via a fiber optic or wireless backhaul. The CN interface circuitry 2214 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 2214 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0166] 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 so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0167] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.Examples

[0168] In the following sections, further exemplary embodiments are provided.

[0169] Example 1 includes a method comprising: receiving, from a network in one or more radio resource control (RRC) messages, a user-equipment (UE) -initiated beam reporting (UEIBR) configuration; monitoring, based on the UEIBR configuration, a plurality of events on one or more component carriers; identifying a maximum number of channel state information (CSI) reports; determining, based on said monitoring, one or more events of the plurality of events are triggered; selecting, from the one or more events, a number of events for reporting, wherein the number is equal to or less than the maximum number; generating a first physical uplink control channel (PUCCH) transmission that includes a first bit to indicate that at least one event is triggered; and generating a physical uplink shared channel (PUSCH) transmission that includes a number of CSI reports that respectively correspond to the number of events.

[0170] Example 2 includes the method of example 1 or some other example herein, wherein the PUCCH transmission comprises PUCCH format 0 or 1 and carries 1-bit uplink control information (UCI) .

[0171] Example 3 includes the method of example 1 or some other example herein, wherein the maximum number of CSI reports is predefined or is configured by radio resource control (RRC) signaling.

[0172] Example 4 includes the method of example 1 or some other example herein, wherein the number of events is a subset of the one or more events and the method includes: determining a priority value associated with each event of the one or more events; and selecting the number of events based on the priority values associated with each of the one or more events.

[0173] Example 5 includes the method of example 4 or some other example herein, wherein determining the priority value is based on a predefined prioritization rule or a priority order value of each event configured by radio resource control (RRC) signaling.

[0174] Example 6 includes the method of example 1 or some other example herein, wherein the PUSCH transmission further includes: one or more event indicator fields to associate the number of CSI reports with the number of events.

[0175] Example 7 includes the method of example 6 or some other example herein, wherein the one or more event indicator fields includes a bitmap that includes a plurality of bits that respectively correspond to the plurality of events, wherein each bit of the plurality of bits is set to indicate whether a CSI report of a corresponding event is included in the PUSCH transmission.

[0176] Example 8 includes the method of example 6 or some other example herein, wherein the one or more event indicator fields includes a number of event indicator fields that respectively correspond to the number of CSI reports, wherein each event indicator field includes an identifier (ID) that identifies an event of the number of events that corresponds to the associated CSI report.

[0177] Example 9 includes the method of example 1 or some other example herein, wherein a number of events is a first number of events and said generating the PUSCH transmission includes: selecting, from the plurality of events, a second number of events that are associated with largest CSI report payload sizes of the plurality of events, wherein the second number equals the maximum number; determining a payload size to accommodate CSI reports of the second number of events; and generating the PUSCH transmission with the payload size.

[0178] Example 10 includes the method of example 9 or some other example herein, wherein the payload size is a first payload size and said generating the PUSCH transmission includes: determining a second payload size to accommodate the number of CSI reports that respectively correspond to the first number of events; generating a number of padding bits that is equal to a difference between the first payload size and the second payload size; and generating the PUSCH transmission with first bits to convey the number of CSI reports and the number of padding bits.

[0179] Example 11 includes a method comprising: receiving, from a network, a user-equipment (UE) -initiated beam reporting (UEIBR) configuration; monitoring, based on the UEIBR configuration, a plurality of events on one or more component carriers; determining, based on said monitoring, a first event of the plurality of events is triggered; generating a physical uplink control channel (PUCCH) transmission that includes a first bit to indicate that the first event is triggered and a second bit to indicate whether a second event of the plurality of events is triggered; and generating a physical uplink shared channel (PUSCH) transmission that includes a channel state information (CSI) report corresponding to first event.

[0180] Example 12 includes the method of example 11 or some other example herein, wherein the PUCCH transmission comprises PUCCH format 2, 3, or 4.

[0181] Example 13 includes the method of example 11 or some other example herein, wherein the PUCCH transmission includes a plurality of bits that respectively correspond to the plurality of events, wherein an individual bit is to indicate whether a corresponding event is triggered.

[0182] Example 14 includes the method of example 13 or some other example herein, wherein the plurality of bits include O bits set to indicate O events are triggered, where O is a positive integer, the PUSCH transmission includes O CSI reports that respectively correspond to the O events that are triggered, and the method further comprises: receiving a dynamic grant for the PUSCH transmission.

[0183] Example 15 includes the 15. The method of example 13 or some other example herein, wherein the plurality of bits include O bits set to indicate O events are triggered, where O is a positive integer, the PUSCH transmission includes O CSI reports that respectively correspond to the O events that are triggered, and the method further comprises: utilizing a configured grant for the PUSCH transmission.

[0184] Example 16 includes the method of example 13 or some other example herein, wherein the plurality of bits include O bits set to indicate O events are triggered, where O is a positive integer, and the method further comprises: generating O CSI reports that respectively correspond to the O events that are triggered; generating O PUSCH transmissions to include the O CSI reports.

[0185] Example 17 includes the method of example 13 or some other example herein, wherein the plurality of bits include O bits set to indicate O events are triggered, where O is a positive integer, the PUSCH transmission is a first PUSCH transmission, and the method further comprises: generating O CSI reports that respectively correspond to the O events that are triggered; generating the first PUSCH transmission to include a first set of the O CSI reports; and generating a second PUSCH transmission to include a second set of the O CSI reports.

[0186] Example 18 includes the method of example 13 or some other example herein, wherein each event of the plurality of events includes an event type and a serving cell index, and the plurality of bits are mapped to the plurality of events in a predefined manner based on event types and serving cell indexes.

[0187] Example 19 includes the method of example 11 or some other example herein, further comprising: receiving a radio resource control (RRC) signal from the network; and mapping the plurality of bits to the plurality of events based on the RRC signal.

[0188] Example 20 includes the method of example 11 or some other example herein, wherein the PUCCH transmission is a first PUCCH transmission that includes a first plurality of bits that respectively correspond to a first subset of the plurality of events and the method further comprises: generating a second PUCCH transmission that includes a second plurality of bits that respectively correspond to a second subset of the plurality of events.

[0189] Example 21 includes a method comprising: receiving, from a network, a user-equipment (UE) -initiated beam reporting (UEIBR) configuration; monitoring, based on the UEIBR configuration, a plurality of events on one or more component carriers; determining, based on said monitoring, two or more events of the plurality of events are triggered, the two or more events to include a first event with a first event type and a second event with a second event type that is different from the first event type; generating a first physical uplink control channel (PUCCH) transmission that includes a first bit to indicate that the first event is triggered; generating a second PUCCH transmission that includes a second bit to indicate that the second event is triggered; and generating one or more physical uplink shared channel (PUSCH) transmissions that include a first channel state information (CSI) report corresponding to the first event and a second CSI report corresponding to the second event.

[0190] Example 22 includes the method of example 21 or some other example herein, wherein the PUCCH transmission comprises PUCCH format 0 or 1 and carry 1-bit uplink control information.

[0191] Example 23 includes the method of example 21 or some other example herein, wherein each of the plurality of events is associated with a respective PUCCH resource to transmit a trigger indication.

[0192] Example 24 includes the method of example 21 or some other example herein, wherein each event of the one or more events includes an event type and a serving cell index, and the method further comprises: receiving a dynamic grant of PUSCH resources; generating a payload by concatenating CSI reports for the one or more events in a predefined order based on event types and serving cell indexes of the one or more events, wherein generating one or more PUSCH transmissions includes: generating a PUSCH transmission with the payload using the PUSCH resources.

[0193] Example 25 includes the method of example 21 or some other example herein, further comprising: selecting a configured grant (CG) -PUSCH resource that is dedicated for UEIBR CSI reports, wherein generating one or more PUSCH transmissions includes: generating a PUSCH transmission using the CG-PUSCH resource.

[0194] Example 26 includes the method of example 25 or some other example herein, wherein selecting the CG-PUSCH resource comprises: determining a payload of CSI reports for the one or more events; determining a maximum payload of each CG-PUSCH resource of a plurality of CG-PUSCH resources based on a code rate threshold for a respective CG-PUSCH resource; selecting the CG-PUSCH resource from the plurality of CG-PUSCH resources based on the CG-PUSCH resource having a smallest number of resource blocks needed to accommodate the payload of CSI reports.

[0195] Example 27 includes the method of example 21 or some other example herein, wherein the one or more PUSCH transmissions includes a PUSCH transmission and the method further comprises: determining a payload of CSI reports for the one or more events; determining a number of resource blocks (RBs) needed to accommodate the payload based on a code rate threshold for the CG-PUSCH resource; and generating the PUSCH transmission using a configured grant (CG) -PUSCH resource with a scalable number of RBs that is set to be equal to the number of RBs needed to accommodate the payload.

[0196] Example 28 includes the method of example 26 or 27 or some other example herein, further comprising: determining the code rate threshold of a CG-PUSCH resource based on radio resource control (RRC) signaling.

[0197] Example 29 includes the method of example 21 or some other example herein, wherein generating one or more PUSCH transmission further comprises: generating a PUSCH transmission using a configured grant (CG) -PUSCH resource, wherein the PUSCH transmission is generated to include uplink (UL) -shared channel (SCH) data based on the CSI reports for the one or more events also being included in the PUSCH transmission.

[0198] Example 30 includes the method of example 21 or some other example herein, wherein generating one or more PUSCH transmissions further comprises: generating, using a first configured grant (CG) -PUSCH resource, a first PUSCH transmission to include the first CSI report; and generating, using a second CG-PUSCH resource, a second PUSCH transmission to include the second CSI report.

[0199] Example 31 includes the method of example 30 or some other example herein, wherein the first PUCCH transmission is on a first PUCCH resource, the second PUCCH transmission is on a second PUCCH resource, and the method further comprises: determining a mapping between the first and second PUCCH resources and the first and second CG-PUSCH resources based on radio resource control (RRC) signaling.

[0200] Example 32 includes the method of example 21 or some other example herein, wherein the one or more events includes two or more events that are triggered and said generating one or more PUSCH transmissions includes generating one or more PUSCH transmissions using a corresponding one or more configured grant (CG) -PUSCH resources and the method further comprises: generating two or more PUCCH transmissions using a corresponding two or more PUCCH resources, the two or more PUCCH transmissions to respectively include trigger indicators for the two or more events that are triggered; and determining a mapping between the two or more PUCCH resources and the one or more CG-PUSCH resources based on radio resource control (RRC) signaling.

[0201] Example 33 includes the method of example 32 or some other example herein, wherein the mapping includes: a plurality of PUCCH resources mapped a single CG-PUSCH resource; or a single PUCCH resource mapped to a single CG-PUSCH resource.

[0202] Example 34 includes a method comprising: generating, for transmission to a user equipment (UE) , a UE-initiated beam reporting (UEIBR) configuration to configure the UE to monitor a plurality of events on one or more component carriers, the plurality of events to include a first event with a first event type and a second event with a second event type that is different from the first event type; processing a first physical uplink control channel (PUCCH) transmission, received from the UE, that includes a first bit to indicate that the at least one event is triggered; and processing a physical uplink shared channel (PUSCH) transmission, received from the UE, that includes at least one channel state information (CSI) report corresponding to the at least one event that is triggered.

[0203] Example 35 includes the method of example 34 or some other example herein, wherein the PUCCH transmission comprises PUCCH format 0 or 1.

[0204] Example 36 includes the method of example 34 or some other example herein, wherein the PUSCH transmission includes a payload having first bits associated with events of the plurality of events that are not triggered and second bits associated with the at least one event that is triggered, wherein the first bits are all set to zero and the second bits are set to indicate information of the at least one CSI report.

[0205] Another example may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1–36, or any other method or process described herein.

[0206] Another example may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1–36, or any other method or process described herein.

[0207] Another example may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1–36, or any other method or process described herein.

[0208] Another example may include a method, technique, or process as described in or related to any of examples 1–36, or portions or parts thereof.

[0209] Another example may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1–36, or portions thereof.

[0210] Another example may include a signal as described in or related to any of examples 1–36, or portions or parts thereof.

[0211] Another example may include a datagram, information element, packet, frame, segment, PDU, or message as described in or related to any of examples 1–36, or portions or parts thereof, or otherwise described in the present disclosure.

[0212] Another example may include a signal encoded with data as described in or related to any of examples 1–36, or portions or parts thereof, or otherwise described in the present disclosure.

[0213] Another example may include a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message as described in or related to any of examples 1–36, or portions or parts thereof, or otherwise described in the present disclosure.

[0214] Another example may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1–36, or portions thereof.

[0215] Another example may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1–36, or portions thereof.

[0216] Another example may include a signal in a wireless network as shown and described herein.

[0217] Another example may include a method of communicating in a wireless network as shown and described herein.

[0218] Another example may include a system for providing wireless communication as shown and described herein.

[0219] Another example may include a device for providing wireless communication as shown and described herein.

[0220] Any of the above-described examples may be combined with any other example (or combination of examples) , unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0221] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1.A method comprising:receiving, from a network in one or more radio resource control (RRC) messages, a user-equipment (UE) -initiated beam reporting (UEIBR) configuration;monitoring, based on the UEIBR configuration, a plurality of events on one or more component carriers;identifying a maximum number of channel state information (CSI) reports;determining, based on said monitoring, one or more events of the plurality of events are triggered;selecting, from the one or more events, a number of events for reporting, wherein the number is equal to or less than the maximum number;generating a first physical uplink control channel (PUCCH) transmission that includes a first bit to indicate that at least one event is triggered; andgenerating a physical uplink shared channel (PUSCH) transmission that includes a number of CSI reports that respectively correspond to the number of events.2.The method of claim 1, wherein the PUCCH transmission comprises PUCCH format 0 or 1 and carries 1-bit uplink control information (UCI) .3.The method of claim 1 or 2, wherein the maximum number of CSI reports is predefined or is configured by radio resource control (RRC) signaling.4.The method of claim 1 or 2, wherein the number of events is a subset of the one or more events and the method includes:determining a priority value associated with each event of the one or more events; andselecting the number of events based on the priority values associated with each of the one or more events,wherein determining the priority value is based on a predefined prioritization rule or a priority order value of each event configured by radio resource control (RRC) signaling.5.The method of claim 1 or 2, wherein the PUSCH transmission further includes:one or more event indicator fields to associate the number of CSI reports with the number of events.6.The method of claim 5, wherein the one or more event indicator fields includes a bitmap that includes a plurality of bits that respectively correspond to the plurality of events, wherein each bit of the plurality of bits is set to indicate whether a CSI report of a corresponding event is included in the PUSCH transmission.7.The method of claim 5, wherein the one or more event indicator fields includes a number of event indicator fields that respectively correspond to the number of CSI reports, wherein each event indicator field includes an identifier (ID) that identifies an event of the number of events that corresponds to the associated CSI report.8.The method of claim 1 or 2, wherein a number of events is a first number of events and said generating the PUSCH transmission includes:selecting, from the plurality of events, a second number of events that are associated with largest CSI report payload sizes of the plurality of events, wherein the second number equals the maximum number;determining a payload size to accommodate CSI reports of the second number of events; andgenerating the PUSCH transmission with the payload size.9.A method comprising:receiving, from a network, a user-equipment (UE) -initiated beam reporting (UEIBR) configuration;monitoring, based on the UEIBR configuration, a plurality of events on one or more component carriers;determining, based on said monitoring, a first event of the plurality of events is triggered;generating a physical uplink control channel (PUCCH) transmission that includes a first bit to indicate that the first event is triggered and a second bit to indicate whether a second event of the plurality of events is triggered; andgenerating a physical uplink shared channel (PUSCH) transmission that includes a channel state information (CSI) report corresponding to first event.10.The method of claim 9, wherein the PUCCH transmission comprises PUCCH format 2, 3, or 4.11.The method of claim 9 or 10, wherein the PUCCH transmission includes a plurality of bits that respectively correspond to the plurality of events, wherein an individual bit is to indicate whether a corresponding event is triggered, the plurality of bits include O bits set to indicate O events are triggered, where O is a positive integer, the PUSCH transmission includes O CSI reports that respectively correspond to the O events that are triggered, and the method further comprises:receiving a dynamic grant for the PUSCH transmission.12.The method of claim 9 or 10, wherein the PUCCH transmission includes a plurality of bits that respectively correspond to the plurality of events, wherein an individual bit is to indicate whether a corresponding event is triggered, the plurality of bits include O bits set to indicate O events are triggered, where O is a positive integer, the PUSCH transmission includes O CSI reports that respectively correspond to the O events that are triggered, and the method further comprises:utilizing a configured grant for the PUSCH transmission.13.The method of claim 9 or 10, wherein the PUCCH transmission includes a plurality of bits that respectively correspond to the plurality of events, wherein an individual bit is to indicate whether a corresponding event is triggered, the plurality of bits include O bits set to indicate O events are triggered, where O is a positive integer, and the method further comprises:generating O CSI reports that respectively correspond to the O events that are triggered;generating O PUSCH transmissions to include the O CSI reports.14.The method of claim 9 or 10, wherein the PUCCH transmission includes a plurality of bits that respectively correspond to the plurality of events, wherein an individual bit is to indicate whether a corresponding event is triggered, the plurality of bits include O bits set to indicate O events are triggered, where O is a positive integer, the PUSCH transmission is a first PUSCH transmission, and the method further comprises:generating O CSI reports that respectively correspond to the O events that are triggered;generating the first PUSCH transmission to include a first set of the O CSI reports; andgenerating a second PUSCH transmission to include a second set of the O CSI reports.15.The method of claim 9 or 10, wherein the PUCCH transmission includes a plurality of bits that respectively correspond to the plurality of events, wherein an individual bit is to indicate whether a corresponding event is triggered, she each event of the plurality of events includes an event type and a serving cell index, and the plurality of bits are mapped to the plurality of events in a predefined manner based on event types and serving cell indexes.16.The method of claim 9 or 10, further comprising:receiving a radio resource control (RRC) signal from the network; andmapping the plurality of bits to the plurality of events based on the RRC signal.17.The method of claim 9 or 10, wherein the PUCCH transmission is a first PUCCH transmission that includes a first plurality of bits that respectively correspond to a first subset of the plurality of events and the method further comprises:generating a second PUCCH transmission that includes a second plurality of bits that respectively correspond to a second subset of the plurality of events.18.A method comprising:receiving, from a network, a user-equipment (UE) -initiated beam reporting (UEIBR) configuration;monitoring, based on the UEIBR configuration, a plurality of events on one or more component carriers;determining, based on said monitoring, two or more events of the plurality of events are triggered, the two or more events to include a first event with a first event type and a second event with a second event type that is different from the first event type;generating a first physical uplink control channel (PUCCH) transmission that includes a first bit to indicate that the first event is triggered;generating a second PUCCH transmission that includes a second bit to indicate that the second event is triggered; andgenerating one or more physical uplink shared channel (PUSCH) transmissions that include a first channel state information (CSI) report corresponding to the first event and a second CSI report corresponding to the second event.19.The method of claim 18, wherein the PUCCH transmission comprises PUCCH format 0 or 1 and carry 1-bit uplink control information.20.The method of claim 18 or 19, wherein each of the plurality of events is associated with a respective PUCCH resource to transmit a trigger indication.21.The method of claim 18 or 19, wherein each event of the one or more events includes an event type and a serving cell index, and the method further comprises:receiving a dynamic grant of PUSCH resources;generating a payload by concatenating CSI reports for the one or more events in a predefined order based on event types and serving cell indexes of the one or more events,wherein generating one or more PUSCH transmissions includes: generating a PUSCH transmission with the payload using the PUSCH resources.22.The method of claim 18 or 19, further comprising:selecting a configured grant (CG) -PUSCH resource that is dedicated for UEIBR CSI reports,wherein generating one or more PUSCH transmissions includes: generating a PUSCH transmission using the CG-PUSCH resource,wherein selecting the CG-PUSCH resource comprises:determining a payload of CSI reports for the one or more events;determining a maximum payload of each CG-PUSCH resource of a plurality of CG-PUSCH resources based on a code rate threshold for a respective CG-PUSCH resource;selecting the CG-PUSCH resource from the plurality of CG-PUSCH resources based on the CG-PUSCH resource having a smallest number of resource blocks needed to accommodate the payload of CSI reports.23.The method of claim 18 or 19, wherein the one or more PUSCH transmissions includes a PUSCH transmission and the method further comprises:determining a payload of CSI reports for the one or more events;determining a number of resource blocks (RBs) needed to accommodate the payload based on a code rate threshold for the CG-PUSCH resource, wherein the code rate threshold is based on radio resource control (RRC) signaling; andgenerating the PUSCH transmission using a configured grant (CG) -PUSCH resource with a scalable number of RBs that is set to be equal to the number of RBs needed to accommodate the payload.24.A method comprising:generating, for transmission to a user equipment (UE) , a UE-initiated beam reporting (UEIBR) configuration to configure the UE to monitor a plurality of events on one or more component carriers, the plurality of events to include a first event with a first event type and a second event with a second event type that is different from the first event type;processing a first physical uplink control channel (PUCCH) transmission, received from the UE, that includes a first bit to indicate that the at least one event is triggered; andprocessing a physical uplink shared channel (PUSCH) transmission, received from the UE, that includes at least one channel state information (CSI) report corresponding to the at least one event that is triggered.25.The method of claim 24, wherein the PUCCH transmission comprises PUCCH format 0 or 1, and the PUSCH transmission includes a payload having first bits associated with events of the plurality of events that are not triggered and second bits associated with the at least one event that is triggered, wherein the first bits are all set to zero and the second bits are set to indicate information of the at least one CSI report.

Images