Uplink feedback method for operation using multiple carriers

Abstract

This provides an uplink feedback method that operates using multiple carriers. [Solution] The method in a wireless transceiver unit (WTRU) includes the steps of: receiving a plurality of transport blocks on a plurality of configured carrier sets; generating hybrid automatic retransmission request (HARQ)-acknowledgment (ACK) feedback for the plurality of transport blocks; and determining the number of HARQ-ACK feedback bits to be used for the HARQ-ACK feedback. The WTRU may apply Reed-Muller coding to the HARQ-ACK feedback bits if the number of HARQ-ACK feedback bits is less than or equal to a threshold, or apply convolutional coding if the number of HARQ-ACK feedback bits is greater than the threshold. The WTRU may then transmit the encoded HARQ-ACK feedback bits.

Description

[Background technology]

[0001] This application claims the benefits of U.S. Provisional Application No. 62 / 108849 filed on 28 January 2015, U.S. Provisional Application No. 62 / 144835 filed on 8 April 2015, U.S. Provisional Application No. 62 / 161057 filed on 13 May 2015, U.S. Provisional Application No. 62 / 166523 filed on 26 May 2015, U.S. Provisional Application No. 62 / 214552 filed on 4 September 2015, and U.S. Provisional Application No. 62 / 250890 filed on 4 November 2015, the contents of which are incorporated herein by reference.

[0002] Carrier aggregation for Long-Term Evolution (LTE) was introduced in the 3rd Generation Partnership Project (3GPP) Release 10. This feature allows a radio transceiver unit (WTRU) to transmit and receive on two or more carriers simultaneously, resulting in an increase in its peak data rate over the air interface. The maximum number of carriers that can be aggregated is five, given a maximum bandwidth of 100 megahertz (MHz). [Overview of the project] [Problems that the invention aims to solve]

[0003] In LTE, downlink data transmission can be performed using a physical downlink shared channel (PDSCH). This physical channel supports Hybrid Automatic Retransmission Request (HARQ) transmissions, which allow the receiver (in the WTRU) to combine successive transmissions of transport blocks to increase the probability of successful decoding on each retransmission. The WTRU can report a given attempt to receive a transport block using an acknowledgment (ACK) for success or a negation (NACK) for failure. In some cases, such as in discontinuous transmissions (DTX), the WTRU may also report that it did not detect that a transport block was transmitted. This provides an uplink feedback method for operation using multiple carriers. [Means for solving the problem]

[0004] A method and apparatus for uplink feedback for operation using multiple carriers is disclosed herein. The method in a wireless transceiver unit (WTRU) includes the steps of: receiving downlink control information (DCI), the DCI scheduling a physical downlink shared channel (PDSCH) transmission, the DCI including an indication; determining, based on the indication in the DCI, whether a hybrid automatic retransmission request (HARQ) acknowledgment (ACK) / negation (NACK) (A / N) report is expected for the PDSCH transmission; and receiving a HARQ A / N report for the PDSCH transmission, provided that it is expected.

[0005] Further examples include solutions for reducing the HARQ-ACK payload, increasing the physical uplink control channel (PUCCH) payload, increasing the uplink control information (UCI) payload within a physical uplink shared channel (PUSCH), and determining the resources or sub-resources used for a feedback group or combination of feedback groups based on downlink control signaling associated with any PDSCH, and the combination of indices or sequences associated with this feedback group.

[0006] Further examples include dynamic scheduling of UCIs on PUCCH and an index for each downlink allocation to enable dynamic codebooks and feedback compression. In the example, the WTRU can determine the order of information bits in the codebook. The WTRU can select codebook permutations to optimize decoding performance. Further examples include codebook indicators. Furthermore, a particular group of carriers to select can be determined based on which carriers for which allocations have been received. In addition, the codebook can be determined using one or more methods. An A / N resource indicator (ARI) can also be used to determine the final allocation. Furthermore, multiple channel status information (CSI) reports can be transmitted within a subframe using one or more methods. For example, the WTRU can be configured to use a maximum payload for each PUCCH resource that can be used for transmitting HARQ-ACKs, periodic CSI reports, and / or scheduling requests (SRs) within a subframe.

[0007] In the example, the WTRU can receive multiple transport blocks on a set of multiple configured carriers, generate HARQ-ACK feedback for the multiple transport blocks, and determine the number of HARQ-ACK feedback bits to use for the HARQ-ACK feedback. Furthermore, the WTRU can apply Reed-Muller coding to the HARQ-ACK feedback bits, provided that the number of HARQ-ACK feedback bits is below a threshold. The WTRU can then transmit the encoded HARQ-ACK feedback bits.

[0008] In addition, the WTRU can add cyclic redundancy check (CRC) bits to the HARQ-ACK feedback bits, provided that the number of HARQ-ACK feedback bits exceeds a threshold. Furthermore, the WTRU can apply convolutional coding to both the HARQ-ACK feedback bits and the CRC bits, provided that the number of HARQ-ACK feedback bits exceeds a threshold. The WTRU can then transmit the encoded HARQ-ACK feedback bits and CRC bits.

[0009] Furthermore, the WTRU can determine the number of HARQ-ACK feedback bits to use for HARQ-ACK feedback based on multiple downlink assignments to carriers within a set of configured carriers. A set of configured carriers can include six or more configured carriers.

[0010] In another example, a WTRU can receive multiple transport blocks on a set of multiple configured carriers and generate HARQ-ACK and CSI feedback for the multiple transport blocks. The WTRU can then generate a feedback message including the number of HARQ-ACK feedback bits to be used for HARQ-ACK feedback and the number of CSI feedback bits to be used for CSI feedback. The WTRU can then determine the PUCCH format based on the number of HARQ-ACK feedback bits and the number of CSI feedback bits. In addition, the WTRU can then transmit the feedback message using the determined PUCCH format.

[0011] Furthermore, the WTRU can determine, based on multiple downlink assignments to carriers within the configured set of carriers, the number of HARQ-ACK feedback bits to use for HARQ-ACK feedback, the number of CSI feedback bits to use for CSI feedback, or both. In the example, the WTRU can choose from four PUCCH formats.

[0012] A more detailed understanding can be obtained from the following explanation, which is given with the attached drawings and related examples. [Effects of the Invention]

[0013] An uplink feedback method is provided that operates using multiple carriers. [Brief explanation of the drawing]

[0014] [Figure 1A] This is a diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments. [Figure 1B] Figure 1A is a system diagram of an exemplary wireless transceiver unit (WTRU) that can be used in the communication system shown. [Figure 1C] This is a system diagram of an exemplary wireless access network and core network that can be used within the communication system shown in Figure 1A. [Figure 2] This is a diagram illustrating an example of possible resource element mapping for an extended physical uplink control channel design utilizing two consecutive resource blocks. [Figure 3] This is a diagram illustrating the selection process for PUCCH formats based on the size and type of feedback. [Figure 4] This is a diagram illustrating an example of a Hybrid Automatic Retransmission Request (HARQ) Acknowledgment / Negative Response (A / N) codebook decision. [Figure 5] This is a diagram illustrating an exemplary selection process for channel coding and cyclic redundancy check (CRC) inclusion based on the number of feedback bits transmitted. [Modes for carrying out the invention]

[0015] Figure 1A is a diagram of an exemplary communication system 100 that can implement one or more disclosed embodiments. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 can utilize one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature FDMA (OFDMA), and single-carrier FDMA (SC-FDMA).

[0016] As shown in FIG. 1A, communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it is understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d can be configured to transmit and / or receive wireless signals and can include, for example, user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, and home appliances.

[0017] Communication system 100 can also include base stations 114a and base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as core network 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b can be base transceiver stations (BTSs), Node Bs, eNode Bs, home Node Bs, home eNode Bs, site controllers, access points (APs), and wireless routers. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0018] The base station 114a can be part of the RAN 104, and the RAN 104 can also include other base stations and / or network elements such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes (not shown). The base station 114a and / or the base station 114b can be configured to transmit and / or receive radio signals within a specific geographical area, sometimes referred to as a cell (not shown). The cell can be further divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a can utilize multiple-input multiple-output (MIMO) technology and thus can utilize multiple transceivers for each sector of the cell.

[0019] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the air interface 116, and the air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0020] More specifically, as mentioned above, the communication system 100 can be a multiple access system and can utilize one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRUs 102a, 102b, and 102c within RAN 104 can implement radio technologies such as Universal Mobile Communications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using broadband CDMA (WCDMA). WCDMA can include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA can include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0021] In another embodiment, base stations 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish an air interface 116 using Long-Term Evolution (LTE) and / or LTE Advanced (LTE-A).

[0022] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.16 (i.e., Global Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), High Speed ​​Data Rate for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0023] The base station 114b in Figure 1A can be, for example, a wireless router, home node B, home e-node B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as workplaces, homes, vehicles, and campuses. In one embodiment, the base station 114b and WTRU 102c, 102d can establish a wireless local area network (WLAN) by implementing wireless technology such as IEEE 802.11. In another embodiment, the base station 114b and WTRU 102c, 102d can establish a wireless personal area network (WPAN) by implementing wireless technology such as IEEE 802.15. In yet another embodiment, the base station 114b and WTRU 102c, 102d can establish a picocell or femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). As shown in Figure 1A, the base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via core network 106.

[0024] RAN 104 can communicate with core network 106, which can be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. For example, core network 106 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 and / or core network 106 can communicate directly or indirectly with other RANs that utilize the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104 which can utilize E-UTRA radio technology, core network 106 can also communicate with another RAN (not shown) that utilizes GSM radio technology.

[0025] The core network 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing basic telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) within the TCP / IP Internet Protocol Suite. Networks 112 may include wired or wireless networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that can utilize the same RAT as RAN 104 or a different RAT.

[0026] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode functionality, i.e., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks on different radio links. For example, the WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which can utilize cellular-based radio technology, and also with base station 114b, which can utilize IEEE 802 radio technology.

[0027] Figure 1B is a system diagram of an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It will be understood that the WTRU 102 may include any subcombinations of the above elements while maintaining consistency with the embodiment.

[0028] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors working with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and a state machine, etc. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, and the transceiver 120 can be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0029] The transmit / receive element 122 can be configured on the air interface 116 to transmit signals to or receive signals from a base station (e.g., base station 114a). For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 may be a radiator / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of radio signals.

[0030] In addition, although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can utilize MIMO technology. Therefore, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals over the air interface 116.

[0031] The transceiver 120 can be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As mentioned above, the WTRU 102 can have multimode capabilities. Therefore, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0032] The processor 118 of the WTRU102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can retrieve information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in them. Non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 can include subscriber identification module (SIM) cards, memory sticks, and secure digital (SD) memory cards, etc. In other embodiments, the processor 118 can obtain information from memory located on a server or home computer (not shown) or the like, which is not physically located on the WTRU 102, and store data therein.

[0033] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components within the WTRU 102. The power supply 134 can be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), and lithium-ion (Li-ion)), a solar cell, and a fuel cell.

[0034] The processor 118 can also be coupled to a GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 can receive location information from base stations (e.g., base stations 114a, 114b) on the air interface 116 and / or determine its own location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 can acquire location information using any suitable location determination method while maintaining consistency with the embodiments.

[0035] The processor 118 can be further coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, e-compass, satellite transceiver, digital camera (for photos or videos), Universal Serial Bus (USB) port, vibration device, TV transceiver, hands-free headset, Bluetooth® module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, and internet browser.

[0036] Figure 1C is a system diagram of RAN 104 and core network 106 according to an embodiment. As mentioned above, RAN 104 can utilize E-UTRA radio technology to communicate with WTRU 102a, 102b, and 102c over air interface 116. RAN 104 can also communicate with core network 106.

[0037] RAN104 may include e-nodes B140a, 140b, and 140c, but it will be understood that RAN104 may include any number of e-nodes B while maintaining consistency with the embodiment. Each of e-nodes B140a, 140b, and 140c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c on the air interface 116. In one embodiment, e-nodes B140a, 140b, and 140c can implement MIMO technology. Thus, e-node B140a can, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU102a.

[0038] Each of the e-nodes B140a, 140b, and 140c can be associated with a specific cell (not shown) and configured to handle wireless resource management decisions, handover decisions, and user scheduling on the uplink and / or downlink. As shown in Figure 1C, the e-nodes B140a, 140b, and 140c can communicate with each other over the X2 interface.

[0039] The core network 106 shown in Figure 1C may include a Mobility Management Entity Gateway (MME) 142, a Serving Gateway 144, and a Packet Data Network (PDN) Gateway 146. Although each of the above elements is shown as part of the core network 106, it will be understood that any one of these elements may be owned and / or operated by an entity different from the core network operator.

[0040] The MME142 can connect to each of the e-nodes B140a, 140b, and 140c within RAN104 via the S1 interface and can act as a control node. For example, the MME142 can be responsible for user authentication of WTRU102a, 102b, and 102c, bearer activation / deactivation, and selection of a specific serving gateway during the initial connection of WTRU102a, 102b, and 102c. The MME142 can also provide control plane functionality for exchanges between RAN104 and other RANs (not shown) utilizing other radio technologies such as GSM or WCDMA.

[0041] The serving gateway 144 can connect to each of the e-nodes B140a, 140b, and 140c in the RAN104 via the S1 interface. The serving gateway 144 can generally perform route selection and forwarding of user data packets to and from WTRU102a, 102b, and 102c. The serving gateway 144 can also perform other functions, such as anchoring the user plane during e-node B handover, triggering paging when downlink data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0042] The serving gateway 144 can also be connected to the PDN gateway 146, which provides WTRU 102a, 102b, and 102c with access to a packet-switched network such as the Internet 110, thereby facilitating communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0043] The core network 106 can facilitate communication with other networks. For example, the core network 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, thereby facilitating communication between WTRU 102a, 102b, and 102c and conventional land-line communication devices. For example, the core network 106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 106 and PSTN 108. In addition, the core network 106 can provide WTRU 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0044] Carrier aggregation for LTE was introduced in the Third Generation Partnership Project (3GPP) Release 10. This feature allows a WTRU to transmit and receive on two or more carriers simultaneously, resulting in an increase in its peak data rate over the air interface. In the unmodified form of carrier aggregation, the maximum number of carriers that can be aggregated is five, given a maximum bandwidth of 100 megahertz (MHz).

[0045] In LTE, downlink data transmission can be performed using a physical downlink shared channel (PDSCH). This physical channel supports Hybrid Automatic Retransmission Request (HARQ) transmission, which allows the receiver (in the WTRU) to combine successive transmissions of transport blocks to increase the probability of successful decoding on each retransmission. The WTRU can report a given attempt to receive a transport block using an acknowledgment (ACK) for successful reception or a negative acknowledgment (NACK) for unsuccessful reception. In some cases, the WTRU may also report that it did not detect that a transport block was transmitted, such as in a discontinuous transmission (DTX). Such reports are sometimes collectively referred to as "HARQ-ACK feedback" in this specification. The result of a particular attempt to receive a transport block (ACK or NACK, or in some solutions, ACK, NACK, or DTX) is sometimes referred to as "HARQ A / N report" in this specification.

[0046] When carrier aggregation is configured, a maximum of two transport blocks can be received per carrier (or serving cell) and subframe on a PDSCH channel. In frequency division duplex (FDD) mode, the WTRU can report a 1-bit HARQ-ACK feedback separately for each transport block, sending an ACK if the transport block is successfully received, and a NACK otherwise. In time division duplex (TDD) mode, in some configurations, the WTRU can report a 1-bit HARQ-ACK for each pair of transport blocks received within the same carrier and subframe (e.g., spatially multiplexed), or for a set of transport blocks received within the same carrier and subframe set, sending an ACK if all transport blocks belonging to the pair or set are successfully received, and a NACK otherwise. A method in which a WTRU reports an ACK if all receptions belonging to a set of two or more transport blocks have been successful, and a NACK otherwise, is sometimes called "A / N bundling." A / N bundling can be performed on spatially multiplexed transport blocks (spatial bundling), on transport blocks received in different subframes (time bundling), or on transport blocks received in different carriers or cells (frequency bundling).

[0047] In both modes, a fixed timing relationship exists between the reception of a transport block and the transmission of a HARQ-ACK bit, which depends on the success or failure of the reception of that transport block. More specifically, in FDD mode, a HARQ-ACK bit corresponding to a transport block received in subframe n can be transmitted in subframe n+4. In TDD mode, the timing relationship can depend on the subframe configuration and on the index of the subframe in which the transport block was received.

[0048] The transmission of the HARQ-ACK bit within a subframe can be performed on a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH). PUCCH can be used when PUSCH transmission is not available within the subframe, or when the WTRU is configured to transmit both PUCCH and PUSCH simultaneously.

[0049] A PUCCH can occupy a single physical resource block (PRB) within each time slot of a subframe and can transmit according to one of a set of possible formats. If it is necessary to transmit five or more HARQ-ACK bits on a PUCCH within a single subframe, the WTRU may need to be configured to use PUCCH format 3. PUCCH format 3 can be described as Discrete Fourier Transform-Spread-Orthogonal Frequency Division Multiplexing (DFT-S-OFDM) transmission, where each symbol modulated by 4-phase shift modulation (QPSK) occupies a single subcarrier and is spread in the time domain using one of a set of orthogonal cover codes. In PUCCH format 3, each QPSK-modulated symbol can be spread on one time slot so that 48 encoded bits can be accommodated within the subframe (2 time slots × 12 subcarriers × 2 bits per symbol). Up to 10 HARQ-ACK bits (in FDD mode) or 20 HARQ-ACK bits (in TDD mode) can be multiplexed with up to one scheduling request (SR) bit so that they are encoded within those 48 encoded bits.

[0050] Within a cell, up to four WTRUs can transmit mutually orthogonal PUCCH format 3 signals within the same resource block. However, the maximum number of WTRUs that can be configured to use the same resource block may be smaller when inter-cell interference is significant.

[0051] When HARQ-ACK bits within a subframe need to be transmitted over the PUSCH, the corresponding modulation symbols can be mapped onto resource elements that occupy some (or all) of the subcarriers in four time symbols adjacent to the time symbol used for transmitting the demodulated reference signal (DM-RS) within the subframe. The number of resources can be determined based on parameters configured such that the size of the PUSCH allocation and the amount of energy available for HARQ-ACK are sufficient to ensure that the error performance objective is met.

[0052] To enhance carrier aggregation capabilities, it has been proposed to allow aggregation of up to 32 carriers. Reusing the same solution as the legacy system may now require the transmission of up to 64 HARQ-ACK bits (in FDD mode) or 128 HARQ-ACK bits (in TDD mode), so this enhancement can be challenging from the standpoint of providing HARQ-ACK feedback. This can raise the following concerns: Firstly, the maximum number of coded bits available in a PUCCH transmission (48) may be lower than the number of HARQ-ACK (and SR) information bits determined using the legacy solution. Secondly, the amount of energy used for HARQ-ACK (and SR) transmission within the PUCCH may be insufficient to guarantee acceptable error performance.

[0053] It has also been proposed that the WTRU be configured to use PUCCH on one or more secondary cells (SCells). In such cases, the WTRU may need to decide whether some or all of the uplink control information (UCI) should be transmitted using a single transmission, and if so, whether to use a PUCCH transmission on the primary cell (PCell) (or, in the case of a secondary cell group (SG) (SCG), the primary SCell (PSCell)), a PUSCH transmission on a cell in the master cell group (MCG) (if available and the UCI is associated with the MCG), or a PUSCH transmission on a cell in the SCG (if available and the UCI is associated with the SCG).

[0054] This specification discloses methods and solutions for reducing HARQ-ACK payloads, including the following: Conditional generation of HARQ A / N reports can be based on the satisfaction of one or more conditions, such as conditions relating to the modulation and coding scheme (MCS) and / or the reported channel quality indicator (CQI). Selective partial bundling can be used, which selects groups of transport blocks (TBs) to which bundling is applied on a subframe basis to minimize unnecessary retransmissions. Furthermore, down-selection of acknowledgment reports can be used.

[0055] This specification discloses methods and solutions for increasing PUCCH payloads, including the following: For example, this specification discloses methods and solutions for using higher-order modulation, possibly on a subset of subcarriers, to implement non-uniform error protection. This specification also discloses methods and solutions for using two or more resource blocks (RBs) using a new DM-RS design that enables multiplexing with legacy formats while maintaining a low cubic metric (CM). In addition, this specification discloses methods and solutions for using spatial multiplexing, in which the number of information bits on each layer can be dynamically selected. Furthermore, modulation symbols can be spread over fewer resource elements (REs) than in the unmodified method, and the number of symbols can be dynamically selected.

[0056] This specification discloses methods and solutions for the efficient use of resources, including: Codebook characteristics can be dynamically determined, for example, based on downlink control signaling; and codebook permutations can be selected to optimize decoding performance. In addition, multiple feedback groups can be transmitted and processed separately or jointly, and feedback group indicators can be used to facilitate decoding. Furthermore, resource selection and mapping, PUCCH power setting functions, and / or dynamic scheduling of UCI on PUCCH can be used. In addition to feedback compression, index and / or counter displays can be used to enable dynamic codebooking as well as feedback compression.

[0057] This specification discloses methods and solutions for increasing the UCI payload within a PUSCH, including: When the number / ratio of REs within a PUSCH exceeds a threshold, modified transport block processing can be used.

[0058] This specification discloses methods and solutions for resource selection in cases of multiple types of transmissions within multiple cells. Furthermore, this specification discloses methods and solutions for transmitting multiple periodic CSI reports within a subframe.

