ES2399020T3

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

Info

Publication number: ES2399020T3
Application number: ES10150230T
Authority: ES
Inventors: Khiem Le
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2000-03-09
Filing date: 2001-03-09
Publication date: 2013-03-25
Anticipated expiration: 2021-03-09
Also published as: AU2001243533B2; BR0109097A; US6680955B1; WO2001067709A3; RU2278478C2; EP2169906B1; DE60141453D1; KR100502313B1; WO2001067709A2; JP2008035543A; CN1617540B; EP2169907A2; DK2169906T3; EP1262052B1; CN1617540A; CN1185844C; JP4612028B2; EP2169996A3; EP2490398B1; ATE543320T1

Abstract

Un procedimiento para descomprimir un sello de tiempo comprimido (414) en un campo cabecera de un paquete actual transmitido en una red desde un compresor a un descompresor (137) que comprende las etapas de: recibir un sello de tiempo comprimido (414) en un campo cabecera de un paquete actual en el descompresor (137), dicho sello de tiempo comprimido (414) habiendo sido calculado en el compresor como una parte de un valor de sello de tiempo que se calcula como un efecto a causa de fluctuación de tiempo que tiene la red entre una fuente (102) y el descompresor (137) en la transmisión de paquetes; calcular una aproximación del valor de sello de tiempo en el campo cabecera del paquete actual en el descompresor (137) en base al tiempo pasado desde la llegada de un campo cabecera previo al descompresor (137) y un valor de sello de tiempo del paquete previo; calcular una magnitud de valor de corrección de sello de tiempo para el paquete actual en el descompresor (137) en base al sello de tiempo comprimido (414) del paquete actual; y descomprimir el sello de tiempo comprimido (414) del paquete actual en el descompresor (137) ajustando la aproximación calculada del valor de sello de tiempo en el campo cabecera del paquete actual en un cantidad 15 en base a la magnitud de valor de corrección de sello de tiempo.

Description

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

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.

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 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. 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 o 4 octetos por enlaces punto a punto. Los algoritmos existentes de 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.

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 de tiempo 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 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. Tal algoritmo de compresión se describe, por ejemplo, en la referencia “Evaluation of the Casner-Jacobson Algorithm for Compressing the RTP/UDP/IP Headers”, G. Mamais.

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 de tiempo del RTP tiene, la mayor parte del tiempo, un patrón linealmente creciente. Cuando la cabecera es conforme al patrón, 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 de tiempo del 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.

La compresión de cabeceras también se describe en S. Casner et al “Compressing IP/UDP/RTP Headers for Low-Seed Serial Links”, Internet Engineering Task Force, July 27, 1998. La compresión de datos de imagen se describe en EP 0

852 446 A2.

Sin embargo todavía existe una necesidad de un esquema de compresión de cabeceras que pueda acomodar un salto arbitrario en el valor del campo (por ejemplo, en el valor del sello de tiempo RTP), alcance un tamaño constante o más consistente y es más robusto respecto a errores.

RESUMEN DE LA INVENCIÓN

Esta necesidad se ve satisfecha por el contenido de las reivindicaciones adjuntas.

Según un ejemplo 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 de tiempo del RTP. El sello de tiempo se envía por una red a un compresor. En el compresor, se utiliza una función de reducción de fluctuación de tiempo (JRF) para determinar si la fluctuación de tiempo del sello de tiempo (cabecera) recibido es excesivo. Si la fluctuación de tiempo es excesiva, se descarta el paquete. En caso contrario, el compresor calcula un campo de cabecera comprimida (sello de tiempo comprimido) sobre la base del sello de tiempo del RTP y un valor inicial del sello de tiempo. El sello de tiempo comprimido representa la fluctuación de tiempo 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 tiempo calculada es una acumulación de fluctuación de tiempo 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 tiempo 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 una red de telecomunicaciones inalámbricas. El paquete del RTP, incluyendo el sello de tiempo comprimido, se transmite entonces por un enlace o red a un descompresor.

