A Technique for Compressing a Header Field in a Data Packet

IS 2 460 140 T3

DESCRIPTION

A technique for compressing a header field in a data packet

TECHNICAL FIELD

The present invention relates to a method and apparatus for compressing a header field in a data packet. More specifically, the present invention relates to a method and apparatus for compressing a header field of a data packet using a Scheme Based on a Timer and a Reference.

For Internet Protocol (IP) -based real-time multimedia, Real-Time Transfer Protocol (RTP) is used predominantly over User Datagram Protocol (UDP / IP). RTP is described in detail in RFC 1889. The size of the combined IP / UDP / RTP headers is at least 40 octets for IPv4, and at least 60 octets for IPv6. The overhead of between 40 and 60 bytes per packet can be considered onerous in systems (eg, such as cellular networks) where spectral efficiency is a primary concern. Consequently, there is a need for suitable IP / UDP / RTP header compression mechanisms. For example EP 0 768 777 A2 describes certain aspects of mobility management. A current header compression scheme is described in document RFC2508, which is capable of compressing the 40/60 octet IP / UDP / RTP header into 2 or 4 octets per point-to-point links. Existing header compression algorithms are based on the observation that most fields in IP packet headers remain constant in a packet stream for the duration of a session. Thus, it is possible to compress the header information by setting a compression state (the complete header information) in the decompressor, and simply carrying a minimal amount of header information from the compressor to the decompressor.

RFC2508 is based on the idea that most of the time, RTP fields that change between one packet and the next, such as the RTP timestamp, can be predicted by linear extrapolation. 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 identifier). When the sender determines that linear extrapolation cannot be applied to the current packet, first order difference information is sent with respect to the immediately preceding packet. To start the session, a full header is sent. Furthermore, when the receiver determines that there is packet loss (as detected by a sequence number increased by more than 1), the receiver will explicitly request the sender to transmit the full header in order to allow a resynchronization.

However, the header compression defined in RFC2508 is not well suited for certain environments (such as cellular or wireless environments), where bandwidth is prohibitive and errors are common. In the RFC2508 header compression scheme, the RTP timestamp is assumed to have a linearly increasing pattern most of the time. When the header conforms to the pattern, essentially only a short sequence number is needed in the compressed header. When the header does not conform to the pattern, the difference between the RTP timestamps of the current header and those of the previous one is sent in the compressed header. Further optimization is possible using a coding table. This approach has three drawbacks. The first is that it is not robust against errors, since the loss of the previous header will invalidate the decompression of the current header. The second is that the differences or jumps of the RTP timestamp can be very large, thus overflowing the encoding lookup table. For example, if the medium is voice, such large differences can be caused by an interval of silence. The third is that the size of the resulting encoded difference is variable, which makes it more difficult to predict and manage the bandwidth to be allocated.

Therefore, there is a need for a header compression scheme that can accommodate an arbitrary jump in the field value (e.g., the RTP timestamp value), providing a more consistent and constant size, and that it is more robust against errors.

SUMMARY OF THE INVENTION

According to one embodiment of the present invention, a timer-based head-end decompression technique is provided. An RTP source generates a header field, such as an RTP timestamp. The timestamp is sent over a network to a compressor. In the compressor, a jitter reduction function (JRF) is used to determine if the delay jitter of the received timestamp (header) is excessive. If the delay jitter is excessive, the packet is discarded. Otherwise, the compressor calculates a compressed header field (compressed timestamp) based on the RTP timestamp and an initial timestamp value. The compressed timestamp represents the delay jitter that is calculated as an effect that the network between the source and the decompressor has on the transmission of packets. The calculated lag jitter is an accumulation of

ES 2 460 140 T3 network delay jitter, which represents the effect that the network between the source and the compressor has on packet transmission, and radio delay jitter, which represents the effect that the network between the compressor and the decompressor has about transmitting packets. It should be noted that the term "network" as used herein is intended as a broad term, so as not to exclude, for example, radio links in a wireless telecommunications network. The RTP packet, including the compressed timestamp, is then transmitted over a link or network to a decompressor.

The decompressor decompresses the compressed timestamp by first calculating an estimate or approximation of the timestamp, based on the current value of a timer located at the terminal (ie, based on elapsed time). The timestamp approximation is then refined or corrected based on the compressed timestamp provided in the header of the packet. In this way, the timestamp for the current packet (header) is regenerated based on a local timer and a compressed timestamp provided in the current header. The packet and the regenerated timestamp are then provided to an RTP endpoint for processing.

The timer-based scheme of the present invention includes several advantages. The term "timer-based scheme" as used herein includes the timer-based scheme using a compressed timestamp, and the timer and reference-based scheme, as disclosed herein. The size of the compressed timestamp (or other header field) is constant and small. Also, the size does not change based on the length of the silence interval. No synchronization is required between the timer process at the RTP source (which generates the timestamp) and the timer in the decompressor process. Furthermore, this technique is robust against errors, since the partial information of the timestamp in the compressed header is self-contained and only needs to be combined with the value of the decompressor timer to produce the full value of the RTP timestamp. Loss or corruption of a header will not invalidate subsequent compressed headers.

A second example of the present invention provides a header hashing scheme in which the header (eg, including the RTP timestamp) is shredded or removed from the RTP packet prior to transmission. A headend shredder and a headend generator are connected via a circuit-like connection (eg, a circuit or virtual circuit), or an essentially constant bit rate channel. After initialization, the header shredder shreds or removes the header (including removal of the timestamp and sequence number) from each packet, and then transmits the non-header packets to the header regenerator. To eliminate packet delay jitter at the head-end chopper, packets can be transmitted with time-spacing according to the RTP timestamp (TS) in the head-end. Therefore, in this example, the timestamp is not explicitly provided in the RTP packet (not even a compressed timestamp). Rather, the timing information is provided implicitly to the header regenerator, based on an essentially constant bit rate channel, between the header splitter and the regenerator. The essentially constant bit rate channel can be provided in a number of different ways.

In this second embodiment, after initialization occurs (e.g., providing the initial sequence number and timestamp to the header regenerator), the header regenerator can regenerate the timestamps for sequential packets by incrementing a counter of local timestamp with the value of TS_tranco every T msec, and regenerate the packet sequence numbers by incrementing a local SN counter by 1 for each packet duration. These fields can be regenerated based on only a local timer or counter, due to the essentially constant bit rate channel provided between the header shredder and the header regenerator, in which no packet delay jitter is introduced. Therefore, after initialization, these header fields can be regenerated in the header regenerator with reference only to a local clock.

However, one or more basic discontinuity events can occur (eg, change in packet size or TS_tranco, non-linear shift in timestamp, etc.) that, if left unaddressed, could likely override the header mincing approach that relies only on a local timer or clock for field regeneration. A header string is a sequence of packet headers with known or linearly predictable fields. The transition from one chain to another can be caused by any of several discontinuity events. When this occurs, the header shredder identifies the discontinuity event and sends updated header information related to the event to the header regenerator, to allow the regeneration of timestamps and sequence numbers to continue. A similar technique of providing updated header information when there is a handover can also be used.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will become more apparent from the following detailed description, when considered in conjunction with the accompanying drawings, in which:

IS 2 460 140 T3

FIG. 1 is a block diagram illustrating a system in accordance with an exemplary embodiment of the present invention;

Fig. 2 is a diagram illustrating an uncompressed format of an RTP packet according to an embodiment of the present invention;

FIG. 3 is a diagram illustrating the uncompressed RTP header format in accordance with an exemplary embodiment of the present invention;

FIG. 4 is a diagram illustrating a compressed RTP header format in accordance with an exemplary embodiment of the present invention;

FIG. 5 is a diagram illustrating exemplary headland compression and decompression operation in accordance with one embodiment of the invention;

FIG. 6 is a diagram illustrating exemplary headland compression and decompression operation in accordance with another embodiment of the invention;

FIG. 7 is a diagram illustrating exemplary handover operation in accordance with an embodiment of the present invention;

FIG. 8 is a block diagram illustrating an exemplary battery in accordance with an exemplary embodiment of the present invention;

FIG. 9 is a table illustrating information that may be provided in messages in accordance with an exemplary embodiment of the invention;

FIG. 10 is a diagram illustrating a handover process in accordance with an exemplary embodiment of the present invention;

FIG. 11 is a diagram illustrating an in-band initialization in accordance with an exemplary embodiment of the invention;

FIG. 12 is a diagram illustrating an out-of-band initialization in accordance with an exemplary embodiment of the invention;

Fig. 13 is a diagram illustrating the steps of calculating network delay jitter according to a first method of the present invention;

Fig. 14 is a diagram illustrating the steps of calculating network delay jitter according to a second method set forth as Option 1 of the present invention; Y

Fig. 15 is a diagram illustrating the steps of calculating network delay jitter according to a third method set forth as Option 2 of the present invention.

BEST WAY TO CARRY OUT THE INVENTION

I. Timer-Based Scheme Employing a Compressed Temporary Seal

A. Architecture

FIG. 1 is a block diagram illustrating a system in accordance with an exemplary embodiment of the present invention. A terminal 102 is connected to an IP network 108. Terminal 102 can be a personal computer, or the like, that executes the RTP / UDP / IP protocols, and that provides packetized voice samples in RTP packets for transmission over the network. 110. Terminal 102 includes an RTP endpoint 104 that identifies this terminal (eg. g., including IP address, port number, etc.) either as a source or as a destination for RTP packets. The IP network is provided as an example; however, other types of packet-switched networks, or the like, may be used instead. It should be noted that the term network, as used herein, is intended to be a broad term, so as not to exclude, for example, radio links in a wireless telecommunications network. Terminal 102 also includes a local timer 103 to generate a timestamp.

An access network infrastructure (ANI) 110 is connected to the IP network 108. A wireless terminal 130 is coupled, via radio frequency (RF) link 140, to the ANI 110. The wireless terminal 130, as described herein The document could be, for example, a wireless compressor or a wireless decompressor, depending on your environment. This occurs in particular when the source of the packets or the destination of the packets are separated from the wireless terminal 130. RF link 140 includes an uplink 142 (from terminal 130 to ANI 110) and a downlink 144 (from ANI 110 to terminal 130). The ANI 110 maintains interfaces between one or more wireless (or radio frequency) terminals (including terminal 130) in a region and the IP network 108, including the conversion between fixed line signals (provided from the IP network 108) and wireless signals or RF (provided to or from terminal 130). In this way, the ANI 110 allows RTP packets received from the IP network 108 to be sent over the RF link 140 to the wireless terminal 130, and allows the RTP packets from the terminal 130 to be sent over the IP network 108. to another terminal, such as terminal 102.

According to an example of the present invention, the ANI 110 includes one or more ANI adapters (ANI_AD), such as the

IS 2 460 140 T3

ANI_AD 112 and ANI_AD 114, each of which preferably includes a timer. Each ANI_AD performs compression (before downlink transmission) and decompression (after uplink transmission) of headers. Headers (or one or more header fields, such as a timestamp) for RTP packets received from IP network 108 are compressed by ANI_AD 112 prior to transmission to terminal 130 on downlink 142, and headers of packets received from terminal 130 are decompressed by ANI_AD 112 prior to transmission to the IP network 108. Therefore, each ANI_AD can be considered a compressor / decompressor 115. Each ANI_AD can maintain interfaces between terminals located in a specific or different area within the region and the IP network 108. The ANI_AD 112 includes a timer 113 to implement a timer-based decompression technique. The ANI_AD 112 also includes a Delay Jitter Reduction Function (JRF) 115 which functions to measure the delay jitter in the packets (or headers) received by the network 108 and to discard all packets / headers that have delay jitter. excessive.

Additional ANIs, such as ANI 120, may be provided to maintain interfaces between the other terminals located in additional regions with the IP network 108. ANI 120 similarly includes one or more ANI_AD, such as ANI_AD 122 (Fig. 1) . Each ANI_AD includes a timer and a JRF.

Terminal 130 includes an RTP endpoint 132 that is a source and / or destination (receiver) for RTP packets. Terminal 130 includes a terminal adapter (term_AD) 136 that performs compression (for packets to be transmitted on the uplink 142) and decompression (on packets received on the downlink 144) of headers. In this way, the terminal adapter (term_AD) can be thought of as a header compressor / decompressor 137, similar to ANI_AD.

Terminal adapter (term_AD) 136 also includes a timer 134 (a receiver timer) for calculating an approximation (or estimate) of an RTP timestamp of a current headend. Terminal adapter (term_AD) 136 then uses additional information in the RTP header to refine or correct the approximation of the timestamp. According to an example of the invention, the timestamp approximation is corrected or adjusted based on a compressed timestamp provided in the RTP header. In this way, a local timer and compressed timestamp can be used to regenerate the correct timestamp for each RTP header. Other terminals (such as terminal 150) may be provided, each including its own RTP endpoint, terminal adapter, and timer.

The configuration shown in Fig. 1 is provided merely as an example, and the invention is not limited thereto. Instead, Fig. 1 simply provides an example where RTP data is transmitted over a link or data system (such as wireless link 140) where bandwidth is prohibitive and errors are not uncommon. The present invention is not limited to a wireless link, but is applicable to a wide variety of links (including fixed line links, etc.)

An example application or system, where the timer-based header compression and decompression scheme can be useful, is where Voice over IP (or IP telephony) packets are transmitted over cellular systems. When VoIP is applied to cellular systems, it is important to minimize the overhead of the IP / UDP / RTP headend, due to the limited bandwidth of the wireless or air (RF) interface. In such a system, for example, the ANI_AD would maintain interfaces between the IP network and a computer terminal running RTP / UDP / IP (eg, terminal 130), and with a cellular or RF interface to receive packets from the RTP over the wireless or RF link. This is merely an application example of the compression / decompression technique of the present invention.

