The present invention relates generally to data transmission systems and, more particularly, to a method and apparatus for improving the quality of information transmitted via a data transmission system.
The Internet was originally developed for transferring bulk data, such as files and email, in small segments commonly referred to as packets. Although it was intended to be a best-effort delivery system, never guaranteeing individual packet delivery, it was nevertheless designed to be extremely resilient, providing a means for routing around individual components upon their failure.
In recent years the Internet has enjoyed immense popularity, in part due to the development of a variety of high-speed data transfer technologies. Even using such high-speed technologies, transferring a large data file (e.g., lengthy document, video file, audio file, etc.) can still be very time consuming. For example, downloading a movie over a standard DSL line typically requires several hours. Accordingly a variety of techniques have been developed, or are under development, in an attempt to minimize the limitations associated with data transfer. A fundamental technique in this area is data compression, which reduces the size of the file/information being transferred.
In developing data transfer technologies, the developer must be mindful of the type of data being transferred as well as any timeliness requirements placed on the data. Many types of data must be transferred perfectly, without alteration (e.g. documents, spreadsheets). This data may be compressed, but the compression algorithm must be completely reversible in order to exactly recover the original data file. Media files (e.g. audio, video, pictures, etc.), however, can be compressed with lossy-compression algorithms that actually throw away information to reduce file size, at the expense of ultimate quality. Therefore, a tradeoff between perceived quality and file size can be made. While quality may be degraded with lossy-compression techniques, the amount of compression achievable is far higher than with lossless compression.
Timeliness refers to whether or not a real-time data stream is required. Although some data is not time-sensitive, a phone or video conversation takes place in real-time and therefore requires timely data delivery. It is also common to play audio or video files in real-time from a remote server. In these approaches the data is sent in packets, with only enough of the data being sent initially to get the sound or image started. Over time, the data file is played-out at the server and sent to the client ‘just in time’ for presentation.
Although the loss of any significant percentage of the data packets leads to an unacceptable quality level in the delivered data (i.e., video and/or audio data), this is typically not a problem with data transferred over a dedicated channel (e.g., cable channel, disc player, etc.). In contrast, data transferred over the Internet suffers from much higher error rates, the higher error rates primarily due to varying levels of Internet traffic, varying hardware capabilities (e.g., link speeds), and individual component/technology failures. Additionally, one or more of the components which make up the underlying Internet network may be subjected to any of a variety of noise or interference sources.
A variety of companies have developed, or are currently developing, services to be delivered to the end user over the Internet (e.g., on-demand movies, interactive video, games, video conferencing, commercial voice services, etc.). In order for such services to be viable, data transmission must be both reliable and of very high quality. Although quality and reliability can typically be achieved by over-provisioning the resources (e.g., transmission redundancy, slow data rates, data transfer verification at the endpoint, etc.), such approaches are both inconvenient and very inefficient, both in terms of transfer rates and overall system usage. Accordingly a variety of adaptation techniques have been developed which can be used to mitigate variations in the hardware, re-route data transfer to avoid congestion, protect against variations in error and available rate, and re-negotiate connection parameters. Typical applications designed to adapt to changing network conditions use any of a variety of encoding, compression, bandwidth smoothing, rate shaping, and error control techniques.
One commonly employed adaptation scheme varies the source rate of the video and/or audio data. Given the direct correlation between source rate and transmitted data quality, high source rates yield desirable quality levels. Unfortunately in the presence of network congestion, high source rates also lead to the loss of data packets, resulting in severely degraded quality if not total data stream failure. As rate reduction can be used to reduce or eliminate congestion, rate adaptive techniques must strike a balance between quality loss due to reduced source rates with the potential for loss or total failure from higher source rates.
Forward Error Correction (FEC) techniques add redundant data to a media stream, thus allowing packet losses to be repaired at the receiver without requiring either contact with the sender or retransmission of lost data. As data retransmission is not used with this technique, its primary advantage is end-to-end speed. The primary tradeoff with FEC schemes is providing sufficient redundant data to compensate for expected packet losses while not providing too much redundant data which adversely affects transfer speed. By varying the amount of applied FEC based on feedback from the client, the technique can be optimized for varying network conditions.
Another adaptation technique, referred to as unequal loss protection, varies the amount of FEC protection encoded by the sender based on the loss-sensitivity of that information. Thus important data (e.g., lower order coefficients of discrete cosine transformation (DCT), critical timing information) are given more protection than less important data.
Although a variety of rate adaptive systems have been designed, these systems are typically designed to adapt based on packet loss at the client system, resulting in the end-user periodically experiencing periods of unacceptable data quality (e.g., drop-outs, frozen frames, etc.). Accordingly, what is needed in the art is a rate adaptive system that provides high speed data transfer while achieving optimal quality levels, the system capable of adapting before packet loss is experienced. The present invention provides such a method and apparatus.
The present invention provides a method and apparatus for optimizing the data transfer rate over the Internet, a wireless network, a satellite based network, a dedicated channel or other communication link. Initially the data is prepared by a transfer rate controller (e.g., encoded, shaped, etc.) and then an FEC algorithm is applied to the data. After the data has been transferred, the quality of the data transfer link is assessed by an application layer FEC decoder that determines if any errors occurred during data transfer and if errors are detected, the magnitude of the errors (i.e., FEC-correctable blocks, FEC-uncorrectable blocks). This information is used to generate a feedback message which is used by the transfer rate controller to adjust and optimize the data transfer rate for the link quality as determined at that point in time. Optimal use results when feedback is sent to the source before end-user data corruption has occurred. By continually monitoring and assessing link quality and providing feedback to the transfer rate controller, the transfer rate can be continually adapted to the varying link quality.
In one embodiment of the invention, in addition to generating feedback used by the transfer rate controller to optimize data transfer rate, the application layer FEC decoder generates feedback that is used by the FEC encoder to optimize the FEC algorithm.
In another embodiment of the invention, the receiver generates feedback which augments the feedback generated by the FEC decoder and used by the transfer rate controller to vary the data transfer rate.
In another embodiment of the invention, a physical layer FEC decoder determines if there are any FEC-correctable blocks and/or FEC-uncorrectable blocks and uses this information to generate the feedback message used by the transfer rate controller to adjust and optimize the data transfer link.
In another embodiment of the invention, a physical layer FEC decoder generates feedback which augments the feedback generated by the application layer FEC decoder and used by the transfer rate controller to vary the data transfer rate.
A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings.
Data channels are subject to errors arising from a variety of time-varying sources such as external noise or interference, router congestion, link congestion, etc., all of which lead to a time varying error rate associated with the channel. This time varying error rate controls the allowable data transfer rate of the channel. If the rate of data transfer over the channel is low enough, the data can be transferred error-free. As the transfer rate over the channel is increased, however, eventually the rate will be high enough that the error characteristics of the channel will cause data to be corrupted or lost. Thus the error rate of the channel establishes an error threshold.
Given the time varying nature of the error threshold, a well designed data transfer system will controllably vary the data transfer rate, maximizing the transfer rate to the level permitted by the channel's error threshold, thereby optimizing the quality of the transferred data.
FEC techniques, which provide a means for replacing data packets lost during data transfer, allow the data transfer rate to exceed the channel's error threshold without the end-user experiencing any data degradation. The extent to which the data transfer rate can exceed the error threshold depends on the amount of redundant data included in the data stream.
In the description of the invention, the terms data rate controller (i.e., controller 403) and data receiver (i.e., receiver 411) are used since the exact nature of the transfer rate controller and the data receiver depends upon the type of data 401 as well as the type of compression technique employed to transfer the data over the transport layer. It is well understood by those of skill in the art that while some data types (e.g., video data, audio data) lend themselves to lossy compression techniques, other data types (e.g., documents, spreadsheets, etc.) require that the full, unaltered bit stream be transferred, or require the use of lossless compression techniques. In addition, if the data stream is being played out in real-time, the information must be sent in a timely manner. For non-real-time data, however, the data-stream can simply be reduced in rate by slowing the transmission of packets using a rate-shaping device.
System 700, shown in
In the embodiments illustrated and discussed above, preferably the required FEC is an application-layer FEC that is applied, and checked, by the data subsystem which can be used across any channel type.
As is well known by those of skill in the art, the last-mile channel or system, which provides the last stretch of data communications into the end-user's home or business (i.e., the final destination for the data), often has much higher error rates than the rest of the network. Consequently this segment will also include one or more FEC encoders/decoders in the physical layer. The embodiments shown in
In a preferred embodiment of the invention, data 401 is comprised of video and/or audio data thereby lending itself to any of a variety of lossy compression techniques (e.g., MPEG-2, MPEG-4, WM-9, MP3, AAC, etc.). Accordingly transfer rate controller 403 is a suitable compressed video encoder (e.g., a trans-coder) or a suitable audio encoder (e.g., a trans-coder) and receiver 411 is a suitable compressed video or audio decoder.
Although it will be appreciated that the invention can utilize any of a variety of well known techniques/devices for controlling the data transfer rate and the exact nature depends both on the type of data and the selected compression technique,
In this embodiment protocol 1115 between streaming video server 1117 and subsequent device 1119 uses MPEG-2 transport stream (TS) packets, 188 bytes each, encapsulated 7 per UDP frame and carried in UDP/IP frames. In the illustrated embodiment, device 1119 is a digital stream management system such as a Terayon DM 6400 CherryPicker™, preferably under the control of a session manager 1121, device 1119 providing both transfer rate control and FEC encoding functionality. Protocol 1115, shown in detail in
Protocol 1123 is used to transport the FEC-encoded data between the sender and the receiver. Protocol 1123 requires two processing steps on both the encoding and decoding sides as shown in
The second processing step of protocol 1123 is an inter-packet byte interleaver. This step is required since Reed-Solomon encoding allows correction of up to T bytes within its codeword. When the DSL channel gets a bit error, the CRC used (see protocol 1127 below) will cause the entire UDP packet to be dropped, resulting in all bytes of all 7 codewords being lost. Accordingly as the FEC algorithm must be able to re-create the entire packet, the data must be spread out preferably such that at most T bytes from any codeword are in any one UDP packet. The interleaver processing step accomplishes this task by interleaving the bytes from a group of source packets in order to create a new group of source packets. Thus the amount of data is unchanged, but it is shuffled (i.e., interleaved) in such a way as to minimize the impact of a lost packet. It will be appreciated that the interleaving process can be performed in a variety of ways.
Rather than using the protocol described above, a standard protocol such as RTP can be used for encapsulating the data such that there are headers with timestamps and/or sequence numbers. This approach will make the discovery of packet loss easier (i.e., the ATM layer will silently discard packets that do not pass CRC check.). It will be appreciated that if a different approach is used, the referenced figures would have to be correspondingly modified, for example adding another small block for packet header generation.
Protocol 1125 is a control protocol that does not carry any of the streaming media, but just includes status information. This is analogous to RTCP, which is part of the RTP protocol (RFC 1889). The purpose of protocol 1125 is for receiver 1111 to report back to sender 1119 on the status of packet reception. Due to the inefficiency of reporting status for each received packet, preferably an adaptive algorithm is used which determines when status information is to be reported back to sender 1119. For example, if no errors are detected then status information would only be reported periodically (e.g., every few seconds). If errors are detected, then status feedback would be provided immediately.
Protocol 1127, shown for completeness, illustrates that there is a level of error checking that happens below the communication protocols used for the invention. DSL systems are typically ATM based and use ATM AAL5 encapsulation to carry all IP packet payloads. This protocol has a 32-bit CRC in a data trailer so that the receiver (i.e., modem 1109 in this example) can check the data for errors. Packets with any bit errors are dropped. As a result, with this type of link-layer protocol a single bit error is turned into a complete packet loss. Therefore the FEC algorithm used in the invention must be able to re-create entire lost packets, not just patch a few wrong bits.
Protocol 1129 is a real-time streaming protocol (RTSP) that is used by IP STB 1111 to request and control video playback. This protocol is not important relative to the invention and is included only for the sake of completeness.
As previously noted, the implementation described above and illustrated in
As will be understood by those familiar with the art, the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Some possible variations are described above. Accordingly, the disclosures and descriptions herein are intended to be illustrative, but not limiting, of the scope of the invention which is set forth in the following claims.