Patent Description:
The present disclosure generally relates to wireless communications and wireless communication networks.

The architecture for New Radio (NR) (also known as <NUM> or Next Generation) is being discussed in standardization bodies such as 3GPP. The NR networks will support a diverse set of use cases and a diverse set of deployment scenarios. The later includes deployment at both low frequencies (e.g. <NUM> of MHz), similar to LTE today, and very high frequencies (e.g. mm waves in the tens of GHz).

Similar to LTE, NR will use OFDM in the downlink (i.e. from a network node, gNB, eNB, or base station, to a user equipment or UE). In the uplink (i.e. from UE to gNB), both DFT-spread OFDM and OFDM will be supported.

The basic NR physical resource can thus be considered as a time-frequency grid similar to the one in LTE, illustrated in <FIG>, where each resource element corresponds to one OFDM subcarrier during one OFDM symbol interval. Although a subcarrier spacing of Δf = <NUM> is shown in <FIG>, different subcarrier spacing values can be supported in NR. The supported subcarrier spacing values (also referred to as different numerologies) in NR are given by Δf = (<NUM> × <NUM>α) kHz where α is a non-negative integer.

Furthermore, the resource allocation in LTE is typically described in terms of resource blocks, where a resource block corresponds to one slot (<NUM>) in the time domain and <NUM> contiguous subcarriers in the frequency domain. Resource blocks are numbered in the frequency domain, starting with <NUM> from one end of the system bandwidth. For NR, a resource block is also <NUM> subcarriers in frequency but for further study in time domain.

In the time domain, downlink and uplink transmissions in NR will be organized into equally-sized subframes, similar to LTE, as shown in <FIG>. In NR, subframe length for a reference numerology of (<NUM> × <NUM>α) kHz is exactly <NUM>/<NUM>α ms.

The control information associated with the UE accessing the network can be broadcast by a network node (e.g. gNB). Some uncertainty may exist between the UE and the network related to the delivery of this control information.

Document <CIT> discloses a method and apparatus for uplink feedback for operating with a large number of carriers. The method in a wireless transmit/receive unit (WTRU) includes receiving a plurality of transport blocks over a set of a plurality of configured carriers, generating hybrid automatic repeat request (HARQ)-acknowledgment (ACK) feedback for the transport blocks and determining a number of HARQ-ACK feedback bits to use for the HARQ-ACK feedback. Further, the WTRU applies, to the HARQ-ACK feedback bits, Reed-Muller coding on a condition that the number of HARQ-ACK feedback bits is less than or equal to a threshold or convolutional coding on a condition that the number of HARQ-ACK feedback bits is greater than a threshold. The WTRU then transmits the encoded HARQ-ACK feedback bits. In addition, the WTRU conditionally appends cyclic redundancy check (CRC) bits onto the HARQ-ACK feedback bits, and encodes and transmits the CRC bits.

<CIT> discloses a method, devices and systems of multi-subband based transmission. The method for use in a wireless transmit/receive unit (WTRU) includes monitoring a plurality of subbands for subbands that include an enhanced physical downlink control channel (EPDCCH), wherein each subband of the plurality of subbands is made up of a subset of frequency resources in a system bandwidth, and determining whether each of the plurality of subbands is a channel state information (CSI) downlink subband (CSI-subband) for CSI feedback based on whether an EPDCCH is included in a corresponding subband of the plurality of subbands. At least two subbands of the plurality of subbands, in which a corresponding EPDCCH is included, are determined as CSI subbands for CSI feedback.

It is an object of the present disclosure to obviate or mitigate at least one disadvantage of the prior art.

Systems and methods for dynamic PUCCH resource allocation for CSI feedback are provided herein. According to the present disclosure, there are provided methods, a wireless device and a network node according to the independent claims. Developments are set forth in the dependent claims.

In a first aspect of the present disclosure, there is provided a method performed by a wireless device. The method comprises receiving, on a Physical Downlink Control Channel, PDCCH, a downlink-, DL, -related Downlink Control Information, DCI, message including:.

In a second aspect of the present disclosure, there is provided a wireless device comprising a radio interface and processing circuitry configured to perform the method of the first aspect.

In a third aspect of the present disclosure, there is provided a method performed by a network node. The method comprises generating a downlink, DL, -related Downlink Control Information, DCI, message including: - both of a Channel State Information, CSI, request and a DL grant to schedule a Physical Downlink Shared Channel, PDSCH, transmission and - a Physical Uplink Control Channel, PUCCH, resource indicator indicating a Hybrid Automatic Repeat Request Acknowledgement, HARQ-ACK, resource for the scheduled PDSCH transmission; transmitting, on a Physical Downlink Control Channel, PDCCH, the generated DL-related DCI message; and receiving, depending on the a value of the PUCCH resource indicator, the CSI report: - multiplexed with a HARQ-ACK on a PUCCH resource according to first values of the value of the PUCCH resource indicator, and.

In a fourth aspect of the present disclosure, there is provided a network node comprising a radio interface and processing circuitry configured to perform the method of the third aspect.

Whenever in the following disclosure any of the above-stated aspects (corresponding to the independent claims) is disclosed as "optional" (e.g., due to usage of conjunctive terms, such as "can", "may", "should", etc.), it is nevertheless to be read as "mandatory".

