Scheduling of acknowledgement

Abstract

A user equipment, UE, is configured to communicate with a network node. The UE receives a transmission and receives control information (S104) scheduling transmission of an acknowledgement of reception of the received transmission. The UE transmits (S106) the acknowledgement in accordance with the control information. The control information is of a type capable of scheduling a data transmission from the UE.

Description

[0001] SCHEDULING OF ACKNOWLEDGEMENT

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to wireless communications, and in particular, to scheduling of an acknowledgement of a transmission received by a user equipment (UE).

[0004] BACKGROUND

[0005] The Third Generation Partnership Project (3GPP) has developed and is developing standards for Fourth Generation (4G) (also referred to as Long Term Evolution (LTE)) and Fifth Generation (5G) (also referred to as New Radio (NR)) wireless communication systems. Such systems provide, among other features, broadband communication between network nodes, such as base stations, and mobile user equipments (UE), as well as communication between network nodes and between UEs. The 3GPP is also developing standards for Sixth Generation (6G) wireless communication networks.

[0006] Downlink and uplink data transmission in 5G NR

[0007] In 5GNR, downlink data is transmitted on the physical downlink shared channel (PDSCH). Associated control information informs the UE about the time-frequency resources used for the data transmission as well as other parameters necessary to process the downlink transmission. Hybrid automatic repeat request (Hybrid-ARQ, also referred to as HARQ) is supported in the downlink. Shortly after receiving the downlink data transmission the UE responds with a positive or negative acknowledgement indicating whether the data was correctly received or not.

[0008] Uplink data transmission is transmitted on the physical uplink shared channel (PUSCH). Similarly to the downlink case, the associated control information informs the UE about the time-frequency resources to use and other transmission parameters necessary. If the uplink data are not correctly received, the network node can schedule a retransmission.

[0009] Downlink control information in 5G NR

[0010] In 5GNR, Downlink control information (DCI) includes downlink scheduling assignments (downlink-related DCI), including information required for the device to be able to properly receive, demodulate, and decode downlink data transmissions on PDSCH, uplink scheduling grants (uplink-related DCI) informing the device about the resources and transport format to use for uplink data transmission on PUSCH. In addition, the downlink control signaling can also be used for special purposes such as conveying information about the symbols used for uplink and downlink in a set of slots, preemption indication, and power control.

[0011] Apart from indicating the time-frequency resources used for downlink data transmission, the downlink-related DCI may also include:

[0012] • Hybrid-ARQ related information o Hybrid ARQ process number, informing the device about the hybrid- ARQ process to use for soft combining. o Downlink assignment index (DAI), only present in the case of a dynamic hybrid- ARQ codebook is configured. o HARQ feedback timing, providing information on when the hybrid- ARQ acknowledgment should be transmitted in the uplink relative to the reception of the PDSCH.

[0013] • Physical uplink control channel (PUCCH)-related information o PUCCH resource indicator, used to select the PUCCH resource from a set of configured resources.

[0014] Only some fields related to DCI have been listed above. It will be appreciated that DCI may include additional fields.

[0015] Uplink control information in 5G NR

[0016] In 5GNR, there is a need for uplink Layer 1 / Layer 2 (L1 / L2) control signaling to support data transmission on downlink and uplink transport channels. Uplink L1 / L2 control signaling in 5G NR includes:

[0017] • Hybrid-ARQ acknowledgments for downlink transport blocks received by the UE;

[0018] • Channel-state information (CSI) related to the downlink channel conditions, used to assist downlink scheduling, including multi-antenna and beamforming schemes; and

[0019] • Scheduling requests, indicating that a device needs uplink resources for data transmission.

[0020] The physical uplink control channel (PUCCH) is the basis for the transmission of uplink control. In principle, the uplink control information (UCI) could be transmitted on the PUCCH regardless of whether the device is transmitting data on the PUSCH simultaneously. However, especially if the uplink resources for the PUSCH and the PUCCH are on the same carrier (or, to be more precise, use the same power amplifier) but widely separated in the frequency domain, the UE may need a relatively large power backoff to fulfill the spectral emission requirements with a corresponding impact on the uplink coverage. Hence, NR supports UCI on PUSCH as a way of handling simultaneous transmission of data and control. If the UE is simultaneously transmitting data on the PUSCH, the UCI is multiplexed with data on the granted resources instead of being transmitted on the PUCCH.

[0021] In the case of carrier aggregation, the uplink control information is transmitted on the primary cell as a baseline. This is motivated by the need to support asymmetric carrier aggregation where the number of downlink carriers supported by a UE is unrelated to the number of uplink carriers.

[0022] UCI on PUCCH

[0023] Uplink control information can be transmitted on PUCCH using several different formats.

[0024] Two of the formats, 0 and 2, may be referred to as short PUCCH formats, as they occupy at most two OFDM symbols. In some cases, the last one or two Orthogonal frequency-division multiplexing (OFDM) symbols in a slot are used for PUCCH transmission, for example, to transmit a hybrid-ARQ acknowledgment of the downlink data transmission. The short PUCCH formats include:

[0025] • PUCCH format 0, capable of transmitting at most two bits and spanning one or two OFDM symbols. This format can, for example, be used to transmit a hybrid- ARQ acknowledgment of a downlink data transmission, or to issue a scheduling request.

[0026] • PUCCH format 2, capable of transmitting more than two bits and spanning one or two OFDM symbols. This format can, for example, be used for CSI reports or for multi-bit hybrid-ARQ acknowledgments for multiple PDSCHs on a same cell or in the case of carrier aggregation, or per code block group (CBG) retransmission. Three of the formats, 1, 3, and 4, are sometimes referred to as long PUCCH formats as they occupy from 4 to 14 OFDM symbols. The reason for having a longer time duration than the previous two formats is coverage. If a duration of one or two OFDM symbols does not provide sufficient energy for reliable reception, a longer time duration may be necessary and one of the long PUCCH formats can be used. The long PUCCH formats include:

[0027] • PUCCH format 1, capable of transmitting at most two bits.

[0028] • PUCCH formats 3 and 4, both capable of transmitting more than two bits but differing in the multiplexing capacity, that is, how many UEs can use the same time-frequency resource simultaneously. Transmission of PUCCH requires time-frequency resources. In 5GNR, a flexible scheme is used, which is necessary given the very flexible framework with a wide range of service requirements in terms of latency and spectral efficiency, support of no predefined uplink-downlink allocation in time division duplex (TDD), different devices supporting aggregation of different number of carriers, and different antenna schemes requiring different amounts of feedback, for example. One aspect of this scheme is the notion of PUCCH resource sets. A PUCCH resource set contains one or more PUCCH resource configurations where each resource configuration contains the PUCCH format to use and all the parameters necessary for that format. The first PUCCH resource set can contain up to 32 PUCCH resources while the remaining sets may contain up to eight resources each. Up to four PUCCH resource sets can be configured, each of them corresponding to a certain range of the number of UCI bits to transmit. PUCCH resource set 0 can handle UCI payloads up to two bits and hence only contain PUCCH formats 0 and 1, while the remaining PUCCH resource sets may contain any PUCCH format except format 0 and 1.

[0029] When the UE is about to transmit UCI, the UCI payload determines the PUCCH resource set and the PUCCH resource indicator in the DCI determines the PUCCH resource configuration within the PUCCH resource set (see FIG. 1). Thus, the scheduler has control of where the uplink control information is transmitted. For the first resource set, which may contain up to 32 resources, there can be more resources than what is possible to indicate with a three-bit PUCCH resource indicator. If this is the case, the index of the first control channel element (CCE) of the physical downlink control channel (PDCCH) scheduling the uplink is used together with the PUCCH resource indicator to determine the PUCCH resource within the set. For periodic CSI reports and scheduling request opportunities, which both are semi-statically configured, the PUCCH resources are provided as part of the CSI or scheduling request (SR) configuration.

[0030] UCI on PUSCH

