Data delivery in conjunction with a hybrid automatic retransmission mechanism in CDMA communication systems

Improved data transmission in hybrid automatic retransmission mechanism in CDMA communication system

This application benefits from provisional U.S. application serial number 60/380408, entitled "A Method and Apparatus for Stall Avoidance in a Communication System", filed on May 13, 2002, and is hereby incorporated by reference for all purposes.

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention generally relates to data communication, and in particular, relates to a technology for improving the data transmission performance to a higher layer and a hybrid automatic repeat (HARQ) mechanism in a CDMA communication system.

Background Wireless communication systems are widely used to provide various types of services, such as voice, packet data, and so on. These systems can be multiple-access systems that can support multiple user communications, and can be based on code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), or some other multiple access technology. CDMA systems can provide advantages over other types of systems, including increased system capacity.

In order to improve the reliability of data transmission, some newer generations of CDMA systems use a hybrid automatic repeat (HARQ) mechanism, which can retransmit packets that were incorrectly decoded by the receiver. For example, in W-CDMA version 5, HARQ is included in the medium access control (MAC)-hs sublayer, which resides on top of the physical layer. On the downlink, the HARQ entity at the transmitter processes the data into packets, and these packets are assigned a sequential transmission sequence number (TSN). These packets can then be sent to the receiver in order based on their TSN.

At the receiver end, the corresponding HARQ entity receives the packet transmission and attempts to decode and recover each transmitted packet. However, due to the deterioration of packet transmission caused by the radio link, some packets may not be correctly decoded (ie, erased). When this happens, a negative acknowledgment (NAK) is sent back from the receiver to the transmitter to initiate the retransmission of each erased packet.

The receiver HARQ entity also has the task of providing recovered packets (that is, these correctly decoded packets) to the higher layer. In W-CDMA, higher layers wait for data in the correct order, as determined by the packet's TSN. However, in the HARQ mechanism, the retransmission packet can be recovered out of order by the receiver HARQ entity. The result is that a reordering entity is used at the receiver to buffer and reorder the packets as they are recovered by the receiver HARQ. The reordered entities then provide groupings in the correct order that they are available to higher layers.

If the packets are recovered out of order by the receiver HARQ entity, the reordering entity may "delay" or delay the delivery of the recovered packets to higher layers. In particular, whenever a packet loss is detected, the reordering entity will delay the transmission of data to higher layers until (1) the lost packet is recovered by the receiver HARQ, or (2) the reordering entity is sure that the lost packet has been lost, And it will not be recovered by HARQ. If the second condition is true, you can rely on another retransmission mechanism at a higher layer to retransmit the lost data.

It is challenging to determine the appropriate amount of time to be waited by the reordering entity before declaring that lost packets are lost and providing recovered packets to higher layers. One goal is to avoid delaying the transmission of high-level data, because it is undesirable to wait for a long time or irregularly for lost packets that cannot be recovered. The goal is preferably a short waiting time. The goal of a conflict is to minimize false declarations of lost packets to minimize unnecessary retransmissions with long delays by higher layers (if supported) or packet loss (if higher layers do not implement retransmissions). Long waiting time will provide a better guarantee that the packet is actually lost. This problem is generally called "delay avoidance" in the field.

Therefore, a technique is needed in the field to improve the delay avoidance performance in the CDMA system.

Overview Techniques are provided here to mitigate the effects of lost packets and improve delay avoidance performance. In particular, these techniques can be used to more effectively deal with data that is delayed to higher layers due to loss of payload. These technologies use information available from HARQ processing to better determine whether to transfer data to higher layers.

Various mechanisms are provided here that can be used alone or in combination to improve delay avoidance performance. These mechanisms include (1) the priority transmission of each packet on a control channel instead of packets, (2) maintaining an inactivity timer for each HARQ channel, (3) sending a "flush" one or The flush indication of multiple HARQ channels, which in turn will cause the data to be flushed by the higher layer by the reordering entity, (4) a set of candidate HARQ channels is formed for each lost packet, which can be used for loss The channel of the packet, (5) Determine whether the lost packet is lost based on the detected activity or inactivity on the HARQ channel in the candidate set. These mechanisms are described in detail below.

In an embodiment, a method is provided for sending data recovered by HARQ entities to a higher layer in a correct sequence in a CDMA communication system. According to this method, packets are received from the HARQ entity by the reordering entity, and missing packets in the received packets are detected. The packets may be sent in order based on the transmission sequence number (TSN) assigned to the packet, and the lost packet may be detected based on the TSN of the received packet. Transmission of received packets later than lost packets is delayed due to higher layers expecting sequential data. Thereafter, it is determined whether each lost packet is (1) received from the HARQ entity next, or (2) is lost, by continuously removing the HARQ channel that may be used to transmit the lost packet. The received packet previously delayed for each lost packet is transmitted after the lost packet is determined to be lost or received.

A set of candidate HARQ channels can be formed for each lost packet. The candidate set may include, for example, all HARQ channels that were active (or a short time later) when the packet was detected to be lost. The HARQ channel can be removed from the set if (1) it is inactive for a certain period of time, (2) the packet is recovered from the HARQ channel, (3) a new packet is detected to be sent on the HARQ channel, or (4) An instruction to dump and clear the HARQ channel is received. An inactivity timer can be used for each HARQ channel to determine whether the channel is inactive, and can be restarted whenever a packet transmission is received on that channel.

These technologies can be used in various CDMA systems, such as W-CDMA systems that implement version 5 or later.

Various aspects and embodiments of the present invention are described in more detail hereinafter. The present invention also provides methods, processors, transmitter units, receiver units, base stations, terminals, systems, and other devices and elements for implementing various aspects, embodiments, and features of the present invention, as described in detail below.

Detailed description of the drawings The features, properties and advantages of the present invention will become more apparent through the following detailed description in conjunction with the accompanying drawings. The same symbols in the drawings have the same signs. Among them: Figure 1 is a diagram of a CDMA communication system. Figure 2 is a diagram of the layer structure defined by W-CDMA version 5; Figure 3 is a diagram illustrating the data encapsulation achieved by Node B for high-speed data packet access (HSDPA) transmission on HS-DSCH; Figures 4A and 4B are W -CDMA version 5 is the corresponding definition of the MAC-hs entity diagram on the UTRAN side and the UE side; Figure 5 is a diagram illustrating the timing relationship between the various downlink and uplink physical channels used to implement HSDPA; Figures 6A and 6B are legend illustrations These are the specific priority queue and the window maintained by the receiver's reordering entity; Figures 7A to 7D illustrate four data transmission situations, where various mechanisms rely on the reordering queue to clear data dumps to higher layers;

Figure 8 is a process flow diagram implemented by a transmitter HARQ entity to send packets on a specific HARQ channel; Figures 9A and 9B show a process flow diagram implemented by a receiver HARQ entity to receive packets on a specific HARQ channel; Figure 9C is a receiver The process flow diagram implemented by the HARQ entity is to maintain all inactivity timers for the HARQ channel; Figure 9D is the process flow diagram implemented by the receiver HARQ entity after receiving the dump clear indication on the control message; Figure 10 is the transmitter reordering Figure 11A and 11B show the process flow diagram of the receiver reordering entity for the specific priority queue; Figure 11C shows the process flow diagram when the delay timer timeout indication is received whenever the delay timer expires. A flowchart of an embodiment of a process implemented by the receiver reordering entity.

FIG. 11D shows a flow diagram of an embodiment of a process of implementing complete processing on a specific HARQ by the receiver reordering entity.

Figure 12 shows the overall process flow diagram of the receiver reordering entity receiving packets from the HARQ entity and transmitting the packets to higher layers; and Figure 13 is a block diagram of an embodiment of Node B and UE.

Detailed Description FIG. 1 is a diagram of a CDMA communication system 100 in which the improved delay avoidance technique described herein can be implemented. The system 100 includes multiple base stations 104 that communicate with multiple terminals 106 (only one base station and two terminals are shown in FIG. 1). The base station is also called Node B, Base Transceiver System (BTS), Access Point, or some other terminology. The base station may be part of the UMTS radio access network (UTRAN). A base station and/or its coverage area is generally called a cell, depending on the environment in which the term is used.

The terminal is also called user equipment (UE), mobile station, remote station, access terminal, or some other terminology. Each terminal can communicate with one or more base stations on the downlink and/or uplink at any given moment, depending on whether the terminal is active, or whether it supports soft handover for data transmission, and whether the terminal is in soft handover . The downlink (i.e., forward link) refers to transmission from the base station to the terminal, and the uplink (i.e., reverse link) refers to the transmission from the terminal to the base station.

The techniques described here for improving the delay avoidance performance can be implemented in various CDMA communication systems. Therefore, the CDMA system 100 can implement one or more publicly known CDMA standards, such as W-CDMA, cdma2000, IS-856, IS-95, and others. For clarity, the following describes various aspects, embodiments, and implementation details for improving delay avoidance performance for a CDMA system supporting W-CDMA version 5. Using W-CDMA terminology, the base station, terminal, and system controller in the following description are referred to as Node B, UE, and RNC, respectively.

W-CDMA supports various types of services, such as voice and packet data. In W-CDMA, data to be sent to a specific UE is processed as belonging to one or more transmission channels. These transport channels are then mapped to one or more physical channels (at the physical layer) allocated to the UE. The physical channel is defined by various parameters (such as carrier frequency, scrambling code, channelization code, etc.).

W-CDMA version 5 further supports High Speed Downlink Packet Access (HSDPA), which is a collection of transmission/physical channels and procedures, defined as part of UTRAN that enables high-speed data transmission on the downlink. For HSDPA, data is processed in packets, and these packets are then multiplexed onto the high-speed downlink shared channel (HS-DSCH), which is the downlink transmission channel. The HS-DSCH is then mapped to the high-speed physical downlink shared channel (HS-PDSCH), which can be shared by multiple UEs. For W-CDMA, the transmission time interval of each packet on the HS-PDSCH is 2 milliseconds, which is called the transmission time interval (TTI).

The following transmission and physical channels defined by W-CDMA are referred to herein as: DPCH-dedicated physical channel HS-DSCH-high-speed downlink shared channel HS-SCCH-shared control physical channel for HS-DSCH HS -PDSCH-High-speed physical downlink shared channelHS-DPCCH-High-speed dedicated physical control channel (on the uplink) HS-PDSCH can be used for multiple time division and code division multiplexing (TDM/CDM) Each UE sends data. The HS-PDSCH control information includes various parameters for correctly receiving the HS-PDSCH, and is sent on the relevant HS-SCCH. The HS-DPCCH is used to carry feedback from the UE to report correctly or incorrectly received (ie, erased) packets.

2 is a layer structure diagram defined by the W-CDMA version 5 layer structure 200, including a radio link control (RLC) layer 210, a medium access control (MAC) layer 220, and a physical layer 230. The RLC layer implements automatic retransmission (ARQ) of data and generally resides at the radio network controller (RNC). Retransmission through the RLC layer is generally associated with a long delay due to the long round-trip time between the RNC and the UE. In the RLC layer, data is handled as belonging to a logical channel.

