Header compression of multimedia data transmitted over a wireless communication system

0001The present Application for Patent claims priority to <patcit id="pcit0001" dnum="US57167304P" dnum-type="L"><text>U.S Provisional Application No. 60/571,673</text></patcit>, entitled "Multimedia Packets Carried by CDMA Physical Layer Products", filed May 13, 2004, and assigned to the assignee hereof.

REFERENCE TO CO-PENDING APPLICATIONS FOR PATENT

0002The present Application for Patent is related to the following co-pending U.S. Patent Applications: <ul id="ul0001" list-style="none" compact="compact"><li>"Delivery Of Information Over A Communication Channel", having Attorney Docket No. 030166U1, filed concurrently herewith, assigned to the assignee hereof,</li><li>"Method And Apparatus For Allocation Of Information To Channels Of A Communication System", having Attorney Docket No. 030166U2, filed concurrently herewith, assigned to the assignee hereof; and</li><li>"Synchronization Of Audio And Video Data In A Wireless Communication System", having Attorney Docket No. 030166U4, filed concurrently herewith, assigned to the assignee hereof.</li></ul>

BACKGROUND

I. Field

0003The present invention relates generally to delivery of streaming data over a wireless communication system, and more specifically, to transmission of multimedia data over a wireless communication system.

II. Background

0004Demand for the delivery of multimedia data over various communication networks is increasing. For example, consumers desire the delivery of streaming video over various communication channels, such as the Internet, wire-line and radio networks. Multimedia data can be different formats and data rates, and the various communication networks use different mechanisms for transmission of real time data over their respective communication channels.

0005One type of communication network that has become commonplace is mobile radio networks for wireless communications. Wireless communication systems have many applications including, for example, cellular telephones, paging, wireless local loops, personal digital assistants (PDAs), Internet telephony, and satellite communication systems. A particularly important application is cellular telephone systems for mobile subscribers. As used herein, the term "cellular" system encompasses both cellular and personal communications services (PCS) frequencies. Various over-the-air interfaces have been developed for such cellular telephone systems including frequency division multiple access (FDMA), time division multiple access (TDMA), and code division multiple access (CDMA).

0006Different 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 cdma 2000, 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.

0007Users, or customers, of mobile radio networks, such as cellular telephone networks, would like to receive streaming media such as video, multimedia, and Internet Protocol (IP) over a wireless communication link. For example, customers desire to be able to receive streaming video, such as a teleconference or television broadcasts, on their cell phone or other portable wireless communication device. Other examples of the type of data that customers desire to receive with their wireless communication device include multimedia multicast/broadcast and Internet access.

0008A protocol that provides a mechanism to stream real time data over an IP network is the real-time transport protocol (RTP). RTP is a flexible protocol for transmitting real time data, such as audio and video over an IP network. It is desirable to use RTP to stream real-time data to wireless communication devices.

0009Typically, in RTP, streaming data is encoded into data packets. The RTP data packets include routing and sequencing information appended to each packet. The appended routing and sequencing information is commonly referred to as a header. Due to the limited resources available in a wireless communication system, such as limited bandwidth, it is desirable to reduce the amount of data that is transmitted. From document <patcit id="pcit0002" dnum="US20030208615A1"><text>US2003/0208615A1</text></patcit> a method and device for adjusting the maximum size of the information sequences transmitted in a telecommunication network is known. This document discloses for each information sequence to be transmitted: The identifier of a destination terminal and the corresponding maximum size of the information sequences are read in an information base; the maximum size read is compared with the current maximum size allowed by the network protocol; and if the maximum size read is less than the current maximum size, the current maximum size is adjusted by allocating to it the value of the maximum size read.

0010Thus, there is therefore a need in the art for techniques and apparatus that can reduce the amount of data that is transmitted in a wireless communication system during the transmission of streaming data, such as multimedia data and VoIP.

SUMMARY

0011The invention is defined in independent claims 1, 21, 30. Embodiments disclosed herein address the above stated needs to reduce the amount of data required to transmit multimedia data streams over a wireless communication channel. Techniques for reducing, or eliminating, headers in the transmission of real time transport protocol (RTP) data streams over a wireless communication system are described. These techniques include determining a physical layer packet size of the wireless communication system and determining a maximum size of a compressed header and then, partitioning an information unit, wherein the size of the partitions are selected such that after a partition is encoded, the aggregate size of the encoded partition and the compressed header are no greater than the physical layer packet size.

0012Another technique for transmitting multimedia data over a wireless communication system includes negotiating a physical layer compressed header size between participants in a communication session.