[0031] If the UE is transmitting data on PUSCH - that is, has a valid scheduling grant - the UCI is “rerouted” from the PUCCH to the PUSCH if the PUCCH transmission overlaps with the PUSCH transmission in the same PUCCH cell group. Only hybrid-ARQ acknowledgments and CSI reports are rerouted to the PUSCH. There is no need to request a scheduling grant when the device is already scheduled.

[0032] In principle, the network node knows when to expect a hybrid-ARQ acknowledgment from the device and can therefore perform the appropriate demultiplexing of the acknowledgment and the data part. However, there is a certain probability that the UE has missed the scheduling assignment on the downlink control channel. In this case the network node would expect a hybrid- ARQ acknowledgment while the UE will not transmit one. If the rate-matching pattern depends on whether an acknowledgment is transmitted or not, all the coded bits transmitted in the data part could be affected by a missed assignment and are likely to cause the uplink shared channel (UL- SCH) decoding to fail.

[0033] One possibility to avoid this error is to puncture hybrid- ARQ acknowledgments onto the coded UL-SCH stream in which case the non-punctured bits are unaffected by the presence / absence of hybrid-ARQ acknowledgments. This is also the solution adopted in LTE. However, given the potentially large number of acknowledgment bits due to, for example, carrier aggregation or the use of codeblock group retransmissions, puncturing is less suitable as a general solution. Instead, NR has adopted a scheme where up to two hybrid-ARQ acknowledgment bits are punctured, while for a larger number of bits, rate matching of the uplink data is used. To avoid the aforementioned error cases, the uplink DAI field in the DCI indicates the amount of resources reserved for uplink hybrid ARQ. Thus, regardless of whether the UE missed any previous scheduling assignments or not, the amount of resources to use for the uplink hybrid-ARQ feedback is known.

[0034] UCI on L2

[0035] Another possibility, currently not in the specifications, is to multiplex UCI with data in the medium access control (MAC), i.e. treat the UCI as L2 information. In principle, the UE can send any feedback it has prepared as part of any scheduled data transmission (subject to rules). Feedback can be formatted as a MAC CE, a flexible data structure which can handle varying reporting sizes, which makes it suitable for HARQ feedback which - due to dynamic scheduling - typically is variable in size. This scheme decouples downlink (DL) and uplink (UL) scheduler which is helpful from an implementation perspective (The size of HARQ feedback depends on DL scheduling decisions, if the network node would need to exactly match the allocated UL resources to the HARQ feedback size this would tightly link DL and UL scheduler). With UCI on L2, the network node allocates a certain amount of UL resources for data and uplink control information, and due to size-flexibility of MAC CEs the network node does not need to bother about the exact size of uplink control information.

[0036] Carrier aggregation

[0037] Carrier aggregation is supported in 5G NR, that is, data transmissions to / from a UE may use multiple carriers, e.g., to obtain very high data rates. A UE capable of carrier aggregation may receive or transmit simultaneously on multiple component carriers while a UE not capable of carrier aggregation can access one of the component carriers only. Thus, the physical-layer description applies to each component carrier separately in the case of carrier aggregation.

[0038] In some specifications (e.g., 3GPP specifications), carrier aggregation is described using the term cell, that is, a carrier-aggregation-capable UE is able to receive and transmit from / to multiple cells. One of these cells is referred to as the primary cell (PCell). This is the cell which the UE initially finds and connects to, after which one or more secondary cells (SCells) can be configured once the UE is in connected mode. The secondary cells can be activated or deactivated to meet the variations in the traffic pattern. Different UEs may have different cells as their primary cell — that is, the configuration of the primary cell is device-specific. Furthermore, the number of carriers (or cells) does not have to be the same in uplink and downlink. In fact, a typical case is to have more carriers aggregated in the downlink than in the uplink. There are several reasons for this. There is typically more traffic in the downlink than in the uplink. Furthermore, the radio frequency (RF) complexity from multiple simultaneously active uplink carriers is typically larger than the corresponding complexity in the downlink.

[0039] Scheduling grants and scheduling assignments, or in general terms downlink control information, is as a baseline transmitted separately per carrier scheduled, that is, there is one PDCCH for each scheduling grant or assignment sent to the UE.

[0040] Control information for scheduling purposes can be transmitted on either the same cell as the corresponding data, known as self-scheduling, or on a different cell than the corresponding data, known as cross-carrier scheduling. There is also a need for uplink control signaling, for example, hybrid- ARQ acknowledgements to inform the network node about the success or failure of downlink data reception. As a baseline, all the feedback is transmitted on the PCell, motivated by the need to support asymmetric carrier aggregation with the number of downlink carriers supported by a UE unrelated to the number of uplink carriers. For a large number of downlink component carriers, a single uplink carrier may thus carry a large number of acknowledgements.

[0041] Hybrid-ARQ

[0042] Hybrid-ARQ is one of the retransmission mechanisms in 5GNR. The basis for the NR hybrid- ARQ mechanism is a structure with multiple stop-and-wait protocols, each operating on a single transport block on one carrier. In a stop-and-wait protocol, the transmitter stops and waits for an acknowledgement after each transmitted transport block. This is a low complexity scheme; the only feedback required is a single bit indicating positive or negative acknowledgement of the transport block. However, since the transmitter stops after each transmission, the throughput is also low. Therefore, multiple stop-and-wait processes operating in parallel are used such that, while waiting for acknowledgement from one process, the transmitter can transmit data to another hybrid- ARQ process. This structure, multiple hybrid-ARQ processes operating in parallel to form one hybrid-ARQ entity, combines the low complexity of a stop-and-wait protocol with the possibility of continuous data transmission.

[0043] Acknowledgement, positive or negative, of a received transport block is fed back from the UE to the network node. The UE needs to know when to transmit the acknowledgement in the uplink in response to a downlink reception. The hybrid-ARQ timing field in the downlink DCI is used to control the transmission timing of the acknowledgement in the uplink. This three-bit field is used as an index into a radio resource control (RRC) configured table providing information on when the hybrid-ARQ acknowledgement should be transmitted relative to the reception of the PDSCH (see FIG. 2). In this particular example, three slots are scheduled in the downlink before an acknowledgement is transmitted in the uplink. In each downlink assignment, different acknowledgement timing indices have been used, which in combination with the RRC- configured table result in all three slots being acknowledged at the same time (multiplexing of these acknowledgments in the same slot is discussed below).

[0044] For proper transmission of the acknowledgement, it is not sufficient for the device to know when to transmit, which is obtained from the timing field discussed, but also where in the resource domain. This is handled through the PUCCH resource indicator, which is a three-bit index selecting one of eight RRC-configured resources in a resource set as discussed above.

[0045] Multiple transport blocks may need to be indicated at the same time, for example, in TDD where multiple downlink slots are followed by a single uplink slot, or in case of carrier aggregation where transmissions on multiple downlink carriers need to be acknowledged on a single uplink carrier. In these cases, a multi-bit report formed according to a HARQ codebook is used. Different types of codebooks exists: type 1 (semistatic), type 2 (dynamic), or type 3 (originally designed for unlicensed spectrum). Semi-static codebook (type 1)

[0046] The semi-static codebook can be viewed as a matrix consisting of a time-domain dimension and a component-carrier dimension, both of which are semi-statically configured. The size in the time domain is given by the maximum and minimum hybrid- ARQ acknowledgement timings configured, and the size in the carrier domain is given by the number of simultaneous transport blocks across all component carriers. An example is provided in FIG. 3, where the acknowledgment timings are one, two, three, and four, respectively, and three carriers, one with two transport blocks, one with one transport block, and one with four CBGs, are configured. Since the codebook size is fixed, the number of bits to transmit in a hybrid-ARQ report is known (4 -7=28 bits in the example in FIG. 3) and the appropriate format for the uplink control signaling can be selected. Each entry in the matrix represents the decoding outcome, positive or negative acknowledgment, of the corresponding transmission. Not all transmission opportunities possible with the codebook are used in this example and for entries in the matrix without a corresponding transmission, a negative acknowledgment is transmitted. This provides robustness; in the case of missed downlink assignment a negative acknowledgment is provided to the network node, which can retransmit the missing transport block (or CBG).

