WO2008135238A1 - Robust acknowledgement handling - Google Patents

Abstract

The present invention relates to methods, data transmission and reception apparatuses, a system, and computer program products for handling a retransmission procedure, wherein an acknowledgement is transmitted from a data reception end (10) to a data transmission end (20), and a request for confirmation of the acknowledgement is transmitted to the data reception end (10) in response to a determination of an insufficient reliability of the acknowledgement. The request is detected at the data reception end (10) and a confirmation of the acknowledgement is transmitted to the data transmission end (20) in response to the detection result.

Description

Robust Acknowledgement Handling

FIELD OF THE INVENTION

The present invention relates to methods, data transmission and reception apparatuses, a system, and computer program products for handling acknowledgements in retransmission procedures, such as automatic repeat request (ARQ) or hybrid automatic repeat request (HARQ) procedures.

BACKGROUND OF THE INVENTION

Retransmission procedures can be used for error correction purposes, wherein a receiving side or end can request retransmissions of incorrectly received data packets. In such an acknowledged mode, a positive acknowledgement (ACK) is returned if no retransmission is required (i.e. data packet has been received cor- rectly), while a negative acknowledgment (NACK) is returned if a retransmission is required (i.e. data packet has not been received correctly).

In 3^rd generation mobile communication systems, acknowledgements (ACK/NACK) and uplink (UL) data (transmitted from terminal devices to the network side) are multiplexed when both UL data and data-non-associated control signals are present. This transmission can be done on a Physical Uplink Shared channel (PUSCH), the channel is shared among terminal devices or user equipments (UEs) because only one UE will be granted to use a specific set of resources on this channel. Otherwise acknowledgements may be sent alone on PUCCH (Physi- cal Uplink Control Channel). In these cases, as acknowledgements may only consist of a single bit (or a few in case of multi-stream transmission), no advanced coding is possible, so that it is difficult or requires a comparatively high signal-to- noise ratio, e.g., bit energy to noise ratio (Eb/No), to transmit the acknowledgements in a reliable manner. Also, multiplexing does not help because the acknowl- edgement is also encoded/protected separately using repetition type methods. Hence, the reliability issues apply equally well to both situations. Encoding with other control signals (e.g. channel quality indicator (CQI)) is possible to gain larger block size but since block error requirements are generally not the same, this is not a promising solution. However, erroneous detection of acknowledgements may lead to the following problems. A positive acknowledgement (ACK) might have been sent but misinterpreted as a negative acknowledgement (NACK). In this case the transmitting end (e.g. base station or NodeB in a cellular system) will unnecessarily retransmit the packet, instead of sending a new packet. This leads to some waste of capacity. The accepted error rate for this error may be agreed to some 1%-5%, causing a loss of throughput in a similar range.

A negative to positive acknowledgement error (NACK to ACK) where a negative acknowledgement (NACK) might have been sent but misinterpreted as a positive acknowledgement (ACK) leads to an undesirable error situation from downlink (DL) point of view, as a transmission is erroneously assumed to be correct, therefore the transmitter will no more retransmit the transmission and the data will not reach the receiver, so that higher layers will now have to detect this and provide means to recover. This in turn leads to much slower recovery and much more delay than physical layer (L1) recovery, because higher layers (e.g. Radio Link Control (RLC) or Transmit Control Protocol (TCP)) will have to retransmit a much larger packet than the lost packet. Such error cases should only happen with an ex- tremely low probability, much lower than the above mentioned 1%-5%. Typically, such errors should only occur with a probability of 0.1% or lower.

Even when assuming an RLC retransmission layer, it appears attractive from a link efficiency viewpoint to be able to reduce the negative to positive acknowledgement error at the physical layer to 0.1% (or even 0.01%) to avoid excessive retransmissions. Mechanisms for controlling the negative to positive acknowledgement error should be flexible in a way that their aggressiveness or efficiency should be adjustable, e.g., for some services a much higher negative to positive acknowledgement error ratio could be tolerated (e.g. Uniform Datagram Protocol (UDP) based streaming or Voice over Internet Protocol (VoIP)).

If positive or negative acknowledgements are sent together with data, an additional problem might arise. In open loop power control schemes where the transmission power of the terminal device is controlled by absolute DL control signaling, the base station or access device (e.g. NodeB) may not always be fully aware of the power the terminal device (e.g. user equipment (UE)) uses, and consequently cannot know the terminal power range or capability as well. The same effect also applies to closed loop power control using relative control signaling (e.g. up/down commands), in case there are errors in the power control signaling, or if there is some signaling from neighbor cells as well (e.g. relative grant in High Speed Uplink Packet Access (HSUPA) systems).

The base station or access device may therefore allocate an UL data packet that would make the terminal exceed its power capability. The terminal device then has to scale down the power of the entire transmission, also compromising the acknowledgement power. While the data can be easily recovered via HARQ or ARQ, an insufficient power for the acknowledgement signaling may compromise ac- knowledgements and consequently DL data performance.

A receiving end (e.g. terminal device) may detect eventually that a packet was missed, e.g., by detecting that a sequence number is missing. There have been proposals to allow the receiving end to signal this fact back to the transmitting end (e.g. base station (NodeB) or access device) via fast physical layer (L1) signalling to allow a faster and more efficient recovery than via higher protocol layers. However, this would require the introduction of a specific signalling scheme for such cases. The receiving end would have to be able to signal this case in an unsolicited way. Such a signalling is difficult to implement in particular in UL direction of cellular networks. Further, the transmitting end would have to store all transmitted data for some time to be able to retransmit them in case of such a request, most often wasting fast hardware resources.

As another option, acknowledgements could be sent with a comfortable power margin, at the expense of a correspondingly reduced system capacity. With abovementioned sources of uncertainty, such margins may become very significant when targeting small error levels and may lead to transmission power problems for the terminal device when the acknowledgement needs to be sent within a single transmission time interval. Some optimizations can be done by shifting the decision threshold towards the negative acknowledgement, which will decrease the negative to positive acknowledgement error probability at the expense of a higher positive to negative acknowledgement probability.

If acknowledgments are multiplexed with data, only a conservative data allocation may be possible to use, which again leads to a reduced signalling capacity.

