Patent Description:
In 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) Release <NUM>, support was introduced for carrier aggregation (CA) involving aggregation of up to five component carriers of the same frame structure. In view of the ongoing proliferation of LTE-capable devices and the ever-increasing volumes of data that must be accommodated by modem networks, 3GPP is contemplating various potential approaches to increasing data rates. One approach under consideration is an extended CA scheme, according to which up to <NUM> component carriers may be aggregated in order to support wider spectrum bands at the user equipment (UE) side and boost peak data rate performance.

<CIT> describes a method for transmitting HARQ-ACK feedback information in a wireless communication system.

Various embodiments may be generally directed to HARQ feedback configuration techniques for broadband wireless communication networks. In one embodiment, for example, an apparatus may comprise a memory and logic for user equipment (UE), at least a portion of the logic implemented in circuitry coupled to the memory, the logic to identify a hybrid automatic repeat request (HARQ) bundling window associated with a received downlink (DL) scheduling command, identify one or more HARQ feedback configuration parameters based on HARQ feedback configuration information comprised in the DL scheduling command, the one or more identified HARQ feedback configuration parameters to include a physical uplink control channel (PUCCH) format for use in transmission of HARQ feedback for the HARQ feedback bundling window, the logic to generate the HARQ feedback for transmission to an evolved node B (eNB) according to the PUCCH format. Other embodiments are described and claimed.

Various embodiments may comprise one or more elements. An element may comprise any structure arranged to perform certain operations. Each element may be implemented as hardware, software, or any combination thereof, as desired for a given set of design parameters or performance constraints. Although an embodiment may be described with a limited number of elements in a certain topology by way of example, the embodiment may include more or less elements in alternate topologies as desired for a given implementation. It is worthy to note that any reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrases "in one embodiment," "in some embodiments," and "in various embodiments" in various places in the specification are not necessarily all referring to the same embodiment.

The techniques disclosed herein may involve transmission of data over one or more wireless connections using one or more wireless mobile broadband technologies. For example, various embodiments may involve transmissions over one or more wireless connections according to one or more 3rd Generation Partnership Project (3GPP), 3GPP Long Term Evolution (LTE), and/or 3GPP LTE-Advanced (LTE-A) technologies and/or standards, including their revisions, progeny and variants. Various embodiments may additionally or alternatively involve transmissions according to one or more Global System for Mobile Communications (GSM)/Enhanced Data Rates for GSM Evolution (EDGE), Universal Mobile Telecommunications System (UMTS)/High Speed Packet Access (HSPA), and/or GSM with General Packet Radio Service (GPRS) system (GSM/GPRS) technologies and/or standards, including their revisions, progeny and variants.

Examples of wireless mobile broadband technologies and/or standards may also include, without limitation, any of the Institute of Electrical and Electronics Engineers (IEEE) <NUM> wireless broadband standards such as IEEE <NUM> and/or <NUM>. 16p, International Mobile Telecommunications Advanced (IMT-ADV), Worldwide Interoperability for Microwave Access (WiMAX) and/or WiMAX II, Code Division Multiple Access (CDMA) <NUM> (e.g., CDMA2000 1xRTT, CDMA2000 EV-DO, CDMA EV-DV, and so forth), High Performance Radio Metropolitan Area Network (HIPERMAN), Wireless Broadband (WiBro), High Speed Downlink Packet Access (HSDPA), High Speed Orthogonal Frequency-Division Multiplexing (OFDM) Packet Access (HSOPA), High-Speed Uplink Packet Access (HSUPA) technologies and/or standards, including their revisions, progeny and variants.

Some embodiments may additionally or alternatively involve wireless communications according to other wireless communications technologies and/or standards. Examples of other wireless communications technologies and/or standards that may be used in various embodiments may include, without limitation, other IEEE wireless communication standards such as the IEEE <NUM>, IEEE <NUM>. 11a, IEEE <NUM>. 11b, IEEE <NUM>, IEEE <NUM>. 11n, IEEE <NUM>. 11u, IEEE <NUM>. 11ac, IEEE <NUM>. 11ad, IEEE <NUM>. 11af, and/or IEEE <NUM>. 11ah standards, High-Efficiency Wi-Fi standards developed by the IEEE <NUM> High Efficiency WLAN (HEW) Study Group, Wi-Fi Alliance (WFA) wireless communication standards such as Wi-Fi, Wi-Fi Direct, Wi-Fi Direct Services, Wireless Gigabit (WiGig), WiGig Display Extension (WDE), WiGig Bus Extension (WBE), WiGig Serial Extension (WSE) standards and/or standards developed by the WFA Neighbor Awareness Networking (NAN) Task Group, machine-type communications (MTC) standards such as those embodied in 3GPP Technical Report (TR) <NUM>, 3GPP Technical Specification (TS) <NUM>, and/or 3GPP TS <NUM>, and/or near-field communication (NFC) standards such as standards developed by the NFC Forum, including any revisions, progeny, and/or variants of any of the above. The embodiments are not limited to these examples.

In addition to transmission over one or more wireless connections, the techniques disclosed herein may involve transmission of content over one or more wired connections through one or more wired communications media. Examples of wired communications media may include a wire, cable, metal leads, printed circuit board (PCB), backplane, switch fabric, semiconductor material, twisted-pair wire, co-axial cable, fiber optics, and so forth.

<FIG> illustrates an example of an operating environment <NUM> that may be representative of various embodiments. In operating environment <NUM>, an evolved node B (eNB) <NUM> generally serves a cell <NUM>, and may provide user equipment (UE) <NUM> with wireless connectivity via a wireless carrier of cell <NUM>. During ongoing operation, eNB <NUM> may identify data <NUM> to be transmitted to UE <NUM>. In some embodiments, eNB <NUM> may schedule transmission of data <NUM> for an upcoming subframe, which may be referred to as the "transmit subframe" for data <NUM>. In various embodiments, in order to notify UE <NUM> of the upcoming transmission, eNB <NUM> may send a downlink (DL) scheduling command <NUM> to UE <NUM> over a physical downlink control channel (PDCCH) or enhanced physical downlink control channel (EPDCCH), collectively depicted in <FIG> as (E)PDCCH <NUM>. In some embodiments, eNB <NUM> may then transmit data <NUM> to UE <NUM> over a physical downlink shared channel (PDSCH) <NUM> during the transmit subframe for data <NUM>. In various embodiments, in response to receipt of DL scheduling command <NUM>, UE <NUM> may identify the transmit subframe of data <NUM> and access one or more resources of PDSCH <NUM> during that transmit subframe to receive data <NUM>.

In some embodiments, in order to confirm successful receipt of data <NUM> - or to report non-receipt of some or all of data <NUM> - UE <NUM> may generate HARQ feedback <NUM>. In various embodiments, UE <NUM> may transmit HARQ feedback <NUM> to eNB <NUM> over a physical uplink control channel (PUCCH) <NUM>. More particularly, in some embodiments, UE <NUM> may transmit HARQ feedback <NUM> to eNB <NUM> using a particular PUCCH resource of PUCCH <NUM> and according to a particular PUCCH format.

In various embodiments, UE <NUM> may be configured to use HARQ feedback <NUM> to provide feedback for one or more other DL data transmissions in addition to that of data <NUM>. In some embodiments, UE <NUM> may be configured to use HARQ feedback <NUM> to provide feedback for one or more DL data transmissions occurring during a different subframe (or set of different subframes) than that during which the DL transmission of data <NUM> occurs. In various embodiments, UE <NUM> may be configured to use HARQ feedback <NUM> to provide feedback for one or more DL data transmissions performed using a different carrier (or set of different carriers) than that used for the DL transmission of data <NUM>. In some embodiments, UE <NUM> may be configured to use HARQ feedback <NUM> to provide feedback for DL data transmissions of multiple subframes and multiple carriers. For example, in various embodiments, carrier aggregation may be used to enable DL data transmission to UE <NUM> via each of a set of aggregated component carriers, and UE <NUM> may be configured to use HARQ feedback <NUM> to provide feedback for DL transmissions collectively performed during multiple subframes using multiple such component carriers. In some such embodiments, cell <NUM> may comprise a primary cell (PCell) with respect to wireless communications with/by UE <NUM>.

