Collision of UE-initiated transmission and other uplink (UL) transmission (s) in a wireless communication system

Abstract

This disclosure provides systems, methods and apparatuses that enable a user equipment (UE) (102) to implement UE-initiated (UEI) transmissions according to a configuration (120) from a network (NW) entity 104). The techniques of this disclosure enable the UE to handle (180) a collision (160) between a first uplink (UL) transmission (150) associated with a UEI transmission and a second UL transmission (170). A collision occurs when UL resources for the first UL transmission at least partially overlaps with UL resources for the second UL transmission. Various aspects of this disclosure provide rules by which the UE can determine (182) which UL resource to use (and thus which UL transmission to transmit) in the event of the overlap.

Description

COLLISION OF UE-INITIATED TRANSMISSION AND OTHER UPLINK (UL) TRANSMISSION (S) IN A WIRELESS COMMUNICATION SYSTEMTECHNICAL FIELD

[0001] This disclosure relates generally to wireless communication and some aspects relate to handling collision of a user equipment (UE) -initiated (UEI) transmission and another uplink (UL) transmission.BACKGROUND

[0002] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0003] A wireless communication system enables a user equipment (UE) to communicate with other communication devices or services via a network (NW) entity, such as a base station, according to a telecommunication standard. An example telecommunication standard, promulgated by Third Generation Partnership Project (3GPP) , is 5th generation (5G) New Radio (NR) . As part of 5G NR (or later standards) , the 3GPP has proposed a UE-initiated (UEI) beam report (which may be referred to as a UEI-BR) . A UEI-BR is an example of a UEI transmission that can improve wireless service and reduce power consumption and / or signaling overhead.

[0004] Prior to 5G NR, the NW entity would schedule and trigger a beam report. The NW entity may configure the UE to perform the beam report in periodic, semi-persistent or aperiodic manner. The NW entity may configure a channel state information (CSI) report configuration, e.g., CSI-ReportConfig, for beam measurement and report, within which the NW entity may configure a list of synchronization signal block (SSB) or CSI reference signal (CSI-RS) resources for beam measurement. Based on the beam report, the NW entity can provide the beam activation / indication by indicating a transmission configuration indicator (TCI) or spatial relation info. The beam quality for a beam may change over time based on the UE’s movement / rotation or blockage. The NW entity has no or limited information on when the beam quality would change. Therefore, the NW entity may not be able to trigger the beam report at a proper time. To maintain good beam quality, the NW entity may trigger the beam report frequently. This enables frequent updates but could cause excessive downlink activating / triggering signaling overhead, uplink overhead for the beam report, and high UE  power consumption. In some implementations, the NW entity may trigger the beam report less frequently to reduce the downlink / uplink overhead and UE power consumption. However, this may cause performance degradation as the NW entity cannot identify the beam quality change which could lead to beam switching. Therefore, one possible way to maintain the good beam quality with less downlink / uplink overhead and UE power consumption is for the UE to trigger the beam report and transmit the UEI-BR as needed.

[0005] In some implementations, when the UE triggers a UEI-BR, the UE may first transmit uplink control signaling (such as a request signal or notification signal) before transmitting the UEI-BR. The request signal is for requesting an uplink (UL) resource to use for transmission of the UEI-BR. In some implementations, the NW entity may pre-configure a UL resource for the UEI-BR. In some implementations, the UE transmits the notification signal for notifying the NW entity of usage of the pre-configured UL resource for the UEI-BR. One potential concern of utilizing a triggered UEI-BR is that the UE might trigger the UEI-BR, the request signal, or the notification signal during a time when the UE has another UL transmission scheduled. This can be interchangeably referred to as a UL transmission collision (or, for brevity, “collision” ) or an “overlap” of UL resources. A collision occurs when a UL resource for a UEI-BR (or a request signal or notification signal associated with the UEI-BR) at least partially overlaps in time with another UL resource for a different UL transmission (or a different UEI transmission) . The collision can occur when UL resources for two or more UL transmissions (including at least one UEI transmission) overlap in the same serving cell or in different serving cells. A NW entity may configure a UE for multiple UEI-BRs (such as for various beams / cells) , potentially increasing the likelihood of collisions. Furthermore, while a UEI-BR is one type of UEI transmission, other types of UEI transmissions may be defined and the potential for collisions may increase. There is currently no technique for a UE to handle collisions that might occur as a result of triggering a UEI transmission.

[0006] BRIEF SUMMARY

[0007] The systems, methods, and apparatuses of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

[0008] One innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by a user equipment (UE) . The method includes the UE receiving, from a network (NW) entity, a configuration for a UE-initiated (UEI) transmission. The method includes the UE detecting an overlap between a first UL  resource for a first UL transmission associated with the UEI transmission and a second UL resource for a second UL transmission of the UE. The method includes the UE prioritizing transmission of the first UL transmission or the second UL transmission according to a rule for the overlap.

[0009] In some implementations, the first UL transmission includes at least one of a request signal for requesting a UL resource for the UEI transmission, a notification signal indicating usage of a pre-configured UL resource for the UEI transmission, or the UEI transmission. In some implementations, the second UL transmission includes at least one of a request signal for requesting a UL resource for the UEI transmission, a notification signal indicating usage of a pre-configured UL resource for the UEI transmission, the UEI transmission, or an UL transmission not for UEI transmission.

[0010] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by a NW entity. The method includes the NW entity transmitting, to a UE, a configuration for a UEI transmission such that the NW entity expects to receive, from the UE, a first UL transmission associated with the UEI transmission via a first UL resource. The method includes the NW entity scheduling a second UL resource for a second UL transmission of the UE. The method includes the NW entity receiving one of the first UL transmission or the second UL transmission according to a rule for an overlap between the first UL resource and the second UL resource.

[0011] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus that includes a communication unit and a processing system configured to control the communication unit to implement any one of the above-referenced methods.

[0012] Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Like reference numbers and designations in the various drawings indicate like elements. Note that the relative dimensions of the figures may not be drawn to scale. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0014] FIG. 1 shows an example wireless communication system and an implementation of a user equipment (UE) handling a collision between a UE-initiated (UEI) transmission and another uplink (UL) transmission.

[0015] FIG. 2A shows an example message diagram for a first mode of UEI transmission, in which a request signal precedes the UEI transmission.

[0016] FIG. 2B shows an example message diagram for a second mode of UEI transmission, in which a network (NW) entity preconfigures the UL resource for the UEI transmission and the UE may transmit a notification signal indicating usage of the preconfigured UL resource.

[0017] FIG. 2C shows several example potential collisions that might occur between resources for a UEI transmission and other UL resources.

[0018] FIG. 3 shows a message diagram of one of a UEI transmission, a request signal or a notification signal overlapping with one or more UL transmission (s) .

[0019] FIG. 4A shows a message diagram of a UEI transmission in a first mode in which a collision occurs between a UEI-BR and another UL transmission.

[0020] FIG. 4B shows a message diagram of a UEI transmission in a first mode in which a collision occurs between a request signal for a UEI-BR and another UL transmission.

[0021] FIG. 5A shows a message diagram of a UEI transmission in a second mode in which a collision occurs between a UEI-BR and another UL transmission.

[0022] FIG. 5B shows a message diagram of a UEI transmission in a second mode in which a collision occurs between a notification signal for a UEI-BR and another UL transmission.

[0023] FIG. 6 shows a flow diagram for handling a collision between a configured grant (CG) physical uplink shared channel (CG-PUSCH) and a normal PUSCH.

[0024] FIG. 7 shows a flow diagram for handling a collision between a PUSCH for a UEI transmission and a physical uplink control channel (PUCCH) associated with channel state information (CSI) reporting.

[0025] FIG. 8 shows a flow diagram for handling a collision between a PUSCH for a UEI transmission and a PUCCH associated with a scheduling request (SR) or a link recovery request (LRR) .

[0026] FIG. 9 shows a flow diagram for handling a collision between a PUSCH for a UEI transmission and a PUCCH associated with a hybrid automatic repeat request acknowledgment (HARQ-ACK) .

[0027] FIG. 10 shows a flow diagram for handling a collision between a first PUCCH for a first mode of a first UEI transmission and a second PUCCH for a second mode of a second UEI transmission.

[0028] FIG. 11 shows a flow diagram for handling a collision between a PUCCH for a first mode of a first UEI transmission and a CG-PUSCH for a second mode of a second UEI transmission.

[0029] FIG. 12 shows a flow diagram for handling a collision between a dynamic grant PUSCH (DG-PUSCH) for a first mode of a first UEI transmission and a PUCCH for a second mode of a second UEI transmission.

[0030] FIG. 13 shows a flow diagram for handling a collision between a DG-PUSCH for a first mode of a first UEI transmission and a CG-PUSCH for a second mode of a second UEI transmission.

[0031] FIG. 14 shows a flow diagram for handling a collision between a PUCCH for a first mode of a UEI transmission and a normal PUSCH.

[0032] FIG. 15 shows a flow diagram for handling a collision between a PUCCH for a second mode of a UEI transmission and a normal PUSCH.

[0033] FIG. 16 shows a flow diagram for handling a collision between a PUCCH of a UEI transmission and a normal PUCCH.

[0034] FIG. 17 shows example uplink control information (UCI) priority order when a collision occurs for UCI related to a UEI transmission and other types of UCI.

[0035] FIG. 18A shows a flow diagram for handling multiple collisions using a first collision handling order.

[0036] FIG. 18B shows a flow diagram for handling multiple collisions using a second collision handling order.

[0037] FIG. 18C shows a flow diagram for handling multiple collisions using a third collision handling order.

[0038] FIG. 19 shows a flow diagram with example operations for a UE in accordance with aspects of this disclosure.

[0039] FIG. 20 shows a flow diagram with example operations for a NW entity to mitigate collisions in accordance with aspects of this disclosure.

[0040] FIG. 21 illustrates an example protocol stack for communications between a UE and a NW entity.

[0041] FIG. 22 shows a block diagram illustrating example components of a NW entity and a UE.

[0042] FIG. 23 shows a block diagram of an example wireless communication system showing hardware features and communication interfaces.DETAILED DESCRIPTION

[0043] The following description is directed to certain implementations for the purpose of describing innovative aspects of this disclosure. However, a person having ordinary skill in the art will readily recognize that the teachings herein can be applied in a multitude of different ways. Some of the examples in this disclosure are based on wireless communication according to the 3rd Generation Partnership Project (3GPP) wireless standards, such as the 4th generation (4G) Long Term Evolution (LTE) and 5th generation (5G) New Radio (NR) standards. However, the described implementations can be implemented in any device, system, or network that is capable of transmitting and receiving radio frequency signals according to any of the wireless communication standards, including any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 or 802.16 wireless standards, or other known signals that are used to communicate within a wireless, cellular, or internet-of-things (IoT) network, such as a system utilizing 4G, 5G, 6th generation (6G) , ZigBee, Bluetooth, WiFi, or future radio technology.

[0044] A network (NW) entity (such as a base station) can configure a user equipment (UE) to transmit a UE-initiated (UEI) transmission. When a triggering condition for the UEI transmission is satisfied, the UE may transmit a first uplink (UL) transmission associated with the UEI transmission. Examples of the first UL transmission include a request signal for requesting an UL resource for the UEI transmission, a notification signal indicating usage of a pre-configured UL resource for the UEI transmission, or the UEI transmission itself. The UE may use various UL resources for the first UL transmission, such as a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH) , that are configured in association with the UEI transmission. In a first mode (sometimes interchangeably referred to as “Mode A” ) of a UEI transmission, the UE first transmits a request signal to request an UL resource or UL channel (e.g., dynamic grant PUSCH (DG-PUSCH) ) to use for the UEI transmission. The DG-PUSCH for the UEI transmission is scheduled by the NW entity based on a request signal. In a second mode ( (sometimes interchangeably referred to as “Mode B” ) , the UL resource for the UEI transmission may be a configured grant PUSCH (CG-PUSCH) that is pre-configured by the NW entity. In some implementations, the UE transmits a notification signal before using the CG-PUSCH.

[0045] Because the UE initiates the UEI transmission, the timing of the first UL transmission (such as the request signal, the notification signal, or the UEI transmission) may be unpredictable. There is a potential that the UE may prepare to transmit the first UL transmission during a time when the UE also has a second UL transmission to transmit. The second UL transmission can be any type of UL transmission, including those scheduled / configured / triggered by the NW entity or possibly related to another UEI transmission. A collision can occur when there is an overlap between UL resources for first UL transmission and the second UL transmission.

[0046] This disclosure provides systems, methods, and apparatuses for handling a collision of a first UL transmission associated with a UEI transmission and a second UL transmission. Various aspects of this disclosure provide rules by which a UE can determine which UL resource to use (and thus which UL transmission to transmit) in the event of a collision. In some aspects, the UE can resolve the collision by determining a priority among the overlapped UL transmission (s) . Some of the examples in this disclosure address priority based on the type of first UL transmission (such as the request signal, the notification signal, or the UEI transmission) and the type of the second UL transmission. As an example, when the second UL transmission includes a random access channel (RACH) message, the RACH message may take highest priority compared to the first UL transmission. In other examples, the second UL transmission may include channel state information (CSI) , scheduling request (SR) , link recovery request (LRR) , hybrid automatic repeat request acknowledgment (HARQ-ACK) , or UL data (or uplink shared channel (UL-SCH) ) . In some examples, the second UL transmission includes a second request signal, second notification signal, or second UEI transmission. By way of several examples and alternative options, this disclosure provides example rules to enable the UE to select which UL resource to use based on the content and type of UL transmissions in a collision.

[0047] In some implementations, when the UE selects one UL resource (and associated UL transmission) over another UL resource for another UL transmission, the UE may be able to multiplex or scramble some portion of the other UL transmission onto the selected UL resource. For example, when the selected UL resources include a PUCCH for the prioritized UL transmission, the UE may multiplex uplink control information (UCI) bits from the other (non-transmitted) UL transmission onto the selected PUCCH. Alternatively, or additionally, the UE may multiplex or scramble some portion of the other UL transmission onto a demodulation reference signal (DMRS) that corresponds to the selected UL resource. In yet other examples, the UE may transmit the other UL transmission via a medium access control (MAC) control element (MAC CE) or MAC protocol data unit (MAC PDU) . The selection of  which UL resource and the techniques for handling the collision may depend on rules based on UCI priority or CSI priority.

[0048] In some implementations, there could be collisions among multiple UEI transmissions. For example, a first UEI transmission may prompt a first UL transmission (such as a request signal, a notification signal or the first UEI transmission) that overlaps with a second UL transmission (such as a request signal, a notification signal or the second UEI transmission) for a triggered second UEI transmission. It is possible that different serving cells are configured with different configuration (s) for performing UEI transmissions. Then, it is possible that a first UL transmission for a first UEI transmission for a first serving cell overlaps with a second UL transmission for a second UEI transmission for a second serving cell. This disclosure provides example techniques for resolving the collision among overlapped UL transmission (s) related to multiple UEI transmissions.

[0049] In some implementations, the UEI transmission includes a UEI beam report (UEI-BR) . For brevity, this disclosure may refer to examples based on a UEI-BR. However, all references to UEI-BR can be replaced with any type of UEI transmission, including future reports / messages that might be initiated by the UE based on a configuration or a predefined protocol for the UEI transmission. Other examples of UEI transmissions include a UEI-BR for a lower layer-triggered mobility (LTM) or LTM candidate cell (s) , a UE-initiated power status report, a UE-initiated emergency report, or a UE-initiated low-power mode request, among other examples. These type (s) of UEI transmission may face the issues mentioned above, such as when these UEI transmissions are conveyed by UCI. Generally speaking, for a UEI transmission transmitted by UCI, a UEI transmission involving a request signal requesting an UL resource to convey UEI transmission, or a UEI transmission involving a notification signal notifying usage of a preconfigured UL resource to convey UEI transmission, the above mentioned collision issues may occur and the collisions may be handled using the techniques of this disclosure. Furthermore, while the examples of this disclosure are based on 5G NR radio access technology (RAT) , the concepts can also apply to other RATs, including LTE or 6G.

[0050] Referring to the UEI-BR use case, a NW entity may transmit different synchronization signaling block (SSB) or CSI reference signal (CSI-RS) resources by different beams. The NW entity may configure the UE to report the beam quality, e.g., layer 1 reference signal received power (L1-RSRP) or layer 1 signal to interference plus noise ratio (L1-SINR) for each reported beam. Rather than the NW entity triggering the beam reports, the NW entity may configure the UE to transmit a UEI-BR when the UE detects one or more triggering events. In some implementations, the NW entity may configure the conditions for  triggering events in a UEI-BR configuration. Alternatively, or additionally, the conditions for triggering events may be specified or predefined in a telecommunications standard.

[0051] This disclosure provides techniques to handle various collision issues, including:

[0052] ● how to resolve collision issues of a UEI transmission (e.g., UEI-BR) overlapped with another UL transmission, which may be from the same serving cell or different serving cell,

[0053] ● how to resolve collision issues of an UL transmission (associated with the UEI transmission) for requesting a UL resource or notifying the NW entity of the usage of a UL resource for conveying a UEI transmission, where the UL transmission overlaps with another UL transmission, which may be from the same serving cell or different serving cell, and / or

[0054] ● how to resolve collision issues of a UEI transmission overlapped with a PUSCH or a PUCCH, where some of the UL channels may be from the same serving cell or different serving cell.

[0055] Particular implementations of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. A UE can avoid or resolve collisions caused by a UEI transmission with another UL transmission or another UEI transmission. A UE can apply consistent rule (s) to determine priority of the UL transmissions and select an appropriate UL resource for transmission of a prioritized UL transmission. In some implementations, the techniques of this disclosure can reduce power consumption by enabling UEI transmissions and / or reducing signaling overhead.

[0056] FIG. 1 shows an example wireless communication system 100 and an implementation of a UE 102 handling a collision between a UEI transmission and another UL transmission. Although illustrated as a smartphone in FIG. 1, the UE 102 can be implemented as any suitable computing or electronic device, such as a mobile communication device, a modem, cellular phone, gaming device, navigation device, media device, laptop computer, desktop computer, tablet computer, smart appliance, vehicle-based communication system, an Internet-of-things (IoT) device (e.g., sensor node, controller / actuator node, combination thereof) , and the like. The example wireless communication system 100 shows a NW entity 104. For example, the NW entity 104 may be a base station. The NW entity 104 supports wireless communication with one or more UEs via radio frequency (RF) signaling using one or more applicable RATs as specified by one or more communications protocols or standards. The NW entity 104 may employ any of a variety of RATs, such as operating as a NodeB (or base transceiver station (BTS) ) for a Universal Mobile Telecommunications System (UMTS)  RAT (also known as “3G” ) , operating as an enhanced NodeB ( “eNB” ) for a Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) RAT, operating as a 5G node B ( “gNB” ) for a 3GPP Fifth Generation New Radio (5G NR) RAT, and the like. The NW entity 104 (e.g., base station, an Evolved Universal Terrestrial Radio Access Network Node B (E-UTRAN Node B) , evolved Node B, eNodeB, eNB, Next Generation Node B, gNode B, gNB, ng-eNB, access point, radio head or the like) , may be implemented in a macrocell, microcell, small cell, picocell, or the like, or any combination thereof. In some aspects, the functionality, and thus the hardware components, of the NW entity 104 may be distributed across multiple network nodes or devices and may be distributed in a manner to perform the functions described herein. As one example, the functionality of the NW entity 104 may be distributed across a radio unit (RU) , distributed unit (DU) , or central unit (CU) .

