Patent Description:
Examples of such multiple-access systems include fourth generation (<NUM>) systems such as a Long Term Evolution (LTE) systems or LTE-Advanced (LTE-A) systems, and fifth generation (<NUM>) systems which may be referred to as New Radio (NR) systems. These systems may employ technologies such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), or discrete Fourier transform-spread-orthogonal frequency division multiplexing (DFT-S-OFDM).

Certain wireless communications systems may include machine type communication (MTC) devices (e.g., UEs) communicating in designated radio frequency bands. For example, an MTC device may include communications from devices that integrate sensors or meters to measure or capture information and relay that information to a central server or application program that can make use of the information or present the information to humans interacting with the program or application. Certain radio frequency bands, however, may be configured such that any devices communicating in the radio frequency bands must meet various communication configuration protocols (e.g., maximum transmit power, power spectral density (PSD) requirements, bandwidth constraints, and the like). While many uplink and/or downlink channel communications may satisfy these protocols, other types of communications (e.g., PUCCH communications for MTC (or eMTC) devices) may need to be designed to comply with the protocols for a particular radio frequency band. <CIT> provides a method by which a terminal measures channel state information (CSI), a method by which a terminal transmits CSI, and devices for supporting the methods. A method by which a terminal feeds back CSI in a wireless access system, according to this document, can comprise the steps of: receiving an upper layer signal including a channel quality indicator (CQI) index; receiving a physical downlink control channel (PDCCH) signal including an aperiodic CSI request field; receiving a physical downlink shared channel (PDSCH) signal that is repeatedly transmitted as many time as the number indicated by the CQI index; measuring the CSI for a CSI reference resource; and feeding back the measured CSI by using a physical uplink shared channel (PUSCH) signal.

3GPP TS <NUM>, V <NUM>. <NUM> is a part of the LTE standard, release <NUM>, concerning physical channels and modulation. Section <NUM> concerns the physical uplink control channel (PUCCH). According to table <NUM>-<NUM> there can be different PUCCH formats, having varying numbers of bits. In particular, the parameter MPUCCH4RB represents the bandwidth of the PUCCH format <NUM>.

Preferred embodiments of the invention are stipulated in the dependent claims. While several embodiments and/or examples have been disclosed in the description, the subject matter for which protection is sought is limited to those examples and/or embodiments which are encompassed by the scope of the appended claims. Embodiments and/or examples that do not fall under the scope of the claims are useful for understanding the invention. The described techniques relate to improved methods, systems, devices, or apparatuses that for physical uplink control signaling for enhanced machine type communications (eMTC) in a shared or unlicensed spectrum (eMTC-U). Generally, the described techniques provide for eMTC-U PUCCH design that supports communications in certain radio frequency bands (e.g., such as the <NUM> industrial, scientific, and medical (ISM) bands). For example, the described techniques may support an eMTC-U PUCCH design that complies with bandwidth, transmit power, etc., requirements associated with communicating in the radio frequency band. For example, a base station may independently or in conjunction with a network device provide an indication of the machine type communication (MTC) PUCCH message configuration to a user equipment (UE). The base station selects the payload size configuration to be used by the UE (and other UEs communicating with the base station). In some aspects, the payload size configuration may indicate either directly or indirectly (e.g., by design) that amount of data that the UE(s) may transmit in the MTC PUCCH message. The payload size configuration designs the MTC PUCCH message to be transmitted over multiple resource blocks (RBs). The base station transmits the payload size configuration to the UE(s) in a configuration message and the UE(s) uses the payload size configuration to generate an MTC PUCCH message. The UE(s) transmits the MTC PUCCH message to the base station over multiple RBs.

Aspects of the disclosure are initially described in the context of a wireless communications system. Aspects of the described techniques may provide for extending the bandwidth of an enhanced machine type communication (eMTC) physical uplink control channel (PUCCH) message to support communicating in certain radio frequency bands. For example, the described techniques may include transmitting the machine type communication (MTC) (or eMTC) PUCCH message over multiple resource blocks (RBs) to provide adequate bandwidth for the MTC PUCCH message communication in the radio frequency band and, in some examples, extend the amount of data that can be communicated in the MTC PUCCH message. For example, a base station may select a payload size configuration for MTC PUCCH messages for a user equipment (UE). The payload size configuration may also determine the amount of data that the UE has available for the MTC PUCCH message. For example, the payload size configuration may extend the MTC PUCCH message from one RB to multiple RBs. This may extend the bandwidth used by the MTC PUCCH message and provide additional data capacity and/or redundancy options for the MTC PUCCH message. The base station may transmit a configuration message to the UE indicating the payload size configuration. The UE may receive the configuration message and use the payload size configuration to generate an MTC PUCCH message. The UE may transmit the MTC PUCCH message to the base station over the multiple RBs.

Aspects of the disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flowcharts that relate to a PUCCH design for eMTC communications in a shared or unlicensed radio frequency spectrum band (eMTC-U) design.

<FIG> illustrates an example of a wireless communications system <NUM> in accordance with various aspects of the present disclosure. The wireless communications system <NUM> includes base stations <NUM>, UEs <NUM>, and a core network <NUM>. In some examples, the wireless communications system <NUM> may be a Long Term Evolution (LTE) network, an LTE-Advanced (LTE-A) network, or a New Radio (NR) network. In some cases, wireless communications system <NUM> may support enhanced broadband communications, ultra-reliable (e.g., mission critical) communications, low latency communications, or communications with low-cost and low-complexity devices.

