HK1167977B - Signaling uplink control information in lte-a - Google Patents

Description

Signaling uplink control information in LTE-A

Cross Reference to Related Applications

The present application claims benefit from U.S. provisional application No.61/218,782 filed on 6/19/2009 and U.S. provisional application No.61/220,017 filed on 6/24/2009, which are incorporated herein by reference in their entirety.

Background

To support higher data rates and spectral efficiency, third generation partnership project (3GPP) Long Term Evolution (LTE) systems have been introduced into 3GPP release 8 (R8). (LTE release 8 may be referred to herein as LTE R8 or R8-LTE). In LTE, transmission on the uplink is performed using single carrier frequency division multiple access (SC-FDMA). In particular, SC-FDMA used in LTE uplink is based on discrete fourier transform spread orthogonal frequency division multiplexing (DFT-S-OFDM) technology. The terms SC-FDMA and DFT-S-OFDM used later may be used interchangeably.

In LTE, a wireless transmit/receive unit (WTRU), alternatively referred to as a User Equipment (UE), transmits on the uplink using only a limited contiguous set of subcarriers assigned in a Frequency Division Multiple Access (FDMA) arrangement. For example, if the total Orthogonal Frequency Division Multiplexing (OFDM) signal or system bandwidth in the uplink consists of useful subcarriers numbered 1 through 100, a first designated WTRU may be assigned to transmit on subcarriers 1-12, a second WTRU may be assigned to transmit on subcarriers 13-24, and so on. While each of the different WTRUs may transmit only a subset of the available transmission bandwidth, an evolved node-B (enodeb) serving the WTRU may receive the composite uplink signal over the entire transmission bandwidth.

LTE-advanced, which includes LTE release 10(R10) and may include later releases, such as release 11, also referred to herein as LTE-a, LTE R10, or R10-LTE, is an enhancement to the LTE standard that provides a fully compatible 4G upgrade path for LTE and 3G networks. In LTE and LTE-a, some associated layer 1/layer 2(L1/2) Uplink Control Information (UCI) is needed to support UL transmissions, Downlink (DL) transmissions, scheduling, multiple-input multiple-output (MIMO), etc. In LTE-a, power setting of the uplink channel may be performed separately and independently. There is a need in the art for systems and methods to provide uplink control information and address power issues that may arise when multiple uplink channels are used.

Disclosure of Invention

Methods and systems for transmitting Uplink Control Information (UCI) in an LTE-advanced system are disclosed. A User Equipment (UE) may determine whether uplink control information should be transmitted on the PUCCH and PUSCH (a subset of bits is transmitted on the PUCCH and the remaining bits are transmitted on the PUSCH) based on whether the number of bits in the UCI is less than or equal to a threshold provided to the UE. The UCI bits may be transmitted on the PUCCH if the number of UCI bits is less than or equal to a threshold, and the UCI bits may be transmitted on the PUSCH and the PUCCH in the same subframe if the number of UCI bits is greater than the threshold. In another embodiment, the number of UCI bits may be compared to another higher threshold and if the number of UCI bits exceeds the other higher threshold, all UCI bits may be transmitted on the PUSCH. In another embodiment, if all UCI bits fit on PUCCH, the bits may be transmitted on PUCCH. If all bits do not fit on PUCCH, the bits may be transmitted on PUCCH and PUSCH in the same subframe. In another embodiment, the relative size of UCI (i.e., the size of UCI payload compared to the capacity size of the shared channel (e.g., PUSCH)) may be determined and UCI bits may be transmitted on PUSCH only if the relative size is below a threshold.

In another embodiment, the type of UCI bits may be determined and if a particular type of bits is present (e.g., ACK/NACK bits), the particular type of bits may be transmitted on one channel (e.g., PUCCH) while the remaining bits may be transmitted on another channel (e.g., PUSCH). Alternatively, the number of active or alternatively configured downlink component carriers (DLCCs) and the use of supported transmission modes in LTE release 8 may be considered. If the number of DL CCs is not 1 or the transmission mode supported in LTE release 8 is not used, a subset of UCI bits may be transmitted on PUCCH, while the remaining bits in the same subframe may be transmitted on PUSCH. If the number of DLCCs is 1 and the transmission mode supported in LTE release 8 is used, UCI may be evaluated to determine whether the content contains a particular type of UCI bits (e.g., ACK/NACK, CQI/PMI, RI) and which channel(s) to use for transmitting these bits. When multiple DL CCs are available (which are active or alternatively configured), the priority or primary DL CC may also be evaluated, and UCI bits associated with the primary or highest priority DL CC may be transmitted on PUCCH, while the remaining bits may be transmitted on PUSCH.

The amount of power required to transmit uplink control information on multiple channels may also be evaluated. If the UE determines that transmitting UCI bits on PUSCH and PUCCH would exceed the maximum power threshold, the UE may transmit UCI bits on only one of PUSCH and PUCCH, or reduce PUSCH and/or PUCCH power. In embodiments where multiple PUSCHs are available, various ways may be used to determine which PUSCH should be used to transmit UCI bits, including determining an appropriate PUSCH based on UCI payload size, PUSCH data payload size, or the relationship between UCI payload size and the carrying capacity of the available PUSCHs. These and other aspects of the disclosure are described in more detail below.

Drawings

The following detailed description of the disclosed embodiments can be better understood when read in conjunction with the appended drawings. For the purpose of illustration, there is shown in the drawings exemplary embodiments; however, the subject matter of the present application is not limited to the specific elements and devices disclosed. In the drawings:

FIG. 1 illustrates a non-limiting exemplary user equipment, eNodeB, and MME/S-GW that can implement the methods and systems disclosed herein for signaling uplink control information;

FIG. 2 illustrates a non-limiting exemplary network environment in which the methods and systems for signaling uplink control information disclosed herein can be implemented;

FIG. 3 illustrates a non-limiting exemplary system for transmitting ACK/NACK bits for different downlink carriers;

fig. 4 illustrates a non-limiting exemplary method for using multiple PUCCH RB resources in a PUCCH region for UCI transmission;

fig. 5 illustrates a non-limiting exemplary method for transmitting UCI from a UE on PUCCH and PUSCH in a system using downlink coordinated multipoint transmission (DL COMP);

fig. 6 illustrates a non-limiting exemplary method of determining how to signal UCI;

fig. 7 illustrates another non-limiting exemplary method of determining how to signal UCI;

fig. 8 illustrates another non-limiting exemplary method of determining how to signal UCI;

fig. 9 illustrates another non-limiting exemplary method of determining how to signal UCI;

fig. 10 illustrates another non-limiting exemplary method of determining how to signal UCI;

fig. 11 illustrates another non-limiting, exemplary method of determining how to signal UCI;

fig. 12 illustrates another non-limiting exemplary method of determining how to signal UCI;

fig. 13 illustrates another non-limiting exemplary method of determining how to signal UCI;

fig. 14 illustrates another non-limiting exemplary method of determining how to signal UCI;

fig. 15 illustrates another non-limiting exemplary method of determining how to signal UCI;

fig. 16 illustrates another non-limiting, exemplary method of determining how to signal UCI.

Detailed Description

FIG. 1 illustrates a non-limiting exemplary UE101 that can implement the subject matter of the present application and features of LTE-A. The UE101 may be any type of Wireless Transmit Receive Unit (WTRU) including a mobile phone, a smart phone, a Personal Data Assistant (PDA), a laptop computer, or any other device that may communicate wirelessly with one or more other devices or networks. In some embodiments, the UE101 may be configured to communicate with an LTE-a network or system. The UE101 may be configured with a processor 140 that may be communicatively coupled with a memory 150 and may draw power from a power source (e.g., a battery 160). The power supply 160 can also provide power to any or all of the other components of the UE 101. The processor 140 may be configured to perform the UCI signaling and related functions disclosed herein, as well as any other functions disclosed herein and/or any other functions that may be performed by a processor configured in the UE. The memory 150 may be configured to store data including computer-executable instructions for performing any of the functions disclosed herein or any other function that may be performed by a UE. The UE101 may also be configured with one or more antennas 110a-d that may communicate data received from one or more transceivers 120a-d to a base station, eNode B, or other network device, and may provide data from these devices to one or more transceivers 120 a-d.

