Patent Description:
In <NUM>rd Generation Partnership Project (3GPP) Release <NUM>, the first release of the <NUM> system (5GS) was developed. This is a new generation's radio access technology intended to serve use cases such as enhanced mobile broadband (eMBB), ultra-reliable and low latency communication (URLLC) and Massive Machine Type Communications (mMTC). <NUM> includes the New Radio (NR) access stratum interface and the <NUM> Core Network (5GC). The NR physical and higher layers are reusing parts of the Long Term Evolution (LTE) specification, and to that add needed components when motivated by the new use cases.

In Release <NUM>, 3GPP started the work to prepare NR for operation in a Non-Terrestrial Network (NTN). The work was performed within the study item "NR to support Non-Terrestrial Networks" and resulted in 3GPP TR <NUM>. In Release <NUM>, the work to prepare NR for operation in an NTN network continues with the study item "Solutions for NR to support Non-Terrestrial Network". See, RP-<NUM>, Study on solutions evaluation for NR to support non-terrestrial Network.

A satellite radio access network usually includes the following components:.

Two popular architectures are the bent pipe transponder and the regenerative transponder architectures. In the first case, the base station is located on earth behind the gateway, and the satellite operates as a repeater forwarding the feeder link signal to the service link, and vice versa. In the second case, the satellite carries the base station and the service link connects it to the earth-based core network.

Depending on the orbit altitude, a satellite may be categorized as low earth orbit (LEO), medium earth orbit (MEO), or geostationary earth orbit (GEO) satellite.

A communication satellite typically generates several beams over a given area. The footprint of a beam is usually in an elliptic shape, which has been traditionally considered as a cell. The footprint of a beam is also often referred to as a spotbeam. The spotbeam may move over the earth surface with the satellite movement or may be earth fixed with some beam pointing mechanism used by the satellite to compensate for its motion. The size of a spotbeam depends on the system design, which may range from tens of kilometers to a few thousands of kilometers.

Hybrid automatic repeat request (HARQ) protocol is one of the most important features in NR. Together with link adaptation through channel state information (CSI) feedback and HARQ acknowledgement (HARQ ACK)/HARQ Negative Acknowledgement (HARQ NACK), HARQ enables efficient, reliable and low delay data transmission in NR.

Existing HARQ procedures at the physical layer (PHY) and Medium Access Control (MAC) layer have been designed for terrestrial networks where the Return Trip Time (RTT) propagation delay is usually restricted to within <NUM>. With HARQ protocol, a transmitter needs to wait for the feedback from the receiver before sending new data. In case of a HARQ NACK, the transmitter may need to resend the data packet. Otherwise, it may send new data. This stop-and-wait (SAW) procedure introduces inherent latency to the communication protocol, which may reduce the link throughput. To alleviate this issue, existing HARQ procedure allows activating multiple HARQ processes at the transmitter. That is, the transmitter may initiate multiple transmissions in parallel without having to wait for a HARQ completion. For example, with <NUM> HARQ processes in NR downlink (DL), the gNodeB (gNB) may initiate up to <NUM> new data transmissions without waiting for an HARQ ACK for the first packet transmission. Note that there are sufficient number of HARQ processes for terrestrial networks where the propagation delay is typically less than <NUM>.

<FIG> illustrates HARQ protocol. As illustrated, the various delays associated with the HARQ procedure may include:.

To avoid HARQ stalling, the minimum required number of HARQ processes is ceil((2Tp+T1+T2)/Ts) where Ts refers to the slot duration in NR.

Existing HARQ procedures in NR have largely been designed for terrestrial networks where the propagation delay is typically limited to <NUM>. We now highlight the main issues with existing HARQ protocol amid large propagation delays.

The existing HARQ mechanism may not be feasible when the propagation delay is much larger than that supported by the allowed number of HARQ processes. For example, consider the scenario where NR DL is to be adopted for satellite communications. For the GEO case, the RTT propagation delay can be around <NUM>. With <NUM> HARQ processes supported in NR and with <NUM> slot duration, the available peak throughput as a percentage of the total channel capacity is very low. Table <NUM> summarizes the available peak throughput for a UE for LEO, MEO and GEO satellites.

Without a sufficient number of HARQ processes, the sheer magnitude of the propagation delay may render closed-loop HARQ communication impractical.

The number of HARQ processes supported by the existing HARQ protocol is not sufficient to absorb the potentially large propagation delays in non-terrestrial networks. For example, Table <NUM> demonstrates that a substantial increase in the existing number of HARQ processes is required for operating HARQ amid large propagation delays. Unfortunately, Rel-<NUM> NR supports a maximum of <NUM> HARQ processes in UL/DL, and it is challenging to support a greater number of HARQ processes (especially at the UE) for at least the following reasons.

In short, the existing (PHY/MAC) HARQ mechanism is ill-suited to non-terrestrial networks with large propagation delays. Moreover, there is no existing signaling mechanism for disabling HARQ at the PHY/MAC layers.