[0047] Dynamic codebook (type 2)

[0048] With a dynamic codebook, only the acknowledgement information for the scheduled carriers is included in the report, instead of all carriers, scheduled or not, as is the case with a semi-static codebook. The description here uses the term ‘carrier’ but the same principle is equally applicable to per-CBG retransmission or multiple transport blocks in case of MIMO. Hence, the size of the codebook (the matrix in FIG. 3) is dynamically varying as a function of the number of scheduled carriers. In essence, only the bold entries in the example in FIG. 3 (denoted by ‘AN’) would be included in the hybrid-ARQ report and the non-bold entries (denoted by ‘N’, and which correspond to non-scheduled carriers) would be omitted. This reduces the size of the acknowledgement message.

[0049] A dynamic codebook would be straightforward if there were no errors in the downlink control signaling. However, in presence of an error in the downlink control signaling, the UE and network node may have a different understanding on the number of scheduled carriers which would lead to an incorrect codebook size and possibly corrupt the feedback report for all carriers, and not only for the ones for which the downlink control signaling was missed. Assume, as an example, that the device was scheduled for downlink transmission in two subsequent slots but missed the PDCCH and hence scheduling assignment for the first slot. In response, the UE will transmit an acknowledgement for the second slot only, while the network node tries to receive acknowledgments for two slots, leading to a mismatch.

[0050] To handle these error cases, NR uses the downlink assignment index (DAI) included in the DCI containing the downlink assignment. The DAI field is further split into two parts, a counter DAI (cDAI) and, in the case of carrier aggregation, a total DAI (tDAI). The counter DAI included in the DCI indicates the number of scheduled downlink transmissions up to the point the DCI was received in a carrier first, time second manner. The total DAI included in the DCI indicates the total number of downlink transmissions across all carriers up to this point in time, that is, the highest cDAI at the current point in time (see FIG. 4 for an example). In principle, when accounting for the number of scheduled downlink transmissions, the counter DAI and total DAI are incremented and represented with decimal numbers with no limitation. However, in practice two bits are used for each and the numbering will wrap around, that is, what is signaled is the numbers in the figure modulo four. As seen in the example in FIG. 4, the dynamic codebook needs to account for 17 acknowledgments (numbered 0 to 16). This can be compared with the semi-static codebook which would require 28 entries regardless of the number of transmissions.

[0051] Furthermore, in this example, one transmission on component carrier five is lost. Without the DAI mechanism, this would result in misaligned codebooks between the UE and the network node. However, as long as the UE receives at least one component carrier, it knows the value of the total DAI and hence the size of the codebook at this point in time. Furthermore, by checking the values received for the counter DAI, it can conclude which component carrier was missed and that a negative acknowledgement should be assumed in the codebook for this position.

[0052] As part of the DCI that schedules a downlink transmission, a slot and PUCCH resource is indicated which should be used for the HARQ feedback. The above description describes how the HARQ codebook is constructed for those PDSCH acknowledged in the same PUCCH. The UE knows all PDSCH that it should acknowledge (assuming it can reconstruct all potentially missed DL assignments using the DAI mechanism outlined above) in the same PUCCH, backtracks the scheduling PDCCH, and sorts the HARQ feedback according to a carrier first, time second manner of the scheduling PDCCH. One-shot codebook (type 3)

[0053] In 3GPP NR release 16, the possibility to postpone the transmission of the hybrid- ARQ acknowledgment to a later, unspecified point in time is introduced. By setting one of the entries in the table controlling when a PUCCH is transmitted to “later”, the network node can instruct the UE not to transmit the hybrid- ARQ acknowledgment but instead store it until a later point in time, see FIG. 5.

[0054] The HARQ feedback is requested using information in a downlink-related DCI. In contrast to the acknowledging reporting using the dynamic codebook (as described above), there is the possibility for a one-shot feedback report where the UE is requested to report the status, positive or negative acknowledgment, for all the hybrid-ARQ processes. This type of reporting is also known as type 3 codebook. If the network sets a flag in the DCI scheduling a downlink transmission, the UE will respond to by transmitting a status report across all hybrid-ARQ processes.

[0055] Scheduling

[0056] NR is a scheduled system, implying that the scheduler determines when and to which UEs the time, frequency, and spatial resources should be assigned and what transmission parameters, including data rate, to use. Scheduling can be either dynamic or semi-static. Dynamic scheduling is the basic mode-of-operation where the scheduler for each time interval, for example, a slot, determines which UEs are to transmit and receive. Since scheduling decisions are taken frequently, it is possible to follow rapid variations in the traffic demand and radio-channel quality, thereby efficiently exploiting the available resources. Semi-static scheduling implies that the transmission parameters are provided to the UEs in advance and not on a dynamic basis.

[0057] The scheduler strategy and how to implement it is not standardized but left for the vendor to decide upon - only the control signaling mechanism between the network node and the UE is specified in the standard.

[0058] One possibility is to implement one single, monolithic scheduler controlling all uplink and downlink transmissions on all carriers. However, this may not always be possible, especially for large network nodes handling a large number of UEs. Implementations with a separate downlink scheduler for each carrier, as well as a separate uplink scheduler for each uplink carrier, is possible. In this case, the different schedulers need to interact to some extent when taking the scheduling decisions.

[0059] The different downlink schedulers need to interact when deciding on the number of carriers to use for downlink data transmission. In particular, they need to agree on the DAI field in the DCI in order to form the HARQ codebook. This interaction is time-critical as the data transmission and the associated control signaling typically are transmitted in the same slot. The uplink and downlink scheduler need to interact when deciding upon the usage of uplink resources. Some uplink resources, more precisely the PUCCH resources, are decided upon by the downlink scheduler(s) and the uplink scheduler needs to take this into account when taking the uplink scheduling decision.

[0060] Transmission of HARQ-related feedback in the uplink using the NR scheme requires very tight interaction both between the downlink schedulers (e.g., when forming the DAI) and between the downlink and uplink schedulers (e.g., uplink resources used for HARQ feedback are controlled by the downlink scheduler and not the uplink scheduler). This complicates the implementation of the scheduler. Treating the feedback as L2 data, i.e., multiplex UCI and data in the MAC layer, could solve this issue, but may lead to increased overhead, especially if the UCI payload is small relative to the size of the necessary MAC headers.

[0061] SUMMARY

[0062] A first aspect provides embodiments of a method implemented in a user equipment (UE). The UE is configured to communicate with a network node. The method comprises receiving a transmission, and receiving control information scheduling transmission of an acknowledgement of reception of the received transmission. The method comprises transmitting the acknowledgement in accordance with the control information. The control information is of a type capable of scheduling a data transmission from the UE.

[0063] Corresponding embodiments of a UE are also enclosed.

[0064] A second aspect provides embodiments of a method implemented in a network node. The network node is configured to communicate with a UE. The method comprises transmitting a transmission, and transmitting control information scheduling transmission of an acknowledgement of reception of the transmitted transmission. The method comprises receiving the acknowledgement in accordance with the control information. The control information is of a type capable of scheduling a data transmission from the UE.

[0065] Corresponding embodiments of a network node are also enclosed.

[0066] BRIEF DESCRIPTION OF THE DRAWINGS

[0067] A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein: FIG. 1 is a diagram of an example of PUCCH resources;

[0068] FIG. 2 is a diagram of an example of acknowledgement timing;

[0069] FIG. 3 is a diagram of an example of semi-static HARQ codebook;

[0070] FIG. 4 is a diagram of an example of dynamic HARQ acknowledgement codebook;

[0071] FIG. 5 is a diagram of an example of postponing HARQ feedback;

[0072] FIG. 6 is a schematic diagram of an example network architecture illustrating a communication system according to principles disclosed herein;

[0073] FIG. 7 is a block diagram of a network node in communication with a user equipment over a wireless connection according to some embodiments of the present disclosure;

[0074] FIG. 8 is a flowchart of an example process in a network node according to some embodiments of the present disclosure;

[0075] FIG. 9 is a flowchart of an example process in a user equipment according to some embodiments of the present disclosure; and