As a further option, it is possible to repeat every acknowledgement also in the next transmission time interval TTI, at the expense to transmit uselessly more power in - A -

case the first acknowledgement was already received with sufficient confidence. In this way some more diversity in time is achieved, and it may be possible to transmit the acknowledgement with more energy, because the transmission is spread over more time, so if constant power is available more energy can be used. This may not be the case if together with the repeated acknowledgement a new acknowledgement is to be sent as well. But this case can be avoided if data packets are not sent in consecutive TTIs but at most on the next but one TTI, at the expense of achievable maximum throughput.

However in an interference limited case, while this repetition of acknowledgements will increase the received energy at the intended base station, it will also increase the interference experienced at other base stations in the same way. Therefore in interference limited cases, where communication at one base station is more severely impacted by transmissions intended for other base stations rather than thermal noise, such a repetition will both increase the signal and the interference and therefore not significantly increase the signal to interference and noise ratio (SINR) and consequently not significantly increase the reception quality and reliability of the acknowledgement.

Such an interference limited scenario can easily happen for transmission on PUCCH due to the fact multiple UEs (having no data to be transmitted) share a common time and frequency resource reserved for control signaling. Therefore, if there is a high load on PUCCH because a high number of UEs needs to transmit acknowledgements (possibly also other information) then there may be a high in- terference experienced on those PUCCH resource blocks, while the interference may be lower on other resources (such as PUSCH), because there are less concurrent users transmitting data. This may often happen if traffic is asymmetric i.e. more traffic in DL compared to UL.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide improved retransmission handling, by means of which acknowledgement error ratios can be reduced.

This object is achieved by a method of controlling a retransmission procedure at a data transmission end, said method comprising: • checking a reliability of an acknowledgement received from a data reception end; and

• signaling a request for confirmation of said received acknowledgement to said data reception end, in response to a determination of an insufficient re- liability as a result of said checking.

Additionally, the above object is achieved by a method of controlling a retransmission procedure at a data reception end, said method comprising:

• transmitting an acknowledgement to a data transmission end;

• detecting a request for confirmation of said acknowledgement; and

• transmitting a confirmation of said acknowledgement in response to the detection result.

Moreover, the above object is achieved by a data transmitting apparatus for controlling a retransmission procedure, said apparatus comprising:

• checking means for checking a reliability of an acknowledgement received from a receiving end; and

• signaling means for signaling a request for confirmation of said received acknowledgement to said receiving end, in response to a determination of an insufficient reliability as a result of said checking by said checking means.

Furthermore, the above object is achieved by a data receiving apparatus for controlling a retransmission procedure, said apparatus comprising:

• transmitting means for transmitting an acknowledgement to a data transmission end;

• detecting means for detecting a request for confirmation of said acknowl- edgement; and • confirmation control means for initiating transmission of a confirmation of said acknowledgement in response to said detection means.

Accordingly, robustness to the retransmission procedure can be increased by an additional confirmation acknowledgement in case an acknowledgement transmis- sion fails. Thereby, retransmission procedures, such as ARQ or HARQ can be made more reliable and/or the margin to be used for the acknowledgement signalling can be reduced. This, in turn, enables less tight power control, i.e., saves signalling for power control as the associated increase in acknowledgement errors can be cured.

Additionally, less frequent power capability reporting (or any equivalent signaling) is required and more ambitious sizes for data packets can be used, rather than conservative sizes, which will increase capacity.

There is very little additional overhead for signaling the request for the proposed additional confirmation acknowledgement, as existing signaling concepts can be used. By alleviating higher layer retransmissions, there is an anticipated gain of the method in overall spectral efficiency.

In a specific example, the retransmission procedure may be a hybrid automatic repeat request procedure.

The confirmation can be enabled or disabled via a signaling of a protocol layer higher than the protocol layer of the retransmission procedure. In a particular example, the confirmation can be enabled or disabled by a base station or access device of a wireless network. This could be achieved, for example, by setting or resetting a flag of the higher protocol layer. The higher protocol layer may be a radio resource control protocol layer, for example.

Furthermore, the request for the confirmation may be signaled by a predetermined setting of a resource allocation table. As an example, the predetermined setting may be an empty allocation e.g. with all bits indicating resource allocation set to zero. The "empty" allocation can be either in the uplink or the downlink which in the former case leads to "scheduled confirmation" whereas for the latter case a place for the confirmation is automatically reserved also on the dedicated control channel for the acknowledgement signal in a similar way as for normal downlink allocations. As an alternative, the request for the confirmation may be signaled by a predetermined setting of a transport format. As a further alternative, the request for the confirmation may be signaled by a predetermined combination of a transport format and a number of resources.

As regards transmission timing, the request for the confirmation may be signaled during a predetermined time window. It may further be signaled while taking into account a discontinuous transmission or reception cycle. The data reception end may be controlled to stay awake from a discontinuous transmission or reception mode after it has sent a negative acknowledgement.

The confirmation may then be transmitted synchronously during a specific transmit timing interval. As an alternative, the confirmation may be transmitted asynchro- nously based on a signaled retransmission process number. A resource to be used for transmitting the confirmation may further be assigned to the data reception end. As alternative, a timing relation of the confirmation may be signaled to the data reception end together with the request for the confirmation.

At the data reception end, data indicating the last type of acknowledgement may be stored.

It may also be signaled to the UE not to transmit the acknowledgement on a stand alone resource e.g. PUCCH, but to provide a dedicated resource e.g. PUSCH to carry the acknowledgement, even if no data are scheduled to be transmitted on that PUSCH. In this case the entire space on the PUSCH may be used for transmitting the acknowledgement. Alternatively a part of the PUSCH may be used to transmit the acknowledgement and some other part may be used for other information e.g. CQI (Channel quality information).

Further advantageous modifications are defined in dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described based on embodiments with reference to the accompanying drawings in which:

Fig. 1 shows a schematic diagram indicating a network architecture in which the present invention can be implemented; Fig. 2 shows a schematic signaling diagram of a robust retransmission signaling according to embodiments of the present invention;

Fig. 3 shows schematic block diagrams of transmission and reception apparatuses according to embodiments of the present invention;