Embodiments of the present disclosure will now be described, by way of example only, with reference to the attached Figures, wherein:.

Whenever in this description an "embodiment" is described, reference is to be made to the above figure list to determine whether this is to be read as "embodiment" or "example".

Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

In some embodiments, the non-limiting term "user equipment" (UE) is used and it can refer to any type of wireless device which can communicate with a network node and/or with another UE in a cellular or mobile or wireless communication system. Examples of UE are target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine (M2M) communication, personal digital assistant, tablet, mobile terminal, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, ProSe UE, V2V UE, V2X UE, MTC UE, eMTC UE, FeMTC UE, UE Cat <NUM>, UE Cat M1, narrow band IoT (NB-IoT) UE, UE Cat NB <NUM>, etc. Example embodiments of a UE are described in more detail below with respect to <FIG>.

In some embodiments, the non-limiting term "network node" is used and it can correspond to any type of radio access node (or radio network node) or any network node, which can communicate with a UE and/or with another network node in a cellular or mobile or wireless communication system. Examples of network nodes are NodeB, MeNB, SeNB, a network node belonging to MCG or SCG, base station (BS), multi-standard radio (MSR) radio access node such as MSR BS, eNodeB, gNB network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, RRU, RRH, nodes in distributed antenna system (DAS), core network node (e.g. MSC, MME, etc.), O&M, OSS, Self-organizing Network (SON), positioning node (e.g. E-SMLC), MDT, test equipment, etc. Example embodiments of a network node are described in more detail below with respect to <FIG>.

In some embodiments, the term "radio access technology" (RAT) refers to any RAT e.g. UTRA, E-UTRA, narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT (NR), <NUM>, <NUM>, etc. Any of the first and the second nodes may be capable of supporting a single or multiple RATs.

The term "radio node" used herein can be used to denote a UE or a network node.

In some embodiments, a UE can be configured to operate in carrier aggregation (CA) implying aggregation of two or more carriers in at least one of DL and UL directions. With CA, a UE can have multiple serving cells, wherein the term 'serving' herein means that the UE is configured with the corresponding serving cell and may receive from and/or transmit data to the network node on the serving cell e.g. on PCell or any of the SCells. The data is transmitted or received via physical channels e.g. PDSCH in DL, PUSCH in UL etc. A component carrier (CC) also interchangeably called as carrier or aggregated carrier, PCC or SCC is configured at the UE by the network node using higher layer signaling e.g. by sending RRC configuration message to the UE. The configured CC is used by the network node for serving the UE on the serving cell (e.g. on PCell, PSCell, SCell, etc.) of the configured CC. The configured CC is also used by the UE for performing one or more radio measurements (e.g. RSRP, RSRQ, etc.) on the cells operating on the CC, e.g. PCell, SCell or PSCell and neighboring cells.

In some embodiments, a UE can also operate in dual connectivity (DC) or multi-connectivity (MC). The multicarrier or multicarrier operation can be any of CA, DC, MC, etc. The term "multicarrier" can also be interchangeably called a band combination.

The term "radio measurement" used herein may refer to any measurement performed on radio signals. Radio measurements can be absolute or relative. Radio measurements can be e.g. intra-frequency, inter-frequency, CA, etc. Radio measurements can be unidirectional (e.g., DL or UL or in either direction on a sidelink) or bidirectional (e.g., RTT, Rx-Tx, etc.). Some examples of radio measurements: timing measurements (e.g., propagation delay, TOA, timing advance, RTT, RSTD, Rx-Tx, etc.), angle measurements (e.g., angle of arrival), power-based or channel quality measurements (e.g., path loss, received signal power, RSRP, received signal quality, RSRQ, SINR, SNR, interference power, total interference plus noise, RSSI, noise power, CSI, CQI, PMI, etc.), cell detection or cell identification, RLM, SI reading, etc. The measurement may be performed on one or more links in each direction, e.g., RSTD or relative RSRP or based on signals from different TPs of the same (shared) cell.

The term "signaling" used herein may comprise any of: high-layer signaling (e.g., via RRC or a like), lower-layer signaling (e.g., via a physical control channel or a broadcast channel), or a combination thereof. The signaling may be implicit or explicit. The signaling may further be unicast, multicast or broadcast. The signaling may also be directly to another node or via a third node.

The term "time resource" used herein may correspond to any type of physical resource or radio resource expressed in terms of length of time. Examples of time resources include: symbol, time slot, sub-frame, radio frame, TTI, interleaving time, etc. The term "frequency resource" may refer to sub-band within a channel bandwidth, subcarrier, carrier frequency, frequency band. The term "time and frequency resources" may refer to any combination of time and frequency resources.

Some examples of UE operation include: UE radio measurement (see the term "radio measurement" above), bidirectional measurement with UE transmitting, cell detection or identification, beam detection or identification, system information reading, channel receiving and decoding, any UE operation or activity involving at least receiving of one or more radio signals and/or channels, cell change or (re)selection, beam change or (re)selection, a mobility-related operation, a measurement-related operation, a radio resource management (RRM)-related operation, a positioning procedure, a timing related procedure, a timing adjustment related procedure, UE location tracking procedure, time tracking related procedure, synchronization related procedure, MDT-like procedure, measurement collection related procedure, a CA-related procedure, serving cell activation/deactivation, CC configuration/de-configuration, etc..