[0057] The NW entity 104 and the UE 102 communicate using wireless links. The wireless links can include one or more wireless links (e.g., radio links) or bearers implemented using any suitable communication protocol or standard, or combination of communication protocols or standards, such as 3GPP LTE, 5G NR, and so forth. In some implementations, multiple wireless links are aggregated in a carrier aggregation to provide a higher data rate for the UE 102. The NW entity 104 may be part of a radio access network (RAN) , for example, an E-UTRAN, 5G NR RAN, or NR RAN. The NW entity 104 may be connected to a core network (not shown) that provides access to services or other networks. The NW entity 104 and the UE 102 may be configured to use multiple-user multiple-input multiple-output (MU-MIMO) communication in which the NW entity can transmit multiple downlink transmissions using beam forming and orthogonal frequency division multiplexing (OFDM) .

[0058] The NW entity 104 and a UE 102 utilize a UL transmission path for RF transmissions (referred to as uplink transmissions) from the UE 102 to the NW entity 104, and a downlink (DL) transmission path for RF transmissions (referred to as downlink transmissions) from the NW entity 104 to the UE 102. Examples of UL transmission paths include a PUSCH, a PUCCH, and a physical random access channel (PRACH) . The PUSCH is used for the transmission of user data, such as voice data, video data, or text message data from the UE to the NW entity. Additionally, the PUSCH may be used to transmit control information (e.g., uplink control information (UCI) ) . The PUSCH may be shared by multiple UEs. The PUCCH is used for transmitting control information (e.g., UCI) from the UE to the network, such as channel quality feedback, scheduling requests, and acknowledgments. The PRACH is used for random access in the uplink direction, enabling the UE to access the system without a prior reservation. The DL transmission path may include one or more of a Physical Downlink Shared Channel (PDSCH) , a Physical Downlink Control Channel (PDCCH) , a Physical  Broadcast Channel (PBCH) , or a paging channel. The PDSCH is used for transmission of user data from the NW entity 104 to the UE 102. The PDSCH may be shared by multiple UEs. As with the PUSCH, PDSCH data may be any type of information, such as voice data, video data, or text message data. The paging channel is used to notify the UE 102 that there is incoming traffic for it from the NW entity 104.

[0059] Radio resource control (RRC) is a component of a radio interface protocol stack that the NW entity and the UE use to communicate. Among other functions, the NW entity and the UE use RRC messaging to establish and / or release radio connections and resources. In an RRC connected state, the UE has an active wireless radio connection with a NW entity. When an active wireless radio connection is not needed, the UE can transition from the RRC connected state to an RRC idle or inactive state to release or suspend, respectively, the wireless radio connection.

[0060] The NW entity transmits one or more SSBs. Among other features, an SSB includes downlink synchronization signals (such as the primary synchronization signal (PSS) and secondary synchronization signal (SSS) ) so that the UE can maintain synchronization with the NW entity. While each cell has at least one SSB, the NW entity can transmit multiple SSBs within a cell. For example, the NW entity might transmit a different SSB for each of a plurality of beams or transmission reception points (TRPs) . Alternatively, or additionally, a NW entity can operate multiple cells and transmit multiple SSBs for the cells.

[0061] In some implementations, the NW entity 104 may configure the UE 102 to perform transmission of a UEI beam report (UEI-BR) . A UEI-BR can also be referred to as a UE-initiated beam report or other terms. For example, the NW entity 104 can provide a configuration 120 of a UEI transmission that configures the UE 102 to perform a UEI-BR, such that the UE 102 decides when to transmit the UEI-BR based on conditions at the UE 102. In some implementations, if the NW entity 104 configures the UE 102 to perform a UEI-BR, the UE 102 may transmit a UEI-BR on a pre-configured or pre-indicated UL resource or channel (such as a CG-PUSCH) or on a dynamically allocated UL resource or channel (such as a DG-PUSCH) . Here, the CG-PUSCH or DG-PUSCH may be specific to the UEI-BR and not the same as a different CG-PUSCH / DG-PUSCH for a different type of UL transmission. In some implementations, the UE may transmit a UEI-BR only when the UE detects a triggering event for the UEI-BR. In some other implementations, the UE may transmit a UEI-BR only when the UE detects a triggering event for the UEI-BR for a number of times. In some implementations, the UEI-BR may include a beam report or a CSI report for reporting L1-RSRP and / or L1-SINR. In some implementations, the UEI-BR may report an SSB index  (SSB resource indicator (SSBRI) ) , a CSI-RS index (CSI-RS resource indicator (CRI) ) , and / or a (Capability) Index.

[0062] In some implementations, the NW entity may provide configuration (s) 120 of UEI-BR (s) based on a serving cell or a cell group. The configuration (s) 120 of a UEI-BR may include or refer to at least one of the following: measurement reference signal (RS) configuration (s) for the current beam, measurement RS configuration (s) for a new beam or candidate beam, and / or an indication of the mode (such as a first mode or a second mode) of a UEI-BR. The first mode ( “Mode A” ) is further described with reference to FIG. 2A. The second mode ( “Mode B” ) is further described with reference to FIG. 2B.

[0063] In some implementations, when the configuration (s) 120 of a UEI-BR includes measurement RS configuration (s) for the current beam, the current beam may be referred to by an indicated transmission configuration indication (TCI) state (e.g., joint, DL, or UL TCI state) , a quasi-co-location (QCL) assumption or a joint, DL, or UL TCI state applied for a channel or RS not following or not applying the indicated TCI state. Alternatively, or additionally, the measurement RS configuration (s) for the current beam may be implicitly derived from a QCL RS (e.g., TRS or CSI-RS or CSI-RS for beam management (BM) ) of the indicated TCI state or the SSB which is QCLed with the QCL RS in the indicated TCI state, or explicitly configured by RRC, MAC-CE, or MAC PDU. In some implementations, when the configuration (s) 120 of a UEI-BR includes measurement RS configuration (s) for the new beam or candidate beam, the measurement RS configurations (s) may be explicitly configured by RRC (e.g., reusing legacy configuration of RS measurement or in TCI-State) or MAC-CE, or implicitly derived from QCL RS (s) of activated TCI state (s) , or implicitly derived from QCL RS (s) of configured TCI state (s) . In some implementations, the configuration (s) 120 indicate whether a first mode or a second mode of performing a UEI-BR is used for a serving cell, one or more component carrier (s) (CC (s) ) , a PUCCH cell group, or a cell group.

[0064] Shown at block 130, the UE may trigger a UEI transmission based on one or more triggering events. In some implementations, the UE may trigger the UEI-BR in response to detecting at least one of the following triggering events:

[0065] ● Event-1: Quality of the current beam is worse than a certain threshold.

[0066] ● Event-2: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the current beam.

[0067] ● Event-3: Quality of a new beam is better than a certain threshold.

[0068] ● Event-4: Quality of the current beam is worse than a threshold 1, and quality of at least one new beam is better than a threshold 2.

[0069] ● Event-5: Absolute value of the difference between the quality of the current beam and the quality of at least one new beam is lower than a threshold.

[0070] ● Event-6: When the current beam is not in the best K>1 beams (out of configured beams for measurement and reporting) .

[0071] ● Event-7: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from an activated TCI state with the M-th best quality among activated TCI state (s) . For such an event, value of M may be configured / indicated by the NW entity.

[0072] ● Event-7a: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the worst quality.

[0073] ● Event-7b: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the best quality.

[0074] ● Event-8: Quality of M>1 new beams, such as L1-RSRP, become a threshold value better than the current beam.

[0075] ● Event-9: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the configured reference RS (can be SSB or CSI-RS) .

[0076] In some implementations, the UE may perform transmission of UEI-BR based on a UEI-BR configuration. In some implementations, the NW entity may configure or indicate, to the UE, one or more UEI beam report configurations. In some implementations, the NW entity may configure or indicate the report quantity of a UEI-BR by a UEI-BR configuration. In some implementations, a CSI report configuration of UEI-BR may be the same as that of a CSI report not for a UEI-BR (e.g., CSI-ReportConfig) . In some implementations, CSI report configuration of a UEI-BR is a CSI-ReportConfig including a RRC parameter indicating the CSI report configuration is for the UEI-BR. In some implementations, a CSI report configuration for configuring UEI-BR may be a CSI-ReportConfig without including a RRC parameter indicating a time domain behavior (e.g., reportConfigType) .

[0077] Based on triggering the UEI transmission (block 130) , the UE may prepare a first UL transmission 150 (such as a request signal, a notification signal, or a UEI-BR) associated with the UEI transmission. The UL resource for the first UL transmission 150 may overlap a UL resource for a second UL transmission 170 (such as a different UL transmission or another UEI transmission, including possibly a second UEI-BR for the same or different cell) . The overlap can be referred to as a collision 160 at the UE 102 preventing the UE 102 from concurrently transmitting both the first UL transmission 150 and the second UL transmission 170 on the overlapped UL resources.

[0078] In accordance with aspects of this disclosure, the UE 102 can resolve the collision (shown at block 180) . This disclosure includes example techniques and rules based on priority, UL content, and / or UL channel (s) associated with the UEI transmission and at least one other UL transmission. The UE may use the example techniques and rules to select (block 182) which UL resource (and thus which UL transmission) the UE 102 will transmit.

[0079] Various examples of this disclosure describe the UE 102 resolving collision or overlap of two or more of the following transmissions, including cases (s) that multiple transmissions with the same type are overlapped:

[0080] ● a UEI transmission (e.g., UL channel or resource for conveying UEI-BR) ,

[0081] ● a request signal requesting a UL resource to convey a UEI transmission (e.g., a request signal for a UL resource for conveying a UEI-BR) ,

[0082] ● a notification signal notifying the NW entity of a usage of a preconfigured UL resource to convey a UEI transmission (e.g., notification signal for usage of a preconfigured UL resource for conveying a UEI-BR) ,

[0083] ● a PUCCH (with at least SR or LRR (SR / LRR) , or at least HARQ-ACK, or at least CSI) ,

[0084] ● a PRACH,

[0085] ● a Msg3 or MsgA, and / or

[0086] ● a DG-PUSCH or a CG-PUSCH.

[0087] The examples provided throughout this document may be applied for use case (s) other than a UEI-BR or a UEI-BR related procedure. Throughout this document, the first UL channel (e.g., a DG-PUSCH) the second UL channel (e.g., CG-PUSCH) may be replaced with or referred to as a UL channel or resource for conveying a UEI transmission. Throughout this document, a request signal may be replaced with or referred to as a signal or transmission for requesting a UL channel or resource for conveying a UEI transmission. Throughout this document, a notification signal may be replaced with or referred to as a signal or transmission for notifying usage of a preconfigured UL channel or resource for conveying a UEI transmission. Throughout this document, procedures related to a first mode or a second mode may be applied for a UEI transmission other than a UEI-BR.

[0088] FIG. 2A shows an example message diagram 200A for a first mode of UEI transmission, in which a request signal 252 precedes the UEI transmission 256A. The UE 102 may transmit a request signal 252 on a PUCCH to request an UL resource for a UL channel to transmit a UEI-BR. In such cases, the capability of the PUCCH or the length of  the request signal may be one-bit. Alternatively, the capability of the PUCCH or the length of the request signal may be multiple-bit.

[0089] In some implementations, the request signal 252 may be a SR or a new UCI (i.e., a UCI other than normal SR, HARQ-ACK, or CSI) . The SR may be a special SR or a normal SR. The UE 102 may transmit a special SR for requesting a UL resource for a UL channel to transmit a UEI-BR (e.g., a PUSCH dedicated for transmitting UEI-BR or other UL channel (say PUCCH) dedicated for transmitting UEI-BR) . The UE 102 may transmit a normal SR for requesting a PUSCH for transmitting UL data, which may not be dedicated for transmitting UEI-BR. This may imply that, without additional indication, when the NW entity receives the PUSCH corresponding to the normal SR, the NW entity may not know whether a UEI-BR is transmitted on the PUSCH, and / or may perform blindly decoding on the PUSCH assuming a UEI-BR may or may not transmitted. The UE 102 may transmit the request signal 252, in response to detecting one or more event (s) for triggering a UEI-BR. The NW entity 104 may transmit a response (e.g., a DCI 253) to the UE 102 in response to receiving the request signal 252. The DCI 253 can indicate an UL resource for a UL channel to transmit the UEI-BR. The UE 102 may transmit the UEI-BR 256A on the UL resource for the UL channel indicated by the DCI 253. In this scenario, the UL channel may be a DG-PUSCH, a CG-PUSCH or a PUCCH.

[0090] In some implementations, if there is an available UL channel, the UE 102 may skip transmitting the request signal 252 to the NW entity 104, and / or the UE may just transmit the UEI-BR 256A on the available UL channel. In some implementations, the UE may determine whether there is an available UL channel by itself (e.g., by considering a waiting time till a next transmission occasion of a UL channel) .

[0091] FIG. 2B shows an example message diagram 200B for a second mode of UEI transmission, in which a NW entity 104 preconfigures the UL resource for the UEI transmission 256B and the UE 102 may transmit a notification signal 254 indicating usage of the preconfigured UL resource. The NW entity 104 may pre-configure one or more UL resources for UL channel (s) , to the UE 102. For example, the NW entity 104 can provide a configuration 220 via RRC signaling to pre-configure the UL resource for the UEI transmission 256B.

[0092] In some implementations, the UE 102 may transmit the notification signal 254 on a PUCCH to indicate that the UE 102 will use the preconfigured resource for the UL channel (s) . The capability of the PUCCH or the length of the notification signal 254 may be one-bit or may be multiple-bit. In some implementations, the notification signal may be a SR or a UCI  other than normal a SR, HARQ-ACK, or CSI. The SR may be a special SR or a normal SR. The UE 102 may transmit a special SR for notifying / indicating usage of a preconfigured UL resource for a UL channel to transmit a UEI-BR (e.g., a PUSCH dedicated for transmitting UEI-BR or other UL channel (say PUCCH) dedicated for transmitting UEI-BR) . The UE 102 may transmit the notification signal 254 in response to detecting one or more event (s) for triggering a UEI-BR.

[0093] In some implementations, the NW entity 104 may transmit a response 259 (e.g., a DCI or other DL signal) to the UE in response to receiving the notification signal 254. The DCI from the NW entity 104 may indicate that the UE 102 can proceed to use the pre-configured UL resource. The UE 102 may transmit the UEI-BR 256B on the preconfigured UL resource for the UL channel (s) notified by the notification signal 254. In this scenario, the UL channel (s) may be or include a DG-PUSCH, a CG-PUSCH or a PUCCH.

