Method and apparatus for uplink transmission

Abstract

The present application provides a method of uplink transmission performed by a UE. The method comprises: receiving a plurality of configured grant configurations allocating a set of PUSCH durations in a BWP, wherein at least two or more PUSCH durations in the set overlap in time domain; identifying a set of one or more PUSCH durations available for repeated transmission from the set of PUSCH durations; selecting a particular PUSCH duration as a priority PUSCH duration from the identified set of one or more PUSCH durations; and performing uplink transmission on the priority PUSCH duration.

Description

[0001] This application is a divisional application of the invention patent with application number 201980074380.4, application date November 8, 2019, and invention title "Method and apparatus for uplink transmission".

[0002] Cross-reference to related applications

[0003] The parent application claims the benefit and priority of Provisional U.S. Patent Application Serial No. 62 / 758,038, filed November 9, 2018, entitled “Handling of Multiple Active Configured Grant Configurations,” Agent’s File No. US75448 (hereinafter referred to as “US75448 Application”). The disclosure of US75448 Application is incorporated herein by reference in its entirety. Technical Field

[0004] This case generally relates to wireless communications, and more specifically, to configuring licensed uplink transmissions in next-generation wireless communication networks. Background Technology

[0005] Various efforts have been made to improve various aspects of wireless communication, such as data rate, latency, reliability, and mobility, for next-generation (e.g., 5G New Radio (NR)) wireless communication systems. In NR, uplink transmissions for user equipment (UE) can be based on dynamic granting or configuration granting. Configuration granting (also known as CG) can have at least two different types, including configuration granting type 1 (e.g., provided by Radio Resource Control (RRC) signaling) and configuration granting type 2 (e.g., provided by the Physical Downlink Control Channel (PDCCH)). In one scenario, multiple CG configurations can be activated simultaneously in different serving cells. For the same serving cell, the Media Access Control (MAC) entity can be configured with either CG type 1 or CG type 2. In another scenario, multiple CG configurations can be activated simultaneously for a bandwidth portion (BWP) of a serving cell. The industry needs an improved and efficient mechanism for UEs to handle multiple active CG configurations (e.g., for uplink transmissions). Invention Overview

[0006] This case relates to a transmission method for uplink performed by a UE in a next-generation wireless communication network.

[0007] According to one aspect of this case, a UE is provided. The UE includes: one or more non-transitory computer-readable media having computer-executable instructions contained thereon, and at least one processor coupled to the one or more non-transitory computer-readable media. The at least one processor is configured to execute the computer-executable instructions to: receive a first configuration grant configuration, wherein the first configuration grant configuration allocates a first Physical Uplink Shared Channel (PUSCH) duration; receive a second configuration grant configuration, wherein the second configuration grant configuration allocates a second PUSCH duration, wherein the second PUSCH duration overlaps with the first PUSCH duration in the time domain, and the first configuration grant configuration and the second configuration grant configuration are associated with the same serving cell; obtain a first Hybrid Automatic Repeat Request (HARQ) procedure ID for the first PUSCH duration; obtain a second HARQ procedure ID for the second PUSCH duration; after obtaining the first HARQ procedure ID, determine whether a first configuration grant timer associated with the first HARQ procedure ID is running; and select one of the first PUSCH duration and the second PUSCH duration for uplink transmission based on whether the first configuration grant timer is running and whether the second configuration grant timer is running.

[0008] According to another aspect of this case, a transmission method for uplink performed by a UE is provided. The method includes: receiving a first configuration grant configuration, wherein the first configuration grant configuration allocates a first PUSCH duration; receiving a second configuration grant configuration, wherein the second configuration grant configuration allocates a second PUSCH duration, wherein the second PUSCH duration overlaps with the first PUSCH duration in the time domain, and the first configuration grant configuration and the second configuration grant configuration are associated with the same serving cell; obtaining a first HARQ procedure ID for the first PUSCH duration; obtaining a second HARQ procedure ID for the second PUSCH duration; after obtaining the first HARQ procedure ID, determining whether a first configuration grant timer associated with the first HARQ procedure ID is running; after obtaining the second HARQ procedure ID, determining whether a second configuration grant timer associated with the second HARQ procedure ID is running; and selecting one of the first PUSCH duration and the second PUSCH duration for uplink transmission based on whether the first configuration grant timer is running and whether the second configuration grant timer is running. Attached Figure Description

[0009] The various aspects of this exemplary disclosure can be best understood in conjunction with the accompanying drawings and the following detailed description. The features are not drawn to scale. The dimensions of the features may be arbitrarily enlarged or reduced for clarity of explanation.

[0010] Figure 1 This is a block diagram of the MAC entity of an exemplary UE shown according to an exemplary embodiment of this application.

[0011] Figure 2 This is a flowchart illustrating an exemplary method performed by the MAC entity of a UE to determine the availability of CG PUSCH duration, according to an example implementation of this application.

[0012] Figure 3 This is a flowchart illustrating an exemplary uplink transmission method performed by a UE according to an example implementation of this application.

[0013] Figure 4 This is a diagram illustrating an exemplary resource selection performed by the MAC entity of the UE according to an example implementation of this application.

[0014] Figure 5 This is a diagram illustrating another exemplary resource selection performed by the MAC entity of the UE according to an example implementation of this application.

[0015] Figure 6 This is a diagram illustrating an exemplary method performed by the MAC entity of a UE to handle resource overlap and HARQ ID conflicts, according to an example implementation of this application.

[0016] Figure 7 This is a diagram illustrating another exemplary method for handling resource overlap and HARQ ID conflicts performed by the MAC entity of the UE, according to an example implementation of this application.

[0017] Figure 8 This is a diagram illustrating an exemplary method for handling HARQ ID conflicts performed by the MAC entity of a UE, according to an example implementation of this application.

[0018] Figure 9 This is a diagram illustrating another exemplary method for handling HARQ ID conflicts performed by the MAC entity of the UE, according to an example implementation of this application.

[0019] Figure 10 This is a block diagram of a wireless communication node according to an example embodiment of this application. Detailed Implementation

[0020] The following description contains specific information relating to the exemplary embodiments described herein. The accompanying drawings and detailed descriptions are only illustrative of exemplary embodiments. However, this application is not limited to these exemplary embodiments. Other variations and embodiments of this application will occur to those skilled in the art. Unless otherwise stated, the same or corresponding elements in the drawings may be indicated by the same or corresponding reference numerals. Furthermore, the drawings and illustrations in this application are generally not drawn to scale and are not intended to correspond to actual relative dimensions.

[0021] For the purposes of consistency and ease of understanding, the same features are labeled with the same numbers in the exemplary figures (although not shown in some examples). However, features in different embodiments may differ in other respects, and therefore should not be narrowly limited to the features shown in the figures.