0013Additional aspects include using robust header compression or zero byte header compression techniques with multimedia data transmitted over a wireless communication channel.

0014The above techniques can be used for various types of multimedia data. For example, the techniques can be used with variable bit rate data streams, video streams, or video teleconference streams.

0015The above techniques can also be used with various over the air interfaces. For example, the techniques can be used with 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), cdma2000, Wideband CDMA (WCDMA), and others.

0016Other features and advantages of the present invention should be apparent from the following description of exemplary embodiments, which illustrate, by way of example, aspects of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

0017<figref idref="f0001">Figure 1</figref> shows a communication system 100 constructed in accordance with the present invention.

0018<figref idref="f0002">Figure 2</figref> is a block diagram illustrating an exemplary packet data network and various air interface options for delivering packet data over a wireless network.

0019<figref idref="f0003">Figure 3</figref> is a diagram illustrating various levels of encapsulation present when using RTP to transmit multimedia data over a wireless link.

0020<figref idref="f0004">Figure 4</figref> is a flow diagram illustrating an example of a negotiation of values for data packet and compressed header sizes.

0021<figref idref="f0005">Figure 5</figref> is a flow diagram illustrating another example of a negotiation of values for data packet and compressed header sizes.

0022<figref idref="f0006">Figure 6</figref> is a diagram illustrating protocol stack for packet data in accordance with a zero byte header compression technique in a wireless communication system.

0023<figref idref="f0007">Figure 7</figref> is a chart illustrating IP header overhead verses data rate of a video data stream.

0024<figref idref="f0008">Figure 8</figref> is a block diagram illustrating exemplary components used in decoding multimedia data when a zero byte header technique is used.

0025<figref idref="f0009">Figure 9</figref> is a flow chart illustrating an example of decoding of a multimedia data stream that uses a zero byte header compression technique.

0026<figref idref="f0010">Figure 10</figref> is a flow diagram illustrating an exemplary procedure for a multimedia play out device.

0027<figref idref="f0011">Figure 11</figref> is a flow diagram illustrating an exemplary procedure for transmitting data over a wireless communication system.

0028<figref idref="f0012">Figure 12</figref> is a block diagram of a wireless communication device, or mobile station (MS), constructed in accordance with an exemplary embodiment of the present invention.

DETAILED DESCRIPTION

0029The 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.

0030The 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.

0031An aspect of the invention is to reduce the amount of data that is transmitted in a wireless communication system when a data stream is transmitted. Examples of streaming of data include multimedia data, such as, video, teleconference, broadcast/multicast services, internet protocol (IP), and voice over IP (VoIP).

0032The techniques described herein relate to partitioning information units, thereby creating a plurality of data packets. Techniques described make use of some of the aspects described in co-pending U.S. Patent Applications referenced in the REFERENCE TO CO-PENDING APPLICATIONS FOR PATENT section above. For example, a technique referred to as explicit bit rate (EBR) is described wherein an encoder may be constrained such that it encodes application layer information units into sizes that match physical layer packet sizes of a communication channel.

0033As noted, RTP is a mechanism used to stream data by encoding the stream into packets. In RTP, a header that includes routing and sequencing information is appended to each packet. An aspect of the present invention is to reduce the size of the header, or remove the header entirely. In this way, the amount of data transmitted over a wireless communication channel transmitting RTP packets is reduced.

0034<figref idref="f0001">Figure 1</figref> shows a communication system 100 constructed in accordance with the present invention. The communication system 100 includes infrastructure 101, multiple wireless communication devices (WCD) 104 and 105, and landline communication devices 122 and 124. The WCDs will also be referred to as mobile stations (MS) or mobiles. In general, WCDs may be either mobile or fixed. The landline communication devices 122 and 124 can include, for example, serving nodes, or content servers, that provide various types of multimedia data such as streaming data. In addition, MSs can transmit streaming data, such as multimedia data.

0035The 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).

0036The 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 <figref idref="f0001">Figure 1</figref>, MSs 104 and 105 receive signals 132 and 136 on the forward link and transmit signals 134 and 138 on the reverse link. In general, signals transmitted from a MS 104 and 105 are intended for reception at another communication device, such as another remote unit, or a landline communication device 122 and 124, and are routed through the IP network or switching network 120. For example, if the signal 134 transmitted from an initiating WCD 104 is intended to be received by a destination MS 105, the signal is routed through the infrastructure 101 and a signal 136 is transmitted on the forward link to the destination MS 105. Likewise, signals initiated in the infrastructure 101 may be broadcast to a MS 105. For example, a content provider may send multimedia data, such as streaming multimedia data, to a MS 105. Typically, a communication device, such as a MS or a landline communication device, may be both an initiator of and a destination for the signals.