The wireless communications system <NUM> may include, for example, a heterogeneous LTE/LTE-A or NR network in which different types of base stations <NUM> provide coverage for various geographic coverage areas <NUM>.

In some examples, a carrier may support multiple cells, and different cells may be configured according to different protocol types (e.g., MTC, narrowband Internet-of-Things (NB-IoT), enhanced mobile broadband (eMBB), or others) that may provide access for different types of devices.

eMTC devices may build on MTC protocols and support lower bandwidths in the uplink or downlink, lower data rates, and reduced transmit power, culminating in significantly longer battery life (e.g., extending batter life for several years). References to an MTC may also refer to an eMTC configured device.

In some cases, operations in unlicensed bands may be based on a carrier aggregation (CA) configuration in conjunction with component carriers (CCs) operating in a licensed band (e.g., LAA).

For example, wireless communication system may use a transmission scheme between a transmitting device (e.g., a base station <NUM>) and a receiving device (e.g., a UE <NUM>), where the transmitting device is equipped with multiple antennas and the receiving devices are equipped with one or more antennas.

In one example, a base station <NUM> may use multiple antennas or antenna arrays to conduct beamforming operations for directional communications with a UE <NUM>. For instance, some signals (e.g. synchronization signals, reference signals, beam selection signals, or other control signals) may be transmitted by a base station <NUM> multiple times in different directions, which may include a signal being transmitted according to different beamforming weight sets associated with different directions of transmission. Transmissions in different beam directions may be used to identify (e.g., by the base station <NUM> or a receiving device, such as a UE <NUM>) a beam direction for subsequent transmission and/or reception by the base station <NUM>. Some signals, such as data signals associated with a particular receiving device, may be transmitted by a base station <NUM> in a single beam direction (e.g., a direction associated with the receiving device, such as a UE <NUM>). In some examples, the beam direction associated with transmissions along a single beam direction may be determined based at least in in part on a signal that was transmitted in different beam directions. For example, a UE <NUM> may receive one or more of the signals transmitted by the base station <NUM> in different directions, and the UE <NUM> may report to the base station <NUM> an indication of the signal it received with a highest signal quality, or an otherwise acceptable signal quality. Although these techniques are described with reference to signals transmitted in one or more directions by a base station <NUM>, a UE <NUM> may employ similar techniques for transmitting signals multiple times in different directions (e.g., for identifying a beam direction for subsequent transmission or reception by the UE <NUM>), or transmitting a signal in a single direction (e.g., for transmitting data to a receiving device).

The organizational structure of the carriers may be different for different radio access technologies (e.g., LTE, LTE-A, NR, etc.).

In a system employing MCM techniques, a resource element (RE) may consist of one symbol period (e.g., a duration of one modulation symbol) and one subcarrier, where the symbol period and subcarrier spacing are inversely related. The number of bits carried by each RE may depend on the modulation scheme (e.g., the order of the modulation scheme). Thus, the more REs that a UE <NUM> receives and the higher the order of the modulation scheme, the higher the data rate may be for the UE <NUM>.

Devices of the wireless communications system <NUM> (e.g., base stations <NUM> or UEs <NUM>) may have a hardware configuration that supports communications over a particular carrier bandwidth, or may be configurable to support communications over one of a set of carrier bandwidths. In some examples, the wireless communications system <NUM> may include base stations <NUM> and/or UEs <NUM> that can support simultaneous communications via carriers associated with more than one different carrier bandwidth.

Wireless communications system <NUM> may support communication with a UE <NUM> on multiple cells or carriers, a feature which may be referred to as CA or multi-carrier operation.

Wireless communications systems such as an NR system may utilize any combination of licensed, shared, and unlicensed spectrum bands, among others. The flexibility of eCC symbol duration and subcarrier spacing may allow for the use of eCC across multiple spectrums. In some examples, NR shared spectrum may increase spectrum utilization and spectral efficiency, specifically through dynamic vertical (e.g., across frequency) and horizontal (e.g., across time) sharing of resources.

One or more of the base stations <NUM> may support aspects of the described techniques for eMTC PUCCH message design. For example, the base station <NUM> may select a payload size configuration for an MTC PUCCH message from a UE <NUM>. The payload size configuration may include a maximum amount of data available for the MTC PUCCH message. The base station <NUM> may transmit a configuration message to the UE to indicate the payload size configuration. The base station <NUM> may receive the MTC PUCCH message from the UE <NUM> over a plurality of RBs.

One or more of the UEs <NUM> may support aspects of the described techniques for eMTC PUCCH message design. For example, the UE <NUM> may receive a configuration message indicating a payload size configuration for MTC PUCCH messages. The UE <NUM> may generate an MTC PUCCH message based at least in part on the payload size configuration and a PUCCH format of MTC uplink control information for transmission by the UE <NUM>. The UE <NUM> may transmit the MTC PUCCH message over a plurality of RBs in a frequency domain.