<FIG> illustrates an example of a wireless network <NUM> that can be used for wireless communications. Wireless network <NUM> includes UEs 102A-102B and a plurality of network nodes, such as radio access nodes 104A-104B (e.g. eNBs, gNBs, etc.) connected to one or more network nodes <NUM> via an interconnecting network <NUM>. The network <NUM> can use any suitable deployment scenarios. UEs <NUM> within coverage area <NUM> can each be capable of communicating directly with radio access node 104A over a wireless interface. In some embodiments, UEs <NUM> can also be capable of communicating with each other via D2D communication.

As an example, UE 102A can communicate with radio access node 104A over a wireless interface. That is, UE 102A can transmit wireless signals to and/or receive wireless signals from radio access node 104A. The wireless signals can contain voice traffic, data traffic, control signals, and/or any other suitable information. In some embodiments, an area of wireless signal coverage associated with a radio access node 104A can be referred to as a cell <NUM>.

The interconnecting network <NUM> can refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, etc., or any combination of the preceding. The interconnecting network <NUM> can include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof.

In some embodiments, the network node <NUM> can be a core network node <NUM>, managing the establishment of communication sessions and other various other functionalities for UEs <NUM>. Examples of core network node <NUM> can include mobile switching center (MSC), MME, serving gateway (SGW), packet data network gateway (PGW), operation and maintenance (O&M), operations support system (OSS), SON, positioning node (e.g., Enhanced Serving Mobile Location Center, E-SMLC), MDT node, etc. UEs <NUM> can exchange certain signals with the core network node using the non-access stratum layer. In non-access stratum signaling, signals between UEs <NUM> and the core network node <NUM> can be transparently passed through the radio access network. In some embodiments, radio access nodes <NUM> can interface with one or more network nodes over an internode interface.

As discussed, system information including the control information required for a UE <NUM> to access the cell <NUM>, is periodically broadcast by the radio access node(s) <NUM>. Some uncertainty may exist between the UE <NUM> and the network related to the delivery of this system information.

Downlink transmissions are dynamically scheduled, i.e., in each subframe the gNB transmits downlink control information (DCI) about which UE data is to be transmitted to and which resource blocks in the current downlink subframe the data will be transmitted on. This control signaling is typically transmitted in the first one or two OFDM symbols in each subframe in NR. The control information is carried on Physical Control Channel (PDCCH) and data is carried on Physical Downlink Shared Channel (PDSCH). A UE first detects and decodes PDCCH and if a PDCCH is decoded successfully, it the decodes the corresponding PDSCH based on the decoded control information in the PDCCH.

Uplink data transmission are also dynamically scheduled using PDCCH. Similar to the downlink, a UE first decodes uplink grants in PDCCH and then transmits data over the Physical Uplink Shared Channel (PUSCH) based the decoded control information in the uplink grant such as modulation order, coding rate, uplink resource allocation, and etc..

In addition to PUSCH, the Physical Uplink Control Channel (PUCCH) is also supported in NR to carry uplink control information (UCI) such as HARQ (Hybrid Automatic Repeat Request) related Acknowledgement (ACK), Negative Acknowledgement (NACK), or Channel State Information (CSI) feedback.

NR supports carrier aggregation of up to <NUM> component carriers (CCs) in the downlink. Each CC acts as a cell and one of them is a primary cell or carrier. Only the primary carrier may have an associated uplink carrier. In this case, ACK/NACK, SR, and CSI for each downlink component carrier are aggregated and transmitted on the single uplink carrier. The aggregated UCI payload size thus can be quite large.

The main content of a DL-related DCI is the DL grant, which schedules a PDSCH transmission. The DL grant comprises information indicating which frequency-domain resources the PDSCH a UE is scheduled with occupies, the modulation and coding scheme (MCS) is used, HARQ-related information such as redundancy version (RV), New Data Indicator (NDI) and HARQ process number. It may also comprise multi-antenna related information, such as the number of layers in the PDSCH and which DMRS antenna ports are used. It has also been agreed that a PUCCH resource indicator is present in the DCI. The PUCCH resource indicator conventionally indicates which time/frequency/code PUCCH resource the UE shall transmit the HARQ-ACK for the scheduled PDSCH. Two (<NUM>) bits can be used for the PUCCH resource indication field, and each codepoint will indicate one out of four higher layers configured PUCCH resources (in terms of frequency-location, slot offset, etc.).

Also included in the DL-related DCI is an SRS request field, which can trigger transmission of one or more SRS resources in the uplink.

In LTE and likely also for NR, it is possible to transmit a DL-related DCI without an DL grant by indicating that all the codewords (CWs) are turned off. In LTE, this is done by indicating MCS=<NUM> and RV=<NUM> for all the CWs. Similar methods can also be employed for NR. Thus, it may be possible to transmit a DL-related DCI with an SRS triggering request only, without also scheduling PDSCH.

A description of the conventional fields in a DL-related DCI, according to RAN1 discussion, is given in Table <NUM>.

