ES2460140T3 - Una técnica para comprimir un campo de cabecera en un paquete de datos - Google Patents

Abstract

Un procedimiento de comunicación que comprende: proporcionar a una fuente (102) una pluralidad de paquetes, incluyendo cada paquete un campo de cabecera, estando la fuente acoplada a una red; llevar a cabo por un compresor incluido en una entidad de red que está acoplada a la red y a un receptor (130) la compresión del campo de cabecera para al menos algunos de los paquetes enviados desde la fuente (102) y dirigidos al receptor (130) que incluye una descompresor (137); y calcular la fluctuación de retardo en la entidad de red en los paquetes dirigidos al receptor (130) estando dicho procedimiento además caracterizado por: descartar paquetes que tienen una fluctuación que es mayor que un valor predeterminado, en donde la fluctuación de retardo se calcula como un total de una cantidad de fluctuación de retardo causada por la red entre la fuente (102) y el descompresor (137) incluido en el receptor (130) .

Description

Una técnica para comprimir un campo de cabecera en un paquete de datos

5 CAMPO TÉCNICO

La presente invención se refiere a un procedimiento y aparato para comprimir un campo de cabecera en un paquete de datos. Más específicamente, la presente invención se refiere a un procedimiento y aparato para comprimir un campo de cabecera de un paquete de datos utilizando un Esquema Basado en un Temporizador y una Referencia.

10 Para los multimedios en tiempo real basados en el Protocolo de Internet (IP), el Protocolo de Transferencia en Tiempo Real (RTP) se utiliza de manera predominante encima del Protocolo de Datagramas de Usuario (UDP / IP). El RTP se describe en detalle en el documento RFC 1889. El tamaño de las cabeceras combinadas de IP/UDP/RTP es de al menos 40 octetos para el IPv4, y de al menos 60 octetos para el IPv6. El sobregasto de entre 40 y 60 octetos por

15 paquete puede considerarse oneroso en sistemas (p. ej., tales como las redes celulares) donde la eficiencia espectral es una preocupación primaria. En consecuencia, existe una necesidad de mecanismos adecuados de compresión de cabeceras de IP/UDP/RTP. Por ejemplo EP 0 768 777 A2 describe ciertos aspectos de la gestión de la movilidad. Un esquema actual de compresión de cabeceras se describe en el documento RFC2508, que es capaz de comprimir la cabecera de IP/UDP/RTP, de 40 / 60 octetos, en 2 ó 4 octetos por enlaces punto a punto. Los algoritmos existentes de

20 compresión de cabeceras se basan en la observación de que la mayoría de los campos de las cabeceras de paquetes IP permanecen constantes en un flujo de paquetes durante la duración de una sesión. Así, es posible comprimir la información de cabecera estableciendo un estado de compresión (la información de cabecera completa) en el descompresor, y llevando simplemente una cantidad mínima de información de cabecera desde el compresor al descompresor.

25 El documento RFC2508 se basa en la idea de que, la mayor parte del tiempo, los campos del RTP que cambian entre un paquete y el siguiente, tal como el sello temporal del RTP, pueden predecirse por extrapolación lineal. Esencialmente, la única información que tiene que enviarse es un número de secuencia, utilizado para la detección de errores y de pérdidas de paquetes (así como un identificador de contexto). Cuando el remitente determina que la

30 extrapolación lineal no puede aplicarse al paquete actual, se envía una información de diferencia de primer orden con respecto al paquete inmediatamente precedente. Para iniciar la sesión, se envía una cabecera completa. Además, cuando el receptor determina que hay pérdida de paquetes (según lo detectado por un número de secuencia incrementado en más de 1), el receptor solicitará explícitamente al remitente que transmita la cabecera completa a fin de permitir una resincronización.

35 Sin embargo, la compresión de cabecera definida en el documento RFC2508 no está bien adaptada para ciertos entornos (tales como los entornos celulares o inalámbricos), donde el ancho de banda es prohibitivo y los errores son comunes. En el esquema de compresión de cabeceras del documento RFC2508, se supone que el sello temporal del RTP tiene, la mayor parte del tiempo, un patrón linealmente creciente. Cuando la cabecera es conforme al patrón,

40 esencialmente sólo se necesita un número de secuencia corto en la cabecera comprimida. Cuando la cabecera no es conforme al patrón, la diferencia entre los sellos temporales de RTP de la cabecera actual y los de la anterior se envía en la cabecera comprimida. Es posible una optimización adicional utilizando una tabla de codificación. Este enfoque tiene tres inconvenientes. El primero es que no es robusto ante los errores, ya que la pérdida de la cabecera anterior invalidará la descompresión de la cabecera actual. El segundo es que las diferencias o saltos del sello temporal del

45 RTP pueden ser muy grandes, desbordando así la tabla de búsqueda de codificación. Por ejemplo, si el medio es la voz, tales grandes diferencias pueden ser causadas por un intervalo de silencio. El tercero es que el tamaño de la diferencia codificada resultante es variable, lo que hace más difícil predecir y gestionar el ancho de banda a adjudicar.

Por lo tanto, hay una necesidad para un esquema de compresión de cabecera que pueda asimilar un salto arbitrario en

50 el valor del campo (p. ej., en el valor del sello temporal del RTP), que brinde un tamaño más coherente y constante, y que sea más robusto ante los errores.

RESUMEN DE LA INVENCIÓN

55 Según una realización de la presente invención, se proporciona una técnica de descompresión de cabecera basada en temporizador. Un origen del RTP genera un campo de cabecera, tal como un sello temporal del RTP. El sello temporal se envía por una red a un compresor. En el compresor, se utiliza una función de reducción de fluctuación de retardo (JRF) para determinar si la fluctuación de retardo del sello temporal (cabecera) recibido es excesivo. Si la fluctuación de retardo es excesiva, se descarta el paquete. En caso contrario, el compresor calcula un campo de cabecera

60 comprimida (sello temporal comprimido) en base al sello temporal del RTP y un valor inicial del sello temporal. El sello temporal comprimido representa la fluctuación de retardo que se calcula como un efecto que la red entre el origen y el descompresor tiene sobre la transmisión de paquetes. La fluctuación de retardo calculada es una acumulación de fluctuación de retardo de red, que representa el efecto que la red entre el origen y el compresor tiene sobre la transmisión de paquetes, y de fluctuación de retardo de radio, que representa el efecto que la red entre el compresor y el descompresor tiene sobre la transmisión de paquetes. Debería observarse que el término “red”, según se utiliza en el presente documento, está concebido como un término amplio, a fin de no excluir, por ejemplo, los enlaces de radio en

5 una red de telecomunicaciones inalámbricas. El paquete del RTP, incluyendo el sello temporal comprimido, se transmite entonces por un enlace o red a un descompresor.

El descompresor descomprime el sello temporal comprimido calculando primero una estimación o aproximación del sello temporal, en base al valor actual de un temporizador situado en el terminal (es decir, en base al tiempo

10 transcurrido). La aproximación del sello temporal se refina o corrige luego en base al sello temporal comprimido proporcionado en la cabecera del paquete. De esta manera, el sello temporal para el paquete (cabecera) actual se regenera en base a un temporizador local y un sello temporal comprimido proporcionado en la cabecera actual. El paquete y el sello temporal regenerado se proporcionan luego a un punto extremo del RTP para su procesamiento.

15 El esquema basado en temporizador de la presente invención incluye varias ventajas. El término “esquema basado en temporizador”, según se utiliza en el presente documento, incluye el esquema basado en temporizador que utiliza un sello temporal comprimido, y el esquema basado en temporizador y referencia, según se revela en el presente documento. El tamaño del sello temporal comprimido (u otro campo de cabecera) es constante y pequeño. Además, el tamaño no cambia en función de la longitud del intervalo de silencio. No se requiere ninguna sincronización entre el

20 proceso temporizador en el origen del RTP (que genera el sello temporal) y el temporizador en el proceso descompresor. Además, esta técnica es robusta frente a los errores, ya que la información parcial del sello temporal en la cabecera comprimida es autocontenida y sólo necesita ser combinada con el valor del temporizador del descompresor para producir el valor completo del sello temporal del RTP. La pérdida o corrupción de una cabecera no invalidará las cabeceras comprimidas subsiguientes.

25 Un segundo ejemplo de la presente invención proporciona un esquema de desmenuzamiento de cabeceras en el cual la cabecera (p. ej., incluyendo el sello temporal del RTP) es desmenuzada o retirada del paquete del RTP antes de la transmisión. Un desmenuzador de cabecera y un generador de cabecera se conectan a través de una conexión similar a un circuito (p. ej., un circuito o circuito virtual), o un canal de tasa de bits esencialmente constante. Después de la

30 inicialización, el desmenuzador de cabecera desmenuza o retira la cabecera (incluyendo la retirada del sello temporal y el número de secuencia) de cada paquete, y luego transmite los paquetes sin cabecera al regenerador de cabecera. Para eliminar la fluctuación de retardo de paquetes en el desmenuzador de cabeceras, los paquetes pueden transmitirse con un espaciado temporal según el sello temporal (TS) del RTP en la cabecera. Por lo tanto, en este ejemplo, el sello temporal no se proporciona explícitamente en el paquete del RTP (ni siquiera un sello temporal

35 comprimido). En cambio, la información de temporización se proporciona implícitamente al regenerador de cabeceras, en base a un canal de tasa de bits esencialmente constante, entre el desmenuzador de cabeceras y el regenerador. El canal de tasa de bits esencialmente constante puede proporcionarse de varias maneras distintas.

En esta segunda realización, después de que ocurre la inicialización (p. ej., proporcionando el número de secuencia

40 inicial y el sello temporal al regenerador de cabeceras), el regenerador de cabeceras puede regenerar los sellos temporales para paquetes secuenciales, incrementando un contador de sello temporal local con el valor de TS_tranco cada T msegs, y regenerar los números de secuencia de paquetes incrementando un contador SN local en 1 por cada duración de paquete. Estos campos pueden regenerarse en base a sólo un temporizador o contador local, debido al canal de tasa de bits esencialmente constante proporcionado entre el desmenuzador de cabeceras y el regenerador de

45 cabeceras, en el cual no se introduce ninguna fluctuación de retardo de paquete. Por lo tanto, después de la inicialización, estos campos de cabecera pueden regenerarse en el regenerador de cabeceras con referencia sólo a un reloj local.

Sin embargo, pueden ocurrir uno o más sucesos de discontinuidad básica (p. ej., cambio en el tamaño del paquete o

50 en TS_tranco, un desplazamiento no lineal en el sello temporal, etc.) que, si no se abordan, podrían probablemente invalidar el enfoque de desmenuzamiento de cabeceras que descansa sólo en un temporizador o reloj local para la regeneración de campos. Una cadena de cabecera es una secuencia de cabeceras de paquete con campos conocidos

o linealmente predecibles. La transición desde una cadena a otra puede estar causada por cualquiera entre varios sucesos de discontinuidad. Cuando esto ocurre, el desmenuzador de cabeceras identifica el suceso de discontinuidad

55 y envía información de cabecera actualizada relacionada con el suceso al regenerador de cabeceras, para permitir que continúe la regeneración de sellos temporales y números de secuencia. Puede utilizarse asimismo una técnica similar de proporcionar información de cabecera actualizada cuando hay un traspaso.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

60 La presente invención será más evidente a partir de la siguiente descripción detallada, cuando se considere conjuntamente con los dibujos adjuntos, en los cuales: La Fig. 1 es un diagrama en bloques que ilustra un sistema según una realización a modo de ejemplo de la presente invención; La Fig. 2 es un diagrama que ilustra un formato no comprimido de un paquete del RTP según una realización

5 de la presente invención; La Fig. 3 es un diagrama que ilustra el formato de cabecera de RTP no comprimida según una realización a modo de ejemplo de la presente invención; La Fig. 4 es un diagrama que ilustra un formato de cabecera de RTP comprimida según una realización a modo de ejemplo de la presente invención;

10 La Fig. 5 es un diagrama que ilustra un funcionamiento a modo de ejemplo de la compresión y descompresión de cabeceras según una realización de la invención; La Fig. 6 es un diagrama que ilustra un funcionamiento a modo de ejemplo de la compresión y descompresión de cabeceras según otra realización de la invención; La Fig. 7 es un diagrama que ilustra un funcionamiento a modo de ejemplo del traspaso según una realización

15 de la presente invención; La Fig. 8 es un diagrama en bloques que ilustra una pila a modo de ejemplo según una realización a modo de ejemplo de la presente invención; La Fig. 9 es una tabla que ilustra información que puede proporcionarse en mensajes según una realización a modo de ejemplo de la invención;

20 La Fig. 10 es un diagrama que ilustra un proceso de traspaso según una realización a modo de ejemplo de la presente invención; La Fig. 11 es un diagrama que ilustra una inicialización en banda según una realización a modo de ejemplo de la invención; La Fig. 12 es un diagrama que ilustra una inicialización fuera de banda según una realización a modo de

25 ejemplo de la invención; La Fig. 13 es un diagrama que ilustra las etapas de calcular la fluctuación de retardo de red según un primer procedimiento de la presente invención; La Fig. 14 es un diagrama que ilustra las etapas de calcular la fluctuación de retardo de red según un segundo procedimiento expuesto como la Opción 1 de la presente invención; y

30 La Fig. 15 es un diagrama que ilustra las etapas de calcular la fluctuación de retardo de red según un tercer procedimiento expuesto como la Opción 2 de la presente invención.

MEJOR MODO PARA LLEVAR A CABO LA INVENCIÓN

35 I. Esquema Basado en Temporizador que Emplea un Sello Temporal Comprimido A. Arquitectura

La Fig. 1 es un diagrama en bloques que ilustra un sistema según una realización a modo de ejemplo de la presente

40 invención. Un terminal 102 está conectado con una red IP 108. El terminal 102 puede ser un ordenador personal, o similar, que ejecuta los protocolos RTP / UDP / IP, y que proporciona muestras de voz paquetizadas en paquetes del RTP para su transmisión por la red 110. El terminal 102 incluye un punto extremo 104 del RTP que identifica este terminal (p. ej., incluyendo la dirección IP, el número de puerto, etc.) bien como un origen o bien como un destino para los paquetes del RTP. La red IP se proporciona como un ejemplo; sin embargo, pueden utilizarse en cambio otros tipos

45 de redes conmutadas por paquetes, o similares. Debería observarse que el término "red", según se utiliza en el presente documento, está concebido para ser un término amplio, a fin de no excluir, por ejemplo, los enlaces de radio en una red de telecomunicaciones inalámbricas. El terminal 102 también incluye un temporizador local 103 para generar un sello temporal.

50 Una infraestructura de red de acceso (ANI) 110 está conectada con la red IP 108. Un terminal inalámbrico 130 está acoplado, mediante el enlace 140 de radiofrecuencia (RF) con la ANI 110. El terminal inalámbrico 130, según se describe en el presente documento, podría ser, por ejemplo, un compresor inalámbrico o un descompresor inalámbrico, según su entorno. Esto ocurre en particular cuando el origen de los paquetes o el destino de los paquetes están separados del terminal inalámbrico 130. El enlace 140 de RF incluye un enlace ascendente 142 (desde el terminal 130

55 a la ANI 110) y un enlace descendente 144 (desde la ANI 110 al terminal 130). La ANI 110 mantiene interfaces entre uno o más terminales inalámbricos (o de radiofrecuencia) (incluyendo al terminal 130) en una región y la red IP 108, incluyendo la conversión entre señales de línea fija (proporcionadas desde la red IP 108) y señales inalámbricas o de RF (proporcionadas a o desde el terminal 130). De esta manera, la ANI 110 permite que los paquetes del RTP recibidos desde la red IP 108 se envíen por el enlace 140 de RF al terminal inalámbrico 130, y permite que los

60 paquetes del RTP desde el terminal 130 se envíen por la red IP 108 a otro terminal, tal como el terminal 102.

Según un ejemplo de la presente invención, la ANI 110 incluye uno o más adaptadores de ANI (ANI_AD), tal como el

ANI_AD 112 y el ANI_AD 114, cada uno de los cuales, preferiblemente, incluye un temporizador. Cada ANI_AD efectúa la compresión (antes de la transmisión por el enlace descendente) y la descompresión (después de la transmisión por el enlace ascendente) de cabeceras. Las cabeceras (o uno o más campos de cabecera, tales como un sello temporal) para los paquetes del RTP recibidos desde la red IP 108 son comprimidas por el ANI_AD 112 antes de la transmisión al 5 terminal 130 por el enlace descendente 142, y las cabeceras de paquetes recibidas desde el terminal 130 son descomprimidas por el ANI_AD 112 antes de la transmisión a la red IP 108. Por lo tanto, cada ANI_AD puede considerarse un compresor / descompresor 115. Cada ANI_AD puede mantener interfaces entre los terminales situados en un área específica o distinta dentro de la región y la red IP 108. El ANI_AD 112 incluye un temporizador 113 para implementar una técnica de descompresión basada en temporizador. El ANI_AD 112 también incluye una

10 función de reducción de fluctuación de retardo (JRF) 115 que funciona para medir la fluctuación de retardo en los paquetes (o cabeceras) recibidos por la red 108 y para descartar todos los paquetes / cabeceras que tengan fluctuación de retardo excesiva.

Pueden proporcionarse ANI adicionales, tales como la ANI 120, para mantener interfaces entre los otros terminales

15 situados en regiones adicionales con la red IP 108. La ANI 120 incluye de manera similar uno o más ANI_AD, tales como el ANI_AD 122 (Fig. 1). Cada ANI_AD incluye un temporizador y una JRF.

El terminal 130 incluye un punto extremo 132 del RTP que es un origen y/o destino (receptor) para paquetes del RTP. El terminal 130 incluye un adaptador de terminal (term_AD) 136 que efectúa la compresión (para paquetes a transmitir

20 por el enlace ascendente 142) y la descompresión (sobre paquetes recibidos por el enlace descendente 144) de cabeceras. De esta manera, el adaptador de terminal (term_AD) puede considerarse como un compresor / descompresor 137 de cabeceras, similar al ANI_AD.

El adaptador de terminal (term_AD) 136 también incluye un temporizador 134 (un temporizador de receptor) para

25 calcular una aproximación (o estimación) de un sello temporal del RTP de una cabecera actual. El adaptador de terminal (term_AD) 136 utiliza entonces información adicional en la cabecera del RTP para refinar o corregir la aproximación del sello temporal. Según un ejemplo de la invención, la aproximación del sello temporal se corrige o se ajusta en base a un sello temporal comprimido proporcionado en la cabecera del RTP. De esta manera, un temporizador local y un sello temporal comprimido pueden utilizarse para regenerar el sello temporal correcto para

30 cada cabecera del RTP. Pueden proporcionarse otros terminales (tales como el terminal 150), incluyendo cada uno su propio punto extremo del RTP, adaptador de terminal y temporizador.

La configuración mostrada en la Fig. 1 se proporciona meramente como un ejemplo, y la invención no está limitada a la misma. En cambio, la Fig. 1 proporciona simplemente un ejemplo donde los datos del RTP se transmiten por un enlace

35 o sistema de datos (tal como el enlace inalámbrico 140) donde el ancho de banda es prohibitivo y los errores no son raros. La presente invención no está limitada a un enlace inalámbrico, sino que es aplicable a una amplia variedad de enlaces (incluyendo enlaces de línea fija, etc.)

Una aplicación o sistema a modo de ejemplo, donde el esquema de compresión y descompresión de cabeceras,

40 basado en temporizador, puede ser útil, es allí donde se transmiten paquetes de Voz sobre IP (o telefonía IP) por sistemas celulares. Cuando la VoIP se aplica a sistemas celulares, es importante minimizar el sobregasto de la cabecera de IP/UDP/RTP, debido al ancho de banda limitado de la interfaz inalámbrica o aérea (RF). En tal sistema, por ejemplo, el ANI_AD mantendría interfaces entre la red IP y un terminal de ordenador que ejecuta RTP/UDP/IP (p. ej., el terminal 130), y con una interfaz celular o de RF para recibir paquetes del RTP por el enlace inalámbrico o de RF.