The transceivers 120a-d and/or the antennas 110a-d may be communicatively coupled to an antenna mapping/precoding module 130. The antenna mapping/precoding module 130 may be communicatively coupled to the processor 140. Note that any or all of the components shown in fig. 1 may be physically the same components or combined into a single physical unit, or alternatively may be physically separate. For example, the antenna mapping/precoding module 130, the processor 140, and the transceivers 120a-d may be physically configured on a single microchip, or each may be configured on a separate microchip. Any variations of these configurations are considered to be within the scope of the present disclosure.

The UE101 may be configured to wirelessly communicate with the enodeb 170. In addition to the components that may be found in a typical enodeb, the enodeb 170 may include a processor 173, which may be any processor or processors that may be configured to perform the enodeb functions and/or subject matter disclosed herein. The processor 173 may be communicatively connected to memory 174, which may be any type of memory or combination of memory types, including volatile memory and non-volatile memory. The eNode B170 may also be configured with transceivers 172a-d that may be communicatively connected to antennas 171a-d, the antennas 171a-d configured to facilitate wireless communications with the UE101 in an LTE or LTE-A system, for example. Multiple transmit and/or receive antennas may be configured on the enodeb 170 to facilitate MIMO and/or other techniques that may utilize the multiple antennas.

The enodeb 170 may be communicatively connected to a mobility management entity/serving gateway (MME/S-GW)180 via one or more wireless or wired communication connections. MME/S-GW 180 may be configured with processor 181, and processor 181 may be any processor or processors configured to perform the MME/S-GW functions and/or subject matter disclosed herein. The processor 181 may be communicatively coupled to the memory 182, and the processor 182 may be any type of memory or combination of memory types, including volatile and non-volatile memory. In one embodiment, the UE101, eNode B170, and/or MME/S-GW 180 are configured for UCI signaling in the LTE-A system disclosed herein.

DFT-S-OFDM may be used as a means of communication from the UE101 to the eNode B170 (i.e., in the uplink). DFT-S-OFDM is a form of OFDM transmission with the additional constraint that the time-frequency resources assigned to a UE comprise a set of subcarriers that are contiguous in frequency. The LTE uplink may not include a Direct Current (DC) subcarrier. The LTE uplink may include a mode of operation in which frequency hopping may be applied by the UE for transmission. In LTE release 8(R8) Uplink (UL), certain associated layer 1/layer 2(L1/2) Uplink Control Information (UCI) is needed to support UL transmission, Downlink (DL) transmission, scheduling, multiple input multiple output (MIMIO), and the like. For example, the UE101 may be configured to periodically and/or non-periodically provide UCI to the enodeb 170. The UCI may include hybrid automatic repeat request (HARQ) acknowledgement/negative acknowledgement (ACK/NACK), which may be 1 or 2 bits; a channel status report comprising a Channel Quality Indicator (CQI), a Precoding Matrix Indicator (PMI), and/or a Rank Indicator (RI), which may be 4-11 bits when transmitted on a Physical Uplink Control Channel (PUCCH); and a Scheduling Request (SR), which may be 1 bit. These examples of the number of bits of these UCI types correspond to the number of bits of these types in LTE release 8. These types of bit numbers are not limited to these values and other implementations are also considered to be within the scope of the present disclosure.

In the embodiments and examples described herein, which relate specifically to CQI, PMI, and RI bit types, the embodiments can be easily extended to include additional UCI bit types that are UE-supported and reported periodically or aperiodically. These embodiments and examples may also be readily extended to replace any one or more of the CQI, PMI, and RI bit types with other types of UCI bits that the UE may support and report periodically or aperiodically.

In LTE release 8, for example, the UE101 may transmit UCI in one of two ways. In the absence of assigned Physical UL Shared Channel (PUSCH) resources in a subframe, the UE101 may transmit UCI using Physical UL Control Channel (PUCCH) resources. UCI signaling may occur on a Physical Uplink Shared Channel (PUSCH) and may be multiplexed with data on the PUSCH when there is UL data or the UE is transmitting data on the PUSCH. However, in release 8, simultaneous transmission of PUCCH and PUSCH is not supported. Furthermore, UE-specific higher layer signaling may not enable simultaneous transmission of ACK/NACK and CQI by the UE. In this case, the CQI is discarded and only ACK/NACK is transmitted using PUCCH, which may result in some reduction in scheduling and rate adaptation accuracy.

In LTE-advanced (LTE-a) introduced in 3GPP release 10(R10), simultaneous PUSCH and PUCCH transmission by, for example, the UE101 may be supported and the single carrier constraint on the UL waveform may be relaxed. In release 10, frequency continuous and frequency discontinuous resource allocation on each UL component carrier may be supported.

Compared to LTE, in LTE-a, new features are considered, including coordinated multi-point transmission (COMP), higher order (order) DL MIMO, bandwidth extension, and relaying, and it is expected that the UCI size (number of UCI bits) will be increased. For example, to support high order MIMO (e.g., 8x8MIMO) and/or COMP, a large number of channel state reports (CQI/PMI/RI) may be fed back to the serving enodeb (and possibly the neighboring enodeb in COMP implementations). The use of asymmetric bandwidth extension will further increase the UCI overhead. Therefore, the payload size of release 8LTE PUCCH is not sufficient to carry the increased UCI overhead in LTE-a (even for a single DL component carrier). UCI signaling in LTE-a is more flexible than signaling in LTE, allowing more configuration of UCI signaling in LTE-a. For this reason, and since the UCI size (UCI bit number) may be larger in LTE-a, a new configuration for supporting the increased UCI size may be required. In some embodiments of the present disclosure, the capability of simultaneous PUSCH and PUCCH transmission is leveraged to convey UCI signaling that may be generated in an LTE-a system or any other system.

Furthermore, since the power settings for PUSCH and PUCCH are done separately, some rules for LTE-a UCI signaling are proposed here for embodiments that utilize simultaneous PUCCH and PUSCH transmission in one subframe for situations where the sum of the power levels of PUSCH and PUCCH meets or exceeds a specified maximum transmit power.

Note that the Physical Uplink Control Channel (PUCCH) used herein may be LTE or LTE-APUCCH, which is an uplink channel carrying uplink control information. Alternatively, PUCCH as used herein may be any channel or channels or other wireless communication means that may be dedicated or non-dedicated to transmitting control information for the uplink. The Physical Uplink Shared Channel (PUSCH) used herein may be LTE or LTE-APUSCH, which is an uplink channel carrying user data (i.e., SCH data). Alternatively, PUSCH, as used herein, may be any channel or channels or other wireless communication means that may be dedicated or non-dedicated to communicating user data on the uplink. The PUSCH used here may also carry control information. Uplink Control Information (UCI) as used herein may be specific LTE or LTE-a control information, or UCI may be any control information used in any wireless system carried over any type of channel or wireless communication means. All such embodiments are considered to be within the scope of the present disclosure.

Fig. 2 illustrates a wireless communication system/access network 200, which may be configured as an entire LTE or LTE-a system or as a portion of an LTE or LTE-a system. The network 200 may include an evolved universal terrestrial radio access network (E-UTRAN) 250. The E-UTRAN 250 may include UEs 210, which UEs 210 may be any type of UE or WTRU, including the UE101 in FIG. 1; and one or more evolved node bs (enodebs) 220a, 220B, and 220c, the enodebs 220a, 220B, and 220c may be any device configured to perform the functions of an enode B, such as the enode B170 of fig. 1. As shown in fig. 2, the UE 210 may communicate with an enodeb 220 a. enode bs 220a, 220B, and 220c may interface with each other using an X2 interface. The enodebs 220a, 220B and 220c may also be connected to Mobility Management Entities (MMEs)/serving gateways (S-GWs) 230a and/or 230B via an S1 interface. MME/S-GWs 230a and 230b may be any device configured to perform the functions of an MME/S-GW (e.g., MME/S-GW 180 in FIG. 1). Although a single UE 210 and three enode bs 220a, 220B, and 220c are shown in fig. 2, it is understood that any number and combination of wireless and wired devices may be included in the network 200.

