Joint range reject automatic repeat request protocol

[0002] This invention relates generally to communication systems, and more particularly to an Automatic Repeat Request (ARQ) protocol useful for transferring delay-sensitive data between sending and receiving devices over error-prone communication links.

[0003] Historically, communication systems have employed separate protocols for the transfer of delay-insensitive data and delay-sensitive data from a sender to receiver. Delay-insensitive data transfer services have used Automatic Repeat Request (ARQ) protocols that allow for reliable transfer of the data stream regardless of delay. ARQ protocols permit the receiver of a stream of data blocks to request the retransmission of data blocks that were either not received or received corrupted from the sender. ARQ protocols are often accompanied with forward error correction (FEC) to reduce the number of required retransmissions.

[0004] Examples of known ARQ protocols include Stop-and-Wait, Go-Back-N, and Selective Repeat. In Stop-and-Wait ARQ, a receiver sends an acknowledge (ACK) message to a transmitter after a given block is received successfully. The transmitter waits until the ACK message is received for a given block before it proceeds with transmitting the next block in a sequence of blocks. If the receiver detects an error in a given block, it sends a negative acknowledgement (NACK) message to the transmitter, and the transmitter then retransmits the given block. In Go-Back-N and Select Repeat ARQ, the transmitter is sending message data and the receiver is sending acknowledgment data simultaneously. After transmitting a given block, the transmitter continues to transmit additional blocks in the sequence even though an ACK has not yet been received for that given block. In Go-Back-N ARQ, if the receiver sends a NACK message indicating that the given block needs to be retransmitted, the transmitter will retransmit the given block and all subsequent blocks that were transmitted prior to receiving the NACK message. In Selective Repeat ARQ, the transmitter retransmits the given block, but then resumes the transmission sequence where it left off prior to receiving the NACK message. A block subsequent to the erroneous block is not retransmitted unless it is specifically identified as erroneous by a NACK message.

[0005] The Stop-and-Wait, Go-Back-N, and Selective Repeat ARQ protocols were developed to transfer delay-insensitive blocks from transmitter to receiver. For example, these protocols are well-suited to transferring a data file over an error-prone link, where the file must be transferred perfectly but the time required to perform the file transfer is of secondary importance. However, the known ARQ procedures are not well suited for transferring delay-sensitive data over error-prone communication links. For example, in packetized voice and video applications, transfer time is of primary importance. After a certain elapsed time the packet is of no value to the receiver. In these delay-sensitive applications, the transmitter and receiver should stop attempting to transfer blocks from a packet which is no longer of value to the receiver. Historically, delay-sensitive services did not use an ARQ protocol, but rather used forward error correction (FEC) techniques to accomplish error correction. Recent improvements in bandwidth management algorithms and physical layer data transfer technologies now permit limited retransmission of blocks within delay-sensitive data streams. However, the known art does not feature an ARQ protocol capable of handling the demands of both delay-sensitive and delay-insensitive data streams over a high transfer rate, high transfer delay data link. Furthermore, there does not exist an ARQ protocol sufficiently flexible to dynamically adapt to changes in data stream delay sensitivity.

[0006] An ARQ protocol capable of transferring delay-sensitive blocks must include a mechanism by which a transmitter (or receiver) can inform its peer entity that attempts to retransmit a particular block are no longer useful and will be (or should be) terminated. The known art employs two methods by which a transmitter can inform a receiver that it no longer wishes to transfer a particular block or blocks (i.e., prematurely terminate block transfer). In the first method, a field is added to the block transfer request message indicating that a particular block or blocks will not be transferred. For example, the block transfer request message might indicate that the block with sequence number 22 is being transferred and that further transmission attempts for the block with sequence number 19 will be halted. In the second method, a separate message is sent from transmitter or receiver indicating which block or blocks will not be transferred. The European Telecommunications Standards Institute (ETSI) HIPERLAN/2 ARQ protocol employs this method.

[0007] These two block transfer termination methods share a serious drawback. If the message specifying which block or blocks will not be transferred is lost, then the transmitter must detect by some mechanism that this has occurred and retransmit the request. These additional termination request messages increase the bandwidth consumption and block transfer delay of the ARQ protocol. Also, the ARQ protocol becomes much more complex.

[0008] A popular technique for increasing the efficiency of Selective Repeat ARQ protocols is to utilize a single message to negatively acknowledge multiple blocks. The known art employs a bit field, where each bit in the field provides the reception status of a single block. For example, if a bit within the bit field is 1, the corresponding block has been received successfully (ACK). If a bit within the bit field is 0, the corresponding block has not been received successfully (NACK). However, a problem with the bit field approach is that as data transfer rates and data transfer delays increase, the number of bits within the bit field must become quite large in order to provide useful negative acknowledgement information to the sender. This is because the receiver may have a large number of consecutive blocks to negatively acknowledge, but a limited number of bits with which to do it. This is a particular problem on high data rate wireless links during fading conditions. A large bit field requires a large negative acknowledgement message, which can prevent piggy-backing. In piggybacking, a data transfer request message for a stream flowing in one direction is packaged with a data transfer response message (ACK and/or NACK) for a stream flowing in the other direction. A data link supporting ARQ message piggybacking is usually much more efficient than a corresponding data link without piggybacking.

