Abstract:
A network interface including: a physical layer device configured to transmit frames received from a host to a network; and a medium access control device configured to receive a first frame of the frames, and iteratively transmit the first frame to the physical layer device based on a first set of parameters until at least one of (i) the physical layer device receives an acknowledgement signal indicating that the first frame has been successfully transmitted, (ii) a number of unsuccessful transmissions of the first frame is equal to a predetermined count value, or (iii) a predetermined period expires prior to successful transmission of the first frame, wherein the first set of parameters comprise a first plurality of transmission parameters.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. application Ser. No. 12/550,841, filed Aug. 31, 2009, which is a continuation of U.S. application Ser. No. 11/305,875 (now U.S. Pat. No. 7,583,649), filed Dec. 16, 2005, which claims priority under 35 U.S.C. §119(e) to U.S. Provisional Application No. 60/707,791, filed Aug. 12, 2005. The disclosures of the applications referenced above are incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     The present invention relates to wireless communications systems, and more particularly to adjustable transfer rates for frames in wireless communications systems. 
     BACKGROUND 
     Referring now to  FIG. 1 , an exemplary block diagram of a network interface  10  includes a medium access control (MAC) device  12  that communicates with a physical layer device  14  (or PHY). The physical layer device  14  selectively communicates with one or more antennae  16  in order to transmit and receive radio frequency (RF) signals through a wireless medium. The MAC device  12  also communicates with a host  18  and receives data from the host  18  for transmission. The MAC device  12  processes the data and encodes frames according to a pre-established protocol. For example, the MAC device  12  may generate frames according to IEEE 802.11, 802.11a, 802.11b, 802.11g, 802.11h, 802.11n, 802.16, and/or 802.20, which are all hereby incorporated by reference in their entireties. 
     Since frames may be of different types and may correspond to different Quality of Service (QoS) priority levels, the MAC device  12  includes a queue module  20 . Frames that are intended for transmission through the wireless medium are first written by firmware into several queues within the queue module  20 . These frames are then scheduled for transmission according to a set of scheduler rules using the queues&#39; priority levels. 
     Referring now to  FIG. 2 , the queue module  20  includes an exemplary transmit queue  28 . Frames awaiting transmission on the wireless network are stored in the transmit queue  28 . For illustrative purposes, the transmit queue  28  is shown with six frames, although a larger or smaller number of frames is possible. Each of the frames includes a transmission information portion  30  and a frame body portion  32 . The transmission information portion  30  includes headers and/or fields that are applicable to the transmission characteristics, including transfer rate, of the frame. 
     The frame body portion  32  is the actual body of the frame and includes any data (payload) that is being transmitted. In various implementations, the queue module  20  includes multiple transmit and/or receive queues. For example, frames that are encoded according to a first coding scheme may be stored in a first transmit queue and frames that are encoded according to a second coding scheme may be stored in a second transmit queue. 
     A desired transmit rate for a frame is conveyed by firmware to the MAC hardware via one or more fields in the transmission information portion  30  of the frame. Referring now to  FIGS. 3A and 3B , the desired transmit rate for a frame is indicated in the PHY preamble via one or more fields such as LT-SIG, HT-SIG 1 , HT-SIG 2 .  FIG. 3A  illustrates an exemplary legacy signal field LT-SIG in the PHY preamble of a frame encoded in an IEEE 802.11 legacy mode format. For example, frames encoded according to IEEE 802.11a, 802.11b, and/or 802.11g standards may be in a legacy mode format. In this case, the transmit rate of the frame is identified by eight bits of a Rate field  40  (identified as LT-SIG in  FIG. 3A ) included in the LT-SIG  30 - 1 . In various implementations, a total of fourteen legacy rates are supported. Rate information is specified by firmware by writing an index (between 0 and 13) into the 4-bit Rate field  60  in the transmission information portion  30  of the queued frame. The MAC hardware provides the corresponding 8-bit encoded value to the PHY to use in the Rate field  40  of LT-SIG. 
     Frames may also be encoded in a high throughput (HT) mode format. For example, frames encoded according to IEEE 802.11n should be in an HT mode format. IEEE 802.11n is directed towards wireless communications systems that take advantage of spatial diversity multiplexing (or multipath) by utilizing multiple transmit and/or receive antennae  16 .  FIG. 3B  illustrates exemplary HT signal fields HT-SIG 1  and HT-SIG 2  in the PHY preamble of a frame encoded in an IEEE HT mode format. Since frames in an HT mode format may be transmitted and/or received by multiple antennae  16 , there are several parameters that contribute to the overall transmit rate that is achieved. 
     Frames encoded in an IEEE FIT mode format include first and second signal fields  42  and  44 , respectively, that are transmitted back-to-back (identified in  FIG. 3B  as HT-SIG 1  and HT-SIG 2 ). The first signal field  42  (HT-SIG 1 ) includes a modulation coding scheme (MCS) field  46  and 20/40 BW field  50 . The MCS field  46  is defined by seven bits and conveys the number of spatial streams (e.g., 1, 2, 3, or 4), a modulation scheme (e.g., BPSK, QPSK, 16-QAM, or 256-QAM), and a coding rate (e.g., ½, ¾, ⅔, or ⅞), which all contribute to transmit rate. The 20/40 BW field  50  identifies whether the current bandwidth (BW) is 20 MHz or 40 MHz. The second signal field  44  (HT-SIG 2 ) includes Short GI field  48 . The Short GI field  48  identifies whether a short guard interval (GI) is used. Guard interval status and bandwidth both also contribute to transmit rate. For an HT frame, the firmware specifies the rate information by writing to the MCS, BW, GI sub-fields included in the RateInfo field  106  in the transmission information portion of the queued frame. 
     The MAC device  12  generally sets the transmit rate of a frame by firmware encoding the appropriate fields in the transmission information portion  30  of the frame before storing the frame in the transmit queue  28 . However, the conditions of multiple wireless channels that are utilized by spatial diversity multiplexing systems are capable of changing due to many factors, including obstruction and line-of-sight (LOS) losses. When wireless channel quality degrades, the MAC device  12  may not receive the acknowledgement (ACK), indicating successful transmission of a frame, from a remote network interface. It is also possible that a negative acknowledgement (NACK) may be received from the remote network interface, but this mechanism becomes less reliable as channel quality degrades. 
     When a frame has not been successfully acknowledged, conventional wireless communications systems may attempt to retransmit the frame. However, the conditions of the wireless channel may not be able to support the desired transmit rate encoded in the frame. A further limitation is that the MAC device  12  is typically incapable of adjusting transmission parameters of the frame once the frame has been stored in the transmit queue  28 . 
     SUMMARY 
     A network interface including: a physical layer device configured to transmit frames received from a host to a network; and a medium access control device configured to receive a first frame of the frames, and iteratively transmit the first frame to the physical layer device based on a first set of parameters until at least one of (i) the physical layer device receives an acknowledgement signal indicating that the first frame has been successfully transmitted, (ii) a number of unsuccessful transmissions of the first frame is equal to a predetermined count value, or (iii) a predetermined period expires prior to successful transmission of the first frame, wherein the first set of parameters comprise a first plurality of transmission parameters. 
     In still other features, the systems and methods described above are implemented by a computer program executed by one or more processors. The computer program can reside on a computer readable medium such as but not limited to memory, non-volatile data storage and/or other suitable tangible storage mediums. 
     Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration-only and are not intended to limit the scope of the invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein: 
         FIG. 1  is a functional block diagram of an exemplary wireless network interface that includes multiple transmit/receive antennae according to the prior art; 
         FIG. 2  is a functional block diagram of an exemplary transmit queue that is included in the queue module of  FIG. 1  according to the prior art; 
         FIG. 3A  illustrates an exemplary legacy signal field in the PHY preamble portion of a frame that is encoded in an IEEE legacy mode format according to the prior art; 
         FIG. 3B  illustrates exemplary high throughput signal fields in the PHY preamble portion of a frame that is encoded in an IEEE high throughput (HT) mode format according to the prior art; 
         FIG. 4  illustrates an exemplary transmission information portion of a frame including a single alternate transmit rate according to the present invention; 
         FIG. 5  is a functional block diagram of an exemplary wireless network interface including a rate adaptation module and an associated memory module according to the present invention; 
         FIG. 6  is a table illustrating one possible configuration of the TX MODE register including a DisableRateDrop field that is capable of disabling the rate adaptation system; 
         FIG. 7  is a table illustrating an exemplary transmission information portion of a frame including a rate drop table pointer that identifies a rate drop table stored in the memory module; 
         FIG. 8  is a table illustrating an exemplary auto rate drop table stored in the memory module that includes multiple tiered transmit parameters; 
         FIG. 9  is a table illustrating exemplary contents of each entry in the auto rate drop table including transmission parameters and an associated retry count; 
         FIG. 10  is a table illustrating an exemplary frame transmit parameter field; 
         FIG. 11  is a table illustrating an exemplary configuration of a Rate Drop Update register including an UpdateDropTable field that is capable of alerting the rate adaptation module of changes in the auto rate drop table; 
         FIG. 12  is a graph conceptually illustrating transmission parameters as a function of time in a tiered rate adaptation algorithm according to the present invention; 
         FIG. 13  is a flowchart illustrating exemplary steps performed by the rate adaptation module of  FIG. 5  for each frame transmitted; 
         FIG. 14A  is a functional block diagram of a high definition television; 
         FIG. 14B  is a functional block diagram of a vehicle control system; 
         FIG. 14C  is a functional block diagram of a cellular phone; 
         FIG. 14D  is a functional block diagram of a set top box; and 
         FIG. 14E  is a functional block diagram of a media player. 
     
    
    
     DETAILED DESCRIPTION 
     The following description of the preferred embodiments is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses. For purposes of clarity, the same reference numbers will be used in the drawings to identify similar elements. As used herein, the term module, circuit and/or device refers to an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A or B or C), using a non-exclusive logical or. It should be understood that steps within a method may be executed in different order without altering the principles of the present invention. 
     Referring now to  FIG. 4 , in an exemplary implementation, a transmission information portion  58  of a frame includes a first rate value  60  (Rate), a second rate value  62  (RateID), and a retry threshold  64  (RetryThr). In various implementations, the first rate  60  occupies bits  3  to  0  of a field and the second rate  62  occupies bits  7  to  4  of the same field. The retry threshold  64  occupies bits  7  to  0  of a second field. Register and bit assignments may differ from the exemplary implementations presented here without departing from the principles of the present invention. Non-limiting examples include storing values in different registers or different fields, using more or fewer bits to store a value, using different numerical values to indicate the same setting, and multiplexing multiple settings within a single group of bits. 
     During normal operating conditions, the frame is sent at the first rate  60 . If an ACK is not received, the frame is resent at the same rate  60 . The retry threshold  64  identifies how many times the frame may be resent at the current rate  60 . Once the number of consecutive retries reaches the retry threshold  64 , the frame is resent at the second rate  62 . 
     In a wireless channel, transmitting a frame at a lower rate typically increases the likelihood that an ACK will be received. Therefore, the second rate  62  is generally lower than the first rate  60 . The implementation illustrated in  FIG. 4  provides for a greater degree of rate flexibility, though it is still limited to a single alternate rate  62 . When wireless channel conditions are very adverse, however, even the alternative rate  62  may be too high. 
     Referring now to  FIG. 5 , a tiered automatic transmit rate adjustment system according to the present invention allows the transmission parameters of a frame to be adjusted an arbitrary number of times to ensure successful transmission of the frame. An exemplary network interface  72  includes a medium access control (MAC) device  74  that communicates with a physical layer device (PHY)  76 . The physical layer device  76  selectively communicates with one or more antennae  78  in order to transmit and receive radio frequency (RF) signals through a wireless medium. The MAC device  74  receives data from a host  80  for communication over a wireless network via the antennae  78 . 
     The MAC device  74  processes the data and encodes frames according to a pre-established protocol. For example, the MAC device  74  may generate frames that are compliant with IEEE 802.11, 802.11a, 802.11b, 802.11g, 802.11h, 802.11n, 802.16, 802.20, and/or other present and future standards. The MAC device  74  stores encoded frames that are ready for transmission in a queue module  82 . In various implementations, the queue module  82  includes multiple transmit and/or receive queues that are each capable of handling varying groups of frames. The MAC device  74  further includes a rate adaptation module  84 , a memory module  86 , and a register module  88 . During normal operation, the rate adaptation module  84  reads the frame that is to be next transmitted from the queue module  82 . The rate adaptation module  84  then determines rate parameters used to transmit the frame. 
     In various implementations according to the principles of the present invention, transmit parameters for the frames are no longer simply stored in static fields. Instead, each frame includes a pointer that identifies a location in the memory module  86  where a table containing transmission parameters is stored. This table can include more than a single alternative transmit rate to be used in the event that the MAC device  74  is unsuccessful at transmitting the frame at the original rate. For example, the table may include a first set of transmission parameters, a second set of parameters to be used after a specified number of failed transmission attempts, a third set of parameters to be used after a specified number of further failed transmission attempts, etc. 
     Each set of transmission parameters stored in the tables of the memory module  86  are stored with an associated count value. The count value identifies the number of times that the MAC device  74  may consecutively attempt to resend a frame using the corresponding transmission parameters before changing to the next set of transmission parameters. Each set of transmission parameters will generally have a lower transmission rate than the previous set to account for the continued failed transmission of the frame. The register module  88  includes a plurality of registers that are utilized by the MAC device  74  for system control, including control of the rate adaptation module  84 , as described below. 
     The register module  88  includes a 32-bit register called TX MODE, the relevant portion of which is depicted in  FIG. 6 . The TX MODE register includes a field called DisableRateDrop (bit  1  of the TX MODE register in this implementation)  96 . A nonzero value for DisableRateDrop 96 indicates that the automatic rate adjustment system is disabled. By default, DisableRateDrop 96 is cleared and thus the rate adjustment system is initially enabled. Even when the rate adjustment system is disabled, the MAC device  74  is still able to transmit frames. This is because the frames contain a fixed transmission parameter field, which can be used by the MAC device  74 . Under most circumstances, these fixed fields are only utilized when the rate adjustment system is disabled. 
     Referring now to  FIG. 7 , a transmission information portion according to the present invention of a frame includes a pointer field (Rate drop table pointer)  104  as well as a fixed transmission parameter field (RateInfo)  106 . As discussed above, the fixed transmission parameters  106  are used when the rate adaptation system is disabled. Otherwise, when the rate adaptation system is enabled, the rate adaptation module  84  fetches a transmission parameter table (or rate drop table) from the location in the memory module  86  that is identified by the frame&#39;s pointer field  104 . In various implementations, the pointer field  104  is a 32-bit value. 
     The transmission information portion of the frame also includes two count fields, RetryCnt  108  and RetryDone  110 . RetryCnt  108  is written when the frame is first queued by software, and indicates the maximum number of times transmission of the frame should be attempted. RetryDone  110  is set to zero when the frame is queued by software, and indicates the total number of times transmission has been attempted for the frame. RetryDone  110  retains the total number of transmit attempts, which is useful if transmission of the frame is delayed and the frame has to be requeued, such as when a higher priority transmission, like a beacon transmission, interrupts. In this way, when transmission of the frame resumes, the rate adaptation system resumes transmitting with the previous parameters. 
     The transmission information portion of the frame also includes a field TxParam  112 , which in turn includes a subfield NoRateDrop (bit  12  of the TxParam field in one implementation)  114 . The subfield NoRateDrop  114  allows rate adaptation to be disabled with respect to individual frames. This is in contrast to globally disabling rate adaptation for all frames via the DisableRateDrop field  96  in the TX MODE register. 
     Referring now to  FIG. 8 , an exemplary transmit rate table  120 , which is stored in the memory module  86 , is shown. This table is selected when a frame&#39;s transmission information includes a pointer (Rate drop table pointer field  104 ) to the starting address of this table. While the implementation shown in  FIG. 8  includes four sets (RateChange fields) of transmission parameters and count values, the memory module  86  is capable of storing a larger number (e.g., eight or sixteen). Additionally, the memory module  86  may include multiple transmit rate tables, each accessible by storing a different value to the pointer field  104 . 
     Using a memory module  88  that is separate from storage for queued frames to indicate transmission parameters allows the parameters to be accessed and/or updated by the MAC device  74  at any time. For example, the memory module  88  is remotely located from the Queue module  82 . Conversely, frames cannot typically be accessed or updated once they are stored in a transmit queue. Therefore, even after a frame has been queued (but not yet fetched for transmission), the transmission parameters with which the frame will be transmitted can be programmed by the MAC device  74 . In various implementations, a device may include only one rate table  120 . In these implementations, frames may not have a pointer, as there is only one rate table  120 . 
     Referring now to  FIG. 9 , an exemplary bit assignment for each of the entries (RateChange fields) in the transmit rate table of  FIG. 8  is shown. A 16-bit transmission parameter subfield (RateInfo)  122  includes transmit parameters, described in detail below. A 4-bit count subfield (Count)  124  identifies the maximum number of times that a frame utilizing the transmission parameters identified by the RateInfo subfield  122  may be resent before progressing to the next RateChange field. 
     The MAC device  74  first attempts to transmit a frame using the transmission parameters (RateInfo) of the first entry in the rate drop table  120  (RateChange  0 ). If transmission is unsuccessful, the MAC device  74  retries transmission and compares the number of retries to the value of the Count subfield  124  of RateChange  0 . When the number of retries reaches Count  124  of RateChange  0 , the MAC device  74  progresses to the second entry in the rate drop table  120  (RateChange  1 ). Once the number of retries at this second RateChange reaches the Count  124  of RateChange  1 , the MAC device progresses to the third entry in the rate drop table  120  (RateChange  2 ). This process continues until the last table entry is reached. Count  124  is not defined for the final table entry—transmission will continue using the final RateInfo until the maximum number of retries (RetryCnt) is exhausted. 
     The rate drop table  120  also allows a frame to be deleted after it has been queued for transmission. A DropFrame subfield  126  of the RateChange field is defined (bit  31  of the RateChange field in one implementation). When the DropFrame subfield  126  has a nonzero value, the MAC device  74  drops the frame without any transmission attempts. Because this drop will happen prior to attempting transmission at any rate, the DropFrame subfield  126  is defined only for the first table entry (RateChange  0 ). 
     Referring now to  FIG. 10 , exemplary transmission parameters (RateInfo) are depicted. RateInfo is specified statically in the transmission information portion of the frame (when rate adaptation is disabled) and is specified for each entry in each drop rate table (for use with rate adaptation). While the system depicted in  FIG. 4  executed automatic transmit rate drops simply by changing a 4-bit RateID, the exemplary transmission parameters illustrated in  FIG. 10  provide for greater control and flexibility. For example, the RateInfo field can accommodate frames in both legacy and HT (high throughput) mode formats. 
     A 1-bit format subfield  134  identifies whether the frame is in a legacy mode or HT (high throughput) mode format. Short guard interval (ShortGl) and bandwidth (BW) subfields  136  and  138 , respectively, are both specific to the HT mode format, and described above. The actual transmission rate value is stored in a rate (RateID) subfield  140 . The RateID subfield  140  is seven bits wide to accommodate either a 4-bit legacy transmit rate or a 7-bit HT transmission rate. A 2-bit antenna selection (AntSelect) subfield  142  allows for selection of a specific transmit antenna. A preamble (PreambleType) field  144  identifies the preamble type (long or short) for systems that are compatible with legacy IEEE 802.11b standards. A 2-bit active sub-channel selection (ActiveSubCh) subfield allows the selection of the upper or lower sub-channels or both for transmission. 
     Referring now to  FIG. 11 , the relevant portion of a Rate Drop Update Register (located in the register module  88 ) is depicted. It would not be efficient for the rate adaptation module  84  to repeatedly read a rate drop table from memory for each frame transmitted. If consecutive frames use the same rate drop table, the rate adaptation module  84  should be able to use the rate drop table it has already read. This is the case when the pointer  104  for a frame is identical to the pointer  104  for the previous frame. This approach, however, does not account for when the table has been altered in memory  86  after it was first read. 
     A nonzero value in an UpdateDropTable field  152  within the Rate Drop Update Register forces the rate adaptation module  84  to re-read the rate drop table for the next frame to be transmitted. The UpdateDropTable field  152  is therefore set to one when the memory module  86  is edited. As a result, in addition to checking for changes in consecutive pointer  104  values, the rate adaptation module  84  also checks the status of the Rate Drop Update Register. This ensures that the most updated transmission parameters are applied to each frame. 
     Referring now to  FIG. 12 , a graphical representation of an exemplary adaptation in transmit rates for a frame is depicted. The MAC device  74  first attempts to transmit the frame using RateInfo  0 . After Count  0  unsuccessful attempts, the MAC device  74  attempts to transmit the frame using RateInfo  1 . If an additional Count  1  attempts are unsuccessful, transmission is attempted using RateInfo  2 . Once the final RateInfo (here, 3) is reached, the frame may be dropped and/or stored in a queue reserved for unsuccessfully transmitted frames. In various implementations, a single queue (DoneQ) stores pointers for all transmitted frames, whether passed or dropped. A status field in the transmission information part of each frame is updated by the MAC  84  to indicate pass/drop status, and a failure code subfield indicating the reason for the drop may be included. 
     Referring now to  FIG. 13 , a rate adaptation algorithm begins in step  162 , where the frame to be transmitted next is read from the transmit queue  82 . Control also reads the TX MODE register. In step  164 , control determines whether the DisableRateDrop bit  96  of the TX MODE register is set and whether the NoRateDrop bit  114  (of the frame&#39;s transmission information) is set. If either bit is set, automatic rate adaptation will not be used for this frame and control transfers to step  166 ; otherwise, control transfers to step  168 . In step  166 , control transmits the frame using the parameters set in the frame&#39;s RateInfo field  106  and control ends. 
     In step  168 , control determines whether the previously transmitted frame used automatic rate adaptation. If not, a drop table will need to be fetched and control transfers to step  170 . If the previous frame did use auto rate adaptation, control transfers to step  172 . In step  172 , the Rate Drop Update register is read and control transfers to step  174 . In step  174 , control determines whether the pointer field  104  of the current frame is different than the previous frame and determines whether the UpdateDropTable bit  152  of the Rate Drop Update register is set. If either condition is true, a new drop table needs to be fetched and control transfers to step  170 ; otherwise, control transfers to step  176 . 
     In step  170 , a drop table is fetched from memory at the location referenced by the frame&#39;s pointer field  104  and the UpdateDropTable bit  152  is cleared. Control then continues at step  176 , where control determines whether the DropFrame bit  126  (of the drop table&#39;s first RateChange field) is set. If the bit is set, the frame is dropped and control ends; otherwise, control transfers to step  178 . 
     In step  178 , variables RateInfo and Count are determined using the frame&#39;s current value of RetryDone and the fetched drop table. These variables can be determined, for an exemplary eight-tier implementation, using the following pseudocode: 
     if (retryDone&lt;(Count=Count[0])) 
     
         
         
           
             RateInfo=RateInfo[0];
 
else if (retryDone&lt;(Count Count[1])
 
             RateInfo=RateInfo[1];
 
else if (retryDone&lt;(Count+=Count[2]))
 
             RateInfo=RateInfo[2];
 
else if (retryDone&lt;(Count+=Count[3]))
 
             RateInfo=RateInfo[3];
 
else if (retryDone&lt;(Count+=Count[4]))
 
             RateInfo=RateInfo[4];
 
else if (retryDone&lt;(Count+=Count[5]))
 
             RateInfo=RateInfo[5];
 
else if (retryDone&lt;(Count+=Count[6]))
 
             RateInfo=RateInfo[6];
 
else {
 
             Count=0; 
             RateInfo=RateInfo[7]; 
             }. 
           
         
       
    
     In the foregoing pseudocode, RateInfo[n] refers to the RateInfo for the nth drop table entry (nth RateChange field). Likewise, Count[n] refers to the Count value for the nth drop table entry (nth RateChange field). The += operator adds the value to the right of the operator to the value to the left of the operator and stores the result in the variable to the left of the operator. In this way, Count represents the cumulative number of retries before the corresponding tier of the drop table is exhausted, while Count[n] represents only the number of retries within the current tier. For the last tier, Count is set to 0 because there is no end to the last tier—the frame will continue to be transmitted until the overall limit on retries (RetryCnt) is reached. 
     Control continues in step  180 , where control attempts to transmit the frame using the RateInfo parameters determined in step  178 . Control continues in step  182 , where the frame&#39;s RetryCnt field  108  is deeremented and the frame&#39;s RetryDone field  110  is incremented. Control continues in step  184 , where if an acknowledgment (ACK) is received, control ends; otherwise, control transfers to step  186 . In step  184 , the ACK receipt may be determined in a number of ways, but in one implementation, receipt is determined after a specified period of time (timeout). 
     In step  186 , if RetryCnt is equal to zero, all the retries for this frame have been exhausted and control ends; otherwise, control transfers to step  188 . In step  188 , control compares RetryDone to the value of Count determined in step  178 . If RetryDone is not equal to Count, the next retry will be attempted using the current RateInfo, and control returns to step  180 . If RetryDone is equal to Count, the number of retries has been exhausted for the current rate drop table tier, and control returns to step  178  to determine the new RateInfo and Count. 
     Referring now to  FIGS. 14A-14E , various exemplary implementations of the present invention are shown. Referring now to  FIG. 14A , the present invention can be implemented in a high definition television (HDTV)  420 . For example, the present invention may implement and/or be implemented in a WLAN interface  429  of the HDTV  420 . The HDTV  420  receives HDTV input signals in either a wired or wireless format and generates HDTV output signals for a display  426 . In some implementations, signal processing circuit and/or control circuit  422  and/or other circuits (not shown) of the HDTV  420  may process data, perform coding and/or encryption, perform calculations, format data and/or perform any other type of HDTV processing that may be required. 
     The HDTV  420  may communicate with mass data storage  427  that stores data in a nonvolatile manner such as optical and/or magnetic storage devices. For example, the mass data storage  427  may include a hard disk drive (HDD) and/or a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8″. The HDTV  420  may be connected to memory  428  such as RAM, ROM, low latency nonvolatile memory such as flash memory, and/or other suitable electronic data storage. The HDTV  420  also may support connections with a WLAN via the WLAN network interface  429 . 
     Referring now to  FIG. 14B , the present invention may be implemented in a vehicle  430 . For example, the present invention may implement and/or be implemented in a WLAN interface  448  of the vehicle  430 . In some implementations, the present invention may be implemented in a powertrain control system  432  that receives inputs from one or more sensors such as temperature sensors, pressure sensors, rotational sensors, airflow sensors and/or any other suitable sensors and/or that generates one or more output control signals such as engine operating parameters, transmission operating parameters, and/or other control signals. 
     The present invention may also be implemented in other control systems  440  of the vehicle  430 . The control system  440  may likewise receive signals from input sensors  442  and/or output control signals to one or more output devices  444 . In some implementations, the control system  440  may be part of an anti-lock braking system (ABS), a navigation system, a telematics system, a vehicle telematics system, a lane departure system, an adaptive cruise control system, a vehicle entertainment system such as a stereo, DVD, compact disc and the like. Still other implementations are contemplated. 
     The powertrain control system  432  may communicate with mass data storage  446  that stores data in a nonvolatile manner. The mass data storage  446  may include optical and/or magnetic storage devices, for example hard disk drives HDD and/or DVDs. At least one HDD may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8″. The powertrain control system  432  may be connected to memory  447  such as RAM, ROM, low latency nonvolatile memory such as flash memory and/or other suitable electronic data storage. The powertrain control system  432  also may support connections with a WLAN via the WLAN network interface  448 . The control system  440  may also include mass data storage, memory, and/or a WLAN interface (all not shown). 
     Referring now to  FIG. 14C , the present invention can be implemented in a cellular phone  450  that may include a cellular antenna  451 . For example, the present invention may implement and/or be implemented in a WLAN interface  468  of the cellular phone  450 . In some implementations, the cellular phone  450  includes a microphone  456 , an audio output  458  such as a speaker and/or audio output jack, a display  460  and/or an input device  462  such as a keypad, pointing device, voice actuation and/or other input device. The signal processing and/or control circuits  452  and/or other circuits (not shown) in the cellular phone  450  may process data, perform coding and/or encryption, perform calculations, format data and/or perform other cellular phone functions. 
     The cellular phone  450  may communicate with mass data storage  464  that stores data in a nonvolatile manner such as optical and/or magnetic storage devices for example hard disk drives HDD and/or DVDs. At least one HDD may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8″. The cellular phone  450  may be connected to memory  466  such as RAM, ROM, low latency nonvolatile memory such as flash memory and/or other suitable electronic data storage. The cellular phone  450  also may support connections with a WLAN via the WLAN network interface  468 . 
     Referring now to  FIG. 14D , the present invention can be implemented in a set top box  480 . For example, the present invention may implement and/or be implemented in a WLAN interface  496  of the set top box  480 . The set top box  480  receives signals from a source such as a broadband source and outputs standard and/or high definition audio/video signals suitable for a display  488  such as a television and/or monitor and/or other video and/or audio output devices. The signal processing and/or control circuits  484  and/or other circuits (not shown) of the set top box  480  may process data, perform coding and/or encryption, perform calculations, format data and/or perform any other set top box function. 
     The set top box  480  may communicate with mass data storage  490  that stores data in a nonvolatile manner. The mass data storage  490  may include optical and/or magnetic storage devices, for example hard disk drives HDD and/or DVDs. At least one HDD may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8″. The set top box  480  may be connected to memory  494  such as RAM, ROM, low latency nonvolatile memory such as flash memory and/or other suitable electronic data storage. The set top box  480  also may support connections with a WLAN via the WLAN network interface  496 . 
     Referring now to  FIG. 14E , the present invention can be implemented in a media player  500 . For example, the present invention may implement and/or be implemented in a WLAN interface  516  of the media player  500 . In some implementations, the media player  500  includes a display  507  and/or a user input  508  such as a keypad, touchpad and the like. In some implementations, the media player  500  may employ a graphical user interface (GUI) that typically employs menus, drop down menus, icons and/or a point-and-click interface via the display  507  and/or user input  508 . The media player  500  further includes an audio output  509  such as a speaker and/or audio output jack. The signal processing and/or control circuits  504  and/or other circuits (not shown) of the media player  500  may process data, perform coding and/or encryption, perform calculations, format data and/or perform any other media player function. 
     The media player  500  may communicate with mass data storage  510  that stores data such as compressed audio and/or video content in a nonvolatile manner. In some implementations, the compressed audio files include files that are compliant with MP3 format or other suitable compressed audio and/or video formats. The mass data storage may include optical and/or magnetic storage devices for example hard disk drives HDD and/or DVDs. At least one HDD may be a mini HDD that includes one or more platters having a diameter that is smaller than approximately 1.8″. The media player  500  may be connected to memory  514  such as RAM, ROM, low latency nonvolatile memory such as flash memory and/or other suitable electronic data storage. The media player  500  also may support connections with a WLAN via the WLAN network interface  516 . Still other implementations in addition to those described above are contemplated. 
     Those skilled in the art can now appreciate from the foregoing description that the broad teachings of the present invention can be implemented in a variety of forms. Therefore, while this invention has been described in connection with particular examples thereof, the true scope of the invention should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, the specification and the following claims.