Fig. 4 shows schematic block diagrams of a software-based implementation according to an embodiment of the present invention; and

Fig. 5 shows a schematic timing diagram of a robust retransmission signaling according to an embodiment of the present invention.

DESCRIPTION OF THE EMBODIMENT

In the following, embodiments of the present invention will be described based on an exemplary HARQ retransmission procedure of a cellular network environment. It is however noted that the present invention is not intended to be restricted to cellular or wireless networks. Rather, it can be used in any retransmission procedure for any type of network or connection.

Fig. 1 shows a schematic diagram of a general network architecture in which the present invention can be implemented. A radio access network 300, e.g., Univer- sal Mobile Telecommunications System (UMTS) Terrestrial Access Network (UTRAN) according to the Long Term Evolution (LTE) or 3^rd Generation Partnership Project (3GPP) Release 8 standard, provides access to a UE 10 via an access device 20, e.g., a base station device (eNodeB), which exchange retransmission signaling 400 to provide an error correction.

According to the preferred embodiments, a specific retransmission mode can be selected by the access device 20. It can be enabled or disabled via a higher layer signalling, e.g., RRC signalling or be predefined in the specifications for certain service types. It could also be available continuously, but the access device 20 can decide whether to apply it for a given connection or service.

Fig. 2 shows a schematic signalling diagram of the proposed "confirmation ACK" mode according to the embodiments, wherein an NodeB (eNB) 20, as an example of the above access device, transmit a data packet to a UE 10 (step 1). In response thereto, the NodeB 20 receives an acknowledgement (ACK or NACK) from the UE 10 (step 2) and checks the received acknowledgement from the UE 10 to assess whether it is reliable or not (step 3). If there is some (non negligible, e.g., more than 0.01%) possibility that the received acknowledgement was erroneous (e.g. the UE 10 actually has sent a negative acknowledgement (NACK) instead of a received positive acknowledgement (ACK)), the NodeB 20 conditionally requests the UE 10 to confirm the acknowledgement, e.g., send an acknowledgement (e.g. ACK/NACK) again (step 4). The reliability threshold can be chosen by the NodeB 20 to improve the spectral efficiency of the link or other parameters like delay statistics. Finally, if the request for confirmation has been sent and received by the UE 10, it responds with a confirmation, e.g., a confirmation ACK or NACK (step 5).

It is to be noted here that the term "confirmation" is to be understood and used in a sense that it covers any kind of confirmation suitable to provide the requesting side with information about the content of an earlier acknowledgement to be confirmed. It may simply be a retransmission of the earlier confirmation or acknowledgement. However, it might as well correspond to a predetermined signalling or parameter type or content which indicates the content of the earlier acknowledgement.

To avoid issues related to multiplexing in uplink, a specific signalling and acknowledgement transmission scheme could be implemented, such that the NodeB 20 can request the additional confirmation by sending an "empty" allocation for the acknowledgement in the DL direction in step 4, e.g., by using an allocation table for allocating resources and/or other transmission parameters. Thereby, existing signalling schemes can be reused or recycled and no additional overhead or significant standardization work is needed.

As it is thus not required that the UE 10 does any decoding to determine the ac- knowledgement (it may for example have stored it from the last decoding), it can send the confirmation straight away, causing less delay for the additional confirmation.

The implementation may relate to several layers of the invention. First, it could be possible to disable the proposed confirmation mode (e.g. in which the UE 10 listens for a request for confirmation from the NodeB 20 and in which the NodeB 20 provides a possibility to utilize this feature). As example, the mode could be changed semi-statically during the call using higher layer signalling. E.g., a flag available in RRC signalling could be used to enable or disable the confirmation mode. It is advantageous that the mode can be disabled, since the UE 10 then does not have to listen to the allocation table for any confirmation request (e.g. if it is set in a discontinuous transmission (DTX) mode).

More specifically, to provide the proposed confirmation mode, the UE 10 could be informed about whether a confirmation is needed, which specific acknowledgement needs to be confirmed, how (or where) to transmit the confirmation, and whether (and when) to avoid DRX to be able to listen to a potential request for confirmation.

In the following, multiple implementation possibilities are discussed based on different embodiments and with reference to Fig. 3 which shows schematic block diagrams of transmission and reception apparatuses, such as the nodeB 20 and UE 10 of Fig. 2, respectively.

According to Fig. 3, the NodeB 20 comprises a transceiver (TRX) unit 200 for enabling transmission and reception of suitably modulated RF signals via an air interface to the UE 10. A retransmission control unit (HARQ unit) 210 controls HARQ procedures by using a corresponding physical layer signaling. Based on a quality related information (e.g. signal-to-noise ratio or the like) received from the HARQ unit 210, a checking unit 220 checks the reliability of a received acknowledgement from the UE 10 and compares the checking result with a predefined reliability threshold. If the threshold is not exceeded, i.e. if the reliability is too low, a corre- sponding control signal is supplied to a confirmation request unit 230 which generates or initiates generation of a request for confirmation or a signaling to be interpreted at the UE 10 as such a request, as explained later in more detail. This request is then transmitted via the TRX 200 towards the UE 10.

The UE 10 also comprises a transceiver (TRX) unit 100 for enabling transmission and reception of suitably modulated RF signals via an air interface towards the cellular network, e.g., to the NodeB 20. A retransmission control unit (HARQ unit) 120 controls HARQ procedures by using a corresponding physical layer signaling e.g. to return positive or negative acknowledgements to the NodeB 20. A data processing unit 110 checks received data packet e.g. based on an error correction coding or the like and controls the HARQ unit 120 to issue a positive or negative acknowledgement in response to the checking result. Additionally, the data processing unit 110 detects requests for confirmation of preceding acknowledgements received via the TRX unit 100 and supplies a trigger or control information to a confirmation unit 130 which in turn controls the HARQ unit 120 to transmit an additional confirmation acknowledgement or other kind of confirmation, as explained later in more detail.

The request for confirmation can be signaled by the confirmation request unit 230 in various ways.