For W-CDMA version 5, the MAC layer is further divided into a MAC-d sublayer 222 and a MAC-hs sublayer 224. The MAC-d sublayer implements a set of functions, including (1) mapping logical channels to public and dedicated transmission channels, (2) multiplexing one or more logical channels onto the transmission channel (C/T MUX), (3) Encryption/decryption, etc. The MAC-d sublayer provides data flows to the MAC-hs sublayer, and each data flow is associated with a certain scheduling attribute.

The MAC-hs sublayer implements specific functions related to HSDPA, as described below. The MAC-hs sublayer further provides an interface between the MAC-h sublayer and the physical layer.

The physical layer provides a mechanism for sending data for the MAC layer and signaling for higher layers.

The various layers and sub-layers of W-CDMA are described in various standard documents, which are publicly available.

Figure 3 is a diagram illustrating the data encapsulation implemented by the Node B for the transmission on the HS-DSCH. In W-CDMA, the data sent on the downlink is provided by the RLC layer in the RLC protocol data unit (RLC PDU), each of which includes a sequence number (SN) and data. The MAC-d sublayer receives RLC PDUs for one or more logical channels, and for each RLC PDU, a (C/T) field is inserted to form a corresponding MAC-d PDU. The C/T field identifies the logical channel associated with the RLC PDU.

The MAC-hs sublayer receives MAC-d PDUs and forms MAC-hs PDUs. For W-CDMA version 5, each MAC-d flow can include data of one or more logical channels in the RLC layer, and each MAC-d PDU can be associated with a specific priority. Since data is sent based on priority and available resources, data with different priorities is stored in different priority queues in the MAC-hs sublayer. Thereafter, the data is obtained from the appropriate priority queue, if necessary, and further processed for transmission on the HS-DSCH.

In order to form a MAC-hs PDU, the MAC-hs sublayer first receives and serially links one or more MAC-d PDUs from a specific priority queue to form a payload for the MAC-hs PDU. Stuffing bits can be added as necessary to fill the payload. The MAC-hs sublayer then adds a header to the payload to form a MAC-hs PDU.

For W-CDMA version 5, the MAC-hs header includes (1) a size index ID (SID) field indicating the length of each MAC-d PDU in the MAC-hs PDU, and (2) indicating the information included in the MAC-hs PDU The N field of the number of MAC-d PDUs, (3) the transmission sequence number (TSN) allocated and used to uniquely identify the MAC-hs PDU, and (4) the queue ID (QID) field indicating a specific priority queue, obtained from the queue MAC-d PDU included in MAC-hs PDU. The TSN allows the UE to identify the recovered MAC-hs PDU and is used to provide the MAC-d PDU to the RLC layer in order, which expects data to be sent to it in the correct order. W-CDMA also provides a mechanism to send MAC-hs PDUs of different sizes in the same packet, but this is not described here for simplicity.

MAC-hs PDU is generated when needed during operation. Each MAC-hs PDU is sent within a TTI of 2 milliseconds, which is a transmission unit on the HS-DSCH. For brevity, the MAC-hs PDU is referred to herein as "packet".

The control information is sent forward with each packet transmission on the shared HS-SCCH. The control information includes (1) HARQ process ID (HID), (2) new data indicator, (3) information, identification control information and the specific IE to which the corresponding data is transmitted, and (4) other information is not described here. HID indicates a specific HARQ process used for grouping. Each packet can be sent and may be retransmitted one or more times until (1) UTRAN receives ACK feedback on the HS-DPCCH of the packet, or (2) the transmitter decides to abandon the packet transmission. Each packet is associated with a specific HARQ process, which is an example of a stop and wait (SAW) protocol used to control the transmission/retransmission of the packet. Since three bits are defined for HID, there may be eight packet processing pending at any given moment. The eight HARQ processes can therefore be regarded as eight "HARQ channels", which can be used to send packets, and each HARQ channel is associated with and identified by a specific HID value.

The new data indicator is used to indicate a new packet transmission on a specific HARQ channel. In order to improve decoding performance, the UE generally (soft) combines all received transmissions of the same packet before decoding. The new data indicator informs the UE that the current transmission is for a new packet, and all previously received transmissions for the same HARQ channel (for previous packets) should be cleared. The new data indicator is a single bit value, which is flipped between "0" and "1" for consecutive packets sent on the same HARQ channel, but actually a 1-bit sequence number for packets sent on the HARQ channel. The UE can therefore detect new data by observing the rollover of the new data indicator. The new data indicator is also referred to herein as the "color" bit.

FIG. 4A is a diagram of the MAC-hs entity 224a defined for the UTRAN side in W-CDMA version 5. In UTRAN, there is a MAC-hs entity for each cell that supports HS-DSCH transmission. The MAC-hs entity processes the data sent on the HS-DSCH and further manages physical resource allocation for HSDPA.

The UTRAN MAC-hs entity includes a scheduling/priority processing entity 410, a HARQ entity 420, and an FTRC entity 430. The scheduling/priority processing entity manages the data flow from the MAC-d entity according to its priority, determines the TSN and priority queue for each packet to be processed, and determines the transmission/retransmission of the packet. The data stream from the MAC-d entity may include data with different priorities, which may then be located in different priority queues. The data will then be obtained from the appropriate priority queue based on priority and resource availability, and further processed for transmission/retransmission on the HS-DSCH.

One HARQ entity provides the function of processing HARQ for each UE. The HARQ entity implements packet transmission and (if necessary) retransmission to ensure reliable transmission of these packets to the UE. The retransmission of the packet is based on the feedback from the UE. The feedback is in the form of acknowledgment (ACK) to indicate the successful decoding of the packet or in the form of negative acknowledgment (NACK) to indicate the unsuccessful decoding of the packet.

The TFRC entity selects the appropriate transmission format and resources for the data to be sent on the HS-DSCH.

FIG. 4B is a MAC-hs entity 224b defined for the UE side in W-CDMA version 5. The MAC-hs entity handles HSDPA specific functions and includes a HARQ entity 440, a reordering queue distribution entity 450, a set of reordering buffers 462, a reordering entity 464, and a disassembly and assembly entity 466 for each queue ID configured at the UE. Therefore, a reordering buffer is provided and associated with each priority queue for the UE.

The UE HARQ entity handles all tasks required by HARQ (for example, generating required ACK/NAK for each received packet transmission). The reordering queue distribution entity provides the recovered packet to the appropriate reordering buffer based on the queue ID sent for the packet.

The recording entity of each reordering buffer reorders the recovered packets in the buffer according to the TSN assigned to each packet. Each priority queue is related to its own TSN sequence. The reordering entity then provides the packet with consecutive TSNs to the disassembly entity when it is restored. If a packet with a lower TSN is lost, the packet is not sent to the disassembly entity (ie "delay").

The disassembly entity pair associated with each reordering buffer provides the group disassembly and assembly to it. Disassembly is achieved by removing the header in each packet to obtain the MAC-hs payload (see Figure 3), extracting the MAC-d PDU included in the MAC-hs payload, and discarding the padding bits (if Have). The disassembly entity then provides the MAC-d PDU to the higher layer through the MAC-d sublayer.

W-CDMA version 5 allows multiple reordering entities and multiple HARQ processes (or HARQ channels) to operate aggressively. Each reordering entity processes data for a specific priority queue and uses a reordering buffer for that task. Therefore, there is a one-to-one correspondence between the reordering queue, priority queue, and reordering buffer. The HARQ channel is a standard stop and wait entity, and each HARQ channel can carry data (or reorder buffer) to any priority queue.

Figure 5 illustrates the timing relationship between various downlink and uplink physical channels used to implement HSDPA. The timing relationship shown in FIG. 5 is used to specify a specific UE that receives HSDPA transmission.

The uplink DPCCH is used by the UE to send signaling for the uplink DPCH. The timing of the uplink DPCCH is used as a reference, and the timing of other physical channels is provided relative to the timing of the uplink DPCCH.

As shown in FIG. 5, the packet is sent to the UE in the subframe 512 on the HS-DPSCH. Each subframe occupies a millisecond slot. The subframe 512 starts to occur some time after time T1, which is the start of the time slot of the uplink DPCCH. The packet is sent to the designated UE, which receives and attempts to recover the packet. Based on the result of the decoding process, the UE reports back one of the following: (1) ACK indicates that the packet was received correctly, (2) NAK indicates that the packet was received in error (that is, erased), or (3) if it fails to detect ( Lost) the corresponding HS-SCCH, there is nothing (ie discontinuous transmission (DTX) bits). The feedback information is sent from the IE in the designated subframe 514 on the uplink HS-DPCCH. The subframe starts at time T2, which is defined as 7.5 time slots plus the delay τx from the end of the corresponding subframe 512 (this is a value between 0 and 255 chips). The delay τx is defined such that the elapsed time τy between the start of the time slot on the uplink DPCCH (T1) and the start of the subframe 514 on the uplink HS-DPCCH (T2) is 256×m, where m is an integer.

The HSDPA design assumptions for the transmission of control information on the downlink HS-SCCH and uplink HS-DPCCH are as follows: HS-SCCH (downlink) Probability {lost HS-SCCH}10-2 Probability {false alarm} 10-4HS-DPCCH (uplink) Probability {ACKNAK}10-2 Probability {NAKACK}10-4 Probability {DTXACK}10-2 On the HS-SCCH, (1) the probability of losing control messages accompanying packet processing needs to be less than or equal to 10-2, and (2) the probability of a control message sent to one UE being erroneously detected as being sent to another UE needs to be less than or equal to 10-4. For the uplink HS-DPCCH, (1) The probability that the ACK sent by the UE is received by the Node B as a NAK needs to be less than or equal to 10-2 (2) The probability that the NAK sent by the UE is received by the Node B as an ACK needs to be less than Or equal to 10-4, and (3) The probability that the DTX bit sent by the UE is received by the Node B as an ACK needs to be less than or equal to 10-2.

Under some channel conditions, especially when the serving Node B of a particular UE is not a node with the best link condition (as it often happens when the HSDPA is slowly switched from one Node B to another), it may be difficult to obtain The aforementioned ACK/NAK probability.

The NAK to ACK error of a given packet causes the transmitter to assume that the packet has been correctly recovered by the receiver. The transmitter can then discard the packet and start the transmission of another packet on the same HARQ. Therefore, NAK to ACK errors cause loss of packets at the MAC layer. The higher probability of NAK to ACK errors corresponds to a higher incidence of packet loss at the MAC layer. This in turn leads to the reordering entities required at the RLC layer and a higher probability of delay caused by more retransmissions.