45 Esto es meramente un ejemplo de aplicación de la técnica de compresión / descompresión de la presente invención.

La Fig. 2 es un diagrama que ilustra un formato no comprimido de un paquete del RTP según un ejemplo de la presente invención. Como se muestra en la Fig. 2, el paquete del RTP no comprimido incluye una cabecera IP, una cabecera UDP 212, una cabecera RTP 214 y una carga útil, que podría ser una muestra 216 de voz.

50 La Fig. 3 es un diagrama que ilustra el formato de la cabecera del RTP no comprimida, según una realización a modo de ejemplo de la presente invención. Según se muestra en la Fig. 3, la cabecera del RTP no comprimida incluye un sello temporal (TS) 310, un número de secuencia (SN) 312 y algunos otros campos 314. Debido a la naturaleza conmutada por paquetes de la red IP 108, los paquetes del RTP pueden llegar desordenados. El número 312 de

55 secuencia se utiliza en el receptor del RTP o el destinatario del RTP (p. ej., el terminal 130, Fig. 1) para armar las muestras de voz del RTP en el orden correcto. Sin embargo, los números de secuencia en los paquetes del RTP no reflejarán ningún cambio no lineal en el campo (p. ej., los intervalos de silencio de la señal de voz). Por lo tanto, se proporciona un sello temporal (TS) 310 para indicar la temporización relativa de cada paquete.

60 Como se ha observado anteriormente, hay alguna preocupación en cuanto a que el sobregasto de cabecera de entre 40 y 60 octetos, proporcionado por las cabeceras IP/UDP/RTP en cada paquete del RTP, es demasiado grande. En particular, un sello temporal del RTP de 4 octetos es especialmente engorroso para los paquetes del RTP que funcionan sobre enlaces de baja velocidad o de ancho de banda limitado (tales como el enlace 140). Como resultado, hay una necesidad de un mecanismo para comprimir eficazmente las cabeceras del RTP y, en particular, comprimir el campo del sello temporal en la cabecera del RTP.

5 La técnica de compresión de cabeceras descrita en el documento RFC 2508 envía inicialmente un paquete completo (no comprimido) del RTP, que incluye todos los campos, al destinatario / receptor del RTP. Muchos de los campos de las cabeceras durante una conexión son estáticos y, por ello, no es necesario que se transmitan después de que el paquete inicial está enviado y recibido. Para la mayoría de los paquetes, sólo el número de secuencia y el sello temporal cambiarán entre paquete y paquete. Según el documento RFC 2508, los campos no estáticos (p. ej., el sello

10 temporal y el número de secuencia) se actualizan en el receptor añadiendo diferencias de primer orden (fijas) a los valores anteriores de esos campos almacenados en el receptor. Por ejemplo, el número de secuencia de cada paquete del RTP recibido se incrementará automáticamente en uno para cada paquete. Los saltos o cambios adicionales (es decir, distintos a la diferencia de primer orden) en los campos no estáticos deben transmitirse por separado al receptor. Desafortunadamente, en el documento RFC 2508, la pérdida de la cabecera anterior invalidará la descompresión en el

15 receptor. Además, el tamaño de las diferencias varía, lo que hace más difícil gestionar y predecir el ancho de banda utilizando la técnica de compresión del documento RFC 2508.

Según un ejemplo de la presente invención, se proporciona una técnica para la compresión de cabeceras que puede utilizarse para comprimir más eficazmente un sello temporal del RTP (u otro campo) de una cabecera de paquete.

20 Según un ejemplo de la presente invención, el esquema de compresión puede asimilar un salto arbitrario en el valor del sello temporal del RTP, brindando a la vez una cabecera comprimida del RTP de tamaño constante (o un sello temporal del RTP de tamaño constante).

La Fig. 4 es un diagrama que ilustra un formato de cabecera comprimida del RTP según una realización a modo de

25 ejemplo de la presente invención. Según se muestra en la Fig. 4, la cabecera comprimida del RTP puede consistir en un tipo 410 de mensaje que indica el tipo de mensaje, una máscara 412 de bits que identifica los campos que están cambiando, y un campo 414 de sello temporal comprimido. El tipo 410 de mensaje puede indicar un sello temporal comprimido si se proporciona un sello temporal comprimido en la cabecera del paquete. Según un ejemplo de la presente invención, el campo 414 del sello temporal comprimido incluye los k bits menos significativos (lsbs) de un

30 valor que puede indicar el tiempo transcurrido entre los paquetes. Según un ejemplo de la invención, el sello temporal comprimido 414 puede proporcionar una parte (es decir, los k bits menos significativos) de un valor de contador de origen (o diferencia de contador). El contador de origen puede utilizarse para generar el sello temporal para cada cabecera de paquete del RTP. Los campos optativos 416 pueden utilizarse para proporcionar campos actualizados o cambiados para aquellos campos identificados en la máscara 412 de bits.

B. Funcionamiento Global de la Compresión y Descompresión de Sellos Temporales

Se describirá brevemente la compresión y descompresión del sello temporal del RTP, según una realización de la invención. Según un ejemplo, un paquete del RTP se genera en un punto extremo del RTP (tal como el punto extremo

40 104 del RTP del terminal 102) y se dirige a otro punto extremo del RTP. En este ejemplo, el punto extremo 104 del RTP es el origen de uno o más paquetes del RTP a enviar al punto extremo 132 (el destinatario) del RTP del terminal 130. La cabecera del paquete del RTP incluye un sello temporal, que se genera en el origen del RTP (p. ej., en el terminal 102) en base a un reloj común.

45 El paquete del RTP se encamina por la red IP 108 al ANI_AD 112 de la ANI 110. El ANI_AD 112 comprime uno o más campos en la(s) cabecera(s) del paquete del RTP. En particular, el ANI_AD comprime el sello temporal 310 del RTP (Fig. 3) en un sello temporal comprimido 414 (Fig. 4). Otros campos en la cabecera pueden comprimirse retirándolos o utilizando alguna otra técnica. El paquete del RTP, incluyendo el sello temporal comprimido 414, se transmite luego por el enlace descendente 144 del enlace 140 de RF al terminal 130.

50 Al recibir el paquete del RTP con cabecera comprimida (es decir, el sello temporal comprimido 414), el adaptador del terminal (term_AD) 136 del terminal 130 descomprime el valor del sello temporal. El adaptador 136 del terminal descomprime el sello temporal comprimido 414 calculando primero una estimación o aproximación del sello temporal en base al valor actual del temporizador 134. La aproximación del sello temporal se refina o corrige luego en base al

55 sello temporal comprimido 414 proporcionado en la cabecera del paquete. De esta manera, el sello temporal para el paquete actual (cabecera) se regenera en base a un temporizador local (temporizador 134) y un sello temporal comprimido proporcionado en la cabecera actual. Los otros campos de la cabecera del paquete (tales como el número de secuencia) también pueden regenerarse. El paquete y el sello temporal regenerado se proporcionan luego al punto extremo 132 del RTP para su procesamiento. El punto extremo 132 del RTP reproduce entonces las muestras de voz

60 en el orden adecuado (según lo especificado por los números de secuencia) y con la temporización adecuada, según lo especificado por los sellos temporales regenerados (p. ej., para compensar cualquier intervalo de silencio).

El ANI_AD 112 también puede recibir cabeceras comprimidas (incluyendo un sello temporal comprimido) por el enlace 140 de RF, y descomprimir el sello temporal utilizando la técnica de descompresión basada en temporizador anteriormente descrita. Por lo tanto, el ANI_AD 112 puede incluir habitualmente un temporizador para permitir que el ANI_AD descomprima el sello temporal comprimido, según lo anteriormente descrito. De manera similar, el term_AD 5 136 del terminal 130 también puede comprimir el sello temporal del paquete del RTP antes de la transmisión del paquete del RTP por el enlace 140 de RF a la ANI 110. Para simplificar la explicación de las realizaciones a modo de ejemplo de la invención, la mayor parte de la descripción se dirigirá a la trayectoria 144 del enlace descendente. Según un ejemplo de la invención, los paquetes del RTP pueden transmitirse en ambas direcciones (enlace ascendente 142 y enlace descendente 144). Así, tanto el ANI_AD 112 de la ANI 110 como el term_AD del terminal 130 pueden funcionar

10 como un compresor (para la transmisión de la cabecera / el paquete por el enlace de RF) y descompresor (después de recibir una cabecera comprimida recibida por el enlace 140 de RF) de sellos temporales.

C. Realizaciones a Modo de Ejemplo de Compresión y Descompresión de Sellos Temporales

15 Se describirán brevemente realizaciones a modo de ejemplo de compresión y descompresión de sellos temporales. Se supone que los datos en los paquetes del RTP son datos de voz. Las siguientes variables y fórmulas se definen sólo para asistir en la explicación de algunas de las características de la presente invención, pero la invención no se limita a las mismas. Además, la presente invención no se limita a sistemas que utilizan tipos iguales o similares de variables, y

20 no se limita a sistemas que efectúan los cálculos específicos descritos más adelante. Las variables y los cálculos se proporcionan meramente como una realización a modo de ejemplo de la invención.

T es la separación temporal entre las muestras de voz del RTP. (Si hay una muestra de voz proporcionada en cada paquete del RTP, entonces T es también la separación entre las cabeceras de paquetes del RTP). 25 TS: sello temporal

TS_tranco: el sello temporal del RTP se incrementa en TS_tranco cada T mseg. En otras palabras, el sello temporal del RTP aumenta en TS_tranco para cada nuevo paquete del RTP. TS_tranco es una constante (p. ej., 100) que depende 30 del códec de voz. El TS_tranco se proporciona al receptor (terminal 130) y al ANI_AD 112.

TS0: sello temporal del RTP de la primera cabecera de una sesión recibida en el receptor del RTP. La primera cabecera de una sesión se considera una cabecera de sincronización, porque se utiliza para la sincronización. El TS0 es un valor inicial del sello temporal del RTP, proporcionado tanto al compresor (p. ej., el ANI_AD 112) como al 35 descompresor (p. ej., el term_AD 136) al comienzo de la sesión (para la sincronización). Según un ejemplo, el ANI_AD y el term_AD se inicializan o sincronizan al recibir un paquete del RTP con una cabeza no comprimida (incluyendo un sello temporal no comprimido que proporciona el TS0). Según una realización de la presente invención, la técnica de descompresión basada en temporizador requiere proporcionar un sello temporal inicial TS0 (p. ej., mediante una cabecera inicial o de sincronización que está descomprimida) al compresor (es decir, el ANI_AD 112) y al

40 descompresor (es decir, el term_AD 136) de sellos temporales antes de que las cabeceras comprimidas puedan descomprimirse debidamente (es decir, a fin de que el descompresor pueda regenerar correctamente el sello temporal).

El sello temporal del RTP de la cabecera m de paquete (generada en el momento m*T mseg) = TS0 + TS_tranco*m.

45 Esto supone que hay una cabecera para cada muestra de voz. Como se muestra en los ejemplos descritos más adelante, esta fórmula puede extenderse para el caso de múltiples muestras de voz (p. ej., 3 muestras de voz) por cabecera de paquete.

m: un número entero que indica el número de muestras de voz que han sido enviadas. m se reinicia o se borra con 0 al

50 comienzo de la sesión. m es proporcional a (o indica) la cantidad de tiempo que ha transcurrido desde el comienzo de la sesión. m se incrementa en 1 cada T mseg.

TS_actual = TS0 + m_actual*TS_tranco; El sello temporal actual para la cabecera del paquete actual.

55 Temporizador del receptor: el temporizador en el receptor del RTP (o destinatario del RTP), tal como el temporizador 134 del terminal 130. El temporizador del receptor local es habitualmente de funcionamiento libre y no se reiniciará al comienzo de una sesión. En cambio, el tiempo transcurrido en el receptor del RTP entre recibir dos cabeceras de paquete puede obtenerse restando el valor del temporizador de la cabecera actual al valor del temporizador del receptor cuando se recibió la cabecera del paquete anterior. Permitiendo que el temporizador del receptor funcione

60 libremente, un temporizador de receptor puede ser compartido por muchos flujos o sesiones. Alternativamente, el temporizador del receptor puede reiniciarse al comienzo de cada sesión. La reinicialización o el borrado de un temporizador de receptor al comienzo de una sesión (es decir, al recibir la cabecera de inicialización) requeriría un temporizador de receptor dedicado (proceso temporizador) para cada sesión o flujo. El primer sello temporal no comprimido (TS0) de una sesión puede proporcionarse al ANI_AD y al term_AD en una cabecera de inicialización. La primera cabecera se proporciona para inicializar el compresor (ANI_AD 112) y el descompresor (term_AD 136). El temporizador del receptor se incrementa luego en 1 cada T mseg. El ANI_AD 112 (compresor) utiliza el valor de TS0

5 para comprimir los sellos temporales de las subsiguientes cabeceras de paquetes del RTP: El term_AD 136 (descompresor) utiliza el valor de TS0 para descomprimir el valor del sello temporal comprimido (p. ej., para regenerar los sellos temporales en las cabeceras de RTP recibidas a continuación).

temporizador_actual: el valor del temporizador en el receptor del RTP (p. ej., el terminal 130) cuando se recibe la 10 cabecera actual

último_temporizador: el valor en el momento, en el receptor, cuando se recibió la última cabecera. (El temporizador_actual se almacena como el último_temporizador para el próximo cálculo de cabecera del sello temporal).

15 m_último: el valor de m para la última cabecera recibida; m indica el número de tramas de voz que han transcurrido desde la cabecera de inicialización.

Para comprimir el sello temporal del paquete actual, el ANI_AD 112 calcula el valor actual de m como: m_actual =

20 (TS_actual – TS0) / TS_tranco. Por lo tanto, el ANI_AD resta el valor inicial del sello temporal (al comienzo de la sesión) al sello temporal actual. Esta diferencia se divide entre el tranco del sello temporal (TS_tranco). Sin embargo, en algunas realizaciones, puede ser innecesario realizar efectivamente una operación de división. Pueden utilizarse otras técnicas para generar debidamente m_actual sin efectuar una operación de división, que puede requerir un alto sobregasto de procesador.

25 Los k bits menos significativos de m_actual se proporcionan luego como el sello temporal comprimido 414. El paquete del RTP que incluye el sello temporal comprimido 414 se transmite luego por el enlace 140 de RF al destinatario o receptor del RTP (p. ej., el terminal 130).

30 En el receptor del RTP (p. ej., el terminal 130), el adaptador del terminal (Term_AD) 136 descomprime el sello temporal comprimido 414. El valor del temporizador_actual de la cabecera anterior se almacena primero como último_temporizador. Luego, cuando llega la cabecera actual, el term_AD 136 lee el valor del temporizador 134 del receptor y almacena esto en memoria como temporizador_actual. Luego, dif_temporizador se calcula como: dif_temporizador = temporizador_actual – último_temporizador. El ANI_AD calcula el valor exacto de m_actual hallando

35 el número entero d, donde

(-L / 2 < d < L /2, donde L = 2k), tal que: (Ec. 1)

k bits menos significativos de (d + m_último + dif_temporizador) = sello temporal comprimido 414 (para la cabecera 40 actual). (Ec. 2)

Como se ha indicado, el sello temporal comprimido recibido también tiene k bits. Una vez que d ha sido calculado 45 utilizando las Ec. 1 y 2, el TS_actual puede calcularse entonces como:

TS_actual = TS0 + (d + m_último + dif_temporizador) * TS_tranco. (Ec. 3).

50 En la ecuación 3, el valor efectivo o correcto de m_actual se muestra entre paréntesis como (d+ m_último + dif_temporizador). m_último + temporizador es la aproximación de m_actual, mientras que d es la diferencia entre la aproximación de m_actual y el valor correcto de m_actual. Además, TS0 + (m_último + dif_temporizador) * TS_tranco es una aproximación del valor del sello temporal actual, y d*TS_tranco es la diferencia entre el sello temporal actual aproximado y el valor efectivo (o correcto) del sello temporal actual.

55 Por lo tanto, puede verse que el receptor del RTP calcula primero una aproximación (o estimación) del sello temporal actual en base al tiempo transcurrido entre recibir la cabecera actual y la cabecera anterior (que fue correctamente descomprimida), como: sello temporal actual aproximado = TS0 + (m_último + dif_temporizador)*TS_tranco. El sello temporal actual aproximado se ajusta o corrige luego con la cantidad d*TS_tranco para calcular el valor correcto del

60 sello temporal actual (TS_actual).

Después de que TS_actual está calculado, el paquete actual del RTP (incluyendo su sello temporal regenerado o descomprimido, TS_actual) se proporciona hasta el punto extremo 132 del RTP. Este proceso de compresión y descompresión es transparente a los puntos extremos del RTP.

La Fig. 5 es un diagrama que ilustra una operación a modo de ejemplo de compresión y descompresión de cabeceras

5 según un ejemplo de la invención. Este ejemplo aplica algunas de las fórmulas específicas descritas anteriormente para ilustrar algunas características de la presente invención. En esta realización a modo de ejemplo, se supone que los temporizadores en el origen 502 de RTP y en el receptor 504 de RTP tienen la misma frecuencia, pero que no están habitualmente sincronizados. El temporizador en el origen de RTP (p. ej., aumentando en 1 cada T mseg) se utiliza para generar el sello temporal, mientras que el temporizador (p. ej., el temporizador 134) en el receptor de RTP se

10 utiliza para regenerar o descomprimir el sello temporal del RTP.

Con referencia a la Fig. 5, al comienzo de una sesión, se genera una cabecera 508 de inicialización en el origen de RTP, incluyendo un valor inicial del sello temporal (TS0). La cabecera 508 de inicialización se transmite a la ANI y se remite luego al receptor 504 de RTP (p. ej., el terminal 130). El sello temporal en la cabecera de inicialización no se

15 comprime. Al recibir la cabecera de inicialización, el valor inicial del sello temporal (TS0) se almacena en memoria en el ANI_AD, junto con el valor de TS_tranco. Según un ejemplo, pueden transmitirse dos cabeceras de inicialización al ANI_AD. El ANI_AD puede calcular luego TS_tranco como el segundo sello temporal – el primer sello temporal. El term_AD puede calcular de manera similar TS_tranco o recibir el valor en un paquete.

20 De manera similar, cuando la cabecera 508 de inicialización se recibe en el receptor del RTP (terminal 130), el sello temporal inicial (TS0) se almacena en memoria junto con el valor de TS_tranco. Además, al recibir 510 la cabecera 508 de inicialización (Fig. 5), el valor de m_actual se borra o se reinicia con cero (0), y el temporizador del receptor se lee luego y se almacena como temporizador_receptor_inicial, 516. En lugar de leer el temporizador al comienzo de la sesión, el temporizador del receptor puede ser reiniciado o borrado. En este ejemplo, ocurre que el valor leído del

25 temporizador del receptor al comienzo de la sesión es cero (0), para simplificar. Así, el ejemplo mostrado en la Fig. 5 se aplica a ambos ejemplos (sólo leer el temporizador del receptor, o reiniciarlo con cero) porque el temporizador de funcionamiento libre se lee como cero al comienzo de la sesión. Análogamente, no es necesario borrar m_actual, sino que podría, en cambio, almacenar un valor para m_actual. El temporizador del receptor se incrementa a continuación

(p. ej., en 1) cada T mseg (que es la misma frecuencia que la del temporizador en el origen 502 de RTP, utilizado para

30 generar sellos temporales). La cabecera 508 de inicialización llega al receptor 502 del RTP después de un retardo fijo (retardo íntegro 512) y un retardo variable (fluctuación de retardo acumulativa 514).

Luego, el origen 502 de RTP genera el siguiente paquete del RTP (el primer paquete del RTP de la sesión después de la cabecera de inicialización). Este paquete del RTP se genera 3*T mseg después de que se haya generado la

