RU2378768C2 - Method and apparatus for increasing reliability of transmitting data in wireless communication systems - Google Patents

Abstract

FIELD: physics; communications. ^ SUBSTANCE: invention relates to wireless communication systems. Methods of detecting duplication and reordering for HARQ transmission are proposed. To detect duplication, a receiver determines whether a decoded packet x for ARQ channel y is a duplicate packet based on packet x and a previously decoded packet for ARQ channel y. For reordering, the receiver determines whether an earlier packet is still expected on any other ARQ channel based on previously decoded packets for ARQ channels, and redirects packet x only if no more earlier packets are expected. On another ARQ channel z there are no expected earlier packets, if (1) a decoded packet was received on the ARQ channel z during a given time or after or (2) within the time window from the current time, no correctly decoded packet was received on ARQ channel z. ^ EFFECT: more reliable data transmission. ^ 30 cl, 13 dwg, 1 tbl

Description

FIELD OF THE INVENTION

[0001] In General, the present invention relates to wireless communications, and more particularly to technologies for improving the reliability of data transmission.

BACKGROUND

[0002] Many wireless communication systems use HARQ to increase the reliability of data transmission. Using HARQ, each data packet can be transmitted by the transmitter once or repeatedly until the packet is correctly decoded by the receiver or the maximum number of transmissions for this packet is transmitted. The HARQ entity in the transmitter (often referred to as the HARQ transmitter entity) receives packets that are assigned sequence numbers, encodes each packet into one or more subpackets, and transmits these subpackets in sequential order.

[0003] The corresponding HARQ entity at the receiver (often referred to as the HARQ receiver entity) receives transmissions from the transmitter and combines subpackets that belong to one packet. Then, the combined subpackets for each transmitted packet are decoded in an attempt to recover the transmitted packet. However, due to degradation caused by destructive effects on the wireless link, some of the received packets may be decoded in error and are called destroyed packets. The receiver may send a confirmation (ACK) for each correctly decoded packet to the transmitter to complete the further transmission of subpackets for that packet and / or a negative acknowledgment (NAK) for each destroyed packet to begin transmitting another subpacket of this packet. The transmitter may erroneously receive the ACK and / or NAK sent by the receiver. Each ACK that is erroneously detected by the transmitter as a NAK leads to the transfer of a different subpacket for a packet that has already been correctly decoded by the receiver. Excessive transmission may be correctly decoded by the receiver, resulting in packet duplication. The error level for ACK transmissions can be high and, therefore, the receiver can often receive duplicate packets.

[0004] The HARQ receiver entity must also provide correctly decoded packets to higher layers. In many systems, higher layers are expected to receive data in the proper order, as determined by packet sequence numbers. Using HARQ, although the HARQ transmitter object sends the first subpackets in sequential order, due to additional subpacket transmissions for destroyed HARQ packets, the receiver object can recover packets in random order. As a result, the HARQ receiver object usually buffers packets that have been correctly decoded, reorders these packets as needed, and provides reordered packets to the upper layers. If the packets are restored in random order, then the HARQ receiver object can “stop” or delay the delivery to the upper levels of correctly decoded packets every time when detecting the absence of earlier packets until either (1) the missing packets are not correctly decoded by the HARQ receiver object, or (2 ) The HARQ receiver object will not be sure that the missing packets are lost and will not be received. If the HARQ receiver object declares that the packet is lost, although this is not the case, then the upper layers may (1) initiate the retransmission of the lost packet despite a long delay, or (2) consider the packet as lost, but both are undesirable.

[0005] In a simple reordering scheme, the receiver stores each correctly decoded packet in a buffer until the maximum length of time for transmitting all the earlier packets has expired. Then, after this maximum length of time, the receiver provides the correctly decoded packet to the upper layers with the confidence that any earlier packets that are still missing will not be received. However, for this simple reordering scheme, the delay in delivering packets to the upper layers can be excessively long.

[0006] Therefore, there is a need in the art for efficiently performing duplication and reordering detection in HARQ transmission.

SUMMARY OF THE INVENTION

[0007] This section describes methods for performing duplication and reordering detection in HARQ transmission. In a HARQ synchronous system, HARQ transmission uses many ARQ channels, and with HARQ transmission, both the transmitter and the receiver know a priori the time at which transmission on each ARQ channel occurs. In an asynchronous HARQ system, the time between subsequent transfers of subpackets on the same ARQ channel is variable and is determined by the planning object based on the channel and / or other features. If the scheduling entity is in the transmitter, which typically occurs in the uplink (or downlink), then a reliable control mechanism can be used to tell the receiver the time at which each ARQ channel is transmitting. In a system with a fully planned downlink (or uplink), the scheduling entity is located in the receiver, which in this case knows the time at which transmission on each ARQ channel occurs. For both synchronous and asynchronous HARQ systems, it is assumed that both the transmitter and the receiver know the time at which transmission on each ARQ channel occurs.

[0008] In HARQ transmission, the transmitter receives a sequence of data packets to which sequence numbers can be assigned to indicate their order in the sequence. The transmitter processes each packet and generates many subpackets to which it assigns successively numbered subpacket identifiers (SPIDs). The transmitter transmits packets in sequential order (based on their serial numbers or in the order of arrival from the upper levels) on the ARQ channel as soon as these channels become available. Each packet is sent on one ARQ channel. For each packet, subpackets for this packet are sent in sequential order based on their SPID, one subpacket at a time, until an ACK is received for the packet or all subpackets are sent.

[0009] To detect duplication, the receiver determines whether a given correctly decoded packet x for a given ARQ channel y is a duplicated packet based on a correctly decoded packet x and a previous correctly decoded packet for an ARQ channel y . After receiving the previous correctly decoded packet, the receiver assigns the unspecified SPID for the ARQ channel to the SPID ℓ of the last subpacket received for the previous correctly decoded packet, plus one, that is, the unintended SPID = ℓ +1. An unintended SPID is an SPID for a subpacket that is not expected to be received on the ARQ channel y . For example, the receiver may send an ACK for the previous correctly decoded packet, which may be erroneously detected by the transmitter as a NAK, which may then transmit the next subpacket with SPID ℓ +1. The receiver receives the SPID of the last subpacket received for the correctly decoded packet x , compares the SPID of this subpacket with the unintended SPID and announces that the packet x is a duplicate packet if the two SPIDs match. The receiver increments the unintended SPID each time ARQ channel y can be sent subpacket so that an unintended SPID tracks the SPID of a subpacket that is not expected to be received on the ARQ channel y . Such an increase occurs even if the receiver has not detected transmission. For example, the receiver can decode a packet with the value SPID = ℓ on the ARQ channel y and send an ACK, which is erroneously detected by the transmitter as NAK. The receiver will not be able to detect the subsequent transmission of the subpacket SPID = по +1 on the ARQ channel y , but it will be able to detect the transmission after the SPID becomes ℓ +2. By constantly increasing the unintended SPID, it is guaranteed that the receiver will always detect duplicate packets, even if it does not detect some subpackets.