0037Examples 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.

0038<figref idref="f0002">Figure 2</figref> is a block diagram illustrating an exemplary packet data network and various air interface options for delivering packet data over a wireless network. The techniques described may be implemented in a packet switched data network 200 such as the one illustrated in <figref idref="f0002">Figure 2</figref>. As shown in the example of <figref idref="f0002">Figure 2</figref>, the packet switched data network system may include a wireless channel 202, a plurality of recipient nodes or MS 204, a sending node or content server 206, a serving node 208, and a controller 210. The sending node 206 may be coupled to the serving node 208 via a network 212 such as the Internet.

0039The 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.

0040In 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 a video stream and thereby produce variable-sized frames of data, and the decoder could receive variable sized frames of data and decode them. Because the frames are of various size, but the video frame rate is constant, a variable bit rate stream of data is produced. 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.

0041In one example illustrated in <figref idref="f0002">Figure 2</figref>, data, such as multimedia data, from the sending node 206 which is connected to the network, or Internet 212 can be sent to a recipient node, or MS 204, via the serving node, or Packet Data Serving Node (PDSN) 206, and a Controller, or Base Station Controller/Packet Control Function (BSC/PCF) 208. The wireless channel 202 interface between the MS 204 and the BSC/PCF 210 is an air interface and, typically, can use many channels for signaling and bearer, or payload, data.

Air Interface

0042The 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 or FDMA, 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.

RTP Packetization

0043The Real-Time Transport Protocol (RTP) is a protocol developed for transmitting real time data, such as multimedia data. RTP is a flexible protocol providing mechanisms to stream real time data over IP networks. See "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, available at URL www.faqs.org/rfc/rfc3550.html). Streaming refers to a technique for transferring data such that it can be processed as a steady and continuous stream.

0044A description of a way to use RTP to stream a particular type of data, for example video, is referred to as an RTP profile. In an RTP profile, the output of a source encoder is grouped into packets and header information is added to the packet.

0045<figref idref="f0003">Figure 3</figref> is a diagram illustrating various levels of encapsulation present when using RTP to transmit multimedia data, such as video data or VoIP, over a wireless link. As shown in <figref idref="f0003">Figure 3</figref>, a payload 302 is generated. For example, the payload can be streaming multimedia data, for example, video data or VoIP. The payload 302 may be pre-pended by a Slice_Header (SH) 304 that includes additional information pertaining to the payload 302. The RTP protocol then encapsulates the payload into one or several RTP packets and appends an RTP header 306. In the example illustrated in <figref idref="f0003">Figure 3</figref>, the payload is encapsulated into a single RTP packet with an RTP header 306 indicated by "RTP." A User Datagram Protocol (UDP) header 308 is then added to each RTP packet, indicating the source and destination ports. An Internet Protocol (IP) header 310 is then added to indicate the network address of the source and destination hosts. For example, in one embodiment the RTP header may be 12 bytes, the UDP header may be 20 bytes, and the IP header may be 8 bytes, thereby resulting in a 40 byte header being appended to the payload 302. It is desirable to reduce the size of the header to conserve system resources when transmitting RTP over a wireless communication system.

0046Upon entering the wireless network, a point to point protocol (PPP) header 312 is added to provide framing information for serializing the packets into a continuous stream of bits. A radio link protocol, for example, RLP in cdma2000 or RLC in WCDMA, then packs the stream of bits into RLP packets 314. The radio-link protocol allows, among other things, the re-transmission and re-ordering of packets sent over the air interface. Finally, the air interface MAC-layer takes one or more RLP packets 314, packs them into MUX layer packet 316, and adds a multiplexing header (MUX) 318. A physical layer packet channel coder then adds a checksum (CRC) 320 to detect decoding errors, and a tail part 322 forming a physical layer packet 325.

