|Publication number||US6886040 B1|
|Application number||US 10/142,232|
|Publication date||Apr 26, 2005|
|Filing date||May 8, 2002|
|Priority date||Oct 28, 1998|
|Also published as||US6421720, US20010023454|
|Publication number||10142232, 142232, US 6886040 B1, US 6886040B1, US-B1-6886040, US6886040 B1, US6886040B1|
|Inventors||Cary W. FitzGerald|
|Original Assignee||Cisco Technology, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (26), Non-Patent Citations (2), Referenced by (30), Classifications (20), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation of prior U.S. Ser. No. 09/181,947, filed Oct. 28, 1998 now U.S. Pat. No. 6,421,720.
This invention relates generally to packet networks and more particularly to a system for adapting packet payload size to the amount of network congestion.
A data stream is transmitted over a packet network by first formatting the data stream into multiple discrete packets. For example, in Voice Over Internet Protocol (VoIP) applications, a digitized audio stream is quantized into packets that are placed onto a packet network and routed to a packet telephony receiver. The receiver converts the packets back into a continuous digital audio stream that resembles the input audio stream. A codec (a compression/decompression algorithm) is used to reduce the communication bandwidth required for transmitting the audio packets over the network.
A large amount of network bandwidth is required for overhead when a data steam is converted and transmitted as packets. For example, in Realtime Transport Protocol (RTP)-encapsulated VoIP, a very common codec technique packetizes two 10 millisecond (ms) frames of speech into one audio packet. For a 8 kilobit per second (Kbit/s) coder, the 20 milliseconds of speech uses 20 bytes of the audio packet. There are an additional 40 bytes of the audio packet used for overhead, 20 bytes for an IP header, 8 bytes for an UDP header, and 12 bytes for a RTP header. The overhead to payload ratio is then 2 to 1, with two bytes of packet header for every one byte of audio packet payload.
When the packet network is congested, it is important to use network bandwidth efficiently. When there is too much congestion, a network processing node may drop some of the transmitted packets. Depending upon the speech encoding algorithm used in the audio encoder, the sound quality of the audio signal degenerates rapidly as more packets are discarded. The large overhead required for transmitting a data stream over the packet network substantially increases this network congestion causing more packets to be delayed or even dropped, in turn, reducing the quality of data transmitted over the packet network.
Accordingly, a need remains for a system that uses network bandwidth more effectively to improve transmission quality of data streams in a packet network.
The size of packet payloads are dynamically adapted to the amount of congestion in a packet network. More data is put in packet payloads when more congestion exists in the packet network. When network congestion is high, less network bandwidth is available for transmitting packets. Accordingly, the packets are transmitted with larger payloads. When there is little or no network congestion smaller packet payloads are transmitted. The additional overhead created in transmitting smaller packets is acceptable when there is little or no network congestion because the network has excess bandwidth. When the network is congested, this excess bandwidth no longer exists. Thus, more payload is loaded into each packet to reduce the overhead to payload ratio and, in turn, reduce bandwidth consumption. Thus, the packet payloads are dynamically adjusted to use network resources more effectively. Some users may be willing to trade off the delay inherent in packing more frames into a packet for increased efficiency.
Data is transmitted over the packet network by first encoding a data stream into encoded data. The encoded data is converted by a packetizer into packets having a packet header and a packet payload. The packetizer transmits the packets over the packet network to a receiving endpoint while monitoring congestion in the packet network.
In one embodiment of the invention, the data stream is an audio or video data stream generated by a telephone. The packetizer packetizes the encoded audio data into audio packets having a header and an audio payload. The size of the audio payload is increased by packing more audio frames into each audio packet. The size of audio payloads is then decreased when the packet network is no longer congested. Congestion is detected by measuring end-to-end delay between a transmitting gateway and a receiving gateway using an existing protocol such as RTCP.
The foregoing and other objects, features and advantages of the invention will become more readily apparent from the following detailed description of a preferred embodiment of the invention which proceeds with reference to the accompanying drawings.
The packet telephony system 12 includes multiple telephone handsets 14 connected to a packet network 16 through gateways 18. The packet gateways 18 each include a codec for converting audio signals into audio packets and converting the audio packets back into audio signals. The handsets 14 are traditional telephones. Gateways 18 and the codecs used by the gateways 18 are any one of a wide variety of commercially available devices used for connecting the handsets 14 to the packet network 16. For example, the gateways 18 can be Voice Over Internet Protocol (VoIP) telephones or personal computers that include a digital signal processor (DSP) and software for encoding audio signals into audio packets.
The gateways 18 operate as a transmitting gateway when encoding audio signals into audio packets and transmitting the audio packets over the packet network 16 to a receiving gateway. The gateways 18 operate as the receiving gateway when receiving audio packets over the packet network 16 and decoding the audio packets back into audio signals.
A gateway transmit path is shown in the transmitting packet gateway 20 in FIG. 2. The transmitting packet gateway 20 includes a voice encoder 22, a packetizer 24, and a transmitter 26. Voice encoder 22 implements the compression half of a codec. Packetizer 24 accepts compressed audio data from encoder 22 and formats the data into packets for transmission. The packetizer 24 receives an end-to-end delay signal 25 back from packet network 16. The end-to-end delay signal 25 is generated in various ways such as from a Real Time Protocol (RTP) report sent back from a receiving packet gateway 28 shown in
The receiving packet gateway 28 is shown in FIG. 3. The receiving gateway 28 reverses the process in transmitting gateway 20. A depacketizer 30 accepts packets from packet network 18 and separates out the audio frames. A jitter buffer 32 buffers the audio frames and outputs them to a voice decoder 34 in an orderly manner. The voice decoder 34 implements the decompression half of the codec employed by voice encoder 22 (FIG. 2). The decoded audio frames are then output to telephone 14. The operations necessary to transmit and receive audio packets performed by the voice encoder 22, decoder 34, transmitter 26, packetizer 24 and depacketizer 30 are well known and, therefore, not described in further detail.
Referring back to
To reduce congestion, the overhead to payload ratio between a packet header 15 and a packet payload 17 in the packet 13 is adapted to the current congestion conditions in packet network 16. When there is little or no congestion on the packet network 16, a smaller packet payload 17 is packed into each voice packet 13. The delay in transmitting the audio packet 13 is, in turn, shorter because the transmitting gateway 20 encodes and transmits a shorter portion of an audio stream 10 output from one of telephones 14.
When the packet network 16 is congested, the transmitting gateway 20 increases the amount of audio data (payload) 17 as shown in audio packet 21. The audio payload is dynamically increased while keeping header 15 the same size. Less network bandwidth is used to transmit the audio stream 10 because more audio data is transmitted using the same amount of packet overhead 15. This reduces congestion on the packet network 16 and reduces the likelihood of packets being dropped or further delayed.
Network congestion is inferred by the amount of time it takes the audio packets to travel between the transmitting gateway 20 and the receiving gateway 28. This end-to-end delay 11 is calculated using existing packet based voice protocols, such as Real Time Protocol (RTP RFC 1889) and Real Time Control Protocol (RTCP). RTP provides end-to-end transport for applications of streaming or real-time data, such as audio or video. RTCP provides estimates of network performance.
RTP and RTCP enable the receiving gateway to synchronize the received packets in the proper order so the user hears or sees the information correctly. Logical framing defines how the protocol “frames” or packages the audio or video data into bits (packets) for transport over a selected communications channel. Sequence numbering determines the order of data packets transported over a communications channel. RTCP also contains a system for determining end-to-end delay and periodically reporting that end-to-end delay back to the transmitting gateway 20. Any other dynamic measure of end-to-end delay or network congestion can similarly be used as an congestion identifier to packetizer 24.
The audio packets 40, 42 and 44 are transmitted over the packet network 16 using an Internet Protocol (IP). The audio packets include an IP header that is 20 bytes long, a User Datagram Protocol (UDP) header that is 8 bytes long, an RTP header that is 12 bytes long, and a variable sized audio payload. With little or no network congestion, usually 20 ms of speech are packed into audio packet 40. The 20 ms of speech is encoded into approximately 20 bytes of packet payload. The 40 bytes of overhead including the IP header, UDP header, and RTP header in packet 40 takes up two thirds of audio packet 40. Every 20 ms. (50 times per second) a 60 byte packet 40 is then generated and transmitted by transmitting gateway 20 (FIG. 2).
When there is medium congestion in the packet network 16, audio packets similar to packet 42 are generated by the packetizer 24 (FIG. 2). The packet 42 carries 40 ms of audio data in a 40 byte packet payload but still uses only 40 bytes of overhead. The overhead ratio for transmitting 40 ms of speech is thereby reduced to one half of the total size of packet 42 at the cost of a 40 ms delay.
If heavy congestion is detected on the packet network 16, the packetizer 24 generates audio packets similar to packet 44. Packet 44 has a still larger audio payload of 100 ms. or more. The overhead ratio for transmitting 100 ms of speech is reduced further to one fifth of the total size of packet 44.
It should be noted that the amount of audio data in each packet is varied independently of the audio encoder 22 (FIG. 22). Thus, the encoding scheme used to encode and decode the audio data does not have to be changed for different packet network conditions. This reduces encoder complexity. Because the size of audio packets and audio packet payloads is relayed in the packet header information, no modifications have to be made to existing network transport protocols. There are several well known algorithms for performing real-time adaptation that can be applied here.
If the payload size is within range, the packetizer 24 jumps back to step 48 and continues to packetize audio data at the current payload size. If the current payload size is not within an acceptable range for the current network congestion, decision step 54 determines whether the current packet payload is either too small or too large.
Decision step 54 decides whether the packet payload size is too small for the current end-to-end delay. If so, the packetizer 24 automatically increases the audio packet payload size in step 56. If the packet payload is too large, the audio packet payload size is automatically decreased by the packetizer 24 in step 58. The packetizer then jumps back to step 48 and packetizes audio data at the new packet payload size.
The invention dynamically changes the overhead to packet payload ratio to more effectively adapt to current network congestion conditions. By improving network bandwidth efficiency, the quality of streaming and real-time data transmitted over the packet network is improved.
Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention can be modified in arrangement and detail without departing from such principles. I claim all modifications and variation coming within the spirit and scope of the following claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4731816||Jan 12, 1987||Mar 15, 1988||Telebit Corporation||Ensemble modem structure for imperfect transmission media|
|US4769815 *||Apr 10, 1987||Sep 6, 1988||American Telephone And Telegraph Company, At&T Bell Laboratories||Packet flow control method|
|US4771391 *||Jul 21, 1986||Sep 13, 1988||International Business Machines Corporation||Adaptive packet length traffic control in a local area network|
|US5115429 *||Aug 2, 1990||May 19, 1992||Codex Corporation||Dynamic encoding rate control minimizes traffic congestion in a packet network|
|US5231633 *||Jul 11, 1990||Jul 27, 1993||Codex Corporation||Method for prioritizing, selectively discarding, and multiplexing differing traffic type fast packets|
|US5384770 *||May 8, 1992||Jan 24, 1995||Hayes Microcomputer Products, Inc.||Packet assembler|
|US5506844 *||May 20, 1994||Apr 9, 1996||Compression Labs, Inc.||Method for configuring a statistical multiplexer to dynamically allocate communication channel bandwidth|
|US5541919 *||Dec 19, 1994||Jul 30, 1996||Motorola, Inc.||Multimedia multiplexing device and method using dynamic packet segmentation|
|US5764645 *||Jun 12, 1996||Jun 9, 1998||Microsoft Corporation||IP/ATM network adaptation|
|US5826032 *||Feb 12, 1996||Oct 20, 1998||University Of Southern California||Method and network interface logic for providing embedded checksums|
|US5940479 *||Oct 1, 1996||Aug 17, 1999||Northern Telecom Limited||System and method for transmitting aural information between a computer and telephone equipment|
|US6002669 *||Mar 25, 1997||Dec 14, 1999||White; Darryl C.||Efficient, multi-purpose network data communications protocol|
|US6003089 *||Mar 31, 1997||Dec 14, 1999||Siemens Information And Communication Networks, Inc.||Method for constructing adaptive packet lengths in a congested network|
|US6005871 *||Oct 30, 1996||Dec 21, 1999||Telefonaktiebolaget Lm Ericsson||Minicell alignment|
|US6006253 *||Oct 31, 1997||Dec 21, 1999||Intel Corporation||Method and apparatus to provide a backchannel for receiver terminals in a loosely-coupled conference|
|US6052368 *||May 22, 1998||Apr 18, 2000||Cabletron Systems, Inc.||Method and apparatus for forwarding variable-length packets between channel-specific packet processors and a crossbar of a multiport switch|
|US6075770 *||Nov 20, 1996||Jun 13, 2000||Industrial Technology Research Institute||Power spectrum-based connection admission control for ATM networks|
|US6298057 *||Apr 19, 1996||Oct 2, 2001||Nortel Networks Limited||System and method for reliability transporting aural information across a network|
|US6370163 *||Mar 11, 1998||Apr 9, 2002||Siemens Information And Communications Network, Inc.||Apparatus and method for speech transport with adaptive packet size|
|US6421720 *||Oct 28, 1998||Jul 16, 2002||Cisco Technology, Inc.||Codec-independent technique for modulating bandwidth in packet network|
|US6466586 *||Mar 31, 1998||Oct 15, 2002||Nortel Networks Limited||Digital subscriber line framing structure supporting imbedded rate adaptive synchronous and asynchronous traffic|
|US20020018465 *||Oct 16, 2001||Feb 14, 2002||Rosenberg Jonathan David||Methods and apparatus for providing voice communications through a packet network|
|US20020090114 *||Dec 13, 2001||Jul 11, 2002||Rhoads Geoffrey B.||Watermark enabled video objects|
|US20020093982 *||Aug 18, 1998||Jul 18, 2002||George Joy||Dynamic sizing of data packets|
|US20030053462 *||Oct 25, 2002||Mar 20, 2003||Compaq Computer Corporation||System and method for implementing multi-pathing data transfers in a system area network|
|EP0942560A2 *||Feb 8, 1999||Sep 15, 1999||Siemens Information and Communication Networks Inc.||Apparatus and method for speech transport with adaptive packet size|
|1||*||Hashimoto, "End-to End QoS Archetecture for Continous Media Services", 1998, IEEE, pp. 490-495.|
|2||*||Lettieri et al., "Adaptive Frame Length Control for Improving Wireless Link:", 1998, IEEE, pp. 564-571.*|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7089320 *||Jun 1, 2001||Aug 8, 2006||Cisco Technology, Inc.||Apparatus and methods for combining data|
|US7369488 *||Feb 26, 2004||May 6, 2008||Matsushita Electric Industrial Co., Ltd.||Wireless LAN apparatus for changing packet length according to changing conditions|
|US7391736 *||Jul 11, 2003||Jun 24, 2008||Samsung Electronics Co., Ltd.||Method and apparatus for transmitting packet data having compressed header|
|US7613181 *||Nov 2, 2005||Nov 3, 2009||Daniel Lecomte||Process and device for securing the transmission, recording and viewing of digital, audiovisual packetized streams|
|US7613182 *||Feb 1, 2006||Nov 3, 2009||Daniel Lecomte||Distributed and secured method and system for protecting and distributing audiovisual flows|
|US7633941 *||Mar 23, 2006||Dec 15, 2009||Daniel Lecomte||Secured distributed method and system for the distribution of audiovisual flows|
|US7643478 *||Nov 24, 2004||Jan 5, 2010||Medialive Sa||Secure and personalized broadcasting of audiovisual streams by a hybrid unicast/multicast system|
|US7733785||Jan 31, 2007||Jun 8, 2010||International Business Machines Corporation||Method and system for dynamically adjusting packet size to decrease delays of streaming data transmissions on noisy transmission lines|
|US7773517 *||Nov 19, 2004||Aug 10, 2010||Research In Motion Limited||Method and system for identifying degradation of a media service|
|US7974280 *||Sep 22, 2009||Jul 5, 2011||Querell Data Limited Liability Company||Distributed and secured method and system for protecting and distributing audio-visual flows|
|US7986626||Jul 13, 2010||Jul 26, 2011||Research In Motion Limited||Method and system for identifying degradation of a media service|
|US8254283||Jun 7, 2011||Aug 28, 2012||Research In Motion Limited||Method and system for identifying degradation of a media service|
|US8270402||Sep 24, 2009||Sep 18, 2012||Querell Data Limited Liability Company||Process and device for securing the transmission, recording and viewing of digital audiovisual packetized streams|
|US8687517 *||Jun 8, 2012||Apr 1, 2014||Blackberry Limited||Method and system for identifying degradation of a media service|
|US20040071096 *||Jul 11, 2003||Apr 15, 2004||Seung-Gu Na||Method and apparatus for transmitting packet data having compressed header|
|US20040170152 *||Feb 26, 2004||Sep 2, 2004||Matsushita Electric Industrial Co., Ltd||Wireless LAN apparatus|
|US20050283811 *||Jul 14, 2005||Dec 22, 2005||Medialive, A Corporation Of France||Process for distributing video sequences, decoder and system for carrying out this process|
|US20060072559 *||Nov 2, 2005||Apr 6, 2006||Medialive, A Corporation Of France||Process and device for securing the transmission, recording and viewing of digital, audiovisual packetized streams|
|US20060109786 *||Nov 19, 2004||May 25, 2006||Research In Motion Limited||Method and system for identifying degradation of a media service|
|US20060184686 *||Mar 23, 2006||Aug 17, 2006||Daniel Lecomte||Secure distribution process and system for the distribution of audiovisual streams|
|US20060195875 *||Apr 9, 2004||Aug 31, 2006||Medialive||Method and equipment for distributing digital video products with a restriction of certain products in terms of the representation and reproduction rights thereof|
|US20070189531 *||Feb 1, 2006||Aug 16, 2007||Medialive, A Corporation Of France||Secure distributed process and system for the protection and distribution of audiovisual streams|
|US20080031326 *||Nov 24, 2004||Feb 7, 2008||Medialive||Secure and Personalized Broadcasting of Audiovisual Streams by a Hybrid Unicast/Multicast System|
|US20080259821 *||Jun 27, 2008||Oct 23, 2008||International Business Machines Corporation||Dynamic packet training|
|US20100011393 *||Sep 22, 2009||Jan 14, 2010||Querell Data Limited Liability Company||Distributed and secured method and system for protecting and distributing audio-visual flows|
|US20100017498 *||Jan 21, 2010||Querell Data Limited Liability Company||Process and device for securing the transmission, recording and viewing of digital audiovisual packetized streams|
|US20100278043 *||Jul 13, 2010||Nov 4, 2010||Research In Motion Limited||Method and system for identifying degradation of a media service|
|US20120250554 *||Oct 4, 2012||Research In Motion Limited||Method and system for identifying degradation of a media service|
|EP2127268A1 *||Feb 7, 2008||Dec 2, 2009||TeliaSonera AB||Transmission of real-time user data frames in packets|
|WO2008000289A1 *||Jun 29, 2006||Jan 3, 2008||Telecom Italia Spa||Method and apparatus for improving bandwith exploitation in real-time audio/video communications|
|U.S. Classification||709/224, 709/233|
|International Classification||H04L29/06, H04L12/56|
|Cooperative Classification||H04L65/608, H04L65/80, H04L47/10, H04L47/12, H04L29/06027, H04L47/36, H04L47/24, H04L69/04, H04L1/0007|
|European Classification||H04L47/10, H04L47/12, H04L47/36, H04L47/24, H04L29/06C5, H04L29/06M8, H04L29/06M6P|
|Sep 18, 2008||FPAY||Fee payment|
Year of fee payment: 4
|Oct 26, 2012||FPAY||Fee payment|
Year of fee payment: 8