In order to adapt HARQ to non-terrestrial networks, one solution is to semi-statically enable/disable HARQ feedback. To this end, the following agreements were made in RAN2#<NUM>:.

According to the above agreement, there is no feedback for transmission if HARQ is disabled. Furthermore, according to the above agreement, a UE can be configured with a mixture of both feedback disabled HARQ processes and feedback enabled HARQ processes as the configuration is on a per UE and per HARQ process basis.

In NR, when receiving a Physical Downlink Shared Channel, PDSCH, in the downlink from a serving gNB at slot n, a UE feeds back a HARQ ACK at slot n+k over a PUCCH (Physical Uplink Control Channel) resource in the uplink to the gNB if the PDSCH is decoded successfully. Otherwise, the UE sends a HARQ NACK at slot n+k to the gNB to indicate that the PDSCH is not decoded successfully.

For DCI format <NUM>-<NUM>, k is indicated by a <NUM>-bit PDSCH-to-HARQ-timing-indicator field. For DCI format <NUM>-<NUM>, kis indicated either by a <NUM>-bit PDSCH-to-HARQ-timing-indicator field, if present, or by higher layers through Radio Resource Control (RRC) signaling.

If code block group (CBG) transmission is configured, a HARQ ACK/NACK for each CBG in a transport block (TB) is reported instead.

In case of carrier aggregation (CA) with multiple carriers and/or Time Division Duplex (TDD) operation, multiple aggregated HARQ ACK/HARQ NACK bits need to be sent in a single Physical Uplink Control Channel (PUCCH).

In NR, up to four PUCCH resource sets can be configured to a UE. A PUCCH resource set with pucch-ResourceSetId=<NUM> can have up to <NUM> PUCCH resources while for PUCCH resource sets with pucch-ResourceSetId=<NUM> to <NUM>, each set can have up to <NUM> PUCCH resources. A UE determines the PUCCH resource set in a slot based on the number of aggregated UCI (Uplink Control Information) bits to be sent in the slot. The UCI bits consist of HARQ ACK/HARQ NACK, scheduling request (SR), and channel state information (CSI) bits.

If the UE transmits OUCI UCI information bits, the UE determines a PUCCH resource set to be.

For a PUCCH transmission with HARQ-ACK information, a UE determines a PUCCH resource after determining a PUCCH resource set. The PUCCH resource determination is based on a <NUM>-bit PUCCH resource indicator (PRI) field in DCI format 1_0 or DCI format 1_1.

If more than one DCI format 1_0 or 1_1 are received in the case of Carrier Aggregation (CA) and/or TDD, the PUCCH resource determination is based on a PUCCH resource indicator (PRI) field in the last DCI format 1_0 or DCI format 1_1 among the multiple received DCI format 1_0 or DCI format 1_1 that the UE detects.

NR Rel-<NUM> supports two types of HARQ codebooks, i.e., semi-static (type <NUM>) and dynamic (type <NUM>) codebooks, for HARQ ACK/HARQ NACK multiplexing for multiple PDSCHs of one or more component carriers (CCs). A UE can be configured to use either one of the codebooks for HARQ ACK/HARQ NACK feedback.

HARQ codebook (CB) size in time (DL association set) is determined based on the configured set of HARQ-ACK timings K1, and semi-static configured TDD pattern in case of TDD. For a Physical Downlink Control Channel (PDCCH) received in slot n for a PDSCH, K1 is signaled in the PDCCH and indicates that the HARQ ACK/HARQ NACK feedback for the PDSCH occurs in slot n+K1.

<FIG> illustrates an example of a Type <NUM> HARQ codebook for a TDD pattern with a set of K1 from <NUM> to <NUM> and a configured time-domain resource allocation table or the pdsch-TimeDomainAllocationList without non-overlapping PDSCH TDRA allocation, i.e., only one PDSCH can be scheduled in a slot. In this case, there are <NUM> entries in the HARQ codebook, one for each K1 value. For slots without PDSCH transmission or for slots where there is no PDSCH detected, the corresponding entry in the codebook is filled with NACK.

If UE supports reception of more than one unicast PDSCH per slot, one HARQ codebook entry for each non-overlapping time-domain resource allocation in the pdsch-symbolAllocation table is reserved per slot; otherwise one HARQ entry is reserved per slot.

Unlike Type <NUM> HARQ codebook, the size of type <NUM> HARQ codebook changes dynamically based on the number of DCIs scheduling PDSCH receptions or Semi Persistent Scheduling (SPS) PDSCH release that are associated with a same PUCCH resource for HARQ ACK/HARQ NACK feedback. The number of DCIs can be derived based a counter Downlink Assignment Indicator (DAI) field in the DCIs and in case of DCI format <NUM>-<NUM>, also a total DAI field if more than one serving cell are configured.

