Patent Description:
Latency reduction for Long-Term Evolution (LTE) has been identified as an important consideration with respect to the future path of LTE. As noted in a recent study item proposal, reducing latency can increase throughput by improving the performance of transmission control protocol (TCP) in the upper layers, by reducing the impact of TCP slow start, a major limiting factor for small size packets. Furthermore, reducing the air interface latency of LTE can enable a new, emerging category of services known as ultra- low latency and mission critical traffic. Such new services were identified as important for use cases such as vehicular networks, among others, in a <NUM> White Paper published by the influential Next Generation Mobile Networks (NGMN) alliance of mobile operators.

Ultra-low latency services are expected to require one-way air interface latency to be on the order of <NUM> millisecond or less, which is represents a significant reduction with respect to current LTE latency.

<CIT> discloses a method in a network node for handling scheduling of a wireless device in a communications network, wherein the network node is adapted to communicate wirelessly with the wireless device over a radio channel, and determines that a data transmission or data reception corresponding to a multi-TTI scheduling message previously transmitted to the wireless device should be at least one of adjusted, interrupted and terminated, and transmits, to the wireless device, information indicating that the data transmission or data reception corresponding to a previously transmitted multi- Transmission Time Interval, TTI, scheduling message should be at least one of adjusted, interrupted and terminated as determined.

The present invention is defined by the features of the independent claim(s). Preferred advantageous embodiments thereof are defined by the sub-features of the dependent claims.

Various embodiments may be generally directed to latency reduction techniques for radio access networks. In the claimed embodiments, a reduced transmission time interval (rTTI) is implemented in order to reduce air interface latency in a radio access network. In the claimed embodiments, an rTTI block is defined, and some operations are performed in rTTI block-wise fashion in order to reduce the marginal overhead associated with implementation of the rTTI. In some embodiments in which an rTTI is implemented, demodulation reference signal (DM-RS) granularity may be improved by use of techniques that enable data and reference signals to be multiplexed within a same orthogonal frequency division multiplexing (OFDM) symbol. In various embodiments, a current transmission time interval (TTI) may be maintained, and latency reduction may be achieved via the use of novel techniques for one or more of code block (CB) segmentation, uplink (UL) resource element (RE) mapping, and hybrid automatic repeat request (HARQ) cycle timing. Other embodiments are described and claimed.

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

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

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

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

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

In a radio access network, one factor that may significantly influence air interface latency is the minimum time scheduling unit. In an LTE evolved UMTS Terrestrial Radio Access Network (E-UTRAN), the minimum time scheduling unit is the transmission time interval (TTI), which comprises a duration of one subframe (<NUM> millisecond, or <NUM> OFDM symbols). Reducing the TTI to one slot (<NUM>, or <NUM> OFDM symbols), or even further to one or few OFDM symbols, may enable a significant reduction in latency. However, implementing a reduced TTI (rTTI) may tend to result in increased amounts of various types of overhead, such as overhead associated with scheduling-related control information, HARQ feedback, and DM-RS reference signals.

In the claimed embodiments, in order to reduce the marginal overhead associated with implementation of an rTTI, an rTTI block is defined to enable some types of operations to be performed in an rTTI block-wise fashion that involves less overhead. In the claimed embodiments, scheduling is performed on an rTTI block-wise basis, eliminating the need for individual TTI scheduling information in the control channel. In various embodiments, respective HARQ feedback corresponding to multiple rTTI contained in an rTTI block may be transmitted jointly, once the entire rTTI block has been processed, rather than being transmitted individually on a per-rTTI basis. In some embodiments, rTTI block-wise scheduling may enable the density of reference signals to be reduced, by exploiting the correlation of channel estimates in the time domain, to a level comparable to the legacy TTI length.

<FIG> illustrates an example of a transmission timing diagram <NUM> that may be representative of various embodiments. As reflected in transmission timing diagram <NUM>, in some embodiments, an rTTI may coexist with the legacy LTE TTI. In this example, use of an LTE TTI and an rTTI are multiplexed in the frequency domain, occupying disjoint sets of physical resource blocks (PRBs) in respective frequency sub-bands. The LTE TTI <NUM>, which comprises a duration of one subframe, is used in sub-bands A, B, and C, while the rTTI is used in sub-bands D and E. During a first LTE TTI <NUM>, per-rTTI scheduling is used in sub-bands D and E, and thus each rTTI in sub-bands D and E within the first LTE TTI <NUM> contains both data and control regions. During a second LTE TTI <NUM>, rTTI block-wise scheduling is used in sub-bands D and E, according to which a control region in a first rTTI contains all of the scheduling information for the entire rTTI block <NUM>, and thus control regions are not needed in the rest of the rTTIs of the block. In this example, the length of rTTI block <NUM> happens to be equal to the length of each LTE TTI <NUM>. In various embodiments, setting the rTTI block length to equal the legacy LTE TTI of one subframe may have significant advantages in terms of re-using legacy LTE control and reference signals. However, it is to be appreciated that other rTTI block sizes are both possible and contemplated, and the embodiments are not limited in this context.

