Patent Description:
MTC is an emerging technology related to the concept of "Internet of Things (IoT). " Existing mobile broadband networks were designed to optimize performance mainly for human type of communications and thus are not designed or optimized to meet MTC related requirements. <NPL> discusses a proposal, according to which the PHICH and PCFICH for low-cost & enhanced coverage MTC UE can be eliminated.

The object of the present application is solved by the independent claims. Advantageous embodiments are described by the dependent claims.

Embodiments relate to systems, devices, apparatus, assemblies, methods, and computer readable media to enable MTC using reduced system bandwidth (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.). In particular, systems and methods are described for UE associated with an eNB to implement communications with such reduced system bandwidth. The following description and the drawings illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments can incorporate structural, logical, electrical, process, and other changes. The scope of the invention is defined by the independent claims.

<FIG> illustrates a wireless network <NUM>, in accordance with some embodiments. The wireless network <NUM> includes UE <NUM> and eNB <NUM> connected via air interface <NUM>. The UE <NUM> and any other UE in the system may be, for example, laptop computers, smart phones, tablet computers, printers, machine-type devices such as smart meters or specialized devices for healthcare monitoring, remote security surveillance, an intelligent transportation system, or any other wireless devices with or without a user interface. The eNB <NUM> provides network connectivity to a broader network (not shown) to UE <NUM> via air interface <NUM> in an eNB service area provided by eNB <NUM>. Each eNB service area associated with eNB <NUM> is supported by antennas integrated with eNB <NUM>. The service areas are divided into a number of sectors associated with certain antennas. Such sectors may be physically associated with fixed antennas or may be assigned to a physical area with tunable antennas or antenna settings adjustable in a beamforming process used to direct a signal to a particular sector. One embodiment of eNB <NUM>, for example, includes three sectors each covering a <NUM> degree area with an array of antennas directed to each sector to provide <NUM> degree coverage around eNB <NUM>.

UE <NUM> includes control circuitry <NUM> coupled with transmit circuitry <NUM> and receive circuitry <NUM>. The transmit circuitry <NUM> and receive circuitry <NUM> may each be coupled with one or more antennas.

The control circuitry <NUM> may be adapted to perform operations associated with MTC. The transmit circuitry <NUM> and receive circuitry <NUM> may be adapted to transmit and receive data, respectively, within a narrow system bandwidth (e.g., <NUM>). The control circuitry <NUM> may perform various operations such as those described elsewhere in this disclosure related to a UE.

Within the narrow system bandwidth, the transmit circuitry <NUM> may transmit a plurality of multiplexed uplink physical channels. The plurality of uplink physical channels may be multiplexed according to time division multiplexing (TDM) or frequency division multiplexing (FDM). The transmit circuitry <NUM> may transmit the plurality of multiplexed uplink physical channels in an uplink super-frame that is comprised of a plurality of uplink subframes.

Within the narrow system bandwidth, the receive circuitry <NUM> may receive a plurality of multiplexed downlink physical channels. The plurality of downlink physical channels may be multiplexed according to TDM or FDM. The receive circuitry <NUM> may receive the plurality of multiplexed downlink physical channels in a downlink super-frame that is comprised of a plurality of downlink subframes.

The transmit circuitry <NUM> and receive circuitry <NUM> may transmit and receive, respectively, HARQ acknowledgment (ACK) and/or negative acknowledgement (NACK) messages across air interface <NUM> according to a predetermined HARQ message schedule. The predetermined HARQ message schedule may indicate uplink and/or downlink super-frames in which the HARQ ACK and/or NACK messages are to appear.

<FIG> also illustrates eNB <NUM>, in accordance with various embodiments. The eNB <NUM> circuitry may include control circuitry <NUM> coupled with transmit circuitry <NUM> and receive circuitry <NUM>. The transmit circuitry <NUM> and receive circuitry <NUM> may each be coupled with one or more antennas that may be used to enable communications via air interface <NUM>.

The control circuitry <NUM> may be adapted to perform operations associated with MTC. The transmit circuitry <NUM> and receive circuitry <NUM> may be adapted to transmit and receive data, respectively, within a narrow system bandwidth (e.g., <NUM>). The control circuitry <NUM> may perform various operations such as those described elsewhere in this disclosure related to an eNB.

Within the narrow system bandwidth, the transmit circuitry <NUM> may transmit a plurality of multiplexed downlink physical channels. The plurality of downlink physical channels may be multiplexed according to TDM or FDM. The transmit circuitry <NUM> may transmit the plurality of multiplexed downlink physical channels in a downlink super-frame that is comprised of a plurality of downlink subframes.

Within the narrow system bandwidth, the receive circuitry <NUM> may receive a plurality of multiplexed uplink physical channels. The plurality of uplink physical channels may be multiplexed according to TDM or FDM. The receive circuitry <NUM> may receive the plurality of multiplexed uplink physical channels in an uplink super-frame that is comprised of a plurality of uplink subframes.

The transmit circuitry <NUM> and receive circuitry <NUM> may transmit and receive, respectively, HARQ ACK and/or NACK messages across air interface <NUM> according to a predetermined HARQ message schedule. The predetermined HARQ message schedule may indicate uplink and/or downlink super-frames in which the HARQ ACK and/or NACK messages are to appear. MTC may then be implemented across air interface <NUM> using the circuitry of UE <NUM> and eNB <NUM>. MTC enables a ubiquitous computing environment to enable devices to efficiently communicate with each other. IoT services and applications stimulate the design and development of MTC devices to be seamlessly integrated into current and next generation mobile broadband networks such as long term evolution (LTE) and LTE-Advanced communication systems that operate according to <NUM>rd generation partnership project (3GPP) standards (e.g., <NPL>).

These existing mobile broadband networks were designed to optimize performance mainly for human type of communications and thus are not designed or optimized to meet the MTC related requirements. MTC systems as described herein function to lower device costs, enhanced coverage, and reduced power consumption. Embodiments described herein particularly reduce cost and power consumption by reducing the system bandwidth, which is corresponding to roughly a single Physical Resource Block (PRB) of existing LTE design. This cellular IoT using reduced system bandwidth could potentially operate in a re-allocated global system for mobile communications (GSM) spectrum, within the guard bands of an LTE carrier, or dedicated spectrum.

When LTE system bandwidth is reduced to a lower bandwidth, certain physical channel designs in existing LTE system cannot be reused because the channel standards are not compatible with the lower bandwidth constraint. Embodiments herein thus describe devices, systems, apparatus, and methods for MTC with narrowband deployment to address the issues identified above due to the narrower bandwidth constraint (e.g., PBCH, SCH, physical random access channel (PRACH), etc.).

Embodiments may thus include a super-frame structure where multiple physical channels can be multiplexed in a TDM manner; control channel design for MTC with narrowband deployment; and HARQ procedure with various number of HARQ processes for MTC with narrowband deployment.

Although the embodiments described below use a <NUM> bandwidth, the design may be extended to other narrow bandwidth (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and etcetera). In addition, the MTC is used as the initial target application for the proposed narrow-band design, the design maybe be extended to other narrow-band deployed applications, (e.g., Device-to-Device, IoT, etc.).

Various physical channels may be used as part of such an MTC. <FIG> illustrates one possible implementation of such; channels in channel design <NUM> are illustrated within super-frames <NUM>, <NUM>, and <NUM> for both download <NUM> and upload <NUM> paths. These physical channels include, but are not limited to, a synchronization channel (M-SCH) <NUM>, a physical broadcast channel (M-PBCH) <NUM>, a control channel <NUM>, a physical downlink shared channel (M-PDSCH) <NUM>, a physical random access channel (M-PRACH) <NUM>, a physical uplink control channel (M-PUCCH) <NUM>, and a physical uplink shared channel (M-PUSCH) <NUM>. These channels and other potential channels are described below.

MTC Synchronization Channel (M-SCH) <NUM> may include the MTC Primary Synchronization Signal (M-PSS) and/or MTC Secondary Synchronization Signal (M-SSS). It may be used to support time and frequency synchronization and provide the UE with the physical layer identity of the cell and the cyclic prefix length. Note that M-SCH may or may not be utilized to distinguish the Frequency Division Duplex (FDD) and Time Division Duplex (TDD) system although the TDD may not need to be supported in MTC system with narrowband deployment.

MTC Physical Broadcast Channel (M-PBCH) <NUM> carries MTC Master Information Block (M-MIB), which consists of a limited number of the most frequently transmitted parameters for initial access to the cell.

The MTC control channel includes MTC Physical Downlink Control Channel (M-PDCCH) and/or MTC Physical Control Format Indicator Channel (M-PCFICH) and/or MTC Physical Hybrid ARQ Indicator Channel (M-PHICH). Note that for the downlink data transmission, time domain resource allocation is supported, while for the uplink data transmission, time domain and/or frequency domain resource allocation can be supported.

M-PDSCH <NUM> is used for all user data, as well as for broadcast system information which is not carried on the PBCH <NUM>, and for paging messages.

M-PUSCH <NUM> is used for uplink data transmission. It may be used to carry MTC Uplink Control Information (M-UCI) for MTC with narrowband deployment.

M-PRACH <NUM> is used to transmit the random access preamble. For initial access, it is utilized to achieve uplink synchronization.

M-PUCCH <NUM> is used to carry M-UCI. In particular, scheduling requests and HARQ acknowledgements for received M-SCH <NUM> transport blocks can be supported in M-PUCCH <NUM> transmission. Given the nature of narrowband transmission, it may not be beneficial to support the channel state reports in M-PUCCH <NUM>, which is mainly used to facilitate channel dependent scheduling.

MTC Physical Multicast Channel (M-PMCH) is used to support Multimedia Broadcast and Multicast Services (MBMS).