Fig. 2 is a diagram illustrating an uncompressed format of an RTP packet according to an example of the present invention. As shown in Fig. 2, the uncompressed RTP packet includes an IP header, a UDP header 212, an RTP header 214, and a payload, which could be a voice sample 216.

FIG. 3 is a diagram illustrating the uncompressed RTP header format, in accordance with an exemplary embodiment of the present invention. As shown in Fig. 3, the uncompressed RTP header includes a timestamp (TS) 310, a sequence number (SN) 312, and some other fields 314. Due to the packet-switched nature of the IP network 108 , RTP packets may arrive out of order. Sequence number 312 is used at the RTP receiver or RTP recipient (eg, terminal 130, Fig. 1) to arm the RTP voice samples in the correct order. However, the sequence numbers in the RTP packets will not reflect any non-linear changes in the field (eg, voice signal silence intervals). Therefore, a timestamp (TS) 310 is provided to indicate the relative timing of each packet.

As noted above, there is some concern that the 40-60 octet header overhead provided by the IP / UDP / RTP headers on each RTP packet is too great. In particular, a 4-byte RTP timestamp is especially cumbersome for RTP packets that

ES 2 460 140 T3 operate over low speed or limited bandwidth links (such as link 140). As a result, there is a need for a mechanism to efficiently compress the RTP headers and, in particular, compress the timestamp field in the RTP header.

The header compression technique described in RFC 2508 initially sends a complete (uncompressed) RTP packet, including all fields, to the RTP recipient / receiver. Many of the header fields during a connection are static and therefore do not need to be transmitted after the initial packet is sent and received. For most packages, only the sequence number and timestamp will change from package to package. According to RFC 2508, non-static fields (eg, timestamp and sequence number) are updated at the receiver by adding first-order (fixed) differences to the previous values ​​of those fields stored at the receiver. For example, the sequence number of each received RTP packet will be automatically incremented by one for each packet. Additional jumps or changes (ie other than first order difference) in non-static fields must be transmitted separately to the receiver. Unfortunately, in RFC 2508, the loss of the old header will invalidate decompression at the receiver. Furthermore, the size of the differences varies, which makes it more difficult to manage and predict bandwidth using the compression technique of RFC 2508.

According to an example of the present invention, a technique for header compression is provided that can be used to more efficiently compress an RTP timestamp (or other field) of a packet header. According to an example of the present invention, the compression scheme can accommodate an arbitrary jump in the RTP timestamp value, while providing a constant-size RTP compressed header (or a constant-size RTP timestamp).

FIG. 4 is a diagram illustrating a compressed header format of RTP in accordance with an exemplary embodiment of the present invention. As shown in Fig. 4, the compressed RTP header may consist of a message type 410 indicating the type of message, a bit mask 412 that identifies the fields that are changing, and a compressed timestamp field 414 . Message type 410 may indicate a compressed timestamp if a compressed timestamp is provided in the packet header. According to an example of the present invention, field 414 of the compressed timestamp includes the k least significant bits (lsbs) of a value that can indicate the elapsed time between packets. In accordance with an example of the invention, compressed timestamp 414 may provide a portion (ie, the k least significant bits) of a source counter value (or counter difference). The source counter can be used to generate the timestamp for each RTP packet header. Optional fields 416 can be used to provide updated or changed fields for those fields identified in bit mask 412.

B. Global Operation of the Compression and Decompression of Time Stamps

The compression and decompression of the RTP timestamp, according to an embodiment of the invention, will be briefly described. According to one example, an RTP packet is generated at one RTP endpoint (such as RTP endpoint 104 of terminal 102) and is directed to another RTP endpoint. In this example, RTP endpoint 104 is the source of one or more RTP packets to be sent to endpoint 132 (the recipient) of terminal 130's RTP. The RTP packet header includes a timestamp, which is generated at the RTP source (eg, at terminal 102) based on a common clock.

The RTP packet is routed over the IP network 108 to the ANI_AD 112 of the ANI 110. The ANI_AD 112 compresses one or more fields in the header (s) of the RTP packet. In particular, the ANI_AD compresses the RTP timestamp 310 (Fig. 3) into a compressed timestamp 414 (Fig. 4). Other fields in the header can be compressed by removing them or using some other technique. The RTP packet, including compressed timestamp 414, is then transmitted on downlink 144 of RF link 140 to terminal 130.

Upon receiving the RTP packet with compressed header (ie, compressed timestamp 414), the terminal adapter (term_AD) 136 of terminal 130 decompresses the timestamp value. Terminal adapter 136 decompresses compressed timestamp 414 by first calculating a timestamp estimate or approximation based on the current value of timer 134. The approximation of the timestamp is then refined or corrected based on the compressed timestamp 414 provided in the header of the packet. In this way, the timestamp for the current packet (header) is regenerated based on a local timer (timer 134) and a compressed timestamp provided in the current header. The other fields in the packet header (such as the sequence number) can also be regenerated. The packet and the regenerated timestamp are then provided to the RTP endpoint 132 for processing. The RTP endpoint 132 then plays the speech samples in the proper order (as specified by the sequence numbers) and with the proper timing, as specified by the regenerated timestamps (eg, to compensate for any gaps). of silence).

IS 2 460 140 T3

The ANI_AD 112 can also receive compressed headers (including a compressed timestamp) over the RF link 140, and decompress the timestamp using the timer-based decompression technique described above. Therefore, the ANI_AD 112 may typically include a timer to allow the ANI_AD to decompress the compressed timestamp, as described above. Similarly, the term_AD 136 of the terminal 130 may also compress the timestamp of the RTP packet prior to transmission of the RTP packet over the RF link 140 to the ANI 110. To simplify the explanation of the exemplary embodiments of the invention, most of the description will be directed to downlink path 144. According to an example of the invention, RTP packets can be transmitted in both directions (uplink 142 and downlink 144). Thus, both the ANI_AD 112 of the ANI 110 and the term_AD of the terminal 130 can function as a compressor (for the transmission of the header / packet over the RF link) and decompressor (after receiving a compressed header received by the link 140 of RF) of temporary stamps.

C. Exemplary Realizations of Compression and Decompression of Time Stamps

Exemplary embodiments of time stamp compression and decompression will be briefly described. The data in the RTP packets is assumed to be voice data. The following variables and formulas are defined only to assist in explaining some of the features of the present invention, but the invention is not limited thereto. Furthermore, the present invention is not limited to systems that use the same or similar types of variables, and is not limited to systems that perform the specific calculations described below. The variables and calculations are provided merely as an exemplary embodiment of the invention.

T is the time separation between the RTP voice samples. (If there is a voice sample provided in each RTP packet, then T is also the spacing between the RTP packet headers.)

TS: time stamp

TS_tranco: the RTP timestamp is incremented by TS_tranco every T msec. In other words, the RTP timestamp increases by TS_tranco for each new RTP packet. TS_tranco is a constant (eg 100) that depends on the speech codec. The TS_tranco is provided to the receiver (terminal 130) and to the ANI_AD 112.

TS0: RTP timestamp of the first header of a session received at the RTP receiver. The first header of a session is considered a synchronization header, because it is used for synchronization. TS0 is an initial value of the RTP timestamp, provided to both the compressor (eg, ANI_AD 112) and decompressor (eg, term_AD 136) at the beginning of the session (for synchronization). According to one example, the ANI_AD and the term_AD are initialized or synchronized upon receipt of a packet from the RTP with an uncompressed head (including an uncompressed timestamp provided by TS0). According to one embodiment of the present invention, the timer-based decompression technique requires providing an initial timestamp TS0 (eg. e.g., via an initial or sync header that is decompressed) to the compressor (i.e., the ANI_AD 112) and to the decompressor (i.e., term_AD 136) of timestamps before the compressed headers can be properly decompressed (i.e. , so that the decompressor can correctly regenerate the time stamp).

The RTP timestamp of packet header m (generated at time m * T msec) = TS0 + TS_tranco * m. This assumes that there is a header for each speech sample. As shown in the examples described below, this formula can be extended to the case of multiple speech samples (eg 3 speech samples) per packet header.

m: an integer indicating the number of voice samples that have been sent. m is reset or cleared with 0 at the beginning of the session. m is proportional to (or indicates) the amount of time that has elapsed since the beginning of the session. m increases by 1 every T msec.

TS_actual = TS0 + m_actual * TS_tranco; The current timestamp for the current packet header.

Receiver Timer: The timer at the RTP receiver (or RTP recipient), such as timer 134 on terminal 130. The local receiver timer is typically free-running and will not be reset at the beginning of a session. Instead, the elapsed time at the RTP receiver between receiving two packet headers can be obtained by subtracting the timer value from the current header from the receiver timer value when the previous packet header was received. By allowing the receiver timer to run freely, a receiver timer can be shared by many flows or sessions. Alternatively, the receiver timer can be reset at the beginning of each session. Resetting or clearing a receiver timer at the beginning of a session (that is, upon receipt of the initialization header) would require a

ES 2 460 140 T3 dedicated receiver timer (timer process) for each session or flow. The first uncompressed timestamp (TS0) of a session can be provided to the ANI_AD and term_AD in an initialization header. The first header is provided to initialize the compressor (ANI_AD 112) and the decompressor (term_AD 136). The receiver timer is then incremented by 1 every T msec. The ANI_AD 112 (compressor) uses the value of TS0 to compress the timestamps of subsequent RTP packet headers: The term_AD 136 (decompressor) uses the value of TS0 to decompress the value of the compressed timestamp (e.g., to regenerate the timestamps in the RTP headers received below).

current_timer: the value of the timer at the RTP receiver (eg terminal 130) when the current header is received last_timer: the value at the time, at the receiver, when the last header was received. (The current_timer is stored as the last_timer for the next time stamp header calculation.)

m_last: the value of m for the last header received; m indicates the number of voice frames that have elapsed since the initialization header.

To compress the timestamp of the current packet, the ANI_AD 112 calculates the current value of m as: m_actual = (TS_actual - TS0) / TS_tranco. Therefore, the ANI_AD subtracts the initial value of the timestamp (at the beginning of the session) from the current timestamp. This difference is divided by the time stamp stride (TS_tranco). However, in some embodiments, it may be unnecessary to actually perform a division operation. Other techniques can be used to properly generate m_current without performing a divide operation, which can require high processor overhead.

The least significant k bits of m_current are then provided as the compressed timestamp 414. The RTP packet that includes the compressed timestamp 414 is then transmitted over the RF link 140 to the recipient or receiver of the RTP (eg, the terminal 130).

At the RTP receiver (eg, terminal 130), the terminal adapter (Term_AD) 136 decompresses the compressed timestamp 414. The current_timer value from the previous header is stored as last_timer first. Then, when the current header arrives, the term_AD 136 reads the value of the receiver's timer 134 and stores this in memory as current_timer. Then timer_diff is calculated as: timer_diff = current_timer - last_timer. The ANI_AD calculates the exact value of m_current by finding the integer d, where (-L / 2 <d <L / 2, where L = 2^k), such that: (Eq. 1) k least significant bits of (d + last_m + timer_diff) = compressed timestamp 414 (for current header).

(Eq. 2)

As noted, the received compressed timestamp also has k bits. Once d has been calculated using Eqs. 1 and 2, the current TS can then be calculated as:

TS_actual = TS0 + (d + m_last + timer_diff) * TS_tranco.

(Eq. 3).

In equation 3, the effective or correct value of current m is shown in parentheses as (d + last_m + timer_diff). m_last + timer is the approximation of m_current, while d is the difference between the approximation of m_current and the correct value of m_current. Also, TS0 + (m_last + timer_diff) * TS_tranco is an approximation of the current timestamp value, and d * TS_tranco is the difference between the approximate current timestamp and the effective (or correct) value of the current timestamp.

Therefore, it can be seen that the RTP receiver first calculates an approximation (or estimate) of the current timestamp based on the time elapsed between receiving the current header and the previous header (which was correctly decompressed), such as: approximate current timestamp = TS0 + (m_last + timer_diff) * TS_tranco. The approximate current timestamp is then adjusted or corrected with the amount d * TS_tranco to calculate the correct value of the current timestamp (TS_current).

After TS_actual is calculated, the current RTP packet (including its regenerated timestamp or

ES 2 460 140 T3 decompressed, TS_current) is provided up to RTP endpoint 132. This compression and decompression process is transparent to the endpoints of the RTP.

FIG. 5 is a diagram illustrating an exemplary header compression and decompression operation in accordance with an example of the invention. This example applies some of the specific formulas described above to illustrate some features of the present invention. In this exemplary embodiment, it is assumed that the timers at the RTP source 502 and at the RTP receiver 504 have the same frequency, but are not typically synchronized. The timer at the RTP source (e.g., increasing by 1 every T msec) is used to generate the timestamp, while the timer (e.g., timer 134) at the RTP receiver is used to regenerate or decompress the RTP timestamp.

Referring to FIG. 5, at the beginning of a session, an initialization header 508 is generated at the RTP source, including an initial value of the timestamp (TS0). The initialization header 508 is transmitted to the ANI and then forwarded to the RTP receiver 504 (eg, terminal 130). The timestamp in the initialization header is not compressed. Upon receiving the initialization header, the initial value of the timestamp (TS0) is stored in memory in the ANI_AD, along with the value of TS_tranco. According to one example, two initialization headers can be transmitted to the ANI_AD. The ANI_AD can then calculate TS_tranco as the second timestamp - the first timestamp. The term_AD can similarly calculate TS_tranco or receive the value in a packet.