In a first embodiment, the number of allocated resources of the shared channel for transmission in DL could be signaled via a so-called DL allocation table. This table may be implemented in the form of a bitmap, where each bit indicates whether a given resource block is allocated to the UE 10 or not. Setting all bits to zero is a useless allocation, which thus can be used by the confirmation request unit 230 to signal the above request for confirmation. In principle, an empty UL or an empty DL allocation table for indicating the requested confirmation of a non-reliable preceding acknowledgement (or flexibly, the Node B 20 could change between the UL and DL allocation table depending on whether there is UL or DL data pending for a user or whether there are free entries in the UL or DL allocation table). E.g., the UE 10 could read the allocation table as normal and then it would find out that ei- ther the indicated DL allocation entry or UL allocation entry is "empty", in which case it can decide that a confirmation of an acknowledgement needs be sent.

In a specific example, the UL allocation table entry may contain less bits, so that less overhead will be generated, compared to a DL allocation table entry. Further more, if both can be used then there is a higher likelihood that there is a free space for at least UL or DL allocation table entry, even if the system is heavily loaded.

In a second embodiment, additional information may be provided by the confirma- tion request unit 230 on top of the allocation table to be signaled to the UE 10. This additional information could be a transport format that usually indicates how big the payload for the UE 10 is. Among the available transport formats, a specific one may be reserved to indicate to the UE 10 that no data is transmitted, but instead only a request to confirm (retransmit) a preceding acknowledgement.

It is apparent to the skilled person, that other types of signaling information could be "abused" or reserved for signaling the request for confirmation. Further, in a third embodiment, the confirmation request unit 230 may be adapted to use a specific (e.g. non-used or seldom used) combination of the allocation table and the transport format. For example, the unusual combination of the smallest transport format with the largest allocation table (i.e. the allocation table indicating the largest number of resources) can be used for signaling the request for confirmation. This combination, while strictly speaking not impossible, could thus be "sacrificed" for the proposed new signaling without detrimental effect on the system. As there is little use to transmit a minimum or very small amount of data with a maximum or very large amount of resources, setting such a combination aside for requesting a confirmation does not compromise scheduling flexibility. Similarly also the also rather unusual combination of the largest transport format with the smallest allocation table can also be used for signaling the request for confirmation.

Furthermore, also a resource that is known to be unavailable can be used to indicate the request for confirmation. For example, some resource may be set aside for specific purposes. This may include broadcasting information (Multicast Broadcast Multimedia Service (MBMS)), pooling resources for allocations that use hopping over these resources, or resources that have already been assigned to other transmissions at the same time, e.g., by another allocation signaling that is sent at the same time.

Optionally, to compress the signaling of the request for confirmation further, and if it is possible to use variable sizes in the DL allocation signaling, then a smaller size could be used by the confirmation request unit 230 to indicate the request for confirmation (this does however not seem viable in current assumed approach where only limited catO information is used to identify the allocation table structure and/ or the size of the allocation signaling).

In principle, any unused parts of the allocation table information (e.g. transport block set (TBS), modulation, multiple input multiple output (MIMO) mode, HARQ information besides from the radio bearer (RB) allocation mask) could be used to specifically indicate which acknowledgement needs to be confirmed.

In a fourth embodiment, it is proposed that a timing is defined so that the confirmation request has to take place at a specific transmission time interval (TTI) taking into account the needed processing requirements at both UE 10 and NodeB 20. Thereby, also the request for confirmation of an acknowledgement is synchronous with the corresponding (re)transmission of the data packet. A reason for this approach may be that since the request for confirmation may be sent quite seldom, it is better that the UE 10 knows when it arrives and that it knows which specific transmission it belongs to. Such a synchronous request for a confirmation is ad- vantageous if also data retransmissions are handled synchronously, i.e. are sent at a fixed timing interval relative to the negative acknowledgement (NACK).

In a fifth embodiment, the UE 10 may associate the request for confirmation with a data packet that was last sent with the same HARQ process number. Such an asynchronous request for a confirmation is particularly applicable, if also data retransmissions are handled asynchronously, i.e. are not necessarily sent at a fixed timing interval relative to the negative acknowledgement (NACK) but at the discretion of the NodeB 20. This leaves the NodeB 20 more freedom how to prioritize and optimize transmissions to different UEs or for different services.

If the UE 10 is in a DRX/DTX mode, sleep patterns could be optimized rather than waiting for a request for confirmation that might not come.

In a sixth embodiment, a timer solution could be implemented where the NodeB 20 has a time window allocated to signal the request for confirmation. Dedicated signaling may then be used to identify which acknowledgement needs be confirmed. As explained already in connection with the fifth embodiment, this can be done by the HARQ process number. This provides the advantage that the NodeB 20 can better utilize its uplink resources for the acknowledgement.

In conventional retransmission procedures, if the UE 10 transmits a negative acknowledgement (NACK) and the NodeB 20 does a retransmission, the UE 10 is aware of this pending retransmission and can autonomously delay DTX/DRX. In the present embodiments, however, the UE 10 cannot be aware that the NodeB 20 is unsure about the actually transmitted acknowledgement. In order to be sure not to miss the request for confirmation, the UE 10 may delay its DRX mode. As another option, according to the seventh embodiment, if the NodeB 20 and the UE 10 have a common understanding of their DRX/DTX cycles, then the request for the confirmation might be sent by the confirmation request unit 230 taking into ac- count this DRX/DTX cycle, i.e. delayed by such an amount of time, that the UE 10 is again known to listen to NodeB 20 commands (of course at the expense of additional delay). In an eighth embodiment which enables to make full use of the DTX/DRX saving potential or acknowledgement performance, the NodeB 20 can configure the UE 10 to allow entering the DRX mode immediately after reception of a data packet, or to wait a specified time for a potential request for confirmation and only then go into the DRX mode, thus being able to trade in acknowledgement performance versus power saving. The waiting time can be made the typical HARQ cycle time, i.e. the UE 10 waits until the earliest time when the NodeB 20 can transmit the request for confirmation, then the NodeB 20 has one opportunity to send this request. Alternatively, slightly longer times can also be used.