[0010] For reordering, the receiver receives a correctly decoded packet x for ARQ channel y , determines whether an earlier packet is still expected on any other ARQ channel based on the previous correctly decoded packets (if any) for ARQ channels, and redirects packet x to higher levels only if earlier packages are not expected. Each expected earlier packet is a packet that was sent before packet x and which can still be received. On the other ARQ channel z there are no expected earlier packets if (1) the correctly decoded packet was received on the ARQ channel z within a specified time or later, or (2) from the current frame within the time window, a correctly decoded packet on the ARQ channel z was not received. The set time for packet x is determined by the start time and the ARQ numbers of the channels available for HARQ transmission. For synchronous HARQ, the time window is determined by the maximum number of subpackets for each packet and the number of ARQ channels. For an asynchronous HARQ in a planned system, the scheduling entity knows a time window for transmission on each ARQ channel.

[0011] Various aspects and embodiments of the present invention are described in more detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG. 1 illustrates packet processing for HARQ systems.

[0013] FIG. 2 shows synchronous HARQ transmission on one ARQ channel.

[0014] FIG. 3A shows synchronous HARQ transmission over four ARQ channels;

[0015] FIG. 3B shows a data buffer for HARQ transmission of FIG. 3A;

[0016] FIG. 4 illustrates processing for performing duplication detection;

[0017] FIGS. 5A and 5B show two states of determining whether an earlier packet is still expected on another ARQ channel;

[0018] FIG. 6 illustrates a packet reordering procedure;

[0019] FIG. 7 shows a procedure for determining whether or not there are expected earlier packets;

[0020] FIG. 8 shows a procedure for processing received packets for HARQ transmission;

[0021] FIG. 9 shows a procedure for reordering and redirecting packets to higher layers;

[0022] FIG. 10 shows a HARQ transmission procedure of FIG. 3A; and

[0023] FIG. 11 is a block diagram of a wireless device and a base station.

DETAILED DESCRIPTION OF THE INVENTION

[0024] The word “illustrative” in the present description means “to serve as an example, occasion or illustration”. Any embodiment described herein as “illustrative” is not necessarily to be considered more preferred or advantageous than other embodiments.