<FIG> illustrates an example of an operating environment <NUM> that may be representative of some embodiments. In operating environment <NUM>, an eNB <NUM> and a UE <NUM> may exchange various types of wireless communications over an LTE air interface <NUM> in a radio access network cell <NUM>. In various embodiments, radio access network cell <NUM> may comprise a cell of an E-UTRAN. In some embodiments, eNB <NUM> may transmit control information <NUM> to UE <NUM>. In various embodiments, eNB <NUM> may transmit control information <NUM> to UE <NUM> over a physical downlink control channel (PDCCH) or an enhanced physical downlink control channel. In some embodiments, control information <NUM> may comprise scheduling information that identifies channel resources that have been scheduled for use in conjunction with wireless communication between eNB <NUM> and UE <NUM>.

In various embodiments, control information <NUM> may comprise downlink scheduling information, and may comprise information identifying channel resources that have been scheduled for use by eNB <NUM> to transmit data <NUM> to UE <NUM>. In some embodiments, eNB <NUM> may transmit data <NUM> to UE <NUM> using physical downlink shared channel (PDSCH) resources specified by control information <NUM>. In various embodiments, in conjunction with transmission of data <NUM> over the PDSCH, eNB <NUM> may also transmit demodulation reference signals (DM-RS) <NUM> over the PDSCH. In some embodiments, UE <NUM> may transmit HARQ feedback <NUM> to eNB <NUM> in order to inform eNB <NUM> of whether UE <NUM> has successfully received data <NUM>. In various embodiments, UE <NUM> may transmit HARQ feedback <NUM> to eNB <NUM> over a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH).

In some embodiments, UE <NUM> may transmit control information <NUM> to eNB <NUM>. In various embodiments, UE <NUM> may transmit control information <NUM> over the PUCCH. In some embodiments, control information <NUM> may comprise a request for eNB <NUM> to schedule channel resources for use by UE <NUM> to transmit data <NUM> to eNB <NUM>. In various embodiments, in response to such a request, eNB <NUM> may allocate physical uplink share channel (PUSCH) resources to UE <NUM> for use in transmitting data <NUM> and may send control information <NUM> to UE <NUM> to notify it of those allocated resources. It is worthy of note that in some embodiments, if UL <NUM> transmits data to eNB <NUM> over the PUSCH during the same time interval as that during which it transmits control information <NUM>, then UE <NUM> may transmit control information <NUM> over the PUSCH as well, rather than the PUCCH. In various embodiments, UE <NUM> may then transmit data <NUM> to eNB <NUM> using the PUSCH resources specified by that control information <NUM>. In some embodiments, in conjunction with transmission of data <NUM> over the PUSCH, UE <NUM> may also transmit DM-RS signals <NUM> over the PUSCH. In various embodiments, eNB <NUM> may transmit HARQ feedback <NUM> to UE <NUM> in order to inform UE <NUM> of whether eNB <NUM> has successfully received data <NUM>. In some embodiments, eNB <NUM> may transmit HARQ feedback <NUM> to UE <NUM> over a physical HARQ indicator channel (PHICH).

In various embodiments, an rTTI may be implemented in radio access network cell <NUM> in order to reduce latency associated with communications over LTE air interface <NUM>. In some embodiments, in order to reduce the marginal overhead associated with implementation of the rTTI, one or more of the aforementioned operations may be conducted in an rTTI block-wise fashion. In various embodiments, different rTTI block sizes may be defined to provide additional flexibility and enable further overhead reductions. In some embodiments, some operations may be performed on an rTTI block-wise basis and others may be performed on a per-rTTI basis. For example, in various embodiments, it may be possible to schedule individual rTTI but, taking into consideration previously scheduled rTTI within an rTTI block, permit some DM-RS signals to not be transmitted and the resources to be used to transmit data instead. Similarly, in some embodiments, a rTTI block-wise HARQ feedback mechanism may be implemented while per-rTTI scheduling is used. The embodiments are not limited to these examples.

In various embodiments, eNB <NUM> may conduct resource scheduling on an rTTI block-wise basis. In some embodiments, in conjunction with rTTI block-wise scheduling operations, eNB <NUM> may allocate resources of an rTTI block for use in conjunction with wireless communications between eNB <NUM> and UE <NUM>. In various embodiments, eNB <NUM> may allocate PDSCH resources of the tTTI block for its own use in transmitting data to UE <NUM>. In some embodiments, eNB <NUM> may allocate PUSCH resources of the rTTI block for use by UE <NUM> in transmitting data to eNB <NUM>. In various embodiments, eNB <NUM> may send rTTI block-wise scheduling information to UE <NUM> in order to inform UE <NUM> of the allocated resources of the rTTI block. In some embodiments, UE <NUM> may be configured through upper layer signaling to operate in an rTTI block mode. In various embodiments, operating in the rTTI block mode may enable UE <NUM> to receive rTTI block-wise scheduling information via legacy control information formats, such as legacy formats for communication of such control information over the PDCCH or ePDCCH. In some embodiments, operating in the rTTI block mode may enable UE <NUM> to receive DM-RS signals via a legacy DM-RS location defined for the PDSCH.

In various embodiments, eNB <NUM> may be able schedule an rTTI block such that different rTTIs of the block are assigned to different UEs. In some embodiments, eNB <NUM> may schedule an rTTI block to be shared among multiple UEs according to a pattern associated with an rTTI block sharing format. In an example embodiment, eNB <NUM> may schedule an rTTI block to be shared by UE <NUM> and a second UE according to a pattern comprising alternating, from rTTI to rTTI in the rTTI block, between UE <NUM> and the second UE. In various embodiments, if UE <NUM> is to share an rTTI block with one or more other UEs, higher layer signaling may be used to inform UE <NUM> of which of the rTTIs of the block are assigned to UE <NUM>. In some embodiments, this information may be conveyed via a predetermined flag or via an identifier of a defined rTTI block sharing format. In various embodiments, respective DM-RS resource element (RE) locations may be selected for each rTTI block sharing format in order to improve/optimize DM-RS granularity.