In some embodiments implemented in LTE-a systems, it is desirable to communicate UL Control Information (UCI) from a UE to an enodeb to support UL user data transmissions and other UL transmissions, DL user data transmissions and other DL transmissions, scheduling data, MIMO data, and so forth. The UCI may include, but is not limited to, HARQ ACK/NACK, channel status report, CQI/PMI/RI, and/or Scheduling Request (SR). It should be noted that the term "user data" as used herein may be used interchangeably with "SCH (shared channel) data". The UE may transmit UCI on PUCCH or PUSCH. Table 1 shows PUCCH formats defined for LTE and corresponding UCI content that may be used in some embodiments. Formats 2a and 2b are only used to support normal cyclic prefixes. In some embodiments, the same format may be used when transmitting UCI on PUSCH.

Table 1PUCCH formats and corresponding UCI content

Time and frequency resources that the UE may use to report UCI may be controlled by the enodeb. Some UCI (e.g., CQI, PMI, and RI) reports may be periodic or aperiodic. In some embodiments, aperiodic reports can provide data similar to that provided by periodic reports, as well as additional data. In this embodiment, if the periodic and aperiodic reports occur in the same subframe, the UE may be configured to transmit only the aperiodic report in that subframe.

The CQI and PMI payload sizes for each PUCCH reporting mode may be predetermined, for example as provided by the 3GPP standard specification. The payload size of the other UCI types for each PUCCH reporting mode may be predetermined, for example, as provided by the 3GPP standard specification.

To handle the increased UCI size and the larger amount of Uplink Control Information (UCI) that may occur in the LTE-a system, some embodiments introduced by the present disclosure may be used. Some embodiments disclosed herein take advantage of the simultaneous PUSCH and PUCCH transmission capabilities of LTE-a.

In one embodiment, an alternative configuration of signaling UCI from a UE in an LTE-a system may be used in addition to the LTE UCI signaling method. In a first such embodiment, multiple PUCCH transmissions may be used for multiple UCI fields or reports. Multiple PUCCH transmissions (or resources) for multiplexing multiple UCI fields/reports may be implemented, whereby the multiple PUCCH transmissions are code or frequency multiplexed. For example, in LTE, Channel Quality Indicator (CQI) is discarded when its transmission collides with Scheduling Request (SR) transmission in the same subframe. However, in LTE-a, it is possible to transmit CQI and SR simultaneously in the same subframe using Code Division Multiplexing (CDM) (i.e., using different orthogonal phase rotations of the cell-specific sequence) or Frequency Division Multiplexing (FDM) (i.e., using different Resource Blocks (RBs)). Thus, the UE may multiplex PUCCH format 1 (possibly with 1a/1b) and format 2 (possibly with 2a/2b) to transmit them over multiple PUCCH resources. Alternatively, a large number of LTE-a UCI may be transmitted from the UE in consideration of multiple PUCCH transmissions.

In embodiments where UCI signaling is performed over multiple PUCCH resources, CDM, FDM, or Time Division Multiplexing (TDM), or any combination of these, may be used to signal UCI. In one embodiment, when a large number of UCI are required, UCI may be transmitted from a UE through multiple PUCCH resources using CDM (i.e., different phase rotations of a cell-specific sequence). In this embodiment, different orthogonal phase rotations (equivalent to cyclic shifts) of the cell-specific length-12 frequency (or time) domain sequence may be applied to each bit (or group of bits or different control fields) of the UCI. For example, in the case of asymmetric bandwidth extension (e.g., 2 DL component carriers and 1 UL component carrier), HARQ ACK/NACKs for different DL component carriers may be transmitted in a single UL carrier using different phase rotations of the cell-specific sequence. Alternatively or additionally, as shown in fig. 3, the same phase rotation sequence may be used but different orthogonal superposition sequences w for carrier 1 and carrier 2, respectively, are used¹And w²To transmit ACK/NACK bits (ACK/NACK bits 310 and 320) for different DL carriers (on the same time-frequency resource).

The enodeb may configure the UE to multiplex multiple UCI fields/reports in a subframe through layer 1 or 2(L1/2) signaling or higher layer signaling. In embodiments using multiple PUCCH transmissions, if the total transmit power of the multiple PUCCHs exceeds the maximum transmit power of the UE (denoted Pmax) (or Pmax + P _ threshold, where P _ threshold is a threshold), the UE may piggyback (piggyback) to the LTE UE procedure (i.e., by dropping low priority feedback reports, such as CQI/PMI).

The enodeb may use blind detection on multiple PUCCH transmissions to determine which PUCCH transmissions are applied in a subframe (UCI field). Alternatively, some of the POWER reduction/backoff (back-off) approaches disclosed in U.S. patent application No.12/703,092 entitled "APPARATUS AND METHOD FOR UPLINK POWER supply A WIRELESS TRANSMITTER/recever UNIT utlizingmultplier," filed on 9/2/2010, may be used, with some modifications, AND may be applied in some embodiments. For example, after calculating the power level of each PUCCH, if the sum of these powers exceeds Pmax, the respective transmit powers may be adjusted with equal power or relative power (depending on the priority of the respective channels) to meet the maximum power limit. Another option for power setting of multiple PUCCHs is to modify LTE PUCCH power control, e.g. introduce power offsets for the individual PUCCHs. For these decisions, exceeding the maximum allowed CC transmit power may be considered instead of or in addition to exceeding Pmax.

In an alternative embodiment, UCI signaling over multiple PUCCH resources may be implemented using FDM. In this embodiment, each bit (or a group of bits such as ACK/NACK bits and CQI bits, or different control fields) of UCI may be transmitted using a different RB pair (i.e., PUCCH resource) within a pre-configured PUCCH region. Fig. 4 illustrates an example of using multiple PUCCH RB resources (FDM based) in PUCCH region 410 to transmit a large number of UCI (e.g., multiple UCI reports), whereby ACK/NACK is transmitted over RB 420 (corresponding m 0), while CQI/PMI/RI is transmitted over a different RB (e.g., RB430, corresponding m 2) in the same subframe. Alternatively or additionally, in the case of asymmetric bandwidth extension (e.g., 2 DL component carriers and 1 UL component carrier), UCI bits for different DL component carriers may be transmitted over different RB pairs (e.g., m 0, 2 for carrier 1 and carrier 2, respectively).

In another embodiment, UCI signaling over multiple PUCCH resources may be implemented using TDM. In this embodiment, each bit (or a group of bits, such as ACK/NACK bits and CQI bits, or different control fields) of UCI may be transmitted using a Time Division Basis (TDB) on an OFDM symbol, slot, or subframe basis.

Note that in the above embodiments of UCI signaling over multiple PUCCH resources, the enodeb may configure the UE through higher layer signaling (or L1 signaling) regarding which PUCCH resources (time/frequency/code) are allocated to the UE. In these embodiments, the R8LTE PUCCH format specified in the 3GPP standard specification may be maintained; that is, backward compatibility to R8LTE is maintained. Further, in the case of CDM (and FDM), CM (cubic metric) may increase depending on the number of resources (code/phase rotations or RBs) in use. Therefore, the impact of CM on the power setting of PUCCH may be considered, i.e. the power backoff is applied by the CM increase amount, if any.

In another embodiment, UCI signaling over PUCCH and PUSCH in the same subframe (UCI transmitted from the UE on PUSCH and PUCCH, e.g., a large amount of UCI) may be implemented, e.g., when asymmetric carrier aggregation, higher order DL MIMO, and/or COMP is used. For signaling UCI on PUSCH and PUCCH in the same subframe (simultaneous PUCCH and PUSCH transmission of UCI), ACK/NACK and/or SR may be multiplexed with CQI/PMI/IR, whereby ACK/NACK and/or SR may be transmitted on PUCCH while CQI/PMI/RI signaling is performed on PUSCH in the same subframe (periodic or aperiodic) (or vice versa). In some embodiments, a UE without user data to transmit may be configured to send UCI without UL data on PUSCH. For example, a UE in DL COMP may transmit UCI (including ACK/NACK, CQI/PMI/RI, and SR) associated with a serving (anchor) cell over a PUSCH scheduled for the serving cell, while in the same subframe the UE may transmit other control information (e.g., CQI/PMI) targeted for a non-serving (anchor) cell over a pre-defined PUCCH for a recipient cell, or vice versa.