35 cabecera de inicialización y, de esta manera, incluiría habitualmente tres (3) muestras de voz, por ejemplo. Son posibles otras cifras. Por lo tanto, el sello temporal para la cabecera de este paquete es: TS(1) = TS0 + 3*TS_tranco, según se muestra en la Fig. 5. TS(1) se refiere al sello temporal generado después de 3T mseg después de la inicialización. En este ejemplo, se supondrá que TS_tranco es 100, por ejemplo. Se supone que TS0 es 0, por ejemplo. Así, TS(1) = 300.

40 El valor del sello temporal para este paquete, TS(1), se recibe en el ANI_AD y se comprime en base a TS(1) (el valor del sello temporal), TS0 (el valor inicial del sello temporal) y TS_tranco (la cantidad en que se incrementa el sello temporal cada T mseg). Según una realización a modo de ejemplo, el sello temporal comprimido puede calcularse como los k bits menos significativos de m_actual. El ANI_AD 112 calcula el valor actual de m como: m_actual =

45 (TS_actual – TS0) / TS_tranco. En este ejemplo, se supondrá que TS_tranco es 100, por ejemplo. En este ejemplo, m_actual se calcula como: m_actual = (300-0) / 100 = 3. k en este ejemplo será dos (2). Así, los dos bits menos significativos de m_actual (11 en binario) se proporcionan como el sello temporal comprimido 414 para este paquete (CTS1), Fig. 5.

50 El sello temporal comprimido (CTS1) llega al receptor 502 del RTP y el term_AD 136 en el receptor del RTP regenera o descomprime el sello temporal, TS(1), para el paquete actual. El valor del temporizador_actual (cero) se almacena como último_temporizador y m_actual se almacena como m_último. m_actual fue previamente fijado en cero al comienzo de la sesión (es decir, al recibir la cabecera de sincronización). El valor del temporizador del receptor (3 en este caso) se lee y se almacena como temporizador_actual. El valor de dif_temporizador se calcula luego como

55 temporizador_actual – último_temporizador, que es 3 – 0 = 3. Dif_temporizador + m_último es una aproximación de m_actual.

Luego, term_AD 136 calcula el valor exacto o corregido para m_actual, utilizando las ecuaciones (1) y (2). Utilizando la ecuación (2), los dos bits menos significativos de (d + m_último + dif_temporizador) = CTS1 (el sello temporal

60 comprimido para la cabecera actual). En este caso, m_último es cero (0), dif_temporizador es tres (3) y CTS1 es tres (3). Así, los dos bits menos significativos de (d + 0 + 3) = 3. Así, d es igual a cero.

Utilizando la ecuación (3), el sello temporal descomprimido para este paquete se calcula luego como TS(1) = TS0 + (d

+ m_último + dif_temporizador) * TS_tranco. Así, como resultado, TS(1) = 0 + (0 + 0 + 3) * 100 = 300. El sello temporal descomprimido para este paquete, TS(1) = 300, se proporciona luego al punto extremo 132 del RTP en el origen de RTP, junto con los datos de RTP y otros campos de cabecera descomprimidos. El valor correcto o efectivo para

5 m_actual es (d + m_último + dif_temporizador). Por lo tanto, para este paquete, puede verse que la aproximación de m_actual es la misma que el valor correcto de m_actual (pero esto no es verdad en el caso general). m_actual se actualiza luego para que sea 3.

El próximo paquete y sello temporal se genera en el origen del RTP, incluyendo un sello temporal TS (2) = 0 + 6 * 100 =

10 600. En el ANI_AD, el valor TS(2) = 600 se comprime en un sello temporal comprimido como los 2 bits menos significativos de (600 – 0) / 100 = 6. En este caso, 6 en binario es 110. Así, los dos bits menos significativos de 110 son

10. Así, CTS2 = 10 en binario.

El sello temporal comprimido para este paquete (CTS2) se recibe luego en el term_AD 136 después de que el

15 temporizador del receptor alcanza el valor de 7, debido al retardo íntegro y a la fluctuación de retardo acumulativa. El valor de temporizador_actual (3) se almacena como último_temporizador y m_actual (3) se almacena como m_último. El valor actual del temporizador del receptor (7 en este caso) se lee y se almacena como temporizador_actual. Se calcula luego dif_temporizador como temporizador_actual - último_temporizador, que es 7 - 3 = 4. Dif_temporizador + m_último es una aproximación de m_actual, que es 7.

20 Luego, term_AD 136 calcula el valor exacto o corregido para m_actual utilizando las ecuaciones (1) y (2). Utilizando la ecuación (2), los dos bits menos significativos de (d + m_último + dif_temporizador) = CTS2 (el sello temporal comprimido para la cabecera actual). En este caso, m_último es 3, dif_temporizador es 4 y CTS2 es 10 (en binario, que es 3 en decimal). d se despeja en la ecuación 2 de la siguiente manera: los 2 bits menos significativos de (d + 3 + 4) =

25 2. Siete en binario es 111. Así, d = -1. d es la diferencia entre la aproximación de m_actual y el valor efectivo de m_actual. Reemplazando d en la ecuación (3), el sello temporal para este paquete se calcula como TS(2) = 0 + (-1 + 3

+ 4) * 100 = 600. Así, el term_AD 136 del receptor de RTP ha regenerado correctamente (p. ej., descomprimido) el sello temporal del RTP en base a un temporizador local y un sello temporal comprimido.

30 Debería observarse que, a diferencia de las técnicas anteriores, es innecesario reenviar una cabecera de inicialización en el caso en que uno o más paquetes no llegan al receptor de RTP. En otras palabras, la sincronización entre el origen y el receptor del RTP es necesaria sólo una vez al comienzo de una sesión o conexión. Esto es porque el sello temporal actual se calcula en el receptor del RTP sobre la base tanto de m_último como de dif_temporizador. Dif_temporizador se calcula como temporizador_actual – último_temporizador. Por lo tanto, los valores de m_último y

35 último_temporizador corresponden al último paquete, independientemente de cuál paquete se recibió en último lugar

(p. ej., independientemente de si los paquetes enviados después del "último" paquete se descartaron erróneamente o se perdieron). Como resultado, el esquema de compresión basado en temporizador según un ejemplo de la invención es robusto ante los errores y disminuye los requisitos de ancho de banda, porque es innecesario enviar un nuevo paquete de sincronización (p. ej., que incluya valores completos no comprimidos para todas las cabeceras) en el caso

40 de que se detecte un error (p. ej., uno o más paquetes descartados o perdidos).

En el funcionamiento normal, la discrepancia entre la aproximación y el valor exacto de m_actual está causada por:

a) Fluctuación de retardo acumulada entre la misma fuente de los sellos temporales del RTP y el receptor; el

45 retardo efectivo = retardo íntegro + fluctuación de retardo acumulada, donde el retardo íntegro es constante y la fluctuación de retardo acumulativa varía entre una cabecera y la siguiente, y 0 < fluctuación de retardo acumulativa < máxima fluctuación de retardo acumulativa; y b) Posible asincronía entre el proceso temporizador y el proceso descompresor, según la implementación del temporizador. Debido a la asincronía, puede haber un error de más o menos uno (+ o – 1) en el valor del

50 temporizador (temporizador_actual).

La Fig. 6 es un diagrama que ilustra una operación a modo de ejemplo de compresión y descompresión de cabeceras según otro ejemplo de la invención. Como la Fig. 5, la Fig. 6 es un diagrama que ilustra el efecto de la fluctuación de retardo y la asincronía del temporizador. En la Fig. 5, el temporizador del receptor se reinicia o borra sólo al comienzo

55 de la sesión. (Esto no es necesario, ya que puede dejarse que el temporizador del receptor continúe en marcha). Sin embargo, en la realización a modo de ejemplo ilustrada en la Fig. 6, el temporizador del receptor se reinicia o se borra con cero (0) para cada paquete. Así, cuando se recibe una cabecera de paquete descomprimida, se lee el valor del temporizador, que indica el valor de dif_temporizador anteriormente descrito (ya que el temporizador indica el tiempo transcurrido desde la última cabecera de paquete). Puede haber muchas maneras distintas de implementar la

60 invención. Lo que es importante es que debería medirse una diferencia de temporizadores que indique el tiempo transcurrido (según lo medido por el temporizador del receptor local) entre el último sello temporal exitosamente descomprimido y el sello temporal actual (dif_temporizador según lo descrito en la Fig. 5).

Con referencia a la Fig. 6, la cabecera n se genera con el sello temporal = TS0 + 3 + TS_tranco. Este sello temporal de la cabecera n se comprime y se transmite al receptor del RTP, y se descomprime. El temporizador se reinicia entonces en el receptor. Las siguientes cabeceras, (n+1), (n+2) y (n+3) se generan y se envían, pero sólo la cabecera (n+3) es 5 recibida (es decir, las cabeceras n+1 y n+2 se pierden). Para simplificar, las cabeceras (n+2) y (n+3) no se muestran en la Fig. 6. La cabecera (n+1) se muestra en la Fig. 6 como la cabecera m+n. La cabecera (m+n) se genera y se envía, con el sello temporal TS = TS0 + 6*TS_tranco. Este sello temporal de la cabecera (m+n) se comprime y se envía luego al receptor del RTP. El valor del temporizador es 4 (lo que indica dif_temporizador). Este valor se utiliza para descomprimir el sello temporal para la cabecera (m+n). Por lo tanto, el ejemplo de la Fig. 6 es muy similar al ejemplo

10 mostrado en la Fig. 5, excepto en que el temporizador se reinicia después de recibir cada cabecera en la Fig. 6.

Independientemente de qué técnica se emplee (bien la Fig. 5 o la Fig. 6), puede utilizarse un esquema de compresión efectiva basada en temporizador. Sin embargo, si la fluctuación de retardo acumulada es excesiva, puede no ser posible regenerar un sello temporal correcto en base al sello temporal comprimido. En muchos casos, la siguiente

15 condición debería ser satisfecha por k para permitir que el esquema de compresión basado en temporizador, ilustrado en las Figs. 5 y/o 6, funcione debidamente:

[Condición 1] (Fluctuación de retardo integral máxima + 2) < 2k,

20 donde la Fluctuación de retardo integral máxima (MIJ) es la máxima fluctuación de retardo acumulativa, expresada en unidades de T mseg, redondeada al siguiente número entero mayor. Por ejemplo, si T = 20 mseg, una fluctuación de retardo acumulativa máxima de 15 mseg dará como resultado una MIJ = 1. Se suma 2 a la MIJ para compensar el posible error causado por la asincronía del temporizador.

25 Debido a los requisitos conversacionales de tiempo real, la fluctuación de retardo acumulativa en el funcionamiento normal puede ser sólo de unos pocos múltiplos de T mseg. Por lo tanto, en tal caso, un valor de k igual a 4 es más que suficiente, ya que una discrepancia de muestras de voz de hasta 16 (es decir, 16*T mseg) puede corregirse en el receptor del RTP. Las situaciones anormales o erróneas pueden dar como resultado que la fluctuación de retardo exceda los valores normales. Una entidad de reducción de fluctuación de retardo puede añadirse flujo arriba del

30 compresor para garantizar que la fluctuación de retardo, según la ve el compresor, permanezca dentro de cotas aceptables.

Las ventajas del esquema de compresión del sello temporal ilustrado en las Figs. 5 y/o 6 incluyen:

35 a) El tamaño del sello temporal es constante y pequeño. La cabecera comprimida consiste habitualmente en un tipo de mensaje, que indica el tipo de mensaje (k 1 bits), una máscara de bits que indica qué campos están cambiando, y un campo que contiene los k bits menos significativos de m_actual (k bits). Suponiendo que se utiliza la misma máscara MST1 de 4 bits que en el documento RFC2508, y que k 1 = 4, el tamaño de la cabecera comprimida, cuando sólo cambia el TS del RTP (este caso es, con diferencia, el más frecuente), es

40 de 1,5 octetos. Además, el tamaño no cambia como función de la longitud del intervalo de silencio. b) Como se muestra en, por ejemplo, la Fig. 6, el temporizador del receptor funciona en la misma frecuencia que el temporizador fuente del RTP (utilizado para generar el sello temporal original); no se requiere la sincronización de fase entre el temporizador de origen y el temporizador del receptor (porque es el tiempo transcurrido según lo medido por el temporizador del receptor lo que se utiliza para regenerar el sello

45 temporal). c) En el receptor, no se requiere ninguna sincronización entre el proceso temporizador y el proceso descompresor. Por ejemplo, el proceso temporizador puede incrementar el temporizador en 1 cada T mseg, mientras que el proceso descompresor es despertado para realizar la descompresión cuando se recibe una nueva cabecera. Sin embargo, no se requiere que el punto en el cual el temporizador se incrementa esté

50 alineado o sincronizado con el punto donde se recibe la cabecera (véase la Fig. 6). d) Robustez ante los errores, ya que la información parcial del TS del RTP en la cabecera comprimida es autocontenida y sólo necesita combinarse con el temporizador del receptor para producir el valor completo del TS del RTP. La pérdida o corrupción de una cabecera no invalidará las subsiguientes cabeceras comprimidas. e) No es necesario mantener o almacenar ninguna memoria ni valores por parte del compresor con el fin de la

55 compresión / descompresión del TS del RTP.

D. Traspaso

Según una realización, a cada ANI_AD se asigna un área específica (p. ej., terminales de interfaz situadas en un área 60 específica). Los terminales (tales como el terminal 130) pueden desplazarse desde un área a otra. Cuando un terminal se mueve desde un área a otra, el terminal debe traspasarse, o conmutarse desde un ANI_AD a otro ANI_AD.

Un caso de traspaso a considerar es el traspaso entre ANI_AD, donde puede haber una perturbación causada por la conmutación desde el viejo ANI_AD a un nuevo ANI_AD. La cuestión es cómo mantener la continuidad de información a través del traspaso, de forma tal que, después del traspaso, la compresión / descompresión en el term_AD 136 y el nuevo ANI_AD continúen sin perturbación.

1. Enlace descendente

No hay ninguna discontinuidad en el lado receptor, que es el terminal (p. ej., el terminal 130, Fig. 1). El papel del compresor se transfiere desde un ANI_AD a otro. Después del traspaso, las cabeceras se encaminan por una nueva

10 trayectoria que pasa a través del nuevo ANI_AD, en lugar del viejo ANI_AD. Además, según el diseño del sistema, puede o no haber un reencaminamiento de paquetes en tránsito durante el traspaso. Los paquetes en tránsito son aquellos generados por el origen pero que no han llegado aún al receptor a la hora del traspaso. El reencaminamiento intenta entregar los paquetes en tránsito al terminal.

15 Para efectuar el traspaso, el viejo ANI_AD debe transferir el valor inicial del sello temporal para la sesión (TS0) y de TS_tranco al nuevo ANI_AD. Estos dos valores permiten que el nuevo ANI_AD continúe comprimiendo nuevos sellos temporales (en nuevas cabeceras de paquetes) recibidos desde el origen del RTP (p. ej., el terminal 102). Sea Cabecera_actual la primerísima cabecera a descomprimir por parte del term_AD después del traspaso, y su TS_actual su sello temporal de RTP. El term_AD puede descomprimir TS_actual mientras se satisfaga la siguiente condición:

20 [Condición 2] (Fluctuación de retardo integral Transitoria del Enlace Descendente + 2) < 2k,

donde la Fluctuación de retardo Integral Transitoria del Enlace Descendente (DTIJ) es la fluctuación de retardo transitoria del enlace descendente de la Cabecera_actual, expresada en unidades de T mseg, redondeada al próximo 25 número entero mayor. La fluctuación de retardo transitoria del enlace descendente se define como = retardo total de Cabecera_actual – retardo íntegro en la vieja trayectoria. Si la Cabecera_actual no es la cabecera de un paquete en tránsito reencaminado, el retardo total de la Cabecera_actual también es el retardo íntegro en la nueva trayectoria + la fluctuación de retardo acumulativa para la Cabecera_actual en la nueva trayectoria. Por lo tanto, la fluctuación de retardo transitoria del enlace descendente = retardo íntegro en la nueva trayectoria – retardo íntegro en la vieja

30 trayectoria + fluctuación de retardo acumulativa para la Cabecera_actual.

Si la Cabecera_actual es la cabecera de un paquete en tránsito reencaminado, el retardo total de Cabecera_actual = retardo total causado por el encaminamiento y el reencaminamiento. En la práctica, los sistemas deberían diseñarse, preferiblemente, para mantener la fluctuación de retardo transitoria del enlace descendente en la misma gama de

35 valores que la fluctuación de retardo acumulativa en el estado estable (es decir, sin traspaso). Por lo tanto, en base a estas hipótesis (que pueden no valer siempre), no se espera ningún problema específico relacionado con el traspaso para el enlace descendente si se satisface la condición 1 (indicada anteriormente).

2. Enlace ascendente

40 En esta descripción del enlace ascendente, el term_AD 136 del terminal (p. ej., el terminal 130) comprime el sello temporal y lo envía por el enlace 140 de RF al ANI_AD local o correspondiente. El origen del RTP en este caso es el terminal 130. Incluso cuando el origen del RTP (el terminal 130) cambia las ubicaciones físicas (lo que requiere un traspaso en el ANI_AD), el papel del receptor (del descompresor) se transfiere desde un ANI_AD a otro. El origen del

45 RTP permanece anclado en el terminal (p. ej., el terminal 130, Fig. 1).

La Fig. 7 es un diagrama que ilustra una operación a modo de ejemplo de traspaso según un ejemplo de la presente invención. Para minimizar el sobregasto de la interfaz aérea, es necesario transferir alguna información desde un viejo ANI_AD 710 a un nuevo ANI_AD 712 para el traspaso. Esa información es el valor del temporizador en el viejo 50 ANI_AD. El viejo ANI_AD 710 lee (o toma una instantánea de) el valor actual del Temporizador (T_u) en el viejo ANI_AD, y lo envía al nuevo ANI_AD, junto con TS0, TS_tranco y m_actual, bloque 714 (Fig. 7). El nuevo ANI_AD reanuda el incremento de su temporizador, a partir de (T_u). Sea T_transfer 715 (Fig. 7) el tiempo para transferir el Temporizador. Además, los procesos temporizadores en los ANI_AD viejo y nuevo pueden tener una diferencia de fase que es, a lo sumo, de T mseg. Sea Cabecera_actual la primerísima cabecera a descomprimir por parte del nuevo

55 ANI_AD después del traspaso, y sea TS_actual su sello temporal de RTP. El nuevo ANI_AD puede descomprimir TS_actual mientras se satisfaga la siguiente condición:

[Condición 3] (Fluctuación de retardo integral transitoria del enlace ascendente + 2 + 1) < 2k,

60 donde la Fluctuación de retardo Integral Transitoria del Enlace Ascendente (UTIJ) es la fluctuación de retardo transitoria del enlace ascendente expresada en unidades de T mseg, redondeada al siguiente número entero mayor. La fluctuación de retardo transitoria del enlace ascendente se define como = retardo total de Cabecera_actual – retardo íntegro en la vieja trayectoria + T_transfer. Como el Retardo Total de la Cabecera_actual = retardo íntegro en la nueva trayectoria + fluctuación de retardo acumulativa para la Cabecera_actual, la fluctuación de retardo transitoria del enlace ascendente = retardo íntegro en la nueva trayectoria – retardo íntegro en la vieja trayectoria + fluctuación de retardo acumulativa para la Cabecera_actual + T_transfer. En comparación con el caso del enlace descendente, se suma 1

5 para compensar la diferencia de fase entre el temporizador del viejo ANI_AD y el temporizador del nuevo ANI_AD.

Específicamente, la Fig. 7 también ilustra la fluctuación de retardo transitoria del enlace ascendente, que incluye la diferencia del retardo íntegro y T_transfer. En este ejemplo, el viejo ANI_AD decide prepararse para el traspaso antes de que el temporizador incremente el temporizador. Por lo tanto, envía T_u = 0 al nuevo ANI_AD 712. T_transfer es,