[0076] FIG. 10 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized.

[0077] DETAILED DESCRIPTION

[0078] Before describing in detail exemplary embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to scheduling of an acknowledgement of a transmission received by a user equipment (UE). Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0079] As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0080] In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

[0081] In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and / or wireless connections.

[0082] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0083] The term “network node” used herein can be any kind of network node comprised in a radio network which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNB), evolved Node B (eNB or eNodeB), Node B, multistandard radio (MSR) radio node such as MSR BS, multi-cell / multicast coordination entity (MCE), relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, a node external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), etc. The network node may also comprise test equipment. The term “radio node” used herein may be used to also denote a user equipment (UE) such as a wireless device (WD) or a radio network node.

[0084] In some embodiments, the non-limiting terms wireless device (WD) or a user equipment (UE) are used interchangeably. The UE herein can be any type of user equipment capable of communicating with a network node or another UE over radio signals, such as a wireless device (WD). The UE may also be a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), low-cost and / or low-complexity UE, a sensor equipped with UE, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device etc.

[0085] Also, in some embodiments the generic term “radio network node” is used. It can be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, RNC, evolved Node B (eNB), Node B, gNB, Multi-cell / multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH).

[0086] Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and / or New Radio (NR) and / or 6G, may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. It is contemplated that other 3GPP systems may make use of the concepts and arrangements disclosed herein. For example, a disclosure relating to NR may also be implementable in a 6G system and / or an LTE system, a disclosure relating to 6G may also be implementable in a NR and / or LTE system, and a disclosure relating to LTE may also be implementable in a NR and / or 6G system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure.

[0087] Note further, that functions described herein as being performed by a user equipment or a network node may be distributed over a plurality of user equipments and / or network nodes. In other words, it is contemplated that the functions of the network node and user equipment described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0088] Some embodiments are directed to asynchronous UCI reporting.

[0089] Referring again to the drawing figures, in which like elements are referred to by like reference numerals, there is shown in FIG. 6 a schematic diagram of a communication system 10, according to an embodiment, such as a 3 GPP-type cellular network that may support standards such as LTE and / or NR (5G) and / or 6G, which comprises an access network 12, such as a radio access network, and a core network 14. The access network 12 comprises a plurality of network nodes 16a, 16b, 16c (referred to collectively as network nodes 16), such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 18a, 18b, 18c (referred to collectively as coverage areas 18). Each network node 16a, 16b, 16c is connectable to the core network 14 over a wired or wireless connection 20. A first user equipment (UE) 22a located in coverage area 18a is configured to wirelessly connect to, or be paged by, the corresponding network node 16a. A second UE 22b in coverage area 18b is wirelessly connectable to the corresponding network node 16b. While a plurality of UEs 22a, 22b (collectively referred to as user equipments 22) are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding network node 16. Note that although only two UEs 22 and three network nodes 16 are shown for convenience, the communication system may include many more UEs 22 and network nodes 16.

[0090] Also, it is contemplated that a UE 22 can be in simultaneous communication and / or configured to separately communicate with more than one network node 16 and more than one type of network node 16. For example, a UE 22 can have dual connectivity with a network node 16 that supports LTE and the same or a different network node 16 that supports NR. As an example, UE 22 can be in communication with an eNB for LTE / E-UTRAN and a gNB for NR / NG-RAN.

[0091] A network node 16 (eNB or gNB) is configured to include a scheduling unit 24 which is configured to perform one or more network node 16 functions as described herein. A user equipment 22 is configured to include a control information unit 26 which is configured to perform UE 22 functions as described herein.

[0092] Example implementations, in accordance with an embodiment, of the UE 22 and network node 16 discussed in the preceding paragraphs will now be described with reference to FIG. 7.

[0093] The communication system 10 includes a network node 16 provided in a communication system 10 and including hardware 28 enabling it to communicate with the UE 22. The hardware 28 may include a radio interface 30 for setting up and maintaining at least a wireless connection 32 with a UE 22 located in a coverage area 18 served by the network node 16. The radio interface 30 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers. The radio interface 30 includes an array of antennas 34 to radiate and receive signal(s) carrying electromagnetic waves.

[0094] In the embodiment shown, the hardware 28 of the network node 16 further includes processing circuitry 36. The processing circuitry 36 may include a processor 38 and a memory 40. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 36 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 38 may be configured to access (e.g., write to and / or read from) the memory 40, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0095] Thus, the network node 16 further has software 42 stored internally in, for example, memory 40, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the network node 16 via an external connection. The software 42 may be executable by the processing circuitry 36. The processing circuitry 36 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by network node 16. Processor 38 corresponds to one or more processors 38 for performing network node 16 functions described herein. The memory 40 is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 42 may include instructions that, when executed by the processor 38 and / or processing circuitry 36, causes the processor 38 and / or processing circuitry 36 to perform the processes described herein with respect to network node 16. For example, processing circuitry 36 of the network node 16 may include scheduling unit 24 which is configured to perform one or more network node 16 functions as described herein. Scheduling unit 24 may include and / or provide the one or more schedulers described herein.

[0096] The communication system 10 further includes the UE 22 already referred to. The UE 22 may have hardware 44 that may include a radio interface 46 configured to set up and maintain a wireless connection 32 with a network node 16 serving a coverage area 18 in which the UE 22 is currently located. The radio interface 46 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers. The radio interface 46 includes an array of antennas 48 to radiate and receive signal(s) carrying electromagnetic waves.

[0097] The hardware 44 of the UE 22 further includes processing circuitry 50. The processing circuitry 50 may include a processor 52 and memory 54. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 50 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 52 may be configured to access (e.g., write to and / or read from) memory 54, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0098] Thus, the UE 22 may further comprise software 56, which is stored in, for example, memory 54 at the UE 22, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the UE 22. The software 56 may be executable by the processing circuitry 50. The software 56 may include a client application 58. The client application 58 may be operable to provide a service to a human or non-human user via the UE 22.

[0099] The processing circuitry 50 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by UE 22. The processor 52 corresponds to one or more processors 52 for performing UE 22 functions described herein. The UE 22 includes memory 54 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 56 and / or the client application 58 may include instructions that, when executed by the processor 52 and / or processing circuitry 50, causes the processor 52 and / or processing circuitry 50 to perform the processes described herein with respect to UE 22. For example, the processing circuitry 50 of the user equipment 22 may include control information unit 26 which is configured to perform one or more UE 22 functions as described herein.

[0100] In some embodiments, the inner workings of the network node 16 and UE 22 may be as shown in FIG. 7 and independently, the surrounding network topology may be that of FIG. 6.

[0101] The wireless connection 32 between the UE 22 and the network node 16 is in accordance with the teachings of the embodiments described throughout this disclosure. More precisely, the teachings of some 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, extended battery lifetime, etc. In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve.

[0102] Although FIGS. 6 and 7 show various “units” such as scheduling unit 24 and control information unit 26 as being within a respective processor, it is contemplated that these units may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry.

[0103] For example, in some embodiments, the telecommunication system 10 includes one or more Open-RAN (ORAN) network nodes 16. An ORAN network node 16 is a node in the telecommunication system 10 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication system 10, including one or more network nodes 16 in the access network 12 and / or core network nodes in core network 14.

[0104] Examples of an ORAN network node 16 include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near- real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O- RAN Alliance or comparable technologies. The network nodes 16 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 22a, 22b (one or more of which may be generally referred to as UEs 22) to the core network 14 over one or more wireless connections.

[0105] FIG. 8 is a flowchart of an example process in a network node 16 according to one or more embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 36 (including the scheduling unit 24), processor 38, and / or radio interface 30. Network node 16 is configured to transmit (Block S100) at least one of a downlink-related downlink control information (DCI) and an uplink-related DCI, as described herein. Network node 16 is configured to receive (Block SI 02) uplink control information (UCI) scheduled by at least one of the downlink-related DCI and the uplink- related DCI, as described herein.

[0106] According to one or more embodiments, the downlink-related DCI is configured to schedule downlink data and the UCI.