Fig. 5 illustrates an example of transmitting UCI from a UE on PUCCH and PUSCH in DL COMP. In this example, assume that the UE has UL shared channel (UL-SCH) data transmitted in a subframe. If the UE does not have any data to transmit at this time, UCI without UL data is transmitted on the PUSCH. Alternatively or additionally, in case of asymmetric CA (e.g., 1 UL carrier and N DL carriers, where N > 1), the UE may transmit UCI associated with the DL anchor carrier over PUSCH or PUCCH. Meanwhile, the UE may transmit UCI for the DL non-anchor carrier through other physical channels (e.g., channels not used for the DL anchor carrier). Alternatively, the UE may transmit UCI for DL non-anchor carriers over PUSCH on different UL Component Carriers (CCs).

In an embodiment of the LTE-a system, power setting of the PUSCH and PUCCH may be separately performed, respectively. In the case where UCI is transmitted through PUSCH and PUCCH in the same subframe, when Pmax is reached (i.e., the case of negative power headroom), a power backoff approach (including the power reduction described in the referenced U.S. patent application No.12/703,092, such as equal power reduction, relative power reduction, or power reduction using priority based on the channel (and/or UCI type)) may be used to meet the maximum power limit. Alternatively or additionally, a UE transmitting UCI using PUSCH and PUCCH and detecting that Pmax is reached may transition to a method of transmitting UCI using multiple PUCCH resources as described herein. In another alternative embodiment, the UE may transmit UCI using only PUSCH. Alternatively, the UE may transmit UCI using only PUCCH, possibly discarding low priority UCI fields such as CQI/PMI (if any). For these decisions, exceeding the maximum allowed CC transmit power may be considered instead of or in addition to exceeding Pmax.

In another embodiment, simultaneous periodic PUCCH and aperiodic PUSCH transmission for UCI may be implemented. In the legacy LTE (R8) system, if a periodic CQI/PMI/RI report collides with an aperiodic CQI/PMI/RI, the periodic CQI/PMI/RI report is discarded in the subframe. However, the UE may be configured to transmit the aperiodic and periodic reports in the same subframe when necessary. For example, in asymmetric CA, a UE may be configured to perform periodic CQI/PMI/RI reporting associated with a DL anchor carrier using PUCCH and to perform aperiodic CQI/PMI/RI reporting associated with a DL non-anchor carrier using PUSCH in the same subframe, or vice versa. When Pmax is reached (i.e., the case of negative power headroom), the UE may discard the aperiodic CQI/PMI/RI report on PUSCH. Alternatively, the UE may discard periodic CQI/PMI/RI reports on the PUCCH. For these decisions, exceeding the maximum allowed CC transmit power may be considered instead of or in addition to exceeding Pmax.

In another embodiment, a large amount of UCI may be transmitted on the PUSCH. When the UCI payload size is too large (e.g., the sum of the number of HARQ ACL/NACK bits and the number of payload bits for CQI/PMI/RI is greater than a threshold) to accommodate PUCCH resources, UCI with or without UL-SCH data may be sent on PUSCH (depending on whether the UE is scheduled for data transmission), similar to LTE UCI signaling on PUSCH when the UE has been scheduled for data transmission of PUSCH. In this embodiment, UCI need not be carried for UEs that are to be scheduled for data transmission on PUSCH. Instead, the UE may be configured through higher layer signaling or L1/2 signaling when UCI is to be carried on PUSCH.

The enodeb may configure the UE to transmit UCI on PUCCH and PUSCH or not, e.g., depending on the UE's capabilities, DL/UL configuration/service, channel conditions, PUSCH/PUCCH resource availability, and/or UE transmit power availability. This configuration may be given to the UE through L1/2 signaling or higher layer signaling. For transmitting UCI on PUCCH and PUSCH in the same subframe, after calculating the power levels of PUCCH and PUSCH separately, if the sum of these powers exceeds Pmax, a power backoff approach (including those described in U.S. patent application No.12/703,092 referenced herein) may be used so that the respective channel transmit powers may be adjusted/reduced with equal or relative power (depending on the priority of the respective channels), or a predefined offset, to meet the maximum power limit. In another alternative embodiment, the UE may transmit UCI only on PUCCH, possibly discarding low priority UCI fields such as CQI/PMI. In yet another embodiment, the UE may transmit all required UCI fields with or without uplink shared channel (UL-SCH) data on PUSCH only, depending on whether the UE has been scheduled for data transmission scheduling. In any of these embodiments, the enodeb may use blind detection on the various physical channels (i.e., PUCCH and PUSCH) to determine which physical channel(s) (or UCI field) to transmit in the subframe. For these decisions, exceeding the maximum allowed CC transmit power may be considered instead of or in addition to exceeding Pmax.

In an alternative embodiment, legacy LTE UCI signaling may be performed by UEs with LTE-like DL/UL configurations (e.g., one-to-one DL/UL spectrum mapping, no COMP). UCI overhead may be similar to LTE R8. However, unlike LTE R8, the UE may transmit HARQ ACK/NACK on PUCCH (in one embodiment to improve ACK/NACK reliability) while transmitting aperiodic CQI/PMI/RI on PUSCH in the same subframe.

In another alternative embodiment, a new PUCCH format with higher order modulation (16QAM) may be used to support larger UCI sizes. These new PUCCH formats may be defined using higher order modulation. As shown in table 2, a new PUCCH format (format 3, 4/4a/4b/4c) is introduced using 16 QAM. PUCCH format 3 may be used to carry 4-bit ACK/NACK (and possibly SR). For example, a 4-bit ACK/NACK may be used in carrier aggregation (e.g., 2 DL carriers and 1 UL carrier using SM MIMO). The PUCCH format 4/4a/4b/4c can be used for feeding back CQI/PMI/RI bits of 40 coded bits (with ACK/NACK in 4/4a/4b/4c) in LTE-A. For the new format disclosed herein, the power setting of the PUCCH may include a power offset to accommodate the use of higher order modulation 16QAM (i.e., to reflect the fact that different modulation schemes require different SINRs)

Table 2 extended PUCCH formats

Note that in all of the above embodiments using LTE-a UCI signaling, the enodeb may configure the UE to transmit UCI through L1/2 signaling or higher layer signaling.

In an alternative embodiment, simultaneous PUCCH and SRS transmission may be used for LTE-a systems that support simultaneous PUCCH (and PUSCH) and SRS transmission in SRS symbol positions (last OFDM symbol). In this embodiment, the UE may transmit SRS even if SRS and PUCCH formats 1/1a/1b (including normal PUCCH format 1/1a/1b) and/or 2/2a/2b (and possibly format 3/4/4a/4b/4c as proposed herein) and transmissions occur in the same subframe that simplifies these transmissions in LTE-a systems.

In another embodiment, UCI signaling may be performed in an LTE-a system implementing UL MIMO. Some MIMO modes for PUSCH may be used, including Spatial Multiplexing (SM) MIMO (e.g., open-loop and closed-loop SM MIMO), Beamforming (BF), and transmit diversity (e.g., Cyclic Delay Diversity (CDD), space-time block code (STBC), space-frequency block code (SFBC), Spatial Orthogonal Resource Transmit Diversity (SORTD), etc.). An LTE-a system configured according to the present disclosure may use any of the following MIMO modes for UCI signaling. For UCI transmission on PUCCH, any of the following MIMO options may be implemented:

beamforming with one layer (in this case, enodeb provides codebook or PMI feedback for UE);

-CDD transmission (tx) diversity;

-STBC/SFBC/SORTD；

antenna switching (in this case, antenna switching may be performed on an OFDM symbol or slot basis); and

when implementing simultaneous PUSCH and PUCCH transmission in UL MIMO, where UCI is transmitted on PUCCH, any of the above MIMO options may be used for PUCCH, regardless of the MIMO mode used for PUSCH.

For UCI transmission on PUSCH, in one embodiment, the UL MIMO scheme for the UCI portion in PUSCH may be applied independently of the UL MIMO for the data portion, where the MIMO scheme for the UCI portion may be any one of:

-beam forming with one layer;

-CDD tx diversity;

-STBC/SFBC；