A value of the counter DAI field in DCI format 1_0 or DCI format 1_1 denotes the accumulative number of {serving cell, PDCCH monitoring occasion}-pair(s) in which PDSCH reception(s) or SPS PDSCH release associated with DCI format 1_0 or DCI format 1_1 is present, up to the current serving cell and current PDCCH monitoring occasion.

The value of the total DAI, when present, in DCI format 1_1 denotes the total number of {serving cell, PDCCH monitoring occasion}-pair(s) in which PDSCH reception(s) or SPS PDSCH release associated with DCI format 1_0 or DCI format 1_1 is present, up to the current PDCCH monitoring occasion m and is updated from PDCCH monitoring occasion to PDCCH monitoring occasion.

<FIG> illustrates an example DAI allocation. As shown, a UE is configured with <NUM> serving cells and <NUM> PDCCH monitoring occasions. Each scheduled DCI is shown via a filled box, and the corresponding counter DAI and total DAI values after each scheduled DCI are denoted as (counter DAI, total DAI). The counter DAI is updated after every scheduled DCI while total DAI is only updated every monitoring occasion. Since only <NUM> bits are allocated for either counter DAI or total DAI in DCI, the actual DAI values are wrapped round with a modulo <NUM> operation. A UE can figure out the actual number of DCIs transmitted even though some DCIs are undetected, if the undetected consecutive DCIs are smaller than <NUM>.

For DCI format <NUM>-<NUM>, the DAI field is only present when the Type-<NUM> HARQ-ACK is used and bitwidths of <NUM>, <NUM>, or <NUM> bits are possible. For DCI format <NUM>-<NUM>, the DAI field is composed of <NUM> bits.

The DAI field may be present in DCI format 0_1 for handling of HARQ codebooks in case of UCI transmitted on PUSCH.

The size of the codebook for NR Type-<NUM> HARQ-ACK is fixed and is determined by the total number of HARQ processes and the number of configured cells. This codebook is used to provide feedback if the UE is configured with pdsch-HARQ-ACK-OneShotFeedback-r16 by higher layers via RRC signaling. The purpose of the Type-<NUM> HARQ-ACK codebook is to be able to provide feedback in one shot for all HARQ processes across all activated cells.

The feedback can be requested in DL DCI format 1_1. In response to the trigger, the UE reports the HARQ-ACK feedback for all DL HARQ processes. The format of the feedback, either CBG-based HARQ-ACK or TB-based HARQ-ACK, can be configured to be part of the one-shot HARQ feedback for the component carriers.

Additionally, to resolve any possible ambiguity between the gNB and the UE that might be caused by possible mis-detection of PDCCH(s), the UE can be configured to report the corresponding latest New Data Indicator (NDI) value for a latest received PDSCH for that HARQ process along with the corresponding HARQ-ACK for the received PDSCH. From gNB perspective, if the NDI value matches the last transmitted value, it indicates that the reported HARQ-ACK feedback correctly corresponds to the HARQ process with pending feedback. Otherwise, the mismatch suggests that the UE is reporting an outdated feedback.

Certain previously proposed enhancements to HARQ feedback procedures for NTNs focused on handling of disabled processes for Type-<NUM> HARQ-ACK codebook. The enhancements proposed not including information corresponding to HARQ processes that are disabled in the Type-<NUM> codebook and including not incrementing the downlink assignment index values for such HARQ processes. The true DAI values can be transmitted in the DAI field when a disabled HARQ process is scheduled or the DAI field can be reserved. The enhancements also included the possibility of not including the DAI field in the DCI.

The enhancements further allowed disabled HARQ processes in the Type-<NUM> HARQ codebook to be set to NACKs.

Additionally, with the UE being configured with both feedback disabled HARQ processes and feedback enabled HARQ processes, UE procedures related to Type-<NUM> HARQ codebook is still undefined. Furthermore, the efficient use of Type-<NUM> codebook along with a Type <NUM> or a Type <NUM> codebook and with other features such as the use of DCI format 1_2 or the indication of non-numerical values for the delay between a DCI scheduling PDSCH on the downlink and the HARQ feedback on the uplink have not been addressed. 3GPP Tdoc R2-<NUM> discusses solutions for NR to support non-terrestrial networks (NTN). 3GPP TR <NUM> V16. <NUM> studies a set of necessary features/adaptations enabling the operation of the New Radio (NR) protocol in non-terrestrial networks for 3GPP Release <NUM> with a priority on satellite access. Access network based on Unmanned Aerial System (UAS) including High Altitude Platform Station (HAPS) could be considered as a special case of non-terrestrial access with lower delay/Doppler value and variation rate. 3GPP TS <NUM> V16. <NUM> defines the physical layer procedures for NR and in particular defines HARQ codebook determination.

All references to alan/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise.