[0025] The methods for detecting duplication and reordering described herein can be used for various communication systems, such as a Code Division Multiple Access (CDMA) system, a Time Division Multiple Access (TDMA) system, a Frequency Division Multiple Access system (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Ultra Wide Band System (UWB), etc. A CDMA system can be implemented as cdma2000, Broadband-CDMA (W-CDMA), or as some other CDMA radio access (RAT) methods. A TDMA system can be implemented as a Global System for Mobile Communications (GSM) or in the form of any other RAT. An OFDM system may be implemented as IEEE 802.11, IEEE 802.16, or IEEE 802.20. The UWB system can be implemented as 802.15. cdma2000 IS-95, IS-2000 and IS-856 and are described in documents from a consortium called the “3rd Generation 2 Partnership Project” (3GPP2). W-CDMA and GSM are described in documents from a consortium named “3rd Generation Partnership Project” (3GPP). 3GPP and 3GPP2 - Documents are available. Duplication and reordering detection methods can also be used for uplink (or downlink) and downlink (or uplink). For clarity, these methods are described for the downlink in cdma2000 version D.

[0026] FIG. 1 illustrates packet processing for a HARQ system. The wireless device processes each data packet in order to generate an encoded packet and further divide the encoded packet into three subpackets. Data packets / coded packets are assigned sequential sequence numbers and are labeled Pac0, Pac1, Pac2, etc., see FIG. For these three subpackets, for each coded packet, the subpacket identifiers (SPIDs) '0', '1' and '2' are assigned and are labeled as SP0, SP1 and SP2 in FIG. Each subpacket contains sufficient information to allow the receiving base station to decode the channel subpacket and recover the packet under favorable conditions. Three subpackets of each packet contain various redundant information for the given packet. Three subpackets for a package can be considered as different versions of a given package or different transfers of a given package.

[0027] The encoded packets begin to transmit in sequential order. Thus, the earliest packet 0 (Pac0) is transmitted before packet 1 (Pac1), which is transmitted before packet 2 (Pac2), which is transmitted before packet 3 (Pac3), etc. For each packet, three subpackets are transmitted in sequential order on the same ARQ channel. Thus, subpacket 0 (SP0) is transmitted first, then, if necessary, subpacket 1 (SP1) follows, and then, if necessary, subpacket 2 (SP2) follows. For each packet, one, two or all three subpackets may be transmitted. The packet processing and transmission described above can be used for data / traffic channels in various systems, such as, for example, Downlink Packet Data Channel (R-PDCH) in cdma2000 version D. For clarity, specific details are described below for R-PDCH.

[0028] Figure 2 shows the structure of the data channel in a synchronous HARQ system. The transmission time for the data channel is divided into frames, with each frame having a fixed duration (for example, for R-PDCH in cdma2000 - 10 milliseconds (ms)). One subpacket can be sent in each frame. Then, the transmission time is divided into four ARQ channels, which are assigned the ARQ channel identifiers (ACIDs) '0', '1', '2' and '3'. Four ARQ channels are interleaved in such a way that ARQ channel 0 with ACID = 0 occupies every fourth frame starting in a given frame, ARQ channel 1 with ACID = 1 occupies every fourth frame immediately after ARQ channel 0, ARQ channel 2 with ACID = 2 every fourth frame immediately after ARQ channel 1, and ARQ channel 3 with ACID = 3 takes every fourth frame immediately after ARQ channel 2. The frames used for all four ARQ channels are determined based on system time (SYS_TIME), and are known to the wireless device and base station. Four ARQ channels are also called ARQs and can be considered as four logical channels or four data channel subchannels in a synchronous HARQ system.

[0029] FIG. 2 also shows an illustrative synchronous HARQ transmission on one ARQ channel. Each packet is transmitted and possibly retransmitted on one ARQ channel. For this packet, the wireless device first transmits subpacket 0 in the frame for the ARQ channel, then subpacket 1 (if necessary) in the next available frame for the same ARQ channel, and finally subpacket 2 (if necessary) in the next available frame for the ARQ channel. Since each subpacket is received, the base station attempts to decode the packet based on all subpackets that were received for the packet. If the decoding is successful, the base station sends an ACK on the Upstream Acknowledgment Channel (F-ACKCH), and the wireless device stops sending subpackets of this packet. Conversely, if decoding was unsuccessful, then the base station sends a NAK on the F-ACKCH, and the wireless device sends the next sub-packet of this packet. The delay for NAK or ACK transmission is one frame. In an asynchronous HARQ system, each subpacket is also transmitted sequentially on the same ARQ channel, but there is no fixed length of time between consecutive transmissions on the same ARQ channel.

[0030] For the example shown in FIG. 2, the wireless device transmits subpacket 0 of packet 0, which is decoded by the base station in error. The wireless device then transmits subpacket 1 of packet 0, which is decoded correctly, and therefore sends back the ACK. The wireless device then transmits subpacket 0 of the next packet 1, which is decoded by the base station in error. The wireless device then transmits subpacket 1 of packet 1. For other packets, data transmission continues in the same manner.

[0031] For clarity, Figure 2 shows the transmission of both NAK and ACK. In order to reduce the number of signal transmissions, many systems send only ACK or only NAK. For an ACK-based scheme, the receiver transmits the ACK only if the packet is decoded correctly and does not send any NAK. Thus, the ACK is sent explicitly, and the NAK is sent implicitly (i.e., it is assumed due to the lack of ACK or is indicated in some other ways). For a NAK-based scheme, a receiver sends a NAK only if the packet is decoded in error and does not send an ACK. The methods described herein can be used with any type of feedback.

[0032] The receiver may determine whether a given packet is decoded correctly or in error based on the erroneous detection code used for the packet. For example, a packet is decoded correctly if the cyclic redundancy check (CRC) has passed for the packet, and decoded with an error if the CRC has failed. As used herein, a decoded packet is a packet that the receiver has decoded correctly (for example, a CRC has passed), and a destroyed packet is a packet that has been decoded by the receiver with an error (for example, the CRC has failed).

[0033] As shown in FIG. 2, some delays have been introduced for transmitting a subpacket, decoding a packet, and sending back an ACK or NAK. Subpacket transmissions for each ARQ channel are separated by four frames to account for transmission delay and processing. Over four ARQ channels, a wireless device can transmit up to four packets in parallel. Up to four pending packet transmissions can be processed at any given moment. Each pending packet transmission occurs for a packet that has not been recognized as being decoded by the base station.

[0034] FIG. 3A illustrates an exemplary synchronous HARQ transmission on all four ARQ channels. The wireless device sends subpacket 0 of packets 0, 1, 2, and 3 on ARQ channels 0, 1, 2, and 3, respectively, in frames 0, 1, 2, and 3, respectively. The base station receives these four subpackets, decodes packets 0, 1, and 3 with an error, and packet 2 decodes correctly. Then, the wireless device transmits subpacket 1 of packets 0, 1, and 3 on ARQ channels 0, 1, and 3, respectively, in frames 4, 5, and 7, respectively, and transmits subpacket 0 of next packet 4 on ARQ channel 2 in frame 6. The base station receives subpackets , decodes packets 0 and 3 correctly, and packets 1 and 4 decodes with an error. The wireless device then transmits subpacket 0 of the next packet 5 on ARQ channel 0 in frame 8, subpacket 2 of packet 1 on ARQ channel 1 in frame 9, subpacket 1 of packet 4 on ARQ channel 2 in frame 10, and subpacket 0 of next packet 6 on ARQ channel 3 in frame 11. The base station receives subpackets, decodes packets 1, 5 and 6 with an error, and packet 4 decodes correctly. The wireless device then transmits subpacket 1 of packet 5 on ARQ channel 0 in frame 12, subpacket 0 of next packet 7 on ARQ channel 1 in frame 13, subpacket 0 of next packet 8 on ARQ channel 2 in frame 14, and subpacket 1 of packet 6 on ARQ channel 3 in frame 15. The wireless device transmits a new packet on ARQ channel 1, even if packet 1 was not decoded, since all three subpackets were sent for packet 1. The wireless device continues to transmit a new packet whenever an ARQ channel becomes available.

[0035] FIG. 3B shows the contents of a data buffer used to store decoded packets at a base station. A data buffer is commonly called a reordering buffer. Each decoded packet can be temporarily stored in the data buffer until the packet is ready to be sent to the upper layers. 3B shows each decoded packet and the frame in which the packet was decoded. Packet 2 was decoded in frame 2, packet 0 was decoded in frame 4, packet 3 was decoded in frame 7, packet 4 was decoded in frame 10, packet 5 was decoded in frame 12 and packet 8 was decoded in frame 14. In frame 9, the absence of packet 1 was detected. As shown in FIGS. 3A and 3B, although the wireless device transmits packets starting in sequential order, the base station restores the packets in random order due to additional transmissions of the destroyed packets.

[0036] For simplicity, FIG. 3A does not receive detection errors for ACKs and NAKs sent by the base station to the wireless device. For each ACK that is detected as a NAK, the wireless device transmits the next packet subpacket that has already been decoded by the base station. For each NAK that is detected as an ACK, the wireless device transmits the next packet, even if the previous packet was not decoded by the base station. To achieve reliable data transmission, the NAK / ACK error level is usually low (for example, 0.1%). However, the ACK / NAK error rate can be high and variable (for example, from 1 to 10%). The base station may receive duplicate packets due to ACK / NAK errors.

[0037] The base station may perform duplicate detection to identify and reject duplicate packets. Duplication detection can be performed based on the following assumptions: (1) the base station (or receiver) has ARQ channel information sent in each frame based on system synchronization, (2) subpackets for each packet are sent in sequential order, and (3 ) the base station can assign the SPID of the subpacket only in the case of decoding the packet.

[0038] FIG. 4 is a flowchart of a procedure 400 for performing detection of duplication of packets received by HARQ transmission. For each ARQ channel, the base station supports the Unexpected_SPID variable. This variable indicates the SPID of the subpacket whose reception is not expected on the ARQ channel. At the beginning of the HARQ transmission for each ARQ channel, the base station initializes the Unexpected_SPID with an invalid value (step 410). For example, Unexpected_SPID can be assigned to Max_Num_Tx, which is the maximum number of subpackets for each packet, where Max_Num_Tx = 3 for the R-PDCH in cdma2000 version D. At step 410, the initialization is performed once for the HARQ transmission.

[0039] The base station performs duplicate detection for each frame during transmission. The base station determines the ARQ channel for the current frame (which is called the ARQ channel y ) based on its system time information (step 420). Then, the base station attempts to decode the packet for the current frame (step 422). Next, a determination is made whether the packet has been decoded (step 424). If the packet was decoded, then the base station receives the SPID from the subpacket received in the current frame (which is called SPID k ) (step 426). In cdma2000 version D, each subpacket carries the SPID assigned to the subpacket, but the base station can reliably set the SPID only if the packet is decoded.

[0040] Then, the base station determines whether the SPID is equal to the Unexpected_SPID value for channel ARQ y (step 428). If the ARID channel y SPID is not equal to Unexpected_SPID, which would be the case for the first packet sent on the ARQ channel y , because Unexpected_SPID was initialized with an invalid value, then Unexpected_SPED is assigned the value to +1 (step 432). For ARQ channel at the base station does not expect to receive a subpacket with SPID value to 1 in the next frame, since packet x is already decoded. If in the next frame for the ARQ channel y a subpacket with an SPID value of k + 1 is received, then this subpacket should have been sent due to an ACK / NAK error and is a duplicate packet. Thus, returning to step 428, if the SPID k is Unexpected_SPID, then packet x is declared as a duplicate packet and is discarded (step 430). After step 430 Unexpected_SPID is set to 1 (step 432).

[0041] If the current frame the packet was destroyed, as determined in step 424, then a determination is made whether for ARQ channel y Unexpected_SPID misleading value (e.g., equal to Max_Num_Tx) (block 434). If the answer is 'No', then for the ARQ channel of the base station increases the value of Unexpected_SPID by one (step 436). If the answer is 'Yes' in step 434 and after step 436, the procedure returns to step 420 to process the next frame.

[0042] The duplication detection of FIG. 4 assigns an Unexpected_SPID value based on the SPID of the last subpacket received for the decoded packet. The detection of duplication increases in step 436 the Unexpected_SPID value by one (1) each time a received packet is received, since the subpackets are sent in sequential order, and (2) if the Unexpected_SPID value does not reach Max_Num_Tx and is not an invalid value assigned in step 410. If the value Unexpected_SPID reaches the value Max_Num_Tx in step 436, then the value Unexpected_SPID can be stored with the value Max_Num_Tx or set to some other invalid value. Detection of duplication can also be performed in other ways, based on this description.

[0043] As shown in FIGS. 3A and 3B, a HARQ receiver entity in a base station may recover packets in random order, even if packets were sent sequentially. To reduce the delay, it is desirable to forward each decoded packet to the upper layers as soon as possible. However, if the upper layers expect packets to be received in sequential order, then the HARQ receiver object usually buffers the decoded packets, reorders packets that are not sequential, and then provides reordered packets to the upper layers.

[0044] For a given decoded packet x, the base station can redirect packet x to higher layers if there is no packet that was sent before packet x and can still be received. Another packet b is sent before packet x , if the transmission of packet b has begun before the transmission of packet x . If the packets are sent in sequential order, then if another packet b was sent before packet x , packet b should have been redirected to the upper layers before packet x , if the upper layers were waiting for packets to be received in sequential order. If packet b is not decoded after as many ARQ retransmissions as possible, then packet b is lost and packet x can be redirected to higher layers.

[0045] For each ARQ channel, the base station can maintain a flag and can clear this flag for packet x if there are no expected earlier packets on the ARQ channel. The expected earlier packet is a packet that was sent on the ARQ channel before packet x and which can still be received by the base station. The base station can redirect packet x to the upper layers if flags are cleared for all ARQ channels. Table 1 presents the various variables used in the description below, and a brief description is given for each variable. For the R-PDCH in cdma2000, the third column of Table 1 shows the default values for some of the variables.

Table 1

Variable Description Default value Num_channels ARQ number of the channel available for data transmission four Max_Num_Tx Maximum number of subpackages per package 3 Max_wait The maximum amount of time (in frames) to wait for a packet on another ARQ channel 8 frames Current_frame Current frame being processed Start_time Time of first packet transmission. Start_Time is supported for each packet and is set in units of frames. Last_Decode_Time The time of the last reception of the decoded packet on the ARQ channel. Last_Decode_Time is supported for each ARQ channel and is set in units of frames.

[0046] In synchronous HARQ, the value of Max_Wait can be calculated as follows:

Max_Wait = Num_Channels x (Max_Num_Tx-1). equation (1)

Max_Wait = 8 frames for the R-PDCH in cdma2000 version D. In the R-PDCH for synchronous HARQ, autonomous transmissions are possible.

[0047] In asynchronous HARQ on the R-PDCH, each transmission may be scheduled. Max_Wait for an ARQ channel is the time between the first and last transmission of a subpacket on a given ARQ channel and can have a variable duration. The receiver knows the Max_Wait value for each ARQ channel if the scheduling object is in the receiver. This is true for fully planned downlinks such as IEEE 802.16. If the scheduling entity is in the transmitter, then the Max_Wait value can be determined for the ARQ channel, if the transmitter has a reliable way of transmitting the subpacket and the ARQ channel identifier to the receiver.

[0048] For each ARQ channel z , where z ∈ C, and C denotes the set of all ARQ channels, the base station can clear the flag for ARQ channel z if either of the following two conditions is met:

1. A packet was sent on the ARQ channel z after Start_Time for packet x or, equivalently, the Last_Decode_Time value for ARQ channel z is greater than the value of Start_Time for packet x minus the Num_Channels value;

2. At least (Max_Num_Tx-1) subpackets were sent on the ARQ channel z , starting with the Start_Time value for packet x .

For unplanned but synchronous HARQ transmission, the number of subpackets that were sent on the ARQ channel can be determined by the time elapsed since the last decoding. For scheduled HARQ transmission, both synchronous and asynchronous, the receiver knows that the subpacket is scheduled. In this case, the receiver knows when it is sent on each ARQ channel (Max_Num_Tx-1).

[0049] For synchronous HARQ, where each subsequent subpacket is transmitted on the ARQ channel after a fixed delay, conditions 1 and 2 are described in detail below. This reduces the time required to describe the algorithm below. The algorithm can also be used for asynchronous HARQ if the receiver knows the Start_Time value of each ARQ channel.

[0050] FIG. 5A shows flag flushing for ARQ channels based on the first condition. For the example shown in FIG. 5A, a packet x is sent on the ARQ channel y −1, starting at the Start_Time shown in FIG. 5A, and is decoded in the current frame. All frames starting after Start_Time-4 (which is a given time and is equal to Start_Time-Num_Channels) to the current frame are shown with diagonal hatching. If a packet for some ARQ channel z were decoded in any of the frames with shading, then any packet that could be sent after this decoded packet on the same ARQ channel z would have a start time longer than Start_Time for packet x . Therefore, this ARQ channel z cannot carry an earlier packet than packet x , and the flag for this ARQ channel z can be reset. Enabling Start_Time-4 for the first condition is optional for decoding packet x while enabling flag reset for channel ARQ y for packet x .

[0051] FIG. 5B shows a flag reset for ARQ channels based on the second condition. For the example shown in FIG. 5B, Max_Num_Tx = 3 and up to three subpackets are sent for each packet. Packet x is sent on the ARQ channel y = 1, starting at Start_Time shown in FIG. 5B, and is correctly decoded in frame Tc-3, which for packet x is four frames after Start_Time. ARQ channel z , which, for packet x, carried Max_Num_Tx-1 subpackets starting with Start_Time, cannot carry the packet that was sent for packet x before Start_Time. For example, the ARQ channel z = 2 carries a subpacket in a Tc-2 frame that is two frames in front of the current frame, and another subpacket in a Tc-6 frame that is six frames in front of the current frame. For packet x, both subpackets are sent on ARQ channel 2 after Start_Time. After processing the subpacket for ARQ channel 2 in the Tc-2 frame, it is impossible for ARQ channel 2 to still carry the packet that for packet x was sent before Start_Time. This happens because, if for a packet x an ARQ channel 2 would have been sent before Start_Time, then this packet would have to be sent starting from the Tc-10 frame and ending in the Tc-2 frame, regardless of whether the packet was decoded or destroyed because the maximum number of subpackets was sent for this packet. For the second condition, for each ARQ channel z , the flag can be reset if within the last Num_Wait frames, starting from the current frame, which can be considered as a sliding time window, no packet was decoded for the ARQ channel z . The above example can also be applied if the packet x was decoded in the Tc-7 frame, and not in the Tc-3 frame.

[0052] FIG. 6 is a flowchart of a procedure 600 for reordering packets received by HARQ transmission. Upon transmission, the base station reorders each frame. The base station determines the ARQ channel for the current frame (which is called the ARQ channel y ) (block 620). Then, the base station attempts to decode packet x for the current frame (block 622). Then, a determination is made whether the packet x has been decoded (block 624). If packet x was decoded, then the base station determines whether another packet was sent before packet x on a different ARQ channel, and whether it can still be received, i.e. is there an earlier packet that is still expected on another ARQ channel (block 626). If an earlier packet is expected, and the base station must wait for this packet, as determined at block 628, then the base station stores packet x in the data buffer (block 632). Otherwise, if earlier packets are not expected, then the base station forwards packet x and / or all packets that have been decoded and waits for packet x (block 630). There may be times when packet x cannot be redirected, but decoding packet x allows other packets to wait for a redirect in the data buffer. The procedure then returns to block 620 to process the next frame.

[0053] FIG. 7 is a block diagram of an embodiment of step 626 of FIG. 6. First, Start_Time is calculated for packet x , as described below (step 710), and for all ARQ channels, the flags are set to a logical unit (step 712). The index i for ARQ channels is set to zero for the first ARQ channel that has been evaluated (block 714). Then, it is determined whether the packet x , which was decoded in the current frame, was received on the ARQ channel i (step 720). If the answer is 'Yes' at step 720, then the flag for the ARQ of channel i is reset (step 726). Otherwise, a determination is made whether a decoded packet was received for ARQ channel i after Start_Time-Num_Channels, where Start_Time is the start time for packet x (block 722). If the answer is 'Yes' at step 722, then the flag for the ARQ of channel i is reset (step 726). Otherwise, it is determined if any decoded packet for the ARQ channel i was received in the last Max_Wait-1 frames (step 724). If the answer is 'Yes' at step 724, then the flag for the ARQ of channel i is reset (step 726).

[0054] Steps 720 and 722 represent the first condition described above in FIG. 5A, which, for clarity, are shown in FIG. 7 as two separate steps. Step 724 is the second condition described above in FIG. 5B, if the answer is 'No' in all three steps 720, 722, and 724, then at least there is one expected packet that was sent before packet x and which can still be received. An indicator is then provided that packet x is waiting for another packet (block 734), and the processing for block 626 ends.

[0055] If the flag for ARQ channel i is reset at step 726, since no earlier packet is expected in this ARQ channel, then a determination is made whether all ARQ channels have been evaluated (step 728). If the answer is 'No', then the index increases (block 730), and the procedure returns to block 720 to evaluate the next ARQ channel. Otherwise, if the answer is 'Yes' at step 728, this means that the flags for all ARQ channels have been reset, an indicator is provided that the packet x can be redirected to the upper levels (step 732), and the processing for step 626 ends.

[0056] A specific embodiment of packet processing and reordering is described below. For this embodiment, for each ARQ channel, a single Last_Decode_Time variable is maintained and used to evaluate both condition 1 and condition 2 for the ARQ channel. Last_Decode_Time for each ARQ channel indicates the frame in which the decoded packet was the last received for the ARQ channel, and is assigned to the current frame (or Current_Frame) whenever a decoded packet is received on the ARQ channel. Last_Decode_Time for each ARQ channel is also set so that it was less than Current_Frame-Max_Wait whenever the ARQ channel is processed so that condition 2 can be evaluated using the same variable. At the beginning of the HARQ, Last_Decode_Time transmissions for ARQ channels 0, 1, 2, and 3 are initialized to First_Frame-4 , First_Frame-3, First_Frame- 2 and First_Frame-1, respectively, where First_Frame is a frame in which the very first subpacket for HARQ transmission is sent.

[0057] FIG. 8 is a flowchart of a procedure 800 for processing packets received for HARQ transmission. Procedure 800 is performed upon transmission for each frame. The base station determines the ARQ channel for the current frame, which is called the ARQ channel y (block 820), decodes the packet x for the current frame (block 822) and determines whether the packet x has been decoded (block 824). If packet x was decoded, then the base station sets Last_Decode_Time for the ARQ channel y in Current_Frame (step 826), determines the SPID of the subpacket received in the current frame for packet x (step 828), and calculates Start_Time for packet x (step 830) as follows :

Start_Time = Current_Frame-Num_Channels x SPID equation (2)

The start time for each packet is set only if the packet is decoded, and then it is calculated based on the number of subpackets that were transmitted for the packet indicated by the SPID for the subpacket received in the current frame for packet x . Then, packet x is stored in the data buffer along with its Start_Time (block 832).

[0058] If packet x was destroyed, as determined in step 824, the base station determines whether the Last_Decode_Time for ARQ channel y earlier than Max_Wait from the current frame (step 834). If the answer is 'Yes', then the base station sets Last_Decode_Time for the ARQ channel y (step 836) as follows:

Last_Decode_Time = Current_Frame-Max_Wait equation (3)

If the answer is 'No' at step 834, as well as after steps 832 and 836, the procedure ends.

[0059] FIG. 9 is a flowchart of a procedure 900 for reordering and forwarding packets to higher layers. Procedure 900 may be performed after procedure 800 and whenever a decoded packet is received on an ARQ channel. The variable Earliest_Decode_Time is set to the earliest Last_Decode_Time among all ARQ channels (block 910).

[0060] Then, a determination is made whether the data buffer is empty (step 920). If the answer is 'Yes', then the procedure ends. Otherwise, the oldest packet stored in the data buffer (which is called packet z ) is identified (step 922). Packet z has the earliest start time among all packets stored in the data buffer. Decoded packets sorted based on their start time can be stored in the data buffer. For example, a packet with the oldest start time may be stored at the top of the buffer, followed by a packet with the next oldest start time, etc. In either case, the Start_Time of packet z is obtained (block 924).

[0061] Then, a determination is made whether Earliest_Decode_Time is later than the Start_Time of package z minus Num_Channels (step 926). 5A, if a decoded packet was received for another ARQ channel z in the Start_Time-Num_Channels frame or later, then the ARQ channel z does not carry the expected earlier packet. Since only packet x is forwarded if there are no ARQ channels of the earlier packets expected, then using Earliest_Decode_Time effectively evaluates Condition 1 for all ARQ channels through a single comparison in step 926. In addition, setting Last_Decode_Time for each ARQ channel no later than Current_Frame-Max_Wait in step 836 of FIG. 8, also condition 2 evaluated by comparison I'm at step 926.

[0062] If at step 926 the answer is 'Yes', which indicates the absence of any expected earlier packets, then packet z is removed from the data buffer and redirected to the upper layers (step 928). The procedure then returns to block 920 to evaluate the oldest packet (if any) in the data buffer. Otherwise, if at step 926 the answer is 'No', which indicates the presence of at least one expected earlier packet, packet z is stored in the data buffer, and the procedure ends.

[0063] FIG. 10 shows the processing of the illustrative HARQ transmission of FIG. 3A using procedures 800 and 900 of FIGS. 8 and 9, respectively. The first transmission of the subpacket occurs at frame 0, and at the beginning of the HARQ transmission of Last_Decode_Time for ARQ channels 0, 1,2 and 3 is initialized as -4, -3, -2 and -1, respectively. Last_Decode_Time for each ARQ channel is updated whenever an ARQ channel is processed. This update entails setting Last_Decode_Time to (1) the current frame if a decoded packet is received for the ARQ channel, which is the case for frames 2, 4, 7, 10, 12 and 14 in FIG. 10, and (2) the current frame minus Max_Wait, if Last_Decode_Time is greater than the value that occurs for frames 9, 13, and 15. The base station reorders and redirects packets whenever a decoded packet is received, for example, in frames 2, 4, 7, 9, 10, 12, 13, and 14 figure 10. For each frame with a decoded packet, FIG. 10 shows (1) Earliest_Decode_Time calculated for the frame, (2) packets stored in the data buffer, and the start time for each saved packet, which is shown in parentheses, and (3) packets, if any, which are redirected to higher levels. For the example shown in FIG. 10, packet 4 is supported in frame 10 because the packet was not decoded on ARQ channel 1. If the packet sequence number is available for reordering, then packet 4 can be redirected if packet 3 has already been redirected.

[0064] The following are illustrative pseudo-codes for procedures 800 and 900 of FIGS. 8 and 9, respectively.

Variable update:

100 If (CRC for Packetx on ACIDy passes) Then {

110 Last_Decode_Time [ACIDy] = Sys_Time;

120 Start_Time [Packetx] = Sys_Time - 4 * SPID [Packetx];

130 Put Packetx in Buffer sorted based on

increasing values of packet Start_Time; }

140 Else {

150 Last_Decode_Time [ACIDy] = max (Last_Decode_Time [ACIDy],

Sys_Time - 4 * (Max_Num_Tx-l)); }

Reordering and redirecting packages;

200 eva1_next_packet = true;

210 Earliest_Decode_Time = min {Last_Decode__Time [ACID0],

Last_Decode_Time [ACID1], Last_Decode_Time [ACID2],

Last_Decode_Time [ACID3]};

220 While ((eva1_next_packet = true) && (Buffer not empty)) do

230 {

240 Next_Packet = Get oldest packet from Buffer

250 If (Earliest_Decode_Time> Start_Time [Next_Packet] - 4)

260 Then forward Next_Packet to upper layers

270 Else eva1_next_packet = false;

280}

[0065] FIG. 11 is a block diagram of an embodiment of a wireless device 1110 and a base station 1150 in a wireless communication system. A wireless device may also be called a mobile station, user / access terminal, user equipment, handset, subscriber unit, or some other terminology. A base station is a fixed station and may also be called a transceiver base station (BTS), access point, node B, or some other terminology.

[0066] In the downlink, the encoding device 1112 receives traffic data to send to the wireless device 1110 for HARQ transmission, and processes each data packet to generate a corresponding encoded packet. Then, encoding device 1112 can split each encoded packet into multiple subpackets. Processing by encoding device 1112 may include formatting, encoding, interleaving, etc., and is determined by the applicable system standard. For example, data may be sent on an R-PDCH, and processing may be performed in accordance with cdma2000 version D. Modulator 1114 (Mod) receives subpackets and processes each subpacket for transmission. Processing by modulator 1114 may include symbol mapping, channelization, spectral expansion, etc., and is also determined by the applicable system standard. Transmitter (TMTR) block 1116 processes the output from modulator 1114 and restores a downlink signal that is passed through doubler (D) 1118 and transmitted through antenna 1120.

[0067] At base station 1150, an antenna 1152 receives a downlink signal, passes through a doubler 1154, and is processed by a receiver unit (RCVR) 1156 to recover received samples. Then, the demodulator 1158 (Demod) processes (for example, narrows, decodes, and demodulates the data) the received samples and provides demodulated symbols. Decoder 1160 decodes demodulated symbols for each packet sent by wireless device 1110, checks the packet, provides packet status to dispatcher 1170, and provides packet (if decoded) to data buffer 1174. Processing with demodulator 1158 and decoder 1160 at base station 1150 is additional to processing using a modulator 1114 and an encoder 1112, respectively, in the wireless device 1110.

[0068] The encoding device 1112 and decoder 1160 perform processing on the physical layer. HARQ is typically implemented at the Middle Access Control (MAC) layer, which is located at the top of the physical layer. In one embodiment, the encoder 1112 implements the HARQ transmitter object, in whole or in part, for HARQ transmission from the wireless device 1110 to the base station 1150. The decoder 1160 implements the HARQ receiver object, in whole or in part, for HARQ transmission. In another embodiment, the manager 1130 implements the HARQ transmitter object, in whole or in part, and the controller 1170 implements the HARQ receiver object, in whole or in part. For example, decoder 1160 may provide the status of each received packet and decoding time for each decoded packet, and controller 1170 may perform duplicate detection, reordering, and redirecting decoded packets to higher layers. Controller 1170 may further provide appropriate ACK / NAK feedback for each subpacket received from wireless device 1110.

[0069] For the uplink, the data to be sent by the base station 1150 and the ACK / NAK for the wireless device 1110 are processed (eg, formatted, encoded, etc.) by the encoding device 1180, further processed (eg, channelized, expanded etc.) by the modulator 1182 and normalized by the transmitter unit 1184 to recover the uplink signal, which is passed through the doubler 1154 and transmitted through the antenna 1152. In the wireless device 1110, the uplink signal received by the antenna 1120, etc. passed through a duplexer 1118, and processed by a receiver unit 1140 to restore the input samples. A demodulator 1142 processes the input samples and provides demodulated symbols, and a decoder 1144 further processes demodulated symbols and provides decoded data to a data buffer 1134.

[0070] The controller 1130 receives from the decoder 1144 ACK / NAK feedback sent by the base station 1150, and directs the transmission of subpackets for the destroyed and new packets. The controllers 1130 and 1170 further control the operation of various processing units in the wireless device 1110 and base station 1150, respectively. Controllers 1130 and 1170 may implement all or part of the duplication and reordering detection methods described herein for uplink and downlink HARQ transmission, respectively. For example, each controller may implement the procedures shown in FIGS. 4, 6, 7, 8, and 9. Memory units 1132 and 1172 store program codes and data used by controllers 1130 and 1170, respectively.

[0071] For clarity, methods for detecting duplication and reordering have been described for R-PDCH in cdma2000 version D. In general, these technologies can be used for HARQ with any number of ARQ channels, any number of subpackets / transmissions for each packet, etc.

[0072] The methods for detecting duplication and reordering described herein can be implemented using various means. For example, these methods may be implemented using hardware, software, or a combination thereof. For hardware implementation, processing units that perform duplicate detection and / or reordering can be implemented within one or more specialized integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, and other electronic units designed to fulfill the requirements of this writing functions, or combinations thereof.

[0073] For implementation using software, methods for detecting duplication and reordering can be implemented using modules (eg, procedures, functions, etc.) that perform the functions disclosed herein. Software codes may be stored in a memory unit (for example, memory unit 1132 or 1172 in FIG. 11) and executed by a processor (eg, controller 1130 or 1170). The memory unit may be implemented within the processor or outside the processor.

[0074] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments are apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the spirit or scope of the present invention. Thus, the present invention is not limited to the embodiments disclosed in the present description, but should correspond to the broadest scope consistent with the principles and new features disclosed in the present description.

Claims (30)

1. A method for performing duplicate detection for transmitting a hybrid automatic data retransmission request (HARQ), comprising decoding a current subpacket received on an ARQ channel to obtain a decoded packet or a destroyed packet for an ARQ channel, said current subpacket containing a sequence number and an identifier, and if the decoded packet is received for the ARQ channel, it is determined whether the decoded packet is a duplicate packet based on the identifier of the current subpacket and the identifier by Lednov subpacket received for a prior decoded packet obtained for the ARQ channel. 2. The method according to claim 1, wherein determining whether the decoded packet is a duplicate packet, comprises determining an unintended identifier for the ARQ channel based on the identifier of the last subpacket received for the previous decoded packet, the unidentified identifier being an identifier for a subpacket that is not received expected on the ARQ channel, comparing the identifier of the current subpacket with an unintended identifier, and declaring the decoded packet as a duplicate packet, If the identifier of the current subpacket is equal to the unexpected identifier. 3. The method according to claim 2, in which the definition of an unspecified identifier comprises assigning an unspecified identifier to the identifier value of the last subpacket received for the previous decoded packet, plus one for each subpacket received on the ARQ channel, starting from the last subpacket. 4. The method according to claim 2, further comprising assigning to the unexpected identifier the identifier value of the current packet plus one if the decoded packet is received for the ARQ channel, and increasing the unexpected identifier by one if the destroyed packet is received for the ARQ channel. 5. A device for receiving transmission of a hybrid automatic request for retransmission of data (HARQ) in a wireless communication system, comprising: a decoder for decoding a current subpacket received on an ARQ channel, and providing a decoded packet or destroyed packet for an ARQ channel, wherein said current subpacket contains serial number and identifier; and a controller so that if a decoded packet is received for the ARQ channel, determine whether the decoded packet is a duplicate packet based on the identifier of the current subpacket and the identifier of the last subpacket received for the previous decoded packet received for the ARQ channel. 6. The device according to claim 5, in which the controller determines an unexpected identifier for the ARQ channel based on the identifier of the last subpacket received for the previous decoded packet, compares the identifier of the current subpacket with the unexpected identifier, and declares the decoded packet a duplicate packet if the identifier of the current subpacket is equal to the unexpected identifier . 7. The device according to claim 6, in which the controller assigns an identifier value to the identifier of the current packet plus one if the decoded packet is received for the ARQ channel, and increases the unexpected identifier by one if the destroyed packet is received for the ARQ channel. 8. The apparatus of claim 5, wherein the decoder decodes packets received on the Downlink Packet Data Channel (R-PDCH) in cdma2000. 9. A device for receiving transmission of a hybrid automatic request for retransmission of data (HARQ) in a wireless communication system, comprising: means for decoding a current subpacket received on an ARQ channel to receive a decoded packet or a destroyed packet for an ARQ channel, said current subpacket comprising serial number and identifier; and means for the case if a decoded packet is received for the ARQ channel, to determine whether the decoded packet is a duplicate packet based on the identifier of the current subpacket and the identifier of the last subpacket received for the previous decoded packet received for the ARQ channel. 10. The device according to claim 9, in which the means for determining whether the decoded packet is a duplicate packet, comprises means for determining an unintended identifier for the ARQ channel based on the identifier of the last subpacket received for the previous decoded packet, means for comparing the identifier of the current subpacket with the unspecified identifier, and means for declaring a decoded packet as a duplicate packet, if the identifier of the current subpacket is equal to an unspecified identifier. 11. The device according to claim 10, in which the means for determining the unexpected identifier for the ARQ channel comprise means for assigning the unexpected identifier to the identifier value of the current packet plus one if the decoded packet is received for the ARQ channel, and means for increasing the value of the unexpected identifier by one if for the ARQ channel received packet destroyed. 12. A computer-readable medium containing instructions recorded thereon which, when executed by a computer, causes the computer to implement a duplication detection method for transmitting a hybrid automatic data retransmission request (HARQ), comprising the steps of decoding the current subpacket received on the ARQ channel to obtain a decoded a packet or a destroyed packet for an ARQ channel, wherein said current subpacket contains a sequence number and an identifier, and if the decoded packet is chen for ARQ channel, determining whether the decoded packet is a duplicate packet based on an identifier of the current subpacket and an identifier of the last subpacket received for a prior decoded packet obtained for the ARQ channel. 13. The computer-readable medium of claim 12, further storing instructions for determining an unintended identifier for an ARQ channel based on the identifier of the last subpacket received for the previous decoded packet, comparing the identifier of the current subpacket with the unforeseen identifier, and declaring the decoded packet a duplicate packet if the identifier the current subpacket is an unintended identifier. 14. A method for performing reordering to transmit a hybrid automatic data retransmission request (HARQ), comprising: receiving a decoded packet for an ARQ channel; determining whether an even earlier packet is expected on any of at least one of the other ARQ channels based on decoded packets for at least one other ARQ channel, with each expected earlier packet being a packet that was transmitted before the decoded package and can still be accepted; and redirecting the decoded packet if there are no expected earlier packets. 15. The method of claim 14, further comprising storing the decoded packet, if there is at least one expected earlier packet. 16. The method of claim 14, wherein it is determined whether an even earlier packet is expected on any at least one of the other ARQ channels, comprising, for each at least one other ARQ channel, an indication of the absence of any pending earlier packets, if a decoded packet was received on a different ARQ channel at a specified time or later. 17. The method according to clause 16, further comprising determining a predetermined time based on the start time for the decoded packet and the number of ARQ channels available for HARQ transmission. 18. The method according to 14, in which it is determined whether an even earlier packet is expected on any at least one other ARQ channel, containing for each at least one other ARQ channel an indication of the absence of any expected more early packets if a decoded packet was not received on another ARQ channel within a time window. 19. The method of claim 18, further comprising determining a time window based on the maximum number of subpackets for each packet and the number of ARQ channels available for HARQ transmission. 20. The method according to 14, in which it is determined whether an even earlier packet is expected on any at least one other ARQ channel, comprising determining the last decoding time for each at least one other ARQ channel, determining the earliest the last decoding time for at least one other ARQ channel, and determining whether an even earlier packet is expected on any of the at least one other ARQ channel based on the earliest last decoding time. 21. The method according to claim 20, in which the determination of the last decoding time for each at least one other ARQ channel comprises setting the last decoding time for each at least one other ARQ channel so that it is within the temporal window from the time at which the reception occurs on another ARQ channel. 22. The method according to clause 16, further comprising receiving HARQ transmission through multiple ARQ channels, which include an ARQ channel and at least one other ARQ channel, and many ARQ channels transmit in a predetermined order in time. 23. A device for receiving the transmission of a hybrid automatic request for retransmission of data (HARQ) in a wireless communication system comprising a decoder for providing a decoded packet for an ARQ channel and a controller for determining whether an earlier earlier packet is expected on any at least one other An ARQ channel based on decoded packets for at least one other ARQ channel and forwarding the decoded packet if there are no expected earlier packets for the decoded packet, each The expected expected earlier packet is a packet that was transmitted before the decoded packet and can still be received. 24. The device according to item 23, in which for at least one other ARQ channel, the controller indicates that earlier packets are not expected if a decoded packet was received on the other ARQ channel at a predetermined time or later, and the predetermined time is determined based on the start time for the decoded packet and the number of ARQ channels available for HARQ transmission. 25. The device according to item 23, in which for at least one other ARQ channel, the controller does not indicate that earlier packets are expected if a decoded packet was not received on the other ARQ channel within a time window determined based on the maximum the number of subpackets for each packet; and the number of ARQ channels available for HARQ transmission. 26. The device according to item 23, further containing a buffer for storing a decoded packet, if there is at least one expected earlier packet. 27. The device according to item 23, in which the decoder decodes the packets received on the downlink Packet Data Channel (R-PDCH) in cdma2000. 28. A device for receiving transmission of a hybrid automatic request for retransmission of data (HARQ) in a wireless communication system, comprising means for receiving a decoded packet for an ARQ channel, means for determining if an earlier earlier packet is expected on any at least one other ARQ channel based on the decoded packets, for at least one other ARQ channel, wherein each expected earlier packet is a packet that has been transmitted before the decoded packet and can still be received; and means for redirecting the decoded packet if no earlier packets are expected. 29. The apparatus of claim 28, wherein the means for determining whether an even earlier packet is expected on any at least one other ARQ channel comprising means for indicating that no earlier packets are expected for each of at least one other ARQ channel, if a decoded packet was received on the other ARQ channel at a predetermined time or later, the predetermined time being determined based on the start time for the decoded packet and the number of ARQ channels available for HARQ transmission. 30. The apparatus of claim 28, wherein the means for determining if an even earlier packet is expected on any at least one other ARQ channel, comprising means for indicating that no earlier packets are expected for each at least , one other ARQ channel, if a decoded packet was not received on the other ARQ channel within a time window determined based on the maximum number of subpackets for each packet and the number of ARQ channels available for HARQ transmission.

Images