[0022] The specification uses the phrases "in one embodiment" or "in some embodiments," which may each refer to one or more of the same or different embodiments. The term "coupled" is defined as a connection, either directly or indirectly through intermediate components, and is not necessarily limited to a physical connection. When the term "comprising" is used, it means "including but not limited to"; it specifically indicates an open-ended inclusion or membership member in the described combination, group, series, and equivalent. The expression "at least one of A, B, and C" or "at least one of the following: A, B, and C" means "only A, or only B, or only C, or any combination of A, B, and C."

[0023] Furthermore, for purposes of explanation and non-restriction, specific details such as functional entities, technologies, protocols, and standards are elaborated to provide an understanding of the described technologies. In other examples, detailed descriptions of well-known methods, technologies, systems, architectures, etc., are omitted to avoid unnecessary ambiguity.

[0024] Those skilled in the art will readily recognize that any network functions or algorithms described herein can be implemented by hardware, software, or a combination of software and hardware. The described functions may correspond to modules, which can be software, hardware, firmware, or any combination thereof. Software implementations may include computer-executable instructions stored on a computer-readable medium such as memory or other types of storage devices. For example, one or more microprocessors or general-purpose computers with communication processing capabilities may be programmed using the corresponding executable instructions to perform the described network functions or algorithms. These microprocessors or general-purpose computers may be formed using application-specific integrated circuits (ASICs), programmable logic arrays, and / or using one or more digital signal processors (DSPs). While several exemplary embodiments described herein are directed to software installed and executed on computer hardware, alternative exemplary embodiments implemented as firmware or hardware or a combination of hardware and software are also within the scope of this specification.

[0025] Computer-readable media include, but are not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, optical disc read-only memory (CD-ROM), cassette tape, magnetic tape, disk storage, or any other equivalent medium capable of storing computer-readable instructions.

[0026] Wireless communication network architectures (e.g., Long Term Evolution (LTE) systems, LTE-Advanced (LTE-A) systems, LTE-Advanced Pro systems, or 5G NR radio access networks) typically include at least one base station, at least one UE, and one or more optional network elements providing connectivity to the network. The UE communicates with the network (e.g., core network (CN), evolved packet core (EPC) network, evolved universal terrestrial radio access network (E-UTRAN), 5G core (5GC), or the Internet) through a RAN established by one or more base stations.

[0027] It should be noted that in this application, the UE may include, but is not limited to, a mobile station, a mobile terminal or device, or a user communication wireless terminal. For example, the UE may be a portable wireless device, including but not limited to mobile phones, tablets, wearable devices, sensors, vehicles, or personal digital assistants (PDAs) with wireless communication capabilities. The UE is configured to receive signals from one or more cells in the radio access network and transmit signals to one or more cells in the radio access network via an air interface.

[0028] The base station can be configured to provide communication services based on at least one of the following radio access technologies (RATs): Global Microwave Access Interoperability (WiMAX), Global System for Mobile Communications (GSM, commonly referred to as 2G), Radio Access Network based on Enhanced Data Rate GSM Evolution Technology (EDGE) (GERAN), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System based on Basic Wideband Code Division Multiple Access (W-CDMA) (UMTS, commonly referred to as 3G), High-Speed ​​Packet Access (HSPA), LTE, LTE-A, eLTE (evolved LTE, such as LTE connected to 5GC), NR (commonly referred to as 5G), and / or LTE-APro. However, the scope of this application should not be limited to the protocols mentioned above.

[0029] Base stations may include, but are not limited to: Node Bs (NBs) in UMTS, such as evolved Node Bs (eNBs) in LTE or LTE-A, Radio Network Controllers (RNCs) in UMTS, Base Station Controllers (BSCs) in GSM / GERAN, NG-eNBs in E-UTRA base stations connected to 5GC, Next Generation Node Bs (gNBs) in 5G-RAN, and any other devices capable of controlling wireless communication and managing radio resources within the cell. A base station can serve one or more UEs through a radio interface.

[0030] A base station is operable to provide wireless coverage to a specific geographic area using multiple cells forming a radio access network. The base station supports the operation of these cells. Each cell is operable to provide service to at least one UE within its wireless coverage area. More specifically, each cell (often referred to as the serving cell) provides service to one or more UEs within its wireless coverage area (e.g., each cell schedules downlink and optional uplink resources to at least one UE within its wireless coverage area for downlink and optional uplink packet transmissions). The base station is capable of communicating with one or more UEs in a wireless communication system through multiple cells. Cells may allocate sidelink (SL) resources to support ProSe or Vehicle-to-Everything (V2X) services. Each cell may have coverage areas overlapping with other cells.

[0031] As mentioned above, the frame structure for NR should support flexible configuration to adapt to various next-generation (e.g., 5G) communication requirements, such as enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), ultra-reliable communications, and low-latency communications (URLLC), while meeting high reliability, high data rate, and low latency requirements. Orthogonal frequency division multiplexing (OFDM) technology, as agreed in 3GPP, can be used as a benchmark for NR waveforms. A scalable set of OFDM parameters, such as adaptive subcarrier spacing, channel bandwidth, and cyclic prefix (CP), can also be used. Furthermore, two coding schemes are considered for NR: (1) low-density parity-check (LDPC) codes and (2) polar codes. Coding scheme adaptation can be configured based on channel conditions and / or the service application.

[0032] In addition, the following is also considered: within the transmission time interval TX of a single NR frame, at least downlink (DL) transmission data, a guard period, and uplink (UL) transmission data should be included, wherein, for example, based on the network dynamics of NR, the individual portions of the DL transmission data, guard period, and UL transmission data should also be configurable. Furthermore, sidelink resources can be provided in the NR frame to support ProSe or V2X services.

[0033] Furthermore, the terms "system" and "network" are used interchangeably in this document. The term "and / or" is used only to describe the relationships between related objects and indicates that three relationships can exist. For example, A and / or B might mean: A exists alone, A and B exist simultaneously, and B exists alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0034] Figure 1 This is a block diagram of the MAC entity of an exemplary UE shown according to an exemplary embodiment of this application.

[0035] MAC entity 100 may include Msg3 cache 110, multiplexing and assembling (M&A) entity 120, and