In some embodiments, a more general term "network node" may be used and may correspond to any type of radio network node or any network node, which communicates with a UE (directly or via another node) and/or with another network node. Examples of network nodes are NodeB, Master NodeB (MeNB), a network node belonging to Master Cell Group (MCG) or Secondary Cell Group (SCG), base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB (eNB), gNodeB (gNB), network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), core network node (e.g. Mobile Switching Center (MSC), Mobility Management Entity (MME), etc.), Operations & Maintenance (O&M), Operations Support System (OSS), Self Organizing Network (SON), positioning node (e.g. Evolved-Serving Mobile Location Centre (E-SMLC)), Minimization of Drive Test (MDT), test equipment (physical node or software), etc..

In some embodiments, the non-limiting term user equipment (UE) or wireless device may be used and may refer to any type of wireless device communicating with a network node and/or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine (M2M) communication, Personal Digital Assistant (PDA), Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), Unified Serial Bus (USB) dongles, UE category M1, UE category M2, Proximity Services UE (ProSe UE), Vehicle-to-Vehicle UE (V2V UE), Vehicle-to-Anything (V2X UE), etc..

Additionally, terminologies such as base station/gNB and UE should be considered non-limiting and do in particular not imply a certain hierarchical relation between the two; in general, "gNodeB" could be considered as device <NUM> and "UE" could be considered as device <NUM> and these two devices communicate with each other over some radio channel. And in the following the transmitter or receiver could be either gNB, or UE.

In the below embodiments, the term K1 is sometimes used to represent the PDSCH-to-HARQ_feedback timing indicator and the terms "non-numerical" and "inapplicable" are used interchangeably to represent a value of K1 that is not to be used by the UE.

According to certain embodiments, the methods, systems, and techniques disclosed herein may include some or all of the following features:.

According to certain embodiments, the methods, systems, and techniques may use non-numerical values of K1 to efficiently handle HARQ feedback for both feedback enabled and feedback disabled HARQ processes.

According to certain embodiments, the methods, systems, and techniques may provide a novel use of existing functionality to reduce DCI overhead:.

Since the Type-<NUM> HARQ codebook includes feedback for all HARQ processes, the size of part of the HARQ codebook that is occupied by HARQ processes that are enabled and the size of the part of the codebook that is occupied by HARQ processes that are disabled is known to the UE based on configuration information from higher layers. Considering that there is no information that needs to be sent for the disabled HARQ processes, according to the invention the Type-<NUM> HARQ codebook only includes feedback for HARQ processes that are enabled. In many scenarios where NTNs may operate with very few HARQ processes enabled, this can result in a significant reduction of overhead when Type-<NUM> HARQ codebook is used.

An example showing changes to the pseudo-code that may achieve the features and operations per this embodiment are given below:
<IMG>
<IMG>
<IMG>
<IMG>
<IMG>
<IMG>
<IMG>.

These embodiments may be useful when Type <NUM> HARQ codebook is intended for primary use. The Type <NUM> HARQ codebook is configured to be of very small size.

According to certain embodiments, for example, when scheduling enabled HARQ processes, a non-numerical K1 value is indicated in the DCI which causes the UE to discard the HARQ process. HARQ feedback is then obtained by triggering feedback for the Type <NUM> HARQ codebook later. By operating in this manner, HARQ feedback overhead can be minimized in situations where the network is operating with very few HARQ processes being enabled.

When operating a Type <NUM> HARQ codebook for NTN, a UE reports HARQ-ACK information for a corresponding PDSCH reception in a HARQ-ACK codebook that the UE transmits in a slot indicated by a value of a PDSCH-to-HARQ_feedback timing indicator only if the HARQ process corresponding to the PDSCH reception is enabled.

If the UE receives a DL DCI that indicates a HARQ process that is disabled, the UE may not generate a corresponding HARQ-ACK information for the PDSCH scheduled by the DCI. In other words, the PRI and K1 fields in the DCI are ignored. If the UE reports HARQ-ACK information for the PDSCH reception corresponding to a disabled HARQ, the UE sets a value for each corresponding HARQ-ACK information bit to NACK.

According to certain embodiments, if all of the HARQ processes corresponding to scheduled PDSCHs in the DL association set are disabled, then no Type <NUM> HARQ codebook is transmitted in the PUCCH resources corresponding to the DL association set. Since the gNB is aware of the HARQ processes that have been scheduled, the gNB does not expect the UE to transmit any HARQ codebook on PUCCH, i.e., there is no misalignment between the gNB and the UE.

According to certain embodiments, HARQ processes that are enabled or disabled can be varied dynamically. This is different from the embodiments described above and is achieved, as in the previous embodiment, using the fact that the UE discards the HARQ feedback for which a non-numerical K1 value is received when configured with a Type <NUM> HARQ codebook, according to certain embodiments.

An exemplary example of such operation could be as follows. The UE operates with a Type <NUM> codebook with some fixed size as configured by higher layers. The UE may initially be configured with all HARQ processes being enabled. When scheduling PDSCH reception for the UE, if the network chooses to dynamically disable the HARQ process corresponding to the PDSCH being scheduled, the gNB can set the PDSCH-to-HARQ _feedback timing indicator value in the DCI to an inapplicable value (-<NUM>) from the values configured in dl-DataToUL-ACK by higher layers. Since no timing information is provided for this HARQ process, the UE will discard the feedback information effectively disabling the HARQ process for this particular PDSCH reception.

