US20100272033A1

US20100272033A1 - Harq buffer management and feedback design for a wireless system

Info

Publication number: US20100272033A1
Application number: US12/647,442
Authority: US
Inventors: Jong-Kae Fwu; Hongmei Sun; Hujun Yin; Tom Harel; Yuval Lomnitz; Yuan Zhu
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2009-04-28
Filing date: 2009-12-26
Publication date: 2010-10-28
Also published as: ES2637294T3; US8677223B2; EP2425572A2; TWI519191B; KR101298863B1; US8560696B2; EP2425594A2; EP2425555A4; US20100274899A1; WO2010129366A3; KR20120005520A; KR20120017437A; JP5382829B2; US8417190B2; TWI528849B; CN102461049B; TWI517624B; CN102415017B; WO2010129358A2; BRPI1011899A2

Abstract

A method is disclosed for performing HARQ buffer management. The HARQ buffer management method is a new approach to buffer overflow management that allows the mobile station, rather than the base station, to control the size of its buffer. The HARQ buffer management reports buffer size, buffer occupancy status, and buffer overflow to the base station, to facilitate efficient communication between the base station and the mobile station.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority under 35 U.S.C. 119(e) to U.S. Provisional Patent Application No. 61/173,204, entitled, “ADVANCED WIRELESS COMMUNICATION SYSTEMS AND TECHNIQUES”, filed on Apr. 28, 2009.

TECHNICAL FIELD

This application relates to hybrid automatic repeat request (HARQ) buffer management under the advanced air interface standard.

BACKGROUND

IEEE 802.16 is a set of wireless broadband standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE). IEEE 802.16m is known as the advanced air interface standard. Hybrid automatic repeat request (HARQ) is widely supported in current state-of-the-art wireless communication standards. Under automatic repeat request (ARQ), error detection information is added to data before transmission, ensuring that the receiver is able to decode the data. With HARQ, additional forward error correction (FEC) bits are also added to the data.
Several wireless communication standards are defined by the Institute of Electrical and Electronics Engineers (IEEE), including 802.16e (broadband wireless access) and 802.16m (advanced air interface standard). IEEE 802.16e is referred to herein as “802.16e” or “broadband wireless access standard”; IEEE 802.16m is referred to herein as “802.16m” or “advanced air interface standard”.
Also under this standard, there are two types of uplink fast feedback channels: a primary fast feedback channel (PFBCH), supporting up to six bits of information; and a secondary fast feedback channel (SFBCH), supporting up to twenty-four bits of information. The SFBCH potentially has up to three times as much storage as the PFBCH. The availability of either the PFBCH, the SFBCH, or both fast feedback channels, will vary, depending on a number of criteria.
In practical implementations, the mobile station saves information from bursts that were not decoded correctly in a buffer known as the HARQ buffer. This buffer has a limited size, and additional bursts cannot be further saved when the buffer is full. The size and management scheme of this buffer affects both the maximum throughput of the mobile station and the performance of HARQ. Since large buffers are required in order to handle the traffic rates supported in 802.16m, the buffer management scheme should balance the buffer utilization with HARQ performance.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of this document will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein like reference numerals refer to like parts throughout the various views, unless otherwise specified.

FIG. 1 is a schematic diagram of a HARQ buffer management method, according to some embodiments;

FIG. 2 is a schematic diagram showing how a mobile station buffers blocks received from a base station, according to some embodiments;

FIG. 3 is a schematic diagram showing how a base station can keep track of the buffer size of the mobile station, according to some embodiments;

FIG. 4 is a graph showing the probability of having a fully occupied buffer when there are x failures in sixteen trials, assuming a fail probability of 0.3 in each transmission, according to some embodiments;

FIG. 5 is a diagram showing four ways in which a mobile station increase the size of its buffer, according to some embodiments;

FIG. 6 is a table showing a possible code word sequence defined for reporting HARQ buffer status to the base station using the HARQ buffer management method of FIG. 1, according to some embodiments; and

FIG. 7 is a table showing possible channel reporting of the buffer overflow, buffer occupancy status, and buffer size by the HARQ buffer management method of FIG. 1, according to some embodiments.

DETAILED DESCRIPTION