[0036] HARQ entity 130. In one embodiment, when MAC entity 100 receives a UL authorization, HARQ entity 130 can retrieve a MAC protocol data unit (PDU) from Msg3 cache 110 or M&A entity 120. HARQ entity 130 can then transmit the retrieved MAC PDU to a HARQ program. In one embodiment, there can be several HARQ programs executed by HARQ entity 130, each HARQ program having a HARQ program ID (e.g., HARQ program #0, HARQ program #1, HARQ program #2, etc.). Each program ID can be associated with a HARQ cache. As an example, such as Figure 1 As shown, HARQ procedure #0140 is associated with HARQ cache #0150, and HARQ procedure #1141 is associated with HARQ cache #1151.

[0037] In NR, multiple CG configurations can be activated simultaneously within a bandwidth portion (BWP) of the serving cell. The HARQ procedure ID (also known as the HARQ ID) for each CG configuration can be handled by the UE's MAC entity. For example, the HARQ ID can be derived by the UE based on a predefined equation along with one or more parameters provided by the base station (e.g., gNB). In one implementation, the HARQ IDs of multiple active CG configurations can be different, thus eliminating HARQ ID conflicts. In another implementation, the HARQ IDs of multiple active CG configurations can be the same, requiring subsequent actions to resolve HARQ ID conflicts between the authorized active configurations.

[0038] The base station can configure the CG timer via RRC signaling through the configuredGrantTimer information element (IE) within the CG configuration (e.g., a ConfiguredGrantConfig IE). The configuredGrantTimer IE can indicate a multiple of the UL transmission period as an initial value for the CG timer. The UL transmission period can be configured via a periodicity IE in the CG configuration. In one implementation, multiple CG configurations can be active simultaneously in the same UL BWP, and the base station can optionally configure one configuredGrantTimer in each BWP (e.g., the same CG timer value can be shared for all CG configurations in the same UL BWP). In another implementation, the base station can configure one configuredGrantTimer in each CG configuration (e.g., the CG timer value can be configured in each CG configuration).

[0039] In one implementation, for each serving cell and one or more configured UL grants, if configured and activated, the UE's MAC entity can check whether the PUSCH duration of the configured uplink grant and the PUSCH duration of the UL grant received on the PDCCH for the serving cell overlap in the time domain before determining the HARQ procedure ID associated with the PUSCH duration. The PUSCH duration can refer to the duration the UE uses for an initial transmission (e.g., according to Technical Standard (TS) 38.214, the PUSCH duration can be part of a bundle of configured uplink grants used for the initial transmission. In one implementation, the redundancy version (RV) of the PUSCH duration is zero). Furthermore, the MAC entity can determine whether the configuredGrantTimer corresponding to the HARQ procedure is running. If the configuredGrantTimer corresponding to the HARQ procedure is not running, the PUSCH duration can be considered available for transmitting a new MACPDU. If the PUSCH duration is deemed sufficient to transmit a new MAC PDU, the MAC entity can assume the New Data Indicator (NDI) bit has been switched. The MAC entity can then transmit uplink grant configuration and associated HARQ information to the HARQ entity, and the HARQ entity (e.g., Figure 1 HARQ entity 130 in the code can be obtained from multiplexed and assembly entities (e.g., Figure 1 Obtain the MAC PDU to be transmitted over the duration of the PUSCH from the M&A entity 120.

[0040] Figure 2This is a flowchart illustrating an exemplary method 200 performed by the MAC entity of a UE to determine the availability of the CG PUSCH duration, according to an example implementation of this application. In one implementation, method 200 may be performed each time the UE receives the PUSCH duration of the CG (also referred to as the "CG PUSCH duration"). The CG PUSCH duration may be used for an initial transmission. In action 210, the MAC entity may determine whether the configured authorized PUSCH duration overlaps with the PUSCH duration received on the PDCCH (e.g., dynamic authorization). If there is no overlap, in action 220, the MAC entity may set a HARQ procedure ID (e.g., based on a predefined equation) associated with the configured authorized PUSCH duration. If there is an overlap, in action 250, the MAC entity may ignore the CG PUSCH duration. In action 230, the MAC entity may determine whether the CG timer for the HARQ procedure (which is associated with the HARQ procedure ID derived in action 220) is running. If the CG timer is running, the PUSCH duration cannot be used to transmit a new MAC PDU. In action 250, the MAC entity can ignore the PUSCH duration of the CG. Conversely, if the CG timer is not running, in action 240, the PUSCH duration can be considered usable for transmitting a new MAC PDU. In this case, the MAC entity can assume the NDI bit has been switched and transmit the configuration UL authorization and HARQ information to the HARQ entity.

[0041] If multiple CG configurations can be configured and activated simultaneously in the same serving cell, there can be more overlap. For example, a PUSCH duration (also referred to as a "PUSCH resource") from one CG configuration can overlap with one or more PUSCH durations from multiple other CG configurations. The term "PUSCH duration" here can refer to a PUSCH duration available for an initial transmission (e.g., according to TS 38.214, this PUSCH duration may be part of a bundle of configuration uplink grants used for an initial transmission. In one implementation, the RV of the PUSCH duration is zero) or a PUSCH duration available for a repeated transmission (e.g., according to TS 38.214, this PUSCH duration is part of a bundle of configuration uplink grants that may not be used for an initial transmission. In one implementation, the RV of the PUSCH duration is not zero). Furthermore, the term "overlap" can refer to overlap between multiple PUSCH durations in the time domain. In one implementation, for each CG PUSCH duration, the MAC entity can check whether it overlaps with one or more PUSCH durations from other CG configurations.

[0042] There can be several cases of overlapping PUSCH durations, including Case 1: overlap between multiple PUSCH durations available for initial transmission from more than one CG configuration; Case 2: overlap between multiple PUSCH durations available for repeated transmission from multiple CG configurations; Case 3: overlap between multiple PUSCH durations from multiple CG configurations, wherein at least one PUSCH duration is available for an initial transmission and at least one PUSCH duration is available for a repeated transmission.

[0043] Figure 3 This is a flowchart illustrating an exemplary uplink transmission method 300 performed by a UE (e.g., the UE's MAC entity) according to an example implementation of this application. In action 302, the UE may receive a first CG configuration, wherein the first CG configuration allocates a first PUSCH duration. In action 304, the UE may receive a second CG configuration, wherein the second CG configuration allocates a second PUSCH duration. The second PUSCH duration and the first PUSCH duration overlap in the time domain. In one implementation, the first CG configuration and the second CG configuration may be associated with the same serving cell.

[0044] In action 306, the UE can obtain a first HARQ procedure ID for the first PUSCH duration. In action 308, the UE can obtain a second HARQ procedure ID for the second PUSCH duration. In one implementation, the UE can derive the corresponding HARQ procedure ID based on a predefined equation along with one or more parameters provided by the base station. In action 310, after obtaining the first HARQ procedure ID, the UE can determine whether a first configuration grant timer associated with the first HARQ procedure ID is running. In action 312, after obtaining the second HARQ procedure ID, the UE can determine whether a second configuration grant timer associated with the second HARQ procedure ID is running. In action 314, based on whether the first configuration grant timer is running and whether the second configuration grant timer is running, one of the first PUSCH duration and the second PUSCH duration is selected for uplink transmission. The expiration time of the first CG timer can be configured in the first CG configuration, and the expiration time of the second CG timer can be configured in the second CG configuration. Several implementations of method 300 are provided below.

[0045] Case 1: Overlap between the durations of multiple PUSCHs available for the initial transmission.

[0046] For a serving cell, after determining that the PUSCH duration configured with uplink grants and the PUSCH duration received on the PDCCH do not overlap, the MAC entity may further check whether the PUSCH duration available for initial transmission from an active CG configuration (e.g., the RV of this PUSCH duration is zero) overlaps with one or more PUSCH durations available for initial transmission from another active CG configuration used for this ULBWP (e.g., the RV of this PUSCH duration is also zero). If there is overlap, the MAC entity can derive the HARQ procedure IDs of all overlapping CG PUSCH durations.

[0047] In one implementation, separate HARQ ID pools can be used for different CG configurations (e.g., the same HARQ ID cannot be obtained from more than one CG configuration activated from the same ULBWP). For each overlapping PUSCH duration available for initial transmission (e.g., the RV of these PUSCH durations is zero), the MAC entity can check whether the CG timer associated with its derived HARQ program ID for the PUSCH duration is not running. If the CG timers associated with the derived HARQ IDs from all overlapping CGPUSCH durations are running, it can be assumed that no PUSCH duration is available for transmission of a new MAC PDU. If only one CG timer associated with a derived HARQ ID is not running, the MAC entity can assume that the corresponding PUSCH duration is available for transmission of a new MAC PDU. In this case, the MAC entity can assume that the NDI bit has been switched and transmit the configuration uplink grant and HARQ information associated with that PUSCH duration to the HARQ entity, which can then obtain the MAC PDU to be transmitted on that PUSCH duration from the multiplexing and assembling entity.

[0048] Figure 4 This is an exemplary resource selection performed by the MAC entity of the UE, as shown in the example implementation of this application. Figure 4In configuration #400, CG configuration #1 allocates PUSCH durations 410 and 411, both of which have HARQ ID #3. CG configuration #2 allocates PUSCH duration 421, which has HARQ ID #6. CG configurations #1 and #2 can be associated with the same serving cell. PUSCH durations 410, 411, and 421 can all be used for initial transmissions (e.g., the RV of these PUSCH durations is zero). PUSCH durations 421 and 411 overlap in the time domain. After determining that the CG timer associated with HARQ ID #3 is running (e.g., at the moment when PUSCH duration 411 overlaps with PUSCH duration 421) and the CG timer associated with HARQ ID #6 is not running, the MAC entity can select PUSCH duration 421 for uplink transmissions. PUSCH duration 421 can be considered usable for transmitting new MAC PDUs. In this case, the MAC entity can assume that the NDI bit has been switched and transmit the configuration uplink grant and HARQ information associated with PUSCH duration 421 to the HARQ entity, and the HARQ entity can obtain the MAC PDU to be transmitted on PUSCH duration 421 from the multiplexing and assembling entity.

[0049] If multiple CG timers associated with the derived HARQ ID are not running, the MAC entity can select one of the overlapping CG PUSCH durations for which the corresponding CG timers are not running. In one implementation, the MAC entity can select the one corresponding to the CG configuration with the highest priority among these overlapping PUSCH durations. The selected PUSCH duration is considered available for transmitting a new MAC PDU. The MAC entity can assume that the NDI bit has been switched and transmits the configuration uplink grant and HARQ information associated with the selected PUSCH duration to the HARQ entity, which can obtain the MAC PDU to be transmitted on the selected PUSCH duration from the multiplexing and assembling entity. In one implementation, when overlapping CG configurations have the same or equal priority, determining which PUSCH duration to select can depend on the UE's implementation. Several implementations of CG configuration priority are provided in Case 4.

[0050] Figure 5 This is another exemplary resource selection performed by the MAC entity of the UE, as shown in the example implementation of this application. Figure 5In configuration #500, CG configuration #1 allocates PUSCH durations 510 and 511, both of which have HARQ ID #3. CG configuration #2 allocates PUSCH duration 521, which has HARQ ID #6. CG configurations #1 and #2 can be associated with the same serving cell. PUSCH durations 510, 511, and 512 can all be used for multiple initial transmissions (e.g., the RV values ​​of these PUSCHs are zero). PUSCH durations 521 and 511 overlap in the time domain. After determining that the CG timer associated with HARQ ID #3 is not running (e.g., at the moment when PUSCH duration 511 overlaps with PUSCH duration 521) and the CG timer associated with HARQ ID #6 is not running, the MAC entity can select one of PUSCH durations 511 and 521 for uplink transmission. In one implementation, the MAC entity may consider which of CG configuration #1 and CG configuration #2 has higher priority, and then select the corresponding PUSCH duration accordingly.

[0051] After prioritization, the selected PUSCH duration can be considered usable for transmitting a new MAC PDU. The MAC entity can assume that the NDI bit has been switched and transmit the HARQ information corresponding to the selected PUSCH duration to the HARQ entity, which can obtain the MAC PDU to be transmitted (if any) from the multiplexing and assembling entity.

[0052] In one implementation, a HARQ ID pool can be used for different CG configurations (e.g., the same HARQ ID can be derived from multiple CG configurations activated in the same ULBWP), and CG timers can be optionally configured in each ULBWP (e.g., CG timer values ​​can be the same in all CG configurations within the same ULBWP) or configured in each CG configuration (e.g., CG timer values ​​can be configured in each CG configuration). For each overlapping PUSCH duration available for initial transmission, the MAC entity can check (a) whether the CG timer corresponding to the derived HARQ program ID for that PUSCH duration is not running, or (b) whether the CG timer is currently running but initiated by a CG configuration with a lower priority than the CG configuration for that PUSCH duration. If no overlapping PUSCH duration satisfies either of the above conditions (i.e., condition (a) or condition (b)), it can be assumed that no PUSCH duration is available for transmission of a new MAC PDU. If only one overlapping PUSCH duration satisfies this condition, the MAC entity can assume that PUSCH duration is available for transmission of a new MAC PDU. If more than one overlapping PUSCH duration satisfies either condition (a) or condition (b) above, the MAC entity may select the PUSCH duration corresponding to the CG configuration with the highest priority. When CG configurations have the same or equal priority, determining which PUSCH duration to select may depend on the UE's implementation. Several implementations of CG configuration priority are provided in Case 4.

[0053] Figure 6 This is an exemplary method for handling resource overlap and HARQID conflicts performed by a MAC entity, as shown in the example implementation of this application. Figure 6In configuration #600, CG configuration #1 allocates PUSCH durations 610 and 611, both of which have HARQ ID #3. CG configuration #2 allocates PUSCH duration 621, which has HARQ ID #3 (e.g., due to a shared HARQ ID pool). CG configuration #3 allocates PUSCH duration 631, which has HARQ ID #1. PUSCH durations 610, 611, 621, and 631 can all be used for an initial transfer. PUSCH duration 611 overlaps with PUSCH duration 631 in the time domain. The CG timer associated with HARQ ID #3 is running when resource overlap occurs (e.g., at the moment when PUSCH durations 611 and 631 overlap). The CG timer associated with HARQ ID #3 is started by CG configuration #2.

[0054] When CG configuration #2 has a higher priority than CG configuration #1, the PUSCH duration 611 of CG configuration #1 can be disabled by CG configuration #2 because the higher-priority CG configuration #2 is still occupying HARQ ID #3. In this case, the above condition "(a) the CG timer corresponding to the HARQ program ID of this PUSCH duration is not running, or (b) the CG timer is currently running, but was started by a lower-priority CG configuration" is only satisfied by the PUSCH duration 631 from CG configuration #3. Therefore, PUSCH duration 631 can be considered the only PUSCH duration available for initial transmission (e.g., for transmitting a new MACPDU).

[0055] When CG configuration #2 has a lower priority than CG configuration #1, the PUSCH duration 611 of CG configuration #1 can take precedence over CG configuration #2 even if HARQ ID #3 is still occupied by CG configuration #2. In this case, the condition "(a) the CG timer corresponding to the HARQ procedure ID derived from this PUSCH duration is not running, or (b) the CG timer is currently running, but was started by a lower-priority CG configuration" is satisfied by both the PUSCH duration 631 from CG configuration #3 and the PUSCH duration 611 from CG configuration #1. In one implementation, when multiple overlapping PUSCH durations satisfy this condition, the MAC entity can select the one corresponding to the CG configuration with the highest priority. That is, the MAC entity can select either PUSCH duration 611 or PUSCH duration 631 based on the priorities of CG configuration #1 and CG configuration #3.

[0056] In one implementation, if a PUSCH duration (e.g., PUSCH duration 611) is selected for an initial transfer due to the configuration authorization priority order (e.g., a PUSCH duration is selected because the associated CG configuration has a higher priority), and its HARQ procedure overwrites another running HARQ procedure with the same HARQ ID (e.g., HARQ ID #3) from another CG configuration with a lower priority (e.g., CG configuration #2), then the MAC entity may refresh the HARQ cache (associated with HARQ ID #3) before generating a new MAC PDU to be transferred on the higher-priority CG configuration (e.g., CG configuration #1).

[0057] In one implementation, if a PUSCH duration is selected for an initial transfer due to configuration authorization priority order, and its HARQ procedure overwrites another running HARQ procedure with the same HARQID from another CG configuration with a lower priority, the MAC entity may stop the running CG timer associated with the lower priority CG configuration and / or HARQ procedure. In one implementation, the MAC entity may flush the HARQ cache before generating a new MAC PDU to be transferred on a higher priority CG configuration. In one implementation, the MAC entity may flush the HARQ cache associated with the lower priority HARQ procedure.

[0058] Figure 7 This is another exemplary method for handling resource overlap and HARQ ID conflicts performed by the UE's MAC entity, as shown in the example implementation of this application. Figure 7 In configuration #700, CG configuration #1 allocates PUSCH durations 710 and 711, both of which have HARQ ID #3. CG configuration #2 allocates PUSCH duration 721, which has HARQ ID #3 (e.g., due to a shared HARQ ID pool). CG configuration #3 allocates PUSCH duration 731, which has HARQ ID #1. PUSCH durations 710, 711, 721, and 731 can all be used for multiple initial transfers. PUSCH durations 711 and 731 overlap in the time domain. The CG timer associated with HARQ ID #3 is running when resource overlap occurs (e.g., at the moment when PUSCH durations 711 and 731 overlap). This CG timer associated with HARQ ID #3 is started by CG configuration #2.

[0059] When CG configuration #1 has a higher priority than CG configuration #2 and CG configuration #3, the MAC entity can select the PUSCH duration 711 for an initial transfer. Furthermore, the MAC entity can stop the ongoing CG timer associated with HARQ ID #3 of CG configuration #2 (e.g., at time T1) because it has been prioritized by CG configuration #1. The MAC entity can also flush the HARQ cache associated with HARQ ID #3 before generating a new MAC PDU to be transferred on CG configuration #1.

[0060] Case 2: Overlap between the durations of multiple PUSCHs that can be used for repeated transmissions.

[0061] For a serving cell, after determining that the PUSCH duration configured with uplink grants and the PUSCH duration received on the PDCCH do not overlap, the MAC entity may further check whether the PUSCH duration available for retransmission from an active CG configuration (e.g., the RV of this PUSCH duration is not zero) overlaps with another PUSCH duration available for retransmission from another active CG configuration used for this ULBWP (e.g., the RV of this PUSCH duration is also not zero). In one implementation, if multiple PUSCH durations available for retransmission overlap, the MAC entity may select the one corresponding to the CG configuration with the highest priority among these overlapping PUSCH durations. In this case, the MAC PDU in the HARQ buffer associated with the HARQ procedure of the selected PUSCH duration can be transmitted. In one implementation, when overlapping CG configurations have the same or equal priority, determining which PUSCH duration to select may depend on the UE implementation. Several implementations of CG configuration priority are provided in Case 4.

[0062] Case 3: Overlap between one or more PUSCH durations available for initial transmission and one or more PUSCH durations available for repeated transmission.

[0063] For a serving cell, after determining that the PUSCH duration configured for uplink grant does not overlap with the PUSCH duration of an uplink grant received on the PDCCH used for the serving cell, the MAC entity may further check whether the PUSCH duration available for a repeating transmission from an active CG configuration (e.g., the RV of this PUSCH duration is not zero) overlaps with another PUSCH duration for initial transmission from another active CG configuration used for the UL BWP (e.g., the RV of this PUSCH duration is zero). If there is an overlap, the MAC entity may derive the HARQ procedure ID for each overlapping PUSCH duration available for initial transmission.

[0064] In one implementation, separate HARQ ID pools can be used for different CG configurations (e.g., the same HARQ ID cannot be obtained from more than one CG configuration activated from the same ULBWP). For each overlapping PUSCH duration available for an initial transfer, the MAC entity can check whether the CG timer corresponding to the derived HARQ procedure ID of the PUSCH duration is running. If the CG timers corresponding to the HARQ IDs of all overlapping PUSCH durations available for multiple initial transfers are running, then any of these PUSCH durations can be considered unavailable for transferring a new MAC PDU. Therefore, the MAC entity can only select PUSCH durations for repeated transfers. In this case, the MAC PDU in the HARQ cache associated with the HARQ procedure of the selected PUSCH duration can be transferred. In one implementation, the PUSCH duration for repeated transfers can be selected following the rules covered in Case 2. If at least one CG timer corresponding to the HARQ ID of a PUSCH duration available for an initial transfer is not running, the MAC entity can select one of these PUSCH durations corresponding to the CG configuration with the highest priority. Several implementations of CG configuration priority are provided in Case 4.

[0065] In one implementation, a HARQ ID pool can be used for different CG configurations (e.g., the same HARQ ID can be obtained from multiple CG configurations activated in the same ULBWP), and CG timers can be optionally configured in each ULBWP (e.g., CG timer values ​​can be the same in different CG configurations within the same ULBWP) or configured in each CG configuration (e.g., a CG timer value is configured in each CG configuration). For each overlapping PUSCH duration available for an initial transfer (e.g., the RV of the PUSCH duration is zero), the MAC entity can check (a) whether the CG timer corresponding to the derived HARQ procedure ID for that PUSCH duration is not running, or (b) whether the CG timer is currently running but initiated by a CG configuration with a lower priority than the CG configuration for that PUSCH duration. If no overlapping PUSCH duration available for an initial transfer satisfies this condition, the MAC entity can choose not to select any of these PUSCH durations for the initial transfer (e.g., transfer a new MAC PDU). Therefore, the MAC entity can only select PUSCH durations for repeated transfers. In one implementation, the PUSCH duration for a repeated transmission can be selected following the rules covered in Case 2. If one or more overlapping PUSCH durations for multiple initial transmissions satisfy this condition, the MAC entity can select one of these PUSCH durations corresponding to the CG configuration with the highest priority. Several implementations of CG configuration priority are provided in Case 4.

[0066] In one implementation, if a PUSCH duration is selected for an initial transfer due to configuration authorization priority order, and its HARQ procedure overwrites another running HARQ procedure with the same HARQID from another CG configuration with a lower priority, the MAC entity may refresh the HARQ cache before generating a new MAC PDU to be transferred on the higher priority CG configuration.

[0067] In one implementation, if a PUSCH duration is selected for an initial transfer due to configuration authorization priority order, and its HARQ procedure overrides another running HARQ procedure with the same HARQID from a lower-priority CG configuration, the MAC entity may stop the running CG timer procedure associated with the lower-priority CG configuration and / or HARQ procedure. The MAC entity may flush the HARQ cache before generating a new MAC PDU to be transferred on a higher-priority CG configuration.

[0068] Case 4: Priority of CG configuration.

[0069] Case 4-1: In one implementation, the priority of one type of CG can be higher than that of another. For example, CG type 2 can have a higher priority than CG type 1, or vice versa. On the other hand, two active CG configurations of the same type can have the same priority, and determining which configuration to select can depend on the implementation of the UE.

[0070] Case 4-2: Priorities can be optionally configured by the base station (e.g., gNB) in each CG configuration (e.g., in configuredGrantConfigIE or in downlink control information (DCI) activating CG type 2 configuration). In one implementation, priorities can include "high priority" and "low priority". For example, the UE can receive a first CG configuration and a second CG configuration. The first CG configuration can include a first priority, and the second CG configuration can include a second priority. The UE can determine the priority order of the first CG configuration and the second CG configuration based on the high and low priorities. In one implementation, if no priority is configured, the corresponding CG configuration can be considered to have the lowest or highest priority than any other CG configuration with a priority. If neither CG configuration is configured with a priority, they can be considered to have the same priority.

[0071] Case 4-3: Priority can be implicitly determined by the Modulation and Coding Scheme (MCS) value associated with the CG configuration and / or the MCS table (e.g., the MCS table type configured in configuredGrantConfigIE and / or the Radio Network Temporary Identifier (RNTI) type associated with the DCI configured to activate CG type 2). In one example, a CG configuration associated with a high-reliability MCS table (e.g., qam64LowSE) can be used for Ultra-Reliable Communications and Low-Latency Communications (URLLC) services, while a CG configuration associated with a low-reliability MCS table (e.g., qam256) can be used for Enhanced Mobile Broadband (eMBB) services. In one implementation, the MAC entity can prioritize the PUSCH duration for the initial transmission from a CG configuration with a high-reliability MCS table. If multiple CG configurations are associated with the same reliability MCS table, determining which CG configuration to select for an initial transmission can depend on the UE's implementation.

[0072] Case 4-4: Priority can be implicitly determined by the parameter periodicity,p associated with the CG configuration (e.g., configuredGrantConfig IE). For example, a CG configuration with a long period can be used for latency-tolerant services. In one implementation, the MAC entity may prioritize the initial transmission from the CG configuration with the shortest associated periodicity,p over the PUSCH duration. If multiple CG configurations are associated with the same period, determining which CG configuration to select for the initial transmission may depend on the UE's implementation.

[0073] Cases 4-5: Priority can be implicitly determined by the number of repetitions (e.g., the repK parameter) associated with a CG configuration (e.g., configuredGrantConfig IE). For example, a CG configuration with a larger repK can be used for services requiring high reliability. Therefore, a CG configuration with a larger repK can have a higher priority.

[0074] Cases 4-6 to 4-9 can be used for scenarios where overlap occurs between one or more PUSCH durations for one or more initial transmissions and between one or more PUSCH durations for one or more repeated transmissions.

[0075] Case 4-6: When one or more PUSCH durations used for the initial transmission overlap with one or more PUSCH durations used for the repeat transmission, the MAC entity may disable the use of one or more PUSCH durations used for the initial transmission. This ensures that the number of repetitions within CG period p is satisfied by another CG configuration. Once all one or more PUSCH durations used for the initial transmission are eliminated, the one or more PUSCH durations used for the repeat transmission can be further prioritized based on the implementations provided in Cases 4-1 to 4-5.

[0076] Case 4-7: When one or more PUSCH durations for the initial transmission overlap with one or more PUSCH durations for the repeated transmission, the MAC entity may allow the use of one PUSCH duration for the initial transmission. This ensures that arriving data is served by the earliest possible PUSCH duration if the corresponding CG timer is not running. Once all one or more PUSCH durations for the repeated transmission are eliminated, the one or more PUSCH durations for the initial transmission can be further prioritized based on the implementations provided in Cases 4-1 to 4-5.

[0077] Case 4-8: In each CG configuration (e.g., configuredGrantConfig IE), the base station may optionally configure a guaranteed repetition count (e.g., parameter GR). If none of the one or more PUSCH durations used for repetitive transmissions are configured with this parameter across all overlapping PUSCH durations, the implementations provided in Cases 4-1 to 4-7 can be adopted. Alternatively, if at least one PUSCH duration used for repetitive transmissions is configured with this parameter, the MAC entity may allow the use of PUSCH durations for repetitive transmissions from CG configurations whose repetition count has not reached parameter GR. Further prioritization can then be ordered according to the implementations provided in Cases 4-1 to 4-5.

[0078] Case 4-9: The allow-repetition timer can optionally be configured in each CG configuration (e.g., configuredGrantConfigIE). If configured, the timer can start when the CG is activated and when the initial transfer is performed on the PUSCH duration used for the initial transfer. If none of the overlapping PUSCH durations have a PUSCH duration configured with the allow-repetition timer, the implementations provided in Cases 4-1 to 4-7 can be adopted. On the other hand, if at least one PUSCH duration for repeated transfers is configured with the allow-repetition timer, the MAC entity can allow the use of PUSCH durations for repeated transfers from CG configurations whose allow-repetition timers have not expired. The PUSCH durations for repeated transfers can then be further prioritized based on the implementations provided in Cases 4-1 to 4-5.

[0079] Case 5: When there is no PUSCH overlap, process the transmission of the PUSCH duration used for the initial transmission.

[0080] When the PUSCH duration configured from the CG for initial transmission (e.g., the RV of this PUSCH duration is zero) arrives, the MAC entity can check whether this PUSCH duration overlaps with any other PUSCH duration. Furthermore, in one implementation, the MAC entity can also check whether this PUSCH duration overlaps with another PUSCH duration received on the PDCCH (e.g., dynamic grant). If the PUSCH duration does not overlap with any other PUSCH duration, the MAC entity can determine the HARQ procedure ID associated with this PUSCH duration.

[0081] In one implementation, each active CG configuration may share a common HARQ ID pool and may configure a CG timer in each ULBWP or each CG configuration. The MAC entity may check whether (a) the CG timer corresponding to the HARQ ID for the PUSCH duration is not running, or (b) whether the CG timer is currently running but initiated by a CG configuration or dynamic grant (DG) with a lower priority than the CG configuration for the PUSCH duration. If the above conditions are not met (i.e., condition (a) or condition (b)), the MAC entity may not consider the PUSCH available for initial transmission (e.g., the MAC entity may not consider the PUSCH duration available for transmitting a new MAC PDU), and the MAC entity may neither transmit this grant to the HARQ entity nor receive a new MAC PDU to be transmitted over the PUSCH duration. This is because the MAC entity knows that the HARQ ID is being occupied by a dynamic transmission / repeated transmission or CG transmission / repeated transmission with a priority equal to or higher than the PUSCH duration. Conversely, if the above conditions are met, the MAC entity can assume that the PUSCH duration is available for the initial transmission (e.g., the MAC entity can assume that the PUSCH duration is available for transmitting a new MACPDU). In this case, the MAC entity can assume that the NDI bit for the corresponding HARQ procedure has been switched, and transmits the configuration UL authorization and associated HARQ information to the HARQ entity. This is because the MAC entity knows that the HARQ ID is not occupied or is occupied by a CG configuration with a lower priority.

[0082] In one implementation, if a PUSCH duration is selected for an initial transfer due to the configuration authorization priority order (e.g., a PUSCH duration is selected for transferring a new MAC PDU), and its HARQ procedure overwrites another running HARQ procedure with the same HARQ ID from another CG configuration with a lower priority or a DG with a lower priority, then the MAC entity may refresh the HARQ cache before generating a new MAC PDU to be transferred on the CG configuration with a higher priority.

[0083] In one implementation, if a PUSCH duration is selected for an initial transfer due to configuration authorization priority (e.g., a PUSCH duration is selected for transferring a new MAC PDU), and its HARQ procedure overwrites another running HARQ procedure with the same HARQ ID from another CG configuration or DG with a lower priority, the MAC entity may stop the CG timer associated with the lower priority CG configuration and / or HARQ procedure. In one implementation, the MAC entity may flush the HARQ cache before generating a new MAC PDU to be transferred on a higher priority CG configuration. In one implementation, the MAC entity may flush the HARQ cache associated with the lower priority HARQ procedure.

[0084] Figure 8 This is an exemplary method for handling HARQ ID conflicts performed by the MAC entity of a UE, as shown in the example implementation of this application. Figure 8 In the example, CG configuration #1 assigns PUSCH duration 810 with HARQ ID #3. CG configuration #2 assigns PUSCH duration 820 with HARQ ID #3 (e.g., due to a shared HARQ ID pool). When a HARQ ID conflict occurs (e.g., at the moment the HARQ ID of PUSCH duration 820 is derived), the CG timer associated with HARQ ID #3 is running. In this example, CG configuration #1 has a higher priority than CG configuration #2. Transmission on PUSCH duration 820 can be disabled because the derived HARQ ID of PUSCH duration 820 is still occupied by CG configuration #1 with the higher priority.

[0085] Figure 9 This is another exemplary method for handling HARQ ID conflicts performed by the MAC entity of the UE, as shown in the example implementation of this application. Figure 9In the example, CG configuration #1 assigns PUSCH duration 910 with HARQ ID #3. CG configuration #2 assigns PUSCH duration 920 with HARQ ID #3 (e.g., because of a shared HARQ ID pool). When a HARQ ID conflict occurs (e.g., at the moment the HARQ ID of PUSCH duration 920 is derived), the CG timer associated with HARQ ID #3 is running. In this example, CG configuration #2 has a higher priority than CG configuration #1. Transmission on PUSCH duration 920 can be allowed even though the derived HARQ ID of PUSCH duration 920 is still occupied by CG configuration #1. The MAC entity can stop the CG timer started by CG configuration #1 (e.g., before PUSCH duration 920 begins). Because CG configuration #1 has priority, the MAC entity can also flush the HARQ cache (associated with HARQ ID #3) before generating a new MAC PDU to be transmitted on CG configuration #2.

[0086] Figure 8 and Figure 9 The example shown illustrates a HARQ ID conflict between two CG configurations. It should be noted that HARQID conflicts can also occur between configuration grants and dynamic grants. The MAC entity can determine which transmission is allowed based on the priority order of configuration grants and dynamic grants. For example, when a configuration-granted PUSCH duration has a higher priority than a dynamic grant, the HARQ ID of the configuration-granted PUSCH duration can override the HARQ ID of the dynamic-granted PUSCH duration.

[0087] Figure 10 This is a block diagram illustrating a wireless communication node according to an exemplary embodiment of this application. Figure 10 As shown, node 1000 may include a transceiver 1020, a processor 1028, a memory 1034, one or more presentation components 1038, and at least one antenna 1036. Node 1000 may also include a radio frequency (RF) band module, a base station (BS) communication module, a network communication module and a system communication management module, input / output (I / O) ports, I / O components, and a power supply. Figure 10 (Not explicitly shown). Each of these components can communicate directly or indirectly with each other via one or more buses 1040. In one embodiment, node 1000 may be, for example, a device performing various functions of this invention. Figures 1 to 9 The UE or base station.

[0088] A transceiver 1020, having a transmitter 1022 (e.g., transmit / transmit circuitry) and a receiver 1024 (e.g., receive / receive circuitry), can be configured to transmit and / or receive time and / or frequency resource allocation information. In some embodiments, the transceiver 1020 can be configured to transmit in different types of subframes and time slots, including but not limited to usable, unusable, and flexibly usable subframe and time slot formats. The transceiver 1020 can be configured to receive data and control signaling.

[0089] Node 1000 may include various computer-readable media. Computer-readable media can be any available media accessible by Node 1000, and includes both volatile and non-volatile media, and removable and non-removable media. By way of example and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media includes both volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data.

[0090] Computer storage media include RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, Digital Universal Optical Disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage, or other magnetic storage devices. Computer storage media do not include the transmission of data signals. Communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals, such as carrier waves or other transmission mechanisms, and include any information delivery medium. The term "modulated data signal" means a signal having one or more characteristics set or altered in a manner that encodes information in the signal. By way of example, and not limitation, communication media include wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic, RF, infrared, and other wireless media). Any combination of the above should also be included within the scope of computer-readable media.

[0091] Memory 1034 may include a computer storage medium in the form of volatile and / or non-volatile memory. Memory 1034 may be removable, non-removable, or a combination thereof. Exemplary memories include solid-state memory, hard disk drives, optical disk drives, etc. Figure 10 As shown, memory 1034 may store computer-readable, computer-executable instructions 1032 (e.g., software code), which are configured to cause processor 1028 to execute, as described herein, referenced for example. Figures 1 to 9 The various functions. Alternatively, instruction 1032 may not be executed directly by processor 1028, but may be configured to cause node 1000 (e.g., at compile and execution time) to perform the various functions described herein.

[0092] Processor 1028 (e.g., having processing circuitry) may include intelligent hardware devices such as a central processing unit (CPU), microcontroller, ASIC, etc. Processor 1028 may include memory. Processor 1028 can process data 1030 and instructions 1032 received from memory 1034, as well as information transmitted via transceiver 1020, baseband communication module, and / or network communication module. Processor 1028 can also process information to be transmitted to transceiver 1020 for transmission via antenna 1036, or to the network communication module for transmission to the core network.

[0093] One or more presentation components 1038 present data indications to a person or other device. Several examples of presentation components 1038 may include display devices, speakers, printing components, vibrating components, etc.

[0094] It is evident from the above description that various techniques can be used to implement the concepts without departing from the scope of the concepts described in this application. Furthermore, although these concepts have been specifically described with reference to certain embodiments, those skilled in the art will recognize that changes in form and detail can be made without departing from the scope of those concepts. Therefore, the described embodiments are to be considered illustrative rather than restrictive in all respects. It should also be understood that this application is not limited to the specific embodiments described above, and many rearrangements, modifications, and substitutions are possible without departing from the scope of this application.

Claims

1. A user equipment (UE), comprising: comprising: a transceiver; one or more non-transitory computer-readable media having computer-executable instructions embodied thereon; and at least one processor coupled to the transceiver and the one or more non-transitory computer-readable media, the at least one processor configured to execute the computer-executable instructions to cause the UE to: receive, by the transceiver, a plurality of configured grant (CG) configurations allocating a group of CG physical uplink shared channel (PUSCH) durations in a bandwidth part (BWP), wherein at least two or more CG PUSCH durations in the group of CG PUSCH durations overlap in a time domain; determine whether at least one first CG timer of a plurality of first CG timers is not running, each of the plurality of first CG timers being associated with a hybrid automatic repeat request (HARQ) process of a respective CG PUSCH duration from the group of CG PUSCH durations; identify, from the group of CG PUSCH durations, a sub-group containing one or more CG PUSCH durations corresponding to the determined at least one first CG timer of the plurality of first CG timers that is not running, for a PUSCH initial transmission; select, from the identified sub-group containing one or more CG PUSCH durations, a particular CG PUSCH duration as a prioritized CG PUSCH duration; and perform, by the transceiver, an uplink transmission on the prioritized CG PUSCH duration.

2. The user equipment of claim 1, wherein, wherein, when a number of CG PUSCH durations in the identified sub-group containing one or more CG PUSCH durations is greater than 1, the prioritized CG PUSCH duration corresponds to a CG configuration having a highest priority among CG configurations corresponding to the identified sub-group containing one or more CG PUSCH durations.

3. The user equipment of claim 1, wherein: wherein, when a number of CG PUSCH durations in the identified sub-group containing one or more CG PUSCH durations is 1, the prioritized CG PUSCH duration corresponds to the identified CG PUSCH duration.

4. The user equipment of claim 1, wherein: wherein, the computer-executable instructions further cause the UE to: stop a second CG timer associated with a HARQ process of a de-prioritized CG PUSCH duration, wherein the de-prioritized CG PUSCH duration is different from the prioritized CG PUSCH duration and is in the group of CG PUSCH durations.

5. The user equipment of claim 4, wherein: wherein, the second CG timer is stopped after a transmission on the de-prioritized CG PUSCH duration has started. 6.A method for uplink transmission on a user equipment (UE), the method comprising: The method comprising: receiving a plurality of configured grant (CG) configurations allocating a group of CG physical uplink shared channel (PUSCH) durations in a bandwidth part (BWP), wherein at least one or more CG PUSCH durations in the group of CG PUSCH durations overlap in a time domain; determining whether at least one of a plurality of first CG timers is not running, each of the plurality of first CG timers being associated with a hybrid automatic repeat request (HARQ) process of a respective CG PUSCH duration from the group of CG PUSCH durations; identifying, from the group of CG PUSCH durations, a sub-group containing one or more CG PUSCH durations corresponding to the determined at least one of the plurality of first CG timers that is not running, for PUSCH initial transmission; selecting a particular CG PUSCH duration from the identified sub-group containing one or more CG PUSCH durations as a prioritized CG PUSCH duration; and 7. The method of claim 6, wherein, performing uplink transmission on the prioritized CG PUSCH duration. wherein, when the number of CG PUSCH durations in the identified sub-group containing one or more CG PUSCH durations is greater than 1, 8. The method of claim 6, wherein: the prioritized CG PUSCH duration corresponds to a CG configuration having a highest priority among CG configurations corresponding to the identified sub-group containing one or more CG PUSCH durations. wherein, 9. The method of claim 6, wherein, when the number of CG PUSCH durations in the identified sub-group containing one or more CG PUSCH durations is 1, the prioritized CG PUSCH duration corresponds to the identified CG PUSCH duration. further comprising: stopping a second CG timer associated with a HARQ process of a de-prioritized CG PUSCH duration, 10. The method of claim 9, wherein: wherein the de-prioritized CG PUSCH duration is different from the prioritized CG PUSCH duration and is in the group of CG PUSCH durations. wherein, stopping the second CG timer after transmission on the de-prioritized CG PUSCH duration has started.

Images