[0107] According to one or more embodiments, the uplink-related DCI is configured to schedule the UCI and uplink data.

[0108] According to one or more embodiments, the uplink-related DCI at least one of: contains information indicating whether to transmit the UCI; contains information indicating whether to use a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) for the UCI; contains information indicating at least one rule that is usable in combination with DCI information; and contains information usable for determining an amount of resources for the transmission of the UCI. According to one or more embodiments, the scheduling of the UCI by the downlink-related DCI or the uplink-related DCI is based on a radio resource configuration, RRC, configuration.

[0109] According to one or more embodiments, the scheduling of the UCI is based on at least one rule associated with a situation where information in the downlink-related DCI conflicts with information in the uplink-related DCI.

[0110] According to one or more embodiments, the received UCI is associated with a hybrid automatic repeat request (HARQ) codebook that is associated with a time span of the HARQ codebook derived from the uplink-related DCI.

[0111] According to some embodiments, a method is implemented in a network node that is configured to communicate with a user equipment (UE). The method comprises transmitting a transmission, and transmitting (as in Block SI 00 in FIG. 8) control information scheduling transmission of an acknowledgement of reception of the transmitted transmission. The method comprises receiving (as in Block SI 02 in FIG. 8) the acknowledgement in accordance with the control information. The control information is of a type capable of scheduling a data transmission from the UE.

[0112] FIG. 9 is a flowchart of an example process in a user equipment 22 according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of user equipment 22 such as by one or more of processing circuitry 50 (including the control information unit 26), processor 52, and / or radio interface 46. UE 22 is configured to receive (Block SI 04) at least one of a downlink-related downlink control information (DCI) and an uplink-related DCI, as described herein. UE 22 is configured to transmit (Block SI 06) uplink control information (UCI) scheduled by at least one of the downlink-related DCI and the uplink-related DCI, as described herein.

[0113] According to one or more embodiments, the downlink-related DCI is configured to schedule downlink data and the UCI.

[0114] According to one or more embodiments, the uplink-related DCI is configured to schedule the UCI and uplink data.

[0115] According to one or more embodiments, the uplink-related DCI at least one of: contains information indicating whether to transmit the UCI; contains information indicating whether to use a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) for the UCI; contains information indicating at least one rule that is usable in combination with DCI information; and contains information usable for determining an amount of resources for the transmission of the UCI.

[0116] According to one or more embodiments, the scheduling of the UCI by the downlink-related DCI or the uplink-related DCI is based on a radio resource configuration, RRC, configuration.

[0117] According to one or more embodiments, the scheduling of the UCI is based on at least one rule associated with a situation where information in the downlink-related DCI conflicts with information in the uplink-related DCI.

[0118] According to one or more embodiments, the transmitted UCI is associated with a hybrid automatic repeat request (HARQ) codebook; and the UE 22 is further configured to derive a time span of the HARQ codebook from the uplink-related DCI.

[0119] According to some embodiments, a method is implemented in a UE that is configured to communicate with a network node. The method comprises receiving a transmission, and receiving (as in Block SI 04 in FIG. 9) control information scheduling transmission of an acknowledgement of reception of the received transmission. The method comprises transmitting (as in Block SI 06 in FIG. 9) the acknowledgement in accordance with the control information. The control information is of a type capable of scheduling a data transmission from the UE.

[0120] FIG. 10 is a block diagram illustrating a virtualization environment 94 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 94 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 94 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. Applications 96 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 94 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0121] Hardware 98 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 100 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 102a and 102b (one or more of which may be generally referred to as VMs 102), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 100 may present a virtual operating platform that appears like networking hardware to the VMs 102.

[0122] The VMs 102 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 100. Different embodiments of the instance of a virtual appliance 96 may be implemented on one or more of VMs 102, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0123] In the context of NFV, a VM 102 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 102, and that part of hardware 98 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 102 on top of the hardware 98 and corresponds to the application 96.

[0124] Hardware 98 may be implemented in a standalone network node with generic or specific components. Hardware 98 may implement some functions via virtualization. Alternatively, hardware 98 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 104, which, among others, oversees lifecycle management of applications 96. In some embodiments, hardware 98 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 106 which may alternatively be used for communication between hardware nodes and radio units.

[0125] Having described the general process flow of arrangements of the disclosure and having provided examples of hardware and software arrangements for implementing the processes and functions of the disclosure, the sections below provide details and examples of arrangements for asynchronous uplink control information (UCI) reporting.

[0126] Some embodiments provide asynchronous uplink control information (UCI) reporting. One or more UE 22 functions described below may be performed by one or more of processing circuitry 50, processor 52, control information unit 26, radio interface 46, etc. One or more network node 16 functions described below may be performed by one or more of processing circuitry 36, processor 38, scheduling unit 24, radio interface 30, etc.

[0127] Scheduling of data and UCI

[0128] UCI is scheduled by an uplink-related DCI, either as a replacement of or a complement to the possibility to use the downlink-related DCI (which is used in 5G NR). This will decouple the uplink and downlink scheduling decisions from each other. The uplink-related DCI in this case may need to be able to schedule transmissions belonging to some or all of:

[0129] 1. Uplink data on PUSCH and no simultaneous UCI

[0130] 2. UCI on PUCCH and no simultaneous PUSCH

[0131] 3. Uplink data and UCI on PUSCH

[0132] 4. Uplink data on PUSCH and UCI on PUCCH, i.e., simultaneous PUSCH and PUCCH. This is an optional feature in the UE 22 and may or may not be supported by a future 3 GPP standard.

[0133] Case 1: Uplink data on PUSCH and no simultaneous UCI is similar to the case in 5G NR. This can be supported for example by reusing the mechanism in 5G NR or a modification thereof. Case 2: UCI on PUCCH and no simultaneous PUSCH can be realized, e.g., by including the PUCCH-related fields located in the downlink-related DCI in 5G NR into the uplink-related DCI. In addition, information to link which downlink transmissions the feedback relate to may be required, as described herein.

[0134] Case 3: both UCI and uplink data on PUSCH. In addition to the PUSCH-related information (see case 1), information on how to multiplex UCI onto PUSCH (and which parts of UCI to include) may be related. Predefined multiplexing rules can also be used in combination with the DCI.

[0135] Case 4: simultaneous PUSCH and PUCCH. This is optional functionality. If it is to be supported the uplink-related DCI needs to contain both PUSCH-related and PUCCH- related information.

[0136] In other words, the uplink-related DCI needs to contain information to, possibly together with a set of predetermined or configurable rules, inform the UE 22 which of the four cases above applies to a certain received downlink-related DCI. One possibility is to include two bits in the uplink-related DCI where the two bits set at:

[0137] - 00 means no UCI, no data. (The uplink-related UCI could include features not described in the present disclosure, e.g. triggering of SRS transmissions)

[0138] - 01 means UCI on PUCCH but no data on PUSCH (case 2)

[0139] 10 means data on PUSCH but no UCI (case 1)

[0140] 11 means data and UCI on PUSCH (case 3)

[0141] Note that if a UE 22 has UCI awaiting transmission, e.g. hybrid-ARQ feedback, it may not necessarily be allowed to transmit the UCI, e.g. if the uplink-related DCI instructs the UE 22 to transmit uplink data only (case 1 above). Alternatively, rules may be defined such that a UE 22, if it has UCI awaiting transmission, should include that on the PUSCH (case 3 above).

[0142] The amount of resources (PUCCH or PUSCH) to be used for UCI can be (partially) indicated in the uplink-related DCI. For example, the uplink-related DCI could indicate small, medium, or large and this information is used as part in the mechanism allocating resources for transmission of the UCI.

[0143] Further cases may be considered in addition to the previously four cases mentioned above, and the corresponding indication in the uplink-related DCI informs the UE 22 which of the cases applies. For example, some other cases are described below.