Similarly, when the initialization header 508 is received at the RTP receiver (terminal 130), the initial timestamp (TS0) is stored in memory along with the value of TS_tranco. Furthermore, upon receipt 510 of the initialization header 508 (FIG. 5), the value of m_current is cleared or reset with zero (0), and the receiver's timer is then read and stored as receiver_initial_timer, 516. Instead of reading the timer at the beginning of the session, the receiver's timer can be reset or cleared. In this example, the value read from the receiver timer at the beginning of the session happens to be zero (0), for simplicity. Thus, the example shown in Fig. 5 applies to both examples (just reading the timer from the receiver, or resetting it with zero) because the free run timer is read as zero at the beginning of the session. Similarly, you don't need to clear m_current, but could instead store a value for m_current. The receiver timer is then incremented (eg, by 1) every T msec (which is the same frequency as the timer at the RTP source 502, used to generate timestamps). The initialization header 508 arrives at the RTP receiver 502 after a fixed delay (integral delay 512) and a variable delay (cumulative delay jitter 514).

Then the RTP source 502 generates the next RTP packet (the first RTP packet in the session after the initialization header). This RTP packet is generated 3 * T msec after the initialization header has been generated and thus would typically include three (3) speech samples, for example. Other figures are possible. Therefore, the timestamp for the header of this packet is: TS (1) = TS0 + 3 * TS_tranco, as shown in Fig. 5. TS (1) refers to the timestamp generated after 3T msec after initialization. In this example, TS_tranco will be assumed to be 100, for example. TS0 is assumed to be 0, for example. Thus, TS (1) = 300.

The timestamp value for this packet, TS (1), is received in the ANI_AD and compressed based on TS (1) (the timestamp value), TS0 (the initial timestamp value), and TS_tranco (the timestamp). amount by which the timestamp is increased every T msec). According to an exemplary embodiment, the compressed timestamp may be calculated as the k least significant bits of m_current. The ANI_AD 112 calculates the current value of m as: m_actual = (TS_actual - TS0) / TS_tranco. In this example, TS_tranco will be assumed to be 100, for example. In this example, current_m is calculated as: current_m = (300-0) / 100 = 3. k in this example will be two (2). Thus, the two least significant bits of m_current (11 in binary) are provided as compressed timestamp 414 for this packet (CTS1), Fig. 5.

The compressed timestamp (CTS1) arrives at the RTP receiver 502 and the term_AD 136 at the RTP receiver regenerates or decompresses the timestamp, TS (1), for the current packet. The value of current_timer (zero) is stored as last_timer and current_m is stored as m_last. m_actual was previously set to zero at the beginning of the session (that is, upon receipt of the sync header). The receiver timer value (3 in this case) is read and stored as current_timer. The value of timer_diff is then calculated as current_timer - last_timer, which is 3 - 0 = 3. Timer_diff + last_m is an approximation of current_m.

Then, term_AD 136 calculates the exact or corrected value for m_current, using equations (1) and (2). Using equation (2), the two least significant bits of (d + last_m + timer_diff) = CTS1 (the compressed timestamp for the current header). In this case, last_m is zero (0), timer_diff is three (3), and CTS1 is three (3). Thus, the two least significant bits of (d + 0 + 3) = 3. Thus, d is equal to zero.

IS 2 460 140 T3

Using equation (3), the decompressed timestamp for this packet is then calculated as TS (1) = TS0 + (d + last_m + timer_diff) * TS_tranco. Thus, as a result, TS (1) = 0 + (0 + 0 + 3) * 100 = 300. The decompressed timestamp for this packet, TS (1) = 300, is then provided to RTP endpoint 132 on the RTP source, along with the RTP data and other decompressed header fields. The correct or effective value for current_m is (d + last_m + timer_diff). Therefore, for this package, it can be seen that the approximation of current m is the same as the correct value of current m (but this is not true in the general case). m_actual is then updated to be 3.

The next packet and timestamp is generated at the RTP source, including a timestamp TS (2) = 0 + 6 * 100 = 600. In the ANI_AD, the value TS (2) = 600 is compressed into a compressed timestamp as the 2 least significant bits of (600 - 0) / 100 = 6. In this case, 6 in binary is 110. Thus, the two least significant bits of 110 are

10. So, CTS2 = 10 in binary.

The compressed timestamp for this packet (CTS2) is then received at term_AD 136 after the receiver timer reaches the value of 7, due to full delay and cumulative delay jitter. The value of current_timer (3) is stored as last_timer and current_m (3) is stored as m_last. The current value of the receiver timer (7 in this case) is read and stored as current_timer. Timer_diff is then calculated as current_timer - last_timer, which is 7 - 3 = 4. Timer_diff + last_m is an approximation of current_m, which is 7.

Then, term_AD 136 calculates the exact or corrected value for m_current using equations (1) and (2). Using equation (2), the two least significant bits of (d + last_m + timer_diff) = CTS2 (the compressed timestamp for the current header). In this case, m_last is 3, timer_diff is 4, and CTS2 is 10 (in binary, which is 3 in decimal). d is solved in equation 2 as follows: the 2 least significant bits of (d + 3 + 4) =

2. Seven in binary is 111. So, d = -1. d is the difference between the approximation of m_current and the effective value of m_current. Replacing d in equation (3), the timestamp for this packet is calculated as TS (2) = 0 + (-1 + 3 + 4) * 100 = 600. Thus, the RTP receiver term_AD 136 has successfully regenerated (eg, decompressed) the RTP timestamp based on a local timer and a compressed timestamp.

It should be noted that, unlike the prior techniques, it is unnecessary to resend an initialization header in the case where one or more packets do not reach the RTP receiver. In other words, synchronization between the RTP source and receiver is required only once at the beginning of a session or connection. This is because the current timestamp is calculated at the RTP receiver based on both m_last and timer_diff. Timer_diff is calculated as current_timer - last_timer. Therefore, the values ​​of m_last and last_timer correspond to the last packet, regardless of which packet was received last (eg, regardless of whether packets sent after the last packet were erroneously discarded or lost). As a result, the timer-based compression scheme according to an example of the invention is robust against errors and lowers bandwidth requirements, because it is unnecessary to send a new synchronization packet (e.g., including complete values ​​not compressed for all headers) in the event that an error is detected (eg, one or more packets dropped or lost).

In normal operation, the discrepancy between the approximation and the exact value of m_actual is caused by:

a) accumulated delay jitter between the same source of the RTP timestamps and the receiver; the effective delay = full delay + cumulative delay jitter, where the integral delay is constant and the cumulative delay jitter varies from one header to the next, and 0 <cumulative delay jitter <maximum cumulative delay jitter; Y

b) Possible asynchrony between the timer process and the decompressor process, depending on the timer implementation. Due to asynchrony, there may be a plus or minus one (+ or - 1) error in the timer value (current_timer).

FIG. 6 is a diagram illustrating an exemplary header compression and decompression operation according to another example of the invention. Like Fig. 5, Fig. 6 is a diagram illustrating the effect of delay jitter and timer asynchrony. In Fig. 5, the receiver timer is reset or cleared only at the beginning of the session. (This is not necessary as the receiver's timer can be allowed to continue.) However, in the exemplary embodiment illustrated in Fig. 6, the receiver timer is reset or cleared with zero (0) for each packet. Thus, when a decompressed packet header is received, the timer value is read, which indicates the timer_diff value described above (since the timer indicates the time elapsed since the last packet header). There can be many different ways to implement the invention. What is important is that a timer difference should be measured indicating the elapsed time (as measured by the local receiver timer) between the last successfully decompressed timestamp and the current timestamp (timer_diff as described in Fig. 5 ).

IS 2 460 140 T3

With reference to Fig. 6, header n is generated with timestamp = TS0 + 3 + TS_tranco. This timestamp of the header n is compressed and transmitted to the RTP receiver, and decompressed. The timer is then reset in the receiver. The following headers, (n + 1), (n + 2), and (n + 3) are generated and sent, but only the header (n + 3) is received (that is, the headers n + 1 and n + 2 are lost). For simplicity, the headers (n + 2) and (n + 3) are not shown in Fig. 6. The header (n + 1) is shown in Fig. 6 as the header m + n. The header (m + n) is generated and sent, with the timestamp TS = TS0 + 6 * TS_tranco. This header timestamp (m + n) is compressed and then sent to the RTP receiver. The timer value is 4 (indicating timer_diff). This value is used to decompress the timestamp for the header (m + n). Therefore, the example in Fig. 6 is very similar to the example shown in Fig. 5, except that the timer is reset after each header is received in Fig. 6.

Regardless of which technique is employed (either Fig. 5 or Fig. 6), an effective timer-based compression scheme can be used. However, if the accumulated delay jitter is excessive, it may not be possible to regenerate a correct timestamp based on the compressed timestamp. In many cases, the following condition should be satisfied by k to allow the timer-based compression scheme, illustrated in Figs. 5 and / or 6, works properly:

[Condition 1] (Maximum integral delay jitter + 2) <2^k, where the Maximum Integral Delay Jitter (MIJ) is the maximum cumulative delay jitter, expressed in units of T msec, rounded to the next largest whole number. For example, if T = 20 msec, a maximum cumulative delay jitter of 15 msec will result in MIJ = 1. 2 is added to the MIJ to compensate for possible error caused by timer asynchrony.

Due to real-time conversational requirements, the cumulative delay jitter in normal operation may be only a few multiples of T msec. Therefore, in such a case, a value of k equal to 4 is more than sufficient, since a discrepancy of speech samples of up to 16 (ie 16 * T msec) can be corrected at the RTP receiver. Abnormal or erroneous situations may result in delay jitter exceeding normal values. A lag jitter reduction entity can be added upstream of the compressor to ensure that lag jitter, as viewed by the compressor, remains within acceptable limits.

The advantages of the temporary seal compression scheme illustrated in Figs. 5 and / or 6 include:

a) The size of the timestamp is constant and small. The compressed header usually consists of a message type, indicating the type of message (k 1 bits), a bit mask that indicates which fields are changing, and a field containing the k least significant bits of m_current (k bits) . Assuming that the same 4-bit MST1 mask is used as in RFC2508, and that k 1 = 4, the compressed header size, when only the RTP TS changes (this case is by far the most frequent) , is 1.5 bytes. Also, the size does not change as a function of the length of the silence interval.

b) As shown in, for example, Fig. 6, the receiver timer operates on the same frequency as the RTP source timer (used to generate the original timestamp); phase synchronization between the source timer and the receiver timer is not required (because it is the elapsed time as measured by the receiver timer that is used to regenerate the timestamp).

c) At the receiver, no synchronization is required between the timer process and the decompressor process. For example, the timer process can increment the timer by 1 every T msec, while the decompressor process is awakened to decompress when a new header is received. However, the point at which the timer is incremented is not required to be aligned or synchronized with the point where the header is received (see Fig. 6).

d) Robustness to errors, since the partial information of the RTP TS in the compressed header is self-contained and only needs to be combined with the receiver's timer to produce the complete value of the RTP TS. Loss or corruption of a header will not invalidate subsequent compressed headers.

e) It is not necessary to maintain or store any memory or values ​​by the compressor in order to compress / decompress the RTP TS.

D. Transfer

According to one embodiment, each ANI_AD is assigned a specific area (eg, interface terminals located in a specific area). Terminals (such as terminal 130) can move from one area to another. When a terminal moves from one area to another, the terminal must be handed over, or switched from one ANI_AD to another ANI_AD.

IS 2 460 140 T3

One case of handover to consider is handover between ANI_AD, where there may be a disturbance caused by switching from the old ANI_AD to a new ANI_AD. The question is how to maintain the continuity of information throughout the handover, such that, after the handover, compression / decompression in the term_AD 136 and the new ANI_AD continue undisturbed.

1. Downlink

There is no discontinuity on the receiving side, which is the terminal (eg, terminal 130, Fig. 1). The role of the compressor is transferred from one ANI_AD to another. After handover, the headers are routed on a new path that passes through the new ANI_AD, instead of the old ANI_AD. Furthermore, depending on the system design, there may or may not be rerouting of packets in transit during the handover. The packets in transit are those generated by the origin but have not yet reached the receiver at the time of handover. The rerouting attempts to deliver the packets in transit to the terminal.

To carry out the handover, the old ANI_AD must transfer the initial value of the timestamp for the session (TS0) and TS_tranco to the new ANI_AD. These two values ​​allow the new ANI_AD to continue compressing new timestamps (into new packet headers) received from the source of the RTP (eg terminal 102). Let Header_actual be the very first header to be decompressed by term_AD after the handover, and its TS_actual its RTP timestamp. The term_AD can decompress TS_actual as long as the following condition is satisfied:

[Condition 2] (Downlink Transient integral delay jitter + 2) <2^k, where the Downlink Transient Integral Delay Jitter (DTIJ) is the current_Header's downlink transient delay jitter, expressed in units of T msec, rounded to the next largest integer. The downlink transient delay jitter is defined as = current_Header total delay - full delay on old path. If the current_Header is not the header of a rerouted in-transit packet, the total delay of the current_Header is also the full delay on the new path + the cumulative delay jitter for the current_Header on the new path. Therefore, the downlink transient delay jitter = full delay on the new path - full delay on the old path + cumulative delay jitter for the current_Header.

If Current_Header is the header of a rerouted in-transit packet, the total delay of Current_Header = total delay caused by routing and rerouting. In practice, systems should preferably be designed to keep the downlink transient delay jitter in the same range of values ​​as the steady state cumulative delay jitter (ie no handover). Therefore, based on these assumptions (which may not always hold), no specific handover-related problem is expected for the downlink if condition 1 (noted above) is satisfied.

2. Uplink