[0094] Typically, in the first mode (as in FIG. 2A) , the UL resource for the UEI transmission 256A is associated with a DG-PUSCH. Typically, in the second mode (as in FIG. 2B) , the UL resource for the UEI transmission 256B is associated with a CG-PUSCH. However, other types of UL resource may be used for the UEI transmission in various modes. In some aspects, the distinction between the first mode and the second mode is based on the presence of a request signal for requesting the UL resource versus the notification signal notifying use of a pre-configured UL resource.

[0095] In some implementations, the NW entity may indicate or configure a dedicated RRC parameter to indicate which mode is configured for a UEI-BR. In some implementations, the dedicated RRC parameter may be configured for a serving cell or a cell group. In some other implementations, the NW entity may indicate or the UE may determine which mode of a UEI-BR is used based on whether the NW entity (pre-) configures one or more resources for a UL channel for UEI-BR. For example, if the NW entity does not (pre-) configure one or more resources for a UL channel for a UEI-BR for a serving cell or a cell group, the UE may determine the first mode is used for the serving cell or the cell group; if the NW entity (pre-) configures one or more resources for a UL channel for a UEI-BR for a serving cell or a cell group, the UE may determine the second mode is used for the serving cell or the cell group.

[0096] FIG. 2C shows several example potential collisions that might occur between resources for a UEI transmission and other UL resources. Example first UL transmissions 250 include the request signal 252, the UEI transmission 256A (using Mode A) , the notification signal 254, and the UEI transmission 256B (using Mode B) as described with reference to FIG. 2A and FIG. 2B. Example second UL transmissions 270 can by any of a  variety of UL transmissions including a HARQ-ACK (via a PUCCH) 272A, an SR / LRR (via a PUCCH) 272B, a CSI report (via a PUCCH) 272C, other UCI (via PUCCH or PUSCH) 272D, UL data (e.g., a normal PUSCH, DG-PUSCH, or CG-PUSCH) 274, a UL transmission related to another UEI transmission 276, or a PRACH or a RACH message (e.g., Msg3 / MsgA PUSCH) 278. In some implementations, the term “normal PUSCH” refer to a PUSCH without UEI-BR multiplexed, piggybacked, or scrambled on it or a PUSCH not scheduled for Msg3 / A transmission or retransmission. In some implementations, the normal PUSCH may be a DG-PUSCH or CG-PUSCH.

[0097] Depending on UL resource configuration (s) , it is possible for any of the example second UL transmissions 270 to be associated with UL resources that overlap 260 in the time domain with UL resources for the example first UL transmissions 250. Furthermore, shown at block 298, it is possible for the example second UL transmissions 270 to be in the same serving cell or different serving cell as the example first UL transmissions 250, increasing the possibility of overlapping UL resources.

[0098] Each combination of an example first UL transmission 250 and an example second UL transmission 270 may have different collision handling rules based on the type and content of the UL transmissions. For example, a collision that includes a RACH message (e.g., Msg3 / MsgA PUSCH) 278 may get different treatment based on the parameters for a random access procedure. The Msg3 and MsgA are typically expected within a particular time frame and format so collision handling rules may prioritize the RACH message (e.g., Msg3 / MsgA PUSCH) 278. A Type-1 random access procedure (also referred to as a 4-step RACH) includes a protocol of at least four messages (referred to as Msg1, Msg2, Msg3, and Msg4) . To begin the Type-1 random access procedure, a UE transmits a random access preamble in a first message (Msg1) via a PRACH. The network entity responds to the Msg1 by transmitting a second message (Msg2) via a PDSCH. The Msg2 is also referred to as a random access response (RAR) transmission. In some instances, the Msg2 configures an uplink grant of scheduled resources (in a PUSCH) for the UE to use for transmission of a third message (Msg3) . In response to the Msg3, the network entity transmits a fourth message (Msg4) . The Msg4 is also referred to as a contention resolution transmission. A Type-2 random access procedure can also be referred to as a 2-step RACH. The 2-step RACH is a newer protocol for random access compared to the 4-step RACH. In the 2-step RACH, the UE can transmit the random access preamble (e.g., PRACH preamble) followed by a PUSCH in the first message (referred to as MsgA) . The network entity responds to the MsgA by transmitting a second message (MsgB) via a PDSCH. One way to describe the 2-step RACH  is that the MsgA is a combination of the Msg1 and Msg3 in a first transmission and the MsgB is a combination of the Msg2 and Msg4 in a second transmission.

[0099] FIG. 3 shows a message diagram 300 of one of a UEI transmission, a request signal or a notification signal overlapping with one or more UL transmission (s) . The UE 102 may transmit a UE capability 310 indicating that the UE supports UEI transmission. In some implementations, the UE capability 310 can indicate whether the UE 102 supports UEI transmissions for multiple serving cells.

[0100] The NW entity 104 transmits a configuration 320 for configuring the UEI transmission (e.g., UEI-BR configuration) for one or more serving cells. The configuration 320 may be communicated by RRC signaling. In some implementations, the configuration 320 can indicate at least one triggering event. Alternatively, or additionally, the triggering event may be predefined or specified in a telecommunications standard. At block 330, the UE detects the triggering event one or more times. Alternatively, or additionally, the UE may detect any type of condition associated with the UEI transmission has been satisfied.

[0101] At block 340, the UE 102 prepares to transmit a first UL transmission associated with the UEI transmission. For example, the UE 102 may determine to transmit one of a UEI transmission, a request signal for UEI transmission, or a notification signal for UEI transmission. The type of the first UL transmission may depend on the mode configured for the UEI transmission and / or available UL resources. The first UL transmission may be any of the example first UL transmissions 250 described with reference to FIG. 2C.

[0102] At block 360, the UE 102 detects whether the one of the UEI transmission, the request signal, or the notification signal would overlap in the time domain with one or more other UL transmission (s) (such as an of the example second UL transmissions 270 described with reference to FIG. 2C) , which could be related or not related to another UEI transmission. At block 380, if the UL transmissions are associated with overlapping UL resources, the UE 102 determines a priority between the one or more second UL transmission (s) and the first UL transmission associated with the UEI transmission. The UE 102 transmits 390 at least one of the one or more second UL transmission (s) or the first UL transmission associated with the UEI transmission, whichever has higher priority. Although priority is used as the example in FIG. 3, other example rule (s) and selection techniques are described with reference to various examples of this disclosure, such as FIG. 4A through FIG. 18C.

[0103] Next, several example scenarios are discussed with reference to FIG. 4A through FIG. 18C. Generally speaking, similar events in FIGs. 4A–18C are labeled with reference numbers that have the same lower-order digits. For brevity, similar messages or events are  not discussed in detail in each instance, but the discussion of a certain event with reference to one of the figures also applies to similar messages or events in other figures. For example, blocks 330, 430, 530, etc., refer to similar concepts such as detection of one or more triggering events. Blocks 180, 380, 480A, 480B, 580A, 580B, etc., refer to UE determining which UL resource (s) to use (and thus which UL transmission) to use based on priority or other collision handling rules. FIG. 4A and FIG. 4B show example scenarios of resolving a collision for a UEI transmission of a first mode, while FIG. 5A and FIG. 5B show example scenarios of resolving a collision for a UEI transmission of a second mode. For brevity, the descriptions of messages and blocks are abbreviated to focus on the differences among the features while omitting redundant explanation. However, any of the variations or alternatives described for messages / blocks in one Figure may also apply to messages / blocks having the same lower-order digits in another Figure.

[0104] FIG. 4A shows a message diagram 400A of a UEI transmission in a first mode in which a collision occurs between a UEI-BR and another UL transmission. In FIG. 4A, the UE capability 410 may include an indication that the UE 102 supports a first mode for a UEI-BR. The NW entity 104 may provide a configuration 420 that configures the first mode for the UEI-BR. Based on detecting one or more triggering events (block 330) , at block 440 the UE 102 prepares to transmit a request signal 252 for the first mode. At block 460A, the UE 102 detects whether transmission of the request signal 252 would overlap in time domain with one or more UL transmission (s) 270. At block 480A, the UE 102 resolves the collision by determining priority between the request signal 252 and the one or more other UL transmission (s) 270. The UE 102 transmits 490A at least one of the request signal or the one or more UL transmission (s) , whichever has higher priority.

[0105] FIG. 4B shows a message diagram 400B of a UEI transmission in a first mode in which a collision occurs between a request signal for a UEI-BR and another UL transmission. FIG. 4B begins the same as FIG. 4A up to block 480A. In the example of FIG. 4B, the request signal 252 either did not have a collision with another UL transmission or the request signal 252 had a higher priority compared to other UL transmissions at the time for transmission of the request signal 252. Thus, shown in FIG. 4B, the UE 102 transmits the request signal 252 and optionally receives a DCI 253 from the NW entity 104. The DCI 253 schedules a UL resource (such as a DG-PUSCH) for the UEI-BR.

[0106] At block 460B, the UE 102 detects that transmission of the UL resource for the UEI-BR 256A would overlap in time domain with one or more other UL transmission (s) 270. At block 480B, the UE 102 resolves the collision by determining priority between the UEI-BR 256A and the one or more other UL transmission (s) 270. The UE 102 transmits 490B at least  one of the UL resource for the UEI-BR or the one or more UL transmission (s) , whichever has higher priority.

[0107] FIG. 5A shows a message diagram 500A of a UEI transmission in a second mode in which a collision occurs between a UEI-BR and another UL transmission. FIG. 5A is similar to FIG. 4A, except that FIG. 5A refers to a notification signal 254 (rather than request signal 252) because FIG. 5A uses the second mode (instead of the first mode) . Note that although the figures are similar, the priority of a notification signal 254 may be different than the priority for a request signal 252.

[0108] In FIG. 5A, the UE capability 510 may include an indication that the UE 102 supports the second mode for a UEI-BR. Based on the UE capability 510, the NW entity 104 may provide a configuration 520 that configures the second mode for the UEI-BR. The configuration 520 also may indicate a pre-configured UL resource for the UEI-BR. Based on detecting one or more triggering events (block 330) , at block 540 the UE 102 prepares to transmit a notification signal 254 for the second mode. At block 560A, the UE 102 detects whether transmission of the notification signal 254 would overlap in time domain with one or more UL transmission (s) 270. At block 580A, the UE 102 resolves the collision by determining priority between the notification signal 254 and the one or more other UL transmission (s) 270. The UE 102 transmits 590A at least one of the notification signal or the one or more UL transmission (s) , whichever has higher priority.

[0109] FIG. 5B shows a message diagram 500B of a UEI transmission in a second mode in which a collision occurs between a notification signal for a UEI-BR and another UL transmission. FIG. 5B begins the same as FIG. 5A up to block 580A. In the example of FIG. 5B, the notification signal 254 either did not have a collision with another UL transmission or the notification signal 254 had a higher priority compared to other UL transmissions at the time for transmission of the notification signal 254. Thus, shown in FIG. 5B, the UE 102 transmits the notification signal 254 and optionally receives a response 259 from the NW entity 104. At block 560B, the UE 102 detects that transmission of the UL resource for the UEI-BR 256B (via the pre-configured UL resource) would overlap in time domain with one or more other UL transmission (s) 270. At block 580B, the UE 102 resolves the collision by determining priority between the UEI-BR 256B and the one or more other UL transmission (s) 270. The UE 102 transmits 590B at least one of the UL resource for the UEI-BR or the one or more UL transmission (s) , whichever has higher priority.

[0110] Next, several example scenarios are discussed with reference to FIG. 6 through FIG. 18C. FIG. 6 through FIG. 9 address examples in which an UL transmission for a UEI  transmission (e.g., CG-PUSCH or DG-PUSCH) overlaps with another UL transmission not for UEI transmission (e.g., PUSCH, PUCCH, sometimes referred to as a “normal” PUSCH or normal PUCCH) . FIG. 10 though FIG. 13 address examples in which a first UL transmission for a first UEI transmission (e.g., request signal, DG-PUSCH, notification signal, or CG-PUSCH) overlaps with a second UL transmission for a second UEI transmission (e.g., request signal, DG-PUSCH, notification signal, or CG-PUSCH) . FIG. 14 through FIG. 17 address examples in which a first UL transmission for a UEI transmission (e.g., request signal or notification signal) overlaps with a second UL transmission not for UEI transmission (e.g., PUSCH or PUCCH) . FIG. 18A through FIG. 18C address examples in which there might be multiple overlapping UL transmissions.

[0111] FIG. 6 through FIG. 18C include several example alternative options, which also may be referred to as a collision handling rule (or just “rule” ) . For clarity, the alternative options are numbered using a first number to indicate a use case followed by a dash and a second number to indicate the alternative rule that may apply to that use case. Although shown as alternative options on each figure, it should be apparent that a specification or technical standard may adopt only one rule for each use case. Alternatively, multiple rules may be defined and then enabled / configured by the NW entity.

[0112] Before proceeding with the examples, some terms may be relevant to the following description. As described previously, the NW entity may provide, to the UE, configuration (s) for performing UEI-BR in a serving cell. The NW entity may configure, to the UE, configuration (s) of indicating whether the UE operates a first mode or a second mode of performing a UEI-BR. In some implementations, the configuration (s) of indicating the first mode or the second mode may be configured for a serving cell, a one or more CC (s) , a PUCCH cell group, or a cell group. Thus, it is possible to have multiple configurations that are cell-specific, carrier-specific, cell-group-specific, etc. In some implementations, if the NW entity configures, to the UE, to operate a first mode of a UEI-BR, the UE may transmit a request signal to the NW entity. In some implementations, for the first mode, the UE may transmit the request signal to the NW entity for requesting UL resource (s) for a first UL channel. In some implementations, the UE may transmit the request signal via a PUCCH. After the NW entity receives the request signal, the NW entity may transmit a DCI to schedule / indicate the UE to transmit a UEI-BR on a first UL channel. The first UL channel refers to a UL channel that is configured for the first mode ( "Mode A" ) . In some implementations, the UE may transmit at least one UEI-BR on the first UL channel. One example of the first UL channel is a DG-PUSCH for UEI-BR in the first mode. Another example of the first UL channel is a  CG-PUSCH. Thus, the NW entity may indicate at least one transmission occasion of the CG-PUSCH can be used for UEI-BR (e.g., via the DCI) .

[0113] In some implementations, if the NW entity configures, to the UE, to operate a second mode of a UEI-BR, the UE may transmit a notification signal to the NW entity. In some implementations, for the second mode, the UE may transmit the notification signal to the NW entity for notifying / claiming usage of UL resources (preconfigured by the NW entity) for a second UL channel. The second UL channel refers to a UL channel that is preconfigured for the second mode ( "Mode B" ) . In some implementations, the UE may transmit the notification signal via a PUCCH. In some implementations, for the second mode, the UE may transmit at least one UEI-BR on the second UL channel. A first example of the second UL channel is a CG-PUSCH for UEI-BR in the second mode. For the first example, the NW entity may refrain from configuring a (valid) HARQ process ID for the CG-PUSCH or may configure an invalid / default HARQ process ID for the CG-PUSCH. A second example of the second UL channel may be a CG-PUSCH used by the UE to transmit UEI-BR, where the CG-PUSCH is not dedicated for UEI-BR, and the UE is configured to perform UEI-BR in the first or second mode. In some implementations, the UE may transmit the second UL channel on P transmission occasion (s) after Q symbols / slots after transmitting the last symbol of the notification signal, where P and Q may be pre-defined, e.g., P=1 and Q=28 symbols or 2 slots, configured by the NW entity, or reported by the UE via UE capability or the notification signal. Alternatively, or additionally, P may be larger than one. This may imply that the UE may transmit at least one UEI-BR on more than one transmission occasion (s) of the second UL channel, after transmitting the notification signal and / or receiving a response of the notification signal. If P is more than one, these P transmission occasion (s) may be consecutive transmission occasion (s) . In one example, these P transmission occasion (s) may exclude an invalid transmission occasion, e.g., a transmission occasion in DL slot.

[0114] In some implementations, if UL-SCH or UL data is allowed to be transmitted on the second UL channel, the UE may perform one of the following:

[0115] ● The UE may report whether UL-SCH or UL data is transmitted or not by UEI-BR, notification signal, DMRS sequence of PUSCH or a UL signaling on the second UL channel.

[0116] ● If there is no UL-SCH or UL data to be transmitted on the second UL channel, the UE may perform at least one of the following options:

[0117] ○ Option 1: Transmit or multiplex padding bits in MAC PDU or one or more MAC CE (s) , e.g., power headroom report (PHR) ;

[0118] ○ Option 2: Refrain from transmitting anything in the data REs of the second UL channel; or

[0119] ○ Option 3: Report that UL-SCH or UL data are not transmitted. For such an option, the UE may report whether UL-SCH or UL data is transmitted or not by UEI-BR, notification signal, DMRS sequence of PUSCH or a UL signaling on the second UL channel.

[0120] In some implementations, for the second mode, the NW entity may configure two UL channels for UEI-BR, where one is for UEI-BR only (e.g., the second UL channel) and the other one is for UEI-BR + UL data; the UE may select one of them to transmit. In some implementations, the UE may further indicate which one is selected in the notification signal. Alternatively, the UE may determine which one is selected based on whether the UE determines to transmit data and the NW entity may perform blind detection of the two UL channels (e.g., receive both UL channels and detect which one can be decoded successfully) .