0047The Internet Engineering Steering Group has proposed guidelines, or rules, about the packetization of video that is carried by RTP. <i>See</i>, "RTP Payload Format for MPEG-4 Audio/Visual Streams", Y. Kikuchi [Toshiba], T. Nomura [NEC], S. Fukunaga [Oki], Y. Matsui [Matsushita], H. Kimata [NTT], RFC-3016 proposed standard, Internet Engineering Steering Group, November 2000, available at URL www:faqs.org/rfcs/rfcs3060.html). Although these rules address MPEG-4, similar schemes also apply to the other video codecs. The RFC3016 defines the following three options for packetization, where Video Object Planes (VOP) refers to an MPEG-4 video frame: <ol id="ol0001"><li><b>1. Packing one Video Frame per RTP Packet:</b> "The RTP timestamp indicates the sampling instance of the VOP contained in the RTP packet. A constant offset, which is random, is added for security reasons." In this case, the RTP timestamp and RTP sequence number are incremented.</li><li><b>2. Packing multiple Video Frames per RTP Packet:</b> "When multiple VOPs are carried in the same RTP packet, the timestamp indicates the earliest of the VOP times within the VOPs carried in the RTP packet. Timestamp information of the rest of the VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment). [...] This kind of packetization is effective to save the overhead of RTP/IP headers when the bit-rate of the underlying network is low. However, it will decrease the packet-loss resiliency because multiple video packets are discarded by a single RTP packet loss. The optimal number of video packets in an RTP packet and the length of the RTP packet can be determined considering the packet-loss rate and the bit-rate of the underlying network." In this case, the RTP timestamp jumps ahead and the RTP sequence number is incremented.</li><li><b>3. Segmenting one Video Frame over multiple RTP Packets:</b> "It is RECOMMENDED that a single video packet is sent as a single RTP packet. The size of a video packet SHOULD be adjusted in such a way that the resulting RTP packet is not larger than the path-MTU. [...] When the packet-loss rate of the underlying network is high, this kind of packetization is recommended. Even when the RTP packet containing the VOP header is discarded by a packet loss, the other RTP packets can be decoded by using the HEC (Header Extension Code) information in the video packet header. No extra RTP header field is necessary." In this case, the RTP timestamp remains the same and the RTP sequence number is incremented.</li></ol>

0048In general, RTP packetization is simpler for speech codecs, or vocoders, as the "variability" of encoders is well defined. For example in cdma2000 vocoders, the payload size is one of four (4) possible rates (i.e., full rate, half rate, fourth rate, and eighth rate).

Header Compression during Transmission of Multimedia Data Streams Generic Header Compression Support

0049A size of a compressed header, wherein the header includes RTP/UDP/IP/PPP headers, for a given compression scheme, depends on changes in the RTP timestamp and the RTP sequence number, among other things. An encoder does not know the actual size of the compressed header at the time of encoding a data packet, for example from a multimedia data stream such as a video data stream. While the actual size of the compressed header may not be known, it is possible to set an upper limit on the header size. For example, during setup of a session an upper limit on header size may be established depending on parameters such as the compression scheme, UDP checksum option, and the like.

0050In one embodiment, a set of possible data rates may be negotiated between a sending terminal, a receiving terminal and their corresponding PDSNs. For example, a set of possible data rates may be negotiated between a sending MS, a receiving MS, and their corresponding PDSNs. Each of the possible data rates has associated with it physical layer packet sizes as described in co-pending U.S. Application No. ________ entitled "DELIVERY OF INFORMATION OVER A COMMUNICATION CHANNEL", supra. Let <i>S</i> represent, in bytes, the set of physical layer packet sizes corresponding to the data rates available to the encoder after negotiation. <maths id="math0001" num="Eq. 1"><math display="block"><mi>S</mi><mo>=</mo><mfenced open="[" close="]"><mtable><mtr><mtd><msub><mi>r</mi><mn>1</mn></msub></mtd><mtd><msub><mi>r</mi><mn>2</mn></msub></mtd><mtd><mo>⋯</mo></mtd><mtd><msub><mi>r</mi><mi mathvariant="normal">i</mi></msub></mtd></mtr></mtable><mspace width="1em" /></mfenced><mo>⁢</mo><mi>ʹ</mi></math><img file="EP1751955B1_D0001.tif" /></maths> Then, <maths id="math0002" num="Eq. 2"><math display="block"><mover><mi>S</mi><mo>^</mo></mover><mo>=</mo><mi>S</mi><mo>-</mo><mi>x</mi></math><img file="EP1751955B1_D0002.tif" /></maths> where <i>Ŝ</i> represents the maximum amount of data, in bytes, within a physical layer packet that can be used for payload, and <ul id="ul0002" list-style="none" compact="compact"><li><i>x</i> ∈ {0,1,2,3,4} where the value of x represents an upper limit on the compressed header size, in bytes, and is dependent on the type of header compression scheme used. For example, as discussed further below, values of correspond to different compression schemes, where:</li><li><i>x</i>≡0 corresponds to zero-header compression, where the header is removed entirely;</li><li><i>x</i>≡1 or 2 correspond to robust header compression (ROHC) without UDP checksum;</li><li><i>x</i>≡3 or 4 correspond to ROHC with UDP checksum;</li></ul>