[0009] Moreover, existing ARQ protocols do not have a means by which an external entity (such as a bandwidth manager) can dynamically alter key aspects of ARQ protocol performance in response to changes in link operating conditions. Instead, ARQ protocol performance is rigidly fixed by the particular procedures incorporated into the protocol. However, such flexibility would be useful to engineers designing advanced scheduling algorithms for managing the transfer of multiple, simultaneous, independent delay-sensitive data streams over error-prone links. For example, the ability to dynamically change the bandwidth consumption and aggregate block transfer delay performance of an ARQ protocol would allow a link bandwidth manager to tailor the performance of the ARQ protocol to the current link load. If the link is lightly loaded, ARQ bandwidth consumption could be increased with a corresponding decrease in aggregate block transfer delay. If the link becomes congested, the bandwidth manager could scale back the ARQ bandwidth consumption with a corresponding increase in aggregate block transfer delay.

[0010] The foregoing discussion indicates that there is a need for an ARQ protocol that is capable of handling the demands of both delay-sensitive and delay-insensitive data transfers over a high transfer rate, high transfer delay data link subject to burst errors. Furthermore, there is a need for an ARQ protocol with data transfer reliability, delay, and bandwidth consumption performance that can be adapted dynamically by the transmitter or receiver to compensate for changes in link operating conditions. The present invention is directed to satisfying or at least partially satisfying these needs.

[0011] The foregoing and other advantages of the invention will become apparent upon reading the following detailed description and upon reference to the drawings in which:

[0012] FIG. 1 is a diagram of a communication system using an ARQ protocol in accordance with the present invention;

[0013] FIG. 2 is an illustration of an ARQ protocol according to the present invention operating on block management arrays managed by sending and receiving devices;

[0014] FIG. 3A shows the structure of a Send ARQ message sent from a sending device to a receiving device according to the present invention;

[0015] FIG. 3B shows the structure of a Receive ARQ message sent from a receiving device to a sending device according to the present invention;

[0016] FIG. 4 illustrates a procedure for a receiving device to process an ARQ message from a sending device according to the present invention;

[0017] FIG. 5 is a message sequence chart associated with termination of a block transfer attempt initiated by a sending device using the ARQ protocol according to the present invention;

[0018] FIG. 6 is a message sequence chart associated with termination of a block transfer attempt initiated by a receiving device using the ARQ protocol according to the present invention;

[0019] FIG. 7 illustrates a procedure for a sending device to process an ARQ message from a receiving device according to the present invention;

[0020] FIG. 8 is a message sequence chart associated with an Implicit NACK procedure using the ARQ protocol according to the present invention;

[0021] FIG. 9 is a message sequence chart associated with an Explicit NACK procedure using the ARQ protocol according to the present invention; and

[0022] FIG. 10 is a message sequence chart associated with a Minimum Corruption Density feature of the ARQ protocol of the present invention.

[0023] The following describes an ARQ protocol with the following characteristics:

[0024] 1. Allows a transmitter to unilaterally terminate an attempt to transfer one or more blocks, and communicate this event to a receiver in a straightforward and robust fashion;

[0025] 2. Allows a receiver to unilaterally terminate an attempt to receive one or more blocks, and communicate this event to the sender in a straightforward and robust fashion;

[0026] 3. Can be operated with any data transfer reliability/data transfer delay performance characteristic, ranging from perfect reliability/maximum potential delay to maximum potential unreliability/minimum delay. The performance is dynamically changeable by either the transmitter or receiver.

[0027] 4. Provides mechanisms by which the transmitter and receiver can dynamically increase bandwidth consumption and decrease aggregate block transfer delay (and vice-versa).

[0028] 5. Supports continuous transmission of data blocks by the transmitter.

[0029] 6. Facilitates ARQ message piggybacking.

[0030] 7. Efficiently supports block transfer over high transfer rate, high delay links.

[0031] 8. Efficiently supports links subject to burst errors.

[0032] In one embodiment of the present invention, there is provided a method of sending a plurality of blocks comprising data. The method comprises generating a first message comprising at least one block of the plurality of blocks, an identification of the at least one block, and an identification of a first active send block of the plurality of blocks, wherein the at least one block appears in the plurality of blocks no earlier than the first active send block; and sending the first message from a sending device to a receiving device.