10 aproximadamente, T mseg. En el nuevo ANI_AD 712, debido a la asincronía del proceso temporizador, casi T mseg transcurren antes de que el temporizador se incremente. También hay una fluctuación de retardo acumulativa en la nueva trayectoria para la cabecera (n+m). Como resultado, el valor del temporizador leído cuando se recibe la cabecera (n+m) es 2, mientras que el valor real debería ser 4. Por lo tanto, hay un desfase de -2. Mientras se cumpla la condición 3, el desfase puede eliminarse y el sello temporal del RTP puede descomprimirse correctamente.

15 Según una realización, T_u se transmite por una red de señalización de alta velocidad, que conecta los ANI_AD viejo y nuevo. En consecuencia, el tiempo T_transfer debería ser, a lo sumo, de sólo unos pocos T mseg. Sin embargo, deben considerarse los casos donde la transferencia de T_u no es exitosa, o no lo bastante puntual. En esos casos, el nuevo ANI_AD notificará al term_AD, que envía el sello temporal completo (no comprimido) hasta que se reciba un acuse de

20 recibo.

E. Reducción de Fluctuación de retardo

Según una realización de la presente invención, el esquema de compresión basada en temporizador que utiliza un

25 sello temporal comprimido y un temporizador de receptor local puede aseverarse si se satisfacen las siguientes condiciones.

[Condición 1] (Fluctuación de retardo integral máxima + 2) < 2k,

30 [Condición 2] (Fluctuación de retardo integral transitoria del enlace descendente + 2) < 2k,

[Condición 3] (Fluctuación de retardo integral transitoria del enlace ascendente + 2 + 1) < 2k.

Debido a los requisitos conversacionales en tiempo real, puede esperarse razonablemente que las diversas

35 fluctuaciones de retardo anteriores sean del orden de unos pocos T mseg en el funcionamiento normal. Por lo tanto, un valor pequeño de k, p. ej., 4, es usualmente más que suficiente para permitir que se corrija cualquier desfase o error. Sin embargo, pueden existir condiciones anormales en la trayectoria desde el origen del RTP al receptor (fallos, etc.) u otras situaciones, en las cuales las fluctuaciones de retardo se tornen excesivas (donde el sello temporal correcto no puede generarse en base al sello temporal comprimido y el temporizador del receptor local). Para tratar estos casos,

40 puede proporcionarse una función de reducción de fluctuación de retardo (JRF) 115 (Fig. 1) como una interfaz de primer orden para el compresor, para filtrar (o descartar) los paquetes con fluctuación de retardo excesiva (p. ej., donde no se satisfaga cualquiera de las condiciones anteriores 1, 2, ó 3).

Para filtrar o identificar paquetes con MIJ excesiva, la función de reducción de fluctuación de retardo (JRF) calcula la

45 fluctuación de retardo de cada paquete recibido por la red 108. Si la fluctuación de retardo medida del paquete es mayor que 2k – 2, esto se considera fluctuación de retardo excesiva y el paquete se descarta. En caso contrario, la cabecera (o campo de cabecera) se comprime (según lo descrito anteriormente) y se transmite luego al terminal receptor (p. ej., el terminal 130).

50 La JRF calcula la fluctuación de retardo del paquete actual de la siguiente manera: fluctuación de retardo = valor absoluto de (TS2 – TS1 – dif_temporizador de JRF), donde TS2 es el sello temporal del paquete actual, TS1 es el sello temporal del paquete anterior y dif_temporizador de JRF es la diferencia en el temporizador_JRF entre el paquete actual y el paquete anterior (tiempo transcurrido). Este valor de fluctuación de retardo se compara con 2k – 2. Si la fluctuación de retardo es mayor que 2k - 2, el paquete se descarta. En caso contrario, la cabecera del paquete se

55 comprime en el ANI_AD y el paquete con la cabecera comprimida se envía al receptor del RTP.

Esta función de reducción de fluctuación de retardo (JRF) 115 es una técnica efectiva para limitar la fluctuación de retardo en los paquetes recibidos por el terminal receptor (porque la fluctuación de retardo introducida por el enlace de RF puede considerarse despreciable). Además, la JRF funciona para utilizar más eficientemente el ancho de banda 60 disponible por el enlace 140 de RF. En ausencia de la JRF 115, uno o más paquetes, con una fluctuación de retardo mayor que 2k - 2, podrían transmitirse al receptor por el enlace 140. Sin embargo, en el receptor, si la fluctuación de retardo es excesiva (es decir, la condición 1 no se satisface), no puede generarse el valor correcto del sello temporal, lo

que causa que el receptor descarte el paquete. Así, la JRF funciona meramente para filtrar aquellos paquetes con fluctuación de retardo excesiva, que serían descartados en el receptor en todo caso (evitando el desperdicio de valioso ancho de banda por el enlace 140).

5 II. Esquema de Desmenuzamiento de Cabecera

Una segunda realización de la presente invención proporciona un esquema de desmenuzamiento de cabecera, basado en temporizador, en el cual una cabecera, o uno o más campos de cabecera (p. ej., que incluyan el sello temporal de RTP), se quita(n) del paquete del RTP antes de la transmisión por el enlace de bajo ancho de banda (p. ej., por el

10 enlace 140 de RF, Fig. 1). En tal caso, el sello temporal no está explícitamente proporcionado en el paquete de RTP. En cambio, la información de temporización puede proporcionarse implícitamente a un regenerador de cabecera para incrementar el temporizador local basado en un canal de tasa de bits esencialmente constante, o una conexión similar a un circuito, entre el desmenuzador de cabecera (p. ej., que pueda existir en un ANI_AD) y el regenerador de cabecera (p. ej., que pueda existir en el terminal 130).

A. Resumen del Desmenuzamiento de Cabecera

El desmenuzamiento de cabecera se basa en la idea de que, para algunas aplicaciones o servicios, no es necesario transportar toda la información contenida en las cabeceras IP/UDP/RTP, bien porque no cambian, o bien porque no son 20 esenciales a la aplicación / servicio. La voz básica es un ejemplo típico. Para brindar un servicio equivalente al servicio existente de voz celular (p. ej., por el enlace 140 de RF, Fig. 1), la única información variable de cabecera que es esencial es el sello temporal (TS) del RTP. También es deseable mantener la transparencia para el número de secuencia (SN) del RTP. La transparencia aquí (para el SN) significa que el SN, después de la retirada / regeneración, es igual al SN original. El desmenuzamiento de cabecera se apoya sobre la información implícita de temporización 25 proporcionada por una conexión similar a un circuito, o por un canal de tasa de bits esencialmente constante (donde no se introduce ninguna fluctuación de retardo de paquete), para permitir que el sello temporal del RTP se regenere sólo en base a un temporizador o contador local. Esto elimina la necesidad de enviar el sello temporal explícitamente (o incluso de enviar un sello temporal comprimido). Para lograr la transparencia del SN, los SN comprimidos pueden utilizarse en combinación con la información de temporización del canal o conexión similar a un circuito. Una conexión

30 similar a un circuito proporciona, preferiblemente, un canal con una tasa de bits esencialmente constante. Cuando no hay ninguna muestra de voz (p. ej., intervalo de silencio), el canal puede o no adjudicarse a otro tráfico y/o otros usuarios. Las ventajas de este esquema de desmenuzamiento de cabecera incluyen:

a) Mínimo sobregasto de cabecera, inigualado por ningún otro esquema (incluso menos que la técnica de

35 cabecera comprimida anteriormente descrita en las Figs. 1-6). b) Robustez ante los errores, ya que la información de temporización de la transmisión similar a la de los circuitos, o del canal de tasa de bits esencialmente constante, está inherentemente fuera del alcance de los errores. c) Posibilidad de conmutar durante una llamada a la compresión de cabecera (p. ej., la técnica de las Figs. 1

40 6), si así se desea. Esto puede ser útil si la llamada se convierte en una llamada de multimedios, según se añade un medio no vocal a la voz. Además, obsérvese que el desmenuzamiento de la cabecera no obliga ni excluye el multiplexado estadístico que, si se implementa, podría tener lugar en una capa inferior.

La Fig. 8 es un diagrama en bloques que ilustra una pila a modo de ejemplo según una realización a modo de ejemplo

45 de la presente invención. Se muestran una pila desmenuzadora 802 de cabecera y una pila regeneradora 830 de cabecera. Como ejemplo, la pila desmenuzadora 802 de cabecera ilustra algunos de los componentes que pueden utilizarse para quitar uno o más campos de cabecera del paquete, mientras que la pila regeneradora 830 de cabecera ilustra algunos de los componentes que pueden utilizarse para regenerar la cabecera de paquetes. La pila desmenuzadora 802 de cabecera podría proporcionarse, por ejemplo, dentro de un tipo de adaptador de ANI (p. ej., el

50 ANI_AD 112, Fig. 1), mientras que la pila regeneradora 830 de cabecera puede residir, por ejemplo, en un tipo de adaptador de terminal (p. ej., el term_AD 136, Fig. 1).

Con referencia a la Fig. 8, la pila desmenuzadora 802 de cabecera incluye las capas 804 de RTP y UDP, y una capa 806 de IP. Las capas de RTP / UDP / IP generan un paquete 808 de RTP (que incluye un sello temporal en la cabecera 55 de RTP). Luego, en la pila desmenuzadora 802 de cabecera, el paquete 808 de RTP se proporciona a un desmenuzador (HS) 810 de cabecera para desmenuzar o retirar una o más cabeceras o campos de cabecera. Se proporcionan las capas L1 y L2 812, donde L2 puede ser una capa del enlace de datos, y la capa L1 puede ser una capa física, por ejemplo. Podrían proporcionarse otras capas según fuera necesario. De manera similar, la pila regeneradora 830 de cabecera incluye las correspondientes capas L1 y L2 820, un regenerador (HR) 822 de cabecera 60 que regenera la cabecera (incluyendo el sello temporal de RTP) para proporcionar el paquete completo 824 de RTP (incluyendo las cabeceras de RTP / UDP / IP). El paquete 824 se proporciona a la capa 826 de IP y luego a las capas 828 de UDP y RTP. Las capas L1 y L2 de la pila desmenuzadora 802 de cabecera y la pila regeneradora 830 de

cabecera están en comunicación por un enlace 815 o interfaz aérea (tal como un enlace 140 de RF), o por una red. Por ejemplo, los paquetes de Voz sobre IP se pasan a través del desmenuzador 810 de cabecera antes de la transmisión por el enlace 815 (p. ej., enlace o red inalámbricos). En el extremo receptor (en la pila regeneradora 830 de cabecera), el regenerador 822 de cabecera regenera las cabeceras antes de la entrega al destinatario. Las capas L2/L1 pueden

5 proporcionar la conexión similar a un circuito, esto es, proporcionando un canal de tasa de bits esencialmente constante entre el desmenuzador 810 de cabecera y el regenerador 822 de cabecera. Además, para una eficiencia máxima, la capa L1 también puede llevar a cabo la optimización de la carga útil de voz, como la protección de bits impares, además de la codificación e intercalación optimizadas de canal. Obsérvese que el concepto de desmenuzamiento de cabecera es aplicable independientemente de si se hace o no la optimización de la carga útil.

10 En funcionamiento, el desmenuzador (HS) 810 de cabecera elimina la fluctuación de retardo en los paquetes entrantes del RTP, y los reproduce según el sello temporal (TS) del RTP en la cabecera. Aquí, la eliminación de la fluctuación de retardo significa programar la transmisión de la muestra de voz por la conexión similar a un circuito, o el canal de tasa de bits esencialmente constante, según el sello temporal. En otras palabras, los paquetes, después de la retirada o el

15 desmenuzamiento de las cabeceras, se transmiten por el canal similar a un circuito o el canal de tasa de bits esencialmente constante, en momentos basados en su sello temporal en el paquete. Los paquetes con fluctuación de retardo excesiva se descartan, utilizando la función de reducción de fluctuación de retardo (JRF 115, Fig. 1), por ejemplo. El regenerador (HR) 822 de cabecera reconstruye los campos de IP/UDP/RTP, que pueden clasificarse en las siguientes categorías:

20 a) Estática: El valor no cambia durante la sesión, p. ej., direcciones IP b) No estática: El valor podría cambiar, en principio, entre un paquete y el siguiente, pero, en la práctica, para la voz, el único campo no estático que es esencial preservar durante el desmenuzamiento de la cabecera es el sello temporal (TS) del RTP. También se preserva el número (SN) de secuencia del RTP. Los campos

25 estáticos pueden transferirse una vez y para siempre como parte de una cabecera completa en la fase de inicialización, al comienzo de la sesión. Puede utilizarse un mecanismo fiable de entrega (p. ej., utilizando Acuses de Recibo, o Ack, desde el receptor de RTP para acusar recibo de la información de inicialización). El sello temporal y el número de secuencia se expondrán brevemente.

30 1. Sello Temporal (TS) del RTP

En el caso de la voz, el sello temporal (TS) del RTP aumenta linealmente como una función del reloj común (es decir, el temporizador de origen) en el origen del RTP. Si el intervalo temporal entre muestras de voz consecutivas es de T mseg, entonces el sello temporal de RTP de la cabecera n (generada en el momento n*T mseg) = sello temporal de

35 RTP de la cabecera 0 (generado en el momento 0) + TS_tranco * n, donde TS_tranco y T son constantes dependientes del códec de voz. Esto es verdad si hay un paquete por muestra de habla (voz). Más en general, el sello temporal (TS) de RTP es de la forma TS0 + m * TS_tranco, donde TS0 es < TS_tranco y m es un número entero. El mismo comportamiento se ve en el desmenuzador (HS) de cabecera después de que se ha eliminado la fluctuación de retardo.

40 Al comienzo de una sesión o conexión, se lleva a cabo una fase de inicialización para inicializar el receptor del RTP (es decir, inicializar el regenerador de cabecera). En la fase de inicialización, el desmenuzador de cabecera sigue enviando información de inicialización (Info_inic) hasta que se recibe un Ack desde el receptor. Info_inic(n) consiste esencialmente de la cabecera completa n de IP/UDP/RTP (incluyendo un sello temporal inicial y un número de

45 secuencia). El número de secuencia del RTP se utiliza para identificar esta específica cabecera de inicialización, dado que las subsiguientes cabeceras de inicialización incluirán números de secuencia mayores (suponiendo que la primera cabecera de inicialización no tenga acuse de recibo).

En el regenerador (HR) 822 de cabecera, cuando la Info_inic(n) se recibe correctamente, el HR 822 envía un acuse de

50 recibo ack(n). Una vez que el regenerador (HR) 822 de cabecera ha acusado recibo de una cabecera completa, el HS 810 deja de enviar cabeceras completas. El HR 822 también inicia un contador local de sellos temporales que se inicializa con el sello temporal de RTP recibido en la Info_inic(n). El contador de TS es similar al temporizador del receptor en la Fig. 1, pero el contador de TS se incrementa en TS_tranco cada T mseg (en lugar de en 1, pero es el mismo principio que el temporizador del receptor). Para las subsiguientes tramas de voz desmenuzadas (es decir,

55 paquetes de RTP donde las cabeceras han sido desmenuzadas o quitadas), el TS del RTP se regenera a partir del contador del sello temporal (TS). El temporizador del receptor (temporizador de TS) tiene la misma frecuencia que el reloj o temporizador utilizado en el origen del RTP (es decir, el temporizador de origen) para generar el sello temporal. Además, la conexión similar a un circuito proporciona una tasa de bits esencialmente constante y, de esta manera, los retardos de paquete no son variables, o no cambian entre paquete y paquete. Como resultado, no hay ninguna

60 fluctuación de retardo de paquete debida al canal de tasa de bits esencialmente constante. Por lo tanto, después de que el receptor de RTP recibe la información de inicialización, incluyendo un valor inicial de sello temporal (TS0), el receptor de RTP puede regenerar un sello temporal correcto para cada paquete subsiguiente (después de la

inicialización), basándose sólo en el contador del sello temporal (o temporizador del receptor).

El canal de tasa de bits esencialmente constante, proporcionado entre el desmenuzador 810 de cabecera y el regenerador 822 de cabecera, sólo necesita suministrar un número predeterminado de bits durante un periodo 5 predeterminado de tiempo entre el desmenuzador 810 de cabecera y el regenerador 822 de cabecera, pero esta función puede efectuarse de varias maneras distintas. Por ejemplo, el canal puede ser un canal de tasa de bits esencialmente constante que está dedicado al desmenuzador 810 y al regenerador 822, o compartido entre varios usuarios. El canal puede proporcionar, por ejemplo, un bit cada milisegundo, o proporcionar 100 bits cada 100 milisegundos, pero donde la tasa de bits puede no ser constante (es decir, puede variar) dentro de un periodo de 100

10 ms. Como un ejemplo adicional, el canal puede proporcionar el número predeterminado de bits mediante una o más ráfagas de datos entre el desmenuzador de cabecera y el regenerador de cabecera. Por ejemplo, el canal puede proporcionar un trozo o ráfaga de 1000 bits cada 10 milisegundos. Así, el canal de tasa de bits esencialmente constante sólo necesita proporcionar un número predeterminado de bits durante un periodo de tiempo predeterminado, pero puede lograr esto utilizando distintas técnicas.

2. Número de Secuencia (SN) del RTP

El SN del RTP (según lo ve el HS 810) aumenta normalmente de a 1 desde un paquete al siguiente. Las únicas

20 excepciones son cuando los paquetes se pierden o se desordenan. En el enlace ascendente, no se espera que ocurran pérdidas o desórdenes de paquetes, ya que el desmenuzador (HS) 810 de cabeceras y el origen del RTP están muy cercanos entre sí. Por lo tanto, lo siguiente se aplica al enlace descendente. El HS 810 efectúa un almacenamiento temporal limitado para intentar reordenar los paquetes antes de desmenuzar sus cabeceras. El paquete con el SN n del RTP se considera perdido si aún no ha sido recibido en el momento en que al paquete con el

25 SN (n+1) del RTP se le quita su cabecera. El paquete con el SN m del RTP está desordenado si, en el momento en que es recibido, al paquete con el SN k del RTP se le ha quitado su cabecera, y k > m. La longitud del almacén temporal de reordenamiento es un parámetro de diseño. Un almacén temporal demasiado largo dará como resultado un retardo excesivamente grande, mientras que un almacén temporal demasiado corto dará como resultado demasiados paquetes descartados. El parámetro también depende de la calidad proporcionada por la red IP 108 flujo

30 arriba del HS 810. El HR 822 mantiene un contador de SN que es su mejor estimación del SN. Observando la Info_inic, el HR 822 puede obtener el SN inicial y el número de bits contenidos en un paquete, también conocido como el tamaño del paquete (p_tamaño). El HR 822 inicializa el contador de SN con el SN en Info_inic. El HR 822 “cuenta” entonces los bits de habla recibidos por el canal de tasa de bits esencialmente constante e incrementa el contador de SN para cada p_tamaño bits de habla (no se incrementa cuando no se recibe ningún paquete, p. ej., durante un intervalo de silencio).

35 Según una realización, el HR 822 no cuenta efectivamente los bits recibidos. En cambio, el contador de SN en el HR 822 se incrementa en 1 por la duración de cada paquete, donde una duración de paquete es el tiempo requerido para recibir un paquete de bits (p_bits). Así, la duración del paquete será una función del tamaño del paquete (p_tamaño) y la tasa de bits (que es constante para la conexión similar a un circuito).

40 Así, puede verse que, después de que tiene lugar la inicialización (que proporciona el SN y TS iniciales al HR 822), el HR 822 puede generar los sellos temporales para paquetes secuenciales incrementando el contador de TS en TS_tranco cada T mseg, e incrementando el contador de SN en 1 por cada duración de paquete. Por lo tanto, después de la inicialización, estos campos pueden regenerarse en el HR 822 con referencia sólo a un reloj local (suponiendo que TS_tranco y la duración del paquete sean conocidos por el HR 822). El aumento del contador de SN en base al

45 tiempo (duración del paquete) en lugar de la cuenta efectiva de los bits recibidos es más robusto ante los errores. En el caso de que uno o más bits se descarten antes de llegar al HR 822, el contador de SN reflejará el verdadero valor y no se verá afectado por los bits perdidos.

B. Discontinuidades y Cadenas

