Hybrid automatic repeat request process determination

By allowing the UE to select the HARQ PID setting and dynamically adjust the use of PUSCH opportunities, the problem of underutilization of resources in the HARQ process in cellular communication is solved, improving data transmission efficiency and flexibility, especially in XR scenarios.

CN120982047APending Publication Date: 2025-11-18APPLE INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202380096838.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-04-05
Publication Date
2025-11-18

AI Technical Summary

Technical Problem

In existing technologies, the Hybrid Automatic Repeat Request (HARQ) process cannot be flexibly adjusted in cellular communications, resulting in the ineffective utilization of backup PUSCH opportunities and affecting data transmission efficiency, especially in scenarios such as extended reality (XR) that require high-speed and reliable data transmission.

Method used

By allowing user equipment (UE) to select HARQ process identifier (PID) settings, the use of standby PUSCH opportunities can be dynamically adjusted to enable autonomous retransmission, autonomous transmission, or new initial transmission, thereby improving resource utilization.

Benefits of technology

It enhances the flexibility and efficiency of data transmission, reduces latency, and meets the needs of high-speed and reliable data transmission such as XR.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120982047A_ABST
    Figure CN120982047A_ABST
Patent Text Reader

Abstract

Techniques are provided for flexible hybrid automatic repeat request selection by a user equipment. An example method includes a user equipment (UE) detecting a set of physical uplink shared channel (PUSCH) opportunities within a configuration grant cycle. The UE may associate a first hybrid automatic repeat request (HARQ) process identifier (PID) setting with a first PUSCH opportunity in a first subset of the set of PUSCH opportunities, the first HARQ PID setting configured by the base station. The UE may select a second HARQ PID setting for a second PUSCH opportunity in a second subset of the set of PUSCH opportunities.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates generally to wireless communication, and more specifically to the determination of a hybrid automatic repeat request process. Background Technology

[0002] Cellular communication can be defined in various standards to enable communication between user equipment and cellular networks. For example, Long Term Evolution (LTE) and Fifth Generation (5G) networks are defined by wireless standards designed to improve data transmission speed, reliability, availability, and so on. Attached Figure Description

[0003] Figure 1 This is an example of a system for providing content to a user equipment (UE) according to one or more implementation schemes.

[0004] Figure 2 This is an example of a periodic flow pattern of the payload based on one or more implementation schemes.

[0005] Figure 3 This is an example of a periodic configuration authorization (CG) configuration based on one or more implementation schemes.

[0006] Figure 4 This is an example of grouping data based on changes in one or more implementation schemes.

[0007] Figure 5 This is an example of a Multiple Physical Uplink Secure Channel (PUSCH) opportunity based on one or more implementation schemes.

[0008] Figure 6 This is an example of used and unused PUSCH opportunities as described in one or more implementation schemes.

[0009] Figure 7 It is an example of a set of PUSCH opportunities based on one or more implementation schemes.

[0010] Figure 8 It is an example of a set of PUSCH opportunities based on one or more implementation schemes.

[0011] Figure 9 It is a process flow for selecting the Hybrid Automatic Repeat Request (HARQ) process identifier (PID) setting according to one or more implementation schemes.

[0012] Figure 10 It is a process flow for UE to select HARQ PID settings according to one or more implementation schemes.

[0013] Figure 11It is a process flow for UE to select HARQ PID settings according to one or more implementation schemes.

[0014] Figure 12 Examples of receiving components according to some implementation schemes are shown.

[0015] Figure 13 Examples of user equipment (UE) according to some implementation schemes are illustrated.

[0016] Figure 14 Examples of base stations based on some implementation schemes are shown. Detailed Implementation

[0017] The following detailed description refers to the accompanying drawings. The same reference numerals may be used to identify the same or similar elements in different drawings. In the following description, specific details, such as particular structures, architectures, interfaces, technologies, etc., are set forth for illustrative and non-limiting purposes to provide a thorough understanding of various aspects of the various embodiments. However, it will be apparent to those skilled in the art that various aspects of the various embodiments may be practiced in other examples departing from these specific details. In some instances, descriptions of well-known devices, circuits, and methods have been omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of this document, the phrase “A or B” means (A), (B), or (A and B); and the phrase “based on A” means “at least partially based on A,” for example, it can be “based solely on A” or it can be “partially based on A.”

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

[0019] As used herein, the term "circuit" refers to, is part of, or includes hardware components such as electronic circuits, logic circuits, processors (shared, dedicated, or grouped) or memories (shared, dedicated, or grouped), application-specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or programmable system-on-a-chip (SoCs)), or digital signal processors (DSPs), etc. In some embodiments, the circuit may execute one or more software or firmware programs to provide at least some of the described functionalities. The term "circuit" may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) and program code for executing the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit.

[0020] As used herein, the term "processor circuit" means, is part of, or includes a circuit capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing, or transmitting digital data. The term "processor circuit" may also refer to an application processor, baseband processor, central processing unit (CPU), graphics processing unit, single-core processor, dual-core processor, triple-core processor, quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions such as program code, software modules, and / or functional processes.

[0021] As used herein, the term "interface circuit" refers to, is part of, or includes a circuit that enables the exchange of information between two or more components or devices. The term "interface circuit" can refer to one or more hardware interfaces, such as buses, I / O interfaces, peripheral component interfaces, or network interface cards.

[0022] As used herein, the term "user equipment" or "UE" refers to a device with radio communication capabilities and can describe network resources in a communication network. Furthermore, the term "user equipment" or "UE" can be considered synonymous and can refer to a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Additionally, the term "user equipment" or "UE" can include any type of wireless / wired equipment or any computing device that includes a wireless communication interface.

[0023] As used herein, the term "base station" refers to a device with radio communication capabilities that is a network component of a communication network (or more simply, a network) and can be configured as an access node within the communication network. The UE's access to the communication network can be managed at least partially by the base station, thereby connecting the UE to the base station to access the communication network. Depending on the Radio Access Technology (RAT), the base station may be referred to as a gNodeB (gNB), eNodeB (eNB), access point, etc.

[0024] As used herein, the term "network" refers to a communication network comprising a set of network nodes configured to provide communication capabilities to multiple user equipments via one or more base stations. For example, a network may be a Public Land Mobile Network (PLMN) implementing one or more communication technologies, including, for example, 5G communication.

[0025] As used herein, the term "computer system" means any type of interconnected electronic device, computer device, or component thereof. Additionally, the term "computer system" or "system" can refer to various components of a computer that are communicatively coupled to each other. Furthermore, the term "computer system" or "system" can refer to multiple computer devices or multiple computing systems that are communicatively coupled to each other and configured to share computing resources or network resources.

[0026] As used herein, the term "resource" refers to physical or virtual devices, physical or virtual components within a computing environment, or physical or virtual components within a specific device, such as computer equipment, mechanical equipment, memory space, processor / CPU time, processor / CPU utilization, processor and accelerator load, hardware time or utilization, power supply, input / output operations, port or network sockets, channel / link allocation, throughput, memory utilization, storage, network, databases and applications, units of workload, etc. "Hardware resource" can refer to computing, storage, or networking resources provided by physical hardware components. "Virtualized resource" can refer to computing, storage, or networking resources provided by virtualization infrastructure to applications, devices, systems, etc. The terms "network resource" or "communication resource" can refer to resources that a computer device / system can access via a communication network. The term "system resource" can refer to any kind of shared entity providing services and can include computing or network resources. System resources can be considered as a coherent set of functions, network data objects, or services that can be accessed through a server, wherein such system resources reside on a single host or multiple hosts and can be clearly identified.

[0027] As used herein, the term "channel" refers to any tangible or intangible transmission medium used to transmit data or data streams. The term "channel" may be synonymous or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term indicating a means or medium through which data is transmitted. Additionally, as used herein, the term "link" refers to a connection between two devices used for transmitting and receiving information.