[0144] Case 5: UCI (e.g., hybrid-ARQ feedback) in PUSCH without simultaneous uplink data. UCI in PUSCH in this case corresponds to having UCI as part of the PUSCH transport block. In this case, information to link which downlink transmissions the feedback relates to can be included in the uplink-related DCI, e.g., there can be further indication in the uplink-related DCI to indicate one of the preconfigured sets of hybrid- ARQ feedback to include in the PUSCH. One of the predefined sets can be the set of all hybrid- ARQ feedback corresponding to all HARQ processes and all configured component carriers.

[0145] Case 6: Uplink data on PUSCH and UCI (e.g., hybrid-ARQ feedback) on PUCCH and / or in PUSCH. UCI in PUSCH here corresponds to having UCI multiplexed as part of the PUSCH transport block, i.e., it is treated as L2 data. In this case, PUSCH and PUCCH are not expected to be transmitted simultaneously. In one example, if a UE 22 has UCI awaiting transmission, e.g., hybrid-ARQ feedback, and if PUSCH is scheduled to be transmitted earlier than PUCCH, the UE 22 transmits the UCI both in PUSCH and PUCCH, otherwise, it transmits the UCI only on PUCCH. One potential benefit of this case is that network node 16 may receive hybrid-ARQ feedback in the earlier PUSCH without the need to receive the later PUCCH. Also, in case that earlier PUSCH is not received correctly and requires a retransmission, network node 16 can receive the feedback in PUCCH instead which can be faster than waiting for the PUSCH retransmission.

[0146] HARQ codebook

[0147] In case UCI is included in the uplink transmission, either on PUCCH or on PUSCH, the time span of the HARQ codebook may need to be defined. This can be done in multiple ways.

[0148] One possibility is to indicate the time span of the HARQ codebook in the uplink- related DCI. For example, the DCI could request reports from all transmissions from slot X to slot Y. The slot numbers could be absolute or relative to the reception time of the uplink-related DCI (instead of slots time counting can also use symbols, subframes, or PDCCH monitoring occasions). Alternatively, the DCI could request reports of all data transmissions starting with DAI=0 and onwards until the latest received tDAI (in this case the latest received tDAI is preferably included in the uplink-related DCI to handle any error cases.).

[0149] Another possibility is to configure the time span using, e.g., RRC signaling, for example include all data transmissions in the latest X slots preceding the reception of the uplink-related DCI in the HARQ report. The time span can be associated with one or multiple cells. The association can be provided by configurations and / or pre-determined rules. For example, for an uplink transmission on cell X can be associated by configuration to DL receptions in a set of cells Y={Y1, Y2, .., Yn} where n can be at least 1.

[0150] In case of downlink data receptions on multiple cells within the time span, the HARQ report includes the HARQ-ACK information corresponding to the DL data receptions on the multiple cells. The DL receptions on multiple cells can be ordered using different methods.

[0151] • In one example, the HARQ-ACK information can be ordered starting with DL receptions from the cell with the smallest serving cell index to the cell with the largest serving cell index. In case of multiple DL receptions on a cell, the HARQ- ACK information for a serving cell are ordered from the DL reception with the earliest starting symbol to the DL reception with the latest starting symbol.

[0152] • In another example, the HARQ-ACK information can be ordered starting with DL receptions with the earliest starting symbol across the cells. In case of multiple DL receptions with the same starting symbol, the ordering starts with the HARQ-ACK information for the DL reception for the cell with lowest cell index.

[0153] The network node 16 can determine the HARQ codebook size based on the transmissions scheduled in DL and use this size information for allocating UL resources. However, this couples UL and DL schedulers together which is undesirable. In existing dynamic HARQ codebook construction the UE 22 determines the HARQ codebook size by using the DAI values in the DL assignment DCI (together with the UL DAI for UCI on PUSCH in the UL grant DCI). To avoid that information contained in the DL assignment DCI influences the determined HARQ codebook size (to decouple DL and UL scheduler), the UL grant DCI scheduling the UL HARQ feedback preferable contains a UCI size indicator field which indicates the HARQ codebook size to the UE 22. The mapping of UCI size indicator field bits to HARQ codebook size could be RRC configured. If the actual number of HARQ feedback bits the UE 22 plans to include in the HARQ codebook (e.g., based on DAI bits in DL assignment DCI) does not fit the indicated UCI size, rules are needed to expand / compress the HARQ feedback report, as described below. Since now the number of HARQ feedback bits following from DL DAIs and the indicated UCI size don’t need to match, the UL scheduler can make smart guesses about the UCI resource allocation (maybe not totally decoupling DL and UL scheduler, but enabling a looser coupling or minimizing the coupling compared to existing systems). Yet another way is to include the time span in the UCI, in which case the UE 22 could determine the time span of the codebook and indicate the time span in the UCI. This may lead to varying HARQ report sizes not known until the actual transmission, and the uplink-related DCI, in this case, may need to indicate the UCI report size (e.g., small, medium, or large). Rules need to be defined such that the UE 22 knows what to do in case all reports do not fit into the allocated UCI payload size, e.g., start by including the oldest HARQ transmissions until the UCI is filled. Alternatively, in a less preferred embodiment, the UCI may be split into two parts: a first part indicating at least the size of the second part and a second part containing the (parts ol) the HARQ report. If the indicated allocated UCI payload size is too large, the UE 22 would pad its report, e.g., by appending 0 or 1.

[0154] The HARQ-ACK codebook can include the HARQ-ACK information corresponding to DL receptions associated to a set of cells, C={C1, .., Cm} with m>=l, with corresponding set of HARQ processes, Hm={H(m,l), .., H(m,k)] with k>=l. The HARQ-ACK information in the codebook are ordered for example starting with the cell with the smallest index and including the HARQ-ACK information corresponding to the HARQ processes associated to the cell in increasing order. Additionally, the HARQ-ACK codebook can include a set of NDI (new data indication) bits corresponding to each HARQ-ACK information in the codebook. One can consider bundling of HARQ-ACK information. The HARQ-ACK information can be bundled into one bit (logical AND of all HARQ-ACK information bits), or in multi-bits corresponding to multiple bundling groups. The number of HARQ-ACK information bits in each bundle group can be determined based on a rule (for example bundle per serving cell, i.e., the HARQ-ACK information associated to the DL receptions on the serving cell), or by configurations (for example M bundle groups each with N HARQ-ACK information bits from the HARQ- ACK codebook).

[0155] The HARQ-ACK codebook can include in addition to the HARQ-ACK information corresponding to DL transmission, the HARQ-ACK information acknowledging other actions, for example confirmation of command, etc. These additional HARQ-ACK information, can be appended to the HARQ-ACK information for the DL transmission to form the HARQ-ACK codebook.

[0156] For transmission of the HARQ-ACK codebook by PUSCH, the HARQ-ACK codebook can be included as part of L2 transport block to be transmitted by PUSCH. In another method, the HARQ-ACK codebook can be multiplexed in PUSCH using LI multiplexing procedures similarly to 5GNR. Handling of conflicts between downlink-related and uplink-related DCI

[0157] As described above, UCI can be scheduled by an uplink-related DCI, either as a replacement of or a complement to the possibility to use the downlink-related DCI.

[0158] RRC configuration (or other means to configure the UE 22 and / or overall system) can be used to determine whether uplink-related DCI, downlink-related DCI, or both can be used to control transmission of UCI.

[0159] If the configuration or set-up of the system is such that both a downlink-related DCI or an uplink-related DCI can control (parts of) the same UCI, there could be conflicts between the two. The DCI (downlink-related or uplink-related) can in this case contain information that (directly or indirectly) controls which DCI is supposed to control the UCI.

[0160] Another possibility to handle potential conflicts is to define rules in the 3 GPP specification to give priority to one of the DCIs relating to the same UCI transmission. The rules could contain parts that are controlled by configuration, for example parameters set by RRC signaling.

[0161] Multiple HARQ codebooks, one (or more) related to UCI transmissions triggered by downlink-related DCIs and one (or more) related to UCI transmission triggered by uplink-related DCIs, may be used. Depending on the DCI controlling the UCI transmission, one or the other HARQ codebook is used to derive the HARQ feedback. In this case, different UCI transmissions based on the different codebooks may contain information relating to the same downlink data transmission.

