Flexible TDD uplink-downlink configuration with flexible subframes
09768942 · 2017-09-19
Assignee
Inventors
Cpc classification
H04L5/0007
ELECTRICITY
H04W72/20
ELECTRICITY
H04W76/28
ELECTRICITY
H04L5/14
ELECTRICITY
International classification
Abstract
The invention relates to a method for communicating based on a flexible TDD configuration by introducing flexible subframes, selectively usable as a downlink or uplink subframe in a manner avoids a transition from a (non-)flexible downlink subframe n to a (non-)flexible uplink subframe n+1. Furthermore, the invention allows reducing the number and types of uplink transmissions that would be pending for a flexible subframe, by defining HARQ uplink feedback timings based on the HARQ uplink feedback timings for the static TDD configurations such that HARQ uplink feedback is never transmitted in a flexible subframe, and also by releasing configurations for periodic uplink transmissions such as, SPS-scheduled uplink data transmissions, periodic CSI report, uplink sounding, random access, and scheduling requests.
Claims
1. A method for communicating between a mobile station and a base station in a communication system based on one out of at least one flexible Time Division Duplex (TDD) configuration, wherein each of the at least one flexible TDD configuration defines subframes of a radio frame as an uplink subframe, a downlink subframe, a special subframe or a flexible subframe, and defines at least one subframe n.sub.flex of the radio frame as a flexible subframe such that subframe n.sub.flex−1 is a special subframe or an uplink subframe, and subframe n.sub.flex+1 is a downlink subframe or a special subframe, wherein the flexible subframe is selectively usable as a downlink or uplink subframe, the method comprising: transmitting control information for an uplink resource assignment, from the base station to the mobile station, in a subframe that assigns uplink resources in a flexible subframe; and determining by the mobile station and the base station the flexible subframe is to be used as an uplink subframe, in case a Cyclic Redundancy Check part of the control information for an uplink resource assignment is scrambled with one of: a Paging-Radio Network Temporary Identifier (RNTI), a System Information-RNTI, a Random Access-RNTI, a Multimedia Broadcast Multicast Service-RNTI, and a predefined flexible-TDD-RNTI, wherein the control information for an uplink resource assignment indicates an invalid value of uplink resources, the control information for an uplink resource assignment is a Downlink Control Information (DCI) Format 0 or 4, the control information for an uplink resource assignment is transmitted from the base station in resources of a common search space, and the control information for the uplink resource assignment indicates a predefined power control value for the uplink resource assignment.
2. The method according to claim 1, wherein the communication between the mobile station and the base station is based either on one out of a plurality of static TDD configurations or on one out of the at least one flexible TDD configuration, wherein each of the static TDD configurations defines subframes of a radio frame as an uplink subframe, a downlink subframe or a special subframe, and wherein the at least one flexible TDD configuration defines the subframes of the radio frame as an uplink subframe, a downlink subframe or a special subframe the same as a corresponding static TDD configuration with the exception of further defining the at least one subframe n.sub.flex as a flexible subframe, wherein the at least one flexible TDD configuration defines the at least one subframe n.sub.flex as a flexible subframe such that subframe n of the corresponding static TDD configuration is an uplink subframe, where n=n.sub.flex.
3. The method according to claim 2, wherein a plurality of retransmission protocol uplink feedback timings, for previous downlink transmissions received by the mobile station, is predefined for the plurality of static TDD configurations, one retransmission protocol uplink feedback timing per static TDD configuration, wherein at least one retransmission protocol uplink feedback timing, for previous downlink transmissions received by the mobile station, is predefined for the at least one flexible TDD configuration, one retransmission protocol uplink feedback timing per flexible TDD configuration, and wherein each of the at least one retransmission protocol uplink feedback timing for a flexible TDD configuration is the same as one out of the plurality of retransmission protocol feedback uplink timings for the static TDD configurations, such that the retransmission protocol uplink feedback is transmitted by the mobile station only in an uplink, downlink or special subframe.
4. The method according to claim 1, wherein the flexible TDD configuration is pre-configured in the mobile station and the base station, and the mobile station receives an identifier from the base station identifying the flexible TDD configuration to be used for communication, or wherein the mobile station, communicating based on a first static TDD configuration, receives an indication from the base station to use a flexible TDD configuration, and the mobile station determines the flexible TDD configuration to be used for communication based on the first static TDD configuration by determining at least one subframe n.sub.flex of the radio frame as a flexible subframe such that subframe n.sub.flex−1 is a special subframe or an uplink subframe, and subframe n.sub.flex+1 is a downlink subframe or a special subframe, and subframe n of the corresponding static TDD configuration is an uplink subframe, where n=n.sub.flex.
5. The method according to claim 1, comprising: determining by the mobile station and the base station the flexible subframe is to be used as an uplink subframe, in case an uplink transmission from the mobile station is pending for the flexible subframe, and determining by the mobile station and the base station the flexible subframe is to be used as a downlink subframe, in case no uplink transmission from the mobile station is pending for the flexible subframe.
6. The method according to claim 1, wherein the mobile station transmits a retransmission protocol uplink feedback to the base station for a flexible subframe which is determined to be used for uplink communication.
7. A mobile station for communicating with a base station in a communication system based on one out of at least one flexible Time Division Duplex (TDD) configuration, wherein each of the at least one flexible TDD configuration defines subframes of a radio frame as an uplink subframe, a downlink subframe, a special subframe or a flexible subframe, and defines at least one subframe n.sub.flex of the radio frame as a flexible subframe such that subframe n.sub.flex−1 is a special subframe or an uplink subframe, and subframe n.sub.flex+1 is a downlink subframe or a special subframe, wherein the flexible subframe is selectively usable as a downlink or uplink subframe, the mobile station comprising: a receiver, which, in operation, receives control information for an uplink resource assignment, from the base station, in a subframe that assigns uplink resources in a flexible subframe; and processing circuitry, coupled to the receiver, which, in operation, determines the flexible subframe is to be used as an uplink subframe, in case a Cyclic Redundancy Check part of the control information for an uplink resource assignment is scrambled with one of: a Paging-Radio Network Temporary Identifier (RNTI), a System Information-RNTI, a Random Access-RNTI, a Multimedia Broadcast Multicast Service-RNTI, and a predefined flexible-TDD-RNTI, wherein the control information for an uplink resource assignment indicates an invalid value of uplink resources, the control information for an uplink resource assignment is a Downlink Control Information (DCI) Format 0 or 4, the control information for an uplink resource assignment is transmitted from the base station in resources of a common search space, and the control information for the uplink resource assignment indicates a predefined power control value for the uplink resource assignment.
8. The mobile station according to claim 7, wherein the communication with the base station is based either on one out of a plurality of static TDD configurations or on one out of the at least one flexible TDD configuration, wherein each of the static TDD configurations defines subframes of a radio frame as an uplink subframe, a downlink subframe or a special subframe, and wherein the at least one flexible TDD configuration defines the subframes of the radio frame as an uplink subframe, a downlink subframe or a special subframe the same as a corresponding static TDD configuration with the exception of further defining the at least one subframe nflex as a flexible subframe, wherein the at least one flexible TDD configuration defines the at least one subframe n.sub.flex as a flexible subframe such that subframe n of the corresponding static TDD configuration is an uplink subframe, where n=n.sub.flex.
9. The mobile station according to claim 8, the mobile station communicating based on a first static TDD configuration, the mobile station comprising: a memory adapted to store the plurality of static TDD configurations, wherein the receiver, in operation, receives an indication from the base station to use a flexible TDD configuration, and wherein the processing circuitry, in operation, determines, in response to the received indication, the flexible TDD configuration to be used for communication, based on the first static TDD configuration by determining at least one subframe n.sub.flex of the radio frame as a flexible subframe such that subframe n.sub.flex−1 is a special subframe or an uplink subframe, and subframe n.sub.flex+1 is a downlink subframe or a special subframe, and subframe n of the corresponding static TDD configuration is an uplink subframe, where n=n.sub.flex.
10. The mobile station according to claim 7, the mobile station comprising: a memory adapted to store the flexible TDD configuration, wherein the receiver, in operation, receives an identifier from the base station, identifying the flexible TDD configuration to be used for communication.
11. The mobile station according to claim 7, wherein the flexible TDD configuration defines at least one subframe of the radio frame as an uplink subframe.
12. The mobile station according to claim 7, wherein the at least one flexible TDD configuration corresponds to a static TDD configuration defining the most uplink subframes in a radio frame.
13. The mobile station according to claim 7, wherein the processing circuitry, in operation, determines the flexible subframe is to be used as an uplink subframe, in case an uplink transmission from the mobile station is pending for the flexible subframe, and determines the flexible subframe is to be used as a downlink subframe, in case no uplink transmission from the mobile station is pending for the flexible subframe.
14. The mobile station according to claim 7, wherein the processing circuitry, in operation, determines the flexible subframe is to be used as a downlink subframe, in case a Cyclic Redundancy Check part of control information for a downlink resource assignment is scrambled with one of: a Paging-Radio Network Temporary Identifier (RNTI), a System Information-RNTI, a Random Access-RNTI, a Multimedia Broadcast Multicast Service-RNTI, and a predefined flexible-TDD-RNTI.
15. The mobile station according to claim 7, wherein in case the processing circuitry of the mobile station determines the flexible subframe nflex of the radio frame is determined to be used as a downlink subframe and in case subframe n−1 of said radio frame is a special subframe, the processing circuitry determines that the special subframe n−1 of said radio frame is usable as a downlink subframe instead of as a special subframe.
16. The mobile station according to claim 7, wherein in case the mobile station communicates based on one of the at least one flexible TDD configuration, a transmitter of the mobile station, in operation, transmits a retransmission protocol uplink feedback, for previous downlink transmissions received by the mobile station, in a flexible subframe.
17. A base station for communicating with a mobile station in a communication system based on one out of at least one flexible Time Division Duplex (TDD) configuration, wherein each of the at least one flexible TDD configuration defines subframes of a radio frame as an uplink subframe, a downlink subframe, a special subframe or a flexible subframe, and defines at least one subframe n.sub.flex of the radio frame as a flexible subframe such that subframe n.sub.flex−1 is a special subframe or an uplink subframe, and subframe n.sub.flex+1 is a downlink subframe or a special subframe, wherein the flexible subframe is selectively usable as a downlink or uplink subframe, the base station comprising: a transmitter, which, in operation, transmits control information for an uplink resource assignment, to the mobile station, in a subframe that assigns uplink resources in a flexible subframe; and processing circuitry, coupled to the transmitter, which, in operation, determines the flexible subframe is to be used as an uplink subframe, in case a Cyclic Redundancy Check part of the control information for an uplink resource assignment is scrambled with one of: a Paging-Radio Network Temporary Identifier (RNTI), a System Information-RNTI, a Random Access-RNTI, a Multimedia Broadcast Multicast Service-RNTI, and a predefined flexible-TDD-RNTI, wherein the control information for an uplink resource assignment indicates an invalid value of uplink resources, the control information for an uplink resource assignment is a Downlink Control Information (DCI) Format 0 or 4, the control information for an uplink resource assignment is transmitted from the base station in resources of a common search space, and the control information for the uplink resource assignment indicates a predefined power control value for the uplink resource assignment.
18. The base station according to claim 17, wherein the communication with the mobile station is based either on one out of a plurality of static TDD configurations or on one out of the at least one flexible TDD configuration, wherein each of the static TDD configurations defines subframes of a radio frame as an uplink subframe, a downlink subframe or a special subframe, and wherein the at least one flexible TDD configuration defines the subframes of the radio frame as an uplink subframe, a downlink subframe or a special subframe the same as a corresponding static TDD configuration with the exception of further defining the at least one subframe n.sub.flex as a flexible subframe, wherein the at least one flexible TDD configuration defines the at least one subframe n.sub.flex as a flexible subframe such that subframe n of the corresponding static TDD configuration is an uplink subframe, where n=n.sub.flex.
Description
BRIEF DESCRIPTION OF THE FIGURES
(1) In the following the invention is described in more detail with reference to the attached figures and drawings.
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
DETAILED DESCRIPTION OF THE INVENTION
(15) The following paragraphs will describe various embodiments of the invention. For exemplary purposes only, most of the embodiments are outlined in relation to a radio access scheme according to 3GPP LTE (Release 8/9) and LTE-A (Release 10/11/12) mobile communication systems, partly discussed in the Technical Background section above. It should be noted that the invention may be advantageously used for example in a mobile communication system such as 3GPP LTE-A (Release 10/11/12) communication systems as described in the Technical Background section above, but the invention is not limited to its use in this particular exemplary communication networks.
(16) The term “static TDD configuration” refers to the TDD uplink/downlink configuration as defined in the current standard, where the TDD configuration defines for each subframe of a radio frame whether same is a downlink, uplink or special subframe. The term “TDD configuration index” is a number (currently 0-6) respectively associated with one out of the seven possible TDD UL/DL configurations, and is defined in the technical standards of 3GPP (see
(17) The term “flexible subframe” used in the claims and the description shall be understood as a subframe that can be flexibly used as an uplink or downlink subframe; this may be decided separately for each flexible subframe. The term “dynamic downlink subframe” or “flexible downlink subframe” used in the claims and the description shall be understood as a flexible subframe that is used as a downlink subframe. The term “dynamic uplink subframe” or “flexible uplink subframe” used in the claims and the description shall be understood as a flexible subframe that is used as an uplink subframe.
(18) The term “subframe n” refers to any subframe in a radio frame, whereas the term “subframe n.sub.flex” shall refer to a flexible subframe.
(19) The term “scrambling” used in the claims in connection with the error detection code and used in the detailed description mainly in connection with a CRC (as an example of the error detection code) refers to the process of implicitly encoding e.g. an identifier into the error detection code (CRC). The term “masking” and also the term “configured by” is used equivalently to “scrambling” in the technical field to mean that an identifier is encoded into a CRC, or more general, into an information element (e.g. a DCI).
(20) The term “invalid parameter” used in the claims and the description shall be broadly understood as a parameter having an invalid value, thus constituting an invalid parameter.
(21) In the following, several embodiments of the invention will be explained in detail. The explanations should not be understood as limiting the invention, but as mere examples of the invention's embodiments to better understand the invention. A skilled person should be aware that the general principles of the invention as laid out in the claims can be applied to different scenarios and in ways that are not explicitly described herein. Correspondingly, the following scenarios assumed for explanatory purposes of the various embodiments shall not limit the invention as such.
(22) The various embodiments explained for the invention in general refer to TDD configurations and in particular shall provide an improved and more flexible TDD configuration and related mechanisms/processes.
First Embodiment
(23) A first set of embodiments of the invention mainly relates to the definition of the flexible TDD configuration, and in particular to how a flexible subframe can be introduced into the TDD configuration(s). Until now a static TDD configuration defines uplink, downlink and special subframe on a radio frame basis, and with a periodic pattern of 5 ms or 10 ms. The uplink subframes can only be used for uplink communications, and conversely the downlink subframes only for downlink communications. Therefore, the TDD configurations are rather fix and static. The change between the seven available TDD configurations is slow, and not practicable for adapting the TDD operation to fast changing traffic conditions.
(24) By introducing at least one flexible subframe in each radio frame, i.e. by defining at least one flexible subframe in a flexible TDD configuration, it is possible to make the TDD operation more flexible; the flexible subframe may be used as a downlink or uplink subframe.
(25) In general, a transition from a downlink subframe n to an uplink subframe n+1 shall be avoided, since then the UE would need to switch its circuitry from reception to transmission and apply timing advance adjustments, as explained in the Background section in connection with the special subframes and the guard period.
(26) Although in the following it is assumed for simplicity that two (or more) subsequent subframes are not defined as flexible, according to one variant of the first embodiment it is indeed possible, as long as a transition of a flexible downlink subframe to a flexible uplink is avoided. Subsequent flexible subframes can be defined as flexible, in which case however the particular use of the first subframe may already fix the use of the next (and possibly further) flexible subframe(s). In one extreme case, for example, a flexible TDD configuration F0 can be defined with the sequence of D, S, F, F, F, D, S, F, F, F for subframes 0-9 of a radio frame. When the flexible subframe of index 2 is determined to be an uplink subframe, then the subsequent flexible subframe of index 3 can be freely selected to be either uplink or downlink. However, in case the flexible subframe of index 2 is determined to be a downlink subframe, then the subsequent flexible subframe of index 3 (and also the one of index 4) must be used as downlink subframe too, so as to avoid the transition from downlink to uplink between two subsequent subframes. The same applies to the remaining flexible subframes of the above-indicated TDD configuration sequence. This concept can also be applied to other flexible TDD configurations.
(27) According to another variant of the embodiment, in order to avoid the need for a guard period of a special subframe, a flexible subframe in a flexible TDD configuration shall always follow after a subframe, the end of which is defined for uplink transmissions, and shall always be ahead of (precede) a subframe, the beginning of which is defined for downlink transmissions. More specifically for 3GPP LTE a subframe n can only be a flexible subframe n.sub.flex if: subframe n.sub.flex−1 is a special or uplink subframe, or subframe n.sub.flex−1 is a downlink subframe where no downlink transmission actually takes place; subframe n+1 is a downlink or a special subframe.
(28) Alternatively, a subframe n can only be a flexible subframe n.sub.flex if: subframe n.sub.flex−1 is a special or uplink subframe, or subframe n.sub.flex−1 is a downlink subframe where no downlink transmission actually takes place, subframe n.sub.flex+1 is a downlink or special subframe, or subframe n.sub.flex+1 is an uplink subframe where no uplink transmission actually takes place.
(29) However, the above requirement of whether an uplink/downlink transmission actually takes place in subframes n.sub.flex+1 or n.sub.flex−1 complicates the resource management and also introduces potential error cases if transmissions are missed or occur erroneously. Consequently, the above requirements may be further improved as follows:
(30) A subframe n can only be a flexible subframe n.sub.flex if subframe n.sub.flex−1 is a special or uplink subframe, subframe n.sub.flex+1 is a downlink or special subframe.
(31) Any flexible TDD configuration that fulfills the above requirements for its flexible subframes may be used by the mobile station and the base station according to the invention. Consequently, a flexible subframe always follows after either a special or uplink subframe, and always precedes a downlink or special subframe, such that transitions from a flexible subframe to an uplink subframe, and transitions from a downlink subframe to a flexible subframe are avoided.
(32) Although only one flexible TDD configuration is mentioned so far, there may be several flexible TDD configurations (e.g. F0-F6), similar to the static TDD configurations 0-6 already predefined according to 3GPP LTE (see
(33) The above-described flexible TDD configuration may define the uplink, downlink, special and flexible subframes, in any way suitable, as long as the requirements for the flexible subframes are fulfilled. However, according to a more preferable variant of the first embodiment, the flexible TDD configurations shall match the corresponding static TDD configurations, except for the flexible subframes. This allows an efficient communication between the eNodeB and the various UEs. More specifically, some UEs will support the use of the flexible TDD configurations (in addition to the use of the static TDD configurations), however other UEs might not. Therefore, it is advantageous if all UEs have the same meaning on the subframe type of as many subframes in a radio frame as possible. Another advantage is that due to the correspondence between a static TDD configuration m and the flexible TDD configuration Fm, the indication to the UE instructing it to use a flexible TDD configuration can be simply an indication to use a flexible instead of static TDD configuration. Hence, the control signaling overhead can be reduced compared to a solution that require the explicit signaling of a flexible TDD configuration on top of the signaling of a static TDD configuration. More details will be explained later.
(34) According to this variant, the flexible TDD configurations are defined to be the same as the corresponding static TDD configurations, with the exception of the at least one flexible subframe in the radio frame; in other words, a flexible TDD configuration defines the uplink, downlink and special subframes in the same manner as the corresponding static TDD configuration, albeit that the flexible TDD configuration defines at least one subframe as a flexible subframe. Although not directly important to the invention, it should be noted that also other parameters defined for a static TDD configuration are likewise re-used for the flexible TDD configuration, such as the definition of a special subframe and its downlink pilot time slot, guard period and uplink pilot time slot.
(35) This will be exemplified in the following with use of
(36)
(37) The basis of
(38) The flexible TDD configuration of
(39) In order to avoid measurement corruption caused by measurements in flexible subframes, in a preferred variant of the first embodiment, a UE will not use flexible subframes to perform these measurements, not even, if a flexible subframe is determined to be used as downlink subframe; instead, the UE will base its measurements exclusively on non-flexible (or static) downlink or special subframes of the flexible TDD configurations (or static TDD configuration).
(40) Correspondingly, the more beneficial variant of
(41) Another more beneficial variant of the flexible TDD configuration definition is illustrated in
(42) Alternatively to the above requirement of always defining at least one uplink subframe for a flexible TDD configuration, the following requirement shall be fulfilled by a flexible TDD configuration: the flexible TDD configuration shall define the subframe of TDD configuration subframe index=2 always as an uplink subframe, as illustrated by
(43) The following explanation of further variants and further embodiments will mainly focus on the flexible TDD configuration of
(44) By introducing a flexible subframe according to a flexible TDD configuration, it is not only possible to flexibly adapt one flexible TDD configuration to the uplink/downlink needs, but overall the downlink capacity of the flexible TDD configuration increases compared to that of the corresponding static TDD configuration. Therefore, when assuming the flexible TDD configurations of
(45) TABLE-US-00004 TABLE Downlink Capacity Gain for flexible TDD configurations UL/DL Max # of DL Max # of DL Max DL configuration subframes in subframes in static capacity FM vs m flexible TDD config TDD config gain Fm vs m F0 vs 0 5.28 3.28 +~61% F1 vs 1 7.28 5.28 +~38% F2 vs 2 8.28 7.28 +~14% F3 vs 3 7.64 6.64 +~15% F4 vs 4 8.64 7.64 +~13% F5 vs 5 8.64 8.64 ±0 F6 vs 6 6.28 4.28 +~47%
(46) As apparent, there is no downlink capacity improvement for flexible TDD configuration F5, which is logical since there is no flexible subframe in the flexible TDD configuration F5. However, this is no loss for the system, since the main benefit of flexible subframes is to adapt to downlink traffic needs by adding additional downlink capacity through dynamic downlink subframes; flexible/static TDD configuration 5 already provides the maximum TDD downlink capacity, with the assumption that one subframe per radio frame is required to be uplink for transmitting corresponding ACK/NACK feedback in the uplink which is vital for the HARQ functionality and corresponding capacity gains related thereto.
(47) Considering the downlink capacity gains of the above table, another variant of the first embodiment does not define seven flexible TDD configurations as assumed so far, but only one or more flexible TDD configurations where the downlink capacity gain is maximum. For example, only the flexible TDD configurations F0 and/or F6 and/or F1 and/or F3 and/or F2 and/or F4 could be defined and used. Correspondingly, this subset of flexible TDD configuration(s) provides the largest potential gain relative the corresponding static TDD configuration, and can also most easily accommodate flexible subframes without affecting legacy UE measurements, as mentioned (they start out with a balanced or slightly uplink-biased TDD configuration).
(48) So far, different definitions of flexible TDD configurations are presented and the various advantages are explained. In the following, it will be explained how the mobile station and base station can determine and control the use of any of the above-described flexible TDD configurations. Again, for illustration purposes the set of flexible TDD configurations according to
(49) According to one variant of the first embodiment, it may be assumed that the flexible TDD configurations are predefined in the UEs and eNodeBs, in a similar manner as done for the static TDD configurations. Put differently, the UE and eNodeB already have stored in a memory information on the flexible TDD configurations and the particular subframe type definitions given by the flexible TDD configurations. The eNodeB may thus select among the various flexible (and static) TDD configurations the one to be used in the future, and, provided that the eNodeB decides that a flexible TDD configuration is to be used for communication, it may provide to the UE a corresponding indication identifying the particular decided flexible TDD configuration to be used. The decision by the eNodeB to change to a flexible TDD configuration and the selection by the eNodeB as to which particular flexible TDD configuration to use, may be based on various parameters, but is not further specified, since it is not the focus of the present invention.
(50) Upon receiving the indication, the UE will in turn gather the corresponding information on the indicated flexible TDD configuration from its memory, and use the indicated flexible TDD configuration for its further communication. The indication of the particular flexible TDD configuration can be either transmitted/broadcast to all UEs of a cell, or may be transmitted specifically to only a subset of at least one UE of a cell.
(51) As explained in the Background section, the static TDD configuration may be indicated by a TDD-config parameter in SIB1 to all UEs in a cell. Similarly, in one variant, a separate parameter flexTDD-config can be defined in SIB1 to carry the indication as to which flexible TDD configuration to be used. Alternatively, the TDD-config parameter already defined for identifying the particular static TDD configuration can be reused or extended to be able to identify the further flexible TDD configurations.
(52) In any case, the eNodeB may directly indicate the flexible TDD configuration to the UE by using an appropriate identifier able to distinguish the various different flexible (and static) TDD configurations.
(53) UEs that do not support the use of a flexible TDD configuration (e.g. legacy UEs) may simply ignore the instruction and proceed with communicating according to the current static TDD configuration.
(54) Another variant of the first embodiment for controlling the use of the flexible TDD configuration assumes that the flexible TDD configurations match corresponding static TDD configurations except for the flexible subframe(s), as explained in connection with
(55) In this particular variant, the UE and eNodeB do not hold information on the flexible TDD configuration, but merely store the static TDD configuration; then, upon indication from the eNodeB, the UE may derive the particular flexible TDD configuration from a corresponding stored static TDD configuration, as will be explained in detail below.
(56) Again, control of the use of flexible and static TDD configuration is at the eNodeB, which assumedly is communicating with the UE using a static TDD configuration. The eNodeB at some point may decide to use (at least for one UE) a flexible TDD configuration instead of the static TDD configuration that is currently used. The decision of the eNodeB can be based on various parameters, and shall not be further discussed in detail, since it is not the focus of the present invention.
(57) It is assumed for the following explanation that the static TDD configuration currently used shall be made flexible, e.g. instead of static TDD configuration m (e.g. m=0) using flexible TDD configuration Fm (e.g. Fm=F0). In said particular case, it is sufficient for the eNodeB to transmit an indication to the UEs instructing to make the current static TDD configuration flexible; the corresponding indication could be implemented for example by an on/off parameter that is transmitted to a UE or to a group of UEs in a dedicated or broadcast message, or for example by means of the presence or non-presence of a parameter in a configuration message.
(58) Alternatively, if the eNodeB considers it beneficial to use another flexible TDD configuration not based on the current static TDD configuration, it needs to change the static TDD configuration in addition to instructing the UE(s) to make the TDD configuration flexible.
(59) Since the UE does not have the direct information on how the flexible TDD configuration defines the subframes, the UE derives same from the static TDD configuration by applying the above-mentioned requirements on each subframe of the static TDD configuration, and by changing the subframe type to flexible for the subframes fulfilling the requirements. In the particular example of flexible TDD configurations of
(60) The eNodeB does the same and equally derives the flexible TDD configuration to be used from a corresponding static TDD configuration by applying the corresponding algorithm. In any case, both the UEs and the eNodeB derived a particular flexible TDD configuration (e.g. one of flexible TDD configurations F0-F6 of
(61) These two variant are illustrated in the flow diagrams of
Second Embodiment
(62) The second embodiment of the invention deals with the determination of whether a flexible subframe is used as a downlink or uplink subframe. This second embodiment shall be regarded independent from the first embodiment, since the concept of how a flexible subframe is actually used, i.e. for downlink or uplink, is independent from the concept of how exactly a flexible TDD configuration is defined and indicated. Of course, the first and second embodiments may also be used in any combination.
(63) For the proper use of a flexible TDD configuration and for taking maximum advantage of the flexible subframes, it is important that the UE and the eNodeB have the same understanding of how a particular flexible subframe is to be used. This helps to avoid a waste of resources, in those cases where the UE and the eNodeB (want to) use the flexible subframe differently. In general, an explicit indication by the eNodeB to the UE or an implicit agreement on both sides may allow having the same flexible subframe understanding. Several variants thereof will be explained in the following.
(64) Overall, once the particular use of a flexible subframe is decided, the UE and eNodeB may use the flexible downlink/uplink subframe as any of other non-flexible downlink/uplink subframes. Correspondingly, the UE shall have a downlink grant (PDCCH or EPDCCH, DCI Format 1, 1A, 1B, 1C, 1D, 2, 2A, 2B, 2C, 2D) to receive a downlink transmission in a flexible downlink subframe, and shall have received previously a corresponding uplink resource assignment that grants the UE resources in the flexible uplink subframe to perform an uplink transmission.
(65) According to a first implicit variant, for each flexible subframe separately, the UE and eNodeB determine whether any uplink transmissions from the UE are pending for said flexible subframe. In a more general variant, it can also be said that the UE and the eNodeB determine whether any uplink transmission opportunity is pending for said flexible subframe, the difference being that the eNodeB might not be able to know beforehand whether the UE actually will take the uplink transmission opportunity at the flexible subframe for transmitting an uplink transmission, e.g. at an SPS-scheduled resource of the flexible subframe.
(66) If at least one uplink transmission (opportunity) is supposed to be transmitted by the UE in the flexible subframe, the corresponding flexible subframe shall be used as an uplink subframe, which gives the UE the opportunity to actually transmit the pending uplink transmission, as well as other uplink transmissions (e.g. dynamically scheduled by the eNodeB, knowing that said particular flexible subframe will be usable for an uplink communication). Conversely, if no uplink transmission is pending for a flexible subframe, said flexible subframe can be determined to be usable as a downlink subframe; the eNodeB can schedule downlink transmissions to the UE in said flexible subframe.
(67) The UE directly knows (amongst others from the specified timing relations for data transmissions, hybrid automatic repeat request (HARQ) feedback, and its own transmission status such as its uplink buffer status or synchronization status, together with the detected dynamic, semi-persistent or periodic scheduling assignments) whether an uplink transmission is pending for a flexible subframe or not. The eNodeB on the other hand may not know for sure all of the pending uplink transmissions, but may only know some of them. For others, the eNodeB may only be aware of other potential uplink transmission opportunities that may fall on a flexible subframe. This will be discussed in more detail with regard to the following non-exhaustive examples of pending uplink transmissions.
(68) As explained in the Background Section, HARQ is applied in the downlink as well as the uplink, for which reason also the UE is supposed to transmit a HARQ uplink feedback (ACK/NACK/DTX) to the eNodeB for a downlink transmission received previously by the UE; such feedback is transmitted by the UE either on PUCCH or PUSCH. The particular HARQ feedback timing according to 3GPP LTE is given exemplary in
(69) Another pending uplink transmission could be a channel state information (CSI) report that is either transmitted regularly (e.g. periodically) from the UE to the eNodeB or is scheduled individually by the eNodeB. In both cases, the UE and the eNodeB know beforehand whether a CSI report is configured/scheduled for a flexible subframe or not, and thus the same understanding can be achieved between the UE and the eNodeB.
(70) Another pending uplink transmission could be an uplink data transmission scheduled according to a semi-persistent allocation. Semi-persistent allocations allow a UE to regularly use particular resources for uplink transmissions; the semi-persistent allocation can be changed or released by the eNodeB. Since it is the eNodeB that configures a semi-persistent allocation for a UE, the eNodeB generally knows beforehand when a semi-persistently allocated resource falls on a flexible subframe. Even if the UE has nothing to transmit, it will transmit dummy data to the eNodeB using the SPS resource. What the eNodeB does not know beforehand is whether the semi-persistently allocated resource is still used by the UE, since the UE might implicitly release the configuration for the semi-persistent allocation, without informing the eNodeB. Such an implicit release is performed by the UE after sending only padding data for a specific number of SPS transmissions, and is specified in detail in TS 36.321 v11.2.0 at the end of chapter 5.10.2 as clearing the configured uplink grant.
(71) Another pending uplink transmission can be a sounding reference symbol (SRS) configured by the eNodeB to be transmitted by the UE regularly or based on an explicit trigger. The eNodeB configures a cell-specific parameter indicating one out of a plurality of subframe sets in which SRS may be transmitted in each radio frame. A UE can then be triggered to transmit an individual SRS, or it can be configured to transmit SRS periodically with a configured periodicity taking the cell-specific parameter into account. More details can be found in LTE—The UMTS Long Term Evolution—From Theory to Practice, Edited by Stefanie Sesia, Issam Toufik, Matthew Baker, chapter 16.6, especially sections 16.6.1 and 16.6.2. Thus, the UE as well as the eNodeB know beforehand the subframe used for sending a sounding reference symbol, and can thus easily determine when a sounding reference symbol is pending for a flexible subframe and when not.
(72) Another pending uplink transmission may be scheduling requests transmitted by the UE to the eNodeB to request uplink resources. In case the UE needs to transmit user data in the uplink and no SPS allocation or other allocations are available for an uplink transmission, the UE can transmit a scheduling request with information on what is to be transmitted, and the scheduler of the eNodeB can consider the scheduling request of the UE and may then provide (if possible) a dynamic uplink resource allocation to the UE. The UE cannot transmit a scheduling request at any time, but has particular configurable opportunities to transmit scheduling requests. Therefore, although the eNodeB cannot know exactly when the UE will indeed transmit a scheduling request, the eNodeB knows the scheduling request opportunities available for the UE in said respect, and can thus determine when a scheduling request opportunity is in a flexible subframe and when not. Therefore, to be on the safe side, the eNodeB will assume that every scheduling request opportunity available to the UE may be potentially used for a scheduling request; i.e. any flexible subframe with a scheduling request opportunity, independently from whether the UE actually sends a scheduling request or not, is considered an uplink subframe. The UE of course behaves in a corresponding manner, by considering a flexible subframe for which a scheduling request opportunity is available, as an uplink subframe; even in view of the UE already knowing sufficiently in time that no scheduling request is indeed pending. In a further embodiment explained later, this will be treated differently.
(73) Another potential pending uplink transmission is a random access message with which the UE can achieve uplink synchronization (when lost by the UE, or at the beginning of a communication), or to connect to a base station or request transmission resources. Similar to the scheduling requests, the UE may not transmit random access message at any time, but has particular opportunities in said respect. Therefore, although the eNodeB cannot know exactly when the UE will indeed transmit a random access message, the eNodeB knows the opportunities the UE has for doing so. Therefore, to be on the safe side, the eNodeB will assume that every opportunity available to the UE to transmit a random access message is indeed used (even if not); i.e. any flexible subframe with a random access opportunity, independently from whether the UE actually sends a scheduling request or not, is considered an uplink subframe. The UE behaves correspondingly, such that both the UE and the eNodeB make the same determination in said respect. In a further embodiment explained later, this will be treated differently.
(74) Still another potential pending uplink transmission is an uplink user data transmission that is dynamically scheduled by the eNodeB. The eNodeB might have provided a dynamic uplink resource allocation to the UE, granting resources on a flexible subframe, for instance by using DCI of one of the Formats 0 or 4 as appropriate. In the current 3GPP LTE system the timings for receiving uplink resource assignments is predefined for the various static TDD configurations.
(75) For instance, in TDD configuration 0, the uplink resource assignment for granting uplink resources in subframe n=4 is expected in subframe 0, i.e. four subframes before; for TDD configuration 6 however, the relation between the uplink resource assignment and the corresponding subframe n=4 for which the uplink resource assignment is intended is different, namely five subframes before. These timing relations defined for static TDD configurations m shall also be used for the corresponding timing relations for flexible TDD configurations Fm.
(76) As can be seen from
(77) Instead of implicitly having the same understanding of how the flexible subframe is to be used, it is also possible to have an explicit control of the flexible subframes in a radio frame, according to a further variant of the second embodiment. In particular, due to the undetected errors in configuration messages (e.g. for SPS or CSI reports), or due to an unknown latency in the UE between the reception of configuration messages and using of same, or due to resource assignments for an uplink transmission missed by the UE, or in case that the UE erroneously detects a resource assignment for uplink transmissions even though no such resource assignment was transmitted by the eNode; in all those cases and of course further cases, the UE and the eNodeB may have a different understanding on how particular flexible subframes should be treated. In addition, as has been described above, the eNodeB is not able to foresee for every kind of potential uplink transmission whether an uplink transmission will indeed take place; for example, regarding scheduling requests, random access messages, or SPS-scheduled uplink transmissions; which thus leads to even less opportunities of using a flexible subframe as a downlink subframe
(78) An explicit use indication for a flexible subframe can thus be advantageous. Preferably, this is controlled by the eNodeB, which transmits a particular instruction to the UE as to how the flexible subframe should be used, i.e. as an uplink or downlink subframe.
(79) According to a first variant, the eNodeB transmits a DCI Format 0 (or alternatively of Format 4, or any other DCI Format that can indicate an uplink resource assignment) to the UE, scrambled and transmitted in a special way such that the UE can derive therefrom how a flexible subframe is to be used. DCI Formats 0 and 4 schedule uplink resources for a UE, as explained above in connection with
(80) Therefore, a DCI Format 0 scrambled in such a manner is not treated by a UE as a normal uplink resource assignment. The use of any of the common RNTIs (or the new RNTI) will cause no backward compatibility problems, since the usage of a common RNTI for scrambling the CRC of a DCI format that can indicate uplink resource assignments does not have any specified meaning so far, but is rather subject of an aspect of the current invention.
(81) Furthermore, instead of transmitting the DCI Format 0 in a UE-specific search space, the eNodeB transmits the specially-scrambled DCI Format 0 in the common search space, such that all UEs in a cell can receive same.
(82) The DCI Format 0 usually comprises an uplink resource allocation, usable for the corresponding subframe. In one alternative, the uplink resource allocation indicated by the DCI Format 0 may actually be used as a valid uplink resource allocation; and the UE can use the uplink resource allocation for transmitting in the uplink at the flexible subframe. However, since said DCI Format 0 would be preferably received by several UEs, this might result in too much interference, when all UEs behave the same and transmit in the uplink at the flexible subframe.
(83) Therefore, according to another alternative, the DCI Format 0 indicates an invalid value for the resource allocation, or the bits that represent the resource assignment carry a predefined value in this case. This improves the error resilience, since the UE may further check whether the specially scrambled and transmitted DCI Format 0, indicates a valid or invalid resource allocation, or matches the predefined value, as applicable. Only in case it indicates an invalid resource allocation, or matches the predefined value, as applicable, the UE determines that the corresponding flexible subframe is to be used as an uplink subframe. In said case, a separate uplink resource assignment for said flexible uplink subframe may be received in a usual manner (e.g. DCI Format 0 scrambled with C-RNTI of a particular UE), to allocate resources to a particular UE to transmit in the uplink.
(84) Since DCI Format 0 of above does not really encode an uplink resource assignment used for an actual uplink transmission, the transmit power control command (TPC command for PUSCH) included in said DCI Format 0 is meaningless too. Therefore, to further increase error resilience the corresponding power control adjustment for PUSCH of DCI Format 0 can be set to a predefined value, e.g. the respective bits are set to 0. In such a case, the UE may preferably assume the power control adjustment to be 0 dB.
(85) If the eNodeB decides that a particular flexible subframe is to be used as an uplink subframe, it transmits such a specially-scrambled DCI Format 0, so as to explicitly inform the UE in said respect. Conversely, the eNodeB will not transmit such a DCI Format 0.
(86) When a UE receives a DCI Format 0, scrambled and transmitted as just explained, it may determine that the flexible subframe is to be used as an uplink subframe; correspondingly, in the absence of such a DCI Format 0 transmission, it will determine that the flexible subframe is to be used as a downlink subframe. The eNodeB can thus explicitly indicate the use of a particular flexible subframe, by transmitting a special DCI Format 0 to the UE.
(87) In addition, if the DCI Format 0 is scrambled with a common RNTI and transmitted in the common search space, it is possible for the eNodeB to reach all (or a subset) of UEs in a cell, which according to the instruction all determine that the flexible subframe is downlink or uplink.
(88) Alternatively to the use of the DCI Format 0 (or 4) as explained above, the eNodeB might reuse a DCI Format that can indicate a downlink resource allocation, such as Format 1, 1A, 1B, 1C, 1D, 2, 2A, 2B, 2C, 2D, to explicitly instruct the UE how to use a flexible subframe. For ease of illustration, the Format 1A is assumed in the following, although the following applies in a similar manner to the other DCI Formats too.
(89) Usually, a downlink resource assignment is transmitted in the same subframe at which the corresponding downlink transmission is performed; in contrast to uplink resource assignments, which are received at least 4 subframes ahead (see above discussion and
(90) In addition, the DCI Format 1A (or more specifically the CRC of DCI Format 1A) is scrambled with one of the common RNTIs, such as the Paging-RNTI, the System Information-RNTI, the Random Access-RNTI or the Multimedia Broadcast Multicast Service-RNTI. These RNTIs are not UE-specific but common to a set or all UEs of a cell. It should be noted however that according to 3GPP standard operation DCI Format 1A can be scrambled with some of these common RNTIs (e.g. for transmission of system information on the assigned PDSCH resources), for which reason the scrambling with one of these common RNTIs does not suffice to distinguish the DCI Format 1A from a “usual” DCI Format 1A for a usual downlink resource assignment. In those cases, the resource assignment indication should be made invalid so as to facilitate said distinction. Consequently, the UE will further check whether the specially-scrambled and specially-transmitted DCI Format 1A also indicates an invalid value for the downlink resource allocation, and only if it finds such an invalid value for the downlink resource allocation, the UE will consider the DCI Format 1A for determining the use of the flexible subframe as a downlink subframe.
(91) Alternatively, a specific RNTI may be reserved for the flexible subframe use indication. For example, in case of an RNTI structure as given in the Table of the Background section is reused, preferably one or more values from the range FFF4-FFFC labeled as “reserved for future use” can be taken in said respect. The use of any of the common RNTIs (or the new RNTI) will cause no backward compatibility problems. In said particular case, it is not necessary to indicate an invalid resource assignment; but, in order to increase error resilience it would be also possible to still provide such an invalid indication for the resource assignment; or even a predefined indication for the resource assignment, such as all bits set to 0.
(92) Furthermore, instead of transmitting the DCI Format 1A in a UE-specific search space, the eNodeB preferably transmits the specially-scrambled DCI Format 1A in the common search space, such that all UEs in a cell can receive same.
(93) Since DCI Format 1A of above does not really encode a downlink resource assignment used for an actual transmission, no corresponding HARQ feedback is expected, and therefore the transmit power control command (TPC command for PUCCH) included in said DCI Format 1A is meaningless too. This transmit power control command is usually used for adjusting the power for the corresponding HARQ feedback in connection with the downlink transmission of the DCI Format 1A. To further increase error resilience however, the corresponding power control adjustment for PUCCH of DCI Format 1A can be set to a predefined value, e.g. the corresponding bits are set to 0. In such a case, the UE may assume the power control adjustment to be 0 dB.
(94) If an eNodeB decides that a particular flexible subframe is to be used as a downlink subframe, it transmits such a specially-scrambled DCI Format 1A, to explicitly inform the UE in said respect. Conversely, the eNodeB will not transmit such a DCI Format 1A, if the eNodeB decides that the flexible subframe should be used as an uplink subframe. The UE, receiving such a specially scrambled and transmitted DCI Format 1A, accordingly identifies the flexible subframe to which the special DCI Format 1A refers (based on the timing relation for an uplink resource allocation) and then determines that the flexible subframe shall be used as a downlink subframe. Accordingly, the UE will expect a DCI carrying with a further downlink resource allocation in the flexible subframe, and the corresponding downlink transmission in the flexible subframe. Correspondingly, in the absence of such a DCI Format 1A transmission, the UE will determine that the corresponding flexible subframe is to be used as an uplink subframe. The eNodeB can thus explicitly indicate the use of a particular flexible subframe, by transmitting a special DCI Format 1A to the UE.
(95) In the above two variants it has been assumed that in the absence of the special DCI Format 0/1A, the UE may determine that the flexible subframe is to be used as downlink/uplink. Instead however, the two above variants may be combined in such a manner that e.g. the DCI Format 0 would explicitly indicate a flexible uplink subframe, and the DCI Format 1A would explicitly indicate a flexible downlink subframe. A lack of explicit indication(s) may furthermore preferably be interpreted by the UE to treat the flexible subframe in the same fashion as it is defined in the corresponding static TDD configuration m.
(96) For the said approach of explicitly indicating the usage of a flexible subframe by means of a DCI scrambled by a common RNTI, it is advantageous to use DCI Format 0 and DCI Format 1A since they have the same size (see Table: DCI Formats in Background section), and thus may be easily detected by the UE during the blind decoding. In addition, DCI format 0 is detected by UEs regardless of their configured uplink transmission mode, and likewise DCI format 1A is detected by UEs regardless of their configured downlink transmission mode (cf. 3GPP TS 36.213 v11.2.0, section 8.0 and section 7.1, respectively).
(97) In a variant to the above embodiments, the usage of the flexible subframe is made for all flexible subframes within a radio frame (or alternatively, for any 5 ms or 10 ms period). In this variant, the UE determines the usage of the first flexible subframe as downlink or uplink according to one or more of the embodiments. The usage of the first flexible subframe then equally determines the usage of the other flexible subframes within the radio frame (or said period). For example assuming configuration F0 as shown in
(98) According to a further improvement, and assuming that a flexible subframe is determined to be used for downlink, the DCI Format 1A (or any of the other downlink resource assignment formats) received in the flexible downlink subframe for the respective downlink transmission in the flexible downlink subframe may carry reserved values in the TPC command for PUCCH, such that the UE can verify these reserved values to further improve the detection of an erroneously received DCI. This is particularly advantageous for DCIs received in flexible subframes if the corresponding HARQ feedback is transmitted together with HARQ feedback corresponding to non-flexible downlink subframes. An example derived from
(99) According to a variant of this embodiment, a special subframe n.sub.flex−1 is changed to a downlink subframe if the subsequent flexible subframe n.sub.flex is used for downlink. As outlined in the Background section, a special subframe n is used to provide a gap when changing from downlink in subframe n−1 to uplink in subframe n+1 at the UE. In case that a flexible subframe is preceded by a special subframe, and said flexible subframe is used for downlink, there is no motivation to provide such a gap in the preceding subframe. Whether the flexible subframe is used for uplink or downlink is, according to other aspects of this invention, known after reception of the DCI at least 4 ms prior to the respective flexible subframe, and consequently at least 3 ms prior to the respective special subframe. Therefore there is sufficient time for the UE to adapt its understanding and change such a special subframe n.sub.flex−1 to a downlink subframe, which increases the downlink capacity and therefore allows a higher throughput. This variant can be easily exemplified regarding flexible downlink configuration F2 according to
Further Embodiment
(100) These further embodiments of the invention relate to the question of how to handle uplink transmissions that would be transmitted in a flexible subframe. Although these embodiments are closely related to the first and second embodiments explained above, they shall be nonetheless treated mostly separately and independently from the various first and second embodiments. Most of the processes and concepts explained in the following do not need a particular flexible TDD configuration to work, or a particular determination of a flexible downlink/uplink subframe; rather, these concepts can applied universally in the context of flexible TDD configurations. Still of course, the following embodiments can be used in any appropriate combination with the first and second embodiments.
(101) As explained in the context with the second embodiment, there may be various different types of uplink transmissions that may be potentially pending for flexible subframe. For one variant of the second embodiment, a pending uplink transmission for a flexible subframe automatically determines the flexible subframe to be uplink, thus preventing flexible subframes to be used for downlink; which is disadvantageous since the purpose of the flexible TDD configurations is to maximize downlink capacity. Also, in case the flexible subframe shall be determined to be used for downlink (irrespective of whether an uplink transmission is pending or not), it is beneficial to define a different handling of those uplink transmissions that would fall onto the flexible subframes.
(102) One embodiment relates to the handling of the HARQ ACK/NACK/DTX feedback such that the HARQ ACK/NACK/DTX feedback, pending for a flexible subframe, is transmitted in another non-flexible uplink subframe. As apparent from
(103) Consequently, the HARQ feedback must be transmitted in uplink subframes, i.e. not in a flexible subframe. Accordingly, a different HARQ feedback timing is to be defined for the flexible TDD configurations, such that the HARQ feedback is never to be transmitted in the flexible subframes. This would facilitate the use of flexible subframes as flexible downlink subframes. According to a particular embodiment, the HARQ feedback timings as standardized for the static TDD configurations (see
(104) A HARQ feedback timing for all the flexible TDD configurations is associated with the HARQ feedback timings of the static TDD configurations according to the following table.
(105) TABLE-US-00005 TABLE HARQ feedback timing for flexible TDD ACK/NACK Timing applied to ACK/NACK Timing defined Flexible Uplink-downlink for non-Flexible Uplink- configuration Fm downlink configuration p F0 1 F1 2 F2 5 F3 4 F4 5 F5 5 F6 2
(106) In other words, instead of defining complete new HARQ feedback timings for the flexible TDD configurations, it is advantageous to merely associate each of the flexible TDD configuration with one appropriate HARQ feedback timing of the static TDD configuration, so as to achieve the result that the HARQ feedback is not timed for flexible subframes. This avoids a separate ACK/NACK timing configuration message, thereby avoiding an increase of control signaling overhead.
(107)
(108) This however leads to a further problem that may be mitigated by the following embodiment. As can be seen from
(109) However, in case the flexible subframe is determined to be an uplink subframe, there is no downlink transmission occurring in the flexible subframe. In any case, for a flexible uplink subframe, the usage of the HARQ uplink feedback is thus not meaningful. Still, according to usual HARQ feedback timing and usage, a HARQ feedback is also to be transmitted for a flexible uplink subframe; in this context, please refer to 3GPP TS 36.213 v11.1.0 “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures (Release 11)” Chapter 10.1.3.1 TDD HARQ-ACK procedure for one configured serving cell and the corresponding tables 10.1.3-2 to 10.1.3-7. This is especially true if the feedback for a flexible subframe is transmitted together with HARQ feedback for other subframes; for instance, the HARQ feedback for flexible subframes 13, 18, is transmitted together respectively with three other HARQ feedbacks.
(110) The preferred handling of such HARQ feedback for flexible uplink subframes is based on the consideration that error cases, or at least their effects, should be minimized. The most adverse effect would be that the UE treats a flexible subframe as a flexible uplink subframe, while the eNodeB uses it as a flexible downlink subframe for transmitting downlink data. The downlink transmission from the eNodeB is not successful, since the UE does not expect and thus does not properly receive the downlink transmission.
(111) According to one embodiment, the UE shall thus transmit a HARQ NACK as HARQ feedback for any flexible uplink subframe. This would give the eNodeB the information that the transmission was not successful and that it should be retransmitted.
(112) In some cases however, especially if HARQ feedback for several downlink transmission is conveyed in the same subframe, a single NACK feedback could require the UE to feedback NACK for all other downlink transmissions as well, in order to be on the conservative side such that rather excessive retransmissions are prompted instead of losing a required re-transmission.
(113) Therefore, according to a further embodiment, the UE shall provide a HARQ DTX as HARQ feedback for any flexible uplink subframe. HARQ DTX is used already in LTE Release 11, e.g. for a case when there is a downlink subframe without a detected DCI (in other words, where no downlink resource assignment was detected). The HARQ DTX handling can therefore be beneficially employed for the uplink feedback for a dynamic uplink subframe as meaning that the downlink resource assignment was not detected, with the background reason that it was not possible to detect any downlink signals because the UE was transmitting uplink at the time.
(114) In a similar way, the handling of uplink ACK/NACK feedback for dynamic downlink subframes, where no downlink resource assignments were detected should preferably be treated as DTX, or if that it is not available, as NACK.
(115) Another type of uplink transmission that may be potentially pending for flexible subframes is a so-called “non-adaptive retransmission”. As explained in the Background Section, the non-adaptive retransmission is employed as of LTE Release 11 (and earlier) for uplink HARQ. For any uplink transmission in a subframe n, the UE expects a downlink ACK/NACK feedback (using a Hybrid ARQ Indication, HI, usually conveyed by PHICH) on a given resource in a subframe n+k (where k is given by the standard and is specific for each TDD configuration). This will be exemplified in the following.
(116) The flexible TDD configuration F1 is assumed for the following explanation. A DCI is transmitted in subframe 4 to schedule a PUSCH transmission in subframe 8 (see
(117) Now, since we assume that subframes 3, 8, 13, 18, 23, etc. . . . are flexible subframes, the situation in this example would be as follows: Flexible subframe 8 of flexible TDD configuration F1 is a flexible uplink subframe (due to the DCI in subframe 4, triggering the uplink transmission in subframe 8), and flexible subframe 18 is a dynamic uplink subframe (due to PHICH=NACK received in subframe 14, triggering the non-adaptive retransmission in subframe 18).
(118) Furthermore, if the PHICH with the HARQ downlink feedback in subframe 14 is transmitted as ACK, it could mean two things: Firstly, it can mean that the eNodeB might have liked to use flexible subframe 18 as a dynamic downlink subframe to transmit downlink data (to that UE or to others), and will therefore not be able to receive and process the non-adaptive retransmissions that the UE transmits in subframe 18. Secondly, it can mean that the eNodeB operates subframe 18 as a dynamic uplink subframe but does not want the UE to transmit the non-adaptive retransmission—rather the resources should be used by other UEs. Then, in case such a HARQ downlink feedback is received erroneously, i.e. as NACK instead of ACK, the non-adaptive retransmissions would create undesired interference.
(119) To avoid the above-described blocking of the flexible subframes by the non-adaptive retransmission, according to a further embodiment of the invention, the UE shall never transmit non-adaptive retransmissions in flexible subframes. This may be achieved differently, by either ignoring the corresponding HARQ downlink feedback, that would potentially trigger a non-adaptive retransmission in a flexible subframe, or alternatively, by treating all HARQ feedback over PHICH, that would potentially trigger a non-adaptive retransmission in a flexible subframe as HARQ ACK (PHICH=ACK). Both of these ways will allow the UE to leave the flexible subframe free from non-adaptive retransmissions and will allow eNodeB to control the flexible subframe, i.e. whether it is a dynamic downlink or uplink subframe by means of transmitting or not transmitting an uplink resource assignment for a flexible subframe to the UE. The retransmission of the previous transmission can be done using a new DCI in said respect.
(120) Another complication with respect to uplink PUSCH data transmissions and PHICH downlink feedback concerns the feedback for data that is transmitted in a flexible uplink subframe.
(121) In some TDD configurations, the PHICH transmitting NACK for a flexible uplink subframe transmission would trigger a non-adaptive retransmission in a flexible subframe (as in the example above), and the PHICH transmitting NACK for a non-flexible uplink subframe transmission would trigger a non-adaptive retransmission in a subsequent non-flexible subframe.
(122) In some TDD configurations however, the PHICH transmitting NACK for a flexible uplink subframe transmission would trigger a non-adaptive retransmission in a non-flexible subframe, and the PHICH transmitting NACK for a non-flexible uplink subframe transmission would trigger a non-adaptive retransmission in a flexible subframe.
(123) For those configurations, it is preferable that neither a PHICH can trigger a non-adaptive retransmission in a flexible subframe, nor that the PHICH that is transmitted for a transmissions in a flexible uplink subframe can trigger a retransmission in a subsequent non-flexible subframe. Therefore, in a preferred embodiment the UE will handle downlink ACK/NACK as follows: All ACK/NACK feedback that is expected by the UE as feedback for an earlier uplink data transmission in a flexible subframe is ignored or treated as ACK All ACK/NACK feedback that is expected by the UE and that would trigger an uplink data transmission in a future flexible subframe is ignored or treated as ACK (see above) For a non-flexible uplink subframe n of a flexible TDD configuration Fm, the timing between the uplink data transmission and the corresponding downlink HARQ feedback is the same as in static TDD configuration m for that uplink subframe n For the timing between a downlink HARQ feedback and a corresponding uplink transmission in a non-flexible uplink subframe n, flexible TDD configuration Fm uses the same timing as static TDD configuration m for that uplink subframe n
(124) The effect can be visualized as in
(125) Other types of uplink transmissions that should be avoided for flexible subframes have been already mentioned in connection with the second embodiment and are the following: the data uplink transmissions that are scheduled by SPS. Scheduling requests Periodic CSI report Uplink sounding Random access messages
(126) To maintain the flexible subframe as free as possible from these uplink transmissions, they should be suppressed. In other words, in case one of the above uplink transmissions would fall on a flexible subframe, the UE should not perform these uplink transmissions.
(127) Alternatively, according to a further embodiment, any configuration defined for the above-mentioned uplink transmissions, where at least one transmission instance would coincide with a flexible subframe, would be treated by the UE as invalid, and would then be discarded. Correspondingly, no such uplink transmission would happen anymore. However, the eNodeB should provide a new configuration for the discarded configuration, this new configuration considering the flexible subframes such that any of the uplink transmissions would not be performed at a flexible subframe.
(128) In another alternative and beneficial embodiment, any uplink SPS configuration is automatically released by the UE, if the (flexible or static) TDD configuration changes to a flexible TDD configuration where an uplink SPS transmission would coincide with a flexible subframe. Again, the eNodeB should in this case provide a new configuration of uplink SPS, so that the UE can continue using an SPS uplink resource.
(129) In a further embodiment, the usage of a flexible TDD configuration, or equivalently the presence of at least one flexible subframe per radio frame affects the maximum number of downlink HARQ processes. Especially in the case where a flexible TDD configuration Fm contains more downlink+flexible subframes than static TDD configuration m, the UE may be required to adapt its limited memory buffer to more downlink HARQ processes. For static TDD configurations m, 3GPP TS 36.213 v11.2.0 Table 7-1 defines the maximum number of HARQ processes for downlink. In a first preferred embodiment, to determine the maximum number of DL HARQ processes when operating a flexible TDD configuration Fm the number given in Table 7-1 for a static TDD configuration m is increased by one for each flexible subframe defined in flexible TDD configuration Fm. For example, Table 7-1 specifies a maximum of 4 HARQ processes for TDD UL/DL configuration 0. Flexible TDD configuration F0 according to
(130) TABLE-US-00006 TABLE Maximum number of DL HARQ processes for flexible TDD, offset-based Flexible Uplink-downlink Maximum number of configuration Fm HARQ processes F0 6 F1 9 F2 11 F3 10 F4 13 F5 15 F6 8
(131) In another variant, a comparison is made between the case where as many of subframes as possible are used for downlink in a flexible TDD UL/DL configuration, and comparing these to an equivalent case of a static TDD configuration. Exemplarily, the flexible configurations in
(132) TABLE-US-00007 TABLE Maximum number of DL HARQ processes for flexible TDD, equivalence-based Maximum downlink- Maximum Flexible Uplink-downlink equivalent static uplink- number of configuration Fm downlink configuration HARQ processes F0 1 7 F1 2 10 F2 5 15 F3 4 12 F4 5 15 F5 5 15 F6 3 9
(133) Hardware and Software Implementation of the Invention
(134) Another embodiment of the invention relates to the implementation of the above described various embodiments using hardware and software. In this connection the invention provides a user equipment (mobile terminal) and a eNodeB (base station). The user equipment is adapted to perform the methods described herein.
(135) It is further recognized that the various embodiments of the invention may be implemented or performed using computing devices (processors). A computing device or processor may for example be general purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, etc. The various embodiments of the invention may also be performed or embodied by a combination of these devices.
(136) Further, the various embodiments of the invention may also be implemented by means of software modules, which are executed by a processor or directly in hardware. Also a combination of software modules and a hardware implementation may be possible. The software modules may be stored on any kind of computer readable storage media, for example RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD, etc.
(137) It should be further noted that the individual features of the different embodiments of the invention may individually or in arbitrary combination be subject matter to another invention.
(138) It would be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.