BACKGROUND

Field

[0001] The present application is related generally to wireless protocols, and more specifically, to configuration of the demodulation reference signal in wireless networks. Related Art

[0002] In Long Term Evolution (LTE)-Advanced downlink, the Demodulation Reference Signal (DMRS) is used in Transmission Modes (TMs) 7-10 for Physical Downlink Shared Channel (PDSCH) demodulation. In Release 11 (Rel-11), the DMRS is transmitted in every Resource Block (RB) scheduled for a User Equipment (UE), which may result in high overhead.

[0003] In the related art, an LTE radio frame may contain ten subframes, which are indexed between 0 and 9 as shown in FIG. 1. Each subframe can be further divided into two slots, each of which may include seven Orthogonal frequency-division multiplexing (OFDM) symbols for normal Cyclic Prefix (CP) length, or six OFDM symbols for extended CP length. In the frequency domain, the LTE signal can be divided into units of twelve subcarriers, each of which can span 180 kilohertz (kHz) of bandwidth with a subcarrier spacing of 15 kHz. Such a unit for the duration of one slot is defined as a Resource Block (RB). A RB is further divided into Resource Elements (REs). One RE is one OFDM subcarrier for the duration of one OFDM symbol and is the smallest unit in the LTE time-frequency resource grid. SUMMARY

[0004] Aspects of the present application may include an enhanced NodeB (eNodeB) which may involve a processor, configured to determine a time period for transmission of a

Demodulation Reference Signal (DMRS) based on one or more attributes of a user equipment (UE) associated with the eNodeB, the time period indicative of a duration for which the DMRS is valid; and transmit the time period to the UE.

[0005] Additional aspects of the present application may include a computer program which may involve instructions for determining a time period for transmission of a Demodulation Reference Signal (DMRS) based on one or more attributes of a user equipment (UE) associated with the eNodeB, the time period indicative of a duration for which the DMRS is valid; and transmitting the time period to the UE. The instructions may be stored in the form of a computer readable signal medium or a computer readable storage medium.

[0006] Additional aspects of the present application may include a computer readable storage medium storing instructions for executing a process. The instructions may involve determining a time period for transmission of a Demodulation Reference Signal (DMRS) based on one or more attributes of a user equipment (UE) associated with the eNodeB, the time period indicative of a duration for which the DMRS is valid; and transmitting the time period to the UE. The instructions may be stored in the form of a computer readable signal medium or a computer readable storage medium.

[0007] Additional aspects of the present application may include a method which may involve determining a time period for transmission of a Demodulation Reference Signal (DMRS) based on one or more attributes of a user equipment (UE) associated with the eNodeB, the time period indicative of a duration for which the DMRS is valid; and transmitting the time period to the UE. [0008] Additional aspects of the present application may include a User Equipment (UE), which may include a processor configured to determine a time period for reception of a Demodulation Reference Signal (DMRS) based on the received time period indicative of a duration for which the DMRS is valid.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 illustrates an example LTE frame structure.

[0010] FIG. 2 illustrates an example of a cell in an LTE-advanced system.

[0011] FIG. 3 illustrates an example block diagram of an eNodeB, in accordance with an example implementation.

[0012] FIG. 4 illustrates an example block diagram of a UE, in accordance with an example implementation.

[0013] FIG. 5 illustrates a flow between an eNodeB and a UE, in accordance with an example implementation.

[0014] FIG. 6 illustrates an example flowchart for determining the DMRS time period for a UE, in accordance with an example implementation.

[0015] FIG. 7 illustrates an example flowchart for the CPU of the eNodeB for choosing PDSCH precoder and whether to transmit DMRS or not for a scheduled UE in a particular subframe, in accordance with an example implementation.

[0016] FIGS. 8-10 illustrate example DMRS patterns, in accordance with an example implementation.

[0017] FIG. 11 illustrates an example of a time flow for choosing PDSCH precoder and determining whether to transmit DMRS for a UE, in accordance with an example implementation. [0018] FIG. 12 illustrates an example of a flowchart for processing a DMRS reference subframe, in accordance with an example implementation.