In various embodiments, UE <NUM> may select the PUCCH format that it uses for transmission of HARQ feedback <NUM> based on the size of HARQ feedback <NUM>, which in turn may depend on the amount of transmitted DL data for which feedback is being provided. For example, in some embodiments, UE <NUM> may use one of relatively compact PUCCH formats 1a or 1b if HARQ feedback <NUM> merely includes feedback for DL data transmission of a single subframe and single carrier, and may use the larger PUCCH format <NUM> if HARQ feedback <NUM> includes feedback for DL data transmissions of multiple subframes and/or multiple component carriers.

In various embodiments, an enhanced carrier aggregation scheme may be implemented to enable DL data transmission to UE <NUM> via any or all of a larger number of component carriers than are aggregated according to conventional techniques. For example, in some embodiments, an enhanced carrier aggregation scheme may be implemented to enable DL data transmission to UE <NUM> via up to <NUM> component carriers, rather than limiting such transmissions to a maximum of five component carriers in accordance with conventional LTE carrier aggregation protocols. In various such embodiments, conventional PUCCH formats may not be large enough to accommodate the potential amounts of HARQ feedback that may need to be transmitted at one time. For example, while PUCCH format <NUM> may be used to accommodate up to <NUM> bits of HARQ feedback, the provision of HARQ feedback for respective DL data transmissions over each of <NUM> component carriers may require <NUM> bits if cell <NUM> is a frequency division duplexing (FDD) cell, and potentially <NUM> bits or more if cell <NUM> is a time division duplexing (TDD) cell.

In some embodiments, in order to accommodate the larger amounts of HARQ feedback that may need to be conveyed in conjunction with such an enhanced carrier aggregation scheme, an enhanced PUCCH format may be implemented. For example, in various embodiments, an enhanced PUCCH format may be implemented that may be used to transmit up to <NUM> bits of HARQ feedback. However, if the enhanced PUCCH format is used for all transmissions of aggregated HARQ feedback, significant amounts of PUCCH resources may be wasted. For example, if an enhanced PUCCH format designed to accommodate a <NUM>-bit HARQ feedback payload is used to transmit <NUM> bits of HARQ feedback, the majority of the resources consumed by the PUCCH transmission may be wasted. The embodiments are not limited to this example.

Disclosed herein are HARQ feedback configuration techniques for broadband wireless networks. According to some such techniques, an eNB such as eNB <NUM> may include HARQ feedback configuration information in a DL scheduling command in order to specify one or more HARQ feedback configuration parameters. In various embodiments, the one or more HARQ feedback configuration parameters may include a PUCCH format to be used for HARQ feedback transmission. In some embodiments, the one or more HARQ feedback configuration parameters may include a PUCCH resource to be used for HARQ feedback transmission. In various embodiments, the one or more HARQ feedback configuration parameters may include a HARQ feedback payload size.

<FIG> illustrates an example of an operating environment <NUM> that may be representative of the implementation of one or more of the disclosed HARQ feedback configuration techniques according to some embodiments. In operating environment <NUM>, eNB <NUM> may send a DL scheduling command <NUM> to UE <NUM> over (E)PDCCH <NUM> in order to notify UE <NUM> of an upcoming transmission of data <NUM> to UE <NUM> over PDSCH <NUM>. In response to receipt of DL scheduling command <NUM>, UE <NUM> may monitor the appropriate resource(s) of PDSCH <NUM> during the transmit subframe for data <NUM>. UE <NUM> may then include HARQ feedback for data <NUM> in HARQ feedback <NUM> that it transmits over PUCCH <NUM> to eNB <NUM>.

In various embodiments, in addition to feedback for data <NUM>, HARQ feedback <NUM> may include feedback for one or more other DL data transmissions to UE <NUM>. In some embodiments, HARQ feedback <NUM> may include respective feedback for DL data transmissions to UE <NUM> over each of multiple component carriers. In various embodiments, PDSCH <NUM> may comprise a PDSCH of one of a plurality of aggregated component carriers, and HARQ feedback <NUM> may include feedback for DL data transmissions to UE <NUM> over respective PDSCHs of one or more other component carriers comprised among the plurality of aggregated component carriers. In some embodiments, HARQ feedback <NUM> may include respective feedback for DL data transmissions to UE <NUM> during each of multiple subframes. In various embodiments, for example, during a given UL subframe, UE <NUM> may need to provide HARQ feedback for each of a set of multiple DL subframes, and HARQ feedback <NUM> may comprise the respective HARQ feedback for each such DL subframe. Hereinafter, the term "HARQ feedback bundling window" shall be employed to denote such a set of multiple DL subframes.

In some embodiments, DL scheduling command <NUM> may comprise HARQ feedback configuration information (HFCI) field <NUM>. In various embodiments, HFCI field <NUM> may comprise a one-bit field. In some embodiments, HFCI field <NUM> may only be permitted to be present in DL scheduling commands that map onto UE-specific (E)PDCCH search spaces corresponding to the cell radio network temporary identifiers (C-RNTIs) to which they are addressed. In various embodiments, eNB <NUM> may construct DL scheduling command <NUM> according to a particular defined DL control information (DCI) format. In some embodiments, that DCI format may comprise an enhanced version of a conventional DCI format. In various embodiments, for example, enhanced versions of one or more of DCI formats <NUM>, 1A, 1B, 1D, <NUM>, 2A, 2B, 2C, and 2D may be defined that include HFCI field <NUM>, and eNB <NUM> may construct DL scheduling command <NUM> in accordance with one such enhanced DCI format.

In some embodiments, eNB <NUM> may use HFCI field <NUM> to indicate a PUCCH format that UE <NUM> should use in transmitting HARQ feedback <NUM> over PUCCH <NUM> to eNB <NUM>. In various such embodiments, eNB <NUM> may select the value of HFCI field <NUM> based on the value-to-parameter correspondences illustrated in Table <NUM> below. In such embodiments, eNB <NUM> may set HFCI field <NUM> to '<NUM>' in order to indicate that UE <NUM> should use a first PUCCH format in transmitting HARQ feedback <NUM>, or may set HFCI field <NUM> to '<NUM>' in order to indicate that UE <NUM> should use a second PUCCH format in transmitting HARQ feedback <NUM>. In some embodiments, the first and second PUCCH formats may include a conventional PUCCH format and an enhanced PUCCH format designed to accommodate larger HARQ feedback payloads. For example, in various embodiments, eNB <NUM> may set the value of HFCI field <NUM> to '<NUM>' in order to indicate that such an enhanced PUCCH format is to be used, or may set the value of HFCI field <NUM> to '<NUM>' in order to indicate that PUCCH format <NUM> is to be used. In some other embodiments, both of the two PUCCH formats may comprised enhanced PUCCH formats.

In various embodiments, based on HFCI field <NUM>, UE <NUM> may identify a PUCCH format according to which to transmit HARQ feedback <NUM> over PUCCH <NUM> to eNB <NUM>. In some embodiments, based on the identified PUCCH format, UE <NUM> may identify a PUCCH resource to be used in transmitting HARQ feedback <NUM> over PUCCH <NUM> to eNB <NUM>. In various embodiments, UE <NUM> may identify the PUCCH resource as one of four PUCCH resources associated with the PUCCH format according to higher-layer configuration. In some such embodiments, UE <NUM> may identify the PUCCH resource based on the value of a transmit power control (TPC) field comprised in a DL scheduling command - which may or may not be DL scheduling command <NUM> - that is associated with a DL data transmission for which HARQ feedback <NUM> includes feedback and that contains a DL assignment index (DAI) value that is greater than <NUM>.