The MAC layer needs to ensure that data is sent to higher layers in order. Since the HARQ mechanism using multiple HARQ channels may cause data to be recovered out of order by the UE, in W-CDMA version 5, a reordering sublayer is added to the MAC layer. The reordering sublayer buffers packets when it is restored, rearranges these packets, and transmits consecutive packets to higher layers (as determined by its TSN). If the reordering sublayer detects a lost packet based on a gap or hole in the TSN of the recovered packet, it delays (ie delays) the transmission of all TSN packets later than the TSN of the earliest lost packet. When the lost packets are finally recovered, the reordering sublayers then provide these newly recovered packets and any previous recovered packets that have been delayed.

W-CDMA version 5 provides three "delay avoidance" mechanisms to allow actual implementation and avoid the situation where the reordering entity is always waiting for data that is not retransmitted. These delay avoidance mechanisms include: Window-based scheme Timer-based scheme HARQ activity scheme Each of these schemes is briefly described below.

Based on the window scheme, since each packet is marked with a specific TSN, the restored packets can be assembled in the correct order at the UE. Although the packets may be sent in order by Node B at the beginning, these packets may be restored out of order because a variable number of retransmissions may be required for each packet.

Figure 6A is a graphical illustration of a window maintained for a specific priority queue. The data of the priority queue is sent in a packet, and the packet is identified by a 6-bit TSN. The TSN number space is 26=64 (that is, from 0 to 63). In order to solve the ambiguity of the TSN number space caused by the limited size of the TSN field, the receiver can use a window. The size of the window is generally set at less than half of the TSN number space (ie, <32), and can be set as small as 8-16. Since the window size is smaller than the TSN number space, there is no ambiguity about the grouping order in the window. There is a trade-off in determining the window size. If the window is small, the delay avoidance performance at the receiver increases and the receiver buffer size requirement is reduced. However, the probability of delay at the transmitter or the need to interrupt retransmission (depending on the transmission strategy) increases.

The window advances as new packets are received. For the receiver, the leading edge of the window can be set equal to the "nearest" TSN of all recovered packets. The packets near the leftmost side of the window have consecutive "earlier" TSNs. Since the TSN value can be rolled back, whenever the TSN is rolled back, the latest TSN value can actually be smaller than the earlier TSN. Lost packets with TSN earlier than the dragging edge of the window are assumed to be lost (that is, not retransmitted). Therefore, as the window advances, packets earlier than the edge of the dragged window are "dumped and cleared" and sent to higher layers.

The window mechanism can therefore be used by the transmitter to dump and clear lost packets at the receiver. However, since the size of the window may need to be large enough to allow a larger number of retransmissions, a larger number of data dumps are required to clear out lost packets. Therefore, the window-based scheme is marginally effective at the end of the data burst, which is more frequent in the case of burst closed-loop traffic generated by browsing.

In order to solve the limitation of the window-based scheme, the timer-based scheme is also introduced in W-CDMA version 5. For the timer-based scheme, whenever a lost packet delays the transmission of a packet to a higher layer at the receiver, a "long" timer is started. If no other lost packets are detected thereafter, once the long timer expires, the lost packets are assumed to have been recovered, and all packets delayed by the lost packets are then sent to higher layers. This mechanism requires a long timer to be maintained for each reordering queue (that is, there are a maximum of eight long timers for the eight reordering queues defined in W-CDMA version 5).

In order to ensure proper HARQ operation, the long timer needs to be set to be longer than the maximum amount of time it takes to complete all retransmissions for a given packet. It may be necessary to implement a large number of retransmissions to recover lost packets. Moreover, in an asynchronous scheduling retransmission system, the amount of resources available for HSDPA (such as channelization code and transmit power quantization) will dynamically change, and the time required to complete all retransmissions of lost packets can vary greatly. Therefore, the timer value needs to be very long. Otherwise, the retransmission of the lost packet may be aborted prematurely because the timer expires. In this case, the lost packet will need to be retransmitted by a higher layer, which is undesirable. The reordering entity may need to wait a long time for the long timer to expire until all retransmissions of the lost payload are completed.

In addition to processing the larger value of the long timer, if several packets in the window are detected as lost, the timers of these lost packets are effectively concatenated (that is, the long timer restarts whenever a new lost packet is detected) . This can lead to even longer delays in the transmission of the lost payload to higher layers (the longest possible delay may be twice the worst-case long timer value).

HARQ activity scheme The third scheme to avoid delayed recovery of packets sent to higher layers is to detect activity on the HARQ channel. When no packet is expected on any HARQ channel (that is, all previous packet processing is completed), all data in the reordering queue can be transmitted to the higher layer by the reordering entity. This mechanism has several disadvantages. First, this solution requires no pending packet processing on any HARQ channel to be able to dump clear packets to higher layers. Second, the receiver "partitions" the HARQ channel only when the packet processing on the channel is completed. Since the receiver can always wait for the packet to be recovered on a given HARQ channel (for example, if the transmitter abandons packet processing), the reordering queue will never be dumped and cleared. Third, if the control message is lost (that is, it is not detected by the receiver), if it is subsequently recovered, the packet associated with the control message may be discarded by the reordering entity. This is the case if another packet with a later TSN is recovered and provided to the reordering entity before the packet with the lost control message is retransmitted and the control channel is successfully decoded.

Here are some techniques to mitigate the effects of packet loss and improve delay avoidance performance. In particular, these techniques can be used to more effectively deal with situations where data transmission to the higher MAC-hs sublayer is delayed due to loss of payload. These techniques use information available from the HARQ process to better determine whether to send data to higher layers.

The following mechanisms can be used to improve delay avoidance performance: Send queue ID on HS-SCCH instead of payload Maintain inactivity timer for each HARQ channel Send a dump clear indication to "dump clear" one or Multiple HARQ channels, which in turn will cause the data to be dumped to higher layers for the reordering entity. Form a set of candidate HARQ channels for each lost packet. These are the channels that can be used to send the lost packets. The delay timer can be used for candidate set formation.

Detect activity on the HARQ channel to determine whether lost packets are lost. Each of these mechanisms is described in detail below.

The following terms are used in the following description: Packet processing-transmission of a specific packet on a specific HARQ channel and zero and multiple retransmissions.

Pending processing-packet processing, where the packet expects one or more additional retransmissions.

Completion processing-packet processing, where the packet does not expect any additional retransmissions.

Lost packet-a packet that has not been recovered by the receiver, and the TSN is earlier than the TSN of another recovered packet (the lost packet may still be in the process of being retransmitted and may have been discarded by the transmitter).

Recovered packet-a packet correctly decoded by the receiver.

Packet received-this term has two meanings, depending on which entity it refers to. For HARQ entities: packet transmission received on a specific HARQ channel, which may or may not be decoded correctly. For the HARQ entity: the recovered packet is received from the HARQ entity but has not been transmitted to the higher layer.

Active HARQ channel-a type of HARQ channel in which packet processing is pending and the next transmission received on the channel is applied to the retransmission of the current packet.

Inactive HARQ channel-a type of HARQ channel in which packet processing is completed and the next transmission received on the channel is applied to a new packet.

Candidate HARQ channel-HARQ channel that can be used to transmit packets that are detected to be lost.

The queue ID on the control channel is sent in W-CDMA version 5. The queue ID that identifies the specific priority queue for the packet is sent as the header part of the packet (see Figure 3). Therefore, the priority queue to which the packet payload belongs can only be determined after the packet has been restored. As a result, it is impossible to determine the priority queue associated with each lost packet because the packet is not recovered.

If the packet is lost and the priority queue it belongs to cannot be determined, the data transmission can be delayed for all reordering entities. This will deteriorate performance.

In one aspect, the priority queue of each packet is sent along with the packet transmission on the control message. The queue ID field can be included in the control message, as shown by the dashed box in FIG. 3. By sending the queue ID on the control channel, it is possible to identify the priority queue for each packet, for which the control message related to the packet is correctly detected by the receiver, regardless of whether the packet itself is decoded correctly or incorrectly. The information identifying the priority queue for each such group can be used together with other mechanisms described below to further improve the delay avoidance performance. For example, when used in conjunction with the mechanism described below, by identifying a priority queue for each such packet, it may be determined that it can be dumped to a higher priority queue. In this way, each such group only affects the reordering entities related to the priority queue of the group and not other reordering entities. Therefore, the delay avoidance performance can be improved.

HARQ channel inactivity timer Each HARQ channel can be used to send a packet at any time. The packet is sent on the HARQ channel and may be retransmitted one or more times until (1) the transmitter receives an ACK for the packet, or (2) the transmitter abandons the transmission of the packet. In any case, the transmitter can then send a new packet on the same HARQ channel, and will indicate this point by triggering a new data indicator.

At the receiver, packet processing on a specific HARQ channel is considered pending until (1) the packet is correctly received from the HARQ channel by the receiver, or (2) the receiver detects a new packet transmission on the HARQ channel (based on control The new data indicator in the channel), because the transmitter does not send a new packet until it determines to stop the transmission of the previous packet.

At the receiver, the new data will "dump and clear" the pending data in the receiver window, which may be discarded by the transmitter for one or other reasons. For example, if no more data is sent for priority queue A, but new data is still sent for priority queue B, the data of priority queue B can be sent on the same HARQ channel previously used for priority queue A. In this case, the data of priority queue B will effectively "overwrite" the data of priority queue A. The inversion of the new data indicator for each HARQ channel will allow the receiver to determine when the priority packet will be discarded by the transmitter.

However, if there is no more data to send, there may not be any activity on any HARQ channel. Without new activity, it is impossible for the UE to determine whether a given packet is dropped by the network or a packet retransmission is coming. For each HARQ channel that is waiting for packets that have been discarded by the transmitter and no new packets are sent, the reordering entity associated with the HARQ channel must wait until the long timer maintained for the reordering queue expires before making available The data is transferred to higher layers. The HARQ process itself will permanently wait for the transmission of a new packet or the retransmission of the current packet on the HARQ channel.

On the other hand, an "inactive" timer can be maintained for each active HARQ channel to avoid the situation where the HARQ entity waits forever for retransmission of packets that have been discarded by the transmitter. In an embodiment, the inactivity timer monitors the inactivity on the HARQ channel based on the control message received on the control channel of the HARQ channel. In one implementation, each time a new control message is received on the control channel for a specific active HARQ channel, the inactivity timer for that channel is restarted. If the inactivity timer expires before another new control message is received on the HARQ channel, the channel is considered inactive.

The main advantage of using an inactivity timer for each HARQ channel is that it does not need to be as long as the timer used for each reordering buffer. This is because the inactivity timer only needs to cover the maximum amount of time expected to receive control messages for the active HARQ channel (or two control messages, for the case if the first one is lost). Since the loss probability of the control channel is on the order of 10-2, the probability of successively losing two control channel transmissions is on the order of 10-4. Therefore, if the timer is set to the maximum time required to achieve two retransmissions, the probability of erroneously discarding packets still to be sent will be roughly the same as the expected probability of NAK to ACK error, which is expected because of this Both have the same effect. In contrast, long timers need to be long enough to handle the maximum number of retransmissions for lost packets (and not just two control message transmissions).