El descompresor descomprime el sello de tiempo comprimido calculando primero una estimación o aproximación del sello de tiempo, sobre la base del valor actual de un temporizador situado en el terminal (es decir, sobre la base del tiempo transcurrido). La aproximación del sello de tiempo se refina o corrige luego sobre la base del sello de tiempo comprimido proporcionado en la cabecera del paquete. De esta manera, el sello de tiempo para el paquete (cabecera) actual se regenera sobre la base de un temporizador local y un sello de tiempo comprimido proporcionado en la cabecera actual. El paquete y el sello de tiempo regenerado se proporcionan luego a un punto extremo del RTP para su procesamiento.

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 de tiempo comprimido, y el esquema basado en temporizador y referencia, según se revela en el presente documento. El tamaño del sello de tiempo 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 proceso temporizador en el origen del RTP (que genera el sello de tiempo) 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 de tiempo 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 de tiempo del RTP. La pérdida o corrupción de una cabecera no invalidará las cabeceras comprimidas subsiguientes.

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 de tiempo 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 inicialización, el desmenuzador de cabecera desmenuza o retira la cabecera (incluyendo la retirada del sello de tiempo 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 tiempo de paquetes en el desmenuzador de cabeceras, los paquetes pueden transmitirse con un espaciado temporal según el sello de tiempo (TS) del RTP en la cabecera. Por lo tanto, en este ejemplo, el sello de tiempo no se proporciona explícitamente en el paquete del RTP (ni siquiera un sello de tiempo comprimido). En cambio, la información de temporización se proporciona implícitamente al regenerador de cabeceras, sobre la base de 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 este segundo ejemplo, después de que ocurre la inicialización (p. ej., proporcionando el número de secuencia inicial y el sello de tiempo al regenerador de cabeceras), el regenerador de cabeceras puede regenerar los sellos temporales para paquetes secuenciales, incrementando un contador de sello de tiempo 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 sobre la base de 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 cabeceras, en el cual no se introduce ninguna fluctuación de tiempo 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 en TS_tranco, un desplazamiento no lineal en el sello de tiempo, 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 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

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 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;

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 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;

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 ejemplo de la invención;

La Fig. 13 es un diagrama que ilustra las etapas del cálculo de la fluctuación de tiempo de red según un primer procedimiento de la presente invención;

La Fig. 14 es un diagrama que ilustra las etapas del cálculo de la fluctuación de tiempo de red según un segundo procedimiento expuesto como la Opción 1 de la presente invención; y

La Fig. 15 es un diagrama que ilustra las etapas del cálculo de la fluctuación de tiempo 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

I. Esquema Basado en Temporizador que Emplea un Sello de tiempo 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 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 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 de tiempo.

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 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 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 de tiempo) para los paquetes del RTP recibidos desde la red IP 108 son comprimidas por el ANI_AD 112 antes de la transmisión al 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 función de reducción de fluctuación de tiempo (JRF) 115 que funciona para medir la fluctuación de tiempo en los paquetes (o cabeceras) recibidos por la red 108 y para descartar todos los paquetes / cabeceras que tengan fluctuación de tiempo excesiva.

Pueden proporcionarse ANI adicionales, tales como la ANI 120, para mantener interfaces entre los otros terminales 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 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 calcular una aproximación (o estimación) de un sello de tiempo 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 de tiempo. Según un ejemplo de la invención, la aproximación del sello de tiempo se corrige o se ajusta sobre la base de un sello de tiempo comprimido proporcionado en la cabecera del RTP. De esta manera, un temporizador local y un sello de tiempo comprimido pueden utilizarse para regenerar el sello de tiempo correcto para 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

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, 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. 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.

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 de tiempo (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 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 de tiempo (TS) 310 para indicar la temporización relativa de cada paquete.

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 de tiempo 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 de tiempo en la cabecera del RTP.

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 de tiempo cambiarán entre paquete y paquete. Según el documento RFC 2508, los campos no estáticos (p. ej., el sello de tiempo 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 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 de tiempo del RTP (u otro campo) de una cabecera de paquete. Según un ejemplo de la presente invención, el esquema de compresión puede asimilar un salto arbitrario en el valor del sello de tiempo del RTP, brindando a la vez una cabecera comprimida del RTP de tamaño constante (o un sello de tiempo 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 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 de tiempo comprimido. El tipo 410 de mensaje puede indicar un sello de tiempo comprimido si se proporciona un sello de tiempo comprimido en la cabecera del paquete. Según un ejemplo de la presente invención, el campo 414 del sello de tiempo comprimido incluye los k bits menos significativos (lsbs) de un valor que puede indicar el tiempo transcurrido entre los paquetes. Según un ejemplo de la invención, el sello de tiempo comprimido 414 puede proporcionar una porción (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 de tiempo 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 de tiempo del RTP, según un ejemplo 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 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 de tiempo, que se genera en el origen del RTP (p. ej., en el terminal 102) sobre la base de un reloj común.

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 de tiempo 310 del RTP (Fig. 3) en un sello de tiempo 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 de tiempo comprimido 414, se transmite luego por el enlace descendente 144 del enlace 140 de RF al terminal 130.

Al recibir el paquete del RTP con cabecera comprimida (es decir, el sello de tiempo comprimido 414), el adaptador del terminal (term_AD) 136 del terminal 130 descomprime el valor del sello de tiempo. El adaptador 136 del terminal descomprime el sello de tiempo comprimido 414 calculando primero una estimación o aproximación del sello de tiempo sobre la base del valor actual del temporizador 134. La aproximación del sello de tiempo se refina o corrige luego sobre la base del sello de tiempo comprimido 414 proporcionado en la cabecera del paquete. De esta manera, el sello de tiempo para el paquete actual (cabecera) se regenera sobre la base de un temporizador local (temporizador 134) y un sello de tiempo 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 de tiempo 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 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 de tiempo comprimido) por el enlace 140 de RF, y descomprimir el sello de tiempo 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 de tiempo comprimido, según lo anteriormente descrito. De manera similar, el term_AD 136 del terminal 130 también puede comprimir el sello de tiempo 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 como un compresor (para la transmisión de la cabecera / el paquete por el enlace de RF) y descompresor (después de la recepción de 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

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 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).

TS: sello de tiempo

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

TS0: sello de tiempo 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 de tiempo del RTP, proporcionado tanto al compresor (p. ej., el ANI_AD 112) como al 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 de tiempo no comprimido que proporciona el TS0). Según un ejemplo de la presente invención, la técnica de descompresión basada en temporizador requiere proporcionar un sello de tiempo 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 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 de tiempo).

El sello de tiempo del RTP de la cabecera m de paquete (generada en el momento m*T mseg) = TS0 + TS_tranco*m. 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 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 de tiempo actual para la cabecera del paquete actual.

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 la recepción de 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 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 de tiempo 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 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 de tiempo 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 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 de tiempo).

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 de tiempo del paquete actual, el ANI_AD 112 calcula el valor actual de m como: m_actual = (TS_actual – TS0) / TS_tranco. Por lo tanto, el ANI_AD resta el valor inicial del sello de tiempo (al comienzo de la sesión) al sello de tiempo actual. Esta diferencia se divide entre el tranco del sello de tiempo (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.

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

En el receptor del RTP (p. ej., el terminal 130), el adaptador del terminal (Term_AD) 136 descomprime el sello de tiempo 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 el número entero d, donde

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

los k bits menos significativos de (d + m_último + dif_temporizador) = sello de tiempo comprimido 414 (para la cabecera actual).

(Ec. 2)

Como se ha indicado, el sello de tiempo comprimido recibido también tiene k bits. Una vez que d ha sido calculado 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).

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 de tiempo actual, y d*TS_tranco es la diferencia entre el sello de tiempo actual aproximado y el valor efectivo (o correcto) del sello de tiempo actual.

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