[0121] In some implementations, for the first mode, the UE may indicate, to the NW entity via the request signal, whether the UE requires a UL channel for UEI-BR only (e.g., the first UL channel) , or a UL channel for UEI-BR + UL data. The latter case may imply that the request signal is encoded or multiplexed jointly with a SR. In some implementations, upon receiving the request signal from the UE, the NW entity may schedule two UL channels for UEI-BR, where one is for UEI-BR only (e.g., the first UL channel) and the other one is for UEI-BR + UL data. In such implementations, the NW entity may not realize whether the UE has the need for transmitting UL data. The NW entity may perform blind detection of the two UL channels (e.g., receive both UL channels and detect which one can be decoded successfully) .

[0122] FIG. 6 shows a flow diagram 600 for handling a collision between a CG-PUSCH for UEI transmission 656 (e.g., a second UL channel) and a normal PUSCH 672. At block 660, the UE detects a collision (overlap) of the CG-PUSCH for UEI transmission 656 and the normal PUSCH 672. In some implementations, the UE may be configured / scheduled / indicated, by the NW entity, or may determine to transmit the second UL channel and a normal PUSCH. In some implementations, the UE may transmit the second UL channel and the normal PUSCH in the same serving cell or different serving cells in a band or band combination. In some implementations, the normal PUSCH may be referred to as a PUSCH without UEI-BR multiplexed / piggybacked / scrambled on it. In some implementations, the normal PUSCH may be referred to as a PUSCH not scheduled for Msg3 / A transmission or retransmission. In some implementations, the normal PUSCH may be a DG-PUSCH or CG-PUSCH.

[0123] Referring to block 660, the UE may detect a collision if transmission of the second UL channel (i.e., the CG-PUSCH for UEI transmission 656) and that of the normal PUSCH (i.e., the normal PUSCH 672) would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell. At block 660, the UE may detect a collision if the transmission of the second UL channel and that of the normal PUSCH would be transmitted on the same carrier or serving cell, and the interval between the transmission of the second UL channel and that of the normal PUSCH is less than a preconfigured or UE-reported value.

[0124] Based on the collision, the UE may handle the collision using one or more rules for collision handling 180.

[0125] At block 682 (referred to as an example alternative 1-1) , the UE may drop or refrain from transmitting the normal PUSCH. For such alternative, the UE may transmit an UL data or UL-SCH on the second UL channel, where the UL data or UL-SCH was scheduled to be transmitted by the normal PUSCH. In some implementations, the NW entity may configure / indicate and / or the UE may report whether the UE transmits the UL data or UL-SCH on the second UL channel, where the UL data or UL-SCH was scheduled to be transmitted by the normal PUSCH. In some implementations, if the UE transmits UL data or UL-SCH (which was scheduled to be transmitted by the normal PUSCH) on the second UL channel, the NW entity and UE may determine that the UL data or UL-SCH is based on the HARQ process configured for the second UL channel, and / or the HARQ process configured for the CG-PUSCH (if the normal PUSCH is a CG-PUSCH) and / or the HARQ process scheduled for the DG-PUSCH (if the normal PUSCH is a DG-PUSCH) . The NW entity and UE may determine the transport block size (TBS) (or MCS) based on the TBS (or modulation and coding scheme (MCS) ) for the UL data configured in the configuration for the second UL channel, and / or configured in the configuration for CG-PUSCH (if the normal PUSCH is a CG-PUSCH) and / or the scheduling information for the DG-PUSCH (if the normal PUSCH is a DG-PUSCH) .

[0126] For block 682, in some implementations, the NW entity and UE may determine whether the UE transmits the UL data or UL-SCH (which was scheduled to be transmitted by the normal PUSCH) on the second UL channel, based on whether the UL data or UL-SCH is for retransmission or initial transmission. In one example, at block 693, the UE may multiplex or transmit the UL data or UL-SCH for initial transmission on the second UL channel. In one example, shown at block 697, the UE may refrain from multiplexing or transmitting the UL data or UL-SCH for retransmission on the second UL channel.

[0127] For block 682, in some implementations, if the UE drops or refrains from transmitting the UL data or UL-SCH (which was scheduled to be transmitted by the normal PUSCH) on the second UL channel, the UE may perform one of the following implementation (s) . In a first implementation, the UE may store the UL data in the HARQ buffer for the corresponding HARQ process. Thus, when scheduled with a retransmission of the HARQ process, the UE may retransmit the UL data. In a second implementation, the UE may still maintain the HARQ buffer for the corresponding HARQ process as before the NW entity schedules / configures the UL data / UL-SCH or the normal PUSCH. Thus, when scheduled with a retransmission of the HARQ process, the UE may retransmit the data in the HARQ buffer for the HARQ process instead of transmitting the UL data. The NW entity may configure whether the UE should perform the HARQ buffer management based on the first or second implementations above. The UE may report the UE capability indicating whether it supports the first and / or the second implementation above.

[0128] At block 684 (example alternative 1-2) , the UE may drop or refrain from transmitting the second UL channel. For such alternative, the UE may multiplex (block 695) or transmit the at least one UEI transmission (e.g., UEI-BR) on the normal PUSCH. In one example, the UE may determine the UCI multiplexing priority for the UEI-BR based on a priority index that is pre-defined (e.g., 0 or 1) , or configured by the NW entity, and the UE may perform the UCI multiplexing based on the procedure in 3GPP TS 38.212 section 6.3.2. For such alternative, the NW entity may configure / indicate and / or the UE may report whether the UE multiplexes or transmits the at least one UEI-BR on the normal PUSCH. Alternatively, or additionally, the UE may determine that the current transmission occasion of the second UL channel is not available for the UEI-BR (e.g., due to overlapping with other UL resource) and may transmit the UEI-BR on the next available transmission occasion of the second UL channel.

[0129] At block 688 (example alternative 1-3) , the UE may perform example alternative 1-1 or example alternative 1-2 depending on the content of the normal PUSCH, e.g., whether it is for CSI only, data only, and / or carrying HARQ-ACK. For example, if the normal PUSCH is for CSI only, the UE may perform block 682; if the normal PUSCH is at least for data or HARQ-ACK, the UE may perform block 684.

[0130] In some implementations (example alternative 1-4) not shown on FIG. 6, the UE may determine that the overlap is an error case or may not expect this collision to occur. For example, the NW entity may refrain from configuration or scheduling that would result in the collision and when the collision is detected (block 660) , the UE may treat it as an error. One example error may be when the normal PUSCH is a DG-PUSCH because the NW entity might  control scheduling of the DG-PUSCH to prevent the collision. For the example alternative 1-4, the UE may perform error recovery procedures based on the error. When the normal PUSCH is a CG-PUSCH, the NW entity may be unable to prevent the collision and / or the UE may perform one of the example alternatives 1-1, 1-2, or 1-3.

[0131] In some implementations, if the normal PUSCH 672 is scheduled for a RACH message (such as a Msg3 / A PUSCH) , the UE may apply a different rule. If transmission of the second UL channel and that of a Msg3 / A PUSCH would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or if the transmission of the second UL channel and that of the Msg3 / A PUSCH would be transmitted on the same carrier or serving cell, and the interval between the transmission of the second UL channel and that of the normal PUSCH is less than a preconfigured or UE-reported value, then, the UE may perform one of the following:

[0132] ● the UE may perform one of the example alternatives 1-1, 1-2, 1-3, or 1-4 above by replacing the normal PUSCH with the Msg3 / A PUSCH, or

[0133] ● the UE may perform example alternative 1-2 (block 684) to drop or refrain from transmitting the second UL channel, and / or the UE may refrain (block 699) from multiplexing / transmitting the at least on UEI-BR on the Msg3 / A PUSCH.

[0134] FIG. 7 shows a flow diagram 700 for handling a collision between a CG / DG-PUSCH for UEI transmission 756 and a PUCCH associated with CSI reporting (referred to as a PUCCH (for CSI) 772) . The CG / DG-PUSCH for UEI transmission 756 may be a CG-PUSCH for UEI-BR (the second UL channel) or a DG-PUSCH for UEI-BR (the first UL channel) . In some implementations, the PUCCH (for CSI) 772 may be used by the UE to transmit / report UCI bit (s) with the CSI report only (e.g., with or without L1-RSRP / L1-SINR) . In some implementations, the CSI report to be transmitted on the PUCCH (for CSI) 772 is a NW-triggered or NW-scheduled CSI report.

[0135] At block 760, the UE detects a collision of the CG / DG-PUSCH for UEI transmission 756 and the PUCCH (for CSI) 772. As an example, the UE may detect the collision if transmission of the CG / DG-PUSCH for UEI transmission 756 and that of the PUCCH (for CSI) 772 would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell. As another example, the UE may detect the collision if the transmission of the CG / DG-PUSCH for UEI transmission 756 and that of the PUCCH (for CSI) 772 would be transmitted on the same carrier or serving cell, and the interval between the transmission of the CG / DG-PUSCH for UEI transmission 756 and that of the PUCCH (for CSI) 772 is less than a preconfigured or UE-reported value.

[0136] The UE may perform one of the following alternatives:

[0137] ● Block 782 (example alternative 2-1) : the UE may drop or refrain from transmitting the PUCCH (for CSI) 772

[0138] ● Block 784 (example alternative 2-2) : the UE may drop or refrain from transmitting the CG / DG-PUSCH for UEI transmission 756. Alternatively, for the CG-PUSCH 756 (e.g., a second UL channel) , the UE may determine that the current transmission occasion of the second UL channel is not available for the UEI-BR (e.g., due to overlapping with other UL resource) and may transmit the UEI-BR on the next available transmission occasion of the CG-PUSCH 756.

[0139] ● Block 788 (example alternative 2-3) : the UE may drop or refrain from transmitting one of the PUCCH (for CSI) 772 or the CG / DG-PUSCH for UEI transmission 756, based on CSI or UCI priority of the at least one UEI-BR on the CG / DG-PUSCH for UEI transmission 756 and UCI bits (s) on the PUCCH (for CSI) 772. For example, if CSI or UCI priority of the at least one UEI-BR is higher than UCI bit (s) , the UE may drop or refrain from transmitting the PUCCH (for CSI) 772, or vice versa. The UE may transmit one of the PUCCH (for CSI) 772 or the CG / DG-PUSCH for UEI transmission 756 with the highest CSI or UCI priority.

[0140] ● Block 786 (example alternative 2-4) : the UE may drop or refrain from transmitting both the PUCCH (for CSI) 772 and CG / DG-PUSCH for UEI transmission 756. For such alternative, at block 797, the UE may multiplex or transmit the at least one UEI-BR and UCI bit (s) on a joint PUCCH or PUSCH. In some implementations, the joint PUCCH or PUSCH is configured by the NW entity to support / afford the payload size of UEI-BR and other UCI. In some implementations, if the NW entity does not configure the joint PUCCH or PUSCH, the UE may perform one of alternatives above (e.g., example alternative 2-1, 2-2, or 2-3) .

[0141] ● (not shown) example alternative 2-5: the UE may determine that this is an error case or may not expect this case to occur. Thus, the NW entity may refrain from such configuration or scheduling.

[0142] In some implementations, if the UE drops or refrain from transmitting the PUCCH (for CSI) 772 (based on one of alternatives above) , the UE may multiplex (block 793) or transmit the UCI bit (s) of the PUCCH (for CSI) 772 on the CG / DG-PUSCH for UEI transmission 756, with multiplexing order based on CSI priority of the UCI bit (s) and the at least one UEI-BR. Such behavior may be performed by the UE, if configured by the NW entity and / or reported by UE capability.

[0143] In some implementations, if the UE drops or refrains from transmitting the CG / DG-PUSCH for UEI transmission 756, based on one of alternatives above, the UE may multiplex (block 795) or transmit the at least one UEI-BR on the PUCCH (for CSI) 772, with multiplexing order based on CSI priority of the UCI bit (s) and the at least one UEI-BR. Such behavior may be performed by the UE, if configured by the NW entity and / or reported by UE capability.

[0144] FIG. 8 shows a flow diagram 800 for handling a collision between a CG / DG-PUSCH for UEI transmission 856 and a PUCCH (for SR / LRR) 872. In some implementations, the UE may be configured / scheduled / indicated, by the NW entity, or may determine to transmit the CG / DG-PUSCH for UEI transmission 856 and a PUCCH (for SR / LRR) 872. In some implementations, the UE may transmit the CG / DG-PUSCH for UEI transmission 856 and the second PUCCH channel in the same serving cell. In some implementations, the second PUCCH may be used by the UE to transmit / report UCI bit (s) including at least an SR / LRR or beam failure recovery (BFR) request (BFRQ) .

[0145] In some implementations, the NW entity may configure or indicate whether the PUSCH for UEI transmission 856 is dedicated for UEI-BR, or is available for both UEI-BR and UL data. For example, the NW entity may configure or indicate it by RRC configuration or the DCI to schedule the first UL channel. In some implementations, if the PUSCH for UEI transmission 856 is dedicated for UEI-BR, the UE may (still) trigger or transmit an SR upon that UL resource for PUSCH is required (even the UE is scheduled or configured for a CG / DG-PUSCH for UEI transmission 856) .

[0146] At block 860, the UE detects a collision, such as when transmission of the PUSCH for UEI transmission 856 and that of the PUCCH (for SR / LRR) 872 would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or when the transmission of the PUSCH for UEI transmission 856 and that of the PUCCH (for SR / LRR) 872 would be transmitted on the same carrier or serving cell, and the interval between the transmission of the PUSCH for UEI transmission 856 and that of the PUCCH (for SR / LRR) 872 is less than a preconfigured or UE-reported value.

[0147] The UE may perform one of the following alternatives:

[0148] ● Block 882 (example alternative 3-1) : the UE may drop or refrain from transmitting the PUCCH (for SR / LRR) 872 or the UE may cancel triggering a SR / LRR / BFRQ on the PUCCH (for SR / LRR) 872.

[0149] ● Block 884 (example alternative 3-2) : the UE may drop or refrain from transmitting the PUSCH for UEI transmission 856. Alternatively, for a CG-PUSCH 856, the UE may determine that the current transmission occasion of the CG-PUSCH 856 is not available for the UEI-BR (e.g., due to overlapping with other UL resource) and may transmit the UEI-BR on the next available transmission occasion of the CG-PUSCH 856.

[0150] ● Block 888 (example alternative 3-3) : the UE may drop or refrain from transmitting one of the PUCCH (for SR / LRR) 872 or the PUSCH for UEI transmission 856, based on CSI or UCI priority of the at least one UEI-BR on the PUSCH for UEI transmission 856 and UCI bits (s) on the PUCCH (for SR / LRR) 872. For example, if CSI or UCI priority of the at least one UEI-BR is higher than UCI bit (s) , the UE may drop or refrain from transmitting the PUCCH (for SR / LRR) 872, and vice versa. The UE may transmit one of the PUCCH (for SR / LRR) 872 or the PUSCH for UEI transmission 856, whichever is the highest CSI or UCI priority.

[0151] ● (not shown) example alternative 3-4: the UE may determine that this is an error case or may not expect this case to occur. Thus, the NW entity may refrain from such configuration or scheduling.

[0152] In some implementations, if the UE drops or does not transmit the PUCCH (for SR / LRR) 872 or does not trigger a SR / LRR / BFRQ on the PUCCH (for SR / LRR) 872 (based on one of alternatives above) , the UE may perform one of the following options:

[0153] ● Block 893 (Option A) : the UE may transmit an indication for SR / LRR / BFRQ (if triggered) on the PUSCH for UEI transmission 856. In some implementations, the indication may be one type of (new) UCI. The length of the indication may be one or more (e.g., two) bit (s) . The NW entity and UE may determine the indication is based on a priority index that is pre-defined (e.g., 0 or 1) , or configured by the NW entity, and the UE may perform the UCI multiplexing based on the procedure for UCI multiplexing for HARQ-ACK or UTO-UCI defined in 3GPP TS 38.212 section 6.3.2.

[0154] ● Block 895 (Option B) : the UE may multiplex or scramble the SR / LRR / BFRQ (if triggered) with UL DMRS of the PUSCH for UEI transmission 856. The NW entity may (blindly) detect whether SR / LRR / BFRQ is transmitted / triggered when receiving the PUSCH for UEI transmission 856.

[0155] ● Block 896 (Option C) : the UE may transmit an UL-SCH or BFR MAC CE on the PUSCH for UEI transmission 856, where the SR / LRR / BFRQ is triggered for transmitting the UL-SCH or BFR MAC CE. This may imply that UL-SCH or UL data is allowed to be transmitted on the PUSCH for UEI transmission 856.

[0156] FIG. 9 shows a flow diagram 900 for handling a collision between a CG / DG-PUSCH for a UEI transmission 956 and a PUCCH (for HARQ-ACK) 972. In some implementations, the UE may be configured / scheduled / indicated, by the NW entity, or may determine to transmit the PUSCH for UEI transmission 956 and a PUCCH (for HARQ-ACK) 972. In some implementations, the UE may transmit the PUSCH for UEI transmission 956 and the PUCCH (for HARQ-ACK) 972 channel in the same serving cell. In some implementations, the PUCCH (for HARQ-ACK) 972 may be used by the UE to transmit / report UCI bit (s) including at least HARQ-ACK bit (s) .