In some embodiments, the higher layer may be able to dimension the resource region for rTTI block mode in the time domain, the frequency domain, or both. In various embodiments, the higher layer may perform time domain configuration, according to which particular subframes may be designated as rTTI block mode subframes. In some embodiments, the higher layer may perform frequency domain configuration, according to which particular sub-bands may be designated as rTTI block mode sub-bands. In various embodiments, these two techniques may be used in combination.

In some embodiments, while UE <NUM> operates in rTTI block mode, a HARQ process may be mapped to each rTTI transport block (TB). In various embodiments, UE <NUM> may aggregate HARQ feedback for all of the rTTIs within an rTTI block and send the aggregated HARQ feedback to eNB <NUM> in a single block-wise HARQ feedback message. In some embodiments, the block-wise HARQ feedback message may provide the aggregated HARQ feedback in the form of an N-bit word, with one bit corresponding to each of N rTTIs in the rTTI block. In various embodiments, eNB <NUM> may provide rTTI block-wise HARQ feedback to UE <NUM> in analogous fashion. In some embodiments, the rTTI block length may equal the LTE TTI of <NUM> subframe, and mechanisms defined by LTE for conventional HARQ feedback may be used. In various embodiments, since channel decoding is done in each rTTI, the decoding/encoding budgets may be shorter than those associated with the legacy system using a conventional <NUM> subframe TTI. Thus, assuming the length of the rTTI block is <NUM> (the same as <NUM> subframe), the aggregated HARQ-ACK feedback corresponding an rTTI block in subframe n may be sent in subframe n+X (where X<<NUM>). As a specific example, X may be equal to <NUM>, corresponding to a <NUM> subframe margin considering timing advance and decoding/encoding time budget. The embodiments are not limited to this example.

In some embodiments, UE <NUM> may use a legacy control signal format, such as PUCCH format <NUM> or PUCCH format <NUM>, to provide aggregated HARQ feedback for rTTI block-based downlink data transmissions. In various embodiments, UE <NUM> may wait for an entire rTTI block to be received and accumulate HARQ feedback. Then, UE <NUM> may use the PUCCH or PUSCH in order to feed back a coded N-bit word containing values <NUM> for ACK and <NUM> for NACK for each individual rTTI in the rTTI block. In some embodiments, UE <NUM> may feed back a single collective ACK or NACK of all of the data transmitted during the rTTI block. For example, in various embodiments, UE <NUM> may feed back the values '<NUM>' in order to indicate a collective ACK, and may feed back the values '<NUM>' to indicate a collective NACK. The embodiments are not limited to this example.

In some embodiments, with respect to HARQ feedback for rTTI block-based uplink transmissions, the PHICH may be modified to carry encoded ACK/NACK words, with each uncoded bit representing one rTTI within the block and taking values <NUM> for ACK and <NUM> for NACK. In various embodiments, for N rTTI/block, N bits may be further encoded to produce an r*N bit word, with r being the code rate. In LTE, ACK/NACK is encoded with a rate <NUM>/<NUM> repetition code, taking values '<NUM>' or '<NUM>'. In some embodiments, the same code may be used in conjunction with rTTI block-based HARQ feedback. In various other embodiments, a higher rate may be used in order to reduce PHICH overhead. In some embodiments, the unmodified PHICH may be used to feed back a single collective ACK/NACK value for the rTTI block, taking values '<NUM>' when all rTTI are received correctly and '<NUM>' otherwise. The embodiments are not limited to this example.

<FIG> illustrates an embodiment of a reference signal design <NUM> that may be representative of the DM-RS signal design used in conventional LTE systems. As shown in <FIG>, according to the conventional DM-RS signal design, two symbols per subframe are used for DM-RS signals. In this example, the symbols used for DM-RS signals are the shaded symbols <NUM> and <NUM>. Subframe <NUM> comprises slots <NUM> and <NUM>. The first DM-RS signal subframe, subframe <NUM>, is comprised in slot <NUM>. The second DM-RS signal subframe, subframe <NUM>, is comprised in slot <NUM>. If an rTTI of <NUM> slot is implemented, only one DM-RS symbol will be available per slot.

In conjunction with implementing an rTTI, it may be desirable to have more granularity in the DM-RS signal so that overhead can be managed and a more reliable channel estimation may be achieved. In order to increase granularity, it may be desirable that data and reference signals are combined in a given symbol interval. Described herein are techniques that may enable data and reference signals to be combined in such fashion. In various embodiments, data and reference signals may be multiplexed in the frequency domain. In some embodiments, this may simplify channel estimation, since reference symbols are not contaminated by data. In various embodiments, data and reference signals may be multiplexed in the time domain. In some embodiments, this may provide a higher number of reference samples but may require more complex receiver processing. In various embodiments, the symbol duration may be reduced in order to enable transmission one or more data symbols and a reference symbol in a same symbol interval. In some embodiments, subcarrier spacing may be effectively increased by the same factor as that by which the symbol interval is reduced. In various embodiments, for example, the symbol interval may be halved and the subcarrier spacing may be effectively increased from <NUM> to <NUM>. In some embodiments, the cyclic prefix (CP) may be divided into two in order to cover two shortened symbols (e.g. <NUM> for each divided symbol). In various embodiments, OFDMA modulation may be used to multiplex data and reference signals in the frequency domain.

