1. Field of the Invention
The present invention relates to compression and decompression of headers in data packet transmissions.
2. Description of the Prior Art
For Internet Protocol (IP) based real-time multimedia, the Real-Time Transfer Protocol (RTP) is predominantly used on top of the User Datagram Protocol (UDP/IP). RTP is described in detail in RFC 1889 which is incorporated herein by reference in its entirety. The size of the combined IP/UDP/RTP headers is at least 40 bytes for IPv4 and at least 60 bytes for IPv6. A total of 40-60 bytes overhead per packet may be considered heavy in systems (e.g., such as cellular networks) where spectral efficiency is a primary concern. Consequently, a need exists for suitable IP/UDP/RTP header compression mechanisms. A current header compression scheme is described in RFC 2508, by S. Casner, V. Jacobson, “Compressing IP/UDP/RTP Headers for Low Speed Serial Links”, Internet Engineering Task Force (IETP), February 1999, which is incorporated herein by reference in its entirety, and which is able to compress the 40/60 byte IP/UDP/RTP header down to 2 or 4 bytes over point-to-point links. The existing header compression algorithms are based on the observation that most fields of the IP packet headers remain constant in a packet stream during the length of a session. Thus, it is possible to compress the header information by establishing a compression state (the full header information) at the de-compressor and by simply carrying minimal amount of header information from the compressor to the de-compressor.
IP/UDP/RTP header compression schemes, as described for example in RFC 2508, take advantage of the fact that certain information fields carried in the headers either 1.) do not change (‘Type 1’ header fields) or 2.) change in a fairly predictable way (‘Type 2’ header fields). Other fields, referred to as ‘Type 3’ header fields, vary in such a way that they must be transmitted in some form in every packet (i.e. they are not compressible).
Examples of Type 1 header fields are the IP address, UDP port number, RTP SSRC (synchronization source), etc. These fields need only be transmitted to the receiver/decompressor once during the course of a session (as part of the packet(s) transferred at session establishment, for example). Type 1 fields are also called ‘unchanging’ fields.
Examples of Type 2 header fields are the RTP time stamp, RTP sequence number, and IP ID fields. All have a tendency to increment by some constant amount from packet(n) to packet (n+1). Thus, there is no need for these values to be transmitted within every header. It is only required that the receiver/decompressor be made aware of the constant increment value, hereafter referred to as the first order difference (FOD), associated with each field that exhibits this behavior. Receiver/decompressor utilizes these FODs to regenerate up-to-date Type 2 field values when reconstructing the original header. Type 2 fields are part of ‘changing’ fields.
It should be emphasized that, on occasion, Type 2 fields will change in some irregular way. Frequency of such events depends on several factors, including the type of media being transmitted (e.g., voice or video), the actual media source (e.g., for voice, behavior may vary from one speaker to another), and the number sessions simultaneously sharing the same IP-address.
An Example of a Type 3 header field is the RTP M-bit (Marker), which indicates the occurrence of some boundary in the media (e.g., end of a video frame). Because the media normally varies in unpredictable ways, this information cannot be truly predicted. Type 3 fields are part of ‘changing’ fields.
The decompressor maintains decompression context information that contains all the pertinent information related to rebuilding the header. This information is mainly type 1 fields, FOD values, and other information. When packets are lost or corrupted, the decompressor can lose synchronization with the compressor such that it can no longer correctly rebuild packets. Loss of synchronization can occur when packets are dropped or corrupted during transmission between compressor and decompressor.
Given the above, the compressor needs to transmit three different types of headers during the course of a session:                Full Header (FH): Contains the complete set of all header fields (Types 1, 2, and 3). This type of header is the least optimal to send due to its large size (e.g., 40 bytes for IPv4). In general, it is desirable to send an FH packet only at the beginning of the session (to establish Type 1 data at the receiver). Transmission of additional FH packets has adverse effects on the efficiency of the compression algorithm. When the compressor transmits FH packets, it is said to be in the ‘FH state’.        First Order (FO): Contains minimal header information (e.g. Type 3 fields), compressor/decompressor specific control fields (specific to the compression algorithm in use), and information describing changes in current FOD fields. An FO packet is basically an SO packet (described below), with additional information that establishes new FOD information for one or more Type 2 fields at the decompressor. If the header compression is being applied to a VoIP (voice over internet protocol) stream, transmission of an FO packet might be triggered by the occurrence of a talk spurt after a silence interval in the voice. Such an event results in some unexpected change in the RTP time stamp value, and a need to update the RTP time stamp at the receiver by a value other than the current FOD. The size of FO packets depends on the number of Type 2 fields whose first order difference changed (and the amount of the absolute value of each change). When the compressor transmits FO packets, it is said to be in the ‘FO state’.        Second Order (SO); A SO packet contains minimal header information (e.g. Type 3 fields), and compressor and decompressor specific control fields. The preferred mode of operation for the compressor and decompressor is transmission and reception of SO packets, due to their minimal size (on the order of just 2 bytes or even less). When the compressor transmits SO packets, it is said to be in the ‘SO state’. SO packets are transmitted only if the current header fits the pattern of an FOD.        
RFC 2508 is based on the concept that most of the time, the RTP fields that change from one packet to the next, such as the RTP time stamp, can be predicted by linear extrapolation of transmitted SO packets. Essentially the only information that has to be sent is a sequence number, used for error and packet loss detection (as well as a context information ID). When the transmitter determines that linear extrapolation cannot be applied to the current packet with respect to the immediately preceding packet, a FO packet is transmitted. To initiate the session, a FH packet is transmitted. In addition, when the receiver determines that there is packet loss (as detected by a sequence number incrementing by more than 1) the receiver will explicitly request the transmitter to transmit the full header in order to allow a resynchronization.
However, the header compression defined in RFC 2508 is not well suited for certain environments (such as cellular or wireless environments), where bandwidth is at a premium and errors are common. In the RFC 2508 header compression scheme, the RTP time stamp is assumed to have most of the time a linearly increasing pattern. When the header conforms to the pattern, essentially only a short sequence number sent as SO is needed in the compressed header. When the header does not conform to the pattern, the difference between the RTP time stamps of the current header and of the previous one is sent in the FO compressed header.
The additional bandwidth requirement can manifest itself in various ways, depending on the operating environment. For example, in cellular systems it is in general very desirable to limit bandwidth usage as much as possible, as it is a scarce resource.
RFC 2508 suffers from lack of robustness to withstand header errors or losses, because the decompression of the current header can only be done if the immediately preceding header was also received without error and decompressed. The header compression defined in RFC 2508 is not well suited for cellular environments, where bandwidth is at a premium and long error bursts are not uncommon. In RFC 2508, when a packet loss is detected, subsequent packets with compressed headers are invalidated, with a further requirement that it is necessary to send a large size header to recover from the error. Large size headers consume bandwidth and create peaks in the bandwidth demand which are more difficult to manage.
Just using a short sequence number (one with a limited number of bits) to detect packet loss is not robust to an error-prone network, such as in a wireless network where long loss may happen at any time. In this case, long loss is defined as loss of sequence cycle or packets in a row. Under the situation of a long loss, a series of packets within the number of packets of the sequence cycle having a packet identification defined by a limited number of bits may get lost and, as a result, the sequence number in the packet received by the decompressor (receiving device in uplink or downlink) of the receiver wraps around (repeats). For example, assuming the sequence number consists of k bits, the sequence cycle equals to 2k.
As shown in FIG. 1, the compressor (transmitting device in uplink or downlink) sent packet with seq=n at time t0, and the following 2k packets, beginning from packet with seq=n+1 at time t1 and ending at packet with seq=n at time t2. At time t3, the compressor sends a packet with sequence number equal to n+1 again. Assume a packet with a sequence number equal to n+1 sent at time t1 until the packet with the sequence number equal to n is sent at time t2 which are all lost due to long loss, then the decompressor only receives the packet with the sequence number equal to n sent at time t0 and the packet with the sequence number equal to n+1 sent at time t3. Based on the current packet loss detection scheme defined in RFC 2508, the decompressor concludes that there is no packet loss and decompresses the packet in a wrong way. This not only affects the correctness of decompression of packet with a sequence number equal to n+1, but the subsequent packets as well.
USPTO Backgrounds
USPTO Backgrounds