The reporting of the true DAI value in the DAI field when scheduled with a disabled HARQ process when operating with a Type-<NUM> HARQ codebook has been proposed as an enhancement for NTN, as described above. However, there may be some ambiguity when all HARQ processes that are currently scheduled to a UE are disabled. The UE may not be able to distinguish whether the indicated DAI value reflects some DCI scheduling a PDSCH that was missed by the UE where the scheduled PDSCH corresponds to a HARQ process that was enabled, or whether the indicated DAI value is meaningless since no scheduling with enabled HARQ processes have any outstanding feedback to be reported. Therefore, according to certain embodiments, it may be necessary to be able to signal to the UE in some instances that the DAI value should be ignored. In a particular embodiment, this is achieved using the inapplicable value for the PDSCH-to-HARQ _feedback timing indicator (referred to as the non-numerical K1 value). That is, the DAI value is ignored when the UE is scheduled a PDSCH with a non-numerical K1 value and a disabled HARQ when operating with a Type <NUM> HARQ codebook.

According to certain embodiments, DCI format 1_1 is used for enabled HARQ processes and DCI format 1_2 is used for disabled HARQ processes. In a particular embodiment, DAI and Redundancy version fields can be configured to have zero bits in DCI format 1_2 to save overhead. In a particular embodiment, the HARQ process number can also be set to zero by configuring the higher layer parameter, harq-ProcessNumberSizeForDCI-Format1-<NUM>, to <NUM> bits. Alternatively, the corresponding field can be kept in DCI to indicate the corresponding HARQ process number. The DAI field is set to zero bits by not configuring the higher layer parameter, downlinkAssignmentIndexForDCI-Format1-<NUM>. The Redundancy version is set to zero bits by configuring the higher layer parameter, numberOfBitsForRV-ForDCI-Format1-<NUM>, to be zero bits.

When a PDSCH is then scheduled using DCI format 1_2, the UE automatically assumes that Redundancy version of <NUM> is used and there is no feedback necessary for the PDSCH. Thus, existing functionality can be reused using a novel scheduling method where the enabled and disabled HARQ processes are used for scheduling with DCI formats 1_1 and 1_2 respectively, according to certain embodiments.

If the UE is configured with Type-<NUM> HARQ-ACK codebook, by using DCI 1_2 for scheduling PDSCHs with disabled HARQ processes with a <NUM> bit DAI field, the UE will not generate any HARQ codebook for the PDSCHs corresponding to disabled HARQ processes following the Rel-<NUM> procedures. By using DCI format 1_0/1_1 for PDSCHs using enabled HARQ processes, the corresponding CB would be generated and transmitted on the associated PUCCHs.

According to certain embodiments, if the UE is configured with Type-<NUM> HARQ-ACK codebook, pdsch-TimeDomainAllocationListForDCI-Format1-<NUM> can be used for scheduling PDSCHs using disabled HARQ processes which can be excluded for semi-static (Type <NUM>) HARQ codebook construction. In this sense, the Type-<NUM> HARQ codebook would not carry overhead due to PDSCHs with disabled HARQ.

<FIG> illustrates a wireless network, in accordance with some embodiments. Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in <FIG>. For simplicity, the wireless network of <FIG> only depicts network <NUM>, network nodes <NUM> and 160b, and wireless devices <NUM>. In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node <NUM> and wireless device <NUM> are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices' access to and/or use of the services provided by, or via, the wireless network.

Network node <NUM> and wireless device <NUM> comprise various components described in more detail below.

<FIG> illustrates an example network node <NUM>, according to certain embodiments.

Interface <NUM> is used in the wired or wireless communication of signalling and/or data between network node <NUM>, network <NUM>, and/or wireless devices <NUM>. Radio front end circuitry <NUM> may receive digital data that is to be sent out to other network nodes or wireless devices via a wireless connection.

<FIG> illustrates an example wireless device <NUM>. According to certain embodiments. As used herein, wireless device refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term wireless device may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. In some embodiments, a wireless device may be configured to transmit and/or receive information without direct human interaction. For instance, a wireless device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a wireless device include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE). a vehicle-mounted wireless terminal device, etc. A wireless device may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, a wireless device may represent a machine or other device that performs monitoring and/or measurements and transmits the results of such monitoring and/or measurements to another wireless device and/or a network node. The wireless device may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the wireless device may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a wireless device may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A wireless device as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a wireless device as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

Wireless device <NUM> may include multiple sets of one or more of the illustrated components for different wireless technologies supported by wireless device <NUM>, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to mention a few. These wireless technologies may be integrated into the same or different chips or set of chips as other components within wireless device <NUM>.