[0033] In another embodiment of the present invention, there is provided a method including steps of maintaining a send block transfer window associated with a sending device and maintaining a receive block transfer window associated with a receiving device. The send block transfer window identifies a plurality of blocks adapted to be transferred from the sending device to a receiving device and the receive block transfer window identifies a plurality of blocks adapted to be received by the receiving device. The sending device forms a Send ARQ message field including a send anchor field and a send sequence number field. The send anchor field identifies a most delayed block of the plurality of blocks identified in the send block transfer window and the send sequence number field identifies a current block of the plurality of blocks identified in the send block transfer window that is to be sent from the sending device to the receiving device. The sending device forms a data transfer request message including, in sequence, the send anchor field, the send sequence number field, and a block data field including data associated with the current block and then sends the data transfer message to the receiving device.

[0034] In still another embodiment of the present invention, there is provided a method wherein a sending device attempts transfer of a plurality of blocks of data to a receiving device. The receiving device designates at least a first block of the plurality of blocks as corrupt and reports a number of consecutive blocks of the plurality of blocks as corrupt, commencing with the first block. The number of consecutive blocks reported as corrupt include an allowable number of non corrupt blocks based on a predefined parameter.

[0035] Turning now to the drawings and referring initially to FIG. 1, there is shown a communication system 100 comprising a sending device 102 and a receiving device 104. It is to be understood that in a typical data communication system, each of the devices 102 and 104 may act either as sender, receiver, or both, depending on whether they are sending and/or receiving data. Sending device 102 includes a controller 106, which may comprise a Central Processor Unit (“CPU”), microprocessor or other control means, memory 108, operating system 110, and Send ARQ Process 112. Receiving device 104 includes a controller 118, which may comprise a Central Processor Unit (“CPU”), microprocessor or other control means, memory 120, operating system 122, and Receive ARQ Process 124.

[0036] The controller 106 runs the operating system 110 of the sending device 102. In addition, the controller 106 runs the Send ARQ Process 112 to manage ARQ error control for the sending device 102. Similarly, the controller 118 runs the operating system 122 and the Receive ARQ Process 124 for the receiving device 104. The sending and receiving devices 102, 104 communicate via communication link 116 which may comprise, for example, terrestrial wired or wireless links, satellite links or a combination thereof. The communication link 116 may cause errors in the information and status messages exchanged between the sending and receiving devices 102, 104 but is otherwise adapted for the transfer of a delay-sensitive data stream such as that generated by an audio or video source. The sending and receiving devices 102 and 104 interface with the communication link 116 through respective communication interfaces 114, 126. The communication interfaces 114, 126 may comprise, for example, modems or other means for interfacing between the sending and receiving devices 102, 104 and the communication link 116.

[0037] Generally, the sending and receiving devices 102, 104 may comprise sources or recipients of control messages and/or payload, including delay-sensitive audio or video payload. The communication devices 102, 104 may comprise, for example, wireline device(s), mobile or portable wireless radio units, base stations or repeaters, dispatch consoles, site controller(s), comparator(s), telephone interconnect device(s), internet protocol telephony device(s), call logger(s), scanner(s) and gateway(s).

[0038] The ARQ protocol assumes that the data flowing across the link 116 has been divided into a sequence of arbitrarily sized chunks of data called blocks. The Send and Receive ARQ Processes 112, 124 exchange ARQ messages to coordinate the transfer of data blocks from sending device 102 to receiving device 104. In one embodiment, the ARQ messages may be embedded within the data transfer request messages and thereby sent along with one or more data blocks between the communication devices 102, 104. There can be multiple, simultaneous, independent ARQ Instances, each comprising a Send and Receive ARQ Process, active in each direction. For convenience, messages generated by the Send ARQ Process 112 will be termed Send ARQ messages and messages generated by the Receive ARQ Process 124 will be termed Receive ARQ messages. The number of bits dedicated to each of the fields within the Send and Receive ARQ messages 112, 124 is an implementation decision and does not affect protocol operation. In a preferred embodiment, the Send and Receive ARQ messages are implemented in a compact form that permits piggybacking: a message carrying a Send ARQ message for a data stream flowing in one direction can also carry a Receive ARQ message for a data stream flowing in the other. This can lead to substantial gains in efficiency for full-duplex applications.

[0039] Operation of the Send and Receive ARQ messages is best described with reference to the block management arrays (BMAs) 202, 204 shown in FIG. 2. The BMAs contain information used by a sending communication device (“Sender”) to transfer blocks to a receiving communication device (“Receiver”). The Sender and Receiver each maintain a BMA. The BMA used by the Sender is termed a “Send BMA” and the BMA used by the Receiver is termed a “Receive BMA.” In a preferred embodiment, the length of the Send and Receive BMAs 202, 204 is fixed prior to operation of the ARQ protocol. Any BMA length can be selected depending on the ARQ protocol performance goals and the nature of the operating environment. The BMA length can be fixed by target system specification or can be negotiated between Sender and Receiver by some other protocol independent of the ARQ protocol.