In this uplink description, the terminal term_AD 136 (eg, terminal 130) compresses the timestamp and sends it on the RF link 140 to the local or corresponding ANI_AD. The RTP source in this case is terminal 130. Even when the RTP source (terminal 130) changes physical locations (requiring a handover in the ANI_AD), the role of the receiver (of the decompressor) is transferred from a ANI_AD to another. The RTP source remains anchored at the terminal (eg, terminal 130, Fig. 1).

FIG. 7 is a diagram illustrating an exemplary handover operation according to an example of the present invention. To minimize air interface overhead, it is necessary to transfer some information from an old ANI_AD 710 to a new ANI_AD 712 for handover. That information is the value of the timer in the old ANI_AD. The old ANI_AD 710 reads (or takes a snapshot of) the current value of the Timer (T_u) in the old ANI_AD, and sends it to the new ANI_AD, along with TS0, TS_tranco and m_actual, block 714 (Fig. 7). The new ANI_AD resumes increasing its timer, starting from (T_u). Let T_transfer 715 (Fig. 7) be the time to transfer the Timer. Also, the timer processes in the old and new ANI_ADs can have a phase difference that is at most T msec. Let Header_current be the very first header to be decompressed by the new ANI_AD after the handover, and let TS_actual be its RTP timestamp. The new ANI_AD can decompress TS_current as long as the following condition is satisfied:

[Condition 3] (Uplink transient integral delay jitter + 2 + 1) <2^k, where the Uplink Transient Integral Delay Jitter (UTIJ) is the uplink transient delay jitter expressed in units of T msec, rounded to the next higher whole number. Uplink transient delay jitter is defined as = Total Header_current delay - delay

ES 2 460 140 T3 intact on the old path + T_transfer. As the Total Delay of the current_Header = full delay on the new path + cumulative delay jitter for the current_Header, the uplink transient delay jitter = full delay on the new path - integral delay on the old path + cumulative delay jitter for Current_Head + T_transfer. Compared to the downlink case, 1 is added to compensate for the phase difference between the old ANI_AD timer and the new ANI_AD timer.

Specifically, Fig. 7 also illustrates the transient uplink delay jitter, which includes the integer delay difference and T_transfer. In this example, the old ANI_AD decides to prepare for the handover before the timer increments the timer. Therefore, send T_u = 0 to the new ANI_AD 712. T_transfer is approximately T msec. In the new ANI_AD 712, due to the asynchrony of the timer process, almost T msec elapses before the timer is incremented. There is also a cumulative delay jitter in the new path for the headland (n + m). As a result, the timer value read when the header (n + m) is received is 2, while the actual value should be 4. Therefore, there is an offset of -2. As long as condition 3 is met, the offset can be removed and the RTP timestamp can be successfully decompressed.

According to one embodiment, T_u is transmitted over a high-speed signaling network, connecting the old and new ANI_ADs. Consequently, the T_transfer time should be, at most, only a few T msec. However, cases where the transfer of T_u is not successful, or not timely enough, should be considered. In those cases, the new ANI_AD will notify term_AD, which sends the full (uncompressed) timestamp until an acknowledgment is received.

E. Delay Jitter Reduction

According to an embodiment of the present invention, the timer-based compression scheme using a compressed timestamp and a local receiver timer can be asserted if the following conditions are satisfied.

[Condition 1] (Maximum integral delay jitter + 2) <2^k,

[Condition 2] (Downlink transient integral delay jitter + 2) <2^k,

[Condition 3] (Uplink transient integral delay jitter + 2 + 1) <2^k.

Due to real-time conversational requirements, the above various delay fluctuations can reasonably be expected to be on the order of a few T msec in normal operation. Therefore, a small value of k, p. eg 4 is usually more than enough to allow any lag or error to be corrected. However, there may be abnormal conditions on the path from the origin of the RTP to the receiver (failures, etc.) or other situations, in which the delay fluctuations become excessive (where the correct timestamp cannot be generated based on the seal time compressed and the local receiver timer). To deal with these cases, a Delay Jitter Reduction Function (JRF) 115 may be provided (Fig. 1) as a first-order interface to the compressor, to filter (or discard) packets with excessive delay jitter (eg, where any of the above conditions 1,2, or 3 are not satisfied).

To filter or identify excessive MIJ packets, the Delay Jitter Reduction (JRF) function calculates the delay jitter of each packet received by the network 108. If the measured delay jitter of the packet is greater than 2^k - 2, this is considered excessive delay jitter and the packet is discarded. Otherwise, the header (or header field) is compressed (as described above) and then transmitted to the receiving terminal (eg, terminal 130).

The JRF calculates the delay jitter of the current packet as follows: delay jitter = absolute value of (TS2 - TS1 - JRF timer diff), where TS2 is the timestamp of the current packet, TS1 is the timestamp of the previous packet and JRF_timer_diff is the difference in the JRF_timer between the current packet and the previous packet (elapsed time). This delay jitter value is compared to 2^k - 2. If the delay jitter is greater than 2^k - 2, the packet is discarded. Otherwise, the packet header is compressed in the ANI_AD and the packet with the compressed header is sent to the RTP receiver.

This jitter reduction function (JRF) 115 is an effective technique to limit jitter in the packets received by the receiving terminal (because the jitter introduced by the RF link can be considered negligible). Additionally, the JRF works to more efficiently utilize the bandwidth available over the RF link 140. In the absence of JRF 115, one or more packets, with a delay jitter greater than 2^k - 2, they could be transmitted to the receiver on link 140. However, at the receiver, if the delay jitter is excessive (that is, condition 1 is not satisfied), the correct value of the timestamp cannot be generated, thus

ES 2 460 140 T3 which causes the receiver to discard the packet. Thus, the JRF functions merely to filter out those packets with excessive delay jitter, which would be discarded at the receiver in any case (avoiding wasted valuable bandwidth over link 140).

II. Header Shredding Scheme

A second embodiment of the present invention provides a timer-based header hash scheme in which a header, or one or more header fields (e.g., including the RTP timestamp), is removed ( n) of the RTP packet prior to transmission over the low-bandwidth link (eg, over the RF link 140, FIG. 1). In such a case, the timestamp is not explicitly provided in the RTP packet. Instead, the timing information can be provided implicitly to a headend regenerator to increment the local timer based on an essentially constant bit rate channel, or a circuit-like connection, between the headend shredder (e.g., that may exist in an ANI_AD) and the header regenerator (eg, that may exist in terminal 130).

A. Summary of Header Breakdown

Header hashing is based on the idea that, for some applications or services, it is not necessary to transport all the information contained in the IP / UDP / RTP headers, either because they do not change, or because they are not essential to the application / service. The basic voice is a typical example. To provide a service equivalent to existing cellular voice service (e.g., over RF link 140, Fig. 1), the only variable header information that is essential is the RTP Timestamp (TS). It is also desirable to maintain transparency for the RTP sequence number (SN). The transparency here (for the SN) means that the SN, after removal / regeneration, is equal to the original SN. Header hashing relies on implicit timing information provided by a circuit-like connection, or by an essentially constant bitrate channel (where no packet delay jitter is introduced), to allow time stamping RTP is regenerated only based on a local timer or counter. This eliminates the need to explicitly send the timestamp (or even send a compressed timestamp). To achieve SN transparency, compressed SNs can be used in combination with channel timing information or circuit-like connection. A circuit-like connection preferably provides a channel with an essentially constant bit rate. When there is no speech sample (eg, silence interval), the channel may or may not be allocated to other traffic and / or other users. Advantages of this header mincing scheme include:

a) Minimal overhead overhead, unmatched by any other scheme (even less than the compressed headland technique previously described in Figs. 1-6).

b) Robustness to errors, since circuit-like transmission timing information, or essentially constant bit rate channel, is inherently out of the range of errors.

c) Possibility of switching during a call to header compression (eg, the technique of Figs. 16), if desired. This can be useful if the call becomes a multimedia call, as a non-voice medium is added to the voice. Also, note that header hash does not force or exclude statistical multiplexing which, if implemented, could take place in a lower layer.

FIG. 8 is a block diagram illustrating an exemplary battery in accordance with an exemplary embodiment of the present invention. A head chopper stack 802 and a head regenerator stack 830 are shown. As an example, the header shredder stack 802 illustrates some of the components that can be used to remove one or more header fields from the packet, while the header regenerator stack 830 illustrates some of the components that may be used to regenerate the packet header. . The header chopper stack 802 could be provided, for example, within one type of ANI adapter (e.g., the ANI_AD 112, Fig. 1), while the header stack 830 may reside, for example, in one type of terminal adapter (eg, term_AD 136, Fig. 1).

Referring to FIG. 8, the header stack 802 includes RTP and UDP layers 804, and an IP layer 806. The RTP / UDP / IP layers generate an 808 RTP packet (which includes a timestamp in the RTP header). Then, in the header shredder stack 802, the RTP packet 808 is provided to a header shredder (HS) 810 to shred or remove one or more headers or header fields. Layers L1 and L2 812 are provided, where L2 can be a data link layer, and L1 layer can be a physical layer, for example. Other layers could be provided as required. Similarly, the header regenerator stack 830 includes the corresponding L1 and L2 layers 820, a header regenerator (HR) 822 that regenerates the header (including the RTP timestamp) to provide the complete RTP packet 824 (including the RTP / UDP / IP headers). The 824 packet is delivered to the IP layer 826 and then to the UDP and RTP layers 828. Layers L1 and L2 of the header shredder stack 802 and regenerative stack 830 of

ES 2 460 140 T3 headends are in communication over a link 815 or air interface (such as an RF link 140), or over a network. For example, Voice over IP packets are passed through headend chopper 810 prior to transmission on link 815 (eg, wireless link or network). At the receiving end (in the headend regenerator stack 830), the headend regenerator 822 regenerates the headers prior to delivery to the recipient. The L2 / L1 layers can provide the circuit-like connection, that is, by providing an essentially constant bit rate channel between the header 810 and the header regenerator 822. In addition, for maximum efficiency, the L1 layer can also carry out voice payload optimization, such as odd-bit protection, in addition to optimized channel coding and interleaving. Note that the concept of header hashing is applicable regardless of whether or not payload optimization is done.

In operation, the header (HS) 810 removes the delay jitter in the incoming RTP packets, and plays them according to the RTP timestamp (TS) in the header. Here, the elimination of the delay jitter means scheduling the transmission of the speech sample over the circuit-like connection, or the essentially constant bit rate channel, according to the timestamp. In other words, the packets, after the headers have been stripped or shredded, are transmitted on the circuit-like channel or the essentially constant bit rate channel, at times based on their timestamp in the packet. Packets with excessive jitter are discarded, using the jitter reduction function (JRF 115, Fig. 1), for example. The header regenerator (HR) 822 reconstructs the IP / UDP / RTP fields, which can be classified into the following categories:

a) Static: The value does not change during the session, p. e.g. IP addresses

b) Non-static: The value could change, in principle, between one packet and the next, but in practice, for voice, the only non-static field that is essential to preserve during the hash of the header is the timestamp ( TS) of the RTP. The RTP sequence number (SN) is also preserved. Static fields can be transferred once and forever as part of a complete header in the initialization phase, at the beginning of the session. A reliable delivery mechanism can be used (eg, using Acknowledgments, or Ack, from the RTP receiver to acknowledge the initialization information). The timestamp and sequence number will be briefly exposed.

1. RTP Temporary Seal (TS)

In the case of voice, the RTP timestamp (TS) increases linearly as a function of the common clock (ie, the source timer) at the RTP source. If the time interval between consecutive speech samples is T msec, then the RTP timestamp of header n (generated at time n * T msec) = RTP timestamp of header 0 (generated at time 0) + TS_tranco * n, where TS_tranco and T are constants dependent on the voice codec. This is true if there is one packet per speech (voice) sample. More generally, the RTP timestamp (TS) is of the form TS0 + m * TS_tranco, where TS0 is <TS_tranco and m is an integer. The same behavior is seen in the head chopper (HS) after the delay jitter has been removed.

At the beginning of a session or connection, an initialization phase is carried out to initialize the RTP receiver (ie initialize the headend regenerator). In the initialization phase, the header chopper continues to send initialization information (Info_inic) until an Ack is received from the receiver. Info_inic (n) consists essentially of the full IP / UDP / RTP header n (including an initial timestamp and sequence number). The RTP sequence number is used to identify this specific initialization header, since subsequent initialization headers will include larger sequence numbers (assuming the first initialization header is unacknowledged).

In the header regenerator (HR) 822, when the Info_inic (n) is received correctly, the HR 822 sends an acknowledgment to ack (n). Once the header regenerator (HR) 822 has acknowledged a full header, the HS 810 stops sending full headers. The HR 822 also starts a local timestamp counter that is initialized with the RTP timestamp received at Info_inic (n). The TS counter is similar to the receiver timer in Fig. 1, but the TS counter is incremented by TS_tranco every T msec (instead of 1, but it is the same principle as the receiver timer). For subsequent hashed voice frames (ie, RTP packets where the headers have been hashed or removed), the RTP TS is regenerated from the timestamp (TS) counter. The receiver timer (TS timer) has the same frequency as the clock or timer used at the RTP source (that is, the source timer) to generate the timestamp. Furthermore, the circuit-like connection provides an essentially constant bit rate and thus the packet delays are not variable, or do not change between packet and packet. As a result, there is no packet delay jitter due to the essentially constant bit rate channel. Therefore, after the RTP receiver receives the initialization information, including an initial timestamp value (TS0), the RTP receiver can regenerate a correct timestamp for each subsequent packet (after the

ES 2 460 140 T3 initialization), based only on the timestamp counter (or receiver timer).