In certain alternative embodiments, antenna <NUM> may be separate from wireless device <NUM> and be connectable to wireless device <NUM> through an interface or port. Antenna <NUM>, interface <NUM>, and/or processing circuitry <NUM> may be configured to perform any receiving or transmitting operations described herein as being performed by a wireless device. Any information, data and/or signals may be received from a network node and/or another wireless device.

Radio front end circuitry <NUM> is connected to antenna <NUM> and processing circuitry <NUM> and is configured to condition signals communicated between antenna <NUM> and processing circuitry <NUM>. In some embodiments, wireless device <NUM> may not include separate radio front end circuitry <NUM>; rather, processing circuitry <NUM> may comprise radio front end circuitry and may be connected to antenna <NUM>. Radio front end circuitry <NUM> may receive digital data that is to be sent out to other network nodes or wireless devices via a wireless connection.

Processing circuitry <NUM> may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and/or encoded logic operable to provide, either alone or in conjunction with other wireless device <NUM> components, such as device readable medium <NUM>, wireless device <NUM> functionality.

In certain embodiments processing circuitry <NUM> of wireless device <NUM> may comprise a SOC.

In certain embodiments, some or all of the functionality described herein as being performed by a wireless device may be provided by processing circuitry <NUM> executing instructions stored on device readable medium <NUM>, which in certain embodiments may be a computer-readable storage medium. The benefits provided by such functionality are not limited to processing circuitry <NUM> alone or to other components of wireless device <NUM>, but are enjoyed by wireless device <NUM> as a whole, and/or by end users and the wireless network generally.

Processing circuitry <NUM> may be configured to perform any determining, calculating, or similar operations (e.g., certain obtaining operations) described herein as being performed by a wireless device. These operations, as performed by processing circuitry <NUM>, may include processing information obtained by processing circuitry <NUM> by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored by wireless device <NUM>, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination.

User interface equipment <NUM> may provide components that allow for a human user to interact with wireless device <NUM>. Such interaction may be of many forms, such as visual, audial, tactile, etc. User interface equipment <NUM> may be operable to produce output to the user and to allow the user to provide input to wireless device <NUM>. The type of interaction may vary depending on the type of user interface equipment <NUM> installed in wireless device <NUM>. For example, if wireless device <NUM> is a smart phone, the interaction may be via a touch screen; if wireless device <NUM> is a smart meter, the interaction may be through a screen that provides usage (e.g., the number of gallons used) or a speaker that provides an audible alert (e.g., if smoke is detected). User interface equipment <NUM> is configured to allow input of information into wireless device <NUM> and is connected to processing circuitry <NUM> to allow processing circuitry <NUM> to process the input information. User interface equipment <NUM> is also configured to allow output of information from wireless device <NUM>, and to allow processing circuitry <NUM> to output information from wireless device <NUM>. Using one or more input and output interfaces, devices, and circuits, of user interface equipment <NUM>, wireless device <NUM> may communicate with end users and/or the wireless network and allow them to benefit from the functionality described herein.

Auxiliary equipment <NUM> is operable to provide more specific functionality which may not be generally performed by wireless devices.

wireless device <NUM> may further comprise power circuitry <NUM> for delivering power from power source <NUM> to the various parts of wireless device <NUM> which need power from power source <NUM> to carry out any functionality described or indicated herein. Power circuitry <NUM> may additionally or alternatively be operable to receive power from an external power source; in which case wireless device <NUM> may be connectable to the external power source (such as an electricity outlet) via input circuitry or an interface such as an electrical power cable. Power circuitry <NUM> may perform any formatting, converting, or other modification to the power from power source <NUM> to make the power suitable for the respective components of wireless device <NUM> to which power is supplied.

UE <NUM>, as illustrated in <FIG>, is one example of a wireless device configured for communication in accordance with one or more communication standards promulgated by the <NUM>rd Generation Partnership Project (3GPP), such as 3GPP's GSM, UMTS, LTE, and/or <NUM> standards. As mentioned previously, the term wireless device and UE may be used interchangeable. Accordingly, although <FIG> is a UE, the components discussed herein are equally applicable to a wireless device, and vice-versa.

Storage medium <NUM> may allow UE <NUM> to access computer-executable instructions, application programs or the like, stored on transitory or non-transitory memory media, to offload data, or to upload data.

For example, communication subsystem <NUM> may be configured to include one or more transceivers used to communicate with one or more remote transceivers of another device capable of wireless communication such as another wireless device, UE, or base station of a radio access network (RAN) according to one or more communication protocols, such as IEEE <NUM>, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, or the like.

In some embodiments, some signaling can be affected with the use of control system <NUM> which may alternatively be used for communication between the hardware nodes <NUM> and radio units <NUM>.

<FIG> illustrates a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments.

Host computer <NUM> may be under the ownership or control of a service provider or may be operated by the service provider or on behalf of the service provider.

<FIG> illustrates a host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments.

Wireless connection <NUM> between UE <NUM> and base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the data rate, latency, and/or power consumption and thereby provide benefits such as reduced user waiting time, relaxed restriction on file size, better responsiveness, and/or extended battery lifetime.