[0028] As used in this article, the terms "instantiate" and "instantiate" refer to the creation of an instance. "Instance" also refers to the concrete occurrence of an object, which may occur, for example, during the execution of program code.

[0029] The term "connection" can refer to an established signaling relationship between two or more elements at a common communication protocol layer through a communication channel, link, interface, or reference point.

[0030] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as networked computers, network hardware, network equipment, network nodes, virtualized network functions, etc.

[0031] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual content of an information element, or the data element that contains that content. An information element may include one or more additional information elements.

[0032] The term "3GPP access" refers to access (e.g., radio access technologies) specified by 3GPP standards. These accesses include, but are not limited to, GSM / GPRS, LTE, LTE-A, 5G NR, and / or 6G. Generally speaking, 3GPP access refers to various types of cellular access technologies.

[0033] Figure 1 This is an example of a system for providing content to a user equipment (UE) according to one or more embodiments. As illustrated, UE 102 may include a client application 104 for providing an experience to a user. For example, a user may use client application 104 to send (e.g., uplink (UL) communication) and receive (e.g., downlink (DL) communication) content and present that content on UE 102. UE 102 may reside in a cell provided by base station 106. Base station 106 may, for example, use user plane function (UPF) 108 to communicate with an external data network (such as an external data network including application server 110). UE 102 may exchange information with application server 110 to provide an experience to the user.

[0034] Base station 106 can use configuration grant (CG) to configure UE 102 to transmit data to base station 106 using uplink transmission parameters. Through CG, UE 102 is allocated resources for periodic Physical Uplink Shared Channel (PUSCH) opportunities, whereby the UE can transmit multiple PUSCHs in each CG cycle. For example, UE 102 can be configured to have the opportunity to transmit x PUSCHs in each CG cycle.

[0035] Certain data traffic patterns can include variations in data packet size based on the technology and the type of data being sent. An example of such a technology is extended reality (XR). XR encompasses several technologies, including virtual reality (VR), augmented reality (AR), and mixed reality (MR). For optimal performance and user experience, XR technology requires high-speed and reliable data delivery. Some XR experiences can be downloaded and enjoyed locally on a device. Other XR experiences can be streamed from a cloud computing environment. For example, in some instances, XR technology is based on overlaying graphics onto images, which can be performed using smaller packet sizes. On the other hand, immersive XR experiences can use high-resolution graphics and location data, which require larger packet sizes.

[0036] Given different data packet sizes, UE 102 may use all PUSCH opportunities in the CG cycle. However, in other instances, the UE may use only a portion of the PUSCH opportunities in the CG cycle. In these instances, some PUSCH opportunities may be unused. One reason UE 102 cannot use these "spare" opportunities is because the Hybrid Automatic Repeat Request (HARQ) procedure for each PUSCH opportunity is preset and fixed based on network configuration. Therefore, it would be beneficial if UE 102 could select the HARQ procedure and use these spare PUSCH opportunities for other purposes during the CG cycle.

[0037] It should be understood that XR technology is shown as an example of a technology capable of generating data traffic patterns that include varying data packet sizes. Those skilled in the art can conceive of various technologies capable of generating data traffic patterns that include varying data packet sizes.

[0038] The implementation described herein addresses the aforementioned problem by providing a technique that allows the UE to select a Hybrid Automatic Repeat Request (HARQ) Procedure Identifier (PID) setting to use standby PUSCH opportunities for purposes other than those intended by the CG. The set of PUSCH opportunities can be divided into a first subset and a second subset, where the first subset includes PUSCH opportunities intended for transmitting data based on the original purpose (e.g., to perform a new transmission for data from a specific Logical Channel (LCH), which can be enabled by LCH mapping restrictions with permitted CGs). The HARQ PID setting for the PUSCH opportunities in the first subset can be configured by the base station. The second subset may include PUSCH opportunities intended for alternative purposes, such as retransmitting a previously transmitted Transport Block (TB), performing an autonomous transmission of a previously de-prioritized TB, or performing a new initial transmission. To allow the UE to use the second subset for alternative purposes, the UE can be enabled to set the HARQ PID setting for the PUSCH opportunities in the second subset.

[0039] Figure 2 This is an example of a periodic traffic pattern for the payload according to one or more implementations. For both DL and UL transmissions in an XR service, the payload is periodic. For example, in an XR service, the video frame rate could be 30 frames per second, 60 frames per second, or 90 frames per second. As shown, the arrival of each packet is periodic, and each period can be defined by a frequency 1 / T. The arrival of the second packet 204 can occur after the arrival of the first packet 202, and so on. The arrival time interval for each packet is time period T.

[0040] Ideally, the Radio Access Network (RAN) can obtain auxiliary information related to the characteristics of data traffic from the core network or the UE. The RAN can then use this auxiliary information to appropriately allocate resources for service. Based on the periodic nature of data traffic, the Garbage Collection (CG) is expected to be a key resource allocation method for new transmissions of data for a specific UL traffic flow. However, as indicated above, in some instances, resources not intended for new transmissions for a specific UL traffic flow may be allocated for the PUSCH, but these resources can be used for alternative purposes if the UE can select the corresponding HARQ PID setting.

[0041] Figure 3 This is illustration 300 of a periodic CG configuration according to one or more implementations. The CG allows the UE to know in advance where PUSCH resources are available for UL transmission within a time and frequency range, without requiring dynamic signaling for resource allocation. As shown, a CG configuration with a periodicity T is illustrated. For each PUSCH opportunity 304, the UE (e.g., UE 102) can receive information from the network configuration for resources allocated for UL transmission during the PUSCH opportunity. As further shown, the CG is used to allocate resources for each PUSCH opportunity in each CG cycle, where each CG cycle can be defined by a time period T.

[0042] Figure 4This is a diagram illustrating the varying data packet sizes based on one or more implementation schemes. As shown, packet k402 is followed by packet k+1. Packet k402 represents an Internet Protocol (IP) packet belonging to video frame k, and packet k+1 404 represents an IP packet belonging to video frame k+1. According to 3GPP Technical Report (TR) 38.838, XR periodic traffic may be associated with random jitter, where the actual arrival time may deviate from the nominal timing based on the periodicity of the traffic. As shown, based on the expected jitter, data traffic packets can be sent at an average rate of 1 frame per second (fps). In addition to timing variations, there are also variations in packet size. As shown, packet k402 is larger than packet k+1 404. It is possible to address these traffic characteristics in Release 18. Different scenarios involving varying packet sizes with a fixed Transport Block Size (TBS) may exist. The first scenario could be when the packet size is larger than the TBS at the CGS timing. Therefore, packets cannot be accommodated in a single CG cycle, which may introduce latency. The second scenario could occur when the packet size is smaller than the CG at the time of TBS, which is not resource-efficient. Furthermore, in this second scenario, the base station can allocate resources to another UE.

[0043] Figure 5 This is a diagram 500 illustrating multiple PUSCH opportunities according to one or more embodiments. As shown, each CG opportunity includes multiple multiple PUSCH opportunities, and each set includes four PUSCH opportunities. It can be seen that each of the first set 502, the second set 504, the third set 506, and the fourth set 508 of PUSCH opportunities includes four PUSCH opportunities. The periodicity of each set of PUSCH opportunities in the CG opportunity extends from the beginning of the first PUSCH opportunity in the first set 502 to the beginning of the first PUSCH opportunity in the second set 504. As described herein, multiple PUSCH opportunities indicate more than one PUSCH opportunity.

[0044] For each CG opportunity, the set of PUSCH opportunities can include PUSCH opportunities associated with different HARQ PIDs. Different HARQ procedures exist that can be used for each PUSCH opportunity. HARQ is a method used to improve the reliability of data transmission by retransmitting lost or corrupted packets. A HARQ procedure identifier is a unique identifier assigned to each transmission attempt within a HARQ procedure.

[0045] The UE can transmit UL data in transport blocks (TBs). After each UL transmission attempt, the base station can attempt to decode the TB. If the TB is successfully decoded by the base station, the base station can send an acknowledgment (ACK) to the UE to indicate that the packet was correctly received. However, if the TB is not successfully decoded by the base station, the base station can schedule a retransmission grant for the UE to retransmit the packet.