<FIG> illustrates an example of a payload configuration <NUM> that supports an eMTC-U PUCCH design in accordance with various aspects of the present disclosure. In some examples, payload configuration <NUM> may implement aspects of wireless communications system <NUM>. In some aspects, payload configuration <NUM> may be implemented by a UE and/or a base station, which may be examples of the corresponding devices described herein.

Payload configuration <NUM> may be an example of a payload size configuration selected by a base station for MTC PUCCH messages from a UE. The base station selects the payload configuration <NUM> as the payload size configuration and transmits an indication of the payload size configuration to the UE in a configuration message (e.g., in an RRC message). Payload configuration <NUM> includes an MTC PUCCH message transmission that includes a plurality of reference signal REs (e.g., demodulation reference signals (DMRSs)), as well as data REs. Payload configuration <NUM> supports the UE transmitting the MTC PUCCH message over a plurality of RBs, with three RBs <NUM>, <NUM>, and <NUM> being shown by way of a non-limiting example. However, the payload configuration <NUM> is not limited to three RBs and may have more than three RBs. Each of the RBs <NUM>, <NUM>, and <NUM> may include seven symbol periods (labeled <NUM>-<NUM>), but may have more or less symbol periods.

In some aspects, payload configuration <NUM> includes at least three RBs to support MTC PUCCH message transmissions on a <NUM> ISM band. For example, each of RBs <NUM>, <NUM>, and <NUM> may have a corresponding bandwidth of <NUM> and payload configuration <NUM> may include three RBs <NUM>, <NUM>, and <NUM> having a cumulative bandwidth of at least <NUM>. The RBs <NUM>, <NUM>, and <NUM> may therefore comply with a minimum bandwidth of the radio frequency band and may be used for MTC PUCCH message communications.

In some aspects, payload configuration <NUM> may be associated with a PUCCH format <NUM> (e.g., a machine PUCCH (mPUCCH) format <NUM>). The PUCCH format <NUM> may include communicating a scheduling request, HARQ feedback, and the like. Here, symbol periods <NUM>, <NUM>, <NUM>, and <NUM> contain data REs while symbol periods <NUM>, <NUM>, and <NUM> contain reference signal REs. However, the payload configuration <NUM> may not be limited to this number or configuration of data and reference signal REs. In some cases, payload configuration <NUM> may be configured for at least two options supporting MTC PUCCH messages in the radio frequency band.

In a first option, payload configuration <NUM> may support frequency domain concatenation. The reference signal REs (e.g., the DMRS waveform) may be repeated across each of RBs <NUM>, <NUM> and <NUM>. In some cases, a cover code (e.g., an orthogonal cover code (OCC)) of length three may be applied to the reference signals. Additionally or alternatively, a cyclic shift may be applied to the reference signals (e.g., a length-<NUM> cyclic shift). In another example, a cover code and/or a cyclic shift may be applied to the data. In some aspects, an OCC cover code of length four may be applied to the data. In some other aspects, a length-<NUM> cyclic shift may also be applied to the data.

In some aspects of the first option, the data REs (e.g., the data waveform) may include all length-<NUM> computer generated sequences (CGSs) (e.g., base sequences) modulated by a data modulation symbol d(i) in each of the RBs <NUM>, <NUM>, and <NUM>. In a first example and for a maximum payload, d(<NUM>) (e.g., the data symbol used to modulate the data in RB <NUM>), d(<NUM>) (e.g., the data symbol used to modulate the data in RB <NUM>), and d(<NUM>) (e.g., the data symbol used to modulate the data in RB <NUM>) may be different. This may support payload configuration <NUM> transmitting six bits of data (e.g., not including channel selection). This example may be used to ACK/NACK multiple HARQ processes in a self-contained frame structure.

In another example and for maximal coverage, d(<NUM>), d(<NUM>), and d(<NUM>) may be the same. That is, the data in each of RBs <NUM>, <NUM>, and <NUM>, may be modulated with the same data symbol. This may support payload configuration <NUM> transmitting two bits of data (e.g., not including channel selection), but the data being repeated across the different RBs. This may provide increased redundancy and coverage. Thus, the data waveforms of the second and third RBs (e.g., RBs <NUM> and <NUM>) may be the same as the data waveform of the first RB (e.g., RB <NUM>). In some aspects, the same resource index may be used across the three RBs <NUM>, <NUM>, and <NUM>. MTC PUCCH message repetition may be required according to aspects of the first option.