50 La descripción anterior indica que TS y SN pueden ser completamente desmenuzados por el HS 810 antes de la transmisión por un enlace (p. ej., el enlace 140 de RF), y luego regenerados por el HR 822, manteniendo un reloj o temporizador local (p. ej., incrementando el contador de TS en TS_tranco cada T mseg e incrementando el contador de SN en 1 por cada duración de paquete). Sin embargo, pueden tener lugar uno o más sucesos de discontinuidad básica

55 que, si no se abordan, podrían eventualmente invalidar la regeneración basada en temporizador, anteriormente descrita. Algunos de los sucesos de discontinuidad pueden incluir:

a) Suceso “Nueva ráfaga ": Cambio transitorio en la diferencia de TS entre el paquete n y el (n+1) (inicio de una nueva ráfaga de conversación); esto también puede describirse como un cambio no lineal o un

60 desplazamiento en el sello temporal (TS): b) Suceso “Cambio de tamaño”: Cambio en el tamaño del paquete (p_tamaño), causado por un cambio en el número de tramas de habla empaquetadas en un paquete y/o el tamaño de la trama de habla c) Suceso “Cambio de tranco”: Cambio en TS_tranco (causado, p. ej., por un cambio en el tipo PT de carga

útil).

Definimos una cadena de cabeceras como una secuencia de cabeceras de paquete tales que todos los

paquetes tienen el mismo tamaño (p_tamaño), los números de secuencia son consecutivos, es decir, n, (n+1),

5 (n+2), etc., y los sellos temporales (TS) de los paquetes consecutivos están separados por el mismo incremento TS_tranco. En otras palabras, una cadena de cabeceras puede considerarse como una cadena de cabeceras con algunos campos de paquetes en común (p. ej., el tamaño del paquete), y otros campos que aumentan linealmente entre los paquetes consecutivos, tal como SN y TS. Una cadena es usualmente una ráfaga de conversación (p. ej., una serie de muestras de voz proporcionadas entre intervalos de silencio).

10 La transición desde una cadena a otra puede estar causada por cualquiera de los sucesos de discontinuidad, individualmente o incluso en combinación. En este esquema, cuando una cadena comienza (y la cadena anterior ha terminado), el HS 810 determina qué suceso de discontinuidad ha ocurrido y, en consecuencia, envía la información necesaria de inicialización de cadena (inic_cadena) al HR 822.

15 La Fig. 9 es una tabla que ilustra información que puede proporcionarse en mensajes según una realización a modo de ejemplo de la invención. Info_inic incluye habitualmente una cabecera completa (incluyendo SN y TS completos), y se envía desde el HS 810 al HR 822 (para inicializar el HR 822) al comienzo de la sesión. El HS 810 continuará reenviando la info_inic hasta recibir un acuse de recibo desde el HR 822, antes de continuar enviando los paquetes de

20 datos sin cabecera. A continuación, puede haber una o más cadenas que pueden aparecer, las cuales pueden requerir actualizaciones adicionales de campos o valores que cambian entre una cadena y otra. Estos valores cambiados se proporcionan al HR 822 utilizando inic_cadena.

Inic_cadena incluye el valor de p_tamaño (si ha cambiado desde la cadena anterior), y el valor de TS_tranco (si ha

25 cambiado desde la cadena anterior). Si no ocurre ningún desplazamiento no lineal en el TS desde una cadena a la siguiente, el HR 822 puede continuar regenerando el TS en base al contador de TS utilizado en la vieja cadena. Sin embargo, si ocurre un desplazamiento no lineal en el sello temporal (TS) entre cadenas (es decir, pérdida de temporización), el sello temporal actualizado debe enviarse explícitamente en inic_cadena desde el HS 810 al HR 822. El TS actualizado puede enviarse como un sello temporal comprimido 414 (véase la Fig. 4) anteriormente descrito,

30 mientras se satisfaga la condición 1, según lo anteriormente descrito. En caso contrario, si la condición 1 no se satisface, debe transmitirse el sello temporal actualizado completo al HR 822.

En la modalidad de acuse de recibo, después de que el HS 810 envía inic_cadena al HR 822, el HS 810 puede requerir que el HR 822 acuse recibo (con ack) de la información de cadena actualizada (inic_cadena) antes de que el HS 810

35 pueda enviar los paquetes de datos adicionales (paquetes sin cabecera) al HR 822. En la modalidad de acuse de recibo, o ack, el HS 810 envía repetidamente un mensaje de inic_cadena al HR 822 hasta que el HS 810 recibe un acuse de recibo desde el HR 822 para un mensaje de inic_cadena. Después de recibir un acuse de recibo desde el HR 822, el HS 810 enviará luego los paquetes restantes de la cadena como paquetes de cabecera desmenuzada (ya que el TS y SN para los paquetes de la nueva cadena pueden regenerarse ahora utilizando sólo un reloj o temporizador

40 local). El requisito del acuse de recibo (en la modalidad de acuse de recibo) para el mensaje inic_cadena impide que el HS 810 envíe una nueva cadena sin notificar al HR 822. Por ejemplo, si el HS 810 envía un nuevo mensaje inic_cadena (p. ej., proporcionando campos actualizados o información relacionada con un suceso de discontinuidad) mientras el enlace entre el HS 810 y el HR 822 está temporalmente roto, el HS 810 no puede continuar enviando paquetes con cabeceras desmenuzadas hasta recibir primero el acuse de recibo desde el HR 822,

45 Una vez que el HS 810 está seguro de que el HR 822 ha recibido la información de inic_cadena, las tramas de habla

(p. ej., los paquetes de datos) se envían luego sin la cabecera para el resto de la cadena. Para estas tramas sin cabecera, el TS y el SN se regeneran utilizando un reloj local en el HR 822.

50 El HS 810 puede determinar los sucesos de la siguiente manera:

a) Suceso “Nueva ráfaga”: la diferencia de TS entre el paquete con SN = n y el paquete con SN = (n+1) es

distinta a TS_tranco. Esto significa el comienzo de una nueva cadena o ráfaga de charla. En este caso, para

garantizar la sincronización del SN, inic_cadena consiste en un SN o un SN comprimido (C_SN). Si no hubo

55 ninguna información de SN enviada, el HR 822 no puede estar seguro de que el incremento del contador de SN en 1 por cada duración de paquete brindará un SN preciso. Esto es porque podría haber habido una desconexión de enlace, durante la cual los bits de habla se perdieron entre el HS 810 y el HR. b) Suceso “Cambio de tamaño”: El tamaño del paquete del RTP con SN = n es distinto al del paquete anteriormente recibido; esto afectará el valor de la duración del paquete (la velocidad a la cual se incrementa

60 el contador de SN). Inic_cadena incluye el nuevo valor de p_tamaño. c) Suceso “Cambio de tranco”: Determinado a partir del análisis del campo de tipo de carga útil (PT) en el paquete del RTP; inic_cadena incluye el nuevo valor de TS_tranco.

Estos sucesos de discontinuidad se proporcionan sólo como ejemplos. Son posibles otros tipos de sucesos de discontinuidad.

5 Los sucesos pueden ocurrir en combinación (suceso compuesto). En ese caso, inic_cadena incluye toda la información de los sucesos básicos correspondientes. Por ejemplo, si ocurre el “Nueva ráfaga” en combinación con “Cambio de tamaño”, inic_cadena = {C_SN, nuevo valor de p_tamaño}

C. Procedimiento para enviar Info_inic, Inic_cadena

10 Info_inic se envía normalmente en la modalidad de acuse de recibo, en la cual el HS 810 enviará Info_inic hasta que sea acusado como recibido por el HR 822. Inic_cadena puede enviarse en la modalidad con o sin acuse de recibo. En la modalidad de acuse de recibo, el HS 810 enviará Inic_cadena en cada paquete hasta que sea acusado como recibido por el HR 822. Una vez que se recibe un acuse de recibo, el HS 810 envía sólo bits de habla para el resto de la

15 cadena, sin ninguna cabecera. En la modalidad sin acuse de recibo, el HS 810 enviará Inic_cadena un cierto número (predeterminado) de veces antes de enviar bits de habla sólo para el resto de la cadena. Optativamente, el mensaje inic_cadena puede repetirse a determinados intervalos durante la cadena, para garantizar que el HR 822 esté sincronizado (p. ej., tenga los valores adecuados).

20 Un suceso compuesto, que incluye el suceso básico “Cambio de tamaño” o “Cambio de tranco” requerirá habitualmente que el mensaje Inic_cadena se envíe en la modalidad de acuse de recibo. En ese caso, Inic_cadena llevará un número de generación. El número de generación es un contador incrementado toda vez que cambian p_tamaño o TS_tranco. Se utiliza en el caso donde p_tamaño o TS_tranco cambian rápidamente, para mantener el rastro de qué cambio ha sido acusado como recibido por el HR 822. Por ejemplo, si p_tamaño cambia desde el valor p_tamaño_0 al

25 p_tamaño_1, y luego nuevamente al valor p_tamaño_2, el HS 810 enviará un Inic_cadena que contiene p_tamaño_1, con un número de generación, digamos, 3; luego, a continuación, otro Inic_cadena que contiene p_tamaño_2, con número de generación 4. Recibir un acuse de recibo a continuación del segundo Inic_cadena será ambigua, si no llevaba el número de generación del Inic_cadena cuyo recibo se está acusando. Si el suceso compuesto es sólo "Nueva ráfaga", Inic_cadena (C_SN) puede enviarse en modalidad con o sin acuse de recibo. La modalidad sin acuse

30 de recibo se basa en la idea de que el C_SN se repetirá al menos al comienzo de cada ráfaga de charla. Por lo tanto, la probabilidad de que el HR 822 nunca resincronice su SN es asintóticamente pequeña. Además, si el SN está desincronizado, es sólo a causa de la pérdida de paquetes entre el HS 810 y el HR 822. Por lo tanto, el efecto de una desincronización de SN es que el SN regenerado < el SN correcto. Esto es sólo una inconsistencia transitoria que se corrige haciendo que el SN aumente en el valor de la diferencia en cuanto se reciba el siguiente C_SN. Un aumento de

35 SN en más de 1 será interpretado por el punto extremo receptor del RTP como una o más pérdidas de paquetes y, normalmente, no debería afectar la reproducción del paquete recibido en sí. La modalidad sin acuse de recibo también permite prescindir de un canal para llevar acuses de recibo en estado estable, es decir, después del establecimiento de llamada y entre traspasos.

40 D. Traspaso

Cuando el desmenuzamiento/regeneración de cabeceras se aplica a sistemas celulares u otros sistemas donde las estaciones terminales pueden moverse desde un adaptador de red (ANI_AD) a otro, deberían considerarse los traspasos o transferencias.

45 El traspaso puede modelarse como atravesando tres fases: preparación del traspaso, ejecución del traspaso y culminación del traspaso. Hay una función llamada administrador del traspaso (HO) (que puede proporcionarse en la ANI 110) que decide iniciar la preparación del traspaso. Tradicionalmente, la preparación del traspaso consiste en intercambiar mensajes de señalización con el sistema de destino para reservar recursos en el sistema de destino y

50 para obtener la información necesaria sobre la célula de destino. La ejecución del traspaso es iniciada por el administrador de HO de origen, enviando un comando de HO al terminal receptor (o estación móvil), junto con la información sobre la célula de destino. En respuesta al comando de HO, el terminal (o estación móvil) ejecuta el traspaso. La culminación del traspaso implica el intercambio de señalización entre el terminal o estación móvil y el sistema de destino, la notificación al origen y la liberación de recursos que ya no se necesitan más (p. ej., en el origen).

1. Enlace ascendente

El ANI_AD actúa como un HR 822 para la transmisión de datos del enlace ascendente (véase el enlace ascendente 142, Fig. 1). El ANI_AD de destino debe ser dotado de la información necesaria para regenerar la cabecera completa.

60 Las principales restricciones incluyen la continuidad del TS del RTP y el SN del RTP durante el traspaso (HO).

La Fig. 10 es un diagrama que ilustra un proceso de traspaso según una realización a modo de ejemplo de la presente

invención. El terminal 130 (o la estación móvil MS), por ejemplo, pueden notificar al ANI_AD 112 de origen que el tamaño del paquete ha cambiado, utilizando un mensaje Inic_cadena, etapa 902. El ANI_AD 112 de origen acusa recibo de esta actualización en el p_tamaño, etapa 904. A continuación, el terminal 130 se mueve hacia una nueva área cubierta por el ANI_AD 114 de destino, y el administrador 901 de HO notifica al ANI_AD de origen sobre la 5 preparación para un traspaso (transferencia), etapa 906. El ANI_AD de origen envía entonces una información de inicialización_HO (HO_inic_u) al ANI_AD 114 de destino, etapa 908. HO_inic_u es una visión estimada de la cabecera completa de IP/UDP/RTP. La visión estimada consiste en la última cabecera regenerada, pero con un TS de RTP reemplazado por TS0_u, m_último_u, TS_tranco_u y el valor del Temporizador_u del TS. Estos valores están relacionados con TS_último, el TS de RTP de la última cabecera regenerada, según lo siguiente: TS_último = TS0_u + 10 m_último_u * TS_tranco_u. El Temporizador_u del TS es un contador en el ANI_AD de origen que fue incrementado en 1 cada T mseg. Además, HO_inic_u incluye p_tamaño_u (tamaño actual del paquete en la dirección del enlace ascendente). Del HO_inic_u, el ANI_AD de destino deriva los campos estáticos, así como valores iniciales aproximados para los campos cambiantes (TS del RTP y SN del RTP). Un comando de traspaso se envía desde el administrador 901 de HO al terminal 130 (estación móvil), etapa 910, causando que el terminal 130 conmute y utilice ahora el ANI_AD

15 de destino para la comunicación. Sin embargo, un administrador de HO puede no ser necesario, ya que pueden emplearse otras técnicas para iniciar un traspaso.

Se considera un traspaso como interruptor de cualquier cadena en marcha. Por lo tanto, después de la culminación del traspaso, la primerísima muestra de habla a enviar se gestiona siempre como una nueva cadena, que requiere enviar 20 información (HO_sinc_u) de inicialización, etapa 912. Hay tres momentos significativos en el tiempo: ST1, que es el inicio de la preparación del HO, ST2, que es la recepción por la MS del comando de HO, y ST3, que es el momento en que el ANI_AD de origen tomó la instantánea de su información interna para enviarla en HO_inic_u. Sea HOT el tiempo transcurrido desde ST1 a ST2. A partir del diseño del sistema, hay una cota superior para HOT: HOT < HOT_máx. Un cuarto momento significativo en el tiempo es ST4: la primera vez en que el terminal 130 quiere reanudar enviar habla

25 en el sistema de destino después del HO. En ST4, el terminal 130 (MS) determina si el cambio más reciente en p_tamaño_u ha sido acusado como recibido hasta el momento ST2 - HOT_máx. Si es así, el terminal 130 está seguro de que HO_inic_u contenía el valor actualizado de p_tamaño_u. Por lo tanto, no hay ninguna necesidad de incluirlo en HO_sinc_u. Esto es porque los momentos en el tiempo se ordenan como ST1 < ST3 < ST2. En caso contrario, el terminal 130 (MS) incluirá el nuevo valor de p_tamaño_u en HO_sinc_u. El mismo algoritmo se aplica a TS_tranco_u.

30 En todos los casos, HO_sinc_u incluye C_SN. C_SN se necesita porque hubo una ruptura causada por el HO. C_TS se necesita si las tasas de bits, las duraciones de paquetes, etc., en los sistemas de origen y de destino no están sincronizadas. Es probable que sea este el caso. HO_sinc_u se envía preferiblemente en modalidad de acuse de recibo.

35 HO_inic_u y HO_sinc_u son utilizados por el ANI_AD 114 de destino para regenerar la cabecera completa de la siguiente manera. Todos los campos, excepto TS y SN, se copian del HO_inic_u. SN se obtiene descomprimiendo el C_SN en HO_sinc_u. TS se determina descomprimiendo el C_TS en HO_sinc_u.

40 2. Enlace descendente

El papel del HS se transfiere desde un ANI_AD a otro. Después del traspaso, las cabeceras se encaminan por una nueva trayectoria que atraviesa el nuevo ANI_AD en lugar del viejo ANI_AD. Como resultado, podría haber una discontinuidad en la temporización para la regeneración del TS del RTP en el terminal 130 (MS).

45 Para gestionar el traspaso para el enlace ascendente, cuando el administrador de HO decide iniciar la preparación del traspaso, notificará al ANI_AD de origen. El ANI_AD de origen envía entonces una información de inicialización_HO (HO_inic_d) al ANI_AD de destino. HO_inic_d consiste en p_tamaño_d y TS_tranco_d, que son los valores con recibo acusado por última vez por la MS, junto con su número de generación. La primera vez en que el ANI_AD de destino

50 quiere enviar habla después del HO, el ANI_AD de destino tiene que enviar HO_sinc_d. HO_sinc_d consiste en C_TS y C_SN. Si el nuevo p_tamaño difiere del p_tamaño_d, HO_sinc_d también contiene el nuevo valor de p_tamaño. Si no es así, HO_sinc_d sólo contiene el número n de generación de p_tamaño_d. La MS utiliza el número de generación para recuperar el p_tamaño correcto. Esto supone que la MS mantenía en memoria los pocos últimos valores de p_tamaño, junto con su número de generación. El mismo algoritmo se aplica a TS_tranco. HO_inic_d se envía hasta

55 que se acusa su recibo por parte del MS_AD. HO_sinc_d se envía en modalidad de acuse de recibo. El proceso de traspaso se ilustra en la figura 2. El caso mostrado es: el cambio más reciente en p_tamaño_u ha sido acusado como recibido hasta el momento ST2 – HOT_máx.

E. Envío de Mensajes

60 Cada una de las informaciones anteriores puede enviarse en banda o fuera de banda. En el enfoque en banda, la información se envía por el canal del habla robando los bits de voz menos significativos. En el enfoque fuera de banda, un canal transitorio dedicado se configura y se desmantela cuando se recibe un acuse de recibo. Es posible una combinación de enfoques en banda y fuera de banda, en la cual se intenta el enfoque fuera de banda, pero el enfoque en banda es una solución de reserva si no hay ningún recurso para un canal transitorio. Los acuses de recibo pueden enviarse en banda, o fuera de banda por su propio canal dedicado de acuse de recibo, o fuera de banda a horcajadas

5 sobre los otros canales transitorios dedicados (TIC, etc.)

1. En banda

Independientemente de cómo se realice el canal de habla similar a un circuito, puede modelarse como un canal que

10 puede transmitir B bits cada T milisegundos. Si S es el tamaño de una trama de habla en bits, S < B. Con los códecs de voz a la vista, se espera que Info_inic sea mayor que S. Por lo tanto, un Info_inic no puede enviarse en el espacio de una única trama de habla. Sin embargo, hay un factor R >= 1 tal que (R-1)*S < H < R*S. Los Info_inic(n) pueden transportarse por el canal similar a un circuito partiéndolos en trozos de B bits y enviando un trozo cada T milisegundos. Una cabecera completa consumirá el espacio de R muestras de habla consecutivas. La Fig. 11 es un diagrama que

15 ilustra una inicialización para el caso en banda, según una realización a modo de ejemplo de la invención. Si hay una actividad vocal continua, los Info_inic enviados son Info_inic(0), Info_inic(R), Info_inic(2R), etc., hasta que se reciba un acuse(n) de recibo. En la Fig. 11, estos mensajes info_inic se muestran como info_inic 500 e info_inic 502. El desmenuzador de cabeceras acusa recibo del info_inic 500, pero no antes de que el HS 810 envíe un segundo paquete info_inic 502. El siguiente paquete 504 se envía desde el HS 810 al HR 822 como la carga útil 504 del paquete

20 (sin cabecera). El HR 822 regenera entonces el SN y el TS y otros campos de la cabecera.