[0046] The UE and base station can use a HARQ procedure identifier (HARQ PID) to identify each transmission attempt within a CG cycle. The HARQ PID is used to track different TBs that are transmitted and retransmitted. For example, if the UE receives a retransmission grant from the base station, the UE can use the HARQ PID to identify which TB needs to be retransmitted.

[0047] Figure 6 This is a diagram 600 illustrating used and unused PUSCH opportunities according to one or more implementations. As indicated above, in some instances, the UE's uplink data traffic includes varying packet sizes, and therefore, the UE does not require every single PUSCH opportunity in the CG cycle. In these instances, there will be unused or spare PUSCH opportunities. In version 18, the UE can transmit an indication (e.g., in the CG-UCI) 602 to the base station regarding which PUSCH opportunities will not be used, and thus, the base station can allocate resources allocated for those PUSCH opportunities to other UEs. As illustrated, for each set of PUSCH opportunities, there can be a different number of used and unused PUSCH opportunities. In the first set 604 of PUSCH opportunities, there are two used PUSCH opportunities (shown in black) and two unused PUSCH opportunities (shown in white). In the second set 606 of PUSCH opportunities, there is one used PUSCH opportunity and three unused PUSCH opportunities. In the third set 608 of PUSCH opportunities, there are three used PUSCH opportunities and one unused PUSCH opportunity.

[0048] The implementation described herein provides greater flexibility by enabling the UE to use these spare PUSCH opportunities for a variety of purposes, such as autonomously retransmitting previously transmitted TBs (without requiring retransmission authorization from the base station), autonomously transmitting previously de-prioritized TBs, and performing new initial transmissions. Under the existing framework, the UE cannot perform these various purposes because the HARQ procedure for each PUSCH within the CG cycle is fixed.

[0049] Figure 7It is an illustration of a set of PUSCH opportunities according to one or more embodiments. For NR operation using unlicensed spectrum, the UE can select the HARQ PID for the CG resources by itself (e.g., from the configured HARQ PID pool). However, in the case where the UE selects the HARQ PID for the CG PUSCH opportunity, according to the current MAC specification, the UE should prioritize the HARQ PID corresponding to the retransmission. For example, the UE should have some TBs stored in certain HARQ processes. The UE should first select the HARQ process corresponding to the retransmission rather than the HARQ process corresponding to the newly transmitted one.

[0050] However, if the new radio unlicensed (NR-U) mechanism is applied to multi-PUSCH CGs for XR, the UE can use one or more previous PUSCH opportunities in the CG cycle for retransmission (based on the prioritization rule mentioned above), and the remaining available PUSCH resources in the CG cycle may not be sufficient to accommodate a large packet size, and the UE may need to wait until the next CG cycle to fully transmit the large packet, which may result in an undesirable delay. As Figure 7 shown, the first two spare PUSCH opportunities 702 are used for retransmission. The remaining two spare PUSCH opportunities 704 are not sufficient to accommodate a large data packet.

[0051] Figure 8 It is an illustration 800 of a set of PUSCH opportunities according to one or more embodiments. The embodiments herein describe a method for enabling the UE to use spare PUSCH resources together with multi-PUSCH CGs and improve resource efficiency. The base station can use a configuration message to allocate resources for N PUSCH opportunities in the CG cycle. Each set of PUSCH opportunities in the CG cycle can be divided into a first subset 802 and a second subset 804. The first subset 802 can include K (K < N) PUSCH opportunities whose HARQ PIDs are fixed. For example, the HARQ PID can be based on resource timing in prior art standards such as including 3GPP TS 38.321.

[0052] As shown in the figure, the first PUSCH opportunity 806 is fixed with HARQ PID 0, and the second PUSCH opportunity 808 is fixed with HARQ PID 1. Each PUSCH opportunity in the second subset 804 is not fixed with any HARQ PID. The second subset 804 includes PUSCH opportunities whose HARQ PIDs are selectable by the UE. It should be understood that HARQ PID 0 and HARQ PID 1 are placeholder values, and the PUSCH opportunities in the subset should not be interpreted as having a fixed specific HARQ PID. The second set of PUSCH opportunities follows the first set of PUSCH opportunities, wherein the second set of PUSCH opportunities has also been divided into a first subset of PUSCH opportunities with fixed HARQ PIDs and a second subset of PUSCH opportunities whose corresponding HARQ PIDs are selectable by the UE. It should be understood that the implementation described herein is applicable to CG and multi-PUSCH dynamic authorization (DG), where DG allocates multiple PUSCH resources.

[0053] The set of PUSCH opportunities in the CG cycle (e.g., a first set 810 of PUSCH opportunities) can be divided into a first subset 802 and a second subset 804 based on a fixed or dynamic partition. A fixed partition includes network pre-configuration of the first subset 802 and the second subset 804. For a fixed partition, the first subset 802 and the second subset 804 are fixed. Therefore, the UE is pre-configured to identify which PUSCH opportunity belongs to the first subset 802 and which PUSCH opportunity belongs to the second subset 804. It should be noted that in some implementations, a PUSCH opportunity in the first subset 802 may occur after a PUSCH opportunity in the second subset 804.

[0054] For dynamic partitioning, partitioning can be based on the number of PUSCH opportunities the UE will use to transmit data from a specific logical channel (LCH). In an instance where the UE transmits all data intended to be transmitted within the set of PUSCH opportunities (i.e., data from a specific LCH), one or more LCH UL transmit buffers may be considered empty. Upon detecting such an empty buffer, the UE can determine whether any spare PUSCH opportunities exist in the CG cycle. If one or more spare PUSCH opportunities exist, the UE can determine which PUSCH opportunities are in the second subset 804. These spare PUSCH opportunities may have their original or default HARQ PID pre-configured by the base station, but if these PUSCH opportunities are considered spare PUSCH opportunities (e.g., not used for data from a specific LCH because the UL transmit buffers of these LCHs are considered empty), the UE can select alternative HARQ PIDs for these PUSCH opportunities (which replace the original or default HARQ PID).

[0055] In instances of periodic traffic (such as XR traffic), the HARQ procedure for the first PUSCH opportunity (e.g., PUSCH opportunity 806) should be statically configured by the base station to ensure that the UE can perform a new initial UL transmission for the intended purpose (e.g., to perform a new transmission of data from a specific LCH) and then select a HARQ procedure for the UL transmission used for another purpose (e.g., to perform a retransmission of a previously transmitted TB).

[0056] In some instances, the UE can select an allowed HARQ procedure for a second subset of PUSCH opportunities from a HARQ PID pool for a specific CG. In these instances, the base station can pre-configure an allowed HARQ PID pool for each CG. When processing PUSCH in the second subset, the UE is only allowed to select a HARQ PID from the pre-configured pool associated with the CG. The base station can configure the UE with an allowed HARQ PID pool using the RRC parameter (or its extension) of harq-ProcID-Offset in the Information Element (IE) of ConfiguredGrantConfig.

[0057] In some instances, the base station configures the DG to allocate resources for a set of PUSCH opportunities. In these instances, the base station may further instruct the UE whether to use fixed or dynamic partitioning to determine how to partition the set of PUSCH opportunities in the CG cycle using the DCI that allocates the DG.

[0058] In instances where the UE is configured to use direct partitioning, the UE can be configured to include a different number of PUSCH opportunities in the first subset for each CG cycle. For example, the UE can be configured to include two PUSCH opportunities in the first subset on the first CG cycle. The UE can be further configured to include three PUSCH opportunities in the first subset on subsequent CG cycles.

[0059] In order for the UE to select a HARQ PID for the second subset of PUSCH opportunities in the CG cycle, the base station and the UE synchronize which HARQ PID has been selected for which PUSCH opportunity.