The essentially constant bitrate channel, provided between the overhead shredder 810 and the overhead regenerator 822, only needs to supply a predetermined number of bits during a predetermined period of time between the overhead shredder 810 and the overhead regenerator 822, But this function can be performed in several different ways. For example, the channel may be an essentially constant bit rate channel that is dedicated to shredder 810 and regenerator 822, or shared among multiple users. The channel may, for example, provide one bit every millisecond, or provide 100 bits every 100 milliseconds, but where the bit rate may not be constant (ie, it may vary) within a period of 100 ms. As a further example, the channel may provide the predetermined number of bits by one or more data bursts between the header chopper and the header regenerator. For example, the channel may provide a 1000-bit chunk or burst every 10 milliseconds. Thus, the essentially constant bitrate channel only needs to provide a predetermined number of bits for a predetermined period of time, but can achieve this using various techniques.

2. RTP Sequence Number (SN)

The RTP SN (as seen by the HS 810) typically increases by 1 from one packet to the next. The only exceptions are when packages are lost or out of order. On the uplink, packet loss or disorder is not expected to occur, as the head-end shredder (HS) 810 and the RTP source are very close to each other. Therefore, the following applies to the downlink. The HS 810 performs limited buffering to try and reorder the packets before shredding their headers. The packet with the SN n of the RTP is considered lost if it has not yet been received at the moment when the packet with the SN (n + 1) of the RTP has its header removed. The packet with RTP SN m is out of order if, at the time it is received, the packet with RTP SN k has had its header removed, and k> m. The length of the reorder buffer is a design parameter. Too long a buffer will result in an excessively long delay, while too short a buffer will result in too many dropped packets. The parameter also depends on the quality provided by the IP network 108 upstream of the HS 810. The HR 822 maintains an SN counter which is its best estimate of the SN. By looking at the Info_inic, the HR 822 can obtain the initial SN and the number of bits contained in a packet, also known as the packet size (p_size). The HR 822 initializes the SN counter with the SN in Info_inic. The HR 822 then "counts" the speech bits received on the essentially constant bit rate channel and increments the SN counter for each p_speech bit size (does not increment when no packet is received, eg, during an interval of silence). According to one embodiment, the HR 822 does not actually count the received bits. Instead, the SN counter in the HR 822 is incremented by 1 for the duration of each packet, where a packet duration is the time required to receive a packet of bits (p_bits). Thus, the duration of the packet will be a function of the packet size (p_size) and the bit rate (which is constant for the circuit-like connection).

Thus, it can be seen that after initialization takes place (which provides the initial SN and TS to the HR 822), the HR 822 can generate the timestamps for sequential packets by incrementing the TS counter by TS_track every T msec, and incrementing the SN counter at 1 for each packet duration. Therefore, after initialization, these fields can be regenerated in the HR 822 with reference to only a local clock (assuming that TS_tranco and the duration of the packet are known by the HR 822). Increasing the SN counter based on time (packet duration) rather than the actual count of received bits is more robust against errors. In the event that one or more bits are discarded before reaching HR 822, the SN counter will reflect the true value and will not be affected by the missing bits.

B. Discontinuities and Chains

The above description indicates that TS and SN can be completely shredded by the HS 810 prior to transmission over a link (eg, RF link 140), and then regenerated by the HR 822, maintaining a local clock or timer. (eg, incrementing the TS counter by TS_tranco every T msec and incrementing the SN counter by 1 for every packet duration). However, one or more basic discontinuity events may occur which, if not addressed, could eventually invalidate the timer-based regeneration, described above. Some of the discontinuity events may include:

a) Event “New burst Transient change in TS difference between packet n and (n + 1) (start of a new conversation burst); this can also be described as a non-linear change or shift in timestamp (TS):

b) “Size change” event: Change in packet size (p_size), caused by a change in the number of speech frames packed in a packet and / or the size of the speech frame

IS 2 460 140 T3

c) “Stride change” event: Change in TS_tranco (caused, for example, by a change in payload PT type).

We define a chain of headers as a sequence of packet headers such that all packets have the same size (p_size), the sequence numbers are consecutive, that is, n, (n + 1), (n + 2), etc. ., and the timestamps (TS) of the consecutive packets are separated by the same increment TS_tranco. In other words, a header string can be thought of as a header string with some packet fields in common (eg. g., packet size), and other fields that increase linearly between consecutive packets, such as SN and TS. A chain is usually a burst of conversation (eg, a series of speech samples provided between intervals of silence).

The transition from one chain to another can be caused by any of the discontinuity events, individually or even in combination. In this scheme, when a chain begins (and the previous chain has ended), the HS 810 determines which discontinuity event has occurred and consequently sends the necessary chain initialization information (chain_start) to the HR 822.

FIG. 9 is a table illustrating information that may be provided in messages in accordance with an exemplary embodiment of the invention. Info_inic typically includes a full header (including full SNs and TSs), and is sent from HS 810 to HR 822 (to initialize HR 822) at the beginning of the session. The HS 810 will continue to resend the info_inic until it receives an acknowledgment from the HR 822, before continuing to send the data packets without a header. Then there may be one or more strings that may appear, which may require additional updates to fields or values ​​that change from string to string. These changed values ​​are provided to the HR 822 using start_string.

Start_string includes the value of p_size (if it has changed from the previous chain), and the value of TS_tranco (if it has changed from the previous chain). If no non-linear shift occurs in the TS from one chain to the next, the HR 822 can continue to regenerate the TS based on the TS counter used in the old chain. However, if a non-linear offset occurs in the timestamp (TS) between strings (ie loss of timing), the updated timestamp must be explicitly sent in start_string from the HS 810 to the HR 822. The updated TS can be sent as a compressed temporary seal 414 (see FIG. 4) described above, as long as condition 1 is satisfied, as described above. Otherwise, if condition 1 is not satisfied, the complete updated timestamp must be transmitted to HR 822.

In the acknowledgment mode, after the HS 810 sends start_string to HR 822, the HS 810 may require the HR 822 to acknowledge (with ack) the updated chain information (start_string) before the HS 810 can send the additional data packets (packets without headers) to the HR 822. In the acknowledgment, or ack mode, the HS 810 repeatedly sends an init_string message to the HR 822 until the HS 810 receives an acknowledgment from the HR 822 for a init_string message. After receiving an acknowledgment from the HR 822, the HS 810 will then send the remaining packets in the chain as hashed header packets (since the TS and SN for the packets in the new chain can now be regenerated using only one clock or local timer). The acknowledgment requirement (in the acknowledgment mode) for the string_start message prevents the HS 810 from sending a new string without notifying the HR 822. For example, if the HS 810 sends a new string_start message (eg. (e.g., providing updated fields or information related to a discontinuity event) while the link between the HS 810 and the HR 822 is temporarily broken, the HS 810 cannot continue to send packets with shredded headers until it first receives the acknowledgment from the HR 822,

Once the HS 810 is certain that the HR 822 has received the start_string information, the speech frames (eg, data packets) are then sent without the header for the remainder of the chain. For these frames without a header, the TS and SN are regenerated using a local clock in the HR 822.

The HS 810 can determine events as follows:

a) “New burst” event: the difference in TS between the packet with SN = n and the packet with SN = (n + 1) is different from TS_tranco. This signifies the beginning of a new chain or burst of talk. In this case, to ensure SN synchronization, start_string consists of an SN or a compressed SN (C_SN). If there was no SN information sent, the HR 822 cannot be sure that incrementing the SN counter by 1 for each packet duration will provide an accurate SN. This is because there could have been a link disconnect, during which the speech bits were lost between the HS 810 and the HR.

b) “Size change” event: The size of the RTP packet with SN = n is different from that of the packet previously received; this will affect the value of the packet duration (the rate at which the SN counter is incremented). Start_string includes the new value of p_size.

c) “Stride change” event: Determined from the analysis of the payload type (PT) field in the RTP packet; start_string includes the new value of TS_tranco.

IS 2 460 140 T3

These discontinuity events are provided as examples only. Other types of discontinuity events are possible.

Events can occur in combination (compound event). In that case, start_string includes all the information for the corresponding basic events. For example, if “New burst” occurs in combination with “Resize”, start_string = {C_SN, new value of p_size}

C. Procedure to send Info_inic, Init_string

Info_inic is normally sent in the acknowledgment mode, in which the HS 810 will send Info_inic until it is acknowledged as received by the HR 822. Init_string can be sent in the acknowledged or unacknowledged mode. In the acknowledgment mode, the HS 810 will send Start_string in each packet until it is acknowledged as received by the HR 822. Once an acknowledgment is received, the HS 810 sends only speech bits for the remainder of the packet. string, without any header. In unacknowledged mode, the HS 810 will send String_start a certain (default) number of times before sending speech bits only for the remainder of the string. Optionally, the start_chain message can be repeated at certain intervals during the chain, to ensure that the HR 822 is in sync (eg, it has the proper values).

A compound event, which includes the basic event "Size Change" or "Stride Change" will typically require the Start_String message to be sent in the acknowledgment mode. In that case, Start_string will carry a generation number. The generation number is a counter incremented every time p_size or TS_tranco change. It is used in the case where p_size or TS_tranco change rapidly, to keep track of which change has been acknowledged as received by the HR 822. For example, if p_size changes from the value p_size_0 to p_size_1, and then back to the value p_size_2, the HS 810 will send a Start_string containing p_size_1, with a generation number, say, 3; then, then, another String_init containing p_size_2, with generation number 4. Receiving an acknowledgment after the second String_initiation will be ambiguous, if it did not carry the generation number of the String_init whose receipt is being acknowledged. If the compound event is New Burst only, Start_String (C_SN) can be sent in acknowledged or unacknowledged mode. The unacknowledged mode is based on the idea that the C_SN will repeat at least at the beginning of each burst of talk. Therefore, the probability that the HR 822 will never resynchronize its SN is asymptotically small. Also, if the SN is out of sync, it is only because of packet loss between the HS 810 and the HR 822. Therefore, the effect of an SN desynchronization is that the regenerated SN <the correct SN. This is just a temporary inconsistency that is corrected by making the SN increase by the value of the difference as soon as the next C_SN is received. An increase in SN by more than 1 will be interpreted by the RTP receiving endpoint as one or more packet losses and normally should not affect the playback of the received packet itself. The unacknowledged mode also allows a channel to be dispensed with to carry acknowledgments in steady state, that is, after call setup and between handovers.

D. Transfer

When head-end hashing / regeneration is applied to cellular systems or other systems where end stations can move from one network adapter (ANI_AD) to another, handovers should be considered.

The handover can be modeled as going through three phases: handover preparation, handover execution, and handover completion. There is a function called the handover manager (HO) (which may be provided in the ANI 110) that decides to initiate handover preparation. Traditionally, handover preparation consists of exchanging signaling messages with the destination system to reserve resources on the destination system and to obtain the necessary information about the destination cell. Handover execution is initiated by the source HO manager, sending an HO command to the receiving terminal (or mobile station), along with information about the destination cell. In response to the HO command, the terminal (or mobile station) executes the handover. The completion of the handover involves the exchange of signaling between the terminal or mobile station and the destination system, the notification to the origin and the release of resources that are no longer needed (eg, at the origin).

1. Uplink

The ANI_AD acts as an HR 822 for uplink data transmission (see uplink 142, Fig. 1). The destination ANI_AD must be provided with the necessary information to regenerate the complete header. The main constraints include the continuity of the RTP TS and RTP SN during handover (HO).

Fig. 10 is a diagram illustrating a handover process according to an exemplary embodiment of the present

ES 2 460 140 T3 invention. The terminal 130 (or mobile station MS), for example, may notify the source ANI_AD 112 that the packet size has changed, using a Start_string message, step 902. The source ANI_AD 112 acknowledges receipt of this update at p_size , step 904. The terminal 130 then moves to a new area covered by the destination ANI_AD 114, and the HO manager 901 notifies the originating ANI_AD of preparation for a handover (handover), step 906. The originating ANI_AD then sends an HO_initialization information (HO_inic_u) to the destination ANI_AD 114, step 908. HO_inic_u is an estimated view of the full IP / UDP / RTP header. The estimated view consists of the last regenerated header, but with an RTP TS replaced by TS0_u, m_last_u, TS_tranco_u and the value of Timer_u of the TS. These values ​​are related to TS_last, the RTP TS of the last regenerated header, as follows: TS_last = TS0_u + m_last_u * TS_tranco_u. The Timer_u of the TS is a counter in the source ANI_AD that was incremented by 1 every T msec. Also, HO_inic_u includes p_size_u (current packet size in the uplink direction). From the HO_inic_u, the destination ANI_AD derives the static fields, as well as approximate initial values ​​for the changing fields (TS of RTP and SN of RTP). A handover command is sent from HO manager 901 to terminal 130 (mobile station), step 910, causing terminal 130 to switch and now use the destination ANI_AD for communication. However, an HO manager may not be necessary, as other techniques can be used to initiate a handover.

A handover is considered a switch of any running chain. Therefore, after the completion of the handover, the very first speech sample to be sent is always managed as a new string, which requires sending initialization information (HO_sinc_u), step 912. There are three significant moments in time: ST1, which is the start of the HO preparation, ST2, which is the reception by the MS of the HO command, and ST3, which is the moment when the source ANI_AD took the snapshot of your internal information to send it in HO_inic_u. Let HOT be the elapsed time from ST1 to ST2. From the system design, there is an upper bound for HOT: HOT <HOT_max. A fourth significant moment in time is ST4: the first time terminal 130 wants to resume sending speech on the destination system after HO. At ST4, terminal 130 (MS) determines whether the most recent change in p_size_u has been acknowledged as received so far ST2-HOT_max. If so, terminal 130 is sure HO_inic_u contained the updated value of p_size_u. Therefore, there is no need to include it in HO_sinc_u. This is because the moments in time are ordered as ST1 <ST3 <ST2. Otherwise, terminal 130 (MS) will include the new value of p_size_u in HO_sinc_u. The same algorithm applies to TS_tranco_u.