[0019] FIG. 13 illustrates an example time flow of identifying a DMRS reference subframe, in accordance with an example implementation.

DETAILED DESCRIPTION

[0020] The following detailed description provides further details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatic" may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. The implementations described herein are also not intended to be limiting, and can be implemented in various ways, depending on the desired implementation.

[0021] Consider a cell in an LTE- Advanced network as shown in FIG. 2, which includes one eNodeB and multiple UEs associated with it. The eNodeB uses DMRS-based TMs (i.e., TMs 7-10) to send PDSCH data to its associated UEs. The UEs are moving around at different movement speeds. In Rel-11, the DMRS is transmitted in each scheduled RB for a UE to perform PDSCH demodulation. However, this may not be necessary for a low mobility UE, since the channel experienced by the UE does not change much within a short period (e.g., a number of subframes). Therefore, if DMRS transmission can be avoided for some RBs for lower mobility UEs, the DMRS overhead can be reduced.

[0022] Example implementations can reduce the DMRS overhead and thus improve the system throughput performance. Example implementations can be used in Frequency Division Duplexing/Time Division Duplexing (FDD/TDD) LTE-Advanced networks to improve the system performance. Example implementations can also be used in small cell deployment, such as indoor scenarios where most UEs are moving slowly.

[0023] In example implementations, the eNodeB transmits the DMRS only in some of the RBs that are scheduled for some UEs. The example implementations deviate from Rel-11, where the DMRS is transmitted in all RBs scheduled for each UE.

[0024] FIG. 3 illustrates an example block diagram of an Enhanced Node B (eNodeB), in accordance with an example implementation. The eNodeB may include various modules, such as the Central Processing Unit (CPU) module 301, the Radio Resource Control (RRC) module 303, the baseband processor 302, and the memory 304. The CPU 301 can be configured to estimate the movement speed and determine the time period for which the DMRS is valid for each UE. Furthermore, the CPU can be configured to schedule UEs in each subframe, choose the PDSCH precoder for each scheduled UE, and decide whether to transmit the DMRS in the RBs assigned to each scheduled UE. The RRC module 303 generates the RRC signaling of the DMRS valid period for each UE. The baseband module 302 generates PDSCH data and multiplexes the data with the DMRS (if configured to transmit by the CPU) for each scheduled UE. The memory 304 can be configured to store a DMRS status table containing the time period for which the DMRS is valid and a transmission counter for each UE. Further details of each module are provided below.

[0025] FIG. 4 illustrates an example block diagram of a UE, in accordance with an example implementation, such as UE 1 and UE 2 as shown in FIG. 2. The UE 400 may involve the following modules: the CPU module 401, the channel estimator 402, the baseband processor 403, and the memory 404. The CPU module 401 can be configured to perform one or more functions, such as to determine the DMRS reference subframe for each subframe based on the received DMRS valid period via RRC signaling, and to report the UE location to the eNodeB. The channel estimator 402 can be configured to extract the DMRS, perform the channel estimation, and save the channel estimate in the memory 404, if the DMRS reference subframe is the current subframe. The baseband digital signal processing (DSP) module can be configured to perform one or more functions, such as to generate the Positioning RS (PRS) and to demodulate PDSCH in each scheduled subframe. The memory 404 can be configured to store the most recent channel estimate, as well as a DMRS status table that includes the DMRS valid period and a DMRS transmission counter for the UE. Further details of each module are provided below.

[0026] FIG. 5 illustrates a flow between an eNodeB and a UE, in accordance with an example implementation, such as the eNodeB and UE 1 , UE 2 as shown in FIG. 2. At 500, a UE periodically sends the PRS (generated by the baseband processor 403) or direct location report (generated by the CPU 401) to its associated eNodeB. At 501, the CPU 301 of the eNodeB estimates the UE movement speed based on the received PRS or direct location report and determines an appropriate DMRS time period for the UE at 502, as detailed, for example, in FIG. 6. The time period is indicative of a duration for which the present DMRS is valid. At 503, the DMRS time period is then signaled to the UE via RRC signaling (generated by the RRC module 303 of the eNodeB). Note that the DMRS time period for validity may be determined by other attributes of a UE, for example, the reference signaling strength from the UE, or the distance between the eNodeB and the UE.