The locally variable CurrNewData can be maintained for each HARQ channel and set to the new data indicator received in the most recent transmission on the channel. If the HARQ channel is considered inactive, the next transmission on the channel is expected to be a new packet, in which case the new data indicator of the transmission will be different from the CurrNewData value. However, if the newly transmitted new data indicator is the same as the CurrNewData value, it can be assumed that the same packet was sent (for example due to an ACK to NAK error), in which case the transmission can be discarded and the ACK can be sent back to the transmission machine.

Dumping the clear indication for the HARQ channel On the other hand, the dump clearing can only be sent on the control channel and used to guide the HARQ entity to dump and clear one or more HARQ channels at the UE. Dumping the cleared HARQ channel indicates that the pending processing on the channel is completed. The reordering entity waiting on the HARQ channel can then implement appropriate behavior based on this information, as described below.

Various dump clear indications can be sent to the UE in various ways. For example, the flushing instruction can be sent in the control message using the reserved value in the field, the field being used to indicate the code set or the size of the transmission module. If the UE receives the dump clear indication, it will not attempt to decode the packet. The reason is as follows. Each HARQ channel cleared by the dump can then be put into an inactive state to indicate that additional retransmissions are not expected to be received on that channel.

One or more HARQ channels can be flushed based on a single flushing instruction. In the first embodiment, the dump clear instruction only dumps and clears the specific HARQ channel sent, which can be identified by the HID field in the control message. For this embodiment, if multiple HARQ channels are to be dumped and cleared, multiple dump clearing indications may be sent. In the second embodiment, the dump clear instruction dump clears all HARQ channels. This embodiment reduces the number of transfers of the dump clear indication. However, the availability of the dump clear indication will also be reduced to the case where no data needs to be sent on any HARQ channel for any reordering queue. In the third embodiment, the dump clear instruction dump clears all HARQ channels that are expected data for a specific priority queue, and the queue may be indicated in the queue ID field included in the same control message used to send the dump clear instruction . This embodiment can be used to dump and clear all HARQ for a specific priority queue after all data transmissions in the traffic burst of the priority queue are completed.

The transmission of the dump clear indication does not require many resources and can be used to suspend the inactivity timer maintained for a specific HARQ channel early. Generally, the system knows which UE has an increased risk of losing packets in its reordering buffer. For example, a UE with a better uplink to the cell than to the serving cell or a high frame error rate (FER) on the DPCH is more likely to have lost packets. For these UEs, the dump clear indication can be sent after the traffic burst transmission of each priority queue is completed.

Activity detection/delay timer of lost packets on HARQ channel If the first transmission based on its TSN packet occurs in sequence, the lost packet can be identified by the TSN of the recovered packet. In particular, if another packet with a later TSN is recovered first, the packet can be considered as lost. (Later TSN may be less than the previous TSN, when the TSN value is rolled back). In this case, the lost packet with the earlier TSN can be assumed to be in transmission.

At the moment when the packet is detected to be lost, a set of candidate HARQ channels on which the lost packet can be transmitted can be identified. Thereafter, the activity on the candidate HARQ channels can be monitored to determine whether any of these channels is the one used to transmit lost packets. Candidate HARQ channels may be continuously removed from the set, as described below. If all candidate HARQ channels are removed and the set is empty, the lost packet is considered to be lost. It is then up to the reordering entity to take the appropriate action.

The HARQ channels included in the candidate set may be selected in a variety of ways, which may depend on the available information. In the first embodiment, the candidate set is formed after detecting the lost packet, and includes all HARQ channels that can be used for packet transmission, except for the HARQ channel for the recovered packet that is used to detect the lost packet.

In the second embodiment, when a lost packet is detected, the candidate set of the lost packet is defined to include all active HARQ channels. At this time, if at least one control message for the lost packet is received, the snapshot of the candidate HARQ channel will be accurate, because the control message will put the HARQ channel corresponding to the lost packet into the active state, and the channel will then be included in the lost Within the grouped candidate set.

However, if all the control messages of the HARQ channel used to transmit the lost packet are lost by the receiver, the snapshot will not be accurate. For example, if the control message of the first transmission of the packet P1 sent on the HARQ channel H1 is lost, the channel will remain in an inactive state. Thereafter, if another packet P2 of the same priority queue is transmitted on another HARQ channel and is correctly decoded (before the packet P1 is retransmitted on the HARQ channel H1), the packet P1 will be detected as lost. However, the candidate set will not include HARQ channel H1 because it is inactive when the set snapshot is taken after packet P2 is restored. The probability of these times occurring may be very low, and the effect will be that the packet P1 is discarded by the reordering entity when it is finally restored.

In the third embodiment, it avoids the problems described above, and forms a candidate set of lost packets some time after the lost packets are detected. The delay is chosen to be long enough to ensure that at least one control message is received for the lost packet before forming a candidate set for the lost packet. The "delay" timer (denoted here as TM2) can be used to track the amount of time to wait before taking a snapshot of the candidate set.

Based on the specified reliability of the control channel, namely 10-2, the delay timer will only need to be long enough to receive an additional control message transmission. If a delay timer is used, the receiver will actually need to lose two consecutive control message transmissions to form an inaccurate candidate set, thus losing packets. Based on the loss probability of the control channel 10-2, two consecutive control channel loss will occur with a probability of 10-4, which is considered acceptable. A longer value for the delay timer will degrade performance, rather than affecting the underlying solution.

In the fourth embodiment, the candidate set is formed for each lost packet when the lost packet is detected, and will include all HARQ channels, except for the HARQ channel used for the recovery packet in which the lost packet is detected (as in the first embodiment) . However, the delay timer is also started. If it is then determined that the channel cannot be used to transmit the lost packet, the candidate HARQ channel in the set can be removed thereafter. When the delay timer expires, the candidate set is modified, and all HARQ channels that are inactive at this time are removed from the set. The modified candidate set is a subset of the initial candidate set. For the fourth embodiment, the delay timer is used to acquire the HARQ channel, for which all control messages were previously lost by the receiver, which is similar to the above-mentioned third embodiment. However, the operation of the delay timer does not affect or hinder the removal of HARQ channels from the initially formed candidate set (for example, HARQ channels for which packets with a later TSN have been restored).

For the embodiment using a delay timer, the timer can be implemented in various ways, as described in detail below.

If the queue ID is also sent on the control channel, and at least one control message is received for the lost packet, the candidate set of the lost packet will only need to include the HARQ channel for the priority queue. Since the number of candidate HARQ channels can be reduced, performance can be enhanced.

The delay timer and dump clear indication mechanism can help the HARQ channel to enter an inactive state when the candidate set is formed. For example, the inactivity timer of a given HARQ channel may elapse when the delay timer is active, in which case the HARQ channel will not be included in the candidate set. These mechanisms therefore limit the set of candidate HARQ channels, which can improve the performance of the delay avoidance mechanism.

For all embodiments used to form candidate sets for lost packets, if it is then determined that they cannot be used to transmit lost packets, the candidate HARQ channels are removed from the set thereafter. In particular, if the pending processing on the channel is completed, the candidate HARQ channel is removed from the set.

In an embodiment, if any of the following conditions occur, the packet processing on the HARQ channel is considered complete: (1) the packet is recovered from the HARQ channel, (2) the HARQ channel is active, and a new packet is detected Until it is sent on the channel, (3) the inactivity timer of the HARQ channel expires, or (4) the dump clear indication is received for the HARQ channel. Condition (1) results in the recovery of the lost packet, or the recovery of the packet is later than the lost packet. Condition (2) can be detected by observing the new data indicator change, and can occur, for example, if the transmitter decides to abandon the previous packet and send a new packet on the HARQ channel. Conditions (1) and (2) also assume that the initial transmission is always implemented in order, and that new packets are not sent on the same HARQ channel before the pending processing is completed.

For a given lost packet, if any of the above four conditions occurs, each HARQ channel in the associated candidate set can be removed. When the candidate set is empty, the lost packet hypothesis is lost (that is, it will not be recovered by the receiver). Appropriate actions can be implemented. For example, all delayed recovered packets due to the lost packet can now be sent to higher layers.

As mentioned above, the queue ID transmission on the control channel can be used in conjunction with the other mechanisms mentioned above to improve performance. In particular, the queue ID on the control channel can (1) reduce the number of candidate HARQ channels for lost packets, (2) allow possible adaptation of the inactivity timer to the priority queue, and (3) allow the use of dump clear indications, Even when other reordering entities are in transit.

In the following description, a candidate set is formed after the delay timer expires, and the timer starts when a lost packet is detected.

Example transmissions The various mechanisms described above to improve delay avoidance are described below for some example transmissions. For these examples, the NAK/ACK feedback on the HS-DPCCH is shown to be aligned with the packet transmission time associated with it (for simplicity). The "sent" feedback values are those sent by the UE on the uplink, and the "received" feedback values are those detected by the Node B. The first transmission of the packet is based on the TSN of the packet in order. Therefore, the lost packet can be determined based on the TSN of the packet recovered by the UE.

In the following example, the delay timer (TM2) is set when the packet is detected to be lost. The set of candidate HARQ channels for lost packets is determined after the delay timer expires.

Figure 7A illustrates that the control channel is received and relies on the new data indicator in the control message to flush data from the reordering queue to a higher level.

At time T1, the packet was received on HARQ channel H1, but was not decoded correctly. For this packet transmission, the receiver sends NAK feedback, which is incorrectly received by the transmitter as an ACK. The state of the HARQ channel H1 is set to active, and the HARQ entity restarts the inactivity timer (TM1) for this channel.

At time T2, a packet with TSNx is received on HARQ channel H2 and decoded correctly, and ACK feedback is sent for the packet transmission. The state of HARQ channel H2 is set to inactive. The recovered packet is then sent to the reordering entity for the priority queue of the packet. The reordering entity can detect the loss of a packet with TSNx-1 based on the TSNx of the packet it just received. Then start a delay timer (TM2) for lost packets. The recovery packet with TSNx is delayed due to the loss of the packet.

At time T3, a packet was received on HARQ channel H3, but was not decoded correctly, and NAK feedback was sent for the packet transmission. The state of HARQ channel H3 is set to active, and the HARQ entity restarts the inactivity timer for this channel.

At time T4, the delay timer for the lost packet expires, and the set of candidate HARQ channels for the lost packet is determined. The candidate set of lost packets includes all HARQ channels that are active when the delay timer expires and can be used to transmit lost packets. The candidate set therefore includes H1 and H3.

At time T5, a packet with TSNx+1 is received on HARQ channel H3 and decoded correctly, and ACK feedback is sent for the packet transmission. The HARQ channel H3 state is set to inactive, and the HARQ entity restarts the inactivity timer for this channel. The recovered packet with TSNx+1 is delayed due to the lost packet. Since the packet processing of HARQ channel H3 is completed for packets later than lost packets, this channel may not be a channel for transmitting lost packets. H3 is therefore removed from the candidate set, which now only includes H1.