0051In one embodiment, MSs, content servers and PDSNs that are involved in a session negotiate values for <i>S</i> and <i>x</i> during setup of a session setup. The negotiation may take into account parameters, such as, the encoding schemes and compression schemes supported by the various devices in the session. During the session a data stream, such as a multimedia data stream, may be partitioned into portions that are sized such that an encoder generates packets that are <i>S</i>-<i>x</i> bytes in size, leaving enough space for compressed headers. For example, if a video data stream is transmitted during a session, a video frame is partitioned, or "sliced", such that when the video slice is encoded the encoded slice will be <i>S</i>-<i>x</i> bytes and the compressed header will be no larger than x bytes in size. If the size of the compressed header is less than x bytes, then null bytes can be included, or the amount of data allocated to encoding the video slice can be increased so that data packets that are generated are of a desired size.

0052<figref idref="f0004">Figure 4</figref> is a flow diagram illustrating an example of a negotiation of values for <i>S</i> and <i>x</i>. Flow begins in block 402 where a MS notifies a device in the infrastructure, for example a PDSN, which compression schemes the MS supports. In addition, the MS can notify the PDSN if the MS prefers one of the supported compression schemes over another. Flow then continues to block 404. In block 404, the infrastructure device, such as a PSDN, compares the MS supported compression schemes with the compression schemes supported by the infrastructure device. The infrastructure device may also take into account any preferences of the MS. Flow then continues to block 406 where the infrastructure device notifies the MS of the compression scheme to use during a session.

0053As an example of the negotiation illustrated in <figref idref="f0004">Figure 4</figref>, a MS may notify a PDSN that the MS supports x = 0, 3, and 1 in that preferred order. In this example, the PDSN does not support <i>x</i> = 1 (ROHC without UDP checksum). The PDSN may then send the supported options (<i>x</i> = 0, 3) to a second PDSN that will be participating in the session. The second PDSN may find out that a receiving MS that will also be participating in the session can support <i>x</i> = 0, 1, 2, 3, and 4, while the second PDSN itself can support <i>x</i> = 0, 1, and 4. Because the only value of x that is supported by all participants in the session is x = 0, the session will be established using a value of zero for x.

0054<figref idref="f0005">Figure 5</figref> is a flow diagram illustrating another example of a negotiation of values for <i>S</i> and <i>x</i>. Flow begins in block 502 where a device in the infrastructure, for example a PDSN, notifies a MS as to which compression schemes the infrastructure device supports. In addition, the infrastructure device can notify the MS of any preferences the infrastructure has for one of the supported compression schemes over another. Flow then continues to block 504. In block 504, the MS compares the MS supported compression schemes with the compression schemes supported by the infrastructure device. The MS may also take into account any preferences of the infrastructure device. Flow then continues to block 506 where the MS notifies the infrastructure device of the compression scheme to use during a session.

0055An example of a protocol sequence for the above examples is listed below: <ul id="ul0003" list-style="bullet" compact="compact"><li>During PPP Internet Protocol Control Protocol (IPCP), both mobile and PDSN indicate their header compression capabilities to each other, along with any preferences, and negotiate to a set of common compression capabilities supported by both mobile and PDSN.</li><li>The mobile determines which header compression type to be used and hence the <i>x</i> value.</li><li>The mobile conveys information, such as the x value, the data packet size, such as a video slice size, etc., to a content server in communication with a PSDN via a wireless communication system (e.g., Session Description Protocol (SDP) parameters in Session Initiation Protocol (SIP) or Real Time Streaming Protocol (RTSP), etc.).</li><li>The mobile conveys flow information, such as, address/port, header compression type, etc., to the PDSN via 3GPP2-specific signaling (i.e., RESerVation (RESV) message). This information allows the PDSN to know what header compression type to be used on this particular session flow identified by the address/port.</li></ul>

Robust Header Compression

0056Robust Header Compression (ROHC) as used herein relates to compression schemes that make use of redundancies between consecutive packets by maintaining state information (context) at both a compressor and a decompressor. The static context information is sent only initially, at the beginning of a session, while dynamic context is sent with subsequent data packets. In order for the decompressor to regenerate the uncompressed packets correctly, the context in the decompressor needs to be synchronized to the context used by the compressor during compression. Techniques that have been developed to maintain synchronization of the context between the decompressor and compressor include the Robust Header Compression (ROHC) technique developed by the ROHC Working Group of the Internet Engineering Task Force, [<i>see</i>, <i>for example</i> the standards and drafts at the Internet URL www.ietf.org/rfc/rfc3095.txt?number=3095].