In all cases, HO_sinc_u includes C_SN. C_SN is needed because there was a break caused by the HO. C_TS is needed if the bit rates, packet durations, etc., on the source and destination systems are out of sync. This is likely to be the case. HO_sinc_u is preferably sent in acknowledgment mode.

HO_inic_u and HO_sinc_u are used by the destination ANI_AD 114 to regenerate the full header as follows. All fields except TS and SN are copied from HO_inic_u. SN is obtained by decompressing the C_SN in HO_sinc_u. TS is determined by decompressing the C_TS into HO_sinc_u.

2. Downlink

The HS role is transferred from one ANI_AD to another. After handover, the headers are routed on a new path through the new ANI_AD instead of the old ANI_AD. As a result, there could be a discontinuity in the timing for regeneration of the RTP TS at terminal 130 (MS).

To manage the handover for the uplink, when the HO administrator decides to initiate handover preparation, it will notify the source ANI_AD. The source ANI_AD then sends HO_initialization information (HO_inic_d) to the destination ANI_AD. HO_inic_d consists of p_size_d and TS_tranco_d, which are the values ​​last acknowledged by the MS, along with their generation number. The first time the destination ANI_AD wants to send speech after the HO, the destination ANI_AD has to send HO_sinc_d. HO_sinc_d consists of C_TS and C_SN. If the new p_size differs from p_size_d, HO_sinc_d also contains the new value of p_size. If not, HO_sinc_d only contains generation number n of p_size_d. The MS uses the generation number to retrieve the correct p_size. This assumes that the MS kept in memory the last few p_size values, along with their generation number. The same algorithm applies to TS_tranco. HO_inic_d is sent until it is acknowledged by the MS_AD. HO_sinc_d is sent in acknowledgment mode. The handover process is illustrated in figure 2. The case shown is: the most recent change in p_size_u has been acknowledged as received so far ST2 - HOT_max.

E. Sending Messages

Each of the above information can be sent in-band or out-of-band. In in-band approach, information is sent over the speech channel stealing the least significant speech bits. In out-of-band approach,

ES 2 460 140 T3 a dedicated transient channel is configured and dismantled when an acknowledgment is received. A combination of in-band and out-of-band approaches is possible, in which out-of-band approach is attempted, but in-band approach is a fallback solution if there is no resource for a transient channel. Acknowledgments can be sent in-band, or out-of-band on its own dedicated acknowledgment channel, or out-of-band straddling the other dedicated transient channels (TIC, etc.)

1. In band

Regardless of how the circuit-like speech channel is realized, it can be modeled as a channel that can transmit B bits every T milliseconds. If S is the size of a speech frame in bits, S <B. With speech codecs in sight, Info_inic is expected to be greater than S. Therefore, an Info_inic cannot be sent in the space of a single speech plot. However, there is a factor R> = 1 such that (R-1) * S <H <R * S. Info_inic (n) can be transported on the circuit-like channel by breaking them into B-bit chunks and sending a chunk every T milliseconds. A full header will consume the space of R consecutive speech samples. FIG. 11 is a diagram illustrating an initialization for the in-band case, in accordance with an exemplary embodiment of the invention. If there is continuous vocal activity, the Info_inic sent are Info_inic (0), Info_inic (R), Info_inic (2R), etc., until an acknowledgment (n) is received. In Fig. 11, these info_inic messages are shown as info_inic 500 and info_inic 502. The header chopper acknowledges receipt of info_inic 500, but not before the HS 810 sends a second packet info_inic 502. The next packet 504 is sent from the HS 810 to the HR 822 as the 504 payload of the packet (no header). The HR 822 then regenerates the SN and TS and other header fields.

Info_inic (0) takes the place of the speech samples 0, 1, ..., (R-1), Info_inic (R) takes the place of the speech samples R, (R + 1), ..., (2R-1), and so on. If there is discontinuous vocal activity, let's say header 0 is followed by a silence interval of L * T msec, then Info_inic (0) is repeated. All other information (start_string, HO_sinc_d, HO_sinc_u, Ack) is well below S in size, so they fit in the space of a speech frame. They steal the least significant bits of voice. For simplicity, the analysis does not take into account the spread caused by channel coding, but the concept is valid with or without channel coding. The initialization process for the in-band case is shown in Figure 3.

2. Out of band

FIG. 12 is a diagram illustrating an initialization for the out-of-band case, in accordance with an exemplary embodiment of the invention. In the out-of-band approach, a separate channel is configured, with adequate bandwidth, to carry only the Info_inic simultaneously with speech, which is carried over a speech channel. The separate channel is called the Transient Initialization Channel (TIC). The system may try to allocate enough bandwidth for the TIC, in order to allow a complete header to be sent once every T msec. The TIC is designed to have a fixed timing relationship with the speech channel. Acknowledgments can be sent out-of-band, allocating a transient acknowledgment channel (TAC), or sent out-of-band, but straddling a direct transient channel. The HO_sinc_u may be sent out-of-band on a transient uplink handoff sync channel (TUHOSC). The TUHOSC is dismantled when the HO_sinc_u is acknowledged. The same applies to HO_sinc_d, which uses a transient downlink handover synchronization channel (TDHOSC).

3. Failure Cases

There may be cases where the destination ANI_AD will not have the HO_inic at the time the handover execution is finished. Reasons include excessive delay in the signaling network between the two ANI_ADs, the need to quickly execute handover, etc. In those cases, the network will send a notification to the MS, which then restarts the initialization process, as at the beginning of the call.

Four. Common Case Where P-Size and TS_tranco are Constants

The case where p_size and TS_tranco are constant is by far the most common for voice. In this case, none of the considerations caused by the possible change of p_size and TS_tranco apply. The generic scheme is simplified. The HO_init_d is not needed. HO_sinc_d and HO_sinc_u only carry the C_SN and C_TS. The Init_string carries the C_SN. It carries the C_TS only if there is a timing change between one chain and the next. The terminal (MS) does not have to keep in memory the last few values ​​of p_size and TS_tranco. In case of HO, the terminal (MS) does not have to determine whether or not to include p_size_u in HO_sinc_u.

As described above, the only information in the IP / UDP / RTP headers that is essential for basic voice are the static fields and the RTP timestamp (TS), and the RTP sequence number (SN) as well. it is very desirable. The scheme described in this document achieves transparency for these fields of

ES 2 460 140 T3 information, and provides an advantageous headend overhead compression efficiency. The continuity of all static and non-static fields is maintained throughout the handover. Bandwidth management is also simplified, because in-band as well as out-of-band approaches are possible. Since the transparency is maintained for the RTP TS and the RTP SN, it is even possible to toggle between the header hash scheme and the header compression scheme described herein, which maintains transparency for all fields. It may be necessary to switch to header compression when, for example, another medium is added to the speech.

III. Timer Based Scheme and Reference

A. Overview of the Timer and Reference Based Scheme

The reference and timer-based scheme is based on the observations that (1) the RTP timestamps, when generated at the RTP source, correlate with a linear function of the time elapsed between packets, and (2) the RTP TS are of the form TS0 + index * TS_tranco, where TS0 and TS_tranco are constants, and index is an integer (hereinafter the index will be referred to as the RTP packed TS). Therefore, in normal operation, the RTP timestamps received at the decompressor are also correlated with a continuously increasing timer, with a distortion created only by the accumulated delay jitter between the source and the decompressor. As the accumulated delay jitter includes the "network" delay jitter (delay jitter between source and compressor) and "radio" delay jitter (delay jitter between compressor and decompressor), the compressor can calculate an upper bound of the accumulated delay jitter by adding to the observed network delay jitter an upper bound of the radio delay jitter. The compressor then sends only the "k" least significant bits of the RTP packed TS as compressed RTP TS. The decompressor decompresses the RTP TS by first calculating an approximation, and then refining the approximation with the information in the RTP compressed TS to determine the exact value. The approximation is obtained by adding to the TS of the RTP of the previously decompressed header a value proportional to the time elapsed since the previously decompressed header was received. The exact value of the RTP TS is determined as the closest to the approximation, whose k least significant bits of the corresponding RTP packed TS match the RTP compressed TS. The compressor chooses a value k as the smallest allowed value that would allow the decompressor to decompress correctly, based on the upper bound of the accumulated delay jitter.

B. Case of the Voice

First, the reference and timer-based scheme will be described with respect to speech. As an example, if the time interval between consecutive speech samples is 20 msec, then the RTP timestamp of header n (generated at time n * 20 msec) = RTP timestamp of header 0 (generated at the moment 0) + TS_tranco * n, where TS_tranco is a constant that depends on the speech codec. Consequently, the RTP TSs in the headers arriving at the decompressor also follow a linear pattern as a function of time, but less closely, due to the delay jitter between the source and the decompressor. In normal operation (no drops or failures), the delay jitter is limited to meet the requirements of real-time conversational traffic.

In this scheme, the receiver uses a timer to get an approximation of the RTP TS of the current header (the one to be decompressed), then refines the approximation with the additional information received in the compressed header.

For example, suppose the following:

The Last_header is the last successfully decompressed header, where TS_last is the last TS of the RTP, and p_TS_last is the last packed TS of the RTP (at the receiver);

T is the normal time spacing between two consecutive speech samples;

TS_tranco is the RTP TS increment every T msec;

Current_Header is the current packet header to decompress, where current_TS is the current RTP TS, and current_TS_p is the current RTP packed TS;

RFH is the sequence number of a header whose acknowledgment was received by the compressor, where TS_RFH is the TS of the RTP, and p_TS_RFH is the packed TS of the RTP;

the Timer is a timer incremented every T msec, where both the compressor and the decompressor each maintain a Timer, indicated as S_timer and R_timer, respectively;

T_RFH is the value of the Timer when the RFH has been received, and T_current is the value of the same Timer when the current_Header has been received; Y

IS 2 460 140 T3

N_delay jitter (n, m) is the observed network delay jitter of header n relative to header m (header n is received after header m);

where N_delay fluctuation (n, m) is calculated by the compressor as follows:

N_delay jitter (n, m) = Timer (n, m) - (Packed TS of RTP from header n - Packed TS from RTP from header m), where Timer (n, m) is the elapsed time from header m to head n, expressed in units of T msec. Delay N_Fluctuation (n, m) can be positive or negative. N_Compressor delay jitter is the network delay jitter, quantized in units of T msec.

R_Delay jitter (n, m) is the radio delay jitter of head n with respect to head m, predicted by the compressor. Delay R_Fluctuation depends only on the characteristics of the compressor-compressor channel (CD-CC). You don't have to calculate R_delay jitter precisely, a good upper bound for R_delay jitter is sufficient. For example, an upper bound might be Max-Delay Jitter_Radius, the maximum delay jitter in DC-DC, if known.

Thus, based on the above, the accumulated delay jitter for a packet is calculated as the sum of the network and radio delay jitter:

Furthermore, the RTP TS is calculated as follows:

RTP TS = TS0 + index * TS_tranco, where TS0 <TS_tranco and index is an integer.

Thus, TS_last = TS0 + index_last * TS_tranco, and TS_current = TS0 + index_current * TS_tranco.

1. Compressor

The compressor sends the k least significant bits of p_TS_current in the compressed header.

The compressor executes the following algorithm to determine k:

Calculate Max_network_delay jitter;

Calculate J1 = Max_net_delay jitter + Max_radio_delay jitter + J, where J = 2 is a factor to compensate for the quantization error caused by the Timers in the compressor and decompressor, which can be +1 or -1; Y

Find the smallest integer k that satisfies a condition of:

(2 * J1 + 1) <2^k.

The mains delay jitter in the compressor can be calculated according to three different procedures, namely, a first procedure illustrated in Fig. 13, a second procedure illustrated in Fig. 4, and a third procedure illustrated in Fig. 15. The Second and third procedures are described below as Option 1 and Option

2, respectively. The first procedure is suitable for calculating the network delay jitter. However, the preferred methods for calculating the mains delay jitter in the compressor are the second and third procedures described as Option 1 and Option 2, respectively, below.

As illustrated in Fig. 13, according to the first method, the network delay jitter for a specific packet in the compressor is calculated using information with respect to the immediately preceding packet. Thus, for example, the network delay jitter for packet 2 (j2) is calculated using information regarding packet 1, the network delay jitter for packet 3 (j3) is calculated using information regarding packet 2 , the network delay jitter for packet 4 (j4) is calculated using information regarding packet 3 and the network delay jitter for packet 5 (j5) is calculated using information regarding packet 4.

Thus, according to Fig. 13, the network delay jitter for packet 2 is equal to the calculated delay jitter j2,

ES 2 460 140 T3 the network delay jitter for packet 3 is equal to the calculated delay jitter j3, the network delay jitter for packet 4 is equal to the calculated delay jitter j4 and the delay jitter of network for packet 5 is equal to the calculated delay jitter j5.

Option 1:

The steps used to calculate the network delay jitter for the second procedure of Option 1 are illustrated in Fig. 14. In Option 1, the network delay jitter for a specific packet is calculated using information regarding a reference pack. Thus, assuming that packet 2 is the reference packet as illustrated in Fig. 14, the j3 delay jitter of packet 3 is calculated using information relative to reference packet 2, the j4 delay jitter of packet 4 is calculated using information relative to reference packet 2, and the j5 delay jitter of packet 5 It is calculated using information with respect to the reference packet 2.