[0027] At 504, for each subframe, the CPU 301 of the eNodeB schedules UE, chooses the PDSCH precoder for each scheduled UE, and decides whether to transmit DMRS for the RBs assigned to each scheduled UE. The details of how to choose PDSCH precoder and for determining whether to transmit DMRS or not is outlined in FIG. 7. At 505, the baseband processor 302 generates PDSCH data and multiplexes it with the DMRS, if determined by the CPU 301 that the transmission should include the DMRS. At 506, upon receiving the PDSCH at the UE receiver, the CPU 401 finds the DMRS reference subframe based on the received DMRS time period, details of which are provided in FIG. 10. At 507, the baseband processor 403 demodulates the PDSCH based on the channel estimate from the channel estimator if the DMRS reference subframe is the current subframe, or based on the most recent channel estimate stored in the memory 404 otherwise. At 508, the PDSCH is demodulated accordingly.

[0028] FIG. 6 illustrates an example flowchart for determining the DMRS time period for a UE, in accordance with an example implementation, which can be determined for a UE by the CPU 301 of the eNodeB. The DMRS time period is indicative of a time duration for which the DMRS is valid for channel estimation. The same flow can be applied for each UE associated to an eNodeB. At 600, the CPU 301 first determines the category of the UE based on the movement speed of the UE. The speed range of each category can be predefined and adjusted, depending on the desired implementation. For example, the UEs can be divided into three categories: low speed 601, medium speed 602, and high speed 603 as shown in FIG. 6. For each speed category, a value of the DMRS time period is defined in units of one subframe (e.g. 1 ms). In an example implementation, the lower speed category has a longer DMRS time period. The highest speed category is implemented with a 1 ms DMRS time period, or one subframe. The DMRS valid period for the UE is chosen by the CPU based on its speed category.

[0029] The speed category and DMRS time period period for all UEs are stored by the CPU in the memory of the eNodeB as part of a DMRS status table. An example of a DMRS status table is shown in Table I, where UE 1 and UE 2 are the two UEs as shown in FIG. 2. The values of the DMRS valid period are selected for illustration purposes only, and may be configured according to a desired implementation. Furthermore, each UE may have a counter as shown in the last column of the table, which may be set to be 0 initially (the first subframe scheduled for the UE) and added by one by the CPU in each subframe no matter if the UE is scheduled or not, to count the time duration. The counter will be reset to be 0 by the CPU if it reaches or exceeds the value of the DMRS valid period at the subframe when the UE is scheduled. Other configurations are also possible, depending on the desired implementation.

[0030] Table I - Example DMRS status for all associated UE saved in the memory of the eNodeB.

[0031] FIG. 7 illustrates an example flowchart for the CPU of the eNodeB for choosing PDSCH precoder and whether to transmit DMRS or not for a scheduled UE in a particular subframe, in accordance with an example implementation. At 700, the CPU first checks whether the counter is greater than or equal to DMRS time period -1. If the condition is "No", the CPU will use the saved PDSCH precoder in the memory and choose not to transmit DMRS as shown at 701, and increments the counter at 702. The REs reserved for DMRS can be used for other purposes instead, such as transmission of the PDSCH. Otherwise, at 703, the CPU will choose a new second PDSCH precoder by using any available solution and save it in the memory; furthermore, the CPU will choose to transmit the DMRS in each RB assigned to the UE. The counter is then reset to 0 as shown at 704. The selection of a new precoder based on channel state information (CSI) feedback can be implemented by any solution for precoder selection, depending on the desired implementation.