antenna switching (in this case, antenna switching may be performed on an OFDM symbol or slot basis);

-an antenna selection; and

the same MIMO mode can be used for the UCI part as used for the data part of PUSCH.

In another embodiment, the UE may transmit all UCI bits on PUSCH only, where large UCI sizes may be used for LTE-AUCI transmission.

The methods and systems will be described below to provide more detailed embodiments of simultaneous PUCCH/PUSCH UCI transmission. Methods and systems are provided that allow a UE to determine which, if any, UCI bits are transmitted on the PUCCH and which, if any, UCI bits are transmitted on the PUSCH. For a UE with user data to be transmitted on a PUSCH, UCI transmitted on the PUSCH may be transmitted with the data. For PUSCH transmission without user data, only UCI may be transmitted on PUSCH. In the following embodiments, the UCI bits may include UCI for a specified subframe for all active (or configured) downlink component carriers (DL CCs). Based on various factors (e.g., scheduling, enodeb requests, and DL transmissions), UCI bits for a given DL CC may include one or more of: ACK/NACK bits (either actual bits or bits reserved for ACK/NACK (even if not transmitted)), CQI bits, PMI bits, RI bits, other types of feedback bits (e.g., long-term (also referred to as outer loop) PMI or short-term (also referred to as inner loop) PMI), and any other control bits that the UE may send to the radio network. Different DL CCs may have different UCI bit types to be transmitted in a given subframe. Any one or more DL CCs may have no UCI bits to be transmitted in a designated subframe. The UCI bits may also include a control bit type that is not particularly related to DL CCs.

Note that CQI and PMI reports are typically reported together and are referred to herein as CQI/PMI reports. However, the report may be reported separately, and the embodiments described herein may be readily extended to such embodiments. As a variation of each of the methods and embodiments described herein, if multiple PUCCHs are allocated in a given subframe and allowed to carry UCI, the PUCCH may be extended to refer to multiple PUCCHs.

In one embodiment, the decision on how to transmit UCI may be made based on the number of UCI bits to be transmitted within a subframe (also referred to as UCI payload size). Fig. 6 illustrates a method of implementing this embodiment. At block 610, a number of UCI bits to transmit is determined. In one embodiment, this determination may exclude any aperiodic CQI/PMI/RI reporting bits and any other aperiodic reporting bits. Other embodiments may include these aperiodic report bits.

At block 620, it is determined whether the number of UCI bits is less than or equal to some number N. N may be preconfigured on the UE or signaled to the UE by the enodeb. The value of N may be a function of the PUCCH formats, and thus, there may be different values of N for each PUCCH format. If the number of UCI bits is less than or equal to N, the UE may prepare to transmit all UCI bits on PUCCH, at block 630. If the number of UCI bits is greater than N, the UE may prepare to transmit a subset of UCI bits on PUCCH and the remaining UCI bits on PUSCH at block 640. For example, the UE may prepare to transmit ACK/NACK bits on PUCCH and transmit the remaining UCI bits (e.g., CQI, PMI, and RI bits) on PUSCH. Alternatively, at block 650, it may be determined whether the number of UCI bits is greater than N ', where N' > N. N' may be preconfigured on the UE or signaled to the UE by the enodeb. The value of N 'may be a function of the PUCCH formats, and thus there may be a different value of N' for each PUCCH format. In this embodiment, if the number of UCI bits is greater than N', the UE may prepare to transmit all UCI bits on PUSCH and not on PUCCH, at block 660. If the number of UCI bits is greater than N but less than or equal to N', the UE may prepare to transmit a subset of UCI bits on PUCCH and the remaining UCI bits on PUSCH at block 640. In another alternative embodiment, if it is determined at block 620 that the number of UCI bits is greater than N, the UE may prepare to transmit all UCI bits on PUSCH and not on PUCCH at block 660.

Note that these UCI bits may be transmitted without further adjustment, in addition to other changes or determinations that may need to be made. In this disclosure, the UE may be described as "preparing to transmit" the UCI bits rather than merely transmitting these bits to allow for the possibility of additional adjustments prior to UCI bit transmission. For example, the UE may prepare to transmit UCI bits using PUCCH and PUSCH, but may then determine that the transmission will reach a power threshold (described in detail below) and thus may actually transmit UCI bits using only one of PUCCH and PUSCH.

In an alternative embodiment, the UE may determine whether the UCI payload fits on the allocated PUCCH to determine how the UE will transmit UCI. Figure 7 illustrates a method of implementing such an embodiment. At block 710, the number of UCI bits to transmit (also referred to as the size of the UCI payload) is determined. In one embodiment, this determination may exclude any aperiodic CQI/PMI/RI reporting bits and any other aperiodic reporting bits. Other embodiments may include these aperiodic report bits.

At block 720, it is determined whether all UCI bits will fit on the allocated PUCCH. If all UCI bits will fit on the allocated PUCCH, the UE may prepare to transmit all UCI bits on PUCCH and not on PUSCH at block 730. If the number of UCI bits does not fit on PUCCH, the UE may prepare to transmit a subset of these bits on PUCCH and the remaining bits on PUSCH at block 740. For example, the UE may prepare to transmit ACK/NACK bits on PUCCH and transmit the remaining UCI bits (e.g., CQI, PMI, and RI bits) on PUSCH. As another example, the UE may prepare to transmit ACK/NACK bits for all DL CCs and all non-ACK/NACK bits (e.g., CQI, PMI, and RI bits) for as many DL CCs as will fit on the PUCCH and transmit non-ACK/NACK bits (e.g., CQI, PMI, and RI bits) for other DL CCs on the PUSCH. When determining whether UCI bits will fit on an allocated PUCCH, the UE may consider all allowed PUCCH formats for that PUCCH.

In another embodiment, the UE may compare the UCI payload size to one or more of the data payload size or the PUSCH size (which may also be referred to as PUSCH carrying capacity) to determine how the UE will transmit UCI. The PUSCH size may be measured using one or more factors, such as the number of RBs, the number of OFDM symbols, the number of physical coded bits, or some combination of these or other factors. Fig. 8 illustrates a method of implementing this embodiment. At block 810, a payload size (number of bits) of the UCI to be transmitted may be determined. In one embodiment, this determination may exclude any aperiodic CQI/PMI/RI reporting bits as well as any other aperiodic reporting bits. Other embodiments may include these aperiodic report bits.

At block 820, the UE may determine a relationship between the UCI payload size and one or more of the data payload size and the PUSCH size. For example, the UE may compare a relative size (e.g., percentage) of the UCI payload relative to the PUSCH size or a relative size (e.g., percentage) of the UCI payload relative to the data payload to a threshold N to determine how to transmit UCI. N may be preconfigured on the UE or signaled to the UE through the enodeb. For example, if the percentage of UCI payload size relative to PUSCH size or the percentage of UCI payload size relative to data payload size is less than the threshold N, the UE may prepare to transmit all UCI on PUSCH at block 830. If the percentage of UCI payload size relative to PUSCH size or the percentage of UCI payload size relative to data payload size is greater than or equal to the threshold N, the UE may prepare to transmit some UCI bits on PUCCH and other UCI bits on PUSCH at block 840, or the UE may prepare to transmit all UCI bits on PUCCH at block 850.

In an alternative embodiment, the UE may compare the PUSCH size to a threshold to determine how the UE will transmit UCI. The PUSCH size may be measured using one or more factors, such as the number of RBs, the number of OFDM symbols, the number of physical coded bits, or some combination of these or other factors. Since this determination is independent of the UCI payload size, block 810 may be skipped. At block 820, the size of PUSCH may be compared to a threshold N. N may be preconfigured on the UE or signaled to the UE by the enodeb. If the carrying capacity of the PUSCH is greater than the specified threshold N, the UE may prepare to transmit all UCI on the PUSCH at block 830. In the case of a large PUSCH, the performance penalty of combining UCI with data on the PUSCH may be reduced, so it is desirable in this case to transmit all UCI on PUSCH and avoid potential power limitations of the simultaneous PUSCH-PUCCH due to Maximum Power Reduction (MPR) effects. If the capacity of the PUSCH is less than or equal to N, the UE may prepare to transmit some UCI bits on the PUCCH and other UCI bits on the PUSCH at block 840. Alternatively, the UE may prepare to transmit all UCI bits on the PUCCH at block 850.

