Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing – Session/connection parameter setting
Reexamination Certificate
1999-11-05
2003-04-01
Wiley, David (Department: 2143)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
Session/connection parameter setting
C709S217000, C709S232000, C709S247000, C713S160000, C714S750000, C341S060000
Reexamination Certificate
active
06542931
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates to a method and apparatus for eliminating the inefficient use of network bandwidth caused by numerous acknowledgements transmitted by a receiver to a transmitter by providing sparse feedback from the receiver to the transmitter to indicate receipt of packets having headers to be used as reference headers.
For Internet Protocol (IP) based real-time multimedia applications packets are used to carry the real-time data. Each packet includes a header and a payload. The header carries information such as source and destination addresses of the packet and the payload carries the data to be transmitted. Each packet is formatted according to the IP and Real-time Transfer Protocol (RTP) which is predominately used on top of User Datagram Protocol (UDP). RTP is described in detail in “RTP: A Transport Protocol for Real-Time Applications” by H. Schulzrinne, et al, Internet Engineering Task Force (IETF) Request for Comments (RFC) 1889, January 1996. The size of a combined IP/UDP/RTP header for a packet is at least 40 bytes for IPv4 and at least 60 bytes for IPv6. A total of 40-60 bytes of overhead per packet may be considered heavy in systems (e.g., such as cellular networks) where spectral efficiency is a common concern. Consequently, a need arises for suitable IP/UDP/RTP header compression mechanisms.
A current header compression scheme is described in “Compressing IP/UDP/RTP Headers for Low-Speed Serial Links” by S. Casner et al, IETF, RFC 2508, February 1999 and “IP Header Compression” by M. Degermark, et al, IETF, RFC 2507, February 1999. The header compression scheme described in RFC 2508 is able to compress the 40-60 bytes IP/UDP/RTP header down to 2 or 4 bytes over point-to-point links. This header compression scheme is based on the observation that most fields of the headers of the packets 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 (context) at a compressor (transmitter) and a decompressor (receiver). Packets having compressed headers are then transmitted from the compressor to the decompressor, wherein the compressed headers correspond to a reference header stored as part of the compression state. Each compressed header contains a minimum amount of information. The information carried in the compressed header is decompressed at the decompressor based on the established compression state.
In RFC 2508 the changes occurring in the RTP header fields from one packet to the next, such as the RTP time stamp, can be predicted by linear extrapolation from the preceding header which was received without error. Thus, in an RTP header the primary information that is sent is a sequence number which is used for packet loss detection. To initiate a session or to re-synchronize a compression state between a compressor and decompressor, a packet containing a Full Header (FH) is transmitted from the compressor to the decompressor. The FH contains all of the information of the header of the packet and is used (stored) as a reference header. After a session has been initialized or re-synchronization has been performed, all subsequent packets are transmitted with compressed headers. The compressed headers are, for example, of two types.
The first type of compressed header is used when the subsequent headers of the subsequently transmitted packets can be extrapolated in a linear fashion from the previous header. In this setting, the compressor transmits sequence numbers as the compressed headers. This type of compressed header is referred to as Second Order (SO) header. The second type of compressed header is used when the subsequent headers of the subsequently transmitted packets cannot be extrapolated in a linear fashion. In this setting, the compressor transmits additional information including the sequence number as the compressed headers. This type of compressed header is referred to as a First Order (FO) header. The FO header contains additional information which is required to accurately decompress the compressed headers of the subsequently transmitted packets. In RFC 2508, all headers that are decompressed are stored as reference headers. In order to decompress the current header, the decompressor must have correctly decompressed the previous header. In practice, it is not uncommon for packets having compressed header to be lost or corrupted during transmission. This results in the compressor and decompressor staying in a less then optimal state for some extended time. The same can occur due to Round Trip delays in receiving the packets having compressed headers. Consequently, the data streams being processed by the compressor and decompressor may require additional bandwidth.
To improve the header compression scheme described in RFC 2508, the decompressor transmits acknowledgements to the compressor indicating receipt of a FH or FO header packet. The compressor in response to an acknowledgement indicating receipt of a FH packet switches to an FO state and begins transmitting FO header packets where linear extrapolation cannot be conducted or switches to the SO state and begins transmitting SO header packets where linear extrapolation can be conducted. Similar to an FH packet the compressor, in response to an acknowledgment indicating receipt of an FO header packet, switches to the SO state and begins transmitting SO header packets.
In error/loss prone communication environments, such as cellular, the decompressor cannot be certain that the acknowledgment has been properly received by the compressor until it sees an altered behavior on the part of the compressor. Namely, the decompressor in conventional apparatus is not aware that the acknowledgment has been properly received, until it sees that the compressor has altered its behavior. That is, the decompressor sees FO header packets instead of FH packets or SO header packets instead of FO header packets. In the mean time, the decompressor keeps sending acknowledgments to headers of each of the packets received. Further, the decompressor in conventional apparatus remains unaware that the acknowledgment has been properly received due to round trip delays in receiving packets resulting rom the altered behavior of the compressor. Thus, the conventional technique suffers from the disadvantage of inefficient use of bandwidth of the network.
FIG. 1
graphically illustrates the inefficient use of the bandwidth of a network resulting from sending acknowledgments in response to each and every FH packet or FO header packet even after a first acknowledgment has been sent. According to the above, as each FH packet or FO header packet is received an acknowledgment is transmitted from the decompressor to the compressor acknowledging receipt of the FH packet or FO header packet. In
FIG. 1
, it is assumed that at time t
0
an FO(n) header packet is transmitted from the compressor and detected by the decompressor at time t
1
. Further, at time t
1
the decompressor, in response to the FO(n) header packet transmits an acknowledgment (ACK(n)) to the compressor. In
FIG. 1
it is assumed that T
dd
is the transmission delay from the decompressor to the compressor, T
du
is the transmission delay from the compressor to the decompressor, T
samp
is the time interval between consecutive media samples inserted into the packet, ACK (n) is an acknowledgment transmitted from the decompressor upon receiving an FH packet or an FO(n) header packet, and SO(
n
+T
dd
+T
du
)/T
samp
) is an SO header packet sent by the compressor in response to receipt of the ACK(n)
According to
FIG. 1
, from time t
0
forward, the compressor continues sending FO header packets through time t
1
until the ACK(n) has been received at the compressor at time t
2
. The decompressor, in response to each FO header packet transmitted subsequent to the FO(n) header packet, transmits an ACK to the compressor. At time t
2
, once the ACK(n) has been received, the compressor begins transmitting SO header packets to the de
Clanton Christoph
Le Khiem
Liu Zhigang
Zheng Haihong
Antonelli Terry Stout & Kraus LLP
Neurauter George C
Nokia Corporation
Wiley David
LandOfFree
Using sparse feedback to increase bandwidth efficiency in... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Using sparse feedback to increase bandwidth efficiency in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Using sparse feedback to increase bandwidth efficiency in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3114557