[0040] As shown, the Send BMA 202 and Receive BMA 204 each include eight elements. Send BMA 202 includes, in order, element 206, element 208, element 210, element 212, element 214, element 216, element 218 and element 220 corresponding to eight send sequence numbers “0” through “7.” Receive BMA 204 similarly includes, in order, element 222, element 224, element 226, element 228, element 230, element 232, element 234 and element 236, corresponding to the eight receive sequence numbers “0” through “7.” In one embodiment, each element in a BMA contains a block state variable (BSV) indicating the current transfer status of a block and possibly the data comprising the block. For example, in one embodiment of the invention, the possible states for a send BSV can be “FREE”, “NOT SENT”, “SENT”, “NACK”, and “TERMINATED”. The FREE state indicates that there is currently no block awaiting transfer to the Receiver. The NOT SENT state indicates that a block is awaiting transfer but a transfer attempt has not yet occurred. The SENT state indicates that a transfer attempt has occurred but no positive or negative acknowledgement has yet been received. The NACK state indicates that an unsuccessful transfer attempt has been made for the block. The TERMINATED state indicates that no further attempts to transfer the block to the receiver should be made. Likewise, in one embodiment of the invention, the possible states for a receive BSV can be “NOT RECEIVED”, “CORRUPT”, “RECEIVED”, and “TERMINATED”. The NOT RECEIVED state indicates that the block has been not yet been received from the Sender. The CORRUPT state indicates that the Receiver has detected that the Sender tried to transfer the block, but failed. The RECEIVED state indicates that the block has been successfully received from the Sender. Finally, the TERMINATED state indicates that further attempts to receive the block from the Sender should not be made.

[0041] In one embodiment, the Send ARQ Process maintains two indices into the Send BMA for managing the transfer of blocks to the Receive ARQ Process. The first index, called the leading index, points to the element where the next block received for transfer to the receiver should be inserted within the Send BMA 202. When the ARQ protocol according to this invention is first instantiated, the leading index points to Send BMA element 0 (FIG. 2, reference number 206). The Send ARQ Process will insert a new block ready for transfer to the receiver into Send BMA element 0, and then advance the leading index to the next element in the Send BMA 202. Subsequent blocks obtained for transfer will be handled in a similar manner. The Send BMA is a circular structure: the last element in the array relates to the first element in the array in the same way that element N relates to element N+1. Therefore, when the leading index advances past the last element of the Send BMA, it will wrap around to the beginning. The second index, called the send anchor, points to the element containing the oldest block obtained for transfer to the receiver. When the ARQ protocol is first instantiated, the send anchor index points to Send BMA 202 element 0 (206 in FIG. 2). As blocks are successfully transferred to the receiver, or terminated without being successfully transferred, the send anchor index advances. Like the leading index, when the send anchor index advances past the last element of the Send BMA 202 it will wrap around to the first element. The send anchor index and the leading index define a window into the Send BMA 202 containing those blocks which are actively being transferred to the receiver. This window is called the Send block transfer window (BTW). The ordering of blocks within the Send BTW directly corresponds to the order in which the blocks were obtained, with blocks obtained earlier appearing before blocks obtained later. The send anchor index defines the first active block within the Send BTW, and the block preceding the leading index defines the last active block within the Send BTW.

[0042] The Receive ARQ process maintains an index into the Receive BMA 204 called the receive anchor. The receive anchor points to the first element within the Receive BTW that the Receive ARQ process is still interested in filling with a block sent by the Send ARQ process. When the ARQ protocol according to this invention is first instantiated, the receive anchor points to element 0 within the Receive BMA 204 (222 in FIG. 2). As blocks are received from the Send ARQ process or terminated without being received by either Sender or Receiver, the receive anchor advances. When the receive anchor advances past the last element of the Receive BMA 204, it will wrap around to the first element. The receive anchor defines a window into the Receive BMA 204 called the Receive block transfer window (BTW).

[0043] FIG. 3A shows the structure of a data transfer request message 302 according to one embodiment of the invention. As shown, the data transfer request message 302 comprises a Send ARQ message field 304 and a block data field 306. The Send ARQ message field 304 comprises a Send block transfer window anchor field 308 (hereinafter anchor send field 308) and a send sequence number field 310 (hereinafter SSN field 310). The SSN field identifies which block is currently being transferred from Sender to Receiver. In the example of FIG. 2, SSN=5, thus indicating that block 5 is currently being transferred from Sender to Receiver by the data transfer request message 302.

[0044] FIG. 3B shows the structure of a Receive ARQ message 312 according to one embodiment of the invention. As shown, the Receive ARQ message 312 comprises a Receive block transfer window anchor field 314 (hereinafter anchor receive field 314) and a number of corrupt blocks field 316 (hereinafter number corrupt field 316). The number corrupt field specifies the number of blocks starting from the receive anchor that the Receiver would like the Sender to mark as corrupt. In the example of FIG. 2, number corrupt=4, thus indicating that the Receiver would like blocks 3 to 6 of the Send BMA 202 to be marked as corrupt.

[0045] The ARQ procedure of the present invention may be characterized as a “joint” procedure because the Send and Receive ARQ Processes have joint control over the flow of blocks over the link. Neither the Send nor Receive ARQ Process is entirely a “slave” to its peer process. The ARQ procedure is characterized as “range” because it supports operation on a range of one or more blocks with a single message.