In other embodiments, if the UE is allocated PUSCH and has no user data to send, the UE may prepare to transmit UCI on PUSCH or on a combination of PUCCH and PUCSH depending on UCI payload size. Fig. 9 illustrates a method of implementing this embodiment. At block 910, it is determined that no user data is available for transmission. At block 920, the number of UCI bits to transmit is determined. At block 930, it is determined whether all UCI bits will fit on PUSCH. If so, the UE may prepare to transmit all UCI on PUSCH at block 940. If the number of UCI bits will not fit on the PUSCH, the UE may prepare to transmit a subset of UCI (e.g., ACK/NACK bits) on the PUCCH and transmit the remaining UCI bits on the PUSCH at block 950. Alternatively, when the number of UCI bits does not fit on the PUSCH, the UE may prepare to transmit all UCI bits on the PUCCH at block 950. Note that this may only be possible if the carrying capacity of the PUCCH is larger than that of the PUSCH. In these embodiments, PUSCH is preferred over PUCCH when UCI bits will fit, as transmitting UCI on PUSCH does not affect the performance of PUSCH when the UE has no data to send.

As a variation of any of these embodiments, if the UCI bits to be transmitted include CQI, PMI, or RI bits associated with aperiodic CQI/PMI, or RI reports, the UE may exclude the UCI bits from the determination of the number of bits to be transmitted and/or determine which bits may be transmitted on the PUCCH. In this embodiment, the UE will always transmit CQI, PMI and RI bits associated with aperiodic CQI/PMI and RI reports on the PUSCH. This embodiment is ideal when aperiodic reports are much larger than periodic reports and are not likely to fit on PUCCH. If additional aperiodic report types are defined in the future or for R10 release, the UE may be configured to also exclude bits for these reports in this way and always transmit these bits on the PUSCH.

For example, if the number of UCI bits excluding any aperiodic CQI/PMI and RI report bits is less than or equal to some number N, or alternatively less than or equal to the carrying capacity of the PUCCH, the UE may prepare to transmit all UCI bits (except for any aperiodic CQI/PMI and RI report bits) on the PUCCH and may prepare to transmit aperiodic CQI/PMI and RI report bits on the PUSCH. If the number of UCI bits excluding any aperiodic CQI/PMI and RI reporting bits is greater than N, or alternatively greater than the carrying capacity of the PUCCH, the UE may prepare to transmit a subset of these bits on the PUCCH and the remaining bits on the PUSCH. For example, in one embodiment, the UE may prepare to transmit ACK/NACK bits on PUCCH and all CQI, PMI, and RI bits (for periodic and aperiodic reporting) on PUSCH. Alternatively, if the number of UCI bits excluding any aperiodic CQI/PMI and RI report bits is greater than N '(where N' is greater than N), the UE may prepare to transmit all UCI bits on the PUSCH and not on the PUCCH. In another alternative embodiment, if the number of UCI bits excluding any aperiodic CQI/PMI and RI report bits is greater than N, the UE may prepare to transmit all UCI bits on the PUSCH and not on the PUCCH. N and N' may each be preconfigured on the UE or signaled to the UE by the enodeb. Each of the N and N 'values may be a function of the PUCCH format, and thus there may be different N and N' values for each PUCCH format.

Note that for any of the embodiments disclosed above, the UE may consider the allowed PUCCH formats for the allocated PUCCH when determining the carrying capacity of the PUCCH. In each embodiment, if scheduling is such that the same type of periodic and aperiodic UCI reports are transmitted simultaneously for a given DL CC, the UE may omit the type of periodic report for that CC from the transmission and UCI payload size determination.

In other embodiments, the UE may determine how the UE will transmit UCI based on the type of UCI bits it needs to transmit, and the determination may be based on UCI type priority. In one such embodiment, as shown in fig. 10, at block 1010, a bit type in the UCI may be determined. At block 1020, it is determined whether there are ACK/NACK bits in the UCI bits to be transmitted. If the UCI bits to be transmitted contain ACK/NACK bits, the UE may prepare to transmit the ACK/NACK bits on the PUCCH and all other types of UCI bits on the PUSCH at block 1030. Since ACK/NACK bits are probably the most important bits, they can be transmitted with better performance on PUCCH than PUSCH.

Alternatively, as shown in fig. 11, the UE may be configured to know which types of UCI bits fit together on the PUCCH in each PUCCH format and determine how to transmit UCI based on this knowledge. At block 1110, the UE may determine a bit type in the UCI to transmit. At block 1120, the UE may select the highest priority type of combination that fits together, and in one embodiment, may maximize the number of high priority bits to be transmitted on the PUCCH. At block 1130, the UE may prepare to transmit the combination of the highest priority types that fit together on the PUCCH using the appropriate PUCCH format. Note that in many embodiments, the ACK/NACK has the highest priority, the RI (or equivalent) has the second highest priority, and the priority of the CQI/PMI (or equivalent) is only next to it. The UE may transmit all other types of UCI on the PUSCH.

In further embodiments, the UE may determine how the UE will transmit UCI bits based on a Downlink (DL) configuration, e.g., including the number of active (or configured) DL CCs and/or DL transmission modes, e.g., using a multi-antenna technique. In one such embodiment, if the UE determines that the number of DL CCs is 1 and the DL transmission mode is a transmission mode supported in R8, the UE may prepare to transmit all UCI on PUSCH and not on PUCCH. Fig. 12 shows an alternative embodiment using DL configuration. At block 1210, it is determined whether the number of DL CCs is equal to 1 and the DL transmission mode is a transmission mode supported in R8-LTE. If not, e.g., if the number of DL CCs is greater than 1, the UE may prepare to transmit a subset of (aggregated) UCI bits on PUCCH and the remaining UCI bits on PUSCH at block 1215. The UE may determine which bits to transmit on the PUCCH and which bits to transmit on the PUSCH according to other methods and embodiments described herein.

If there is only one DL CC and the DL transmission mode is a transmission mode supported in R8-LTE, it is determined whether UCI contains ACK/NACK bits in block 1220. If so, the UE may prepare to transmit ACK/NACK bits on the PUCCH at block 1230. At block 1240, it is determined whether there are periodic CQI/PMI and periodic RI bits in the UCI. If so, the UE may prepare to transmit periodic RI bits on PUCCH and CQI/PMI bits on PUSCH in block 1250. At block 1260, a determination is made whether there are periodic CQI/PMI bits and no periodic RI bits. If so, the UE may prepare to transmit periodic CQI/PMI bits on the PUCCH at block 1270. At block 1280, it is determined whether there are periodic RI bits and no periodic CQI/PMI bits. If so, at block 1290, the UE may prepare to transmit periodic RI bits on PUCCH. If the UE determines that there are aperiodic UCI reporting bits, the UE prepares to transmit these bits on the PUSCH.

In some embodiments, the UE may determine how the UE will transmit UCI based on the UL transmission mode (e.g., number of transmit antenna ports) and/or PUSCH configuration (including continuous PUSCH RB allocation versus non-continuous PUSCH RB allocation). In one such embodiment, if the UE is configured to transmit PUSCH (carrying two codewords) using multiple antenna ports in a subframe, the UE may prepare to transmit CQI/PMI bits on PUSCH and transmit the remaining UCI bits (e.g., ACK/NACK bits and/or RI bits) on PUCCH. Alternatively, the UE may transmit all UCI bits on PUSCH and not on PUCCH.

In other embodiments, if the UE is given a non-continuous PUSCH RB allocation grant, the UE may prepare to transmit all UCI on PUSCH and not on PUCCH. Otherwise (i.e., case of continuous PUSCH RB allocation), the UE may prepare to transmit UCI bits using one or more of the methods described herein.

In some embodiments, there may be the same type of periodic and aperiodic UCI reports requested for DL CCs (or scheduled for transmission) in the same frame. In this case, the UE may transmit (or prepare to transmit) aperiodic UCI reporting bits for the CC on the PUSCH and may discard (not transmit) this type of periodic report for the CC. Fig. 13 illustrates a method of implementing this embodiment. At block 1310, it is determined that there are periodic and aperiodic reports of the same type requested for the DL CC (or scheduled for transmission) in the same subframe. At block 1320, the UE may discard (not transmit) the type of periodic report for the CC. At block 1330, the remaining UCI content may be transmitted or prepared for transmission in some embodiments using one or more methods disclosed herein.