<FIG> illustrates a system design for MTC with narrowband deployment. In the system design, a certain number of subframes are formed as a super-frame (e.g., X subframes are used to form a super-frame as shown in <FIG>). The starting subframe and duration of the super-frame can be predefined or configured by eNB, where in the latter case, scheduling flexibility can be provided depending on specific system configuration, traffic scenarios, and the like. The duration of the super-frame and the corresponding number of subframes in a super-frame is determined at least in part based on the bandwidth of the narrowband deployment. In various embodiments, the super-frame duration is configured to enable compatibility with standard bandwidth LTE systems for MTC communications operating at narrow bandwidths as described above. In one embodiment, this configuration information can be included in the MIB conveyed in the M-PBCH or it can be carried in another system information block (SIB).

In the super-frame, multiple physical channels are multiplexed in a TDM or FDM) manner. More specifically, in the download (DL) <NUM>, either control channel/M-PDSCH or M-SCH/M-PBCH/M-PDSCH/control channel can be multiplexed in one super-frame. For example, as illustrated, super-frame <NUM> includes M-SCH 209A, M-PBCH 210A, Control channel 220A, and M-PDSCH 230A in the DL <NUM> of super-frame <NUM> and M-PRACH240A, M-PUCCH 250A, and M-PUSCH 260A as segments in the upload (UL) <NUM> of super-frame <NUM>. Thus, M-PRACH/M-PUCCH/PUSCH can be multiplexed in one super-frame. Note that UL <NUM> and DL <NUM> may have certain subframes offset to allow additional processing time. This super-frame structure is also beneficial to address the issue in the coverage limited scenarios. In particular, periodicity of a super-frame can be extended to allow more repetitions for DL <NUM> and UL <NUM> transmission, thereby improving the link budget. In certain embodiments, for example, a coverage enhancement target is selected for a system. A coverage enhancement target may be a link budget improvement associated with a periodicity of the super-frame structure. In other words, by increasing the size of a super-frame within the super-frame structure by, for example, increasing the number of subframes in a super-frame and thereby increasing the percentage of a super-frame devoted to data instead of overhead, the link budget is improved. In other embodiments, the size of a super-frame may be based, at least in part, on the bandwidth of the MTC system. In certain embodiments, a superframe may be set to match the amount of data in an MTC super-frame with the amount of data in a single frame (e.g. <NUM> subframes) in a standard LTE or LTE-advanced system. In other embodiments, the structure of a superframe may be based on a combination of coverage enhancement targets and compatibility with other systems based on the bandwidth of the MTC system.

In one embodiment, a MTC region can be defined in order to coexist with a current LTE system. In particular, the starting orthogonal frequency division multiplexing (OFDM) symbols of the MTC region in each subframe can be predefined or configured by a higher layer. For instance, the starting symbol of the MTC region can be configured after the PDCCH region in the legacy LTE system.

In the DL <NUM>, M-PDSCH transmission is scheduled and follows M-PDCCH transmission. Unlike the current LTE specification, cross-subframe scheduling is employed for a MTC system with narrowband deployment. To avoid the excessive blind decoding attempts for M-PDCCH, the starting subframe of M-PDCCH is limited to a subset of the subframes. The configuration regarding the periodicity and offset of M-PDCCH transmission can be predefined or configured by eNB in a device-specific or cell-specific manner. In one embodiment, this configuration information can be included in the MIB conveyed in the M-PBCH <NUM>.

M-PBCH <NUM> is transmitted with periodicity of Y subframes, preceded by an M-SCH <NUM> transmission. To reduce the overhead and improve the spectrum efficiency, M-PBCH <NUM> is less frequently transmitted compared to M-PDCCH. In the case when M-PDCCH transmission is collided with M-SCH <NUM> and M-PBCH <NUM>, the starting subframe of M-PDCCH is delayed by N subframes, where N is the number of subframes allocated for M-SCH <NUM> and M-PBCH <NUM> transmission.

Note that certain super-frames can be configured as MBMS Single Frequency Network (MBSFN) super-frames. The M-PBCH <NUM> may be allocated after the control region in the configured MBSFN super-frame. The configuration information can be configured and transmitted (broadcast or unicast/groupcast) by eNB. As in the existing LTE specification, extended Cyclic Prefix (CP) can be used to facilitate the efficient MBSFN operation by ensuring the signals remain within the CP at the UE receivers.

In the UL, M-PUCCH <NUM> and M-PUSCH <NUM> are transmitted after M-PRACH in one super-frame. Although as shown in the <FIG>, M-PUCCH is followed by M-PUSCH transmission, it can be transmitted in the middle of M-PUSCH or after M-PUSCH. The time location of M-PRACH, M-PUCCH, and M-PUSCH can be predefined or configured by eNB. In one embodiment, this configuration information can be included in the MIB conveyed in the M-PBCH.

In one example, M-PUSCH is transmitted in a subframe #<NUM>-#<NUM> and #<NUM>-#<NUM>, while M-PUCCH is transmitted in the subframe #<NUM>. In another example, M-PUSCH is transmitted in the subframe #<NUM>-#<NUM>, while M-PUCCH is transmitted in the subframe #<NUM>. Note that in order to allow adequate processing time for M-PDCCH decoding, the starting subframe of the M-PUSCH transmission may offset certain number of subframes relative to the last subframe of the M-PDCCH transmission.

In one embodiment, M-PCFICH can be considered in the control channel as the current LTE specification. However, unlike the PCFICH in the existing LTE standard, M-PCFICH carries a MTC Control Format Indicator (M-CFI) which is used to indicate the information for M-PDCCH and M-PDSCH transmission (e.g., the time/frequency locations of M-PDCCH transmission). In this case, control channel overhead can be adjusted according to a particular system configuration, traffic scenario, and channel conditions. To simplify the specification effort and implementation, some existing PCFICH designs in current LTE specification can be reused for M-PCFICH design, (e.g., modulation scheme, layer mapping and precoder design). In this case, <NUM>-PCFICH symbols are grouped into <NUM> symbol quadruplets (e.g., resource elements), and each symbol quadruplet can be allocated into one MTC resource element group (M-REG). In other embodiments, other groupings may be used. For example, in another embodiment, the time/frequency locations for M-PDCCH and/or M-PDSCH are predetermined or configured by the higher layers. In this case, M-PCFICH is not needed in the control channel design.

Furthermore, M-PHICH may or may not be included in the control channel. In one embodiment, M-PHICH is not needed in the control channel design. This can be considered if HARQ is not supported for MTC with narrowband deployment or in the case when M-PHICH functionality may be replaced by M-PDCCH.

In another embodiment, M-PHICH is supported to carry the HARQ ACK/NACK, which indicates whether the eNB has correctly received a transmission on the PUSCH. The number of PHICH groups for M-PHICH transmission can be predefined or configured by eNB. In one embodiment, the configuration information can be broadcast in the MTC Master Information Block (M-MIB) conveyed in the MTC Physical Broadcast Channel (M-PBCH) or broadcast in MTC System Information Block (M-SIB). To simplify the specification effort and implementation, some existing PHICH designs in current LTE specification can be reused for M-PHICH design (e.g., modulation scheme, layer mapping, and precoder design). In this case, <NUM> symbols for one M-PHICH group are grouped into <NUM> symbol quadruplets, and each symbol quadruplet can be allocated into one MTC resource element group (M-REG).

In the case when M-PCFICH and M-PHICH are supported, several options can be considered in the control region design for MTC with narrowband deployment as follows.

In one embodiment, M-PCFICH is located in the first K<NUM> subframes of the control region while M-PHICH is allocated in the last K<NUM> subframes of the control region. In addition, M-PDCCH is allocated in the resource elements which are not assigned for M-PCFICH and M-PHICH in the control region.

In another embodiment, M-PCFICH is located in the first M<NUM> subframes of the control region while M-PHICH is located in the M<NUM> subframes of the data region. Similarly, M-PDCCH and M-PDSCH are allocated in the resource elements which are not assigned for M-PCFICH in the control region and M-PHICH in the data region, respectively.

Note that in the example embodiments shown below, continuous resource allocations are considered for MTC control region. Distributed resource allocation for the MTC control region can be easily extended in other embodiments.

<FIG> illustrates one implementation of a control channel <NUM>, according to some embodiments. <FIG> shows control region <NUM> within super-frame <NUM>, with control region <NUM> followed by data region <NUM>. Control region <NUM> includes M-PCFICH <NUM> in subframe <NUM>, M-PHICH 350A in subframe <NUM>, and M-PHICH <NUM> in subframe <NUM>, with M-PDCCH elements in all subframes including M-PDCCH <NUM> in subframe <NUM>. In this embodiment, M-PCFICH <NUM> is located in the first K<NUM> subframes of the control region, while M-PHICH 350A is allocated in the last K<NUM> subframes of the control region, where K<NUM> < (Ncontrol -<NUM>), K<NUM> ≤ (Ncontrol -<NUM>) and Ncontrol is the number of subframes allocated for control channel. Furthermore, the M-PDCCH <NUM> transmission is rate-matched or punctured around the allocations for M-PCFICH <NUM> and M-PHICH 350A transmission. Note that K<NUM> and K<NUM> can be predefined or configured by higher layers.

For M-PCFICH <NUM> resource mapping, four symbol quadruplets can be either separated by approximately one-fourth of the K<NUM> subframes or allocated in the contiguous M-REGs, with the starting position derived from the physical cell identity. Similarly, for M-PHICH 350A resource mapping, three symbol quadruplets can be either separated by approximately one-third of the K<NUM> subframes or allocated in the contiguous M-REGs, with the starting position derived from the physical cell identity.

The embodiment of <FIG> shows one example of the control region design option <NUM> for MTC with narrowband deployment. In this example, M-PCFICH <NUM> is allocated and equally distributed in the first subframe of the control region (i.e., K<NUM> = <NUM>). Similarly, M-PHICH 350A is equally distributed from the second subframe to the last subframe of the control region (i.e., K<NUM> = (Ncontrol -<NUM>)).