Después de que TS_actual está calculado, el paquete actual del RTP (incluyendo su sello de tiempo 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 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 de tiempo, mientras que el temporizador (p. ej., el temporizador 134) en el receptor de RTP se utiliza para regenerar o descomprimir el sello de tiempo 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 de tiempo (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 de tiempo en la cabecera de inicialización no se comprime. Al recibir la cabecera de inicialización, el valor inicial del sello de tiempo (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 de tiempo – el primer sello de tiempo. El term_AD puede calcular de manera similar TS_tranco o recibir el valor en un paquete.

De manera similar, cuando la cabecera 508 de inicialización se recibe en el receptor del RTP (terminal 130), el sello de tiempo 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 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 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 tiempo 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 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 de tiempo 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 de tiempo 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.

El valor del sello de tiempo para este paquete, TS(1), se recibe en el ANI_AD y se comprime sobre la base de TS(1) (el valor del sello de tiempo), TS0 (el valor inicial del sello de tiempo) y TS_tranco (la cantidad en que se incrementa el sello de tiempo cada T mseg). Según una realización a modo de ejemplo, el sello de tiempo 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 = (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 de tiempo comprimido 414 para este paquete (CTS1), Fig. 5.

El sello de tiempo comprimido (CTS1) llega al receptor 502 del RTP y el term_AD 136 en el receptor del RTP regenera

o descomprime el sello de tiempo, 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 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 de tiempo 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 de tiempo 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 de tiempo 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 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 de tiempo se genera en el origen del RTP, incluyendo un sello de tiempo TS (2) = 0 + 6 * 100 = 600. En el ANI_AD, el valor TS(2) = 600 se comprime en un sello de tiempo 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 de tiempo comprimido para este paquete (CTS2) se recibe luego en el term_AD 136 después de que el temporizador del receptor alcanza el valor de 7, debido al retardo íntegro y a la fluctuación de tiempo 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.

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 de tiempo 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) =

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 de tiempo 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 de tiempo del RTP sobre la base de un temporizador local y un sello de tiempo comprimido.

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 de tiempo 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 ú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 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 tiempo acumulada entre la misma fuente de los sellos temporales del RTP y el receptor; el retardo efectivo = retardo íntegro + fluctuación de tiempo acumulada, donde el retardo íntegro es constante y la fluctuación de tiempo acumulativa varía entre una cabecera y la siguiente, y 0 < fluctuación de tiempo acumulativa < máxima fluctuación de tiempo 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 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 tiempo y la asincronía del temporizador. En la Fig. 5, el temporizador del receptor se reinicia o borra sólo al comienzo 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 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 de tiempo exitosamente descomprimido y el sello de tiempo 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 de tiempo = TS0 + 3 + TS_tranco. Este sello de tiempo 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 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 de tiempo TS = TS0 + 6*TS_tranco. Este sello de tiempo 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 de tiempo para la cabecera (m+n). Por lo tanto, el ejemplo de la Fig. 6 es muy similar al ejemplo 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 tiempo acumulada es excesiva, puede no ser posible regenerar un sello de tiempo correcto sobre la base del sello de tiempo comprimido. En muchos casos, la siguiente 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 tiempo integral máxima + 2) < 2k,

donde la Fluctuación de tiempo integral máxima (MIJ) es la máxima fluctuación de tiempo acumulativa, expresada en unidades de T mseg, redondeada al siguiente número entero mayor. Por ejemplo, si T = 20 mseg, una fluctuación de tiempo 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.

Debido a los requisitos conversacionales de tiempo real, la fluctuación de tiempo 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 tiempo exceda los valores normales. Una entidad de reducción de fluctuación de tiempo puede añadirse flujo arriba del compresor para garantizar que la fluctuación de tiempo, según la ve el compresor, permanezca dentro de cotas aceptables.

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

a) El tamaño del sello de tiempo 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 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 de tiempo 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 de tiempo).

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é 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 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 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 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.