At time T6, a new packet is received on HARQ channel H1, and the new data indicator rolls over from D0 to D1. The new packet is sent by the transmitter on this channel because it erroneously received the ACK of the previous packet transmission at time T1. This change in the new data indicator means that the pending packet processing on HARQ channel H1 is completed, and the lost packet will not be sent on this channel. H1 is therefore removed from the candidate set, which is now empty. The two delayed packets with TSNx and TSNx+1 are then sent to the higher layer.

Figure 7B illustrates a situation where the control channel is received and the inactivity timer (TM1) is used to dump data from the reordering queue to a higher layer. The packet transmission in FIG. 7B is similar to that shown in FIG. 7A, except that the packet transmission is not received at time T6. At time T7, the inactivity timer of HARQ channel H1 expires. This indicates that it is not expected to receive lost packets on this channel. H1 is therefore removed from the candidate set and the set becomes empty. The two delayed packets with TSNx and TSNx+1 are then sent to the higher layer.

Figure 7C illustrates a situation in which a control channel is received and a dump clear indication sent on the control channel is relied upon to dump data from the reordering queue to a higher layer. The packet transmission in FIG. 7C is similar to that shown in FIG. 7A, except that a dump clear indication is received at time T6 (instead of a packet transmission). For this example, the dump clear indication covers all HARQ channels used for the priority queue identified in the control message. H1 and H3 will be dumped and cleared because they are used to identify the priority queue. The candidate set of lost packets will then be empty. The delayed packets with TSNx and TSNx+1 are then sent to higher layers.

Figure 7D illustrates a situation where the control channel is not received and the DTX to NAK error is received by the transmitter. Fig. 7D also shows a situation in which the use of a delay timer enables the correct determination of the candidate set for a lost packet, otherwise the packet will be lost.

At time T1, the packet is sent on HARQ channel H1, but the control channel is not received (ie, lost). The receiver does not know the existence of the packet transmission, and sends DTX (that is, without feedback), which is incorrectly received by the transmitter as a NAK. Since the receiver does not know the packet transmission, the HARQ channel H1 state remains set to inactive, and the inactivity timer of the channel is not restarted.

At time T2, the packet with TSNx is received on HARQ channel H2 and decoded correctly, and ACK feedback is sent for the packet transmission. The state of the HARQ channel H2 is set to inactive, and the inactivity timer of the channel is restarted (not shown in FIG. 7D). The recovered packet is then sent to the reordering entity for the priority queue of the packet. The reordering entity can detect the packet loss of TSNx-1 based on the TSNx of the packet it just received. Then start a delay timer for lost packets.

At time T3, a packet retransmission is received on HARQ channel H1 for the NAK detected by the transmitter at time T1. The packet was not decoded correctly, and a NAK feedback was sent for the packet transmission. The HARQ channel H1 state is set to active, and the HARQ entity restarts the inactivity timer for this channel (not shown in FIG. 7D).

At time T4, a new packet with TSNx+1 is received on HARQ channel H2, and the new data indicator changes to a new value (that is, from D0 to D1). The packet is decoded correctly, and ACK feedback is sent for the packet transmission. The state of HARQ channel H2 is set to inactive, and the HARQ entity cancels the inactivity timer for this channel.

At time T5, the delay timer for lost packets expires. At this point, there is an active HARQ channel H1. The candidate set then only includes HARQ channel H1.

As shown in this example, the use of a delay timer enables the determination of the correct candidate set for the lost packet. Without the delay timer, the candidate set will be an empty set because the control message of the packet with TSNx-1 at time T1 is lost. In the case of a delay timer, the second transmission within the delay timer window enables the HARQ channel H1 to be included in the candidate set.

At time T6, the lost packet with TSNx-1 is received on HARQ channel H1 and decoded correctly, and ACK feedback is sent for the packet transmission. The packet with TSNx-1 and TSNx is then sent to the higher layer .

At time T7, a packet retransmission is received on HARQ channel H2 for a packet with TSNx+1, which was NAKed at time T4. The packet is correctly decoded and sent to higher layers by the reordering entity. ACK feedback is also sent for this packet.

Specific Implementation For clarity, the following describes a specific implementation of the processing performed by the HARQ entity and the reordering entity at the transmitter and receiver. This implementation maintains a delay timer for lost packets so that a more accurate candidate set can be formed for lost packets. However, the delay timer is not as strictly necessary as described above. If the delay timer is not used, the generation behavior is equivalent to setting the delay timer to 0.

In the following implementation, it is assumed that the queue ID is sent on the control channel, and the priority queue of a given packet is unknown to the HARQ entity until the packet is correctly decoded. In this case, when the packet processing is completed, the HARQ entity notifies all reordering entities, because the lost packet may be for any priority queue. Moreover, when the delay timer expires, the reordering entity does not know which HARQ channel carries its data, and therefore includes all active HARQ channels in the candidate set for the lost packet.

Transmitter HARQ FIG. 8 is a flow diagram of an embodiment of processing 800 implemented by a transmitter HARQ entity for sending packets on a specific HARQ channel. For this embodiment, the locally variable NewData is maintained for each HARQ channel. This variable is flipped for the first transmission of a new packet when the payload to be sent changes. The variable is initialized to "1".

At the beginning, it is determined whether there is a packet to be sent (step 812). If the answer is no, the process proceeds to step 822. Otherwise, it is determined whether this is the first transmission of the packet (step 814). If the answer is also yes, the NewData variable is inverted (that is, the first new packet is set to "0"), and the new data indicator in the control message of the packet is also inverted because it is set to the NewData value (Step 816). Otherwise, if the packet is sent, step 816 is skipped, and the NewData variable is not flipped. The queue ID in the control message of the packet (if it is sent there) is set to the priority queue of the packet to be sent (step 818). The packet and control messages (this includes HID, queue ID, new data indicator, etc.) are then forwarded to the physical layer for transmission (step 820).

In step 822, it is determined whether an ACK (if any) of the current packet transmission is received from the UE on the HARQ channel. If the answer is yes, the current packet being sent on the channel is discarded (step 824), and the scheduler is notified that the HARQ channel is available for sending to another packet (step 826). After step 826, or if no ACK is received in step 822, the process returns to step 812.

Receiver HARQ FIGS. 9A and 9B show an embodiment flow diagram of a process 900 of receiving packets on a specific HARQ channel implemented by a receiver HARQ entity. Maintain three local variables CurrNewData, CurrQueueID and CurrState for each HARQ channel. The CurrNewData variable is the value of the current transmission maintenance new data indicator on the HARQ channel, and the CurrQueueID variable is the value of the current transmission maintenance queue ID. The CurrState variable indicates the current state of the HARQ channel and is inactive or active.

An inactivity timer is also maintained for each HARQ channel. In one embodiment, the inactivity timer is set to be long enough so that the probability of two packet transmissions occurring on the HARQ channel before the inactivity timer expires is high. However, other values can also be used for the inactivity timer, and this is within the scope of the present invention.

Each HARQ channel variable is initialized by setting CurrNewData to "1" and CurrState to inactive (step 910). It is determined for the UE whether a control message is received on the control channel (step 912). If the answer is no, the process returns to step 912 and waits. Otherwise, it is determined whether the control message includes a dump clear indication (step 914). If the answer is yes, then one or more HARQ channels are flushed, depending on the specific flushing scheme implemented (step 916). Dump cleaning can be implemented as described in Figure 9D below.

As part of the dump and clear processing, each reordering entity that dumps and clears the HARQ channel is notified that the packet processing is complete on that channel. Since the control message with the dump clear indication is sent only for dumping and clearing the HARQ channel, and is sent together with the control message without packet forwarding, the process then returns to step 912 to wait for the next control message.

If the received control message is not sent for dumping and clearing the HARQ channel, as determined in step 914, it is sent for packet transmission on the HS-DSCH. In this case, the specific HARQ channel used for the current packet transmission is determined from the HID field in the control message (step 922). Then the inactivity timer of the HARQ channel is restarted (step 924). As described above, restart the inactivity timer of the HARQ channel, whenever a control message is received for this channel, and if the channel is not active when the inactivity timer expires, the channel is considered inactive, and It is possible to perform appropriate actions. The inactivity timer is used to avoid a situation in which the HARQ entity waits forever for packet transmission on a specific HARQ channel, which transmission is not sent for any reason. The processing implemented when the inactivity timer expires is described below.

Then the current state of the HARQ channel is determined based on the CurrState variable (step 926), and the processing implemented for the HARQ channel depends on the current state.

If the HARQ channel is in an inactive state, indicating the completion of priority packet processing, the current transmission expectation is the first transmission of a new packet. In this case, it is determined whether CurrNewData is equal to the new data indicator in the control message of the packet processing (step 930). If they are the same, it indicates that the current transmission is not a new packet, the received packet is discarded (step 932), the ACK is sent back to the transmitter (step 934), and the process returns to step 912 to wait for the next control message. For example, if the receiver sent an ACK for a previous packet transmission, the previous packet may have been sent, but the transmitter incorrectly received the NAK and retransmitted the previous packet.

Otherwise, if the CurrNewData value is not equal to the new data indicator, indicating that the current transmission is a new packet, the HARQ channel variable is set to active (step 942) and CurrNewData to the new data indicator in the control message. (Step 944) and set CurrQueueID to the value of the queue ID in the control message (if it is sent there) (step 946) to be updated. The new packet received on the HS-DSCH is then stored in the soft buffer for the priority queue identified by the CurrQueueID value (step 948). The process then proceeds to step 958.

Returning to step 926, if the HARQ channel is in the active state, the current transmission is expected to be a retransmission of the current packet because the processing is still pending. In this case, it is determined whether CurrNewData is equal to the new data indicator in the control message (step 950). If they are the same, indicating that the current transmission is indeed a retransmission, the received packet is combined with the previous transmission of the packet (step 952), and the process proceeds to step 958.

Otherwise, if the CurrNewData value is not equal to the new data indicator determined in step 950, then the current transmission is a new packet. For example, if the transmitter decides to abandon the pending process before it is completed or receives an ACK in error for the sent NAK, the new packet may have been sent. In this case, the previous packet in the soft buffer is cleared (step 954). If the priority queue of the previous packet is known (for example, identified by the CurrQueueID value, which can be obtained from the queue ID included in the control message), the reordering entity of the priority queue is notified that the processing of the previous packet is complete (Step 956). If the priority queue of the previous packet is not known (e.g. not sent within a control message), all reordering can be notified of the processing done on the HARQ channel. The variables of the HARQ channel are then set by setting CurrNewData as the new data indicator in the control message (step 944) and CurrQueueID as the queue ID value in the control message (if it is sent there) (step 946). The new packets received on the HS-DSCH are then stored on the soft buffer (step 948), which has just been cleared of previous packets. The process then proceeds to step 958.