Info_inic(0) toma el lugar de las muestras de habla 0, 1, ..., (R-1), Info_inic(R) toma el lugar de las muestras de habla R, (R+1), ..., (2R-1), y así sucesivamente. Si hay actividad vocal discontinua, digamos que la cabecera 0 es seguida por un intervalo de silencio de L*T mseg, entonces se repite el Info_inic(0). Toda la otra información (inic_cadena,

25 HO_sinc_d, HO_sinc_u, Ack) tiene un tamaño muy por debajo de S, por lo que caben en el espacio de una trama de habla. Roban los bits de voz menos significativos. Para mayor simplicidad, el análisis no tiene en cuenta la expansión causada por la codificación del canal, pero el concepto es válido con o sin la codificación del canal. El proceso de inicialización para el caso en banda se muestra en la figura 3.

30 2. Fuera de banda

La Fig. 12 es un diagrama que ilustra una inicialización para el caso fuera de banda, según una realización a modo de ejemplo de la invención. En el enfoque fuera de banda, se configura un canal por separado, con el ancho de banda adecuado, para llevar sólo el Info_inic simultáneamente con el habla, que es transportada por un canal de habla. El 35 canal por separado se llama el canal de inicialización transitorio (TIC). El sistema puede intentar adjudicar bastante ancho de banda para el TIC, a fin de permitir enviar una cabecera completa una vez cada T mseg. El TIC está diseñado para tener una relación de temporización fija con el canal de habla. Los acuses de recibo pueden enviarse fuera de banda, adjudicando un canal de acuse de recibo transitorio (TAC), o enviarse fuera de banda, pero a horcajadas sobre un canal transitorio directo. El HO_sinc_u puede enviarse fuera de banda por un canal transitorio de sincronización de

40 traspaso del enlace ascendente (TUHOSC). El TUHOSC se desmantela cuando se acusa recibo del HO_sinc_u. Lo mismo se aplica a HO_sinc_d, que utiliza un canal transitorio de sincronización de traspaso del enlace descendente (TDHOSC).

3. Casos de Fallos

45 Puede haber casos donde el ANI_AD de destino no tendrá el HO_inic en el momento en que se acaba la ejecución del traspaso. Las razones incluyen un retardo excesivo en la red de señalización entre los dos ANI_AD, la necesidad de ejecutar rápidamente el traspaso, etc. En esos casos, la red enviará una notificación a la MS, que reinicia entonces el proceso de inicialización, como al comienzo de la llamada.

4. Caso Común Donde P-Tamaño y TS_tranco son Constantes

El caso en que p_tamaño y TS_tranco son constantes es, con gran diferencia, el más común para la voz. En este caso, no se aplican ninguna de las consideraciones causadas por el posible cambio de p_tamaño y TS_tranco. El esquema

55 genérico se simplifica. No se necesita el HO_init_d. HO_sinc_d y HO_sinc_u sólo llevan el C_SN y el C_TS. El Inic_cadena lleva el C_SN. Lleva el C_TS sólo si hay un cambio de temporización entre una cadena y la siguiente. El terminal (MS) no tiene que mantener en memoria los últimos pocos valores de p_tamaño y TS_tranco. En caso de HO, el terminal (MS) no tiene que determinar el incluir o no p_tamaño_u en HO_sinc_u.

60 Como se ha descrito anteriormente, la única información en las cabeceras de IP/UDP/RTP que es esencial para la voz básica son los campos estáticos y el sello temporal (TS) del RTP, y el número de secuencia (SN) del RTP también es muy deseable. El esquema descrito en el presente documento logra la transparencia para estos campos de información, y brinda una ventajosa eficiencia de compresión del sobregasto de la cabecera. La continuidad de todos los campos estáticos y no estáticos se mantiene a lo largo del traspaso. La gestión del ancho de banda también se simplifica, porque son posibles enfoques en banda así como los fuera de banda. Como se mantiene la transparencia para el TS del RTP y el SN del RTP, incluso es posible conmutar alternadamente entre el esquema de

5 desmenuzamiento de cabecera y el esquema de compresión de cabecera descrito en el presente documento, que mantiene la transparencia para todos los campos. Puede ser necesario conmutar a la compresión de cabecera cuando, por ejemplo, se añade otro medio a la voz.

III.

Esquema Basado en Temporizador y Referencia

A.

Panorama General del Esquema Basado en Temporizador y Referencia

El esquema basado en temporizador y referencia se basa en las observaciones de que (1) los sellos temporales del RTP, cuando se generan en el origen del RTP, se correlacionan con una función lineal del tiempo transcurrido entre los 15 paquetes, y (2) los TS del RTP son de la forma TS0 + índice*TS_tranco, donde TS0 y TS_tranco son constantes, e índice es un número entero (en lo sucesivo, se denominará al índice como el TS empaquetado del RTP). Por lo tanto, en el funcionamiento normal, los sellos temporales del RTP recibidos en el descompresor también se correlacionan con un temporizador continuamente incrementado, con una distorsión creada sólo por la fluctuación de retardo acumulada entre el origen y el descompresor. Como la fluctuación de retardo acumulada incluye la fluctuación de retardo de “red” 20 (fluctuación de retardo entre el origen y el compresor) y la fluctuación de retardo de “radio” (fluctuación de retardo entre el compresor y el descompresor), el compresor puede calcular una cota superior de la fluctuación de retardo acumulada sumando a la fluctuación de retardo de red observada una cota superior de la fluctuación de retardo de radio. El compresor envía entonces sólo como TS comprimido del RTP los “k” bits menos significativos del TS empaquetado del RTP. El descompresor descomprime el TS del RTP calculando primero una aproximación, y 25 refinando luego la aproximación con la información en el TS comprimido del RTP para determinar el valor exacto. La aproximación se obtiene añadiendo al TS del RTP de la cabecera previamente descomprimida un valor proporcional al tiempo transcurrido desde que se recibió la cabecera previamente descomprimida. El valor exacto del TS del RTP se determina como el más cercano a la aproximación, cuyos k bits menos significativos del correspondiente TS empaquetado del RTP coincidan con el TS comprimido del RTP. El compresor escoge un valor k como el valor más

30 pequeño permitido que dejaría que el descompresor descomprimiera correctamente, en base a la cota superior de la fluctuación de retardo acumulada.

B. Caso de la Voz

35 Primero, se describirá el esquema basado en temporizador y referencia con respecto a la voz. Como ejemplo, si el intervalo temporal entre muestras consecutivas de habla es de 20 mseg, entonces el sello temporal del RTP de la cabecera n (generada en el momento n*20 mseg) = sello temporal del RTP de la cabecera 0 (generada en el momento 0) + TS_tranco*n, donde TS_tranco es una constante que depende del códec de voz. En consecuencia, los TS del RTP en las cabeceras que llegan al descompresor también siguen un patrón lineal como función del tiempo, pero menos

40 estrechamente, debido a la fluctuación de retardo de retardo entre el origen y el descompresor. En el funcionamiento normal (ausencia de caídas o fallos), la fluctuación de retardo de retardo está acotada, para satisfacer los requisitos del tráfico conversacional en tiempo real.

En este esquema, el receptor utiliza un temporizador para obtener una aproximación del TS del RTP de la cabecera 45 actual (la que ha de descomprimirse), luego refina la aproximación con la información adicional recibida en la cabecera comprimida.

Por ejemplo, supongamos lo siguiente:

50 La Última_cabecera es la última cabecera exitosamente descomprimida, donde TS_último es el último TS del RTP, y p_TS_último es el último TS empaquetado del RTP (en el receptor); T es el espaciado temporal normal entre dos muestras consecutivas de habla; TS_tranco es el incremento del TS del RTP cada T mseg; La Cabecera_actual es la cabecera del paquete actual a descomprimir, donde TS_actual es el TS actual del

55 RTP, y p_TS_actual es el TS empaquetado actual del RTP; RFH es el número de secuencia de una cabecera cuyo acuse de recibo fue recibido por el compresor, donde TS_RFH es el TS del RTP, y p_TS_RFH es el TS empaquetado del RTP; el Temporizador es un temporizador incrementado cada T mseg, donde tanto el compresor como el descompresor mantienen cada uno un Temporizador, indicados como S_temporizador y R_temporizador,

60 respectivamente; T_RFH es el valor del Temporizador cuando se ha recibido el RFH, y T_actual es el valor del mismo Temporizador cuando se ha recibido la Cabecera_actual; y

N_fluctuación de retardo(n, m) es la fluctuación de retardo de red observada de la cabecera n con respecto a la cabecera m (la cabecera n se recibe a continuación de la cabecera m); donde N_fluctuación de retardo(n, m) es calculada por el compresor de la siguiente manera:

5 N_fluctuación de retardo(n, m) = Temporizador(n,m) – (TS empaquetado del RTP de la cabecera n – TS empaquetado del RTP de la cabecera m),

donde Temporizador (n,m) es el tiempo transcurrido desde la cabecera m hasta la cabecera n, expresado en unidades de T mseg. N_Fluctuación de retardo(n,m) puede ser positiva o negativa. 10 N_Fluctuación de retardo en el compresor es la fluctuación de retardo de red, cuantizada en unidades de T mseg.

R_Fluctuación de retardo(n,m) es la fluctuación de retardo de radio de la cabecera n con respecto a la cabecera m, predicha por el compresor. R_Fluctuación de retardo depende sólo de las características del canal compresor

15 descompresor (CD-CC). No hay que calcular R_Fluctuación de retardo con precisión, una buena cota superior para R_fluctuación de retardo es suficiente. Por ejemplo, u na cota superior puede ser Máx-radio_fluctuación de retardo, la máxima fluctuación de retardo en el CD-CC, si se conoce.

20 Así, según lo anterior, la fluctuación de retardo acumulada para un paquete se calcula como la suma de la fluctuación de retardo de red y de radio:

Además, el TS del RTP se calcula de la siguiente manera:

25 TS del RTP = TS0 + índice*TS_tranco,

donde TS0 < TS_tranco e índice es un número entero. Así, TS_último = TS0 + índice_último*TS_tranco, y TS_actual = TS0 + índice_actual*TS_tranco.

30 1. Compresor

El compresor envía en la cabecera comprimida los k bits menos significativos de p_TS_actual.

El compresor ejecuta el siguiente algoritmo para determinar k: 35 Calcular Máx_fluctuación de retardo_red;

Calcular J1 = Máx_fluctuación de retardo_red + Máx_fluctuación de retardo_radio + J,

40 donde J = 2 es un factor para compensar el error de cuantización causado por los Temporizadores en el compresor y descompresor, que puede ser +1 o -1; y

Hallar el menor número entero k que satisface una condición de:

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

La fluctuación de retardo de red en el compresor puede calcularse según tres procedimientos distintos, a saber, un primer procedimiento ilustrado en la Fig. 13, un segundo procedimiento ilustrado en la Fig. 4 y un tercer procedimiento ilustrado en la Fig. 15. Los procedimientos segundo y tercero se describen más adelante como la Opción 1 y la Opción

50 2, respectivamente. El primer procedimiento es adecuado para calcular la fluctuación de retardo de red. Sin embargo, los procedimientos preferidos para calcular la fluctuación de retardo de red en el compresor son los procedimientos segundo y tercero descritos como Opción 1 y Opción 2, respectivamente, más adelante.

Según se ilustra en la Fig. 13, de acuerdo al primer procedimiento, la fluctuación de retardo de red para un paquete

55 específico en el compresor se calcula utilizando información con respecto al paquete inmediatamente precedente. Así, por ejemplo, la fluctuación de retardo de red para el paquete 2 (j2) se calcula utilizando información con respecto al paquete 1, la fluctuación de retardo de red para el paquete 3 (j3) se calcula utilizando información con respecto al paquete 2, la fluctuación de retardo de red para el paquete 4 (j4) se calcula utilizando información con respecto al paquete 3 y la fluctuación de retardo de red para el paquete 5 (j5) se calcula utilizando información con respecto al

60 paquete 4.

Así, según la Fig. 13, la fluctuación de retardo de red para el paquete 2 es igual a la fluctuación de retardo calculada j2, la fluctuación de retardo de red para el paquete 3 es igual a la fluctuación de retardo calculada j3, la fluctuación de retardo de red para el paquete 4 es igual a la fluctuación de retardo calculada j4 y la fluctuación de retardo de red para el paquete 5 es igual a la fluctuación de retardo calculada j5.

5 Opción 1:

Las etapas utilizadas para calcular la fluctuación de retardo de red para el segundo procedimiento de la Opción 1 se ilustran en la Fig. 14. En la Opción 1, la fluctuación de retardo de red para un paquete específico se calcula utilizando información con respecto a un paquete de referencia. Así, suponiendo que el paquete 2 es el paquete de referencia

10 según se ilustra en la Fig. 14, la fluctuación de retardo j3 del paquete 3 se calcula utilizando información con respecto al paquete 2 de referencia, la fluctuación de retardo j4 del paquete 4 se calcula utilizando información con respecto al paquete 2 de referencia y la fluctuación de retardo j5 del paquete 5 se calcula utilizando información con respecto al paquete 2 de referencia.

15 Según el segundo procedimiento de la Opción 1, como se ilustra en la Fig. 14, si se supone que la fluctuación de retardo j3 = 2, la fluctuación de retardo j4 = 3 y la fluctuación de retardo j5 = -1, entonces, antes del paquete 5, N_fluctuación de retardo_mín = 2 y N_fluctuación de retardo_máx = 3, mientras que, en el paquete 5, N_fluctuación de retardo_mín = -1 y N_fluctuación de retardo_máx = 3. Así, la máxima (Máx) fluctuación de retardo de red en el paquete 5 = N_fluctuación de retardo_máx - N_fluctuación de retardo_mín = 4. En consecuencia, la Máx_fluctuación de

20 retardo_red para el paquete 5 es 4. Las ecuaciones para calcular la fluctuación de retardo de red según el procedimiento de la Opción 1, y una descripción de las mismas, se exponen más adelante.

La fluctuación de retardo de red de un paquete actual se calcula según el procedimiento de la Opción 1 de la siguiente manera:

25 N_fluctuación de retardo (Cabecera_actual, RFH) = (T_actual – T_RFH) – (p_TS_actual -p_TS_RFH);

Actualizar N_fluctuación de retardo_máx y N_fluctuación de retardo_mín, donde N_fluctuación de

30 retardo_máx se define como Máx {N_fluctuación de retardo (j, RFH)}, para todas las cabeceras j enviadas desde el RFH, e incluyendo el RFH. N_fluctuación de retardo_mín se define como Mín {N_fluctuación n de retardo (j, RFH)}, para todas las cabeceras j enviadas desde el RFH, e incluyendo el RFH; y Calcular Máx_fluctuación de retardo_red = (N_fluctuación de retardo_máx – N_fluctuación de retardo_mín).

35 Debería observarse que N_fluctuación de retardo_máx y N_fluctuación de retardo_mín pueden ser positivas o negativas, pero (N_fluctuación de retardo_máx – N_fluctuación de retardo_mín) es positiva.

Opción 2:

40 Las etapas utilizadas para calcular la fluctuación de retardo de red para el tercer procedimiento de la Opción 2 se ilustran en la Fig. 15. En la Opción 2, la fluctuación de retardo de red en un paquete específico se calcula utilizando cálculos de fluctuación de retardo entre el paquete de interés y cada uno entre un número predeterminado de paquetes precedentes. El número predeterminado de paquetes precedentes se define como una ventana, y tal ventana puede tener cualquier valor. En el ejemplo ilustrado en la Fig. 15, la ventana tiene un valor de 4 paquetes precedentes. La

45 ventana podría fijarse en cualquier otro valor, tal como, por ejemplo, 7 paquetes. Además, la ventana podría, por ejemplo fijarse en un valor igual al número de paquetes desde el último paquete de referencia.

Como se ilustra en la Fig. 15, la fluctuación de retardo de red para el paquete 5 se calcula utilizando información con respecto al paquete 1, j(5,1), el paquete 2, j(5,2), el paquete 3, j(5,3) y el paquete 4, j(5,4). Como se ilustra en la Fig. 15,

50 si la fluctuación de retardo de red calculada para el paquete 5 con respecto, respectivamente, al paquete 1, es j(5,1) = 2, al paquete 2, es j(5,2) = 3, al paquete 3, es j(5,3) = 4 y al paquete 4, es j(5,4) = 7, entonces la máx_fluctuación de retardo_red = 7. Las ecuaciones para calcular la fluctuación de retardo de red según el tercer procedimiento de la Opción 2 y una descripción de las mismas se exponen más adelante.

55 La fluctuación de retardo de red de un paquete actual se calcula según el procedimiento de la Opción 2 de la siguiente manera:

Calcular N_fluctuación de retardo (Cabecera_actual, j) = (T_actual – T_j) – (p_TS_actual – p_TS_j) para todas las cabeceras j enviadas antes de la cabecera actual, y pertenecientes a una ventana W, donde T_j es el valor

60 del temporizador cuando se recibió la cabecera j, y p_TS_j es el TS empaquetado del RTP de la cabecera j; y Calcular Máx_fluctuación de retardo_red = |Máx N_fluctuación de retardo (Cabecera_actual, j)| para todo j en la ventana W.

En el caso en que se dispone de una retroalimentación desde el descompresor, la ventana W incluye cabeceras enviadas desde la última cabecera conocida como correctamente recibida (p. ej., con acuse de recibo). En el caso de que no haya retroalimentación, la ventana W incluye las últimas L cabeceras enviadas, donde L es un parámetro.

2. Descompresor

Para descomprimir el TS del RTP de la Cabecera_actual, el receptor calcula el tiempo transcurrido desde que se recibió la Última_cabecera, en unidades de T mseg. Ese tiempo, el Temporizador (Cabecera_actual, Última_cabecera),

10 se añade a p_TS_último, para dar una aproximación de p_TS_actual. El receptor determina luego el valor exacto de p_TS_actual escogiendo el valor más cercano a la aproximación, cuyos k bits menos significativos coincidan con el TS comprimido del RTP. El TS_actual se calcula luego como TS0 + (p_TS_actual)*TS_tranco.

El Temporizador (Cabecera_actual, Última_cabecera) puede calcularse como (T_actual – T_último), donde T_actual y

15 T_último son los valores de R_Temporizador cuando se recibieron, respectivamente, la Cabecera_actual y la Última_cabecera.

3. Prueba de exactitud

20 A fin de demostrar la corrección del esquema basado en temporizador y referencia, se supone lo siguiente:

TS_Aprox es la aproximación de p_TS_actual, calculada por el descompresor como p_TS_último +

Temporizador (Cabecera_actual, Última_cabecera); y

TS_Exacto es el valor exacto de p_TS_actual.

25 En base a lo anterior, entonces:

|TS_Aprox – TS_Exacto| <= |Fluctuación de retardo (Cabecera_actual, Última_cabecera)|; Debido a la definición de Máx_fluctuación de retardo_red en el compresor:

30 |Fluctuación de retardo (Cabecera_actual, Última_cabecera)| < J1, Donde J1 = Máx_fluctuación de retardo_red + Máx_fluctuación de retardo_radio + J.

J es un factor añadido para compensar el error de cuantización causado por los Temporizadores en el compresor y el descompresor, que puede ser +1 o -1. Por lo tanto, J = 2 es suficiente.

35 Así, se deduce que:

|TS_Aprox – TS_Exacto| < J1

40 Para calcular el TS_Exacto sin ambigüedad, es suficiente escoger k de forma tal que se satisfaga la condición de (2*J1

+ 1) < 2k.

4. Caso de Desorden de Paquetes Antes del Compresor

45 El Desorden de Paquetes puede detectarse por un número decreciente de secuencia del RTP (SN del RTP). Cuando eso ocurre, el compresor puede codificar el TS empaquetado del RTP utilizando un esquema distinto, por ejemplo, VLE. El descompresor es notificado de la codificación distinta por los bits indicadores adecuados en la cabecera comprimida.

50 Otra opción es aplicar el algoritmo normal del Esquema Basado en Temporizador y Referencia: es probable que el Desorden dé como resultado un mayor valor de k.

5. Enlace ascendente

