Robust header compression in packet communications

Details Robust header compression in packet communications Robust header compression in packet communications

1999-06-18

2004-06-22

Qureshi, Afsar (Department: 2667)

Multiplex communications

Communication techniques for information carried in plural...

Assembly or disassembly of messages having address headers

C370S235000, C370S392000, C370S477000, C709S247000

Reexamination Certificate

active

06754231

ABSTRACT:

FIELD OF THE INVENTION
The invention relates generally to packet communications and, more particularly, to header compression in packet communications.
BACKGROUND OF THE INVENTION
Due to the tremendous success of the Internet, it has become a challenging task to make use of the Internet Protocol IP (see, e.g., Jon Postel,
Internet Protocol
, DARPA RFC 791, September 1981, incorporated herein by reference) over all kind of links. However, because the IP protocols were designed for wired links with high bandwidth capabilities, and because packet headers of the IP protocols are rather large, it is not always a simple task to use IP protocols with narrow band links, for example cellular links. If we consider the scenario when the IP protocols are used for real-time data, for example ordinary speech, the User Datagram Protocol UDP (see, e.g., Jon Postel,
User Datagram Protocol
, DARPA RFC 768, August 1980, incorporated herein by reference) and the Real-Time Transport Protocol RTP (see, e.g, Henning Schulzrinne, Stephen L. Casner, Ron Frederick and Van Jacobson,
RTP: A Transport Protocol for Real-Time Applications
, IETF RFC 1889, IETF Audio/Video Transport Working Group, January 1996, incorporated herein by reference) are applied on top of IP. Together they require a total amount of 40 header octets (IP 20, UDP 8 and RTP 12 octets). If we combine these header requirements with ordinary speech usage, which may have frame sizes as low as 15-20 octets, the header part will disadvantageously represent more than 70% of the packet. With the upcoming new IP version 6 (see, e.g., Steven Deering and Robert Hinden,
Internet Protocol Version
6 (Ipv6)
Specification
, RFC 2460, IETF Network Working Group, December 1998, incorporated herein by reference), which has a header of 40 bytes, this problem will increase. Reducing the header sizes would improve the spectrum efficiency and save a lot of money when transmitting over wireless links.
The term header compression (HC) comprises the art of minimizing the necessary bandwidth for information carried in headers on a per-hop basis over point-to-point links. Header compression takes advantage of the fact that some fields in the headers are not changing within a flow, and that most header changes are small and/or predictable. Conventional header compression schemes make use of these facts and send static information only initially, while changing fields are sent either as uncompressed values (e.g., for completely random information) or as differences (or deltas) from packet to packet, the latter typically referred to as difference (or delta) encoding. When difference encoding is used, the compression scheme can be fragile, with its performance very dependent on link quality. For example, if packet loss is common on the link, quality suffers because many consecutive packets are typically lost each time a loss occurs.
Conventional header compression/decompression schemes are often realized using state machines, and the challenging task is to keep the compressor and decompressor states, (or contexts), consistent with each other.
In general, there are two different conventional techniques to keep the de-compressor context updated. The first technique uses periodic refreshes wherein absolute header data is sent. An advantage of this solution is that its performance is not affected by the round-trip-time (RTT) of the link, due to the fact that no messages are sent from the de-compressor to the compressor. This means that it also works over simplex links. On the other hand, there are a number of disadvantages with periodic refreshing. For example, the average header overhead will be high due to the high number of large refresh headers, most of which are unnecessary. On the other hand, if the header refresh rate is too low, the number of lost packets will be high if errors on the link are common.
The other common way of keeping the context updated is to let the compressor send refreshing information (i.e., absolute header data) only when requested by the de-compressor. This requires a duplex link but reduces the average header overhead because no unnecessary updates are performed. Provided that the RTT is small, this solution also reduces the number of lost packets due to inconsistent context states after a link error. The obvious disadvantages are dependence on the back channel of the duplex link, sensitivity to lost packets on the link, and the high number of consecutive lost packets that will occur in case of an invalid context (and associated refresh request) when the RTT is high.
For all header compression schemes, two measures describe their performance. Compression efficiency describes how much the headers are compressed. This can be expressed by the average or maximal header size, combinations of both, or in other ways. Robustness describes how well the scheme handles loss on the link. Will loss of a packet make the header contexts inconsistent resulting in a large number of subsequent lost packets?
Normally, most conventional header compression schemes perform well, but they require links with low error-rates and small RTT's.
Currently, there exist a number of different conventional header compression schemes. In fact, they are not really different schemes but different development states of the same one. The earliest proposals (see, e.g., Van Jacobson,
Compressing TCP/IP Headers for Low-Speed Serial Links
, IETF RDC 1144, IETF Network Working Group, February 1990, incorporated herein by reference) handle only compression of TCP (see, e.g., Jon Postel,
Transmission Control Protocol
, DARPA RFC 761, January 1980, incorporated herein by reference) flows, while ideas have later evolved to make compression of UDP and also RTP headers possible (see, e.g., Mikael Degermark, Björn Nordgren and Stephen Pink,
IP Header Compression
, IETF RFC 2507, IETF Network Working Group, February 1999, incorporated herein by reference; and Steven Casner and Van Jacobson,
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
, IETF RFC 2508, IETF Network Working Group, February 1999, incorporated herein by reference). Today it could therefore be stated that for real-time data flows there is just one scheme for header compression (see Casner and Jacobson above), which is currently being standardized within the IETF (Internet Engineering Task Force) by the Audio/Video-Transport working group, and which is referred to herein as CRTP.
CRTP compresses the 40 octets of RTP/UDP/IP headers down to 2 octets for most packets and, as long as the links are reliable, this minimal size will almost be equal to the average. CRTP uses difference encoding for three fields: the RTP sequence number field; the RTP time stamp field; and the ID field of the IP header. CRTP uses update requests, as described above, to bring invalidated de-compressor contexts up to date.
A more general scheme for compression of UDP/IP headers (see Degermark, et al. above), which uses the periodic refreshing principle, may also be used, but the RTP headers are then sent uncompressed, resulting in 12 extra header octets in each packet.
CRTP performs well as long as the used link has a low bit-error rate and/or the RTT is small. However, this is often not the case for wireless links. The RTT is generally also of a magnitude that results in a large number of consecutive lost packets before the decompressor receives a context update. This is in general undesirable for applications such as real-time audio and video. The overall packet-loss-rate will therefore also be too high and it is not considered possible to improve the wireless link characteristics to make the result better. Both reduction of the bit-error rate (BER) and the RTT would be too expensive. Thus, the robustness of CRTP is identified to be its weakness.
One thing that all existing header compression schemes have in common is that their de-compressors have a small amount of intelligence. Because of the typically high predictability of header fields, especially when the kind of data flow is known, this simplicity can be a signif

Affiliated with

Also associated with

Rating

Robust header compression in packet communications does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Robust header compression in packet communications, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Robust header compression in packet communications will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3327918