Para efectuar el traspaso, el viejo ANI_AD debe transferir el valor inicial del sello de tiempo 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 de tiempo de RTP. El term_AD puede descomprimir TS_actual mientras se satisfaga la siguiente condición:

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

donde la Fluctuación de tiempo Integral Transitoria del Enlace Descendente (DTIJ) es la fluctuación de tiempo transitoria del enlace descendente de la Cabecera_actual, expresada en unidades de T mseg, redondeada al próximo número entero mayor. La fluctuación de tiempo 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 tiempo acumulativa para la Cabecera_actual en la nueva trayectoria. Por lo tanto, la fluctuación de tiempo transitoria del enlace descendente = retardo íntegro en la nueva trayectoria – retardo íntegro en la vieja trayectoria + fluctuación de tiempo 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 tiempo transitoria del enlace descendente en la misma gama de valores que la fluctuación de tiempo acumulativa en el estado estable (es decir, sin traspaso). Por lo tanto, sobre la base de 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

En esta descripción del enlace ascendente, el term_AD 136 del terminal (p. ej., el terminal 130) comprime el sello de tiempo 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 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 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 ANI_AD después del traspaso, y sea TS_actual su sello de tiempo de RTP. El nuevo ANI_AD puede descomprimir TS_actual mientras se satisfaga la siguiente condición:

[Condición 3] (Fluctuación de tiempo integral transitoria del enlace ascendente + 2 + 1) < 2k, donde la Fluctuación de tiempo Integral Transitoria del Enlace Ascendente (UTIJ) es la fluctuación de tiempo transitoria del enlace ascendente expresada en unidades de T mseg, redondeada al siguiente número entero mayor. La fluctuación de tiempo 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 tiempo acumulativa para la Cabecera_actual, la fluctuación de tiempo transitoria del enlace ascendente = retardo íntegro en la nueva trayectoria – retardo íntegro en la vieja trayectoria + fluctuación de tiempo acumulativa para la Cabecera_actual + T_transfer. En comparación con el caso del enlace descendente, se suma 1 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 tiempo 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, 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 tiempo 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 de tiempo del RTP puede descomprimirse correctamente.

Según un ejemplo, 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 de tiempo completo (no comprimido) hasta que se reciba un acuse de recibo.

E. Reducción de Fluctuación de tiempo

Según un ejemplo de la presente invención, el esquema de compresión basada en temporizador que utiliza un sello de tiempo comprimido y un temporizador de receptor local puede aseverarse si se satisfacen las siguientes condiciones.

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

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

Debido a los requisitos conversacionales en tiempo real, puede esperarse razonablemente que las diversas 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 de tiempo correcto no puede generarse sobre la base del sello de tiempo comprimido y el temporizador del receptor local). Para tratar estos casos, puede proporcionarse una función de reducción de fluctuación de tiempo (JRF) 115 (Fig. 1) como una interfaz de primer orden para el compresor, para filtrar (o descartar) los paquetes con fluctuación de tiempo excesiva (p. ej., donde no se satisfaga cualquiera de las condiciones anteriores 1, 2, o 3).

Para filtrar o identificar paquetes con MIJ excesiva, la función de reducción de fluctuación de tiempo (JRF) calcula la fluctuación de tiempo de cada paquete recibido por la red 108. Si la fluctuación de tiempo medida del paquete es mayor que 2k – 2, esto se considera fluctuación de tiempo 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).