[0046] FIG. 4 illustrates a procedure for a Receiver to process a Send ARQ message received from a Sender. At step 401, the Receive ARQ Process of the Receiver receives a Send ARQ message from the Send ARQ Process of the Sender. At step 402, the Receive ARQ Process determines if the Send ARQ message indicates a Sender-initiated termination of a block transfer attempt. The Sender may wish to terminate a block transfer attempt, for example, if the transfer of a block or blocks is excessively delayed due to link errors. In one embodiment of the present invention, the Sender unilaterally initiates termination of a block transfer by simply advancing the block identified in the anchor send field. For example, assume that the Sender has previously sent an ARQ message with anchor send=2. Suppose now that the Sender wishes to terminate the transfer of block 2. The sender “advances” or changes the block identified in the anchor send field to the next oldest block that is not yet terminated or transferred successfully and generates another ARQ message. For example, the Sender may now generate and send an ARQ message with anchor send=3. This indicates to the Receiver that block 3 is now the first block of the Send BTW and block 2 is now “terminated.” It will be appreciated that any number of blocks may be terminated in this fashion by advancing the Send BTW and sending an ARQ message to the Receiver identifying the new anchor send field. For example, the Sender might terminate the transfer of blocks 2, 3 and 4 by advancing the anchor send field from 2 to 5, and so forth.

[0047] The Receive ARQ Process may make the determination at step 402 by comparing the latest reported position of the Send BTW to the current position of the Receive BTW. In one embodiment, the latest reported position of the Send BTW can lead the current position of the Receive BTW only if the Sender has unilaterally terminated a block or blocks and has advanced its Send BTW accordingly. In response to a positive determination at step 402, the Receive ARQ Process proceeds to Step 404 where it advances its Receive BTW in corresponding fashion to match the Send BTW, thereby performing a “bilateral termination” of the appropriate block or blocks.

[0048] An example message sequence chart associated with a bilateral termination initiated by the Sender is shown at FIG. 5. The example assumes that blocks 0 to 9 have already been transferred successfully and that the Sender has blocks 10 to 13 awaiting transfer to the Receiver. The following sequence of events is shown:

[0049] 1. With the send anchor at block 10, the Sender attempts to transfer blocks 10 to 12, in sequence, to the Receiver via Send ARQ messages 502, 504, 506. Blocks 10 and 12 are transferred successfully, as illustrated by a solid line for message 502 and 506; block 11 transfer fails, as indicated by a dotted line for message 504. The Receive ARQ Process advances its receive anchor to 11 after the successful receipt of block 10. When block 12 is successfully received, Receive ARQ Process marks block 11 as corrupt.

[0050] 2. The Receive ARQ Process transfers a Receive ARQ message 508 indicating that block 11 is corrupt.

[0051] 3. The Send ARQ Process advances the send anchor to block 11 based on the new reported position of the receive anchor. The Send ARQ Process marks block 11 as negatively acknowledged.

[0052] 4. The Sender decides to abandon further block 11 transfer attempts after receiving the negative acknowledgement. The Send ARQ Process unilaterally advances the send anchor to block 12, and transfers block 13 using a Send ARQ message 510 carrying the advanced send anchor.

[0053] 5. The Receive ARQ Process notes the advanced send anchor reported in Send ARQ message 510 and advances the receive anchor to block 12. The successful receipt of block 13 causes a further advance of the receive anchor to block 14.

[0054] 6. The Receiver transfers a Receive ARQ message 512 indicating the updated position of the receive anchor.

[0055] 7. The Send ARQ Process advances the send anchor to block 14 in response to the newly reported position of the receive anchor.

[0056] Upon completing the bilateral termination, or in response to a negative determination at step 402 (FIG. 4), the Receive ARQ Process proceeds to step 406 to perform a “gap detection” procedure whereby any missing blocks that should have been received are designated as corrupt. For example, the Receive ARQ process may conclude that any missing blocks in the Receive BMA between anchor send and SSN are corrupt. This is because, in one embodiment, the Send ARQ Process must attempt to send all preceding blocks before sending the block indicated by SSN, thus the Receive ARQ Process can conclude that any missing block(s) in the Receive BMA is corrupt. Thus, for example, if the Receiver receives a Send ARQ message with anchor send=2 and SSN=5, it will designate blocks 2, 3 and 4 as corrupt if they were not previously received because the Receiver knows that blocks 2, 3 and 4 should have been received before block 5.

[0057] Next, at step 408, the Receive ARQ Process updates the Receive BSV. This is performed in one embodiment by identifying the block in the Receive BMA specified by the Send ARQ message SSN field as either received or corrupt, depending upon the condition of the block payload associated with the Send ARQ message. For example, if the Receiver receives a Send ARQ message with SSN=5, the Receive ARQ Process may identify block 5 as received if the data associated with block 5 is received in good condition, or corrupt if the data is received in bad condition. It will be appreciated, however, for implementations where the block data is not protected separately from the Send ARQ message, the Receive ARQ Process may only be able to identify the block as received in good condition.