[0032] FIGS. 8-10 illustrate example DMRS patterns, in accordance with an example implementation. Specifically, FIG. 8 is an example of the DMRS pattern for a RB in FDD systems specified in Rel-11. Note that any DMRS pattern for a RB can be used here, depending on the desired implementation. For example, the DMRS Patterns as shown in FIG. 9 and FIG. 10 can be used for normal CP and extended CP configurations in FDD/TDD systems, respectively.

[0033] FIG. 11 illustrates an example of a time flow for choosing PDSCH precoder and determining whether to transmit DMRS for a UE, in accordance with an example

implementation, such as for UE 1 as shown in FIG. 2. For the example of FIG. 11, assume the DMRS valid period of UE 1 is 5 ms and UE 1 is initially scheduled in subframe 0. If UE 1 is scheduled in subframe 2 (within the DMRS valid period) next time, the CPU of the eNodeB will use saved PDSCH precoder in subframe 0 and the DMRS will not be transmitted. If UE 1 is scheduled afterwards in subframe 8, the counter exceeds the DMRS valid period. Thus, the CPU will choose the new PDSCH precoder and the DMRS will be transmitted.

[0034] FIG. 12 illustrates an example of a flowchart for processing a DMRS reference subframe, in accordance with an example implementation. Specifically, FIG. 12 illustrates the flowchart for the CPU of the UE to determine the DMRS reference subframe in a scheduled subframe. The CPU maintains a table of DMRS status in the memory, which includes the DMRS time period for the UE, a counter, and a field to indicate whether the DMRS reference subframe is current subframe or not. The counter is set to be 0 initially (the first subframe scheduled for the UE) and incremented by one by the CPU for each subframe no matter whether the UE is scheduled or not. The counter will be reset to be 0 by the CPU if it reaches or exceeds the value of the DMRS time period at the subframe when the UE is scheduled. Table II gives an example of a DMRS status table for UE 1 as shown in FIG. 2, where the DMRS valid period is assumed to be 5 ms. The third field of the table is updated in each scheduled subframe as follows. [0035] At 1200, the CPU first checks whether the counter is greater than or equal to DMRS valid period -1. If the condition is "Yes", the DMRS reference subframe is determined to be the current subframe as shown at 1203, and the CPU will fill in the field with "Yes", wherein the counter is reset to zero as shown at 1204. Otherwise, the field will be set to be "No", as shown at 1201, and the counter is incremented at 1202.

[0036] Table II - DMRS status saved in the memory of the UE.

[0037] FIG. 13 illustrates an example time flow of identifying a DMRS reference subframe, in accordance with an example implementation. In the example of FIG. 13, the DMRS reference subframe is identified for UE 1 as shown in FIG. 2. Assume the DMRS time period of UE 1 is 5 ms and UE1 is initially scheduled in subframe 0. If UE 1 is scheduled in subframe 2 for the next time, the field indicator whether the DMRS reference subframe is current subframe will be set to be "No". If UE 1 is scheduled afterwards in subframe 8, the counter will exceed the DMRS time period for validity. Thus, the field will be set to be "Yes".

[0038] Although example implementations have been described with respect to movement speed, other factors may also be taken into consideration in conjunction with, or in replacement of UE movement speed, depending on the desired implementation. For example, if the cell associated with the eNodeB is small with mostly stationary or slow moving UEs (e.g., indoor setting), then distance from the cell may be used in consideration, wherein UEs that are substantially stationary and located close to the eNodeB may have longer time periods of DMRS validity, as they are not expected to exit the cell environment. A person of ordinary skill in the art can utilize any combination of factors for the eNodeB environment for determining whether to transmit DMRS or not for overhead management purposes.

[0039] Finally, some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to most effectively convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.

[0040] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing,"

"computing," "calculating," "determining," "displaying," or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.

[0041] Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible media suitable for storing electronic information. A computer readable signal medium may include non-tangible mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0042] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example

implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

[0043] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example

implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.

[0044] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.