Similar to how the DL-related DCI may comprise an DL grant scheduling PDSCH, the UL-related DCI may comprise a UL grant scheduling a PUSCH transmission for a UE. Many of the fields are similar between DL and UL related DCI. For instance, UL-related DCI comprises information about the physical time-frequency resources the UE shall use for the PUSCH transmission, MSC, HARQ-related information, multi-antenna related information, and so forth. The UL-related DCI also contains a CSI report triggering request field, which can trigger an aperiodic CSI report. This field is present in UL-related DCI as the aperiodic CSI report typically is carried on PUSCH together with the scheduled UL-SCH. A description of the conventional fields in a UL-related DCI, according to RAN1 agreements, is given in Table <NUM>.

In LTE and likely in NR, each codepoint of the CSI request field points to a higher layer configured "CSI report set", which can comprise multiple CSI Report Settings for one or multiple cells, implying that multiple CSI reports may be triggered simultaneously. This is illustrated in Table <NUM> below.

In NR, a UE can be configured with N ≥ <NUM> CSI reporting settings, M ≥ <NUM> Resource settings, and <NUM> CSI measurement setting, where the CSI measurement setting includes L ≥ <NUM> links and value of L may depend on the UE capability. At least the following configuration parameters are signaled via RRC at least for CSI acquisition.

N, M, and L are indicated either implicitly or explicitly.

In each CSI reporting setting, at least: reported CSI parameter(s), CSI Type (I or II) if reported, codebook configuration including codebook subset restriction, time-domain behavior, frequency granularity for CQI and PMI, measurement restriction configurations.

In each of the L links in CSI measurement setting: CSI reporting setting indication, Resource setting indication, quantity to be measured (either channel or interference).

At least, the following are dynamically selected by L1 or L2 signaling, if applicable:.

In LTE, UEs can be configured to report CSI in periodic or aperiodic reporting modes. Periodic CSI reporting is carried on PUCCH while aperiodic CSI is carried on PUSCH. PUCCH is transmitted in a fixed or configured number of PRBs and using a single spatial layer with QPSK modulation. PUSCH resources carrying aperiodic CSI reporting are dynamically allocated through uplink grants carried over PDCCH or enhanced PDCCH (EPDCCH), and can occupy a variable number of PRBs, use modulation states such as QPSK, 16QAM, and <NUM> QAM, as well as multiple spatial layers.

In NR, in addition to periodic and aperiodic CSI reporting as in LTE, semi-persistent CSI reporting can also be supported.

Thus, three types of CSI reporting can be supported in NR as follows:.

Periodic CSI Reporting: CSI is reported periodically by the UE. Parameters such as periodicity and subframe offset are configured semi-statically, by higher layer signaling from the gNB to the UE.

Aperiodic CSI Reporting: This type of CSI reporting involves a single-shot (i.e., one time) CSI report by the UE which is dynamically triggered by the gNB, e.g. by the DCI in PDCCH. Some of the parameters related to the configuration of the aperiodic CSI report is semi-statically configured from the gNB to the UE but the triggering is dynamic.

Semi-Persistent CSI Reporting: Similar to periodic CSI reporting, semi-persistent CSI reporting has a periodicity and subframe offset which may be semi-statically configured by the gNB to the UE. However, a dynamic trigger from gNB to UE may be needed to allow the UE to begin semi-persistent CSI reporting. In some cases, a dynamic trigger from gNB to UE may be needed to command the UE to stop the semi-persistent transmission of CSI reports.

Furthermore, NR can support two types of aperiodic CSI reporting, in addition to the PUSCH-based aperiodic CSI reporting supported by LTE, NR also supports aperiodic CSI reporting on PUCCH (at least for short PUCCH).

Given that NR can support aperiodic CSI reporting on PUCCH, in addition to aperiodic CSI reporting on PUSCH, and also semi-persistent CSI reporting on either of PUSCH and PUCCH, efficient dynamic triggering of CSI reports on PUCCH is required.

In some embodiments, a CSI request field can be introduced in DL-related DCI to support triggering of CSI reports on PUCCH (e.g., the CSI request field can be in addition to the fields shown in Table <NUM>). The already existing PUCCH resource indication field (previously only used for indication of PUCCH resource for HARQ-ACK) can be reused for indication of PUCCH resource for CSI feedback/report.

In some embodiments, the PUCCH resource indication field can be interpreted differently depending on if a DL grant and/or a CSI request is present in the DL-related DCI.

Accordingly, dynamic PUCCH resource allocation for aperiodic CSI feedback can be achieved without increasing the DCI overhead, enabling increased scheduling flexibility and larger multi-user capacity.

One possible benefit to supporting aperiodic CSI reporting on short PUCCH is to allow for more scheduling flexibility, as even WB CSIs can be triggered aperiodically, and it can be wasteful to spend an entire PUSCH transmission (spanning multiple OFDM symbols) if only transmitting a couple of <NUM> bits of WB CSI. Another motivation is to allow for same-slot CSI feedback where the DCI containing the aperiodic CSI request trigger is received in the beginning of a slot and the CSI feedback is transmitted on a short PUCCH at the end of the slot.

In some embodiments discussed herein, aperiodic CSI (A-CSI) reports are triggered with DCI by indicating which CSI report(s) shall be reported in the CSI request field.