[0060] The base station can use configuration messages to configure the UE with resources for a set of PUSCH opportunities for multiple CG cycles. The base station can further configure the UE for multiple instances of direction partitioning and / or multiple instances of dynamic partitioning during multiple CG cycles. The UE can send one or more UL messages / control signals to indicate at least one of the following: (1) whether the UE will use standby PUSCH opportunities for purposes other than those in the first subset; (2) which PUSCH opportunities will be considered as the "second subset" for which the UE will choose its own HARQ PID, given that the base station has already configured the UE with PUSCH resources using DG; and (3) what HARQ PID the UE chooses for each PUSCH in the second subset. The UE can send UL messages / uplink control signals to the base station using UCI, CG-UCI, or a Media Access Control CE (MAC CE).

[0061] The UE can transmit one or more uplink messages / control signals in one or more PUSCHs within the relevant CG cycle. In other words, the CG cycle in which the UE resides will select a HARQ PID for the PUSCH opportunity. For example, the UE can transmit a CG-UCI to the base station in the first PUSCH of the CG cycle (e.g., the first PUSCH in the first subset), where the CG-UCI includes an indication of what HARQ PID the UE will select for all subsequent PUSCHs in the second subset. Alternatively, the UE can transmit a CG-UCI to the base station that includes an indication of whether the UE will use or skip the PUSCH resources in the second subset. Yet another alternative could include the UE transmitting a CG-UCI indicating the selected HARQ PID in the corresponding PUSCH in the second subset.

[0062] If a fixed partitioning is used, the UE can choose not to transmit any CG-UCI and PUSCH resources in the first subset. Base stations that have already partitioned into the first and second subsets know the HARQ PID for the first subset.

[0063] As indicated above, the UE can select a HARQ PID for a standby PUSCH opportunity in the second subset of PUSCH opportunities in the CG cycle. The UE can be configured to select a HARQ PID for the standby PUSCH opportunity using various criteria.

[0064] For example, the UE can select the same HARQ procedure as the HARQ procedure corresponding to an earlier PUSCH in the same CG cycle. The UE can make this selection to, for example, repeat the transmission of the transport block sent on the earlier PUSCH in the same CG cycle. This proactively improves reliability.

[0065] In another example, the UE can select the same HARQ procedure as the HARQ procedure corresponding to an earlier PUSCH in a previous CG cycle or the same CG cycle, where the configuration grant timer associated with the HARQ procedure is still running. The configuration grant timer controls how long the UE should keep the TB in the HARQ procedure before refreshing. Similarly, the UE can select the same HARQ PID based on the need to retransmit the TB still stored in the HARQ buffer.

[0066] In some instances, the UE can select a HARQ procedure where the associated configuration grant timer is not running in order to perform a new transmission. An example in the above scenario is that the UE is retransmitting a previously transmitted TB. However, in many instances, the UE may need to transmit a new TB instead of retransmitting a previously transmitted TB. Therefore, after the configuration grant timer associated with the previous PUSCH expires, the UE can select the HARQ PID used for the new transmission.

[0067] In another example, the UE can select the same HARQ procedure as the earlier PUSCH in a previous CG cycle or the same CG cycle. However, the MAC Protocol Data Unit (PDU) sent using the PUSCH resource has been de-prioritized. Note that a MAC PDU can be equivalent to a TB. A MAC PDU can be de-prioritized based on expectations such as allowing higher-priority MAC PDUs to be sent first during high traffic periods. De-prioritized MAC PDUs that have not yet been fully sent can be sent in subsequent resources based on an autonomous transmission mechanism. Therefore, when a spare PUSCH exists, the UE can select the HARQ procedure corresponding to the de-prioritized MAC PDU to perform the autonomous transmission of the de-prioritized MAC PDU.

[0068] In any of the examples above, the UE may consider the LCH priority of the MAC PDU corresponding to different HARQ procedures. For example, the UE may select the HARQ procedure corresponding to the purpose of sending the MAC PDU with the highest LCH priority.