[0162] Further examples

[0163] Some embodiments advantageously provide methods, systems, and apparatuses for asynchronous uplink control information (UCI) reporting.

[0164] Scheduling of data and UCI may be provided by separate DCIs; the downlink- related DCI schedules downlink data while the uplink-related DCI schedules uplink data and / or UCI.

[0165] First group of examples:

[0166] Example 1. UCI is scheduled by an uplink-related DCI.

[0167] Example 2. Example 1 where the uplink-related DCI contains information on if UCI should be transmitted or not.

[0168] Example 3. Example 2 + the uplink-related DCI contains information on whether PUCCH or PUSCH should be used for UCI Example 4. Example 2 or 3 + predefined / configurable rules are used in combination with DCI information.

[0169] Example 5. Any of the examples above + the uplink-related DCI contains information used when determining the amount of resources used for transmission of the UCI

[0170] Second group of examples:

[0171] Example 1A. The time span of the HARQ codebook is (partially) derived from the uplink-related DCI

[0172] Example 2A. The UCI contains information about the time span of the HARQ codebook.

[0173] Third group of examples:

[0174] Example IB. UCI can be scheduled by either a downlink-related DCI or an uplink-related DCI.

[0175] Example 2B. Example IB where the RRC configuration selects whether downlink-related DCI and / or uplink-related DCI is used to schedule UCI.

[0176] Example 3B. Example IB where the DCI (downlink-related or uplink- related) contains information whether UCI should be transmitted or not.

[0177] Example 4B. Any one of Examples 2B-3B where the predefined / configurable rules to determine whether a downlink-related DCI or uplink-related DCI is used to schedule the UCI in case there are conflicting information in the downlink- related DCI and uplink-related DCI controlling (at least part of) the UCI.

[0178] Example 5B. Any of Examples 1B-4B where separate HARQ codebooks are maintained for UCI triggered by downlink-related DCI and uplink-related DCI.

[0179] Example 6B. Example 5B where the codebooks may both contain feedback information related to the same downlink data transmission.

[0180] One or more embodiments described in the present disclosure reduce the need for interaction between uplink and downlink schedulers.

[0181] Miscellaneous

[0182] As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and / or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and / or functionality described herein may be performed by, and / or associated to, a corresponding module, which may be implemented in software and / or firmware and / or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

[0183] Some embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special purpose computer), special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0184] These computer program instructions may also be stored in a computer readable memory or storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0185] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0186] It is to be understood that the functions / acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0187] Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Python, Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0188] Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and / or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

[0189] It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings.

[0190] Embodiments

[0191] Embodiment Al . A method implemented in a user equipment (UE) that is configured to communicate with a network node, the method comprising: receiving at least one of a downlink-related downlink control information (DCI) and an uplink-related DCI; and transmitting uplink control information (UCI) scheduled by at least one of the downlink-related DCI and the uplink-related DCI.

[0192] Embodiment A2. The method of Embodiment Al, wherein the downlink- related DCI is configured to schedule downlink data and the UCI.

[0193] Embodiment A3. The method of any one of Embodiments A1-A2, wherein the uplink-related DCI is configured to schedule the UCI and uplink data.

[0194] Embodiment A4. The method of any one of Embodiments Al -A3, wherein the uplink-related DCI at least one of: contains information indicating whether to transmit the UCI; contains information indicating whether to use a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) for the UCI; contains information indicating at least one rule that is usable in combination with DCI information; and contains information usable for determining an amount of resources for the transmission of the UCI.

[0195] Embodiment A5. The method of any one of Embodiments A1-A4, wherein the scheduling of the UCI by the downlink-related DCI or the uplink-related DCI is based on a radio resource configuration, RRC, configuration.

[0196] Embodiment A6. The method of any one of Embodiments A1-A5, wherein the scheduling of the UCI is based on at least one rule associated with a situation where information in the downlink-related DCI conflicts with information in the uplink-related DCI.

[0197] Embodiment A7. The method of any one of Embodiments A1-A6, wherein the transmitted UCI is associated with a hybrid automatic repeat request (HARQ) codebook; and the method further comprises deriving a time span of the HARQ codebook from the uplink-related DCI. Embodiment Bl . A user equipment (UE) configured to communicate with a network node, the UE configured to, and / or comprising a radio interface and / or processing circuitry configured to: receive at least one of a downlink-related downlink control information (DCI) and an uplink-related DCI; and transmit uplink control information (UCI) scheduled by at least one of the downlink-related DCI and the uplink-related DCI.

[0198] Embodiment B2. The UE of Embodiment Bl, wherein the downlink-related DCI is configured to schedule downlink data and the UCI.

[0199] Embodiment B3. The UE of any one of Embodiments B1-B2, wherein the uplink-related DCI is configured to schedule the UCI and uplink data.

[0200] Embodiment B4. The UE of any one of Embodiments B1-B3, wherein the uplink-related DCI at least one of: contains information indicating whether to transmit the UCI; contains information indicating whether to use a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) for the UCI; contains information indicating at least one rule that is usable in combination with DCI information; and contains information usable for determining an amount of resources for the transmission of the UCI.

[0201] Embodiment B5. The UE of any one of Embodiments B1-B4, wherein the scheduling of the UCI by the downlink-related DCI or the uplink-related DCI is based on a radio resource configuration, RRC, configuration.

[0202] Embodiment B6. The UE of any one of Embodiments B1-B5, wherein the scheduling of the UCI is based on at least one rule associated with a situation where information in the downlink-related DCI conflicts with information in the uplink-related DCI. Embodiment B7. The UE of any one of Embodiments B1-B6, wherein the transmitted UCI is associated with a hybrid automatic repeat request (HARQ) codebook; and the UE is further configured to derive a time span of the HARQ codebook from the uplink-related DCI.

[0203] Embodiment Cl . A method implemented in a network node that is configured to communicate with a user equipment, the method comprising: transmitting at least one of a downlink-related downlink control information (DCI) and an uplink-related DCI; and receiving uplink control information (UCI) scheduled by at least one of the downlink-related DCI and the uplink-related DCI.

[0204] Embodiment C2. The method of Embodiment Cl, wherein the downlink- related DCI is configured to schedule downlink data and the UCI.

[0205] Embodiment C3. The method of any one of Embodiments C1-C2, wherein the uplink-related DCI is configured to schedule the UCI and uplink data.

[0206] Embodiment C4. The method of any one of Embodiments C1-C3, wherein the uplink-related DCI at least one of: contains information indicating whether to transmit the UCI; contains information indicating whether to use a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) for the UCI; contains information indicating at least one rule that is usable in combination with DCI information; and contains information usable for determining an amount of resources for the transmission of the UCI.

[0207] Embodiment C5. The method of any one of Embodiments C1-C4, wherein the scheduling of the UCI by the downlink-related DCI or the uplink-related DCI is based on a radio resource configuration, RRC, configuration. Embodiment C6. The method of any one of Embodiments C1-C5, wherein the scheduling of the UCI is based on at least one rule associated with a situation where information in the downlink-related DCI conflicts with information in the uplink-related DCI.

[0208] Embodiment C7. The method of any one of Embodiments C1-C6, wherein the received UCI is associated with a hybrid automatic repeat request (HARQ) codebook that is associated with a time span of the HARQ codebook derived from the uplink-related DCI.

[0209] Embodiment DI. A network node configured to communicate with a user equipment (UE), the network node configured to, and / or comprising a radio interface and / or comprising processing circuitry configured to: transmit at least one of a downlink-related downlink control information (DCI) and an uplink-related DCI; and receive uplink control information (UCI) scheduled by at least one of the downlink-related DCI and the uplink-related DCI.

[0210] Embodiment D2. The network node of Embodiment D 1 , wherein the downlink-related DCI is configured to schedule downlink data and the UCI.

[0211] Embodiment D3. The network node of any one of Embodiments D1-D2, wherein the uplink-related DCI is configured to schedule the UCI and uplink data.