La JRF calcula la fluctuación de tiempo del paquete actual de la siguiente manera: fluctuación de tiempo = valor absoluto de (TS2 – TS1 – dif_temporizador de JRF), donde TS2 es el sello de tiempo del paquete actual, TS1 es el sello de tiempo 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 tiempo se compara con 2k – 2. Si la fluctuación de tiempo es mayor que 2k - 2, el paquete se descarta. En caso contrario, la cabecera del paquete se 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 tiempo (JRF) 115 es una técnica efectiva para limitar la fluctuación de tiempo en los paquetes recibidos por el terminal receptor (porque la fluctuación de tiempo introducida por el enlace de RF puede considerarse despreciable). Además, la JRF funciona para utilizar más eficientemente el ancho de banda disponible por el enlace 140 de RF. En ausencia de la JRF 115, uno o más paquetes, con una fluctuación de tiempo mayor que 2k - 2, podrían transmitirse al receptor por el enlace 140. Sin embargo, en el receptor, si la fluctuación de tiempo es excesiva (es decir, la condición 1 no se satisface), no puede generarse el valor correcto del sello de tiempo, lo que causa que el receptor descarte el paquete. Así, la JRF funciona meramente para filtrar aquellos paquetes con fluctuación de tiempo excesiva, que serían descartados en el receptor en todo caso (evitando el desperdicio de valioso ancho de banda por el enlace 140).

II. Esquema de Desmenuzamiento de Cabecera

Un segundo ejemplo 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 de tiempo 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 enlace 140 de RF, Fig. 1). En tal caso, el sello de tiempo 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

15 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 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 de tiempo (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 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 tiempo de paquete), para permitir que el sello de tiempo del RTP se regenere sólo sobre la base de un temporizador o contador local. Esto elimina la necesidad de enviar el sello de tiempo

25 explícitamente (o incluso de enviar un sello de tiempo 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 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 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.

35 c) Posibilidad de conmutar durante una llamada a la compresión de cabecera (p. ej., la técnica de las Figs. 16), 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 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