In some embodiments, there may be periodic and aperiodic UCI reports requested for different DL CCs in the same subframe. For example, there may be a periodic UCI report requested for one DL CC while there may be an aperiodic UCI report requested for another DL CC. In this case, the UE may transmit (or prepare to transmit) periodic UCI reporting bits on the PUCCH and aperiodic UCI reporting bits on the PUSCH, or vice versa.

In other embodiments, the UE may use DL CC priorities to determine how the UE will transmit UCI, with the primary DL CC having the highest priority. Fig. 14 illustrates a method of implementing this embodiment. At block 1410, the UE may determine whether there are any UCI bits for the primary DL CC in the UCI bits. If not, the UE may prepare to transmit all UCI on PUSCH at block 1420. If there are bits in the UCI for the primary DL CC, the UE may prepare to transmit bits associated with the primary DL CC on PUCCH while preparing to transmit the remaining bits in the UCI on PUSCH in the same subframe, at block 1430. For example, if the UCI includes multiple periodic CQI/PMI reports to be transmitted in a given subframe and one of the reports is for a primary DL CC, the UE may prepare to transmit the CQI/PMI report for the primary DL CC on the PUCCH at block 1430. If there are no reports for the primary DL CC in the report, the UE may prepare to transmit all reports on the PUSCH at block 1420.

Note that if it is determined at block 1410 that there are no bits to transmit for the primary DL CC, instead of transmitting all UCI bits on the PUSCH at block 1420, the UE may prepare to transmit UCI bits on PUCCH for the next highest priority (e.g., determined by a configuration command, DL CC index or ID, or any other manner known to the UE and/or enodeb) DL CC and UCI for the other DL CCs on PUSCH (block 1440). For example, if the UCI includes multiple periodic CQI/PMI reports to be transmitted in a given subframe and no report in the reports is for the primary DL CC, the UE may prepare to transmit a CQI/PMI report for the next highest priority DL CC on the PUCCH and transmit other reports on the PUSCH. The options and alternatives for this next priority DL CC are the same as described herein for the primary DL CC.

Alternatively, when using the allowed PUCCH format of the allocated PUCCH, if the UE is configured to know that only a particular UCI type combination will fit on the PUCCH, the UE may prepare to transmit a combination of the highest priority UCI type for the primary DL CC on the PUCCH (e.g., ACK/NACK and periodic RI (if periodic RI is to be transmitted); otherwise, ACK/NACK and periodic CQI/PMI) and transmit other UCI types for the primary DL CC on the PUSCH at block 1430. Alternatively, the UE may discard bits for other UCI types of the primary DL CC. If there are no UCI bits for the primary DL CC, the same principle may be applied to the highest priority DL CC where UCI is present at block 1440.

In another alternative, if the UCI to be transmitted in the designated subframe includes ACK/NACK and periodic CQI/PMI reports for the primary DL CC, the UE may prepare to transmit the ACK/NACK and periodic CQI/PMI reports for the primary DL CC on the PUCCH and transmit other UCI bits on the PUSCH at block 1430. If there are no UCI bits for the primary DL CC, the same principle may be applied to the highest priority DL CC where UCI is present at block 1440.

In some embodiments, the UE may determine how the UE will transmit UCI bits based on an explicit grant for UCI (e.g., for periodic CQI/PMI/RI reporting). In this embodiment, the enodeb may explicitly provide a UL grant to the UE, e.g., via a new or modified DCI format or via higher layer signaling, to transmit UCI without user data. For example, when the enodeb knows that the UE has no data to send and that the scheduled UCI report will not fit in the PUCCH, the enodeb may provide a UL grant to the UE to transmit periodic reports, e.g., reports for CQI/PMI or RI bits. In one embodiment, if the UE receives the grant, the UE may prepare to transmit UCI only on PUSCH according to the grant. In another embodiment, the UE may split UCI between PUCCH and PUSCH according to one or more other embodiments described herein.

Note that in any of the methods and embodiments described herein, the UE and/or enodeb may also determine how to transmit UCI bits based on whether a maximum power threshold has been met or exceeded or will be met or exceeded. Figure 15 illustrates a method of implementing one such embodiment. At block 1510, the UE may make a decision on how to transmit UCI. At block 1510, any manner or method of transmitting UCI may be determined, including, for example, partitioning UCI between PUCCH and PUSCH in the same frame according to any other embodiments described herein. At block 1520, the UE may determine the power required to transmit the UCI using the manner determined at block 1510. At block 1530, the UE may determine whether the power required for the transmission will exceed the maximum allowed power. If the maximum power is not to be exceeded, then at block 1540 the UCI bits are transmitted according to the preferred method determined at block 1510. The decision as to whether or not the maximum power is to be exceeded may include one or more power limits configured or known to the UE, such as CC maximum transmit power and UE maximum transmit power.

At block 1530, if it is determined that the maximum allowed power is to be exceeded, the UE may take one or more alternative routes of action. In one embodiment, at block 1550, the UE may scale one or more of PUCCH and PUSCH power. Note that scaling methods and approaches that may be used include, but are not limited to, those set forth in U.S. patent application No.12/703,092, which is incorporated herein by reference.

Alternatively, at block 1530, if it is determined that the maximum allowed power will be exceeded, the UE may transmit all UCI on PUSCH at block 1560. Transmitting all UCI on PUSCH eliminates MPR impact that would reduce maximum allowed power due to simultaneous PUSCH-PUCCH transmission.

In another alternative, if the UE determines that the maximum allowed power will be exceeded at block 1530, the UE may determine whether transmitting all UICs on the PUSCH would exceed the maximum allowed power level at block 1570. Transmitting all UCI on PUSCH will eliminate the need to scale power prior to transmission if transmitting all UCI on PUSCH does not exceed the maximum allowed power level. If transmitting UCI on PUSCH would eliminate the need to scale power, the UE may transmit all UCI on PUSCH at block 1560. If transmitting UCI on PUSCH will not eliminate the need to scale power, the UE may keep its initial decision on the UCI transmission method, e.g., partition UCI between PUCCH and PUSCH in the same frame, and scale power on PUCCH and PUSCH (e.g., based on channel priority) in any manner described for block 1550, at block 1580. In such embodiments, UCI on PUCCH may be reserved since PUCCH may have the highest priority.

Note that in any of the methods and embodiments disclosed herein, PUCCH and PUSCH may be transmitted through the same or different UL CCs. These methods and embodiments are applicable in both cases. An example of transmitting on different UL CCs is to transmit PUCCH on the primary UL CC and PUSCH on other UL CCs.

In some LTE-a systems and implementations, multiple PUSCHs may be used for each subframe. In such embodiments, the UE may have to determine on which PUSCH UCI bits are transmitted when it has determined that any UCI bits are transmitted not on PUCCH but on PUSCH or on PUSCH in addition to PUCCH. Such bits are referred to herein as "UCI bits for PUSCH".

In one such embodiment, as shown in fig. 16, the UE may first determine whether multiple PUSCHs are in use or available at block 1610. If not, the UE may prepare to transmit any UCI bits intended for transmission on the PUSCH on the available PUSCH at block 1620. If multiple PUSCHs are available, the UE may select a PUSCH for UCI transmission based on the PUSCH size (carrying capacity) at block 1630. In one embodiment, the UE may prepare to transmit UCI bits for PUSCH on a PUSCH with the largest size (or carrying capacity). The PUSCH size may be measured using one or more factors, such as the number of RBs, the number of OFDM symbols, the number of physically coded bits, or some combination of these or other factors. Alternatively, at block 1630, the UE may select a PUSCH based on a relationship between two or more of UCI payload size, PUSCH data payload size, and PUSCH carrying capacity. For example, the UE may transmit UCI bits for a PUSCH on a PUSCH for which a UCI payload size (e.g., percentage) relative to a total payload size or a UCI payload size (e.g., percentage) relative to a data payload is smallest. Each of these embodiments may reduce the performance impact on PUSCH of including UCI with data. At block 1640, the UE may prepare to transmit UCI bits for PUSCH on the PUSCH selected at block 1630.