According to a ninth embodiment, the UE 10 might be allowed to enter the DRX/DTX mode immediately after sending a positive acknowledgement, but keep it awake after sending a negative acknowledgement. This behavior serves to make the transmission of the negative acknowledgement most effective. There may however be an error case, if the HARQ unit 120 of the UE 10 has transmitted a positive acknowledgement and consequently enters the DRX/DTX mode, but the checking unit 220 of the NodeB 20 detects a non-reliable acknowledgement and the confirmation request unit 230 responsively requests a confirmation. Apparently, this request will be lost and no confirmation will be sent. The NodeB 20 will then receive a DTX instead of the expected confirmation. This error case can be eased if the NodeB 20 tries to detect whether a NACK or a DTX was sent. Even if the NodeB 20 makes a wrong assumption here, i.e. assumes a NACK, the consequence is "only" a waste of some DL capacity (because the NodeB 20 will retransmit the packet unnecessarily), but not a loss of date and thus a less critical error case. Typically the operating point of a HARQ protocol is set so that there is a higher probability of successful transmission than non-successful transmission. Therefore, typically the probability of sending a NACK is only some 10% to 30% of transmitting an ACK. So if the terminal can enter DRX/DTX mode immediately after sending a positive acknowledgement, then it will only seldom not be able to enter DRX/DTX mode due to the invention, i.e., the loss in terms of battery stand by time is insignificant.

In the following, the question when the confirmation unit 130 of the UE 10 triggers transmission of the confirmation will be addressed. If using the empty downlink allocation approach, it would be logical to let the UE 10 follow the normal acknowledgement structure and then let the accompanying acknowledgement be the confirmation. Hence, physical resources (e.g. constant amplitude zero auto-correlation (CAZAC) codes if sent on the physical uplink control channel (PUCCH)) are al- ready identified and allocated to the UE 10 in the UL for the confirmation request. If using an UL allocation to signal the request for confirmation, then the physical resources need to be specified (just using the last physical resources may not be valid since another user may now use this for acknowledgement transmission).

However, after receiving a request for confirmation, the UE 10 does not have to demodulate and decode the data packet, as would be the case for a normal data packet. E.g., it can store the last transmitted acknowledgement or it has data stored indicating that it was really a negative acknowledgement. Therefore the confirmation unit 130 of the UE 10 is able to transmit the confirmation much faster than normally possible taking into account the processing delay of the UE 10, e.g. 1-2 TTI earlier. This can be used, to reduce the delay that would otherwise be caused by the retransmission of the acknowledgement when using conventional allocation methods. In principle, the confirmation could be sent already in the fol- lowing uplink TTI (e.g. at same speed as UE 10 is able to schedule data in uplink after allocation).

According to a tenth embodiment, the resource used by the UE 10 to transmit the acknowledgement is implicitly provided by the DL allocation. This can be achieved by (implicitly) numbering the allocations and providing a predefined relation between the allocation number and the resource to be used for the acknowledgement. In this way a unique assignment of acknowledgement resources to UEs is assured. The NodeB 20 then knows which dedicated acknowledgement resources are already occupied for the TTI where the confirmation is requested.

In case of a signaling of the request for confirmation via an empty downlink allocation for the next uplink TTI, the NodeB 20 knows which CAZAC codes are used for the next uplink TTI and will give dedicated resources for the UEs confirmation. The UE 10 could for example even send two acknowledgements at the same time on the PUCCH. If the UE 10 is given an UL allocation, the acknowledgement may be sent with data. The NodeB 20 needs to ensure that the same UE does not have a pending normal acknowledgement at same time or it may be standardized that the UE 10 can send two acknowledgements (e.g. ACK and confirmation ACK) at same time.

In case of a signaling of the request for confirmation via an empty DL allocation for a future (normally associated ACK/NACK time) uplink TTI, the normal procedure could be applied, and as acknowledgement resources are tied to an earlier DL allocation, resources are easily allocated. The UE 10 will not have an additional acknowledgement to send at the same time, since there was no DL allocation. Hence, this approach works well regardless of whether the UE 10 has UL data allocated andthe confirmation time available (confirmation sent in confirmation ACK space).

In case of a signaling of the request for confirmation via an empty UL allocation for the next uplink TTI, the NodeB 20 knows which CAZAC codes are unused (and can even use those that were originally allocated to another user but which will not be used since that user now has data allocation in UL) and these are specified to the user. If a user has an acknowledgement to send from earlier downlink transmission, the HARQ unit 120 of the UE 10 can be allocated two CAZAC codes at the same time within the PUCCH (e.g. two acknowledgements are sent simultaneously). Otherwise, one acknowledgement may be set to override the other. The NodeB 20 knows the state of the UE 10 so that extra wasted signaling can be avoided (e.g. the NodeB 20 does not request confirmation if the UE 10 has a normal acknowledgement to transmit).

However, if there is already an acknowledgement pending in response to the transmission of the previous TTI, there are some special cases to consider. If the UE 10 cannot transmit two acknowledgements in the same TTI, then it is not possible to transmit the requested acknowledgement more early. In order to address this complication, an implicit rule could be implemented, so that the UE 10 sends the acknowledgement earlier, if possible. I.e., if there is not already a pending ac- knowledgement, it can send it early, and otherwise at the regular timing. This principle can easily be extended for the case that the UE 10 can send the requested acknowledgement even several TTIs earlier than usual. As the NodeB 20 may inform the UE 10 about the DL scheduled data, both NodeB 20 and UE 10 have common knowledge, when acknowledgements are already due and therefore can both determine the timing when the requested acknowledgement is due.

An eleventh embodiment relates to the case where a DL allocation is lost (i.e. not received) by the UE 10. Then the UE 10 will not be aware of the necessity to transmit an acknowledgement in response to the lost data packet and therefore may erroneously assume that it can send a requested confirmation at the time this expected acknowledgement corresponding to the lost data packet is due. This error case can be excluded if the timing relation of the requested confirmation is signalled by the confirmation request unit 230 explicitly with the request for confirma- tion. This can be done by including a single or multiple bits in the request. If a normal allocation message is "abused" then there will be bits without a meaning (e.g. redundancy version, MIMO, etc.) that can be used for this purpose.