<FIG> illustrates another example of the control region design for MTC with narrowband deployment. In this example, M-PCFICH is allocated and equally distributed in the first subframe of the control region (i.e., M<NUM> = <NUM>). Similarly, M-PHICH is equally distributed in the data region (i.e., M<NUM> = Ndata).

Similar to the embodiment of <FIG>, <FIG> shows control region <NUM> in super-frame <NUM> with subframes <NUM>, <NUM>, and M-PCFICH <NUM>. Data region <NUM> follows control region <NUM>. M-PHICH <NUM>, however, is within data region <NUM>. In this option, M-PCFICH <NUM> is located in the first M<NUM> subframes of the control region <NUM>, while M-PHICH <NUM> is located in the M<NUM> subframes of the data region, where M<NUM> < (Ncontrol -<NUM>), M<NUM> ≤ Ndata, and Ndata is the number of subframes allocated for the data region. <FIG> particularly shows these in the first subframe, while additional embodiments may use related configurations as stated above. Similarly, M-PDCCH and M-PDSCH are allocated in the resource elements that are not assigned for M-PCFICH <NUM> in the control region and M-PHICH <NUM> in the data region, respectively. Note that M<NUM> and M<NUM> can be predefined or configured by higher layers.

Similar to the initial embodiment of control channel <NUM>, four symbol quadruplets for M-PCFICH <NUM> transmission can be either separated by approximately one-fourth of the M<NUM> subframes or allocated in the contiguous M-REGs, with the starting position derived from the physical cell identity. For M-PHICH <NUM> resource mapping, three symbol quadruplets can be either separated by approximately one-third of the M<NUM> subframes or allocated in the contiguous M-REGs in the data region, with the starting position derived from the physical cell identity.

<FIG> and <FIG> illustrate upload and download HARQ procedure with two HARQ processes implemented by a UE <NUM> and an eNB <NUM>. <FIG> shows a download HARQ procedure with two HARQ processes shown as HARQ <NUM> and HARQ <NUM> across super-frames <NUM>-<NUM>. <FIG> shows an upload HARQ procedure with two HARQ processes shown as HARQ <NUM> and HARQ <NUM> across super-frames <NUM>-<NUM>.

For the DL HARQ procedure of <FIG>, in the super-frame <NUM>, M-PDSCH with HARQ <NUM> process is scheduled and transmitted. After UE <NUM> decodes the M-PDSCH, it feeds back ACK/NACK to eNB <NUM> via M-PUCCH in the super-frame <NUM>. In the case with NACK, eNB <NUM> would schedule the retransmission in the super-frame <NUM>. Similarly, for HARQ <NUM> process, initial transmission and retransmission for M-PDSCH are scheduled in the super-frame <NUM> and <NUM>, respectively, while the ACK/NACK feedback is transmitted via M-PUCCH in the super-frame <NUM>. Unlike the existing LTE specification, the M-PUCCH resource index for HARQ acknowledgement can be associated with the index of either the first control channel elements (CCE) in the M-PDCCH or the starting subframe of the M-PDCCH or the combination of both for the corresponding M-PDSCH transmission. In another embodiment, the M-PUCCH resource index for HARQ acknowledgement can be indicated by the starting subframe of M-PDSCH transmission.

For the UL HARQ procedure of <FIG>, in the super-frame <NUM>, M-PUSCH with HARQ <NUM> process is scheduled and transmitted. Then eNB <NUM> will send the ACK/NACK via M-PHICH in the super-frame <NUM>. If NACK is received by MTC UE <NUM>, M-PUSCH retransmission would occur in the super-frame <NUM>. A similar design principle is also applied for HARQ <NUM> process. Unlike the existing LTE specification, the M-PHICH index can be associated with the index of the starting subframe used for the corresponding M-PUSCH transmission.

<FIG> and <FIG> show upload and download HARQ procedures for four HARQ processes. <FIG> shows download processes HARQ <NUM>, <NUM>, <NUM>, AND <NUM> across superframes <NUM>-<NUM> between UE <NUM> and eNB <NUM>. <FIG> shows upload HARQ processes HARQ <NUM>, <NUM>, <NUM>, and <NUM> across super-frames <NUM>-<NUM> for eNB <NUM> and UE <NUM>.

As shown in <FIG>, for DL HARQ processes, UE 601would provide the ACK/NACK feedback via M-PUCCH with a two super-frame delay after it receives the M-PDSCH transmission. Subsequently, the retransmission occurs two super-frames later after eNB <NUM> receives the NACK.

For UL HARQ processes, the gap between M-PUSCH transmission and ACK/NACK feedback via M-PHICH, as well as between ACK/NACK feedback and M-PUSCH retransmission, is similarly two super-frames.

The same design principle can be generalized and applied for the HARQ procedure with <NUM>×M HARQ processes (M><NUM>). More specifically, the gap between the data transmission (M-PDSCH in the DL and M-PUSCH in the UL) and the ACK/NACK feedback (M-PUCCH in the DL and M-PHICH in the UL), as well as between ACK/NACK feedback and the data retransmission, is M super-frames.

In another embodiment, in the case of HARQ procedure with <NUM>×M HARQ processes (M≥<NUM>), an unbalanced processing gap can be introduced to allow an increased time-budget at the UE side. In this option, delay between the retransmission of M-PDSCH and M-PUCCH transmission (for DL HARQ), and the delay between the M-PUSCH retransmission and M-PHICH transmission (for UL HARQ) does not scale with an increase in the number of HARQ processes. For instance, in the case for four HARQ processes with M = <NUM>, for DL HARQ, a delay of three super-frames is available for transmission of the M-PUCCH with the DL HARQ information, while a retransmission (in case of a NACK) is scheduled in the next super-frame itself.

In another embodiment, multiple HARQ processes can be scheduled in one super-frame. In this option, multiple M-PDCCHs can be used to schedule multiple M-PDSCHs and/or M-PUSCHs in one super-frame.

<FIG> and <FIG> then illustrate methods that may be performed by a UE and an associated eNB such as UE <NUM> and eNB <NUM> of <FIG>. The method <NUM> may be performed by a UE such as UE <NUM> or any UE described herein, and may include an operation <NUM> for multiplexing a plurality of downlink physical channels. The plurality of physical channels may be multiplexed according to TDM or FDM.

The method <NUM> may further include an operation <NUM> for transmitting a downlink super-frame that includes the plurality of multiplexed downlink physical channels. In various embodiments, the downlink super-frame may be of a predetermined duration (e.g., comprised of a predetermined number of downlink subframes). The downlink super-frame may comprise a predetermined starting downlink subframe. The operation <NUM> for transmitting the downlink super-frame may be associated with a predetermined periodicity for transmission.

The method <NUM> may further include an operation <NUM> for receiving a HARQ ACK and/or NACK message based on the transmitting of the downlink super-frame. In various embodiments, the HARQ ACK and/or NACK message may be received in an uplink super-frame (e.g., a predetermined plurality of uplink subframes) according to a predetermined schedule for HARQ ACK/NACK message communication (e.g., a HARQ ACK/NACK message may be scheduled to be received in an uplink super-frame immediately following in time the transmission of the downlink super-frame). Optional operations may include retransmitting the plurality of multiplexed downlink physical channels (e.g., in another downlink super-frame according to a predetermined schedule for retransmission) if a HARQ NACK message is received based on the transmitting of the downlink super-frame.

<FIG> shows corresponding method <NUM> that may be performed by circuitry of an eNB such as eNB <NUM> or any eNB described herein. The method <NUM> may include an operation <NUM> for multiplexing a plurality of uplink physical channels. The plurality of uplink physical channels may be multiplexed according to TDM or FDM.

The method <NUM> may further include an operation <NUM> for transmitting an uplink super-frame that includes the plurality of multiplexed uplink physical channels. In various embodiments, the uplink super-frame may be of a predetermined duration (e.g., comprised of a predetermined number of uplink subframes). The uplink super-frame may comprise a predetermined starting uplink subframe or a starting uplink subframe that is signaled by an eNB in an information block (e.g., MIB or SIB). The operation <NUM> for transmitting the uplink super-frame may be associated with a predetermined periodicity for transmission, which may be predetermined or signaled by an eNB in an information block (e.g., MIB or SIB).

The method <NUM> may further include an operation <NUM> for receiving a HARQ ACK and/or NACK message based on the transmitting of the uplink super-frame. In various embodiments, the HARQ ACK and/or NACK message may be received in a downlink super-frame (e.g., a predetermined plurality of downlink subframes) according to a predetermined schedule for HARQ ACK/NACK message communication (e.g., a HARQ ACK/NACK message may be scheduled to be received in a downlink super-frame immediately following in time the transmission of the uplink super-frame). Optional operations may include retransmitting the plurality of multiplexed uplink physical channels (e.g., in another uplink super-frame according to a predetermined schedule for retransmission) if a HARQ NACK message is received based on the transmitting of the uplink super-frame.

<FIG> relate to embodiments for PCFICH in MTC with narrowband deployment. <FIG> illustrates aspects of PCFICH processing. PCFICH consists of two bits of information, corresponding to the three control-region sizes of one, two, or three OFDM symbols (two, three. or four for narrow bandwidths, e.g., <NUM>), which are coded into a <NUM>-bit codeword by rate <NUM>/<NUM> block code circuitry <NUM>. The <NUM> resulting coded bits are scrambled by scrambling circuitry <NUM> with a cell- and subframe-specific scrambling code to randomize inter-cell interference. These output bits are then quadrature phase-shift key (QPSK) <NUM> modulated. The resulting <NUM> symbols are mapped to <NUM> resource elements as illustrated by mapping <NUM> as part of subframe <NUM>. As the size of the control region is unknown until the PCFICH is decoded, the PCFICH is mapped to the first OFDM symbol of each subframe including subframe <NUM> in the embodiment shown.