<FIG> illustrates an embodiment of a reference signal design <NUM> and an embodiment of a reference signal design <NUM>, both of which may be representative of DM-RS signal designs that may be implemented in some embodiments in order to improve DM-RS granularity in conjunction with the use of an rTTI. Reference signal design <NUM> corresponds to an rTTI <NUM> comprising a duration of one OFDM symbol, while reference signal design <NUM> corresponds to an rTTI <NUM> comprising a duration of one slot. According to reference signal designs <NUM> and <NUM>, data and reference signals are multiplexed in the frequency domain, such that different subcarriers are used to transmit data and reference signals in any given OFDM symbol during which reference signals are transmitted.

<FIG> illustrates an embodiment of a mapping process <NUM> that may be representative of a first approach to facilitating the multiplexing of data and reference signals in the frequency domain according to various embodiments. Denote by N the total number of sub-carriers allocated to a given UE, by Nd the number of data symbols, and by Nrs the number of reference symbols, with Nd+Nrs=N. With respect to mapping process <NUM>, Nd may be selected to be equal to N/k, with integer k. According to mapping process <NUM>, a block of Nd data symbols is first repeated k times and then multiplied block-wise by a phase vector ϕ=[<NUM> exp(j2πa/k),. exp(j2πa(k-<NUM>)/k)], where 'a' takes an integer value between <NUM> and N/Nd-<NUM>. After this procedure, the usual DFT spreading with DFT size N yields an interleaved allocation of sub-carriers, where subcarriers a+bk, b=<NUM>,<NUM>,. Nd contain data symbols. The remainder of sub-carriers within block N is empty, and can be used to insert a reference signal in the frequency domain, in some embodiments, a shortened DM-RS sequence or a different sequence may be used.

A second approach that may be used to facilitate multiplexing data and reference signals in the frequency domain in various embodiments may include using a different DFT size Nd to spread data symbols, and then mapping symbols in a subset of the N sub-carriers of the block. In some embodiments, this approach may offer more flexibility since any value for Nd may be possible. If Nd=N/k, then this approach may be the same as the approach embodied in mapping process <NUM>, if the frequency mapping is done in an interleaved manner in the frequency domain.

At the receiver, according the either the first approach or the second approach, reference symbols may be used in the frequency domain to estimate the channel and may then be removed. In various embodiments, the remaining signal may first be equalized and may then be transformed with an IDFT of size N (according to the first approach) or Nd (according to the second approach). In some embodiments, data symbols may then be retrieved in the time domain.

Data and reference signal multiplexing may offer a great deal of flexibility in the allocation of reference signals. In various embodiments, patterns may be defined that reduce the mean square error of channel estimation after applying a suitable interpolation method. <FIG> illustrates a multiplexing pattern table <NUM> that comprises examples of patterns that may be suitable for use in some embodiments.

In the "Example Patterns" column of multiplexing pattern table <NUM>, 'A' denotes a symbol consisting entirely of data symbols. 'B' denotes a symbol consisting of interleaved reference and data symbols, consisting of a regular pattern, and starting with a pilot symbol. In various embodiments, such a symbol may be obtained via an approach described above. 'cs(B,a)' denotes a cyclic shift of B by 'a' subcarriers. In some embodiments, such a symbol may be obtained by phase vector multiplication, as described above. Multiplexing pattern table <NUM> comprises example patterns for rTTI sizes ranging from <NUM> to <NUM> symbols. In various embodiments, a suitable value for 'n' may be defined based on various considerations, which may vary from embodiment to embodiment. It is to be appreciated that other patterns and/or combinations of 'A' and cyclic shifts of B may be defined in some embodiments, and the embodiments are not limited to the examples listed in multiplexing pattern table <NUM>.

<FIG> and <FIG> illustrate respective reference signal designs <NUM> and <NUM>. Reference signal designs <NUM> and <NUM> both reflect the use of an rTTI of <NUM> symbols with k = <NUM>, and illustrate respective example multiplexing patterns comprised in multiplexing pattern table <NUM> of <FIG>. Reference signal design <NUM> corresponds to the multiplexing pattern 'ABAcs(B,<NUM>)'. Reference signal design <NUM> corresponds to the multiplexing pattern 'Bcs(B,<NUM>)Bcs(B,<NUM>)'. The embodiments are not limited to these examples.

In various embodiments, OFDMA modulation may be used in order to multiplex data and reference signals in the frequency domain. In some embodiments, patterns of multiplexing pattern table <NUM> may be readily used if OFDM rather than SC/FDMA is used for uplink transmission. In various embodiments, it may be possible to adopt a symmetric DM-RS pattern for uplink and downlink signals.

<FIG> illustrates an embodiment of a reference signal design <NUM> and an embodiment of a reference signal design <NUM>, both of which may be representative of DM-RS signal designs that may be implemented in some embodiments in order to improve DM-RS granularity in conjunction with the use of an rTTI. Reference signal design <NUM> corresponds to an rTTI <NUM> comprising a duration of one OFDM symbol, while reference signal design <NUM> corresponds to an rTTI <NUM> comprising a duration of one slot. According to reference signal designs <NUM> and <NUM>, data and reference signals are multiplexed in the time domain, such that overlapping data and reference signals are transmitted over each subcarrier during any given OFDM symbol during which reference signals are transmitted.