Conventionally, the CSI request field is present in UL-related DCI, as the CSI report in that case is multiplexed with UL-SCH on PUSCH and the UL-related DCI contains the PUSCH resource allocation. However, when an A-CSI report is transmitted on PUCCH, a CSI request field can be included in the DL-related DCI. First, for the case of same-slot CSI reporting, the UE is likely being scheduled with PDSCH in the same slot as it is triggered with an immediate CSI report (otherwise, there is no benefit with immediate reporting). Thus, if the CSI request field is not present in the DL-related DCI containing the DL grant, both a UL-related DCI and a DL-related DCI would need to be transmitted in the same slot. Second, the DL-related DCI already contains a PUCCH resource indicator field for HARQ-ACK, indicating the timing offset and frequency/code location of the PUCCH containing ACK/NACK.

In some embodiments, this field can be re-used for indicating the PUCCH resource to be used when transmitting the A-CSI report.

In one embodiment, the A-CSI report is always piggybacked on the same PUCCH that is used to transmit the HARQ-ACK. That is, the HARQ-ACK bits and the A-CSI bits are bundled and multiplexed to the same PUCCH resource that is indicated in the PUCCH resource indication field in DCI. While this embodiment can simplify UE implementation and reduce specification complexity, it may limit flexibility of the gNB. It may also be wasteful in terms of UL resources. As HARQ-ACK is only a few bits, while WB CSI can be in the order of <NUM> bits, different frequency-allocations and/or PUCCH formats could be required depending on if "HARQ-ACK only" or "HARQ-ACK + CSI" are multiplexed in the PUCCH.

It could potentially be beneficial to transmit the HARQ-ACK and CSI that was triggered with the same DCI on different PUCCH resources. For example, a CSI report with many antenna ports could be triggered, requiring some CSI process delay by the UE so that the CSI report is transmitted in, for example, slot n + <NUM>, while the ACK/NACK could be transmitted in slot n. Thus, it may be beneficial to indicate different PUCCH timing offsets for CSI and ACK/NACK. It may also be beneficial if such flexibility can be introduced without increasing DCI overhead.

Therefore, in some embodiments, the PUCCH resource indicator field can be interpreted differently depending on the presence of a DL grant (i.e. if a PDSCH is scheduled by the DCI or if all the CWs are turned off) and/or the presence of a CSI request in the DCI (i.e. if one or more CSI report is triggered or if triggering state <NUM> is indicated, meaning that no CSI report is triggered).

An example of one such embodiment is illustrated in Table <NUM> below. In this example, if bits <NUM> are indicated in the PUCCH resource indicator field, PUCCH resource #<NUM> is used if the DCI contains DL grant only and not a CSI request while PUCCH resource #<NUM> is used if DCI contains CSI request only and no DL grant. If DCI contains both DL grant and CSI request, PUCCH resource #<NUM> is used. Further in the example, if bits <NUM> are indicated, PUCCH resource #<NUM> is used for HARQ-ACK and PUCCH resource #<NUM> is used for CSI, if both are triggered simultaneously, separate PUCCH resources are used for the respective transmissions.

In some embodiments, the higher layer configuration of a PUCCH resource indicator triggering state (i.e. trigger00, trigger01,. ) can comprise two or more information fields. Each information field can comprise a reference to a separate PUCCH resource. Which information field (i.e. which PUCCH resource) a UE shall use depends on if the DCI comprises a CSI request trigger or not. In some embodiments, the configuration of the trigger state can comprise two information fields: a first field that shall be used when CSI request is present and a second field that shall be used when CSI request trigger is not present in DCI.

In other embodiments, three information fields can be used: a first field that shall be used when only DL grant is present, a second field that shall be used when DL grant is not present but CSI request trigger is present, and a third field that shall be used when both DL grant and CSI request is present. In some such embodiments, the information field that shall be used when both DL grant and CSI request is present in DCI comprises two PUCCH resources, a first and a second. The first PUCCH resource shall be used for transmitting HARQ-ACK while the second PUCCH resource shall be used for transmitting CSI.

It will be appreciated by those skilled in the art that the embodiments herein have discussed with respect to aperiodic CSI feedback on PUCCH, but may equally well be applied for semi-persistent CSI feedback on PUCCH, when triggered by a DCI. In such a case, the PUCCH resource to use for the semi-persistent CSI feedback can be indicated in the PUCCH resource indicator field. In some such embodiments, only frequency and code resources for the PUCCH are indicated while the periodicity and slot offset for the semi-persistent CSI report can be semi-statically configured with another higher layer parameter. In other embodiments, the slot offset can also be indicated.

<FIG> is an example signaling diagram. An access node, such as gNB <NUM>, can generate parameters for a control message, such as a downlink DCI message (step <NUM>). In some embodiments, this can include adding a CSI request field to indicate to a wireless device to trigger at least one CSI report. This can further include using a PUCCH resource indication field to indicate, to the wireless device, PUCCH resource(s) for said CSI report(s). Access node <NUM> transmits the configured control message (e.g. downlink DCI) to the wireless device <NUM> (step <NUM>). Wireless device <NUM> can determine uplink control resource(s) in accordance with the received downlink DCI message (step <NUM>). In some embodiments, this can include interpreting the PUCCH resource indication field in accordance with the downlink DCI message. The interpretation can depend on at least one of a scheduled downlink grant and/or a CSI request in the downlink DCI message. Wireless device <NUM> can subsequently transmit uplink control information in the determined uplink control resource(s) (step <NUM>).