0057Using ROHC there is a one byte header for most payloads when context is available at the decompressor and a forty-four byte header when it is necessary to establish the context at the decompressor. When UDP checksum is enabled, the compressed header size, when context is available at the decompressor, is three bytes. In one embodiment, ROHC is used and when context is available at the decompressor the payload packet sizes are restricted to be one byte smaller than the physical layer packet sizes. In another embodiment, ROHC with UDP checksum enabled is used and when context is available at the decompressor the payload packet sizes are restricted to be three bytes smaller than the physical layer packet sizes.

0058When ROHC context needs to be established, a "blank and burst" transmission feature of cdma2000 can be used, for example on multiple communication channels, or an additional packet can be sent. In this way, use of ROHC can be used with the techniques described and thereby result in a reduction in the amount of data transmitted. "Blank and burst" means that the signaling data (in this case the ROHC context information) is sent instead of voice data.

Zero Byte Header Compression

0059A third generation mobile technology, known as Universal Mobile Telecommunications System (UMTS), can deliver audio and video to wireless devices anywhere in the world through fixed, wireless and satellite systems. In general, a UMTS codec payload size is fixed based on the Adaptive Multi-Rate (AMR) mode. In order to amortize the RTP overhead across multiple frames one or both of the following methods can be used: <ol id="ol0002" compact="compact"><li>1. header compression (such as ROHC)</li><li>2. bundling multiple frames in one RTP packet</li></ol> When bundling is used, the RTP timestamp is that of the earliest frame in the RTP packet.

0060When an IP node is communicating with a receiver, or "sink" terminal, it may not be necessary to reconstruct the RTP header if the timestamp information is implicitly known. If the decoder receives frames at a constant, known, rate, the decoder may be able to output samples without additional timestamp information. For example, if a decoder receives at least one frame every 20 ms, the decoder can output samples every 20 ms without additional timestamp information. Blank frames may be generated during packet losses.

0061<figref idref="f0006">Figure 6</figref> is a diagram illustrating a protocol stack for packet data in accordance with a zero byte header compression technique in a wireless communication system. In the example illustrated in <figref idref="f0006">Figure 6</figref>, a MS 602 receives data from a host 604 in the infrastructure. In the host 604 a codec 606 encodes data packets. The output of the codec has RTP, UDP and IP header information, 608, 610, and 612 respectively, appended to the data packets. A PDSN 614 sends the encoded data packet to the MS 602 via a Radio Network 616, such as a base station/packet control function. When the data packets are received by the MS 602, the data packets are routed from a media access control layer 618 to a codec 620. The codec 620 in the MS 602 decodes the received packet.

0062As described above, with RTP packetization it has been shown that when multiple video frames are included in one RTP packet a compliant decoder can recreate the timing of frames in this packet using the modulo_timebase and time_incriment fields of the subsequent video frames in the RTP packet. For example, using EBR, if there is a QoS guarantee that n video frames are delivered every <i>nT</i> ms (where T is the time between two video frames, <i>T</i> = <i>1000</i>/<i>frames_per_second</i>), a mechanism for synchronous delivery of video data may be established. Thus, the EBR approach can utilize zero byte header compression, similarly to Service Option 60 (SO60) for speech. Use of zero byte header compression can greatly reduce the amount o data that is transmitted. For example, in a wireless communication system based on CDMA, for a supplemental channel (SCH) operating at 8x (a 64 kbps stream) this technique could result in a reduction of at least 44 bytes of header information for each 160 bytes, e.g. about a 27.5% savings in the bitrate.

0063<figref idref="f0007">Figure 7</figref> is a chart illustrating IP header overhead verses data rate of a video data stream. The vertical axis 702 represents a RTP/UDP/IP/PPP overhead normalized as a percent of the total bitrate and the horizontal axis 704 represents a bitrate for the video stream. The curve 706 of <figref idref="f0007">Figure 7</figref> illustrates the increase in available bitrate for data as the size of the overhead reduces. In the example illustrated in <figref idref="f0007">Figure 7</figref>, a value of four bytes was used for PPP overhead. A value of four for the PPP overhead probably underestimates actual values for the PPP overhead because, occasionally, escape codes are added so that some of the video data is not mistaken for a PPP header.