It is possible to implement the invention as a NodeB 20 proprietary implementation in a backward compatible way without changes to the specifications. Then at least one resource has to be allocated to the UE 10, but no actual data have to be transmitted. An advantage is then that no transmission power has to be spent on it, i.e. the saved power can be use for other transmissions. For code division mul- tiple access (CDMA) systems, often there are more potential resources available than can be actually used due to power limitations anyhow. Then there is no real disadvantage of allocating a resource without power. As a further refinement of this embodiment, if multiple UEs are requested to confirm an acknowledgement and all can be assigned the same resource without power, then the number of un- used resources can be minimized.

Fig. 4 shows a schematic block diagram of an alternative software-based implementation of the proposed embodiments for achieving robust retransmission signaling. The required functionalities can be implemented in any receiver, transmitter or transceiver module 200 with a processing unit 210, which may be any processor or computer device with a control unit which performs control based on software routines of a control program stored in a memory 212. The control program may also be stored separately on a computer-readable medium. Program code instructions are fetched from the memory 212 and are loaded to the control unit of the processing unit 210 in order to perform the processing steps of the above functionalities of blocks 210 to 230 and 110 to 130 of Fig. 3, which may be implemented as the above mentioned software routines. The processing steps may be performed on the basis of input data Dl and may generate output data DO. At the data transmission side (e.g. NodeB 20) the input data Dl may correspond to the received acknowledgement and at the data reception side (e.g. UE 10) the input data Dl may correspond to the received information indicating the request for confirmation, while at the data transmission side (e.g. NodeB 20) the output data DO may correspond to the information indicating the request for confirmation and at the data reception side (e.g. UE 10) the output data DO may correspond to the confirmation.

Consequently, the above and later embodiments may be implemented as a computer program product comprising code means for generating each individual step of the confirmation based retransmission procedure when run on a computer device or data processor of the access device (e.g. NodeB 20) or terminal device (e.g. UE 10), respectively.

Fig. 5 shows a schematic timing diagram of the proposed "confirmation acknowledgement" mode according to the embodiments, wherein in DL, as an example, a data packet is transmitted at DL TTI number 1 to user 1. In response thereto, user 1 transmits an acknowledgement (ACK or NACK), after deciding of that data packet. The decoding time is represented by the block arrow. After decoding is finished, i.e. at the earliest in UL TTI number 3, the acknowledgement is sent in UL. This received acknowledgement from user 1 is assessed whether it is reliable or not at the time indicated above DL TTI number 5. If there is some (non negligible, e.g., more than 0.01 %) possibility that the received acknowledgement was erroneous (e.g. user 1 actually has sent a negative acknowledgement (NACK) in- stead of a received positive acknowledgement (ACK)), a conditional requests is sent to user 1 in DL TTI number 6 to user 1 to request user 1 to confirm the acknowledgement, e.g., send an acknowledgement (e.g. ACK/NACK) again. Finally, once the request for confirmation has been sent and received by the user 1 , it responds with a confirmation, e.g. a confirmation ACK or NACK. Because user 1 does not need to decode any data this time, the confirmation can already be sent in UL TTI number 7, i.e. one TTI earlier. Alternatively, the confirmation can also be sent in UL TTI number 8, i.e. with the same timing compared to the initial acknowledgement. Note that typically only one confirmation acknowledgement will be sent, for ease of comparison both cases are drawn in Fig. 5. Furthermore, together with the request for confirmation for user 1 data packets may be sent to other users or even to user 1 as well as indicated in DL TTI number 6.

According to another embodiment, acknowledgement transmission can be shifted from PUCCH to PUSCH. There are only at maximum two OFDMA symbols per slot available to carry acknowledgement information on PUSCH when acknowledgement is multiplexed with UL data. Having only comparatively little energy may limit the achievable range for acknowledgement. In the absence of UL data all the OFDMA symbols are available to carry acknowledgement information (including reference signals). However, PUCCH may be more interference limited compared to PUSCH and this may limit the achievable range for achknowledgements (ACK/NACK). In order to solve this problem we propose to transmit together with each data packet in DL that will give rise to transmit an acknowledgement in UL, also a grant for an UL transmission on PUSCH. Normally such a grant is only nee- essary if UL data packets need to be transmitted as well, or if a so called aperiodic CQI is requested by the base station. According to an embodiment of this invention we however propose to also grant an UL PUSCH transmission in case an acknowledgement is expected to be sent in UL. In this case no data packet needs to be sent on PUSCH but instead these resources can be used to transmit the acknowledgement. In this way more OFDM symbols are available to transmit the acknowledgement, consequently it can be sent with more energy, better SINR, less susceptibility to interference and higher reliability. Additionally, the grant for UL PUSCH can specify specific RB (Resource Blocks) and consequently specific subcarriers i.e. a specific frequency range to be used for the transmission. This can be selected to coincide with a frequency range where there is a good instantaneous channel available i.e. a constructive fade on the particular frequency range. Frequency range having favorable interference conditions can also be used as a criteria for specifying the ACK/NACK (acknowledgement) RB on PUSCH. In this way an even more efficient more reliable and less interference generating way to convey the acknowledgement is achieved.

The PUSCH signaling that should be used for the acknowledgement can be done similarly to the signaling in the embodiments presented above, just now for the grant of the UL transmission instead of the grant for the DL transmission. In particular a zero transport block size can be reserved to indicate acknowledgement transmission on PUSCH. If a retransmission of an acknowledgement is requested, it is possible to trigger this retransmission only with such a dummy UL grant. As no actual data are transmitted on UL several bits in the UL grant that otherwise spec- ify details of this data transmission are not needed and can be instead used to specify which particular acknowledgement should be repeated, e.g. by specifying the HARQ process ID or the timing when the acknowledgement that is to be repeated was transmitted last.

According to a further embodiment , signalling can be refined to request aperiodic CQI. In the current LTE standard it would be possible to request an aperiodic CQI to be sent in UL on PUSCH, either with or without data. In another embodiment this can be extended to transmit also an ACK on top of the CQI or without the ape- riodic CQI. The aperiodic CQI could be sent alone on PUSCH e.g. by signaling "zero" in the TBS (transport block size) table, i.e. a data packet of size "0". By including the value "0" into the TBS table it is possible to have the acknowledgement sent on PUSCH simply by sending a UL grant where the TBS is set to "0 and the aperiodic CQI request trigger/flag is set to "off¹, i.e., an "empty" PUSCH allocation.