[0058] At step 410, the Receive ARQ Process advances the Receive BTW. In one embodiment, the Receive ARQ Process advances its Receive BTW past blocks that are either received or terminated, such that the anchor receive field identifies the first block in the Receive BMA that is either corrupt or not received. Thus, for example, where anchor receive=3, if block 3 is received or terminated and block 4 is corrupt or not yet received, the Receive ARQ Process will advance the anchor receive field to block 4.

[0059] The Receive ARQ Process may initiate an optional, unilateral termination of a block transfer attempt at any time. The Receiver may wish to unilaterally terminate a block transfer attempt, for example, if the block or blocks are excessively delayed due to transfer errors. In one embodiment of the present invention, the Receiver initiates unilateral termination of a block transfer by simply advancing its Receive BTW past the block to be terminated and generating a Receive ARQ message with the anchor receive field indicating the new Receive BTW position. For example, with reference to FIG. 2, note that the anchor receive block 3 differs from the anchor send block 2. This indicates that the Receiver has advanced the anchor receive block from 2 to 3, perhaps because block 2 was already received or that it was excessively delayed such that the Receiver no longer wishes to receive it. The Receiver generates and sends an ARQ message with anchor receive=3. This indicates to the Sender that block 3 is now the first block of interest to the Receiver. It will be appreciated that any number of blocks may be terminated in this fashion by means of a single ARQ message. For example, the Receiver might terminate the transfer of blocks 2, 3 and 4 by advancing the anchor receive field from 2 to 5, and so forth. The Send ARQ Process, in turn, will advance its Send BTW in corresponding fashion to match the Receive BTW, thereby performing a bilateral termination of the appropriate block or blocks.

[0060] An example message sequence chart associated with a bilateral termination initiated by the Receiver is shown at FIG. 6. The example assumes that blocks 0 to 9 have already been transferred successfully and that the Sender has blocks 10 to 13 awaiting transfer to the Receiver. The following sequence of events is shown:

[0061] 1. With the send anchor at block 10, the Sender attempts to transfer blocks 10 to 12, in sequence, to the Receiver via Send ARQ messages 602, 604, 606. Blocks 10 and 12 are transferred successfully, as illustrated by a solid line for message 602 and 606; block 11 transfer fails, as indicated by a dotted line for message 604. The Receive ARQ Process decides that it is no longer interested in receiving block 11 and unilaterally advances the receive anchor to block 12. Since block 12 has already been successfully received, the receive anchor is further advanced to block 13.

[0062] 2. The Receive ARQ Process transfers a Receive ARQ message 608 indicating the new position of the receive anchor and that no blocks are corrupt.

[0063] 3. The Send ARQ Process advances the send anchor to block 13 based on the new reported position of the receive anchor.

[0064] 4. The Sender transfers block 13 using a Send ARQ message 610 carrying the advanced send anchor.

[0065] 5. The Receiver acknowledges the successful receipt of block 13 by advancing the receive anchor to block 14 and transferring a Receive ARQ message 612 indicating the updated position of the receive anchor.

[0066] 6. The Send ARQ Process advances the send anchor to block 14, aligning it with the updated receive anchor reported in the Receive ARQ message 612.

[0067] The process of FIG. 4 may be continued to process multiple Send ARQ messages. If the process is continued at step 412, the process returns to step 401 where the Receive ARQ Process receives another Send ARQ message from the Send ARQ Process, and so forth. Otherwise, if the process is not continued at step 412, the process ends.

[0068] FIG. 7 illustrates a procedure for the Sender to process a Receive ARQ message transferred from the Receiver. At step 702, the Send ARQ Process receives a Receive ARQ message from the Receive ARQ Process. At step 704, the Send ARQ Process determines whether the anchor receive field within the Receive ARQ message has advanced. If the anchor receive field has advanced, the Send ARQ Process advances its Send BTW at step 706. Thus, for example, with reference to FIG. 2, where the anchor send field of the Send ARQ Process initially identifies block 2 and a Receive ARQ message is received with anchor receive=3, the Send ARQ Process will advance the anchor send field to block 3.

[0069] Upon advancing the Send BTW, or in response to a negative determination at step 704, the Send ARQ Process proceeds to step 708, where a reception determination procedure is performed to decide which blocks in the Send BTW are eligible to be negatively acknowledged by the Receive ARQ message. For example, if a particular block is sent by the Send ARQ Process at time t=1000 over a link with a propagation delay of d=200, then a Receive ARQ message received by the Send ARQ Process at t=1050 cannot possibly reflect the reception status of this block. There are a variety of methods by which Receive ARQ message coverage can be determined. Example reception determination procedures that may be used are shown at Appendix A, “Automatic Repeat Request (ARQ) Protocol; Reception Determination Procedures,” by Stephen Hershey. Appendix A is appended to and is incorporated in its entirety as a part of the present disclosure. It will be appreciated, however, the ARQ protocol according to the present invention does not require any particular method of reception determination.