The mapping <NUM> of the PCFICH to resource elements in the first OFDM symbol in the subframe is performed in groups of four resource elements, with the four groups being well separated in frequency to obtain good diversity. Four groups of four resource elements are shown in <FIG> as resource elements <NUM>, <NUM>, <NUM>, and <NUM>, with each group of resource elements including four resource elements as shown, for a total of <NUM> resource elements illustrated in <FIG>. Furthermore, to avoid collisions between PCFICH transmissions in neighboring cells, the location of the four groups in the frequency domain depends on the physical-layer cell identity.

In the existing standard LTE systems (where CFI is used to indicate the control-region sizes in OFDM symbols), M-CFI can be used to indicate the information for M-PDCCH and M-PDSCH transmissions. In some embodiments, this information contains the number of time/frequency units (e.g., symbol, slot, subframes, PRB, etc.) used for M-PDCCH and/or M-PDSCH transmission. For instance, M-CFI can be used to indicate the number of subframes used for M-PDCCH transmission.

In other embodiments, this information contains the time/frequency locations used for M-PDCCH and/or M-PDSCH transmission. For instance, M-CFI can be used to indicate which subframes in one super-frame are allocated for M-PDCCH. In still further embodiments, this information contains a set of time/frequency locations for M-PDCCH and/or M-PDSCH transmission. In other embodiments, M-CFI can be used to indicate the M-PHICH configuration (e.g., the number of M-PHICH groups). To simplify certain implementations, the same code words for CFI can be reused as listed in the Table <NUM>.

As illustrated by Table <NUM>, values (n<NUM>, n<NUM>, n<NUM>, n<NUM>) carried by the M-CFI can be predefined or configured by higher layers in certain embodiments. In some embodiments, the configuration information can be broadcast in the M-MIB conveyed in M-PBCH or broadcast in M-SIB.

In other embodiments, values (n<NUM>, n<NUM>, n<NUM>, n<NUM>) can be predefined according to the super-frame duration. For instance, in the case when M-CFI is used to indicate the number of subframes for M-PDCCH transmission: when super-frame duration spans <NUM>, we can set the number of M-PDCCH subframes to n<NUM> = <NUM>, n<NUM> = <NUM>, n<NUM> = <NUM>, n<NUM> = <NUM>. When super-frame duration spans <NUM>, we can set the (n<NUM>, n<NUM>, n<NUM>, n<NUM>) values to n<NUM> = <NUM>, n<NUM> = <NUM>, n<NUM> = <NUM>, n<NUM> = <NUM>.