According to the second procedure of Option 1, as illustrated in Fig. 14, if it is assumed that the delay jitter j3 = 2, the delay jitter j4 = 3 and the delay jitter j5 = -1, then before for packet 5, N_delay jitter_min = 2 and N_delay jitter_max = 3, while in packet 5, N_delay jitter_min = -1 and N_delay jitter_max = 3. Thus, the maximum (Max) network delay jitter in packet 5 = N_delay jitter_max - N_delay jitter_min = 4. Consequently, the Max_network delay jitter for packet 5 is 4. The equations to calculate the delay jitter of network according to the Option 1 procedure, and a description thereof, are set forth below.

The network delay jitter of a current packet is calculated according to the Option 1 procedure as follows:

N_delay jitter (Current_Header, RFH) = (T_current - T_RFH) - (p_TS_actual p_TS_RFH);

Update N_delay jitter_max and N_delay jitter_min, where N_delay jitter_max is defined as Max {N_delay jitter (j, RFH)}, for all j headers sent from the RFH, and including the RFH. N_delay jitter_min is defined as Min {N_delay jitter (j, RFH)}, for all headers j sent from the RFH, and including the RFH; Y

Calculate Max_net_delay jitter = (N_delay jitter_max - N_delay jitter_min).

It should be noted that N_max_delay jitter and N_min_delay jitter can be positive or negative, but (N_max_delay jitter - N_min_delay jitter) is positive.

Option 2:

The steps used to calculate the network delay jitter for the third procedure of Option 2 are illustrated in Fig. 15. In Option 2, the network delay jitter in a specific packet is calculated using delay jitter calculations. between the packet of interest and each of a predetermined number of preceding packets. The predetermined number of preceding packets is defined as a window, and such a window can have any value. In the example illustrated in Fig. 15, the window has a value of 4 preceding packets. The window could be set to any other value, such as 7 packets. Furthermore, the window could, for example, be set to a value equal to the number of packets since the last reference packet.

As illustrated in Fig. 15, the network delay jitter for packet 5 is calculated using information regarding packet 1, j (5,1), packet 2, j (5,2), packet 3 , j (5,3) and package 4, j (5,4). As illustrated in Fig. 15, if the calculated network delay jitter for packet 5 relative to packet 1 respectively is j (5,1) = 2, packet 2 is j (5,2) = 3, packet 3 , is j (5,3) = 4 and for packet 4, it is j (5,4) = 7, so the max_network_delay jitter = 7. The equations to calculate the network delay jitter according to the third procedure of Option 2 and a description thereof are set forth below.

The network delay jitter of a current packet is calculated according to the Option 2 procedure as follows:

Calculate N_delay jitter (Current_head, j) = (Current_T - T_j) - (current_TS_p - p_TS_j) for all j headers sent before the current header, and belonging to a window W, where T_j is the value of the timer when it was received header j, and p_TS_j is the RTP packed TS of header j; y Calculate Max_net_delay jitter = | Max N_delay jitter (current_header, j) | for all j in window W.

IS 2 460 140 T3

In the case where feedback from the decompressor is available, window W includes headers sent from the last known header as correctly received (eg, with acknowledgment). In the case of no feedback, the W window includes the last L headers sent, where L is a parameter.

2. Decompressor

To decompress the RTP TS of the Current_Header, the receiver calculates the time elapsed since the Last_Header was received, in units of T msec. That time, the Timer (Current_Header, Last_Header), is added to p_TS_last, to give an approximation of p_TS_current. The receiver then determines the exact value of p_TS_actual by choosing the value closest to the approximation, whose k least significant bits coincide with the compressed TS of the RTP. The TS_current is then calculated as TS0 + (p_TS_current) * TS_tranco.

The Timer (Current_Header, Last_header) can be calculated as (Current_T - Last_T), where Current_T and Last_T are the values ​​of R_Timer when the Current_Head and Last_header were received, respectively.

3. Accuracy test

In order to demonstrate the correctness of the timer and reference-based scheme, the following is assumed:

TS_Aprox is the approximation of p_TS_actual, calculated by the decompressor as p_TS_ultimo + Timer (Header_current, Last_header); Y

TS_Exacto is the exact value of p_TS_actual.

Based on the above, then:

| TS_Aprox - TS_Exacto | <= Delay jitter (Current_Head, Last_Head) |;

Due to the definition of Max_mains_delay jitter in the compressor:

Delay Jitter (Current_Head, Last_Head) | <J1,

Where J1 = Max_network_delay jitter + Max_radio_delay jitter + J.

J is an added factor to compensate for the quantization error caused by the Timers in the compressor and decompressor, which can be +1 or -1. Therefore, J = 2 is sufficient.

Thus, it follows that:

| TS_Aprox - TS_Exacto | <J1

To calculate the TS_Exact without ambiguity, it is sufficient to choose k in such a way that the condition of (2 * J1 + 1) <2 is satisfied^k.

Four. Package Disorder Case Before Compressor

Packet Disorder can be detected by decreasing RTP sequence number (RTP SN). When that happens, the compressor can encode the RTP packed TS using a different scheme, for example VLE. The decompressor is notified of the different encoding by the appropriate flag bits in the compressed header.

Another option is to apply the normal Timer and Reference Scheme algorithm: Clutter is likely to result in a higher value of k.

5. Uplink

In wireless systems, for the uplink direction, the network delay jitter is zero (since both the RTP source and the compressor are located in the wireless terminal), and the radio delay jitter is normally bounded and controlled. so that it stays very small. Therefore, the expected k will be very small and constant, minimizing header size fluctuation. This is a very significant advantage for bandwidth management, since for the uplink, the terminal usually has to request increased bandwidth from the network. Also, there is no package clutter. Consequently, the timer-based scheme is extremely well suited for the uplink.

IS 2 460 140 T3

6. Downlink

For the downlink direction, the network delay jitter is not zero, but the overall delay jitter is normally small, to meet the real-time requirements. The expected k will still be small and usually constant. There may be more fluctuations in k, but bandwidth management is less contentious as the network controls the allocation of bandwidth.

7. Transfer

In cellular systems, there is an MS-to-network radio link and a network-to-MS radio link, referred to as an uplink and a downlink, respectively. When compression / decompression is applied to cellular links, there is an MS-based function, MS_AD (MS adapter), which does compression and decompression for the uplink and downlink, respectively. There is a network-based entity called ANI_AD (Access Network Infrastructure Adapter) that does decompression and compression for the uplink and downlink respectively.

The specific case of handover to consider is intra-ANI_AD handover, where there may be a disturbance caused by switching from the old ANI_AD to a new ANI_AD. The question is how to maintain the continuity of the information throughout the handover, such that, after the handover, compression / decompression in the MS_AD and the new ANI_AD continue undisturbed.

There are two alternative procedures for handover, described below:

to. First procedure

The first procedure uses the scheme of taking a snapshot of the context information exchanged between the ANI_AD and the MS_AD, with the greeting procedure, as disclosed in the request associated with Serial No. 09 / 522.497, registered on March 09 1999, the same date as the present application, for "AN EFFICIENT HANDOFF PROCEDURE FOR HEADER COMPRESSION", by K. Le. For the RTP TS, the context information contains the complete RTP TS of a reference header. Immediately after the handover, the compressors (MS_AD for the uplink and ANI_AD for the downlink) temporarily discontinue the use of the timer-based scheme and send a compressed TS of the RTP relative to the reference value. For example, the VLE encoding could be used, as disclosed in the application associated with Serial No. 09 / 522,497, filed on March 9, 1999, the same date as the present application, for "AN EFFICIENT HANDOFF PROCEDURE FOR HEADER COMPRESSION ”, by K. Le. Once an acknowledgment has been received, the compressor uses the acknowledged value as the RFH, and switches back to the timer-based scheme.

b. Second Procedure

The second procedure continues to use the timer-based scheme throughout the handover.

i. Downlink

There is no discontinuity on the receiving side, which is the MS. The role of the compressor is transferred from one ANI_AD to another. After the handover, the headers are routed on a new path through the new ANI_AD instead of the old ANI_AD.

- Compressor

The old ANI_AD transfers to the new ANI_AD a snapshot of the following information: T_RFH, p_TS_RFH, current value of S_Timer, TS0 and TS_tranco, using the hello procedure. (Snapshot values ​​will be indicated by an asterisk, eg T_RFH *). The new ANI_AD initializes its S_Timer with the current value of the Stetimer received from the old ANI_AD, and starts incrementing that timer every T msec. The initialization of the S_timer with the current value of S_timer from the old ANI_AD is a conceptual description. If there is a single S_timer shared by multiple flows, the effective S_timer is not reset. Instead, the offset between that S_timer and the value of the old ANI_AD is recorded. The displacement is taken into account in future calculations. To compress the very first header after the handover, the new ANI_AD sends the k least significant bits of p_TS_actual. The new ANI_AD determines k, the number of bits to use, as follows:

J2 = Upper bound of N_delay jitter (Current_head, RFH *) + Max_fluctuation of

ES 2 460 140 T3 radio_delay + J,

Where k is selected to satisfy a condition of (2 * J2 + 1) <2^k.

In the above, Max_radio_delay jitter is the maximum delay jitter in the segment between the new ANI_AD and the MS_AD.

An upper bound for N_delay jitter (Current_Head, RFH *) is calculated as follows:

Timer (Current_Header, RFH *) - (p_TS_actual - p_TS_RFH *) | + T_transfer, where Timer (Current_Header, RFH *) is (T_current - T_RFH *);

T_current is the value of S_Timer in the new ANI_AD when the Header_current was received;

T-RFH * is the value received from the old ANI_AD;

T_transfer is an upper bound on the time to transfer the context information from the old ANI_AD to the new ANI_AD, expressed in units of T msec; Y

J = 2.

- Decompressor

To decompress the TS from the RTP of the current_Header, the receiver calculates the time elapsed since the RFH was received, in units of T msec. That time, Timer (Current_Header, RFH), is added to p_TS_RFH, to give an approximation of the current p_TS_RFH. The receiver then determines the exact value of the p_TS_actual choosing the value closest to the approximation, whose k least significant bits coincide with the compressed TS of the RTP. The TS_current is then calculated as TS0 + (p_TS_current) * TS_tranco.

The time elapsed since the RFH was received can be calculated as (T_current - T_RFH).

- Failure case

When the context information cannot be transferred to the new ANI_AD in a timely manner, the new ANI_AD will send the full RTP TS until an acknowledgment is received.

ii. Uplink

The role of the decompressor is transferred from one ANI_AD to another. The compressor remains anchored to the MS.

- Decompressor

The old ANI_AD transfers to the new ANI_AD a snapshot of the following information: T_RFH *, p_TS_RFH *, the current value of R_Timer *, TS0 and TS_tranco, using the hello procedure. The new ANI_AD initializes its R_Timer with the current value of the R_Timer received from the old ANI_AD² and it starts incrementing that timer every T msec. The initialization of the R_timer with the current value of the R_timer from the old ANI_AD is only a conceptual description. If there is a single R_timer shared by multiple flows, the effective R_timer is not reset. Instead, the offset between that R_timer and the value of the old ANI_AD is recorded. This displacement is taken into account in future calculations. To decompress the very first header after the handover, the new ANI_AD calculates Timer (Actual_ Header, RFH) and adds it to p_TS_RFH *, to give an approximation of the current p_TS_. The receiver then determines the exact value of p_TS_actual choosing the value closest to the approximation, whose k least significant bits coincide with the compressed TS of the RTP. The TS_current is then calculated as TS0 + (p_TS_current) * TS_tranco.

The Timer (Current_Header, RFH) can be estimated as (T_current - T_RFH *). T_current is the value of R_Timer when the Header_current was received.

- Compressor

The MS_AD sends the k least significant bits of the current p_TS_. Determine k, the number of bits to use, as follows:

Calculate J2 = upper bound of N_delay jitter (Current_Header, RFH *) + Max_delay jitter_radio + J,

Where k is selected to satisfy a condition of (2 * J2 + 1) <2^k.

IS 2 460 140 T3

Here Max_radio_delay jitter is the maximum delay jitter in the segment between the new ANI_AD and the MS_AD.

The upper bound of N_delay jitter (Current_Head, RFH *) is calculated as ¡Timer (Current_Head, RFH *) - (p_TS_current_header - p_TS_RFH *) ¡+ T_transfer, where Timer (Current_Header, RFH *) is (T_Current - T_RF *) ;

T_actual is the value of S_Timer in the new ANI_AD when the current header was received;

T_RFH * is the value received from the old ANI_AD;

T_transfer is an upper bound on the time to transfer the context information from the old ANI_AD to the new ANI_AD, expressed in units of T msec; Y

J = 2

- Failure Case

When the context information cannot be transferred to the new ANI_AD in a timely manner, the new ANI_AD will notify the MS_AD, which sends the full RTP TS until an acknowledgment is received.

8. Scheme Performance

Due to real-time conversational requirements, the cumulative delay jitter in normal operation is expected to be only a few times T msec at most. Therefore, a value of k around 4 or 5 is sufficient, since a delay jitter of up to 16 to 32 speech samples can be corrected.

The advantages of this scheme are as follows:

The size of the compressed header is constant and small. The compressed header typically includes a message type, indicating the message type (k1 bits), a bit mask indicating which fields are changing, and a field containing the k least significant bits of the current_index (k bits). Assuming a 4-bit MSTI bit mask is used, and k1 = 4, the compressed header size when only the RTP TS changes (this case is by far the most frequent) is 1.5 octets . Also, the size does not change as a function of the length of the silence interval.

No synchronization is required between the timer process and the decompressor process.

There is robustness against errors, since the partial information of the RTP TS in the compressed header is self-contained and only needs to be combined with the receiver timer to produce the full value of the RTP TS. Loss or corruption of a header will not invalidate subsequent compressed headers.

The compressor needs to keep little memory information:

T_RFH, p_TS_RFH, N_delay jitter_max, N_delay jitter_min, TS0 and TS_tranco in Option 1, and {Tj, p-TS-j}, for all j in window W, TS0 and TS_tranco in Option 2.

