A Technique for Compressing a Header Field in a Data Packet
Abstract
A method of transmitting in a network, between a source and a receiver, a current header field comprising a time stamp of a current packet, using a timer-based compression technique, comprising: providing, from a compressor to a decompressor , an initial time stamp value of a header field; calculate in the compressor a compressed header field of the current package, based on the current header field of the current package and the delay fluctuation, wherein said calculation stage comprises the steps of: calculate a delay fluctuation effect that the network, between an origin and said decompressor, has on packet transmission, and calculate the compressed header field as a portion of a time stamp value, said portion being a function of the fluctuation of delay; receive the compressed header field of the current package in the decompressor; estimate the header field of the current package on the basis of the time spent in the decompressor between the reception of the compressed header field of the current package and the reception of a header field of a previous package that was decompressed, and a decompressed stamp value temporary of the previous package; and correct the estimated current header field based on the compressed header field received in the decompressor.

Term
Term ended
Projected expiry passed 9 March 2021, 5.5 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
9 claims: 1 independent, 8 dependent
- 1ES 2 339 742 T3 REIVINDICACIONES 1. Un procedimiento de transmitir en una red, entre un origen y un receptor, un campo de cabecera actual que comprende un sello temporal de un paquete actual, utilizando una técnica de compresión basada en temporizador, que comprende:proporcionar, desde un compresor a un descompresor, un valor inicial de sello temporal de un campo de cabecera;calcular en el compresor un campo de cabecera comprimido del paquete actual, sobre la base del campo de cabecera actual del paquete actual y de la fluctuación de retardo, en donde dicha etapa de cálculo comprende las etapas de: calcular un efecto de fluctuación de retardo que la red, entre un origen y dicho descompresor, tiene sobre la transmisión de paquetes, y calcular el campo de cabecera comprimido como una porción de un valor del sello temporal, siendo dicha porción una función de la fluctuación de retardo;recibir el campo de cabecera comprimido del paquete actual en el descompresor;estimar el campo de cabecera del paquete actual sobre la base del tiempo transcurrido en el descompresor entre la recepción del campo de cabecera comprimido del paquete actual y la recepción de un campo de cabecera de un paquete anterior que fue descomprimido, y un valor descomprimido de sello temporal del paquete anterior;y corregir el campo estimado de cabecera actual sobre la base del campo de cabecera comprimido recibido en el descompresor.
- 2Un procedimiento según la reivindicación 1, en el cual dicho cálculo de un efecto de fluctuación de retardo comprende las etapas de:calcular un efecto de fluctuación de retardo de la red antes del compresor;y calcular un efecto de fluctuación de retardo de la red entre el compresor y el descompresor.
- 3Un procedimiento según la reivindicación 2, en el cual dicho efecto de fluctuación de retardo de la red entre el compresor y el descompresor se fija en un valor de cota superior para la fluctuación de retardo.
- 4Un procedimiento según la reivindicación 2, en el cual dicho cálculo de un efecto de fluctuación de retardo de la red antes del compresor comprende:calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a un paquete de referencia.
- 5Un procedimiento según la reivindicación 2, en el cual dicho cálculo de un efecto de fluctuación de retardo de la red antes del compresor comprende:calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y a cada uno entre un número predeterminado de paquetes precedentes.
- 6Un procedimiento según la reivindicación 2, en el cual dicho cálculo de un efecto de fluctuación de retardo de la red antes del compresor comprende:calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y a cada paquete precedente, hasta un paquete de referencia.
- 7Un procedimiento según la reivindicación 1, en el cual dicho cálculo en el compresor del campo de cabecera comprimido del paquete actual comprende:calcular el campo de cabecera comprimido del paquete actual como los k bits menos significativos del valor del sello temporal, donde k es un número entero.
- 8Un procedimiento de la reivindicación 1, en el cual dicho campo de cabecera comprende un sello temporal del RTP.
- 9Un procedimiento según la reivindicación 1, en el cual dicho cálculo en el compresor del campo de cabecera comprimido del paquete actual comprende:convertir el valor del sello temporal en otro valor, denominado valor empaquetado, que requiere menos bits para ser representado;y calcular el campo de cabecera comprimido del paquete actual como los k bits menos significativos del valor empaquetado, donde k es un número entero.
Independent claims9
344 paragraphs in 17 sections, as filed
ES 2 339 742 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 combined IP / UDP / RTP header size 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. g., such as cellular networks) where spectral efficiency is a primary concern. Consequently, there is a need for suitable IP / UDP / RTP header compression mechanisms. A current header compression scheme is described in 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. Such a compression algorithm is described, for example, in the reference "Evaluation of the CasnerJacobson Algorithm for Compressing the RTP / UDP / IP Headers", G. Mamais.
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
The present invention relates to a process as defined by the appended claims.
According to an example 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 value of the timestamp. 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 delay jitter is an accumulation of network delay jitter, which represents the effect that the network between the source and the compressor has on packet transmission, and of radio delay jitter, which represents the effect that the network between compressor and decompressor has over packet transmission. It should be noted that the term "network" as used herein is intended as a broad term, so as not to exclude, for example,
ES 2 339 742 T3 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 at the head 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 source of the RTP (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 in the header splitter, the packets can be transmitted with a time spacing according to the RTP timestamp (TS) in the header. Therefore, in this example, the timestamp is not explicitly provided in the RTP packet (not even a compressed timestamp). Instead, the timing information is provided implicitly to the headend regenerator, based on an essentially constant bit rate channel, between the headend crusher and the regenerator. The essentially constant bit rate channel can be provided in a number of different ways.
In this second example, 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, 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:
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 according to an exemplary embodiment of the present invention;
ES 2 339 742 T3
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 header compression and decompression operation in accordance with one embodiment of the invention;
FIG. 6 is a diagram illustrating exemplary header 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 the 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 mode 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 may 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 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 ANI_AD 112 and the ANI_AD 114, each of which preferably includes a timer. Each ANI_AD performs compression (before downlink transmission) and decompression (after transmission).
ES 2 339 742 T3 transmission on the uplink) 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 before transmission to IP network 108. Therefore, each ANI_AD can be considered a compressor / decompressor 115. Each ANI_AD can maintain interfaces between the 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 technique decompression based on timer. The ANI_AD 112 also includes a Delay Jitter Reduction (JRF) function 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 ANI120, 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. The 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 operating over low-speed or bandwidth-limited 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 seal
ES 2 339 742 T3 temporary will switch between packet and packet. 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 RTP compressed 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 will be briefly described, according to an example of the invention. 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. The terminal adapter 136 decompresses the compressed timestamp 414 by first calculating an estimate or approximation of the timestamp based on the current value of the timer 134. The timestamp approximation is then refined or corrected based on the compressed timestamp 414 provided at the head 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).
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 the reception of a compressed header received by RF link 140) of time stamps.
ES 2 339 742 T3
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 spacing 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 an example 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 time elapsed at the RTP receiver between the receipt of 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's timer can be reset at the beginning of each session. Resetting or clearing a receiver timer at the beginning of a session (ie upon receipt of the initialization header) would require a 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 the subsequent RTP packet headers: The term_AD 136 (decompressor) uses the value of TS0 to decompress the value of the compressed timestamp (p. (e.g., to regenerate 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). But nevertheless,
ES 2 339 742 T3 In some embodiments, it may be unnecessary to actually perform a division operation. Other techniques can be used to properly generate current m 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<sup>k</sup>), such that: (Eq. 1) the k least significant bits of (d + last_m + timer_diff) = compressed timestamp 414 (for the 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 m _current is shown in parentheses as (d + m_last + diff_timer). 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 the receipt of the current header and the previous header (which was correctly decompressed), such as: stamp approximate current time = 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_current is calculated, the current RTP packet (including its regenerated or decompressed timestamp, TS_current) is provided to the 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 read the timer from the receiver, or reset it with zero) because the timer of
ES 2 339 742 T3 free run 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's 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 amount by which the timestamp is incremented 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, m_current 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.
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 param_current value 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. Thus, 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, the timing between
ES 2 339 742 T3 the source and receiver of RTP is needed 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 (e.g. (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 case an error is detected (p. (e.g., one or more packets dropped or lost).
In normal operation, the discrepancy between the approximation and the exact value of m_current 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 value of the timer is read, which indicates the value of timer_diff 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 ).
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<sup>k</sup>, 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 the 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.
ES 2 339 742 T3
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 indicating 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.
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<sup>k</sup>, 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 for 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.
ES 2 339 742 T3
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 handoff-related problem is expected for the downlink if condition 1 (noted above) is satisfied.
2. Uplink
In this uplink description, the terminal's 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 may have a phase difference that is at most T msec. Let Header_actual 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 current TS_ as long as the following condition is satisfied:
[Condition 3] (Uplink transient integral delay jitter + 2 + 1) <2<sup>k</sup>, 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. The uplink transient delay jitter is defined as = total delay of Header_current - full delay on 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 - full delay on the old path + cumulative delay jitter for Current_Header + 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 example, 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 example 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<sup>k</sup>, <sup>[Condition 2]</sup> (Downlink transient integral delay jitter + 2) <2<sup>k</sup>, <sup>[Condition 3]</sup> (Uplink transient integral delay jitter + 2 + 1) <2<sup>k</sup>.
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, abnormal conditions may exist in the path from the RTP source to the receiver (failures, etc.) or
ES 2 339 742 T3 other situations, in which the delay fluctuations become excessive (where the correct timestamp cannot be generated based on the compressed timestamp and the local receiver timer). To deal with these cases, a jitter reduction function (JRF) 115 (Fig. 1) can be provided as a first order interface to the compressor, to filter (or discard) packets with excessive delay jitter (eg. e.g., where any of the above conditions 1, 2, or 3 are not satisfied).
To filter or identify excessive MIJ packets, the Jitter Reduction Function (JRF) calculates the Jitter Jitter for each packet received by the network 108. If the measured Jitter of the packet is greater than 2<sup>k</sup> - 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<sup>k</sup> - 2. If the delay jitter is greater than 2<sup>k</sup> - 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). In addition, 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<sup>k</sup> - 2, 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, which causes the receiver to drop 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 example 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 on the basis of 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 the 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. The 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.
ES 2 339 742 T3
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 header stack 802 and header stack 830 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 over 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 on 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. eg 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).
ES 2 339 742 T3
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 initialization), based on 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 only to 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. (e.g., incrementing the TS counter in TS_tranco every T msec and incrementing the counter
ES 2 339 742 T3 of SN at 1 for each 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) “New burst” event: Transitory change in the difference in TS 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
c) “Stride change” event: Change in TS_tranco (caused, for example, by a change in payload PT type).
We define a header chain 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. eg, 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 forward 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 (that is, 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, HS 810 may require HR 822 to acknowledge (with ack) the updated chain information (start_string) before 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 headerless frames, 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). Yes
ES 2 339 742 T3 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 previously received packet; 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.
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, next, another String_Init containing p_size_2, with generation number 4. The receipt of an acknowledgment after the second String_Init 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 only “New burst”, Init_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 difference value 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).
ES 2 339 742 T3
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 in accordance with an exemplary embodiment of the present 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 that terminal 130 wants to resume sending speech on the destination system after HO. At ST4, the 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 role of the HS 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. 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.
ES 2 339 742 T3
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 the out-of-band approach, 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 payload 504 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 speech samples 0, 1, ..., (R-1), Info_inic (R) takes the place of 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 can try to allocate enough bandwidth for the TIC, in order to allow to send a complete header 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 can 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 required. 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 is 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 information fields, and provides an advantageous compression efficiency of the headend overhead. The continuity of all
ES 2 339 742 T3 static and non-static fields are maintained throughout the handover. Bandwidth management is also simplified, because in-band as well as out-of-band approaches are possible. As transparency is maintained for RTP TS and RTP Sn, it is even possible to toggle between the header hashing 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) 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 to 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 lag 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 in 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
ES 2 339 742 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) - (RTP packed TS of header n RTP packed TS of header m), where Timer (n, m) is the elapsed time from header m up to header 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 on 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<sup>k</sup>.
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.
ES 2 339 742 T3
Thus, according to Fig. 13, the network delay jitter for packet 2 is equal to the calculated delay jitter j2, the network delay jitter for packet 3 is equal to the calculated delay jitter j3, the jitter The network delay jitter for packet 4 is equal to the calculated delay jitter j4 and the network delay jitter 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 delay jitter j3 = 2, delay jitter j4 = 3 and 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 with respect to packet 1 respectively is j (5,1) = -2, to packet 2, is j (5,2) = 3, to packet 3, is j (5,3) = 4 and to packet 4, it is j (5,4) = 7, then the max_network_delay jitter = 7. The equations to calculate the network delay jitter according to the third procedure of the 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 fluctuation (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_head, j) | for all j in window W.
ES 2 339 742 T3
In the case where feedback is available from the decompressor, 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_Head, Last_Head), 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. Proof of correction
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_lastimo + 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<sup>k</sup>.
Four. Case of Package Disorder 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 distinct 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 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.
ES 2 339 742 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 revealed 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 S-timer received from the old ANI_AD, and starts incrementing that timer every T msec. Initializing 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_delay jitter_radio + J,
Where k is selected to satisfy a condition of (2 * J2 +1) <2<sup>k</sup>.
In the above, Max_radio_delay jitter is the maximum delay jitter in the segment between the new ANI_AD and the MS_AD.
ES 2 339 742 T3
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 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 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 TS of the RTP 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<sup>2</sup> 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 (Current_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 current_TS is then calculated as TS0 + (current_TS_p) * current_TS.
The Timer (Current_Head, 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<sup>k</sup>.
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_RFH *);
ES 2 339 742 T3
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 Features
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 delay 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.
In the handover case, 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.
ES 2 339 742 T3
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 in headers 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 limited 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<sup>k</sup> = 16 or 32). For video, a higher value of k is required, due to the Adjustment. Since the video is structured in 30 frames per second, | Adjust | <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.
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, as defined by the appended claims.
Contents17
12 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12
49 members in 16 offices
Priority claims4
| Document | Office | Kind | Date |
|---|---|---|---|
| 52236300 | United States of America | A | |
| 52236300 | United States of America | A | |
| 52236301916516 | – | – | – |
| US20000522363 | – | – | – |
Members49
| Document | Office | Kind | |
|---|---|---|---|
| CA2402438A1 | Canada | A1 | |
| WO0167709A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU4353301A | Australia | A | |
| WO0167709A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1262052A2 | European Patent Office (EPO) | A2 | |
| KR20030001376A | Republic of Korea | A | |
| CN1419771A | China | A | |
| BR0109097A | Brazil | A | |
| JP2003529247A | Japan | A | |
| US6680955B1 | United States of America | B1 | |
| RU2002126997A | Russian Federation | A | |
| MXPA02008806A | Mexico | A | |
| CN1185844C | China | C | |
| CN1617540A | China | A | |
| AU2001243533B2 | Australia | B2 | |
| KR100502313B1 | Republic of Korea | B1 | |
| RU2278478C2 | Russian Federation | C2 | |
| CA2402438C | Canada | C | |
| JP2008035543A | Japan | A | |
| JP4159287B2 | Japan | B2 | |
| EP1262052B1 | European Patent Office (EPO) | B1 | |
| AT460038T | Austria | T | |
| ATE460038T1 | Austria | T1 | |
| EP2169906A2 | European Patent Office (EPO) | A2 | |
| EP2169907A2 | European Patent Office (EPO) | A2 | |
| EP2169996A2 | European Patent Office (EPO) | A2 | |
| DE60141453D1 | Germany | D1 | |
| ES2339742T3This record | Spain | T3 | |
| CN1617540B | China | B | |
| JP4612028B2 | Japan | B2 | |
| EP2169907A3 | European Patent Office (EPO) | A3 | |
| EP2169996A3 | European Patent Office (EPO) | A3 | |
| EP2169906A3 | European Patent Office (EPO) | A3 | |
| EP2169907B1 | European Patent Office (EPO) | B1 | |
| AT543320T | Austria | T | |
| ATE543320T1 | Austria | T1 | |
| EP2169996B1 | European Patent Office (EPO) | B1 | |
| AT547885T | Austria | T | |
| ATE547885T1 | Austria | T1 | |
| EP2490398A1 | European Patent Office (EPO) | A1 | |
| EP2169906B1 | European Patent Office (EPO) | B1 | |
| PT2169906E | Portugal | E | |
| DK2169906T3 | Denmark | T3 | |
| ES2399020T3 | Spain | T3 | |
| EP2490398B1 | European Patent Office (EPO) | B1 | |
| PT2490398E | Portugal | E | |
| DK2490398T3 | Denmark | T3 | |
| ES2460140T3 | Spain | T3 | |
| BRPI0109097B1 | Brazil | B1 |
Numbers
- Publication, DOCDB
- 2339742
- Publication, EPODOC
- ES2339742T
- Application
- 1916516
- Application, DOCDB
- 01916516
- Application, EPODOC
- ES20010916516T
Titles2
- Spanish
- UNA TECNICA PARA COMPRIMIR UN CAMPO DE CABECERA EN UN PAQUETE DE DATOS.
- English
- A TECHNIQUE FOR COMPRESSING A FIELD OF HEAD IN A DATA PACKAGE.
Classification
- CPC, 8
- H04L65/80
- H04L69/04
- H04L69/22
- H04L65/65
- H04L65/70
- H04L47/43
- H04L9/40
- H04L65/1101
- IPC, 7
- H03M7 30
- H04L29 06
- H04L12 801
- H04L12 841
- H04W28 06
- H04W36 00
- H04W56 00