0064As illustrated in <figref idref="f0007">Figure 7</figref>, although the percentage of the total bit rate that is dedicated to overhead decreases as the bitrate increases, a significant amount of the total bitrate may be dedicated to transmission of overhead. For example, at a bit rate of 88 bytes per second about 20% of the total bit rate is dedicated to the transmission of overhead. Removal, or reduction, of header information through techniques such as ROHC and zero byte header compression allows bitrate that would otherwise be dedicated to transmission of overhead to instead be used to improve video quality or increase the system capacity, or the like.

0065<figref idref="f0008">Figure 8</figref> is a block diagram illustrating exemplary components used in decoding multimedia data when a zero byte header technique is used. As shown in <figref idref="f0008">Figure 8</figref>, a channel decoder 802 is configured to receive data packets that make up a multimedia data stream. The output of the channel decoder 802 is connected to an RLP resequencer 804. The RLP resequencer 804 places the channel packets into a resequencing buffer 806 where the channel packets are sequenced in accordance with the sequence number of each packet. A multimedia decoder 808, for example a video decoder, retrieves the data packets from the resequencing buffer 806 and decodes the individual multimedia packets. The multimedia packets are output from the multimedia decoder 808 and placed into a multimedia frame buffer 810 where the multimedia packets are stored. A multimedia play out device 812 retrieves decoded multimedia packets from the multimedia frame buffer 810. The multimedia play out device 812 formats the multimedia packets for presentation to a user in an appropriate multimedia presentation device 814. For example, if the multimedia data is video data, then the multimedia presentation device 814 may be a video display.

0066<figref idref="f0009">Figure 9</figref> is a flow chart illustrating an example of decoding of a multimedia data stream that uses a zero byte header compression technique as could be accomplished in a multimedia decoder 808 shown in <figref idref="f0008">Figure 8</figref>. In the example of <figref idref="f0009">Figure 9</figref>, the multimedia data is video data and the multimedia decoder 808 is a video decoder. Flow begins in block 902 where the video decoder retrieves a data packet, or slice, that is next in-sequence from a resequencing buffer. Flow continues to block 904. In block 904 the data packet is examined and it is determined if the data packet includes a start code or a resync marker. If the data packet includes a start code, indicating the start of a video frame in the video stream, then flow continues to block 906. In block 906 the data packet is examined and a Frame Header is read. The frame header may include information about an entire video frame including timing information. Flow then continues to block 908 where a new frame in a video frame buffer is opened. Flow then continues to block 910.

0067Returning to block 904, if the data packet is examined and it is determined that the data packet, or slice, includes a resync marker flow continues to block 912. If the data packet includes a resync marker then the data packet is not the start of a video frame in the video stream but is a portion, also referred to as a slice or a macroblock, of a video frame. In block 912 a slice header of the data packet, or slice or macroblock, is read. Flow then continues to block 910.

0068In block 910 the data packet, or slice or macroblock, is decoded. Flow then continues to block 914 where it is determined if a decoding error occurred. For example, it may be determined in block 914 that there are conflicting sequence numbers in decoded data packets. If it is determined that there is a decoding error, an affirmative outcome at block 914, flow continues to block 916. In block 916 the data packet, or slice containing the decoding error is discarded. Flow then continues to block 918 where it is determined if there are additional data packets in the stream.

0069Returning to block 914, if there is no decoding error, a negative outcome at block 914, then flow continues to block 920. In block 920 the encoded packet, or slice, is inserted into the open video frame. Flow then continues to block 922 where it is determined if there are additional data packets in the stream.

0070In block 922 if it is determined if there are no additional data packets in the stream, a negative outcome at block 922, flow continues to block 918 where it is determined if there are additional data packets in the stream. At block 922, if it is determined that there are more packets in the stream, an affirmative outcome at block 922, then flow continues to block 910 and the next macro block of the packet is decoded. Returning to block 918, if it is determined there are additional data packets in the stream, an affirmative outcome at block 918, flow continues to block 902 and the next packet in the sequence is retrieved. If, in block 918, it is determined that there are no additional data packets in the stream, a negative outcome in block 918, flow continues to block 924 and flow stops.

0071<figref idref="f0010">Figure 10</figref> is a flow diagram illustrating an exemplary procedure for a multimedia play out device 812. In the example of <figref idref="f0010">Figure 10</figref>, the multimedia data is video data and the multimedia play out device 812 is a video play out device. Flow begins in block 1002 where decoded video frames are retrieved from a video frame buffer at a frame rate of the video data. The video frame that is retrieved is the oldest frame in the video frame buffer. The age of the video frames may be determined, for example, by the RTP sequence number of the video frames, or timestamps of the video frames, or other techniques. Flow then continues to block 1004. In block 1004 the retrieved frames are examined and error concealment techniques are applied if desired. For example, error concealment techniques may be applied if there are missing packets, of slices, in a video frame, or if an entire video frame is missing, or other types of error.

