Patent Grant
9717018
The present Application for Patent is related to the following co-pending U.S. Patent Applications:
U.S. patent application Ser. No. 11/129,625, titled “Delivery Of Information Over A Communication Channel”, filed concurrently herewith, assigned to the assignee hereof, and expressly incorporated in its entirety by reference herein.
U.S. patent application Ser. No. 11/129,687, titled “Method And Apparatus For Allocation Of Information To Channels Of A Communication System”, filed concurrently herewith, assigned to the assignee hereof, and expressly incorporated in its entirety by reference herein.
U.S. patent application Ser. No. 11/129,735, titled “Header Compression Of Multimedia Data Transmitted Over A Wireless Communication System”, filed concurrently herewith, assigned to the assignee hereof, and expressly incorporated in its entirety by reference herein.
I. Field
The present invention relates generally to delivery of information over a wireless communication system, and more specifically to synchronization of audio and video data transmitted over a wireless communication system.
II. Background
Various techniques for transmitting multimedia or real-time data, such as audio or video data, over various communication networks have been developed. One such technique is the real-time transport protocol (RTP). RTP provides end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Further details about RTP can be found in “RTP: A Transport Protocol for Real-Time Applications”, H. Schulzrinne [Columbia University], S. Casner [Packet Design], R. Frederick [Blue Coat Systems Inc.], V. Jacobson [Packet Design], RFC-3550 draft standard, Internet Engineering Steering Group, July 2003 incorporated by reference herein, in its entirety.
An example illustrating aspects of RTP is an audio conferences where the RTP is carried on top of Internet Protocol (IP) services of the Internet for voice communications. Through an allocation mechanism, an originator of the conference obtains a multicast group address and pair of ports. One port is used for audio data, and the other is used for control (RTCP) packets. This address and port information is distributed to the intended participants. The audio conferencing application used by each conference participant sends audio data in small partitions, for examples partitions of 20 ms duration. Each partition of audio data is preceded by an RTP header; and the combined RTP header and data are encapsulated into a UDP packet. The RTP header includes information about the data, for example it indicates what type of audio encoding, such as PCM, ADPCM or LPC, is contained in each packet, Time Stamp (TS) the time at which the RTP packet is to be rendered, Sequence Number (SN) a sequential number of the packet that can be used to detect lost/duplicate packets, etc. This allows senders to change the type of encoding used during a conference, for example, to accommodate a new participant that is connected through a low-bandwidth link or react to indications of network congestion.
In accordance with the RTP standard, if both audio and video media are used in an RTP conference, they are transmitted as separate RTP sessions. That is, separate RTP and RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same name in the RTCP packets for both so that the sessions can be associated.
A motivation for transmitting audio and video as separate RTP sessions is to allow some participants in the conference to receive only one medium if they choose. Despite the separation, synchronized playback of a source's audio and video can be achieved using timing information carried in the RTP/RTCP packets for both sessions.
Packet networks, like the Internet, may occasionally lose, or reorder, packets. In addition, individual packets may experience variable amounts of delay in their respective transmission times. To cope with these impairments, the RTP header contains timing information and a sequence number that allow a receiver to reconstruct the timing produced by the source. This timing reconstruction is performed separately for each source of RTP packets in a session.
Even though the RTP header includes timing information and a sequence number, because the audio and video are delivered in separate RTP streams, there is potential time slip, also referred to as lip-synch or AV-synch, between the streams. An application at a receiver will have to re-synchronize these streams prior to rendering audio and video. In addition, in applications where RTP streams, such as audio and video, are transmitted over wireless networks there is an increased likelihood that packets may be lost, thereby making re-synchronization of streams more difficult.
There is therefore a need in the art for improving the synchronization of audio and video RTP streams that are transmitted over networks.
Embodiments disclosed herein address the above stated needs by encoding data streams, such as an audio video stream, that is transmitted over a network, for example a wireless or IP network, such that an the data streams are synchronized. For example, an entire frame of audio and an entire frame of video are transmitted within a frame period required to render the audio and video frames by an application in the receiver. For example, a data stream synchronizer may include a first decoder configured to receive a first encoded data stream and to output a decoded first data stream, wherein the first encoded data stream has a first bit rate during an information interval. The data synchronized may also include a second decoder configured to receive a second encoded data stream and to output a decoded second data stream, wherein the second encoded data stream has a second bit rate during the information interval. A first buffer is configured to accumulate the first decoded data stream for at least one information interval and to output a frame of the first decoded data stream each interval period. A second buffer configured to accumulate the second decoded data stream for at least one information interval and to output a frame of the second decoded data stream each interval period. Then a combiner that is configured to receive the frame of first decoded data stream and the frame of second decoded data stream outputs a synchronized frame of first and second decoded data streams. The first encoded data stream may be video data, and the second encoded data stream may audio data.
An aspect of this technique includes receiving an audio and video RTP streams and assigning an entire frame of RTP video data to communication channel packets that occupy the same period, or less, as the video frame rate. Also an entire frame of RTP audio data is assigned to communication channel packets that occupy the same period, or less, as the audio frame rate. The video and audio communication channel packets are transmitted simultaneously. Receiving and assigning RTP streams can be performed in a remote station, or a base station.
Another aspect is to receive communication channel packets that include audio and video data. Decoding the audio and video data and accumulating the data for a period equal the frame period of the audio and video data. At the end of the frame period a frame of video and a frame of audio are combined. Because the audio frame and video frame are transmitted at the same time, and each transmission occurs within a frame period, the audio and video frames are synchronized. Decoding and accumulating can be performed in a remote station or a base station.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.
The word “streaming” is used herein to mean real time delivery of multimedia data of continuous in nature, such as, audio, speech or video information, over dedicated and shared channels in conversational, unicast and broadcast applications. The phrase “multimedia frame”, for video, is used herein to mean video frame that can be displayed/rendered on a display device, after decoding. A video frame can be further divided in to independently decodable units. In video parlance, these are called “slices”. In the case of audio and speech, the term “multimedia frame” is used herein to mean information in a time window over which speech or audio is compressed for transport and decoding at the receiver. The phrase “information unit interval” is used herein to represent the time duration of the multimedia frame described above. For example, in case of video, information unit interval is 100 milliseconds in the case of 10 frames per second video. Further, as an example, in the case of speech, the information unit interval is typically 20 milliseconds in cdma2000, GSM and WCDMA. From this description, it should be evident that, typically audio/speech frames are not further divided in to independently decodable units and typically video frames are further divided in to slices that are independently decodable. It should be evident form the context when the phrases “multimedia frame”, “information unit interval”, etc. refer to multimedia data of video, audio and speech.
Techniques for synchronizing RTP streams transmitted over a set of constant bit rate communication channels are described. The techniques include partitioning information units that are transmitted in RTP streams into data packets wherein the size of the data packets are selected to match physical layer data packet sizes of a communication channel. For example, audio and video data that are synchronized to each other may be encoded. The encoder may be constrained such that it encodes the data into sizes that match available physical layer packet sizes of the communication channel. Constraining the data packet sizes to match one or more of the available physical layer packet sizes supports transmitting multiple RTP streams that are synchronized because the RTP streams are transmitted simultaneously or serially, but within the time frame the audio and video packets are required to be rendered with synchronization. For example, if audio and video RTP streams are transmitted, and the data packets are constrained so that their size matches available physical layer packets, then the audio and video data are transmitted within the display time and are synchronized. As the amount of data needed to represent the RTP stream varies the communication channel capacity varies through selection of different physical layer packet sizes as described in co-pending applications listed in REFERENCE TO CO-PENDING APPLICATIONS FOR PATENTS above.
Examples of information units, such as RTP streams, include variable bit rate data streams, multimedia data, video data, and audio data. The information units may occur at a constant repetition rate. For example, the information units may be frames of audio/video data.
Different domestic and international standards have been established to support the various air interfaces including, for example, Advanced Mobile Phone Service (AMPS), Global System for Mobile (GSM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Interim Standard 95 (IS-95) and its derivatives, IS-95A, IS-95B, ANSI J-STD-008 (often referred to collectively herein as IS-95), and emerging high-data-rate systems such as cdma2000, Universal Mobile Telecommunications Service (UMTS), wideband CDMA, WCDMA, and others. These standards are promulgated by the Telecommunication Industry Association (TIA), 3rd Generation partnership Project (3GPP), European Telecommunication Standards Institute (ETSI), and other well-known standards bodies.
The infrastructure 101 may also include other components, such as base stations 102, base station controllers 106, mobile switching centers 108, a switching network 120, and the like. In one embodiment, the base station 102 is integrated with the base station controller 106, and in other embodiments the base station 102 and the base station controller 106 are separate components. Different types of switching networks 120 may be used to route signals in the communication system 100, for example, IP networks, or the public switched telephone network (PSTN).
The term “forward link” or “downlink” refers to the signal path from the infrastructure 101 to a MS, and the term “reverse link” or “uplink” refers to the signal path from a MS to the infrastructure. As shown in
Examples of a MS 104 include cellular telephones, wireless communication enabled personal computers, and personal digital assistants (PDA), and other wireless devices. The communication system 100 may be designed to support one or more wireless standards. For example, the standards may include standards referred to as Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS2000, HRPD, cdma2000, Wideband CDMA (WCDMA), and others.
The serving node 208 may comprise, for example, a packet data serving node (PDSN) or a Serving GPRS Support Node (SGSN) or a Gateway GPRS Support Node (GGSN). The serving node 208 may receive packet data from the sending node 206, and serve the packets of information to the controller 210. The controller 210 may comprise, for example, a Base Station Controller/Packet Control Function (BSC/PCF) or Radio Network Controller (RNC). In one embodiment, the controller 210 communicates with the serving node 208 over a Radio Access Network (RAN). The controller 210 communicates with the serving node 208 and transmits the packets of information over the wireless channel 202 to at least one of the recipient nodes 204, such as an MS.
In one embodiment, the serving node 208 or the sending node 206, or both, may also include an encoder for encoding a data stream, or a decoder for decoding a data stream, or both. For example the encoder could encode an audio/video stream and thereby produce frames of data, and the decoder could receive frames of data and decode them. Likewise, a MS may include an encoder for encoding a data stream, or a decoder for decoding a received data stream, or both. The term “codec” is used to describe the combination of an encoder and a decoder.
In one example illustrated in
The air interface 202 may operate in accordance with any of a number of wireless standards. For example, the standards may include standards based on TDMA, such as Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), or standards based on CDMA such as TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS2000, HRPD, cdma2000, Wideband CDMA (WCDMA), and others.
As shown in
In
The video RTP packets are allocated to communication channel packets 306. In a conventional communication channel, such as CDMA or GSM, the communication channel data packets 306 are a constant size, and are transmitted at a constant rate. For example, the communication channel data packets 306 may be transmitted at a 50 Hz rate, that is, a new data packet is transmitted every 20 milliseconds. Because the communication channel packets are a constant size, it takes more communication channel packets to transmit the larger RTP packets. Thus, it takes more communication channel packets 306 to transmit RTP packets corresponding to I video frames N and N+4, than communication channel packets needed to transmit the smaller RTP packets corresponding to P video frames N+1, N+2 and N+3. In the example illustrated in
For each frame of video data there is a corresponding audio data.
As shown in
Comparison between the assignment of the video frames and audio frames to their respective communication channel packets illustrates the loss of synchronization between the audio and video frames. In the example illustrated in
For example, in
Because video encoders such as H.263, AVC/H.264, MPEG-4, etc. are inherently variable rate in nature due to predictive coding and also due to the use of variable length coding (VLC) of many parameters, real time delivery of variable rate bitstreams over circuit switched networks and packet switched networks is generally accomplished by traffic shaping with buffers at the sender and receiver. Traffic shaping buffers introduces additional delay which is typically undesirable. For example, additional delay can be annoying during teleconferencing when there is delay between when a person speaks and when another person hears the speech.
For example, because video at a receiver of the communication channel is played back at the same rate as the original video frame rate, delays in the communication channel can cause pauses in the playback. In
In
The video RTP packets are allocated to communication channel packets 406. Using techniques as described in co-pending application listed in REFERENCE TO CO-PENDING APPLICATIONS FOR PATENT above, the capacity of the communication channel is variable. Because of the variable capacity of the communication channel packets 406, the video frame N can be transmitted in a block 408 containing five communication channel packets 406.
In a conventional communication channel, such as standards based on CDMA such as TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS2000, HRPD, cdma2000, and Wideband CDMA (WCDMA), the communication channel data packets 406 may be transmitted at a 50 Hz rate, that is, a new data packet is transmitted every 20 milliseconds. Because the communication channel packets 406 capacity can be varied, the encoding of the video frame N can be constrained such that the entire video frame N can be transmitted during a frame period. As shown in
As illustrated in
For each frame of video data 302 there is a corresponding audio frame 320. Each audio frame N, N+1, N+2, N+3, N+4, and N+5 corresponds to the respective video frame and occurs at a 10 Hz rate, that is a new audio frame begins every 100 milliseconds. As discussed in relation to
In
It is noted that, as illustrated in
As described below, depending on aspects of the communication network, different techniques can be used to synchronize RTP streams. For example, the communication network may be over provisioned, that is it has excess capacity, or the communication network may have a guaranteed Quality of Service. In addition, the RTP streams may be modified so as to maintain synchronization when transmitted over a communication network. Each of these techniques will be discussed below.
Over Provisioned Communication Network
In the scenario when a communication link between PDSN 208 and the sender 206 is over provisioned, that is, there is excess capacity available for transmission of data over the wireline Internet, then there is no delay due to congestion. Because there is excess capacity in the communication link there is no need to delay a transmission so that the transmission can be accommodated by the communication link. With no delay in transmission there is no “time slip” between voice and video packets as they arrive at the infrastructure, such as at a PDSN. In other words, the audio and video data remain synchronized to each other up to the PDSN and the synchronization is maintained between the PDSN and the MS, as described in this invention.
In the over provisioned scenario, audio-visual synchronization is easily accomplished. For example, video data may have a frame rate of 10 frames per second (fps), based on a 100 millisecond frame, and the associated audio may have a frame rate of 50 fps, based on a 20 millisecond speech frame. In this example, five frames of received audio data would be buffered, so that it would be synchronized with the video frame rate. That is, five frames of audio data would be buffered, corresponding to 100 milliseconds of audio data, so that it would be synchronized to the 100 millisecond video frame.
Communication Networks with a Guaranteed QoS on Maximum Delay
By buffering an appropriate number of higher frame rate speech frames it is possible to match a lower frame rate video frame. In general, if video packets are delivered with a quality of service (QoS) delay guarantee:
QoS_delay=nT ms Eq. 1
where n is the delay in frames; and
T=1000/frames_per_second
Then a buffer sized to store nT/w speech frames, where w is the duration of speech frames in milliseconds, is needed to store enough speech frames to ensure that the speech and video can be synchronized. In cdma2000 UMTS, the duration of a speech frame, w, is 20 milliseconds, in other communication channels the duration of a speech frame may be different, or vary.
Another technique for synchronization of audio and video data includes buffering both data streams. For example, if a communication system has a guaranteed maximum delay of DQ milliseconds, meaning that DQ is the maximum delay that can be experienced during the transmission of audio and video streams, then an appropriate sized buffer can be employed to maintain synchronization.
For example, with a guaranteed maximum delay of DQ, then buffering DQ/T video frames (T is the duration of video frames in milliseconds) and DQ/w speech frames (w is the duration of speech frames in milliseconds) will ensure audio video synchronization (AV-synch). These additional buffer spaces are commonly called a de-jitter buffer.
The techniques described synchronization of audio and video data streams. The techniques can be used with any data streams that need to be synchronized. If there are two data streams, a first higher bit rate data stream and a second lower bit rate data stream that have the same information interval and need to be synchronized, then buffering the higher bit rate data allows it to be synchronized with the lower bit rate data. The size of the buffer can be determined, depending on a QoS as described above. Likewise, both the higher and lower bite rate data streams can be buffered and synchronized as described above.
The techniques described can be performed by a data stream synchronizer that includes a first decoder configured to receive a first encoded data stream and to output a decoded first data stream, wherein the first encoded data stream has a first bit rate during an information interval. And a second decoder configured to receive a second encoded data stream and to output a decoded second data stream, wherein the second encoded data stream has a second bit rate during the information interval. The data stream synchronized also includes a first buffer configured to accumulate the first decoded data stream for at least one information interval and to output a frame of the first decoded data stream each interval period, and a second buffer configured to accumulate the second decoded data stream for at least one information interval and to output a frame of the second decoded data stream each interval period. Then a combiner configured to receive the frame of first decoded data stream and the frame of second decoded data stream and to output a synchronized frame of first and second decoded data streams. In one example, the first encoded data stream may be video data and the second encoded data stream is audio data, such that the first bit rate is higher than the second bit rate.
Single RTP Stream with Audio and Video Multiplexed
Another embodiment is to carry audio and video in a single RTP stream. As noted, it is not common practice in IP networks to transmit audio and video as a single RTP stream. RTP was designed to enable participants with different resources, for example, terminals capable of both video and audio, and terminals capable of only audio, to communicate in the same multimedia conference.
The restriction of transmitting audio and video as separate RTP streams may not be applicable in a wireless network for video services. In this case, a new RTP profile may be designed to carry specific speech and video codec payloads. Combination of audio and video into a common RTP stream eliminates any time slip between the audio and video data without requiring an over provisioned communication network. Hence, audio video synchronization can be accomplished using techniques described in connection with an over provisioned network as described above.
The video and audio communication channel packets are output by the video and audio communication channel interfaces 602 and 604 respectively and communicated to a combiner 606. The combiner 606 is configured to accept the video and audio communication channel packets and to combine them and to output a composite signal. The output of the combiner 606 is communicated to a transmitter 608 that transmits that composite signal to the wireless channel. Operation of the video communication channel interface 602, audio communication channel interface 604 and combiner 606 may be controlled by a controller 614.
Signals from the infrastructure are received by the network interface 906 and sent to the host processor 910. The host processor 910 receives the signals and, depending on the content of the signal, responds with appropriate actions. For example, the host processor 910 may decode the received signal itself, or it may route the received signal to the codec 908 for decoding. In another embodiment, the received signal is sent directly to the codec 908 from the network interface 906.
In one embodiment, the network interface 906 may be a transceiver and an antenna to interface to the infrastructure over a wireless channel. In another embodiment, the network interface 906 may be a network interface card used to interface to the infrastructure over landlines. The codec 908 may be implemented as a digital signal processor (DSP), or a general processor such as a central processing unit (CPU).
Both the host processor 910 and the codec 908 are connected to a memory device 912. The memory device 812 may be used to store data during operation of the WCD, as well as store program code that will be executed by the host processor 910 or the DSP 908. For example, the host processor, codec, or both, may operate under the control of programming instructions that are temporarily stored in the memory device 912. The host processor 910 and codec 908 also can include program storage memory of their own. When the programming instructions are executed, the host processor 910 or codec 908, or both, perform their functions, for example decoding or encoding multimedia streams, such as audio/video data and assembling the audio and video frames. Thus, the programming steps implement the functionality of the respective host processor 910 and codec 908, so that the host processor and codec can each be made to perform the functions of decoding or encoding content streams and assembling frames as desired. The programming steps may be received from a program product 914. The program product 914 may store, and transfer the programming steps into the memory 912 for execution by the host processor, codec, or both.
The program product 914 may be semiconductor memory chips, such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, as well as other storage devices such as a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art that may store computer readable instructions. Additionally, the program product 914 may be the source file including the program steps that is received from the network and stored into memory and is then executed. In this way, the processing steps necessary for operation in accordance with the invention may be embodied on the program product 914. In
The user interface 916 is connected to both the host processor 910 and the codec 908. For example, the user interface 916 may include a display and a speaker used to output multimedia data to the user.
Those of skill in the art will recognize that the step of a method described in connection with an embodiment may be interchanged without departing from the scope of the invention.
Those of skill in the art would also understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
The present Application for Patent claims priority to U.S. Provisional Application No. 60/571,673, entitled “Multimedia Packets Carried by CDMA Physical Layer Products”, filed May 13, 2004, and assigned to the assignee hereof and hereby expressly incorporated by reference herein
| Number | Name | Date | Kind |
|---|---|---|---|
| 4948019 | Rodum | Aug 1990 | A |
| 5510842 | Phillips et al. | Apr 1996 | A |
| 5537409 | Moriyama et al. | Jul 1996 | A |
| 5541852 | Eyuboglu et al. | Jul 1996 | A |
| 5557332 | Koyanagi et al. | Sep 1996 | A |
| 5559608 | Kunihiro | Sep 1996 | A |
| 5570372 | Shaffer | Oct 1996 | A |
| 5572705 | Carson | Nov 1996 | A |
| 5583652 | Ware | Dec 1996 | A |
| 5646693 | Cismas | Jul 1997 | A |
| 5717464 | Perkins et al. | Feb 1998 | A |
| 5729534 | Jokinen et al. | Mar 1998 | A |
| 5844600 | Kerr | Dec 1998 | A |
| 5867230 | Wang et al. | Feb 1999 | A |
| 5898695 | Fujii et al. | Apr 1999 | A |
| 5914717 | Kleewein et al. | Jun 1999 | A |
| 6023552 | Kunihiro | Feb 2000 | A |
| 6041067 | Takamori et al. | Mar 2000 | A |
| 6058141 | Barger et al. | May 2000 | A |
| 6085270 | Gulick | Jul 2000 | A |
| 6108626 | Cellario et al. | Aug 2000 | A |
| 6111916 | Talluri et al. | Aug 2000 | A |
| 6154780 | Zhu | Nov 2000 | A |
| 6181711 | Zhang et al. | Jan 2001 | B1 |
| 6192257 | Ray | Feb 2001 | B1 |
| 6215789 | Keenan et al. | Apr 2001 | B1 |
| 6262829 | Kuramoto et al. | Jul 2001 | B1 |
| 6473404 | Kaplan et al. | Oct 2002 | B1 |
| 6473442 | Lundjso et al. | Oct 2002 | B1 |
| 6496504 | Malik | Dec 2002 | B1 |
| 6535043 | Chen | Mar 2003 | B2 |
| 6535557 | Saito et al. | Mar 2003 | B1 |
| 6536043 | Guedalia | Mar 2003 | B1 |
| 6542481 | Foore et al. | Apr 2003 | B2 |
| 6584125 | Katto | Jun 2003 | B1 |
| 6584200 | Tanaka | Jun 2003 | B1 |
| 6647006 | Rasanen | Nov 2003 | B1 |
| 6680955 | Le | Jan 2004 | B1 |
| 6704281 | Hourunranta et al. | Mar 2004 | B1 |
| 6891854 | Zhang et al. | May 2005 | B2 |
| 6920118 | Lozano | Jul 2005 | B2 |
| 6956875 | Kapadia et al. | Oct 2005 | B2 |
| 6996069 | Willenegger | Feb 2006 | B2 |
| 7016337 | Wu | Mar 2006 | B1 |
| 7043749 | Davies | May 2006 | B1 |
| 7068708 | LaRosa et al. | Jun 2006 | B2 |
| 7149549 | Ortiz et al. | Dec 2006 | B1 |
| 7230941 | Odenwalder et al. | Jun 2007 | B2 |
| 7370094 | Rousseau et al. | May 2008 | B2 |
| 7391717 | Klemets et al. | Jun 2008 | B2 |
| 7453843 | Mowery et al. | Nov 2008 | B2 |
| 7486678 | Devanagondi et al. | Feb 2009 | B1 |
| 7530089 | Hayes et al. | May 2009 | B1 |
| 7680912 | McNabb et al. | Mar 2010 | B1 |
| 8089948 | Garudadri et al. | Jan 2012 | B2 |
| 20010008535 | Lanigan | Jul 2001 | A1 |
| 20010017853 | Kikuchi et al. | Aug 2001 | A1 |
| 20020009287 | Ueda | Jan 2002 | A1 |
| 20020048321 | Katayama | Apr 2002 | A1 |
| 20020049969 | Duquesnois et al. | Apr 2002 | A1 |
| 20020093982 | Joy | Jul 2002 | A1 |
| 20020105976 | Kelly et al. | Aug 2002 | A1 |
| 20020114388 | Ueda et al. | Aug 2002 | A1 |
| 20020131426 | Amit et al. | Sep 2002 | A1 |
| 20020137521 | Kim et al. | Sep 2002 | A1 |
| 20020150123 | Ro | Oct 2002 | A1 |
| 20020194606 | Tucker et al. | Dec 2002 | A1 |
| 20030021298 | Murakami et al. | Jan 2003 | A1 |
| 20030026342 | Horiike et al. | Feb 2003 | A1 |
| 20030039465 | Bjorgan et al. | Feb 2003 | A1 |
| 20030053484 | Sorenson et al. | Mar 2003 | A1 |
| 20030063628 | Marko et al. | Apr 2003 | A1 |
| 20030086373 | Kronz | May 2003 | A1 |
| 20030128882 | Kim et al. | Jul 2003 | A1 |
| 20030140347 | Varsa | Jul 2003 | A1 |
| 20030147561 | Faibish et al. | Aug 2003 | A1 |
| 20030152107 | Pekonen | Aug 2003 | A1 |
| 20030152224 | Candelore et al. | Aug 2003 | A1 |
| 20030161401 | Shen et al. | Aug 2003 | A1 |
| 20030224806 | Hebron | Dec 2003 | A1 |
| 20040008766 | Wang et al. | Jan 2004 | A1 |
| 20040052209 | Ortiz | Mar 2004 | A1 |
| 20040057446 | Varsa et al. | Mar 2004 | A1 |
| 20040066319 | Chang et al. | Apr 2004 | A1 |
| 20040078744 | Wei et al. | Apr 2004 | A1 |
| 20040174912 | Moon | Sep 2004 | A1 |
| 20040196870 | Cheng et al. | Oct 2004 | A1 |
| 20040198371 | Balasubramanian et al. | Oct 2004 | A1 |
| 20050047417 | Lee et al. | Mar 2005 | A1 |
| 20050094655 | Newson et al. | May 2005 | A1 |
| 20050105615 | El-Maleh et al. | May 2005 | A1 |
| 20050138251 | Fanning | Jun 2005 | A1 |
| 20050169374 | Marpe et al. | Aug 2005 | A1 |
| 20050172154 | Short et al. | Aug 2005 | A1 |
| 20050220071 | Sivalingham et al. | Oct 2005 | A1 |
| 20050226262 | Hsieh et al. | Oct 2005 | A1 |
| 20050259613 | Garudadri et al. | Nov 2005 | A1 |
| 20050259623 | Garudadri et al. | Nov 2005 | A1 |
| 20060285654 | Nesvadba et al. | Dec 2006 | A1 |
| 20070064588 | Kisoda et al. | Mar 2007 | A1 |
| 20070092224 | Tsukagoshi et al. | Apr 2007 | A1 |
| 20080002669 | O'Brien et al. | Jan 2008 | A1 |
| 20140362740 | Garudadri et al. | Dec 2014 | A1 |
| 20150016427 | Garudadri et al. | Jan 2015 | A1 |
| Number | Date | Country |
|---|---|---|
| 1316163 | Oct 2001 | CN |
| 0424903 | May 1991 | EP |
| 1564992 | Aug 2005 | EP |
| 2000-196634 | Jul 2000 | JP |
| 2004226272 | Aug 2004 | JP |
| 1997012585 | Mar 1997 | KR |
| 20010024530 | Apr 2000 | KR |
| 20010024531 | Apr 2000 | KR |
| 20020044169 | Apr 2002 | KR |
| 20030088054 | Nov 2003 | KR |
| 9528684 | Oct 1995 | WO |
| 0021321 | Apr 2000 | WO |
| 0078054 | Dec 2000 | WO |
| 0152553 | Jul 2001 | WO |
| 0152565 | Jul 2001 | WO |
| 0205575 | Jan 2002 | WO |
| 0215591 | Feb 2002 | WO |
| 0223745 | Mar 2002 | WO |
| 0223916 | Mar 2002 | WO |
| 02065667 | Aug 2002 | WO |
| 02089434 | Nov 2002 | WO |
| 03041326 | May 2003 | WO |
| 2004036816 | Apr 2004 | WO |
| Entry |
|---|
| International Preliminary Report on Patentability—PCT/US05/016839—International Preliminary Examining Authority—United States Office—Sep. 28, 2006. |
| International Search Report—PCT/US05/016839, International Search Authority—European Patent Office—Aug. 25, 2005. |
| Written Opinion—PCT/US05/016839, International Search Authority—European Patent Office—Aug. 25, 2005. |
| Formulasys, ““The Basics of Wireless””, Dec. 21, 2003, pp. 1-6. |
| Jonsson: “Zero Byte ROHC RTP”, Ericsson Research, Lulea Sweden, Mar. 23, 2001. |
| Svanbro: “Lower Layer Guidelines for Robust RTP UDP IP Header Compression”, IETF Standard, Internet Engineering Task Force, IETF, CH,Networking Working Group, 3409 Ericsson, Dec. 2002, XP015009203. |
| 3GPP TS 45.002 , V6.9.0 (Apr. 2005); 3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Multiplexing and multiple access on the radio path (Release 6). |
| Borman, “Robust Header Compression”, RFAC 3095, Jul. 2001, pp. 1-157. |
| Garudadri, et al., “Video Transport over Wireless Networks.” 2004, ACM, all pages. |
| Formulasys, The Basics of Wireless, p. 3-16, 2002. |
| Kikuchi, et al., “RTP Payload Format for MPEG-4 Audio/Visual Streams,” Network Working Group, RFC 3016, Nov. 2000, 20 pp. |
| Schulzrinne, et al., “RTP: A Transport Protocol for Real-Time Applications,” IETF RFC 3550 (Jul. 2003). |
| Taiwanese Search report—094115718—TIPO—Oct. 4, 2010. |
| European Search Report—EP10152796—Search Authority—The Hague—Mar. 26, 2010. |
| European Search Report—EP12195665—Search Authority—The Hague—Apr. 3, 2013. |
| Pyun, J.Y., et al., “Wireless Measurement Based Resource Allocation for QoS Provisioning over IEEE 802.11 Wireless LAN”, IEEE Trans. on Consumer Electronics, Aug. 2003, vol. 49, No. 3, pp. 614-620. |
| Taiwan Search Report—TW100115872—TIPO—Aug. 9, 2013. |
| Yallapragada R., et al., “Video Delivery Over Cellular Wireless Networks using EBR Techniques”, Personal Wireless Communications, 2005. ICPWC 2005. 2005 IEEE International Conference on New Delhi, India Jan. 23-25, 2005, Piscataway, NJ, USA, IEEE, Jan. 23, 2005 (Jan. 23, 2005), pp. 249-253, XP010798556. |
| Number | Date | Country | |
|---|---|---|---|
| 20050259694 A1 | Nov 2005 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60571673 | May 2004 | US |