In various embodiments, in conjunction with multiplexing data and reference signal in the time domain, a data block of size Nd and a time domain reference signal of size Nrs, with Nd+Nrs=N, may be generated in the time domain. In some embodiments, the two blocks may then be combined into a size N block and transformed with a size N DFT. In various embodiments, this approach may mix data and reference signals in the frequency domain. In some embodiments, more advanced receiver techniques may be needed in order to separate them.

<FIG> illustrates an embodiment of a reference signal design <NUM> and an embodiment of a reference signal design <NUM>, both of which may be representative of DM-RS signal designs that may be implemented in various embodiments in order to improve DM-RS granularity in conjunction with the use of an rTTI. Reference signal design <NUM> corresponds to an rTTI <NUM> comprising a duration of one OFDM symbol, while reference signal design <NUM> corresponds to an rTTI <NUM> comprising a duration of one slot. According to reference signal designs <NUM> and <NUM>, the symbol duration is halved, such that one data symbol and one reference symbol are transmitted within a same OFDM symbol interval over each subcarrier during any given OFDM symbol during which reference signals are transmitted.

In some embodiments, it may be possible to provide sufficient reference symbols for even very short rTTIs by increasing the sub-carrier spacing. In various embodiments, a shorter rTTI may comprise shorter symbols, corresponding to larger subcarrier spacing. In some embodiments, either multiplexed data-DM-RS patterns or pure DM-RS symbols can be used with increased sub-carrier spacing. In various embodiments, the original CP length may be distributed to shorter symbols. For example, if a shorter symbol is half of a standard symbol and if the CP length for the standard symbol is <NUM>, the length of each shorter symbol CP may be <NUM>. The embodiments are not limited to this example.

In some embodiments, a conventional LTE TTI of <NUM> subframe may be maintained, and latency reductions may be achieved via one or more alternate techniques. According to various techniques, received signals may be made available for processing earlier at the receiver, so that processing time, and overall latency, may be reduced. According to some techniques, a code block (CB) segmentation procedure may be modified so that code block decoding may begin at the receiver prior to receipt of the entire subframe. According to various such techniques, the modified CB segmentation procedure may use smaller CBs that take less time to process. In some embodiments, a modified UL resource element (RE) mapping may be implemented in conjunction with use of the modified CB segmentation procedure. In various embodiments, conventional LTE TTI and control channel formats may be maintained, and latency may be reduced according to techniques that involve moderate changes to the current standard. For ease of understanding, embodiments will be explained based on an FDD structure unless otherwise noted. However, it is to be appreciated that embodiments are not limited to this structure.

According to contemporary LTE procedures, a CB is not permitted to be larger than a maximum CB size Z of <NUM> bits. If a codeword (CW) from a MAC layer transport block (TB) is too large enable its bits to fit within a single CB, a CB segmentation procedure is performed. According to the CB segmentation procedure, the CW is broken into multiple CBs, and cyclic redundancy checks (CRCs) are appended at the ends of each of the multiple CBs. Channel coding and rate matching are then applied on a per-CB basis, after which the data is concatenated and passed to the channel interleaver. For ease of explanation, a one-to-one mapping between TBs and CWs, such that the number of bits in a CW matches the number of bits in its TB, is assumed. However, it is to be appreciated that the embodiments are not limited in this context.

In some embodiments, a modified CB segmentation procedure may be implemented according to which each TB is divided into a fixed number C of CBs, where C is determined by upper layers. In various embodiments, each TB may be divided into a fixed number C of equalsize CBs. In some embodiments, filler bits may be used in order to reach appropriate CB sizes. It is worthy of note that in various embodiments, depending on the value of C and the TB size, a TB may be segmented into a greater number of CBs according to such a modified CB segmentation procedure than it would according to the conventional CB segmentation procedure that segments CBs only if they exceed <NUM> bits and only into the minimum number of CBs needed to observe the <NUM> bit limit.

In some embodiments, a modified CB segmentation procedure may be implemented according to which a smaller value may be defined for the maximum CB size Z. In various embodiments, according to such a modified CB segmentation procedure, the upper layers may be able to configure Z to be equal to any of multiple possible values. For example, in some embodiments, a default value for Z may be defined to be <NUM> bits, but upper layers may be able to configure Z to equal other values, such as <NUM> bits or <NUM> bits. In various embodiments, the value of Z may be defined as a function of a parameter N, which may be predetermined or configured by upper layers. In some such embodiments, for example, the maximum CB size Z may be given by one of Equations (<NUM>), (<NUM>), and (<NUM>), as follows: <MAT> <MAT> <MAT> The embodiments are not limited to these examples.

<FIG> depicts a resource element (RE) mapping scheme <NUM> that illustrates the manner in which rate-matched bits may be mapped to the REs of PUSCH resource blocks (RBs) according to contemporary LTE procedures. According to RE mapping scheme <NUM>, rate-matched bits are mapped to REs in a time-first manner, according to which the REs of an RB pair are filled in a row-wise fashion. During each of a series of mapping passes, rate-matched bits are mapped to the PUSCH REs of a respective subcarrier. For example, as shown in <FIG>, the rate-matched bits associated with a given CB may be mapped to the PUSCH REs of subcarriers <NUM>-<NUM> to <NUM>-<NUM> during respective passes <NUM>-<NUM> to <NUM>-<NUM>.