[0069] Base station (e.g., Figure 1 The base station 106 can configure the UE (e.g., regarding how to handle the spare PUSCH opportunities in the second subset associated with the CG) Figure 1 (UE 102). For example, the base station can send a message to the UE that includes an indication of which PUSCH opportunities are included in the second subset and all PUSCH opportunities in the second subset are skipped. This procedure can be used when the base station has configured the UE for fixed partitioning.

[0070] In another example, even if the UE has no data to send, the base station can send a message to the UE to use each spare PUSCH opportunity. If the UE has data to send, the UE can use the PUSCH resources to send the data. If the UE has no data to send, the UE can, for example, generate a dummy MAC PDU and use the PUSCH resources to send the dummy MAC PDU.

[0071] In another example, the base station can send a message to the UE to select a HARQ PID for a backup PUSCH opportunity. In this case, the UE can select the HARQ PID from the intended purpose of the first subset of PUSCH opportunities to use the backup PUSCH opportunity for a new purpose. The new purpose could be, for example, performing a retransmission / repetition of a previously transmitted transport block (TB), performing an autonomous transmission of a previously de-prioritized TB, or performing a new initial transmission or other new purpose. As an example, the base station can configure the UE to use PUSCHs from a second subset to repeat TBs, which may have different redundancy versions (RVs).

[0072] The base station can, for example, use MAC CE or downlink control information (DCI) to further dynamically change the UE's behavior regarding how to handle the spare PUSCH. For example, the base station can configure the UE as described in any of the examples above. The base station can then use MAC CE or DCI to change how the UE handles the spare PUSCH.

[0073] Figure 9 This is a process flow 900 for selecting HARQ PID settings according to one or more embodiments. At 902, the method may include a computing device detecting a set of PUSCH opportunities within a configuration grant cycle. The computing device may be a UE that has already had resources configured by a base station using a CG for the set of PUSCH opportunities.

[0074] At 904, the method may include a computing device associating a first HARQ PID setting with a first PUSCH opportunity in a first subset of a set of PUSCH opportunities, the first HARQ PID setting being configured by a base station. The set of PUSCH opportunities may be divided into a first subset and a second subset of PUSCH opportunities.

[0075] In some implementations, the partitioning can be fixed, where the base station sends an indication to the UE regarding how to partition the set of PUSCH opportunities. In some implementations, the partitioning is based on technical standards. For example, for a set of PUSCH opportunities with a quantity of N, the base station can send an indication that a quantity of X PUSCH opportunities are included in a first subset and a quantity of Y opportunities are included in a second subset, where X + Y = N. The base station can also select a HARQ PID setting for the PUSCH opportunities in the first subset. The base station can use a CG or a multi-PUSCH DG to configure resources for the UE.

[0076] In some implementations, the first PUSCH opportunity for the HARQ PID settings of a first subset is statically selected, allowing the UE to use the first PUSCH opportunity to perform a new transmission. In other words, the HARQ PID corresponds to a new transmission, rather than a repetition of a previous transmission.

[0077] In some implementations, when the base station uses a fixed partition, the number of PUSCH opportunities in the first CG cycle is set differently from the number of PUSCH opportunities in the second CG cycle. For example, the base station may set P P PUSCH opportunities for the first subset in the CG cycle. The base station may also set O PUSCH opportunities for the first subset in subsequent CG cycles.

[0078] In some other implementations, the partitioning can be dynamic, where the UE determines which PUSCH opportunities are included in a first subset and which are included in a second subset. For example, the UE can use resources allocated to the PUSCH opportunities in the first subset and use the LCH to send uplink messages. The UE can further determine that the LCH buffer is empty based on the absence of transmissions. The UE can further detect standby PUSCH opportunities from the set of PUSCH opportunities. The UE can even further associate standby PUSCH opportunities with a second subset of the set of PUSCH opportunities, where the standby PUSCH opportunity is a second PUSCH opportunity.

[0079] In some implementations, the base station uses DGs allocated in the DCI to allocate resources for the set of PUSCH opportunities. In these instances, the DCI may further instruct the UE whether to use a fixed allocation or a dynamic allocation.

[0080] At 906, the method may include the computing device selecting a second HARQ PID setting for a second PUSCH opportunity within a second subset of the set of PUSCH opportunities. The selection of the HARQ PID setting may be based on the intended purpose of the uplink transmission at the second PUSCH opportunity. In some embodiments, the UE selects the second HARQ PID from a pool of allowed HARQ PIDs, wherein the UE is configured by the base station to have access to the pool of allowed HARQ PIDs. The base station may use parameters from a Radio Resource Control (RRC) message to configure the UE to have access to the pool of allowed HARQ PIDs. The UE may further select the HARQ PID setting.

[0081] In some implementations, the base station can configure the UE to perform direct partitioning or dynamic partitioning for two or more consecutive CG cycles. For example, the base station can configure the UE for direct partitioning for a number of CG cycles A, and then configure the UE for dynamic partitioning for a number of CG cycles B, where A and B are each greater than 1.

[0082] The computing device can use the second PUSCH opportunity to send data to the base station. The base station can perform the HARQ procedure based on the selected second HARQ PID setting and return a HARQ response to the UE.

[0083] Figure 10 This is a process flow 1000 for a UE to select HARQ PID settings according to one or more embodiments. At 1002, the method may include a computing device detecting a set of Physical Uplink Shared Channel (PUSCH) opportunities. The computing device may be a UE including memory and processing circuitry coupled to the memory.

[0084] At 1004, the method may include a computing device associating a first Hybrid Automatic Repeat Request (HARQ) process identifier (PID) setting with a first PUSCH opportunity in a first subset of the set of PUSCH opportunities, the first HARQ PID setting being indicated by a base station. The set of PUSCH opportunities may be divided into a first subset and a second subset of PUSCH opportunities.

[0085] At 1006, the method may include a second PUSCH opportunity in a second subset of the set of PUSCH opportunities identified by the computing device, and a second HARQ PID setting for the second PUSCH opportunity may be selected by the UE. The UE may select an appropriate HARQID.

[0086] The computing device may send an indication to the base station associated with a second PUSCH opportunity. This indication may include whether the UE will use the second PUSCH opportunity for a different purpose than the first PUSCH opportunity; the identifier of the second PUSCH opportunity; or the corresponding HARQ PID for each PUSCH opportunity in a second subset that includes the second PUSCH opportunity. The indication is sent using UCI, CG-UCI, or MAC CE.

[0087] In some implementations, the indication can be sent using CG-UCI, wherein the UE sends CG-UCI at a first PUSCH opportunity in the set of PUSCH opportunities, and wherein the CG-UCI indicates the corresponding HARQ PID for each PUSCH opportunity in the set of PUSCH opportunities divided into a first subset and a second subset.

[0088] In some implementations, the indication may be sent using CG-UCI, and the CG-UCI indicates that the UE will use or skip using any PUSCH resources associated with the second subset.

[0089] In some implementations, the indication can be sent using CG-UCI, wherein the UE sends CG-UCI at the second PUSCH opportunity, and wherein the CG-UCI indicates the HARQ ID for the second PUSCH opportunity.

[0090] In some implementations, the set of PUSCH opportunities may be divided into a first subset and a second subset based on a fixed partition, and the UE is configured to send CG-UCI in any PUSCH opportunity (including the first PUSCH opportunity) that is not in the first subset.

[0091] Figure 11 This is a process flow 1100 for a UE to select HARQ PID settings according to one or more embodiments. At 1102, the method may include a computing device detecting a set of Physical Uplink Shared Channel (PUSCH) opportunities within a configuration grant cycle. The computing device may be a UE including memory and processing circuitry coupled to the memory.

[0092] At 1104, the method may include a computing device associating a first HARQ PID setting with a first PUSCH opportunity in a first subset of the set of PUSCH opportunities.

[0093] At 1106, the method may include a computing device selecting a second HARQ PID setting for a second PUSCH opportunity based on the intended purpose of a second PUSCH opportunity in a second subset of the set of PUSCH opportunities.

[0094] In some implementations, the UE may select a second HARQ PID setting based on the same HARQ PID of an earlier PUSCH opportunity in the CG cycle, and the intended purpose is to repeat the data blocks sent at the earlier PUSCH opportunity.

[0095] In some implementations, the UE may select a second HARQ PID setting for a PUSCH opportunity based on the same HARQ PID as the earlier PUSCH opportunity, wherein the CG timer associated with the same HARQ PID is running, and wherein the intended purpose is to retransmit the data block sent at the earlier PUSCH opportunity.

[0096] In some implementations, the UE may select a second HARQ PID setting based on the same HARQ PID of the earlier PUSCH opportunity, wherein the CG timer associated with the same HARQ PID is not running, and wherein the instruction is executed by one or more processors, and wherein the intended purpose is to send a data block at the second PUSCH opportunity for an alternative purpose other than sending a data block at the first PUSCH opportunity.

[0097] In some implementations, the UE may select a second HARQ PID setting based on the same HARQ PID that is an earlier PUSCH opportunity, and the intended purpose is to autonomously send a de-prioritized MAC PDU.

[0098] In some implementations, the UE can select a second HARQ PID for the PUSCH opportunity based on the MAC PDU with the highest priority LCH.

[0099] The computing device can use the second PUSCH opportunity to send uplink transmissions to the base station.

[0100] The term "non-3GPP access" refers to any access technology (e.g., radio access technologies) not specified by 3GPP standards. These accesses include, but are not limited to, WiMAX, CDMA2000, Wi-Fi, WLAN, and / or fixed networks. Non-3GPP access can be categorized into two types: "trusted" and "untrusted." Trusted non-3GPP access can interact directly with the Evolved Packet Core (EPC) and / or the 5G Core (5GC), while untrusted non-3GPP access interoperates with the EPC / 5GC via network entities such as Evolved Packet Data Gateways and / or 5G NR Gateways. Generally speaking, non-3GPP access refers to various types of non-cellular access technologies.

[0101] Figure 12A receiver assembly 1200 for a UE 1206 according to some embodiments is illustrated. The receiver assembly 1200 may include an antenna panel 1204 that includes a plurality of antenna elements. The panel 1204 is shown as having four antenna elements, but other embodiments may include other numbers of antenna elements.

[0102] Antenna panel 1204 can be coupled to an analog beamforming (BF) assembly including a plurality of phase shifters 1208(1) to 1208(4). Phase shifters 1208(1) to 1208(4) can be coupled to a radio frequency (RF) chain 1212. RF chain 1212 can amplify received analog RF signals, down-convert RF signals to baseband, and convert analog baseband signals into digital baseband signals that can be provided to a baseband processor for further processing.

[0103] In various implementations, control circuitry residing in the baseband processor may provide BF weights (e.g., W1 to W4) (which may represent phase shift values) to phase shifters 1208(1) to 1208(4) to provide a receive beam at antenna panel 1204. These BF weights may be determined based on channel-based beamforming.

[0104] Figure 13 An example of UE 1300 according to some implementation schemes is shown. UE 1300 may be similar to Figure 12 The UE 1206 is basically interchangeable with it.

[0105] Similar to the description above relative to UE 1300, UE 1300 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, computer, tablet, industrial wireless sensors (e.g., microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, stock sensors, voltmeters / ammeters, actuators, etc.), video surveillance / monitoring devices (e.g., cameras, camcorders, etc.), wearable devices, or loosely coupled IoT devices. In some implementations, the UE can be a reduced-capacity UE or an NR lightweight UE.

[0106] UE 1300 may include a processor 1304, RF interface circuitry 1308, memory / storage device 1312, user interface 1316, sensor 1320, drive circuitry 1322, power management integrated circuit (PMIC) 1324, and battery 1328. The components of UE 1300 may be implemented as integrated circuits (ICs), portions of such integrated circuits, discrete electronic devices or other modules, logic components, hardware, software, firmware, or combinations thereof. Figure 13The block diagram is intended to show a high-level view of some of the components of the UE 1300. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other specific implementations.

[0107] The components of UE 1300 can be coupled to various other components via one or more interconnects 1332, which can represent any type of interface, input / output, bus (local, system, or extension), transmit line, trace, optical connection, etc., allowing various circuit components (on common or different chips or chipsets) to interact with each other.

[0108] Processor 1304 may include processor circuitry, such as, for example, baseband processor circuitry (BB) 1304A, central processing unit circuitry (CPU) 1304B, and graphics processing unit circuitry (GPU) 1304C. Processor 1304 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional procedures from memory / storage device 1312) to cause UE 1300 to perform the operations described herein.