In other embodiments, in the case when M-CFI is used to indicate a set of time/frequency locations for M-PDCCH transmission, n<NUM> indicates the first set (subframe #<NUM>, #<NUM>, #<NUM>, #<NUM>), n<NUM> indicates the second set (subframe #<NUM>, #<NUM>, #<NUM>), n<NUM> indicates the third set (subframe #<NUM>, #<NUM>) and n<NUM> indicates the fourth set (subframe #<NUM>). In still additional embodiments, additional numbers of codewords can be introduced to allow finer granularity for the indication of the number of subframes in the control region. In this case, the M-CFI codewords need to be redefined in the specification.

As mentioned above with respect to <FIG>, after the channel coding, scrambling is performed in order to randomize the interference. In some M-PCFICH design embodiments, the same scrambling procedure as is used in the existing standard LTE specification used for PCFICH can be applied to M-PCFICH. In one embodiment, the same scrambling seed as defined in the LTE specification can be reused as: <MAT> where ns is the slot number and <MAT> is the cell ID.

In other embodiments, the scrambling seed can be defined as a function of the cell ID only. For instance, the scrambling seed can be given as: <MAT>.

In additional embodiments, the scrambling seed can be defined as a function of the cell ID and super-frame number, i.e., <MAT> where nsuperframe is the super-frame number. For instance, the scrambling seed can be given as: <MAT>.

In additional embodiments, the scrambling seed can be defined as a function of the slot number (ns), the cell ID, and super-frame number. For instance, it can be given as: <MAT>.

Subsequently, the same modulation scheme (e.g., QPSK as illustrated by QPSK modulation <NUM> of <FIG>), layer mapping (e.g.,. as illustrated by mapping <NUM>), and precoding can be reused for M-PCFICH design to simplify the implementation and maintain compatibility of certain aspects with existing LTE systems.

In various embodiments, M-PCFICH can be either located at the beginning of or distributed in the control region. In current LTE specification, a REG is defined for up to four OFDM symbols. For certain embodiment MTC systems with narrowband deployment, M-REG can be extended to one subframe to ensure adequate resources allocated for the control channel. In particular, in certain embodiments, four resource elements (REs) are mapped to the M-REG not used for reference signals (e.g., Cell-specific Reference Signal (CRS) or other MTC related reference signals if applicable) in the increasing order of first subcarrier and then OFDM symbol.

<FIG> illustrate M-REG mapping patterns. In different embodiments, different mapping patterns with one subframe and one, two, or four antenna ports in the case of normal CP may be used. As illustrated, <NUM>-REGs are available in one subframe with one or two antenna ports in the case of normal CP, as shown by <FIG>, and <NUM>-REGs are available in one subframe in the case of normal CP with four antenna ports as shown by <FIG>. It will be apparent that the same design principle can be applied to extended CP to generate an equivalent mapping pattern to match the extended CP case. In this case, the total number of available M-REGs in one subframe is reduced to <NUM> and <NUM> with one, two, or four antenna ports, respectively.

In the examples shown below, an M-REG mapping rule is designed based on CRS pattern. It can be easily extended to other reference signal patterns (e.g., dedicated MTC DL reference signal (M-RS)).

<FIG> show M-REG mapping patterns for additional embodiments. In the embodiments illustrated by <FIG>, OFDM symbols <NUM> and <NUM> are not used for M-REG resource mapping in the case of normal CP. Note that these two symbols can be used for M-PDCCH transmission. <FIG> illustrate the M-REG mapping pattern in one subframe with one, two, or four antenna ports in the case of normal CP in such an alternate embodiment. As shown by <FIG>, <NUM>-REGs are available in one subframe with one-half of the antenna ports in the case of normal CP, and as shown by <FIG>, <FIG> M-REGs are used for four antenna ports in the case of normal CP.

The embodiments of <FIG> can allow unified M-REG mapping design between normal and extended CP cases as well as lattice-type pattern design for M-PCFICH resource mapping. Such embodiments may operate where: <MAT> denotes symbol quadruplet i for antenna port p for M-PCFICH transmission, where y(p)(k), k = <NUM>,. ,<NUM> represents the M-PCFICH signal for antenna port p, and where p = <NUM>,. , P - <NUM> and the number of antenna ports for cell-specific reference signals P ∈ {<NUM>,<NUM>,<NUM>}. In such embodiments, the M-PCFICH is being transmitted on the same set of antenna ports as the M-PBCH. According to these two M-REG mapping patterns, several options can be considered for M-PCFICH resource mapping.

<FIG> illustrate M-PCFICH resource mapping for the M-REG mapping pattern of <FIG>. <FIG> illustrates the mapping pattern in the case of cell ID <NUM>, and <FIG> illustrates the mapping pattern in the case of cell ID <NUM>. In a first such embodiment, in the case for M-REG mapping pattern illustrated by <FIG>, z(p)(<NUM>) and z(p)(<NUM>) are mapped to the M-REGs in the slot <NUM> while z(p)(<NUM>) and z(p)(<NUM>) are mapped to the M-REGs in the slot <NUM>. In order to reduce the risk of inter-cell M-PCFICH collisions, M-PCFICH mapping depends on the physical-layer cell identity. The M-PCFICH resource mapping rule can be defined as follows: z(p)(<NUM>) is mapped to the M-REG represented by k = k; z(p)(<NUM>) is mapped to the M-REG represented by k = k + <NUM>; z(p)(<NUM>) is mapped to the M-REG represented by k = k + (NREG/<NUM>); and z(p)(<NUM>) is mapped to the M-REG represented by k = k + <NUM> + (NREG/<NUM>); where k is the M-REG index; <MAT>; and NREG is the number of M-REGs in one subframe. In the normal CP case, Nreg=<NUM> for one or two antenna ports and Nreg=<NUM> for four antenna ports. In the extended CP case, Nreg=<NUM> for one or two antenna ports and Nreg=<NUM> for four antenna ports. According to resource mapping rules, for Cell ID <NUM>, M=PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, and <NUM>, and for Cell ID <NUM>, M-PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, and <NUM>. Nreg/<NUM> distinct M-PCFICH resource regions for different cells can be multiplexed in one subframe in such embodiments.

<FIG> illustrate M-PCFICH resource mapping for alternate embodiments where four symbol quadruplets for M-PCFICH transmission are equally spread in one subframe. In particular, the M-PCFICH resource mapping rule fur such an embodiment may be defined as follows:.

where k is the M-REG index; <MAT>; and NREG is the number of M-REGs in one subframe. In the normal CP case, NREG = <NUM> for one or two antenna ports and NREG = <NUM> for four antenna ports. In the extended CP case, NREG = <NUM> for one or two antenna ports and NREG = <NUM> for four antenna ports.

<FIG> illustrates this mapping pattern for M-REG mapping patterns as illustrated in <FIG> with one or two antenna ports in the case of normal CP for cell ID <NUM>, and <FIG> illustrates the corresponding mapping for cell ID <NUM>. According to this resource mapping, for cell ID <NUM>, M-PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, and <NUM>, and for cell ID <NUM>-PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, and <NUM>.

<FIG> illustrate another embodiment where four symbol quadruplets for M-PCFICH transmission can be allocated in contiguous M-REGs, with the starting position derived from the physical cell identity. The M-PCFICH resource mapping rule can be defined as follows:.

<FIG> illustrates the M-PCFICH resource mapping of these rules for M-REG mapping pattern of <FIG> with one or two antenna ports in the case of normal CP. According to this third embodiment of a resource mapping rule, for Cell ID <NUM>, M-PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, and <NUM>. Similarly, for Cell ID <NUM>, M-PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, and <NUM>.

The above shows application of three resource mapping rules to the first M-REG mapping pattern illustrated by <FIG>. Similar additional embodiments of resource mapping rules may be applied to the second M-REG mapping pattern illustrated by <FIG>. In these additional embodiments for the second M-REG mapping pattern, each slot in one subframe is divided into two sub-regions. In the case of normal CP, symbols <NUM>-<NUM> and <NUM>-<NUM> are located in the first sub-region in the slot <NUM> and <NUM>, respectively, while symbols <NUM>-<NUM> and <NUM>-<NUM> are in the second sub-region in the slot <NUM> and <NUM>, respectively. In the case of extended CP, symbols <NUM>-<NUM> and <NUM>-<NUM> are located in the first sub-region in the slot <NUM> and <NUM>, respectively, while symbols <NUM>-<NUM> and <NUM>-<NUM> are in the second sub-region in the slot <NUM> and <NUM>, respectively.

In various such embodiments, each symbol quadruplet for M-PCFICH transmission is mapped into one of the sub-regions. More specifically, z(p)(<NUM>) and z(p)(<NUM>) are mapped to the M-REGs in the sub-region <NUM> and sub-region <NUM> of the slot <NUM>, respectively; while z(p)(<NUM>) and z(p)(<NUM>) are mapped to the M-REGs in the sub-region <NUM> and sub-region <NUM> of the slot <NUM>, respectively.

<FIG> illustrate a first resource mapping for the M-REG mapping pattern of <FIG>. In such an embodiment, the M-REG location used for M-PCFICH transmission is the same across slots and sub-regions. Similarly, M-PCFICH mapping in such embodiments depends on the physical-layer cell identity to reduce the risk of inter-cell M-PCFICH collisions. The M-PCFICH resource mapping rule can be defined as follows:.

where k is the M-REG index; <MAT>; and NREG is the number of M-REGs in one subframe. NREG = <NUM> for one or two antenna ports and NREG = <NUM> for four antenna ports.

<FIG> illustrates this M-PCFICH resource mapping option for the M-REG mapping pattern illustrated by <FIG> with ½ antenna ports in the case of normal CP with cell ID <NUM>. <FIG> illustrates the corresponding mapping with cell ID <NUM>. According to this resource mapping rule, for Cell ID <NUM>, M-PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, <NUM>. For Cell ID <NUM>, M-PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, <NUM>.

<FIG> illustrate an embodiment with RE hopping between two sub-regions in the same slot. <FIG> illustrates such an embodiment of M-PCFICH resource mapping with the M-REG mapping pattern illustrated by <FIG> with ½ antenna ports in the case of normal CP and cell ID <NUM>. <FIG> illustrates the corresponding mapping with cell ID <NUM>. Resource mapping with RE hopping between two sub-regions in the same slot results in resource mapping for cell ID <NUM> where M-PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, <NUM>. Similarly, for Cell ID <NUM>, M-PCFICH is mapped to M-REG <NUM>, <NUM>, <NUM>, <NUM>.

In still further embodiments of M-PCFICH resource mapping, M-REG can be extended to K subframes, where K can be predefined or configured by higher layer. The same design principle for the two M-REG mapping patterns illustrated by <FIG> and <FIG> can be extended to K subframes. Furthermore, the patterns illustrated can be easily extended to the case when M-PCFICH spans K subframes. Such embodiments increase the capacity for multiplexing more cells with distinct M-PCFICH resources. However, as M-PCFICH spans multiple subframes, MTC UEs may store multiple subframes to decode the M-CFI contents, which may increase the decoding latency for control channel. Additionally, for such embodiments, the scrambling seed may not be defined as a function of the subframe number. Instead, the scrambling seed may be defined as a function of either a physical cell ID or a super-frame number or a combination of these two parameters as proposed above.

In some embodiments, an MTC region can be defined in order to coexist with current LTE system. In particular, the starting OFDM symbols of MTC regions in each subframe can be predefined or configured by a higher layer. In additional embodiments, M-REG can be defined within the MTC region. For instance, if the starting symbol for the MTC region is configured as <NUM>, then M-REG can be defined from symbol <NUM> to symbol <NUM> in one subframe or in each subframe of K subframes. In such embodiments, the same design principle as illustrated above for <FIG> can be applied for M-PCFICH resource mapping.

<FIG> describes a method <NUM> for PCFICH operation. In various embodiments, method <NUM> may be performed by circuitry of an eNB such as eNB <NUM>. Circuitry of such an eNB may be adapted to determine configuration information associated with wireless communication within the narrow system bandwidth, such as MTC. This configuration information may be associated with one or more of an M-PDCCH, an M-PDSCH, and/or an M-PHICH. The control circuitry may generate an M-CFI to indicate the determined configuration information to a UE. In various embodiments, the control circuitry may be adapted to map resource elements to one or more M-REGs for transmission through an M-PCFICH. Within the narrow system bandwidth, the transmit circuitry of an eNB may transmit the generated M-CFI through the M-PCFICH to a UE. Accordingly, the receive circuitry may be adapted to receive data from the UE based on the configuration information for MTC within the narrow system bandwidth. The method <NUM> may include an operation <NUM> for determining configuration information associated with MTC within a narrow system bandwidth. This configuration information may be associated with one or more of an M-PDCCH, an M-PDSCH, and/or an M-PHICH.

The method <NUM> may further include an operation <NUM> for generating an M-CFI to indicate the determined configuration information.

Operation <NUM> then involves transmitting the generated M-CFI through an M-PCFICH to a UE. In various embodiments, operation <NUM> may include operations associated with mapping resource elements to one or more M-REGs for transmission through the M-PCFICH. Accordingly, the UE communicating with the eNB may use the configuration information indicated by the M-CFI for MTC within narrow system bandwidth.

<FIG> describes a method <NUM>. Method <NUM> may be performed by a UE such as UE <NUM> of <FIG>. Within the narrow system bandwidth, the receive circuitry of such a UE may be configured to receive an M-CFI through an M-PCFICH from an eNB. Based on the M-CFI, the control circuitry of the UE may be adapted to detect configuration information associated with wireless communication within the narrow system bandwidth, such as MTC. This configuration information may be associated with one or more of an M-PDCCH, M-PDSCH, and/or an M-PHICH. Transmit circuitry of the UE may be adapted to transmit data from the UE within the narrow system bandwidth.

The UE circuitry may then perform method <NUM> which may include an operation <NUM> for receiving an M-CFI through an M-PCFICH from an eNB. Operation <NUM> then includes detecting configuration information based on the M-CFI for MTC within narrow system bandwidth. The detected configuration information be associated with one or more of an M-PDCCH, an M-PDSCH, and/or an M-PHICH. For example, the detected configuration information may indicate one or more time and/or frequency units (e.g., symbols, clots, subframes, physical resource blocks, etc.) that are to be used for MTC within narrow system bandwidth through one or more of the M-PDCCH, M-PDSCH, and/or M-PHICH.

<FIG> relate to embodiments for PHICH design in MTC with narrowband deployment. Certain such embodiments as described herein use scrambling on M-PHICH based on a super-frame number, as well as M-PHICH resource allocation based on a super-frame definition for a particular embodiment. Additionally, embodiments describe M-PHICH locations and mapping rules in conjunction with M-REG for MTC narrowband systems.

<FIG> illustrates aspects of PHICH processing. The PHICH carries the HARQ ACK/NACK which indicates whether an eNB such as eNB <NUM> has correctly received a transmission on the PUSCH. The HARQ indicator, which is a single bit of information per transport block, is repeated three times using repetition circuitry <NUM>, <NUM> for each PHICH in a PHICH group <NUM>, followed by binary phase shift key (BPSK) modulation circuitry <NUM> and <NUM> for each PHICH. Multiple PHICHs are mapped to the same set of resource elements, as illustrated in <FIG>. These constitute a PHICH group, shown as PHICH group <NUM>, where different PHICHs within the same PHICH group <NUM> are separated through different complex orthogonal codes <NUM> and <NUM> (e.g., Walsh sequences). The sequence length is four for the normal CP (or two in the case of the extended CP). After forming the composite signal representing the PHICHs in a group, cell-specific scrambling <NUM> is applied and the <NUM> scrambled symbols are mapped to three resource-element groups <NUM>, <NUM>, <NUM>, separated by approximately one-third of the downlink cell bandwidth. Note that a PHICH resource <NUM>, <NUM>, <NUM> is identified by the index pair ( <MAT>), where <MAT> is the PHICH group number and <MAT> is the orthogonal sequence index within the group. The PHICH index is implicitly associated with the index of the lowest uplink resource block used for the corresponding PUSCH transmission. In addition, cyclic shifts of the uplink demodulation reference signals configured for the different UEs are used to derive the PHICH index.

The number of PHICH groups such as PHICH group <NUM> for M-PHICH transmission can be predefined or configured by the eNB, such as eNB <NUM>. In one embodiment, the configuration information can be broadcast in the M-MIB conveyed in the M-PBCH or broadcast in M-SIB.

In additional embodiments, the number of PHICH groups can be predefined or configured depending on the super-frame duration. For instance, similar to the existing LTE specification, the number of the PHICH groups <MAT> is constant in all super-frames and given by <MAT> where Ng is provided by higher layers, and NSuperFrame is the duration of super-frame. For instance, Ng ∈ {<NUM>/<NUM> , <NUM>/<NUM> ,<NUM>,<NUM> }.

For M-PHICH processing in various embodiments, channel coding as used in the existing (high-bandwidth) LTE specification can be applied with ACK/NACK repeated three times. Furthermore, similar modulation mapping, orthogonal sequences, and procedures to generate a sequence of modulation symbols d(<NUM>),. ,d(Msymb -<NUM>) can be reused as in the current LTE standard, where Msymb is the number of symbols for M-PHICH transmission.

Additionally, in some embodiments, the same scrambling seed as defined in the LTE specification can be reused, which may be: <MAT> where ns is the slot number and <MAT> is the cell ID.

In additional embodiments, the scrambling seed can be defined as a function of the cell ID only. For instance, the scrambling seed can be given as <MAT> In still further such embodiments, the scrambling seed can be defined as a function of the cell ID and super-frame number, i.e., <MAT> where nsuperframe is the super-frame number. For instance, the scrambling seed can be given as <MAT> In still further embodiments, the scrambling seed can be defined as a function of the slot number (ns), the cell ID, and super-frame number. For instance, it can be given as <MAT>.

In these various embodiments, the resource group alignment, layer mapping, and precodings as used in accordance with standard LTE systems may be used for M-PHICH design as merged with the super-frame design of the embodiments described herein for simplicity in integration with such existing systems. As discussed above, various M-PHICH resource mappings may be used and allocated in either the control region or data region. Examples discussed above include a first embodiment where M-PHICH is allocated in the last K<NUM> subframes of the control region where K<NUM> ≤ (Ncontrol -<NUM>), and Ncontrol is the number of subframes allocated for control channel. Embodiments include a second embodiment where M-PHICH is located in the K<NUM> subframes of the data region, where K<NUM> ≤ Ndata, and Ndata is the number of subframes allocated for the data region. Embodiments discussed above include a third embodiment where M-PHICH is located in the first K<NUM> subframes within a super-frame. As a special case of the third embodiment, K<NUM>=<NUM>.

In the embodiments discussed below in <FIG>, continuous resource allocations are considered for MTC control regions. Distributed resource allocation for the MTC control region may be extended in various additional embodiments not particularly described, but which will be apparent based on the descriptions herein.

Let <MAT> where i = <NUM>,<NUM>,<NUM> denotes symbol quadruplet i for antenna port p , and where ỹ(p)(n) is the M-PHICH mapping unit from an M-PHICH group. Although the examples shown below consider the case that all the OFDM symbols are allocated for the M-REG resource mapping, similar design principles can be easily extended to the case where OFDM symbols in the MTC region as are allocated for the M-REG resource mapping as described above for PCFICH design. For instance, if the starting symbol for MTC region is configured as <NUM>, then M-REG can be defined from symbol <NUM> to symbol <NUM> in one subframe or in each subframe of K subframes.

As discussed above, M-REG can be defined and extended from an existing REG for one or more subframes for control channel design. In particular, four REs may be mapped to the M-REG)not used for reference signals (e.g., CRS or other MTC related reference signals if applicable) in the increasing order of first subcarrier and then OFDM symbol. In certain embodiments discussed below, M-REG mapping rules are designed based on CRS patterns. It will be apparent that additional embodiments may be derived from other reference signal patterns (e.g., dedicated M-RS).