<FIG> is a flow chart illustrating a method which can be performed in a wireless device, such as UE <NUM>. The method can include:
Step <NUM>: Receiving a control message. The control message can be a downlink-related DCI message. The control message can be received from an access node, such as gNB <NUM>. The control message can be received on the PDCCH.

In some embodiments, the control message can include a first information indicating whether to trigger at least one CSI report. The first information can be a CSI request field. In some embodiments, the control message can include a second information indicating at least one UL control resource. The second information can be a PUCCH resource indicator field. The second information can indicate at least one PUCCH resource to be used for CSI report/feedback. The control message can further include grant/scheduling information associated with a downlink transmission. In some embodiments, the downlink transmission can be a PDSCH transmission.

Step <NUM>: Determining to trigger at least one CSI report in accordance with the received control message. In some embodiments, this can include determining to trigger the CSI report(s) in accordance with the first information (CSI request field in the downlink-related DCI message). In some embodiments, this can further include determining one or more uplink control resources (e.g. PUCCH resources) in accordance with the second information (PUCCH resource indicator in the downlink-related DCI message). Determining the uplink control resource(s) can be further in accordance with at least one of the first information and/or the grant/scheduling information associated with a downlink transmission.

In some embodiments, the uplink control resource(s) are determined in accordance with whether the first information triggers a CSI report(s), or not. In some embodiments, the uplink control resource(s) are determined in accordance with whether a downlink transmission is scheduled, or not. For example, determining the uplink control resource can include determining a first PUCCH resource responsive to a CSI request being indicated in the downlink-related DCI message. In another example, determining the uplink control resource can include determining a second PUCCH resource responsive to a CSI request being not indicated in the downlink-related DCI message. In some embodiments the first PUCCH resource is different from the second PUUCH resource. In another example, determining the uplink control resource can include determining at least a third PUCCH resource responsive to both a CSI request being indicated and a downlink grant being included in the downlink DCI message. In some embodiments the third PUCCH resource is different from the first and second PUCCH resources.

Step <NUM>: Transmitting uplink control information. The uplink control information can be transmitted in the determined at least one uplink control resource (e.g. PUCCH resource). The uplink control information can be transmitted to an access node, such as gNB <NUM>). The transmitted uplink control information can include at least one of a HARQ-ACK and/or a CSI report. In some embodiments, a CSI report can be multiplexed with a HARQ-ACK on the determined uplink control resource. In other embodiments, the CSI report and the HARQ-ACK can be transmitted on different PUCCH resources. In some embodiments, the HARQ-ACK can be scheduled by the downlink-related DCI and the HARQ-ACK resource can be determined in accordance with the PUCCH resource indicator.

In some embodiments, the method of <FIG> can further include obtaining, by the wireless device, configuration information associated with interpreting the CSI request field and/or the PUCCH resource indicator. In some embodiments, the wireless device can obtain the configuration information prior to receiving the DL-related DCI message. This can include obtaining, by higher layer signaling, a first information mapping a first bitfield in a downlink control message to triggering of one or more CSI reports; and obtaining, by higher layer signaling, a second information mapping a second bitfield in a downlink control message to an indication of one or more uplink control resource(s). Accordingly, the wireless device can interpret a received DL-related DCI message in accordance with the obtained configuration information.

It will be appreciated that one or more of the above steps can be performed simultaneously and/or in a different order. Also, steps illustrated in dashed lines are optional and can be omitted in some embodiments.

<FIG> is a flow chart illustrating a method which can be performed in a network node, such as access node <NUM>. The method can include:
Step <NUM>: Generating a downlink control message. In some embodiments, the control message can be a DL-related DCI message. Generating the control message can include generating/configuring parameters including a CSI request field and/or a PUCCH resource indicator field. The CSI request field can indicate whether to trigger CSI feedback on the PUCCH. The control message can further include a grant to schedule a PDSCH transmission.

In some embodiments, the PUCCH resource indicator can include at least a first field indicating a first PUCCH resource to use when a CSI report is requested/triggered by the control message, and a second field indicating a second PUCCH resource to use when a CSI report is not requested/not triggered by the control message. In some embodiments, the PUCCH resource indicator can include a third field indicating at least a third PUCCH resource to use when both a CSI report is request and a downlink grant is included by the control message.

Step <NUM>: Transmitting the generated control message. In some embodiments this includes transmitting, on a PDCCH, the generated downlink-related DCI message.

Step <NUM>: Receiving uplink control information. The uplink control information can include at least one CSI report. The uplink control information can be received on a PUCCH resource in accordance with the generated downlink control message.

<FIG> is a block diagram of an example wireless device, UE <NUM>, in accordance with certain embodiments. UE <NUM> includes a transceiver <NUM>, processor <NUM>, and memory <NUM>. In some embodiments, the transceiver <NUM> facilitates transmitting wireless signals to and receiving wireless signals from radio access node <NUM> (e.g., via transmitter(s) (Tx), receiver(s) (Rx) and antenna(s)). The processor <NUM> executes instructions to provide some or all of the functionalities described above as being provided by UE, and the memory <NUM> stores the instructions executed by the processor <NUM>. In some embodiments, the processor <NUM> and the memory <NUM> form processing circuitry.

The processor <NUM> may include any suitable combination of hardware to execute instructions and manipulate data to perform some or all of the described functions of UE <NUM>, such as the functions of UE <NUM> described above. In some embodiments, the processor <NUM> may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and/or other logic.

