A technique for compressing a header field in a data packet
Abstract
This record has no abstract on file.
Term
Term ended
Projected expiry passed 9 March 2021, 5.5 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
15 claims: 2 independent, 13 dependent
- 1REIVINDICAÇÕES 1. Método de comunicação compreendendo:proporcionar numa fonte (102) uma pluralidade de pacotes, cada pacote incluindo um campo de cabeçalho, a fonte estando acoplada a uma rede;efectuar, por um compressor incluído na entidade de rede que está acoplada à rede e a um receptor (130) de cabeçalho de campo, compressão para, pelo menos, alguns dos pacotes enviados a partir da (102) e dirigidos para o receptor (130) o qual inclui um descompressor (137);calcular, na entidade de rede, o desvio de temporização nos pacotes dirigidos para o receptor (130), o referido método sendo ainda caracterizado por descartar pacotes tendo um desvio de temporização que é maior do que um número predeterminado, em que o desvio de temporização é calculado como um total do valor de desvio de temporização causado pela rede entre a fonte (102) e o descompressor (137) incluído no receptor (130) .
- 2Método de acordo com a reivindicação 1, em que o referido desvio de temporização é calculado, calculando um efeito de desvio de temporização da rede antes do compressor e calculando um efeito de desvio de temporização entre o compressor e o descompressor (137) .
- 3Método de acordo com a reivindicação 1, em que o referido efeito de desvio de temporização da rede entre o compressor e o descompressor (137), é definido para um valor de limite superior para desvio de temporização.
- 4Método de acordo com a reivindicação 2, em que o referido desvio de temporização da rede antes do compressor é calculado, calculando o efeito de desvio de temporização de um pacote actual utilizando informação relacionada com um pacote de referência.
- 5Método de acordo com a reivindicação 2, em que o referido cálculo de um efeito de desvio de temporização da rede antes do compressor compreende:calcular o efeito de desvio de temporização de um pacote actual utilizando informação relacionada com o referido pacote actual e cada um de um predeterminado número de pacotes anteriores.
- 6Método de acordo com a reivindicação 2, em que o referido cálculo de um efeito de desvio de temporização da rede antes do compressor compreende:calcular efeito de desvio de temporização de um pacote actual utilizando informação relacionada com o referido pacote actual e cada pacote anterior até um pacote de referência.
- 7Método de acordo com a reivindicação 1, em que a estampilha temporal comprimida no campo de cabeçalho é calculada como os k bits menos significativos do valor de estampilha temporal, onde k é um número inteiro;e em que uma aproximação do valor do pacote com base no tempo decorrido desde a chegada de um pacote anterior e um valor empacotado do pacote anterior é calculado no descompressor (137) .
- 8Sistema de comunicação compreendendo:uma fonte (102) proporcionando uma pluralidade de pacotes, cada pacote incluindo um campo de cabeçalho, a fonte estando acoplada a uma rede;um receptor (130) incluindo um descompressor (137);uma entidade de rede acoplada à rede e ao receptor (130) por uma rede entre a entidade de rede e o receptor (130), a entidade de rede incluindo um compressor para efectuar compressão de cabeçalho de campo para, pelo menos, alguns dos pacotes enviados a partir da fonte (102)e dirigidos ao receptor (130), a entidade de rede incluindo uma função (115) de redução do desvio de temporização para calcular o desvio de temporização nos pacotes dirigidos ao receptor (130), o referido sistema sendo caracterizado por compreender meios para descartar pacotes tendo um desvio de temporização que é maior do que um valor predeterminado, em que o desvio de temporização é calculado como um total de um valor de desvio de temporização causado pela rede entre a fonte (102) e o descompressor (137) incluido no receptor (13 0) .
- 9Sistema de comunicação de acordo com a reivindicação 8, em que o referido desvio de temporização é calculado, calculando um efeito de desvio de temporização da rede antes do compressor e calculando um efeito de desvio de temporização entre o compressor e o descompressor (137) .
- 10Sistema de comunicação de acordo com a reivindicação 8, em que o referido efeito de desvio de temporização da rede, entre o compressor e o descompressor (137), é definido para um valor limite superior para desvio de temporização.
- 11Sistema de comunicação de acordo com a reivindicação 9, em que o referido desvio de temporização da rede antes do compressor é calculado, calculando o efeito de desvio de temporização do pacote actual utilizando informação relativa a um pacote de referência.
- 12Sistema de comunicação de acordo com a reivindicação 9, em que o referido cálculo do efeito de desvio de temporização da rede antes do compressor compreende:calcular o efeito de desvio de temporização de um pacote actual utilizando informação relativa ao referido pacote actual e a cada pacote de um número predeterminado de pacotes anteriores.
- 13Sistema de comunicação de acordo com a reivindicação 9, em que o referido cálculo do efeito de desvio de temporização da rede antes do compressor compreende:calcular o efeito de desvio de temporização de um pacote actual utilizando informação relativa ao referido pacote actual e a cada pacote anterior até um pacote de referência.
- 14Sistema de comunicação de acordo com a reivindicação 8, em que o campo de cabeçalho comprimido é calculado como os k bits menos significativos de um valor empacotado, onde k é um número inteiro, e pacote anterior.
- 15Produto de programa de computador, compreendendo:um meio legivel por computador compreendendo: código para fazer com que, pelo menos, um computador execute um método de acordo com uma das reivindicações 1 a 7 quando executado.
Independent claims15
419 paragraphs in 4 sections, as filed
The present invention relates to a method and apparatus for compressing a header field in a data packet. More particularly, the present invention relates to a method and apparatus for compressing a header field of a data packet using a Timer and a Reference Based Scheme.
For real time multimedia based on the Internet Protocol (IP), the Real Time Transfer Protocol (RTP) is used predominantly in addition to the User Datagram Protocol (UDP / IP). RTP is described in detail in RFC 1889. The size of the combined IP / UDP / RTP headers is at least 40 bytes for IPv4 and at least 60 bytes for IPv6. 40-60 bytes of complementary information per packet can be considered heavy on systems (e.g. g., such as cellular networks) where spectral efficiency is a major concern. Accordingly, there is a need for suitable IP / UDP / RTP header compression mechanisms. For example, document 0768777A2 describes certain aspects of mobility management. A current header compression scheme is described in document RFC2508 which is capable of compressing the 40/60 byte IP / UDP / RTP header to 2 or 4 bytes on peer-to-peer connections. Existing header compression algorithms are based on the observation that most IP packet header fields remain constant in a data stream over the period of a session. Thus, it is possible to compress 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 concept that most of the time, RTP fields that change from one packet to another, such as the RTP time stamp, can be predicted by linear extrapolation. Essentially, the only information that has to be sent is a sequential number, used for error and packet loss detection (as well as a context ID). When the issuer determines that linear extrapolation cannot be applied to the current packet, first order difference information from the immediately preceding packet is sent. To log in, a full header is sent. In addition, when the receiver determines that there is packet loss (as detected by an incrementing sequential number of more than 1), the receiver will explicitly require the sender to transmit the full header to allow for resynchronization.
However, the header compression defined in RFC2508 is not well suited for certain environments (such as cellular or wireless environments) where bandwidth is very important and errors are common. In the header compression scheme of document RFC2508, it is assumed that the RTP time stamp most of the time has a linearly increasing pattern. When the header follows the pattern, essentially only a short sequential number is required in the compressed header. When the header does not follow the pattern, the difference between the current and previous header RTP timestamps is sent in the compressed header. Further optimization is possible using a coding table. This approach has three drawbacks. 0 The first is that it is not error resistant as the loss of the previous header will invalidate the decompression of the current header. The second is that differences or jumps in the RTP time stamp can be very large, thus exceeding the capacity of the coding search table. For example, if the medium is voice, these large differences may be caused by a silence interval. 0 Third, the size of the resulting coded difference is variable, making it more difficult to predict and manage the bandwidth to be allocated.
Consequently, there is a need for a header compression scheme that can accommodate an arbitrary jump in field value (eg, RTP time stamp value), produce a more consistent or constant size, and be more error resistant.
SUMMARY OF THE INVENTION
According to one embodiment of the present invention, a timer-based header decompression technique is provided. An RTP source generates a header field, such as an RTP time stamp. The time stamp is sent along a network to a compressor. In the compressor, a time offset reduction (JRF) function is used to determine if the received time stamp (header) offset is excessive. If the time offset is excessive, the packet is discarded. Otherwise, the compressor calculates a compressed header field (compressed time stamp) based on the RTP time stamp and an initial value of the time stamp. The compressed time stamp represents time offset which is calculated as an effect that the network between the source and the decompressor has on packet transmission. 0 calculated time offset is an accumulation of network timing deviation which represents the effect that the network between the source and the compressor has on packet transmission and radio timing deviation represents the effect that the network between the compressor and the decompressor has in the transmission of packets. It should be noted that if the term network, as used herein, is intended to be a broad term such that it does not exclude, for example, radio connections in a wireless telecommunications network. The RTP packet, including the compressed time stamp, is then transmitted over a connection or network to a decompressor.
decompressor decompresses the compressed time stamp by first calculating an estimate or approximation of the time stamp based on the current value of a terminally located timer (ie, based on elapsed time). The time stamp approximation is then refined or corrected based on the compressed time stamp provided in the packet header. In this way, the time stamp for the current packet (header) is regenerated based on a local timer and a compressed time stamp provided on the current header. The packet and the regenerated time stamp are then provided to an RTP endpoint for processing.
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 time stamp and the timer and a reference based scheme as disclosed herein. The size of the compressed time stamp (or other header field) is constant and small. Also, the size does not change depending on the length of silence interval. No synchronization is required between the timer process at the RTP source (generating the time stamp) and the timer in the decompressor process. Likewise, this technique is error resistant since the partial time stamp information in the compressed header is autonomous and only needs to be combined with the decompressor timer value to produce the full RTP time stamp value. Loss or corruption of a header will not invalidate subsequent compressed headers.
A second embodiment of the present invention provides a header cutout scheme in which the header (eg, including the RTP time stamp) is cut or removed from the RTP packet prior to transmission. A header cutter and header generator are connected via a circuit-like connection (eg, circuit or virtual circuit) or an essentially constant binary rate channel. After initialization, the header cutter cuts or removes the header (including removing the time stamp and sequence number) from each packet and then transmits the headerless packets to the header regenerator. To eliminate packet timing offset in the header cutter, packets may be transmitted with a time spacing according to the RTP time stamp (TS) in the header. Therefore, in this embodiment, the time stamp is not explicitly provided in the RTP packet (not even a compressed time stamp). In contrast, timing information is implicitly provided to the header regenerator based on an essentially constant binary rate channel between the cutter and the header regenerator. The essentially constant binary flow channel may be provided in several different ways.
In this second embodiment, after initialization occurs (eg<sub>f</sub> provide the initial sequence number and time stamp to the header regenerator) the header regenerator can regenerate time stamps for sequential packets incrementing from TS_step into a local time stamp counter every T ms and regenerating sequence packet numbers incrementing from 1 num local SN counter at each packet duration. These fields can be regenerated based on a local timer or counter only because of the essentially constant binary rate channel provided between the header cutter and the header regenerator, in which no packet timing offset is introduced. Therefore, upon initialization, these header fields can be regenerated in the header regenerator using only a local clock as a reference.
However, one or more discontinuity events may occur (eg <sub>Λ</sub> change in packet size or TS_step, a nonlinear offset in the timestamp, etc.) which, if not addressed, could probably invalidate the header removal approach, which relies only on a local timer or clock for regeneration of fields. A header string is a sequence of packet headers having linearly known or predictable fields. The transition from one chain to another can be caused by any of several discontinuity situations. When this occurs, the header cutter identifies a discontinuity situation and sends updated situation-related header information to the header regenerator to allow time stamp and sequence number regeneration to continue. A similar technique may also be used to provide up-to-date header information when there is also a link transfer.
BRIEF DESCRIPTION OF DRAWINGS
The present invention will be more apparent from the following detailed description when taken in combination with the accompanying drawings in which:
Fig. 1 is a block diagram illustrating a system according to an exemplary embodiment of the present invention;
Fig. 2 is a diagram illustrating an uncompressed format of an RTP packet according to an embodiment of the present invention;
Fig. 3 is a diagram illustrating the uncompressed RTP header format in accordance with an exemplary embodiment of the present invention;
Fig. 4 is a diagram illustrating a compressed RTP header format in accordance with an exemplary embodiment of the present invention;
Fig. 5 is a diagram illustrating an exemplary header compression and decompression operation in accordance with an embodiment of the invention;
Fig. 6 is a diagram illustrating an exemplary header compression and decompression operation in accordance with another embodiment of the invention;
Fig. 7 is a diagram illustrating an exemplary link transfer operation in accordance with an embodiment of the present invention;
Fig. 8 is a block diagram illustrating an exemplary stack according to 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 link transfer process according to an exemplary embodiment of the present invention;
Fig. 11 is a diagram illustrating an in-band initialization according to an exemplary embodiment of the invention;
Fig. 12 is a diagram illustrating an out-of-band initialization according to an exemplary embodiment of the invention;
Fig. 13 is a diagram illustrating the steps for calculating the network time offset according to a first method of the present invention;
Fig. 14 is a diagram illustrating the steps for calculating the network time offset according to a second method presented as Option 1 of the present invention; and
Fig. 15 is a diagram illustrating the steps for calculating the network time offset according to a third method presented as Option 2 of the present invention.
BEST MODE FOR CARRYING OUT THE INVENTION
I. Timer Based Scheme Using a Compressed Time Stamp
A. Architecture
Fig. 1 is a block diagram illustrating a system according to 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, running RTP / UDP / IP and providing RTP packet voice samples for transmission over network 110. Terminal 102 includes an RTP terminal point 104 which identifies this terminal (e.g. including IP address, port number, etc.) as a source or as a recipient for RTP packets. The IP network is provided as an example, however, other types of packet switching networks or the like may be used. It is to be noted that the term network, as used herein, is intended to be a broad term such that it does not exclude, for example, radio links in a wireless telecommunications network. Terminal 102 also includes a local timer 103 for generating a time stamp.
An access network (ANI) infrastructure 110 is connected to IP network 108. A wireless terminal 130 is coupled via radiofrequency (RF) connection 140 to ANI 110. The wireless terminal 130 as described above could, for example, be a wireless compressor or a wireless decompressor depending on its environment. This is particularly so when the packet source or packet recipient is 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). ANI 110 acts as an interface between one or more wireless (or radio frequency) terminals (including terminal 130) in a region and the IP network 108, including converting between fixed network signals (provided by IP network 108) and RF or wireless (provided to or by terminal 130). Thus, ANI 110 allows RTP packets received from IP network 108 to be sent over RF link 140 to wireless terminal 130 and allows RTP packets from terminal 130 to be sent over IP network 108 to another terminal, such as a terminal 102.
According to one embodiment of the present invention, ANI 110 includes one or more ANI adapters (ANI_AD), such as ANI_AD 112 and ANI_AD 114, each preferably including a timer. Each ANI_AD performs header compression (before downlink transmission) and decompression (after uplink transmission). Headers (or one or more header fields, such as a time stamp) for RTP packets received from IP network 108 are compressed by ANI_AD 112 prior to transmission to terminal 130 via downlink 142 and packet headers received from terminal 130 is decompressed by ANI_AD 112 prior to transmission to IP network 108. Therefore, each ANI_AD can be considered to be a compressor / decompressor 115. Each ANI_AD may function as an interface between terminals located in a specific or different zone within the region and the IP network 108. ANI_AD 112 includes a timer 113 for implementing a timer based decompression technique. 0 ANI_AD 112 also includes a time offset reduction (JRF) function 115 that functions to measure the time offset in packets (or headers) received over network 108 and discard any packets / headers that have excessive time offset.
Additional ANIs, such as ANI 120, may be provided to interface with other terminals located in additional regions and the IP network 108. ANI 120 also 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 terminal point 132 which is a source and / or recipient (receiver) of RTP packets. Terminal 130 includes a terminal adapter (term_AD) 136 which performs header compression (for packets to be transmitted on uplink 142) and decompression (on packets received via downlink 144). Thus, the terminal adapter (term_AD) may be considered to be a header compressor / decompressor 137, similar to ANI_AD.
Terminal adapter 136 (term_AD) also includes a timer 134 (a receive timer) for calculating an approximation (or estimate) of an RTP time stamp of a current header. Terminal adapter 136 (term_AD) then uses additional information in the RTP header to refine or correct the time stamp approach. According to one embodiment of the invention, the time stamp approach is corrected or adjusted based on a compressed time stamp provided in the RTP header. Thus, a local timer and a compressed time stamp can be used to regenerate the correct time stamp for each RTP header. Other terminals (such as terminal 150) may be provided, each including its terminal point, adapter and terminal timer.
The configuration shown in Fig. 1 is provided merely as an example and the invention is not limited thereto. In contrast, Fig. 1 simply provides an example where RTP data is transmitted over a data link or system (such as wireless link 140) where bandwidth is very important and errors are not uncommon. The present invention is not limited to a wireless connection, but is applicable to a wide variety of connections (including fixed network connections, etc.).
An exemplary application or system where the timer-based header compression and decompression scheme may be useful is when Voice over IP (or IP telephony) packets are transmitted over cellular systems. When applying VoIP to cellular systems, it is important to minimize supplemental IP / UDP / RTP header information due to limited wireless or air interface (RF) bandwidth. In such a system, for example, ANI_AD would function as an interface between the IP network and a computer terminal running RTP / UDP / IP (eg, terminal 130) and having a cellular or RF interface to receive RTP packets over wireless or RF connection. This is merely an exemplary application 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 embodiment 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 may 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 time stamp 310 (TS), a sequential number 312 (SN), and other fields 314. Due to the packet switching nature of the IP network 108, RTP can get cluttered. The consecutive number 312 is used at the RTP receiver or RTP recipient (e.g. terminal 130, Fig. 1) to group the RTP voice samples in the correct order. However, the following numbers in the RTP packets will not reflect any nonlinear changes in the field (eg, voice signal silence intervals). Therefore, a time stamp 310 (TS) is provided to indicate the relative timing of each packet.
As mentioned above, there is some concern that the 40-60 byte header supplemental information provided by the IP / UDP / RTP headers in each RTP packet is too large. In particular, a 4-byte RTP time stamp is particularly heavy for RTP packets operating with low speed or limited bandwidth connections (such as link 140). As a result, there is a need for a mechanism that efficiently compresses the RTP headers and particularly compresses the time stamp field in the RTP header.
The header compression technique described in RFC2508 initially sends a complete (uncompressed) RTP packet, including all fields to the RTP recipient / receiver. Many of the header fields during a call are static and thus do not need to be transmitted after the initial packet is sent and received. For most packages, only the tracking number and time stamp will change from package to package. According to RFC2508, non-static fields (eg time stamp and tracking 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 consecutive number of each received RTP packet will be incremented by 1 automatically for each packet. Additional hops or changes (i. e., different from the first order difference) in non-static fields must be transmitted separately to the receiver. Unfortunately, in document RFC2508, the loss of the previous header will invalidate decompression at the receiver. Also, the size of the differences varies, making it more difficult to manage and predict bandwidth using the document compression technique RFC2508.
According to one embodiment of the present invention, there is provided a technique for header compression which may be used to more efficiently compress a time stamp (or other field) of a packet header. According to one embodiment of the present invention, the compression nozzle may accommodate an arbitrary jump in the RTP time stamp value while producing a constant size compressed RTP header (or constant size time stamp).
Fig. 4 is a diagram illustrating a compressed RTP header format in accordance with an exemplary embodiment of the present invention. As shown in Fig. 4, the RTP header may consist of a message type 410 indicating the message type, bit mask 412 identifying the changing fields, and a compressed time stamp field 414. Message type 410 may indicate a compressed time stamp if a compressed time stamp is provided in the packet header. According to one embodiment of the present invention, the compressed time stamp field 414 includes the least significant ks (lbs) of a value that may indicate the time elapsed between packets. According to one embodiment of the invention, the compressed time stamp 414 provides a part (i. e., the least significant k bits) of a source counter value (or counter difference). The source counter can be used to generate the time stamp for each RTP packet header. Optional fields 416 can be used to provide updated or changed fields for the fields identified in bit mask 412.
B. General Operation of Time Stamp Compression and Decompression
Compression and decompression of the RTP time stamp will be briefly described in accordance with one embodiment of the invention. According to one embodiment, an RTP packet is generated at one RTP endpoint (such as the RTP terminal point 104 of terminal 102) and is addressed to another RTP endpoint. In this example, RTP terminal point 104 is the source of one or more RTP packets to be sent to RTP terminal point 132 (the recipient) of terminal 130. The RTP packet header includes a time stamp, which is generated at the RTP source (eg, terminal 102) based on a wall clock.
The RTP packet is routed through IP network 108 to ANI_AD 112 of ANI 110. ANI_AD 112 compresses one or more fields in the header (s) of the RTP packet. In particular, ANI_AD compresses the RTP time stamp 310 (Fig. 3) into a compressed time stamp (Fig. 4). Other fields in the header may be compressed by removing them or using another technique. The RTP packet, including the compressed time stamp 414, is then transmitted over downlink 144 from RF link 140 to terminal 130.
Upon receipt of the compressed header RTP packet (ie, compressed time stamp 414), the terminal 130 adapter 136 (term_AD) decompresses the time stamp value. Terminal adapter 136 decompresses the compressed time stamp 414 by first calculating an estimate or approximation of the time stamp based on the current value of timer 134. The time stamp approximation is then refined or corrected based on the compressed time stamp 414 provided in the packet header. Thus, the time stamp for the current packet (header) is regenerated based on a local timer (timer 134) and a compressed time stamp provided on the current header. The other packet header fields (such as sequence number) can also be regenerated. 0 The packet and the regenerated time stamp are then provided to the RTP terminal point 132 for processing. The RTP endpoint 132 then repeats the voice samples in the correct order (as specified by the sequence numbers) and having the correct timing as specified by the regenerated time stamps (eg, to account for any silent intervals).
ANI_AD 112 may also receive compressed headers (including a compressed time stamp) via RF link 140 and decompresses the time stamp using the timer-based decompression technique described above. Therefore, ANI_AD 112 may typically include a timer to allow ANI_AD to decompress compressed time stamps as described above. Similarly, term_AD 136 of terminal 130 may also compress the time stamp of the RTP packet before transmitting the RTP packet over RF link 140 to ANI 110. To simplify the explanation of the explanatory embodiments of the invention, most of the description will be directed to downlink path 144. According to one embodiment of the invention, RTP packets can be transmitted in both directions (uplink 142 and downlink 144). Thus, ANI 110 of ANI 110 and term_AD of terminal 130 can function as a compressor (for header / packet transmission via the RF link) and a decompressor (upon receipt of a compressed header received via the RF link 140). ) of time stamp.
C. Exemplary Embodiments of Time Stamp Compression and Decompression
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 solely to help explain some of the features of the present invention, but the invention is not limited to them. Likewise, the present invention is not limited to systems using the same or similar types of variables and is not limited to systems performing the specific calculations described below. Variables and calculations are provided merely as an exemplary embodiment of the invention.
T - is the time spacing between RTP talk samples. (If a conversation sample is provided in each RTP packet, then T is also the spacing between RTP packet headers.)
TS - time stamp
TS_step - The RTP time stamp is incremented by TS_step every T ms. In other words, the RTP time stamp increases TS_step for each new RTP packet. The TS_pass is a constant (eg, 100) that depends on the voice codec. The TS_step is provided to the receiver (terminal 130) and the ANI_AD 112.
TSO - RTP time stamp 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. The TSO is an initial value of the RTP time stamp provided to the compressor (eg, ANI_AD 112) and the decompressor (eg, term_AD 136) at the beginning of the session (for synchronization). According to one embodiment, ANI_AD and term_AD are initialized or synchronized by receiving an RTP packet with an uncompressed header (including an uncompressed time stamp providing TSO). According to one embodiment of the present invention, the timer based decompression technique requires that an initial temporal TSO stamp be provided (eg , through an initial or sync header that is not compressed) to the compressor (1. e.,
ANI_AD 112) and to the time stamp decompressor (1. e., Term_AD 136) before properly decompressed decompressor can regenerate temporal).
headers can be e.g., so that the stamps (i.
correctly
RTP time stamp of m packet header (time generated m * T ms) = TSO + TS_step * m. This assumes that there is a header for each voice sample. As shown in the examples described below, this formula can be extended for multiple voice samples (eg, 3 voice samples) per packet header.
m - an integer indicating the number of chat samples that have been sent, m is reset or cleared to 0 at session start, m is proportional (or indicates) the length of time that has elapsed since session start, m is incremented by 1 every T ms.
TS_current = TSO + m_current * step_of_TS; The current time stamp for the current packet header.
Receiver Timer - The timer on the RTP receiver (or RTP recipient), such as the timer 130 on terminal 130. The local receiver timer is typically in free course and will not be reset at login. Instead, the time elapsed at the RTP receiver between receiving two packet headers can be obtained by subtracting the timer value from the current header from the receiver timer value when the previous packet header was received. By allowing the receiver timer to be in free course, a receiver timer can be shared across multiple streams or sessions. Alternatively, the receiver timer may be reset at the beginning of each session. Resetting or clearing the receiver timer at the beginning of a session (ie, upon receipt of a startup header) would require a dedicated receiver timer (timer process) for each session or stream. The first uncompressed time stamp (TSO) of a session can be provided to ANI_AD and term_AD in a startup header. The first header is provided for initializing the compressor (ANI_AD 112) and the decompressor (term_AD 136). The receiver timer is then incremented by 1 every T ms. ANI_AD 112 (compressor) uses the value of TSO to compress subsequent RTP packet header time stamps. Term_AD 136 (decompressor) uses the TSO value to decompress the compressed time stamp value (eg, to regenerate time stamps on subsequently received RTP headers).
current_timer - the timer value on the RTP receiver (eg, terminal 130) when the current header is received.
last_timer - the value in time at the receiver when the last header was received. (The current_timer is stored as the last_timer for the next header time stamp calculation).
last_m - the value of m for the last header received; m indicates the number of voice frames that have elapsed since the boot header.
To compress the time stamp of the current packet, ANI_AD 112 calculates the current value of m as: m_actual = (TS_actual - TSO) / TS_step. Therefore, ANI_AD subtracts the initial value from the time stamp (at the beginning of the session) from the current time stamp. This difference is divided by the time stamp step (TS_step). However, in some embodiments, it may be unnecessary to actually perform the division operation. Other techniques may be used to properly generate the current m_ without performing a division operation, which may require a lot of processor over-processing.
The least significant k bits of m_current are then provided as the compressed time stamp 414. The RTP packet including the compressed time stamp 414 is then transmitted over the RF link 140 to the RTP recipient or receiver (eg, terminal 130).
At the RTP receiver (eg, terminal 130), terminal adapter 136 (Term_AD) decompresses compressed time stamp 414. The current_timer value of the previous header is first stored as last_timer. Then, when the current header arrives, term_AD 136 reads the value of receiver timer 134 and stores it in memory as current_ timer. Then, timer_dif is calculated as: timer_diff = current_timer last_timer. ANI_AD calculates the exact value of m_current by finding the integer d value, where:
(-L / 2 <ddl / 2, where L = 2<sup>k</sup>) so that: (Eq. 1) the least significant k bits of (d + last_ + time_dif) = compressed time stamp 414 (for the current header).
(Eq. 2)
As mentioned, the received compressed time stamp is also k bits. Once d has been calculated using Eq. 1 and 2, current TS_ can be calculated as:
TS_current = TSO + (d + last_dif_timer) * TS_step.
(Eq. 3)
In the equation shown in
3, the actual value or parentheses as correct (d + of m_current_ last_dif_different). m_last + timer is the approximation of m_current, whereas d is the difference between the approximation of and the correct value of m_current. Also, TSO + and an approximation of * ST_pass is the current_multiple (last + time_dif) *TS_pass of the current time stamp value and the difference between the approximate current time stamp and the actual (or correct) value of the current time stamp.
Therefore, it can be seen that the RTP receiver first calculates an approximation (or estimate) of the current time stamp based on the time elapsing between receiving the current header and the previous (correctly decompressed) header, such as: time stamp approximate current = TSO + (last_dif_different) * TS_step. The approximate current time stamp is then adjusted or corrected by the amount of d * TS_step to calculate the correct current time stamp value (current TS_).
After the current TS_ is calculated, the current RTP packet (including its regenerated or decompressed time stamp, TS_actual) is provided to the RTP terminal point 132. This compression and decompression process is transparent to the RTP endpoints.
Fig. 5 is a diagram illustrating an exemplary operation of header compression and decompression in accordance with an embodiment 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, the timers on the RTP source 502 and the RTP receiver 504 are assumed to have the same frequency but typically are not synchronized. 0 RTP source timer (eg, incrementing 1 every T ms) is used to generate the time stamp, while the timer (eg, timer 134) on the RTP receiver is used to regenerate or decompress the time stamp. RTP.
Referring to Fig. 5, at login, an initialization header 508 is generated at the RTP source, including an initial time stamp (TSO) value. The initialization header 508 is transmitted to the ANI and then forwarded to the RTP receiver 504 (eg, terminal 130). The time stamp in the startup header is not compressed. Upon receipt of the initialization header, the initial time stamp (TSO) value is stored in memory in ANI_AD, along with the TS_step. According to one embodiment, two initialization headers may be transmitted to ANI_AD. ANI_AD can then calculate the TS_step as the second time stamp + the first time stamp. Term_AD can likewise calculate the TS_step or receive the value in a packet.
Similarly, when the initialization header 508 is received at the RTP receiver (terminal 130), the initial time stamp (TSO) is stored in memory along with the TS_step. Also, upon receipt 510 of the initialization header 508 (Fig. 5), m_current is cleared or reset to zero (0) and the receiver timer is then read and stored as initial_receptor_timer, 516. Instead of reading the timer at login, the receiver timer can be reset or cleared. In this example, it simply happens that the read value of the receiver timer at session start is zero (0) for simplicity. Thus, the example shown in Fig. 5 applies to both embodiments (simply reading the receiver timer or resetting it to zero) because the free course timer is read as zero at the beginning of the session. Similarly, it is not necessary to delete m_actual, but could instead write a value to m_actual. The receiver timer thereafter increments (eg, 1) every T ms. (which is the same frequency as the timer on the RTP source 502 used to generate time stamps). The initialization header 508 arrives at the RTP receiver 502 after a fixed delay (basic delay 512) and a variable delay (cumulative time offset 514).
Next, RTP source 502 generates the next RTP packet (the first session RTP packet after the initialization header). This RTP packet is generated 3 * T ms after the initialization header has been generated and thus would typically include three (3) voice samples, for example. Other values are possible. Therefore, the time stamp for the header of this packet is: TS (1) = TSO +
3 * TS_pass, as shown in Fig. 5. TS (1) refers to the time stamp generated after 3T ms after initialization. In this example, it will be assumed that TS_step is 100, for example. It is assumed that TSO is 0, for example. Thus TS (1) = 300.
The time stamp value for this packet, TS (1), is received at ANI_AD and is compressed based on TS (1) (the time stamp value), TSO (the initial time stamp value), and TS_step (the amount time stamp increases every T ms). According to an exemplary embodiment, the compressed time stamp may be calculated as the least significant k bits of m_current. 0
ANI_AD 112 calculates the current value of m as: m_actual = (TS_actual - TSO) / TS_step. In this example, it will be assumed that TS_step is 100, for example. In this example, m_actual is calculated as: m_actual = (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 the compressed time stamp 414 for this packet (CTS1), Fig. 5.
The compressed time stamp (CTS1) arrives at the RTP receiver 502 and term_AD 136 on the RTP receiver regenerates or decompresses the time stamp TS (1) for the current packet. The current_timer (zero) value is stored as last_timer and m_current is stored as last_mount. m_current was previously set to zero at the beginning of the session (ie, waiting to receive the sync header). The receiver timer value (3 in this case) is read and stored as current_ timer. Timer Diff is then calculated as current_timer - last_timer, which is 3-0 = 3. Tim_diff + m_lt is an approximation of m_current.
Therm_AD 136 then calculates the exact or corrected value of m_current using steps (1) and (2). Using guideline (2), the two least significant bits of (d + last_ + time_dif) = CTS1 (the compressed time stamp for the current header). In this case, last_ 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 equals zero.
Using the uncompressed for TS (1) = TSO + (d equation (3), time stamp then calculated as timer_dif) * this packet is + last + +_step. Thus, as a result, TS (1) = 0 + (0 + 0 + 3) * 100 = 300. The uncompressed time stamp for this package, TS (1) = 300, is then provided to the termination point 132. RTP in the RTP source, along with the RTP data and other uncompressed header fields. The correct or actual value of m_current is (d + last_dif_timer_dif). Therefore, for this packet, it can be observed that the approximation of m_current is the same as the correct value of m_current (but this is not the case in general). The m_actual is then updated to 3.
The following packet and time stamp are generated from the RTP source, including a time stamp TS (2) = 0 +
6 * 100 = 600. At ANI_AD, TS (2) = 600 is compressed in a time stamp as the least significant 2 bits of (600 - 0) / 100 = 6. In this case, 6 in binary is 110. Thus, the two least significant bits of 110 are 10. Thus, CTS2 = 10 in binary.
The compressed time stamp for this packet (CTS2) is then received at term_AD 136 after the receiver timer reaches the value of 7 due to the basic delay and the accumulated time offset. The current_timer value (3) is stored as last_timer and m_current (3) is stored as last_mount. The current receiver timer value (in this case 7) is read and stored as current_ timer. Tim_dif is then calculated as current_timer - last_timer, which is 7 - 3 = 4. Timer_different + m is an approximation of current_m, which is 7.
Therm_AD 136 then 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_ + time_dif) = CTS2 (the compressed time stamp for the current header). In this case, last_is 3, timer_diff is 4, and CTS2 is 10 (in binary, which is 3 in decimal). Equation 2 solves for 2 as follows.
<td>follows: 2</td><td>lsbs</td><td>(d</td><td> +</td><td>3 + 4) = 2. Seven in binary is</td><td>111. From this</td>
<td>mode, d =</td><td> : -1.</td><td>in</td><td>The</td><td>difference between the approximation of</td><td>m_current and</td>
<td>the value</td><td>real</td><td>in</td><td>m_</td><td colspan="2">_current. By introducing d into equation (3),</td>
time stamp for this packet is calculated as TS (2) = 0 + (-1 + 3 + 4) * 100 = 600. Thus, the RTP receiver term_AD 136 correctly regenerated (eg, decompressed) the RTP time stamp based on a local timer and a compressed time stamp.
It should be noted that, unlike prior art, it is unnecessary to resend an initialization header in case one or more packets do not reach the RTP receiver. In other words, synchronization between the RTP source and receiver is only required at the beginning of a session or connection. This is because, the current time stamp is calculated on the RTP receiver based on last_ and time_dif. Timer Diff is calculated as current_timer last_timer. Therefore, the last_ and last_timer values correspond to the last packet, regardless of which packet was last received (eg, regardless of whether packets sent after the last packet were incorrectly discarded or lost). As a result, the timer-based compression scheme according to one embodiment of the invention is error resistant and decreases bandwidth requirements because it is unnecessary to send a new synchronization packet (eg, including full uncompressed values for all headers) if an error is detected (eg, one or more dropped or lost packets).
In normal operation, the discrepancy between the approximation and the exact value of m_current is caused by:
(a) cumulative time deviation between the true source of RTP time stamps and the receiver; actual delay = basic delay + cumulative time offset, where the basic delay is constant and the cumulative time offset varies from one header to the next and 0 d cumulative time offset d maximum cumulative time offset; and
b) Possible asynchronism between the timer process and the decompressor process, depending on the timer implementation. Due to asynchronism, there may be an error of
<td>so-so</td><td>one</td><td>(+ or —1</td><td>) in value</td><td>in</td><td>timer</td>
<td colspan="2">(current_timer).</td><td></td><td></td><td></td><td></td>
<td>Fig. 6</td><td>it is a</td><td>diagram</td><td>that illustrates</td><td>one</td><td>operation</td>
<td>exemplary</td><td colspan="2">compression and</td><td>decompression</td><td>in</td><td>header from</td>
according to another embodiment of the invention. Like Fig. 5, Fig. 6 is a diagram illustrating the effect of timing offset and timer asynchronism. In Fig. 5, the receiver timer is reset or cleared only at the beginning of the session. (This is not necessary since you can allow the receiver timer to simply run). However, in the exemplary embodiment shown in Fig. 6, the receiver timer is reset or cleared to zero (0) for each packet. Thus, when a compressed packet header is received, the timer value is read, which indicates the timer dif_value described above (once the timer indicates the time elapsed since the last packet header). There may be many different ways of implementing 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 time stamp and the current time stamp (time_differ as described in Fig. 5).
Referring to Fig. 6, header n is generated with the time stamp = TSO + 3 * TS_step. This time stamp of header n is compressed and transmitted to the RTP receiver and decompressed. The timer is then reset at the receiver. The following headers, (n + 1), (n + 2) and (n + 3) are generated and sent, but only the header (n + 3) is received (1. e., The headings η + 1 en + 2 are lost). For simplicity, the headings (n + 2) and (n + 3) are not shown in Fig. 6. The header (n + 1) is shown in Fig. 6 as header m + η. The header (m + n) is generated and sent, with a time stamp TS = TSO + 6 * TS_step. This header time stamp (m + n) is compressed and then sent to the RTP receiver. The timer value is 4 (indicating timer_dif). This value is used to decompress the time stamp for the header (m + n). Therefore, the example of Fig. 6 is very similar to the example shown in Fig. 5, except that the timer is reset after receiving each header in Fig. 6.
Regardless of which technique is used (either Fig. 5 or Fig. 6), an efficient timer-based compression squeegee can be used. However, if the accumulated time offset is excessive, it may not be possible to regenerate a correct time stamp based on the compressed time stamp. In many cases, the following condition must be met by k to allow the timer-based compression squad shown in Figs. 5 and / or 6 to function correctly:
[Condition 1] (Maximum Integer Deviation + 2) <2<sup>k</sup>where the maximum integer time deviation (MIJ) is the maximum cumulative time deviation, expressed in units of T ms, rounded to the next largest integer. For example, if T = 20 ms, a maximum cumulative time offset of 15 ms will result in MIJ = 1. 2 will be added to the MIJ to account for possible errors caused by timer asynchronism.
Due to real-time talk time requirements, the accumulated time shift in normal operation can only be a few times T ms. Therefore, in such a case, a k value of 4 is more than sufficient since a discrepancy of up to 16 chat samples (ie, 16 * T ms) can be corrected at the RTP receiver. Abnormal or error situations may result in a time shift exceeding the usual values. A timing offset reduction entity may be added upstream of the compressor to ensure that the timing offset, as seen by the compressor, remains within acceptable limits.
Advantages of the time stamp compression scheme illustrated in Figs. 5 and / or 6 include:
a) The size of the time stamp is constant and small. The compressed header typically consists of a message type indicating the message type (kl bits), a bit mask indicating which fields are changing, and a field containing the least significant k bits of m_current (k bits). ). Assuming that the same 4-bit MST1 bitmask is used as in document RFC2508, and kl = 4, the size of the compressed header when only RTP TS changes (this is by far the most frequent case) is 1.5. bytes. Also, the size does not change depending on the length of the silence interval.
b) As shown, for example, in Fig. 6, the receiver timer operates at the same frequency as the RTP source timer (used to generate the original time stamp); No phase synchronization is required between the source timer and the receiver timer (because it is the elapsed time as measured by the receiver timer that is used to regenerate the time stamp).
c) At the receiver, no synchronization is required between the timer process and the decompressor process. For example, the timer process may increment the timer every 1 ms, whereas the decompressor process is started to perform decompression when a new header is received. However, it is not necessary for the point at which the timer increments to be aligned or synchronized with the point at which the header is received (see Fig. 6).
d) Error resistance, since the partial RTP TS information in the compressed header is autonomous and only needs to be combined with the receiver timer to produce the full RTP TS value. Loss or corruption of a header will not invalidate subsequent compressed headers.
e) There is no need for memories or values to be kept or stored by the compressor for the purpose of RTP TS compression / decompression.
D. Link Transmission
According to one embodiment, each ANI_AD is assigned to a specific zone (eg, acts as an interface to terminals located in a specific zone). Terminals (such as terminal 130) may move from one zone to another. When a terminal moves from one zone to another, the terminal must be moved or switched from one ANI_AD to another ANI_AD.
One case of link transmission to consider is link transmission between ANI_AD, where an interruption caused by switching from the old ANI_AD to a new ANI_AD may occur. The question is how to maintain the continuity of information during the link transmission, so that after the link transmission the compression / decompression in term_AD 136 and the new ANI_AD continue without interruption.
1. Downlink
There is no discontinuity on the receiver side which is the terminal (eg terminal 130, Fig. 1). The role of the compressor is transferred from one ANI_AD to another. After link transmission, headers are routed in a new path through the new ANI_AD instead of the old ANI_AD. Also, depending on the system design, packets may be rerouted in transit during link transmission. Packets in transit are source-generated packets that have not yet reached the receiver at the time of the call transmission. Relay attempts to deliver packets in transit to the terminal.
To perform link transmission, the old ANI_AD must transfer the initial value of the time stamp for the session (TSO) and TS_step to the new ANI_AD. These two values allow ANI_AD to continue compressing new time stamps (in new packet headers) received from the RTP source (eg, terminal 102). Let Current_header be the truly first header to be decompressed by term_AD after the link transmission and your current_ TS, its RTP time stamp. Term_AD can decompress TS_actual as long as the following condition is met:
[Condition 2] (Downlink Transient Integer Delay + 2) <2<sup>k</sup>, where the Transient Downlink Integer Time Shift (DTIJ) is the current_header Transient Downlink time offset, expressed in units of T ms, rounded to the next largest integer. The forward link transient time offset is defined as = current_header total delay - basic delay on the old path. If the Current_header is not the header of a forwarded packet in transit, the total delay of the Current_header is also the basic delay on the new path + accumulated time offset for the Current_header on the new path. Therefore, the downlink transient time offset = basic delay on new path - basic delay on old path + accumulated time offset for the current_header.
If the Current_header is the header of a forwarded packet in transit, the total delay of the Current_header = total delay caused by forwarding and forwarding. In practice, systems should preferably be designed to maintain the downlink transient time offset within the same range as the steady state accumulated time offset (ie, no link transmission). Therefore, based on these assumptions (which may not always apply), no specific problems related to link transmission are expected if condition 1 (mentioned above) is met.
2. Uplink
In this uplink description, terminal term_AD 136 (eg, terminal 130) compresses the time stamp and sends it over 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 location (requiring link transmission on ANI_AD), the role of the receiver (decompressor) is transferred from a ANI_AD to another. The RTP source remains anchored to the terminal (eg , terminal 130, Fig. 1).
Fig. 7 is a diagram illustrating an exemplary link transmission operation in accordance with an embodiment of the present invention. To minimize overhead processing due to air interface, some information needs to be transferred from an old ANI_AD 710 to a new ANI_AD 712 for link transmission. This information is the timer value in the old ANI_AD. The old ANI_AD 710 reads (or takes a picture) the current value of the Timer (T_u) on the old ANI_AD, and sends it to the new ANI_AD, along with the TSO, step_ of_TS and current_block 714 (Fig. 7). The new ANI_AD starts incrementing its timer starting at (T_u). Let T_transfer 715 (Fig. 7) the time to transfer the Timer. Also, the timer processes in the old ANI_AD and the new ANI_AD may have a phase difference that is at most T ms. Let Current_header be the truly first header to be decompressed by the new ANI_AD after link transmission, and TS_actual to its RTP time stamp. ANI_AD can decompress TS_actual as long as the following condition is met:
[Condition 3] (Transient Integer Time Shift of
<td>Link</td><td>ascending</td><td> +2+1) < 2<sup>k</sup>,</td>
<td>where the</td><td>Deviation from</td><td>link transient integer timing</td>
<td colspan="2">ascending (UTIJ)</td><td>is the transient timing deviation of</td>
<td>Link</td><td>ascending</td><td>expressed in units of T ms, rounded</td>
to the next largest integer. The uplink transient time offset is defined as = Current Header total delay - Basic path old delay + T_transfer. Once gue Current Header Total Delay = Basic New Path Delay + Cumulative Time Deviation for Current Header, Uplink Transient Time Deviation = New Path Basic Delay - Old Path Basic Delay + Cumulative Time Header Deviation + T_transfer. Compared to the downlink case, 1 is added to account for the phase difference between the old ANI_AD timer and the new ANI_AD timer.
Specifically, Fig. 7 also illustrates the transient uplink timing offset, which includes the basic delay difference and T_transfer. In this example, the old ANI_AD resolves to prepare for link transmission before the timer increments the timer. Therefore, it sends T_u = 0 to the new ANI_AD 712. T_transfer is approximately T ms. In the new ANI_AD 712, due to the timing of the timer process, almost T ms elapses before the timer is incremented. There is also a cumulative time offset in the new path to the header (n + m). As a result, the timer value read when header (n + m) is received is 2, while the actual value should be 4. Thus, there is a deviation of -2. Provided condition 3 is met, the offset can be eliminated and the RTP time stamp can be decompressed correctly.
According to one embodiment, T_u is transmitted on a high speed signaling network connecting the old and new ANI_ADs. Consequently, the T_transfer time should be at most only a few Tms. However, consideration should be given to cases where the transfer of T_u is not successful or sufficiently well timed. In such cases, the new ANI_AD will notify term_AD, which sends the full (uncompressed) RTP time stamp until acknowledgment is received.
3 Time Shift Reduction
According to one embodiment of the present invention, the timer based compression scheme using a compressed time stamp and a local receiver timer may be based on the following conditions if they are met.
[Condition 1] (Maximum Integer Time Shift + 2) <2<sup>k</sup>, [Condition 2] (Downlink Transient Integer Delay + 2) <2<sup>k</sup>, [Condition 3] (Transient Uplink Transient Integer Delay + 2 + 1) <2<sup>k</sup>,
Due to the real-time conversation rules, it can reasonably be expected that the various timing deviations above are in the order of a few Tms in normal operation. Therefore, a poor value of k, eg 4, is usually more than sufficient to allow any deviation or error to be corrected. However, there may be abnormal conditions in the path from the RTP source to the receiver (faults, etc.) or other situations in which the timing deviations become excessive (where the correct time stamp cannot be generated based on the compressed time stamp and local receiver timer). To deal with these cases, a time offset reduction (JRF) function 115 may be provided (Fig. 1) as an input to the compressor so as to filter (or discard) packets which have excessive timing deviation (eg, under any of conditions 1, 2 or 3 not being met).
In order to exclude or identify packets that have an excessive MIJ, the time offset reduction (JRF) function calculates the time offset of each packet received over network 108. If the measured time offset is greater than 2<sup>k</sup> - 2, this is considered excessive time offset and the packet is discarded. Otherwise, the header (or header field) is compressed (as described above) and then transmitted to the receiver terminal (eg, terminal 130).
JRF calculates the timing deviation of the current packet as follows: timing deviation = absolute value of (TS2 - TS1 - JRF timer_dif), where TS2 is the current packet timestamp, TS1 is the previous packet timestamp and JRF timer_dif is the difference in JRF_timer between the current package and the previous package (elapsed time). This time offset value is compared to 2<sup>k</sup> - 2. If the time deviation is greater than 2<sup>k</sup> - 2, the package is discarded. Otherwise, the packet header is compressed at ANI_AD and the packet with the compressed header is sent to the RTP receiver.
JRF 115 is an efficient technique of limiting the jitter in packets received by the receiver terminal (because the jitter introduced by the RF link can be considered negligible). In addition, JRF works to more efficiently utilize available bandwidth through RF link 140. In the absence of JRF 115, one or more packets that have a time offset greater than 2<sup>k</sup> - 2 may be transmitted to the RTP receiver over link 140. However, at the receiver, if the time offset is excessive (ie, if condition 1 is not met), the correct time stamp value cannot be generated, causing the receiver to discard the packet. Thus, the JRF only works to filter out packets that have excessive time drift that would otherwise be discarded at the receiver (avoiding wasting valuable bandwidth over link 140).
II. Header Cutout Scheme
A second embodiment of the present invention provides a timer-based header cutter scheme in which a header or one or more header fields (eg, including the RTP time stamp) are cut from the RTP packet prior to transmission over the link. low bandwidth (eg, via RF link 140, Fig. 1). In such a case, the time stamp is not explicitly provided to the RTP packet. Instead, timing information may be provided implicitly to a header regenerator to increment the local timer based on an essentially constant binary rate channel or circuit-like connection between the header cutter (eg, which may exist in an ANI_AD ) and the header regenerator (eg, which may exist at terminal 130).
A. Header Removal Summary
Header removal is based on the idea that for some applications or services, it is not necessary to carry 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 services (eg via RF link 140, Fig. 1), the only variable header information that is essential is the RTP time stamp (TS). It is also desirable to maintain transparency for transparency numbers here (for removal / regeneration is header depends on the sequential (SN) of RTP. The SN) means that the SN after equal to the original SN. The removal of implicit timing information provided by a circuit-like connection or essentially constant binary rate channel (where no packet timing offset is introduced) to allow RTP time stamps to be regenerated based on a timer only or local accountant. This eliminates the need to send the time stamp explicitly (or even send a compressed time stamp). To achieve SN transparency, compressed SNs may be used in combination with channel timing information or circuit-like connection. A circuit-like connection preferably provides a channel having essentially constant torque throughput. When there is no voice sample (eg, silence interval), the channel may or may not be allocated to other traffic and / or users. Advantages of this header removal scheme include:
a) Bottom header supplementary information unmatched by any other scheme (even smaller than the compressed header technique described above in Figs. 1-6).
b) Error resistance, since essentially circuit-like transmission or channel timing information is essentially inherently unaffected by errors.
c) Possibility to switch during a call for header compression (eg, Fig. 1-6 technique), if desired. This can be useful if the call becomes multimedia, with a non-voice medium being added to the voice. In addition, it should be noted that header removal does not require or exclude statistical multiplexing, which if implemented, may occur at a lower layer.
<td>one</td><td>diagram</td><td>of blocks</td><td colspan="2">illustrating a stack</td>
<td>in</td><td>wake up</td><td>with one</td><td>form</td><td>of achievement</td>
<td>gives</td><td>gift</td><td>invention.</td><td>Are</td><td>shown one</td>
Fig. 8 is an exemplary header cutter stack 802 and a header regenerative stack 830. As an example, header cutter stack 802 illustrates some of the components that can be used to cut one or more packet header fields, while header regenerator stack 830 illustrates some of the components that can be used to regenerate the header Package Header stack 802 could be provided, for example, in an ANI adapter type (eg, ANI_AD 112, Fig. 1), while header regenerator stack 830 could reside, for example, in an ANI adapter type. terminal (eg, term_AD 136, Fig. 1).
Referring to Fig. 8, header cutter stack 802 includes RTP and UDP layers 804, an IP layer 806. RTP / UDP / IP layers generate an RTP packet 808 (which includes a time stamp in the RTP header). Next, in header cutter stack 802, RTP packet 808 is provided to a header cutter 810 (HS) for cutting or removing one or more header or header fields. Layers 812 L1 and L2 are provided, where L2 may be a data link layer and layer L1 may be a physical layer, for example. Other layers may be provided as required. Similarly, header regenerator stack 830 includes corresponding layers 820 L1 and L2, a header regenerator (HR) 822 that regenerates the header (including the RTP timestamp) to provide the complete RTP packet 824 (including network header). RTP / UDP / IP). Packet 824 is provided to IP layer 826 and then to UDP and RTP layers 828. Layers L1 and L2 of header cutter stack 802 and header regenerator stack 830 are in communication over a link 815 or air interface (such as RF link 140) or over a network. For example, Voice over IP packets are passed through the header cutter 810 prior to transmission over link 815 (eg, link or wireless network). At the receiving side (in header regenerative stack 830), header regenerator 822 regenerates the header prior to delivery to the container. Layers L2 / L1 may provide circuit-like bonding, ie, provide an essentially constant binary throughput channel between header cutter 810 and header regenerator 822. In addition, for maximum efficiency, the L1 layer can also perform voice payload optimization such as uneven bit protection, plus optimized channel encoding and interlacing. Note that the concept of header removal applies regardless of whether or not payload optimization is performed.
In operation, header cutter 810 (HS) eliminates the time offset in incoming RTP packets and reruns them according to the RTP time stamp (TS) in the header. Here, eliminating the timing offset means scheduling the transmission of the voice sample on the circuit-like connection or essentially constant binary rate channel according to the time stamp. In other words, packets, after cutting or removing headers, are transmitted on the circuit-like channel or essentially constant binary rate channel at heights based on their time stamp in the packet. Packets with excessive time drift are discarded using the time drift reduction function (JRF 115, Fig. 1), for example. 0 Header Regenerator 822 (HR) rebuilds the IP / UDP / RTP fields, which can be classified into the following categories:
a) Static: Value does not change over session duration, eg, IP addresses.
b) Non-static: Value may in principle change from one packet to the next, but in practice for voice, the only non-static field that is essential to preserve during header removal is the time stamp (TS) of RTP. The RTP sequence number (SN) is also preserved. Static fields can be transferred once and for all as part of a complete header at the startup phase at the beginning of the session. A reliable delivery mechanism may be used (eg using
Acknowledgments or RTP Receiver Ack to confirm receipt of initialization information). The time stamp and sequence number will be discussed briefly.
1. RTP Time Stamp (TS)
In the case of voice, the RTP time stamp (TS) increases linearly as a function of the wall clock (ie, timer).
<td>from source)</td><td>at</td><td>source</td><td>of RTP. If the</td><td colspan="2">range of</td><td>time between</td>
<td>samples</td><td>in</td><td colspan="2">consecutive voice for</td><td>T ms</td><td>;, then</td><td>the stamp</td>
<td>temporal</td><td>in</td><td>RTP</td><td>of the header</td><td>no</td><td>(generated</td><td>in time</td>
<td>n * T ms) =</td><td colspan="2">stamp</td><td>RTP time</td><td>of</td><td>header</td><td>0 (generated in</td>
<td>time 0)</td><td> +</td><td>step_of</td><td>_TS * n, in</td><td>gue</td><td>step_of_</td><td>_TS and T are</td>
voice codec dependent constants. This is true if there is only one packet per sample conversation (voice). More generally, the time stamp (TS) is of the form TSO + m * TS_step, where TSO is <TS_step and is an integer. The same behavior is observed in header cutter (HS) after the time offset has been eliminated.
At the beginning of the session or connection, an initialization phase is performed to initialize the RTP receiver (ie initialize the header regenerator). In the initialization phase, the header cutter continues to send initialization information (Info_de_inic) until an Ack is received from the receiver. Start_Info consists essentially of the full IP / UDP / RTP n header (including a time stamp and leading number). 0 RTP tracking number is used to identify this particular boot header, since subsequent boot headers will include larger boot numbers (assuming the first boot header does not receive an Ack).
In Header Regenerator (HR) 822, when the Start_Info (n) is received correctly, HR 822 sends an Ack (n). Once Header Regenerator (HR) 822 has sent Ack from a full header, the HS 810 stops sending full headers. HR 822 also initiates a local time stamp counter that is initialized to the time stamp received at Start_Info (n). The TS counter is similar to the receiver timer in Fig. 1, but the TS counter is incremented by TS_step every T ms (instead of 1, but is the same principle as the receiver timer). For subsequent clipped conversation frames (ie, RTP packets where headers have been clipped or removed), the RTP TS is regenerated from the time stamp counter (TS). The receiver timer (TS timer) has the same frequency as the clock or timer used on the RTP source (i. e., source timer) to generate the time stamp. In addition, the circuit-like connection provides essentially constant torque throughput and thus packet delays are not variable or do not change from packet to packet, as a result, there is no timing offset due to the binary rate channel. essentially constant. Therefore, after the RTP receiver receives initialization information, including an initial time stamp (TSO) value, the RTP receiver can regenerate a correct time stamp for each subsequent packet (after initialization) based on the counter only. time stamp (or receiver timer).
The binary flow channel provided between the essentially constant header regenerator cutter 822
810 only providing a predetermined number of bits over a predetermined period of time between the header cutter 810 and the header regenerator 822, but this function may be performed in a variety of different ways. For example, the channel may be a constant bit rate channel that is dedicated to cutter 810 and regenerator 822 or shared among multiple users. The channel may provide, for example, one bit per millisecond or provide 100 bits per 100 milliseconds but where the data rate may not be constant (ie, may vary) within a period of 100 ms.
As a further example, the channel may provide the predetermined number of bits through one or more data broadcasts between the header cutter and the header regenerator. For example, the channel may provide a 1000 bit portion or burst every 10 milliseconds. Thus, the essentially constant binary rate channel need only provide a predetermined number of bits over a predetermined period of time, but can achieve this using different techniques.
2. RTP Sequential Number (SN)
RTP SN (as seen by HS 810) typically increases from 1 from one packet to the next. The only exceptions are when packets are lost or misordered. In the uplink, packet loss or misorder is not expected to occur since header cutter 810 (HS) and RTP source are very close together. Therefore, the following applies to downlink. The HS 810 performs a limited buffer register to try to reorder packets before cutting their headers. The packet with RTP SN n is considered lost if it was not received when the packet with RTP SN (n + 1) has its header clipped. The packet with RTP SN m is misordered if, when received, the packet with RTP SN k already has its header clipped ek> m. Reordering buffer register length is a design parameter. Too long a buffer will result in an excessively long delay, while too short a buffer will result in many dropped packets. The parameter also depends on the quality provided by the upstream IP network 108 of the HS 810. The HR 822 maintains a SN counter which is its best estimate of SN. Looking at Start_Info, HR 822 can get the starting SN and the starting number of bits contained in a packet also known as packet size (p_size). HR 822 initializes the SN counter with SN at Start_Info. HR 822 then counts the talk bits received via the essentially constant binary rate channel and increments the SN counter by 1 for each size of talk bits (not incremented when no packet is received, eg during a silence interval). According to one embodiment, HR 822 does not actually count the received bits. Instead, the SN counter on HR 822 is incremented by 1 for each packet duration, where a packet duration is the time required to receive a bit packet (p_bits). Thus, packet duration will be a function of packet size (p_size) and binary throughput (which is constant over a circuit-like connection).
Thus, it can be observed that after initialization occurs (provide the initial SN and TS to HR 822), HR
822 You can generate time stamps for sequential packets by incrementing TS_step the TS counter every T ms and incrementing the SN counter by 1 each packet duration. Therefore, upon initialization, these fields can be regenerated on HR 822 using only a local clock (assuming that the TS_step and packet duration are known by HR 822). Time-based SN (packet duration) counter incrementing, rather than an actual count of received bits, is more error-resistant. If one or more bits are lost before reaching HR 822, the SN counter will reflect the actual value and will not be affected by the loss of bits.
B. Discontinuities and Chains
The above description indicates that TS and SN can be completely trimmed by HS 810 prior to transmission via a link (eg RF link 140) and regenerated by HR 822 which maintains a local clock or timer (eg by incrementing the counter_TS of TS every T ms and incrementing the SN counter by 1 for each packet duration). However, one or more basic discontinuity situations may occur which, if not addressed, could probably invalidate the timer-based regeneration approach described above. Some of the discontinuity situations may include:
a) New pulse event: Transient change in the difference in TS between packet n and n (1 +) (start of a new talk pulse); This can also be described as a nonlinear variation or time stamp shift (TS).
b) Event Size change: Change in RTP packet size (p_size), caused by a change in the number of conversation frames inserted into a packet and / or the size of the conversation frame.
c) Event Step change: Change in TS_step (caused, eg, by a change in payload type PT).
A header string is defined as a sequence of packet headers, such that all packets have the same size (p_size), sequential numbers are consecutive, ie n, (n + 1), (n + 2) , etc., and the time stamps (TS) of consecutive packets are spaced by the same increment step_of_TS. In other words, a header string can be considered as a header string having some package fields in common (e.g. g., packet size) and other packets that increase linearly over consecutive packets, such as SN and TS. A chain is usually a conversation pulse (eg, a series of voice samples provided between silent intervals).
The transition from one chain to another can be caused by any of the discontinuity situations, alone or even in combination. In this scheme, when a chain begins (and the previous chain is already over), HS 810 determines what discontinuity situation has occurred and accordingly sends the chain initialization information (start_string) required to HR 822.
Fig. 9 is a table illustrating information which may be provided in messages according to an exemplary embodiment of the invention. The info_de_inic typically includes a full header (including full SN and TS) and is sent from HS 810 to HR 822 (to initialize HR 822) at the beginning of the session. The HS 810 will continue to resend info_de_inic until it receives an HR 822 Ack before proceeding with sending headerless data packets. Subsequently, there may be one or more strings that may occur which may require additional field updates or values that change from one string to another. These changed values are provided to HR 822 using the start_string.
The start_string includes the value of p_size (if it has changed since the last string) and the value of_step (if it has changed since the last string. If no nonlinear shifting occurs from one string to the next, HR 822 can continue to regenerate the TS based on the TS counter used in the old string, however if a non-linear time stamp (TS) shift occurs between strings (1. (ie, timing loss), the updated time stamp should be sent explicitly at the start of HS 810 to HR 822. The updated TS can be sent as a compressed time stamp 414 (see Fig. 4) described above provided that condition 1 as described above. Otherwise, if condition 1 is not met, the complete updated time stamp should be transmitted to HR 822.
In Ack mode, after HS 810 sends the start string to HR 822, HS 810 may require the HR 822 to confirm (or send an Ack) receipt of the updated string information (start string) before HS 810 can send. additional data packets (headerless packets) for HR 822. In Ack or Ack mode, the HS 810 repeatedly sends a start-string message to HR 822 until the HS 810 receives an HR 822 Ack for a start-string message. . After receiving an HR 822 Ack, HS 810 will then send the remaining packets of the chain as clipped header packets (since TS and SN for new chain packets can already be regenerated).
<td>using</td><td>only</td><td>one</td><td>timer or</td><td>local clock).</td><td>THE</td>
<td>request</td><td>from Ack</td><td>(at the</td><td>confirmed mode)</td><td>to the message</td><td>in</td>
<td>string_start</td><td>prevent</td><td>what</td><td>HS 810 send</td><td>a new chain</td><td>without</td>
<td>notify the</td><td>HR 822.</td><td>Per</td><td>example if the HS</td><td colspan="2">810 send a new</td>
start message (eg> providing updated fields or information related to a discontinuity situation) while the link between HS 810 and HR 822 is temporarily broken, HS 810 cannot proceed to send clipped header packets until it first receives the message. HR 822 Ack.
Once HS 810 has confidence that HR 822 has received the string_initiation information, conversation frames (eg, data packets) without the header in the rest of the string are then sent. For these headerless frames, TS and SN are regenerated using a local clock on HR 822.
HS 810 can determine the events as follows:
a) Event New impulse: The difference in TS between a packet having SN = n and a packet having SN = (n + 1), is different from TS_step. This indicates the beginning of a new chain or conversation impulse. In this case, to ensure synchronization between SN, the string_init consists of either a SN or a compressed SN (C_SN). If SN information was not sent, HR 822 cannot be sure that incrementing the SN counter by 1 for each packet duration will result in an accurate SN. This is because there may have been a connection disconnect during which conversation bits were lost between HS 810 and HR.
b) Event Size change: The size of an RTP packet having SN = n is different from the previously received packet; This will affect the value of the packet duration (the rate at which the SN counter is incremented). The start_string includes the new value of size_p.
c) Event Step change: Determined when parsing a payload type (PT) field in the RTP packet; the start_string includes the new value of_step.
These discontinuity situations are provided by way of example only. Other types of discontinuity situations are possible.
Situations may occur in combination (composite situation). In this case, the start_string includes all the information of the corresponding basic events. For example, if New Pulse occurs in combination with Size Change, start_string = {C_SN, new value of size_p}.
C. Procedure for Sending Start_Info, String_Init
Info_de_inic is usually sent in Ack mode, so the HS 810 will send Info_de_inic until it receives an Ack from HR 822. The start_string can be sent in Ack or non-Ack mode. In Ack mode, the HS 810 will send the string_Start in each packet until it receives an HR 822 Ack. Once an Ack is received, the HS 810 only sends talk bits for the remainder of the chain, without any headers. In non-Ack mode, the HS 810 will send the String_Start a certain (predetermined) number of times before sending only talk bits for the remainder of the chain. Optionally, the start_string may be repeated at some interval during the chain to make sure that HR 822 is synchronized (eg, has the right values).
A composite event that includes the basic Size Change or Step Change event will typically require the String_Start to be sent in Ack mode. In this case, the start_string will carry a generation number. The generation number is an incremented counter each time p_size or TS_step changes. It is used in case where p_size and TS_step change in rapid succession to track which change has received an HR 822 Ack. For example, if p_size changes from p_size_0 value to p_size_length, then again to p_size_2 value, the HS 810 will send a string_start containing 1 generation number, for example 3, subsequently another p2_setting string, with generation number 4. Receiving an Ack subsequent to the second string start will be ambiguous if it did not carry the string start generation number to receive an Ack. If the composite event is just New Pulse, a Chain_Start (C_SN) can be sent in Ack or nonAck mode. The non-Ack mode is based on the concept that C_SN will be repeated at least at the beginning of each conversation pulse. Therefore, the probability that HR 822 will never resynchronize your SN is asymptotically small. Also, if SN is out of sync, this is only caused by packet loss between HS 810 and HR 822. Therefore, the effect of a SN desynchronization is that regenerated SN <correct SN. This is just a transient inconsistency that is corrected by making the SN increase the difference as soon as the next C_SN is received. An SN increase of more than 1 will be interpreted by the receiving RTP endpoint as packet loss (s) and should normally not affect the retry of the received packet itself. Non-Ack mode also allows you to dispense a channel to carry Ack in a stable state, ie after call setup and between call transfer.
D. Link Transfer
When header removal / regeneration is applied to cellular systems or other systems where station terminals can move from one network adapter (ANI_AD) to another, connection transfers or transmissions should be considered.
Binding transfer can be modeled as going through three phases: binding transfer preparation, binding transfer execution and binding transfer completion. There is a function called link transfer manager (HO) (which may be provided in ANI 110) that decides to initiate link transfer preparation. Typically, lead transfer preparation consists of exchanging signaling messages with the target system to reserve resources on the target system and obtain necessary information about the target cell. The call forwarding execution is initiated with the source HO manager sending an HO command to the receiving terminal (or mobile station) along with the target cell information. In response to the HO command, the terminal (or mobile station) performs link transfer. Link transfer completion involves exchanging signaling between the terminal or mobile station and the target system, notification to the source, and release of resources no longer needed (eg, at the source).
1. Uplink
The ANI_AD acts as an HR 822 for uplink data transmission (see uplink 142, Fig. 1). The target ANI_AD must be provided with the information necessary to regenerate the full header. Major constraints include continuity of RTP TS and RTP SN during link transfer (HO).
Fig. 10 is a diagram illustrating a link transfer process according to an exemplary embodiment of the present invention. Terminal 130 (or MS mobile station), as an example, may notify source ANI_AD 112 that the packet size has changed using a string start message, step 902. Source ANI_AD 112 confirms this update to p_size, step 904. Subsequently, terminal 130 moves to a new zone covered by the target ANI_AD 114 and the HO manager 901 notifies the source ANI_AD of preparation for a link transfer (link transmission), step 906. Then, the source ANI_AD sends a HO_boot (start_u_in) information for target ANI_AD 114, step 908.HO_u_init is an estimated view of the complete IP / UDP / RTP packet. The estimated view consists of the last regenerated header, but with an RTP TS replaced by TS0_u, last_u, TS_u step, and TS Timer_u value. These values are related to TS_last, the RTP TS of the last regenerated header as follows: TS_last = TS0_u + m_last_u * step_of_TS_u. TS_u Timer is a counter in the source ANI_AD that has been incremented by 1 every T ms. In addition, start_ho_u includes size_p_u (current packet size in uplink direction). From start_of_HO_u, the target ANI_AD derives static fields as well as approximate initial values for variable fields (RTP TS and RTP SN). A wire transfer command is sent from the HO manager 901 to terminal 130 (mobile station), step 910, causing terminal 130 to switch and use the target ANI_AD for communications. However, an HO manager may not be required as other techniques may be used to initiate a connection transfer.
A wire transfer is considered to break a chain in progress. Therefore, upon completion of the wire transfer, the truly first sample chat to be sent is always treated as a new string, which requires sending signaling information (sinc_ho_u), step 912. There are three significant points in time: ST1, which is the beginning of the preparation of HO, ST2, which is the command reception of HO by MS, and ST3, which is the time when the source ANI_AD recorded its internal information to be sent in start_of_HO_u. Let HOT be the time elapsed from ST1 to ST2. From system design, there is an upper limit on HOT: HOT <HOT_max. A fourth significant point in time is ST4: the first time that terminal 130 wants to resume sending conversation on the target system after HO. At ST4, terminal 130 (MS) determines whether the most recent p_size change has been committed until time ST2 - HOT_max. If so, terminal 130 is sure that HOT_init_u contained the updated value of p_size. Therefore, there is no need to include it in sinc_de_HO_u. This is because the points in time are ordered as ST1 <ST3 <ST2. Otherwise, terminal 130 (MS) will include the new p_size value in u_ sinc_u. The same algorithm applies to step_of_TS_u.
In all casesHO_u_ sinc includes C_SN. C_SN is required as there was an interruption caused by HO. C_TS is required if binary rates, packet durations, etc. on source and target systems are not synchronized. This is likely to be the case. The HO_u Sync is preferably sent in Ack mode.
The START_u_u and sinc_de_HO_u are used by the target ANI_AD 114 to regenerate the full header as follows. All fields except TS and SN are copied from start_of_u. O
SN is obtained by decompressing C_SN in sinc_of_HO_u. TS is determined by decompressing C_TS in sinc_de_HO_u.
2. Downlink HS paper is transferred from one ANI_AD to another. After link transmission, headers are forwarded in a new path through the new ANI_AD instead of the old ANI_AD. As a result, there may be a timing discontinuity for RTP TS regeneration at terminal 130 (MS).
an information of
ANI AD target.
To handle link transfer for the uplink, when the HO manager decides to initiate link transfer preparation, it will notify the source ANI_AD. Then the source ANI_AD will sendHO_boot (start_HO_d) to
HO_d_start consists of p_size and TS_step, which are the last values to be confirmed by the MS, along with their generation number. The first time the target ANI_AD wants to send conversation after HO, the target ANI_AD must sendHO_d_ sinc. Syn_of_HO_d consists of C_TS and C_SN. If the new size_p differs from size_p_d, sinc_HO_d also contains the new value size_p. Otherwise, the d_H sinc_c simply contains the generation number n of p_d_size. MS uses the generation number to extract the correct p_size. This assumes that MS has stored in memory the last values of p_size, along with their generation number. The same algorithm applies to TS_step. The one sent until you receive an MS_AD Ack. sent in Ack mode
In i c_of_HO_d Sync of HO d
The link transfer process is shown in figure 2. The case shown is: the most recent change in p_size that has been confirmed up to time ST2 - HOT_max.
E. Sending Messages
Each of the above information may be sent in-band or out-of-band. In the in-band approach, the information is sent on the conversation channel taking out the least significant voice bits. In the out-of-band approach, a dedicated transient channel is established and destroyed when an Ack is received. A combination of in-band and out-of-band is possible, so the out-of-band approach is tried, but the in-band approach is a backup solution if there are no resources for a transient channel. In-band or out-of-band acknowledgments can be sent on their own dedicated Ack channel, or out-of-band supported by the other dedicated transient channels (ICT, etc.).
1. In Band
Regardless of how a circuit-like talk channel is made, it can be modeled as a channel that can transmit B bits every T ms. If S is the size of a bit conversation frame, S d b. With the expected voice codecs, the Info_de_inic is expected to be greater than S. Therefore, an Info_de_inic cannot be sent within a single chat frame. However, there is a factor R> 1, such as (R1) * S <H <R * S. Start_info (n) can be carried on the circuit-like channel by dividing it into B-bit portions and sending a portion every T milliseconds.
A full header will take the space of R consecutive conversation samples. Fig. 11 is a diagram illustrating an in-band initialization according to an exemplary embodiment of the invention.
If there is no continuous voice activity, the Start_Info sent is Start_Info (0), Start_Info (R), Start_Info (2R), etc. until an Ack (n) is received. In Fig. 11, these info_de_inic 500 messages are shown as info_de_inic 500 and info_de_inic 502. The header cutter sends an Ack from info_de_inic 500, but not before HS 810 sends a second info_de_inic packet. The next 504 packet is sent from HS HR 822 as a packet payload 504 (no header). HR 822 then regenerates SN and TS and other fields of
502 from> 10 for header
Info_de_inic (0) takes the place of conversation samples 0, 1, ..., (R - 1), info_de_inic (R) takes the place of conversation samples R, (R + 1), ... , (2R - 1) and consecutively. If there is discontinuous voice activity, for example, header 0 is followed by a silence interval of L * T ms, then start_info (0) is repeated. The rest of the information (string_in_HO_d_ sinc, HO_u_ sinc, Ack) all has a size much smaller than S, so it fits into the space of a conversation board. These take away the least significant speech bits. For simplicity, the analysis does not take into account the expansion caused by channel coding, but the concept is valid with or without channel coding. Initialization process for the in-band case is shown in figure 3.
2. Out of Band
Fig. 12 is a diagram illustrating an out-of-band initialization according to an exemplary embodiment of the invention. In the out-of-band approach, a separate channel with the appropriate bandwidth to carry only the Info_de_inic concomitantly with conversation is established, which is carried on a conversation channel. The separate channel is called the transient initialization channel (ICT). 0 The system may attempt to allocate sufficient bandwidth to the ICT to allow it to send a full header every T ms. The ICT is designed to have a fixed timing relationship with the talk channel.
Acknowledgments can be sent out of band by allocating a transient acknowledgment channel (TAC) or sent out of band but supported by a direct transient channel. The HO_u Sync can be sent out of band via a transient uplink transfer transfer synchronization channel (TUHOSC). 0 TUHOSC is destroyed when a sinc_de_HO_u Ack is received. 0 The same applies to HO_d sync, which uses a transient downlink link transfer synchronization channel (TDHOSC).
3 Failure Cases
There may be cases where the target ANI_AD will not have the start_HO when the connection transfer execution is completed. Reasons include excessive delay in the signaling network between the two ANI_AD, need to make the connection transfer quickly, etc. In such cases, the network will send a notification to MS, which then restarts the initialization process, as at the beginning of the call.
<td colspan="4">4. Common Case where p_Size Constants</td><td>and</td><td>TS_pass</td><td>are</td>
<td> 0</td><td>case where</td><td>p_size</td><td>and TS_pass</td><td>are</td><td>constants</td><td>it's from</td>
<td>far</td><td>the most</td><td>common for</td><td>voice. In this</td><td colspan="2">case none</td><td>of</td>
considerations caused by possible change of p_size and the TS_step applies. The generic squirt is simplified. HO_d_init is not required. The SY_of_HO_d and sinc_de_HO_u only carry C_SN and C_TS. String_Init carries C_SN. Carries C_TS only if there is a timing change from one string to the next. Terminal (MS) does not have to keep in memory the last values of p_size and TS_step. In the case of HO, the terminal (MS) does not have to determine whether to include p_size in u_ sinc_u.
As described above, the only information in the
Static IP / UDP / RTP and is essential for basic voice, are the RTP time stamp (TS) fields and the RTP sequential number (SN) is also quite desirable. The foregoing scrub achieves transparency for these information fields and provides advantageous header supplementary information compression efficiency. The continuity of all static and non-static fields is maintained during link transfer. Bandwidth management is also simplified because in-band and out-of-band approaches are possible. Since transparency is maintained for RTP TS and RTP SN, it is even possible to switch between the header cropper scheme and the header compression scheme, and vice versa, described here that maintains transparency for all. the fields. Switching to header compression may be necessary when, for example, another voice medium is added.
III. Timer and Reference Based Scheme
A. Summary of Timer and Reference Based Scheme timer and reference based scheme is based on observations that (1) RTP time stamps when generated at the RTP source correlate with a linear function of time elapsed between packets and (2) RTP TS are of the form TSO + index * TS_pass, where TSO and TS_pass are constants and index is an integer (hereinafter the index will be referred to as a packet RTP TS). Therefore, in normal operation, the RTP time stamps received on the decompressor also correlate with a continuously incrementing timer, with a distortion created only by the accumulated timing offset between the source and the decompressor. Since the accumulated time deviation includes mains time deviation (time deviation between source and compressor) and radio time deviation (time deviation between compressor and decompressor), the compressor may calculate an upper limit. for the accumulating time offset by adding an upper limit of the radio time offset to the observed network time offset. 0 compressor then only sends as compressed RTP TS the least significant k bits of packet RTP TS. The decompressor decompresses the RTP TS by first calculating an approximation and then refining the approximation with the information in the RTP TS to determine the exact value. The approximation is obtained by adding to the RTP TS of the previously decompressed header a value proportional to the time elapsed since the previously decompressed header was received. 0 The exact value of RTP TS is determined as closest to the approximation, whose k less significant bits of the corresponding packet RTP TS are equal to the compressed RTP TS. The compressor chooses a value k as the smallest allowable value that would allow the decompressor to decompress correctly based on the upper limit of the accumulated time offset.
B. Voice Case
First, the timer and reference based scheme will be described with respect to the voice. As an example, if the time interval between consecutive chat samples is 20 ms, then header nt RTP time stamp (generated at time n * 20 ms) = header 0 rtp time stamp (generated at time 0) + TS_step * n, where TS_step is a constant depending on the voice codec. Consequently, RTP TS in headers coming to the decompressor also follow a linear pattern as a function of time, but less precisely due to the delay timing deviation between the source and the decompressor. In normal operation (no malfunctions or failures), delay delay deviation is limited to meet real-time talk traffic requirements.
In this scheme, the receiver uses a timer to obtain 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, assume the following:
Last_head is the last successfully decompressed header, where last_ TS is the last RTP TS and last_in_p is the last packet RTP TS (at the receiver);
T is the normal time spacing between two consecutive chat samples;
TS_pass is the increment of RTP TS every T ms;
Current_header is the header of a current packet to be decompressed, where TS_actual is the current RTP TS and ts_actual_em_p is the current packet RTP TS;
RFH is the sequence number of a header whose Ack was received by the compressor, where TS_RFH is the RTP TS and TS_RFH_em_p is the packet RTP TS;
Timer is an incremental timer every T ms, in which the compressor and decompressor each maintain their Timer named E_timer and R_timer respectively;
T_RFH is the value of the Timer when the RFH was received and T_current is the value of the same Timer when the current_header is received; and
R_time offset (n, m) is the observed network timing deviation of header n from header m (header n is subsequently received from header m), where R_time offset (n, m) is calculated by the compressor as if Follow:
R_Time Offset (n, m) = Timer (n, m) - (Header Packet RTP TS n - Header Packet RTP TS), where Timer (n, for header n, R_Time Offset (n, R_Time Offset) network number, quantified in
m) is the elapsed time of header m expressed in ms units of T. m) can be positive or negative, compressor is the timing deviation of units of T milliseconds.
Offset_Time_Ra (n, m) is the radio timing offset of header n relative to header m, predicted by the compressor. The Offset_Ra depends only on the characteristics of the compressor-decompressor channel (CD-CC). 0Ra_Dias does not have to be calculated exactly, a good upper limit for Ra_Dias is sufficient. For example, an upper limit may be Max-time-offset_radio, the maximum time-shift on CD-CC, if known.
Thus, according to the above, cumulative time offset for a packet is calculated as the sum of network and radio time offset:
Additionally, the RTP TS is calculated as follows:
RTP TS = TSO + index * TS_step, where TSO <TS_step and index is an integer.
So TS_last = TSO + index_last * TS_step and
TS_current = TSO + index_current * TS_step.
1. Compressor compressor sends in the compressed header k less significant bits of TS_actual_em_p.
compressor runs the following algorithm to determine k:
Calculate network_timeout_max;
Calculate J1 = Max_dive_timeout + Max_date_time_adjust + J, where J = 2 is a factor to account for the quantization error caused by the Compressor and decompressor Timers, which can be +1 or -1; and
Find the smallest integer k that satisfies the condition:
(2 * J1 + 1) <2<sup>k</sup>.
Compression timing deviation can be calculated according to three different methods, namely a first method illustrated in Fig. 13, a second method illustrated in Fig. 14 and a third method illustrated in Fig. 15. The second and third methods are described. below as Option 1 and Option 2, respectively. The first method is suitable for calculating network time deviation. However, preferred methods for calculating compressor network time offset are the second and third methods described as Option 1 and Option 2, respectively, below.
As illustrated in Fig. 13, according to the first method, the network time offset for a particular packet in the compressor is calculated using information relating to the immediately preceding packet. Thus, for example, the network timing offset for packet 2 (j2) is calculated using packet-related information, the network timing offset for packet 3 (j3) is calculated using packet-related information. 2, the network timing offset for packet 4 (j4) is calculated using packet-related information and the network timing offset for packet 5 (j5) is calculated using packet-related information.
Thus, according to Fig. 13, the network timing offset for packet 2 is equal to the calculated timing offset j2, the network timing offset for packet 3 is equal to the calculated timing offset j3, the network time offset for packet 4 equals calculated time offset j4 and network time offset for packet 5 equals calculated time offset j5.
Option 1:
The steps used to calculate network time offset for the second method of Option 1 are shown in Fig. 14. In Option 1, the network time offset for a particular packet is calculated using information related to a reference packet. Thus, assuming that packet 2 is the reference packet as illustrated in Fig. 14, packet 3 timing deviation j3 is calculated using reference packet 2 related information, packet 4 timing deviation j4 is calculated using reference packet 2 related information and packet 5 timing deviation j5 is calculated using information related to reference package 2.
According to the second method of Option 1 as illustrated in Fig. 14, if it is assumed that the timing offset j3 = 2, timing offset j4 = 3 and timing offset j5 = -1, then before packet 5 Deviation_time_R_min = 2 and the
Deviation_time_R_max = 3, whereas gue 5
Deviation_Time_R_min = -1 and Deviation_Time_R_max = 3.
Thus, the maximum network time deviation (Max) in packet 5 = Time_Shift_R_max - Time_shift_R_min = 4. Consequently, the Network_time_shift_max for packet 5 is 4. The equations for calculating the time shift
<td>network according to the method</td><td>gives</td><td>Option 1</td><td>is</td><td>your</td><td>description</td>
<td>are presented below.</td><td></td><td></td><td></td><td></td><td></td>
<td>0 time shift</td><td>in</td><td>network</td><td colspan="2">a package</td><td>current is</td>
<td>calculated according to the method</td><td>gives</td><td>Option 1</td><td>as if</td><td colspan="2">Follow:</td>
R_Time Deviation (Current_header, RFH) = (Actual_T_RFH) - (TS_actual_em_p - TS_RFH_em_p);
Update the
Deviation_Time_R_min,
Runtime_offset_R_max and where Runtime_offset_R_max is set to Max {Runtime_offset (j, RFH)}, for all headers already sent since Runtime_offset (j, RFH)},
RFH and including RFH.
set to all
Min headers sent from RFH and including RFH; and
Calculate network_timeout_max (time_offset_R_max - time_offset_R_min).
It should be noted that the Runtime_Tax Deviation and R_min_Tax Deviation can be positive or negative, but the (R_max_Tax Deviation - R_min) is positive.
Option 2:
The steps used to calculate network time drift for the third method of Option 2 are illustrated in Fig. 15. In Option 2, the network time drift in a particular packet is calculated using time drift calculations between the packet of interest. and each of a predetermined number of previous packets. The predetermined number of previous packets is defined as a window, and such window may be of any value. In the example shown in Fig. 15, the window has a value of 4 previous packages. The window could be set to any other value, such as 7 packages. In addition, 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 time offset for packet 5 is calculated using information related to 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 time offset for packet 5 related to each of packet 1 is j (5, 1) = -2, packet 2 is j (5, 2) = 3, packet 3 for j (5, 3) = 4 and packet 4 for j (5, 4) = 7, then max_display_timeout = 7. The equations for calculating the network time offset according to the third method of Option 2 and a description thereof are presented below.
Network time offset of a current packet is calculated according to the Option 2 method as follows:
Calculate Deviation_Time_R (Current_header, j) = (T_actual - T_j) - (TS_actual_em_p - TS_j_em_p) for all headers j before the current header and belonging to a window W, where T_j is the timer value when header j was received and TS_j_em_p is the packet RTP TS of header j; and
Calculate network_timeout_max = | Max Deviation_Time_R (Current_header, j) | over all j in window W.
In the case where feedback from the decompressor is available, window W includes headers sent since the last header known to have been received correctly (eg, confirmed). In case there is no feedback, window W includes the last L headers sent, where L is a parameter.
2. Decompressor
To decompress the current_header RTP TS, the receiver calculates the elapsed time since the last_header was received, in units of T ms. This time, Timer (Current_header, Last_header) is added to TS_last_in_p, to provide an approximation of TS_actual_in_p. The receiver then determines the exact value of TS_current_in_p by choosing the nearest approximation value, whose k least significant bits are equal to the compressed RTP TS. Then TS_actual is calculated as TSO + (TS_actual_in_p) * TS_step.
Timer (Current_header, Last_header) can be calculated as (Current_T - Last_T), where Current_ and T_Last are the values of Timer_R when Current_header and Last_header were received, respectively.
3 Proof of accuracy
In order to prove corrections to the timer-based and reference-based schema, the following is assumed:
Approx_TS is the approximation of TS_actual_em_p, calculated by the decompressor as TS_last_em_p +
Timer (Current_header, Last_header); and
TS_Exact is the exact value of TS_actual_em_p.
Based on the above then:
| Approx_TS - TS_Exacto | <= | Time Offset (Current_header, Last_header) |;
Due to the setting of Max_dispatch_time on the compressor:
I Time Offset (Current_header,
Last_header) | d Jl,
Where Jl = Max_team_timeout +
Max_deviation_time_radio + J.
J is an added factor to account for the quantization error caused by the Compressor and decompressor Timers, which can be +1 or -1. Therefore, J = 2 is sufficient.
Thus, it follows that:
| Approx_TS - TS_Exacto | d jl
To unambiguously calculate the TS_Exact, it is sufficient to choose k such that the condition (2 * Jl + 1) <2<sup>k</sup> be satisfied.
4 Bad Packing Case Before the Compressor Bad packet sorting can be detected by a decreasing RTP sequence number (RTP SN). When this happens, the compressor may encode packetized RTP TS using a different scheme, for example, VLE. The decompressor is notified of the different encoding by appropriate indicator bits in the compressed header.
Another option is to apply the Timer Based Scheme algorithm and a Normal Reference - Poor sorting will likely result in a higher value of k.
5 Uplink
In wireless systems, for the uplink direction, the network time offset is zero (since the RTP source and compressor are located at the wireless terminal) and the radio time offset is usually limited and controlled. to stay very low. Therefore, expected k will be very low and constant, which minimizes header size fluctuation. This is a very significant advantage for bandwidth management, since for uplink, the terminal typically has to request increased network bandwidth. Also, there is no bad package ordering. As a result, the timer-based scheme is extremely well suited for uplink.
6 Downlink
For downlink, the network time offset is not zero, but the overall time offset is usually small to meet real-time requirements. The expected value of k will be the same small and usually constant. There may be more fluctuation in k, but bandwidth management is not so much an issue as the network controls bandwidth allocation.
7 Link Transmission
In cellular systems, there is an MS to network radio link and a network to MS radio link, called uplink and downlink respectively. When compression / decompression is applied to cellular links, there is an MS-based function, MS_AD (MS adapter), which performs compression and decompression for uplink and downlink respectively. There is a network-based entity called ANI_AD (access network infrastructure adapter) that performs decompression and compression for uplink and downlink, respectively.
A specific case of link transmission to consider is link transmission between ANI_AD, where an interruption caused by switching from the old ANI_AD to a new ANI_AD may occur. The question is how to maintain the continuity of information during link transmission so that after compression / decompression link transmission in MS_AD and the new ANI_AD continues without interruption.
There are two alternative methods for link transmission, described below:
The. First Method The first method uses the scheme of recording context information exchanged between ANI_AD and MS_AD, with the handshake method, as disclosed in the request related to
Series 09/522497, filed March 9, 1999, the same date as this application for AN EFFICIENT HANDOFF PROCEDURE FOR HEADER COMPRESSION by K. Le. For RTP TS, context information contains the full RTP TS of a reference header. Shortly after link transmission, the compressors (MS_AD for uplink and temporarily leave down)
ANI_AD to use the timer-based scheme send a compressed RTP TS related to the reference value. For example, VLE encoding may be used as disclosed in the application relating to Serial No. 09/522497, filed March 9, 1999, the same date as the present application for AN EFFICIENT HANDOFF PROCEDURE FOR HEADER COMPRESSION by K. Le. Once acknowledgment has been received, the compressor uses the confirmed value as RFH and switches back to the timer based scheme.
B. Second Method
The second method continues to use the timer-based scheme throughout the link transmission.
i. Downlink
There is no discontinuity on the receiver side, which is MS. The role of the compressor is transferred from one ANI_AD to another. After link transmission, headers are routed in a new path through the new ANI_AD instead of the old ANI_AD.
- compressor
Old ANI_AD transfers to the new ANI_AD a photograph of the following information: T_RFH, TS_RFH_in_p, current value of E_timer, TSO, and TS_pass using the handshake method. (Photo values will be indicated with an asterisk, eg, T_RFH *). The new ANI_AD initializes its S_timer with current value of S_timer received from the old ANI_AD and starts incrementing that timer every T ms. Initializing the timer_ with the current value of timer_ from the old ANI_AD is a conceptual description. If there is a single timer_ shared by multiple streams, the actual timer_ is not reset. Instead, the deviation between this S_timer and the value of the old ANI_AD is written. The deviation is taken into account in future calculations. To compress the truly first header after link transmission, the new ANI_AD sends the least significant k bits of TS_actual_em_p. The new ANI_AD determines k, the number of bits to use, as follows:
J2 = Limit
R_Time Deviation (Current_head, Max_Radio_Time + J, top
RFH * 'of +
Where k is selected to satisfy a condition of (2 * J2 + 1) <2<sup>K</sup>.
Above, Max_address_radio is the maximum time offset in the segment between the new ANI_AD and MS_AD.
a
Upper limit of
R_time deviation (Current_header, RFH *) is calculated as follows:
| Timer (Current_header, RFH *) - (TS_actual_in_p
TS_RFH_in_p *) | + T_transfer, in gue
Timer (Current_header, RFH *) is (Current_T - T_RFH *);
T_current is the value of timer_ in the new ANI_AD when the current_header has been received;
T_RFH * is the value received from the old ANI_AD;
T_transfer is an upper limit of time to transfer context information from the old ANI_AD to the new ANI_AD, expressed in units of T ms; and
J = 2.
- Decompressor
To decompress the current_header RTP TS, the receiver calculates the elapsed time since RFH was received, in units of T ms. This time, Timer (Current_header, RFH), is added to TS_RFH_em_p to give an approximation of TS_actual_em_p. The receiver then determines the exact value of
TS_actual_em_p by choosing the nearest approximation value, whose k least significant bits are equal to the compressed RTP TS. Actual TS is then calculated as TSO + (TS_actual_in_p) * TS_step.
The elapsed time since RFH was received can be calculated as (T_current - T_RFH).
- Failure Case
When context information cannot be transferred in time to the new ANI_AD, the new ANI_AD will send the full RTP TS until it receives an acknowledgment.
ii. Uplink Decompressor role is transferred from one ANI_AD to another. The compressor remains anchored to the MS.
- Decompressor
Old ANI_AD transfers to the new ANI_AD a photograph of the following information: T_RFH *, TS_RFH_in_p *, current R_timer value *, TSO, and TS_pass using the handshake method. The new ANI_AD initializes its R_ timer with current R_ timer value received from the old ANI_AD and starts incrementing that timer every T ms. Initializing R_timer with the current ANI_AD R_timer current value is just a conceptual description. If there is a single R Timer shared by multiple streams, the actual R Timer is not reset.
Instead, the deviation between this R_ timer and the value of the old ANI_AD is written. This deviation is taken into account in future calculations. To decompress the truly first header after link transmission, the new ANI_AD calculates Timer (Current_header, RFH) adds it to to approximate TS_actual_in_p
TS_RFH_em_p *, the receiver then determines the exact value of TS_actual_em_p by choosing the nearest approximation value, whose k least significant bits are equal to the compressed RTP TS. Actual TS is then calculated as TSO + (TS_actual_in_p) * TS_step.
Timer (Current_header, RFH) can be estimated as (T_actual - T_RFH *). Current_T is the value of timer_R when Current_header was received.
- compressor
MS_AD sends the least significant k bits of TS_actual_em_p. Determines k, the number of bits to use, as follows:
Calculate
J2
Limit
R_Time Deviation (Current_header, Max_Ray_Time Deviation + J, top
RFH *) of +
Where k is selected to satisfy a condition of (2 * J2 + 1) <2<sup>K</sup>.
Here, Max_talk_address is the maximum time offset in the segment between the new ANI_AD and MS_AD.
a
Upper limit of
R_Time Deviation (Current_header, RFH *) is calculated as | Timer (Current_header, RFH *) (TS_acutal_header_in_p - TS_RFH_em_p *) | + T_transfer, where Timer (Current_header, RFH *) is (T_actual - T_RFH *);
T_current is the value of timer_ in the new ANI_AD when Current_header was received;
T_RFH * is the value received from the old ANI_AD;
T_transfer is an upper limit of time to transfer context information from the old ANI_AD to the new ANI_AD, expressed in units of T ms; and
J = 2.
- Failure Case
When context information cannot be transferred in time to the new ANI_AD, the new ANI_AD will notify the MS_AD sending the full RTP TS until it receives an acknowledgment.
8 Scheme Performance
Due to real-time talk requirements, the accumulated time offset in normal operation can be expected to be at most only a few times T ms. Therefore, a value of k around 4 or 5 is sufficient as a time offset of up to 16 to 32 chat samples can be corrected.
The advantages of this scheme are as follows:
Compressed header size is constant and small. The compressed header typically includes a message type, which indicates the message type (kl bits), a bit mask indicating which fields are changing, and a field containing the least significant k bits of current_index ( k bits). Assuming that a 4-bit MSTI bitmask is used, and kl = 4, the compressed header size when only RTP TS changes (this is by far the most frequent case) is 1.5 bits. Also, the size does not change as a function of the silence interval length.
No synchronization is required between the timer process and the decompressor process.
Error resistance, since the partial RTP TS information in the full header is autonomous and only needs to be combined with the receiver timer to produce the full RTP TS value. Loss or corruption of a header will not invalidate subsequent compressed headers.
compressor needs to keep little memory information:
T_RFH, TS_RFH_in_p, Runtime_times_R_max, Runtime_times_R_min, TSO and TS_pass in Option 1 and {Tj, p-TS-j} for all j in window W, TSO and TS_pass in Option 2.
C. Reduction of Time Deviation
Due to the real-time talk traffic requirements, it can reasonably be expected that the various timing deviations described above are in the order of a few Tms in normal operation. However, cases cannot be excluded where the time shift is greater and would therefore require a larger k. For example, abnormal conditions may occur in the path from RTP source to receiver (failures, etc.), during which time offsets become excessive. Also, cases may occur where a constant k value is desired or desirable. To deal with these cases, a time offset reduction function can be implemented as a terminal for the compressor to filter out overdue (i. e., time deviation exceeding some threshold value).
In the stationary case (without link transmission), the time offset is calculated as J1 and compared to a stationary limit as follows:
(Time_offset_n_max Time_offset_N_min) + Max_off_time_offset +
J.
In the case of link transmission, the time offset is calculated as J2 and compared to a link transmission limit as follows:
J2 = | Timer (Current_header, RFH *) (TS_actual_em_p - TS_RFH_em_p *) | + T_transfer +
Max_deviation_time_radio + J.
The main difference from the stationary case without link transmission is the addition of T_transfer. In practice, to be able to perform link transmission within 100 ms, T_transfer must be limited to around 100 ms, so T_transfer = about 5 or 6 in T ms units (T = 20 ms). A value of k = 5 is sufficient.
Stationary and link transmission limits may or may not be the same.
D. Video Case
<td>At the</td><td>case</td><td>of a</td><td>video source</td><td>RTP</td><td>, it is not</td><td>necessarily</td>
<td>truth</td><td>what</td><td>there is</td><td>a spacing</td><td>in</td><td>time</td><td>constant between</td>
<td>bundles</td><td>and,</td><td>beyond</td><td>In addition, the TS</td><td>in</td><td>RTP</td><td>does not increment</td>
<td colspan="3">necessarily from</td><td colspan="2">a steady step</td><td>on one</td><td>package for</td>
<td>Following</td><td colspan="2">. Yet,</td><td>RTP TS and</td><td colspan="2">spacing</td><td>of time between</td>
packets are discrete values. Thus, as follows:
packet RTP time stamp m = packet 0 RTP time stamp (generated at time 0) + TS_step * [index + setting (m)], where TS_step is a codec dependent constant and setting (m) is a value integer which depends on my reflecting differences in linear behavior as in voice; and the time spacing between two consecutive packets is a multiple integer value of T ms.
In the following, this behavior in the RTP source is referred to as an adjusted linear behavior. Using the same gue notation for voice, TS_last = TSO + TS + step * [last_index + fit (last_index)] and TS_current = TSO + TS_step * [current_index] .The fit parameter can be either positive or Therefore, the main difference compared to voice is the additional term Adjustment.
RTP TS in headers that go to the decompressor also follows a time-adjusted linear pattern, but less rigorously, due to the delay timing deviation between the source and the decompressor. In normal operation (no malfunctions or failures), the delay delay deviation is limited to meet real-time conversation traffic rules.
As above it is assumed that the RTP TS in Current_header packet = current_index + adjustment (current_index). The same notation will be used will be used for TS_actual_em_p, for example,
Compressor compressor sends in the compressed header the least significant k bits of TS_actual_em_p. The algorithm for determining k is the same as for voice.
Decompressor algorithm for determining k is the same as for voice.
1. Link Transmission
The two alternative methods for call forwarding described for voice also apply to video.
2. K value
For voice, it has been 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 Adjustment. Since the video is structured at 30 frames per second, | I set <30. Therefore, k = 7 or 8 bits should be sufficient in normal operation.
Various embodiments of the present invention are illustrated and / or specifically described herein. However, it will be understood that modifications and variations of the present invention are encompassed by the above teachings and to the extent of the appended claims without departing from the intended spirit and scope of the invention.
While the present invention has been described in detail and graphically in the accompanying drawings, it is not limited to such details, since many changes and modifications recognizable to those skilled in the art can be made to the invention without departing from its spirit and scope.
In the following, further aspects are described to facilitate understanding of the invention.
In a first further aspect, a method of transmitting a current header field of a current packet using a timer-based compression technique on a network between a source and a receiver is described, the method may comprise the steps of providing from a compressor for a decompressor an initial value of a header field; calculating in the compressor a compressed header field of the current packet based on the current header field of the current packet and timing delay, wherein said calculation step may comprise the steps of: calculating a time delay effect that the network between a source and said decompressor may have on packet transmission, and calculating the compressed header field as a part of a field value, said part could be a function delay time; receive the compressed header field and the decompressor, delay time of the current packet in the decompressor; calculate the current packet header field based on the time elapsed in the decompressor between receiving the current packet compressed header field and receiving a previous packet header field that was decompressed and a previous packet field uncompressed value ; and correcting the current header field calculated based on the compressed header field received on the decompressor. Where said calculation of a time delay effect may comprise the steps of: calculating a network time delay effect prior to the compressor; and calculating a network delay delay effect between the In addition, said network effect between the compressor and the decompressor may be adjusted to an upper limit value for the delay delay. Also, said calculation of a network delay time effect, prior to the compressor, may comprise calculating the timing delay effect of a current packet using information relative to a reference packet. Further, said calculation of a network delay time effect prior to the compressor may comprise calculating the timing delay effect of a current packet using information with respect to said current packet and each of a predetermined number of packets. previous Wherein said calculating a time delay effect of the network before the compressor may comprise calculating the time delay effect of a current packet using information with respect to said current packet and each previous packet to a reference packet. Further, said computation in the current packet compressed header field compressor may comprise: calculating the current packet compressed header field as the least significant k of the field value, where k is an integer. Also, said header field may comprise a time marker. Also, said header field may comprise an RTP time marker. Furthermore, said computation in the compressed header field packet of the current packet may comprise converting the field value to another value, referred to as a packed value, which requires fewer bits to represent; and computing the compressed header field of the current packet as the least significant k bits of the packet value, where k may be an integer.
In yet another additional aspect, a method of decompressing a current header field of a current packet transmitted in a network from a compressor to a decompressor is described, the method may comprise the steps of: receiving a compressed header field from a current packet in the decompressor, said compressed header field can be calculated on the compressor as a part of a field value that can be calculated as a delay time effect that the network between a source and the decompressor has in the transmission of packets; calculating an approximation of the current packet header field in the decompressor based on the time elapsed since the arrival of a previous compressed header field in the decompressor and an uncompressed value of the previous packet field; calculate a header field correction value for the current packet in the decompressor that may be based on the compressed header field of the current packet; and decompressing the compressed header field of the current packet in the decompressor by adjusting the approximation of the current packet header field to a value based on the correction value of the header field.
Furthermore, said timing delay effect that the network between the source and the decompressor may have on packet transmission may be calculated by calculating a timing delay effect of the network between the compressor and calculating a timing delay effect. between the compressor and the decompressor. Furthermore, said grid delay time effect between the compressor and decompressor may be adjusted to an upper limit value for delay time. Wherein said calculating a time delay effect of the network before the compressor may comprise calculating the time delay effect of a current packet using the reference packet information. Also, said calculation of a network delay time effect prior to the compressor may comprise calculating the timing delay effect of a current packet using information with respect to said current packet and each of a predetermined number of times. previous packages. 0 Said calculation of a network delay time effect prior to the compressor may comprise calculating the timing delay effect of a current packet using information relating to said current packet and each previous packet to a reference packet. Similarly, the compressed header field can be calculated as the least significant k bits of the field value, where k can be an integer. In addition, the compressed header field can be calculated as k least significant bits of a packed value, where k can be an integer; and where the decompressor may calculate an approximation of the packaged value based on the time elapsed since the arrival of a previous packet and a packaged decompressor value of the previous packet.
In yet another aspect, a method of performing a link transmission between first and second network entities in a system is described, the first and second network entities may connect a mobile decompressor to a source terminal when the mobile decompressor is located on the first and second network. second areas, respectively, the method may comprise receiving an initial value of a header field in the first network entity and the mobile decompressor from a source terminal, the first network entity connecting the mobile decompressor in a first area to a source terminal; receiving a header field from a first packet that is addressed to the mobile decompressor in the first network entity from the source terminal, compressing the first packet header field in the first network entity and sending a first compressed header field from the first packet to the mobile decompressor, said first compressed header field may be calculated as a part of a field value, which may be calculated as a first time delay effect that the network may have between the source terminal and the mobile decompressor in packet transmission; receiving and decompressing the first packet header field of the first packet in the mobile decompressor based on the time elapsed since the arrival of a previous packet and the uncompressed field value of the previous packet; the mobile decompressor can move from the first area to the second area; transmitting boot information to the second network entity to initialize the second network entity for compression; receiving and compressing, in the second network entity, a header field of a second packet from the source terminal that can be addressed to the mobile decompressor, and sending a second compressed header field of the second packet to said mobile decompressor. The second compressed header field may be calculated as a part of a field value that is calculated as a second time delay effect that the network may have, between the source terminal and the mobile decompressor in packet transmission and time to transmit initialization information to the second network entity; and receiving and decompressing the second packet header field of the second packet in the mobile decompressor based on the time elapsed since the arrival of a previous packet and the uncompressed field value of the previous packet. Similarly, each of said first and second effects of the time delay that the network between the source terminal and the decompressor may have on packet transmission may be calculated by calculating a time delay effect of the network before the compressor. , and calculating a grid delay effect between the compressor and the decompressor. Furthermore, said grid delay time effect between the compressor and decompressor may be adjusted to an upper limit value for delay time. Also, said first packet may be a packet immediately preceding link transmission and said second packet may be a packet immediately succeeding link transmission. Further, said calculation of a network delay time effect prior to the compressor may comprise calculating the timing delay effect of a current packet using the reference packet information. Also, said calculation of a network delay time effect prior to the compressor may comprise calculating the timing delay effect of a current packet, using information about said current packet each of a predetermined number of previous packets. Further, said calculation of a network delay time effect prior to the compressor may comprise calculating the timing delay effect of a current packet using information relating to said current packet and each previous packet to a reference packet. . Furthermore, said header field comprises a time marker. Similarly, the compressed header field can be calculated as the least significant k bits of the field value, where k can be an integer. In addition, the compressed header field can be calculated as the least significant k bits of a packed value, where k can be an integer; and wherein the decompressor may calculate an approximation of the packet value based on the time elapsed since the arrival of a previous packet and a packaged value of the previous packet.
In another further aspect, a method of performing a link transmission between first and second network entities is described, the first and second network entities may connect a mobile compressor with a receiver terminal when the mobile compressor is located in the first and second areas. respectively, the method may comprise receiving an initial value of a header field in a first network entity of a mobile compressor; receiving in the first network entity a first compressed header field from a first packet received from the mobile compressor, said first compressed header field may have been calculated on the mobile compressor as a part of a field value which is calculated as a first time delay effect that the network may have between a source and a decompressor in the transmission of packets; decompressing in the first network entity the first compressed header field of the first packet based on the time elapsed since the arrival of a previous packet and the uncompressed field value of the previous packet; the mobile compressor can move the first area to the second area; sending boot information to the second network entity to initialize the second network entity for compression; receiving, on the second network entity, a second compressed header field from a second packet received from the mobile compressor, said second compressed header field may have been calculated on the mobile compressor as a part of a field value that is calculated as a second time delay effect that the network may have between the source and the decompressor, packet transmission and time to transmit initialization information to the second network entity; and decompressing on the second network entity the second compressed header field of the second packet based on the time elapsed since the arrival of a previous packet and the uncompressed field value of the previous packet. In addition, said first and second time delay effects that the network may have between the source and the decompressor on packet transmission may be calculated by calculating a time delay effect of the network before the mobile compressor, and calculating a grid delay effect between the compressor and the decompressor. Likewise, said grid delay effect between the compressor and decompressor may be adjusted to an upper limit value for delay time. Further, said first packet may be a packet immediately preceding the link transmission and said second packet may be a packet immediately succeeding the link transmission. Also, said calculation of a time delay effect of the network before the mobile compressor may comprise calculating the time delay effect of a current packet using information relative to a reference packet. Further, said calculation of a network delay time effect prior to the mobile compressor may comprise calculating the timing delay effect of a current packet using information with respect to said current packet and each of a predetermined number of packets. previous Further, said calculation of a network delay time effect prior to the mobile compressor may comprise calculating the timing delay effect of a current packet using information relating to said current packet and each previous packet up to a packet. reference. Also, said header field may comprise a time marker. In addition, the compressed header field can be calculated as the least significant k bits of a packed value, where k can be an integer; and where the decompressor may calculate an approximation of the packaged value based on the time elapsed since the arrival of a previous packet and a packaged decompressor value of the previous packet. Similarly, the compressed header field can be calculated as the least significant k bits of the field value, where k can be an integer.
In another further aspect a communication system is described, the system may comprise a source providing a plurality of packets, each packet may include a header field, the source may be coupled to a network; a receiver which may include a decompressor; a network entity that may be coupled to the network and the receiver by a network between the network entity and the receiver, the network entity may include a compressor for performing header field compression for at least some of the packets sent from the source and directed to the receiver, the network entity may include a time delay reduction function for calculating the time delay in packets directed to the terminal receiver and discard packets that may have a time delay that is greater than a predetermined value, where the time delay may be calculated as a total of a time delay value caused by the network between the source and the decompressor that may be included in the receiver. In addition, said timing delay may be calculated by calculating a grid delay effect before the compressor, and calculating a grid delay effect between the compressor and the decompressor. Also, said grid delay time effect between the compressor and decompressor may be set to an upper limit value for delay time. In addition, said network delay time before the compressor may be calculated by calculating the effect of the timing delay of a current packet using information relative to a reference packet. Likewise, said calculation of a network delay time effect prior to the compressor may comprise calculating the timing delay effect of a current packet using information with respect to said current packet and each of a predetermined number of previous packets. . Further, said calculation of a network delay time effect prior to the compressor may comprise calculating a timing delay effect from a current packet using information relating to said current packet and each previous packet to a reference packet. Similarly, the compressed header field can be calculated as the least significant k bits of a value.
100 packaged, where k can be an integer; decompressor can calculate an approximation of the value based on the time elapsed since the previous arrival and a packaged previous decompressor value.
Lisbon, 5th March 2014 and where the bundled a bundle package
101
Contents4
49 members in 16 offices
Priority claims4
| Document | Office | Kind | Date |
|---|---|---|---|
| 52236300 | United States of America | A | |
| 52236300 | United States of America | A | |
| 522363 | – | – | – |
| 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 | |
| ES2339742T3 | 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 | |
| PT2490398EThis record | Portugal | E | |
| DK2490398T3 | Denmark | T3 | |
| ES2460140T3 | Spain | T3 | |
| BRPI0109097B1 | Brazil | B1 |
Numbers
- Publication
- 2490398
- Publication, DOCDB
- 2490398
- Publication, EPODOC
- PT2490398E
- Application
- 121653299
- Application, DOCDB
- 12165329
- Application, EPODOC
- PT20120165329T
Titles2
- English
- A TECHNIQUE FOR COMPRESSING A HEADER FIELD IN A DATA PACKET
- Portuguese
- TÉCNICA PARA COMPRIMIR UM CAMPO DE CABEÇALHO NUM PACOTE DE DADOS
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