0072Error concealment techniques can include, for example, copying packets, or slices from a previous video frame to replace a corrupted slice in the current video frame. Another example of error concealment is to use information from neighboring video slices to generate a replacement slice for a corrupted slice. For example, information from neighboring slices can be used to determine, for example, interpolation motion vectors for the corrupted slice. Other techniques for concealment of errors in video slices may also be implemented. The error concealment techniques of block 1004 can also be performed as part of the video decoding, for example as part of the flow diagram of <figref idref="f0009">Figure 9</figref>.

0073Flow continues from block 1004 to block 1006. In block 1006 the video data is displayed. For example, the video data may be projected on a video display in a wireless communication device, such as a cell phone, PDA, wireless enabled personal computer, or other wireless communication device.

0074<figref idref="f0011">Figure 11</figref> is a flow diagram illustrating an exemplary procedure for transmitting data over a wireless communication system. Flow beginnings in block 1102 where a physical layer packet size of the wireless communication system is determined. For example, the physical layer packet size can be a single size or one of a plurality of sizes. Flow continues to block 1104 where a maximum size of a compressed header is determined. Flow then continues to Block 1106. In block 1106 an information unit is partitioned. The size of the partition is selected such that after a partition is encoded the total;, or aggregate, size of the encoded partition and the compressed header are no greater than the physical layer packet size.

0075<figref idref="f0012">Figure 12</figref> is a block diagram of a wireless communication device, or MS, constructed in accordance with an exemplary embodiment of the present invention. The communication device 1202 includes a network interface 1206, a codec 1208, a host processor 1210, a memory device 1212, a program product 1214, and a user interface 1216.

0076Signals from the infrastructure are received by the network interface 1106 and sent to the host processor 1210. The host processor 1210 receives the signals and, depending on the content of the signal, responds with appropriate actions. For example, the host processor 1210 may decode received data packets of a multimedia data stream, for example a video data stream, or it may route the received signal to the codec 1208 for decoding. In another embodiment, the received signal are sent directly to the codec 1208 from the network interface 1206.

0077Signals from the MS can also be transmitted to the infrastructure from the host processor 1206, or the codec 1208, or both via the network interface 1206. The host processor 1210 may partition a data stream into data packets that are sized so that after a header is appended to the data packet the total size of the data packet and appended header matches the size of a physical layer packet size. In another embodiment, the codec 1208 partitions a data stream into data packets that are sized so that after a header is appended to the data packet the total size of the data packet and appended header matches the size of a physical layer packet size. In both embodiments, the data packet and appended header are then sent to the network interface 1206 and transmitted to the infrastructure.

0078In one embodiment, the network interface 1206 may be a transceiver and an antenna to interface to the infrastructure over a wireless channel. In another embodiment, the network interface 1206 may be a network interface card used to interface to the infrastructure over landlines.

0079Both the host processor 1210 and the codec 1208 are connected to a memory device 1212. The memory device 1212 may be used to store data during operation of the MS. For example, the memory device may include a resequencing buffer, or a frame buffer, or both. The memory device may also store program code that will be executed by the host processor 1210 or the codec 1208, or both. For example, the host processor, codec, or both, may operate under the control of programming instructions that are temporarily stored in the memory device 1212. The host processor 1210 and coded 1208 also can include program storage memory of their own. When the programming instructions are executed, the host processor 1210 or codec 1208, or both, perform their functions, for example encoding and decoding multimedia streams with compressed headers. Thus, the programming steps implement the functionality of the respective host processor 1210 and codec 1208, so that the host processor and codec can each be made to perform the functions of encoding or decoding content streams with compressed headers as desired. The programming steps may be received from a program product reader 1214. The program product 1214 may store, and transfer the programming steps into the memory 1212 for execution by the host processor, codec, or both.

0080The program product 1214 may include a reader that receives interchangeable storage devices. The interchangeable storage devices may be a semiconductor memory chip, 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 1214 may be a 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. In <figref idref="f0012">Figure 12</figref>, the exemplary storage medium is shown coupled to the host processor 1210 such that the host processor may read information from, and write information to, the storage medium. Alternatively, the storage medium may be integral to the host processor 1210.

0081The user interface 1216 is connected to both the host processor 1210 and the codec 1208. For example, the user interface 1216 may include a display and a speaker used to output multimedia data to the user.

0082Those 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.

0083Those 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.

0084Those 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.

0085The 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.

0086The 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.

0087The 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 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.