|Publication number||US7072309 B2|
|Application number||US 10/025,521|
|Publication date||Jul 4, 2006|
|Filing date||Dec 17, 2001|
|Priority date||Dec 17, 2001|
|Also published as||US20030115331|
|Publication number||025521, 10025521, US 7072309 B2, US 7072309B2, US-B2-7072309, US7072309 B2, US7072309B2|
|Inventors||Qiaobing Xie, Randall R. Stewart, La Monte Henry Piggy Yarroll|
|Original Assignee||Motorola, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (4), Referenced by (23), Classifications (16), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates generally to data transmission and in particular, to a method and apparatus for data transmission within a communication system.
Within a communication system, transmissions are conducted between a transmitting device and a receiving device over a communication resource, commonly referred to as a communication channel. To date, data transmissions have typically consisted of either a totally reliable data transfer protocol, or a totally unreliable data transfer protocol. Reliable data transmission protocols guarantee a lossless data transfer service, while unreliable data transfer protocols guarantee a “best effort” and are not capable of meeting specific loss requirements. An example of a reliable transmission protocol is the Transmission Control Protocol (TCP), while an example of an unreliable protocol is the User Datagram Protocol (UDP).
In many data transmission scenarios a user can afford some loss of data even though a totally unreliable transmission protocol (e.g., UDP) is unacceptable. That leaves the user with only one choice, namely, a totally reliable transmission protocol. For example, a user may be able to tolerate a maximum 10% loss in data transmission. Because UDP cannot guarantee a maximum loss, the user will be required to utilize a totally reliable transmission protocol (e.g., TCP). Since reliable transmission protocols are generally more expensive than unreliable transmission protocols, the user will be forced to pay a higher price for the totally reliable transmission protocol, even though the user can tolerate data loss. Notwithstanding this fact, the user is forced to occupy more bandwidth than is necessary. Therefore, a need exists for a method and apparatus for data transmission within a communication system that is less than totally reliable, yet offers more reliability than a totally unreliable transmission scheme and the level of reliability can be controlled by the user.
To address the above-mentioned need, a method and apparatus for data transmission is provided herein. In accordance with the preferred embodiment of the present invention a loss-ratio estimator estimates a current loss (L) for a communication channel. Once the actual channel loss is known, a generator compares the actual loss (L) to a target loss (T). A retransmission control parameter (R) is then adjusted by the generator and output to a transmitter where it is used to control the current retransmission behavior of the transmitter.
Because the transmitter continuously adjusts a retransmission parameter based on the current channel condition, a specific user-defined QoS loss ratio can be maintained. Therefore, a user requiring a certain QoS can obtain that QoS without having to resort to a totally reliable transmission control protocol.
The present invention encompasses a method for data transmission. The method comprises the steps of receiving a first bad frame and/or detecting a first lost frame a first plurality of times, and sending a first number of Acknowledgments (ACKs) or Negative Acknowledgments (NAKs) in response to the received first bad or lost frames. The first bad or lost frame is aborted. A second bad or lost frame is received or detected a second plurality of times, and a second number of ACKs or NAKs is sent in response to the received second bad or lost frames. The second bad or lost frame is then aborted.
The present invention additionally encompasses a method for data transmission. The method comprises the steps of receiving an acknowledgment (ACK) or negative acknowledgment (NAK) and determining a loss ratio (L) based on the received ACK/NAK. The loss ratio is compared with a target loss ratio (T) and a retransmission parameter (R) is adjusted based on the comparison. The retransmission parameter comprises a number of times a particular frame is to be retransmitted prior to aborting the frame.
The present invention additionally encompasses an apparatus comprising a loss ratio generator having an ACK or NAK as an input and outputting an estimated channel loss (L) and a retransmission parameter generator having the estimated channel loss as an input and outputting a retransmission parameter (R) based on the estimated channel loss, wherein R comprises a number of retransmissions a frame undergoes prior to declaring the frame an aborted frame.
Finally, the present invention encompasses an apparatus comprising a receiver having a poor frame as an input or detecting a lost frame, and an ACK/NAK generator coupled to the receiver, the receiver outputting an ACK/NAK based on a targeted loss ratio (T), an actual channel loss ratio (L), and a retransmission parameter (R), wherein the retransmission parameter comprises a number of times a frame is ACK/NAKed prior to declaring the frame an aborted frame.
Turning now to the drawings, wherein like numerals designate like components,
Communication system 100 comprises transmitting device 101, which may be a base transceiver station (BTS) and receiving device 102, which may be a mobile unit. As shown, transmitter and receiver are communicating via communication channel 108.
Communication systems that request retransmission of data can be either Negative Acknowledgment (NAK) based, or Acknowledgment (ACK) based. For communication systems utilizing a NAK-based protocol, receiver 106 does not acknowledge correctly-received frames. Receiver 106 only requests the retransmission of frames that were missing or incorrectly received by sending a NAK to transmitting device 101. For communication systems using an ACK-based protocol receiver 106 acknowledges all good frames received. From these acknowledgments, transmitter 101 determines which frame(s) is lost or is incorrectly received.
In either a NAK-based or ACK-based communication system, once transmitter 101 determines that a particular frame is lost or not correctly received by receiver 106, the transmitter performs a retransmission of the frame and records the total number of retransmissions applied to the frame so far. After a predetermined number retransmissions (R), and if the frame has not been correctly received by the receiver, the transmitter aborts the retransmission of the bad frame and instructs the receiving device 102 that the frame has been aborted.
In the preferred embodiment of the present invention for both ACK and NAK-based systems, retransmission control parameter generator 104 controls the number of retransmissions (R) of bad frames to target a specific loss ratio (T). More particularly, the user of the communication system specifies a target Quality of Service (QoS) loss ratio. This can be done on a per-call basis, or apriori, based on a user's service agreement. Once transmitting device 101 receives the target loss ratio (T), transmitting device 101 continuously computes a loss ratio (L) based on information carried in the NAKs or ACKs received by loss-ratio estimator 105. In the preferred embodiment of the present invention the loss ratio is simply the number of lost or incorrectly received frames divided by the total number of frames sent during a predetermined time period (e.g., the last 10 seconds). More particularly,
Once the loss ratio is known, generator 104 compares the target loss ratio to the actual loss ratio and adjusts the retransmission control parameter (R) accordingly. In particular, if:
It should be noted that for the above logic, R can be decreased to a minimum of 0. When R is 0, transmitter 103 will not retransmit a frame even if it is indicated as lost.
Because transmitter 101 serves to maintain a specific user-defined QoS loss ratio, a user requiring a certain QoS can obtain that QoS without having to resort to a totally reliable transmission control protocol. Because of this, the bandwidth resource of communication channel 108 which is often shared with other users can be saved and the additional data delay often associated with a totally reliable transmission control protocol can be avoided.
Operation of Communication System Using a NAK-Based Protocol
In current Code Division Multiple Access (CDMA) communication systems a Radio Link Protocol (RLP) is utilized for the link layer to transport data traffic between a mobile unit and infrastructure equipment. During typical data transmission Point to Point Protocol (PPP) is utilized on top of the RLP. In such situations, RLP fragments PPP packets into 20 millisecond frames that are transmitted over the air. This is illustrated in
RLP is a NAK-based protocol in that once a bad frame has been received, receiving device 102 will request retransmission of the lost frame periodically until the frame is received, or until an indication is received from transmitting device 101 that the frame is aborted. Such a scenario is illustrated in
As shown in
Current RLP defines variables V(N) and V(R), with V(N) being equal to the next frame needed for sequential delivery of frames, and V(R) equal to the next new frame expected from the transmitter. V(N) is a variable that tells the receiver what frames have been received or aborted. In particular, all frames<V(N) are tagged as “received” by the receiver, and the receiver will fail to send a NAK for frames having values<V(N). (See IS-707 Section 22.214.171.124).
Implementing the above procedure into RLP requires that transmitting device 101 constantly update R, record the number of retransmission performed on each frame, determine whether the retransmission of a frame should be aborted, and communicate to receiving device 102 when a frame is aborted. In the scenario described in
Operation of Communication System Using an ACK-Based Protocol
In many existing communication systems an ACK-based protocol is utilized for the transportation of data traffic between a transmitting and receiving device. During typical data transmission, receiving device 102 will periodically report to transmitting device 101 on frames correctly received by sending back ACKs. Combining the information reported in the ACKs with its own data transmission record, transmitting device 101 will derive information on lost frames if there are any. In other words, in an ACK-based protocol the information on frames that are lost or poorly received is implicitly indicated in the ACKs. Once the lost frame(s) is identified through analyzing a newly arrived ACK, loss-ratio estimator 105 will update the current loss-ratio estimate L and generator 104 will then adjust retransmission parameter R. At the same time, for each lost frame identified, transmitter 103 will first examine whether the frame has already been retransmitted for R or more times. If so, transmitter 103 will not retransmit the frame, but instead will communicate to receiving device 102 indicating that the frame is aborted. Upon reception of the abortion indication, receiving device 102 will indicate the frame as received in its subsequent ACKs.
As shown in
The logic flow begins at step 401 where an ACK/NAK arrives at transmitting device 101. At step 403 the information carried in the ACK/NAK is analyzed to identify which frame(s) is lost. At step 405, loss-ratio estimator 105 estimates a current loss (L) for communication channel 108. Once the loss ratio is known, generator 104 compares the actual loss (L) to a target loss (T) (step 407). A retransmission control parameter (R) is adjusted by generator 104 (step 409) and output to transmitter 103 (step 411). At the same time, after the lost frame(s) is identified at step 403, transmitter 103 examines the lost frame and retransmit it if necessary (step 413).
At step 501 a lost frame is identified by estimator 105. The lost frame is first examined whether it has already been retransmitted for R or more times (step 503). If so, the lost frame is aborted and not be retransmitted (step 504), otherwise, the lost frame is retransmitted (step 505). After all the identified lost frames are either retransmitted or aborted, transmitter 103 indicates to receiving device 102 the frames that have been aborted (step 508).
By adjusting the retransmission control parameter (R), communication system 100 maintains a targeted loss ratio (T). Therefore, a user requiring a certain QoS can obtain that QoS without having to resort to a totally reliable transmission control protocol.
It should be noted that in the above description, the first and the second number of ACK/NAKs that are transmitted to transmitting device 101 may differ. In each case, the frame is declared aborted, however, a different number of ACK/NAKs were required to do so in each case. Because of this, a user requiring a certain QoS can obtain that QoS without having to resort to a totally reliable transmission control protocol. Because of this, the bandwidth resource of communication channel 108 which is often shared with other users can be saved and the additional data delay often associated with a totally reliable transmission control protocol can be avoided.
Operation of communication system 700 in accordance with the alternate embodiment of the present invention occurs as follows: Once the loss ratio is known, generator 104 compares the target loss ratio to the actual loss ratio and adjusts the retransmission control parameter (R) and instructs frame dropper 701 to drop frames according to the following logic:
Both R and D are set to 0 at initialization.
Communication system 700 serves to maintain a targeted QoS loss ratio (T) by dropping frames when the retransmission control parameter is at its lowest value.
While the invention has been particularly shown and described with reference to a particular embodiment, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention. For example, although the above description was given with respect to link-layer retransmission, one of ordinary skill in the art will recognize that the above description may be applied to any layer requiring retransmission of lost data packets. It is intended that such changes come within the scope of the following claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6208620 *||Aug 2, 1999||Mar 27, 2001||Nortel Networks Corporation||TCP-aware agent sublayer (TAS) for robust TCP over wireless|
|US20020114291 *||Feb 19, 2002||Aug 22, 2002||Moulsey Timothy J.||Radio communication system|
|US20020191544 *||Dec 27, 2001||Dec 19, 2002||Cheng Mark W.||Method and system for interlayer control between re-sequencing and retransmission entities|
|US20030086403 *||Nov 8, 2001||May 8, 2003||Harris John M.||Method for dynamically adjusting the number of retransmissions and NAKs in a communications system implementing TCP/IP|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7313121 *||Mar 15, 2004||Dec 25, 2007||Conexant, Inc.||Acknowledging data transmissions in the presence of multiple shared-communications channels|
|US7583636||Feb 19, 2002||Sep 1, 2009||Koninklijke Philips Electronic N.V.||Radio communication system|
|US7716731||Oct 24, 2005||May 11, 2010||Cisco Technology, Inc.||Method for dynamically tunneling over an unreliable protocol or a reliable protocol, based on network conditions|
|US7747731 *||May 22, 2003||Jun 29, 2010||Nokia Corporation||Minimizing message processing latency in a communication network|
|US7827236 *||Oct 18, 2006||Nov 2, 2010||Kenora Technology, Llc||Digital transactions for the delivery of media files|
|US8117193||Aug 15, 2008||Feb 14, 2012||Lemi Technology, Llc||Tunersphere|
|US8316015||Nov 20, 2012||Lemi Technology, Llc||Tunersphere|
|US8494899||Dec 2, 2008||Jul 23, 2013||Lemi Technology, Llc||Dynamic talk radio program scheduling|
|US8577874||Oct 19, 2012||Nov 5, 2013||Lemi Technology, Llc||Tunersphere|
|US8627449||Mar 3, 2011||Jan 7, 2014||Cisco Technology, Inc.||Dynamic tunneling over virtual private network connections based on network conditions|
|US8755763||Oct 27, 2011||Jun 17, 2014||Black Hills Media||Method and device for an internet radio capable of obtaining playlist content from a content server|
|US8792850||Oct 21, 2011||Jul 29, 2014||Black Hills Media||Method and device for obtaining playlist content over a network|
|US8874554||Nov 1, 2013||Oct 28, 2014||Lemi Technology, Llc||Turnersphere|
|US8918480||Apr 9, 2007||Dec 23, 2014||Black Hills Media, Llc||Method, system, and device for the distribution of internet radio content|
|US8983937||Sep 17, 2014||Mar 17, 2015||Lemi Technology, Llc||Tunersphere|
|US9015147||Dec 20, 2007||Apr 21, 2015||Porto Technology, Llc||System and method for generating dynamically filtered content results, including for audio and/or video channels|
|US20020114291 *||Feb 19, 2002||Aug 22, 2002||Moulsey Timothy J.||Radio communication system|
|US20040215795 *||May 22, 2003||Oct 28, 2004||Petteri Poyhonen||Minimizing message processing latency in a communication network|
|US20040223478 *||Mar 15, 2004||Nov 11, 2004||Fischer Michael Andrew||Acknowledging data transmissions in the presence of multiple shared-communications channels|
|US20050073960 *||Aug 15, 2003||Apr 7, 2005||Satoshi Oura||Data transfer system capable of precisely deciding transfer rate|
|US20070078660 *||Oct 18, 2006||Apr 5, 2007||Radioscape Limited||Digital Transactions for the Delivery of Media Files|
|US20070094723 *||Oct 24, 2005||Apr 26, 2007||Short Todd M||Method for dynamically tunneling over an unreliable protocol or a reliable protocol, based on network conditions|
|USRE43151||Dec 28, 2009||Jan 31, 2012||Intellectual Ventures I Llc||Acknowledging data transmissions in the presence of multiple shared-communications channels|
|U.S. Classification||370/278, 714/749, 709/227, 370/252|
|International Classification||H04B7/005, H04L1/18, H04L29/08, H04L1/20, H04L12/56|
|Cooperative Classification||H04L69/324, H04L1/20, H04W28/18, H04L1/1867|
|European Classification||H04L1/18T, H04L1/20, H04L29/08A2|
|Dec 17, 2001||AS||Assignment|
Owner name: MOTOROLA, INC., ILLINOIS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:XIE, QIAOBING;STEWART, RANDALL R.;YARROLL, LA MONTE HENRY PIGGY;REEL/FRAME:012404/0043;SIGNING DATES FROM 20011127 TO 20011205
|Dec 22, 2009||FPAY||Fee payment|
Year of fee payment: 4
|Dec 13, 2010||AS||Assignment|
Owner name: MOTOROLA MOBILITY, INC, ILLINOIS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOTOROLA, INC;REEL/FRAME:025673/0558
Effective date: 20100731
|Oct 2, 2012||AS||Assignment|
Owner name: MOTOROLA MOBILITY LLC, ILLINOIS
Free format text: CHANGE OF NAME;ASSIGNOR:MOTOROLA MOBILITY, INC.;REEL/FRAME:029216/0282
Effective date: 20120622
|Dec 30, 2013||FPAY||Fee payment|
Year of fee payment: 8
|Nov 21, 2014||AS||Assignment|
Owner name: GOOGLE TECHNOLOGY HOLDINGS LLC, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOTOROLA MOBILITY LLC;REEL/FRAME:034311/0001
Effective date: 20141028