C. Delay Jitter Reduction

Due to real-time conversational requirements, the various delay fluctuations discussed above can reasonably be expected to be on the order of a few values ​​of T msec in normal operation. However, cases where the delay jitter is greater, and therefore requires a greater k, cannot be ruled out. For example, there may be abnormal conditions in the path from the source of the RTP to the receiver (failures, etc.), during which the delay fluctuations become excessive. Also, there may be cases where a constant value of k is desired, or is desirable. To deal with these cases, a delay jitter reduction function can be implemented as a first order interface to the compressor, to filter out packets with excessive delay jitter (ie, delay jitter that exceeds some threshold value).

In the static case (no handover), the lag jitter is calculated as J1 and compared to a static threshold as follows:

J1 = (n_max_delay jitter - N_min_delay jitter) + Max_radio_delay jitter + J.

IS 2 460 140 T3

In the case of handover, the delay jitter is calculated as J2 and compared to a handover threshold as follows:

J2 = Timer (Current_Header, RFH *) - (p_TS_actual - p_TS_RFH *) | + T_transfer + Max_radio_delay jitter + J.

The main difference from the static case without handover is the sum of T_transfer. In practice, to be able to execute the handoff in 100 msec, T_transfer must be bounded by around 100 msec, so T_transfer = around 5 or 6 in units of T msec (T = 20 msec). A value of k = 5 is sufficient.

The static and pass-through thresholds may or may not be the same.

D. Video Case

In the case of an RTP video source, it is not necessarily true that there is a constant time spacing between the packets, and furthermore, the RTP TS does not necessarily increase in a constant stride from one packet to the next. However, the RTP TS and the time spacing between the packets are discrete. Thus, as follows:

RTP timestamp of packet m = RTP timestamp of packet 0 (generated at time 0) + TS_tranco * [index + setting (m)], where TS_tranco is a constant that depends on the codec, and setting (m) is an integer that depends on m and that reflects the differences with respect to a linear behavior, as in the voice; and the time spacing between two consecutive packets is an integer multiple of T msec.

In the following, that behavior at the RTP source is called fitted linear behavior. Using the same notation as for voice, TS_last = TS0 + TS_tranco * [index_last + fit (index_last)], and TS_current = TS0 + TS_tranco * [index_current) + fit (index_current]. The Fit parameter can be positive or negative. Thus, the main difference, compared to voice, is the additional term Adjustment.

The RTP TSs at the head-ends arriving at the decompressor also follow a linear pattern fitted as a function of time, but less closely, due to the delay jitter between the source and the decompressor. In normal operation (no drops or failures), the delay jitter is constrained, to meet the requirements of real-time conversational traffic.

As before, it is assumed that the RTP packed TS of current_header = current_index + adjustment (current_index). The same notation will be used with respect to p_TS_actual, for example.

Compressor

The compressor sends the k least significant bits of p_TS_current in the compressed header. The algorithm for determining k is the same as for speech.

Decompressor

The algorithm to use is the same as for voice.

1. Transfer

The two alternative handover procedures, described for voice, also apply to video.

2. K value

For the voice, it was shown that k = 4 or 5 is sufficient (2^k = 16 or 32). For video, a higher value of k is required, due to the Adjustment. Since the video is structured at 30 frames per second, Set | <30. Therefore, k = 7 or 8 bits should be sufficient in normal operation.

Some examples of the present invention are specifically illustrated and / or described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the foregoing disclosures, and within the scope of the appended claims, without departing from the intended scope of the invention.

IS 2 460 140 T3

While the present invention has been described in detail and illustratively in the accompanying drawings, it is not limited to such details, as many changes and modifications, recognizable to those of ordinary skill in the technology, can be made to the invention without departing from the scope of the invention. the same.

More aspects are described below to facilitate the understanding of the invention.

In a first further aspect, a method of transmission in a network between a source and a receiver of a current header field of a current packet using a timer-based compression technique is described the method may comprise the steps of providing from a compressor to a decompressor of an initial value of a header field; calculating in the compressor a compressed header field of the current packet based on the current header field of the current packet and the delay jitter, in which said calculation step may comprise the steps of: calculate a delay jitter effect that the network can have between a source and said decompressor in transmitting packets, and calculate the compressed header field as a part of a field value, said part can be a function of the jitter of time delay; receiving the compressed header field of the current packet at the decompressor; estimate the header field of the current packet based on time elapsed in the decompressor between receiving the compressed header field of the current packet and receiving a header field from a previous packet that was decompressed, and a decompressed field value from the previous packet, and correcting the estimated current header field, based on the compressed header field received at the decompressor. Wherein said calculating a delay jitter effect may comprise the steps of: calculating a mains delay jitter effect before the compressor, and calculating a mains delay jitter effect between the compressor and the decompressor. Also, said network delay jitter effect between compressor and decompressor can be set to a higher threshold value for delay jitter. Furthermore, said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information relative to a reference packet. Furthermore, said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information regarding said current packet and each of a predetermined number of preceding packets. Wherein said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information regarding said current packet and each preceding packet, up to a reference packet. Furthermore, said computing in the compressor the compressed header field of the current packet may comprise: computing the compressed header field of the current packet as the k least significant bits of the field value, where k is an integer. Furthermore, said header field may comprise a timestamp. Furthermore, said header field may comprise an RTP timestamp. Furthermore, said calculating in the compressor the compressed header field of the current packet may comprise converting the value of the field into another value, which is called the packed value, which can be represented with a smaller number of bits, and calculating the compressed header field of the current packet as the k least significant bits of the packed value, where k can be an integer.

In yet another aspect, a method of decompressing a current header field of a current transmission packet in a network from a compressor to a decompressor is described, the method may comprise the steps of: receive a compressed header field of a current packet in the decompressor, where said compressed header field can be calculated in the compressor as a part of a field value that can be calculated as an effect of the delay jitter that the network has between a source and the decompressor has over the transmission of packets; calculating an approximation of the packet stream header field in the decompressor based on the time elapsed since the arrival of a previous compressed header field in the decompressor and a decompressed field value from the previous packet; calculate a header field correction amount for the current packet in the decompressor that could be based on the compressed header field of the current packet, and decompress the compressed header field of the current packet in the decompressor by adjusting the field approximation header of the current packet an amount based on the header field correction amount. Furthermore, such a delay jitter effect that the network between the source and the decompressor could have on the packet transmission could be calculated by calculating a network delay jitter effect between the compressor and calculating a delay jitter effect. of the network between the compressor and the decompressor. Also, said network delay jitter effect between compressor and decompressor can be set to a higher threshold value for delay jitter. Wherein said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information with respect to a reference packet. Furthermore, said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information regarding said current packet and each of a predetermined number of preceding packets. Said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information regarding said current packet and each preceding packet, up to a reference packet. Also, the header field

The compressed ES 2 460 140 T3 can be calculated as the smallest k significant bits of the field value, where k can be an integer. Furthermore, the compressed header field can be calculated as the k least significant bits of a packed value, where k can be an integer, and where the decompressor can calculate an approximation of the packed value based on the time elapsed since the arrival of a previous packet and a value packed in the decompressor from the previous packet.

In yet another aspect, a method is described for performing a handover between first and second network entities in a system, the first and second network entities can interconnect a mobile decompressor to a source terminal when the mobile decompressor is in the first and second zones, respectively, The method may comprise receiving an initial value of a header field in the first network entity and in the mobile decompressor from a source terminal, the first interface network entity between the mobile decompressor, located in a first zone, to a source terminal; receiving a header field of a first packet that is addressed to the mobile decompressor at the first network entity from the source terminal; compressing the header field of the first packet in the first network entity and sending a first compressed header field of the first packet to the mobile decompressor, said first compressed header field can be calculated as a part of a field value that can be calculated as a first delay jitter effect that the network could have between the source terminal and the mobile decompressor in the transmission of packets; receiving and decompressing the first compressed header field of the first packet in the mobile decompressor based on the time elapsed since the arrival of a previous packet and the decompressed field value of the previous packet; the mobile decompressor can move from the first zone to the second zone; transmit the initialization information to the second network entity to initialize the second network entity for the reception and compression, in the second network entity, of a header field of a second packet from the originating terminal that they can use for the mobile decompressor and send a second compressed header field of the second packet to the mobile decompressor, said second compressed header field can be calculated as a part of a field value that is calculated as a second effect of the delay jitter that the network could have between the source terminal and the mobile decompressor in the transmission of packets and the time to transmit the initialization information to the second network entity, and receiving and decompressing the second compressed header field of the second packet in the mobile decompressor based on the time elapsed since the arrival of a previous packet and the decompressed field value of the previous packet. In addition, each of said first and second network delay jitter effect between source terminal and decompressor could have on packet transmission could be calculated by calculating a network delay jitter effect before compressor, and calculate a mains delay fluctuation effect between compressor and decompressor. Also, said network delay jitter effect between compressor and decompressor can be set to a higher threshold value for delay jitter. Furthermore, said first packet may be a packet immediately prior to handover and said second packet may be a packet immediately after handover. Furthermore, said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information relative to a reference packet. Furthermore, said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information regarding said current packet and each of a predetermined number of preceding packets. Furthermore, said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information regarding said current packet and each preceding packet, up to a reference packet. In addition, said header field has a time stamp. Also, the compressed header field can be computed as the k least significant bits of the field value, where k can be an integer. Furthermore, the compressed header field can be calculated as the k least significant bits of a packed value, where k can be an integer, and where the decompressor can calculate an approximation of the packed value based on the time elapsed since the arrival of a previous package and a packaged value of the decompressor from the previous package.

In another additional aspect, a procedure is described to perform a handover between first and second network entities, the first and second network entities can interconnect a mobile compressor to a receiving terminal when the mobile compressor is in the first and second zones, respectively. , the method may comprise receiving an initial value of a header field in a first network entity from a mobile compressor; receive in the first network entity a first compressed header field of a first packet received from the mobile compressor, said first compressed header field may have been computed in the mobile compressor as a part of a field value that is computed as a first effect of the delay jitter that the network could have between a source and a decompressor in the transmission of packets; decompressing, in the first network entity, the first compressed header field of the first packet based on the time elapsed since the arrival of a previous packet and the decompressed field value of the previous packet; the mobile compressor can move from the first zone to the second zone, send initialization information to the second network entity to initialize the second network entity for compression; receive, in the second network entity, a second compressed header field of a second packet received from the mobile compressor, said second compressed header field may have been calculated in the mobile compressor as a part of a field value that is calculated as a second effect of the

ES 2 460 140 T3 delay fluctuation that the network could have between the source and the decompressor in the transmission of packets and the time to transmit the initialization information to the second network entity, and decompress, in the second network entity, the second compressed header field of the second packet based on the time elapsed since the arrival of a previous packet and the decompressed field value of the previous packet. In addition, said first and second network delay jitter effect between source and decompressor may have on packet transmission can be calculated by calculating a network delay jitter effect before the mobile compressor, and calculate an effect delay fluctuation of the network between the compressor and decompressor. Also, said network delay jitter effect between compressor and decompressor can be set to a higher threshold value for delay jitter. Furthermore, said first packet may be a packet immediately prior to handover and said second packet may be a packet immediately after handover. Furthermore, said calculating a delay jitter effect of the network before the mobile compressor may comprise calculating the delay jitter effect of a current packet using information with respect to a reference packet. Furthermore, said calculating a delay jitter effect of the network before the mobile compressor may comprise calculating the delay jitter effect of a current packet using information regarding said current packet and each of a predetermined number of preceding packets. Furthermore, said calculating a delay jitter effect of the network before the mobile compressor may comprise calculating the delay jitter effect of a current packet using information regarding said current packet and each preceding packet, up to a reference packet. Furthermore, said header field may comprise a timestamp. Furthermore, the compressed header field can be calculated as the k least significant bits of a packed value, where k can be an integer, and where the decompressor can calculate an approximation of the packed value based on the time elapsed since the arrival of a previous package and a decompressor value of the previous full package. Also, the compressed header field can be computed as the k least significant bits of the field value, where k can be an integer.

In yet another aspect, a communication system is described, where the system can comprise a source of providing a plurality of packets, each packet can include a header field, the source can be coupled to a network; a receiver that may include a decompressor; a network entity that may be coupled to the network and to the receiver by a network between the network entity and the receiver, the network entity may include a compressor to perform header field compression for at least some of the sent packets from the source and directed to the receiver, the network entity may include a delay jitter reduction function to calculate the delay jitter in packets directed to the receiving terminal and discarding packets that may have a delay jitter that is greater than a predetermined value, wherein the Delay jitter can be calculated as a total of an amount of the network-caused delay jitter between the source and the decompressor that could be included in the receiver. Furthermore, said delay jitter can be calculated by calculating a network delay jitter effect before the compressor, and calculating a network delay jitter effect between the compressor and the decompressor. Also, said network delay jitter effect between compressor and decompressor can be set to a higher threshold value for delay jitter. Furthermore, said network delay jitter before the compressor can be calculated by calculating the delay jitter effect of a current packet using information with respect to a reference packet. Furthermore, said calculating a delay jitter effect of the network before the compressor may comprise calculating the delay jitter effect of a current packet using information regarding said current packet and each of a predetermined number of preceding packets. Furthermore, said calculating a delay jitter effect of the network before the compressor may comprise calculating a delay jitter effect of a current packet using information regarding said current packet and each of the previous packets of up to a reference packet. . Also, the compressed header field can be calculated as the k least significant bits of a filled value, where k can be an integer, and in which the decompressor can calculate an approximation of the packed value based on the time elapsed since the arrival of a previous package and a packaged value of the decompressor from the previous package.