In an alternative embodiment, upon determining that there are multiple PUSCHs at block 1610, the UE may determine whether there is a primary UL CC with a PUSCH at block 1650. If so, at block 1660, the UE may prepare to transmit UCI bits for PUSCH on the PUSCH of the primary UL CC. The primary UL CC may be an UL CC that has been paired with the primary DL CC. If there is no PUSCH on the primary UL CC, the PUSCH is selected using the approach of block 1630 or any other approach or method. In an alternative embodiment, the UE may select the PUSCH for UCI bit transmission as a PUSCH on a UL CC configured or specified in some way by the enodeb on which the UE transmits ACK/NACK bits.

In some embodiments, the UE may select PUSCH for transmission based on explicit signaling or grant (e.g., grant for aperiodic UCI reporting request). In one such embodiment, the UE may prepare to transmit UCI bits for PUSCH on a PUSCH explicitly specified by the enodeb via L1 or higher layer signaling. In one alternative, if the enodeb provides a UL grant specific for UCI, the UE may transmit UCI for PUSCH on the allocated PUSCH. In another alternative, if the UE receives a PDCCH with an aperiodic UCI request bit (or an aperiodic request bit set to "1"), the UE may prepare to transmit UCI bits for PUSCH on the PUSCH associated with the request for PDCCH. The UCI bits may include the aperiodic UCI report bits and all other UCI bits to be transmitted on the PUSCH.

Although the features and elements of the embodiments and methods disclosed herein are described in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements. The methods or flow charts provided herein may be implemented in a computer program, software, or firmware embodied in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of the computer readable storage medium include Read Only Memory (ROM), Random Access Memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM optical disks and Digital Versatile Disks (DVDs).

For example, suitable processors include: a general-purpose processor, a special-purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any Integrated Circuit (IC), and/or a state machine.

A processor in association with software may be used to implement a radio frequency transceiver for use in a Wireless Transmit Receive Unit (WTRU), User Equipment (UE), terminal, base station, Radio Network Controller (RNC), or any host computer. The UE may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a bluetooth (TM) module, a Frequency Modulated (FM) radio unit, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any Wireless Local Area Network (WLAN) module or Ultra Wideband (UWB) module.

Claims (26)

1. A method for transmitting uplink control information, the method comprising:

determining that the uplink control information satisfies a criterion, wherein the criterion comprises a particular type of uplink control information bit; and

in response to determining that the uplink control information satisfies the criteria, transmitting a first subset of uplink control information bits on a physical uplink control channel in a first subframe and transmitting a second subset of uplink control information bits on a physical uplink shared channel in the first subframe.

2. The method of claim 1, wherein the particular type of uplink control information bit comprises at least one of: hybrid automatic repeat request (HARQ) positive Acknowledgement (ACK)/Negative Acknowledgement (NACK), Scheduling Request (SR), Channel Quality Indicator (CQI), Precoding Matrix Indicator (PMI), and Rank Indicator (RI).

3. The method of claim 2, wherein the first subset of uplink control information bits comprises at least one of: HARQ ACK and SR.

4. The method of claim 2, the second subset of uplink control information bits comprising at least one of: periodic CQI, aperiodic CQI, periodic PMI, aperiodic PMI, periodic RI, and aperiodic RI.

5. The method of claim 1, wherein determining that the uplink control information satisfies the criteria further comprises determining that a number of uplink control information bits is above a first threshold.

6. The method of claim 5, further comprising determining that the number of uplink control information bits is below a second threshold.

7. The method of claim 1, wherein determining that the uplink control information satisfies the criteria further comprises determining that a number of uplink control information bits will not fit in the physical uplink control channel.

8. The method of claim 1, wherein determining that the uplink control information satisfies the criteria further comprises:

determining a relative uplink control information payload size; and

determining that the relative uplink control information payload size is less than a first threshold.

9. The method of claim 1, wherein determining that the uplink control information meets the criteria further comprises determining that there is no user data to transmit and that a number of uplink control information bits will not fit in the physical uplink shared channel.

10. The method of claim 1, wherein determining that the uplink control information satisfies the criteria further comprises determining that the uplink control information includes at least one of acknowledgement bits and negative acknowledgement bits.

11. The method of claim 10, wherein the first subset of uplink control information bits includes at least one of the acknowledgement bits and the negative acknowledgement bits, and the second subset of uplink control information bits includes all other uplink control information bits.

12. The method of claim 1, wherein determining that the uplink control information satisfies the criteria comprises determining that a single downlink component carrier exists.

13. The method of claim 12, further comprising determining that the uplink control information comprises at least one of each of channel quality indicator bits, precoding matrix indicator bits, and rank indicator bits.

14. A wireless transmit receive unit configured to transmit uplink control information, the wireless transmit receive unit comprising:

a processor configured to:

determining that the uplink control information satisfies a criterion, wherein the criterion includes a particular type of uplink control information bit, an

In response to determining that the uplink control information satisfies the criteria, determining a first subset of uplink control information bits and a second subset of uplink control information bits; and

a transceiver configured to:

transmitting a first subset of the uplink control information bits on a physical uplink control channel in a first subframe, an

Transmitting a second subset of the uplink control information bits on a physical uplink shared channel in the first subframe.

15. The wireless transmit and receive unit of claim 14, wherein the particular type of uplink control information bit comprises at least one of: hybrid automatic repeat request (HARQ) positive Acknowledgement (ACK)/Negative Acknowledgement (NACK), Scheduling Request (SR), Channel Quality Indicator (CQI), Precoding Matrix Indicator (PMI), and Rank Indicator (RI).

16. The wireless transmit and receive unit of claim 15, wherein the first subset of uplink control information bits comprises at least one of: HARQ ACK and SR.

17. The wireless transmit receive unit of claim 15, the second subset of uplink control information bits comprising at least one of: periodic CQI, aperiodic CQI, periodic PMI, aperiodic PMI, periodic RI, and aperiodic RI.

18. The wireless transmit and receive unit of claim 14, wherein the processor being configured to determine that the uplink control information satisfies the criteria further comprises the processor being configured to determine that at least one uplink control information bit is associated with a primary downlink component carrier.

19. The wireless transmit receive unit of claim 14, wherein the processor is further configured to determine that a power required to transmit the first subset of uplink control information bits on the physical uplink control channel and the second subset of uplink control information bits on the physical uplink shared channel is less than a maximum power threshold.

20. The wireless transmit receive unit of claim 14, wherein the processor is further configured to:

determining that a power required to transmit the first subset of uplink control information bits on the physical uplink control channel and the second subset of uplink control information bits on the physical uplink shared channel is greater than a maximum power threshold; and

scaling at least one of the PUCCH power level and the PUSCH power level.

21. The wireless transmit and receive unit of claim 14, wherein the processor is further configured to select the physical uplink shared channel from a plurality of physical uplink shared channels.

22. The wireless transmit and receive unit of claim 21, wherein the processor is further configured to select the physical uplink shared channel from the plurality of physical uplink shared channels based on an uplink control information payload size.

23. The wireless transmit and receive unit of claim 21, wherein the processor is further configured to select the physical uplink shared channel from the plurality of physical uplink shared channels based on a relationship between uplink control information payload size and at least one of physical uplink shared channel data payload size and physical uplink shared channel carrying capacity.

24. The wireless transmit and receive unit of claim 21, wherein the processor is further configured to select the physical uplink shared channel from the plurality of physical uplink shared channels based on whether one of the plurality of physical uplink shared channels is on a primary uplink component carrier.

25. The wireless transmit and receive unit of claim 14, wherein the processor being configured to determine that the uplink control information satisfies the criteria further comprises the processor being configured to determine that the number of downlink component carriers is 1 and the uplink control information comprises at least one of each of a channel quality indicator bit, a precoding matrix indicator bit, and a rank indicator bit.

26. The wireless transmit receive unit of claim 14, wherein the processor is further configured to:

determining that the uplink control information includes periodic reporting data and aperiodic reporting data; and

discarding the periodic report data.