45 desmenuzadora 802 de cabecera podría proporcionarse, por ejemplo, dentro de un tipo de adaptador de ANI (p. ej., el 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 de tiempo en la cabecera 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 que regenera la cabecera (incluyendo el sello de tiempo 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 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.

En funcionamiento, el desmenuzador (HS) 810 de cabecera elimina la fluctuación de tiempo en los paquetes entrantes del RTP, y los reproduce según el sello de tiempo (TS) del RTP en la cabecera. Aquí, la eliminación de la fluctuación de tiempo 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 de tiempo. En otras palabras, los paquetes, después de la retirada o el 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 de tiempo en el paquete. Los paquetes con fluctuación de tiempo excesiva se descartan, utilizando la función de reducción de fluctuación de tiempo (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:

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 de tiempo (TS) del RTP. También se preserva el número (SN) de secuencia del RTP. Los campos 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 de tiempo y el número de secuencia se expondrán brevemente.

1. Sello de tiempo (TS) del RTP

En el caso de la voz, el sello de tiempo (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 de tiempo de RTP de la cabecera n (generada en el momento n*T mseg) = sello de tiempo de 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 de tiempo (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 tiempo.

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 de tiempo inicial y un número de 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 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 de tiempo 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, paquetes de RTP donde las cabeceras han sido desmenuzadas o quitadas), el TS del RTP se regenera a partir del contador del sello de tiempo (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 de tiempo. 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 fluctuación de tiempo 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 de tiempo (TS0), el receptor de RTP puede regenerar un sello de tiempo correcto para cada paquete subsiguiente (después de la inicialización), basándose sólo en el contador del sello de tiempo (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 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 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 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 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 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). 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).

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 sobre la base del 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

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 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 desplazamiento en el sello de tiempo (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 16

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), (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).

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.

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 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 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 sobre la base del contador de TS utilizado en la vieja cadena. Sin embargo, si ocurre un desplazamiento no lineal en el sello de tiempo (TS) entre cadenas (es decir, pérdida de temporización), el sello de tiempo actualizado debe enviarse explícitamente en inic_cadena desde el HS 810 al HR

822. El TS actualizado puede enviarse como un sello de tiempo comprimido 414 (véase la Fig. 4) anteriormente descrito, 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 de tiempo 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 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 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,

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.

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 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 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.

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

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 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).

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 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. La recepción de 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 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 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.

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.

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 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. 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 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 + 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 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 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 el envío de habla 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.

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.

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.

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).

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 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 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

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 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 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 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 (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, 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.

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 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 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

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 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.

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 de tiempo (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 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 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 tiempo acumulada entre el origen y el descompresor. Como la fluctuación de tiempo acumulada incluye la fluctuación de tiempo de “red” (fluctuación de tiempo entre el origen y el compresor) y la fluctuación de tiempo de “radio” (fluctuación de tiempo entre el compresor y el descompresor), el compresor puede calcular una cota superior de la fluctuación de tiempo acumulada sumando a la fluctuación de tiempo de red observada una cota superior de la fluctuación de tiempo 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 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 pequeño permitido que dejaría que el descompresor descomprimiera correctamente, sobre la base de la cota superior de la fluctuación de tiempo acumulada.

B. Caso de la Voz

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 de tiempo del RTP de la cabecera n (generada en el momento n*20 mseg) = sello de tiempo 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 estrechamente, debido a la fluctuación de tiempo de retardo entre el origen y el descompresor. En el funcionamiento normal (ausencia de caídas o fallos), la fluctuación de tiempo 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 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:

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 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, 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 tiempo(n, m) es la fluctuación de tiempo 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 tiempo(n, m) es calculada por el compresor de la siguiente manera:

N_fluctuación de tiempo(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 tiempo(n,m) puede ser positiva o negativa. N_Fluctuación de tiempo en el compresor es la fluctuación de tiempo de red, cuantizada en unidades de T mseg.

R_Fluctuación de tiempo(n,m) es la fluctuación de tiempo de radio de la cabecera n con respecto a la cabecera m, predicha por el compresor. R_Fluctuación de tiempo depende sólo de las características del canal compresordescompresor (CD-CC). No hay que calcular R_Fluctuación de tiempo con precisión, una buena cota superior para R_fluctuación de tiempo es suficiente. Por ejemplo, una cota superior puede ser Máx-radio_fluctuación de tiempo, la máxima fluctuación de tiempo en el CD-CC, si se conoce.

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

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

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.

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:

Calcular Máx_fluctuación de tiempo_red;

Calcular J1 = Máx_fluctuación de tiempo_red + Máx_fluctuación de tiempo_radio + J,

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:

(2*J1 + 1) < 2k.

La fluctuación de tiempo 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 2, respectivamente. El primer procedimiento es adecuado para calcular la fluctuación de tiempo de red. Sin embargo, los procedimientos preferidos para calcular la fluctuación de tiempo 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 tiempo de red para un paquete específico en el compresor se calcula utilizando información con respecto al paquete inmediatamente precedente. Así, por ejemplo, la fluctuación de tiempo de red para el paquete 2 (j2) se calcula utilizando información con respecto al paquete 1, la fluctuación de tiempo de red para el paquete 3 (j3) se calcula utilizando información con respecto al paquete 2, la fluctuación de tiempo de red para el paquete 4 (j4) se calcula utilizando información con respecto al paquete 3 y la fluctuación de tiempo de red para el paquete 5 (j5) se calcula utilizando información con respecto al paquete 4.

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

Opción 1:

Las etapas utilizadas para calcular la fluctuación de tiempo 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 tiempo 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 según se ilustra en la Fig. 14, la fluctuación de tiempo j3 del paquete 3 se calcula utilizando información con respecto al paquete 2 de referencia, la fluctuación de tiempo j4 del paquete 4 se calcula utilizando información con respecto al paquete 2 de referencia y la fluctuación de tiempo j5 del paquete 5 se calcula utilizando información con respecto al paquete 2 de referencia.

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 tiempo j3 = 2, la fluctuación de tiempo j4 = 3 y la fluctuación de tiempo j5 = -1, entonces, antes del paquete 5, N_fluctuación de tiempo_mín = 2 y N_fluctuación de tiempo_máx = 3, mientras que, en el paquete 5, N_fluctuación de tiempo_mín = -1 y N_fluctuación de tiempo_máx = 3. Así, la máxima (Máx) fluctuación de tiempo de red en el paquete 5 = N_fluctuación de tiempo_máx - N_fluctuación de tiempo_mín = 4. En consecuencia, la Máx_fluctuación de tiempo_red para el paquete 5 es 4. Las ecuaciones para calcular la fluctuación de tiempo 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 tiempo de red de un paquete actual se calcula según el procedimiento de la Opción 1 de la siguiente manera:

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

Actualizar N_fluctuación de tiempo_máx y N_fluctuación de tiempo_mín, donde N_fluctuación de tiempo_máx se define como Máx {N_fluctuación de tiempo (j, RFH)}, para todas las cabeceras j enviadas desde el RFH, e incluyendo el RFH. N_fluctuación de tiempo_mín se define como Mín {N_fluctuación de tiempo 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 tiempo_red = (N_fluctuación de tiempo_máx – N_fluctuación de tiempo_mín).

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

Opción 2:

Las etapas utilizadas para calcular la fluctuación de tiempo 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 tiempo de red en un paquete específico se calcula utilizando cálculos de fluctuación de tiempo 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 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 tiempo 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, si la fluctuación de tiempo 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 tiempo_red = 7. Las ecuaciones para calcular la fluctuación de tiempo de red según el tercer procedimiento de la Opción 2 y una descripción de las mismas se exponen más adelante.

La fluctuación de tiempo 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 tiempo (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 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 tiempo_red = |Máx N_fluctuación de tiempo (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), 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 T_último son los valores de R_Temporizador cuando se recibieron, respectivamente, la Cabecera_actual y la Última_cabecera.

3. Prueba de corrección

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.

Sobre la base de lo anterior, entonces:

|TS_Aprox – TS_Exacto| <= |Fluctuación de tiempo (Cabecera_actual, Última_cabecera)|;

Debido a la definición de Máx_fluctuación de tiempo_red en el compresor:

|Fluctuación de tiempo (Cabecera_actual, Última_cabecera)| < J1,

Donde J1 = Máx_fluctuación de tiempo_red + Máx_fluctuación de tiempo_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.

Así, se deduce que:

|TS_Aprox – TS_Exacto| < J1

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

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.

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

En sistemas inalámbricos, para la dirección del enlace ascendente, la fluctuación de tiempo 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 tiempo 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 de tiempo 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 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 tiempo de red no es cero, pero la fluctuación de tiempo global es normalmente pequeña, para satisfacer los requisitos de tiempo real. El k esperado será aún pequeño y 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

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 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 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

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 revela 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 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 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

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

i. Enlace descendente

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

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 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 a utilizar, de la siguiente manera:

J2 = Cota superior de N_fluctuación de tiempo (Cabecera_actual, RFH*) + Máx_fluctuación de tiempo_radio + J,

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

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

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

|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 nuevo ANI_AD, expresado en unidades de T mseg; y

J = 2.

-: Descompresor

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.

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

-: Caso de fallo

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

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 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 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.

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

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 tiempo (Cabecera_actual, RFH*) + Máx_fluctuación de tiempo_radio + J,

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

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

La cota superior de N_fluctuación de tiempo (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;

J = 2

-: 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.

8. Prestaciones del Esquema

Debido a los requisitos conversacionales en tiempo real, se espera que la fluctuación de tiempo 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 tiempo de hasta 16 a 32 muestras de habla puede corregirse.

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é 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.

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.

El compresor necesita mantener poca información de memoria:

T_RFH, p_TS_RFH, N_fluctuación de tiempo_máx, N_fluctuación de tiempo_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 tiempo

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 funcionamiento normal. Sin embargo, no pueden descartarse casos donde la fluctuación de tiempo 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 tiempo como una interfaz de primer orden con el compresor, para eliminar por filtrado paquetes con fluctuación de tiempo excesiva (es decir, fluctuación de tiempo que excede algún valor umbral).

En el caso estático (sin traspaso), la fluctuación de tiempo se calcula como J1 y se compara con un umbral estático de la siguiente manera:

J1 = (n_fluctuación de tiempo_máx – N_fluctuación de tiempo_mín) + Máx_fluctuación de tiempo_radio + J.

En el caso de traspaso, la fluctuación de tiempo 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 de tiempo_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.

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

D. Caso del Vídeo

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:

Sello de tiempo del RTP del paquete m = sello de tiempo 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

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 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 tiempo de retardo entre el origen y el descompresor. En el funcionamiento normal (ausencia de caídas o fallos), la fluctuación de tiempo de retardo está acotada, para 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.

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.

Descompresor

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

1. Traspaso

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

2. Valor de k

Para la voz, se mostró que k = 4 o 5 es suficiente (2k = 16 o 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 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.

Claims

REIVINDICACIONES

1. Un procedimiento para descomprimir un sello de tiempo comprimido (414) en un campo cabecera de un paquete actual transmitido en una red desde un compresor a un descompresor (137) que comprende las etapas de:

recibir un sello de tiempo comprimido (414) en un campo cabecera de un paquete actual en el descompresor (137), dicho sello de tiempo comprimido (414) habiendo sido calculado en el compresor como una parte de un valor de sello de tiempo que se calcula como un efecto a causa de fluctuación de tiempo que tiene la red entre una fuente (102) y el descompresor (137) en la transmisión de paquetes;

calcular una aproximación del valor de sello de tiempo en el campo cabecera del paquete actual en el descompresor (137) en base al tiempo pasado desde la llegada de un campo cabecera previo al descompresor (137) y un valor de sello de tiempo del paquete previo;

calcular una magnitud de valor de corrección de sello de tiempo para el paquete actual en el descompresor

(137) en base al sello de tiempo comprimido (414) del paquete actual; y

descomprimir el sello de tiempo comprimido (414) del paquete actual en el descompresor (137) ajustando la aproximación calculada del valor de sello de tiempo en el campo cabecera del paquete actual en un cantidad en base a la magnitud de valor de corrección de sello de tiempo.
2.

El procedimiento según la reivindicación 1, en el que dicho efecto a causa de fluctuación de tiempo que tiene la red entre la fuente (102) y el descompresor (137) en la transmisión de paquetes se calcula calculando un efecto a causa de fluctuación de tiempo de la red entre la fuente y el compresor y calculando un efecto a causa de fluctuación de tiempo de la red entre el compresor y el descompresor (137).
3.

El procedimiento según la reivindicación 2, en el que dicho efecto a causa de fluctuación de tiempo entre la fuente (102) y el descompresor (137) se fija a un valor de umbral superior de fluctuación de tiempo.
4.

El procedimiento según la reivindicación 2, en el que dicho calcular un efecto a causa de fluctuación de tiempo de la red antes del compresor comprende:

calcular un efecto a causa de fluctuación de tiempo de un paquete actual usando información respecto a un paquete de referencia.
5.

El procedimiento según la reivindicación 2, en el que dicho calcular un efecto a causa de fluctuación de tiempo de la red antes del compresor comprende:

calcular un efecto a causa de fluctuación de tiempo de un paquete actual usando información respecto a dicho paquete actual y cada uno de un número predeterminado de paquetes precedentes.
6.

El procedimiento según la reivindicación 2, en el que dicho calcular un efecto a causa de fluctuación de tiempo de la red antes del compresor comprende:

calcular un efecto a causa de fluctuación de tiempo de un paquete actual usando información respecto a dicho paquete actual y cada paquete precedente hasta un paquete de referencia.
7.

El procedimiento según la reivindicación 1, en el que el sello de tiempo comprimido en el campo cabecera se calcula como los k bits menos significativos del valor de sello de tiempo, en donde k es un entero.
8.

Un aparato para descomprimir un sello de tiempo comprimido (414) en un campo cabecera de un paquete actual transmitido en una red desde un compresor a un descompresor (137) que comprende:

medios para recibir un sello de tiempo comprimido (414) en un campo cabecera de un paquete actual [en el descompresor (137)], dicho sello de tiempo comprimido (414) habiendo sido calculado en el compresor como una parte de un valor de sello de tiempo que se calcula como un efecto a causa de fluctuación de tiempo que tiene la red entre una fuente (102) y el descompresor (137) en la transmisión de paquetes;

medios para calcular una aproximación del valor de sello de tiempo en el campo cabecera del paquete actual en el descompresor (137) en base al tiempo pasado desde la llegada de un campo cabecera previo al descompresor (137) y un valor de sello de tiempo del paquete previo;

medios para calcular una magnitud de valor de corrección de sello de tiempo para el paquete actual en el descompresor (137) en base al sello de tiempo comprimido (414) del paquete actual; y

medios para descomprimir el sello de tiempo comprimido (414) del paquete actual en el descompresor (137) ajustando la aproximación calculada del valor de sello de tiempo en el campo cabecera del paquete actual en un cantidad en base a la magnitud de valor de corrección de sello de tiempo.
9.

El aparato según la reivindicación 8, en el que dicho efecto a causa de fluctuación de tiempo que tiene la red entre la fuente (102) y el descompresor (137) en la transmisión de paquetes se calcula calculando un efecto a causa de fluctuación de tiempo de la red entre la fuente y el compresor y calculando un efecto a causa de fluctuación de tiempo de la red entre el compresor y el descompresor (137).
10.

El aparato según la reivindicación 9, en el que dicho efecto a causa de fluctuación de tiempo entre la fuente

(102) y el descompresor (137) se fija a un valor de umbral superior de fluctuación de tiempo.
11.

El aparato según la reivindicación 9, en el que dicho efecto a causa de fluctuación de tiempo de la red antes del compresor se calcula usando información respecto a un paquete de referencia.
12.

El aparato según la reivindicación 9, en el que dicho efecto a causa de fluctuación de tiempo de la red antes del compresor se calcula usando información respecto a dicho paquete actual y cada uno de un número predeterminado de paquetes precedentes.
13.

El aparato según la reivindicación 9, en el que dicho efecto a causa de fluctuación de tiempo de la red antes del compresor se calcula usando información respecto a dicho paquete actual y cada paquete precedente hasta un paquete de referencia.
14.

El aparato según la reivindicación 8, en el que el sello de tiempo comprimido en el campo cabecera se calcula como los k bits menos significativos del valor de sello de tiempo, en donde k es un entero.
15.

Un producto de programa de ordenador que comprende:

un medio legible por ordenador que comprende:

código que cuando se ejecuta hace que al menos un ordenador lleve a cabo un procedimiento según 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 DE TIEMPO (TS)

NÚMERO DE SECUENCIA (SN) OTROS CAMPOS

310

312 314

FIG. 4

FORMATO COMPRIMIDO DE CABECERA DE RTP

TIPO DE MENSAJE

MÁSCARA DE BITS SELLO DE TIEMPO Campos optativos

COMPRIMIDO

410

412 416

414

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Í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_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 VARIACIÓN DE RETARDO DE PAQUETE 5 CON RESPECTO A 1: j(5,1) = 2 = N_VARIACIÓN DE RETARDO (5,1)

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

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

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

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