55 En sistemas inalámbricos, para la dirección del enlace ascendente, la fluctuación de retardo de red es cero (ya que tanto el origen del RTP como el compresor están situados en el terminal inalámbrico), y la fluctuación de retardo de radio está normalmente acotada y controlada para que se mantenga muy pequeña. Por lo tanto, el k esperado será muy pequeño y constante, lo que minimiza la fluctuación del tamaño de la cabecera. Esta es una ventaja muy significativa para la gestión del ancho de banda, ya que para el enlace ascendente, el terminal usualmente tiene que

60 solicitar ancho de banda aumentado de la red. Además, no hay ningún desorden de paquetes. En consecuencia, el esquema basado en temporizador está extremadamente bien adaptado para el enlace ascendente.

6. Enlace descendente

Para la dirección del enlace descendente, la fluctuación de retardo de red no es cero, pero la fluctuación de retardo global es normalmente pequeña, para satisfacer los requisitos de tiempo real. El k esperado será aún pequeño y 5 usualmente constante. Puede haber más fluctuaciones en k, pero la gestión del ancho de banda es menos conflictiva, ya que la red controla la adjudicación del ancho de banda.

7. Traspaso

10 En sistemas celulares, hay un enlace de radio MS-a-red y un enlace de radio red-a-MS, denominados, respectivamente, enlace ascendente y enlace descendente. Cuando se aplica la compresión / descompresión a enlaces celulares, hay una función basada en la MS, MS_AD (adaptador de MS), que hace la compresión y la descompresión para el enlace ascendente y el enlace descendente, respectivamente. Hay una entidad basada en la red, llamada ANI_AD (adaptador de infraestructura de red de acceso) que hace la descompresión y la compresión para

15 el enlace ascendente y el enlace descendente, respectivamente.

El caso específico de traspaso a considerar es el traspaso intra-ANI_AD, donde puede haber una perturbación causada por la conmutación desde el viejo ANI_AD a un nuevo ANI_AD. La cuestión es cómo mantener la continuidad de la información a lo largo del traspaso, de forma tal que, después del traspaso, la compresión / descompresión en el

20 MS_AD y el nuevo ANI_AD continúen sin perturbación.

Hay dos procedimientos alternativos para el traspaso, descritos más adelante:

a. Primer procedimiento

25 El primer procedimiento utiliza el esquema de tomar una instantánea de la información de contexto intercambiada entre el ANI_AD y el MS_AD, con el procedimiento del saludo, según se divulga en la solicitud asociada con Nº de Serie 09/522.497, registrada el 09 de marzo de 1999, la misma fecha que la presente solicitud, para “AN EFFICIENT HANDOFF PROCEDURE FOR HEADER COMPRESSION”, por K. Le. Para el TS del RTP, la información de contexto

30 contiene el TS completo del RTP de una cabecera de referencia. Inmediatamente después del traspaso, los compresores (MS_AD para el enlace ascendente y ANI_AD para el enlace descendente) discontinúan temporalmente el empleo del esquema basado en temporizador y envían un TS comprimido del RTP con respecto al valor de referencia. Por ejemplo, podría utilizarse la codificación VLE, según lo revelado en la solicitud asociada con Nº de Serie 09/522.497, registrada el 09 de marzo de 1999, la misma fecha que la de la presente solicitud, para “AN EFFICIENT

35 HANDOFF PROCEDURE FOR HEADER COMPRESSION”, por K. Le. Una vez que se ha recibido un acuse de recibo, el compresor utiliza el valor con acuse de recibo como el RFH, y conmuta de nuevo al esquema basado en temporizador.

b. Segundo Procedimiento

40 El segundo procedimiento continúa utilizando el esquema basado en temporizador a lo largo del traspaso.

i. Enlace descendente

45 No hay ninguna discontinuidad en el lado receptor, que es la MS. El papel del compresor se transfiere desde un ANI_AD a otro. Después del traspaso, las cabeceras se encaminan por una nueva trayectoria que atraviesa el nuevo ANI_AD en lugar del viejo ANI_AD.

-

Compresor

50 El viejo ANI_AD transfiere al nuevo ANI_AD una instantánea de la siguiente información: T_RFH, p_TS_RFH, valor actual de S_Temporizador, TS0 y TS_tranco, utilizando el procedimiento del saludo. (Los valores de la instantánea se indicarán con un asterisco, p. ej., T_RFH*). El nuevo ANI_AD inicializa su S_Temporizador con el valor actual del Stemporizador recibido desde el viejo ANI_AD, y comienza a incrementar ese temporizador cada T mseg. La

55 inicialización del S_temporizador con el valor actual de S_temporizador del viejo ANI_AD es una descripción conceptual. Si hay un único S_temporizador compartido por múltiples flujos, el S_temporizador efectivo no se reinicializa. En cambio, se registra el desplazamiento entre ese S_temporizador y el valor del viejo ANI_AD. El desplazamiento se tiene en cuenta en futuros cálculos. Para comprimir la primerísima cabecera después del traspaso, el nuevo ANI_AD envía los k bits menos significativos de p_TS_actual. El nuevo ANI_AD determina k, el número de bits

60 a utilizar, de la siguiente manera:

J2 = Cota superior de N_fluctuación de retardo (Cabecera_actual, RFH*) + Máx_fluctuación de 25 retardo_radio + J,

Donde k se selecciona para satisfacer una condición de (2*J2 + 1) < 2k.

5 En lo anterior, Máx_fluctuación de retardo_radio es la máxima fluctuación de retardo en el segmento entre el nuevo ANI_AD y el MS_AD.

Una cota superior de N_fluctuación de retardo (Cabecera_actual, RFH*) se calcula de la siguiente manera:

10 |Temporizador (Cabecera_actual, RFH*) -(p_TS_actual – p_TS_RFH*)| + T_transfer, donde Temporizador (Cabecera_actual, RFH*) es (T_actual – T_RFH*); T_actual es el valor de S_Temporizador en el nuevo ANI_AD cuando se recibió la Cabecera_actual; T-RFH* es el valor recibido desde el viejo ANI_AD; T_transfer es una cota superior del tiempo para transferir la información de contexto desde el viejo ANI_AD al

15 nuevo ANI_AD, expresado en unidades de T mseg; y J = 2.

-

Descompresor

20 Para descomprimir el TS del RTP de la Cabecera_actual, el receptor calcula el tiempo transcurrido desde que se recibió el RFH, en unidades de T mseg. Ese tiempo, Temporizador (Cabecera_actual, RFH), se añade a p_TS_RFH, para dar una aproximación del p_TS_actual. El receptor determina entonces el valor exacto del p_TS_actual escogiendo el valor más cercano a la aproximación, cuyos k bits menos significativos coincidan con el TS comprimido del RTP. El TS_actual se calcula luego como TS0 + (p_TS_actual)*TS_tranco.

25 El tiempo transcurrido desde que se recibió el RFH puede calcularse como (T_actual – T_RFH).

-

Caso de fallo

30 Cuando la información de contexto no puede transferirse al nuevo ANI_AD de manera oportuna, el nuevo ANI_AD enviará el TS completo del RTP hasta que se reciba un acuse de recibo.

ii. Enlace ascendente

35 El papel del descompresor se transfiere desde un ANI_AD a otro. El compresor permanece anclado a la MS.

-

Descompresor

El viejo ANI_AD transfiere al nuevo ANI_AD una instantánea de la siguiente información: T_RFH*, p_TS_RFH*, el valor

40 actual de R_Temporizador*, TS0 y TS_tranco, utilizando el procedimiento del saludo. El nuevo ANI_AD inicializa su R_Temporizador con el valor actual del R_Temporizador recibido desde el viejo ANI_AD2 y comienza a incrementar ese temporizador cada T mseg. La inicialización del R_temporizador con el valor actual del R_temporizador del viejo ANI_AD es sólo una descripción conceptual. Si hay un único R_temporizador compartido por múltiples flujos, el R_temporizador efectivo no se reinicializa. En cambio, se registra el desplazamiento entre ese R_temporizador y el

45 valor del viejo ANI_AD. Ese desplazamiento se tiene en cuenta en futuros cálculos. Para descomprimir la primerísima cabecera después del traspaso, el nuevo ANI_AD calcula Temporizador (Cabecera_actual, RFH) y la añade a p_TS_RFH*, para dar una aproximación del p_TS_actual. El receptor determina entonces el valor exacto de p_TS_actual escogiendo el valor más cercano a la aproximación, cuyos k bits menos significativos coincidan con el TS comprimido del RTP. El TS_actual se calcula luego como TS0 + (p_TS_actual)*TS_tranco.

50 El Temporizador (Cabecera_actual, RFH) puede estimarse como (T_actual – T_RFH*). T_actual es el valor de R_Temporizador cuando se recibió la Cabecera_actual.

-

Compresor

55 El MS_AD envía los k bits menos significativos del p_TS_actual. Determina k, el número de bits a utilizar, de la siguiente manera:

Calcular J2 = cota superior de N_fluctuación de retardo (Cabecera_actual, RFH*) + Máx_fluctuación 60 de retardo_radio + J,

Donde k se selecciona para satisfacer una condición de (2*J2 + 1) < 2k. 26

Aquí Máx_fluctuación de retardo_radio es la fluctuación de retardo máxima en el segmento entre el nuevo ANI_AD y el MS_AD.

5 La cota superior de N_fluctuación de retardo (Cabecera_actual, RFH*) se calcula como |Temporizador (Cabecera_actual, RFH*) - (p_TS_cabecera_actual - p_TS_RFH*)| + T_transfer, donde Temporizador (Cabecera_actual, RFH*) es (T_actual – T_RFH*); T_actual es el valor de S_Temporizador en el nuevo ANI_AD cuando se recibió la cabecera actual; T_RFH* es el valor recibido del viejo ANI_AD;

10 T_transfer es una cota superior del tiempo para transferir la información de contexto desde el viejo ANI_AD al nuevo ANI_AD, expresado en unidades de T mseg; y

J = 2

15 - Caso de Fallo

Cuando la información de contexto no puede transferirse al nuevo ANI_AD de forma oportuna, el nuevo ANI_AD notificará al MS_AD, que envía el TS completo del RTP hasta que se recibe un acuse de recibo.

20 8. Rendimiento del Esquema

Debido a los requisitos conversacionales en tiempo real, se espera que la fluctuación de retardo acumulativa en el funcionamiento normal sea, a lo sumo, sólo de unas pocas veces los T mseg. Por lo tanto, un valor de k alrededor de 4

o 5 es suficiente, ya que una fluctuación de retardo de hasta 16 a 32 muestras de habla puede corregirse.

25 Las ventajas de este esquema son las siguientes:

El tamaño de la cabecera comprimida es constante y pequeño. La cabecera comprimida incluye habitualmente un tipo de mensaje, que indica el tipo de mensaje (k1 bits), una máscara de bits que indica qué

30 campos están cambiando, y un campo que contiene los k bits menos significativos del índice_actual (k bits). Suponiendo que se utilice una máscara de bits MSTI de 4 bits, y k1 = 4, el tamaño de la cabecera comprimida cuando sólo cambia el TS del RTP (este caso es, con gran diferencia, el más frecuente) es de 1,5 octetos. Además, el tamaño no cambia como función de la longitud del intervalo de silencio.

35 No se requiere ninguna sincronización entre el proceso temporizador y el proceso descompresor.

Hay robustez ante errores, ya que la información parcial del TS del RTP en la cabecera comprimida está autocontenida y sólo requiere combinarse con el temporizador del receptor para producir el valor completo del TS del RTP. La pérdida

o corrupción de una cabecera no invalidará las cabeceras comprimidas subsiguientes. 40 El compresor necesita mantener poca información de memoria:

T_RFH, p_TS_RFH, N_fluctuación de retardo_máx, N_fluctuación de retardo_mín, TS0 y TS_tranco en la Opción 1, y {T-j, p-TS-j}, para todas las j en la ventana W, TS0 y TS_tranco en la Opción 2.

C. Reducción de Fluctuación de retardo

Debido a los requisitos conversacionales de tiempo real, puede esperarse razonablemente que las diversas fluctuaciones de retardo expuestas anteriormente sean del orden de unos pocos valores de T mseg en el 50 funcionamiento normal. Sin embargo, no pueden descartarse casos donde la fluctuación de retardo sea mayor, y requiera, por lo tanto, un k mayor. Por ejemplo, puede haber condiciones anormales en la trayectoria desde el origen del RTP al receptor (fallos, etc.), durante la cual las fluctuaciones de retardo lleguen a ser excesivas. Además, puede haber casos donde se desee un valor constante de k, o sea deseable. Para tratar estos casos, puede implementarse una función de reducción de fluctuación de retardo como una interfaz de primer orden con el compresor, para eliminar

55 por filtrado paquetes con fluctuación de retardo excesiva (es decir, fluctuación de retardo que excede algún valor umbral).

En el caso estático (sin traspaso), la fluctuación de retardo se calcula como J1 y se compara con un umbral estático de la siguiente manera: 60 J1 = (n_fluctuación de retardo_máx – N_fluctuación de retardo_mín) + Máx_fluctuación de retardo_radio + J.

En el caso de traspaso, la fluctuación de retardo se calcula como J2 y se compara con un umbral de traspaso de la siguiente manera:

J2 = |Temporizador (Cabecera_actual, RFH*) – (p_TS_actual – p_TS_RFH*)| + T_transfer + Máx_fluctuación 5 de retardo_radio + J.

La principal diferencia con respecto al caso estático sin traspaso es la suma de T_transfer. En la práctica, para poder ejecutar el traspaso en 100 mseg, T_transfer debe estar acotado por alrededor de 100 mseg, por lo que T_transfer = alrededor de 5 o 6 en unidades de T mseg (T = 20 mseg). Un valor de k = 5 es suficiente.

10 Los umbrales estáticos y de traspaso pueden o no ser los mismos.

D. Caso del Vídeo

15 En el caso de una fuente de vídeo del RTP, no es necesariamente cierto que hay un espaciado temporal constante entre los paquetes y, además, el TS del RTP no necesariamente se incrementa en un tranco constante desde un paquete al siguiente. Sin embargo, el TS del RTP y el espaciado temporal entre los paquetes son discretos. Así, de la siguiente manera:

20 Sello temporal del RTP del paquete m = sello temporal del RTP del paquete 0 (generado en el momento 0) + TS_tranco * [índice + ajuste(m)],

donde TS_tranco es una constante que depende del códec, y ajuste(m) es un número entero que depende de m y que refleja las diferencias con respecto a un comportamiento lineal, como en la voz; y

25 el espaciado temporal entre dos paquetes consecutivos es un múltiplo número entero de T mseg.

En lo siguiente, ese comportamiento en el origen del RTP se denomina comportamiento lineal ajustado. Utilizando la misma notación que para la voz, TS_último = TS0 + TS_tranco* [índice_último + ajuste(índice_último)], y TS_actual = TS0 + TS_tranco* [índice_actual) + ajuste(índice_actual]. El parámetro de Ajuste puede ser positivo o negativo. Así, la

30 diferencia principal, en comparación con la voz, es el término adicional Ajuste.

Los TS del RTP en cabeceras que llegan al descompresor también siguen un patrón lineal ajustado como una función del tiempo, pero menos estrechamente, debido a la fluctuación de retardo de retardo entre el origen y el descompresor. En el funcionamiento normal (ausencia de caídas o fallos), la fluctuación de retardo de retardo está acotada, para

35 satisfacer los requisitos del tráfico conversacional en tiempo real.

Como anteriormente, se supone que el TS empaquetado del RTP de la Cabecera_actual = índice_actual + ajuste(índice_actual). La misma notación se utilizará con respecto a p_TS_actual, por ejemplo.

40 Compresor

El compresor envía en la cabecera comprimida los k bits menos significativos de p_TS_actual. El algoritmo para determinar k es el mismo que para la voz.

45 Descompresor

El algoritmo a utilizar es el mismo que para la voz.

1. Traspaso

50 Los dos procedimientos alternativos para el traspaso, descritos para la voz, valen asimismo para el vídeo.

2. Valor de k

55 Para la voz, se mostró que k = 4 ó 5 es suficiente (2k = 16 ó 32). En el caso del vídeo, se requiere un valor mayor de k, debido al Ajuste. Como el vídeo está estructurado en 30 tramas por segundo, |Ajuste| < 30. Por lo tanto, k = 7 u 8 bits deberían ser suficientes en el funcionamiento normal.

Algunos ejemplos de la presente invención se ilustran y/o describen específicamente en el presente documento. Sin

60 embargo, se apreciará que las modificaciones y variaciones de la presente invención están cubiertas por las revelaciones anteriores, y dentro del alcance de las reivindicaciones adjuntas, sin apartarse del ámbito concebido de la invención.

Si bien la presente invención ha sido descrita en detalle e ilustrativamente en los dibujos adjuntos, no está limitada a tales detalles, ya que muchos cambios y modificaciones, reconocibles para aquellos medianamente versados en la tecnología, pueden hacerse a la invención sin apartarse del alcance de la misma.

5 A continuación se describen más aspectos para facilitar el entendimiento de la invención.

En un primer aspecto adicional, se describe un procedimiento de transmisión en una red entre una fuente y un receptor de un campo de cabecera actual de un paquete actual utilizando una técnica de compresión basada en temporizador el 10 procedimiento puede comprender las etapas de proporcionar desde un compresor a un descompresor de un valor inicial de un campo de cabecera; calcular en el compresor un campo de cabecera comprimido del paquete actual en base al campo de cabecera actual del paquete actual y la fluctuación de retardo, en el que dicha etapa de cálculo puede comprender las etapas de: calcular un efecto de fluctuación de retardo que puede tener la red entre una fuente y dicho descompresor en la transmisión de paquetes, y calcular el campo de cabecera comprimido como una parte de un 15 valor de campo, dicha parte puede ser una función de la fluctuación de retardo; recibir el campo de cabecera comprimido del paquete actual en el descompresor; estimar el campo de cabecera del paquete actual en base a tiempo transcurrido en el descompresor entre recibir el campo de cabecera comprimido del paquete actual y recibir un campo de cabecera de un paquete anterior que fue descomprimido, y un valor de campo descomprimido del paquete anterior, y corregir el campo de cabecera actual estimado, en base al campo de cabecera comprimida recibido en el 20 descompresor. En el que dicho calcular un efecto de fluctuación de retardo puede comprender las etapas de: calcular un efecto de fluctuación de retardo de la red antes del compresor, y calcular un efecto de fluctuación de retardo de la red entre el compresor y el descompresor. Además, dicho efecto de fluctuación de retardo de la red entre el compresor y el descompresor se puede establecer en un valor umbral superior para la fluctuación de retardo. Además, dicho calcular un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de 25 fluctuación de retardo de un paquete actual utilizando información con respecto a un paquete de referencia. Además, dicho calcular un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada uno de un número predeterminado de paquetes precedentes. En el que dicho calcular un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de fluctuación de retardo de un paquete actual 30 utilizando información con respecto a dicho paquete actual y a cada paquete precedente, hasta un paquete de referencia. Además, dicho calcular en el compresor el campo de cabecera comprimido del paquete actual puede comprender: calcular el campo de cabecera comprimido del paquete actual como los k bits menos significativos del valor del campo, donde k es un número entero. Además, dicho campo de cabecera puede comprender una marca de tiempo. Además, dicho campo de cabecera puede comprender un sello de tiempo RTP. Además, dicho calcular en el

35 compresor el campo de cabecera comprimido del paquete actual puede comprender convertir el valor del campo en otro valor, que se denomina valor empaquetado, que se puede representar con un menor número de bits, y calcular el campo de cabecera comprimido del paquete actual como los bits menos significativos k del valor empaquetado, donde k puede ser un número entero.

40 En aún otro aspecto adicional, se describe un procedimiento de descomprimir un campo de cabecera actual de un paquete de transmisión actual en una red desde un compresor a un descompresor el procedimiento puede comprender los pasos de: recibir un campo de cabecera comprimido de un paquete actual en el descompresor, donde dicho campo de cabecera comprimido se puede calcular en el compresor como una parte de un valor de campo que se puede calcular como un efecto de la fluctuación de retardo que tiene la red entre una fuente y el descompresor tiene sobre la