In various embodiments, after identifying the PUCCH format according to which HARQ feedback <NUM> is to be transmitted over PUCCH <NUM> to eNB <NUM>, UE <NUM> may determine a HARQ payload size OACK for HARQ feedback <NUM> based on the identified PUCCH format. In some embodiments, particular respective HARQ payload sizes for use in conjunction with the first and second PUCCH formats may be predefined, or may be configured by higher layer signaling. In various embodiments, for example, OACK may be predefined or configured by higher layers to be equal to <NUM> when PUCCH format <NUM> is being used, and may be predefined or configured by higher layers to be equal to <NUM> or <NUM> when an enhanced PUCCH format designed to accommodate larger HARQ feedback payloads is being used. The embodiments are not limited to this example.

In some embodiments, once it determines OACK, UE <NUM> may construct HARQ feedback <NUM> as a sequence of OACK bits <MAT>. In various embodiments, in generating HARQ feedback <NUM> for a plurality of DL data transmissions of a HARQ feedback bundling window, UE <NUM> may order the bits <MAT> according to the values of DAI fields comprised in the DL scheduling commands corresponding to those DL data transmissions. In some embodiments, the HARQ feedback for a PDSCH transmission with a corresponding PDCCH/EPDCCH transmission or for a PDCCH/EPDCCH indicating downlink semi-persistent scheduling (SPS) release in a subframe n-k may be associated with <MAT> if a configured transmission mode supports one transport block or spatial HARQ feedback bundling is applied, and otherwise may be associated with <MAT> and <MAT>, where DAI(k) represents the value of the DAI field in a detected DL scheduling command of DCI format <NUM>, 1A, 1B, 1D, <NUM>, 2A, 2B, 2C, or 2D detected in the HARQ feedback bundling window, and <MAT> and <MAT> represent HARQ feedback for codewords <NUM> and <NUM>, respectively. In various embodiments in which NSPS > <NUM>, HARQ feedback for a PDSCH transmission for which there is no corresponding PDCCH/EPDCCH transmission may be mapped to <MAT>. In some embodiments, HARQ feedback bits that correspond to PDCCH/EPDCCH transmissions without any detected corresponding PDSCH transmissions or correspond to non-detected PDCCH/EPDCCH downlink SPS release indications may be set to NACK.

<FIG> illustrates an example of a HARQ feedback generation process <NUM> that may be representative of the implementation of one or more of the disclosed HARQ feedback configuration techniques according to various embodiments. For example, HARQ feedback generation process <NUM> may be representative of a HARQ feedback generation process that UE <NUM> may use to generate HARQ feedback <NUM> following a determination that HARQ feedback <NUM> is to be transmitted using PUCCH format <NUM> and a determination that HARQ feedback <NUM> is to comprise <NUM> bits. According to HARQ feedback generation process <NUM>, for a UE configured with an aggregated set of ten component carriers - each corresponding to a respective one of cells <NUM> to <NUM> - a HARQ feedback bit sequence <NUM> may be generated for a HARQ feedback bundling window <NUM>. In this example, HARQ feedback bundling window <NUM> comprises a series of four subframes: subframe n, subframe n+<NUM>, subframe n+<NUM>, and subframe n+<NUM>. The embodiments are not limited to this example.

According to HARQ feedback generation process <NUM>, construction of HARQ feedback bit sequence <NUM> proceeds on a subframe-by-subframe basis, and within each subframe, on a cell-by-cell basis. For each subframe, any cells for which previously received DL scheduling commands had indicated scheduled DL data transmissions may be identified, and for each such cell, a respective HARQ feedback bit may be generated to indicate whether the scheduled DL data transmission was successfully received. For example, cells <NUM>, <NUM>, <NUM>, and <NUM> may be identified as cells from which DL data transmissions were expected during subframe n, and HARQ feedback bits b<NUM>, b<NUM>, b<NUM>, and b<NUM> may be generated to indicate whether the scheduled DL data transmissions were successfully received from respective cells <NUM>, <NUM>, <NUM>, and <NUM> during subframe n.

In order to account for the possibility of some DL scheduling commands pertaining to HARQ feedback bundling window <NUM> having been missed, DAI values comprised in received DL scheduling commands pertaining to HARQ feedback bundling window <NUM> may be analyzed. According to HARQ feedback generation process <NUM>, when discontinuities are detected in such DAI values, HARQ feedback bits may be generated for DL data transmissions of which the UE had been unaware. In the example depicted in <FIG>, DL scheduling commands corresponding to DL data transmissions of cells <NUM> and <NUM> during subframe n+<NUM> may have been missed. However, based on respective DAI values of <NUM> and <NUM> comprised in DL scheduling commands corresponding to DL data transmissions of cells <NUM> and <NUM> during subframe n+<NUM>, it may be concluded that DL scheduling commands were missed for DL data transmissions of two of cells <NUM> to <NUM> during subframe n+<NUM>. Thus, HARQ feedback bits b<NUM>, b<NUM>, b<NUM>, and b<NUM> may be generated for subframe n+<NUM>. Bits b<NUM> and b<NUM> may be set to indicate whether DL data transmissions were successfully received from respective cells <NUM> and <NUM> during subframe n+<NUM>, and bits b<NUM> and b<NUM> may be set to NACKs.

Similarly, for subframe n+<NUM>, HARQ feedback bits b<NUM>, b<NUM>, and b<NUM> may be generated. Bits b<NUM> and b<NUM> may be set to indicate whether DL data transmissions were successfully received from respective cells <NUM> and <NUM> during subframe n+<NUM>, and bit b<NUM> may be set to a NACK based on detection of a missed DL scheduling command, which in this example was a DL scheduling command for a DL data transmission of cell <NUM>. For subframe n+<NUM>, a HARQ feedback bit b<NUM> may be generated and set to indicate whether a DL data transmission was successfully received from cell <NUM> during subframe n+<NUM>. Following the generation of HARQ feedback bits b<NUM> to b<NUM>, in accordance with a determination that HARQ feedback bit sequence <NUM> is to comprise <NUM> bits, nine additional bits b<NUM> to b<NUM> may be generated and set to NACKs. Finally, HARQ feedback bit sequence <NUM> may be generated by concatenating HARQ feedback bits b<NUM> to b<NUM> to obtain a bit sequence of <NUM> bits. The embodiments are not limited to this example.

<FIG> illustrates an example of an operating environment <NUM> that may be representative of some embodiments. In operating environment <NUM>, as in operating environment <NUM> of <FIG>, UE <NUM> may receive DL scheduling command <NUM> and generate HARQ feedback <NUM>. However, in operating environment <NUM>, DL scheduling command <NUM> may comprise a multi-bit HFCI field <NUM>. In various embodiments, eNB <NUM> may use multi-bit HFCI field <NUM> to specify multiple HARQ feedback configuration parameters In some embodiments, HFCI field <NUM> may only be permitted to be present in DL scheduling commands that map onto UE-specific (E)PDCCH search spaces corresponding to the cell radio network temporary identifiers (C-RNTIs) to which they are addressed. In various embodiments, enhanced versions of one or more of DCI formats <NUM>, 1A, 1B, 1D, <NUM>, 2A, 2B, 2C, and 2D may be defined that include multi-bit HFCI field <NUM>, and eNB <NUM> may construct DL scheduling command <NUM> in accordance with one such enhanced DCI format.