In various embodiments, mapping rate-matched bits to PUSCH REs in a time-first manner such as that illustrated in <FIG> may result in respective bits associated with a same CB being spread out across the entire breadth of the subframe during the very first mapping pass, even if the CB is relatively small. Since a receiver may need to receive all of the bits associated with the CB before it can begin decoding the CB, the generation of smaller CBs according to one of the aforementioned modified CB segmentation procedures may not enable the receiver to begin decoding any earlier when time-first PUSCH RE mapping is used. As such, with respect to the PUSCH, it may be desirable to implement a modified RE mapping scheme according to which all of the bits associated with a given CB may potentially be mapped to PUSCH REs comprised within a subset of the OFDM symbols of the subframe. In some embodiments, implementing such a modified RE mapping scheme in conjunction with one of the modified CB segmentation techniques discussed above may enable a receiver of a CB transmitted over the PUSCH to begin decoding that CB earlier than it would be able to according to contemporary LTE procedures.

<FIG> depicts an example of a modified RE mapping scheme that may be implemented in various embodiments in order to support earlier decoding of CBs transmitted over the PUSCH. According to modified RE mapping scheme <NUM>, rate-matched bits are mapped to PUSCH REs in a frequency-first manner, according to which the PUSCH REs of an RB pair are filled in a column-wise fashion. During each of a series of mapping passes, rate-matched bits are mapped to the PUSCH REs of a respective OFDM symbol. For example, the rate-matched bits associated with the same CB as that discussed above in reference to <FIG> may be mapped to the REs of OFDM symbols <NUM> to <NUM> and <NUM> to <NUM> during respective passes <NUM>-<NUM> to <NUM>-<NUM> and <NUM>-<NUM> to <NUM>-<NUM>.

<FIG> depicts a second example of a modified RE mapping scheme that may be implemented in some embodiments in order to support earlier decoding of CBs transmitted over the PUSCH. According to modified RE mapping scheme <NUM>, rate-matched bits are mapped to PUSCH REs of an RB pair in a block-wise time-first manner, according to which the PUSCH REs of the first RB are filled first, in a row-wise fashion, and the PUSCH REs of the second RB are filled second, also in a row-wise fashion. During each of a series of mapping passes, rate-matched bits are mapped, within the OFDM symbols of the RB being filled, to the PUSCH REs of a respective subcarrier. For example, the rate-matched bits associated with the same CB as that discussed above in reference to <FIG> and <FIG> may be mapped, within OFDM symbols <NUM> to <NUM>, to the PUSCH REs of subcarriers <NUM>-<NUM> to <NUM>-<NUM> during respective passes <NUM>-<NUM> to <NUM>-<NUM>.

It is worthy of note that according to each of the mapping schemes depicted in <FIG>, the rate-matched bits of the CB are mapped to half of the PUSCH REs of the RB pair. However, unlike RE mapping scheme <NUM>, which maps some of the rate-matched bits to respective PUSCH REs of each of OFDM symbols <NUM> to <NUM>, modified RE mapping schemes <NUM> and <NUM> map the rate-matched bits only to PUSCH REs comprised in OFDM symbols <NUM> to <NUM>. In various embodiments, this may enable a receiver to begin decoding the CB following OFDM symbol <NUM>, rather than needing to wait until after OFDM symbol <NUM>.

In some embodiments, in order to implement frequency-first mapping of CBs to be transmitted over the PUSCH, the interleaving process for those CBs may be skipped. In various embodiments, in order to implement block-wise time-first mapping of CBs to be transmitted over the PUSCH, a matrix-based channel interleaver mapping may be applied by N-times. For instance, in a non-limiting example, assuming N = <NUM> and Z < <NUM>, an input value Cmux of die channel interleaver matrix may be given by one of Equations (<NUM>), (<NUM>), and (<NUM>) as follows: <MAT> <MAT> <MAT> Where Cmux represents the number of columns of the matrix and <MAT> represents the number of SC-FDMA. symbols carrying the PUSCH in the subframe. In some embodiments, if N = <NUM>, then Cmux may be equal to Cslot. In various embodiments, the interleaver matrix may be given by Equation (<NUM>) as follows: <MAT> Where Cm represents Cmux, and Cb represents the number of blocks. The embodiments are not limited to this example.

<FIG> illustrates a HARQ cycle <NUM> that may be representative of conventional LTE procedures. With respect to HARQ cycle <NUM> and each of the various additional HARQ cycles discussed below, it is assumed that decoding time for a CB is proportional to CB transmission time, and that the amount of time required at the transmitter to process received HARQ feedback for a CB is the same as the amount of time that was required at the receiver to process that CB after receiving it from the transmitter. With respect to HARQ cycle <NUM> in particular, it is assumed that the CB decoding time is three times the CB transmission time. It is to be understood, however, that these assumptions are adopted merely for ease of explanation, and that the embodiments are not limited in this context.

In HARQ cycle <NUM>, a transmitter transmits the data associated with a CB to a receiver. In this example, it takes the transmitter one subframe (subframe <NUM>) to transmit the data associated with the CB to the receiver. The receiver decodes the data during the next three subframes (subframes <NUM> to <NUM>), and then transmits HARQ feedback (FB) for the data during subframe <NUM>. The transmitter decodes the FB during the next three subframes (subframes <NUM> to <NUM>). HARQ cycle <NUM> thus spans subframes <NUM> to <NUM>, a duration of <NUM>.

