An automatic repeat-reQuest (arq) reset method for an arq transmitter disables (120) transmission, starts (130) an arq transmitter window at a first unacknowledged block, and discards (140) service data units (sdus) in the arq transmitter window having zero blocks in a ‘not-sent’ state. Thus, for all sdus having no blocks in a ‘not-sent’ state, the blocks in an ‘outstanding’ or ‘waiting-for-retransmission’ state are changed to a ‘discard’ state. Next, the arq transmitter sets (150) the state of all blocks in partially unsent sdus of the arq transmitter window to ‘not-sent.’ So, any remaining blocks in an ‘outstanding,’ ‘waiting-for-transmission’ or ‘discard’ state are changed to ‘not-sent.’ After the arq transmitter enables (160) transmission and ends (190) the arq reset procedure, the arq transmitter will send blocks in the ‘not-sent’ state. This arq reset method avoids retransmitting blocks that might cause duplicate packets at the arq receiver, which some protocols cannot handle.
|
1. A method for an automatic repeat-reQuest (arq) transmitter comprising:
starting an arq reset procedure;
disabling transmission of the arq transmitter;
starting an arq transmitter window at a first unacknowledged block;
determining if a first block in the arq transmitter window is associated with a service data unit (sdu) having blocks in only a ‘discard,’ ‘outstanding,’ or ‘waiting-for-retransmission’ state; and
changing the first block to a ‘discard’ state if the first block in the arq transmitter window is associated with an sdu having blocks in only a ‘discard,’ ‘outstanding,’ or ‘waiting-for-retransmission’ state.
2. A method according to
setting the first block to a ‘not-sent’ state if the first block in the arq transmitter window is associated with an sdu having at least one block in a ‘not-sent’ state.
3. A method according to
determining if a second block in the arq transmitter window is associated with an sdu having blocks in only a ‘discard,’ ‘outstanding,’ or ‘waiting-for-retransmission’ state; and
changing the second block to a ‘discard’ state if the second block in the arq transmitter window is associated with an sdu having blocks in only a ‘discard,’ ‘outstanding,’ or ‘waiting-for-retransmission’ state.
4. A method according to
setting the second block to a ‘not-sent’ state if the second block in the arq transmitter window is associated with an sdu having at least one block in a ‘not-sent’ state.
|
This disclosure relates generally to Automatic Repeat-reQuest (ARQ)-enabled transmitters.
According to Section 6.3.4.6.2 of IEEE Standard 802.16e (Institute for Electrical and Electronics Engineers Standard for Local and Metropolitan Area Networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems, including Amendment 2 and Corrigendum 1), during an ARQ Reset procedure, all service data units (SDUs) with ARQ blocks in a ‘discarded’ state are to be discarded by an ARQ transmitter and all other ARQ blocks retransmitted after the ARQ Reset procedure has completed.
From an ARQ transmitter's point of view, an ARQ block may be in one of the following four states: not-sent, outstanding, discarded, and waiting-for-retransmission. Any ARQ block begins in the ARQ transmitter as ‘not-sent.’ After it is sent by the ARQ transmitter, the ARQ block becomes ‘outstanding’ for a “retry-timeout” period of time. While a block is in the ‘outstanding’ state, it is either acknowledged (an ACK is received from the ARQ receiver) and ‘discarded’, or the block transitions to ‘waiting-for-retransmission’ after the retry-timeout expires or a NACK is received from the ARQ receiver. An ARQ block can transition from ‘waiting-for-retransmission’ to ‘discarded’ when an ACK message for it is received or after a “lifetime-timeout” period has expired.
If an ARQ transmitter and its ARQ receiver lose synchronization, either the ARQ transmitter or the ARQ receiver can initiate an ARQ Reset procedure to restore synchronization. According to FIG. 34 and FIG. 35 of IEEE Standard 802.16e, an ARQ transmitter discards SDUs with one or more blocks in the ‘discarded’ state during the ARQ Reset procedure. Then, SDUs that have no ARQ blocks in the discard state will be sent (or resent).
One consequence of this behavior is that ARQ blocks that were received by the ARQ receiver before the ARQ Reset procedure initiated may be resent after the ARQ Reset procedure is complete. In fact, ARQ blocks for a complete SDU may be resent in accordance with this procedure even when the complete SDU was already received by the ARQ receiver before the ARQ Reset procedure started. For example, all the ARQ blocks for an SDU can be in the ‘outstanding’ state because ACKs sent by the ARQ receiver were not received by the ARQ transmitter. Then, these ‘outstanding’ ARQ blocks will transition to ‘waiting-for-retransmission’ and be resent after the ARQ Reset procedure has completed. In this case, the ARQ receiver will assemble a duplicate SDU and pass it to the higher layer. Thus, the higher layer receives duplicate packets.
Some higher layer transport protocols, such as Transmission Control Protocol (TCP) and Real-time Transport Control Protocol (RTCP), use sequence numbers and will be able to detect and discard these duplicate packets. Other protocols, however, cannot easily detect and discard duplicate packets. For example, Robust Header Compression (ROHC) specifically requires that lower layers not generate duplicate packets.
Thus, there is an opportunity to prevent duplicate packets resulting from an ARQ Reset procedure. The various aspects, features and advantages of the disclosure will become more fully apparent to those having ordinary skill in the art upon careful consideration of the following Drawings and accompanying Detailed Description.
The Automatic Repeat-reQuest (ARQ) Reset method for an ARQ transmitter discards all service data units (SDUs) after the start of an ARQ transmitter window that have no blocks in the ‘not-sent’ state and changes the state of all blocks in partially unsent SDUs to ‘not-sent’. When the ARQ Reset procedure is completed, the ARQ transmitter will send (or resend) all the blocks in the ‘not-sent’ state. By discarding SDUs having all their ARQ blocks in the ‘discard,’ ‘outstanding,’ and ‘waiting-for-retransmission’ states, the ARQ Reset method avoids retransmitting ARQ blocks that might result in duplicate packets at the ARQ receiver. This is important because some transport layer protocols cannot handle duplicate packets or experience poor efficiency when dealing with duplicate packets, while most transport layer protocols can handle lost packets.
In step 140, the ARQ transmitter considers partial and complete SDUs occurring after the start of the ARQ transmitter window. An SDU is a data unit received from an adjacent higher layer. An SDU, sometimes called a ‘packet’ in this context, is reformatted into one or more blocks for ARQ transmission. If an SDU has associated no blocks in the ‘not-sent’ state, then the SDU is discarded. In other words, if all the ARQ blocks relating to an SDU are in either the ‘discard,’ ‘outstanding,’ or ‘waiting-for-retransmission’ state, then the ARQ transmitter changes all the ARQ blocks for that SDU to the ‘discard’ state.
In step 150, the ARQ Reset method considers the remaining SDUs after the start of the ARQ transmitter window. For any SDUs having associated ARQ blocks in both a ‘not-sent’ state and another state (i.e., ‘discard,’ ‘outstanding,’ or ‘waiting-for-retransmission’), the blocks in the other state are changed to the ‘not-sent’ state. This allows complete SDUs to be transmitted after the ARQ Reset procedure finishes. Because an ARQ receiver discards all incomplete SDUs during an ARQ Reset procedure, step 150 does not result in duplicate packets at the ARQ receiver.
Step 160 enables transmission, and step 190 indicates the end of the ARQ Reset procedure. When the ARQ Reset procedure is completed, the ARQ transmitter sends ‘not-sent’ blocks with new sequence numbers and the ARQ receiver receives these blocks, provides ACKs or NACKs, constructs SDUs, and sends them to the higher layers according to general ARQ reception methods. Note that there is no change to the ARQ receiver and it continues to operate in accordance with FIG. 34 and FIG. 35 of IEEE Standard 802.16e.
In order to better understand the effect of the ARQ Reset method shown in
During the ARQ Reset method of
All the SDUs having no associated ARQ blocks in the ‘not-sent’ state are changed to the ‘discard’ state. See step 140 in
Next, all the SDUs with at least one ARQ block in the ‘not-sent’ state will have all their associated ARQ blocks set to the ‘not-sent’ state. See step 150 of
When the ARQ Reset procedure is complete, the ARQ transmitter will send all the ARQ blocks 246, 256 in row 296 that are in the ‘not-sent’ state and will process ACKs, NACKs, and timeouts in accordance with the general ARQ process. Although the ‘outstanding’ ARQ blocks 222, 232 were not acknowledged and also were not re-sent after the ARQ Reset procedure, there is a chance that the ARQ receiver did receive those ARQ blocks 222, 232 and was able to reassemble SDUs for delivery to the higher layer. If one or more of these ‘outstanding’ ARQ blocks 222, 232 was not received by the ARQ receiver, the high layer protocol of the ARQ receiver has methods to handle these lost packets.
In this example, several ARQ blocks 314, 322, 324 in an ‘outstanding’ state were changed to the ‘discard’ state by the ARQ Reset method of
The start of the ARQ transmitter window 380 begins where the first non-‘discard’ ARQ block begins. See step 130 of
Next, the ARQ Reset method sets the state of all ARQ blocks in partially unsent SDUs to ‘not-sent’. See step 150 of
When the ARQ Reset method is complete, the ARQ transmitter sends all the ARQ blocks 336, 338, 356 in row 396 that are in the ‘not-sent’ state and will process ACKs, NACKs, and timeouts in accordance with the general ARQ process. Although the ‘outstanding’ ARQ blocks 314, 322, 324 were not acknowledged and also not resent after the ARQ Reset procedure, it is possible that the ARQ2 block 314 was received by the ARQ receiver, processed with the acknowledged ARQ1 block 312 into a complete SDU and delivered to the ARQ receiver's higher layer. Even if the ARQ2 block 314 was never received, the ARQ receiver's higher layer can handle the missing packet related to SDU1 310. Additionally, it is also possible that both of the ARQ blocks 322, 324 for SDU2 320 were received by the ARQ receiver before the ARQ Reset procedure started, and thus the corresponding SDU was assembled and delivered to the ARQ receiver's higher layer. Again, even if SDU2 320 was not reconstructed at the ARQ receiver, transport layer protocols can generally handle missing packets.
On the other hand, the final ‘outstanding’ ARQ block 332 was retransmitted because the ARQ receiver is directed to discard all incomplete SDUs during an ARQ Reset procedure. See FIG. 34 and FIG. 35 of IEEE Standard 802.16e. Thus, resending the ARQ5 block 336 along with previously unsent ARQ6 block 338 does not result in a duplicate packet at the ARQ receiver.
In this example, the ‘waiting-for-retransmission’ state ARQ block 414 and the ‘outstanding’ state ARQ block 416 were both changed to a ‘discard’ state by the ARQ Reset method of
The start of the ARQ transmitter window 480 begins at the start of ARQ2 block 414, which is the first non-‘discard’ ARQ block. See step 130 of
SDU2 430 has an associated ARQ6 block 436 in a ‘not-sent’ state, so step 150 of
When the ARQ Reset method is complete, the ARQ transmitter sends ‘not-sent’ ARQ blocks 442, 444, 446, 456 from row 496 and processes ACKs, NACKs, and timeouts in accordance with the general ARQ process. Although ARQ blocks 414, 416 were not acknowledged, they may have been received by the ARQ receiver. If one or more of these ARQ blocks 414, 416 were not received by the ARQ receiver, the ARQ receiver's high layer should have procedures to handle a missing packet corresponding to SDU1 410.
Although there was an ARQ block 432 in a ‘discard’ state between two unacknowledged ARQ blocks 416, 434, this ‘discard’ state ARQ block 432 is set to a ‘not-sent’ state by the ARQ Reset method of
The ARQ Reset method avoids duplicate packets at the ARQ receiver. This is important because certain higher layer transport protocols cannot handle duplicate packets, or experience low efficiency when dealing with duplicate packets, while most all higher layer transport protocols can handle missing packets. The ARQ Reset method discards SDUs with zero blocks in the ‘not-sent’ state and changes the state of all ARQ blocks in partially-unsent SDUs to ‘not-sent.’ When the ARQ Reset method is completed and the ARQ transmitter returns to normal operation, the ARQ transmitter will send ARQ blocks for complete SDUs that had not been previously transmitted in their entirety. For SDUs that had all their ARQ blocks transmitted at least once prior to the ARQ Reset procedure, the ARQ transmitter will not transmit them again after the ARQ Reset procedure even if the blocks were ‘outstanding’ or ‘waiting-for-retransmission’ at the time of the ARQ Reset initiation.
While this disclosure includes what are considered presently to be the preferred embodiments and best modes of the invention described in a manner that establishes possession thereof by the inventors and that enables those of ordinary skill in the art to make and use the invention, it will be understood and appreciated that there are many equivalents to the preferred embodiments disclosed herein and that modifications and variations may be made without departing from the scope and spirit of the invention, which are to be limited not by the preferred embodiments but by the appended claims, including any amendments made during the pendency of this application and all equivalents of those claims as issued.
As understood by those in the art, the ARQ Reset method may be implemented using a processor that executes computer program code. Embodiments include computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a processor, the processor becomes an apparatus for practicing the invention.
It is further understood that the use of relational terms such as “first” and “second”, “top” and “bottom”, and the like, if any, are used solely to distinguish one from another entity, item, or action without necessarily requiring or implying any actual such relationship or order between such entities, items or actions. Much of the inventive functionality and many of the inventive principles are best implemented with or in software programs or instructions. It is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs with minimal experimentation. Therefore, further discussion of such software, if any, will be limited in the interest of brevity and minimization of any risk of obscuring the principles and concepts according to the present invention.
Zegers, Leon J., Korndewal, Marcel, Schaap, Wim, Hiddink, Gerrit W.
Patent | Priority | Assignee | Title |
8352823, | May 01 2009 | Qualcomm Incorporated | Methods and systems for handling ARQ resets |
8751891, | Aug 14 2009 | Samsung Electronics Co., Ltd | Apparatus and method for retransmitting data in wireless communication system |
9432151, | Nov 08 2007 | Samsung Electronics Co., Ltd. | Method and apparatus for automatic repeat reQuest (ARQ) in broadband wireless access system |
Patent | Priority | Assignee | Title |
20030206534, | |||
20060156165, | |||
20070110101, | |||
WO20050109778, | |||
WO2006065008, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Jan 30 2007 | SCHAAP, WIM | Motorola, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018874 | /0711 | |
Jan 30 2007 | HIDDINK, GERRIT W | Motorola, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018874 | /0711 | |
Jan 30 2007 | KORNDEWAL, MARCEL | Motorola, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018874 | /0711 | |
Jan 30 2007 | ZEGERS, LEON J | Motorola, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018874 | /0711 | |
Feb 09 2007 | Motorola Mobility, Inc. | (assignment on the face of the patent) | / | |||
Jul 31 2010 | Motorola, Inc | Motorola Mobility, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 025673 | /0558 | |
Jun 22 2012 | Motorola Mobility, Inc | Motorola Mobility LLC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 029216 | /0282 | |
Oct 28 2014 | Motorola Mobility LLC | Google Technology Holdings LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034451 | /0001 |
Date | Maintenance Fee Events |
Jan 12 2015 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jan 14 2019 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Feb 27 2023 | REM: Maintenance Fee Reminder Mailed. |
Aug 14 2023 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Jul 12 2014 | 4 years fee payment window open |
Jan 12 2015 | 6 months grace period start (w surcharge) |
Jul 12 2015 | patent expiry (for year 4) |
Jul 12 2017 | 2 years to revive unintentionally abandoned end. (for year 4) |
Jul 12 2018 | 8 years fee payment window open |
Jan 12 2019 | 6 months grace period start (w surcharge) |
Jul 12 2019 | patent expiry (for year 8) |
Jul 12 2021 | 2 years to revive unintentionally abandoned end. (for year 8) |
Jul 12 2022 | 12 years fee payment window open |
Jan 12 2023 | 6 months grace period start (w surcharge) |
Jul 12 2023 | patent expiry (for year 12) |
Jul 12 2025 | 2 years to revive unintentionally abandoned end. (for year 12) |