Table <NUM> illustrates a first example of a value-to-parameter mapping that may be defined in some embodiments for a two-bit HFCI field <NUM>. According to the value-to-parameter mapping illustrated in Table <NUM>, eNB <NUM> may use HFCI field <NUM> to indicate both a PUCCH format and a PUCCH resource that UE <NUM> should use in transmitting HARQ feedback <NUM> over PUCCH <NUM> to eNB <NUM>. Namely, eNB <NUM> may set HFCI field <NUM> to '<NUM>' to indicate a first PUCCH format and a first PUCCH resource, may set HFCI field <NUM> to '<NUM>' to indicate the first PUCCH format and a second PUCCH resource, may set HFCI field <NUM> to '<NUM>' to indicate a second PUCCH format and the first PUCCH resource, or may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format and the second PUCCH resource.

Table <NUM> illustrates a second example of a value-to-parameter mapping that may be defined in various embodiments for a two-bit HFCI field <NUM>. Like the mapping illustrated in Table <NUM>, the mapping illustrated in Table <NUM> may enable eNB <NUM> to use HFCI field <NUM> to indicate both a PUCCH format and a PUCCH resource that UE <NUM> should use in transmitting HARQ feedback <NUM> over PUCCH <NUM> to eNB <NUM>. However, the value-to-parameter mapping illustrated in Table <NUM> may enable eNB <NUM> to select a PUCCH resource for use with PUCCH format <NUM> from among three candidate values rather than two. According to the value-to-parameter mapping illustrated in Table <NUM>, eNB <NUM> may set HFCI field <NUM> to '<NUM>' to indicate a first PUCCH format and a first PUCCH resource, may set HFCI field <NUM> to '<NUM>' to indicate a second PUCCH format and the first PUCCH resource, may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format and a second PUCCH resource, or may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format and a third PUCCH resource.

In some embodiments, respective corresponding HARQ feedback payload sizes may be predefined or configured by higher-layer signaling for the first and second PUCCH formats in conjunction with the use of a two-bit HFCI field <NUM> according to the value-to-parameter mapping of Table <NUM> or Table <NUM>. In various embodiments, for example, a <NUM>-bit HARQ feedback payload size may be predefined for the first PUCCH format and a <NUM>-bit HARQ feedback payload size may be predefined for the second PUCCH format. In some embodiments, the first PUCCH format may comprise PUCCH format <NUM> and the second PUCCH format may comprise an enhanced PUCCH format designed to accommodate larger HARQ feedback payloads. In various embodiments, the second PUCCH format may comprise a physical uplink shared channel (PUSCH)-based PUCCH format.

Table <NUM> illustrates a third example of a value-to-parameter mapping that may be defined in some embodiments for a two-bit HFCI field <NUM>. According to the value-to-parameter mapping illustrated in Table <NUM>, eNB <NUM> may use HFCI field <NUM> to indicate a PUCCH format and either a PUCCH resource or a HARQ feedback payload size. Namely, eNB <NUM> may set HFCI field <NUM> to '<NUM>' to indicate a first PUCCH format and a first PUCCH resource, may set HFCI field <NUM> to '<NUM>' to indicate the first PUCCH format and a second PUCCH resource, may set HFCI field <NUM> to '<NUM>' to indicate a second PUCCH format and a first HARQ feedback payload size, and may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format and a second HARQ feedback payload size.

In various embodiments, the first PUCCH format corresponding to respective HFCI field <NUM> values of '<NUM>' and '<NUM>' according to the value-to-parameter mapping of Table <NUM> may comprise PUCCH format <NUM>. In some embodiments, the second PUCCH format corresponding to respective HFCI field <NUM> values of '<NUM>' and '<NUM>' according to the value-to-parameter mapping of Table <NUM> may comprise an enhanced PUCCH format designed to accommodate larger HARQ feedback payloads. In various such embodiments, the first and second HARQ feedback payload sizes corresponding to respective HFCI field <NUM> values of '<NUM>' and '<NUM>' according to the value-to-parameter mapping of Table <NUM> may both be comprised among a set of HARQ feedback payload sizes designated for use in conjunction with the enhanced PUCCH format. In some embodiments, for example, the first and second HARQ feedback payload size may comprise two different numbers of bits comprised among the set {<NUM> bits, <NUM> bits, <NUM> bits}. In various embodiments, HARQ feedback payload sizes to which HFCI field <NUM> values of '<NUM>' and '<NUM>' may be used to refer may be defined to differ between TDD environments and FDD environments. In an example embodiment, in the context of a TDD PUCCH, HFCI field <NUM> values of '<NUM>' and '<NUM>' may indicate <NUM>-bit and <NUM>-bit HARQ feedback payload sizes, respectively. In the same example embodiment, in the context of an FDD PUCCH, HFCI field <NUM> values of '<NUM>' and '<NUM>' may indicate <NUM>-bit and <NUM>-bit HARQ feedback payload sizes, respectively. The embodiments are not limited to this example.

Table <NUM> illustrates a fourth example of a value-to-parameter mapping that may be defined in some embodiments for a two-bit HFCI field <NUM>. Like the mapping illustrated in Table <NUM>, the mapping illustrated in Table <NUM> may enable eNB <NUM> to use HFCI field <NUM> to indicate a PUCCH format and either a PUCCH resource or a HARQ feedback payload size. However, the value-to-parameter mapping illustrated in Table <NUM> may enable eNB <NUM> to select a HARQ feedback payload size for use with PUCCH format <NUM> from among three candidate sizes rather than two. According to the mapping illustrated in Table <NUM>, eNB <NUM> may set HFCI field <NUM> to '<NUM>' to indicate a first PUCCH format and a first PUCCH resource, may set HFCI field <NUM> to '<NUM>' to indicate a second PUCCH format and a first HARQ feedback payload size, may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format and a second HARQ feedback payload size, and may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format and a third HARQ feedback payload size.

In various embodiments, in conjunction with the use of a two-bit HFCI field <NUM> according to the value-to-parameter mapping of Table <NUM> or Table <NUM>, a particular HARQ feedback payload size to be used in combination with the first PUCCH format may be predefined or configured by higher-layer signaling. For example, in some embodiments, a HARQ feedback payload size of <NUM> bits may be predefined or configured by higher-layer signaling for use with the first PUCCH format, which may comprise PUCCH format <NUM>. In various embodiments, in conjunction with the use of a two-bit HFCI field <NUM> according to the value-to-parameter mapping of Table <NUM> or Table <NUM>, a particular PUCCH resource to be used in combination with the second PUCCH format may be predefined or configured by higher-layer signaling.

Table <NUM> illustrates a fifth example of a value-to-parameter mapping that may be defined in some embodiments for a two-bit HFCI field <NUM>. According to the value-to-parameter mapping illustrated in Table <NUM>, eNB <NUM> may use HFCI field <NUM> to indicate a PUCCH format and one or both of a PUCCH resource and a HARQ feedback payload size. Namely, eNB <NUM> may set HFCI field <NUM> to '<NUM>' to indicate a first PUCCH format and a first PUCCH resource, may set HFCI field <NUM> to '<NUM>' to indicate a second PUCCH format, the first PUCCH resource, and a first HARQ feedback payload size, may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format, a second PUCCH resource, and the first HARQ feedback payload size, or may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format and a second HARQ feedback payload size.

In various embodiments, in conjunction with the use of a two-bit HFCI field <NUM> according to the value-to-parameter mapping of Table <NUM>, a particular HARQ feedback payload size to be used in combination with the first PUCCH format and the first PUCCH resource may be predefined or configured by higher-layer signaling. In some embodiments, in conjunction with the use of a two-bit HFCI field <NUM> according to the value-to-parameter mapping of Table <NUM>, a particular PUCCH resource to be used in combination with the second PUCCH format and the second HARQ feedback payload size may be predefined or configured by higher-layer signaling.