[0070] If it is determined at step 710 that a certain block or blocks are eligible for negative acknowledgement by the Receive ARQ message, the process proceeds to step 712 and steps 714 or 716 to determine whether the Send ARQ Process should negatively acknowledge (NACK) the eligible block or blocks. In one embodiment, the ARQ protocol defines two methods for marking blocks as negatively acknowledged: Explicit NACK and Implicit NACK. If it is determined at step 710 that a certain block or blocks are not eligible for negative acknowledgement, the process returns to step 702 to receive additional Receive ARQ messages, advance Send BTW, and so forth but block(s) are not negatively acknowledged until such time that they are determined at step 710 to be eligible for negative acknowledgement.

[0071] At step 712, the Send ARQ Process examines the number of corrupt blocks reported in the Receive ARQ message. If the number corrupt=0, an Implicit NACK procedure is performed at step 714. In the Implicit NACK procedure, the Send ARQ Process can negatively acknowledge block(s) even though it has not received a Receive ARQ message indicating that those block(s) are corrupt. The Implicit NACK procedure can provide significant efficiency gains when a long sequence of consecutive blocks are corrupted, such as during fading over wireless links. However, the Implicit NACK procedure relies upon a reception determination procedure able to estimate which sent blocks should have been received and positively acknowledged by the Receive ARQ Process.

[0072] An example message sequence chart associated with the Implicit NACK procedure is shown at FIG. 8. The example assumes that blocks 0 to 9 have already been transferred successfully. The following sequence of events is shown:

[0073] 1. With the send anchor at block 10, the Sender attempts to transfer blocks 10 to 14, in sequence, to the Receiver via Send ARQ messages 802, 804, 806, 808, 810. Blocks 10, 11 and 12 are not transferred successfully, as illustrated by a dotted line for messages 802, 804 and 806. However, the Receive ARQ Process cannot mark these blocks as corrupt until block 13 is successfully received.

[0074] 2. After the hypothetical receipt time of block 12, the Receiver transfers a Receive ARQ message 812 indicating that the receive anchor has not advanced and that no blocks are corrupt. When block 13 is successfully received, Receive ARQ Process Gap Detection marks blocks 10, 11, and 12 as corrupt. However, by the time block 13 is received, the Receive ARQ message has already been generated and transferred to the Sender. Block 14 is also successfully received.

[0075] 3. The Send ARQ Process reception determination algorithm determines which blocks are eligible for negative acknowledgement, and blocks 10, 11, and 12 are marked as negatively acknowledged.

[0076] 4. The Send ARQ Process retransmits blocks 10, 11 and 12 to the Receiver, via Send ARQ messages 814, 816, 818.

[0077] Returning to FIG. 7, if the number corrupt is greater than zero, an Explicit NACK procedure is performed at step 716. The Send ARQ Process examines the number of consecutive blocks specified by number corrupt and starting at anchor receive. Those blocks within the range of blocks reported as corrupt that are eligible for negative acknowledgement by the Receive ARQ message are marked as such.

[0078] An example message sequence chart associated with an Explicit NACK procedure is shown at FIG. 9. The example assumes that blocks 0 to 9 have already been transferred successfully. The following sequence of events is shown:

[0079] 1. With the send anchor at block 10, the Sender attempts to transfer blocks 10 to 12, in sequence, to the Receiver via Send ARQ messages 902, 904, 906. Blocks 10 and 12 are transferred successfully, as illustrated by a solid line for message 902 and 906; block 11 transfer fails, as indicated by a dotted line for message 904. The Receive ARQ Process advances its receive anchor to block II after the successful receipt of block 10. When block 12 is successfully received, the Receive ARQ Gap Detection Process marks block 11 as corrupt.

[0080] 2. The Receive ARQ Process transfers a Receive ARQ message 908 indicating the new position of the receive anchor and that block 11 is corrupt.

[0081] 3. The Send ARQ Process advances the send anchor to block 11 based on the new reported position of the receive anchor. After reception determination, the Send ARQ Process marks block 11 as negatively acknowledged and retransmits block 11 via Send ARQ message 910 carrying the advanced send anchor. The Send ARQ then transfers block 13 via Send ARQ message 912.

[0082] 4. The Receive ARQ Process advances its receive anchor to 12 after the successful receipt of block 11, and then further advances the receive anchor to block 13 since block 12 was already received. The successful receipt of block 13 causes the receive anchor to advance to block 14.

[0083] 5. The Receive ARQ Process transfers a Receive ARQ message 914 indicating the new position of the receive anchor and that no blocks are corrupt.

[0084] 6. The Send ARQ Process advances the send anchor to block 14 based on the new reported position of the receive anchor.

