Coded data generation or conversion – Digital code to digital code converters – To or from packed format
Reexamination Certificate
2000-03-09
2001-10-09
Young, Brian (Department: 2819)
Coded data generation or conversion
Digital code to digital code converters
To or from packed format
Reexamination Certificate
active
06300887
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to the relocation of header compression/decompression functions between a plurality of network entities and mobile terminals.
2. Description of the Prior Art
Carrying real-time multi-media traffic over IP-based network has become of great interest since the real-time transport protocol has been introduced. Due to the large size of the IP/UDP/RTP header, that is undesirable in low bandwidth networks such as wireless networks, suitable header compression mechanisms are needed. All known RTP header compression techniques require the storing of context information used for compression and decompression of headers of packets at the compressor (transmitter) and decompressor (receiver) and to initialize the compression/decompression process by sending essentially full headers. When header compression/decompression is utilized with a wireless link, headers sent on the uplink traffic are compressed by the mobile terminal and decompressed by a network entity. In the downlink traffic, the network entity compresses the headers, and the mobile terminal decompresses the headers.
In normal operation of compression/decompression, the decompression context information is in synchronism with the compression context information, in the sense that when the decompression context information is used to decompress a header that was compressed with the compression context information, the original uncompressed header is reconstructed. Both the compression context information and decompression context information may be continuously updated by the compressor and decompressor respectively, based on the incoming headers, etc. However, the two contexts normally stay in synchronism.
When a mobile terminal is handed off to another radio cell served by another network entity, if no efficient procedure is defined to transfer the context information to the new network entity, the header compression/decompression process has to again proceed through reinitialization, which entails sending full headers in both the downlink traffic and the uplink traffic. Such a reinitialization with full headers is both disruptive of the ongoing communications and consumes the bandwidth over the air interface. The transfer of compression and decompression context information is a challenge because the compression/decompression process is asynchronous relative to and independent of the handoff process, since the former is driven by the flow of packets, while the latter is driven by the radio conditions. Hence, by the time the new network entity uses the transferred context information, it may already be out-of-synchronism with the contexts at the mobile terminal.
FIG. 1
illustrates the problem in the prior art involving transfer of compression and decompression context information associated with radio handoff. There is a non zero handoff preparation time (time ST
1
to time ST
2
), during which the compression and decompression context information may be updated by the old network entity thus rendering the transferred value of the compression and decompression context information stale. Consequently, compression and decompression after the radio handoff is incorrect. In addition, the mobile terminal (MS) may be involved in information exchange, but transfer of information over the air interface should be kept to a minimum.
In RFC
2508
, a short sequence number is included in each packet in order to detect error or packet loss. When the decompressor receives a header with a sequence number that is not consecutive from the previous one, packet loss is detected and a recovery scheme is employed to resynchronize the compressor and decompressor.
Just using a short sequence number to detect packet loss is not robust to an error-prone network, such as wireless network where ‘long loss’ may happen frequently. Long loss is defined as the loss of ‘sequence cycle’ or more packets in a row.
When long loss occurs, the sequence number in the packet received by decompressor ‘wraps around’. For example, assuming the sequence number consists of k bits, hence the sequence cycle equals to 2
k
packets. If 2
k
packets are lost in a row, the decompressor fails to detect the packet losses since it still sees consecutive sequence number in the incoming packets.
IP/UDP/RTP header compression schemes, as described for example in RFC
2508
, S. Casner, V. Jacobson “Compressing IP/UDP/RTP Headers for Low Speed Serial Links, Internet Engineering Task Force, February 1999, which is incorporated herein by reference in its entirety, 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 timestamp, 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
Antonelli Terry Stout & Kraus LLP
Nokia Networks Oy
Young Brian
LandOfFree
Efficient handoff procedure for header compression does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Efficient handoff procedure for header compression, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Efficient handoff procedure for header compression will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2616416