In a second option, which is in agreement with the claimed invention, payload configuration <NUM> includes a sequence (e.g., a base sequence) being applied to both of the reference signals and data. A single sequence (e.g., a sequence that doesn't repeat in the frequency domain over the RBs) is be applied to the reference signals across each of RBs <NUM>, <NUM>, and <NUM>. In some cases, the single sequence may be a longer sequence when compared to a length-<NUM> CGS (e.g., a Chu sequence). A cyclic shift of <NUM> may be applied to the reference signals and the data on a per-RB configuration. A length three cover code may be applied to the reference signals and a length four cover code may be applied to the data.

In some aspects of the second option, the sequence may be applied across all allocated RBs of the data. The data may be modulated by the same data symbol. Thus, payload configuration <NUM> according to the second option may carry two bits of data (e.g., not including the channel selection). In some aspects, payload configuration <NUM> may be used to multiplex up to <NUM> UEs (e.g., three RBs with a length-<NUM> cyclic shift being used to multiplex up to <NUM> UEs). MTC PUCCH message repetition may not be required according to aspects of the second option.

Payload configuration <NUM> may be an example of a payload size configuration selected by a base station for MTC PUCCH messages from a UE. For example, the base station may select the payload configuration <NUM> as the payload size configuration and transmit an indication of the payload size configuration to the UE in a configuration message (e.g., in an RRC message). Payload configuration <NUM> may include an MTC PUCCH message transmission that includes a plurality of reference signal REs (e.g., DMRS, as well as data REs). Payload configuration <NUM> may support the UE transmitting the MTC PUCCH message over a plurality of RBs, with three RBs <NUM>, <NUM>, and <NUM> being shown. However, the payload configuration <NUM> is not limited to three RBs and may have more than three RBs. Each of the RBs <NUM>, <NUM>, and <NUM> may include seven symbol periods (labeled <NUM>-<NUM>), but may have more or less symbol periods.

In some aspects, payload configuration <NUM> may be associated with a PUCCH format <NUM> (e.g., a mPUCCH format <NUM>). The PUCCH format <NUM> may include communicating a scheduling request, HARQ feedback, channel quality indicators, and the like. Here, symbol periods <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> contain data REs while symbol periods <NUM> and <NUM> contain reference signal REs. However, the payload configuration <NUM> may not be limited to this number or configuration of data and reference signal REs. In some cases, payload configuration <NUM> may be configured for at least two options supporting MTC PUCCH messages in the radio frequency band.

In a first option, payload configuration <NUM> may support frequency domain concatenation. The reference signal REs (e.g., the DMRS waveform) may be repeated across each of RBs <NUM>, <NUM> and <NUM>. In some aspects, a cover code (e.g., an OCC) of length two may be applied to the reference signals. In some aspects, a cyclic shift may also be applied to the reference signals (e.g., a length-<NUM> cyclic shift). In some cases, a cover code and/or cyclic shift may be applied to the data. For example, an OCC cover code of length five and/or a length-<NUM> cyclic shift may be applied to the data.

In some aspects of the first option, the data REs (e.g., the data waveform) may include all ten length-<NUM> CGSs modulated by ten data modulation symbols d(i) in each of the RBs <NUM>, <NUM>, and <NUM>. In one example and for a maximum payload, each group of ten data symbols in different RBs may be different. This may provide a total of <NUM> data symbols providing <NUM> bits of data payload. This may be used to ACK/NACK multiple HARQ processes in a self-contained frame structure and convey channel state information in multiple hopping frequencies.

In a second example and for maximal coverage, the ten data symbols in the different RBs may be the same. This may provide for ten data symbols providing <NUM> bits of data payload. Thus, the data waveforms in each of RBs <NUM> and <NUM> may be the same as the data waveform in RB <NUM>. In some aspects, the same resource index may be used across the three RBs <NUM>, <NUM>, and <NUM>. In some aspects of the first option, up to <NUM> UEs may be multiplexed according to payload configuration <NUM>.

In a second option, payload configuration <NUM> may include a sequence being applied to the reference signals. For example, a single sequence (e.g., a sequence that doesn't repeat in the frequency domain over the RBs, such as a Chu sequence) may be applied to the reference signals across each of RBs <NUM>, <NUM>, and <NUM>. A cyclic shift of <NUM> may be applied to the reference signals and the data on a per-RB configuration. A length two cover code may be applied to the reference signals and a length five cover code may be applied to the data.

In some aspects of the second option, the sequence may be applied across all allocated RBs of the data. For example, ten long sequences may be modulated by ten data modulation symbols. Thus, payload configuration <NUM> according to the second option may carry <NUM> bits of data (e.g., not including the channel selection). In some aspects, payload configuration <NUM> may be used to multiplex up to <NUM> UEs. MTC PUCCH message repetition may not be required according to aspects of the second option.

In some cases, payload configuration <NUM> may be associated with a PUCCH format <NUM> (e.g., a mPUCCH format <NUM>). The PUCCH format <NUM> may include communicating using a frequency hopping scheme using <NUM> or more frequencies in eMTC-U. For example, the eMTC-U transmission may hop over <NUM> in a <NUM> ISM band. In some instances, the PUCCH format <NUM> may include additional bits to carry channel state information as compared to other eMTC protocols which may use fewer hopping frequencies (e.g., four hopping frequencies). The additional bits may be used to capture and carry interference and channel frequency variation (e.g., information used to update the white list and rate adaptation).

In some aspects of the PUCCH format <NUM>, a reference signal may include a sequence (e.g., a single Chu sequence) being applied across all allocated RBs <NUM>, <NUM>, and <NUM>. A length-<NUM> cyclic shift may be applied to the reference signals on a per RB basis. A length two cover code (e.g., OCC) may be applied over two reference signal symbols per slot (e.g., all allocated RBs).

In some aspects of the PUCCH format <NUM>, the data waveform may have a length five cover code applied over five data symbols per slot (e.g., all allocated RBs). One data symbol may be applied per tone per slot, giving <NUM> data symbols for one subframe. This may support up to <NUM> data bits being carried in the payload configuration <NUM>. The same resource index may be used across all allocated RBs. Payload configuration <NUM> may be configured to multiplex up to five UEs. MTC PUCCH message repetition may not be required according to certain aspects of the PUCCH format three.

Payload configuration <NUM> may be an example of a payload size configuration selected by a base station for MTC PUCCH messages from a UE. For example, the base station may select the payload configuration <NUM> as the payload size configuration and transmit an indication of the payload size configuration to the UE in a configuration message (e.g., in an RRC message). Payload configuration <NUM> may support the UE transmitting the MTC PUCCH message over a plurality of RBs, with three RBs being shown by way of a non-limiting example. However, the payload configuration <NUM> is not limited to three RBs and may have more than three RBs. In some aspects, payload configuration <NUM> includes at least three RBs to support MTC PUCCH message transmissions on a <NUM> ISM band.

In some aspects, payload configuration <NUM> may include multiplexing of PUCCH format <NUM> and <NUM> (e.g., format <NUM> and format <NUM><NUM>). That is, UEs may use TDM techniques for eMTC-U PUCCH transmissions and therefore less PUCCH capacity may be used for a given subframe. PUCCH format <NUM><NUM> may carry ACK/NACK feedback and a scheduling request. PUCCH format <NUM><NUM> may be used to carry ACK/NACK feedback, a scheduling request, and a periodic channel state information. Multiplexing of the PUCCH format <NUM> and PUCCH format <NUM><NUM> may be helpful, for example, when certain UEs have ACK/NACK feedback to send and other UEs have periodic channel state information to send. The multiplexed PUCCH format may occupy three RBs over a six RB bandwidth allocation, with the remaining three RBs being allocated to physical uplink shared channel (PUSCH) <NUM>.

That is, the multiplexed PUCCH format (e.g., format <NUM> and format <NUM>) may occupy three RBs and the remaining three RBs may be occupied by the PUSCH <NUM> (e.g., a first subset of RBs allocated to the MTC PUCCH message and a second subset of RBs allocated to PUSCH message(s)). The enhanced format <NUM> and format <NUM><NUM> may share the same three RBs, but use different cyclic shifts (e.g., a first subset of cyclic shifts applied to the first subset of RBs for the PUCCH format <NUM> and a second subset of cyclic shifts applied to the first subset of RBs for the PUCCH format <NUM>). In one example, <NUM> cyclic shifts total may include <MAT> cyclic shifts allocated for format <NUM><NUM>, a δ guard cyclic shift, and <MAT> cyclic shifts allocated to format <NUM><NUM>. In some aspects, format <NUM> and format <NUM><NUM> may have the same or different reference signal/data symbol locations, may use the same sequence (e.g., a base sequence that may be either a long base sequence such as a single Chu sequence or short base sequence such as a length-<NUM> CGS), and both reference signal and data symbol may be the same across all allocated RBs (e.g., may use any of the options discussed above with reference to payload configurations <NUM> and/or <NUM>).

In some aspects, the multiplexing capacity for payload configuration <NUM> may be determined as follows. A multiplexing capacity associated with format <NUM> may be determined by <MAT>, where Δ refers to the minimum cyclic shift gap. A multiplexing capacity associated with format <NUM><NUM> may be determined by <MAT>.

<FIG> illustrates an example of a process <NUM> that supports an eMTC-U PUCCH design in accordance with various aspects of the present disclosure. In some examples, process <NUM> may implement aspects of wireless communications system <NUM> and/or payload configurations <NUM>, <NUM> and/or <NUM>. Process <NUM> may include a base station <NUM> and a UE <NUM>, which may be examples of the corresponding devices described herein.

At <NUM>, base station <NUM> may select or otherwise identify a payload size configuration for an MTC PUCCH message from UE <NUM>. The payload size configuration may include a maximum amount of data available for the MTC PUCCH message. The payload size configuration may be an example of the payload configuration <NUM>, <NUM>, and/or <NUM>.

At <NUM>, base station <NUM> may transmit (and UE <NUM> may receive) a configuration message to UE <NUM> that indicates the payload size configuration. The configuration message may be transmitted in an RRC message, in some examples.

At <NUM>, UE <NUM> may generate an MTC PUCCH message based on the payload size configuration indicated from base station <NUM> and a PUCCH format of MTC uplink control information for transmission by UE <NUM>. For example, the MTC PUCCH message may be generated based on whether the PUCCH format is a format <NUM>, format <NUM>, format <NUM>, or hybrid format <NUM>/<NUM>, as is discussed above.

At <NUM>, UE <NUM> may transmit (and base station <NUM> may receive) the MTC PUCCH message across a plurality of RBs in the frequency domain. For example, the MTC PUCCH message may be transmitted across three RBs.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports an eMTC-U PUCCH design in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a UE <NUM> as described herein. Wireless device <NUM> may include receiver <NUM>, UE communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Receiver <NUM> may receive information such as packets, user data, or control information associated with various information channels (e.g., control channels, data channels, and information related to eMTC-U PUCCH design, etc.). Information may be passed on to other components of the device. The receiver <NUM> may be an example of aspects of the transceiver <NUM> described with reference to <FIG>. The receiver <NUM> may utilize a single antenna or a set of antennas.

UE communications manager <NUM> may be an example of aspects of the UE communications manager <NUM> described with reference to <FIG>.

UE communications manager <NUM> and/or at least some of its various sub-components may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions of the UE communications manager <NUM> and/or at least some of its various sub-components may be executed by a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present disclosure. The UE communications manager <NUM> and/or at least some of its various sub-components may be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations by one or more physical devices. In some examples, UE communications manager <NUM> and/or at least some of its various sub-components may be a separate and distinct component in accordance with various aspects of the present disclosure. In other examples, UE communications manager <NUM> and/or at least some of its various sub-components may be combined with one or more other hardware components, including but not limited to an I/O component, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof in accordance with various aspects of the present disclosure.

UE communications manager <NUM> may receive, at a UE, a configuration message indicating a payload size configuration for MTC PUCCH messages. UE communications manager <NUM> may generate an MTC PUCCH message based on the payload size configuration and a PUCCH format of MTC uplink control information for transmission by the UE. UE communications manager <NUM> may transmit the MTC PUCCH message over a set of RBs in a frequency domain.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports an eMTC-U PUCCH design in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a wireless device <NUM> or a UE <NUM> as described herein. Wireless device <NUM> may include receiver <NUM>, UE communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

UE communications manager <NUM> may be an example of aspects of the UE communications manager <NUM> described with reference to <FIG>. UE communications manager <NUM> may also include configuration message manager <NUM> and MTC PUCCH message manager <NUM>.

Configuration message manager <NUM> may receive, at a UE, a configuration message indicating a payload size configuration for MTC PUCCH messages.

MTC PUCCH message manager <NUM> may generate an MTC PUCCH message based on the payload size configuration and a PUCCH format of MTC uplink control information for transmission by the UE and transmit the MTC PUCCH message over a set of RBs in a frequency domain.

<FIG> shows a block diagram <NUM> of a UE communications manager <NUM> that supports an eMTC-U PUCCH design in accordance with aspects of the present disclosure. The UE communications manager <NUM> may be an example of aspects of a UE communications manager <NUM>, a UE communications manager <NUM>, or a UE communications manager <NUM> described with reference to <FIG>, <FIG>, and <FIG>. The UE communications manager <NUM> may include configuration message manager <NUM>, MTC PUCCH message manager <NUM>, data symbol manager <NUM>, reference signal manager <NUM>, sequence manager <NUM>, and RB manager <NUM>. Each of these modules may communicate, directly or indirectly, with one another (e.g., via one or more buses).

Data symbol manager <NUM> may identify, based on the payload size configuration, a data symbol to use for modulating data bits in a CGS of an RB of the set of RBs. Data symbol manager <NUM> may modulate each CGS of the RB, where each CGS of the RB is modulated with a different data symbol. Data symbol manager <NUM> may modulate each CGS of the RB, where each CGS of the RB is modulated with a same data symbol.

Reference signal manager <NUM> may repeat a reference signal in the set of RBs of the MTC PUCCH message.

Sequence manager <NUM> may apply, for the UE, a sequence to different tones of the set of RBs of the MTC PUCCH message, where the sequence is non-repeating in a frequency domain over the set of RBs. Sequence manager <NUM> may apply, for the UE, a same cyclic shift to each of the set of RBs of the MTC PUCCH message. Sequence manager <NUM> may apply, for the UE, a same cover code to different symbol periods in each of the set of RBs of the MTC PUCCH message. In some cases, the sequence includes a Chu sequence.

RB manager <NUM> may allocate, based on the payload size configuration, a first subset of RBs of the set of RBs for the MTC PUCCH message and a second subset of RBs of the set of RBs for a PUSCH message. RB manager <NUM> may apply a first sequence to the first subset of RBs according to a first PUCCH format and apply a second sequence to the first subset of RBs according to a second PUCCH format, where the first sequence is from the same as the second sequence. RB manager <NUM> may apply a first cyclic shift to a first portion of the first subset of RBs and apply a second cyclic shift to a second portion of the first subset of RBs, where the first cyclic shift is different from the second cyclic shift. RB manager <NUM> may use different reference signal and data symbol location configuration for a first portion of the first subset of RBs and a second portion of the first subset of RBs. RB manager <NUM> may use a same base sequence for a first portion of the first subset of RBs and a second portion of the first subset of RBs. RB manager <NUM> may configure a first portion of the first subset of RBs and a second portion of the first subset of RBs to use a same data symbol.

<FIG> shows a diagram of a system <NUM> including a device <NUM> that supports an eMTC-U PUCCH design in accordance with aspects of the present disclosure. Device <NUM> may be an example of or include the components of wireless device <NUM>, wireless device <NUM>, or a UE <NUM> as described herein. Device <NUM> may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including UE communications manager <NUM>, processor <NUM>, memory <NUM>, software <NUM>, transceiver <NUM>, antenna <NUM>, and I/O controller <NUM>. These components may be in electronic communication via one or more buses (e.g., bus <NUM>). Device <NUM> may communicate wirelessly with one or more base stations <NUM>.

Processor <NUM> may include an intelligent hardware device, (e.g., a general-purpose processor, a DSP, a central processing unit (CPU), a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, processor <NUM> may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into processor <NUM>. Processor <NUM> may be configured to execute computer-readable instructions stored in a memory to perform various functions (e.g., functions or tasks supporting eMTC-U PUCCH design).

Software <NUM> may include code to implement aspects of the present disclosure, including code to support eMTC-U PUCCH design. Software <NUM> may be stored in a non-transitory computer-readable medium such as system memory or other memory. In some cases, the software <NUM> may not be directly executable by the processor but may cause a computer (e.g., when compiled and executed) to perform functions described herein.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports an eMTC-U PUCCH design in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a base station <NUM> as described herein. Wireless device <NUM> may include receiver <NUM>, base station communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Base station communications manager <NUM> may be an example of aspects of the base station communications manager <NUM> described with reference to <FIG>.

Base station communications manager <NUM> and/or at least some of its various sub-components may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions of the base station communications manager <NUM> and/or at least some of its various sub-components may be executed by a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present disclosure. The base station communications manager <NUM> and/or at least some of its various sub-components may be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations by one or more physical devices. In some examples, base station communications manager <NUM> and/or at least some of its various sub-components may be a separate and distinct component in accordance with various aspects of the present disclosure. In other examples, base station communications manager <NUM> and/or at least some of its various sub-components may be combined with one or more other hardware components, including but not limited to an I/O component, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof in accordance with various aspects of the present disclosure.

Base station communications manager <NUM> may select a payload size configuration for an MTC PUCCH message from a UE, the payload size configuration including a maximum amount of data available for the MTC PUCCH message. Base station communications manager <NUM> may transmit a configuration message to the UE to indicate the payload size configuration. Base station communications manager <NUM> may receive the MTC PUCCH message from the UE over a set of RBs.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports an eMTC-U PUCCH design in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a wireless device <NUM> or a base station <NUM> as described herein. Wireless device <NUM> may include receiver <NUM>, base station communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Base station communications manager <NUM> may be an example of aspects of the base station communications manager <NUM> described with reference to <FIG>. Base station communications manager <NUM> may also include payload size configuration manager <NUM>, configuration message manager <NUM>, and MTC PUCCH message manager <NUM>.

Payload size configuration manager <NUM> may select a payload size configuration for an MTC PUCCH message from a UE, the payload size configuration including a maximum amount of data available for the MTC PUCCH message.

Configuration message manager <NUM> may transmit a configuration message to the UE to indicate the payload size configuration.

MTC PUCCH message manager <NUM> may receive the MTC PUCCH message from the UE over a set of RBs.

<FIG> shows a block diagram <NUM> of a base station communications manager <NUM> that supports an eMTC-U PUCCH design in accordance with aspects of the present disclosure. The base station communications manager <NUM> may be an example of aspects of a base station communications manager <NUM> described with reference to <FIG>, <FIG>, and <FIG>. The base station communications manager <NUM> may include payload size configuration manager <NUM>, configuration message manager <NUM>, MTC PUCCH message manager <NUM>, CGS manager <NUM>, reference signal manager <NUM>, sequence manager <NUM>, and RB manager <NUM>. Each of these modules may communicate, directly or indirectly, with one another (e.g., via one or more buses).

CGS manager <NUM> may demodulate each CGS of the set of RBs of the MTC PUCCH message, where each CGS of the RB is modulated with a different data symbol. CGS manager <NUM> may demodulate each CGS of the set of RBs of the MTC PUCCH message, where each CGS of the RB is modulated with a same data symbol.

Reference signal manager <NUM> may receive a reference signal in the set of RBs of the MTC PUCCH message, where the reference signal is repeated in the set of RBs.

Sequence manager <NUM> may recover each of the set of RBs of the MTC PUCCH message using a sequence applied to different tones of the set of RBs of the PUCCH message, where the sequence is non-repeating over the set of RBs. Sequence manager <NUM> may reverse cyclically shifting, for the UE, each of the set of RBs of the MTC PUCCH message using a same cyclic shift code. Sequence manager <NUM> may recover each of the set of RBs of the MTC PUCCH message using a same cover code.

RB manager <NUM> may identify, based on the payload size configuration, a first subset of RBs of the set of RBs for the MTC PUCCH message and a second subset of RBs of the set of RBs for a PUSCH message. RB manager <NUM> may identify a first subset of cyclic shifts applied to the first subset of RBs according to a first PUCCH format (e.g., PUCCH format <NUM>) and identify a second subset of cyclic shifts applied to the first subset of RBs according to a second PUCCH format (e.g., PUCCH format <NUM>). RB manager <NUM> may recover a first portion of the first subset of RBs using a first cyclic shift and recover a second portion of the first subset of RBs using a second cyclic shift, where the first cyclic shift is different from the second cyclic shift. RB manager <NUM> may recover, according to a different reference signal and data symbol location configuration, a first portion of the first subset of RBs and a second portion of the first subset of RBs. RB manager <NUM> may recover, according to a same base sequence, a first portion of the first subset of RBs and a second portion of the first subset of RBs. RB manager <NUM> may recover, according to a same data symbol, a first portion of the first subset of RBs and a second portion of the first subset of RBs.

<FIG> shows a diagram of a system <NUM> including a device <NUM> that supports an eMTC-U PUCCH design in accordance with aspects of the present disclosure. Device <NUM> may be an example of or include the components of base station <NUM> as described above (e.g., with reference to <FIG>). Device <NUM> may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including base station communications manager <NUM>, processor <NUM>, memory <NUM>, software <NUM>, transceiver <NUM>, antenna <NUM>, network communications manager <NUM>, and inter-station communications manager <NUM>. These components may be in electronic communication via one or more buses (e.g., bus <NUM>). Device <NUM> may communicate wirelessly with one or more UEs <NUM>.

Processor <NUM> may include an intelligent hardware device, (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, processor <NUM> may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into processor <NUM>. Processor <NUM> may be configured to execute computer-readable instructions stored in a memory to perform various functions (e.g., functions or tasks supporting eMTC-U PUCCH design).

Inter-station communications manager <NUM> may manage communications with other base station <NUM>, and may include a controller or scheduler for controlling communications with UEs <NUM> in cooperation with other base stations <NUM>. In some examples, inter-station communications manager <NUM> may provide an X2 interface within an LTE/LTE-A wireless communication network technology to provide communication between base stations <NUM>.

<FIG> shows a flowchart illustrating a method <NUM> for wireless communications in accordance with aspects of the present disclosure. The operations of method <NUM> may be implemented by a UE <NUM> or its components as described herein. For example, the operations of method <NUM> may be performed by a UE communications manager as described with reference to <FIG>. In some examples, a UE <NUM> may execute a set of codes to control the functional elements of the device to perform the functions described below. Additionally or alternatively, the UE <NUM> may perform aspects of the functions described below using special-purpose hardware.

At block <NUM> the UE <NUM> may receive, at a UE, a configuration message indicating a payload size configuration for MTC PUCCH messages. The operations of block <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of block <NUM> may be performed by a configuration message manager as described with reference to <FIG>.

At block <NUM> the UE <NUM> may generate an MTC PUCCH message based at least in part on the payload size configuration and a PUCCH format of MTC uplink control information for transmission by the UE. The operations of block <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of block <NUM> may be performed by an MTC PUCCH message manager as described with reference to <FIG>.

At block <NUM> the UE <NUM> may transmit the MTC PUCCH message over a plurality of RBs in a frequency domain. The operations of block <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of block <NUM> may be performed by an MTC PUCCH message manager as described with reference to <FIG>.

At block <NUM> the UE <NUM> may apply, for the UE, a sequence to different tones of the plurality of RBs of the MTC PUCCH message, where the sequence is non-repeating in a frequency domain over the plurality of RBs. The operations of block <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of block <NUM> may be performed by a sequence manager as described with reference to <FIG>.

<FIG> shows a flowchart illustrating a method <NUM> for wireless communications in accordance with aspects of the present disclosure. The operations of method <NUM> may be implemented by a base station <NUM> or its components as described herein. For example, the operations of method <NUM> may be performed by a base station communications manager as described with reference to <FIG>. In some examples, a base station <NUM> may execute a set of codes to control the functional elements of the device to perform the functions described below. Additionally or alternatively, the base station <NUM> may perform aspects of the functions described below using special-purpose hardware.

At block <NUM> the base station <NUM> may select a payload size configuration for an MTC PUCCH message from a UE, the payload size configuration including a maximum amount of data available for the MTC PUCCH message. The operations of block <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of block <NUM> may be performed by a payload size configuration manager as described with reference to <FIG>.

At block <NUM> the base station <NUM> may transmit a configuration message to the UE to indicate the payload size configuration. The operations of block <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of block <NUM> may be performed by a configuration message manager as described with reference to <FIG>.

At block <NUM> the base station <NUM> may receive the MTC PUCCH message from the UE over a plurality of RBs. The operations of block <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of block <NUM> may be performed by an MTC PUCCH message manager as described with reference to <FIG>.

At block <NUM> the base station <NUM> may identify a first subset of cyclic shifts applied to a first subset of RBs according to a first PUCCH format. The operations of block <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of block <NUM> may be performed by an RB manager as described with reference to <FIG>.

At block <NUM> the base station <NUM> may identify a second subset of cyclic shifts applied to the first subset of RBs according to a second PUCCH format. The operations of block <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of block <NUM> may be performed by an RB manager as described with reference to <FIG>.

The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a DSP, an ASIC, a FPGA, or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.

By way of example, and not limitation, non-transitory computer-readable media may comprise RAM, ROM, electrically erasable programmable read only memory (EEPROM), flash memory, compact disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor.

Claim 1:
A method for wireless communication, comprising:
receiving (<NUM>), at a user equipment, UE, a configuration message indicating a payload size configuration for machine type communication, MTC, physical uplink control channel, PUCCH, messages;
generating (<NUM>) an MTC PUCCH message based at least in part on the payload size configuration and a PUCCH format of MTC uplink control information for transmission by the UE, wherein the payload size configuration configures the MTC PUCCH message to include a plurality of reference signal resource elements, REs, and a plurality of data REs, and wherein the payload size configuration configures the UE to use a single sequence across a plurality of resource blocks, RBs, wherein the symbol periods occupied by the reference signal REs and the symbol periods occupied by the data REs are different;
applying (<NUM>), for the UE, based on the payload size configuration, the sequence to the plurality of reference signal REs and the plurality of data REs in the plurality of RBs of the MTC PUCCH message, wherein the sequence is non-repeating in a frequency domain over the plurality of RBs; and
transmitting (<NUM>) the MTC PUCCH message over the plurality of RBs in the frequency domain.