In accordance with the embodiments described herein, a method is disclosed for performing HARQ buffer management. The HARQ buffer management allows the mobile station, rather than the base station, to control the size of its own buffer. The HARQ buffer management reports buffer overflow, buffer occupancy status, and buffer size to the base station, to facilitate efficient communication between the base station and the mobile station.
FIG. 1 is a block diagram of a HARQ buffer management method 100, according to some embodiments. The HARQ buffer management method 100 includes buffer overflow management and buffer occupancy feedback reporting. The HARQ buffer management method 100 reports buffer overflow 30, buffer occupancy 40, and buffer size 50 to a base station 70 by a mobile station 60. The operations of the HARQ buffer management method 100 are described in more detail in the following paragraphs.
The mobile station 60 includes a HARQ buffer 200. Because the base station 70 may transmit encoded data in multiple blocks, the mobile station 60 stores some of the blocks until all blocks have been received from the base station. The mobile station 60 then decodes the blocks together. If one of the blocks is transmitted in error, the mobile station 60 requests retransmission from the base station 70 of the erroneously transmitted block.
These operations are depicted schematically in FIG. 2, according to some embodiments. In FIG. 2, a data transmission consists of four separate blocks 80 _A, 80 _B, 80 _C, and 80 _D(collectively, “blocks 80”), or partial transmissions, which may vary in size. The blocks 80 are encoded at the base station 70 before transmission to the mobile station 60. Three of the four blocks 80 _A, 80 _B, and 80 _Dare successfully transmitted to the base station 70, and the mobile station 60 transmits an acknowledgement (“ACK”) to the base station for each of the successful transmissions. The block 80 _C, however, is erroneously transmitted, and the mobile station 60 transmits a negative acknowledgement (“NACK”) to notify the base station 70 to retransmit the block 80 _C. Thus, the base station 70 retransmits the block 80 _Cto the mobile station, after which the mobile station 60 acknowledges the successful transmission.
The HARQ buffer 200 located at the mobile station 60 stores the blocks 80 as they are received from the base station 70. In FIG. 2, the HARQ buffer 200 is a first-in-first-out (FIFO) memory buffer, but the mobile station may have other types of buffer storage as well. The four-block data transmission is not decoded until all blocks 80 of the original data transmission are received. Thus, the HARQ buffer 200 saves the portions of the transmission that were successfully received ( blocks 80 _A, 80 _B, and 80 _D) until all blocks have been received (block 80 _C). Then, the mobile station 60 is able to decode the data.
FIG. 2 shows the general principles in which the HARQ buffer 200 is used. As long as there is storage available for the blocks 80 being transmitted, the mobile station 60 will only have to request retransmission (“NACK”) whenever a block is transmitted erroneously. Another way in which retransmissions will be needed is when the buffer 200 overflows, preventing the mobile station 60 from being able to store the partial transmission. The HARQ buffer 200 is said to overflow when the buffer is full of data such that no additional data can be stored therein. Until the buffer 200 is available to store blocks 80 received from the base station 70 (not overflowed), the mobile station 60 is forced to request retransmission.
The availability of a buffer of sufficient size in the mobile station 60 relates directly to the throughput of transmissions between the mobile station and the base station 70. If the size of the HARQ buffer 200 (given by HARQ buffer size 50) is very small, the buffer will fill up quickly, and the mobile station 60 will force retransmission by the base station 70. Therefore, traditionally, the buffer has been managed conservatively, with the base station 70 controlling the HARQ buffer 200 in the mobile station 60.
The HARQ buffer management method 100 takes a different approach than the traditional buffer management methods. In some embodiments, the HARQ buffer management method 100 gives control of the buffer size to the mobile station 60, with the mobile station 60 giving the base station 70 sufficient status information about the HARQ buffer 200 to enable the base station to intelligently transmit data to the mobile station.
Buffer Overflow Management
As used herein, buffer overflow is defined as the reception of more (erroneously decoded) data into the HARQ buffer 200 than the buffer is capable of processing. When the buffer overflows, the HARQ performance deteriorates. Put another way, the throughput of transmissions between the base station 70 and the mobile station 60 is undermined when the HARQ buffer 200 overflows.
The throughput problem becomes more severe for incremental redundancy HARQ (IR-HARQ or HARQ-IR) and adaptive HARQ, for two reasons. First, in HARQ-IR, the re-transmission might include only parity bits. Channel-to-channel (CTC) decoder performance, in the absence of some initial information on systematic bits, is undesirable. Further, in some cases, it is impossible to decode a re-transmission without using the original transmission, even without noise (SNR→∞). Also, in adaptive HARQ, the size of the re-transmission may be quite small, assuming most of the information needed for decoding was received in the previous transmissions.
Accordingly, in some embodiments, under the HARQ buffer management method 100, the overflow of the HARQ buffer 200 is managed by the base station's scheduler, which manages the data transmission to the mobile station 60. The mobile station 60 reports its HARQ buffer size 50 to the base station 70, and the base station thereafter tracks the occupancy level in the mobile station's buffer 200 (until the next reporting of the HARQ buffer size). By knowing the buffer size 50 and keeping track of transmissions to the mobile station 60, the base station 70 controls the transmission of data to the mobile station 60, in some embodiments, such that improved throughput is realized.
FIG. 3 schematically depicts buffer overflow management by the HARQ buffer management method 100, according to some embodiments. The mobile station 60 reports the HARQ buffer size 50 to the base station 70. The base station 70 has a scheduler 300 that keeps track of various data and operations performed by the base station, including data about each mobile station serviced by the base station. The scheduler 300 also has a processor 90, to keep track of data transmissions to the mobile station 60 that will affect the size of the HARQ buffer 200. (The processor 90 may be a simple counter or timer to keep track of transmissions to the mobile station.) Since the mobile station 60 only receives transmission from the base station 70 (known as its “serving base station”), the base station is able to keep track of the size of the HARQ buffer 200 by first obtaining the size information (buffer size 50) from the mobile station 60, then keeping track of transmissions made by the base station to the mobile station, transmissions that will affect the fullness or emptiness of the buffer. In some embodiments, the mobile station 60 periodically transmits the buffer size 50 to the base station 70. Each time the mobile station 60 sends the buffer size 50 to the mobile station 70, the scheduler 300 restarts the processor 90.
Maximum Throughput and HARQ Buffer Occupancy
A conservative buffer management scheme that avoids overflow limits the maximum throughput that can be achieved by the mobile station 60 with a given HARQ buffer size. One of the goals for the advanced air interface standard (802.16m) is to support high throughput traffic, about 180 Mbits/sec for 2×2 MIMO (multiple-input-multiple-output schemes) with a 20 MHz bandwidth. A conservative design, such as was applied in the mobile broadband wireless standard (802.16e), may be used for 802.16m, but such an implementation is likely to use large buffers to support such throughput, as depicted in the following calculation. Large buffers, however, add to the expense of the mobile station and are inefficient when they are not fully utilized.
The maximum supported throughput is given by:
$thput \leq \frac{Buf f {erSiz}^{*} e \underset{\max}{R}}{R T T}$
where R_maxthe maximum code-rate (e.g., ⅚) and RTT (round trip time) is the time from a transmission to its retransmission or new transmission. A new transmission includes receiver processing time, (N)ACK channel signaling, and scheduling of re-/new transmission, in 802.16m, is at least one sub-frame (5 ms), and BufferSize is the number of soft bits or metrics in the buffer.
The reason for the higher bound on this throughput is that the base station 70 cannot send more coded bits than the mobile station 60 buffer size before receiving an acknowledgement that some bursts were received and decoded correctly, making room for new information.
This worst case approach ensures that the HARQ buffer is never overflowed (unless there are errors in control signaling). Actually, however, this approach makes poor usage of the buffering capability. Assume the information in one frame is divided into sixteen bursts of equal size, each one on a different HARQ channel, and the probability of error is 0.3 for each burst and independent among them. Then, the probability of having a fully occupied buffer by the end of the frame is as small as 4*10⁻⁹. This shows that more information could have been sent to the mobile station 60 with negligible error probability. FIG. 4 is a graph showing the probability of having a fully occupied buffer when there are x failures in sixteen trials, assuming a fail probability of 0.3 in each transmission (0<=x<=16). FIG. 4 shows that, with a probability of 10⁻², up to one half of the buffer (eight bursts) is occupied at the end of the frame.
The conservative buffer management protocol of avoiding overflow wastes resources and limits the maximum user throughput. Therefore, the base station 70 might over-use the mobile station 60 buffer by transmitting more information than the declared mobile station buffer size, using statistical assumptions on the maximum number of failures in the frame (that do not cause buffer overflow). However, the statistical assumption for the buffer over-usage depends on mobile station buffer management.
In contrast to prior art solutions in which the base station 70 controls the size of the HARQ buffer 200, the HARQ buffer management method 100 allows the mobile station 60 to control its buffer size, larger or smaller, therefore allowing more efficient buffer usage.
In some embodiments, the HARQ buffer management method 100 enables the mobile station 60 to enlarge its buffer size 50 in several ways. The options are depicted schematically in FIG. 5, according to some embodiments, with items excluded from the buffer 200 being denoted using dashed lines. For example, the mobile station 60 may evacuate correctly decoded forward error correction (FEC) blocks 82 from the buffer 200. Forward error correction encoding encodes the “data bits” as well as error detection bits such as cyclic redundancy check (CRC) or checksum bits. Thus, the FEC encoding inflates the number of transmitted bits. For example, if the code rate is ½, then 100 “data bits” are transmitted by 200 “coded bits.” The coded bits are obtained during demodulation at the mobile station 60, typically with many errors. The coded bits are saved in the form of “metrics,” in which each metric is a guess of the transmitted coded bits together with its reliability. For example, a metric of ∞ means the coded bit surely is a “0” while a metric of −∞ means the coded bit surely is a “1”. A metric of zero means that the coded bit might be a “1” or a “0” with equal probability. These metrics are sometimes called “soft bits.” The metrics are quantized and saved, as one example, in 8-bit form.
For example, if there are 100 data bits and the code rate is ½, then the mobile station 60 would need to save 100/½ or 200 soft bits (one for each coded bit), which require 200 times 8, or 1600 bits in the buffer 200 (for the current decoding as well as for HARQ combining). However, if only the data bits are stored in the buffer 200, then only 100 bits of space in the buffer are needed. Furthermore, if the data bits contain error detection bits (e.g., CRC), then their savings is not required, but the potential savings is relatively small.
Alternatively, the mobile station 60 may perform smart handling of buffer overflow events, such as on-the-fly allocation of more buffering resources, using a buffer overflow handler 210, as shown in FIG. 5. In some embodiments, the buffer overflow handler 210 is invoked if the mobile station 60 gets stuck and must be reset, due to a buffer overflow or if the buffer 200 is full. Or, the buffer overflow handler 210 may ensure that the buffer 200 always has room to decode new transmissions by evacuating old transmissions in random order or according to some criteria. For example, the buffer 200 may delete the oldest transmissions first (FIFO buffer), since the base station 70 may no longer retransmit the older data.
Under a more sophisticated approach, the buffer overflow handler 210 may evacuate only parity soft bits and try to save the metrics of systematic bits. Systematic bits are coded bits that are more important to the decoder performance than other bits. Thus, it makes sense to evacuate other bits before the systematic bits. As another option, the buffer overflow handler 210 may save each metric with fewer bits, e.g., two bits per metric instead of eight bits per metric, to recover more space in the buffer 200. These options are ways to trade off the performance (HARQ combining gain) with a limited buffer size.
As yet another option, the mobile station 60 may refrain from reserving buffer space for mother code bits 84 and save metrics only for actually received coded bits 86. In incremental redundancy HARQ, new coded bits are transmitted in a retransmission, necessitating a larger buffer size after retransmission. A naïve implementation is to allocate sufficient buffer size for all of the subsequent transmissions during the reception of the first transmission. The size of the buffer is determined according to a minimal effective code rate, or “mother code rate.” In 802.16m systems, the mother code rate is ⅓, while the actual code rate of a transmission might be ½ or ⅚, for example, and use a significantly smaller buffer. Under the HARQ buffer management method 100, the mother code bits 84, i.e., the newly coded bits used for retransmission, would not be stored in the HARQ buffer 200, in contrast with prior art implementations.
Or, the mobile station 60 may trade off performance for buffer size (lossy compression of received information).
As can be observed from the above list, it may be difficult and undesirable to fully standardize the internal buffer management of a mobile station. For example, to fully specify the removal of FEC blocks 82 from the buffer 200 to the base station 70, the mobile station 60 would need to report the size of the soft bit buffer, the size of the decoded bit buffer, and some parameters regarding the delay of evacuating correctly received blocks to the base station. Even with this information, the base station 70 lacks sufficient information to decide on the maximum traffic to send, since the utilization of these buffers ultimately depends on the channel behavior.
Accordingly, the HARQ buffer management method 100 operates under a different approach. The mobile station internal buffer management is not exposed to the base station 70. Instead, the base station 70 receives metrics from the mobile station 60 that will allow the base station 70 to manage the traffic rate. These metrics will encompass the channel behavior as well as the specific mobile station implementation.
In some embodiments, according to the HARQ buffer management method 100, the mobile station 60 judiciously stores bits in the HARQ buffer 200. When some received bits are decoded correctly while others cannot be decoded, HARQ retransmission is initiated. In prior art solutions, all of the soft bits are saved in the buffer 200 for combining with the HARQ retransmission. In the HARQ buffer management method 100, the mobile station 60 saves the correctly decoded FEC blocks as data bits, while the coded soft bits are evacuated from the buffer 200. Only FEC blocks that were not decoded correctly are saved in the form of soft bits.
Buffer Occupancy Feedback
In order to allow the base station 70 to optimally use the HARQ buffer 200, the HARQ buffer management method 100 uses two kinds of feedback from the mobile station 60 to the base station 70, as shown in FIG. 1. First, the HARQ buffer size 50 is reported by the mobile station 60 to the base station. In some embodiments, the mobile station 60 reports as a capability the number of coded soft bits that can be saved in its HARQ buffer 200. Also, the buffer occupancy notification 40 is reported by the mobile station 60 to the base station 70. The buffer occupancy 40 is a measure of the buffer usage efficiency. In some embodiments, the buffer occupancy 40 is reported to the base station 70 either upon request (on demand) or periodically.
On-Demand Buffer Occupancy Feedback Reporting Mechanism
Since HARQ buffer overflow happen irregularly, it is more efficient to feed back buffer management-related information on demand. The HARQ buffer management method 100 reports two kinds of status, in some embodiments. For the buffer occupancy 40, a ratio threshold, BufThr, is predefined. When the buffer occupancy 40 exceeds the BufThr threshold, the mobile station 60 sends a notification to the base station 70.
For example, assume that the buffer threshold, BufThr, is 40%. When the buffer occupancy 40 exceeds 40% (meaning that at least 40% of the buffer 200 is occupied, or full, of data), the mobile station 60 will notify the base station 70. The notification can thus be accomplished with a single bit, in some embodiments. While the buffer occupancy 40 is less than 40%, no notification will be sent.
Second, the HARQ buffer management method 100 feeds back buffer overflow information 30 to the base station 70. In this case, the mobile station 60 sends a notification to the base station 70 when the HARQ buffer 200 overflows since last being reported.
There are different ways to report on-demand buffer occupancy 40 and buffer size 50 mentioned above. In some embodiments, the HARQ buffer management method 100 uses a primary fast feedback channel (PFBCH) to feed back the buffer occupancy 40 and overflow notification on demand by reserving two code-words in the PFBCH, one code word to represent buffer occupancy and the other code word to represent buffer overflow on demand.
FIG. 6 is a table 24 showing a possible code word sequence for reporting buffer overflow 30 and buffer occupancy 40 using the PFBCH by the HARQ buffer management method 100, according to some embodiments. Some of the sequences are reserved for channel quality indicator (CQI) reporting. Two code words, denoted X+1 and X+2, are defined to report buffer information to the base station 70 by the mobile station 60. The code word, X+1, indicates the buffer occupancy 40, whether the buffer 200 exceeds the predefined threshold, BufThr, or not. The code word, X+2, notifies the base station 70 of an overflow of the HARQ buffer 200 (buffer overflow 30).
As another option, a bandwidth request channel (BWRCH) may be used to send a one-bit message to represent the buffer occupancy 40 and the buffer overflow 30 on demand. Thus, instead of the code words defined in the table 24 (FIG. 6), a single bit may be defined for each of these buffer status indicators. Additionally, the secondary fast feedback channel (SFBCH) may be used to feed back the buffer size 50. FIG. 7 has a table showing the various options for reporting this data to the base station 70 by the mobile station 60.
Thus, the buffer size 50, the buffer overflow indicator 30 and the buffer occupancy status 40 may be reported using an uplink feedback channel, such as the PFBCH, the SFBCH, the BWRCH, or other channels. In still other embodiments, the buffer size 50, the buffer overflow indicator 30, and the buffer occupancy status 40 may be reported using a single type feedback channel, such as the physical uplink control channel (PUCCH) in long-term evolution (LTE) systems.
While the application has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of the invention.