In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which OTT connection <NUM> passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above or supplying values of other physical quantities from which software <NUM>, <NUM> may compute or estimate the monitored quantities.

<FIG> depicts a method <NUM> by a wireless device <NUM>, according to certain embodiments. At step <NUM>, the wireless device receives, from a network node <NUM>, configuration information. The configuration information enables HARQ ACK and/or HARQ NACK feedback on a per HARQ basis for a first set of HARQ processes. Each of the first set of HARQ processes is identified by a respective one of a first set of HARQ process numbers. The configuration information also disables HARQ ACK and/or HARQ NACK feedback, on a per HARQ process basis, for a second set of HARQ processes. Each of the second set of HARQ processes being identified by a respective one of a second set of HARQ process numbers. At step <NUM>, the wireless device <NUM> constructs a first HARQ codebook of a first type based on the first set of HARQ process numbers for first set of HARQ processes for which HARQ ACK and/or HARQ NACK feedback is enabled. At step <NUM>, the wireless device <NUM> sends, to the network node <NUM>, the HARQ ACK and/or HARQ NACK feedback based on the first HARQ codebook.

In a particular embodiment, the first HARQ codebook of the first type is not constructed based on the second set of HARQ processes for which HARQ ACK and/or HARQ NACK feedback is disabled.

In a particular embodiment, the first HARQ codebook comprises a TYPE <NUM> HARQ codebook, and wireless device <NUM> receives DCI that triggers Type <NUM> HARQ Feedback.

In a further particular embodiment, the TYPE <NUM> HARQ codebook is used along with a HARQ codebook of Type <NUM>.

In a particular embodiment, a PDSCH reception corresponding to a particular HARQ process for which HARQ feedback is enabled is scheduled with an indication of an inapplicable value for the PDSCH-to-HARQ_feedback timing indicator field in the DCI triggering the HARQ ACK and/or HARQ NACK feedback. The HARQ ACK and/or HARQ NACK feedback for the particular HARQ process is subsequently obtained by triggering feedback for the Type <NUM> HARQ codebook.

In a particular embodiment, based on DCI triggering HARQ ACK and/or HARQ NACK feedback, the wireless device <NUM> determines a transmission resource for sending the HARQ ACK and/or HARQ NACK feedback. The HARQ ACK and/or HARQ NACK feedback is sent to the network node using the transmission resource.

In a further particular embodiment, the resource includes a PUCCH resource for sending the HARQ ACK and/or HARQ NACK feedback, and the PUCCH resource is determined based on a PUCCH resource indicator field in the DCI triggering the HARQ feedback.

<FIG> illustrates a schematic block diagram of a virtual apparatus <NUM> in a wireless network (for example, the wireless network shown in <FIG>). The apparatus may be implemented in a wireless device or network node (e.g., wireless device <NUM> or network node <NUM> shown in <FIG>). Apparatus <NUM> is operable to carry out the example method described with reference to <FIG> and possibly any other processes or methods disclosed herein. It is also to be understood that the method of <FIG> is not necessarily carried out solely by apparatus <NUM>. At least some operations of the method can be performed by one or more other entities.

Virtual Apparatus <NUM> may comprise processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In some implementations, the processing circuitry may be used to cause receiving module <NUM>, constructing module <NUM>, sending module <NUM>, and any other suitable units of apparatus <NUM> to perform corresponding functions according one or more embodiments of the present disclosure.

According to certain embodiments, receiving module <NUM> may perform certain of the receiving functions of the apparatus <NUM>. For example, receiving module <NUM> may receive, from a network node <NUM>, configuration information. The configuration information enables HARQ ACK and/or HARQ NACK feedback on a per HARQ basis for a first set of HARQ processes. Each of the first set of HARQ processes is identified by a respective one of a first set of HARQ process numbers. The configuration information also disables HARQ ACK and/or HARQ NACK feedback, on a per HARQ process basis, for a second set of HARQ processes. Each of the second set of HARQ processes being identified by a respective one of a second set of HARQ process numbers.

According to certain embodiments, constructing module <NUM> may perform certain of the constructing functions of the apparatus <NUM>. For example, constructing module <NUM> may construct a first HARQ codebook of a first type based on the first set of HARQ process numbers for first set of HARQ processes for which HARQ ACK and/or HARQ NACK feedback is enabled.

According to certain embodiments, sending module <NUM> may perform certain of the sending functions of the apparatus <NUM>. For example, sending module <NUM> may send, to the network node, the HARQ ACK and/or HARQ NACK feedback based on the first HARQ codebook.

As used herein, the term module may have conventional meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, units, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.