[0109] In some implementations, the baseband processor circuit 1304A can access the communication protocol stack 1336 in the memory / storage device 1312 to communicate over a 3GPP-compliant network. Generally, the baseband processor circuit 1304A can access the communication protocol stack to perform user plane functions at the PHY, MAC, RLC, PDCP, SDAP, and PDU layers; and control plane functions at the PHY, MAC, RLC, PDCP, RRC, and Non-Access Stratum (NAS) layers. In some implementations, PHY layer operations may additionally / optionally be performed by components of the RF interface circuit 1308.

[0110] The baseband processor circuit 1304A can generate or process baseband signals or waveforms carrying information in a 3GPP-compliant network. In some implementations, the waveforms used for NR can be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and Discrete Fourier Transform Extended OFDM (DFT-S-OFDM) in the uplink.

[0111] The baseband processor circuit 1304A can also access group information 1324 from the memory / storage device 1312 to determine multiple repeating search space groups in which PDCCH can be sent.

[0112] The memory / storage device 1312 may include any type of volatile or non-volatile memory that can be distributed throughout the UE 1300. In some embodiments, some of the memory / storage devices 1312 may be located on the processor 1304 itself (e.g., L1 cache and L2 cache), while other memory / storage devices 1312 may be located outside the processor 1304 but accessible via a memory interface. The memory / storage device 1312 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0113] RF interface circuitry 1308 may include transceiver circuitry and a radio frequency front-end module (RFEM), which allows UE 1300 to communicate with other devices via a radio access network. RF interface circuitry 1308 may include various components arranged in the transmit or receive path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0114] In the receiving path, the RFEM can receive the radiated signal from the air interface via antenna 1324, and continue to filter and amplify the signal (using a low-noise amplifier). This signal can be provided to the receiver of the transceiver, which downconverts the RF signal into a baseband signal that is provided to the baseband processor of processor 1304.

[0115] In the transmission path, the transceiver's transmitter up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM can then amplify the RF signal using a power amplifier before it is radiated across the air interface via antenna 1324.

[0116] In various implementations, the RF interface circuit 1308 can be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0117] Antenna 1324 may include multiple antenna elements, each of which converts an electrical signal into a radio wave to travel through the air and converts received radio waves back into electrical signals. These antenna elements may be arranged in one or more antenna panels. Antenna 1324 may have omnidirectional, directional, or combinations thereof antenna panels to achieve beamforming and multiple-input multiple-output communication. Antenna 1324 may include a microstrip antenna, a printed antenna fabricated on the surface of one or more printed circuit boards, a patch antenna, a phased array antenna, etc. Antenna 1324 may have one or more panels designed for a specific frequency band included in FR1 or FR2.

[0118] User interface circuitry 1316 includes various input / output (I / O) devices designed to enable a user to interact with UE 1300. User interface 1316 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual components for accepting input, particularly one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, or a headset. Output device circuitry includes any physical or virtual components for displaying or otherwise transmitting information, such as sensor readings, actuator positions, or other similar information. Output device circuitry may include any number or combination of audio or visual displays, particularly one or more simple visual outputs / indicators (e.g., binary status indicators such as light-emitting diodes (LEDs) and multi-character visual outputs), or more complex outputs (e.g., display devices or touchscreens such as liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.)), wherein the output of characters, graphics, and multimedia objects is generated or produced by the operation of UE 1300.

[0119] Sensor 1320 may include a device, module, or subsystem intended to detect events or changes in its environment and transmit information (sensor data) about the detected events to another device, module, subsystem, etc. Examples of such sensors include, in particular, inertial measurement units, which include accelerometers; gyroscopes or magnetometers; microelectromechanical systems or nanoelectromechanical systems including: triaxial accelerometers, triaxial gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless apertures); light detection and ranging sensors; proximity sensors (e.g., infrared radiation detectors, etc.); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other similar audio capture devices; and so on.

[0120] The driving circuitry 1322 may include software and hardware elements that operate to control a specific device embedded in, attached to, or otherwise communicatively coupled to the UE 1300. The driving circuitry 1322 may include various drivers that allow other components to interact with or control various input / output (I / O) devices that may exist within or be connected to the UE 1300. For example, the driving circuitry 1322 may include a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to a touchscreen interface, a sensor driver for obtaining sensor readings from and controlling and allowing access to the sensor circuitry 1320, a driver for obtaining actuator positioning of an electromechanical component or controlling and allowing access to an electromechanical component, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0121] The PMIC 1324 manages the power supplied to various components of the UE 1300. Specifically, relative to the processor 1304, the PMIC 1324 can control power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0122] In some implementations, the PMIC 1324 may control or otherwise become part of various power-saving mechanisms of the UE 1300. For example, if the platform UE is in the RRC_Connected state, where it remains connected to the RAN node as it anticipates receiving traffic soon, then after a period of inactivity, the platform UE may enter a state known as Discontinuous Receive Mode (DRX). During this state, the UE 1300 may power down for short intervals, thus saving power. If there is no data traffic activity during an extended period, the UE 1300 may transition to the RRC_Idle state, where the UE disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The UE 1300 enters a very low-power state, and the UE performs paging, where it periodically wakes up again to listen to the network, and then power down again. The UE 1300 may not receive data in this state; to receive data, the UE must transition back to the RRC_Connected state. An additional power-saving mode renders the device unusable for a period exceeding the paging interval (from seconds to hours). During this time, the device is completely unconnected to the network and may be completely powered off. Any data transmitted during this period will incur significant latency, which is assumed to be acceptable.

[0123] Battery 1328 can power UE 1300, but in some examples, UE 1300 may be installed and deployed in a fixed location and may have a power source coupled to the power grid. Battery 1328 may be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, battery 1328 may be a typical lead-acid automotive battery.

[0124] Figure 14 An example of a gNB 1400 according to some implementation schemes is shown. The gNB node 1400 can be similar to... Figure 1 The base stations 144 and 146 are basically interchangeable with them.

[0125] The gNB 1400 may include a processor 1404, an RF interface circuit 1408, a core network (CN) interface circuit 1412, and a memory / storage device circuit 1416.

[0126] The components of gNB 1400 can be coupled to various other components via one or more interconnects 1428.

[0127] The processor 1404, RF interface circuit 1408, memory / storage device circuit 1416 (including communication protocol stack 1410), antenna 1424, and interconnect 1428 can be similar to those relative to... Figure 12 Similar named elements are shown and described.

[0128] The CN interface circuit 1412 provides connectivity to a core network, such as a 4th generation (5GC) core network using a 4GC-compatible network interface protocol (e.g., Carrier Ethernet) or some other suitable protocol. Network connectivity can be provided to / from the gNB 1400 via fiber optic or wireless backhaul. The CN interface circuit 1412 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 1412 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0129] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0130] For one or more embodiments, at least one component of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the Embodiments section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more examples below. Similarly, circuitry associated with the UE, base station, network element, etc., described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more embodiments described in the Embodiments section below.

[0131] Example

[0132] Additional example implementations are provided in the following sections.

[0133] Example 1 includes a method implemented by a UE, the method comprising: detecting a set of PUSCH opportunities within a configuration grant cycle; associating a first HARQ PID setting with a first PUSCH opportunity in a first subset of the set of PUSCH opportunities, the first HARQ PID setting being configured by a base station; and selecting a second HARQ PID setting for a second PUSCH opportunity in a second subset of the set of PUSCH opportunities.