Error! Reference source not found. <FIG> illustrates the M-REG resource mapping for two subframes with one or two antenna ports in the case of normal CP. The same design principle can be applied for four antenna ports and/or extended CP in multiple various different embodiments. In the embodiment illustrated by <FIG>, Nreg is defined as the number of M-REGs in one subframe. According to the M-REG resource mapping pattern, in the normal CP case, Nreg=<NUM> for one or two antenna ports and Nreg=<NUM> for four antenna ports. In the extended CP case, Nreg=<NUM> for one or two antenna ports and Nreg= <NUM> for four antenna ports.

For Kth subframe, the starting M-REG index is (K -<NUM>)· NREG and the last M-REG index is K · NREG -<NUM>. For instance, as shown in <FIG>, the starting and last M-REG index for the <NUM>nd subframe is <NUM> and <NUM> with one or two antenna ports in the case of normal CP, respectively.

In some embodiments, M-PHICH is equally distributed in the last K<NUM> subframes of the control region, where K<NUM> ≤ (Ncontrol -<NUM>). K<NUM> can be predefined or configured by higher layers. For instance, M-PHICH can be allocated from the second subframe to the last subframe of the control region. In another example embodiment, M-PHICH can be allocated in the last two subframes of the control region, which may help to alleviate the uplink processing timing issue when the number of HARQ processes is small. In various embodiments described herein for M-PHICH resource mapping, then, three symbol quadruplets in one M-PHICH group are separated by approximately one-third of the K<NUM> subframes, with the starting position derived from the physical cell identity. This resource mapping scheme can help exploit the benefits of time diversity and reduce the risk of inter-cell M-PHICH collisions. The M-PHICH resource mapping rule for option <NUM> can be defined as follows: Mapping to resource elements for M-PHICH transmission is defined in terms of symbol quadruplets according to steps <NUM>-<NUM> below:.

<FIG> illustrates one example of M-PHICH resource mapping, according to the above described embodiment with two subframes and ½ antenna ports in the case of normal CP. In the example, <MAT> and <MAT>. From the figure, it can be seen that the total number of M-REG nc is <NUM> and M-PHICH is transmitted in the M-REG <NUM>, <NUM>, and <NUM>.

<FIG> describes alternative embodiments using different resource mapping. In such alternate embodiments, three symbol quadruplets in one M-PHICH group are allocated in the contiguous M-REGs, with the starting position derived from the physical cell identity. The alternative M-PHICH resource mapping rule for can be defined as follows:.

<FIG> illustrates one example of alternative M-PHICH resource mapping just above for two subframes with one or two antenna ports in the case of normal CP. In the example, <MAT> and <MAT>. From <FIG>, it can be seen that the total number of M-REG nc is <NUM> and M-PHICH is transmitted in the M-REG <NUM>, <NUM>, and <NUM>.

<FIG> describe an additional alternative set of embodiments. In such embodiments, M-PHICH is allocated in the data region. More specifically, three symbol quadruplets can be either separated by approximately one-third of the K<NUM> subframes or allocated in the contiguous M-REGs in the data region, with the starting position derived from the physical cell identity. K<NUM> can be either predefined or configured by the higher layers.

In one embodiment, the same rule for M-REG and M-PHICH resource mapping as discussed above for <FIG> can be applied for the data region. In this case, M-PDSCH transmission is punctured or rate-matched around the REs allocated for M-PHICH transmission.

In certain other embodiments, M-PHICH is located in the REs near the reference signal, (e.g., CRS or dedicated M-RS), in order to improve the channel estimation performance for M-PHICH transmission. For instance, <NUM> REs in the center of <NUM> subcarriers that are assigned for CRS transmission can be grouped as an M-REG. <FIG> illustrates the M-REG resource mapping for two subframes with one or two antenna ports in the case of normal CP. In the example, M-REG is located in the center four REs in OFDM symbol #<NUM>, #<NUM>, #<NUM>, #<NUM> in each subframe in the case of normal CP and one or two antenna ports. In addition, the number of M-REGs in two subframes is eight.

Based on the proposed M-REG resource mapping pattern in the data region, M-PHICH resource mapping can follow the same principle as in option <NUM> (i.e., three symbol quadruplets in one M-PHICH group are separated by approximately one-third of K<NUM> subframes in the data region). Further, the same M-PHICH resource mapping rule can be applied for this option based on the proposed M-REG pattern. In such embodiments, M-PDSCH transmission is punctured or rate-matched around the REs allocated for M-PHICH transmission.

<FIG> illustrates the M-PHICH resource mapping as described in <FIG> for three subframes in the data region with one or two antenna ports in the case of normal CP. In such embodiments, <MAT> and <MAT>. In <FIG>, it can be seen that the total number of M-REG nc is <NUM> and M-PHICH is transmitted in the M-REG #<NUM>, #<NUM> and #<NUM>, which are allocated in the center four REs of the OFDM symbol #<NUM> in the first, second, and third subframe, respectively.

<FIG> describes additional embodiments, where M-PHICH is allocated in the increasing order of M-REGs, with the starting index derived from the physical cell ID. Similarly, M-PDSCH transmission is punctured or rate-matched around the REs allocated for M-PHICH transmission.

<FIG> illustrates the alternative M-PHICH resource mapping for three subframes in the data region with one or two antenna ports in the case of normal CP. In the example, <MAT> and <MAT>. From <FIG>, it can be seen that the total number of M-REG nc is <NUM> and M-PHICH is transmitted in the M-REG #<NUM>, #<NUM> and #<NUM>.

In addition to the embodiments above describing first and second options for M-PHICH resource mapping, in a third set of additional embodiments, M-PHICH is located in the first K<NUM> subframes within a super-frame. In certain embodiments, K<NUM> = <NUM>. A similar M-PHICH resource mapping mechanism as described above for <FIG> can be applied for such embodiments. More specifically, M-PHICH can be equally distributed or allocated in the contiguous M-REGs in the first K<NUM> subframes within a super-frame. As discussed above, particularly with respect to <FIG>, <FIG>, <FIG>, and <FIG>, a DL/UL HARQ procedure with various numbers of HARQ processes is proposed based on a super-frame structure. More specifically, for UL HARQ procedure with <NUM>×M HARQ processes, the gap between the M-PUSCH transmission and the ACK/NACK feedback in M-PHICH is M super-frames. According to such embodiments, for M-PUSCH transmissions scheduled from serving cell c in super-frame n, a UE shall determine the corresponding M-PHICH resource of serving cell c in super-frame n+ M. Similar to the existing LTE specification, M-PHICH resources can be identified by the index pair ( <MAT>), where <MAT> is the M-PHICH group number and <MAT> is the orthogonal sequence index within the group. In one embodiment, the M-PHICH resource index can be defined as: <MAT> where nDMRS is mapped from the cyclic shift for DMRS field; <MAT> is the spreading factor size used for M-PHICH modulation; <MAT> is the number of M-PHICH groups configured by higher layers; and IPRB_RA is the resource index of the corresponding M-PUSCH transmission as described by LTE standards. IPRB_RA can be defined as a function of either time or frequency locations, (e.g., symbol, slot, subframes, PRB, etc.) of the corresponding M-PUSCH transmission, or a function of any combinations of these parameters. For instance, in some embodiments, if TDM is considered for the UL data transmission, IPRB_RA can be defined as the starting subframe of the corresponding M-PUSCH transmission. In additional such embodiments, a M-PHICH resource index can be defined as: <MAT> In embodiments according to (<NUM>), the cyclic shift index is not used when deriving the M-PHICH resource index.