In step 958, the packet just received may have been combined with the transmission previously received for the packet (if any), and the packet is then decoded in an attempt to recover the packet. If the packet is not recovered, as determined in step 960, NAK feedback is sent to the transmitter (step 962), and the process returns to step 912. Otherwise, if the packet is successfully recovered, ACK feedback is sent (step 964), the current state of the HARQ channel is set to inactive to indicate the completion of the current packet processing, and no additional transmission is expected on the HARQ channel (step 966) ), and the restored packet is the priority queue identified by the CurrQueueID value and is sent to the reordering entity (step 968). The process then returns to step 912 to wait for the next control message.

Figure 9C is a flowchart of an embodiment of a process 970 implemented by the receiver HARQ entity for maintaining the inactivity timer for the HARQ channel. The steps in this process can be implemented for each TTI.

At the beginning, it is determined whether the inactivity timer has expired (step 972). Generally, only one inactivity timer, if any, expires within any given TTI, because each timer restarts at a different time, whenever a control message is received for the HARQ channel associated with the timer. If no inactivity timer expires, the process returns to step 972 and waits. Otherwise, discard the data in the soft buffer of the HARQ channel with the time-out inactivity timer (step 974). The reordering entity is the last packet transmission processing priority queue on the HARQ channel with the time-out inactivity timer, and the entity is notified that the packet processing is completed (step 976). The HARQ channel state with the time-out inactivity timer is then set to inactive (step 978), and the process returns to step 972.

Fig. 9D is a flowchart of an embodiment of a process implemented by the receiver HARQ entity after receiving the dump clear indication in the control message. This process can be implemented for step 916 in FIG. 9A. At the beginning, the HARQ channel to be dumped and cleared is identified (step 982). In an embodiment, these HARQ channels are identified as being used for a specific priority queue, which is identified by the queue ID value included in the control message itself. In other embodiments, the dump clear indication may dump and clear a specific HARQ channel, all HARQ channels, or some determinable set of HARQ channels. In any case, the data in the soft buffer in each identified HARQ channel is discarded (step 984). The status of each identified HARQ channel is then set to inactive (step 986). The reordering entity that processes each identified HARQ channel is then notified that the packet processing on that channel is complete (step 988). The process then aborts.

Transmitter reordering. Physical transmitters can maintain windows for each priority queue. The size of this window is the same as that used by the receiver, and it is used to dump and clear old data that will not be sent, because the receiver always discards the data, as described above. At the transmitter end, if packets of a given priority queue are sent in order based on their TSN, the leading edge of the window can be set as the closest TSN of the sent packet. Thereafter, as each new packet is sent, the leading edge of the window is moved to the TSN of that packet. As the window moves forward for each new packet transmission, all packets whose TSN is earlier than the dragging edge of the window are discarded.

At the transmitter, a "transmitter reordering entity" is responsible for determining the packets sent on the HS-DSCH for each priority queue. The transmitter reordering entity is the protocol peer of the reordering entity at the transmitter. The transmitter reordering entity maintains a window for the associated priority queue. The local variable TxLeadWinEdge is used to indicate the leading edge of the window, and is set to "0" at the beginning. The size of the window is represented by the local variable WindowSize.

Figure 10 is an embodiment of a process 1000 implemented by a transmitter reordering entity for a specific priority queue. The steps shown in Figure 10 are performed whenever a new packet is scheduled for transmission in the priority queue.