Claims

1. A method to manage a hybrid automatic repeat request (HARQ) buffer, the method comprising:

transmitting a buffer size to a base station, the buffer size indicating the size of the HARQ buffer, wherein the buffer size is transmitted when the size of the HARQ buffer changes;

if the HARQ buffer overflows, transmitting a buffer overflow indicator to the base station; and

managing the size of the HARQ buffer without input from the base station.

2. The method of claim 1, further comprising:

if occupancy of the buffer exceeds a predetermined threshold, transmitting a buffer occupancy notification to the base station.

3. The method of claim 1, transmitting a buffer size to a base station further comprising:

transmitting the buffer size in a secondary fast feedback channel to the base station.

4. The method of claim 2, transmitting a buffer occupancy notification to the base station further comprising:

transmitting the buffer occupancy notification as a code word using a primary fast feedback channel to the base station.

5. The method of claim 2, transmitting a buffer occupancy notification to the base station further comprising:

transmitting the buffer occupancy notification as a bit using a bandwidth request channel.

6. The method of claim 2, further comprising:

transmitting the buffer occupancy notification and buffer overflow indicator as a code word using a primary fast feedback channel to the base station.

7. The method of claim 2, further comprising:

transmitting the buffer size, buffer occupancy notification, and buffer overflow indicator using an uplink feedback channel.