Table <NUM> illustrates a sixth example of a value-to-parameter mapping that may be defined in various embodiments for a two-bit HFCI field <NUM>. According to the value-to-parameter mapping illustrated in Table <NUM>, eNB <NUM> may use HFCI field <NUM> to indicate a PUCCH format and a PUCCH resource, and possibly a HARQ feedback payload size as well. Namely, eNB <NUM> may set HFCI field <NUM> to '<NUM>' to indicate a first PUCCH format and a first PUCCH resource, may set HFCI field <NUM> to '<NUM>' to indicate a second PUCCH format, the first PUCCH resource, and a first HARQ feedback payload size, may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format, a second PUCCH resource, and a second HARQ feedback payload size, or may set HFCI field <NUM> to '<NUM>' to indicate the second PUCCH format, a third PUCCH resource, and a third HARQ feedback payload size. In some embodiments, in conjunction with the use of a two-bit HFCI field <NUM> according to the value-to-parameter mapping of Table <NUM>, a particular HARQ feedback payload size to be used in combination with the first PUCCH format and the first PUCCH resource may be predefined or configured by higher-layer signaling.

It is to be appreciated that although Tables <NUM> to <NUM> illustrate various examples of value-to-parameter mappings that may be defined for an HFCI field <NUM> comprising two bits, an HFCI field <NUM> comprising more than two bits may be implemented in various embodiments. Table <NUM> illustrates an example of a value-to-parameter mapping that may be defined in some embodiments for an X-bit HFCI field <NUM>, where X > <NUM>.

According to the value-to-parameter mapping illustrated in Table <NUM>, eNB <NUM> may use an X-bit HFCI field <NUM> to indicate a value of a parameter W. More particularly, in this example, eNB <NUM> may use the X-bit HFCI field <NUM> to identify an integer in the inclusive range [<NUM>, <NUM>X] as the value of W. In various embodiments, following receipt of DL scheduling command <NUM>, UE <NUM> may identify the value of W based on the contents of HFCI field <NUM> and may then identify - based on the value of W - a HARQ feedback payload size to be used in transmitting HARQ feedback <NUM> over PUCCH <NUM> to eNB <NUM>. In some such embodiments, UE <NUM> may use W to identify such a HARQ feedback payload size OACK according to Equation (<NUM>) as follows: <MAT> where U denotes a total number of PDSCH transmissions and PDCCH downlink SPS release indications received during a HARQ feedback bundling window. In various embodiments, based on an OACK value determined in such fashion, UE <NUM> may determine one or both of a PUCCH format and a PUCCH resource for use in transmitting HARQ feedback <NUM> over PUCCH <NUM> to eNB <NUM>. In some embodiments, for example, UE <NUM> may transmit HARQ feedback <NUM> using a first PUCCH format and a corresponding first PUCCH resource if OACK ≤ <NUM>, and may transmit HARQ feedback <NUM> using a second PUCCH format and a corresponding second PUCCH resource if OACK > <NUM>. In various such embodiments, the first PUCCH format may comprise PUCCH format <NUM>, and the second PUCCH format may comprise an enhanced PUCCH format designed to accommodate larger HARQ feedback payloads.

Table <NUM> illustrates a more generalized form of a value-to-parameter mapping that may be defined in some embodiments for X-bit HFCI field <NUM>. According to the value-to-parameter mapping illustrated in Table <NUM>, each of <NUM>X-<NUM> possible values of d - where d represents a decimal value of a bit string of X bits contained in HFCI field <NUM> - is defined to indicate a particular respective set of HARQ feedback configuration parameters {Fd, OACKd, Rd}. For any given value of d, Fd may comprise a PUCCH format indicated by that value of d, OACKd may comprise a HARQ feedback payload size indicated by that value of d, and Rd may comprise a PUCCH resource indicated by that value of d.

It is to be appreciated that in various embodiments, some or all of these three parameters may be the same for multiple given values of d. Table <NUM> illustrates an example of such an embodiment. In the example illustrated in Table <NUM>, HFCI field <NUM> comprises <NUM> bits, and thus X is equal to three. F<NUM> and F<NUM> both correspond to PUCCH format <NUM>, while F<NUM> to F<NUM> all correspond to an enhanced PUCCH format designed to accommodate larger HARQ feedback payloads. OACK<NUM> and OACK<NUM> both correspond to a <NUM>-bit HARQ feedback payload size, OACK<NUM>, OACK<NUM>, and OACK<NUM> each correspond to a <NUM>-bit HARQ feedback payload size, and OACK<NUM>, OACK<NUM>, and OACK<NUM> each correspond to a <NUM>-bit HARQ feedback payload size. R<NUM>, R<NUM>, and R<NUM> each correspond to a first PUCCH resource, R<NUM>, R<NUM>, and R<NUM> each correspond to a second PUCCH resource, and R<NUM> and R<NUM> both correspond to a third PUCCH resource. The embodiments are not limited to this example.

In some embodiments, a conventional field within DL scheduling command <NUM> may be repurposed for use as HFCI field <NUM>. In various embodiments, for example a <NUM>-bit TPC field in DL scheduling command <NUM> may be used as a <NUM>-bit HFCI field <NUM>. In some such embodiments, such repurposing of TPC fields as <NUM>-bit HFCI fields may be limited to TPC fields comprised in PDCCH assignments with DAI values greater than '<NUM>' or DAI values equal to '<NUM>' that are not the first PDCCH transmissions on the primary cell and TPC fields comprised in DCI of the corresponding PDCCH detected on the secondary cell.

In various embodiments, rather than being repurposed for use as HFCI field <NUM>, a conventional field within DL scheduling command <NUM> may be repurposed for use in combination with HFCI field <NUM> in conjunction with the indication of one or more HARQ feedback configuration parameters. For example, in some embodiments, the collective set of bits comprised in HFCI field <NUM> and a TPC field may indicate one or more of a PUCCH format, a PUCCH resource, and a HARQ feedback payload size. In various embodiments, the repurposed field may be used to independently specify one or more HARQ feedback configuration parameters. For example, in some embodiments, the TPC field may be used to indicate a PUCCH format, and HFCI field <NUM> may be used to indicate a PUCCH resource and a HARQ feedback payload size. In various other embodiments, HFCI field <NUM> and the repurposed field may be used to provide bits to be combined to obtain a bit string that maps to a particular set of HARQ feedback configuration parameters. For example, in some embodiments, UE <NUM> may obtain a bit string by concatenation the bits in HFCI field <NUM> with the bits in the TPC field, and may determine a set of HARQ feedback configuration parameters according to a value-to-parameter mapping of the general form illustrated in Table <NUM>.

In various embodiments, UE <NUM> may generate HARQ feedback <NUM> according to a HARQ feedback generation process that implements a cell-group-based approach to HARQ feedback payload size adaptation. In some embodiments, according to such an approach, the various configured DL component carriers may be divided into multiple HARQ feedback cell groups (CGs). In various such embodiments, the number of CGs may be an integer power of <NUM> and/or each CG may comprise a same number of component carriers. In some embodiments, each CG may be assigned a unique CG identifier (ID). In various embodiments, HFCI field <NUM> may comprise a bitmap that includes, for each of the multiple CGs, a respective bit that indicates whether a PDSCH transmission or SPS release is scheduled on at least one DL component carrier of that CG during the HARQ feedback bundling window. In some embodiments, UE <NUM> may determine a HARQ feedback payload size based on such a bitmap comprised in HFCI field <NUM>.