<FIG> describes a method <NUM> that may be performed by an UE such as UE <NUM> of <FIG>. Circuitry of such an UE may be configured to transmit HARQ data based on the received downlink data. For example, the transmit circuitry may transmit HARQ data using a MTC PHICH. The control circuitry of such a UE may perform various operations such as those described elsewhere in this disclosure. The control circuitry may be adapted to generate the HARQ data based on the received downlink data and to assign resources associated with an MTC PHICH based on a physical cell identity.

The method <NUM> includes operation <NUM> for receiving a downlink transmission from an eNB, and operation <NUM> for generating HARQ data based on the received downlink data. Operation <NUM> involves assigning resources associated with an MTC PHICH based on a physical cell identity, and operation <NUM> includes transmitting the HARQ data using the MTC PHICH.

<FIG> describes a method <NUM> that may be performed by an eNB such as eNB <NUM> of <FIG>. Circuitry of such an eNB may be adapted to receive uplink transmissions, for example, from a UE performing method <NUM>. In various embodiments, transmit circuitry of such an eNB may transmit HARQ data based on the received uplink data. Such transmit circuitry may be configured to transmit HARQ data using a MTC PHICH. The control circuitry of such an eNB may perform various operations such as those described elsewhere in this disclosure. The control circuitry may be adapted to generate the HARQ data based on the received uplink data and to assign resources associated with an MTC PHICH based on a physical cell identity.

Method <NUM> includes an operation <NUM> for receiving an uplink transmission from a UE. In the embodiment of method <NUM>, this is followed by operation <NUM> for generating HARQ data based on the received uplink data, and then operation <NUM> for assigning resources associated with an M-PHICH based on a physical cell identity. Operation <NUM> then includes transmitting the HARQ data using the M-PHICH.

<FIG> describes another method <NUM>. In operation <NUM>, a super frame structure is determined, with the super-frame structure set, at least in part, based on a bandwidth of the narrowband deployment. This setting may be an adjustable setting controlled by system values or targets as described above. In other embodiments, this may be set as a fixed structure of the system based on system hardware. Configuration information for a UE is then determined in communication with an ENB in operation <NUM>. A configuration for an M-CFI for the UE is generated to indicate the determined configuration information in operation <NUM>, and in operation <NUM>, the M-CFI is transmitted through an M-PCFICH within a super-frame of the super-frame structure.

In these methods and any methods described herein, operations may be performed in various orders or may include intervening steps in accordance with various embodiments.

An additional embodiment may be an apparatus of an evolved nodeB (eNB) for machine-type communications (MTC) with narrowband deployment comprising. This apparatus may be, for example, an integrated circuit, a board assembly with integrated circuits, a system on a chip, or any other such apparatus. Such an apparatus embodiment includes control circuitry configured to determine a super-frame structure, wherein the super-frame structure is set, at least in part, on a bandwidth of the narrowband deployment; determine configuration information for a user equipment (UE) in communication with the eNB; and generate a configuration for an MTC control format indicator (M-CFI) for the UE to indicate the determined configuration information; and transmit circuitry configured transmit the M-CFI through a narrowband MTC Physical Control Format Indicator Channel(M-PCFICH) within a super-frame of the super-frame structure.

Additional embodiments may operate where the M-CFI indicates resource information for an MTC Physical Downlink Control Channel (M-PDCCH) or MTC Physical Downlink Shared Channel (M-PDSCH) transmission.

Additional embodiments may operate where the M-PDCCH comprises a number of symbol, slot, subframes, subcarrier, and physical resource blocks (PRB) for the M-PDCCH.

Additional embodiments may operate further comprising MTC physical broadcast channel (M-PBCH) circuitry comprising: block code circuitry configured to generate a codeword; scrambling circuitry coupled to the block code circuitry and configured to scramble the codeword; and modulation circuitry configured to generate a plurality of symbols from the scrambled codeword.

Additional embodiments may operate where the M-PCFICH is determined from a plurality of symbols by an M-PCFICH mapping of resource elements associated with the symbols onto one or more subframes of the superframe structure.

Additional embodiments may operate where the scrambling circuitry is configured to scramble the codeword using a scrambling sequence based on a function of a super-frame number associated with the super-frame.

Additional embodiments may operate where an MTC resource element group (M-REG) is defined for transmission of the M-PCFICH, wherein a plurality of resource elements (REs) are mapped to the M-REG where the M-REG is not used for reference signals.

Additional embodiments may operate where the plurality of REs are mapped based at least in part on a first subcarrier and an orthogonal frequency division multiplexing symbol associated with the M-REG.

Additional embodiments may operate where the M-REGs are allocated over one or more partial subframes of the super-frame.

Additional embodiments may operate where the M-REGs are allocated over one or more contiguous or non-contiguous full subframes of the super-frame.

Additional embodiments may operate where the eNB further comprises circuitry to map M-PCFICH symbols on the indicated M-REGs, with the starting position in accordance with a physical cell identity.

Additional embodiments may operate where the eNB is arranged to map the M-PCFICH symbols using <MAT> to denote a symbol quadruplet i for an antenna port p for M-PCFICH transmission, where y(p)(k), k = <NUM>,. ,<NUM> represents an M-PCFICH signal for antenna port p and where p = <NUM>,. , P - <NUM> represents a number of antenna ports for cell-specific reference signals P ∈ {<NUM>,<NUM>,<NUM>};
wherein:.

Additional embodiments may operate where the UE comprises four antenna ports; wherein a cyclic prefix associated with the super-frame is an extended cyclic prefix; and
wherein:
NREG = <NUM>.

An additional embodiment is method performed by circuitry of an evolved nodeB (eNB) for machine-type communications (MTC) with narrowband deployment comprising: determining a super-frame structure, wherein the super-frame structure is set, at least in part, on a coverage enhancement target; determining configuration information for a user equipment (UE) in communication with the eNB; and generating a configuration for an MTC Control Format Indicator (M-CFI) for the UE to indicate the determined configuration information; and transmiting circuitry configured transmit the M-CFI through a narrowband MTC Physical Control Format Indicator (M-PCFICH) within a super-frame of the super-frame structure.

Another embodiment of such a method operates where an MTC resource element group (M-REG) is defined for transmission of the M-PCFICH, wherein a plurality of resource elements (REs) are mapped to the M-REG where the M-REG is not used for reference signals; and wherein the plurality of REs are mapped based at least in part on a first subcarrier and an orthogonal frequency division multiplexing symbol associated with the M-REG.

Another embodiment of such a method operates where an MTC resource element group (M-REG) is defined for transmission of the M-PCFICH, wherein a plurality of resource elements (REs) are mapped to the M-REG where the M-REG is not used for reference signals; wherein the M-REGs are allocated over one or more contiguous or non-contiguous full subframes of the super-frame; wherein the eNB further comprises circuitry to map M-PCFICH symbols on the indicated M-REGs, with the starting position in accordance with a physical cell identity; wherein the eNB is arranged to map the M-PCFICH symbols using <MAT> to denote a symbol quadruplet i for an antenna port p for M-PCFICH transmission, where y(p)(k), k = <NUM>,. ,<NUM> represents an M-PCFICH signal for antenna port p and where p = <NUM>,. , P - <NUM> represents a number of antenna ports for cell-specific reference signals P ∈ {<NUM>,<NUM>,<NUM>};
wherein:.

Another embodiment is a non-transitory computer readable medium comprising instructions that, when executed by one or more processors, configure an evolved nodeB (eNB) for machine-type communications (MTC) with narrowband deployment comprising determining a super-frame structure, wherein the super-frame structure is set, at least in part, on a coverage enhancement target; determining configuration information for a user equipment (UE) in communication with the eNB; generating a configuration for an MTC Control Format Indicator (M-CFI) for the UE to indicate the determined configuration information; and transmiting circuitry configured transmit the M-CFI through a narrowband MTC Physical Control Format Indicator (M-PCFICH) within a super-frame of the super-frame structure; wherein the M-CFI indicates resource information for an MTC Physical Downlink Control Channel (M-PDCCH) or MTC Physical Downlink Shared Channel (M-PDSCH) transmission.

Additional embodiments may operate where an MTC resource element group (M-REG) is defined for transmission of the M-PCFICH, wherein a plurality of resource elements (REs) are mapped to the M-REG where the M-REG is not used for reference signals; and wherein the M-REGs are allocated over one or more partial subframes of the super-frame.

The foregoing description of one or more implementations provides illustration and description.

<FIG> then illustrates aspects of computing machine according to some example embodiments. Embodiments described herein may be implemented into a system <NUM> using any suitably configured hardware and/or software. <FIG> illustrates, for some embodiments, an example system <NUM> comprising radio frequency (RF) circuitry <NUM>, baseband circuitry <NUM>, application circuitry <NUM>, memory/storage <NUM>, display <NUM>, camera <NUM>, sensor <NUM>, and input/output (I/O) interface <NUM>, coupled with each other at least as shown.

The application circuitry <NUM> may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may be coupled with memory/storage <NUM> and configured to execute instructions stored in the memory/storage <NUM> to enable various applications and/or operating systems running on the system <NUM>.

The processor(s) may include a baseband processor. The baseband circuitry <NUM> may handle various radio control functions that enables 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, encoding, decoding, radio frequency shifting, and the like.