45 transmisión de paquetes; calcular una aproximación del campo de cabecera del flujo de paquetes en el descompresor en base al tiempo transcurrido desde la llegada de un campo de cabecera comprimido anterior en el descompresor y un valor de campo descomprimido del paquete anterior; calcular una cantidad de corrección de campo de cabecera para el paquete actual en el descompresor que podrían basarse en la cabecera comprimida campo del paquete actual, y descomprimir el campo de cabecera comprimido del paquete actual en el descompresor mediante el ajuste de la

50 aproximación del campo de cabecera del paquete actual una cantidad basada en la cantidad de corrección de campo de cabecera. Además, dicho efecto de fluctuación de retardo que podría tener la red entre el origen y el descompresor podría tener en la transmisión de paquetes podría calcularse mediante calcular un efecto de fluctuación de retardo de la red entre el compresor y calcular un efecto de fluctuación de retardo de la red entre el compresor y el descompresor. Además, dicho efecto de fluctuación de retardo de la red entre el compresor y el descompresor se puede establecer en

55 un valor umbral superior para la fluctuación de retardo. En el que dicho calcular un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a un paquete de referencia. Además, dicho calcular un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada uno de un número predeterminado de

60 paquetes precedentes. Dicho calcular un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y a cada paquete precedente, hasta un paquete de referencia. Además, el campo de cabecera comprimida puede ser calculado como el menor k bits significativos del valor del campo, donde k puede ser un número entero. Además, el campo de cabecera comprimido puede calcularse como los k bits menos significativos de un valor empaquetado, donde k puede ser un número entero, y en el que el descompresor puede calcular una aproximación del valor empaquetado en base al tiempo transcurrido desde la llegada de un paquete anterior y un valor empaquetado en

5 el descompresor del paquete previo.

En incluso otro aspecto más, se describe un procedimiento para realizar un traspaso entre primera y segunda entidades de red en un sistema, las primera y segunda entidades de red pueden interconectar un descompresor móvil a un terminal de fuente cuando el descompresor móvil se encuentra en las zonas primera y segunda, respectivamente, 10 el procedimiento puede comprender recibir un valor inicial de un campo de cabecera en la primera entidad de red y en el descompresor móvil desde un terminal de fuente, la primera entidad de red de interfaz entre el descompresor móvil, situada en una primera zona, a un terminal de fuente; recibir un campo de cabecera de un primer paquete que se dirige al descompresor móvil en la primera entidad de red desde el terminal de fuente; comprimir el campo de cabecera del primer paquete en la primera entidad de red y enviar un primer campo de cabecera comprimido del primer paquete al 15 descompresor móvil, dicho primer campo de cabecera comprimido se puede calcular como una parte de un valor de campo que puede calcularse como un primer efecto de fluctuación de retardo que podría tener la red entre el terminal fuente y el descompresor móvil en la transmisión de paquetes; recibir y descomprimir el primer campo de cabecera comprimido del primer paquete en el descompresor móvil basándose en el tiempo transcurrido desde la llegada de un paquete anterior y el valor de campo descomprimido del paquete anterior; el descompresor móvil puede pasar de la 20 primera zona a la segunda zona; transmitir la información de inicialización a la segunda entidad de red para inicializar la segunda entidad de red para la recepción y compresión, en la segunda entidad de red, de un campo de cabecera de un segundo paquete de la terminal de origen que podrán utilizar para el descompresor móvil y enviar un segundo campo de cabecera comprimida del segundo paquete al descompresor móvil, dicho segundo campo de cabecera comprimido puede calcularse como una parte de un valor de campo que se calcula como un segundo efecto de la fluctuación de 25 retardo que podría tener la red entre el terminal fuente y el descompresor móvil en la transmisión de paquetes y el tiempo para transmitir la información de inicialización a la segunda entidad de red, y recibir y descomprimir el segundo campo de cabecera comprimido del segundo paquete en el descompresor móvil basándose en el tiempo transcurrido desde la llegada de un paquete anterior y el valor de campo descomprimido del paquete anterior. Además, cada uno de dichos primero y segundo efecto de fluctuación de retardo de la red entre el terminal fuente y el descompresor podría 30 tener en la transmisión de paquetes podría ser calculada mediante calcular un efecto de fluctuación de retardo de la red antes del compresor, y calcular un efecto de fluctuación de retardo de la red entre el compresor y el descompresor. Además, dicho efecto de fluctuación de retardo de la red entre el compresor y el descompresor se puede establecer en un valor umbral superior para la fluctuación de retardo. Además, dicho primer paquete puede ser un paquete inmediatamente anterior al traspaso y dicho segundo paquete puede ser un paquete inmediatamente posterior al 35 traspaso. Además, dicho calcular un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a un paquete de referencia. Además, dicho calcular un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada uno de un número predeterminado de paquetes precedentes. Además, dicho calcular un 40 efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y a cada paquete precedente, hasta un paquete de referencia. Además, dicho campo de cabecera cuenta con un sello de tiempo. También, el campo de cabecera comprimido puede calcularse como los k bits menos significativos del valor del campo, donde k puede ser un número entero. Además, el campo de cabecera comprimido puede calcularse como los k bits menos significativos

45 de un valor empaquetado, donde k puede ser un número entero, y en el que el descompresor puede calcular una aproximación del valor empaquetado en base al tiempo transcurrido desde la llegada de un paquete anterior y un valor empaquetado del descompresor del paquete previo.

En otro aspecto adicional se describe un procedimiento para realizar un traspaso entre primera y segunda entidades de

50 red, las primera y segunda entidades de red pueden interconectar un compresor móvil a un terminal receptor cuando el compresor móvil se encuentra en las zonas primera y segunda, respectivamente, el procedimiento puede comprender recibir un valor inicial de un campo de cabecera en una primera entidad de red desde un compresor móvil; recibir en la primera entidad de red un primer campo de cabecera comprimido de un primer paquete recibido desde el compresor móvil, dicho primer campo de cabecera comprimido puede haber sido calculo en el compresor móvil como una parte de

55 un valor de campo que se calcula como un primer efecto de la fluctuación de retardo que podría tener la red entre una fuente y un descompresor en la transmisión de paquetes; descomprimir, en la primera entidad de red, el primer campo de cabecera comprimida de la primer paquete en base al tiempo transcurrido desde la llegada de un paquete anterior y el valor de campo descomprimido del paquete anterior; el compresor móvil puede pasar de la primera zona a la segunda zona, enviar información de inicialización a la segunda entidad de red para inicializar la segunda entidad de

60 red para la compresión; recibir, en la segunda entidad de red, un segundo campo de cabecera comprimido de un segundo paquete recibido desde el compresor móvil, dicho segundo campo de cabecera comprimido puede haber sido calculado en el compresor móvil como una parte de un valor de campo que se calcula como un segundo efecto de la

fluctuación de retardo que podría tener la red entre el origen y el descompresor en la transmisión de paquetes y el tiempo para transmitir la información de inicialización a la segunda entidad de red, y descomprimir, en la segunda entidad de red, el segundo campo de cabecera comprimido del segundo paquete en base al tiempo transcurrido desde la llegada de un paquete anterior y valor de campo descomprimido del paquete anterior. Además, dicho primer y 5 segundo efecto de la fluctuación de retardo de la red entre el origen y el descompresor puede tener en la transmisión de paquetes puede calcularse mediante calcular un efecto de fluctuación de retardo de la red antes del compresor móvil, y calcular un efecto de fluctuación de retardo de la red entre el compresor y descompresor. Además, dicho efecto de fluctuación de retardo de la red entre el compresor y el descompresor se puede establecer en un valor umbral superior para la fluctuación de retardo. Además, dicho primer paquete puede ser un paquete inmediatamente anterior 10 al traspaso y dicho segundo paquete puede ser un paquete inmediatamente posterior al traspaso. Además, dicho calcular un efecto de fluctuación de retardo de la red antes del compresor móvil puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a un paquete de referencia. Además, dicho calcular un efecto de fluctuación de retardo de la red antes del compresor móvil puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada 15 uno de un número predeterminado de paquetes precedentes. Además, dicho calcular un efecto de fluctuación de retardo de la red antes del compresor móvil puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y a cada paquete precedente, hasta un paquete de referencia. Además, dicho campo de cabecera puede comprender una marca de tiempo. Además, el campo de cabecera comprimido puede calcularse como los k bits menos significativos de un valor empaquetado,

20 donde k puede ser un número entero, y en el que el descompresor puede calcular una aproximación del valor empaquetado en base al tiempo transcurrido desde la llegada de un paquete anterior y un descompresor valor del paquete anterior lleno. También, el campo de cabecera comprimido puede calcularse como los k bits menos significativos del valor del campo, donde k puede ser un número entero.

25 En otro aspecto adicional, se describe un sistema de comunicación, donde el sistema puede comprender una fuente de proporcionar una pluralidad de paquetes, cada paquete puede incluir un campo de cabecera, la fuente puede estar acoplada a una red; un receptor que puede incluir un descompresor; una entidad de red que puede estar acoplada a la red y al receptor por una red entre la entidad de red y el receptor, la entidad de red puede incluir un compresor para realizar la compresión del campo de cabecera para al menos algunos de los paquetes enviados desde la fuente y

30 dirigidos al receptor, la entidad de red puede incluir una función de reducción de fluctuación de retardo para calcular la fluctuación de retardo en los paquetes dirigidos al terminal receptor y el descarte de paquetes que pueden tener una fluctuación de retardo que es mayor que un valor predeterminado, en donde la fluctuación de retardo se puede calcular como un total de una cantidad de la fluctuación de retardo causada por la red entre el origen y el descompresor que podría incluirse en el receptor. Además, dicha fluctuación de retardo puede ser calculada mediante calcular un efecto

35 de fluctuación de retardo de la red antes del compresor, y calcular un efecto de fluctuación de retardo de la red entre el compresor y el descompresor. Además, dicho efecto de fluctuación de retardo de la red entre el compresor y el descompresor se puede establecer en un valor umbral superior para la fluctuación de retardo. Además, dicha fluctuación de retardo de la red antes del compresor puede calcularse mediante calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a un paquete de referencia. Además, dicho calcular

40 un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada uno de un número predeterminado de paquetes precedentes. Además, dicho calcular un efecto de fluctuación de retardo de la red antes del compresor puede comprender calcular un efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada uno de los paquetes anteriores de hasta un paquete de

45 referencia. También, el campo de cabecera comprimido puede calcularse como los k bits menos significativos de un valor lleno, donde k puede ser un número entero, y en el que el descompresor puede calcular una aproximación del valor empaquetado en base al tiempo transcurrido desde la llegada de un paquete anterior y un valor empaquetado del descompresor del paquete previo.

Claims (9)

1. REIVINDICACIONES

   1. Un procedimiento de comunicación que comprende:

   5 proporcionar a una fuente (102) una pluralidad de paquetes, incluyendo cada paquete un campo de cabecera, estando la fuente acoplada a una red;

   llevar a cabo por un compresor incluido en una entidad de red que está acoplada a la red y a un receptor (130) la compresión del campo de cabecera para al menos algunos de los paquetes enviados desde la fuente (102) y 10 dirigidos al receptor (130) que incluye una descompresor (137); y

   calcular la fluctuación de retardo en la entidad de red en los paquetes dirigidos al receptor (130) estando dicho procedimiento además caracterizado por: descartar paquetes que tienen una fluctuación que es mayor que un valor predeterminado, en donde la fluctuación de retardo se calcula como un total de una cantidad de 15 fluctuación de retardo causada por la red entre la fuente (102) y el descompresor (137) incluido en el receptor

   (130) .
2. 2. El procedimiento según la reivindicación 1, en el que dicha fluctuación de retardo se calcula mediante el cálculo

   de un efecto de fluctuación de retardo de la red antes del compresor, y calcular un efecto de fluctuación de 20 retardo de la red entre el compresor y el descompresor (137).
3. 3. El procedimiento según la reivindicación 1, en el que dicho efecto de fluctuación de retardo de la red entre el compresor y el descompresor (137) se establece en un valor umbral superior para la fluctuación de retardo.

   25 4. El procedimiento según la reivindicación 2, en el que dicha fluctuación de retardo de la red antes del compresor se calcula mediante el cálculo del efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a un paquete de referencia.
4. 5. El procedimiento según la reivindicación 2, en el que dicho calcular un efecto de fluctuación de retardo de la red

   30 antes del compresor comprende: calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada uno de un número predeterminado de paquetes precedentes.
5. 6. El procedimiento según la reivindicación 2, en el que dicho calcular un efecto de fluctuación de retardo de la red

   35 antes del compresor comprende: calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada paquete anterior hasta un paquete de referencia.
6. 7. El procedimiento según la reivindicación 1, en el que el campo de cabecera comprimido se calcula como los k

   40 bits menos significativos de un valor empaquetado, donde k es un número entero, y en el que una aproximación del valor empaquetado en base al tiempo transcurrido desde la llegada de un paquete anterior y un valor empaquetado del paquete anterior se calcula en el descompresor (137).
7. 8. Un sistema de comunicación que comprende:

   45 una fuente (102) que proporciona una pluralidad de paquetes, incluyendo cada paquete un campo de cabecera, estando la fuente acoplada a una red;

   un receptor (130) que incluye un descompresor (137);

   50 una entidad de red acoplada a la red y al receptor (130) por una red entre la entidad de red y el receptor (130), incluyendo la entidad de red un compresor para llevar a cabo la compresión del campo de cabecera para al menos algunos de los paquetes enviados desde la fuente (102) y dirigidos al receptor (130), incluyendo la entidad de red una función de reducción de fluctuación de retardo (115) para calcular la fluctuación de retardo

   55 en los paquetes dirigidos al receptor (130) estando dicho sistema caracterizado por medios para descartar paquetes que tienen una fluctuación que es mayor que un valor predeterminado, en donde la fluctuación de retardo se calcula como un total de una cantidad de fluctuación de retardo causada por la red entre la fuente

   (102) y el descompresor (137) incluido en el receptor (130).

   60 9. El sistema de comunicación según la reivindicación 8, en el que dicha fluctuación de retardo se calcula mediante el cálculo de un efecto de fluctuación de retardo de la red antes del compresor, y calcular un efecto de fluctuación de retardo de la red entre el compresor y el descompresor (137).
8. 10. El sistema de comunicación según la reivindicación 8, en el que dicho efecto de fluctuación de retardo de la red entre el compresor y el descompresor (137) se establece en un valor umbral superior para la fluctuación de retardo.
9. 11. El sistema de comunicación según la reivindicación 9, en el que dicha fluctuación de retardo de la red antes del compresor se calcula mediante el cálculo del efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a un paquete de referencia.

   10 12. El sistema de comunicación según la reivindicación 9, en el que dicho calcular un efecto de fluctuación de retardo de la red antes del compresor comprende: calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada uno de un número predeterminado de paquetes precedentes.

   15 13. El sistema de comunicación según la reivindicación 9, en el que dicho calcular un efecto de fluctuación de retardo de la red antes del compresor comprende: calcular el efecto de fluctuación de retardo de un paquete actual utilizando información con respecto a dicho paquete actual y cada paquete anterior hasta un paquete de referencia.

   20 14. El sistema de comunicación según la reivindicación 8, en el que el campo de cabecera comprimido se calcula como los k bits menos significativos de un valor empaquetado, donde k es un número entero; y en el que el descompresor (137) calcula una aproximación del valor empaquetado en base al tiempo transcurrido desde la llegada de un paquete anterior y un valor empaquetado del paquete anterior.

   25 15. Un producto de programa informático, que comprende: un medio legible por ordenador que comprende: código para hacer que cuando se ejecuta al menos un ordenador lleve a cabo un procedimiento de acuerdo con una de las reivindicaciones 1 a 7.

   FIG. 2

   FORMATO DE PAQUETES DEL RTP

   CABECERA IP

   CABECERA UDP CABECERA RTP CARGA ÚTIL

   210

   212 214 216

   (p. ej., MUESTRA DE VOZ)

   FIG. 3

   FORMATO NO COMPRIMIDO DE CABECERA DE RTP

   SELLO TEMPORAL (TS)

   NÚMERO DE SECUENCIA (SN) OTROS CAMPOS

   310

   312 314

   FIG. 4

   FORMATO COMPRIMIDO DE CABECERA DE RTP

   TIPO DE

   MÁSCARA DE BITS SELLO TEMPORAL COMPRIMIDO Campos optativos

   MENSAJE 410

   412 414 416

   ���������������

   �����������������������������������������������

   PILA REGENERADORA DE CABECERA 830

   FIG. 9

   INFORMACIÓN

   CONTENIDO TAMAÑO

   Info_inic(n)

   CABECERA DE IP/UDP/RTP COMPLETA; n ESTÁ IMPLÍCITAMENTE ESPECIFICADO EN SN DEL RTP ALREDEDOR DE 40 OCTETOS=320 BITS AL MENOS; ENVIADOS POR INTERFAZ AÉREA

   Inic_cadena(n)

   C_SN, C_TS (SI LA TEMPORIZACIÓN NO SE MANTIENE DESDE UNA CADENA A LA PRÓXIMA), p_tamaño (IMPROBABLE), TS_tranco (IMPROBABLE); n ESTÁ IMPLÍCI-TAMENTE ESPECIFICADO EN C_SN ALREDEDOR DE 8 BITS SI SÓLO SE TRATA DE C_SN, 12 BITS SI SE TRATA DE C_SN Y C_TS

   HO_inic_u(n)

   CABECERA IP/UDP/RTP COMPLETA, PERO TS DEL RTP REEMPLAZADO POR TSO_u, m_último_u, TS_tranco_u, Temporizador_u de TS, p_tamaño_u; n ESTÁ IMPLÍCITAMENTE ESPECIFICADO EN SN DEL RTP LIGERAMENTE MAYOR QUE LA CABECERA COMPLETA; LLEVADO EN RED DE LÍNEA POR CABLE, ENTRE ANI_AD

   HO_inic_d(n)

   P_tamaño_d, y TS_tranco_d, JUNTO CON SU NÚMERO DE GENERACIÓN EL TAMAÑO DEPENDE DE LA CODIFICACIÓN DE p_tamaño Y TS_tranco; LLEVADO POR RED DE LÍNEA DE CABLE, ENTRE ANI_AD

   HO_sinc_u(n)

   C_SN, C_TS (PROBABLE), p_tamaño_u, TS_tranco_u; n ESTÁ IMPLÍCITAMENTE ESPECIFICADO EN C_SN ALREDEDOR DE 8 BITS SI SÓLO SE TRATA DE C_SN, 12 BITS SI SE TRATA DE C_SN Y C_TS

   HO_sinc_d(n)

   C_SN, C_TS (PROBABLE), p_tamaño_d, TS_tranco_d; n ESTÁ IMPLÍCITAMENTE ESPECIFICADO EN C_SN ALREDEDOR DE 8 BITS SI SÓLO SE TRATA DE C_SN, 12 BITS SI SE TRATA DE C_SN Y C_TS

   Ack (n)

   UNOS POCOS BITS

   FIG. 15

   CALCULAR FLUCTUACIÓN DE RETARDO DE PAQUETE 5 CON RESPECTO A 1: j(5,1) = 2 = N_FLUCTUACIÓN DE RETARDO (5,1)

   CALCULAR FLUCTUACIÓN DE RETARDO DE PAQUETE 5 CON RESPECTO A 2: j(5,2) = 3 = N_FLUCTUACIÓN DE RETARDO (5,2)

   CALCULAR FLUCTUACIÓN DE RETARDO DE PAQUETE 5 CON RESPECTO A 3: j(5,3) = 4 = N_FLUCTUACIÓN DE RETARDO (5,3)

   CALCULAR FLUCTUACIÓN DE RETARDO DE PAQUETE 5 CON RESPECTO A 4: j(5,4) = 7 = N_FLUCTUACIÓN DE RETARDO (5,4)

   MÁX FLUCTUACIÓN DE RETARDO DE RED = 7 PARA EL PAQUETE 5