The memory <NUM> is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor <NUM>. Examples of memory <NUM> include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processor <NUM> of UE <NUM>.

In some embodiments, communication interface <NUM> is communicatively coupled to the processor <NUM> and may refer to any suitable device operable to receive input for network node <NUM>, send output from network node <NUM>, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. The communication interface <NUM> may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

Other embodiments of UE <NUM> may include additional components beyond those shown in <FIG> that may be responsible for providing certain aspects of the UE's functionalities, including any of the functionalities described above and/or any additional functionalities (including any functionality necessary to support the solution described above). As just one example, UE <NUM> may include input devices and circuits, output devices, and one or more synchronization units or circuits, which may be part of the processor. Input devices include mechanisms for entry of data into UE <NUM>. For example, input devices may include input mechanisms, such as a microphone, input elements, a display, etc. Output devices may include mechanisms for outputting data in audio, video and/or hard copy format. For example, output devices may include a speaker, a display, etc..

In some embodiments, the UE <NUM> can comprise a series of functional units or modules configured to implement the functionalities of the UE described above. Referring to <FIG>, in some embodiments, the UE <NUM> can comprise a downlink control module <NUM> for receiving a downlink control message and for processing said control message, and an uplink control module <NUM> for determining an uplink control resource and for transmitting uplink control information.

It will be appreciated that the various modules may be implemented as combination of hardware and software, for instance, the processor, memory and transceiver(s) of UE <NUM> shown in <FIG>. Some embodiments may also include additional modules to support additional and/or optional functionalities.

<FIG> is a block diagram of an example network node, e.g. access node <NUM>, in accordance with certain embodiments. Access node <NUM> may include one or more of a transceiver <NUM>, processor <NUM>, memory <NUM>, and network interface <NUM>. In some embodiments, the transceiver <NUM> facilitates transmitting wireless signals to and receiving wireless signals from UE <NUM> (e.g., via transmitter(s) (Tx), receiver(s) (Rx), and antenna(s)). The processor <NUM> executes instructions to provide some or all of the functionalities described above as being provided by an access node <NUM>, the memory <NUM> stores the instructions executed by the processor <NUM>. In some embodiments, the processor <NUM> and the memory <NUM> form processing circuitry. The network interface <NUM> communicates signals to backend network components, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), core network nodes or radio network controllers, etc..

The processor <NUM> may include any suitable combination of hardware to execute instructions and manipulate data to perform some or all of the described functions of access node <NUM>, such as those described above. In some embodiments, the processor <NUM> may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and/or other logic.

The memory <NUM> is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor <NUM>. Examples of memory <NUM> include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

In some embodiments, the network interface <NUM> is communicatively coupled to the processor <NUM> and may refer to any suitable device operable to receive input for access node <NUM>, send output from access node <NUM>, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. The network interface <NUM> may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

Other embodiments of access node <NUM> may include additional components beyond those shown in <FIG> that may be responsible for providing certain aspects of the access node's functionalities, including any of the functionalities described above and/or any additional functionalities (including any functionality necessary to support the solutions described above). The various different types of network nodes may include components having the same physical hardware but configured (e.g., via programming) to support different radio access technologies, or may represent partly or entirely different physical components.

In some embodiments, the network node <NUM>, which can be, for example, a radio access node, may comprise a series of modules configured to implement the functionalities of the network node <NUM> described above. Referring to <FIG>, in some embodiments, the network node <NUM> can comprise a configuration module <NUM> for generating a downlink control message and a transmission module <NUM> for transmitting said generated control message.

It will be appreciated that the various modules may be implemented as combination of hardware and software, for instance, the processor, memory and transceiver(s) of network node <NUM> shown in <FIG>. Some embodiments may also include additional modules to support additional and/or optional functionalities.

Processors, interfaces, and memory similar to those described with respect to <FIG> and <FIG> may be included in other network nodes (such as core network node <NUM>). Other network nodes may optionally include or not include a wireless interface (such as the transceiver described in <FIG> and <FIG>).

It was agreed to support aperiodic CSI reporting on short PUCCH in RAN1#<NUM>-AH3. One motivation for this is to allow for more scheduling flexibility, even WB CSIs can be triggered aperiodically and it can be wasteful to spend an entire PUSCH transmission (spanning multiple OFDM symbols) if only transmitting a couple of <NUM> bits of WB CSI. Another motivation is to allow for same-slot CSI feedback (i.e. Y=<NUM>).

An A-CSI report must be triggered with DCI by indicating which CSI report(s) shall be reported in the CSI request field. Conventionally, the CSI request field is present in UL-related DCI, as the CSI report in that case is multiplexed with UL-SCH on PUSCH and the UL-related DCI contains the PUSCH RA. However, when the A-CSI report is transmitted on PUCCH, it may be appropriate to include a CSI request field in the DL-related DCI. Firstly, for the case same-slot CSI reporting (Y=<NUM>), the UE is likely being scheduled with PDSCH in the same slot as it is triggered with an immediate CSI report (otherwise, there is little benefit with immediate reporting). Thus, if the CSI request field is not present in the DL-related DCI containing the DL grant, both a UL-related and DL-related DCI would need to be transmitted in the same slot. Secondly, the DL-related DCI already contains a PUCCH resource indicator field for HARQ-ACK, indicating the timing offset and frequency/code location of the PUCCH containing ACK/NACK. This field can be re-used for indicating the PUCCH resource for A-CSI.