8. The method of claim 1, managing the size of the HARQ buffer without input from the base station further comprising:

evacuating correctly decoded forward error correction blocks from the HARQ buffer.

9. The method of claim 1, managing the size of the HARQ buffer without input from the base station further comprising:

evacuate soft parity bits from the HARQ buffer; and

store systematic bits in the HARQ buffer, wherein the systematic bits positively affect decoder performance.

10. The method of claim 1, managing the size of the HARQ buffer without input from the base station further comprising:

not storing mother coded bits in the HARQ buffer.

11. The method of claim 1, managing the size of the HARQ buffer without input from the base station further comprising:

storing some blocks received from the base station into the HARQ buffer in a compressed manner that enables HARQ combining gain while using fewer memory bits; and

not storing some other blocks received from the base station into the HARQ buffer;

wherein the stored blocks are sufficient to decode as a lossy version of data transmitted by the base station.

12. A method to manage a hybrid automatic repeat request (HARQ) buffer, the method comprising:

receiving a buffer size from a mobile station, the buffer size indicating the size of the HARQ buffer within the mobile station, wherein the buffer size is received when the size of the HARQ buffer changes;

if the HARQ buffer overflows, receiving a buffer overflow indicator from the mobile station; and

managing the traffic rate to the mobile station without managing the HARQ buffer.