[0157] At block 960, the UE detects a collision, such as when transmission of the PUSCH for UEI transmission 956 and that of the PUCCH (for HARQ-ACK) 972 would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or when the transmission of the PUSCH for UEI transmission 956 and that of the PUCCH (for HARQ-ACK) 972 would be transmitted on the same carrier or serving cell, and the interval between the transmission of the PUSCH for UEI transmission 956 and that of the PUCCH (for HARQ-ACK) 972 is less than a preconfigured or UE-reported value.

[0158] The UE may perform one of the following alternatives:

[0159] ● Block 982 (example alternative 3A-1) : the UE may drop or refrain from transmitting the PUCCH (for HARQ-ACK) 972.

[0160] ● Block 984 (example alternative 3A-2) : the UE may drop or refrain from transmitting the PUSCH for UEI transmission 956. Alternatively, for a CG-PUSCH 956, the UE may determine that the current transmission occasion of the CG-PUSCH 956 is not available for the UEI-BR (e.g., due to overlapping with other UL resource) and may transmit the UEI-BR on the next available transmission occasion of the CG-PUSCH 956.

[0161] ● Block 988 (example alternative 3A-3) : the UE may drop or refrain from transmitting one of the PUCCH (for HARQ-ACK) 972 or the PUSCH for UEI transmission 956, based on CSI or UCI priority of the at least one UEI-BR on the PUSCH for UEI transmission 956 and UCI bits (s) on the PUCCH (for HARQ-ACK) 972. For example, if CSI or UCI priority of the at least one UEI-BR is higher than UCI bit (s) , the UE may drop or refrain from transmitting the PUCCH (for HARQ-ACK) 972, and vice versa. The UE may transmit one of the PUCCH (for HARQ-ACK) 972 or the PUSCH for UEI transmission 956 with the highest CSI or UCI priority.

[0162] ● (not shown) example alternative 3A-4: the UE may determine that this is an error case or may not expect this case to occur. Thus, the NW entity may refrain from such configuration or scheduling.

[0163] In some implementations, if the UE drops or does not transmit the PUCCH (for HARQ-ACK) 972, the UE may perform one of the following options:

[0164] ● Block 993 (Option A) : the UE may multiplex or transmit the UCI bit (s) of the PUCCH (for HARQ-ACK) 972 on the PUSCH for UEI transmission 956. In some implementations, the UE may multiplex / transmit the UCI bit (s) by puncturing resource element (s) (RE (s) ) of the PUSCH for UEI transmission 956. This may imply some coded bit(s) of UEI-BR on PUSCH for UEI transmission 956 may be reduced or discarded. In some implementations, the NW entity may configure whether the UE can multiplex / transmit the UCI bit (s) by puncturing RE (s) of the PUSCH for UEI transmission 956. In some implementations, a UE capability may report whether the UE supports multiplexing / transmitting the UCI bit (s) by puncturing RE (s) of the PUSCH for UEI transmission 956.

[0165] ● Block 995 (Option B) : the UE may multiplex or scramble the UCI bit (s) of the PUCCH (for HARQ-ACK) 972 with UL DMRS of the PUSCH for UEI transmission 956. This option may be performed if the length of UCI bit (s) of the PUCCH (for HARQ-ACK) 972 is less than or equal to a number (e.g., 2) . The NW entity may configure whether the UE multiplex / scramble the UCI bit (s) of the PUCCH (for HARQ-ACK) 972 with UL DMRS of the PUSCH for UEI transmission 956. A UE capability may report whether the UE supports multiplexing / scrambling the UCI bit (s) of the PUCCH (for HARQ-ACK) 972 with UL DMRS of the PUSCH for UEI transmission 956.

[0166] FIG. 10 though FIG. 13 address examples in which a first UL transmission for a first UEI transmission (e.g., request signal, DG-PUSCH, notification signal, or CG-PUSCH) overlaps with a second UL transmission for a second UEI transmission (e.g., request signal, DG-PUSCH, notification signal, or CG-PUSCH) . In some implementations, the NW entity may refrain from configuring, to the UE, both the first mode and the second mode of performing UEI-BR in the same serving cell or the same bandwidth part (BWP) . In some implementations, the NW entity may refrain from configuring, to the UE, both the first mode and the second mode of performing UEI-BR in the same set of serving cell (s) , the same PUCCH cell group, the same cell group, the same frequency band, or the same frequency range (e.g., FR1 or FR2) . In some other implementations, the NW entity may configure, to the UE, the first mode of performing UEI-BR in a first serving cell, and the second mode of performing UEI-BR in a second serving cell. In some implementations, the first and the second serving cells may be in different PUCCH cell group, different cell group, different frequency band, or different frequency range.

[0167] FIG. 10 shows a flow diagram 1000 for handling a collision between a first PUCCH for a first UEI transmission of a first mode and a second PUCCH for a second UEI transmission of a second mode. In the example of FIG. 10, the first PUCCH is for a request signal 1052 (for a first mode of a first UEI transmission) and the second PUCCH is for a notification signal 1054 (for a second mode of a second UEI transmission) . In some implementations, the UE may be configured / scheduled / indicated, by the NW entity, or may determine to transmit the request signal 1052 and the notification signal 1054. In some implementations, the UE may transmit the request signal 1052 and the notification signal 1054 in the same serving cell. In some implementations, the UE may transmit the request signal 1052 and the notification signal 1054 in the same serving cell (e.g., the first, the second or another serving cell) , when the first and the second serving cell are in the same PUCCH cell group.

[0168] In some implementations, shown at block 1051 (referred to as example alternative 4-1) : the UE refrains from triggering both the first UEI transmission and the second UEI transmission at the same time. Thus, there is no overlap of the request signal 1052 and the notification signal 1054 and the collision is avoided.

[0169] In some other implementations, if the NW entity configures, to the UE, the first mode of performing UEI-BR in the first serving cell and the second mode of performing UEI-BR in the second serving cell, the UE may transmit only one of the request signal 1052 or the notification signal 1054, when triggering event (s) are detected one or more times in the first serving cell and the second serving cell respectively. This may imply that the UE may only transmit UEI-BR for one serving cell at a time. Alternatively, or additionally, this may imply that the UE may only transmit UEI-BR corresponding to one mode at a time. In some implementations, the UE may transmit only one of the request signal 1052 or the notification signal 1054, if the first serving cell and the second serving cell are in the same PUCCH cell group and triggering event (s) are detected one or more times in the first serving cell and the second serving cell, respectively. In some implementations, the UE may transmit both the request signal 1052 and the notification signal 1054, if the first serving cell and the second serving cell are in different PUCCH cell group and triggering event (s) are detected one or more times in the first serving cell and the second serving cell, respectively. In one example, if the UE transmits only one of the request signal 1052 or the notification signal 1054, the UE may select one of them by its own decision. In another one example, if the UE transmits only one of the request signal 1052 or the notification signal 1054, the UE may select one of them based on configuration / indication from the NW entity. In yet another one example, if the UE  transmits only one of the request signal 1052 or the notification signal 1054, the UE may select one of them based on pre-specified / defined one or rule.

[0170] At block 1060, the UE detects a collision, such as when transmission of the request signal 1052 and that of the notification signal 1054 would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or when the transmission of the request signal 1052 and that of the notification signal 1054 would be transmitted on the same carrier or serving cell, and the interval between the transmission of the request signal 1052 and that of the notification signal 1054 is less than a preconfigured or UE-reported value.

[0171] The UE may perform one of the following alternatives:

[0172] ● Block 1082 (example alternative 4-2) : the UE may drop or refrain from transmitting the request signal 1052.

[0173] ● Block 1084 (example alternative 4-3) : the UE may drop or refrain from transmitting the notification signal 1054.

[0174] ● Block 1088 (example alternative 4-4) : the UE may drop or refrain from transmitting one of the request signal 1052 and the notification signal 1054 based on a rule. In some implementations, the UE may determine which one to transmit based on the number of detected triggering event (s) and / or the number of serving cell (s) with triggering event (s) detected corresponding to the request signal 1052 and those of the notification signal 1054. In some implementations, the UE may determine which one to transmit based on the lowest serving cell index among serving cell (s) with triggering event (s) detected corresponding to the request signal 1052 and that of the notification signal 1054. In some implementations, the UE may determine which one to transmit based on the report configuration ID corresponding to the request signal 1052 and that of the notification signal 1054.

[0175] ● Block 1093 (example alternative 4-5) : the UE may multiplex or transmit both the request signal 1052 and the notification signal 1054 on a joint PUCCH preconfigured by the NW entity. In some implementations, the example alternative 4-5 is only possible if the joint PUCCH is configured; otherwise, the UE may perform one of other alternatives above.

[0176] FIG. 11 shows a flow diagram 1100 for handling a collision between a PUCCH for a request signal 1152 of a first mode of a first UEI transmission and a CG-PUSCH 1156 for a second mode of a second UEI transmission. In some implementations, the UE may be configured / scheduled / indicated, by the NW entity, or may determine to transmit the request  signal 1152 and the CG-PUSCH 1156. In some implementations, the UE may transmit the request signal 1152 and the CG-PUSCH 1156 in the same serving cell. In some implementations, the UE may transmit the request signal 1152 and the CG-PUSCH 1156 in the same serving cell, when the first and the second serving cell are in the same PUCCH cell group.

[0177] In some other implementations (example alternative 5-1) , at block 1151, the UE refrains from triggering both the first UEI transmission and the second UEI transmission at the same time (e.g., UE can only trigger UEI for one CC or one mode at a time) . Thus, the overlap might be avoided. For example, in this alternative, if the NW entity configures, to the UE, the first mode of performing UEI-BR in the first serving cell and the second mode of performing UEI-BR in the second serving cell, the UE may transmit only one of the request signal 1152 or the CG-PUSCH 1156, when triggering event (s) are detected one or more times in the first serving cell and the second serving cell respectively. This may imply that the UE may only transmit UEI-BR for one serving cell at a time. Alternatively, or additionally, this may imply that the UE may only transmit UEI-BR corresponding to one mode at a time. In some implementations, the UE may transmit only one of the request signal 1152 or the CG-PUSCH 1156, if the first serving cell and the second serving cell are in the same PUCCH cell group and triggering event (s) are detected one or more times in the first serving cell and the second serving cell, respectively. In some implementations, the UE may transmit both the request signal 1152 and the CG-PUSCH 1156, if the first serving cell and the second serving cell are in different PUCCH cell group and triggering event (s) are detected one or more times in the first serving cell and the second serving cell, respectively. In one example, if the UE transmits only one of the request signal 1152 or the CG-PUSCH 1156, the UE may select one of them by its own decision. In another one example, if the UE transmits only one of the request signal 1152 or the CG-PUSCH 1156, the UE may select one of them based on configuration / indication from the NW entity. In yet another one example, if the UE transmits only one of the request signal 1152 or the CG-PUSCH 1156, the UE may select one of them based on pre-specified / defined one or rule.

[0178] At block 1160, the UE detects a collision, such as when transmission of the request signal 1152 and that of the CG-PUSCH 1156 would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or when the transmission of the request signal 1152 and that of the CG-PUSCH 1156 would be transmitted on the same carrier or serving cell, and the interval between the transmission of the request signal 1152 and that of the CG-PUSCH 1156 is less than a preconfigured or UE-reported value.

[0179] The UE may perform one of the following alternatives:

[0180] ● Block 1182 (example alternative 5-2) : the UE may drop or refrain from transmitting the request signal 1152.

[0181] ● Block 1184 (example alternative 5-3) : the UE may drop or refrain from transmitting the CG-PUSCH 1156.

[0182] ● Block 1188 (example alternative 5-4) : the UE may drop or refrain from transmitting one of the request signal 1152 and the CG-PUSCH 1156 based on a rule. In some implementations, the UE may determine which one to transmit based on the number of detected triggering event (s) and / or the number of serving cell (s) with triggering event (s) detected corresponding to the request signal 1152 and those of the CG-PUSCH 1156. In some implementations, the UE may determine which one to transmit based on the lowest serving cell index among serving cell (s) with triggering event (s) detected corresponding to the request signal 1152 and that of the CG-PUSCH 1156. In some implementations, the UE may determine which one to transmit based on the report configuration ID corresponding to the request signal 1152 and that of the CG-PUSCH 1156.

[0183] In some implementations, if the UE drops or refrains from transmitting the request signal 1152 (based on one of alternatives above) , the UE may perform one of the following options:

[0184] ● Block 1193 (Option A) : the UE may transmit an indication for the request signal 1152 on the CG-PUSCH 1156. In some implementations, the indication may be one type of (new) UCI. In some implementations, the length of the indication may be one or more (e.g., two) bit (s) .

[0185] ● Block 1195 (Option B) : the UE may multiplex or scramble the request signal 1152 with a UL DMRS of the CG-PUSCH 1156. In some implementations, the NW entity may (blindly) detect whether the request signal 1152 is transmitted / triggered when receiving the CG-PUSCH 1156.

[0186] ● Block 1197 (Option C) : the UE may transmit a MAC CE or MAC PDU for the request signal 1152 on the CG-PUSCH 1156. This may imply that UL-SCH or UL data is allowed to be transmitted on the CG-PUSCH 1156.

[0187] FIG. 12 shows a flow diagram 1200 for handling a collision between a dynamic grant PUSCH (DG-PUSCH 1256) for a first mode of a first UEI transmission and a notification signal 1254 (via a PUCCH) for a second mode of a second UEI transmission. In some implementations, the UE may be configured / scheduled / indicated, by the NW entity, or may determine to transmit the DG-PUSCH 1256 and the notification signal 1254. In some  implementations, the UE may transmit the DG-PUSCH 1256 and the notification signal 1254 in the same serving cell. In some implementations, the UE may transmit the DG-PUSCH 1256 and the notification signal 1254 in the same serving cell, when the first and the second serving cell are in the same PUCCH cell group.

[0188] In some implementations, at block 1251, the UE refrains from triggering both the first UEI transmission and the second UEI transmission at the same time (e.g., UE can only trigger UEI for one CC or one mode at a time) . Thus, the collision is avoided. For example, if the NW entity configures, to the UE, the first mode of performing UEI-BR in the first serving cell and the second mode of performing UEI-BR in the second serving cell, the UE may transmit only one of the DG-PUSCH 1256 and the notification signal 1254, when triggering event (s) are detected one or more times in the first serving cell and the second serving cell respectively. This may imply that the UE may only transmit UEI-BR for one serving cell at a time. Alternatively, or additionally, this may imply that the UE may only transmit UEI-BR corresponding to one mode at a time. In some implementations, the UE may transmit only one of the DG-PUSCH 1256 and the notification signal 1254, if the first serving cell and the second serving cell are in the same PUCCH cell group and triggering event (s) are detected one or more times in the first serving cell and the second serving cell, respectively. In some implementations, the UE may transmit both the DG-PUSCH 1256 and the notification signal 1254, if the first serving cell and the second serving cell are in different PUCCH cell group and triggering event (s) are detected one or more times in the first serving cell and the second serving cell, respectively. In one example, if the UE transmits only one of the DG-PUSCH 1256 and the notification signal 1254, the UE may select one of them by its own decision. In another one example, if the UE transmits only one of the DG-PUSCH 1256 and the notification signal 1254, the UE may select one of them based on configuration / indication from the NW entity. In yet another one example, if the UE transmits only one of the DG-PUSCH 1256 and the notification signal 1254, the UE may select one of them based on pre-specified / defined rule.

[0189] At block 1260, the UE detects a collision, such as when transmission of the DG-PUSCH 1256 and that of the notification signal 1254 would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or when the transmission of the DG-PUSCH 1256 and that of the PUCCH for the notification signal 1254 would be transmitted on the same carrier or serving cell, and the interval between the transmission of the DG-PUSCH 1256 and that of the notification signal 1254 is less than a preconfigured or UE-reported value.

[0190] The UE may perform one of the following alternatives:

[0191] ● Block 1282 (example alternative 6-2) : the UE may drop or refrain from transmitting the DG-PUSCH 1256.

[0192] ● Block 1284 (example alternative 6-3) : the UE may drop or refrain from transmitting the notification signal 1254.

[0193] ● Block 1288 (example alternative 6-4) : the UE may drop or refrain from transmitting one of the DG-PUSCH 1256 and the notification signal 1254 based on a rule. In some implementations, the UE may determine which one to transmit based on the number of detected triggering event (s) and / or the number of serving cell (s) with triggering event (s) detected corresponding to the DG-PUSCH 1256 and those of the notification signal 1254. In some implementations, the UE may determine which one to transmit based on the lowest serving cell index among serving cell (s) with triggering event (s) detected corresponding to the DG-PUSCH 1256 and that of the notification signal 1254. In some implementations, the UE may determine which one to transmit based on the report configuration ID corresponding to the DG-PUSCH 1256 and that of the notification signal 1254.

[0194] In some implementations, if the UE drops or refrains from transmitting the notification signal 1254 (based on one of alternatives above) , the UE may perform one of the following options:

[0195] ● Block 1293 (Option A) : the UE may transmit an indication for the notification signal 1254 on the DG-PUSCH 1256. In some implementations, the indication may be one type of (new) UCI. In some implementations, the length of the indication may be one or two bit(s) .

[0196] ● Block 1295 (Option B) : the UE may multiplex or scramble the notification signal 1254 with UL DMRS of the DG-PUSCH 1256. In some implementations, the NW entity may (blindly) detect whether the notification signal 1254 is transmitted / triggered when receiving the DG-PUSCH 1256.

[0197] ● Block 1297 (Option C) : the UE may transmit a MAC CE or MAC PDU for the notification signal 1254 on the DG-PUSCH 1256. This may imply that UL-SCH or UL data is allowed to be transmitted on the DG-PUSCH 1256.

[0198] In some implementations (example alternative 6-5) , the NW entity can prevent the collision by scheduling PUSCH for UEI-BR (Mode A) to be transmitted on other serving cells. In some implementations, the NW entity may refrain from scheduling the DG-PUSCH 1256 to be transmitted on a serving cell configured with the notification signal 1254 or a PUCCH for conveying the notification signal 1254. In some other implementations, the NW  entity may refrain from scheduling the DG-PUSCH 1256 to be transmitted on a slot or a one or more OFDM symbol (s) configured / scheduled with potential transmission of the notification signal 1254 or a PUCCH for conveying the notification signal 1254.

[0199] FIG. 13 shows a flow diagram 1300 for handling a collision between a DG-PUSCH (referred to as first UL channel 1356A) for a first mode of a first UEI transmission and a CG-PUSCH (referred to as second UL channel 1356B) for a second mode of a second UEI transmission. In some implementations, the UE may be configured / scheduled / indicated, by the NW entity, or may determine to transmit the first UL channel and the second UL channel. In some implementations, the UE may transmit the first UL channel and the second UL channel in the same serving cell. In some implementations, the UE may transmit the first UL channel and the second UL channel in the same serving cell, when the first and the second serving cell are in the same PUCCH cell group.

[0200] At block 1351, the overlap may be avoided by NW entity managing scheduling of resources. For example, the NW entity may refrain from scheduling the first UL channel to be transmitted on a serving cell configured with the second UL channel. In some other implementations, the NW entity may refrain from scheduling the first UL channel to be transmitted on a slot or a multiple of OFDM symbol (s) configured / scheduled with potential transmission of the second UL channel.

[0201] If the NW entity cannot prevent the overlap, a collision may occur. At block 1360, the UE detects the collision such as when transmission of the first UL channel and that of the second UL channel would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or when the transmission of the first UL channel and that of the second UL channel would be transmitted on the same carrier or serving cell, and the interval between the transmission of the first UL channel and that of the second UL channel is less than a preconfigured or UE-reported value.

[0202] The UE may perform one of the following alternatives:

[0203] ● Block 1382 (example alternative 7-1) : the UE may drop or refrain from transmitting the first UL channel (e.g., the DG-PUSCH for the first UEI transmission) . For such an alternative, the UE may transmit (block 1393) the UEI-BR of the first UL channel on the second UL channel. For such an alternative, the NW entity may configure / indicate and / or the UE may report whether the UE transmits the UEI-BR of the first UL channel on the second UL channel.

[0204] ● Block 1384 (example alternative 7-2) : the UE may drop or refrain from transmitting the second UL channel. For such an alternative, the UE may transmit (block 1395) the  UEI-BR of the second UL channel on the first UL channel. In some implementations, the NW entity may configure / indicate and / or the UE may report whether the UE transmits the UEI-BR of the second UL channel on the first UL channel. Alternatively, at block 1397) the UE may determine that the current transmission occasion of the second UL channel is not available for the UEI-BR (e.g., due to overlapping with other UL resources) and may transmit the UEI-BR on the next available transmission occasion of the second UL channel.

[0205] FIG. 14 through FIG. 17 address examples in which a first UL transmission for a UEI transmission (e.g., request signal, notification signal) overlaps with a second UL transmission not for UEI transmission (e.g., PUSCH, PUCCH) . In these examples, the first UL transmission is associated with a PUCCH configured for the UEI transmission.

[0206] FIG. 14 shows a flow diagram 1400 for handling a collision between a PUCCH for a first mode of a UEI transmission and a normal PUSCH 1472. In the example of FIG. 14, the PUCCH is configured for a request signal 1452 of a first mode of a UEI transmission. In some implementations, the normal PUSCH 1472 may be referred to as a PUSCH without UEI-BR multiplexed / piggybacked / scrambled on it. In some implementations, the normal PUSCH 1472 may be referred to as a PUSCH not scheduled for Msg3 / A transmission or retransmission. In some implementations, the normal PUSCH 1472 may be a DG-PUSCH or CG-PUSCH not associated with UEI transmission.

[0207] At block 1471, the UE may multiplex UCI for the request signal on the normal PUSCH 1472. In some implementations, the NW entity may configure, to the UE, a first RRC parameter indicating whether the UE is allowed to multiplex / transmit at least one UEI-BR for the first mode on the normal PUSCH. In some implementations, the NW entity may configure, to the UE, a first RRC parameter indicating whether the UE is allowed to multiplex / transmit at least one UEI-BR for the first mode on the normal PUSCH, if one of the following occurs:

[0208] ● transmission of the request signal and that of the normal PUSCH are overlapped partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or

[0209] ● transmission of the request signal and that of the normal PUSCH are transmitted on the same carrier or serving cell, and the interval between the transmission of the request signal and that of the normal PUSCH is less than a preconfigured or UE-reported value.

[0210] In some implementations, the first RRC parameter may be configured per cell, per cell group, per band or per frequency range. In some implementations, if the NW entity  configures that the UE is allowed to multiplex / transmit at least one UEI-BR for the first mode on a normal PUSCH, and / or the UE determines there is an available normal PUSCH, the UE may drop or not trigger the request signal.

[0211] At block 1460, the UE detects a collision that is not resolved in block 1471, such as when transmission of the request signal 1452 and that of the normal PUSCH 1472 would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or when transmission of the request signal 1452 and that of the normal PUSCH 1472 would be transmitted on the same carrier or serving cell, and the interval between the transmission of the request signal and that of the normal PUSCH is less than a preconfigured or UE-reported value. In some implementations, the collision detection in block 1460 is further based on a determination that the NW entity has not configured the UE to multiplex / transmit at least one UEI-BR for the first mode on the normal PUSCH or that the remaining / available RE (s) of the normal PUSCH are not enough for multiplexing / transmitting the at least one UEI-BR for the first mode.

[0212] The UE may perform one of the following alternatives:

[0213] ● Block 1482 (example alternative 8-1) : the UE may drop or refrain from transmitting the request signal.

[0214] ● Block 1484 (example alternative 8-2) : the UE may drop or refrain from transmitting the normal PUSCH.

[0215] ● Block 1488 (example alternative 8-3) : the UE may drop or refrain from transmitting the request signal if the normal PUSCH carries UCI bit (s) for HARQ-ACK; otherwise, the UE may drop or not transmit the normal PUSCH.

[0216] In some implementations, if the UE drops or refrains from transmitting the request signal (based on one of the alternatives above) , the UE may perform one of the following options:

[0217] ● Block 1493 (Option A) : the UE may transmit an indication for the request signal on the normal PUSCH. In some implementations, the indication may be one type of (new) UCI. In some implementations, the length of the indication may be one or two bit (s) . In some implementations, the indication may be multiplexed or transmitted on the normal PUSCH by puncturing RE (s) for coded bits of UL data. This may imply that some coded bits of UL data may be dropped or discarded. In some implementations, if UCI bit (s) for HARQ-ACK are carried or multiplexed on the normal PUSCH, the indication or the request signal may be encoded jointly with UCI bit (s) for HARQ-ACK. For UCI bits  generation, the indication or the request signal may be put before or after UCI bit (s) for HARQ-ACK.

[0218] ● Block 1495 (Option B) : the UE may multiplex or scramble the request signal with UL DMRS of the normal PUSCH. In some implementations, the NW entity may (blindly) detect whether the request signal is transmitted / triggered when receiving the normal PUSCH.

[0219] ● Block 1497 (Option C) : the UE may transmit a MAC CE or MAC PDU for the request signal on the normal PUSCH. This may imply that UL-SCH or UL data is allowed to be transmitted on the normal PUSCH.

[0220] In some implementations, if transmission of the request signal and that of a Msg3 / A PUSCH would overlap partially or fully in time domain (e.g., overlapped with at least one OFDM symbol) , and are transmitted on the same carrier or serving cell, or if the transmission of the request signal and that of the Msg3 / A PUSCH would be transmitted on the same carrier or serving cell, and the interval between the transmission of the request signal and that of the Msg3 / A PUSCH is less than a preconfigured or UE-reported value, then the UE may perform one of the following:

[0221] ● the UE may perform one of example alternative 8-1, 8-2, or 8-3 above by replacing the normal PUSCH with the Msg3 / A PUSCH, or

[0222] ● the UE may drop or refrain from transmitting the request signal, and / or the UE may refrain from multiplexing / transmitting the request signal on the Msg3 / A PUSCH.

[0223] FIG. 15 shows a flow diagram 1500 for handling a collision between a PUCCH for a second mode of a UEI transmission and a normal PUSCH 1574. FIG. 15 is similar to FIG. 14, except that in FIG. 15, the PUCCH is configured for a notification 1554 (rather than a request signal 1452 as in FIG. 14) . The description of FIG. 15 is omitted for brevity. Blocks 1571, 1560, 1582, 1854, 1588, 1593, 1595, and 1597 have the same features as blocks 1471, 1460, 1482, 1484, 1488, 1493, 1495, and 1497 except that the blocks in FIG. 15 refer to notification signal (rather than request signal) .

[0224] FIG. 16 shows a flow diagram 1600 for handling a collision between a PUCCH (for UEI transmission) 1655 and a normal PUCCH. Following a detection of a collision (at block 1660) of the PUCCH (for UEI transmission) 1655 and the normal PUCCH 1672, the UE may perform one of the following alternatives:

[0225] ● Block 1682 (example alternative 9A-1) : the UE may drop or refrain from transmitting the normal PUCCH.

[0226] ● Block 1684 (example alternative 9A-2) : the UE may drop or refrain from transmitting the request signal or notification signal (PUCCH for UEI transmission) .

[0227] ● Block 1688 (example alternative 9A-3) : the UE may drop or refrain from transmitting one of the normal PUCCH or the request signal (or notification signal) , based on corresponding UCI priority. For example, if UCI priority of the request signal (or notification signal) is higher than UCI bit (s) of the normal PUCCH, the UE may drop or refrain from transmitting the normal PUCCH, or vice versa. In some implementations, the UE may transmit one of the normal PUCCH or the request signal (or notification signal) with the highest UCI priority. In some implementations, the UE may determine UCI priority based on a predefined prioritization order, such as any of the example priority orders described with reference to FIG. 17.

[0228] ● (not shown) example alternative 9A-4: the UE may determine that this is an error case or may not expect this case to occur. Thus, the NW entity may refrain from such configuration or scheduling.

[0229] In some implementations, if the UE drops or does not transmit the normal PUCCH or if the UE drops or does not transmit the request signal (or notification signal) , at block 1693, the UE may multiplex or transmit the UCI bit (s) of the normal PUCCH on the PUCCH carrying the request signal (or notification signal) , if the normal PUCCH is dropped or not transmitted, or vice versa. In some implementations, at block 1695, the UE may multiplex or transmit the UCI bit (s) of the normal PUCCH and the request signal (or notification signal) on a joint PUCCH.

[0230] In some implementations of block 1693 and / or block 1695, the UE may determine the multiplexing order based on UCI priority, such as any of the example priority orders described with reference to FIG. 17. In some implementations, if maximal UCI multiplexing capability of the PUCCH (the transmitted or not dropped one) or the joint PUCCH is achieved, some UCI bit (s) may be (still) dropped.

[0231] FIG. 17 shows example UCI priority order 1701, 1702, 1703, 1704, and 1705. In some implementations, the UE may determine UCI priority of UCI bit (s) or UCI type, based on of a UCI priority order.

[0232] A first example UCI priority order 1701 illustrates an example of priority (high to low) , where a request / notification signal 1755 has a higher priority than HARQ-ACK 1772A. The HARQ-ACK 1772A has a higher priority than an SR / LRR 1772B. The SR / LRR 1772B has a higher priority than CSI 1772C. Although FIG. 17 shows the first example UCI priority  order 1701 with block diagrams, the priority can be described using shorthand notation, such as “request / notification signal > HARQ-ACK > SR / LRR > CSI. ”

[0233] A second example UCI priority order 1702 illustrates an example of priority (high to low) , where the request / notification signal 1755 and the HARQ-ACK 1772A both have the same priority that is higher than an SR / LRR 1772B. The SR / LRR 1772B has a higher priority than CSI 1772C. Although FIG. 17 shows the second example UCI priority order 1702 with block diagrams, the priority can be described using shorthand notation, such as “request / notification signal = HARQ-ACK > SR / LRR > CSI. "In the second example UCI priority order 1702, when the UE performs UCI multiplexing, the request / notification signal and HARQ-ACK bit (s) may be encoded jointly. This may imply that when determining available / remaining UCI multiplexing capability, the request / notification signal and HARQ-ACK bit (s) are considered together.

[0234] A third example UCI priority order 1703 is shown in FIG. 17 using shorthand notation “HARQ-ACK > request / notification signal > SR / LRR > CSI. ” The HARQ-ACK has a higher priority than the request / notification signal and the SR / LRR. The request / notification signal has a higher priority than SR / LRR. The SR / LRR has a higher priority than the CSI.

[0235] A fourth example UCI priority order 1704 is shown in FIG. 17 using shorthand notation “HARQ-ACK > request / notification signal = SR / LRR > CSI. ” In this example, when the UE performs UCI multiplexing, the request / notification signal and SR / LRR may be encoded jointly. This may imply that when determining available / remaining UCI multiplexing capability, the request / notification signal and SR / LRR are considered together.

[0236] A fifth example UCI priority order 1705 is shown in FIG. 17 using shorthand notation “HARQ-ACK > SR / LRR > request / notification signal > CSI. "

[0237] FIG. 18A through FIG. 18C address examples in which there are multiple overlapping UL transmissions. For example, the UE detects a collision arising due to multiple UL transmissions having overlapping UL resources. In the examples of FIG. 18A through FIG. 18C, the multiple UL transmissions include a PUSCH for UEI transmission 1876, a normal PUSCH 1874, and one or more PUCCHs. The PUCCHs can include a PUCCH 1852 for a scheduling request (of a UEI transmission of the first mode) , a PUCCH 1854 for a notification signal (of a UEI transmission of a second mode) , and a normal PUCCH 1872 (such as for HARQ-ACK, CSI, SR / LRR, etc. ) . The combination of various UL resources and UL transmissions in FIG. 18A through FIG. 18C are provided as examples and other combinations of UL resources / transmissions are possible. The collision handling procedures  in FIG. 18A through FIG. 18C show an iterative approach in which the UE can apply the various examples in FIG. 3 through FIG. 17 according to an order. The first step may use a first rule for a first set of candidate UL transmissions to select a UL resource from among the first set. Then a second step may use a second rule to select a UL resource from among a second set of candidate UL transmissions that includes the UL selected in the first step, and so on. The application of the rules depends on the types of UL transmissions considered in each step. The order of the steps and rules may be referred to as a collision handling order. Although described as an iterative process, some of the steps / rules may be combined or consolidated. Alternatively, a new rule may include prioritization of multiple UL resources by a single rule.

[0238] FIG. 18A shows a flow diagram 1800A for handling multiple collisions using a first collision handling order. In FIG. 18A, a first step (shown at block 1881) includes the UE performing the collision handling for the one or multiple PUCCHs. For example, the collision handling in block 1881 may include one or more features of FIG. 3, FIG. 4A, FIG. 5A, FIG. 10, FIG. 16, and / or FIG. 17. The PUCCH selected in block 1881 becomes a candidate UL resource for consideration in the second step.

[0239] In the second step (shown at block 1882) , the UE may perform the collision handling between the normal PUCCH 1872 and a PUCCH selected in the first step. For example, the collision handling in block 1882 may include one or more features of FIG. 3, FIG. 4A, FIG. 5A, FIG. 7, FIG. 8, FIG. 9, FIG. 14, and / or FIG. 15. The UL resource (which may be a PUCCH or the normal PUSCH 1874) selected in block 1882 becomes a candidate UL resource for consideration in the third step.

[0240] In the third step (shown at block 1883) , the UE may perform the collision handling between the PUSCH for UEI transmission 1876 (such as a CG-PUSCH or a DG-PUSCH associated with the UEI transmission) and the UL channel selected in the second step (block 1882) . For example, the collision handling in block 1883 may include one or more features of FIG. 3 through FIG. 17, depending on which UL resource is selected in block 1882.