[0059] This specification discloses methods and solutions for codebook determination, in which an affirmative / negative (A / N) resource indicator (ARI) can be used to determine the final allocation, and for the submission of multiple CSI reports.

[0060] The following solutions address the limited payload (or range) issue for sending HARQ-ACKs by enabling a reduction in the number of information bits used for HARQ-ACKs.

[0061] In some solutions, the number of information bits generated for HARQ-ACK can be reduced by restricting the generation of HARQ A / N reports (or bits) for a given transport block to only when at least one condition is met. This at least one condition can be defined as minimizing unnecessary retransmissions of transport blocks by the network. Generally, this can be achieved when at least one condition is that A / N reports are generated only when the probability of successful decoding is significant.

[0062] In legacy LTE systems, a WTRU can generally generate a HARQ A / N report when it receives a transmission on the PDSCH and / or when it receives Downlink Control Information (DCI) that activates or deactivates a configured uplink grant or configured downlink allocation.

[0063] In one way, the WTRU can make further decisions when generating the HARQ A / N report. The WTRU can generate the HARQ A / N report for a transmission associated with a particular carrier (or a particular serving cell) in the WTRU's configuration according to at least one of the following:

[0064] A WTRU can receive a DCI, such as a DCI characterized by at least one of the following: DCI type, representation within the DCI, Radio Network Temporary Identifier (RNTI) used for successful decoding of the DCI, search space associated with the received DCI, location of the DCI within the search space, aggregation level of the DCI, other DCI content, or a combination thereof.

[0065] For DCI types, a WTRU can determine whether a HARQ A / N report is expected for a transmission as a function of the type (or format) of the DCI associated with the transmission. For example, a WTRU may receive a DCI of a particular type (or format) and decide that it does not need to generate a HARQ A / N report. Such associations can be based on the DCI format itself. For example, a DCI can also convey scheduling information for an associated transmission. Such associations can be based on timing, for example, a DCI of a particular type (or format) received in the same subframe as a DCI that schedules one or more transmissions in the associated subframe. Such types may include DCI types that can be used to provide "hints" in supporting WTRU processing of downlink control signaling. Such a DCI may indicate that a transmission is not applicable to the associated carriers in a given subframe. Alternatively, such a DCI may indicate that the WTRU is not expected to generate HARQ A / N feedback for one or more carriers. Perhaps such a DCI could, for example, use code points to indicate a specific format and / or carrier combination for which a HARQ A / N report is expected during the relevant interval (e.g., subframe). Further examples of such DCIs are described herein. Similar to legacy systems, a WTRU may be required to generate a HARQ A / N report for a DCI that activates or deactivates a configured grant and / or configured downlink assignment, while other DCI formats may require additional rules to determine whether or not to generate a HARQ A / N report.

[0066] In the case of a display within a DCI, a WTRU can determine whether a HARQ A / N report is expected for a transmission, as a function of the content of the DCI associated with the transmission. For example, a WTRU may receive a DCI that schedules a PDSCH transmission. Such a DCI may include a display. From such a display, a WTRU can determine whether a HARQ A / N report is expected for the associated PDSCH transmission. Perhaps such a DCI could use, for example, a code point to indicate a specific format and / or carrier combination for which a HARQ A / N report is expected during the associated interval (e.g., subframe). The display may consist of the values ​​of a field included in the DCI's payload, or the values ​​of a field used to mask a subset or all of the bits of a Cyclic Redundancy Check (CRC). The field may consist of, for example, a Downlink Assignment Index (DAI) field, or a dedicated field (HARQ A / N Reporting Indicator).

[0067] For an RNTI used to successfully decode a DCI, the WTRU can determine whether a HARQ A / N report for the transmission is expected, as a function of the RNTI used to successfully decode the DCI associated with the transmission. For example, the WTRU can be configured to use multiple RNTIs. The WTRU can be configured to indicate that successful decoding of a DCI using a given RNTI does not require (or, conversely, requires) a HARQ A / N report for the associated transmission.

[0068] For a received DCI associated with a search space, the WTRU can determine whether a HARQ A / N report is expected for a transmission, as a function of the search space of the DCI associated with the transmission. For example, a WTRU can expect to generate a HARQ A / N report for a transmission associated with a DCI received within a common search space (CSS), but may not expect it for DCIs received within a WTRU-specific search space (or UE-specific search space (UESS)), and / or in the latter case, the WTRU can apply additional rules. For example, a WTRU can be configured to use multiple UESSs (or similar, e.g., UESSs can be split), and the reception of a DCI within a particular UESS (or part thereof) may indicate that a HARQ A / N report is not expected, while for a different UESS (or part thereof), it may be expected.