In various embodiments, for each CG for which a PDSCH transmission or SPS release is scheduled on at least one DL component carrier during the HARQ feedback bundling window, UE <NUM> may generate a pre-defined number of HARQ feedback bits. In some embodiments, if the component carriers correspond to FDD cells, UE <NUM> may a number of HARQ feedback bits equal to the number of component carriers comprised in the CG. In various embodiments, if the component carriers correspond to TDD cells, UE <NUM> may generate a number of HARQ feedback bits equal to the total number of subframes comprised within the HARQ feedback bundling window. In some embodiments, UE <NUM> may refrain from generating HARQ feedback bits for any CG with respect to which neither a PDSCH transmission nor an SPS release is scheduled on any component carrier during the HARQ feedback bundling window.

<FIG> illustrates an example of a HARQ feedback generation process <NUM> that may be representative of a CG-based HARQ feedback generation process. In various embodiments, UE <NUM> may perform the HARQ feedback generation process illustrated in <FIG> in response to receipt of a DL scheduling command <NUM> in which HFCI field <NUM> contains the bitmap '<NUM>'. In some embodiments, based on such a bitmap, UE <NUM> may determine that HARQ feedback bits are to be generated for CGs <NUM>, <NUM>, and <NUM>, but not for CG <NUM>. Each of CGs <NUM>, <NUM>, <NUM>, and <NUM> comprises four respective component carriers. In this example, these various component carriers may correspond to FDD cells, and thus UE <NUM> may generate four respective HARQ feedback bits for each of CGs <NUM>, <NUM>, and <NUM>, and assemble those various HARQ feedback bits into a <NUM>-bit HARQ feedback bit sequence <NUM>. In various embodiments, UE <NUM> may select a PUCCH format for use in transmission of HARQ feedback <NUM> based on the size of HARQ feedback bit sequence <NUM>. In some embodiments, if the DAI field exists, the HARQ feedback payload can be further compressed according to the value of the DAI field with respect to each CG for which HARQ feedback bits are generated.

In various embodiments, in conjunction with any of the various aforementioned approaches, UE <NUM> may be configured to autonomously select and use PUCCH format 1a/1b and a corresponding PUCCH resource to transmit HARQ feedback <NUM> under certain circumstances. In some embodiments, for example, UE <NUM> may be configured to autonomously select and use PUCCH format 1a/1b and a corresponding PUCCH resource when received DCI indicates only a PDSCH transmission or SPS release in the primary cell during the HARQ-ACK bundling window. In various such embodiments, the corresponding PUCCH resource may be determined according to the lowest control channel element (CCE) index used to construct the PDCCH. In some embodiments, UE <NUM> may be configured to autonomously select and use PUCCH format 1a/1b and a corresponding PUCCH resource to transmit HARQ feedback for a primary cell PDSCH transmission during a subframe of the HARQ feedback bundling window for which no corresponding PDCCH/EPDCCH transmission is detected within that subframe. In various such embodiments, UE <NUM> may select the corresponding PUCCH resource from among four PUCCH resource values configured by higher layers, based on the value comprised in a TPC command for PUCCH field in DCI used to indicate a semi-persistent DL scheduling activation.

Operations for the above embodiments may be further described with reference to the following figures and accompanying examples. Some of the figures may include a logic flow. Although such figures presented herein may include a particular logic flow, it can be appreciated that the logic flow merely provides an example of how the general functionality as described herein can be implemented. Further, the given logic flow does not necessarily have to be executed in the order presented unless otherwise indicated. In addition, the given logic flow may be implemented by a hardware element, a software element executed by a processor, or any combination thereof.

<FIG> illustrates an example of a logic flow <NUM> that may be representative of the implementation of one or more of the disclosed HARQ feedback configuration techniques according to various embodiments. For example, logic flow <NUM> may be representative of operations that may be performed in some embodiments by UE <NUM> in operating environment <NUM> of <FIG> or operating environment <NUM> of <FIG>. As shown in <FIG>, a DL scheduling command may be received at <NUM> that comprises HARQ feedback configuration information. For example, UE <NUM> may receive a DL scheduling command <NUM> from eNB <NUM>, and the DL scheduling command <NUM> may comprise an HFCI field <NUM> or HFCI field <NUM> containing HARQ feedback configuration information. At <NUM>, a HARQ feedback bundling window associated with the DL scheduling command may be identified. For example, UE <NUM> may identify a HARQ feedback bundling window associated with DL scheduling command <NUM>.

At <NUM>, one or more HARQ feedback configuration parameters for the HARQ feedback bundling window may be identified based on the HARQ feedback configuration information. For example, HARQ feedback <NUM> may comprise HARQ feedback for a HARQ feedback bundling window, and UE <NUM> may identify one or more of a PUCCH format to be used for transmission of HARQ feedback <NUM>, a PUCCH resource for use in transmission of HARQ feedback <NUM>, and a HARQ feedback payload size for HARQ feedback <NUM> based on HARQ feedback configuration information comprised in HFCI field <NUM> or HFCI field <NUM>. At <NUM>, HARQ feedback for the HARQ feedback bundling window may be generated for transmission to an eNB in accordance with the one or more identified HARQ feedback configuration parameters. For example, UE <NUM> may generate HARQ feedback <NUM> for transmission to eNB <NUM> in accordance with the one or more HARQ feedback configuration parameters identified at <NUM>. The embodiments are not limited to these examples.

<FIG> illustrates an example of a logic flow <NUM> that may be representative of the implementation of one or more of the disclosed HARQ feedback configuration techniques according to various embodiments. For example, logic flow <NUM> may be representative of operations that may be performed in some embodiments by eNB <NUM> in operating environment <NUM> of <FIG> or operating environment <NUM> of <FIG>. As shown in <FIG>, a HARQ feedback bundling window for which HARQ feedback is to be received from a UE may be identified at <NUM>. For example, eNB <NUM> may identify a HARQ feedback bundling window for which it is to receive HARQ feedback <NUM> from UE <NUM>. At <NUM>, one or more HARQ feedback configuration parameters for the HARQ feedback may be determined. For example, eNB <NUM> may determine one or more of a PUCCH format to be used by UE <NUM> for transmission of HARQ feedback <NUM>, a PUCCH resource to be used by UE <NUM> in transmission of HARQ feedback <NUM>, and a HARQ feedback payload size to be used by UE <NUM> for HARQ feedback <NUM>.

At <NUM>, a DL data transmission to the UE that is scheduled for a subframe in the HARQ feedback bundling window may be identified. For example, eNB <NUM> may identify a DL transmission of data <NUM> to UE <NUM> that is scheduled for a subframe comprised in the HARQ feedback bundling window. At <NUM>, downlink control information may be generated for transmission to the UE to indicate the scheduling of the DL data transmission, and the downlink control information may comprise HARQ feedback configuration information to indicate at least one of the one or more HARQ feedback configuration parameters determined at <NUM>. For example, eNB <NUM> may generate a DL scheduling command <NUM> for transmission to UE <NUM> to indicate the scheduling of the DL transmission of data <NUM> to UE <NUM> during the subframe comprised in the HARQ feedback bundling window, and DL scheduling command <NUM> may comprise an HFCI field <NUM> or HFCI field <NUM> containing HARQ feedback configuration information that indicates one or more of a PUCCH format to be used by UE <NUM> for transmission of HARQ feedback <NUM>, a PUCCH resource to be used by UE <NUM> in transmission of HARQ feedback <NUM>, and a HARQ feedback payload size to be used by UE <NUM> for HARQ feedback <NUM>. The embodiments are not limited to these examples.