[0241] FIG. 18B shows a flow diagram 1800B for handling multiple collisions using a second collision handling order. Block 1881 is the same as described with reference to FIG. 18A. In FIG. 18B, the second step (block 1884) includes the UE performing the collision handling between the normal PUSCH 1874 and a PUSCH 1876 (such as a CG-PUSCH or DG-PUSCH) for the UEI transmission. For example, the collision handling in block 1884 may include one or more features of FIG. 3, FIG. 4B, FIG. 5B, FIG. 6, and / or FIG. 13. In a third  step (shown at block 1885) , the UE may perform the collision handling between a PUCCH selected in block 1881 and the UL channel selected in block 1884.

[0242] FIG. 18C shows a flow diagram 1800C for handling multiple collisions using a third collision handling order. FIG. 18C is similar to FIG. 18A with one difference being that in the second step (block 1886) , the UE performs the collision handling between the a PUSCH for UEI transmission 1876 and a PUCCH selected in the first step (block 1881) . In the third step (block 1887) , the UE may perform the collision handling between the normal PUSCH 1874 and a UL channel selected in the second step (block 1886) .

[0243] Although not shown in FIG. 18A through FIG. 18C, it is also possible that the multiple UL resources include a PUSCH for a RACH message (such as a Msg3 / A) . In such instances, the UE may perform one of the procedures of FIG. 18A, 18B, or 18C by replacing the normal PUSCH with the Msg3 / A PUSCH. Alternatively, or additionally, the UE may drop or refrain from transmitting the PUSCH for UEI transmission 1876 and the multiple PUCCHs 1852, 1854 or 1872 such that the RACH message has highest priority. In some implementations, the UE may refrain from multiplexing / transmitting the UEI transmission and / or multiplexing / transmitting UCI (s) from the multiple PUCCHs on the Msg3 / A PUSCH.

[0244] FIG. 19 shows a flow diagram 1900 with example operations for a UE in accordance with aspects of this disclosure. Although the example operations depict a particular sequence of operations, the sequence may be altered without departing from the scope of the present disclosure. For example, some of the operations depicted may be performed in parallel or in a different sequence. At block 1920, the UE receives, from a NW entity, a configuration for a UEI transmission. At block 1960, the UE detects an overlap between a first UL resource for a first UL transmission associated with the UEI transmission and a second UL resource for a second UL transmission of the UE. At block 1980, the UE prioritizes transmission of the first UL transmission or the second UL transmission according to a rule for the overlap. For example, the rule may include any of the example collision handling rules described with reference to FIG. 3 through FIG. 18C, based on the first UL resource, the second UL resource, UCI priority, and / or content associated with either UL resource.

[0245] FIG. 20 shows a flow diagram 2000 with example operations for a NW entity to mitigate collisions in accordance with aspects of this disclosure. At block 2020A, the NW entity may refrain from scheduling DG-PUSCH for UEI transmission that would overlap with a normal PUSCH or PUCCH. At block 2020B, the NW entity may refrain from configuring Mode A (for the first UEI transmission) and Mode B (for the second UEI transmission) on the same CC, the same serving cell, the same cell group, or the same BWP. At block 2020C,  the NW entity may configure Mode A (for the first UEI transmission) in a first CC and / or first serving cell, and may configure Mode B (for the second UEI transmission) in a second CC and / or second serving cell. At block 2020D, the NW entity may transmit signaling to configure user equipment (UE) behavior for uplink (UL) collision handling. At block 2053, the NW entity may refrain from scheduling DG-PUSCH for the first UEI transmission that would overlap with a CG-PUSCH for a second UEI transmission.

[0246] FIG. 21 illustrates an example protocol stack 2100 for communications between a UE 102 and a NW entity 104. In the example protocol stack 2100, a physical (PHY) layer 2102 provides transport channels to a MAC sublayer 2104, which in turn provides logical channels to a radio link control (RLC) sublayer 2106. The RLC sublayer 2106 in turn provides RLC channels to a Packet Data Convergence Protocol (PDCP) sublayer 2108. The PDCP sublayer 2108 in turn can provide data transfer services to a RRC sublayer 2110, an Internet Protocol (IP) layer and / or a Service Data Adaptation Protocol (SDAP) sublayer (not shown in Fig. 21) . The PDCP sublayer 2108 receives packets (e.g., from the RRC sublayer 2110, the SDAP sublayer, or the IP layer, layered directly or indirectly over the PDCP layer 2108) that can be referred to as service data units (SDUs) , and output packets (e.g., to the RLC layer 2106) that can be referred to as protocol data units (PDUs) . Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets. ” In some implementations, the PHY layer 2102, MAC sublayer 2104, RLC sublayer 2106, PDCP sublayer 2108, RRC sublayer 2110 are EUTRA layers or sublayers. In other implementations, the PHY layer 2102, MAC sublayer 2104, RLC sublayer 2106, PDCP sublayer 2108, RRC sublayer 2110 are NR layers or sublayers.

[0247] The RRC sublayer 2110 provides data transfer services to a Non-Access-Stratum (NAS) layer 2112. The NAS layer 2112 includes a mobility management (MM) sublayer and / or a session management (SM) sublayer. In some implementations, the MM sublayer is an evolved packet system (EPS) MM (EMM) sublayer. In other implementations, the MM sublayer is a 5G MM (5GMM) sublayer. In some implementations, the SM sublayer is an EPS SM (ESM) sublayer. In other implementations, the SM sublayer is a 5G SM (5GSM) sublayer.

[0248] On a control plane, the PDCP sublayer 2108 can provide signaling radio bearers (SRBs) to the RRC sublayer 2110 to exchange RRC messages or NAS messages (e.g., MM messages and / or SM messages) , for example. On a user plane, the PDCP sublayer 2108 can provide Data Radio Bearers (DRBs) to support user plane data exchange. User plane data exchanged on the PDCP sublayer 2108 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0249] FIG. 22 shows a block diagram illustrating example components of a NW entity 104 and a UE 102. Note that the hardware configurations depicted represent the processing components and communication components of a NW entity 104. The depicted hardware configurations may omit certain components well-understood to be frequently implemented in such electronic devices, such as displays, peripherals, power supplies, and the like.

[0250] The UE 102 includes antennas 2203A, a radio frequency front end (RF front end 2203B) , and radio-frequency transceivers (e.g., an LTE transceiver 2203D and a 5G NR transceiver 2203C) for communicating with the NW entity 104. The RF front end 2203B includes one or more modems configured for the corresponding RAT (s) employed (for example, 3GPP 5G NR) , one or more analog-to-digital converters (ADCs) , one or more digital-to-analog converters (DACs) , signal processors, and the like. In the example illustrated in FIG. 22, the RF front end 2203B of the UE 102 may couple or connect the 5G NR transceiver 2203C to the antennas 2203A to facilitate various types of wireless communication. The RF front end 2203B operates, in effect, as a physical (PHY) transceiver interface to conduct and process signaling between the one or more processor (s) 2203E and antennas 2203A so as to facilitate various types of wireless communication.

[0251] The antennas 2203A of the UE 102 include an array of multiple antennas that may be tuned to one or more frequency bands associated with a corresponding RAT. The antennas 2203A and the RF front end 2203B are tuned to, and / or be tunable to, one or more frequency bands defined by the 3GPP 5G NR communication standards and implemented by the 5G NR transceiver 2203C. Additionally, the antennas 2203A, the RF front end 2203B, and / or the 5G NR transceiver 2203C can be configured to support beamforming for the transmission and reception of communications with the NW entity 104. By way of example and not limitation, the antennas 2203A and the RF front end 2203B may be implemented for operation in sub-gigahertz bands, sub-6 GHz bands, and / or above 6 GHz bands that are defined by the 3GPP LTE and 5G NR communication standards.

[0252] The UE 102 also includes processor (s) 2203E and computer-readable storage media (CRM 2203F) . The processor (s) 2203E may include, for example, one or more central processing units, graphics processing units (GPUs) , or other application-specific integrated circuits (ASIC) , and the like. To illustrate, the processor (s) 2203E may include an application processor (AP) utilized by the UE 102 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor of the RF front end 2203B. The CRM 2203F may include any suitable memory or storage device such as random-access memory (RAM) , static RAM (SRAM) , dynamic RAM (DRAM) , non-volatile RAM (NVRAM) , read-only memory (ROM) , Flash memory, solid- state drive (SSD) or other mass-storage devices, and the like useable to store one or more sets of executable software instructions and associated data that manipulate the one or more processor (s) 2203E and other components of the UE 102 to perform the various functions described herein and attributed to the UE 102. The sets of executable software instructions include, for example, an operating system (OS) and various drivers (not shown) , and various software applications (not shown) , which are executable by processor (s) 2203E to enable user-plane communication, control-plane signaling, and user interaction with the UE 102.

[0253] The processor (s) 2203E along with other processors of the UE 102 that are used to implement the techniques described herein may be individually or collectively referred to as “a processing system. ” One or more of RF front end 2203B, LTE transceiver 2203D, 5G NR and LTE transceiver 2203D may be individually or collectively referred to as a “communication unit. ”

[0254] Turning to the hardware of the NW entity 104, it is noted that although FIG. 22 illustrates an implementation of the NW entity 104 as a single network node (for example, a 5G NR Node B, or “gNB” ) , the functionality, and thus the hardware components, of the NW entity 104 instead may be distributed across multiple network nodes or devices and may be distributed in a manner to perform the functions described herein. As one example, the functionality of NW entity 104 may be distributed across a radio unit (RU) , distributed unit (DU) , or central unit (CU) .

[0255] The NW entity 104 includes antennas 2207A, a radio frequency front end (RF front end 2207B) , and one or more 5G NR transceiver (s) 2207C for communicating with the UE 102. The RF front end 2207B of the NW entity 104 may couple or connect the 5G NR transceiver (s) 2207C to the antennas 2207A to facilitate various types of wireless communication. Similar to RF front end 2203B, the RF front end 2207B includes one or more modems, one or more ADCs, one or more DACs, and the like. RF front end 2207B receives the one or more RF signals, for example, RF signals from UE 102, and pre-processes the one or more RF signals to generate data from the RF signals that are provided as input to processes and / or applications executing on NW entity 104. This pre-processing may include, for example, power amplification, conversion of band-pass signaling to baseband signaling, initial analog-to-digital conversion, and the like.

[0256] The antennas 2207A of the NW entity 104 may be configured individually and / or as one or more arrays of multiple antennas. The antennas 2207A and the RF front end 2203B may be tuned to, and / or be tunable to, one or more frequency band defined by the 3GPP 5G NR communication standards and implemented by the 5G NR transceiver (s) 2207C.  Additionally, the antennas 2207A, the RF front end 2207B, and the 5G NR transceiver (s) 2207C may be configured to support beamforming, such as Massive-MIMO, for the transmission and reception of communications with the UE 102.

[0257] The NW entity 104 also includes processor (s) 2207D and computer-readable storage media (CRM 2207E) . The processor (s) 2207D may include, for example, one or more central processing units, graphics processing units (GPUs) , or other application-specific integrated circuits (ASIC) , and the like. To illustrate, the processor (s) 2207D may include an application processor (AP) utilized by the NW entity 104 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor of the RF front end 2207B to enable communication with the UE 102. In at least some aspects, the processor (s) 2207D configures the 5G NR transceiver (s) 2207C for communication with the UE 102, TRPs, and radio units via fronthaul interface 2209, as well as communication with a core network. In some aspects, the NW entity 104 includes an inter-network entity interface 2205, such as an Xn and / or X2 interface, which the processor (s) 2207D configures to exchange user-plane and control-plane data with another NW entity, to manage the communication of the NW entity 104 with the UE 102. The NW entity 104 includes a core network interface UE 102 that the processor (s) 2203E configures to exchange user-plane and control-plane data with core network functions and entities.

[0258] The processor (s) 2207D along with other processors of the NW entity 104 that are used to implement the techniques described herein may be individually or collectively referred to as “a processing system. ” One or more of RF front end 2207B, 5G NR transceiver (s) 2207C, fronthaul interface 2209, inter-network entity interface 2205, and core network interface 2210 may be individually or collectively referred to as a “communication unit. ” The NW entity 104 can include a UEI configuration unit 2220 designed to provide a UEI configuration (such as UEI-BR configuration) to the UE 102. The NW entity 104 may include a UL channel unit 2222 designed to configure PUCCH (s) and PUSCH (s) according to aspects of this disclosure.

[0259] The UE 102 includes a UEI transmission unit 2240 designed to prepare a UEI transmission based on one or more triggering events or satisfaction of triggering conditions at the UE 102. The UE 102 also may include a collision handling unit 2260 designed to implement one or more rules for handling a collision according to aspects of this disclosure. For example, the collision handling unit 2260 may detect an overlap between a UL transmission associated with a UEI transmission and another UL transmission. The collision handling unit 2260 may select which UL resource (and which UL transmission) to transmit  based on any of the examples or rules described in this disclosure, including type or content of the UL transmissions, UCI priority, etc.

[0260] FIG. 23 shows a block diagram of an example wireless communication system 2300 showing hardware features and communication interfaces. The depicted hardware configurations may omit certain components well-understood to be frequently implemented in such electronic devices, such as displays, peripherals, power supplies, and the like. The example wireless communication system 2300 includes the same elements as described with reference to FIG. 1, including the UE 102 and the NW entity 104. FIG. 23 also shows a second network entity 2306 and the core network 2311. In some implementations, the UE 102 can support at least a 5G NR (or simply, “NR” ) or E-UTRA air interface to communicate with the NW entity 104. The NW entity 104 connects to the NW entity 104 via an interface (e.g., S1 or NG interface) . The NW entity 104 can connect to other base stations (including the second network entity 2306) via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes. In FIG. 23, the second network entity 2306 operates a second cell 2308B.

[0261] The NW entity 104 is equipped with processing hardware 2304 that can include a receiver 2307B configured to receive data in the uplink direction. The processing hardware 2304 can also include a transmitter 2307A configured to transmit data in the downlink direction. The processing hardware further can one or more general-purpose processor (s) 2307C (e.g., CPUs) and a non-transitory computer-readable memory (CRM 2307D) storing instructions that the one or more general-purpose processors execute. Additionally, or alternatively, the processing hardware 2304 can include special-purpose processing units. The processor 2307C may include, for example, one or more central processing units, graphics processing units (GPUs) , or other application-specific integrated circuits (ASICs) , and the like. CRM 2307D may include any suitable memory or storage device such as random-access memory (RAM) , static RAM (SRAM) , dynamic RAM (DRAM) , non-volatile RAM (NVRAM) , read-only memory (ROM) , or Flash memory usable to store device data of the NW entity 104.

[0262] The UE 102 is equipped with processing hardware 2302 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory 2303D storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 2302 can also include a transmitter 2303A configured to transmit data in the downlink direction. The processing hardware further can include a receiver 2303B configured to receive data in the uplink direction. The processing hardware 2302, in an example implementation, includes a processor 2303C to process data that the UE 102 will transmit in the uplink direction or  process data received by UE 102 in the downlink direction. The processor (s) 2303C may include, for example, one or more central processing units, GPUs, or other ASICs, and the like. To illustrate, the processor (s) 2303C may include an application processor (AP) utilized by the UE 102 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor. The CRM 2303D may include any suitable memory or storage device such as RAM, SRAM, DRAM, NVRAM, ROM, Flash memory, SSD or other mass-storage devices, and the like useable to store one or more sets of executable software instructions and associated data that manipulate the one or more processor (s) 2303C and other components of the processing hardware 2302 to perform the various functions described herein and attributed to the UE 102. The sets of executable software instructions include, for example, an operating system (OS) and various drivers (not shown) , and various software applications (not shown) , which are executable by processor (s) 2303C to enable user-plane communication, control-plane signaling, and user interaction with the UE 102.

[0263] The core network 2311 can be an Evolved Packet Core (EPC) and / or a 5G core (5GC) . Among other components, the EPC can include a Serving Gateway (SGW) , a Mobility Management Entity (MME) , a Home Subscriber Server (HSS) , and a Packet Data Network Gateway (PGW) . The SGW in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME is configured to manage authentication, registration, paging, and other related functions. The PGW provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC includes a User Plane Function (UPF) , a Unified Data Management (UDM) , an Access and Mobility Management Function (AMF) , and / or Session Management Function (SMF) . Generally speaking, the UPF is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF is configured to manage authentication, registration, paging, and other related functions, and the SMF is configured to manage PDU sessions. The HSS and the UDM store and maintain subscription information regarding the UE 102. The core network 2311 can be implemented by one or more processing elements (shown as processing hardware 2310) . The processing hardware 2310 can include a transmitter 2311A, a receiver 2311B, a processor 2311C, and a CRM 2311D, similar to corresponding components described with reference to processing hardware 2302 and 2304.

[0264] The transmitters 2303A, 2307A, and 2311A and receivers 2303B, 2307B, and 2311B are examples of a communication unit. The processors 2303C, 2307C, and 2311C can also be referred to as a processing system. Other examples of a communication unit and a processing  system are possible, including some examples that are commonly used in a wireless communication system. The NW entity 104, UE 102, second network entity 2306, and core network 2311 can include other components not illustrated in FIG. 23.

[0265] FIG. 1 through FIG. 23 and the operations described herein are examples meant to aid in understanding example implementations and should not be used to limit the potential implementations or limit the scope of the claims. some implementations may perform additional operations, fewer operations, operations in parallel or in a different order, and some operations differently.