[0069] For the location of a DCI in the search space, the WTRU can determine whether a HARQ A / N report is expected for a transmission as a function of the control channel element (CCE) of the DCI associated with the transmission. For example, such a CCE could be the first CCE for the received DCI. The CCEs can be organized using a numerological sequence (e.g., the first CCE in the SS is #0 and the second CCE is #2) so that the WTRU can determine that a HARQ A / N report can be expected when the first CCE of the DCI matches a particular CCE in the SS (e.g., an even-indexed CCE), but not for another CCE in the SS (e.g., an odd-indexed CCE).

[0070] For a DCI aggregation level (e.g., the number of CCEs, such as 1, 2, 4, or 8 CCEs), a WTRU can determine whether a HARQ A / N report is expected for a transmission as a function of the DCI aggregation level (AL) associated with the transmission. For example, a WTRU might expect to generate a HARQ A / N report for transmissions associated with an AL of 4 or higher, while not requiring one otherwise.

[0071] For other DCI content, for example, scheduling information and / or transmission characteristics (as further described herein) may be used. In one method, the WTRU may use any of the methods described above to determine whether a DCI that has been successfully decoded includes a UCI (or HARQ feedback only) request as described herein.

[0072] A WTRU can determine that a transmission is characterized according to at least one of the following: identification information of the associated HARQ process, redundancy version, initial transmission or retransmission for the associated HARQ process, scheduling type for the transmission, timing associated with the transmission, scheduling parameters, concurrent downlink transmission and / or UCI aggregation size, or any combination thereof.

[0073] For the identification information of an associated HARQ process, the WTRU can determine whether a HARQ A / N report is expected for a transmission as a function of the identification information of the HARQ process associated with the transmission (or indicated in the DCI). For example, a WTRU may not be expected to generate HARQ A / N reports for a subset of HARQ processes, while it may be configured to generate HARQ A / N reports for other processes. For example, a WTRU may be determined to always be expected to generate HARQ A / N reports for processes configured to use semi-permanent assignments.

[0074] For redundancy versions (e.g., 0, 2, 3, 1), the WTRU can determine whether a HARQ A / N report is expected for a transmission as a function of the redundancy version (RV) associated with the transmission. For example, the WTRU may generate a HARQ A / N report for RV=2, 3, and 1, but not for RV=0.

[0075] For initial or retransmissions of an associated HARQ process, the WTRU can determine whether a HARQ A / N report is expected for the transmission, as a function of whether the transmission is an initial transmission of the HARQ process. For example, the WTRU can determine that only for HARQ retransmissions it is expected to generate a HARQ A / N report.

[0076] For the type of scheduling for a transmit, the WTRU can determine whether a HARQ A / N report is expected for the transmit as a function of whether dynamic scheduling information for the transmit (e.g., DCI on the physical downlink control channel (PDCCH) that provided the transmit parameters) has been received, or whether the transmit was received using a configured assignment. For example, the WTRU can determine that a HARQ A / N report may not be required for dynamically scheduled transmits (although it may always be required for semi-permanent assignments, for example), and may make further decisions in combination with other methods described herein.

[0077] For timing associated with a transmission (or associated UCI transmission), the WTRU can determine whether a HARQ A / N report is expected for the transmission as a function of the transmission time interval (TTI) (or subframe or slot) associated with the downlink transmission. For example, the WTRU can be configured so that for one or more subframes within a frame (e.g., even subframes), it is not required to generate a HARQ A / N report.

[0078] For scheduling parameters (e.g., TB size and MCS) that are likely related to other metrics such as channel quality, the WTRU can determine whether HARQ A / N reporting is expected for a transmit as a function of the parameters associated with the transmit. For example, the WTRU may determine that HARQ A / N reporting is required for TBs greater than a certain value, and not required otherwise. Similarly, MCS can be used as a determinant. For example, the WTRU may determine that HARQ A / N reporting can be optional if the expected BLER is higher than a threshold. The WTRU can use a combination of one or more characteristics of a downlink transmit, such as the last reported CSI, an MCS greater than the threshold function of the CQI, and a transmit rank greater than the rank indicator (RI).

[0079] For simultaneous downlink transmissions and / or UCI aggregate sizes, the WTRU can determine whether a HARQ A / N report is expected for a transmission as a function of the number of payload bits, the total sum for all transport blocks, or any other aggregated metric associated with a time interval, such as when the transmission meets certain conditions, e.g., when it is greater than X. The WTRU can perform a similar determination as a function of the UCI aggregate size, e.g., the sum of HARQ A / N bits expected according to legacy behavior can exceed a certain value X bits.

[0080] Combinations of the examples described can be used. For example, a WTRU may be configured to generate a HARQ A / N report for one (or more) specific HARQ processes when it receives an explicit feedback request, such as the receipt of a DCI (UCI) as described herein, and otherwise the WTRU may not generate a HARQ A / N report for the relevant processes, and such behavior may be combined with additional rules so that the WTRU can generate a HARQ A / N report under other circumstances. For example, a WTRU may generate a HARQ A / N report starting from the x-th retransmission for the relevant HARQ process, and / or a WTRU may generate a HARQ A / N report when it receives a dynamic scheduling for uplink resources for UCI reporting as described herein.

[0081] The methods described herein may be applicable as a function of the physical channel used for reporting. A WTRU may determine whether it can perform the above-mentioned decisions, or whether it can use legacy behavior for generating HARQ A / N reports to communicate UCI, as a function of the type of uplink transmission. For example, a WTRU may use legacy behavior when it determines that it can transmit HARQ A / N reports using one (or more) PUCCH transmissions. When a WTRU determines that it can transmit HARQ A / N reports using one (or more) PUCCH transmissions, it may determine that some HARQ A / N reports can be optional. A WTRU may perform such decisions as a function of the timing of the relevant uplink transmissions.

[0082] The methods described herein may be applicable as a function of the carrier associated with the transmission. A WTRU may determine whether it can perform the above-described decision, or whether it can associate legacy behavior for generating HARQ A / N reports with downlink transmissions, as a function of the carrier type. For example, a WTRU may use the first method for a carrier in licensed bands, while using the second method for a carrier in unlicensed bands. For example, a WTRU may generate a HARQ A / N report (or more generally, a UCI report) for an unlicensed band (e.g., for LTE Licensed Auxiliary Access (LAA)) (and / or for CSI) when it successfully receives a DCI containing a UCI (or HARQ feedback only) request (as described herein). In any case, for example, a WTRU may report the status of the relevant HARQ process, such status may be determined (and correspond to) the time of receipt of such request, for example. Otherwise, WTRUs are not required to generate relevant UCI feedback (for example, other rules may apply). For example, WTRUs are not required to generate HARQ A / N reports for all received transmissions.

[0083] In any of the examples described herein, such transmissions may be at least one of the following: PDSCH and at least one of a particular type of DCI. The transmission may be a PDSCH transmission. The transmission may be a sidelink. The transmission may be a direct WTRU-to-WTRU transmission, e.g., a physical sidelink shared channel (PSSCH) (for data), a physical sidelink controlled channel (PSCCH) (for control), and / or a physical sidelink discovery channel (PSDCH) (for discovery).

[0084] A transmission may be a DCI that modifies a semi-permanent downlink assignment or a semi-permanent uplink grant. A transmission may be a DCI (UCI) that includes, for example, a UCI request and / or dynamic UCI scheduling information, as described herein. A DCI may be any other DCI to which any of the methods described above can be applied.

[0085] In any of the examples described herein, such transmission may be associated with a serving cell, which serving cell may be at least one of the following: namely, the type of serving cell in the WTRU configuration, the cell configuration, the group of cells, the state of the cells, and the quality of the cells.

[0086] In the example, a serving cell can be a type of serving cell in the WTRU configuration. For example, a cell can be a secondary cell (such as a SCell) in the WTRU configuration such that conditional HARQ A / N reporting applies to such transmissions for such cells. For example, a WTRU may not apply conditional HARQ A / N reporting to any such transmissions for primary cells (such as PCell) in the WTRU configuration, for a WTRU configured to use carrier aggregation or for a WTRU configured to use dual connectivity. For example, a WTRU may not apply conditional HARQ A / N reporting to any such transmissions for a specific cell in a secondary cell group (such as a PSCell) for a WTRU configured to use dual connectivity.

[0087] In another example, a serving cell can be configured in the cell configuration. For instance, a cell can be configured (by means of radio resource control (RRC) or media access control (MAC), for example) so that conditional HARQ A / N reporting is applied to such transmissions for such a cell.

[0088] In the example, a serving cell may be part of a group of cells. For example, a cell may be part of a specific group of cells, such as a “HARQ A / N group,” so that conditional HARQ A / N reporting applies to such transmissions for such cells. Such a group may correspond to a secondary cell group (e.g., a Continuity of Service Gateway (SCG)) for a WTRU configured to use dual connectivity. Such a group may correspond to a secondary timing advance group (e.g., a Secondary Timing Advance Group (sTAG)) for a WTRU configured to use carrier aggregation.

[0089] In a further example, a serving cell can be associated with a cell state. For instance, a cell can be associated with a state to control whether conditional HARQ A / N reporting is applied. A WTRU can change such a state based on various events, such as the reception of L1 signaling or L2 / MAC control signaling indicating a change in the cell's state. For example, a cell can be in an inactive state so that conditional HARQ A / N reporting is applied to the uplink control signaling associated with the cell.

[0090] In a further example, the quality of a serving cell can be used. For example, cell quality can be based on WTRU measurements. For instance, WTRU may determine that the quality of a cell is below (or above) a certain threshold, and it may determine whether it can apply conditional HARQ A / N reporting to such transmissions for a cell until it determines that the quality has changed sufficiently, significantly, and perhaps over a sufficiently long period of time. WTRU may make such a determination only for cells that report measurements about them, for example, channel quality indicators (CQIs). WTRU may make such a determination when it performs transmissions of such measurements for the relevant cells.

[0091] Additional control information can be placed within the uplink transmission, including the UCI report. In one way, the WTRU can communicate whether non-legacy processing of the HARQ A / N bit has been applied by transmitting, for example, a 1-bit indicating whether a conditional HARQ A / N has been applied to the uplink control signaling within the uplink transmission, or it can add a CRC. For example, the WTRU can do at least one of the following: concatenate a 1-bit (a 1-bit flag indicator is added to the transmission), concatenate a CRC (for example, a 3-bit CRC can be added to the transmission, thereby associating different methods with different CRC calculations), or use different resources / characteristics of PUCCH.

[0092] In one method, a WTRU may associate priority with a HARQ A / N report for such a transmission using any of the methods described above. In addition, a WTRU may process information bits associated with a HARQ A / N report in accordance with at least one of the following: a WTRU may drop information bits; a WTRU may set the value of information bits to a specific value; a WTRU may bundle information bits with other information bits; a WTRU may encode information bits with less protection; and a WTRU may transmit information bits using different physical layer channels.

[0093] If the WTRU can drop information bits, it may, for example, not transmit any HARQ A / N for a lower-priority transmission. In such cases, the WTRU may choose a different (possibly smaller) format if the resulting total number of HARQ A / N bits to be transmitted is suitable for the chosen format. Alternatively, the WTRU may perform an uplink transmission of HARQ A / N signaling if present, so that enode B can interpret the absence of the relevant HARQ A / N bits as a NACK.

[0094] If the WTRU can set the value of the information bits to a specific value (such as NACK), the WTRU can use coding for the HARQ A / N bits so that energy is not wasted on transmitting a HARQ NACK, and enode B can interpret the absence of HARQ A / N as NACK.

[0095] If a WTRU can bundle information bits with other information bits (such as those of similar priority), the WTRU can bundle multiple HARQ A / N information bits, for example, based on the activation state of the SCell associated with the transmission for which the HARQ feedback was generated. For example, feedback for carriers of similar priority can be bundled together, perhaps only for carriers associated with lower-priority uplink control information.

[0096] If the WTRU can encode the information bits with less protection, for example, the WTRU can do so in cases where non-uniform error protection is applied to the transmission of the information bits.

[0097] If a WTRU can transmit information bits using different physical layer channels, it may transmit information bits using a different physical layer channel than the one used for transmitting higher-priority bits.

[0098] The solutions described above can also be used to determine whether a WTRU transmits a HARQ A / N on a particular resource or channel. For example, in cases where a WTRU can determine that a transmission on a PUCCH or on a particular PUCCH resource will only occur if at least one HARQ A / N bit is transmitted based on one of the solutions.

[0099] In some examples described herein, selective partial bundling can be used. In some examples, the number of information bits generated for HARQ-ACK can be reduced by applying bundling to a subset of transport blocks that can be dynamically selected to minimize the number of resulting unnecessary retransmissions.

[0100] More generally, a WTRU may apply a first solution to a first subset of transport blocks for generating HARQ-ACK information bits, and a second solution to a second subset of transport blocks, where the first and second subsets of transport blocks are selected based on at least one criterion that can change dynamically. For example, the criterion may be that the number of correctly received transport blocks for which the WTRU does not acknowledge is minimized relative to a given number of HARQ-ACK information bits. The WTRU may generate additional HARQ-ACK information bits to indicate which groups belong to the first subset and which belong to the second subset, for example, using a combination index.

[0101] Examples of generating HARQ-ACK information bits on a group of transport blocks include at least one of the following: no bundling, full bundling, and partial bundling. In the case of no bundling, one bit can be generated for each transport block, with a first value ("ACK" or 1) generated if the transport block was received correctly, and a second value ("NACK" or 0) generated if the transport block was not received correctly or not received at all. In the case of full bundling, one bit can be generated for all transport blocks, with a first value ("ACK" or 1) generated if all transport blocks were received correctly, and a second value ("NACK" or 0) otherwise. In the case of partial bundling, one bit can be generated for each of several subsets of transport blocks belonging to the group, with a first value ("ACK" or 1) generated for each subset of transport blocks, with a second value ("NACK" or 0) generated if all transport blocks belonging to the subset were received correctly, and a second value ("NACK" or 0) otherwise.

[0102] In the foregoing, a subset and / or group of transport blocks can be defined as a transport block that can be received from, for example, a serving cell (or a subset thereof), a subframe (or a subset thereof), or a combination thereof. Groups can be explicitly configured by a higher layer or implicitly derived from the configuration (for example, the group size can be set to a fixed value, and groups can be defined from the order of the configured serving cells in the configuration).

[0103] For example, in an FDD, the WTRU is configured to use 32 serving cells and can receive up to 64 transport blocks within a subframe. One can define eight groups of eight transport blocks, each corresponding to a transport block that can be received from a set of four serving cells. Two of the eight groups can generate HARQ-ACK information bits according to the "no bundling" solution, and the remaining six groups can generate HARQ-ACK information according to the "full bundling" solution, resulting in 16 bits plus 6 bits for all groups. In addition, five information bits can be generated to represent the combination index for the 28 possible combinations when selecting the two groups from the eight groups in which the "no bundling" solution is used within this subframe. To select which two of the eight groups use the "no bundling" solution, the WTRU can determine, for each group, the number of transport blocks that would generate a "NACK" despite successful reception if "full bundling" were used. The WTRU can select the two groups with the highest number of successfully received transport blocks. For example, within a subframe, the number of successfully received transport blocks may be as follows: 8 for groups 1, 4, and 8; 5 for group 2; 4 for group 3; 2 for groups 5 and 6; and 0 for group 7. In this case, the WTRU can select groups 2 and 3 for the "no bundling" solution, while all other groups use "full bundling."

[0104] The selection of a group for which a given bundling solution is applied can be based on at least one of the following criteria: The group selection can be based on minimizing the number of correctly received transport blocks within a subframe for which the WTRU does not acknowledge, as described herein. Alternatively, the group selection can be based on the presence or number of correctly received transport blocks within a group's set of preceding subframes for which the WTRU does not acknowledge. In addition, the group selection can be based on the number of times a "ACK" was not reported for a successfully received transport block within the group. For example, the WTRU may use a "no bundling" solution for a group for which it would otherwise report a "NACK," for the group with the maximum number of such blocks, or for which this number can exceed a threshold. Furthermore, the group selection can be based on indications from the physical layer or higher-level signaling regarding the bundling solution applied to a given group. Such indications can be included in a PDCCH / Evolved PDCCH (E-PDCCH) field containing downlink (DL) assignments for a group's serving cells, or in a PDCCH / E-PDCCH containing information about DL assignments within a subframe. This allows the network to override the group selection by the WTRU, regardless of whether the WTRU has received a DL assignment from a particular serving cell of the group. Furthermore, the group selection can be based on the characteristics of one of the group's PDSCH transmissions. Additionally, the group selection can be based on the DCI format used to schedule the group's PDSCH transmissions.

[0105] In the examples disclosed herein, when a bundling solution is used across a group of serving cells, the WTRU can determine whether a DL allocation has been lost within a serving cell from an indication in the PDCCH / E-PDCCH that includes DL allocations for other serving cells in the group. Such an indication may include the number of DL allocations transmitted within the group in this subframe. The WTRU can determine that a DL allocation has been lost and therefore report a "nack" for the group if the total number of correctly received DL allocations for the group in the subframe is lower than the indicated number.

[0106] In some cases, it is possible to display the index of the delivered cell or TB. Furthermore, in some cases, the WTRU can be configured by a higher layer to report an ACK using only the PUCCH A / N (ACK / NACK) resource. In such cases, the lack of feedback by the WTRU can imply that it represents a NACK at e-node B. The TB and HARQ processes can be used interchangeably.

[0107] In the PUCCH format, which allows reporting of multiple transport block HARQ A / N bits (presumably from multiple cells), there can be a predetermined location in the bit string for each possible TB HARQ A / N report. The WTRU can leave any bit representing the TB HARQ A / N blank (or set to a pre-configured value), for which it may otherwise send a NACK.

[0108] In another example, pre-configured locations can exist within a bit string where sets of TB HARQ A / N reports can be placed. Such sets of bit locations can be used to report subsets of ACKs for multiple TBs. For example, a HARQ A / N bit string reported within a PUCCH can consist of sets of x bits, each of which can be used to report HARQ A / Ns for n TBs. In this example, the WTRU is all possible 2 of the set of bits. x The code points can be pre-configured (perhaps semi-statically) to have meaning, and each code point can identify a different subset of TBs for which an ACK can be assumed at e-node B. As a simple numerical example, the bit string reported within PUCCH can consist of five sets of 2 bits each. Each set of 2 bits can be used to report an ACK for any of the three TBs. For example, the code point "00" may indicate no ACK for any of the three TBs, "01" may indicate an ACK for the first TB, "10" may indicate an ACK for the second TB, and "11" may indicate an ACK for the third TB. The meaning of each code point can be semi-statically set by e-node B and can also indicate a group of TBs for which delivery has been acknowledged (for example, the code point may indicate that the first and second TBs are ACKed).

[0109] In another example, there may not be a predetermined location in the bit string for each TB HARQ A / N report. In such an example, it is not necessary to reserve space in the bit string for TB HARQ A / N reports that do not show an ACK. This can enable, on average, a larger number of possible TB HARQ A / N reports, as capacity can be avoided for TB HARQ A / N reports with no ACKs.

[0110] In cases where a predetermined (and / or pre-configured) location is not used for each TB HARQ A / N within the bit string of the HARQ A / N report, the WTRU may indicate the TB for which an ACK is sent to e-node B. A unique identifier (possibly a bit string) for each TB can be provided to the WTRU from all possible cells. The WTRU can report back the identifier as an ACK within the PUCCH. For example, in the case where the WTRU has up to 64 TBs being sent in a subframe, a 6-bit identifier for each TB can be provided to the WTRU. In such cases, the HARQ A / N report can simply include the 6-bit string for any TB for which an ACK is sent to the WTRU. In one example, the TB identifier can be provided when the WTRU is scheduled to use a transport block. In another example, the WTRU can determine the TB identifier as a function of the identifier (such as the cell identification information (ID)) of the cell sending the TB and the HARQ process ID.

[0111] In some of the examples presented herein, a WTRU may have multiple ACKs to send within a PUCCH resource. In solutions where each TB HARQ A / N is not configured to use a specific bit location within the HARQ A / N bitstring, there may be situations where it is necessary to send more ACKs within a PUCCH instance than the PUCCH capacity allows. In such situations, the WTRU can down-select any TB for which an ACK should be fed back within any PUCCH instance. Any TB for which no ACK is sent can be assumed, and perhaps mistakenly, to be a NACK at e-node B.

[0112] The WTRU may indicate to e-node B that the PUCCH feedback does not include all ACKs and that down selection was used by the WTRU. In another example, the WTRU may include with each ACK transmission an indication to e-node B that the ACK for its TB is for the most recently transmitted PDSCH or for a preceding version. For example, in reality, a WTRU may only be able to send an ACK after a second retransmission when it has been confirmed for delivery after the first retransmission. Indicating to the WTRU whether the ACK occurred for a preceding retransmission, and / or perhaps for which retransmission the ACK occurred, may enable e-node B to use link adaptation.

[0113] The selection of ACKs to send can be performed autonomously by the WTRU according to several pre-configured rules. The WTRU can determine a subset of ACKs to send by at least one of a priority list and a set of semi-statically configured rules.

[0114] Priority lists can be preconfigured by eNode B and determined as a function of TBs and / or SCells sending TBs. WTRUs can rank acknowledged TBs and, in either case, send ACK feedback for the first TB, assuming PUCCH has the capacity to send n ACKs. Priority ranking can be determined by WTRU as a function of the PDSCH content. For example, a PDSCH used for control plane transmissions (such as RRC reconfiguration messages) may have a higher ACK reporting priority than a PDSCH used for user plane transmissions. Priority ranking can depend on the type of scheduling used for the PDSCH. For example, a cross-carrier scheduled PDSCH may have a higher / lower priority than a self-scheduled PDSCH. Or, a semi-permanently scheduled PDSCH may have a higher / lower priority than a PDSCH scheduled alone.

[0115] A semi-statically configured set of rules can enable WTRU to determine which TBs for which ACKs are sent within a PUCCH instance, up to the maximum allowable ACK capacity within any single instance. For example, report ACKs for confirmed processes that could have had the maximum number of retransmissions. For example, WTRU can order TB ACK reporting priorities based on the number of retransmissions per HARQ process and feed back ACKs for n processes that have the maximum number of retransmissions. For example, report ACKs for confirmed processes whose ACK reports were skipped earlier. These could possibly be ordered by how many times ACK reports were skipped during a process (e.g., the most skips result in the highest ranking). For example, report ACKs for confirmed TBs with the highest / lowest data rates, and / or highest / lowest MCS, and / or highest / lowest number of PRBs, and / or highest / lowest RIs. For example, report ACKs for confirmed TBs sent with / without spatial multiplexing. The above rules can be used in any combination, and the order in which the rules can be followed can be pre-configured. For example, the first rule could be to report an ACK for a delivery-acknowledged process whose ACK was skipped earlier. If fewer than n processes are eligible, the PUCCH feedback could further satisfy ACKs for processes that satisfy another rule (such as the process with the maximum number of retransmissions).

[0116] Priority lists and / or sets of rules can be configured semi-statically and may also depend on the timing of PDSCH and / or PUCCH. There may be subsets of subframes such that in a first subset of subframes, a first set of rules is used to down-select ACK feedback, and in a second subset of subframes, a second set of rules is used to down-select ACK feedback.

[0117] In a given subframe or group of subframes, the WTRU may determine a method for generating HARQ-ACK information according to at least one of the following, namely, no bundling, fixed bundling of HARQ A / N reports for a determined subset of transport blocks (such as in the spatial, frequency, and / or time domain), conditional HARQ A / N report generation as described herein, selective partial bundling as described herein, and down selection of ACK transmissions as described herein, which may include HARQ A / N reports in which HARQ-ACKs are concatenated in a predetermined order.

[0118] The method for generating a HARQ-ACK to be applied in a particular subframe, and possibly the selection of its parameters, can be determined according to at least one of the following: namely, the payload of the HARQ-ACK information bits, the maximum payload accommodated by the PUCCH format, the maximum payload accommodated by the PUSCH transmission, and at least one of the indications from the physical layer, MAC, or RRC signaling.

[0119] The payload of HARQ-ACK information bits can be used to determine how to apply it in a particular subframe. The payload can determine the number of received transport blocks to which a HARQ-ACK transmission is related (based on received DL assignments), or the maximum number of receivable transport blocks to which a HARQ-ACK transmission is related (based on the maximum possible number of received DL assignments and the maximum number of transport blocks per assignment, etc.).

[0120] To determine how to apply within a particular subframe, under the condition that no PUSCH transmissions occur within that subframe, the maximum payload that can be accommodated by the PUCCH format configured for use within that subframe can be used. For example, the WTRU can choose to generate a smaller number of HARQ-ACK information items than the maximum.

[0121] To determine how to apply this within a particular subframe so that the number of REs required to transmit HARQ-ACK information does not exceed a threshold, the maximum payload that can be accommodated by a PUSCH transmission within that subframe can be used.

[0122] To determine how to apply this within a specific subframe, indicators from the physical layer, MAC, or RRC signaling can be used. For example, fields belonging to the PDCCH / E-PDCCH, including downlink assignments, uplink grants, or information about a set of downlink assignments and uplink grants, can be used to indicate how HARQ-ACK information can be generated, or the maximum number of HARQ-ACK bits that can be generated.

[0123] The following solution addresses the issue of insufficient maximum payload for UCI within PUCCH, which includes at least one of HARQ-ACK, Channel State Information (CSI), and SR. In the example, the number of available encoded bits within PUCCH can be increased.

[0124] In some solutions, the PUCCH payload can be increased by using higher modulation order symbols, such as 16 quadrature amplitude modulation (QAM), 64QAM, and 256QAM, which are higher modulation orders than those of QPSK.

[0125] For example, the number of encoded bits carried in a single 16QAM symbol is 4 bits, which is twice as many as those carried in a single legacy PUCCH QPSK symbol (such as PUCCH format 3). A legacy PUCCH format 3 payload can be encoded to 48 bits, which can then be mapped to 24 QPSK symbols. For example, if 16QAM symbols can be used instead of QPSK for the same number of symbols, such as 24 symbols, PUCCH can carry 4 × 24 = 96 encoded bits, which, compared to the maximum number of encoded bits in legacy PUCCH format 3 using QPSK modulation, is twice as many.

[0126] WTRU can use different modulation orders for different symbols that can be mapped to different PUCCH REs.

[0127] A WTRU can use different modulation orders for different symbols that can be mapped to different subcarriers. For example, out of 12 subcarriers per PUCCH RB, n subcarriers (e.g., n=4) can carry QPSK-modulated symbols, and (12-n), i.e., 8 subcarriers, can carry 16QAM-modulated symbols. The total number of encoded bits for a PUCCH with two PRBs can be calculated as follows (assuming that all SC-FDMA symbols within the same PRB can carry the same information): 2×[n×2+(12-n)×4]=96-2×n Equation (1) All symbols mapped to the same subcarrier within the same PUCCH PRB can be modulated using the same modulation order, such as QPSK and 16QAM.

[0128] A WTRU can use different encoders and / or generate different sets of encoded bits. Different sets of encoded bits can be mapped to different sets of PUCCH symbols, and each set of PUCCH symbols can be modulated using different modulation techniques, such as QPSK and 16QAM. As an example, two encoders can be used to encode the information bits carried within a single PUCCH PRB, which may be called "encoder A" and "encoder B". Each encoder can have a different set of information bits as its encoder input. The output of encoder A can be modulated using a certain modulation technique, such as QPSK, and can be mapped to a certain number of PUCCH subcarriers, such as four subcarriers. The output of encoder B can be modulated using a different modulation technique, such as 16QAM, and can be mapped to a different set of PUCCH subcarriers, such as 12-8=4 subcarriers. The total number of encoded bits for a PUCCH with two PRBs can be calculated as 88 according to the formula described earlier (assuming that all SC-FDMA symbols within the same PRB can carry the same information).

[0129] Each PUCCH encoder, which can map encoded bits to different modulation orders / techniques, can have different levels of protection and / or robustness against channel / decoding failures. For example, encoded bits that can ultimately be mapped to 16QAM symbols may have less robustness against channel / decoding failures compared to encoded bits mapped to QPSK symbols.

[0130] A WTRU can have two or more different sets of information bits, which have the potential to meet two or more different performance requirements. These two or more different sets of information bits can be encoded using two or more encoders, and / or the encoded bits can be modulated by two or more modulation techniques, such as QPSK and 16QAM. These two or more sets of modulation symbols can be mapped to two or more sets of subcarriers and / or REs.

[0131] For example, a WTRU can use HARQ ACK / NACK bundling to bundle the HARQ ACK / NACK bits of several component carriers, and / or the WTRU can not bundle the HARQ ACK / NACK bits of several other component carriers. Since an error in receiving bundled HARQ ACK / NACK bits can affect the operation of more component carriers compared to an error in unbundled HARQ ACK / NACK bits, a WTRU can assign bundled HARQ ACK / NACK bits to an encoder that can ultimately map them to QPSK symbols, while a WTRU can assign unbundled HARQ ACK / NACK bits to an encoder that can ultimately map them to 16QAM symbols. As a result, bundled HARQ ACK / NACK bits can have higher protection against channel / decoding failures compared to unbundled HARQ ACK / NACK bits.

[0132] A WTRU can determine its modulation scheme based on the number of encoded bits that need to be transmitted within a subframe. For example, assuming the same spreading scheme and number of RBs as PUCCH format 3 are used (i.e., two symbols and one RB per subcarrier), a WTRU can transmit using QPSK if 48 encoded bits are required, or using 16QAM if 92 encoded bits are required.

[0133] In some solutions, the PUCCH payload can be increased by allocating two or more resource blocks to a single PUCCH resource. Such solutions may be referred to as "extended PUCCH" when described herein.

[0134] Figure 2 shows an example of a possible RE mapping for an extended PUCCH design utilizing two consecutive RBs. As shown in mapping 200, the time and frequency dimensions are represented by the horizontal and vertical axes, respectively. In the example of mapping 200, RB#1 210 and RB#2 220 are consecutive and transmitted within the same time slot. This design can have the benefit of preserving the single-carrier characteristics of uplink transmission. The number of REs available to carry uplink control information can be essentially doubled compared to the legacy transmission format utilizing a single RB.

[0135] In some solutions where PUCCH utilizes two RBs, the demodulated DM-RS230 can be transmitted in the same time symbols as in legacy transmission formats, such as PUCCH format 3. Information 240 and Information 250 can also be transmitted, as shown in Figure 2.

[0136] As described herein, different solutions for determining the DM-RS sequence can also be considered.

[0137] In the first solution, the DM-RS sequence for extended PUCCH is a basic sequence F of length 24, used for the DM-RS sequence of PUSCH assignment of two RBs in the legacy system. u,v It can be generated from (<<). Such a base sequence can be different from the base sequence of length 12 used for PUCCH. The sequence itself can be defined as a cyclic shift of the base sequence.

[0138]

number

[0139] The benefits of this solution are that the DM-RS sequence has a low peak-to-average power ratio, and that this allows for the multiplexing of other extended PUCCH resources using the same pair of RBs by using different cyclic shifts of the same basic sequence.

[0140] In the second solution, the DM-RS sequence for the extended PUCCH can be generated from two concatenated basic sequences of length 12. In other words, the DM-RS sequence used for the extended PUCCH

[0141]

number

[0142] teeth,

[0143]

number

[0144]

number

[0145] This can be expressed as follows, where K can be a unit amplitude constant, which likely depends on group sequence numbers u1 and u2, configured to keep the peak-to-mean ratio of the DM-RS sequence low. Group sequence numbers u1 and u2 can be set to the same value u. In this case, the extended DM-RS sequence in this solution has a different cyclic shift α i And using α2, and for the second sequence, phase offset β, K≡e jβ Using this, two concatenated DM-RS sequences of length 12, generated from the same basic sequence, for example,

[0146]

number

[0147] and

[0148]

number

[0149] It can be considered equivalent to this.

[0150] An exemplary benefit of this solution is that, provided that the cyclic shifts of PUCCH format 3 on the first RB (or second RB) are different from α1 (or α2), respectively, and orthogonality is also guaranteed for the information-carrying resources, it can enable multiplexing of extended PUCCH resources with PUCCH format 3 resources on the same RB. Multiplexing with other extended PUCCH resources on the same pair of RBs can also be enabled using appropriate selection of cyclic shifts. The possible combinations of cyclic shifts α1 and α2 and the set of phase offsets β can be restricted so as to maintain desirable characteristics of the DM-RS sequence (e.g., a low peak-to-average power ratio). For example, the use of a phase offset of pi / 4 can result in a lower peak-to-average power ratio than without using a phase offset.

[0151] In all of the above solutions, the values ​​of the cyclic shift and phase offset β used for the DM-RS can be functions of the time symbols transmitted within the DM-RS.

[0152] The processing of information carried by the extended PUCCH can be the same as the processing used for PUCCH format 3 after modulation. Each modulation symbol can be spread over one subcarrier and one time slot, resulting in a total of 48 modulation symbols or 96 encoded bits when QPSK is used. This technique has the advantage of enabling multiplexing of the extended PUCCH with PUCCH format 3 on the same RB, provided that DM-RS orthogonality is also achieved.

[0153] The WTRU can determine the number of RBs based on the number of encoded bits that need to be transmitted within a subframe. For example, assuming the same spreading and modulation scheme as PUCCH format 3 (i.e., two symbols per subcarrier, and QPSK) is used, the WTRU can transmit on two RBs if 96 encoded bits are required, or on three RBs if 144 encoded bits are required. When there are two or more RBs used for PUCCH, the WTRU can apply a transform precoding using one of the following solutions.

[0154] In this solution, the WTRU can apply the Discrete Fourier Transform (DFT) to all transmitted subcarriers. If the WTRU does not transmit over one of the RBs defined for PUCCH transmission (for example, according to one of the solutions described in the following paragraphs), the DFT may not be applied to the corresponding subcarrier. This solution can ensure that the output signal maintains, as much as possible, the desirable characteristics of SC-FDMA (e.g., low cubic metric).

[0155] In an alternative solution, the WTRU can have the DFT applied separately on each RB. This solution can reduce receiver complexity in cases where there is uncertainty about whether the WTRU will transmit on each RB.

[0156] In some solutions, spatial multiplexing can increase the PUCCH payload. Such solutions may be referred to herein as “rank n PUCCH,” where n is the number of layers. When the number of REs available for transmitting information remains the same, such solutions can increase the number of modulation symbols (and encoded bits) by a factor of n. The WTRU can transmit a different DM-RS sequence for each antenna port corresponding to a layer.

[0157] In some solutions, each DM-RS sequence transmitted per antenna port is the same basic sequence of length 12.

[0158]

number

[0159] It can be generated from the DM-RS sequence used within the time symbol.

[0160]

number

[0161] This allows the use of different cyclic shifts a for each antenna port p. This technique has the advantage of enabling multiplexing with legacy PUCCH format 3 transmissions within the same resource block.

[0162] When spatial multiplexing is used, channel quality, such as that observed by an e-node B receiver, can differ between the two antenna ports. In some solutions, the WTRU can therefore utilize different coding rates, coding schemes, and / or modulation schemes between the two transmit layers to ensure that at least one type of error performance objective for uplink control information is met for the lowest possible transmit power. For example, in the case of rank 2 PUCCH (n=2), at least one of the following solutions can be applied: processing of k information bits of a given type such that the k1 information bits are encoded, modulated, and mapped on the first antenna port and the k2 information bits are encoded, modulated, and mapped on the second antenna port; encoding, modulating, and mapping of a first type of information bits on the first antenna port and a second type on the second antenna port; determining the modulation order to be used on each antenna port (e.g., QPSK or 16QAM); determining the number of encoded bits available on each antenna port; and determining the encoding scheme to be used on each antenna port (e.g., block code, convolutional code, turbo).

[0163] For example, a WTRU may need to transmit k=30 bits of a given information type (such as a HARQ-ACK) over a rank 2 PUCCH. The WTRU may decide that k1=20 bits and k2=10 bits will be encoded, modulated, and mapped on the first and second antenna ports, respectively. The WTRU may also decide that QPSK will be used on each antenna port so that 48 encoded bits are available per antenna port. The WTRU can then encode the 20 information bits mapped on the first antenna port using a 20 / 48 encoding rate, and the 10 information bits mapped on the second antenna port using a 10 / 48 encoding rate.

[0164] The WTRU can determine at least one of the above parameters using at least one of the following solutions: The WTRU can use indications received from higher-layer signaling. The WTRU can use indications received from at least one field of the DCI received on the PDCCH or E-PDCCH. For example, the DCI may be a DCI that includes one of the downlink assignments, which indicates the transport block for which the HARQ-ACK should be transmitted in a PUCCH transmission. The display may include at least one of the following: a display of the number or ratio of information bits encoded and mapped on each layer (for example, a 2-bit field may indicate that the ratio is 1 / 3, 1 / 2, 2 / 3, or 3 / 4 on the first antenna port and the remainder on the second antenna port (where the number of bits may be rounded up or down)); an A / N Resource Indicator (ARI) field overloaded to include the above (the ARI field may be equivalent to the Transmitter Power Control (TPC) field received in the downlink control information for SCell, or the same resources may be reused); a display of whether QPSK or 16QAM can be used for each antenna port; and a display of channel quality imbalance between the two antenna ports, expressed, for example, in terms of the ratio or dB difference of the signal-to-interference ratio (SINR), or in terms of the required difference between the transmitted energy per information bit on each antenna port. The WTRU can use at least one resource index associated with an N-rank PUCCH, which can be indicated using the ARI field in combination with signaling from higher layers. The number of information bits and modulation per antenna port can be configured as part of the resources configured by the higher layers.

[0165] In some examples, precoding can be used. In some examples, a WTRU with two or more antenna ports for uplink can utilize precoding similar to the precoding applied to PUCCH. This can enable spatial multiplexing of PUCCH transmissions from multiple WTRUs on the same frequency and time resources. The precoding matrix applicable to PUCCH transmissions can be provided using downlink control signaling in at least one PDCCH / E-PDCCH, including PDSCH assignments, where feedback about it is provided within subframes.

[0166] In some cases, DFT-S-OFDM with a smaller diffusion coefficient can be used. In some solutions, the PUCCH payload can be increased by spreading modulation symbols over fewer resource elements within the DFT-S-OFDM structure. For example, 48 modulation symbols spread over 3 time symbols can be mapped onto the PUCCH, in which case the number of time symbols used for DM-RS is reduced to 2.

[0167] In some solutions, the time symbols used for DM-RS can be maintained within the same time symbols as in legacy PUCCH format 3, thus maintaining the possibility of multiplexing with legacy PUCCH transmissions of this format within the same RB. In such a framework, several possibilities can be envisioned, without limitation, regarding the spreading from modulation symbols to time symbols on subcarriers, such as 10 modulation symbols (e.g., no spreading), each on a single time symbol; 5 modulation symbols, each spreading on two time symbols; 4 modulation symbols, two that can spread on three time symbols and two that can spread on two time symbols; and 3 modulation symbols, two that can spread on three time symbols and one that can spread on four time symbols.

[0168] In the case of a shortened PUCCH transmission where the last time symbol is unavailable, the number of time symbols over which the modulation symbol is spread can be reduced by one per modulation symbol. The affected modulation symbol is preferably one that is spread over a larger number of time symbols in a non-shortened PUCCH transmission.

[0169] The precise mapping from modulation symbols to time symbols within a subcarrier (and therefore the diffusion coefficient) can be parameterized to support a maximum payload value for PUCCH that depends on this parameter value. The parameter can be derived from the PUCCH resource index and can be constructed in conjunction with the PUCCH resource index.

[0170] When separate encodings are applied to different subsets of UCI bits, the encoded bits for UCIs requiring higher robustness can be carried by using modulation symbols spread over a larger number of time symbols within the PUCCH (e.g., two modulation symbols per subcarrier spread over three time symbols instead of two).

[0171] The WTRU can determine the spreading scheme based on the number of encoded bits that need to be transmitted within a subframe. For example, if 120 encoded bits are required, the WTRU can spread 5 modulation symbols per subcarrier, and if 72 encoded bits are required, it can spread 3 modulation symbols per subcarrier.

[0172] In the example, the selection of codebooks, resources and transmission formats, as well as parameters, can be used. The WTRU can determine the PUCCH transmission format and possibly associated parameters for use within a particular subframe. The PUCCH transmission format can be characterized by the total number of encoded bits and how the set of encoded bits (or each subset of encoded bits, if applicable) can be modulated, spread, and mapped to physical resources (possibly including spatial multiplexing).

[0173] The PUCCH transmission format may include at least one of the legacy PUCCH formats such as 1, 1a, 1b, 2, and 3, as well as newer PUCCH formats that support higher payloads, such as formats based on one or a combination of the techniques described above (higher-order modulation, larger BW, spatial multiplexing, or reduced spread).

[0174] The selection of the format and associated parameters can be based on at least one of the following: The selection can be based on the number of information bits for different types of UCI (including multiple types of HARQ-ACK, CSI, SR) transmitted over the PUCCH. For example, the selection can be based on the presence or absence of different types of UCI transmitted over the PUCCH. Alternatively, the selection can be based on indications received from the signaling of the physical layer or a higher layer, such as DL assignment or PDCCH / E-PDCCH containing information about DL assignment. For example, the indications can include parameters indicating the number of mapped modulation symbols per subcarrier (or diffusion coefficient or set of diffusion coefficients), parameters indicating the modulation type (such as QPSK or 16QAM), and / or parameters indicating the number (rank) of layers for the PUCCH transmission. Furthermore, the selection can be based on the method used to generate the HARQ-ACK information bits transmitted within the PUCCH. In addition, the selection can be based on indications received from the signaling of the physical layer or a higher layer for at least one codebook characteristic, as described herein. Selection may also be based on a subset of feedback groups transmitted within a subframe, as described herein. Furthermore, selection may be based on dynamic scheduling of uplink resources for UCI feedback, as described herein, including, for example, a method relating to UCI scheduling information, as described herein, using a DCI (UCI) similar to that described herein.

[0175] In some solutions, the WTRU can determine all characteristics of the transmission format (including at least one of modulation, number of RBs, spreading, and spatial multiplexing) based on the number of encoded bits required, and can determine the mapping based on a predetermined set consisting of the number of encoded bits, the number of information bits, and / or a subset of feedback groups. For example, the WTRU can determine the transmission format based on a table similar to Table 1.

[0176] [Table 1]

[0177] In this example, the WTRU can determine the number of encoded bits based, for example, on the total number of information bits and the maximum coding rate, as described in the following paragraphs. For example, if the WTRU determines that 144 encoded bits are required, it can use QPSK modulation for the encoded bits, spread the modulated symbols so that three symbols are spread on each subcarrier, and map the resulting signal onto two RBs.

[0178] In some solutions, the WTRU can select several characteristics of the transmission format based on a dynamic indication, such as receiving an ARI or another field from the PDCCH / E-PDCCH. For example, a resource indicated by the received ARI may have one RB. If the required number of encoded bits is 96 bits, the WTRU can determine that the spreading should be such that four modulation symbols are spread per subcarrier, allowing for 96 encoded bits within the RB. In the case where the resource indicated by the received ARI has two RBs, the WTRU can determine that the spreading should be such that two modulation symbols are spread per subcarrier, allowing for 96 encoded bits within the two RBs. Further examples of such dynamic aspects are described herein.

[0179] In some examples, dynamic determination of codebook characteristics can be used. In some solutions, the WTRU can determine at least one characteristic of the set of information bits for the HARQ feedback and possibly other UCI (e.g., codebook) based on semi-static and / or dynamic aspects. The solution can enable minimizing the amount of resources used for transmitting such information. Further examples of such dynamic aspects are described herein.

[0180] Through extensions, the solutions described below can also be used to determine the PUCCH format, PUCCH resource, or power control method, which can be associated with codebook characteristics (such as codebook size). For example, WTRU can be used to determine if the codebook size is less than a first value, if the first PUCCH format (and / or power control method) is used, if the codebook size is greater than or equal to the first value but less than a second value, the second PUCCH format is used, and so on.

[0181] At least one of the following codebook characteristics can be determined: The number of information bits in the codebook can be determined. For example, the order of the information bits in the codebook can be determined regarding which transport block in which cell or cell group is mapped to a given position in the codebook. The interpretation of each information bit (or set thereof) can be determined, such as whether the bit represents the ACK or NACK result of decoding a transport block received on a particular cell, cell group, and / or subframe, and / or whether bundling is applied or not to the cell, cell group, or subframe. The source coding scheme that can be applied (e.g., Huffman coding) can be determined. The channel coding scheme that can be applied to the codebook (e.g., Reed-Muller, Turbo, or Convolution) can be determined.

[0182] Figure 3 is a diagram illustrating an exemplary selection process for PUCCH formats based on the size and type of feedback. In the example shown in process 300, the WTRU can receive multiple transport blocks on a set of multiple configured carriers and generate HARQ-ACK feedback 310 and CSI feedback 320 for the multiple transport blocks. Furthermore, the number of information bits required for the HARQ-ACK feedback 310, which can be represented by n, and the number of information bits required for the CSI feedback 320, which can be represented by m, can be combined (e.g., concatenated) by the WTRU in 330. The WTRU can generate a feedback message including the number of HARQ-ACK feedback bits to be used for the HARQ-ACK feedback and the number of CSI feedback bits to be used for the CSI feedback. The WTRU can then determine a possible PUCCH format based on the content of the feedback in 340. For example, this PUCCH format determination can be made based on the number of HARQ-ACK feedback bits and the number of CSI feedback bits. The WTRU can then transmit the feedback message using the determined PUCCH format.

[0183] For example, if HARQ-ACK feedback exists and therefore n > 0, and CSI feedback exists and therefore m > 0, then in 350, a first PUCCH format such as PUCCH format x, or a second PUCCH format such as PUCCH format y, can be selected. Also, if HARQ-ACK feedback does not exist and therefore n = 0, and only CSI feedback exists and therefore m > 0, then in 360, a third PUCCH format such as PUCCH format x, or PUCCH format z, can be selected. Furthermore, if HARQ-ACK feedback exists and therefore n > 0, and CSI feedback does not exist and therefore m = 0, then in 370, a fourth PUCCH format such as PUCCH format x, or PUCCH format w, can be selected.

[0184] In step 350, if PUCCH format x or PUCCH format y is selected, the WTRU can then, in step 355, compare the number of information bits in the feedback payload to a first threshold such as B1. If the feedback payload is greater than the first threshold, and therefore n+m > B1, then in step 356, PUCCH format x can be selected. Furthermore, if the feedback payload is less than or equal to the first threshold, and therefore n+m ≤ B1, then in step 358, PUCCH format y can be selected. The WTRU can then send the feedback message using the determined PUCCH format.

[0185] In step 360, if PUCCH format x or PUCCH format z is selected, the WTRU can then, in step 365, compare the number of information bits in the feedback payload to a second threshold such as B2. If the feedback payload is greater than the second threshold, and therefore m > B2, then in step 366, PUCCH format x can be selected. Furthermore, if the feedback payload is less than or equal to the second threshold, and therefore m ≤ B2, then in step 369, PUCCH format z can be selected. The WTRU can then send the feedback message using the determined PUCCH format.

[0186] In step 370, if PUCCH format x or PUCCH format w is selected, the WTRU can then, in step 375, compare the number of information bits in the feedback payload to a third threshold such as B3. If the feedback payload is greater than the third threshold, and therefore n > B3, then in step 376, PUCCH format x can be selected. Furthermore, if the feedback payload is less than or equal to the third threshold, and therefore n ≤ B3, then in step 377, PUCCH format w can be selected. The WTRU can then send the feedback message using the determined PUCCH format.

[0187] Codebook characteristics may depend on at least semi-static (or static) information such as the number of configured carriers (or cells), subframe configuration, grouping of cells within a cell group, the number of transport blocks that can be received within a given cell, the transmission mode used within a given cell, and the HARQ feedback scheme configured for use within a cell or group of cells (such as whether bundling within a subframe or cell, or bundling across subframes or cells, is applied, or whether a HARQ feedback solution as described above is applied).

[0188] WTRU can also determine codebook characteristics as a function of more dynamically changing information, such as the activation status of a cell or cell group, whether a radio link problem or failure has occurred for a cell group, or whether such has been reported for a cell group, whether it is known that a PDSCH was not transmitted from the network for a cell or cell group, or whether it is known that a PDSCH was transmitted from the network, the dynamic subframe configuration within the cell (uplink (UL) or DL), and DL control information received within the subframe.

[0189] For example, a WTRU may determine that the codebook contains only HARQ feedback for cells or groups of cells that are activated or for which no radio link failures have been reported. A WTRU may also determine that the codebook contains only HARQ feedback for cells, groups of cells, or subframes from which the WTRU determines that a PDSCH could have been transmitted. In this case, the WTRU can determine the appropriate codebook size and bit positions. For example, in a case where there are 10 configured cells and 2 transport blocks per cell, if the WTRU determines that a PDSCH could have been transmitted from only cells 2, 3, and 6, then for a 6-bit codebook size, the first 2 bits could correspond to the HARQ feedback for cell 2, the next 2 bits could correspond to the HARQ feedback for cell 3, and so on.

[0190] The WTRU can determine that it was possible to transmit a PDSCH by using one of the following solutions: The WTRU can receive an indication from the downlink control signaling contained within the PDCCH or E-PDCCH of which cells, cell groups, transport blocks, and / or subframes can transmit a PDSCH within. The indication may consist of fields, each of which possible values ​​indicate a subset of cells, cell groups, and / or subframes that can (or cannot) transmit a PDSCH within. The subset associated with each value may be predetermined or configured by a higher layer. The subset may also be a function of the cells or cell groups in which the signaling is received, or the cells or cell groups indicated within the same PDCCH or E-PDCCH in which the field is contained.

[0191] For example, if the field size is 2 bits, the value "00" can indicate that the PDSCH can only be received within the cell or cell group to which the PDSCH is scheduled within this PDCCH or E-PDCCH; the value "11" can indicate that the PDSCH can be received within any configured cell or cell group; the value "01" can indicate that the PDSCH can be received within a first set of cell groups configured by higher layers; and the value "10" can indicate that the PDSCH can be received within a second set of cell groups configured by higher layers.

[0192] In another example, to determine the codebook, the cell index of one (or more) serving cells to which the PDSCH is sent can be used in combination with the display value. In this example, any DCI with a downlink assignment can send the same display. The display value can be mapped to a different set of cells and / or carriers and / or transport blocks, which the WTRU can expect to feed back an A / N about. Determining the appropriate set based on the display can be a function of the serving cell ID of at least one cell to which the PDSCH is sent.

[0193] Table 2 provides an example of the relationship between a display and the set of cells to which a WTRU can report an A / N, as a function of serving cells. Essentially, a WTRU can determine the appropriate set as a function of a display and as a function of the set of serving cells to which at least one is a PDSCH.

[0194] [Table 2]

[0195] In cases where HARQ-ACKs should be reported for two or more subframes (for example, in the case of TDD), in one solution, the display can represent the entire codebook across all subframes and cells, regardless of the subframe in which it was received. Alternatively, the display can represent a portion of the codebook corresponding to the subframe in which it was received. Alternatively, the display can represent a portion of the codebook corresponding to the subframes up to that subframe, including the subframe in which it was received. For example, the display can represent a set of cells or cell groups that can receive PDSCH within any of the subframes up to that subframe, including the subframe in which the display was received.

[0196] The meaning of a representation (e.g., a set of transport blocks and / or cells and / or carriers and / or subframes for which the WTRU is expected to provide HARQ A / N feedback) may depend on other potentially implicit factors. For example, a WTRU may receive a specific code point or bitmap within a representation, and the WTRU may map such a representation to a different codebook depending on at least one of the following: The WTRU may map such a representation to a different codebook depending on the timing of its transmission. For example, a subframe number may be used in conjunction with the representation. In another example, a specific subframe from a set of subframes for which feedback is reported (in TDD) may be used. The WTRU may also map such a representation to a different codebook depending on another parameter of the DCI containing the representation. For example, a combination of a TPC command and a new representation may be used. In another example, a parameter of the DCI's search space (e.g., whether it is a common search space or a WTRU-specific search space, or the CCE of the search space) may be used in conjunction with the representation value. Furthermore, WTRUs can also map such representations to different codebooks, depending on the PUCCH format and / or resources indicated within the downlink assignment.

[0197] In the above, the display may be included in a subset or all of the downlink assignments. The display may also be included in one or more PDCCH / E-PDCCH (or DCI) dedicated to providing scheduling information for the UCI, as described herein.

[0198] In another example, the network can indicate which pre-configured groups of carriers contain at least one downlink assignment. Therefore, the number of NACK bits ("known" NACKs) corresponding to unscheduled carriers can be reduced when there are no scheduled downlink assignments within a given group of carriers. Thus, while it may still contain a few (fewer) NACKs from unscheduled carriers, the codebook size can be dramatically reduced. This reduction in codebook size improves not only performance in terms of power consumption but also PUCCH resource usage.

[0199] Table 3 shows another example for a WTRU configured to use 32 carriers. In this example, one of the indicator code points (00) can indicate "all carriers," allowing the WTRU to be scheduled on all carriers. Another code point (01) can indicate four disparate groups of eight carriers each. The specific group to select can be determined based on which carriers have received assignments. Two other code points (10) and (11) can indicate different groups of 16 carriers each, or perhaps groups with altered carrier order, as in Option 1. For maximum scheduling flexibility and performance, more precise mapping can be configured by higher layers. Additional flexibility can also be gained by using fields with 3 or more bits. One possibility for minimizing additional overhead is to use a single field for the ARI and codebook indicators.

[0200] [Table 3]

[0201] In the example, it may not be necessary to schedule all carriers in the indicated group. WTRU may indicate "NACK" if no DL assignment is found for any carriers included in the indicated group.

[0202] Figure 4 is a diagram illustrating an example of HARQ A / N codebook determination. In the example shown in Figure 400, the WTRU can receive downlink assignments for a subset of carriers within the set of carriers 410. For example, the WTRU can receive downlink assignments for a subset consisting of carriers 9, 10, 13, 14, 15, and 16, and for each DL assignment, the codebook indicator is "01". The WTRU has no DL assignment for carrier 12. The WTRU cannot receive an assignment for carrier 11, which may have no assignment. The WTRU can use codebook 420 which holds HARQ A / Ns for carriers such as {9, 10, 11, 12, 13, 14, 15, 16}, which includes NACKs for carriers 11 and 12.

[0203] The display may include at least one Downlink Assignment Index (DAI) received as part of the downlink control information associated with each PDSCH transmission. In this case, the WTRU may order the received PDSCHs for each cell and subframe according to predetermined rules (e.g., by cell index first, by subframe, or vice versa). The WTRU may include a HARQ A / N bit for each received PDSCH in its codebook (unless it has been determined, based on the previously described solution, that the HARQ A / N should not be included), and for each PDSCH determined to be lost based on the difference between consecutive DAI values ​​in the sequence, it may include a HARQ A / N bit (with the value "NACK"). For example, the number of lost PDSCHs may be determined to be (N-1) mod M, where N is the difference between consecutive DAI values ​​in the sequence and M is the number of possible DAI values.

[0204] The display may include fields that are received as part of downlink control information associated with at least one PDSCH transmission. The fields may indicate the final downlink assignment in a group of downlink assignments, possibly assigned within or for a particular subframe. One value of the field (e.g., "0") may indicate that the assignment is not the final assignment, while another value (e.g., "1") may indicate that the assignment is the final assignment for the group and / or subframe and / or component carrier. This may also allow the WTRU to know when to stop blind detection within a subframe and whether it has detected the final assignment.

[0205] In some solutions, the display associated with the final (or last) assignment can be derived from the value of a field that can also be used to indicate other types of information. For example, the display can be derived from at least one value of a TPC command for ARI and / or PUCCH received in one or more PDCCH / E-PDCCH, or from at least one value of a PUCCH format indicator, according to at least one of the following:

[0206] WTRU can identify an allocation as the final allocation if the ARI value for this allocation differs from at least one other allocation in the set. The set can consist of all allocations in a subframe, or all allocations in a set. In this case, the ARI value for this allocation (or the TPC command for PUCCH) cannot be used directly to indicate an index to the PUCCH resource. The determination of an allocation as the final allocation may be subject to at least one of the following additional conditions:

[0207] In the example, the number of other assignments can be at least one, perhaps limited to the same subframe. In another example, at least one other assignment can be an assignment preceding the final assignment according to a predefined sequence (e.g., first the carrier, second the subframe). In yet another example, at least one other assignment can include at least one assignment that does not correspond to a primary cell. In yet another example, the ARI value for the final assignment can be a fixed or configured value. In yet another example, the ARI value for the final assignment can be related to the ARI values ​​in other assignments. For example, the ARI value for the final assignment can indicate a PUCCH resource with a number of RBs less than or equal to the PUCCH resource indicated by the ARI value in other assignments. Furthermore, the ARI value for the final assignment can be the sum of the decoded ARIs in other assignments plus a fixed or configured value (or XORed with the fixed or configured value). For example, the ARI value for the final assignment can be 1 plus the ARI values ​​in other assignments (modulo the number of possible ARI values).

[0208] In cases where the WTRU does not find a final assignment based on one of the solutions described above, the WTRU may consider the codebook undetermined and apply actions according to the solutions described in other paragraphs. Alternatively, the WTRU may add at least one NACK (or "0") to the codebook so that the total size of the codebook corresponds to an effective size from a set of predefined or configured effective sizes.

[0209] The display may consist of fields received as part of the downlink control information associated with each PDSCH transmission. The field may indicate in the WTRU the number of remaining assignments expected after the current assignment is detected, within a group of downlink assignments (possibly for subframes and / or component carriers). The WTRU can better determine lost PDSCHs, and any NACK values ​​for lost PDSCHs can be placed in the appropriate location in the feedback report. In an alternative solution, the field may indicate the total number of downlink assignments within a group of downlink assignments and / or subframes and / or component carriers. The WTRU can determine the total number of lost PDSCHs, which can be indicated in the serving cell within the feedback report.

[0210] The display may consist of a portion of the downlink control information associated with each PDSCH transmission, for example, a field received as DAI. DAI can serve as an ascending counter, ordered according to the parameters of the serving cell (for example, DAI can serve as a cumulative counter of all assignments up to the current assignment, counting in the direction of increasing the serving cell index). For example, assuming that DAI is 2 bits and the serving cells are ordered by an ascending serving cell index, the first assignment on the first serving cell (e.g., the serving cell with the lowest serving cell index) may have DAI=00, the second assignment on the second serving cell (e.g., the serving cell with the second lowest serving cell index) may have DAI=01, and so on.

[0211] In an alternative solution, the DAI can function as a descending counter, ordered according to the serving cell parameters (for example, the DAI can function as a counter for the remaining assignments in the direction of increasing the serving cell index). For example, assuming the countdown DAI is 2 bits and the serving cells are ordered by an ascending serving cell index, the last assignment (e.g., the assignment on the serving cell with the highest serving cell index) can have a countdown DAI = 00, the second to last assignment (e.g., the assignment on the serving cell with the highest serving cell index among the remaining) can have a countdown DAI = 01, and so on.

[0212] A counter can increment by a unit value or may not have a unit counting step. For example, a descending counter for remaining assignments can repeat the DAI value for several consecutive assignments. For example, a descending counter for remaining assignments can repeat the same value for consecutive assignments of P. In the example, if there are 10 serving cells with assignments and P=3, the countdown DAI could be assigned (in the order of increasing serving cell index) as follows: 11 10 10 10 01 01 01 00 00 00. In such a solution, the WTRU can anticipate that the last P=3 assignment will have a countdown DAI of 00. In such a solution, the WTRU may be able to resolve whether it succeeded in receiving the last downlink assignment. However, if one of the assignments with a countdown DAI is missing, the WTRU may have to report a NACK for all consecutive P=3 assignments that share the same countdown DAI if it does not know which of the consecutive P=3 assignments is missing.

[0213] A hybrid solution may be possible, using both an ascending cumulative counter for the allocations and a descending counter for the remaining allocations. For example, a counter that increments in unit steps (e.g., an allocation cumulative counter where the DAI is incremented by 1 for each allocation) can be used, and an iterative counter (repeats P times) for the remaining allocations can be used. For example, assuming the cumulative DAI and countdown DAI are 2 bits, allocations of 10 could have the following combined DAI values ​​(the first 2 bits representing the cumulative DAI using unit step increments and the last 2 bits representing the countdown DAI using P=3): 0011 0110 1010 1110 0001 0101 1001 1100 0000 0100. In this case, from the cumulative counter, the WTRU is any 2 N+i Excluding consecutively lost allocations (where N is the bitwise size of the cumulative DAI and i is a non-negative integer), and / or any last lost allocation, it is possible to determine which allocations are missing, if any. Also, from the iterative descending counter of the remaining allocations, the WTRU can be calculated at most P × 2 M It is possible to determine whether consecutive allocations are missing (where M is the bitwise size of the countdown DAI) and whether the last downlink allocation is missing. By combining the two DAIs, the WTRU is P × 2 M and 2 N Any consecutive assignments can be resolved except those that are greater than the least common multiple of M and N. The values ​​of M and N do not need to be equal. For example, a situation where the cumulative counter uses N=2 bits, the descending counter for the remaining assignments uses M=1 bit, and the iterations are P=3 can result in WTRU being able to resolve any other missing assignments except for 12 or more consecutive assignments, and whether the last assignment is missing.

[0214] The field may also indicate other information related to HARQ feedback for each value, such as the format display and / or the resource index of the PUCCH to be transmitted on it ("ACK / NACK resource indicator"). For example, if the field size is 3 bits, the value "010" may indicate that a PDSCH can be received in a first set of cell groups composed of higher layers and that the transmission of HARQ feedback occurs on a given PUCCH format with respect to a first value of the resource index composed of higher layers; the value "011" may indicate that a PDSCH can be received in a first set of cell groups composed of higher layers and that the transmission of HARQ feedback occurs with respect to a second value of the resource index composed of higher layers, and so on. Alternatively, information about one or more PUCCH resource indices to be used may be provided in a separate field or in a separate PDCCH or E-PDCCH.

[0215] To ensure robustness against lost detections, a WTRU can receive a display of the same value from two or more PDCCHs or E-PDCCHs (i.e., within any cell from which it receives a PDSCH assignment). The display can also be contained within a PDCCH or E-PDCCH of a specific DCI format within a specific cell or search space, independent of other PDCCHs or E-PDCCHs containing PDSCH assignments for this WTRU. For example, the display can be contained within a PDCCH received within a common search space. The display can be valid for the duration of one subframe or two or more subframes (such as one frame).

[0216] In the example, a generalized indicator can be used. The display may consist of fields that can be interpreted as a Downlink Assignment Index (DAI), or as a Codebook Indicator or Codebook Size Indicator, depending on its specific value or the value of an associated flag or field. For example, the display may consist of N bits, and the interpretation of the N-1 bits depends on the value of a particular bit. Table 4 provides an example.

[0217] In further examples, the codebook size value can be predefined or configured by a higher layer.

[0218] [Table 4]

[0219] In another example, codebook determination may use DAI and size indicators. In some examples, a WTRU may determine a codebook based on zero or more DAIs and zero or more codebook indicators or codebook size indicators received from a downlink assignment. In such a solution, the WTRU can determine a codebook (or a portion thereof) based on the received DAIs and verify that this codebook (or a portion thereof) matches any applicable received codebook indicators. If the WTRU determines that the DAI-codebook matches the received codebook indicators, the WTRU may send a HARQ-ACK according to the DAI-codebook. Otherwise, the WTRU may send other information and / or perform other actions as described herein.

[0220] The received codebook indicator can be applied to the entire HARQ-ACK codebook or to a subset of the HARQ-ACK codebook. In the latter case, the subset can correspond to downlink assignments received within the same subframe in which the codebook indicator was received. Alternatively, the subset can correspond to downlink assignments received within a preceding subframe that includes the subframe in which the codebook indicator was received. Similarly, a DAI codebook can be applied to the entire HARQ-ACK codebook or to a subset of it.

[0221] A codebook indicator can indicate a range of possible codebook sizes, a set of possible codebook sizes, or a specific size. For example, a particular code point on the indicator may correspond to a size range between 21 bits and 50 bits. In this case, the WTRU can determine that the DAI codebook matches the applicable received codebook indicator if its size is within the indicated range or equal to the indicated size. A codebook indicator can correspond to a PUCCH format indicator, where the PUCCH format indication implicitly indicates a range of possible sizes for the codebook. For example, the PUCCH format 3 indication may implicitly indicate that the codebook size is 21 bits or less.

[0222] In some cases, the WTRU can implicitly derive a range or set of codebook sizes from other characteristics or fields of the downlink control signaling, instead of an explicit codebook indicator. For example, the WTRU can derive a range of possible codebook sizes from a representation of the number of RBs assigned to the PUCCH, or perhaps from a resource representation (e.g., ARI) about the PUCCH, possibly in combination with a PUCCH formatting indicator. A set of possible codebook sizes for a given number of RBs in the PUCCH, or for a given value of ARI, can be predefined or constructed by a higher layer. For example, a set of possible codebook sizes could be constructed as {16, 32, 48, 64, 80, 96, 112, 128} for ARI=2, and as {24, 40, 56, 72, 88, 104, 120} for ARI=3.

[0223] A particular downlink assignment may include a codebook indicator, a DAI, or both. When a downlink assignment does not indicate a DAI (for example, when a generalized indicator has a value that does not correspond to a DAI), the expected DAI value in the next received downlink assignment may be incremented as if a DAI had been received.

[0224] If the WTRU determines that a DAI codebook does not match a codebook indicator for at least one portion of the codebook, the WTRU may adjust the size of the codebook for at least one portion to a value corresponding to the codebook indicator, if such an indicator indicates a specific size. The WTRU may indicate a NACK for all bits of at least one portion. If the WTRU determines that a DAI codebook does not match a codebook indicator for at least one portion of the codebook, but the WTRU cannot determine the correct size of the codebook (for example, if the indicator only indicates a range of sizes), the WTRU may consider the codebook undetermined and may perform the actions described herein.

[0225] In the above, the display may consist of the values ​​of fields included in the DCI payload, or the values ​​of fields used to mask a subset or all of the bits of the CRC.

[0226] In some cases, the network can dynamically indicate codebooks to the WTRU. For example, a codebook indicator can be included in at least one of all downlink assignments whose transmissions are mapped to a single HARQ A / N feedback resource. The meaning of code points within the codebook indicator can be configured by the network, perhaps semi-statically. For example, RRC commands can be used to indicate possible codebooks for each code point to the WTRU (the WTRU can then select the appropriate codebook based on the indicator and at least one serving cell). To improve the granularity of the codebooks, and therefore perhaps to increase the benefits of using dynamic codebooks, the number of indicator bits can be increased. For example, four indicator bits could be used, allowing each of the 16 possible code points to be mapped to multiple codebooks, depending on the serving cell of at least one assignment. Such configurations may require large RRC payloads and may not be sustainable.

[0227] The meaning of a codebook indicator for a codebook can be determined by the configuration of a subset of code points and its combination with at least one serving cell. For example, a WTRU may be configured, perhaps by the RRC, to use a number of sets of carriers (e.g., four sets, each with up to eight carriers, or eight sets, each with up to four carriers, or sixteen sets, each with up to two carriers, or thirty-two sets, each with one carrier). The sets can be predetermined or explicitly configured by the network. Alternatively, the sets can be determined in the WTRU by a network-transmitted indicator about the total number of sets, and the WTRU can divide the configured carriers in a predetermined or pre-configured manner (e.g., the WTRU can order the carriers by an index such as a cell index, and then divide the carriers evenly into the configured number of sets). The WTRU may also be configured (perhaps semi-statically) to use a table that maps the first x (e.g., x=2) bits of the indicator to the sets of carriers. The other remaining y bits of the indicator (e.g., y=2) can be determined as a function of the table used for the first x bits, and possibly as a function of at least one serving cell.

[0228] For example, a network can indicate to a WTRU that it should use four sets of carriers. Each set of carriers can contain up to eight carriers (e.g., set A={1,2,3,4,5,6,7,8}, set B={9,10,11,12,13,14,15,16}, set C={17,18,19,20,21,22,23,24}, set D={25,26,2,28,29,30,31,32}). The WTRU can also be configured (perhaps semi-statically) to use a table that maps the first two bits of an indicator to a different set, for example, as shown in Table 5.

[0229] [Table 5]

[0230] The meaning of the last two bits of an indicator can be determined by using an empty set for at least one code point (e.g., "00"), and then using a complementary set of the set determined from at least one serving cell for all other code points (the complementary set for A is shown by Ac, and in this example, given by BCD). Table 6 shows an example of the meaning of the last two bits of a codebook indicator.

[0231] [Table 6]

[0232] For example, a WTRU configured to use Table 5 for the first two bits of an indicator, and receiving an assignment from a cell in set A, can interpret the first two bits of the indicator based on Table 7, and then interpret the last two bits of the indicator based on Table 8. The overall codebook can be determined from the merging of the sets obtained from the first two bits and the last two bits of the codebook indicator. In this example, if a WTRU decodes an assignment from a cell in set A and is also given the codebook indicator code point 0110, then the meaning of the first two bits (01) can mean set AB, and the meaning of the last two bits (10) can mean set BD, given that it has at least one cell in set A. Therefore, in this case, the codebook can include all cells in the merging of the two sets, thus sets A, B, and D.

[0233] In another example, the WTRU can decode the assignment within a cell in set A using the codebook indicator (0000), and from Tables 7 and 8, it can be determined that the codebook is a merger of set A and an empty set, and therefore contains all cells in set A.

[0234] [Table 7]

[0235] [Table 8]

[0236] In another example, the set for any code point in Table 5 can be determined by WTRU as a function of the total number of sets and a pre-configured or predetermined formula. For example, code point "00" can be any single set, while code point "01" can be a pair of two sets (e.g., a set containing at least one cell that submits an index, selected from AB or CD or EF or GH or...), code point "10" can be a group of three sets (e.g., a set containing at least one cell that submits an index, selected from ABC or DEF or GHI or...), and code point "11" can be a group of four sets (e.g., a set containing at least one cell that submits an index, selected from ABCD or EFGH or...).

[0237] In further examples, the WTRU can determine the order of information bits within the codebook. The WTRU can select codebook permutations to optimize decoding performance. In some solutions, the WTRU can determine or select the order (or sequence) of transmissions of HARQ-ACK bits within a subframe. A suitable order selection can improve HARQ-ACK decoding performance on the network side by avoiding HARQ-ACK bits that are known to be NACK by the network (for example, to correspond to cells / subframes where PDSCH was not transmitted) that are located in consecutive positions in the codebook.

[0238] The order can be selected based on the display from the downlink control signaling (such as codebook display or shuffling display). Alternatively, the order can be determined based on the set of PDSCHs received or not received within a cell and / or subframe for which a HARQ-ACK should be reported. Furthermore, the order can depend on the overall size of the HARQ-ACK codebook within a particular subframe.

[0239] In some cases, the WTRU may contain the same number of bits, but the position of each bit corresponds to the ACK or NACK result of the PDSCH for different cells, subframes, and / or transport blocks of a cell, and one of many possible codebooks is selected. For example, in the first codebook, the 23rd bit may correspond to the first transport block received from the 12th configured cell, while in the second codebook, the 23rd bit may correspond to the second transport block received from the 18th configured cell. The total number of bits in each codebook can be determined based on the number of configured cells, the number of transport blocks that can be received within each cell (depending on the transmission mode), and the subframe configuration.

[0240] In some cases, a set of codebooks can be constructed by interleaving or rearranging bits from a base codebook whose bit order is determined based on predefined rules. For example, the base codebook order could be, firstly, by the order of transport blocks within a cell, secondly, by the order of subframe indices (for TDDs), and finally by the order of the constructed cells. Another possible rule for the base codebook could be, firstly, by the order of cells, then by the order of subframe indices (for TDDs), and finally by the order of transport blocks.

[0241] A particular codebook in a set can correspond to a defined permutation of bits from a base codebook. A set of permutations can be explicitly defined (e.g., using a table) for each possible number of codebook sizes. For example, for a 64-bit codebook size, two permutations can be defined as [1;2;3;4;5;...64] and [1;33;2;34;3;35;...32;64]. Alternatively, a set of permutations can be defined using a formula that can depend on the codebook size. The formula can implement, for example, a set of pseudo-random permutations, or a set of permutations characterized by a specific difference between consecutive entries.

[0242] The codebook to be used within a given subframe can be indicated by downlink control signaling. For example, the codebook can be indicated in a field of a DCI or set of DCIs that includes a downlink assignment for a PDSCH for which a HARQ-ACK is reported. In another example, the codebook can be indicated in a field of a DCI used to provide dynamic scheduling information for the transmission of uplink control information on a PUCCH or PUSCH. In cases where only two codebooks are defined, the field may consist of a single bit indicating whether the base codebook should be used or whether the substituted (or "shuffled") codebook should be used.

[0243] Alternatively, the codebook used within a given subframe can be determined so that a certain metric, which depends on the set of PDSCHs received, is optimized. For example, the codebook can be selected so that the maximum number of consecutive bits corresponding to the A / N bits of a PDSCH that was not assigned (or was not detected as assigned) is minimized.

[0244] In some cases, the WTRU cannot determine at least one characteristic of the codebook based on the received downlink assignment to the extent that there is certainty that it matches the codebook assumed on the network side. In such situations, the codebook may be considered "undetermined" by the WTRU.

[0245] A WTRU occurs when one of the following occurs: the WTRU does not receive at least one codebook indicator (or codebook size indicator) from the set of downlink assignments; a field in the last received assignment in a predefined sequence of cells / carriers and subframes indicates that further downlink assignments should be received; (presumably only if a field received in the last subframe in which a downlink assignment was received indicates that further downlink assignments may exist in the next subframe) the WTRU does not receive at least one codebook indicator from the set of downlink assignments for a subframe that indicates a set of cells, cell groups, and / or transport blocks for this subframe only; A WTRU may be considered undetermined if it has not received at least one codebook indicator from the set of downlink assignments for the last subframe, indicating a set of cells, cell groups, and / or transport blocks for all subframes up to that subframe, including the subframe in which it was received, and / or if the DAI codebook does not match a codebook indicator for at least one portion of the codebook, but the correct size of the codebook cannot be determined (for example, if the indicator only shows a range of size).

[0246] If a WTRU considers the codebook to be undetermined, it may send a HARQ-ACK using a default codebook defined solely from higher-layer configurations, and may send an indication that the codebook is undetermined on a specific PUCCH resource and format, or possibly on a PUSCH transmission if one exists (the specific PUCCH resource and / or format may be configured by higher layers or obtained from downlink control signaling (e.g., ARI), the indication may consist of a single bit (e.g., corresponding to a NACK), and if sent, may be multiplexed with the default codebook HARQ-ACK, and / or the WTRU may refrain from sending any HARQ-ACK within a PUCCH or PUSCH.

[0247] In the example, HARQ feedback transmission using multiple feedback groups can be used. In some solutions, the HARQ feedback information that needs to be transmitted within a given uplink subframe can be represented by two or more sets of information bits. Each such set may be referred to herein as a “feedback group”.

[0248] Feedback groups can be defined based on cells, cell groups, and / or subframes. For example, a first feedback group may include HARQ feedback from a first group of cells (e.g., a first group consisting of eight configured cells), a second feedback group may include HARQ feedback from a second group of cells (e.g., a second group consisting of eight configured cells), and so on.

[0249] In another example, a feedback group can be defined based on at least one of the following: the total number of information bits that need to be transmitted within a subframe based on at least semi-static information; the order of such information bits; the maximum or target number of information bits per feedback group; the maximum or target number of feedback groups; the goal of making the number of bits in each group equal (or the difference at most 1 bit); and minimizing the number of feedback groups. For example, in a case where the total number of information bits transmitted within a subframe is 36 and the maximum number of information bits per feedback group is 10, the feedback group can consist of four groups of 9 bits each.

[0250] In some solutions, the WTRU can encode and transmit information from a feedback group only if at least one PDSCH (or transport block) associated with that feedback group has been received. In the case where at least one PDSCH for that feedback group has been received, the WTRU can report "NACK" for the cells and / or subframes associated with that feedback group from which the PDSCH was not received. Alternatively, the WTRU can report "DTX". For example, if the feedback group consists of HARQ feedback for a group of three cells, each having two transport blocks, and the PDSCH is received only on the second cell, then there can be six information bits in the feedback group. The first two bits (corresponding to the cells from which the PDSCH was not received) and the last two bits can indicate "NACK", while the middle two bits (corresponding to the cells from which the PDSCH was received) can indicate "ACK" if the decryption of the transport block was successful, or "NACK" otherwise.

[0251] In some solutions, the combinations of subsets of feedback groups can be restricted to a set of valid combinations of feedback groups. For example, it may not be possible to send exactly one feedback group, such as only group #2, but several combinations of two feedback groups (such as #1 and #2) may be possible. The WTRU can send information from this feedback group to obtain a valid combination of the group, even if no PDSCH associated with the feedback group has been received. The set of valid combinations can be predefined or provided by a higher layer.

[0252] In the example, separate processing of transmitted feedback groups can be used. In the solution, the information bits of each feedback group for which transmission occurs can be encoded separately. For example, if the first feedback group consists of 8 bits and the second feedback group consists of 10 bits, each feedback group can be encoded into 24 encoded bits (e.g., using a Reed-Muller block code). Subsequent modulation, spreading, and mapping to physical resources can also be performed separately for each feedback group.

[0253] The number of encoding bits used for each feedback group can be a function of the number of bits in each feedback group. Each encoding bit can be selected from a predetermined set of values ​​for the number of encoding bits (e.g., 24 or 48). In some solutions, the selected number of encoding bits can be chosen to be the smallest of a predetermined value that achieves the maximum encoding rate (e.g., the ratio of information bits to encoding bits).

[0254] In the example, collaborative processing of transmitted feedback groups can be used. In the solution, the information bits of each feedback group for which transmission occurs can be collaboratively processed and mapped to a single resource. For example, there may be four defined feedback groups (labeled #1, #2, #3, and #4) consisting of 8, 12, 10, and 14 bits, respectively. In the subframe for which feedback groups #1, #3, and #4 are transmitted, a total of B=32 bits (=8+10+14) can be encoded.

[0255] The encoding can consist of multiple Read-Muller block codes, where a set of B bits can be evenly divided into subsets M, each consisting of up to N information bits, and each subset is encoded independently. The encoded bits from the subsets of M can then be multiplexed prior to subsequent processing (possibly including modulation, spreading, and mapping to physical resources). Such a type of encoding can improve performance at the receiver by reducing the total number of codeword candidates being tested. The number of subsets M can be a function of the number of bits B, according to a predefined function. For example, M can be set to the smallest integer greater than the ratio B / N.

[0256] In another example, encoding can use other types of code, such as convolution or turbo encoding. The type of encoding used within a particular subframe can be a function of the number of bits B transmitted, given a subset of the feedback groups for which the transmission occurs. For example, within a subframe where the subset of feedback groups results in B ≤ B0 bits transmitted (B0 can be a fixed value such as 40), the WTRU can use multiple Read-Muller block codes. Within a subframe where B is greater than B0 but less than or equal to B1 (B1 can be a fixed value such as 100), the WTRU can use convolution encoding. Within a subframe where B is greater than B1, the WTRU can use turbo encoding.

[0257] To improve reliability, a set of CRC bits can be added to the set of B bits prior to encoding. The number of CRC bits can depend on the number of bits B, or on the type of encoding applied. For example, zero CRC bits can be added when B is less than or equal to B0 bits, or when convolution or turbo encoding is not used.

[0258] Figure 5 is a diagram illustrating an exemplary selection process for channel coding and CRC inclusion based on the number of feedback bits transmitted. As shown in process 500, the WTRU can receive multiple transport blocks on a set of multiple configured carriers 510 and generate HARQ-ACK feedback 520 for multiple transport blocks. Inclusion of HARQ-ACK feedback for a carrier can be based on the DAI field present in the downlink assignment for that carrier. Furthermore, depending on the consecutive DAI values ​​detected by the WTRU, supplementary HARQ-ACK feedback bits can be inserted into the HARQ-ACK codebook. Furthermore, there may be no downlink assignment for a carrier. The HARQ-ACK feedback 520 can use HARQ-ACK feedback bits 525. The WTRU can determine the number of HARQ-ACK feedback bits to be used. In 530, the WTRU can compare the number of HARQ-ACK feedback bits, which can be represented by n, to a threshold such as threshold B. In the example, if the number of feedback bits is less than or equal to the threshold, and therefore n ≤ B, then in 540, Reed-Muller coding can be used. The encoded set of feedback bits 545 can be obtained from Reed-Muller coding. Furthermore, if the number of feedback bits is greater than the threshold, and therefore n > B, the WTRU can insert or add a CRC at 550. Also, if the number of feedback bits is greater than the threshold, and therefore n > B, the WTRU can use convolutional coding at 560. The encoded set of feedback bits 565 can be obtained from convolutional coding.

[0259] In some solutions, a finite set of possible numbers B' of information bits (or payload size) prior to encoding can simplify decoding at the receiver. This set can be predefined or determined from the configuration (such as the number of cells, groups of cells, and the number of transport blocks per cell). A specific payload size B' to be used in a particular subframe can also be dynamically determined from downlink control signaling. For example, a field within PDCCH / E-PDCCH may indicate one of a set of possible payload sizes B' predefined or configured by a higher layer. In another example, a field may indicate one of a set of possible PUCCH formats, each corresponding to a payload size depending on the configuration (such as the number of cells and groups of cells). The WTRU can use padding bits when the number of bits B to transmit is lower than the allowed number B' of information bits. For example, the sets of possible payload sizes could be 20 bits, 50 bits, and 100 bits. In the case where the number of bits B to be transmitted, based on a selected subset of feedback groups, is 60 bits, the WTRU can utilize padding bits so that the total payload becomes 100 bits. The WTRU can also transmit information from additional feedback groups (not initially selected) so that the total number of bits matches the valid payload size.

[0260] The number of encoding bits used can be a function of the total number of bits B or the payload size B'. It can be selected from a predetermined set of values ​​for the number of encoding bits. In some solutions, the number of encoding bits selected can be chosen to be the smallest of a predetermined value that achieves the maximum encoding rate (e.g., the ratio of information bits to the number of encoding bits).

[0261] In the example, resource determination can be used. As described herein, a resource may be a set of transmission characteristics for transmitting feedback (for example, on a PUCCH). A resource can be identified by an index derived from all characteristics, such as a set of RBs, characteristics of one or more DM-RS sequences, and at least one diffusion sequence. In the case where a PUCCH is composed of multiple cells, the resource may include the cell on which the PUCCH is to be transmitted, or a set of cells. A sub-resource may be a part of such a resource, for example, one RB in the case where the resource consists of two or more sets of RBs, or one diffusion sequence in the case where the resource consists of two or more sets of diffusion sequences, or one cell in the case where the resource consists of multiple cells.

[0262] The WTRU can determine a resource or sub-resource used for transmitting a feedback group or combination of feedback groups based on downlink control signaling that can be associated with at least one of the PDSCHs associated with the feedback group. For example, a resource or sub-resource can be indicated by an ARI field in a PDCCH / E-PDCCH that schedules a PDSCH associated with the feedback group portion of the feedback group or combination. In another example, a resource or sub-resource may depend on the cell or cell group from which the PDCCH / E-PDCCH is decoded, or on the cell or cell group of the corresponding PDSCH. For example, the cell on which a PUCCH is transmitted may be a cell in the same cell group from which the PDCCH / E-PDCCH is decoded. In yet another example, signaling as described herein may be used.

[0263] The resources used for transmitting a combination of feedback groups may depend on the number of encoded bits and / or the associated PUCCH format, possibly in combination with the ARI. For example, a WTRU might select a first resource if the number of encoded bits is a first number and the received ARI is a first value, and a second resource if the number of encoded bits is a second number and the received ARI is a first value. The mapping between resources and combinations of ARI and the number of encoded bits can be configured by higher-level layers. In another example, a WTRU might be configured to use a single resource for each PUCCH format, or for each possible number of information bits or encoded bits. In this case, the WTRU can select a PUCCH resource corresponding to the number of information bits or encoded bits that need to be transmitted (or the PUCCH format that needs to be used).

[0264] In the example, a fixed mapping of feedback groups to sub-resources using possible zero-power transmissions can be used. The WTRU can determine the resources or sub-resources used for the transmission of this feedback group (or combination of feedback groups) based on a combination of downlink control signaling that can be associated with any PDSCH and an index or sequence associated with the feedback group. For example, a combination of an index received from the ARI field and an index for the feedback group can determine the resources or sub-resources for the transmission of this feedback group. For example, a particular value of ARI may indicate a resource spanning two consecutive RBs, and there may be two feedback groups to be transmitted. In this case, the sub-resource used for the first feedback group may be the first of the two RBs, and the sub-resource used for the second feedback group may be the second of the two RBs.

[0265] In cases where there is no need for transmission for a feedback group, the WTRU can transmit using zero power (i.e., not transmit) on the corresponding subresource. In some solutions, the WTRU can transmit on the subresource even when there is no need for transmission for the corresponding feedback group, to ensure that the signals transmitted by the WTRU span consecutive RBs. The WTRU can perform such transmission, for example, when the subresource exists on an RB and non-zero power transmission occurs on both adjacent RBs. In this case, for example, the WTRU can encode information about the corresponding feedback group according to a pre-determined rule, as if the WTRU were reporting "NACK" or "DTX" for all corresponding transmissions of the feedback group.

[0266] In the example, flexible mapping of feedback groups to resources with possible representations can be used. The resources used for transmitting a particular feedback group can also be determined based on a subset (or combination) of feedback groups transmitted within a subframe. This solution can ensure that the combination of resources used for transmitting all feedback groups results in a signal with desirable characteristics, such as a signal spanning consecutive resource blocks. For example, there may be four defined feedback groups (labeled #1, #2, #3, and #4), and the values ​​received from downlink control signaling (e.g., ARI) can determine a set of resources spanning four consecutive resource blocks (labeled #a, #b, #c, and #d). When all four feedback groups are transmitted, groups #1, #2, #3, and #4 can be mapped to resources #a, #b, #c, and #d, respectively. On the other hand, when only groups #1, #2, and #4 are transmitted, these groups can be mapped to resources #a, #b, and #c, so that only consecutive resource blocks are used. When there is possible ambiguity with respect to the network regarding the identification information of a feedback group transmitted on a given resource, the WTRU may include at least an indication of the feedback group within that resource, such as a bit indicating whether the feedback group transmitted on resource #c is #3 or #4. Such an indication may be encoded jointly with or separately from the information bits from the feedback group.

[0267] In an example, transmission of a feedback group indicator can be performed. In some solutions, the WTRU can transmit at least one indication of a subset of the feedback groups transmitted within a subframe to facilitate decoding at the receiver. Such an indication may hereinafter be referred to as a "feedback group indication" (FGI). The value of the FGI can indicate one of a set of valid possible combinations of feedback groups and includes the codebook size. The mapping between each possible FGI value and the combination of feedback groups can be provided by a higher layer or predefined. The mapping can depend on the total number of information bits B and / or the payload size B' for transmission within the subframe. In some solutions, the FGI can consist of an indication of the transmission format for the PUCCH.

[0268] In a solution, the FGI can be processed separately from other feedback bits and mapped to specific physical resources. For example, the FGI bits can be encoded, modulated, spread, and mapped to specific subcarriers and / or slots of a resource block. This solution has the benefit of being able to support multiple possible numbers (B) of information bits without unduly increasing the complexity at the receiver, since the receiver can first determine the number of information bits by first decoding the FGI.

[0269] In a solution, the FGI bits can be concatenated (and perhaps interleaved) with other feedback bits prior to subsequent joint processing (which may include at least one of encoding, modulation, spreading, and mapping to physical resources). This solution can be particularly beneficial when the possible set of payload sizes is known at the receiver.

[0270] In the solution, the FGI bits can be used to mask the CRC added to the set of feedback bits. This solution has the benefit of providing enhanced reliability through error detection while at the same time reducing the likelihood of errors in feedback transmission due to lost PDSCH allocations or misdetected PDSCH allocations. In the receiver, the network can attempt to perform decoding assuming a given payload size (or set of possible payload sizes) and check whether the CRC masked by the FGI value expected if the transmitted PDSCH were given is valid.

[0271] In the solution, the resources used for transmission of the feedback group can perhaps be made a function of the FGI, combined with downlink control signaling (such as ARI) and information received from higher layers. This solution provides an implicit FGI signaling mechanism since the receiver can determine the FGI from the resources from which it can then decode the feedback information.

[0272] In an example, power settings can be used. The WTRU can determine the power applied to a transmission containing feedback information (including transmissions containing only feedback information such as PUCCH transmission) based at least on the path loss estimate PL C , parameters provided by higher layers such as the configured maximum power PCMAX.C, PO_PUCCH, DeltaF_puccH, and DeltaTxD, parameters dependent on the received TPC command g(i), and / or a power offset h that is a function of parameters that can vary on a subframe basis as described below.

[0273] In some solutions, the power offset can be a function of at least one of the following, based on a subset of feedback groups selected for transmission, including feedback groups sent to ensure transmission over consecutive RBs: the total number of information bits B, the maximum number of information bits in a feedback group within the subset selected for transmission, the number of transport blocks based on the received PDSCH, the number of transport blocks based on the received PDSCH within each feedback group, or its maximum value within a feedback group, the maximum number of transport blocks that can be received based on the configuration, the payload size B' for transmitting feedback information within a subframe, the type of encoding used within the subframe (read-Muller, convolution, turbo), whether a CRC and / or FGI are added to the set of feedback bits transmitted, the number of subsets of bits M that are independently encoded prior to multiplexing, the number of bits transmitted within each subset of independently encoded bits, which may or may not be limited to those corresponding to the received PDSCH, or its maximum value among all subsets.

[0274] The power offset function can depend on different parameters depending on the type of encoding used, or more generally, on the transmission format used. For example, in cases where the encoding is based on block codes such as Reed-Muller, the power offset can be a function of the number of transport blocks based on the received PDSCH within a subframe, or perhaps the maximum number of such blocks in an independently encoded subset. On the other hand, in cases where the encoding is based on convolutional or turbo codes, the power offset can be a function of the maximum number of transport blocks that can be received based on the configuration. This solution can be appropriate in cases where block encoding based on small codebooks is used, as the receiver can improve the likelihood of correct detection by utilizing knowledge of information bits known to be set to NACK (based on the scheduled PDSCH).

[0275] In legacy systems, the number of encoded modulation symbols per layer for HARQ-ACK, Q', is the number of information bits for HARQ-ACK, the number of subcarriers in the first push transmission, and a coefficient.

[0276]

number

[0277] It can be set to a value proportional to but not greater than four times the number of subcarriers in PUSCH. Encoding, interleaving, multiplexing, and mapping of higher-layer data are performed independently of the presence or absence of HARQ-ACKs. When HARQ-ACKs are sent, their encoded modulation symbols can override symbols used for higher-layer data within a resource element, mitigating performance degradation for higher-layer data due to puncturing.

[0278] When it is necessary to transmit a large number of HARQ-ACK bits, for example, in power-limited scenarios where it may not be possible to have a very large bandwidth for the PUSCH, the limit of four times the number of subcarriers on the PUSCH may be insufficient. In some solutions, the limit of four times the number of subcarriers allocated to the PUSCH can be raised so that modulation symbols for HARQ-ACK can be mapped to additional resources on the PUSCH (e.g., time symbols).

[0279] In some solutions, to prevent performance degradation due to excessive puncturing, the WTRU may process higher-layer data by taking into account that at least some resource elements are unavailable for higher-layer data due to the transmission of a HARQ-ACK or a minimum number of its bits. More specifically, the following parameters or procedures can be affected: The transport block size of the higher-layer data can be affected. For example, the calculation of the transport block size as a function of the transmitted modulation and coding scheme (MCS) and the size of the PUSCH allocation (within the resource block) can take into account the number of time symbols unavailable due to the transmission of a HARQ-ACK. For example, in cases where the number of modulation symbols required for a HARQ-ACK is more than four times the number of PUSCH subcarriers, when it may be necessary to transmit a HARQ-ACK, the transport block size can be scaled down by a coefficient of (12-4) / 12 = 2 / 3, taking into account the fact that at least 1 / 3 of the time symbols (not used for DM-RS) are unavailable for higher-layer data. The procedure for mapping symbols to REs for PUSCH can be modified so that a subset or all of the REs on which symbols for HARQ-ACK are mapped are excluded from the set of REs on which symbols for PUSCH can be mapped. For example, the REs on the first four time symbols on which symbols for HARQ-ACK can be mapped can be excluded.

[0280] A WTRU may determine that higher-layer data is processed according to the above, based on at least one of the following conditions: A WTRU may determine that higher-layer data is processed according to explicit signaling from the received PDCCH / E-PDCCH. The received PDCCH / E-PDCCH may be a PDCCH / E-PDCCH containing an uplink grant for the relevant PUSCH, or possibly another received PDCCH / E-PDCCH indicating information about a set of PDSCH and / or PUSCH transmissions. A new or existing field of the DCI may be used for this purpose. This solution has the advantage of being robust against the loss of downlink allocations. A WTRU may determine that higher-layer data is processed according to the number of HARQ-ACK information bits transmitted within the PUSCH. A WTRU may also determine that higher-layer data is processed according to whether the number of symbols for the HARQ-ACK exceeds a threshold, such as four times the number of subcarriers in the PUSCH transmission.

[0281] In the example, the WTRU can select uplink resources for UCI transmission. In the example, the WTRU can determine resources for transmitting UCI in the following situations: perhaps when multiple types of physical channels, e.g., both PUSCH and PUCCH, are available for UCI transmission; perhaps when multiple types of UCI, e.g., HARQ-ACK, CSI, or SR, are available for transmission; and / or perhaps when several cells on the carrier are operating in an unlicensed frequency band (e.g., LAA).

[0282] In the example, the WTRU can divide the UCI between PUSCH and PUCCH. In one exemplary method, the WTRU can determine that a first amount of the UCI can be applied to a first type of transmission, e.g., PUCCH, while a second amount can be applied to a second type of transmission (e.g., PUSCH). Perhaps such a method can be applied on a cell-by-cell basis, for example, to a PUCCH group or a cell group (e.g., CG).

[0283] For example, the first quantity of the UCI can correspond to a specific type of UCI, such as the HARQ A / N bit. For example, the second quantity of the UCI can correspond to other types of UCIs, such as the CQI, precoding matrix indicator (PMI), or CSI such as the RI bit.

[0284] Within a subframe in which a WTRU is expected to transmit a UCI, the WTRU can determine whether at least one PUSCH resource is available for the relevant subframe. The WTRU can also determine whether it is configured for simultaneous transmission on PUCCH and PUSCH for a given serving cell or group of cells.

[0285] If a WTRU can perform transmissions simultaneously on both PUSCH and PUCCH (for example, if resources are available and the WTRU is configured for such operation), the WTRU may decide that it can transmit a first type of UCI, e.g., HARQ-ACK, on ​​a PUSCH transmission, while transmitting a second type of UCI, e.g., CSI, on a PUCCH transmission, or vice versa.WTRU may transmit a first part of a given type of UCI (e.g., HARQ-ACK) over a PUSCH transmission, while transmitting a second part over a PUCCH transmission, by at least one of the following: for example, receiving downlink control signaling using a method similar to that described herein (such signaling may indicate that the UCI has been split and to use PUSCH and PUCCH transmissions); and for example, receiving downlink control signaling using a method similar to that described herein (such signaling may include a UCI request, and the indicated UCI will be transmitted to a first specific resource and / or transmission (e.g., PUCCH, also) Alternatively, the feedback may be routed by dynamic scheduling (for example, to a resource as described herein and shown accordingly), while other feedback may be routed (or possibly dropped) to a second specific resource and / or transmission (e.g., a PUSCH), or vice versa; and the PUSCH allocation (e.g., the size of the grant) may be determined according to at least one of the following: the PUSCH allocation (e.g., the size of the grant) is less than (or equal to) a (possibly configurable) threshold; the resulting ratio of the number of (non-UCI) payload bits to the number of UCI bits for the associated PUSCH transmission is greater than or equal to a specific threshold for the relevant amount of UCI bits; the resulting ratio of the number of (non-UCI) payload bits to the number of HARQ A / N bits for the associated PUSCH transmission is greater than or equal to a specific threshold; and the number of modulation symbols per layer Q' for the UCI type and associated PUSCH transmission exceeds a threshold (for example, the threshold may be four times the number of subcarriers in the PUSCH in the case of HARQ-ACK).

[0286] When at least one of the above conditions is met, the WTRU can determine a part of the UCI bits transmitted on each channel according to at least one of the following. The WTRU can determine a part according to the information including the first type of UCI (e.g., HARQ-ACK bits) in the related PUSCH transmission up to the number of symbols required for the most relevant UCI. The WTRU can use the transmission on the PUCCH to transmit the remaining UCI (e.g., CSI bits) (e.g., of the second type). Also, the WTRU can determine a part according to the information including the number of UCI bits in the PUSCH transmission based on the PUSCH allocation (e.g., the size of the grant), and the remaining UCI bits can then be transmitted using a different transmission. For example, the WTRU can determine the number of HARQ-ACK bits that results in at most a threshold number Q' of modulation symbols per layer that depends on the size of the PUSCH, such as N times the number of subcarriers. In another example, the number of UCI bits in a PUSCH transmission (of a given type perhaps) can be set to zero, and all bits can be transmitted on different transmissions.

[0287] In an example, the WTRU can separate the UCI among multiple PUCCHs. In one exemplary method, the WTRU can make the first amount of UCI applicable to the first type of transmission, e.g., PUCCH, on the resources of the first serving cell (e.g., PCell), while making the second amount applicable to the first type of transmission (e.g., PUCCH) on the resources of the second serving cell (e.g., SCell configured to use PUCCH). Perhaps such a method can be applicable per cell group, e.g., to or across a PUCCH group or a cell group (e.g., CG).

[0288] For example, the first quantity of the UCI may correspond to a specific type of UCI, e.g., HARQ A / N bits. For example, the second quantity of the UCI may correspond to other types of UCI, e.g., CSI such as CQI, PMI, or RI bits. In such cases, the WTRU may use a PUCCH to transmit the first UCI type on it by receiving downlink control signaling using, for example, a method similar to that described herein (such signaling may indicate that the UCI is divided and uses different PUCCH transmissions, and that the first type of UCI should be transmitted using the resources of a particular cell (e.g., the cell on which the control signaling was received)) and receiving downlink control signaling using, for example, a method similar to that described herein (such signaling may include a UCI request, and the indicated UCI should be transmitted using the first specific PUCCH resource and / or PUCCH transmission (e.g., perhaps, a dynamic PUCCH transmission as described herein, for example) The feedback can be routed to a resource indicated by scheduling, while other feedback can be routed to a second specific PUCCH resource and / or PUCCH transmission (for example, according to other methods for determining the PUCCH resource), or vice versa, and the decision can be made according to at least one of the following: always PCell (or PSCell in the case of MCG), or always SCell; the WTRU selects a PUCCH that has sufficient capacity (and / or the best expected transmission performance); the WTRU selects a cell that has the lowest path loss estimate; the WTRU selects a cell that also has resources for PUSCH transmission (only if simultaneous PUSCH+PUCCH transmission is configured for the WTRU); or to follow a semi-static configuration.

[0289] In some examples, a WTRU may select a single PUCCH when multiple are available. In possible examples, a WTRU may select a single PUCCH when multiple are available, but only if the WTRU can perform simultaneous transmissions on different PUCCHs. In other examples, a WTRU may also determine which serving cell to use a PUCCH according to at least one of the following: the WTRU selects a cell based on received control signaling similar to that described above, and receives downlink control signaling using a method similar to that described herein (such signaling may include dynamic scheduling for UCI transmissions, for example, as described herein); the WTRU selects a PUCCH with sufficient capacity (and / or best expected transmission performance); the WTRU selects a cell with the lowest path loss estimate; and follows a semi-static configuration. In some examples, a WTRU may only consider cells that are activated.

[0290] A WTRU can be configured to use multiple PUCCH resources on at least one SCell. A WTRU can also be configured to have a limit on the number of simultaneous uplink transmissions it can perform. Such limits may be for all transmissions of the WTRU (including all transmissions for all configured cells or CGs), for all transmissions for a given CG in the WTRU's configuration, for all physical transmissions of a particular type (e.g., only for PUCCH transmissions), and / or for all transmissions of a certain type (e.g., only for UCI transmissions).

[0291] In such cases, the WTRU can determine which uplink transmissions it can use for UCI transmissions according to the solutions described herein. For example, the WTRU can determine the uplink transmissions as a function of limitations.

[0292] In one way, the WTRU can determine how to forward UCI transmissions as a function of the number of simultaneous uplink transmissions (and possibly only simultaneous PUCCH transmissions) and a limit applicable to the number of simultaneous uplink transmissions. For example, the WTRU can determine that at least some UCI transmissions should be performed within a given subframe by at least one of the following (possibly for a given CG): that the WTRU can perform at most a number X transmissions on a PUCCH (e.g., the WTRU can determine an applicable number X serving cells using PUCCH resources according to at least one of the following: descending order of required transmit power for PUCCH transmissions, ascending order of estimated path loss criteria for the corresponding carriers, and descending order of PUCCH capacity); and that the WTRU can perform at most a number X transmissions on a PUCCH for a given group of cells (e.g., at most one PUCCH transmission per PUCCH group if a group can be made up using two or more PUCCH resources). WTRU can probably be calculated using a method similar to the one used for the previous case, which was applied on a cell-by-cell basis.

[0293] A WTRU can be configured to use at least one serving cell (hereinafter "LAA cell") that uses a carrier operating in an unlicensed frequency band. The following solutions describe how a WTRU may determine which uplink resources to use for the transmission of at least some (or all) of the generated UCIs as a function of the type of access, the type of band (e.g., licensed or unlicensed), the type of the UCI itself (e.g., HARQ A / N, CQI, or PMI / RI), and / or the received control signaling (e.g., similar to the signaling configurations described herein).

[0294] In exemplary methods and other examples, a WTRU may forward UCI over the resources of a serving cell in a licensed band. A WTRU may determine that it can transmit an applicable UCI using the uplink resources of a serving cell in its configuration, associated with a carrier in the frequency band used for licensed operations. A WTRU may make such a determination independently of whether it has scheduled uplink transmissions to the uplink resources of an LAA cell. Alternatively, a WTRU may transmit at least a portion of the UCI over a push transmission of an LAA cell (if available) so that it can make such a forwarding determination, but only when no push transmissions exist for the LAA cell.

[0295] Such applicable UCIs can be determined according to at least one of the following: The WTRU cannot transmit any UCI using the resources of an LAA cell. For example, the WTRU can forward any UCI related to an LAA operation to a carrier-associated transmission within the licensed area, independently of whether the WTRU has resources for a PUSCH transmission for an LAA cell. In another example, the WTRU can transmit only UCIs associated with an LAA cell using the resources of an LAA cell when available; otherwise, UCIs can be forwarded to the cell's resources within the licensed area. For example, the WTRU can forward only UCIs related to an LAA cell to a transmission over the LAA cell's resources if such a transmission is available (e.g., a PUSCH transmission is scheduled). In yet another example, the WTRU can do any of the above, but only for the transmission of a specific type of UCI. For example, a WTRU can use only the resources of a cell within the licensed area to send (more time-sensitive) HARQ A / N feedback related to operations within the unlicensed area, in which case other types of UCIs can send it using PUSCH transmissions within the unlicensed area (if available) or using resources within the licensed area (if not).

[0296] In further examples, the applicable UCI can be determined by the reception of downlink control signaling, for example, using a method similar to that described herein. Such signaling may include a UCI request, and the indicated UCI can be generated based on the status of the HARQ process at the time of reception of the control signaling; for example, the UCI can be associated with the most recent status of each HARQ process and not necessarily with transmissions received simultaneously and / or during the time interval associated with the reception of such control signaling. In addition, the WTRU can receive UCI scheduling information, similar to that described herein, regarding UCI feedback associated with such cells.

[0297] A method for determining uplink resources for UCI transmission is described herein. A method is described herein that allows a WTRU to at least partially determine which resources to use for at least some UCIs, based on downlink control information, such as dynamic scheduling.

[0298] A method for downlink control signaling using DCI(UCI) is described herein. In an example, a WTRU may receive dynamic scheduling information about UCI. Such dynamic scheduling information may be received on the PDCCH using DCI. Such scheduling information may be contained in an existing DCI format or a dedicated DCI format (for example, using one or more indices that refer to specific control information). Such DCI may further be referred to herein as DCI(UCI).

[0299] Dynamic scheduling may include UCI requests and / or resource allocations. Such a DCI (UCI) may represent at least one of a UCI request (by which the WTRU can determine, for example, which UCIs to include in a given transmission) and UCI scheduling information (by which the WTRU can determine, for example, which uplink resources should transmit applicable UCIs and how, using dynamically scheduled information).

[0300] In the example, DCI(UCI) can indicate a UCI request. A UCI request can be used to determine which UCIs should be generated for transmission. In the example, WTRU can determine which feedbacks should be included in the UCI transmission as a function of the UCI request.

[0301] Furthermore, UCI requests can be used to generate smaller UCI payloads. In the example, a UCI request can be used to prioritize the transmission of the requested UCI and possibly drop (or lower the priority of) other UCIs.

[0302] Furthermore, a UCI request can be used to route a subset of UCIs to a specific resource, whether or not they are scheduled. For example, a UCI request can be used to assign the indicated UCIs to a specific uplink resource, such as a resource indicated by UCI scheduling information (see examples herein where applicable).

[0303] The content of a UCI request may include at least one of the following pieces of information: UCI type, serving cell identification information, downlink HARQ process identification information, UCI size reduction method, feedback group, and non-periodic request. For example, the content of a UCI request may include the UCI type. A WTRU can determine which type of UCI to include in a UCI transmission, such as a standalone HARQ A / N or a HARQ A / N combined with any applicable CSI. For example, the type may be implicit to the DCI(UCI) format, based on the field arrangement within the DCI(UCI) format. For example, the DCI(UCI) format may include one field for a CSI request and one field for a HARQ A / N request (for example, as separate bitmap fields).

[0304] In another example, the content of a UCI request may include serving cell identification information. The WTRU can determine the serving cell identification information to which the request is applicable, and for example, a request for a relevant UCI may be applicable to all configured (and / or possibly active) serving cells in the WTRU configuration, or a subset thereof, as indicated by the transmitted identification information.

[0305] For example, the identification information can correspond to serving cell identification information configured by a higher layer, and can correspond to cells that are part of a group of cells (e.g., grouping for PUCCH transmissions based on configured groupings - PUCCH groups based on special cells - based on Timing Advance Grouping (TAG) for only PCells in MCG or PSCells in SCG, etc.). Such identification information can be based on carrier field indicators (CFIs) used for cross-carrier scheduling.

[0306] In the example, the UCI request may indicate CSIs, legacy HARQs, for only a subset of cells on a dynamically scheduled PUSCH. For example, the UCI request may indicate that only CSIs for a subset of serving cells, e.g., for serving cells IDs 1 and 3, are requested. Such indications can be received using a bitmap arrangement similar to the example shown in Table 9. The WTRU can then include the CSIs for those cells, along with the applicable UCIs for uplink transmission.

[0307] The WTRU can perform such uplink transmissions, for example, using a dynamic schedule (perhaps on PUSCH). In the example, such UCI request signaling for a CSI can be applied only to periodic CSIs (e.g., periodic CQI reports), or preferably to any type of CSI, including arrears. Table 9 shows an example of a bitmap arrangement for CSI feedback requests.

[0308] [Table 9]

[0309] In further examples, the content of a UCI request may include downlink HARQ process identification information. The WTRU can determine, for example, the identification information of the HARQ processes to which the request is applicable when the type of requested UCI is HARQ feedback. For example, the control information can use, for example, the bitmap representations of all HARQ processes in the WTRU in a specific order for each (and possibly activated) cell in the WTRU's configuration, for example, based on the respective serving cell identification information, for example, in ascending order of process IDs for all applicable cells in ascending order. Table 10 shows an example of a bitmap arrangement for a HARQ feedback request.

[0310] [Table 10]

[0311] In the example, HARQ feedback may be included for only specific processes for all applicable cells. For example, upon receiving a UCI request, the WTRU may determine that it includes HARQ feedback for processes x1, x3, and x7 for serving cell ID=0, for x0 and x4 for serving cell ID=1, and for x0, x2, x3, x4, and x5 for serving cell ID=3, as shown in Table 10. In such a case, the WTRU may generate 10 bits of HARQ feedback for transmission over the uplink resource. The WTRU can then determine the applicable encoding and applicable uplink resource using one of the methods described herein or using a legacy method.

[0312] In the example, the overload may indicate the presence or absence of dynamic scheduling information about a process. In the example, the HARQ feedback may only respond to transmissions in which the WTRU has scheduling information (e.g., dynamic and / or configured / semi-permanent) about a process, so that the request may also indicate that the process in question is scheduled. In such cases, the WTRU may perform verification to determine whether it failed to successfully decode one(or more) PDCCHs during the relevant interval (e.g., "missing PDCCH") (and possibly also for which serving cell), or whether it failed to successfully decode one(or more) PDCCHs (e.g., "false positive").

[0313] In the example, a special case can be used for configured DL assignments. For a HARQ process configured to use downlink assignments during the relevant interval, the WTRU can determine that a UCI is always required. In this case, the absence of a request for the relevant HARQ process can indicate that dynamic scheduling was not associated with the process, while the presence of such a request can indicate that dynamic scheduling was associated with the process.

[0314] In the example, an overload can be used as PDCCH decoding assistance. In the example, the WTRU can determine that the UCI request corresponds to all cells in the WTRU's configuration (perhaps only activated cells) and / or all such cells associated with such control signaling, so that the WTRU can use the UCI request information to perform decoding attempts only for cells for which HARQ feedback has been requested.

[0315] In another example, HARQ feedback requests can be independent of DL scheduling, e.g., process states. In this example, HARQ feedback can correspond to the state of the relevant HARQ process, independently of scheduling activities for the relevant process. In such cases, further verification by the WTRU may not be required to detect the possible occurrence of a lost PDCCH and / or any false positive.

[0316] In further examples, the content of a UCI request may include methods for reducing the UCI size. In an example, the WTRU may also determine which size reduction methods should be applied to the requested UCI, such as any other methods described herein. For example, a UCI request may indicate that for a cell for which a HARQ A / N should be reported, the WTRU should use bundling for the HARQ A / N for cells configured to use spatial multiplexing (e.g., multiple transport blocks per interval).

[0317] In further examples, the content of a UCI request may include, for example, a feedback group, as described herein. In an example, a WTRU may determine, based on a dynamic feedback request field, a set of PDSCH transmissions and / or HARQ processes for which it should provide feedback. Different code points in the field may map to different feedback groups (e.g., sets of PDSCH transmissions and / or HARQ processes), and these code point mappings may be configured semi-statically, possibly by an RRC configuration.

[0318] In another example, the content of a UCI request may include an irregular request. In this example, the WTRU may also decide that irregular uplink feedback should be sent from the UCI request.

[0319] A WTRU may perform additional behaviors regarding HARQ A / Ns generated from the reception of one or more DCIs, activating or deactivating configured downlink allocations and / or configured uplink grants. In one way, a WTRU may always generate HARQ A / N reports for such signaling, independently of UCI requests. In another way, a WTRU may generate HARQ A / N reports for such signaling if a serving cell on which the WTRU has received control signaling is included in the UCI request (e.g., causing the network to coherently coordinate the transmission of semi-permanent scheduling (SPS) commands and UCI requests).

[0320] In another example, a WTRU may determine, for example, using the methods described herein, that a given UCI should not be generated and / or included in an uplink transmission. In other words, such signaling can be used to suppress some (or all) applicable UCIs instead of being considered a UCI request.

[0321] In the example, DCI(UCI) can indicate scheduling information for the UCI. A UCI request can be used to determine which UCI should be generated for transmission. In the example, the WTRU can determine some or all characteristics of an uplink transmission for at least some of the applicable UCIs, for example, as a function of the UCI scheduling information, including applicable transmission resources and / or applicable transmission formats, possibly including one of the following: modulation, (start) resource block, number of resource blocks, spread, spatial multiplexing, possibly timing and / or timing offset, or one or more DM-RS sequences.

[0322] UCI scheduling information may include at least one of the following: physical channel type (PUCCH, PUSCH), physical channel type identifier (e.g., PUCCH on PCell, PUCCH on SCell), serving cell identifier, PUCCH / UCI feedback group identifier, PUCCH format, PUSCH transmission parameters, channel coding, payload size, TPC command (power control information), and CSI request. Furthermore, different combinations of the above scheduling information are possible, depending on whether the indicated resource is a PUSCH resource or a PUCCH resource.

[0323] UCI scheduling information can include the physical channel type (PUCCH, PUSCH). A WTRU can determine which type of physical channel to use for UCI transmission as a function of the indication in the scheduling information. If no such indication exists, the WTRU can decide to use PUCCH. When PUSCH is scheduled for UCI transmission (perhaps only for that purpose), the WTRU cannot perform any WTRU-autonomous retransmissions for the associated HARQ process.

[0324] UCI scheduling information may include physical channel type identifiers (e.g., PUCCH on PCell, PUCCH on SCell). A WTRU can determine which physical channel of a certain type (e.g., PUCCH) should be used for UCI transmission as a function of an indication in the scheduling information (e.g., PUCCH on PCell, PUCCH on SCell). If no such indication exists, the WTRU can decide to use the default PUCCH channel, for example, PUCCH on PCell. This can also be applied to feedback transmissions on PUSCH, for example, when a PUSCH on a serving cell configured to use PUCCH can be scheduled for UCI transmission.

[0325] UCI scheduling information may include serving cell identification information. WTRU can determine the identification information of the serving cell corresponding to a physical uplink resource. Serving cell identification information, or CFI, can be used for PUSCH scheduling on UCI. For example, WTRU may receive a value corresponding to the serving cell identification information. Such identification information may be based on serving cell identification information used by other layers, e.g., servCell-ID in RRC. Alternatively, such identification information may be based on a configured value for cross-carrier scheduling, e.g., CFI. In this example, this can be applicable when the scheduling information can indicate a resource on PUSCH.

[0326] UCI scheduling information may include PUCCH / UCI feedback group identification information. WTRU can determine the identification information of the uplink feedback channel corresponding to a physical uplink resource as a function of the identification information of a group of cells associated with a single uplink channel (e.g., a PUCCH group). This can also be applied to feedback transmissions on a PUCCH, for example, when a PUCCH on a serving cell configured to use a PUCCH can be scheduled for UCI transmission.

[0327] UCI scheduling information may include the PUCCH format. WTRU can receive a representation of the PUCCH format used within the scheduling information, for example, PUCCH format 3 or other formats.

[0328] UCI scheduling information may include push transmission parameters. WTRUs can receive information similar to that for grants regarding uplink push transmissions for transmission on UCI feedback. For example, such grants may be dedicated to UCI transmissions.

[0329] UCI scheduling information may include PUCCH transmission parameters. These PUCCH transmission parameters can be similar to existing PUCCH formats, for example, parameters determined by the WTRU for PRB allocation.

[0330] UCI scheduling information may include channel coding. A WTRU can determine whether it should transmit one or a specific combination of UCI types as a function of the indicated channel coding method.

[0331] UCI scheduling information may include payload size. A WTRU can determine the amount of UCI to include in an uplink transmission as a function of the indicated payload size for a scheduled UCI transmission. In the example, if such information is not available, a WTRU may include UCI requests as described herein, using any other method, such as those described herein.

[0332] UCI scheduling information can include TPC commands (power control information). These TPC commands can be similar to legacy TPC commands, but can be interpreted as a function of whether the scheduling information is for PUSCH transmission or PUCCH transmission.

[0333] UCI scheduling information may include CSI requests. These CSI requests can be similar to legacy requests. For example, such a CSI request may override other CSI reports (e.g., periodic CSIs) during the relevant time interval.

[0334] Furthermore, different combinations of the scheduling information described above are possible as part of PUCCH or PUSCH. For example, a WTRU may receive a DCI(UCI) scheduling the transmission of a UCI over PUSCH, which may include the type of physical channel (i.e., PUSCH), identification information of the serving cell for uplink transmission (e.g., serving cell 0-PCell), PUSCH transmission parameters including resource block allocation, a modulation and coding scheme (MCS), and a TPC.

[0335] For example, a WTRU may receive a DCI(UCI) scheduling the transmission of a UCI on a PCell's PUCCH, which may include the type of physical channel (i.e., PUCCH), PUCCH transmission parameters including, for example, resource block allocation, and a TPC. In addition, the DCI(UCI) may include a UCI request such that the WTRU determines which UCIs should be included in such a transmission. The WTRU may determine that a PCell's PUCCH is scheduled based on the identification information of the cell on which the PDCCH for the DCI(UCI) was received.

[0336] In one example, a DCI for UCI, or DCI(UCI), can be used. In another example, a dedicated DCI can be used. In yet another example, an extension to an existing DCI can be used.

[0337] In the example, DCI(UCI) may represent any of the information described herein using a dedicated format that includes one or more fields for any of the embodiments described herein, or using one or more indices within the DCI(UCI) format.

[0338] In the example, if transient, the HARQ A / N cannot be generated by the DCI. In the example, the WTRU can receive the DCI(UCI). The WTRU cannot generate and / or include any HARQ A / N to report feedback about the DCI itself. The WTRU cannot do so if such a DCI(UCI) is applied per subframe and / or per TTI.

[0339] In another example, a HARQ A / N can be generated by a DCI if it is configured / activated or deactivated over a period of time. In this example, a WTRU may receive a DCI(UCI). The WTRU may decide that a DCI(UCI) constitutes a UCI report for a period of time equal to two or more subframe lengths (or two or more TTI lengths), for example, until it receives another DCI(UCI) that modifies or deactivates its configured UCI report. In such a case, the WTRU may generate and / or include HARQ A / N feedback for such a DCI(UCI) to report feedback about the reception of the DCI(UCI) itself, for example. In one way, the WTRU may use a UCI reporting method applicable prior to the reception of such a DCI(UCI) for the HARQ A / N report of the relevant DCI(UCI). When the WTRU receives such a DCI(UCI) in subframe n, it may start using the new configuration in subframe n+x+1. For example, x can be equal to 4, and the WTRU can apply the new configuration starting from the subframe following the transmission of the HARQ A / N report for the relevant DCI(UCI). In one example, the WTRU can use the new configuration shown in the DCI(UCI) itself for the HARQ A / N report for the relevant DCI(UCI). When the WTRU receives such a DCI(UCI) in subframe n, it can begin using the new configuration in subframe n+x. For example, x can be equal to 4, and the WTRU can apply the new configuration starting from the subframe that transmits the HARQ A / N report for the relevant DCI(UCI).

[0340] In the example, a UCI that is not requested for the specified type may be suppressed / dropped. In the example, when a WTRU receives such a request, it may decide that any UCI that is not part of the UCI request cannot be sent.

[0341] In another example, if a UCI is not part of any UCI request, other methods can be used. In this example, when a WTRU receives such a request, it can determine, using other methods, such as legacy methods, that any UCI that is not part of the UCI request can be transmitted. For example, if UCI scheduling indicates transmission over PUCCH, the WTRU can, according to legacy methods, forward the remaining UCI to a PUSCH transmission (if such is available). For example, if UCI scheduling indicates transmission over PUSCH, the WTRU can, according to legacy methods, forward the remaining UCI to a PUCCH transmission, but only if the WTRU is configured for simultaneous PUSCH / PUCCH transmissions, and both PUSCH and PUCCH are simultaneous and possibly for the same serving cell.

[0342] In another example, a WTRU may determine that it cannot transmit any UCI unless it receives a DCI(UCI) that includes a UCI request. In this example, even when it does not receive a DCI(UCI) that includes a DCI request, the WTRU may still include a UCI for any PUSCH transmission, for example, according to the legacy method.

[0343] In another example, UCI types that are not part of a request may be suppressed / dropped, or legacy transmission methods may be used. In this example, when a WTRU receives such a request, it may decide that it cannot transmit any UCIs that are not part of the UCI request.

[0344] In another example, a DCI(UCI) request could be solely for HARQ feedback. For instance, a WTRU could receive a DCI(UCI) requesting HARQ A / N feedback for a specific HARQ process and / or only for a specific serving cell.

[0345] In other examples, alternative decisions can be made. In some examples, any of the information described herein regarding UCI requests or UCI scheduling information can be implicitly derived by other means. For example, a specific RNTI can be assigned to indicate the type of DCI (DCI format 0, 1, etc., compared to DCI (UCI)), the type of UCI request, the type of physical channel (e.g., PUSCH vs. PUCCH), or cell identification information. Similarly, a specific region of the PDCCH search space, or a specific DCI aggregate level, or a specific size for the CRC of a DCI can be assigned and used to determine similar information.

[0346] In another example, semi-permanent assignments can be made. Scheduling information can be configured semi-permanently. In such cases, the configured information can be used as the default scheduling information. In such cases, the WTRU can receive a DCI (UCI) that overrides the configured scheduling information for the applicable serving cell. In such cases, the WTRU can refrain from performing any transmissions using the configured assignment when a UCI is not generated and / or when it is not available for transmissions during the relevant time interval. Alternatively, for HARQ feedback, the WTRU can report the value of the HARQ feedback following the last reception for the relevant process, while for CSI feedback, the WTRU can consider this as a periodic reporting configuration (for example, if aperiodic CSI configurations also exist).

[0347] In another example, the choice of channel coding can be a function of dynamic scheduling information. The WTRU can choose an appropriate channel coding as a function of the requested UCI (for example, the channel coding can be chosen in any of the ways described herein, or using legacy methods for at least one different combination of HARQ A / N, periodic CSI, CQI / PMI, and scheduling requests), and / or as a function of scheduling parameters for the UCI (for example, whether it is on PUCCH or PUSCH (if applicable)).

[0348] In another example, scheduling information for UCI may indicate resources corresponding to PUCCH transmissions, even when the WTRU is expected to perform simultaneous PUCCH transmissions for a given cell group (CG), for example. In such cases, the WTRU can use the indicated resources to perform applicable UCI transmissions, for example, when simultaneous PUCCH and PUSCH transmissions are configured for the relevant CG. If the WTRU does not perform simultaneous PUCCH / PUSCH transmissions, it may, according to legacy behavior, include applicable UCI information within the PUSCH transmission (e.g., UCIs required in dynamic scheduling information). In the example, the WTRU may include SRs within the scheduled UCI transmission.

[0349] In some cases, a WTRU can be configured to send periodic CSI reports (multiple periodic CSI reports) for two or more cells within a single subframe on PUCCH or PUSCH. A WTRU can also be configured to send HARQ-ACKs and / or SRs within the same subframe.

[0350] In some cases, a maximum payload can be configured for the transmission of HARQ-ACKs and periodic CSIs. A WTRU can be configured to use a maximum payload for each PUCCH resource that can be used for the transmission of HARQ-ACKs, periodic CSI reports, and / or SRs within a subframe. The maximum payload can be expressed in units of bits, or in terms of the maximum code rate, which is related to the known number of available coded bits for the configured resource. Such a maximum payload may depend on the combination of UCIs being transmitted, e.g., whether only a HARQ-ACK is transmitted, or whether a combination of a HARQ-ACK, periodic CSI, and SR is transmitted.

[0351] Alternatively, or in addition, the WTRU may be configured to use a maximum payload for periodic CSI reports per PUCCH resource, applicable independently of the number of HARQ-ACKs and SR bits transmitted within the resource. Such a maximum payload for periodic CSI reports may be the same as the configured maximum payload for a PUCCH resource used within a subframe, or used solely for the transmission of periodic CSIs within a subframe, according to one of the solutions described herein. Alternatively, the maximum payload for periodic CSI reports in the case of simultaneous transmission with HARQ-ACKs and / or SRs may be configured independently.

[0352] The WTRU may transmit fewer than the configured number of periodic CSI reports within a subframe in which HARQ-ACKs and / or SRs are also transmitted if the payload of periodic CSI reports exceeds the configured maximum payload for periodic CSI reports, or if the combined payload of HARQ-ACKs, SRs, and periodic CSI reports exceeds the configured maximum payload (or total number of UCI bits) for the PUCCH resource. The subset of periodic CSI reports to be transmitted can be determined according to one of the solutions described herein.

[0353] In some cases, when the transmission of HARQ-ACK conflicts with the transmission of multiple periodic CSI reports, the WTRU may transmit on one of the PUCCH resources configured for the transmission of multiple periodic CSIs, according to the solutions described herein. Alternatively, the WTRU may transmit on a periodic PUCCH resource indicated by downlink control information (i.e., the TPC field of the SCell assignment / ARI).

[0354] A WTRU can be configured to use two or more PUCCH resources for sending multiple periodic CSI reports within a subframe. In this case, the WTRU can determine the PUCCH resources according to at least one of the following solutions:

[0355] In this example, the WTRU can select a PUCCH resource based on at least one priority criterion. For instance, the WTRU can select a resource from among all serving cells for which periodic CSI reports are sent within the subframe, and associate it with the serving cell whose periodic CSI reports have the highest priority within the subframe.

[0356] In another example, a WTRU may select a PUCCH resource based on the total payload of periodic CSI reports transmitted within a subframe, or the total payload of HARQ-ACKs (if applicable), SRs (if applicable), and periodic CSI reports. For example, a WTRU may select a first PUCCH resource if the total payload does not exceed a threshold, and a second PUCCH resource otherwise. The threshold may correspond to, or be a function of, the maximum payload that the first PUCCH resource can support, which may be less than the maximum payload that the second PUCCH resource can support.

[0357] In a further example, a WTRU can select a PUCCH resource as a function of the required transmit power, based on power control parameters and formulas associated with each resource. The transmit power can be a function of at least one of the following: resource-specific parameters, format-specific parameters, payload, number of resource blocks, code rate, power control adjustments, and / or path loss. For example, a WTRU can select a resource that minimizes the required transmit power. In another example, a WTRU can select a first resource if the required transmit power for that resource is below a threshold; otherwise, it can select a second resource, perhaps only if the required transmit power for the second resource is lower in dB than the required transmit power for the first resource plus a configured offset. Above, the required transmit power for each resource can be adjusted to correspond to the peak transmit power, taking into account possible differences in cubic metrics (CM) and / or peak-to-average power ratio (PAPR) between different resources. The adjustment can be a function of at least one characteristic associated with the PUCCH resource, such as the PUCCH format or the number of resource blocks.

[0358] The WTRU can select a PUCCH resource based on whether HARQ-ACK and / or SR are also transmitted within the same subframe. In cases where HARQ-ACK and / or SR are also transmitted, the PUCCH resource used can be propagated from downlink control information or consist solely of higher layers.

[0359] In another example, a WTRU can select a PUCCH resource based on the timing of a subframe. For example, a first set and a second set of subframes can be associated with a first PUCCH resource and a second PUCCH resource, respectively. Each set can be defined in terms of duration and offset associated with the frame number and / or subframe number, or in terms of an index representing the duration and offset. For example, one set may correspond to subframes occurring with a duration of 20ms, including subframe #3 of frame #0. A WTRU can select a first PUCCH resource within subframes belonging only to the first set, and a second PUCCH resource within subframes belonging only to the second set. For subframes belonging to both sets, a WTRU can select a PUCCH resource based on at least one of the following: In the example, a WTRU can select a PUCCH resource based on a priority criterion. Priority can be predefined or based on resource characteristics such as the maximum supported payload (or code rate), the number of resource blocks, the starting resource block number, or the format. For example, priority can be assigned to a PUCCH resource that can support the highest maximum payload. In another example, a WTRU may select a PUCCH resource based on solutions already described elsewhere in this specification, such as based on the total payload to be transmitted, the required transmit power, and / or the priority of the relevant serving cell from which a report is being sent.

[0360] In some cases, a WTRU may transmit fewer periodic CSI reports than configured due to power limitations. The WTRU can first determine the maximum payload for periodic CSI reports and CRC (if applicable), or for a combination of periodic CSI reports, SR, HARQ-ACK feedback, and CRC (if applicable), based on the maximum power available for transmission, the channel type (PUCCH or PUSCH), the format in the case of PUCCH, and other parameters and measurements used for power control (e.g., path loss). The maximum payload may take into account the number of bits required for CRC addition, where applicable. Such a maximum payload may be referred to as a power-limited payload. In cases where the WTRU is configured to use two or more PUCCH resources, the WTRU can first determine the PUCCH resources based on the solutions described herein, and then determine the power-limited payload associated with the resources. Alternatively, the WTRU can select the PUCCH resource that yields the highest possible power-limited payload.

[0361] A power-limited payload can be constrained to one of a finite set of allowed values ​​for the maximum payload, or to a parameter from which the maximum payload can be derived (such as the maximum number of periodic reports or the maximum code rate). Such a set of allowed values ​​can correspond to a set of possible values ​​that can constitute part of the PUCCH resource.

[0362] The maximum power available for transmission can be determined using existing power scaling and allocation solutions when multiple cells and / or cell groups are configured. In some solutions, the WTRU can be configured to use a maximum power specific to PUCCH transmissions, including periodic CSIs. In this case, the maximum power available for transmission can be the minimum between this configured maximum power for periodic CSIs and the maximum available power obtained from the existing solution.

[0363] The maximum payload in the case of PUCCH can be determined using the relationship between the number of information bits and the power offset applicable to the PUCCH format used to transmit periodic CSI reports. The maximum payload in the case of PUCCH can also be determined from the maximum number of symbols (or symbol ratios) that can be used for encoding different types of CSI reports (RI, CQI, and PMI).

[0364] If the number of bits required to send a set of periodic CSI reports according to the configuration exceeds the maximum payload according to one of the solutions described herein, the WTRU may send a subset of the CSI reports based on priority rules. Priority rules may be based on legacy priority rules (i.e., report type and serving cell index). Priority rules may also be based on at least one of the following: namely, the time since the last transmission of a periodic report for a cell and at least one of the CQI and / or RI values. Perhaps only reports where the CQI / RI for it is above or below a configured threshold, and / or reports of changes in the CQI and / or RI values ​​since the last transmission of the corresponding report for the cell, may be sent (for example, reports with the largest changes in CQI and / or RI may be prioritized).

[0365] A WTRU may include cell identification information along with each set of CSI reports for a cell, at least in cases where the network cannot know the priority in advance, or when only a subset of reports are sent. A WTRU may also send a potentially separately encoded indication that only a subset of reports are being sent due to power limitations.

[0366] In cases where the power-limited payload is lower than the number of bits required for transmitting only the HARQ-ACK bit, or the HARQ-ACK and SR bits (plus the CRC bit, if applicable), the WTRU cannot include any periodic CSI reports in its transmission. In some solutions, the WTRU cannot include any periodic CSIs in its transmission whenever the power-limited payload is lower than the number of bits required for transmitting all periodic CSI reports, HARQ-ACK (if applicable), SR (if applicable), and CRC (if applicable), according to the configuration. In such cases, the WTRU can transmit only the HARQ-ACK, SR, and CRC, if applicable.

[0367] In some cases, the payload can be configured to belong to one of a finite set of possible values. For example, a WTRU can use padding (e.g., adding a large number of "0" bits to the payload) so that the payload matches one of a set of possible payload values ​​that can be predefined or configured by a higher layer. This can facilitate blind detection of the payload by receivers on the network side. Such padding can occur after payload reduction (for periodic CSI or other UCIs) according to one of the solutions described above. Perhaps padding should only be performed in cases where payload reduction occurs due to power limitations.

[0368] While features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in computer programs, software, or firmware contained within computer-readable media, executed by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, 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 disks and digital multi-purpose disks (DVDs). A processor in conjunction with software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer. [Embodiment 1] A method for uplink feedback operating with multiple carriers in a wireless transceiver unit (WTRU), The WTRU receives multiple transport blocks on a set of multiple configured carriers, The steps include generating hybrid automatic retransmission request (HARQ)-acknowledgment (ACK) feedback for the plurality of transport blocks using the WTRU, The steps include determining the number of HARQ-ACK feedback bits to be used for the HARQ-ACK feedback using the WTRU, The steps include applying Reed-Muller coding to the HARQ-ACK feedback bits by the WTRU, provided that the number of HARQ-ACK feedback bits is less than or equal to a threshold, The WTRU transmits the encoded HARQ-ACK feedback bits. A method characterized by comprising: [Embodiment 2] The step of adding cyclic redundancy check (CRC) bits to the HARQ-ACK feedback bits by the WTRU, provided that the number of feedback bits is greater than a threshold. The method of embodiment 1, further comprising: [Embodiment 3] The steps include applying convolution coding to the HARQ-ACK feedback bits and the CRC bits by the WTRU, provided that the number of HARQ-ACK feedback bits is greater than a threshold, The WTRU transmits the encoded HARQ-ACK feedback bits and CRC bits. The method of embodiment 2, further comprising [Embodiment 4] The method of Embodiment 1, characterized in that the generation of HARQ-ACK feedback for the plurality of transport blocks is based on a plurality of downlink assignment index (DAI) fields for the plurality of configured carriers, each DAI being shown within the downlink assignment. [Embodiment 5] The method of Embodiment 4, characterized in that the number of HARQ-ACK feedback bits used for the HARQ-ACK feedback is determined based on the number of transport blocks, the number of carriers in the set consisting of configured carriers, and the number of subframes on which the transport block receives. [Embodiment 6] The method of Embodiment 1, characterized in that the number of HARQ-ACK feedback bits used for the HARQ-ACK feedback is determined based on a plurality of downlink assignments to carriers in the set of configured carriers. [Embodiment 7] The method of Embodiment 1, characterized in that the set of configured carriers includes six or more configured carriers. [Embodiment 8] The method of Embodiment 1, characterized in that the number of HARQ-ACK feedback bits used for the HARQ-ACK feedback is determined for each of a plurality of subframes. [Embodiment 9] A wireless transceiver unit (WTRU) that operates using multiple carriers, A processor configured to receive multiple transport blocks on a set of multiple configured carriers, The processor is configured to generate hybrid automatic retransmission request (HARQ)-acknowledgment (ACK) feedback for the plurality of transport blocks, The processor is configured to determine the number of HARQ-ACK feedback bits to be used for the HARQ-ACK feedback, The processor is configured to apply Reed-Muller coding to the HARQ-ACK feedback bits, provided that the number of HARQ-ACK feedback bits is less than or equal to a threshold. The processor is operably coupled to a transceiver, The WTRU is characterized in that the transceiver and the processor are configured to transmit the encoded HARQ-ACK feedback bits. [Embodiment 10] The WTRU of embodiment 9 is further configured to add cyclic redundancy check (CRC) bits to the HARQ-ACK feedback bits, provided that the number of feedback bits is greater than a threshold. [Embodiment 11] The processor is further configured to apply convolution coding to the HARQ-ACK feedback bits and the CRC bits, provided that the number of HARQ-ACK feedback bits is greater than a threshold. The WTRU of embodiment 10 is characterized in that the transceiver and the processor are further configured to transmit the encoded HARQ-ACK feedback bits and CRC bits. [Embodiment 12] The generation of HARQ-ACK feedback for the plurality of transport blocks is characterized in that it is based on a plurality of downlink assignment index (DAI) fields for the plurality of configured carriers, each DAI being shown within the downlink assignment, in the WTRU of Embodiment 9. [Embodiment 13] The WTRU of Embodiment 12 is characterized in that the number of HARQ-ACK feedback bits used for the HARQ-ACK feedback is determined based on the number of transport blocks, the number of carriers in the set consisting of configured carriers, and the number of subframes on which the transport block receives. [Embodiment 14] The WTRU of Embodiment 9 is characterized in that the number of HARQ-ACK feedback bits used for the HARQ-ACK feedback is determined based on a plurality of downlink assignments to carriers in the set of configured carriers. [Embodiment 15] The WTRU of embodiment 9 is characterized in that the set consisting of configured carriers includes six or more configured carriers. [Embodiment 16] The WTRU of embodiment 9 is characterized in that the number of HARQ-ACK feedback bits used for the HARQ-ACK feedback is determined for each of a plurality of subframes. [Embodiment 17] A method for uplink feedback operating with multiple carriers in a wireless transceiver unit (WTRU), The WTRU receives multiple transport blocks on a set of multiple configured carriers, The steps include generating hybrid automatic retransmission request (HARQ)-acknowledgment (ACK) feedback and channel status information (CSI) feedback for the plurality of transport blocks using the WTRU, The steps of generating a feedback message using the WTRU, including the number of HARQ-ACK feedback bits to be used for the HARQ-ACK feedback and the number of CSI feedback bits to be used for the CSI feedback, The steps include determining the physical uplink control channel (PUCCH) format based on the number of HARQ-ACK feedback bits and the number of CSI feedback bits using the WTRU, The WTRU then performs the steps of sending the feedback message using the determined PUCCH format and A method characterized by comprising: [Embodiment 18] The step of selecting a first PUCCH format or a second PUCCH format by the WTRU, provided that the number of HARQ-ACK feedback bits is greater than zero and the number of CSI feedback bits is greater than zero. The method of embodiment 17, further comprising: [Embodiment 19] The step of selecting a first PUCCH format by the WTRU, provided that the sum of the number of HARQ-ACK feedback bits and the number of CSI feedback bits is greater than a first threshold, The step of selecting a second PUCCH format by the WTRU, provided that the sum of the number of HARQ-ACK feedback bits and the number of CSI feedback bits is less than or equal to the first threshold, The method of embodiment 18, further comprising: [Embodiment 20] The step of selecting a first PUCCH format or a third PUCCH format by the WTRU, provided that the number of HARQ-ACK feedback bits is equal to zero and the number of CSI feedback bits is greater than zero. The method of embodiment 17, further comprising: [Embodiment 21] The step of selecting a first PUCCH format by the WTRU, provided that the number of CSI feedback bits is greater than a second threshold, The step of selecting a third PUCCH format by the WTRU, provided that the number of CSI feedback bits is less than or equal to the second threshold, The method of embodiment 20, further comprising: [Embodiment 22] The step of selecting a first PUCCH format or a fourth PUCCH format by the WTRU, provided that the number of HARQ-ACK feedback bits is greater than zero and the number of CSI feedback bits is equal to zero. The method of embodiment 17, further comprising: [Embodiment 23] The step of selecting a first PUCCH format by the WTRU, provided that the number of HARQ-ACK feedback bits is greater than a third threshold, The step of selecting a fourth PUCCH format by the WTRU, provided that the number of HARQ-ACK feedback bits is less than or equal to the third threshold, The method of embodiment 22, further comprising: [Embodiment 24] The method of Embodiment 17, characterized in that the number of HARQ-ACK feedback bits used for the HARQ-ACK feedback is determined based on a plurality of downlink assignments to carriers in the set of configured carriers. [Embodiment 25] The method of embodiment 17, characterized in that the number of CSI feedback bits used for the CSI feedback is determined based on a plurality of downlink assignments to carriers in the set of configured carriers. [Embodiment 26] The method of Embodiment 17, characterized in that the number of HARQ-ACK feedback bits used for the HARQ-ACK feedback is determined based on the number of transport blocks, the number of carriers in the set consisting of configured carriers, and the number of subframes on which the transport block receives. [Embodiment 27] The method of Embodiment 17, characterized in that the number of CSI feedback bits used for the CSI feedback is determined based on the number of transport blocks, the number of carriers in the set consisting of configured carriers, and the number of subframes on which the transport block receives. [Embodiment 28] The method of embodiment 17, characterized in that the set of configured carriers includes six or more configured carriers. [Industrial applicability]

[0369] This invention can generally be used in wireless communication systems. [Explanation of symbols]

[0370] 100 Communication Systems 102a~102d Wireless Transmitter / Receiver Unit (WTRU) 103 RAN 106 Core Network 108 PSTN 110 Internet 112 Other Networks 118 processors 120 transceivers 122 Antenna

Claims

1. A wireless transceiver unit (WTRU) equipped with a processor and memory, The processor and the memory are, On at least one configured carrier, multiple transport blocks are received, The number of hybrid automatic retransmission request (HARQ) acknowledgment (ACK) feedback bits for the plurality of transport blocks and the number of channel state information feedback bits (a plurality of CSI feedback bits) for the at least one configured carrier are generated. Based on the generated HARQ-ACK feedback bits and the CSI feedback bits, the number of cyclic redundancy check (CRC) bits is determined. Based on at least the number of HARQ-ACK feedback bits and the number of CSI feedback bits, the physical uplink control channel (PUCCH) format is determined. Based on the number of HARQ-ACK feedback bits, the number of CSI feedback bits, and the number of CRC bits, the transmit power to be used for PUCCH transmission is determined. With the determined transmit power, a feedback bit is transmitted using the determined PUCCH format, the feedback bit includes the generated HARQ-ACK feedback bit, the generated CSI feedback bit, and the determined CRC bit. A well-configured WTRU.

2. The processor and the memory are, The WTRU of claim 1 is further configured to determine a set of PUCCH resources based on the number of HARQ-ACK feedback bits and the number of CSI feedback bits, wherein at least one resource of the set of PUCCH resources is used to transmit the feedback bits.

3. The processor and the memory are, A WTRU according to claim 1, further configured to generate a number of scheduling request (SR) bits.

4. The WTRU of claim 3, wherein the determination of the PUCCH format is further based on the number of SR bits.

5. The WTRU of claim 3, wherein the determination of the transmission power is further based on the number of SR bits.

6. The WTRU of claim 3, wherein the number of CRC bits is determined based on the number of HARQ-ACK feedback bits, the number of CSI feedback bits, and the number of SR bits.

7. The WTRU according to claim 1, wherein the plurality of configured carriers include at least one configured carrier.

8. The WTRU of claim 7, wherein the number of HARQ-ACK feedback bits for the generated HARQ-ACK feedback, or the number of CSI feedback bits for the generated CSI feedback, is determined based on a plurality of downlink assignments to carriers among the plurality of configured carriers.

9. The WTRU of claim 1, wherein the number of HARQ-ACK feedback bits for the HARQ-ACK feedback is determined based on at least one of the number of the plurality of transport blocks, the number of carriers in the at least one configured carrier, or the number of subframes from which the transport block is received.

10. The WTRU of claim 1, wherein the number of CSI feedback bits for the CSI feedback is determined based on at least one of the number of the plurality of transport blocks, the number of carriers in the at least one configured carrier, or the number of subframes from which the transport block is received.

11. A method implemented by a wireless transceiver unit (WTRU), The steps include receiving multiple transport blocks on at least one configured carrier, The steps include generating a number of hybrid automatic retransmission request (HARQ) acknowledgment (ACK) feedback bits for the plurality of transport blocks and a number of channel state information feedback bits (a plurality of CSI feedback bits) for the at least one configured carrier, The steps include determining the number of cyclic redundancy check (CRC) bits based on the generated HARQ-ACK feedback bits and the generated CSI feedback bits, The steps include determining the physical uplink control channel (PUCCH) format based on at least the number of HARQ-ACK feedback bits and the number of CSI feedback bits, A step of determining the transmit power to be used for PUCCH transmission based on the number of HARQ-ACK feedback bits, the number of CSI feedback bits, and the number of CRC bits, A step of transmitting a feedback bit using the determined PUCCH format with the determined transmit power, wherein the feedback bit includes the generated HARQ-ACK feedback bit, the generated CSI feedback bit, and the determined CRC bit. A method for providing this.

12. A step of determining a set of PUCCH resources based on the number of HARQ-ACK feedback bits and the number of CSI feedback bits. The method of claim 11, further comprising, wherein at least one resource of the set of PUCCH resources is used to transmit the feedback bit.

13. Steps to generate the number of scheduling request (SR) bits. The method of claim 11, further comprising the above.

14. The method of claim 13, wherein the determination of the PUCCH format is further based on the number of SR bits.

15. The method of claim 13, wherein the determination of the transmission power is further based on the number of SR bits.

16. The method of claim 13, wherein the number of CRC bits is determined based on the number of HARQ-ACK feedback bits, the number of CSI feedback bits, and the number of SR bits.

17. The method of claim 13, wherein the plurality of configured carriers include at least one configured carrier.

18. The method of claim 17, wherein the number of HARQ-ACK feedback bits for the generated HARQ-ACK feedback, or at least one of the number of CSI feedback bits for the generated CSI feedback, is determined based on a plurality of downlink assignments to carriers among the plurality of configured carriers.

19. The method of claim 11, wherein the number of HARQ-ACK feedback bits for the HARQ-ACK feedback is determined based on at least one of the number of the plurality of transport blocks, the number of carriers in the at least one configured carrier, or the number of subframes in which the transport block is received.

20. The method of claim 11, wherein the number of CSI feedback bits for the CSI feedback is determined based on at least one of the number of the plurality of transport blocks, the number of carriers in the at least one configured carrier, or the number of subframes from which the transport block is received.

Images