For the new packet to be sent, the transmitter reordering entity first slides the window forward by incrementing the TxLeadWinEdge variable (step 1012). The TSN of the new packet is then set to the updated TxLeadWinEdge value (step 1014). Then any pending packets with TSN outside the window are discarded (step 1016). In particular, packets with TSN(TxLeadWinEdge-WindowSize) will fall outside the window and be discarded. (The Modulo-WindowSize operation is implemented to consider wrap-around in the TSN space. The reason for discarding these packets is because they will fall outside the receiver's window and will be discarded if received. New packets It is then sent to the HARQ entity designated to process the packet (step 1018). The process then aborts.

If the channel condition of the receiver is poor, the dump clear indication can be sent to the receiver when all data transmission in the data burst of the specific priority queue is completed. The dump clear indication can be used to dump and clear all HARQ channels used in the priority queue, as described above. For example, if the serving cell is not a cell with the best uplink to the UE, a dump clear indication can be sent, and there is a greater possibility that the NAK/ACK feedback from the UE cannot be correctly received.

The receiver reordering entity is at the receiver, and a receiver reordering entity is responsible for processing data for each priority queue. The receiver reordering entity receives the packets recovered by the HARQ entity for the associated priority queue, reorders these packets, and transmits these packets to higher layers in order. These reordering entities maintain a window whose size is replicated at the transmitter. The local variable RxLeadWindEdge is used to indicate the most recent TSN received for the priority queue, and is set to "0" at the beginning. The size of the window is represented by the local variable WindowsSize. Packets with TSN in the range of {(RxLeadWindEdge-WindowSize+1)}... are considered to be in the receiving window.

In one embodiment, each receiver reordering entity can start multiple delay timers, one for each hole detected in the window. The delay timer is set to be long enough to have a higher probability that at least one control message is transmitted as a HARQ channel for sending the lost packet before the timer expires. Each delay timer is associated with a specific lost packet.

Figure 6B is a diagram illustrating a window maintained by the receiver reordering entity. The packet is identified and referenced by its TSN. In one embodiment, from the perspective of the receiver reordering entity, each packet in the TSN number space is associated with one of four possible states: transmitted, received, lost, and expected. A packet is considered (1) transmitted if it has been received from the HARQ entity and sent to a higher layer, (2) received, if it has been received from the HARQ entity but has not been sent to a higher layer , (3) Lost, if it is part of the hole inside the window, and (4) Expected, if it falls outside the window. If another packet with the following TSN is received before it, the packet is considered lost. Holes appear whenever there are one or more consecutive lost packets in the window. There are zero, one or more holes in the window at any given moment. At the beginning, the status of all packets in the window is set as transmitted, and those outside the window are set as desired.

In an embodiment, for each packet in the lost state (ie, lost packet), the receiver reordering entity maintains -MaskVector to mark the candidate HARQ channel of the lost packet. MaskVector is therefore used to indicate whether each of the HARQ channels is used to transmit lost packets. The size of MaskVector is equal to the number of HARQ channels used for transmission of all priority queues, and includes one element for each possible HARQ channel.

The MaskVector of each lost packet is "initialized" when the lost packet is first detected. The initial candidate set will have elements of each HARQ channel set to "1", except for the element of the HARQ channel of the received packet used to detect lost packets, which is set to "0". The value "1" indicates that the relevant HARQ channel can be used to send lost packets, and the value "0" indicates that the channel cannot be used to send lost packets. Therefore, the initial candidate set includes all HARQ channels, except for one HARQ channel that is known not to be used to transmit lost packets. Thereafter, the element of each candidate HARQ channel can be set to "0", if it is determined that the channel cannot be used to transmit lost packets. This will be the case if (1) a new packet is sent on the HARQ channel, as determined by the change in the channels new data indicator, (2) the channels inactivity timer expires, or (3) this The channel received a dump clear indication.

The MaskVector of each lost packet is also "modified" when the applicable delay timer for the lost packet expires. The modified candidate set is cleared of all HARQ channels that are inactive when the delay timer expires (by setting the elements in the MaskVector of these HARQ channels to "0"). The process of removing the remaining HARQ channels from the candidate set will proceed as above.

11A and 11B show a flowchart of an embodiment of a process 1100 implemented by a receiver reordering entity for a specific priority queue. At the beginning, the receiver reordering entity receives a packet with TSNr from the HARQ entity on the HARQ channel Hx (step 1112). It is then determined whether the packet just received (ie, the current packet) is a new packet (step 1114). If TSNr falls outside the window, the current packet is considered a new packet, and if TSNr falls within the window, it is considered a retransmission of a pending packet. If the current group is a new group, the process proceeds to step 1140.

Otherwise, if the TSNr falls within the window, then the current packet is either (1) a copy of a previously received packet, or (2) a lost packet that will partially or completely fill the hole in the window. It is then determined whether the current packet is a packet that has been received or transmitted (step 1116). If the answer is yes, the current packet is a copy and is discarded (step 1118), and the process is aborted.

Otherwise, if the answer is no in step 1116, the current packet is for the lost packet in the window. In this case, each previously lost MaskVector (ie, those with TSN earlier than TSNr) is updated by setting the element corresponding to the HARQ channel Hx to "0" (step 1120). This is because a later packet with TSNr is received on this channel, and it cannot be the one used to send the earlier lost packet. Each time the MaskVector is updated, it is also checked to determine whether all the elements of the MaskVector are "0", which indicates that the candidate set is empty and the lost packet is lost. If the MaskVector includes all "0"s, all received packets delayed by the lost packet are sent to the higher layer, and all packets earlier than the packet are set to have been transmitted.

The status of the current packet is then set to receive (step 1122). All received packets (if any) currently delayed by a hole are transmitted to the higher layer (1124). In particular, consecutively received packets starting from the leftmost side of the window and continuing until the first hole (or missing packet) is detected are identified and sent to a higher layer. The status of these sent packets is also set to have been transmitted.

In one embodiment, a delay timer is maintained for the last packet in each "original" hole, which is whenever a new packet is received by the reordering entity and one or more packets are earlier than the new packet (or On the left) the holes that occurred during the desired grouping. The state of the desired packet in the hole is changed to lost. This is described in detail below. Then, a packet can be received by the reordering entity for the lost packet in the hole. If the hole is as wide as a packet, the received packet will completely cover the hole and the delay timer is cancelled. Otherwise, if the hole covers multiple packets, and the current packet is the last lost packet in the hole, the delay timer is moved to the (new) last lost packet in the partial coverage hole. And if the hole covers multiple packets and the current packet is not the last lost packet in the hole, the delay timer is not affected. Under this implementation, only one delay timer needs to be maintained for all lost packets in the original hole (because they are detected at the same time), even if the hole is then divided into multiple holes by packets received by the reordering entity later.

Therefore, it is determined whether the delay timer is the start of the current packet (step 1126). If the answer is no, the process is aborted. Otherwise, it is determined whether there is a hole on the left side of the current packet (step 1128). If the answer is yes, the delay timer for the current packet is cancelled, because this indicates that the current packet completely fills the hole, in which case the delay timer does not need to be maintained (step 1130). Otherwise, if the current packet does not fill a hole, no action is performed with respect to the delay timer. In both cases, the process is aborted.

Returning to step 1114, if the current packet is a new packet, the status of the packet is set as received (step 1140). The MaskVector of each lost packet in the window is updated and verified, and the result is that the packet can be dumped and cleared to a higher layer by the reordering entity, as described in step 1120 (step 1142) above. The window is then moved forward to TSNr by setting the leading edge of the window, RxLeadWinEdge (step 1144). The state of all packets received outside the window is transmitted to the higher layer (step 1146), the state of all packets outside the window is set to the desired state (step 1148), and all the delays that have been set for the packets outside the window are stopped. Hour timer (step 1150). Received packets (if any) that are not currently delayed for holes are transmitted to higher layers (step 1152). This can be performed as step 1124 as described above.

It is then determined whether there is a hole on the left side of the current group (step 1154). It can be determined by checking whether the status of the packet with TSNr-1 is expected. If the answer is no, the process is aborted. Otherwise, if there is a hole, the delay timer (ie with TSNr-1) is started for the last packet in the hole (step 1156). Each desired packet in the hole is then set to be lost, and the MaskVector of each such packet is initialized by setting the element of the corresponding HARQ channel Hx to "0" and all other elements to "1" (step 1158 ). The process then aborts.

For the above-mentioned embodiment, a delay timer is used for all lost packets in each original hole (ie, a hole with a new packet that moves the window forward is detected). This timer is related to the last lost packet in the hole, but can be applied to (or referenced) all lost packets in the hole. In an implementation, a timer_over flag is used for each lost packet to indicate whether its available delay timer (that is, the first delay timer on the right side of the packet) has expired. When the original hole is detected, the timer_over flag of each lost packet in the hole can be set to "0" to indicate that the applicable delay timer has not expired (step 1158). And when the delay timer expires, the timer_over flag of all lost packets covered by the timer is set to "1", and the MaskVectors of all these lost packets are also modified to be inactive or blocked at this time as described above. Used for HARQ channels where other priority queues are removed. This implementation is described in detail below.

The MaskVector of the lost packet is updated/modified based on various events, such as (1) whenever the HARQ entity indicates that the packet processing on a given HARQ channel is complete, and (2) when each delay is maintained for the associated lost packet. When the timer expires.

FIG. 11C shows a flowchart of an embodiment of a process 1160 implemented by the receiver reordering entity, in which an indication that the delay timer expires is received whenever an indication is received. At the beginning, it is determined whether the delay timer expires (step 1162). If the answer is no, the process is aborted. Otherwise, if the delay timer expires, the TSN of the lost packet associated with the expired delay timer is determined and denoted as TSNe (step 1164). Multiple lost packets can rely on this delay timer because only one is maintained for all lost packets in each original hole, as described above. The timer_over flag of each lost packet covered by the time-out delay timer is then set to "1" to indicate that the packet timer has expired (step 1166). The lost packets covered by this timeout delay timer include those with TSN earlier than TSNe. The MaskVector of each lost packet covered by the delay timer is then "modified" (that is, the candidate set of the lost packet is modified) (step 1168). In order to modify the MaskVector for lost packets, consider each HARQ channel, and if the channel is inactive, or the channel is used in another priority queue, the corresponding element in the MaskVector is set to "0". The HARQ channel corresponding to the element in the MaskVector that is still set to "1" is the remaining candidate HARQ channel at this time. If the MaskVector is modified, it is checked to determine whether the packet should be dumped and cleared to a higher layer. The process then aborts.

FIG. 11D shows a flow diagram of an embodiment of the process 1170 implemented by the receiver reordering entity to complete the processing on a specific HARQ channel. At the beginning, it is determined whether an indication has been received from the receiver HARQ entity, indicating that the packet processing has been completed on the HARQ channel (step 1172). If the answer is yes, then for each lost packet for which the applicable delay timer has expired (that is, the timer_over flag is reset to "0"), the element in the MaskVector corresponding to the HARQ channel is set to "0" ( Step 1174). Similarly, if the MaskVector is updated, check to determine whether the packet should be dumped and cleared to a higher layer. The processing to be implemented for the processing performed on the HARQ channel is described in pseudo code below. The process then aborts.

In the above embodiment, each receiver reordering entity can start multiple delay timers, one for the original hole detected in each window. In other embodiments, each reordering entity may have a delay timer that runs at any given moment. Whenever an original hole is detected, if it is not currently running, the delay timer for the reordering entity can be started, and the delay timer is not started for the lost packets in the second original hole at that moment. If the delay timer expires thereafter, the lost packets covered by the delay timer (that is, the lost packets with TSN earlier than the TSNe of the lost packet associated with the delay timer) are shown in steps 1162 to 1166 in Figure 11C The ones out are updated. In addition (after step 1166), it is determined whether there are any missing packets with TSN later than TSNe. If the answer is yes, the delay timer restarts and is associated with the last lost packet.

This other embodiment reduces the number of delay timers that each reordering entity needs to maintain to one. However, this embodiment can double the delay timer value for lost packets in the worst case. For example, the delay timer may start for the first lost packet, and the second lost packet may be detected in the next transmission interval. The delay timer for the second lost packet cannot be started before the delay timer for the first lost packet expires. The second lost packet will then need to wait for the first lost packet plus the second lost packet delay timer to expire. This other embodiment is described in detail in the pseudo code shown below.

Figure 12 shows a flow diagram of the overall process 1200 implemented by the reordering entity for receiving packets from the HARQ entity and sending the packets to higher layers. At the beginning, the correctly decoded packet is received from the HARQ entity (step 1212). Then a missing packet between the received packets is detected (step 1214). This can be obtained based on the TSN in the received packet, as described above. If a lost packet is detected, it is delayed to transfer the received packet later than the detected lost packet to a higher layer (step 1216). It is then determined for each lost packet (1) whether it is received next from the HARQ entity or (2) whether it is lost by successively removing the HARQ channel that may be used to transmit the lost packet, as described above (step 1218). The received packet that has been delayed for each lost packet is thereafter transmitted to a higher layer after the lost packet is determined to be lost or received from the HARQ entity (step 1220).

The pseudo code for the specific implementation of the process described above in FIGS. 8 to 11C is shown below.

When the transmitter HARQ entity schedules (re)transmissions for a specific priority queue, the transmitter: 1-if this is the first transmission of the packet; 2-flip the new data indicator; 1-set the queue ID field to The priority queue of the packet being sent; 1-End the process.

When an ACK is received 1-discard the current packet being sent; 1-indicate to the scheduler that the HARQ entity is available; 1-end the process.

When the receiver HARQ entity receives the control channel transmission sent for the receiver: 1-If the control message includes a dump clear indication: 2-Process the dump clear indication for the priority queue specified in the queue ID field (see below) ; 2-End the process.

1- Start/restart the inactivity timer (TM1) for the HARQ channel identified by the control message; 1- If the identified HARQ channel is in an inactive state; 2- If CurrNewData has the same value as the new data indicator; 3 -Discard the received packet; 3-Send an ACK on the uplink; 3-End the process.

2- Otherwise: 3- Set the HARQ channel as active; 3- Set CurrNewData to the value of the new data indicator; 3- Set CurrQueueID to the value of the queue ID field; 3- Store the received packet transmission In the soft buffer; 1-otherwise (if the HARQ channel is active)' 2-if CurrNewData = new data indicator; 3-soft combination of the received packet with the previous transmission accumulated in the soft buffer; 2- Otherwise: 3- discard the data currently in the soft buffer; 3- indicate the completion of the packet processing to the reordering entity corresponding to the Curr queue ID (see below); 3- set CurrNewData to the new data indicator value; 3- Set the Curr queue ID as the value of the queue ID field; 3-store the received packet transmission in the soft buffer;

1- Attempt to decode the packet in the soft buffer; 1- If the decoding is successful: 2- Send ACK on the uplink; 2- Set the HARQ channel to an inactive state; 2- Transfer the recovered packet to the corresponding The reordering entity of CurrQueueID (see below); 1-otherwise: 2-send NAK on the uplink; 1-end the process.

After the inactivity timer (TM1) of a given HARQ channel expires: 1- discard the data currently in the soft buffer; 1- indicate to the reordering entity corresponding to CurrQueueID that the packet processing is complete (see below); 1- Set the HARQ channel to an inactive state; 1-End the process.

After receiving the dump clear indication of a given priority queue: 1-For each HARQ channel, where its CurrQueueID is equal to the queue ID value in the control message of the dump clear indication: 2-do not try to receive data; 2-discard Data in the soft buffer; 2- Set the HARQ channel to an inactive state; 2- Indicate the completion of the packet processing to the reordering entity corresponding to the CurrQueueID; 1- End the process.

Transmitter reordering entity When scheduling the associated priority queue for transmission, the transmitter reordering entity: 1-increment TxLeadWinEdge; 1-set the TSN of the new packet to TxLeadWinEdge; 1-discard any TSN TxLeadWinEdge-WindowSize Pending packets; 1-deliver the new packet to the HARQ entity designated by the scheduler; 1-end the process.

The receiver reordering entity is for this embodiment, where a delay timer is maintained for each original hole.

When a new packet with TSNr is transmitted by the HARQ entity, the receiver reorders the entities: 1- If the received packet is within the receiving window (RxLeadWinEdge-WindowSizeTSNr<RxLeadWinEdge); 2-For each TSNi in the lost state; 3-If TSNi<TSNr: 4-Set the elements in the MaskVector corresponding to the HARQ channel to "0"; 4-If all elements in the MaskVector are equal to 0: 5-Implement the dump and clear process for TSNi (see below ) 2- If TSNr status is received or transmitted; 3- Discard the received packet; 2- Otherwise (TSNr status is lost); 3- If there are all packet statuses in the receiving window with TSN<TSNr To be sent, then: 4- If the delay timer (TM2) associated with TSNr starts, stop the read timer; 4- Transmit the packet to a higher layer; 4- Set the status of TSNr to be Transmit; 4-For each TSNj in the receiving window, start at TSNr+1; 5-If the state of TSNj is expected or lost; 6-Stop iterating on TSNj.

5- Otherwise, if the TSNj status is received; 6-Transmit the data of TSNj to the higher layer; 6-Set the status of TSNj to be transmitted; 6-If the delay timer is associated with TSNj, stop Timer; 6-to the next TSNj; 3- otherwise: 4- set the status of TSNr to received; 1- otherwise (received packet is outside the receiving window); 2- for each in the lost state TSNi; 3-Set the element in the MaskVector corresponding to the HARQ channel to "0";

3- If all the elements in the MaskVector are equal to "0"; 4- Perform a dump and clear process on TSNi; 2- Set RxLeadWinEdge to TSNr; 2- Set all the bands associated with TSN outside the receiver window The data with the received state is sent to the higher layer; 2-stop the delay timer TM2 associated with the TSN outside the receiver window; 2-set all the TSN states outside the receiver window as expected; 2- If the status of all packets with TSN<TSNr within the receiving window is received or transmitted, then: 3- Send the packet to a higher layer; 3- Set the status of TSNr to be transmitted; 2- Otherwise: 3-set the status of TSNr as received; 3-start the delay timer TM2 associated with TSNr-1; 3-for each TSNj within the receiving window with the desired status under TSNj<TSNr : 4- Set the TSNj status to lost; 4- Reset the timer_over flag to "0"; 4- In the MaskVector associated with TSNj; 5- Set the element corresponding to the HARQ channel to "0" ; 5- Set the elements corresponding to other HARQ channels to "1"; 1- End the process; when the HARQ entity indicates that the packet processing of the specific HARQ channel is complete: 1- For each TSNi in the lost state, its timer_over flag is set Set as 1; 2- Set the elements in the MaskVector corresponding to the HARQ channel to "0"; 2- If all elements in the MaskVector are equal to "0"; 3- Realize TSNi dump and clear process 1- End process when When the delay timer (TM2) expires: 1- consider each TSN in the lost state, TSN is less than or equal to the TSN related to the timer; 2- set the timer_over flag to "1";

2- Consider the MaskVector variable of the TSN; 2- For each HARQ entity: 3- If the HARQ entity is not in the active state or the CurrQueueID is different from the priority queue of the reordering entity; 4- It will correspond to the MaskVector element of the HARQ channel Set to "0"; 1-end the process dumping and clearing process-when all elements in TSNi's MaskVector are equal to "0"; 1-for each TSNj in the receiving window and TSNj earlier than or equal to TSNi; 2 -If the status of TSNj is received, send the associated data to the higher layer; 2- Set the status of TSNj to be sent; 1- For each TSNj in the receiving window, start at TSNi+1; 2 -If the status of TSNj is expected or missing: 3-Stop the iteration of TSNj.

2- Otherwise, if the status of TSNj is received: 3- Transmit the associated data to a higher layer; 3- Set the state of TSNj to be transmitted; 3- To the next TSNj; 1- Return; For In an embodiment, a delay timer is maintained for each reordering entity.

When a new packet with TSNr is transmitted by the HARQ entity, the receiver reorders the entities: 1-If the received packet is within the receiving window (RxLeadWinEdge-WindowSize<TSNr<RxLeadWinEdge); 2-For each TSNi in the lost state ; 3- If TSNi <TSNr: 4- Set the elements in the MaskVector corresponding to the HARQ channel to "0"; 4- If all elements in the MaskVector are equal to 0: 5- Realize the dump and clear process for TSNi (see Below) 2-If the status of TSNr is received or transmitted: 3-Discard the received packet;

2- Otherwise (the status of TNSr is lost): 3- If the status of all packets with TSN<TSNr in the receiving window has been transmitted, then: 4- If the delay timer (TM2) associated with TSNr has started , Then stop the timer; 4-Transmit the packet to the higher layer; 4-Set the status of TSNr to be transmitted; 4-For each TSNj in the receiving window, start at TSNr+1; 5-If the TSNj The status is expected or lost; 6-Stop the iteration on TSNj; 5-Otherwise, if the status of TSNj is received; 6-Transmit the data of TSNj to higher layers; 6-Set the status of TSNj to be Transmit; 6-if the delay timer is associated with TSNj, stop the timer; 6-to the next TSNj; 3-otherwise: 4-set the status of TSNr to received; 1-otherwise (receive packet Outside the receiving window): 2-For each TSNi in the lost state: 3-Set the elements in the MaskVector corresponding to the HARQ channel to "0"; 3-If all the elements in the MaskVector are equal to "0"; 4- Realize the dumping and clearing process for TSNi 2- Set TxLeadWinEdge to TSNr; 2- Transmit all data associated with TSN that is outside the receiver window to the higher layer; 2- Stop all the data in the receiver The delay timer TM2 associated with the TSN outside the window; 2- Set all the TSN states outside the receiver window to the desired state; 2- If the state of all packets with TSN <TSNr within the receiving window is received To or have been transmitted, then: 3-transmit the packet to a higher layer; 3-set the status of TSNr to be transmitted; 2-otherwise 3-set the state of TSNr to received;

3- If the delay timer TM2 of the reordering entity is not running; then: 4- start the delay timer TM2 associated with TSNr-1; 3- for every TSNj<TSNr in the receiving window with the status expected TSNj: 4- Set the TSNj status to lost; 4- Reset the timer_over flag to "0"; 4- In the MaskVector associated with TSNj: 5- Set the element corresponding to the HARQ channel to " 0"; 5-Set the elements corresponding to other HARQ channels to "1"; 1-End the process when the HARQ entity indicates that the packet processing for a specific HARQ channel is complete: 1-For each TSNi in the lost state, its timer_over flag Set to 1; 2-Set the elements in the MaskVector corresponding to the HARQ channel to "0"; 2-If all the elements in the MaskVector are equal to "0"; 3-Realize the dump and clear process for TSNi 1-End Process When the delay timer (TM2) expires: 2- consider each TSN in the lost state, TSN is less than or equal to the TSN associated with the timer; 2- set the timer_over flag to "1"; 2- consider this The MaskVector variable of TSN; 2- For each HARQ entity: 3- If the HARQ entity is not in the active state or the CurrQueueID is different from the priority queue of the reordering entity; 4- Set the MaskVector element corresponding to the HARQ channel to " 0"; 1-If there is any TSN in the lost state: 2-Start the delay timer and associate it with the TSN of the last packet in the lost state; 1-End the process dumping and clearing process-when the MaskVector of TSNi When all elements in is equal to "0"; 2-For each TSNj in the receiving window and TSNj earlier than or equal to TSNi;

2- If the status of TSNj is received, then transmit the associated data to the higher layer; 2- Set the status of TSNj to be sent; 1- For each TSNj in the receiving window, start at TSNi+1; 2- If the status of TSNj is expected or missing: 3- Stop the iteration on TSNj.

2- Otherwise, if the status of TSNj is received: 3- Transmit the associated data to a higher layer; 3- Set the state of TSNj to be transmitted; 3- To the next TSNj; 1- Return; above The pseudo code of a specific implementation is shown to provide a clearer understanding of the process implemented by each entity at the transmitter and receiver. Other implementations can also be considered, such as those skilled in the art can describe based on the foregoing principles, and these various other implementations are also within the scope of the present invention.

The techniques described herein can be used to provide improved delay avoidance performance for systems with basic retransmission mechanisms (such as HARQ) and higher-layer data requiring sequential data. These technologies can be used in various communication systems, such as, for example, W-CDMA systems, cdma2000 systems, and so on. These technologies can also be used in other types of communication systems (such as TDMA and FDMA systems).

FIG. 13 is a block diagram of an embodiment of Node B 104 and UE 106. On the downlink, the transmit (TX) data processor 312 receives and processes (for example, formatting, encoding, etc.) HS-DSCH and HS-SCCH data designated to receive HSDPA transmission for a specific UE. The processing of HS-DSCH and HS-SCCH can be implemented as described in the applicable W-CDMA version 5 standard documents, including TS.25-321 V5.0.0, TS.25-308 V5.2.0 and 25-212 V5. 0.0, these are all included here as a reference. These and other documents for W-CDMA version 5 are publicly available.

The processed data is then provided to a modulator (MOD) 1314 and further processed (eg, channelized, expanded, etc.) to provide modulated data. The transmitter (TMTR) unit 1316 then converts the modulated data into one or more analog signals, which are adjusted (e.g., amplified, filtered, and frequency up-converted) to provide a downlink signal. The downlink signal is routed through the antenna duplexer (D) 1322 and sent to the designated UE through the antenna 1324.

At the UE, the downlink signal is received by the antenna 1352, routed through the antenna duplexer 1354 and provided to the receiver (RCVR) unit 1356. The receiver unit 1356 adjusts (eg, filters, amplifies, and frequency down-converts) the received signal and further digitizes the adjusted signal to provide samples. The demodulator 1358 then receives and processes (e.g., despreads, channelizes, and data demodulates) the samples to provide symbols. The demodulator 1358 can implement a rake receiver, which can process multiple instances of the received signal (ie, multipath components) to provide combined symbols. The receive (RX) data processor 1360 then decodes the symbols, checks the received packet and provides decoded data. The processing of the demodulator 1358 and the RX data processor 1360 is complementary to the processing of the modulator 1314 and the TX data processor 1312, respectively.

In an embodiment, the RX data processor 1360 implements processing of the physical layer and part of the MAC layer (such as HARQ entities), and the controller 1370 implements some processing (such as reordering entities) for the MAC layer, and further implements parts of HARQ. For this embodiment, the RX data processor 1360 can provide (1) decoded data for each packet correctly decoded, (2) the status of each packet transmission (such as ACK or NAK), and (3) inactivity indicating timeout Performance and delay timers, etc. The controller 1370 then detects the lost packet and provides it to higher layers when the packet is received and available. The controller 1370 also provides appropriate ACK/NAK feedback for the HARQ operation to the TX data processor 1382.

On the uplink, the TX data processor 1382 processes (such as formatting, encoding, etc.) the uplink data and ACK/NAK feedback information, which are further processed by the modulator 1384 (such as channelization, extension, etc.), and are processed by the modulator 1384. The transmitter unit 1386 is adjusted (eg, converted to an analog signal, amplified, filtered, and upconverted) to provide an uplink signal. The uplink signal is then routed through the antenna duplexer 1354 and sent through the antenna 1352 to the base station.

At Node B, the uplink signal is received by the antenna 1324, routed through the antenna duplexer 1322, and provided to the receiver unit 1342. The receiver unit 1342 adjusts (eg, down-converts, filters, and amplifies) the received signal and further digitizes the adjusted signal to provide a sample stream. The demodulator 1344 then processes (eg, despreads, channelizes, etc.) the samples to provide symbols, and the RX data processor 1346 also processes the symbols to provide decoded data to the UE. Downlink and uplink data processing is described by the W-CDMA standard document.

The controller 1330 receives the ACK/NAK feedback from the RX data processor 1346 and retransmits the HARQ guide packet, if necessary. The controllers 1330 and 1370 also control the corresponding processing at the Node B and the UE. Each controller can also be designed to implement all or part of the HARQ transmission/retransmission technology described herein. The program codes required by the controllers 1330 and 1370 can also be stored in the memory units 1332 and 1372, respectively.

The techniques described here for improving the delay avoidance performance can be implemented in various ways. For example, these technologies can be implemented in hardware, software, or a combination thereof. For hardware implementation, the components used in this implementation technology (for example, components that can implement the process of FIGS. 8 to 11A) can be implemented with the following components: one or more application-specific integrated circuits (ASIC), digital signal processors (DSP), Digital signal processing device (DSPD), programmable processor (DSP), digital signal processing device (DSPD), programmable logic device (PLD), field programmable gate array (FPGA), processor, controller, microcontroller , Other electronic units designed to realize the functions described here, or their combinations, etc.

For software implementation, these technologies can be implemented with modules that implement the above-mentioned functions (for example, procedures, functions, etc.). The software codes may be stored in a memory unit (e.g., memory units 1332 and 1372 in FIG. 13) and executed by a processor (e.g., controllers 1330 and 1370). The memory unit may be implemented within the processor or external to the processor, in which case it may be communicatively coupled to the processor in various ways known in the art.

The above description of the preferred embodiments enables those skilled in the art to make or use the present invention. Various modifications of these embodiments are obvious to those skilled in the art, and the general principles defined here can be applied to other embodiments without using creative ability. Therefore, the present invention is not limited to the embodiments shown here, but should conform to the broadest scope consistent with the principles and novel features disclosed herein.