[0266] Aspects of the subject matter described in this disclosure can be implemented as a computer-readable medium having stored therein instructions which, when executed by a processor, causes the processor to perform any one of the above-mentioned functionalities. Aspects of the subject matter described in this disclosure can be implemented as a system having means for implementing any one of the above-mentioned functionalities. Aspects of the subject matter described in this disclosure can be implemented as an apparatus having one or more processors configured to perform one or more operations from any one of the above-mentioned functionalities.

[0267] The following additional considerations may apply to the foregoing and the following discussions.

[0268] It is noted that throughout this disclosure, the UE may have one or more of the following attributes or behaviors. The following attributes or behaviors of the UE may also imply associated attributes or behaviors of a NW entity.

[0269] ● The UE may be configured with and / or served by the NW entity in a serving cell.

[0270] ● The UE may (be configured to) communicate with the NW entity in the serving cell.

[0271] ● The UE may be configured with one or more serving cells by the NW entity, which may include the serving cell.

[0272] ● The UE may be activated or be indicated, by the NW entity, to activate one or more serving cells, which may include the serving cell.

[0273] ● The UE may be configured and / or indicated, by the NW entity, one or more BWP. The UE may be indicated and / or configured, by the NW entity, a BWP (in the serving cell) .

[0274] ○ In some implementations, the BWP may be activated as an active BWP.

[0275] ○ In some implementations, the BWP may be referred to as an active BWP.

[0276] ○ In some implementations, the BWP may be an active DL BWP.

[0277] ○ In some implementations, the BWP may be an active UL BWP.

[0278] ○ In some implementations, the BWP may be an initial BWP.

[0279] ○ In some implementations, the BWP may be a default BWP.

[0280] ○ In some implementations, the BWP may be a dormant BWP.

[0281] ● The UE may be in one of RRC_CONNECTED state, RRC_INACTIVE state or RRC_IDLE state.

[0282] It is noted that throughout this disclosure, when a procedure or description is related to a serving cell, it may mean the procedure or description is related to an active (DL / UL) BWP in the serving cell.

[0283] It is noted that throughout this disclosure, a NUL may mean or be referred to as a normal uplink, a UL, an uplinkConfig configuration or a non-supplementary uplink.

[0284] It is noted that throughout this disclosure, when / if the NW entity configures / indicates the UE to perform a behavior or procedure, it may be referred to as or replaced with that the NW entity transmits, to the UE, configuration (s)  / indication (s) of indicating the UE to perform the behavior or procedure.

[0285] It is noted that throughout this disclosure, when / if the UE is configured / indicated to perform a behavior or procedure, it may be referred to as or replaced with that the UE receives, from the NW entity, configuration (s)  / indication (s) of indicating the UE to perform the behavior or procedure.

[0286] It is noted that throughout this disclosure, when / if the NW entity configures / indicates the UE an object, it may be referred to as or replaced with that the NW entity transmits, to the UE, configuration (s)  / indication (s) of the object.

[0287] It is noted that throughout this disclosure, when / if the UE is configured / indicated an object, it may be referred to as or replaced with that the UE receives, from the NW entity, configuration (s)  / indication (s) of the object.

[0288] It is noted that, some or all of the following terminology and assumption may be used hereafter.

[0289] ● BS: a network central unit or a network node in NR which is used to control one or multiple TRPs which are associated with one or multiple cells. Communication between BS and TRP (s) is via fronthaul. BS may be referred to as central unit (CU) , eNB, gNB, or NodeB.

[0290] ● TRP: a transmission and reception point provides network coverage and directly communicates with UEs. TRP may be referred to as distributed unit (DU) or network node.

[0291] ● Cell: a cell is composed of one or multiple associated TRPs, i.e., coverage of the cell is composed of coverage of all associated TRP (s) . One cell is controlled by one BS or a NW entity. Cell may be referred to as TRP group (TRPG) .

[0292] ● Serving beam: serving beam for a UE is a beam generated by a network node, e.g., TRP, which is configured to be used to communicate with the UE, e.g., for transmission and / or reception.

[0293] ● Candidate beam: candidate beam for a UE is a candidate of a serving beam. Serving beam may or may not be a candidate beam.

[0294] Generally speaking, description for one of the above figures can apply to another of the above figures. Any event or block described above can be optional. For example, an event or block with dashed lines can be optional. In some implementations, “message” is used and can be replaced by “information element (IE) , ” and vice versa. In some implementations, “IE” is used and can be replaced by “field, ” and vice versa. In some implementations, “subband” can be replaced with “sub-band. ” In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters, ” and vice versa. In some implementations, “some” means “one or more. ” In some implementations, “at least one” means “one or more. ” The “eNB” can be replaced by “base station, ” “gNB, ” “6G base station, ” “evolved gNB, ” or 6G gNB. “MME” can be replaced by AMF or evolved AMF or 6G AMF. “Core network (CN) ” can be replaced by EPC, 5GC or 6GC.

[0295] Unless defined otherwise, technical and scientific terms used herein have the same meaning as is commonly understood by one of ordinary skill in the art to which this specification belongs. The terms “first, ” “second, ” and the like, as used herein do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The use of terms “including, ” “comprising” or “having” and variations thereof herein are meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The terms “connected” and “coupled” are not restricted to physical or mechanical connections or couplings and can include electrical connections or couplings, whether direct or indirect. Furthermore, terms “circuit” and “circuitry” and “control unit” may include either a single component or a plurality of components, which are either active and / or passive and are connected or otherwise coupled together to provide the described function. In addition, the term operationally coupled as used herein includes wired coupling, wireless coupling, electrical coupling, magnetic coupling, radio communication, software based communication, or combinations thereof.

[0296] Some or all of the foregoing or the following implementations can be jointly combined or formed to be a new or another one implementation. The foregoing or the following techniques can be used to solve at least (but not limited to) the issue (s) or scenario (s) mentioned in this disclosure. Any two or more than two of the foregoing or the following paragraphs, (sub) -bullets, points, actions, or claims described in each  method / technique / implementation may be combined logically, reasonably, and properly to form a specific method. Any sentence, paragraph, (sub) -bullet, point, action, or claim described in each of the foregoing or the following technique (s)  / implementation (s)  / concept (s) may be implemented independently and separately to form a specific method. Dependency, such as “based on, ” “more specifically, ” “where” or etc., in technique (s)  / implementation (s)  / concept (s) mentioned in this disclosure is just one possible implementation which would not restrict the specific method.

[0297] As used herein, the terms “user device” , “user equipment” (for example, UE 102) , “wireless communication device” , “mobile communication device” , “communication device” , or “mobile device” refer to any one or all of cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, Internet-of-Things (IoT) devices, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, display sub-systems, driver assistance systems, vehicle controllers, vehicle system controllers, vehicle communication system, infotainment systems, vehicle telematics systems or subsystems, vehicle display systems or subsystems, vehicle data controllers, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media-streaming dongles or another personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, broadband routers or other types of routers, and similar electronic devices which include a programmable processor and memory and circuitry configured to perform operations as described herein. Further, the user device, in some implementations, may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS) . Still further, the user device can operate as an internet-of-things (IoT) device or a mobile-internet device (MID) . Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0298] Certain techniques are described in this disclosure as including logic or a number of components or modules. Modules can be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) , a digital signal processor (DSP) , etc. ) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose  processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0299] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

[0300] As used herein, the terms “component” and “module” are intended to be broadly construed as hardware, firmware, or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, or a combination of hardware and software. As used herein, the phrase “based on” is intended to be broadly construed to mean “based at least in part on. ”

[0301] As used herein, a phrase referring to a list of items separated by “or” refers to any combination of those items, including single members. For example, “a, b, or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0302] In this disclosure, an expression of “X / Y” may include meaning of any of the following: “X or Y” or “X and Y” or “X and / or Y. " An expression of “ (A) B” or “B (A) ” may include concept of “only B. ” An expression of “ (A) B” or “B (A) ” may include the concept of “A+B” or “B+A. ”

[0303] In this disclosure, the term "can" indicates a capability, or alternatively indicates a possible implementation option. The term "may" indicates a permission or a possible implementation option.

[0304] Some aspects are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.

[0305] The various illustrative components, logic, logical blocks, modules, circuits, operations and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, or combinations of hardware, firmware or software, including the structures disclosed in this specification and the structural equivalents thereof. The interchangeability of hardware, firmware and software has been described generally, in terms of functionality, and illustrated  in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware, firmware or software depends upon the particular application and design constraints imposed on the overall system.

[0306] As described above, some aspects of the subject matter described in this specification can be implemented as software. For example, various functions of components disclosed herein, or various blocks or steps of a method, operation, process or algorithm disclosed herein can be implemented as one or more modules of one or more computer programs. Such computer programs can include non-transitory processor-executable or computer-executable instructions encoded on one or more tangible processor-readable or computer-readable storage media for execution by, or to control the operation of, a data processing apparatus including the components of the devices described herein. By way of example, and not limitation, such storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store program code in the form of instructions or data structures. Combinations of the above should also be included within the scope of storage media.

[0307] Various modifications to the implementations described in this disclosure may be readily apparent to persons having ordinary skill in the art, and the generic principles defined herein may be applied to other implementations without departing from the scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shown herein but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

[0308] Additionally, various features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. As such, although features may be described above as acting in particular combinations, and even initially claimed as such, one or more features from a claimed combination can, in some implementations, be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0309] The drawings may schematically depict one or more example processes in the form of a flowchart or flow diagram. However, other operations that are not depicted can be incorporated in the example processes that are schematically illustrated. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing may  be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Additionally, other implementations are within the scope of the following claims. In some implementations, the actions recited in the claims can be performed in a different order and still achieve desirable results.

[0310] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the aspects. While the aspects of the disclosure have been described in terms of various examples, any combination of aspects from any of the examples is also within the scope of the disclosure.The examples in this disclosure are provided for pedagogical purposes.

Claims

1.A method for wireless communication by a user equipment (UE) , comprising:receiving, from a network (NW) entity, a configuration (120, 220, 320, 420, 520, 1920) for a UE-initiated (UEI) transmission;detecting (360, 460A, 460B, 560A, 560B, 660, 760, 860, 960, 1060, 1160, 1260, 1360, 1460, 1560, 1660, 1960) an overlap between a first UL resource for a first UL transmission associated with the UEI transmission and a second UL resource for a second UL transmission (170, 270) of the UE; andprioritizing (180, 380, 480A, 480B, 580A, 580B, 660, 760, 860, 960, 1060, 1160, 1260, 1360, 1460, 1560, 1660, 1980) transmission of the first UL transmission or the second UL transmission according to a rule for the overlap.2.The method of claim 1, further comprising:preparing (340, 440, 540) to transmit the first UL transmission (150, 250) based on one or more triggering events (330, 430, 530) , the first UL transmission including at least one of a request signal (252) for requesting an UL resource for the UEI transmission, a notification signal (254) indicating usage of a pre-configured UL resource for the UEI transmission, or the UEI transmission (256A, 256B) .3.The method of claim 1, further comprising, when the first UL transmission is prioritized over the second UL transmission:refraining (682, 782, 882, 982, 1084, 1184, 1284, 1384, 1484, 1584, 1684) from transmitting the second UL transmission; andtransmitting the first UL transmission including at least one of a request signal (252) for requesting an UL resource for the UEI transmission, a notification signal (254) indicating usage of a pre-configured UL resource for the UEI transmission, or the UEI transmission (256A, 256B) .4.The method of claim 1, further comprising, when the second UL transmission is prioritized over the first UL transmission:refraining (684, 784, 884, 984, 1082, 1182, 1282, 1382, 1482, 1582, 1682) from transmitting the first UL transmission including at least one of a request signal (252) for requesting an UL resource for the UEI transmission, a notification signal (254) indicating usage of a pre-configured UL resource for the UEI transmission, or the UEI transmission (256A, 256B) ; andtransmitting the second UL transmission.5.The method of claim 1, further comprising:transmitting (797, 1093) both of the first UL transmission and the second UL transmission.6.The method of any one of claims 3 to 5, further comprising:multiplexing (693, 793, 893, 895, 993, 995, 1193, 1195, 1293, 1295, 1395, 1693) or scrambling at least a portion of the second UL transmission on the first UL resource; ormultiplexing (695, 795, 1393, 1493, 1495, 1593, 1595, 1693) or scrambling at least a portion of the first UL transmission on the second UL resource.7.The method of any one of claims 3 to 6, further comprising:transmitting the first UL transmission via a medium access control (MAC) control element (MAC-CE) or MAC protocol data unit (MAC-PDU) based on the refraining from transmitting the first UL resource.8.The method of any one of claims 3 to 6, further comprising:refraining (699) from multiplexing the UEI transmission on the second UL resource when the second UL resource includes a physical uplink shared channel (PUSCH) scheduled for a random access channel (RACH) message.9.The method of any one of claims 1 to 8, wherein the prioritizing transmission of the first UL transmission or the second UL transmission includes:selecting a selected one of the first UL resource or the second UL resource based on at least one of:a content of the second UL transmission, wherein the content includes a channel state information (CSI) report, UL data, a scheduling request (SR) , a link recovery request (LRR) , or a hybrid automatic repeat request acknowledgement (HARQ-ACK) ;an uplink control information (UCI) priority of the first UL transmission compared to a UCI priority of the second UL transmission;a payload size of the first UL resource compared to a payload size of the second UL resource; orprioritization rules obtained from the NW entity.10.The method of claim 9, wherein the prioritizing transmission of the first UL transmission or the second UL transmission includes at least one of:prioritizing the request signal or the notification signal over the HARQ-ACK, the SR or LRR (SR / LRR) , and the CSI report;prioritizing the request signal, the notification signal, and the HARQ-ACK at a same prioritization;prioritizing the HARQ-ACK over the request signal, the notification signal, the SR / LRR, and the CSI report;prioritizing the request signal or the notification signal at a same prioritization as the SR / LRR; orprioritizing the HARQ-ACK and the SR / LRR over the request signal or the notification signal.11.The method of any one of claims 1 to 10, wherein the second UL resource includes at least one of:a normal physical uplink shared channel (PUSCH) not used for UEI transmissions;a normal physical uplink control channel (PUCCH) not used for UEI transmissions;a PUSCH configured for an other UEI transmission; ora PUCCH for control signaling of the other UEI transmission.12.The method of any one of claims 1 to 11, wherein the rule is based on:whether the first UL resource includes:a physical uplink control channel (PUCCH) for a first UEI transmission, a first carrier, a first serving cell, or a first cell group,a dynamic grant physical uplink shared channel (DG-PUSCH) for a first mode of the first UEI transmission, the first carrier, the first serving cell, or the first cell group, ora configured grant PUSCH (CG-PUSCH) for a second mode of the first UEI transmission, the first carrier, the first serving cell, or the first cell group; andwhether the second UL resource includes:a PUCCH configured for a CSI report,a PUCCH configured for an SR or LRR,a PUCCH configured for HARQ-ACK,a normal PUCCH,a normal PUSCH for UL data,a PUCCH for a second UEI transmission, second carrier, a second serving cell, or a second cell group,a DG-PUSCH or CG-PUSCH for the second UEI transmission, the second carrier, the second serving cell, or the second cell group.13.The method of any one of claims 1 to 12, further comprising:determining an error condition based on the overlap when the first UL resource is a DG-PUSCH and the second UL resource includes a normal PUSCH or a normal PUCCH.14.The method of any one of claims 1 to 13, wherein the UEI transmission includes a UEI beam report (UEI-BR) .15.A method for wireless communication by a network (NW) entity, comprising:transmitting, to a user equipment (UE) , a configuration (120, 220, 320, 420, 520, 1920) for a UE-initiated (UEI) transmission such that the NW entity expects to receive, from the UE, a first UL transmission (150, 250) associated with the UEI transmission via a first UL resource;scheduling a second UL resource for a second UL transmission (170, 270) of the UE; andreceiving one of the first UL transmission or the second UL transmission according to a rule for an overlap between the first UL resource and the second UL resource.16.The method of claim 15, wherein the first UL transmission includes at least one of a request signal (252) for requesting a UL resource for the UEI transmission, a notification signal (254) indicating usage of a pre-configured UL resource for the UEI transmission, or the UEI transmission (256A, 256B) .17.The method of claim 15, further comprising:configuring a first mode for a first UEI transmission in a first carrier, a first serving cell, or a first cell group; andconfiguring a second mode for a second UEI transmission in a second carrier, second serving cell, or a second cell group.18.The method of claim 15, further comprising at least one of:refraining from scheduling a dynamic grant physical uplink shared channel (DG-PUSCH) for a UEI transmission that would overlap with a normal PUSCH or normal physical uplink control channel (PUCCH) ;refraining from configuring both of a first mode for a first UEI transmission and a second mode for a second UEI transmission on the same carrier, same serving cell, same cell group, or same bandwidth part; orrefraining from scheduling a DG-PUSCH for the first UEI transmission that would overlap with a configured grant PUSCH (CG-PUSCH) for the second UEI transmission.19.An apparatus, comprising:a communication unit; anda processing system configured to control the communication unit to implement a method according to any one of claims 1 to 18.

Images