<FIG> illustrates an embodiment of a storage medium <NUM> and an embodiment of a storage medium <NUM>. Storage media <NUM> and <NUM> may comprise any non-transitory computer-readable storage media or machine-readable storage media, such as an optical, magnetic or semiconductor storage media. In various embodiments, storage media <NUM> and <NUM> may comprise an article of manufacture. In some embodiments, storage media <NUM> and <NUM> may store computer-executable instructions, such as computer-executable instructions to implement logic flow <NUM> of <FIG> and logic flow <NUM> of <FIG>, respectively. Examples of a computer-readable storage medium or machine-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer-executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.

Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software.

<FIG> illustrates an example of a UE device <NUM> that may be representative of a UE that implements one or more of the disclosed techniques in various embodiments. For example, UE device <NUM> may be representative of UE <NUM> according to some embodiments. In some embodiments, the UE device <NUM> may include application circuitry <NUM>, baseband circuitry <NUM>, Radio Frequency (RF) circuitry <NUM>, front-end module (FEM) circuitry <NUM> and one or more antennas <NUM>, coupled together at least as shown.

The baseband circuitry <NUM> may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry <NUM> and to generate baseband signals for a transmit signal path of the RF circuitry <NUM>. Baseband processing circuity <NUM> may interface with the application circuitry <NUM> for generation and processing of the baseband signals and for controlling operations of the RF circuitry <NUM>. For example, in some embodiments, the baseband circuitry <NUM> may include a second generation (<NUM>) baseband processor 904a, third generation (<NUM>) baseband processor 904b, fourth generation (<NUM>) baseband processor 904c, and/or other baseband processor(s) 904d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (<NUM>), <NUM>, etc.). The baseband circuitry <NUM> (e.g., one or more of baseband processors 904a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry <NUM>. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry <NUM> may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry <NUM> may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry <NUM> may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and/or radio resource control (RRC) elements. A central processing unit (CPU) 904e of the baseband circuitry <NUM> may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 904f. The audio DSP(s) 904f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry <NUM> and the application circuitry <NUM> may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the RF circuitry <NUM> may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry <NUM> may include mixer circuitry 906a, amplifier circuitry 906b and filter circuitry 906c. The transmit signal path of the RF circuitry <NUM> may include filter circuitry 906c and mixer circuitry 906a. RF circuitry <NUM> may also include synthesizer circuitry 906d for synthesizing a frequency for use by the mixer circuitry 906a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 906a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry <NUM> based on the synthesized frequency provided by synthesizer circuitry 906d. The amplifier circuitry 906b may be configured to amplify the down-converted signals and the filter circuitry 906c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry <NUM> for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 906a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 906a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 906d to generate RF output signals for the FEM circuitry <NUM>. The baseband signals may be provided by the baseband circuitry <NUM> and may be filtered by filter circuitry 906c. The filter circuitry 906c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 906a of the receive signal path and the mixer circuitry 906a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion respectively. In some embodiments, the mixer circuitry 906a of the receive signal path and the mixer circuitry 906a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 906a of the receive signal path and the mixer circuitry 906a may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 906a of the receive signal path and the mixer circuitry 906a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the synthesizer circuitry 906d may be a fractional-N synthesizer or a fractional N/N+<NUM> synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 906d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 906d may be configured to synthesize an output frequency for use by the mixer circuitry 906a of the RF circuitry <NUM> based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 906d may be a fractional N/N+<NUM> synthesizer.

Synthesizer circuitry 906d of the RF circuitry <NUM> may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+<NUM> (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 906d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry <NUM> may include an IQ/polar converter.

In some embodiments, the UE device <NUM> may include additional elements such as, for example, memory/storage, display, camera, sensor, and/or input/output (I/O) interface.

<FIG> illustrates an embodiment of a communications device <NUM> that may implement one or more of eNB <NUM>, UE <NUM>, logic flow <NUM>, logic flow <NUM>, storage medium <NUM>, storage medium <NUM>, and UE <NUM>. In various embodiments, device <NUM> may comprise a logic circuit <NUM>. The logic circuit <NUM> may include physical circuits to perform operations described for one or more of eNB <NUM>, UE <NUM>, logic flow <NUM>, logic flow <NUM>, and UE <NUM> of <FIG> for example. As shown in <FIG>, device <NUM> may include a radio interface <NUM>, baseband circuitry <NUM>, and computing platform <NUM>, although the embodiments are not limited to this configuration.

The device <NUM> may implement some or all of the structure and/or operations for one or more of eNB <NUM>, UE <NUM>, logic flow <NUM>, logic flow <NUM>, storage medium <NUM>, storage medium <NUM>, UE <NUM>, and logic circuit <NUM> in a single computing entity, such as entirely within a single device. Alternatively, the device <NUM> may distribute portions of the structure and/or operations for one or more of eNB <NUM>, UE <NUM>, logic flow <NUM>, logic flow <NUM>, storage medium <NUM>, storage medium <NUM>, UE <NUM>, and logic circuit <NUM> across multiple computing entities using a distributed system architecture, such as a client-server architecture, a <NUM>-tier architecture, an N-tier architecture, a tightly-coupled or clustered architecture, a peer-to-peer architecture, a master-slave architecture, a shared database architecture, and other types of distributed systems.

In one embodiment, radio interface <NUM> may include a component or combination of components adapted for transmitting and/or receiving single-carrier or multi-carrier modulated signals (e.g., including complementary code keying (CCK), orthogonal frequency division multiplexing (OFDM), and/or single-carrier frequency division multiple access (SC-FDMA) symbols) although the embodiments are not limited to any specific over-the-air interface or modulation scheme. Radio interface <NUM> may include, for example, a receiver <NUM>, a frequency synthesizer <NUM>, and/or a transmitter <NUM>. Radio interface <NUM> may include bias controls, a crystal oscillator and/or one or more antennas <NUM>-f. In another embodiment, radio interface <NUM> may use external voltage-controlled oscillators (VCOs), surface acoustic wave filters, intermediate frequency (IF) filters and/or RF filters, as desired. Due to the variety of potential RF interface designs an expansive description thereof is omitted.

Baseband circuitry <NUM> may communicate with radio interface <NUM> to process receive and/or transmit signals and may include, for example, a mixer for down-converting received RF signals, an analog-to-digital converter <NUM> for converting analog signals to digital form, a digital-to-analog converter <NUM> for converting digital signals to analog form, and a mixer for up-converting signals for transmission. Further, baseband circuitry <NUM> may include a baseband or physical layer (PHY) processing circuit <NUM> for PHY link layer processing of respective receive/transmit signals. Baseband circuitry <NUM> may include, for example, a medium access control (MAC) processing circuit <NUM> for MAC/data link layer processing. Baseband circuitry <NUM> may include a memory controller <NUM> for communicating with MAC processing circuit <NUM> and/or a computing platform <NUM>, for example, via one or more interfaces <NUM>.

In some embodiments, PHY processing circuit <NUM> may include a frame construction and/or detection module, in combination with additional circuitry such as a buffer memory, to construct and/or deconstruct communication frames. Alternatively or in addition, MAC processing circuit <NUM> may share processing for certain of these functions or perform these processes independent of PHY processing circuit <NUM>. In some embodiments, MAC and PHY processing may be integrated into a single circuit.

The computing platform <NUM> may provide computing functionality for the device <NUM>. As shown, the computing platform <NUM> may include a processing component <NUM>. In addition to, or alternatively of, the baseband circuitry <NUM>, the device <NUM> may execute processing operations or logic for one or more of eNB <NUM>, UE <NUM>, logic flow <NUM>, logic flow <NUM>, storage medium <NUM>, storage medium <NUM>, UE <NUM>, and logic circuit <NUM> using the processing component <NUM>. The processing component <NUM> (and/or PHY <NUM> and/or MAC <NUM>) may comprise various hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processor circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.

The computing platform <NUM> may further include other platform components <NUM>. Other platform components <NUM> include common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components (e.g., digital displays), power supplies, and so forth. Examples of memory units may include without limitation various types of computer readable and machine readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information.

Device <NUM> may be, for example, an ultra-mobile device, a mobile device, a fixed device, a machine-to-machine (M2M) device, a personal digital assistant (PDA), a mobile computing device, a smart phone, a telephone, a digital telephone, a cellular telephone, user equipment, eBook readers, a handset, a one-way pager, a two-way pager, a messaging device, a computer, a personal computer (PC), a desktop computer, a laptop computer, a notebook computer, a netbook computer, a handheld computer, a tablet computer, a server, a server array or server farm, a web server, a network server, an Internet server, a work station, a mini-computer, a main frame computer, a supercomputer, a network appliance, a web appliance, a distributed computing system, multiprocessor systems, processor-based systems, consumer electronics, programmable consumer electronics, game devices, display, television, digital television, set top box, wireless access point, base station, node B, subscriber station, mobile subscriber center, radio network controller, router, hub, gateway, bridge, switch, machine, or combination thereof. Accordingly, functions and/or specific configurations of device <NUM> described herein, may be included or omitted in various embodiments of device <NUM>, as suitably desired.

Embodiments of device <NUM> may be implemented using single input single output (SISO) architectures. However, certain implementations may include multiple antennas (e.g., antennas <NUM>-f) for transmission and/or reception using adaptive antenna techniques for beamforming or spatial division multiple access (SDMA) and/or using MIMO communication techniques.

The components and features of device <NUM> may be implemented using any combination of discrete circuitry, application specific integrated circuits (ASICs), logic gates and/or single chip architectures. Further, the features of device <NUM> may be implemented using microcontrollers, programmable logic arrays and/or microprocessors or any combination of the foregoing where suitably appropriate. It is noted that hardware, firmware and/or software elements may be collectively or individually referred to herein as "logic" or "circuit.

It should be appreciated that the exemplary device <NUM> shown in the block diagram of <FIG> may represent one functionally descriptive example of many potential implementations. Accordingly, division, omission or inclusion of block functions depicted in the accompanying figures does not infer that the hardware components, circuits, software and/or elements for implementing these functions would be necessarily be divided, omitted, or included in embodiments.

<FIG> illustrates an embodiment of a broadband wireless access system <NUM>. As shown in <FIG>, broadband wireless access system <NUM> may be an internet protocol (IP) type network comprising an internet <NUM> type network or the like that is capable of supporting mobile wireless access and/or fixed wireless access to internet <NUM>. In one or more embodiments, broadband wireless access system <NUM> may comprise any type of orthogonal frequency division multiple access (OFDMA)-based or single-carrier frequency division multiple access (SC-FDMA)-based wireless network, such as a system compliant with one or more of the 3GPP LTE Specifications and/or IEEE <NUM> Standards, and the scope of the claimed subject matter is not limited in these respects.

In the exemplary broadband wireless access system <NUM>, radio access networks (RANs) <NUM> and <NUM> are capable of coupling with evolved node Bs (eNBs) <NUM> and <NUM>, respectively, to provide wireless communication between one or more fixed devices <NUM> and internet <NUM> and/or between or one or more mobile devices <NUM> and Internet <NUM>. One example of a fixed device <NUM> and a mobile device <NUM> is device <NUM> of <FIG>, with the fixed device <NUM> comprising a stationary version of device <NUM> and the mobile device <NUM> comprising a mobile version of device <NUM>. RANs <NUM> and <NUM> may implement profiles that are capable of defining the mapping of network functions to one or more physical entities on broadband wireless access system <NUM>. eNBs <NUM> and <NUM> may comprise radio equipment to provide RF communication with fixed device <NUM> and/or mobile device <NUM>, such as described with reference to device <NUM>, and may comprise, for example, the PHY and MAC layer equipment in compliance with a 3GPP LTE Specification or an IEEE <NUM> Standard. eNBs <NUM> and <NUM> may further comprise an IP backplane to couple to Internet <NUM> via RANs <NUM> and <NUM>, respectively, although the scope of the claimed subject matter is not limited in these respects.

Broadband wireless access system <NUM> may further comprise a visited core network (CN) <NUM> and/or a home CN <NUM>, each of which may be capable of providing one or more network functions including but not limited to proxy and/or relay type functions, for example authentication, authorization and accounting (AAA) functions, dynamic host configuration protocol (DHCP) functions, or domain name service controls or the like, domain gateways such as public switched telephone network (PSTN) gateways or voice over internet protocol (VoIP) gateways, and/or internet protocol (IP) type server functions, or the like. However, these are merely example of the types of functions that are capable of being provided by visited CN <NUM> and/or home CN <NUM>, and the scope of the claimed subject matter is not limited in these respects. Visited CN <NUM> may be referred to as a visited CN in the case where visited CN <NUM> is not part of the regular service provider of fixed device <NUM> or mobile device <NUM>, for example where fixed device <NUM> or mobile device <NUM> is roaming away from its respective home CN <NUM>, or where broadband wireless access system <NUM> is part of the regular service provider of fixed device <NUM> or mobile device <NUM> but where broadband wireless access system <NUM> may be in another location or state that is not the main or home location of fixed device <NUM> or mobile device <NUM>.

Fixed device <NUM> may be located anywhere within range of one or both of eNBs <NUM> and <NUM>, such as in or near a home or business to provide home or business customer broadband access to Internet <NUM> via eNBs <NUM> and <NUM> and RANs <NUM> and <NUM>, respectively, and home CN <NUM>. It is worthy of note that although fixed device <NUM> is generally disposed in a stationary location, it may be moved to different locations as needed. Mobile device <NUM> may be utilized at one or more locations if mobile device <NUM> is within range of one or both of eNBs <NUM> and <NUM>, for example. In accordance with one or more embodiments, operation support system (OSS) <NUM> may be part of broadband wireless access system <NUM> to provide management functions for broadband wireless access system <NUM> and to provide interfaces between functional entities of broadband wireless access system <NUM>. Broadband wireless access system <NUM> of <FIG> is merely one type of wireless network showing a certain number of the components of broadband wireless access system <NUM>, and the scope of the claimed subject matter is not limited in these respects.

Some embodiments may be implemented, for example, using a machine-readable medium or article which may store an instruction or a set of instructions that, if executed by a machine, may cause the machine to perform a method and/or operations in accordance with the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and/or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and/or storage unit, for example, memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD), a tape, a cassette, or the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate preferred embodiment. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein," respectively. Moreover, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

Claim 1:
An apparatus, comprising:
a memory; and
logic for user equipment (<NUM>), UE, at least a portion of the logic implemented in baseband circuitry coupled to the memory, the logic to:
identify a two-bit feedback configuration information, HFCI, field (<NUM>) contained in downlink control information, DCI, received from an evolved node B, eNB, (<NUM>),
the two-bit HFCI field indicating a physical uplink control channel, PUCCH, format, a PUCCH resource (<NUM>), and a hybrid automatic repeat request, HARQ, feedback (<NUM>) payload size for a HARQ feedback;
determine a number of bits of HARQ feedback from the HARQ feedback payload size to be included in control information to be provided to an evolved node B (<NUM>), eNB;
determine whether a PUCCH format <NUM> can accommodate the number of bits of HARQ feedback (<NUM>); and
in response to a determination that the PUCCH format <NUM> cannot accommodate the number of bits of HARQ feedback:
generate the control information according to a second PUCCH format; and
send the control information to radio frequency, RF, circuitry (<NUM>) for transmission to the eNB (<NUM>) via the PUCCH resource identified based on the two-bit HFCI field.