[0212] Embodiment D4. The network node of any one of Embodiments D1-D3, wherein the uplink-related DCI at least one of: contains information indicating whether to transmit the UCI; contains information indicating whether to use a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) for the UCI; contains information indicating at least one rule that is usable in combination with DCI information; and contains information usable for determining an amount of resources for the transmission of the UCI. Embodiment D5. The network node of any one of Embodiments D1-D4, wherein the scheduling of the UCI by the downlink-related DCI or the uplink-related DCI is based on a radio resource configuration, RRC, configuration. Embodiment D6. The network node of any one of Embodiments D1-D5, wherein the scheduling of the UCI is based on at least one rule associated with a situation where information in the downlink-related DCI conflicts with information in the uplink- related DCI. Embodiment D7. The network node of any one of Embodiments D1-D6, wherein the received UCI is associated with a hybrid automatic repeat request (HARQ) codebook that is associated with a time span of the HARQ codebook derived from the uplink-related DCI.

Claims

1. CLAIMS1. A method implemented in a user equipment, UE (22), that is configured to communicate with a network node (16), the method comprising: receiving a transmission; receiving (SI 04) control information scheduling transmission of an acknowledgement of reception of the received transmission; and transmitting (SI 06) the acknowledgement in accordance with the control information, wherein the control information is of a type capable of scheduling a data transmission from the UE.

2. The method of claim 1, wherein the control information indicates whether the acknowledgement is to be transmitted on a control channel or on a data channel.

3. The method of any of the preceding claims, wherein the control information indicates that the acknowledgement is to be transmitted on a data channel together with data.

4. The method of claim 3, wherein the control information indicates how to multiplex the acknowledgement onto the data channel.

5. The method of any of claims 3-4, wherein the control information schedules a data transmission from the UE on the data channel.

6. The method of any of claims 1-2, wherein the control information indicates that the acknowledgement is to be transmitted on a data channel without simultaneous data.

7. The method of claim 6, wherein the UE receives a plurality of transmissions, and wherein the control information indicates which of the received transmissions to be acknowledged on the data channel.

8. The method of claim 7, wherein the plurality of transmissions include transmissions corresponding to a plurality of HARQ processes and / or a plurality of component carriers,and wherein control information indicates that all of these transmissions are to be acknowledged on the data channel.

9. The method of any of claims 1-2, wherein the control information indicates that the acknowledgement is to be transmitted on a control channel simultaneously as data transmitted on a data channel.

10. The method of claim 9, wherein the control information schedules a data transmission from the UE on the data channel.

11. The method of any of claims 1-2, wherein the control information indicates that the acknowledgement is to be transmitted on a control channel without simultaneous transmission of data.

12. The method of claim 11, wherein the UE receives a plurality of transmissions, and wherein the control information indicates which of the received transmissions to be acknowledged on the control channel.

13. The method of any of claims 1-2, wherein the control information indicates that the acknowledgement is to be transmitted both on a data channel and on a control channel.

14. The method of any of the preceding claims, wherein the control information is of a type capable of scheduling transmission from the UE in accordance with at least some of the following options: data on a data channel from the UE and no simultaneous acknowledgement from the UE; acknowledgement on a control channel from the UE and no simultaneous data from the UE; data and acknowledgement on a data channel from the UE; data on a data channel from the UE and acknowledgement on a control channel from the UE.

15. The method of claim 14, wherein the control information indicates which of said options applies for the control information.

16. The method of any of the preceding claims, wherein the acknowledgement is transmitted as uplink control information on a control channel or a data channel, and wherein the control information indicates an amount of resources in the control channel or data channel to be used for the uplink control information.

17. The method of any of the preceding claims, wherein the UE receives a plurality of transmissions, and wherein the control information indicates which of the received transmissions to be acknowledged together in a codebook.

18. The method of claim 17, wherein the control information indicates: that transmissions received during a certain time span are to be acknowledged together in the codebook; or that transmissions associated with downlink assignment index, DAI, from 0 to a latest receive total DAI, tDAI, are to be acknowledged together in the codebook.

19. The method of any of claims 1-16, wherein the UE receives a plurality of transmissions, and wherein the UE acknowledges those of the transmission that are received during a preconfigured time span relative to reception of the control information.

20. The method of any of the preceding claims, wherein the control information indicates a size of a codebook to be used for transmitting the acknowledgement.

21. The method of any of claims 1-19, wherein the UE receives a plurality of transmissions, wherein the UE acknowledges, together in a codebook, those of the transmission received during a time span, and wherein the UE indicates the time span to the network node.

22. The method of any of the preceding claims, further comprising: receiving a configuration indicating whether transmissions of acknowledgements are schedulable by control information of a type capable of scheduling a data transmission from the UE and / or by control information of a type capable of scheduling a data transmission to the UE.

23. The method of any of the preceding claims, wherein the UE maintains a first codebook for acknowledgements scheduled by control information of a type capable of scheduling a data transmission from the UE and a second codebook for acknowledgements scheduled by control information of a type capable of scheduling a data transmission to the UE.

24. The method of claim 23, wherein the first and the second codebook both include the acknowledgement of the received transmission.

25. The method of any of the preceding claims, wherein the acknowledgement of the received transmission is hybrid automatic repeat request, HARQ, feedback.

26. The method of any of the preceding claims, wherein the received transmission is a data transmission from the network node, and wherein the method further comprises receiving control information scheduling the received transmission.

27. The method of any of claims 1-25, wherein the received transmission is a command from the network node.

28. A method implemented in a network node (16) that is configured to communicate with a user equipment, UE (22), the method comprising: transmitting a transmission; transmitting (SI 00) control information scheduling transmission of an acknowledgement of reception of the transmitted transmission; and receiving (SI 02) the acknowledgement in accordance with the control information, wherein the control information is of a type capable of scheduling a data transmission from the UE.

29. The method of claim 28, wherein the control information indicates whether the acknowledgement is to be transmitted on a control channel or on a data channel.

30. The method of any of claims 28-29, wherein the control information indicates that the acknowledgement is to be transmitted: on a data channel together with data; or on a data channel without simultaneous data; oron a control channel simultaneously as data transmitted on a data channel; or on a control channel without simultaneous transmission of data; or both on a data channel and on a control channel.

31. The method of any of the preceding claims, wherein: the transmitted transmission is a data transmission to the UE, and the method further comprises transmitting control information scheduling the transmitted transmission; or the transmitted transmission is a command from the network node to the UE.

32. A user equipment, UE (22), configured to communicate with a network node (16), wherein the UE is configured to: receive a transmission; receive control information scheduling transmission of an acknowledgement of reception of the received transmission; and transmit the acknowledgement in accordance with the control information, wherein the control information is of a type capable of scheduling a data transmission from the UE.

33. The UE of claim 32, wherein the UE is configured to perform the method of any of claims 2-27.

34. A user equipment, UE (22), configured to communicate with a network node (16), wherein the UE comprises a radio interface (46) and processing circuitry (50) configured to: receive a transmission; receive control information scheduling transmission of an acknowledgement of reception of the received transmission; and transmit the acknowledgement in accordance with the control information, wherein the control information is of a type capable of scheduling a data transmission from the UE.

35. The UE of claim 34, wherein the radio interface and processing circuitry are configured to perform the method of any of claims 2-27.36 A network node (16) configured to communicate with a user equipment, UE (22), wherein the network node is configured to: transmit a transmission; transmit control information scheduling transmission of an acknowledgement of reception of the transmitted transmission; and receive the acknowledgement in accordance with the control information, wherein the control information is of a type capable of scheduling a data transmission from the UE.

37. The network node of claim 36, wherein the network node is configured to perform the method of any of claims 29-31.

38. A network node (16) configured to communicate with a user equipment, UE (22), wherein the network node comprises a radio interface (30) and processing circuitry (36) configured to: transmit a transmission; transmit control information scheduling transmission of an acknowledgement of reception of the transmitted transmission; and receive the acknowledgement in accordance with the control information, wherein the control information is of a type capable of scheduling a data transmission from the UE.

39. The network node of claim 38, wherein the radio interface and processing circuitry are configured to perform the method of any of claims 29-31.

Images