One approach would be to always piggyback the A-CSI report on the same PUCCH that is used to transmit the HARQ-ACK. However, this would limit the flexibility for the gNB. It can also be wasteful in terms of UL resources. As HARQ-ACK is only a few bits, while WB CSI can be on the order of <NUM> bits, different frequency-allocations and/or PUCCH formats could be required depending on if "HARQ-ACK only" or "HARQ-ACK + CSI" are multiplexed in the PUCCH. Furthermore, it could potentially be beneficial to transmit the HARQ-ACK and CSI that was triggered with the same DCI on different PUCCH resources. For instance, a CSI report with many antenna ports could be triggered, requiring some CSI processing delay by the UE so that the CSI report is transmitted in e.g. slot n+<NUM>, while the ACK/NACK could be transmitted in slot n. Thus, different PUCCH timing offsets would need to be indicated. Such flexibility can be introduced without increasing DCI overhead. The PUCCH resource indicator field can simply be interpreted differently depending on the presence of DL grant and/or CSI request in the DCI. This is illustrated in Table <NUM> above. In this example, if bits <NUM> are indicated, PUCCH resource #<NUM> is used if the DCI contains DL grant only and not a CSI request while PUCCH resource #<NUM> is used if DCI contains CSI request only and no DL grant. If DCI contains both DL grant and CSI request, PUCCH resource #<NUM> is used. Further in the example, if bits <NUM> are indicated, PUCCH resource #<NUM> is used for HARQ-ACK and PUCCH resource #<NUM> is used for CSI, if both are triggered simultaneously, separate PUCCH resources are used for the respective transmissions.

Proposal <NUM>: To support aperiodic CSI feedback on PUCCH, a CSI request field can be configured to be present in DL-related DCI.

In the agreed WF, support of A-CSI on PUCCH for CSI triggering offsets larger than zero was left as a working assumption. It should be noted that Y=<NUM> is the most difficult case for a UE to handle, as it requires fast CSI calculation. Since the mechanisms for A-CSI on PUCCH is introduced in the spec regardless, limiting its support to only Y=<NUM> seems like a very artificial restriction. Therefore, we propose:.

The agreement in RAN1#<NUM>-AH3 only added support for A-CSI on short PUCCH. However, the same mechanism could be used to support A-CSI on long PUCCH as well, which could be beneficial for reliability if e.g. CSI and HARQ-ACK is bundled together in a single PUCCH. Furthermore, it increases scheduling flexibility at the gNB.

In RAN1#<NUM>, it was agreed that SP-CSI potentially could be supported on short PUCCH / long PUCCH / PUSCH, with potential down-selection. In RAN1#<NUM>-AH3 it was agreed that SP-CSI is supported on PUSCH, with LTE SPS-like triggering. Thus, the question remains if SP-CSI is supported on short / long PUCCH as well.

In RAN1#<NUM>-AH2 Qingdao, it was agreed that Type I sub-band CSI can be carried on either one of PUSCH and long PUCCH. Since only WB CSI is supported for periodic CSI feedback, this implies that either A-CSI or SP-CSI (or both) must support being carried on long PUCCH for the agreement to be fulfilled. Furthermore, according to agreement in RAN1#<NUM>-AH3, the use of short or long PUCCH resource for a PUCCH-based CSI report is configured, meaning that either both short/long PUCCH or none of them must be supported for SP-CSI.

In order to keep down the number of reporting modes, we believe that it is sufficient to support SP-CSI on PUSCH and A-CSI on long PUCCH. Therefore, if SP-CSI is supported on PUCCH can be further considered.

Some embodiments may be represented as a software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied therein). The machine-readable medium may be any suitable tangible medium including a magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause processing circuitry (e.g. a processor) to perform steps in a method according to one or more embodiments. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described embodiments may also be stored on the machine-readable medium. Software running from the machine-readable medium may interface with circuitry to perform the described tasks.

Claim 1:
A method performed by a wireless device (<NUM>), the method comprising:
receiving (<NUM>), on a Physical Downlink Control Channel, PDCCH, a downlink-, DL, -related Downlink Control Information, DCI, message including:
- a Physical Uplink Control Channel, PUCCH, resource indicator indicating a Hybrid Automatic Repeat Request Acknowledgement, HARQ-ACK, resource for the scheduled PDSCH transmission and
- both of a DL grant to schedule a Physical Downlink Shared Channel, PDSCH, transmission and a Channel State Information, CSI, request;
determining (<NUM>) to trigger a CSI report in accordance with the CSI request in the DL-related DCI message;
determining a PUCCH resource for the triggered CSI report in accordance with a value of the PUCCH resource indicator in the DL-related DCI message; and
transmitting (<NUM>), depending on the value of the PUCCH resource indicator, the CSI report:
- multiplexed with a HARQ-ACK on the determined PUCCH resource according to first values of the value of the PUCCH resource indicator, and
- on the determined PUCCH resource and a HARQ-ACK on a different PUCCH resource according to second values of the value of the PUCCH resource indicator,
wherein the PUCCH resource indicator indicates a time and frequency resource.