[0134] Example 2 includes the method according to Example 1, wherein the first subset is configured by the network, and wherein the second subset is configured by the network.

[0135] Example 3 includes the method according to Example 1 or 2, wherein the first subset is fixed by a specification, and wherein the second subset is fixed by a specification.

[0136] Example 4 includes the method according to any one of Examples 1 to 3, wherein the method further includes: using resources allocated for PUSCH opportunities in the first subset to send a TB containing data from a set of LCHs; determining, based on the sending, that the buffer of the set of LCHs is empty; detecting a standby PUSCH opportunity from the set of PUSCH opportunities; and associating the standby PUSCH opportunity with a second subset of the set of PUSCH opportunities, wherein the standby PUSCH opportunity is the second PUSCH opportunity.

[0137] Example 5 includes the method according to any one of Examples 1 to 4, wherein resources are allocated to the set of PUSCH opportunities based on CG or based on multiple PUSCH DG.

[0138] Example 6 includes the method according to any one of Examples 1 to 5, wherein the first HARQ PID setting is a static configuration performed by the base station to enable the UE to perform a new transmission.

[0139] Example 7 includes the method according to any one of Examples 1 to 6, wherein selecting the second HARQ PID includes selecting the second HARQ PID from a pool of allowed HARQ PIDs, wherein the UE is configured by the base station with the pool of allowed HARQ PIDs.

[0140] Example 8 includes the method according to Example 7, wherein the UE is configured by the base station with the pool of allowed HARQ PIDs using RRC parameters.

[0141] Example 9 includes the method according to any one of Examples 1 to 8, wherein resources are allocated to the set of PUSCH opportunities based on dynamic grants (DG) allocated in downlink control information (DCI), and wherein the DCI further indicates whether the UE uses fixed allocation or dynamic allocation.

[0142] Example 10 includes the method according to Example 1, wherein the UE uses a fixed partition, and wherein the number of PUSCH opportunities in the first CG cycle is different from the number of PUSCH opportunities in the second CG cycle.

[0143] Example 11 includes the method according to Example 1, wherein the UE is configured to use fixed partitioning or dynamic partitioning for two or more consecutive cycles.

[0144] Example 12 includes one or more computer-readable media having a sequence of instructions stored thereon, which, when executed, causes a processor to perform operations including or related to the methods described in Examples 1 to 11.

[0145] Example 13 includes an apparatus comprising a memory; and processing circuitry coupled to the memory to perform one or more elements of the methods described in or related to Examples 1 to 11.

[0146] Example 14 includes a UE comprising: a memory; and processing circuitry coupled to the memory to: detect a set of PUSCH opportunities; associate a first HARQ PID setting with a first PUSCH opportunity in a first subset of the set of PUSCH opportunities, the first HARQ PID setting being configured by a base station; and identify a second PUSCH opportunity in a second subset of the set of PUSCH opportunities, a second HARQ PID setting for the second PUSCH opportunity being selectable by the UE.

[0147] Example 15 includes the UE according to Example 14, wherein the processing circuitry is further configured to: send an indication to the base station associated with the second PUSCH, wherein the indication includes whether the UE will use the second PUSCH opportunity for a purpose different from that of the first PUSCH opportunity; an identifier of the second PUSCH opportunity, or a corresponding HARQ PID for each PUSCH opportunity in the second subset including the second PUSCH opportunity.

[0148] Example 16 includes the UE according to Example 14 or 15, wherein the indication is transmitted via UCI, CG-UCI or MAC CE.

[0149] Example 17 includes a UE according to Example 14 or 15, wherein the indication is sent using CG-UCI, wherein the UE sends the CG-UCI at a first PUSCH opportunity in the set of PUSCH opportunities, and wherein the CG-UCI indicates the corresponding HARQ PID for each PUSCH opportunity in the set of PUSCH opportunities divided into the first subset and the second subset.

[0150] Example 18 includes a UE according to Example 14 or 15, wherein the indication is sent using CG-UCI, and wherein the CG-UCI indicates that the UE will use or skip using any PUSCH resources associated with the second subset.

[0151] Example 19 includes a UE according to Example 14 or 15, wherein the indication is sent using CG-UCI, wherein the UE sends the CG-UCI at the second PUSCH opportunity, and wherein the CG-UCI indicates the HARQ ID for the second PUSCH opportunity.

[0152] Example 20 includes a UE according to any one of Examples 14 to 19, wherein the set of PUSCH opportunities is divided into a first subset and a second subset based on a fixed partition, and wherein the UE is configured not to send CG-UCI in any PUSCH opportunity in the first subset that includes the first PUSCH opportunity.

[0153] Example 21 includes one or more computer-readable media having a sequence of instructions stored thereon, which, when executed, causes a processor to perform operations including or relating to the steps described in Examples 14 to 19.

[0154] Example 22 includes a method performed by a device to perform one or more elements of the steps described in or related to Examples 14 to 19.

[0155] Example 23 includes one or more non-transitory computer-readable media, the one or more non-transitory computer-readable media including instructions stored thereon, which, when executed by one or more processors, cause the UE to: detect a set of PUSCH opportunities within a configuration grant cycle; associate a first Hybrid Automatic Repeat Request (HARQ) PID setting with a first PUSCH opportunity in a first subset of the set of PUSCH opportunities; and select a second HARQ PID setting for the second PUSCH opportunity based on the intended purpose of a second PUSCH opportunity in a second subset of the set of PUSCH opportunities.

[0156] Example 24 includes one or more non-transitory computer-readable media according to Example 23, wherein the UE selects the second HARQ PID setting based on the same HARQ PID that is an earlier PUSCH opportunity in the CG cycle, and wherein the intended purpose is to repeatedly transmit data blocks transmitted at the earlier PUSCH opportunity.

[0157] Example 25 includes one or more non-transitory computer-readable media according to Example 23, wherein the UE selects the second HARQ PID setting for the PUSCH opportunities in the selected second subset based on the same HARQ PID that is an earlier PUSCH opportunity, wherein a CG timer associated with the same HARQ PID is running, and wherein the intended purpose is to retransmit the data block sent at the earlier PUSCH opportunity.

[0158] Example 26 includes one or more non-transitory computer-readable media according to Example 23, wherein the UE selects the second HARQ PID setting based on the same HARQ PID of an earlier PUSCH opportunity, wherein the CG timer associated with the same HARQ PID is not running, and wherein the instruction is executed by one or more processors, and wherein the intended purpose is to send a data block at the second PUSCH opportunity for an alternative purpose other than sending a data block at the first PUSCH opportunity.

[0159] Example 27 includes one or more non-transitory computer-readable media according to Example 23, wherein the UE selects the second HARQ PID setting based on the same HARQ PID that is an earlier PUSCH opportunity, and wherein the intended purpose is to autonomously send a de-prioritized MAC PDU.

[0160] Example 28 includes one or more non-transitory computer-readable media according to Example 23, wherein the UE selects the second HARQ PID for the PUSCH opportunity based on the MAC PDU with the highest priority LCH.

[0161] Example 29 includes an apparatus comprising a memory; and processing circuitry coupled to the memory to perform one or more elements of the methods described in or related to Examples 23 to 28.

[0162] Example 30 includes a method performed by a device to perform one or more elements of the steps described in or related to Examples 23 to 28.

[0163] Example 31 includes a base station comprising: one or more processors; a communication interface; radio frequency (RF) interface circuitry; and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the base station to: send a message to a UE using a multi-PUSCH CG regarding the purpose of an alternate PUSCH opportunity in a set of PUSCH opportunities; receive an uplink transmission from the UE, the uplink transmission being transmitted using resources allocated by the CG; and perform HARQ for the uplink transmission, the HARQ PID being selected by the UE.

[0164] Example 32 includes a base station according to Example 31, wherein the message includes a first indication of identifying the spare PUSCH and a second indication of skipping the identified spare PUSCH.

[0165] Example 33 includes a base station according to Example 31, wherein the message includes a first indication to use the spare PUSCH and a second indication to use a dummy MAC PDU when the LCH buffer is empty.