<FIG> also illustrates a HARQ cycle <NUM>. HARQ cycle <NUM> may be representative of some embodiments in which it takes one subframe to transmit the data associated with the same CB as that of HARQ cycle <NUM>, but the CB decoding time is equal to the CB transmission time. In HARQ cycle <NUM>, as in HARQ cycle <NUM>, the transmitter transmits the data associated with the CB to the receiver during subframe <NUM>. The receiver decodes the data during subframe <NUM>, and then transmits FB for the data during subframe <NUM>. The transmitter decodes the FB during subframe <NUM>. HARQ cycle <NUM> thus spans subframes <NUM> to <NUM>, a duration of <NUM>.

<FIG> illustrates a HARQ cycle <NUM> that may be representative of various embodiments in which the CB decoding time is three times the CB transmission time, but the CB transmission time for the same CB as that of HARQ cycles <NUM> and <NUM> of <FIG> is only one slot instead of one subframe. In some embodiments, one or more of the modified CB segmentation techniques and/or modified RE mapping schemes discussed above may be implemented in order to make it possible to transmit the data associated with the CB within one slot. In HARQ cycle <NUM>, the transmitter transmits the data associated with the CB to the receiver during the first slot of subframe <NUM>. The receiver decodes the data during the next three slots, which comprise the second slot of subframe <NUM> and both slots of subframe <NUM>. The receiver transmits FB for the data during the first slot of subframe <NUM>. The transmitter decodes the FB during the next three slots, which comprise the second slot of subframe <NUM> and both slots of subframe <NUM>. HARQ cycle <NUM> thus spans subframes <NUM> to <NUM>, a duration of <NUM>. This constitutes a latency reduction of <NUM> with respect to the <NUM> duration of HARQ cycle <NUM> of <FIG>, according to which the CB transmission time was one subframe instead of one slot.

<FIG> also illustrates a HARQ cycle <NUM>. HARQ cycle <NUM> may be representative of various embodiments in which the CB transmission time for the same CB as that of HARQ cycles <NUM>, <NUM>, and <NUM> is one slot and the CB decoding time is the same as the CB transmission time. In some embodiments, one or more of the modified CB segmentation techniques and/or modified RE mapping schemes discussed above may be implemented in order to make it possible to transmit the data associated with the CB within one slot. In HARQ cycle <NUM>, is in HARQ cycle <NUM>, the transmitter transmits the data associated with the CB to the receiver during the first slot of subframe <NUM>. The receiver decodes the data during the second slot of subframe <NUM>, and then transmits FB for the data during the first slot of subframe <NUM>. The transmitter decodes the FB during the second slot of subframe <NUM>. HARQ cycle <NUM> thus spans subframes <NUM> to <NUM>, a duration of <NUM>. This constitutes a latency reduction of <NUM> with respect to the <NUM> duration of HARQ cycle <NUM> of <FIG>, according to which the CB decoding time was equal to the CB transmission time, but the CB transmission time was one subframe instead of one slot. The embodiments are not limited to these examples.

In various embodiments in which latency reductions are achieved via one or more of the modified CB segmentation techniques and/or modified RE mapping schemes discussed above, a modified HARQ cycle timing scheme may be implemented in order to account for the reduced transmission and decoding delays. In some embodiments, a variable duration HARQ cycle may be implemented, according to which the HARQ cycle duration may be configured by upper layer signaling.

<FIG> illustrates a HARQ cycle <NUM> that may be representative of various embodiments in which the CB transmission time is one slot, CB decoding time is three times the CB transmission time, and respective feedback for each CB is transmitted separately. In HARQ cycle <NUM>, the transmitter transmits the data (D1) associated with a first CB during the first slot of subframe <NUM>, and transmits the data (D2) associated with a second CB during the second slot of subframe <NUM>. The receiver decodes D1 during the second slot of subframe <NUM> and both slots of subframe <NUM>, and sends feedback (FB1) for D1 during the first slot of subframe <NUM>. The receiver decodes D2 during both slots of subframe <NUM> and the first slot of subframe <NUM>, and then must wait until the first slot of subframe <NUM> to send feedback (FB2) for D2. The transmitter decodes FB1 during the second slot of subframe <NUM> and both slots of subframe <NUM>, and decodes FB2 during the second slot of subframe <NUM> and both slots of sub-frame <NUM>. HARQ cycle <NUM> thus spans subframes <NUM> to <NUM>, a duration of <NUM>.

<FIG> illustrates a HARQ cycle <NUM> that may be representative of some embodiments in which the CB transmission time is one slot, CB decoding time is three times the CB transmission time, and the respective feedback for multiple CBs may be aggregated and transmitted jointly. In HARQ cycle <NUM>, the transmitter transmits the data (D1) associated with the same first CB as that of HARQ cycle <NUM> of <FIG> during the first slot of subframe <NUM>, and transmits the data (D2) associated with the same second CB as that of HARQ cycle <NUM> during the second slot of subframe <NUM>. The receiver decodes D1 during the second slot of subframe <NUM> and both slots of subframe <NUM>. However, in contrast to HARQ cycle <NUM> of <FIG>, in HARQ cycle <NUM>, the receiver refrains from sending feedback for D1 during the first slot of subframe <NUM>. The receiver decodes D2 during both slots of subframe <NUM> and the first slot of subframe <NUM>. The receiver the transmits aggregated feedback (AFB), comprising respective feedback for both D1 and D2, during the first slot of subframe <NUM>. The transmitter decodes the AFB during the second slot of subframe <NUM> and both slots of subframe <NUM>. HARQ cycle <NUM> thus spans subframes <NUM> to <NUM>, a duration of <NUM>, which is the same as that of HARQ cycle <NUM> of <FIG>. In comparison to HARQ cycle <NUM>, HARQ cycle <NUM> involves less overhead, since only one HARQ feedback message is transmitted rather than the two that are transmitted in HARQ cycle <NUM>. On the other hand, according to HARQ cycle <NUM>, the arrival of feedback for D1 at the transmitter is delayed by one subframe, as this feedback is contained in the AFB transmitted during the first slot of subframe <NUM>, rather than arriving via a separate transmission during the first slot of subframe <NUM> as it does in HARQ cycle <NUM>. The embodiments are not limited to these examples.

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