According to a further embodiment, several acknowledgements can be combined for several HARQ processes. While on PUCCH there are only very few bits available, there is more space on PUSCH. This can be used to not only transmit a single acknowledgement, but even multiple acknowledgements for several HARQ processes. This is particularly attractive, because this allows to do some coding on the set of acknowledgements to get some coding gain. Some bits that are not used in an UL grant that is used to trigger acknowledgements can be used to indicate which acknowledgements to repeat. Furthermore, it is possible to use a single bit to indicate that all outstanding acknowledgements should be retransmitted. In this case, if there was no outstanding acknowledgement on some HARQ proc- esses, a predetermined value, e.g. an ACK, should be sent. By using suitable codes and making use of this pre-knowledge, it is possible to get almost the same performance as if only the outstanding acknowledgements were sent. Therefore, a risk that there may be misunderstanding whether or not an acknowledgement is included can be reduced.. This pre-knowledge can then be used in the receiver to increase the decoding performance of the code.

In a further embodiment it is possible to request the retransmission of an acknowledgement even before the previous acknowledgement was received. If channel or interference conditions are currently bad then the access device (e.g. based sta- tion or node B (NB)) will know that already in advance and can therefore request a retransmission of the acknowledgement even before receiving it. A special case of this approach is to request the retransmission of the acknowledgement already when sending the data to be acknowledged. This can be done by specifying a specific bit or information in either the UL or DL grant, similarly to the previous embodiments. The advantage over the prior art is that retransmission of acknowledgement can be activated very quickly, much quicker than would be possible with higher layer signalling.

Some of the embodiments are related to enhancing the coverage of UL acknowl- edgements sent by the UE on Physical Uplink Control Channel (PUCCH). The coverage of PUCCH is critical since it to large extent defines the overall system coverage. However, we do not preclude the usage of the points listed below for repetition of acknowledgement sent on PUCCH either. One aspects is the usage of the physical channels. In embodiments of the invention it is proposed that the confirmation request can be transmitted on Physical Downlink Control Channel (PDCCH), more specifically using the UL grant, and/or that the confirmation acknowledgement (e.g. step 5 of Fig. 2) can be sent on Physical Uplink Shared Channel (PUSCH).

In LTE the steps 4 and 5 of Fig. 2 can be realized in the following manner:

In the confirmation request the enhanced Node B (eNodeB) requests the UE to re- send the acknowledgement and potentially defines the resource for the acknowledgement transmission. There are several ways of realizing this:

A first option where the confirmation request is an UL grant.

A second option where the resource allocation field in the UL grant defines the UL resources on PUSCH to be used for the transmission of confirmation acknowledgement. The same mechanism as for regular data resource allocation can be used, this allows easy implementation by reusing existing signalling schemes and decision procedures and hardware.

A third option where the transmission of an UL grant is used to allocate PUSCH resources for acknowledgement transmission in the uplink ("acknowledgement only format").

A fourth option where the usage of "acknowledgement-only format" in PUSCH relates to multiple TTIs/subframes (i.e., acknowledgement repetition for the standalone acknowledgement transmitted on PUSCH is used). In a first example, certain DL scheduler restrictions can be taken into use in order to avoid transmission of multiple acknowledgement during a single UL subframe. In a second example, no DL scheduler restrictions are introduced and the UE is capable to transmit multiple acknowledgement (associated to different DL subframes) during the same subframe.

A fifth option where the signalling of acknowledgement on PUSCH is based on a pre-defined (QPSK) modulation. A sixth option where slot-based frequency hopping is used when signalling acknowledgement.

A seventh option where at least one of the following UL grant bits or states are used (stolen) to configure the "PUCCH acknowledgement-only" transmission:

An eighth option where the transmission of an UL grant where the MCS set to cor- respond to Transport Block Size (TBS) "0" triggers the UE to send the confirmation acknowledgement.

A ninth option where the CQI request flag is set "on" combined with some other predefined value of some bit field triggers the UE to send the confirmation ac- knowledgement

Furthermore, another application of the embodiments is to use the above defined mechanism to allocate resources for acknowledgement transmission on PUSCH without any relation to previous acknowledgement, i.e. to define a format and mechanism for sending acknowledgement on PUSCH without data:

As a further embodiment, the usage of "acknowledgement-only format" in PUSCH relates to a single UL TTI (subframe) (No acknowledgement repetition here)

It should be noted that the embodiments starting from the twelfth can be combined with the request to send a confirmation of the acknowledgement according to the first claim of this invention, but these embodiments can also be applied independently, i.e. they can both be used for a confirmation of an acknowledgement and also for the initial transmission of an acknowledgement. It will further be apparent that the embodiments descried above can be used for methods, data transmission and reception apparatuses, a system, and computer program products for handling a retransmission. The apparatuses can be base stations or terminals in a network. While the description of the embodiments has show the case that the acknowledgement is sent from the terminal to the base station, the procedures can also be reversed and applied for the case that the acknowledgement is sent from the base station to the terminal.

In summary, methods, data transmission and reception apparatuses, a system, and computer program products for handling a retransmission procedure have been described, wherein an acknowledgement is transmitted from a data reception end to a data transmission end, and a request for confirmation of the acknowledgement is transmitted to the data reception end in response to a determination of an insufficient reliability of the acknowledgement. The request is detected at the data reception end and a confirmation of the acknowledgement is transmitted to the data transmission end in response to the detection result.

It is apparent that the invention can easily be extended to any retransmission procedure for any kind of connection or channel of any kind of network. Specifically, the present invention is not intended to be restricted to cellular or wireless networks. The embodiment may thus vary within the scope of the attached claims. Further more, while the invention has been described mainly for the case that the NodeB is the receiving device and the terminal device the transmitting device, this can be reversed as well and other devices can take the respective role as well.

Claims

Claims

1. A method of controlling a retransmission procedure at a data transmission end, said method comprising:

a) checking a reliability of an acknowledgement received from a data re- ception end (10); and

b) signaling a request for confirmation of said received acknowledgement to said data reception end (10), in response to a determination of an insufficient reliability as a result of said checking.

2. A method of controlling a retransmission procedure at a data reception end, said method comprising:

a) transmitting an acknowledgement to a data transmission end (20);

b) detecting a request for confirmation of said acknowledgement; and

c) transmitting a confirmation of said acknowledgement in response to the detection result.

3. The method according to claim 1 or 2, wherein said retransmission procedure is a hybrid automatic repeat request procedure.

4. The method according to any one of the preceding claims, wherein said confirmation can be enabled or disabled via a signaling of a protocol layer higher than the protocol layer of said retransmission procedure.

5. The method according to claim 4, wherein said confirmation can be enabled or disabled by a base station or access device of a wireless network.

6. The method according to claim 4 or 5, wherein said confirmation is enabled or disabled by setting or resetting a flag of said higher protocol layer.

7. The method according to any one of claims 4 to 6, wherein said higher pro- tocol layer is a radio resource control protocol layer.

8. The method according to any one of the preceding claims, wherein said request for said confirmation is signaled by a predetermined setting of a resource allocation table.

9. The method according to claim 8, wherein said predetermined setting is an empty allocation with all bits set to zero.

10. The method according to claim 8 or 9, wherein said request for said confirmation is signaled by a predetermined setting of a transport format.

11. The method according to any one of the preceding claims, wherein said request for said confirmation is signaled by a predetermined combination of a transport format and a number of resources.

12. The method according to any one of the preceding claims, wherein said confirmation is transmitted synchronously during a specific transmit timing interval.

13. The method according to any one of claims 1 to 11 , wherein said confirma- tion is transmitted asynchronously based on a signaled retransmission process number.

14. The method according to any one of claims 1 to 11 or 13, wherein said request for said confirmation is signaled during a predetermined time window.

15. The method according to any one of claims 1 to 11 or 13, wherein said re- quest for said confirmation is signaled taking into account a discontinuous transmission or reception cycle.

16. The method according to claim 15, further comprising controlling said data reception end (10) to stay awake from a discontinuous transmission or reception mode after it has sent a negative acknowledgement.

17. The method according to any one of the preceding claims, further comprising storing at said data reception end (10) data indicating the last type of acknowledgement.

18. The method according to any one of the preceding claims, further comprising assigning to said data reception end (10) a resource to be used for transmitting said confirmation.

19. The method according to any one of the preceding claims, further compris- ing signaling to said data reception end (10) a timing relation of said confirmation together with said request for said confirmation.

20. A data transmitting apparatus for controlling a retransmission procedure, said apparatus (20) comprising:

a) checking means (220) for checking a reliability of an acknowledgement received from a receiving end (10); and

b) signaling means (230) for signaling a request for confirmation of said received acknowledgement to said receiving end (10), in response to a determination of an insufficient reliability as a result of said checking by said checking means (220).

21. The apparatus according to claim 20, wherein said retransmission procedure is a hybrid automatic repeat request procedure.

22. The apparatus according to claim 20 or 21 , wherein said signaling means (230) is configured to enable or disable said confirmation via a signaling of a protocol layer higher than the protocol layer of said retransmission proce- dure.

23. The apparatus according to claim 22, wherein said signaling means (230) is configured to enable or disable said confirmation by setting or resetting a flag of said higher protocol layer.

24. The apparatus according to any one of claims 4 to 6, wherein said higher protocol layer is a radio resource control protocol layer.

25. The apparatus according to any one of claims 20 to 24, wherein said signaling means (230) is configured to signal said request for confirmation by a predetermined setting of a resource allocation table.

26. The apparatus according to claim 25, wherein said predetermined setting is an empty allocation with all bits set to zero.

27. The apparatus according to claim 25 or 26, wherein said signaling means (230) is configured to signal said request for said confirmation by a prede- termined setting of a transport format.

28. The apparatus according to any one of claims 20 to 27, wherein said signaling means (230) is configured to signal said request for confirmation by a predetermined combination of a transport format and a number of resources.

29. The apparatus according to any one of claims 20 to 27, wherein said signaling means (230) is configured to signal said request for said confirmation during a predetermined time window.

30. The apparatus according to any one of claims 20 to 27, wherein said signaling means (230) is configured to signal said request for said confirmation by taking into account a discontinuous transmission or reception cycle.

31. The apparatus according to any one of claims 20 to 30, wherein said signaling means (230) is configured to assign to said data reception end (10) a resource to be used for transmitting said confirmation.

32. The apparatus according to any one of claims 20 to 31 , wherein said signal- ing means (230) is configured to signal to said data reception end (10) a timing relation of said confirmation together with said request for said confirmation.

33. The apparatus according to any one of claims 20 to 32, wherein said apparatus is configured to control said data reception end (10) to stay awake from a discontinuous transmission or reception mode after it has sent a negative acknowledgement.

34. The apparatus according to any one of claims 20 to 33, wherein said apparatus is a base station or access device of a wireless network.

35. A data receiving apparatus for controlling a retransmission procedure, said apparatus (10) comprising:

a) transmitting means (100) for transmitting an acknowledgement to a data transmission end (20);

b) detecting means (110) for detecting a request for confirmation of said acknowledgement; and

c) confirmation control means (130) for initiating transmission of a confirmation of said acknowledgement in response to said detection means.

36. The apparatus according to claim 35, wherein said confirmation control means (130) is configured to initiate transmission of said confirmation synchronously during a specific transmit timing interval.

37. The apparatus according to claim 35, wherein said confirmation control means (130) is configured to initiate transmission of said confirmation asyn- chronously based on a received retransmission process number.

38. The apparatus according to any one of claims 35 to 37, further comprising storing means for storing data indicating the last type of acknowledgement.

39. The apparatus according to any one of claims 35 to 38, wherein said apparatus (10) is configured to be controllable by a control signaling received from said transmission end (20) to stay awake from a discontinuous trans- mission or reception mode after said apparatus (10) has sent a negative acknowledgement.

40. The apparatus according to any one of claims 35 to 39, wherein said apparatus is a terminal device (10).

41. A computer program product comprising code means for generating the steps of method claim 1 when run on a computer device.

42. A computer program product comprising code means for generating the steps of method claim 2 when run on a computer device.

43. A system for handling retransmission, said system comprising a data transmission apparatus according to claim 20 and a data receiving apparatus according to claim 35.