[0166] Example 34 includes a base station according to Example 31, wherein the message includes a first indication of a HARQ PID for selecting the standby PUSCH opportunity.

[0167] Example 35 includes a base station according to Example 31, wherein the message includes a MAC CE or DCI, and wherein the message includes an indication for the UE to change its behavior regarding the standby PUSCH opportunity.

[0168] Example 36 includes one or more computer-readable media having a sequence of instructions stored thereon, which, when executed, causes a processor to perform operations including or relating to the steps described in or related to Examples 31 to 35.

[0169] Example 37 includes a method performed by a device to perform one or more elements of the steps described in or related to Examples 31 to 35.

[0170] Unless otherwise expressly stated, any of the embodiments described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. In view of the teachings above, modifications and variations are possible, or modifications and variations may be obtained from the practice of various embodiments.

[0171] Although the above embodiments have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. It is intended that the following claims be construed as encompassing all such variations and modifications.

Claims

1. A method implemented by a user equipment (UE), the method comprising: detecting a set of physical uplink shared channel (PUSCH) opportunities within a configured grant cycle; associating a first hybrid automatic repeat request (HARQ) process identifier (PID) setting with a first PUSCH opportunity in a first subset of the set of PUSCH opportunities, the first HARQ PID setting configured by a base station; and selecting a second HARQ PID setting for a second PUSCH opportunity in a second subset of the set of PUSCH opportunities.

2. The method of claim 1, wherein the first subset is configured by a network, and wherein the second subset is configured by the network.

3. The method of claim 1, wherein the first subset is fixed by specification, and wherein the second subset is fixed by specification.

4. The method of claim 1, wherein the method further comprises: transmitting a transport block (TB) containing data from a set of logical channels (LCHs) using resources allocated for a PUSCH opportunity in the first subset; determining that buffers for the set of LCHs are empty based on the transmitting; detecting a backup PUSCH opportunity from the set of PUSCH opportunities; and associating the backup PUSCH opportunity with the second subset of the set of PUSCH opportunities, wherein the backup PUSCH opportunity is the second PUSCH opportunity.

5. The method of claim 1, wherein resources are allocated for the set of PUSCH opportunities based on configured grants (CGs) or multi-PUSCH dynamic grants (DGs).

6. The method of claim 1, wherein the first HARQ PID setting is statically configured by the base station to enable the UE to perform a new transmission.

7. The method of claim 1, wherein selecting the second HARQ PID comprises selecting the second HARQ PID from a pool of allowed HARQ PIDs, wherein the UE is configured by the base station with the pool of allowed HARQ PIDs.

8. The method of claim 1, wherein resources are allocated for the set of PUSCH opportunities based on dynamic grants (DGs) allocated in downlink control information (DCI), and wherein the DCI further indicates whether the UE is to use a fixed partitioning or a dynamic partitioning.

9. The method of claim 1, wherein the UE uses a fixed partitioning, and wherein a number of PUSCH opportunities in a first CG cycle is different than a number of PUSCH opportunities in a second CG cycle.

10. A user equipment (UE), comprising: a memory; processing circuitry coupled with the memory to: detect a set of physical uplink shared channel (PUSCH) opportunities; associate a first hybrid automatic repeat request (HARQ) process identifier (PID) setting with a first physical uplink shared channel (PUSCH) occasion in a first subset of the set of PUSCH occasions, the first HARQ PID setting configured by a base station; and identify a second PUSCH occasion in a second subset of the set of PUSCH occasions for which a second HARQ PID setting for the second PUSCH occasion can be selected by the UE.

11. The UE of claim 10, wherein the processing circuitry is further to: transmit an indication associated with the second PUSCH to a base station, wherein the indication comprises whether the UE will use the second PUSCH occasion for a different purpose than the first PUSCH occasion, an identification of the second PUSCH occasion, or a respective HARQ PID for each PUSCH occasion in the second subset comprising the second PUSCH occasion.

12. The UE of claim 11, wherein the indication is transmitted using CG uplink control information (CG-UCI), wherein the UE transmits the CG-UCI at a first PUSCH occasion in the set of PUSCH occasions, and wherein the CG-UCI indicates the respective HARQ PID for each PUSCH occasion in the set of PUSCH occasions divided into the first subset and the second subset.

13. The UE of claim 11, wherein the indication is transmitted using CG-UCI, and wherein the CG-UCI indicates that the UE will use or skip using any PUSCH resources associated with the second subset.

14. The UE of claim 11, wherein the indication is transmitted using CG-UCI, wherein the UE transmits the CG-UCI at the second PUSCH occasion, and wherein the CG-UCI indicates a HARQ ID for the second PUSCH occasion.

15. The UE of claim 10, wherein the set of PUSCH occasions is divided into the first subset and the second subset based on a fixed division, and wherein the UE is configured to not transmit CG-UCI in any PUSCH occasion in the first subset comprising the first PUSCH occasion.

16. One or more non-transitory computer-readable media comprising instructions stored thereon that, when executed by one or more processors, cause a user equipment (UE) to: detect a set of physical uplink shared channel (PUSCH) occasions within a configured grant cycle; associate a first hybrid automatic repeat request (HARQ) process identifier (PID) setting with a first PUSCH occasion in a first subset of the set of PUSCH occasions; and select a second HARQ PID setting for a second PUSCH occasion in a second subset of the set of PUSCH occasions based on an intended purpose of the second PUSCH occasion.

17. The one or more non-transitory computer-readable media of claim 16, wherein the UE selects the second HARQ PID setting based on a same HARQ PID of an earlier PUSCH occasion in the CG cycle, and wherein the intended purpose is to repeat a data block transmitted at the earlier PUSCH occasion.

18. The one or more non-transitory computer-readable media of claim 16, wherein the UE selects the second HARQ PID setting for the PUSCH occasion in the selected second subset based on a same HARQ PID of an earlier PUSCH occasion, wherein a CG timer associated with the same HARQ PID is running, and wherein the intended purpose is to retransmit a data block transmitted at the earlier PUSCH occasion.

19. The one or more non-transitory computer-readable media of claim 16, wherein the UE selects the second HARQ PID setting based on a same HARQ PID of an earlier PUSCH occasion, wherein a CG timer associated with the same HARQ PID is not running, and wherein the instructions, when executed by one or more processors, and wherein the intended purpose is to transmit a data block at the second PUSCH occasion for an alternative purpose other than transmitting a data block at the first PUSCH occasion.

20. The one or more non-transitory computer-readable media of claim 16, wherein the UE selects the second HARQ PID setting based on a same HARQ PID of an earlier PUSCH occasion, and wherein the intended purpose is to autonomously transmit a deprioritized medium access control protocol data unit (MAC PDU).

21. The one or more non-transitory computer-readable media of claim 16, wherein the UE selects the second HARQ PID for the PUSCH occasion based on a MAC PDU having a highest priority logical channel (LCH).

22. A base station comprising: one or more processors; a communication interface; radio frequency (RF) interface circuitry; and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the base station to: transmit, to a user equipment (UE), a message regarding a purpose of a spare PUSCH occasion in a set of PUSCH occasions using a configured grant (CG) for a physical shared channel (PUSCH); receive an uplink transmission from the UE, the uplink transmission being transmitted using resources allocated by the CG; and perform a hybrid automatic repeat procedure (HARQ) for the uplink transmission, a HARQ process identifier (PID) setting being selected by the UE. ​ ​ 23. The base station of claim 22, wherein the message comprises a first indication of an identification of the backup PUSCH and a second indication to skip the identified backup PUSCH.

24. The base station of claim 22, wherein the message comprises a first indication to use the backup PUSCH and a second indication to use a dummy medium access protocol data unit (MAC PDU) in case a buffer of a logical channel (LCH) is empty.

25. The base station of claim 22, wherein the message comprises a first indication of a selection of a hybrid automatic repeat request process identifier (HARQ PID) for the backup PUSCH opportunity.