<FIG> illustrates an embodiment of a logic flow <NUM>, which may be representative of the operations executed by one or more embodiments described herein. For example, logic flow <NUM> may be representative of operations that may be performed in some embodiments by UE <NUM> in operating environment <NUM> of <FIG>. As shown in <FIG>, control information for an rTTI block comprising a plurality of rTTIs may be accessed at <NUM>, where the plurality of rTTIs includes one or more rTTIs assigned to a UE. For example, LTE <NUM> of <FIG> may access control information <NUM>, which may constitute control information for an rTTI block comprising a plurality of rTTIs including one or more rTTIs assigned to UE <NUM>. At <NUM>, resources of each of the one or more rTTIs assigned to the UE may be identified based on the control information. For example, UE <NUM> of <FIG> may identify resources of the one or more rTTIs based on control information <NUM>. At <NUM>, wireless communication with an eNB may be performed via resources of at least one of the one or more rTTIs. For example, UE <NUM> of <FIG> may receive data <NUM> from eNB <NUM> via identified resources of at least one of the one or more rTTIs. In another example, UE <NUM> may transmit data <NUM> to eNB <NUM> via identified resources of at least one of the one or more rTTIs. The embodiments are not limited to these examples.

<FIG> illustrates an embodiment of a logic flow <NUM>, which may be representative of the operations executed by one or more embodiments described herein. For example, logic flow <NUM> may be representative of operations that may be performed in some embodiments by eNB <NUM> in operating environment <NUM> of <FIG>. As shown in <FIG>, one or more rTTIs may be assigned to a UE at <NUM>, where the one or more rTTIs are comprised among a plurality of rTTIs of an rTTI block. For example, eNB <NUM> of <FIG> may assign one or more rTTIs of an rTTI block to UE <NUM>. At <NUM>, resources of each of the one or more rTTIs may be allocated for communication with the UE. For example, eNB <NUM> of <FIG> may allocate resources of each of the one or more rTTIs for communication with UE <NUM>. At <NUM>, during a first rTTI of the rTTI block, control information may be transmitted that indicates the respective allocated resources of each of the one or more rTTIs. For example, during a first rTTI of an rTTI block comprising one or more rTTIs that it has assigned to UE <NUM>, eNB <NUM> may transmit control information <NUM>, which may indicate respective allocated resources of each of those one or more rTTIs. The embodiments are not limited to these examples.

Various embodiments of the invention may be implemented fully or partially in software and/or firmware. This software and/or firmware may take the form of instructions contained in or on a non-transitory computer-readable storage medium. Those instructions may then be read and executed by one or more processors to enable performance of the operations described herein. The instructions may be in any suitable form, such as but not limited to source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Such a computer-readable medium may include any tangible non-transitory medium for storing information in a form readable by one or more computers, such as - but not limited to - read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, semiconductor storage media, flash memory, etc..

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

<FIG> illustrates an embodiment of a storage medium <NUM>. Storage medium <NUM> may comprise any non-transitory computer-readable storage medium or machine-readable storage medium, such as an optical, magnetic or semiconductor storage medium. In various embodiments, storage medium <NUM> may comprise an article of manufacture. In some embodiments, storage medium <NUM> may store computer-executable instructions, such as computer-executable instructions to implement logic flow <NUM> of <FIG>. Examples of a computer-readable storage medium or machine-readable storage medium and of computer-executable instructions may include any of the respective examples mentioned above in reference to storage medium <NUM> of <FIG>.

As used herein, the term "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claim 1:
An apparatus for a user equipment, comprising:
at least one memory; and
logic, at least a portion of which is implemented in circuitry coupled to the at least one memory, the logic to:
access (<NUM>), at user equipment, UE, (<NUM>, <NUM>) control information (<NUM>) for a reduced transmission time interval, rTTI, block, the rTTI block comprising a plurality of reduced transmission time intervals, rTTIs, including one or more rTTIs assigned to the UE, each of the plurality of rTTIs comprising a duration of less than one subframe, the control information to be comprised in signals received via resources of a first rTTI of the rTTI block;
identify (<NUM>) resources of each of the one or more rTTIs based on the control information; and
using the identified resources, wirelessly communicate (<NUM>) with an evolved node B, eNB, (<NUM>) via resources of at least one of the one or more rTTIs;
the control information comprising rTTI block-wise downlink scheduling information identifying allocated physical downlink shared channel, PDSCH, and resources of multiple rTTIs of the rTTI block, the rTTI block-wise downlink scheduling information comprising a format matching a physical downlink control channel, PDCCH, downlink control information, DCI, format.