[0085] At step 718 (FIG. 7), the Send ARQ Process optionally attempts to retransmit those block(s) that were negatively acknowledged by the Implicit NACK or Explicit NACK procedure. The process of FIG. 7 may be continued for the Sender to receive and process multiple Receive ARQ messages. If the process is continued at step 720, the process returns to step 702 where the Send ARQ Process receives another Receive ARQ message from the Receive ARQ Process, and so forth. Otherwise, if the process is not continued at step 720, the process ends at step 722.

[0086] Adjustable Minimum Corruption Density

[0087] The number corrupt field within the Receive ARQ message identifies the number of consecutive blocks that are reported as corrupt, starting from the first block within the receive BTW. According to one embodiment of the present invention, the number of blocks reported as corrupt may include a percentage of blocks that are not actually corrupt, based on a parameter called Minimum Corruption Density (MCD). The MCD may vary from 0 to 1.0 and is dynamically changeable by the Receiver depending on the desired bandwidth consumption/block transfer delay performance characteristic. For example, if the MCD is 1.0, then every block within the range of blocks specified by the number corrupt field is actually corrupt. However, if the MCD is less than 1.0, then some of the blocks reported as corrupt may not be corrupt, but rather may have been received or terminated. For example, if the MCD is 0.8, then 80% or more of the blocks within the range of blocks specified by the “number corrupt” field must be corrupt (thus 20% or less must have been received or terminated). If the MCD is 0.2, then only 20% or more of the blocks within the range of blocks specified by the “number corrupt” field must be corrupt, and so forth. The Receive ARQ Process reports the largest value for number corrupt that is consistent with the required MCD.

[0088] The Send ARQ Process, having received the Receive ARQ message with the number corrupt field and the anchor receive field, will mark the appropriate number of blocks as corrupt. For example, if the Receive ARQ message identifies anchor receive=3 and number corrupt=4, the Send ARQ Process may mark blocks 3 to 6 as corrupt after reception determination and subsequently attempt to retransmit those blocks. If the MCD is 1.0, all of the blocks that were reported as corrupt (and thus all of the blocks that are retransmitted) are actually corrupt. If the MCD is less than 1.0, some of the blocks that were reported as corrupt are not actually corrupt, thus the Sender will retransmit some blocks that were already been received or terminated, thereby increasing bandwidth consumption.

[0089] In general, if free excess bandwidth is available to absorb the increased and width demands resulting from an MCD less than 1.0, the transfer delay over the link will decrease. This is because lower values of MCD often result in larger values for number corrupt. Thus, one method by which the Receiver might manage the MCD parameter is to set the MCD to 1.0 during periods of congestion to minimize bandwidth consumption and to lower the MCD during less congested periods to increase bandwidth consumption but decrease delay. In any event, whatever MCD parameter is selected, it is preferred that the final block in the range reported as corrupt (i.e., farthest from the receive anchor) should always be actually corrupt, because including final blocks that were received successfully within the reported corruption range merely leads to unnecessary retransmissions with no corresponding reduction in aggregate block transfer delay.

[0090] FIG. 10 is a message sequence chart useful for illustrating the MCD feature of the present invention. The example assumes that blocks 0 to 9 have already been transferred successfully. The following sequence of events is shown:

[0091] 1. The Sender attempts to transfer blocks 10 to 13, in sequence, to the Receiver via Send ARQ messages 1002, 1004, 1006, 1008. Blocks 10 and 12 were not transferred successfully; blocks 11 and 13 were transferred successfully.

[0092] 2. The Receive ARQ Process transfers a Receive ARQ message 1010 indicating a number of corrupt blocks, based on the minimum corruption density (MCD). If the MCD is 1.0, then the Receive ARQ Process indicates only that block 10 is corrupt even though it knows that block 12 is also corrupt. This is because any larger reported number corrupt would include at least one block (block 11) that is not corrupt and therefore would be inconsistent with the MCD of 1.0. However, if the MCD is 0.6 (thereby requiring that at least 60% of the blocks reported as corrupt are indeed corrupt), the Receive ARQ Process can report the number of corrupt blocks as 3 because two out of the three blocks (blocks 10 and 12) are indeed corrupt. (The remaining message sequence assumes an MCD of 0.6).

[0093] 3. The Sender retransmits blocks 10, 11, 12 that were reported as corrupt, via Send ARQ messages 1012, 1014, 1016. Even though block 11 has been already received correctly by the Receiver and would not be retransmitted if MCD =1, the advantage of lowering the MCD to 0.6 (and thereby reporting the number of corrupt blocks as three) is that the Send ARQ Process is notified that block 12 is corrupt earlier, and hence retransmits block 12 sooner than it otherwise would have if the number of corrupt blocks was reported as one. This reduces the aggregate block transfer delay. The tradeoff is the excess bandwidth consumption caused by unnecessary retransmissions of correctly received blocks (in this example, block 11). Thus, lowering the minimum corruption density can reduce aggregate block transfer delay at the cost of greater bandwidth consumption.

[0094] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]