In various embodiments, baseband circuitry <NUM> may include circuitry to operate with signals that are not strictly considered as being in a baseband frequency. For example, in some embodiments, baseband circuitry <NUM> may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

In various embodiments, the RF circuitry <NUM> may include switches, filters, amplifiers, and the like to facilitate the communication with the wireless network.

In various embodiments, RF circuitry <NUM> may include circuitry to operate with signals that are not strictly considered as being in a radio frequency. For example, in some embodiments, RF circuitry <NUM> may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

In various embodiments, the transmitter circuitry or receiver circuitry discussed above with respect to the UE or eNB may be embodied in whole or in part in one or more of the RF circuitry <NUM>, the baseband circuitry <NUM>, and/or the application circuitry <NUM>.

In some embodiments, some or all of the constituent components of a baseband processor or as the baseband circuitry <NUM>, the application circuitry <NUM>, and/or the memory/storage <NUM> may be implemented together on a system on a chip (SOC).

Memory/storage <NUM> may be used to load and store data and/or instructions, for example, for system <NUM>. Memory/storage <NUM> for one embodiment may include any combination of suitable volatile memory (e.g., dynamic random access memory (DRAM)) and/or non-volatile memory (e.g., Flash memory).

In various embodiments, the I/O interface <NUM> may include one or more user interfaces designed to enable user interaction with the system and/or peripheral component interfaces designed to enable peripheral component interaction with the system <NUM>. User interfaces may include, but are not limited, to a physical keyboard or keypad, a touchpad, a speaker, a microphone, and so forth. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface.

In various embodiments, sensor <NUM> may include one or more sensing devices to determine environmental conditions and/or location information related to the system <NUM>. In some embodiments, the sensors <NUM> may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, the baseband circuitry <NUM> and/or RF circuitry <NUM> to communicate with components of a positioning network (e.g., a global positioning system (GPS) satellite). In various embodiments, the display <NUM> may include a display (e.g., a liquid crystal display, a touch screen display, etc.).

In various embodiments, the system <NUM> may be a mobile computing device such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, an ultrabook, a smartphone, and the like. In various embodiments, system <NUM> may have more or less components, and/or different architectures.

<FIG> shows an example UE, illustrated as UE <NUM>. UE <NUM> may be an implementation of UE <NUM> or eNB <NUM> any device described herein. The UE <NUM> can include one or more antennas configured to communicate with transmission station, such as a base station (BS), an eNB, or other type of wireless wide area network (WWAN) access point. The mobile device can be configured to communicate using at least one wireless communication standard including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The mobile device can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The mobile device can communicate in a WLAN, a WPAN, and/or a WWAN.

<FIG> illustrates an example of a UE <NUM>. The UE <NUM> can be any mobile device, a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a handset, or other type of mobile wireless computing device. The UE <NUM> can include one or more antennas <NUM> within housing <NUM> that are configured to communicate with a hotspot, BS, an eNB, or other type of WLAN or WWAN access point. A UE may thus communicate with a WAN such as the Internet via an eNB or base station transceiver implemented as part of an asymmetric RAN as detailed above. UE <NUM> can be configured to communicate using multiple wireless communication standards, including standards selected from 3GPP LTE, WiMAX, HSPA, Bluetooth, and Wi-Fi standard definitions. The UE <NUM> can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The UE <NUM> can communicate in a WLAN, a WPAN, and/or a WWAN.

<FIG> also shows a microphone <NUM> and one or more speakers <NUM> that can be used for audio input and output from the UE <NUM>. A display screen <NUM> can be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display. The display screen <NUM> can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. An application processor <NUM> and a graphics processor <NUM> can be coupled to internal memory <NUM> to provide processing and display capabilities. A non-volatile memory port <NUM> can also be used to provide data I/O options to a user. The non-volatile memory port <NUM> can also be used to expand the memory capabilities of the UE <NUM>. A keyboard <NUM> can be integrated with the UE <NUM> or wirelessly connected to the UE <NUM> to provide additional user input. A virtual keyboard can also be provided using the touch screen. A camera <NUM> located on the front (display screen) side or the rear side of the UE <NUM> can also be integrated into the housing <NUM> of the UE <NUM>.

<FIG> is a block diagram illustrating an example computer system machine <NUM> upon which any one or more of the methodologies herein discussed can be run, and may be used to implement eNB <NUM> and UE <NUM> or any other device described herein. In various alternative embodiments, the machine operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can operate in the capacity of either a server or a client machine in server-client network environments, or it can act as a peer machine in peer-to-peer (or distributed) network environments. The machine can be a personal computer (PC) that may or may not be portable (e.g., a notebook or a netbook), a tablet, a set-top box (STB), a gaming console, a Personal Digital Assistant (PDA), a mobile telephone or smartphone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

Example computer system machine <NUM> includes a processor <NUM> (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory <NUM>, and a static memory <NUM>, which communicate with each other via an interconnect <NUM> (e.g., a link, a bus, etc.). The computer system machine <NUM> can further include a video display unit <NUM>, an alphanumeric input device <NUM> (e.g., a keyboard), and a user interface (UI) navigation device <NUM> (e.g., a mouse). In one embodiment, the video display unit <NUM>, input device <NUM>. and UI navigation device <NUM> are a touch screen display. The computer system machine <NUM> can additionally include a storage device <NUM> (e.g., a drive unit), a signal generation device <NUM> (e.g., a speaker), an output controller <NUM>, a power management controller <NUM>, and a network interface device <NUM> (which can include or operably communicate with one or more antennas <NUM>, transceivers, or other wireless communications hardware), and one or more sensors <NUM>, such as a GPS sensor, compass, location sensor, accelerometer, or other sensor.

The storage device <NUM> includes a machine-readable medium <NUM> on which is stored one or more sets of data structures and instructions <NUM> (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions <NUM> can also reside, completely or at least partially, within the main memory <NUM>, static memory <NUM>, and/or within the processor <NUM> during execution thereof by the computer system machine <NUM>, with the main memory <NUM>, static memory <NUM>, and the processor <NUM> also constituting machine-readable media.

While the machine-readable medium <NUM> is illustrated in an example embodiment to be a single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions <NUM>. The term "machine-readable medium" shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions.

The instructions <NUM> can further be transmitted or received over a communications network <NUM> using a transmission medium via the network interface device <NUM> utilizing any one of a number of well-known transfer protocols (e.g., hypertext transport protocol HTTP). The term "transmission medium" shall be taken to include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Various techniques, or certain aspects or portions thereof may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, non-transitory computer readable storage medium, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be a RAM, EPROM, flash drive, optical drive, magnetic hard drive, or other medium for storing electronic data. The base station and mobile station may also include a transceiver module, a counter module, a processing module, and/or a clock module or timer module. One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

Various embodiments may use 3GPP LTE/LTE-A, Institute of Electrical and Electronic Engineers (IEEE) <NUM>, and Bluetooth communication standards. Various alternative embodiments may use a variety of other WWAN, WLAN, and WPAN protocols and standards can be used in connection with the techniques described herein. These standards include, but are not limited to, other standards from 3GPP (e.g., HSPA+, UMTS), IEEE <NUM> (e.g., <NUM>. 16p), or Bluetooth (e.g., Bluetooth <NUM>, or like standards defined by the Bluetooth Special Interest Group) standards families. Other applicable network configurations can be included within the scope of the presently described communication networks. It will be understood that communications on such communication networks can be facilitated using any number of PANs, LANs, and WANs, using any combination of wired or wireless transmission mediums.

The embodiments described above can be implemented in one or a combination of hardware, firmware, and software. Various methods or techniques, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as flash memory, hard drives, portable storage devices, read-only memory (ROM), RAM, semiconductor memory devices (e.g., EPROM, Electrically Erasable Programmable Read-Only Memory (EEPROM)), magnetic disk storage media, optical storage media, and any other machine-readable storage medium or storage device wherein, when the program code is loaded into and executed by a machine, such as a computer or networking device, the machine becomes an apparatus for practicing the various techniques.

A machine-readable storage medium or other storage device can include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). In the case of program code executing on programmable computers, the computing device can include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that can implement or utilize the various techniques described herein can use an API, reusable controls, and the like. Such programs can be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language, and combined with hardware implementations.

It should be understood that the functional units or capabilities described in this specification may have been referred to or labeled as components or modules in order to more particularly emphasize their implementation independence. For example, a component or module can be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component or module can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules can also be implemented in software for execution by various types of processors. An identified component or module of executable code can, for instance, comprise one or more physical or logical blocks of computer instructions, which can, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component or module need not be physically located together, but can comprise disparate instructions stored in different locations which, when joined logically together, comprise the component or module and achieve the stated purpose for the component or module.

Claim 1:
An apparatus, comprising:
control circuitry (<NUM>) configured to cause a base station (<NUM>, <NUM>, <NUM>) configured for machine-type communication, MTC, to:
determine a super-frame structure, the super-frame structure comprising a control region in a super-frame according to the super-frame structure, and
a number of subframes in a data region of the super-frame, wherein the number of subframes in the data region of the super-frame is set, at least in part, based on a coverage enhancement target of a narrowband deployment;
determine configuration information for a user equipment, UE, in communication with the base station (<NUM>, <NUM>, <NUM>); and
generate a configuration for an MTC control format indicator, M-CFI, for the UE (<NUM>, <NUM>, <NUM>) to indicate the determined configuration information; and
transmit circuitry (<NUM>) configured to transmit the M-CFI through a narrowband MTC Physical Control Format Indicator Channel, M-PCFICH, (<NUM>, <NUM>) within the control region of the super-frame, wherein the M-PCFICH (<NUM>, <NUM>) carries the M-CFI, which is used to indicate information for MTC Physical Downlink Control Channel, M-PDCCH, WEPBEEH (<NUM>) and MTC Physical Downlink Shared Channel, M-PDSCH, (<NUM>) transmission.