13. The method of claim 12, further comprising:

if occupancy of the HARQ buffer exceeds a predetermined threshold, receiving a buffer occupancy notification from the mobile station.

14. The method of claim 12, receiving a buffer size from a mobile station further comprising:

receiving a buffer size from a secondary fast feedback channel, wherein the secondary fast feedback channel comprises up to twenty-four bits.

15. The method of claim 13, further comprising:

receiving the buffer overflow indicator and buffer occupancy notification as a code word in a primary fast feedback channel.

16. The method of claim 12, further comprising:

receiving the buffer overflow indicator as a bit in a bandwidth request channel.

17. The method of claim 13, further comprising:

receiving the buffer occupancy notification as a bit in a bandwidth request channel.

18. A method, comprising:

managing a hybrid automatic repeat request (HARQ) buffer for use in a wireless system, wherein the management comprises:

sending a size of the HARQ buffer to a serving base station when the size of the HARQ buffer changes;

sending a buffer overflow indication to the base station if the buffer is full; and

sending a buffer occupancy indicator to the base station if the buffer contents exceed a predetermined threshold.

19. The method of claim 18, managing a HARQ buffer further comprising:

receiving blocks from the base station, the blocks comprising both decode bits and receive bits;

storing the decode bits in the HARQ buffer; and

not storing the receive bits in the HARQ buffer.

20. The method of claim 19, not storing the receive bits in the HARQ buffer further comprising:

not storing forward error correction bits in the HARQ buffer.