<FIG> depicts a method <NUM> by a network node <NUM>, according to certain embodiments. At step <NUM>, the network node <NUM> transmits, to a wireless device <NUM>, configuration information. The configuration information enables HARQ ACK and/or HARQ NACK feedback on a per HARQ basis for a first set of HARQ processes. Each of the first set of HARQ processes is identified by a respective one of a first set of HARQ process numbers, The configuration also disables HARQ ACK and/or HARQ NACK feedback, on a per HARQ process basis, for a second set of HARQ processes. Each of the second set of HARQ processes is identified by a respective one of a second set of HARQ process numbers. At step <NUM>, the network node <NUM> receives, from the wireless device <NUM>, the HARQ ACK and/or HARQ NACK feedback based on a first HARQ codebook. The first HARQ codebook is of a first type, and the first HARQ codebook is constructed based on the first set of HARQ process numbers for the first set of HARQ processes for which HARQ ACK and/or HARQ NACK feedback is enabled.

In a particular embodiment, the first HARQ codebook is a Type <NUM> HARQ codebook, and the network node <NUM> transmits DCI that triggers Type <NUM> HARQ Feedback.

In a further particular embodiment, the Type <NUM> HARQ codebook is used along with a HARQ codebook of Type <NUM>, and a PDSCH reception corresponding to a particular HARQ process for which HARQ feedback is enabled is scheduled with an indication of an inapplicable value for the PDSCH-to-HARQ_feedback timing indicator field in the DCI triggering the HARQ ACK and/or HARQ NACK feedback. The HARQ ACK and/or HARQ NACK feedback for the particular HARQ process is subsequently obtained by triggering feedback for the Type <NUM> HARQ codebook.

In a particular embodiment, the network node <NUM> transmits, to the wireless device <NUM>, DCI triggering the HARQ ACK and/or HARQ NACK feedback. The DCI indicates a transmission resource for sending the HARQ ACK and/or HARQ NACK feedback, and the HARQ ACK and/or HARQ NACK feedback is received from the wireless device using the transmission resource.

In a particular embodiment, the resource comprises a PUCCH resource for sending by the wireless device the HARQ ACK and/or HARQ NACK feedback, and the PUCCH resource is indicated based on a PUCCH resource indicator field in the DCI triggering the HARQ feedback.

Virtual Apparatus <NUM> may comprise processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In some implementations, the processing circuitry may be used to cause transmitting module <NUM>, receiving module <NUM>, and any other suitable units of apparatus <NUM> to perform corresponding functions according one or more embodiments of the present disclosure.

According to certain embodiments, transmitting module <NUM> may perform certain of the transmitting functions of the apparatus <NUM>. For example, transmitting module <NUM> may transmits, to a wireless device <NUM>, configuration information. The configuration information enables HARQ ACK and/or HARQ NACK feedback on a per HARQ basis for a first set of HARQ processes. Each of the first set of HARQ processes is identified by a respective one of a first set of HARQ process numbers, The configuration also disables HARQ ACK and/or HARQ NACK feedback, on a per HARQ process basis, for a second set of HARQ processes. Each of the second set of HARQ processes is identified by a respective one of a second set of HARQ process numbers.

According to certain embodiments, receiving module <NUM> may perform certain of the receiving functions of the apparatus <NUM>. For example, receiving module <NUM> may receive, from the wireless device <NUM>, the HARQ ACK and/or HARQ NACK feedback based on a first HARQ codebook. The first HARQ codebook is of a first type, and the first HARQ codebook is constructed based on the first set of HARQ process numbers for the first set of HARQ processes for which HARQ ACK and/or HARQ NACK feedback is enabled.

Modifications, additions, or omissions may be made to the systems and apparatuses described herein without departing from the scope of the disclosure. The components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. Additionally, operations of the systems and apparatuses may be performed using any suitable logic comprising software, hardware, and/or other logic. As used in this document, "each" refers to each member of a set or each member of a subset of a set.

Modifications, additions, or omissions may be made to the methods described herein without departing from the scope of the disclosure. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

Claim 1:
A method by a wireless device comprising:
receiving, from a network node, configuration information, wherein the configuration information configures the wireless device to provide feedback in one shot for all HARQ processes across all activated cells, the configuration information further comprising information which:
enables Hybrid Automatic Repeat Request Acknowledgment, HARQ ACK, and/or Negative Acknowledgment, HARQ NACK, feedback on a per Hybrid Automatic Repeat Request, HARQ, basis for a first set of HARQ processes, each of the first set of HARQ processes being identified by a respective one of a first set of HARQ process numbers, and which:
disables HARQ ACK and/or HARQ NACK feedback, on a per HARQ process basis, for a second set of HARQ processes, each of the second set of HARQ processes being identified by a respective one of a second set of HARQ process numbers;
constructing a Type <NUM> HARQ codebook based on the first set of HARQ process numbers for first set of HARQ processes for which HARQ ACK and/or HARQ NACK feedback is enabled, and wherein the Type <NUM> HARQ codebook is not constructed based on the second set of HARQ processes for which HARQ ACK and/or HARQ NACK feedback is disabled;
sending, to the network node, the HARQ ACK and/or HARQ NACK feedback based on the first HARQ codebook.