ES2397710T3 - Procedimiento y sistema para comprimir y descomprimir encabezamientos de paquetes - Google Patents

Abstract

Un procedimiento de funcionamiento de un descompresor (115, 137) en un sistema que tiene un transmisor (110,120) que transmite una pluralidad de paquetes, conteniendo cada uno un encabezamiento, a un receptor (130, 150),comprendiendo el procedimiento descomprimir un encabezamiento comprimido contenido en un paquete actualrecibido por el receptor: determinando con un contador (134) en el receptor un tiempo transcurrido Dt entre paquetes recibidosconsecutivamente, siendo el tiempo transcurrido Dt la diferencia entre tiempos en los que se recibieron elpaquete actual y un paquete recibido inmediatamente antes; determinando si el tiempo transcurrido Dt es mayor que o igual a un lapso de tiempo que indica que al menosun paquete se ha perdido entre el paquete actual y el paquete recibido inmediatamente antes; procesando el tiempo transcurrido Dt que indica que al menos se ha perdido un paquete para determinar unnúmero de paquetes perdidos entre el paquete recibido inmediatamente antes y el paquete actual; añadiendo el número de paquetes perdidos a un número de paquete del paquete recibido inmediatamenteantes para actualizar un número del paquete actual en una secuencia de transmisión de la pluralidad depaquetes; y descomprimiendo el encabezamiento comprimido del paquete actual usando el número actualizado del paqueteactual.

Description

Procedimiento y sistema para comprimir y descomprimir encabezamientos de paquetes

La presente invención se refiere a compresión y descompresión de encabezamientos en transmisiones de paquetes de datos.

El Protocolo de Transferencia en Tiempo Real (RTP) se usa predominantemente por multimedia en tiempo real basada en el Protocolo de Internet (IP) en la parte superior del Protocolo de Datagramas de Usuario (UDP/IP). Se describe RTP en detalle en el documento RFC 1889. El tamaño de los encabezamientos IP/UDP/RTP combinados es al menos 40 bytes para IPv4 y al menos 60 bytes para IPv6. En sistemas, un total de 40-60 bytes de tara por paquete se puede considerar fuerte (por ejemplo, tal como redes celulares) donde la eficacia espectral es una preocupación primaria. Por consiguiente, existe una necesidad de mecanismos de compresión de encabezamientos IP/UDP/RTP adecuados. Se describe un esquema de compresión de encabezamiento actual en el documento RFC 2508, por S. Casner, V. Jacobson, "Comprimir Encabezamientos IP/UDP/RTP para Enlaces Serie de Baja Velocidad", Grupo de Tareas Especiales de Ingeniería en Internet (IETF), Febrero 1999, y que puede comprimir el encabezamiento IP/UDP/RTP de 40/60 bytes hasta 2 o 4 bytes sobre enlaces punto a punto. Los algoritmos de compresión de encabezamientos existentes están basados en la observación que muchos campos de los encabezamientos de paquetes IP permanecen constantes en un flujo de paquetes durante la duración de una sesión. Por lo tanto, es posible comprimir la información del encabezamiento estableciendo un estado de compresión (la información de encabezamiento completa) en el des-compresor y llevando simplemente una mínima cantidad de información de encabezamiento desde el compresor hasta el des-compresor. Los esquemas de compresión de encabezamientos IP/UDP/RTP, como se describen por ejemplo en el documento RFC 2508, se benefician del hecho que ciertos campos de información llevados en los encabezamientos 1.) no cambian (campos de encabezamiento de 'Tipo 1') o 2.) cambian de una manera bastante predecible (campos de encabezamiento de 'Tipo 2'). Otros campos, denominados como campos de encabezamiento de 'Tipo 3', varían de tal manera que se deben transmitir de alguna forma en cada paquete (es decir, no son compresibles).

Son ejemplos de campos de encabezamiento de Tipo 1 la dirección IP, número de puerto UDP, RTP SSRC (fuente de sincronización), etc. Estos campos únicamente se necesitan transmitir al receptor/descompresor una vez durante el curso de una sesión (como parte del paquete o paquetes transferidos en el establecimiento de sesión, por ejemplo). Los campos de Tipo 1 también se denominan campos 'invariables'.

Son ejemplos de campos de encabezamiento de Tipo 2 la indicación de tiempo RTP, el número de secuencia RTP y los campos ID de IP. Todos tienen una tendencia a incrementar en alguna cantidad constante desde el paquete (n) al paquete (n+1). Por lo tanto, no hay necesidad de transmitir estos valores en cada encabezamiento. Se requiere únicamente que el receptor/descompresor sea consciente del valor de incremento constante, denominado en lo sucesivo como la diferencia de primer orden (FOD), asociada con cada campo que muestra este comportamiento. El receptor/descompresor utiliza estas FOD para regenerar valores de campo de Tipo 2 actualizados cuando reconstruye el encabezamiento original. Los campos de Tipo 2 son parte de los campos 'variables'.

Se debe señalar que, en ocasiones, los campos de Tipo 2 cambiarán de una manera irregular. La frecuencia de tales eventos depende de varios factores, incluyendo el tipo de medios que se transmiten (por ejemplo, voz o vídeo), la fuente de medios actual (por ejemplo, para voz, el comportamiento puede variar de un altavoz a otro), y el número de sesiones que comparten simultáneamente la misma dirección IP.

Un Ejemplo de un campo de encabezamiento de Tipo 3 es el M-bit RTP (Marcador), que indica la aparición de algunos límites en el medio (por ejemplo, fin de un fotograma de vídeo). Debido a que los medios normalmente varían de manera impredecible, esta información no se puede predecir realmente. Los campos de Tipo 3 son parte de campos 'variables'.

El descompresor mantiene información de contexto de descompresión que contiene toda la información pertinente relacionada para reconstruir el encabezamiento. Esta información es principalmente campos de tipo 1, valores FOD y otra información. Cuando se pierden o corrompen paquetes, el descompresor puede perder sincronización con el compresor de manera que ya no puede reconstruir paquetes correctamente. La pérdida de la sincronización puede ocurrir cuando se eliminan o corrompen paquetes durante la transmisión entre el compresor y descompresor.

Dado lo anterior, el compresor necesita transmitir tres tipos diferentes de encabezamientos durante el curso de una sesión:

•

Encabezamiento Completo (FH): contiene el conjunto completo de todos los campos de encabezamiento (Tipos 1, 2 y 3). Este tipo de encabezamiento es el menos óptimo para enviar debido a su gran tamaño (por ejemplo, 40 bytes para IPv4). En general, es deseable enviar un paquete FH únicamente al principio de la sesión (para establecer datos de Tipo 1 en el receptor). La transmisión de paquetes FH adicionales tiene efectos adversos en la eficacia del algoritmo de compresión. Cuando el compresor transmite paquetes FH, se dice que está en el 'estado FH'.

•

Primer Orden (FO): contiene información de encabezamiento mínima (por ejemplo campos de Tipo 3), campos de control específico de compresor/descompresor (específicos para el algoritmo de compresión en uso), e

información que describe cambios en los campos FOD actuales. Un paquete FO es básicamente un paquete SO (descrito a continuación), con información adicional que establece nueva información FOD para uno o más campos de Tipo 2 en el descompresor. Si se aplica la compresión de encabezamiento a un flujo VoIP (voz sobre protocolo de internet), la transmisión de un paquete FO podría activarse por la aparición de una secuencia hablada después de un intervalo de silencio en la voz. Tal evento da como resultado algún cambio inesperado en el valor de indicación de tiempo RTP, y una necesidad de actualizar la indicación del tiempo RTP en el receptor por un valor distinto de la FOD actual. El tamaño de los paquetes FO depende del número de campos de Tipo 2 cuya diferencia de primer orden cambió (y la cantidad del valor absoluto de cada cambio). Cuando el compresor transmite paquetes FO, se dice que está en el 'estado FO'.

• Segundo Orden (SO): un paquete SO contiene información de encabezamiento mínima (por ejemplo campos de Tipo 3) y campos de control específico de compresor y descompresor. El modo preferido de funcionamiento para el compresor y descompresor es transmisión y recepción de paquetes SO, debido a su mínimo tamaño (en orden de solo 2 bytes o incluso menos). Cuando el compresor transmite paquetes SO, se dice que está en el 'estado SO'. Los paquetes SO se transmiten únicamente si el encabezamiento actual se ajusta con el patrón de una FOD.

El documento RFC 2508 está basado en el concepto que la mayor parte del tiempo, los campos RTP que cambian de un paquete al siguiente, tales como la indicación de tiempo RTP, se pueden predecir mediante extrapolación lineal de los paquetes SO transmitidos. Esencialmente la única información que se tiene que enviar es un número de secuencia, usado para detección de errores y pérdida de paquetes (así como una ID de información de contexto). Cuando el transmisor determina que no se puede aplicar la extrapolación lineal al paquete actual con respecto al paquete inmediatamente anterior, se transmite un paquete FO. Para iniciar la sesión, se transmite un paquete FH. Además, cuando el receptor determina que hay una pérdida de paquete (como se detecta mediante un número de secuencia que incrementa en más que 1) el receptor solicitará explícitamente al transmisor transmitir el encabezamiento completo para permitir una resincronización.

Sin embargo, la compresión de encabezamientos definida en el documento RFC 2508 no es bien adecuada para ciertos entornos (tales como entornos celulares o inalámbricos), donde el ancho de banda escasea y los errores son comunes. En el esquema de compresión de encabezamientos del documento RFC 2508, se supone que la indicación de tiempo RTP tiene la mayoría del tiempo un patrón de aumento lineal. Cuando el encabezamiento se ajusta al patrón, esencialmente únicamente se necesita un corto número de secuencia enviado como SO en el encabezamiento comprimido. Cuando el encabezamiento no se ajusta al patrón, se envía la diferencia entre las indicaciones de tiempo RTP de los encabezamientos actual y previo en el encabezamiento comprimido FO.

El requisito de ancho de banda adicional puede manifestarse por sí mismo de diversas maneras, dependiendo del entorno de funcionamiento. Por ejemplo, en sistemas celulares es muy deseable en general limitar el uso de ancho de banda tanto como sea posible, ya que es un recurso escaso.

El documento RFC 2508 sufre de falta de robustez para soportar errores o pérdidas de encabezamientos, debido a que la descompresión del encabezamiento actual se puede hacer únicamente si el encabezamiento inmediatamente anterior se recibió y descomprimió también sin error. La compresión de encabezamientos definida en el documento RFC 2508 no es bien adecuada para entornos celulares, donde el ancho de banda escasea y son comunes grandes ráfagas de errores. En el documento RFC 2508, cuando se detecta una pérdida de paquete, se invalidan los siguientes paquetes con encabezamientos comprimidos, con un requisito adicional que es necesario enviar un encabezamiento de gran tamaño para recuperarse del error. Los encabezamientos de gran tamaño consumen ancho de banda y crean picos en la demanda de ancho de banda que son más difíciles de gestionar.

Solo usando un corto número de secuencia (uno con un número limitado de bits) para detectar pérdida de paquetes no es robusto para una red propensa a errores, tal como en una red inalámbrica donde pueden ocurrir grandes pérdidas en cualquier momento. En este caso, se definen las grandes pérdidas como pérdida de un ciclo de secuencia o paquetes en línea. Bajo la situación de una gran pérdida, pueden perderse unas series de paquetes en el número de paquetes del ciclo de secuencia que tienen una identificación de paquete definida por un número limitado de bits y, como resultado, el número de secuencia en el paquete recibido por el descompresión (dispositivo de recepción en el enlace ascendente o en el enlace descendente) del receptor vuelve a cero (repite). Por ejemplo, suponiendo que el número de secuencia consiste en k bits, el ciclo de secuencia es igual a 2k.

Como se muestra en la Figura 1, el compresor (dispositivo de transmisión en el enlace ascendente o enlace descendente) envía un paquete con sec=n en el momento t0, y los siguientes 2k paquetes, comenzando desde el paquete con sec=n+1 en el momento t1 y finalizando en el paquete con sec=n en el momento t2. En el momento t3, el compresor envía un paquete con número de secuencia igual a n+1 de nuevo. Suponiendo un paquete con un número de secuencia igual a n+1 enviado en el momento t1 hasta que se envía el paquete con el número de secuencia igual a n en el momento t2, que se pierden todos debido a grandes pérdidas, a continuación el descompresor únicamente recibe el paquete con el número de secuencia igual a n enviado en el momento t0, y el paquete con el número de secuencia igual a n+1 enviado en el momento t3. En base al esquema de detección de pérdida de paquetes actual definido en el documento RFC 2508, el descompresor concluye que no hay pérdida de paquetes y descomprime el paquete de una manera equivocada. Esto no solo afecta a la corrección de descompresión de paquetes con un número de secuencia igual a n+1, sino también a los paquetes posteriores.

La presente invención puede proporcionar transmisión y recepción de paquetes mejorada en entornos, tales como comunicaciones inalámbricas, que son propensas a interrupciones periódicas de recepción de paquetes tales como las causadas por desvanecimiento, etc. La invención puede proporcionar rendimiento mejorado de transmisión y recepción de paquetes en comparación con el documento RFC 2508 incluyendo eliminación del problema de vuelta

5 a cero de la técnica anterior analizado anteriormente en la Figura 1. La decodificación apropiada de un encabezamiento comprimido en un paquete actual de acuerdo con la invención no depende de la correcta descompresión de un paquete inmediatamente anterior como con el documento RFC 2508.

La presente invención proporciona un mecanismo que detecta grandes pérdidas en el nivel de compresión de encabezamiento, así como un esquema de recuperación correspondiente después de detección de una gran 10 pérdida. La invención en general es aplicable a protocolos de comunicaciones donde la sincronización de secuencia se debe mantener entre el transmisor y el receptor, en la presencia de grandes ráfagas de errores.

La compresión de encabezamientos adaptable es un marco general para compresión de encabezamientos robusta, que se puede parametrizar para considerar la existencia/no existencia y características de rendimiento de un canal inverso. El marco incluye tres modos básicos de funcionamiento:

15 • Modo Determinístico Bidireccional: se usa este modo en el caso donde hay un canal inverso 'bien definido', que se puede usar para llevar diversos tipos de información de retroalimentación desde el descompresor hasta el compresor. Un ejemplo de tal retroalimentación desde el descompresor es un acuse de recibo, usado, por ejemplo, para avanzar desde un estado de compresión más bajo a un estado de compresor más alto.

• Modo Oportunístico Bidireccional: este modo de funcionamiento se usa en el caso donde existe un canal

20 inverso, pero está definido 'débilmente', es decir, el canal puede no estar siempre disponible, o puede ser lento/no fiable.

• Modo Unidireccional (Pesimista u Optimista): este modo de funcionamiento se usa cuando no existe canal inverso de ningún tipo.

La invención está definida mediante las reivindicaciones.

25 La Figura 1 ilustra la deficiencia de pérdida de paquetes CON el documento RFC 2508. La Figura 2 ilustra un ejemplo de una arquitectura de sistema que se puede usar para practicar la presente invención. La Figura 3 ilustra conceptualmente información de contexto de compresión. La Figura 4 ilustra conceptualmente información de contexto de descompresión.

30 La Figura 6 ilustra la transición de un compresor de transmitir encabezamientos que tienen un número más alto de bits a encabezamientos que tienen un número más bajo de bits usando acuses de recibo. La Figura 7 ilustra la transición de un compresor de transmitir encabezamientos con un primer orden de compresión a encabezamientos con un segundo orden de compresión. La Figura 8 ilustra la detección y recuperación de paquetes cuando ocurre una vuelta a cero que tiene un

35 número de paquetes mayor de 2k donde se usan k bits para codificar n números de secuencia definidos por los k bits. La Figura 9 ilustra el funcionamiento de un compresor y descompresor usando acuses de recibo para controlar la transición entre números de secuencia que tienen k bits y f bits extendidos y vuelta a k bits. La Figura 10 ilustra reducción de ancho de banda conseguida transmitiendo una secuencia de paquetes FH y

40 FO antes de que se genere un acuse de recibo por el descompresor que significa la recepción de un paquete FH. Las Figuras 14A-F ilustran formatos de paquetes que se transmiten mediante la presente invención. La Figura 15 ilustra la conmutación de un estado de compresión de un compresor a un estado más alto de compresión únicamente después de que se recibe un acuse de recibo desde un descompresor.

45 La Figura 16 ilustra la conmutación de un estado de compresión de un compresor a un estado más alto de compresión antes de que llegue un número preestablecido de paquetes en una descompresión cuando se recibe un acuse de recibo. La Figura 17 ilustra la conmutación de un estado de compresión de un compresor a un mayor estado de compresión después de que llegue un número preestablecido de paquetes en un descompresor antes de que

50 llegue un acuse de recibo. La Figura 18 ilustra la conmutación de un estado de compresión de un compresor a un estado de compresión más alto únicamente después de que lleguen un número presente de paquetes en una descompresión. La Figura 19 ilustra gráficamente una comparación de la invención con el documento RFC 2508. La Figura 20 ilustra un análisis gráfico del rendimiento de la presente invención.

55 La Figura 2 ilustra un sistema ejemplar en el que se puede practicar la presente invención. Sin embargo, debe entenderse que la presente invención no está limitada al mismo siendo otras arquitecturas de sistemas igualmente aplicables a la práctica de la invención. Un terminal 102 está conectado a una red 108 IP. El terminal 102 puede ser, sin limitación, un ordenador personal o similar ejecutando RTP/UDP/IP, y proporcionando muestras de voz empaquetadas en paquetes RTP para transmisión sobre la red 108 IP. El terminal 102 incluye un punto final 104 que

60 identifica este terminal (por ejemplo, incluyendo dirección IP, número de puerto, etc.) ya sea como una fuente y/o destino para paquetes RTP. Mientras que la red 108 IP se proporciona como un ejemplo de una red de paquetes, sin

embargo, se pueden usar otros tipos de redes de conmutación de paquetes o similares en lugar de la misma. El terminal 102 también incluye un temporizador 103 local para generar una indicación de tiempo.

Las infraestructuras 110 y 120 de red de acceso (ANI), que pueden estar residentes en un subsistema de estación base (BSS), están conectadas a la red 108 IP. Las ANI son entidades de red y nodos de red. Están acoplados una pluralidad de terminales móviles inalámbricos que son entidades de red y nodos de red y funcionan como compresores móviles y descompresores móviles (se ilustran dos terminales inalámbricos 130 y 150) mediante enlaces 140 de frecuencia de radio (RF) a las ANI 110 y 120. Cuando se mueve uno de los terminales 130 y/o 150 móviles, es necesario para el terminal o terminales de vez en cuando traspasarse a otra ANI, como una consecuencia del movimiento más allá de la conexión de radio con una ANI. Este procedimiento también requiere, cuando se usa y localiza la compresión y descompresión de encabezamientos en la ANI, la transferencia de la información de contexto de compresión y descompresión desde una ANI (antigua) a otra ANI (nueva) para conseguir continuidad, por ejemplo si se mueven los terminales móviles 130 y/o 150 y se traspasan de la ANI 110 a la ANI 120. La transferencia, como se analiza a continuación, puede ocurrir en diversos momentos pero para minimizar interrupciones, se debe completar en el momento en que la nueva ANI realiza sobre el encabezamiento el papel de compresión/descompresión de la antigua ANI. La relocalización de funciones de compresión/descompresión aparece cuando la nueva entidad de red releva en un punto en el tiempo. Por otro lado, la transferencia de información de contexto se puede dispersar sobre un momento material y precede la relocalización. El enlace 140 RF incluye, como se ilustra, tráfico 142 del enlace ascendente (desde los terminales 130 y 150 móviles hasta la ANI 110) y tráfico 144 del enlace descendente (desde la ANI 110 hasta los terminales 130 y 150 móviles). Los terminales 130 y/o 150 móviles se traspasan de una ANI, tal como la ANI 110 cuando uno o más de los terminales móviles se mueve a otra ANI, por ejemplo la ANI 120. Cada ANI se interrelaciona con uno o más de los terminales inalámbricos (o de frecuencia de radio) (incluyendo el terminal 130) en una región con la red 108 IP, incluyendo conversión entre señales cableadas (proporcionadas desde una red 108 IP) e inalámbricas o señales RF (proporcionadas hacia o desde terminales 130 y 150). Por lo tanto, cada ANI permite que los paquetes, tales como, pero sin limitación, paquetes RTP transmitidos y recibidos desde la red 108 IP se envíen sobre el enlace 140 RF a al menos uno de los terminales 130 y 150 inalámbricos, y permite transmisión de paquetes, tales como paquetes RTP pero sin limitación a paquetes RTP, que se transmitan desde los terminales 130 y 150 que se transmiten mediante la red 108 IP a otro terminal, tal como el terminal 102.

Cada ANI incluye una pluralidad de entidades. La explicación y descripción más detallada de la ANI 110 se da para facilitar el entendimiento de la arquitectura y funcionamiento de todas las ANI en la red. Todas las ANI pueden ser de la misma arquitectura como la ANI 110 pero no están ilustradas en el mismo grado de detalles. La ANI 110 incluye uno o más adaptadores ANI (ANI_AD), tales como ANI_AD 112 (ilustrado en detalle) y ANI_AD 114, cada uno de los cuales preferentemente incluye un temporizador 113 para proporcionar una indicación de tiempo. Cada ANI_AD realiza compresión de encabezamientos (anterior al tráfico de enlace descendente) y descompresión (después del tráfico de enlace ascendente). Los encabezamientos (uno o más campos de encabezamiento, tales como una indicación de tiempo y número de secuencia) para paquetes RTP recibidos desde la red 108 IP se comprimen mediante la ANI_AD 112 antes de la transmisión a los terminales 130 y 150 sobre el tráfico 142 de enlace descendente, y se descomprimen los encabezamientos de paquetes recibidos desde los terminales 130 y 150 móviles mediante la ANI_AD 112 antes de la transmisión a la red 108 IP. ANI_AD 110 funciona como un transmisor/receptor (transceptor) y específicamente como un compresor/descompresor 115 con el compresor comprimiendo paquetes de datos antes de la transmisión y el descompresor descomprimiendo paquetes de datos después de la recepción. ANI_AD 110 se interrelaciona con terminales localizados en un área específica o diferente en la región de una red 108 IP. ANI_AD 112 incluye un temporizador 113 para implementar una técnica de descompresión basada en el tiempo. ANI_AD 112 también incluye una función 116 de reducción de fluctuación de fase (JRF) que funciona para medir la fluctuación de fase en paquetes (o encabezamientos) recibidos sobre la red 108 y descarta cualquier encabezamiento/paquete que tenga fluctuación de fase excesiva.

Cada terminal incluye una pluralidad de entidades. La explicación más detalla del terminal 130 móvil se da para facilitar el entendimiento del diseño y funcionamiento de todos los terminales 130 y 150 móviles en la red que son de un diseño y funcionamiento similares. Cada uno de los terminales móviles puede también funcionar como un compresor/descompresor en comunicaciones más allá de las ANI 110 y 120 y específicamente, con otras redes. El Terminal Móvil 130 incluye un punto final 132 RTP que es una fuente (transmisor) y/o destino (receptor) para paquetes RTP e identifica la dirección IP del terminal, el número de puerto, etc. El terminal 130 móvil incluye un adaptador 136 de terminal (MS_AD) que realiza compresión de encabezamientos (paquetes para transmitirse sobre el tráfico 142 de enlace ascendente) y descompresión (paquetes recibidos sobre el tráfico 144 de enlace descendente). Por lo tanto, el adaptador 136 de terminal (MS_AD) se puede considerar que es un compresor/descompresor 137 de encabezamientos (transceptor), similar al compresor/descompresor ANI_AD. La terminología MS_AD tiene el mismo significado que AD. El MS_AD 136 también incluye un temporizador 134 (un temporizador receptor) para calcular una aproximación (o estimación) de una indicación de tiempo RTP de un encabezamiento actual y para medir el tiempo transcurrido entre paquetes recibidos sucesivamente para localizar pérdidas de paquetes durante la transmisión al terminal mediante degradación inalámbrica tal como desvanecimiento. El MS_AD 136 puede usar información adicional en el encabezamiento RTP para afinar o corregir la aproximación de la indicación de tiempo como se describe en la Solicitud de Patente con Nº de Serie 091377.913 en trámite junto con la presente. La aproximación de la indicación de tiempo puede estar corregida o ajustada en base a una indicación de tiempo comprimida proporcionada en el encabezamiento RTP. De esta manera, se pueden usar un temporizador local y una indicación de tiempo comprimida para regenerar la indicación de tiempo correcta para cada encabezamiento RTP.

Los paquetes RTP, incluyendo paquetes con encabezamientos comprimidos y no comprimidos, se transmiten en la

5 red, tal como, pero sin limitación, la red ejemplar de la Figura 2 sobre un enlace de datos (tal como un enlace 140 inalámbrico) donde el ancho de banda escasea y los errores son comunes. La presente invención no está limitada a un enlace inalámbrico, sino que es aplicable a una amplia diversidad de enlaces (incluyendo enlaces cableados, etc.).

La Figura 3 ilustra conceptualmente ejemplos e información de contexto de compresión. La información de contexto

10 de compresión es un conjunto, subconjunto o representación de un subconjunto de información que puede ser de cualquier tipo en un encabezamiento usada por el compresor como una entrada para el algoritmo de compresión para producir un encabezamiento comprimido y se puede transmitir desde una entidad hasta otra entidad. La otra entrada es desde la fuente de encabezamiento de los encabezamientos a comprimir.

La Figura 4 ilustra conceptualmente ejemplos e información de contexto de descompresión. La información de

15 contexto de descompresión es un conjunto, subconjunto o representación de un subconjunto de información que puede ser de cualquier tipo en un encabezamiento usada por el descompresor como una entrada para el algoritmo de compresión para producir un encabezamiento descomprimido y se puede transmitir desde una entidad hasta otra entidad. La otra entrada es desde la fuente de encabezamiento de los encabezamientos a descomprimir.

Tanto la información de contexto de compresión como de descompresión son dinámicas, es decir, se pueden

20 actualizar mediante el compresor y el descompresor respectivamente. La frecuencia de las actualizaciones depende del esquema de compresión del encabezamiento. Los eventos que pueden dar como resultado una actualización de la información de contexto de compresión en el compresor incluyen la compresión de un encabezamiento de entrada, o la recepción de retroalimentación desde el descompresor. Los eventos que pueden dar como resultado una actualización de la información de contexto de descompresión en el descompresor incluyen la descompresión

25 de un encabezamiento de entrada.

La Compresión de Encabezamiento Adaptable (ACE) es un marco general para compresión de encabezamientos robusta que se puede parametrizar para considerar la existencia/no-existencia y características de rendimiento de un canal de retroalimentación. El marco incluye tres modos básicos de funcionamiento:

• Modo Determinístico Bidireccional: este modo se usa en el caso donde existe un canal inverso 'bien definido',

30 que se puede usar para llevar diversos tipos de información de retroalimentación desde el descompresor hasta el compresor. Un ejemplo de tal retroalimentación desde el descompresor es el acuse de recibo (ACK), usado, por ejemplo, para avanzar desde un estado de compresión más bajo a un estado de compresor más alto. Mediante la recepción de los ACK mediante un canal bien definido, el compresor obtiene el conocimiento que se ha recibido algún encabezamiento específico. El compresor se beneficia de ese conocimiento para

35 comprimir más fiablemente y más eficazmente.

• Modo Oportunístico Bidireccional: este modo de funcionamiento se usa en el caso donde existe un canal inverso, pero está definido 'débilmente', es decir, el canal puede no estar siempre disponible, o puede ser lento/no fiable. Hay muchas aplicaciones importantes que bidireccionales bilaterales. Un ejemplo principal es voz o vídeo conversacional. En tales casos, hay inherentemente un canal inverso, que puede llevar la

40 retroalimentación.

• Modo Unidireccional (Pesimista u Optimista): este modo de funcionamiento se usa cuando no hay canal inverso de ningún tipo. Debido a que no hay retroalimentación en absoluto desde el descompresor con respecto a su estado actual, el compresor debe enviar ocasionalmente alguna información de refresco al descompresor, que se puede usar para restablecer sincronismo en el caso que algo vaya mal. Dependiendo de diversos factores

45 (por ejemplo, condiciones de canal), que se pueden conocer por el compresor, el enfoque en este modo puede ser pesimista (refrescos más frecuentes) u optimista (refrescos menos frecuentes). Además, hay eventos que pueden activar el compresor para enviar información FH, para refrescar al descompresor y reducir la posibilidad de descompresión incorrecta.

El compresor ACE se puede caracterizar como una progresión a través de una serie de estados. El compresor deja

50 un estado de compresión más bajo y entra en un estado de compresión más alto cuando tiene suficiente confianza que el descompresor ha recibido alguna información.

En el caso de compresión de encabezamientos RTP, los estados son estados de Encabezamiento Completo, Primer Orden y Segundo Orden.

• Estado de Encabezamiento Completo (FH): el compresor entra en este estado cuando el momento de

55 inicialización o cuando aparece algún caso excepcional (bloqueo de CPU o pérdida de memoria). En este estado, el compresor transmite esencialmente información de encabezamiento FH al descompresor. Un encabezamiento FH contiene el conjunto completo de todos los campos de encabezamiento, más alguna información adicional. Esta información puede incluir datos específicos de compresor/descompresor, tales como el CID (Identificador de Contexto, usado para discriminar múltiples flujos). El compresor permanece en este estado hasta que ha adquirido suficiente confianza que el descompresor ha recibido la información del encabezamiento FH. Los paquetes FH son los menos óptimos para transmitir debido a su gran tamaño (por ejemplo, al menos 40 bytes para IPv4, 60 bytes para IPv6). El compresor deja este estado y entra en el estado

5 FO cuando tiene suficiente confianza que el descompresor ha recibido correctamente un encabezamiento FH. Esa confianza puede venir, por ejemplo, de la recepción de un ACK desde el descompresor o enviando un número predefinido de FH.

• Estado de Primer Orden (FO): el compresor entra en este estado cuando se inicia una nueva cadena, después de que ha dejado el estado FH. En este estado, el compresor transmite esencialmente información de encabezamiento FO. Un encabezamiento FO contiene campos específicos de compresor/descompresor, y alguna información que describe cambios irregulares que han ocurrido en los campos variables esenciales. El compresor permanece en este estado hasta que ha adquirido suficiente confianza que la información de encabezamiento FO se ha recibido por el descompresor. Esa confianza puede venir, por ejemplo, de la recepción de Acuses de recibo desde el descompresor o enviando un número predefinido de FO.

15 • Estado de Segundo Orden (SO): el compresor está en este estado cuando el encabezamiento a comprimir se ajusta al patrón de una cadena, y el compresor está suficientemente confiado que el descompresor ha adquirido el patrón de cadena. En este estado, el compresor transmite encabezamientos SO. Un encabezamiento SO contiene esencialmente solo un número de secuencia. El modo preferido de funcionamiento para el compresor/descompresor es transmisión/recepción de paquetes SO, debido a su mínimo tamaño (en el orden de solo unos pocos bits).

En resumen, una sesión inicia con el compresor en el estado FH. En esa fase, el compresor envía un encabezamiento completo al descompresor para establecer un contexto en el descompresor. Esto inicia una cadena. El compresor a continuación entra en los estados FO o SO. En el estado FO, envía la información de actualización de campos variables esencial necesaria al descompresor. En el estado SO, envía información

25 mínima al descompresor. El descompresor hace una extrapolación simple en base a la información intercambiada en los paquetes FH y SO previos hasta que la cadena finaliza. Cuando se inicia otra cadena, el compresor entra el estado FO de nuevo y el procedimiento se repite.

Los modos de transmisión bidireccional utilizan acuses de recibo para diversas funciones:

•

para informar al compresor que se ha recibido información FH; en ese caso, el compresor sabe que el descompresor ha adquirido la información necesaria para descomprimir encabezamientos FO y, por lo tanto, el compresor puede transicionar fiablemente al estado de compresión más alto, FO; este tipo de ACK se denomina como FH-ACK.

•

para informar al compresor que se ha recibido información FO; en ese caso, el compresor sabe que el descompresor ha adquirido la información necesaria para descomprimir encabezamientos SO y, por lo tanto, el

35 compresor puede transicionar fiablemente al estado de compresión más alto, SO; este tipo de ACK se denomina como FO-ACK.

• para informar al compresor que se ha recibido un encabezamiento con un número n específico; en ese caso, el compresor sabe que el descompresor puede determinar el número de secuencia sin ninguna ambigüedad causada por la vuelta a cero del contador hasta el número de encabezamiento n + sec_ciclo, donde sec_ciclo es el ciclo de contador; el compresor puede usar fiablemente k bits para el número de secuencia del encabezamiento, sin preocupaciones de número de secuencia incorrectos o ambiguos que se decodifican en el descompresor, este tipo de ACK se denomina SO-ACK.

El control de transición de los estados FH a FO a SO mediante Acuses de recibo asegura que no hay propagación de errores. Es decir, un encabezamiento comprimido que no se recibe con error se puede descomprimir siempre

45 correctamente, debido a que nunca se pierde sincronización.

Hay mucha flexibilidad con respecto a cuándo y cómo de a menudo el descompresor envía los acuses de recibo. ACE es también extremadamente resistente a que los ACK se pierdan o retrasen. El compresor adapta constantemente su estrategia de compresión en base a la información actual que se comprime y los ACK recibidos. Por ejemplo, la pérdida o retardo de un FO-ACK puede dar como resultado en el compresor permanecer más tiempo en el estado FO. La pérdida o retardo de un SO-ACK puede dar como resultado en el compresor que envíe más bits por el número de secuencia, para prevenir cualquier descompresión incorrecta en el descompresor causada por la vuelta a cero del contador.

Los ACK se pueden transmitir periódicamente o no periódicamente. La frecuencia de los acuses de recibo no periódicos se puede reducir o aumentar a partir de una tasa periódica. Se puede enviar un ACK menos

55 frecuentemente debido a que se pierden Ack debido a errores o congestión de red, o no se pueden transmitir ACK debido la disponibilidad intermitente del canal inverso o a algunas condiciones del descompresor. Se puede transmitir también un ACK más estrechamente espaciado que un ACK periódico tradicional. Por ejemplo, cuando el canal inverso está muy ligeramente cargado y disponible, el descompresor puede transmitir ACK más a menudo y como un resultado el compresor puede funcionar más eficazmente y fiablemente.

Por consiguiente, el canal de retroalimentación utilizado para transmitir los ACK puede tener requisitos muy débiles.

Esto se debe a que los ACK únicamente tienen un efecto en la eficacia de compresión, no en la corrección. El retardo o pérdida de ACK puede causar que el tamaño de los encabezamientos comprimidos aumente, pero incluso en tales casos el aumento es logarítmico.

En el modo determinístico bidireccional, la transición de FH/FO a FO/SO está basada en acuse de recibo. En el

5 modo unidireccional, nunca se envía un ACK, por lo que el número de paquetes FH/FO que se envían antes de la transición al estado FO/SO depende de un valor seleccionado dinámicamente/adaptablemente o un valor predefinido. En el modo oportunístico bidireccional, el ACK puede retrasarse, por lo que la transición de FH/FO a FO/SO no es está basada estrictamente en ACK, sino que depende de cualquiera que venga primero de 1) transmisión de un número seleccionado dinámicamente/adaptablemente o predefinido de FH/FO, o 2) recepción de

10 al menos un ACK.

En resumen, el número de paquetes FO/FH a enviar antes de conmutar al estado FO/SO depende de si se requiere un ACK antes de conmutar y/o un parámetro m ajustable que puede ser predefinido o seleccionado dinámicamente/adaptablemente. Se analizan cuatro casos a continuación.

La Figura 15 ilustra conmutación del estado de compresión del compresor en base a únicamente en la llegada de un

15 ACK apropiado. Se transmite una secuencia de al menos un encabezamiento de un estado particular que, como se ilustra sin limitación son encabezamientos FH o FO, al descompresor. El descompresor, tras recibir el primer encabezamiento FH(n) o FO(n) (podría ser un encabezamiento distinto del primer encabezamiento) transmite de vuelta un Ack(n) que, tras la recepción, causa que el compresor transicione en un estado de compresión más alto, como se ilustra, es FO(N+i+1) o SO(n+i+1) que es el paquete transmitido inmediatamente después de la recepción

20 de ACK(n).

Las Figuras 16 y 17 ilustran conmutación del estado de compresión del compresor en base a un parámetro m que es un número de encabezamientos transmitidos o ACK (conmutación de acceso siempre que se transmiten m encabezamientos FO/FH o se recibe ACK). La realización de la Figura 16 no está limitada a transmisión de encabezamientos FH/FO/SO por el compresor. En la Figura 16, llega un ACK(n) antes de que el número de

25 encabezamientos FO/FH transmitidos alcanza m, que como el resultado del número preestablecido de encabezamientos FH/FO que se transmiten, causa al compresor conmutar a un estado más alto de compresión y transmitir paquetes FO(n+i) o SO(n+i). La realización de la Figura 17 no está limitada a transmisión de encabezamientos FH/FO/SO por el compresor. En la Figura 17, llega un ACK después de que se transmiten m encabezamientos.

30 La Figura 18 ilustra la conmutación del estado de compresión del compresor que ocurre después de que se envían un conjunto de número de encabezamientos sin ningún acuse de recibo.

Bajo diferentes modos, la estrategia de funcionamiento del compresor y descompresor son diferentes.

Modos de funcionamiento del compresor

• Estrictamente basado en ACK: en este modo, el compresor depende estrictamente en la recepción de los ACK.

35 Si un ACK no ha llegado a tiempo debido a pérdida, disponibilidad de canal, condiciones de descompresor, etc., el compresor conmuta a un modo comprimido menor mediante por ejemplo aumentando el tamaño de los campos de codificación, y únicamente se puede volver a conmutar a un modo comprimido mayor después de que recibe ACK apropiados.

• Débilmente basado en ACK: en este modo, ACK ayuda a mejorar la eficacia y fiabilidad cuando se recibe, pero

40 el compresor no depende estrictamente de la recepción de los ACK. Si el compresor recibe un ACK apropiado, conmuta de un estado menos comprimido a un estado más comprimido o permanece en el estado actual si ya está en el estado más comprimido. Si no ha recibido un ACK apropiado, conmuta de un estado menos comprimido a un estado más comprimido en base a otros criterios, por ejemplo, enviando un cierto número de encabezamientos menos comprimidos, en lugar de la recepción de ACK.

45 • No basado en ACK: el compresor funciona normalmente en este modo cuando no está disponible canal inverso. En este modo, el criterio de transición de un estado menos comprimido a un estado más comprimido no está basado en ACK. En cambio, el compresor puede conmutar de un estado menos comprimido a un estado más comprimido después de que se hayan transmitido un cierto número de encabezamientos menos comprimidos. Tal número puede ser un parámetro ajustable. Además, hay eventos que pueden activar el

50 compresor para enviar información menos comprimida para refrescar al descompresor y reducir la posibilidad de descompresión incorrecta.

Modos de funcionamiento del descompresor

• Enviar ACK determinístico: en este modo, el descompresor envía periódicamente ACK y cuando recibe

paquetes FH/FO. Además, el descompresor puede enviar ACK de vuelta al compresor más frecuentemente 55 que periódicamente cuando el canal inverso está ligeramente cargado y disponible.

• Enviar ACK oportunístico: en este modo, el descompresor no envía estrictamente AKC periódicamente. Envía

ACK únicamente cuando tiene una oportunidad para enviar un ACK, por ejemplo, cuando el canal inverso está disponible para llevar el ACK.

• No ACK: en este modo, el compresor no envía ACK en absoluto.

Una aplicación de ejemplo donde el esquema de compresión y descompresión de encabezamientos es útil es donde se transmiten paquetes de Voz sobre IP (VoIP) (o telefonía IP) sobre sistemas celulares. Cuando se aplica VoIP a sistemas celulares, es importante minimizar la tara del encabezamiento IP/LUDP/RTP debido al ancho de banda limitado de la interfaz inalámbrica o aérea (RF). En un sistema tal por ejemplo, las ANI_AD interrelaciona la red IP con un terminal de ordenador que ejecuta RTP/UDP/IP (por ejemplo, el terminal 130) que tiene una interfaz RF o celular para recibir paquetes RTP sobre el enlace inalámbrico o RF. Esto es meramente una aplicación de ejemplo de la técnica de compresión/descompresión de la presente invención.

Definiciones

n: número de secuencia asignado por el compresor y llevado en los encabezamientos. El número n siempre incrementa en 1 por cada nuevo paquete e independientemente del número de secuencia RTP. Obsérvese que n se puede codificar en k-bits ( = (CD_SN)k ) o f bits extendidos ( = (CD_SN)f_extendido ).

CD_SN 139: contador interno que corresponde a n. El compresor y descompresor mantienen sus contadores. El tamaño de los contadores internos se puede elegir suficientemente grande para evitar cualquier ambigüedad por la duración de la sesión, por ejemplo, 32 bits.

(CD_SN)k: k bits menos significativos de CD_SN. (CD_SN)k se envía normalmente en el encabezamiento comprimido.

(CD_SN)f_extendido: f_extendido bits menos significativos de CD_SN. (CD_SN)f_extendido se envía en el encabezamiento comprimido en el modo extendido.

S_RFH: CD_SN del paquete cuyo encabezamiento se conoce para reconstruirse correctamente por el descompresor; S_RFH se actualiza continuamente por el compresor en base a la retroalimentación del descompresor. S_RFH se envía en la forma de k o f_extendido bits menos significativos.

N_elapsed: un contador mantenido por el compresor para seguir la pista del número de paquetes que se han enviado desde el último paquete que se realizó ACK. N_elapsed = CD_SN actual - S_RFH, si S_RFH se establece siempre igual al último paquete que se realizó ACK por el compresor cuando recibe un ACK. R_RFH: CD_SN de paquete de referencia en el descompresor, que se establece igual a S_RFH cuando se recibe un paquete FO(n, S_RFH).

SN(n): el número de secuencia RTP del enésimo paquete enviado por el compresor. Si el compresor no hace reordenación, SN(n) no es necesariamente una secuencia monotónicamente creciente en la que n se define por valores de bit de los k o f bits extendidos.

TS(n): la indicación de tiempo RTP del enésimo paquete enviado por compresión.

CFO(n): diferencia de primer orden actual en el paquete n. Obsérvese que es un vector, con cada uno de sus componentes individuales igual a la diferencia entre el campo correspondiente en el paquete n y en el paquete (n-1); por ejemplo, el componente de indicación de tiempo de CFO(n) se calcula como TS(n) - TS(n-1).

FO_DIFF(n2, n1): diferencia de primer orden en el paquete n2, con respecto al paquete n1. Cada uno de sus campos individuales es igual a la diferencia entre el campo correspondiente en el paquete n2 y en el paquete n1; por ejemplo, el campo de indicación de tiempo de FO_DIFF(n2, n1) se calcula como TS(n2) - TS(n1).

N_Last_Interr: el CD_SN correspondiente a la interrupción más reciente (es decir, cambio no lineal). Se actualiza (por el compresor) a n siempre que CFO(n) != CFO(n-1). S_DFOD: diferencia de primer orden por defecto en el emisor. S_DFOD es un vector que especifica el patrón actual. S_DOD se usa por el compresor para determinar si el encabezamiento actual se ajusta al patrón. El encabezamiento n actual se ajusta al patrón si el encabezamiento(n) = encabezamiento(n-1) + S_DFOD. Cuando el patrón no cambia de una cadena a la siguiente, S_DFOD es estático. De otra manera, el compresor tiene que determinar S_DFOD de una manera dinámica.

TS_DFOD y SN_DFOD: los componentes en S_DFOD que corresponden a indicación de tiempo RTP y número de secuencia, respectivamente.

R_DFOD: diferencia de primer orden por defecto en el compresor. R_DFOD es un vector que especifica el patrón actual. R_DOD se usa por el descompresor para descomprimir encabezamientos SO. Cuando el patrón no cambia de una cadena a la siguiente, R_DFOD es estático. De otra manera, el descompresor tiene que determinar R_DFOD de una manera dinámica. Por diseño, S_DFOD y R_DFOD son siempre iguales durante el estado SO.

Extended_flag: un indicador mantenido por el compresor. Si es VERDADERO, entonces se usan f bits extendidos por el CD_SN y se enviarán otros parámetros de secuencia en los encabezamientos. De otra manera, se enviará

(CD_SN)k. Obsérvese que este indicador en sí mismo se lleva también en los encabezamientos de modo el descompresor sabe qué codificación CD_SN se usa.

Encabezamiento(n): un término usado genéricamente para significar la información de encabezamiento enviada por el compresor. Encabezamiento(n) se puede enviar de diversas formas, FH(n), FO(n, S_RFH), SO(n), dependiendo del estado del compresor. Obsérvese que en el encabezamiento, n se codifica realmente como (CD_SN)k o (CD_SN)f_extendido, dependiendo del indicador extendido.

Diff(n2, n1): la verdadera distancia entre n2 y n1, que se codifica como (CD_SN)k o (CD_SN)f_extendido. Diff (n2, n1) = CD_SN(n2) - CD_SN(ni), donde CD_SN(n2) y CD_SN(n1) son los CD_SN correspondientes a n2 y n, respectivamente. Por ejemplo, si el primer paquete lleva (CD_SN)k = 14 y el segundo lleva (CD_SN)k = 1, entonces la verdadera distancia es (16 + 1 - 14) = 3, no (1 -14) = -13.

FH_Req: enviado por el descompresor para solicitar al compresor que funcione en el estado FH. Esto se usa por ejemplo cuando el descompresor acaba de recuperarse de un bloqueo y ya no tiene información de estado fiable.

ACK(n): enviado en respuesta al encabezamiento(n). Un ACK significa que el paquete(n) se recibió correctamente. Sec_ciclo: Sec_ciclo-1 es el número máximo alcanzado por el número de secuencia antes de vuelta a cero y volver a 0. Sec_ciclo = 2k.

SEC Ext_ciclo: = 2 f_extendido .

HSW 117: el compresor mantiene una ventana deslizante de los encabezamientos enviados al descompresor (HSW): encabezamiento (n), encabezamiento (n+1), encabezamiento (n+2), etc. Los encabezamientos se pueden haber enviado en la forma de FH, FO o SO. Cuando el compresor recibe un ACK(n), borrará cualquier Encabezamiento(p) donde p <n2-n1 y también mueve el Encabezamiento(p=n) al Encabezamiento(S_RFH). Los campos estáticos no se necesitan almacenar como múltiples entradas en HSW. Únicamente se necesita una sola copia de los campos estáticos. Obsérvese que en HSW, se marca cada encabezamiento con un color, verde o rojo.

Color de un encabezamiento (paquete): es verde si el CD_SN llevado en el encabezamiento (paquete) se codifica en k bits. De otra manera, es rojo, por ejemplo f bits extendidos. En la implementación se puede usar un indicador de 1bit para almacenar el color. El color se usa para ayudar al compresor a identificar únicamente un encabezamiento cuando recibe un ACK.

OAW 135: el descompresor mantiene una ventana deslizante de los encabezamientos que ha descomprimido y realizado ACK satisfactoriamente: encabezamiento (n1), encabezamiento (n2), encabezamiento (n3). Obsérvese que los ACK no se sabe a ciencia cierta que se recibirán por el compresor. La ventana se referirá como la ventana de anticipación Ack (OAW). Los campos estáticos no se necesitan almacenar como múltiples entradas en OAW. Únicamente se necesita una sola copia de los campos estáticos.

R_Last_Decomp: el CD_SN del último paquete reconstruido por el descompresor. El descompresor mantiene el encabezamiento completo correspondiente que se denomina como FH(Last_Decomp). Obsérvese:

Se transfieren los encabezamientos IP, UDP y RTP originales excepto por los cambios descritos a continuación.

•

El campo de Tamaño Total del encabezamiento IP (2 bytes) se reemplaza con extended_flag (1 bit), sec_num (4 u 8 bits), y otra información opcional. Si el indicador extendido es igual a 1, sec_num es de 8-bit de tamaño, es decir, se envía el paquete en modo extendido.

•

El campo de Tamaño en el encabezamiento UDP (2 bytes) se reemplaza también con el contexto ID para compresión de encabezamiento, denominado CID. El compresor puede comprimir simultáneamente múltiples flujos RTP independientes entre sí. Se asigna cada flujo a un único CID. En la implementación, CID puede ser de 1-byte o 2-bytes de longitud, dependiendo del número máximo de flujos RTP en cualquier momento dado.

Una primera realización de la invención, que se puede practicar con el sistema de la Figura 2, está basada en campos IP/UDP/RTP que son la mayoría del tiempo constantes o se pueden extrapolar de una manera lineal. En estos casos, el encabezamiento comprimido solo lleva un número de secuencia no extendido múltiple que tiene k bits que proporciona suficiente información para extrapolación lineal. Al igual que en el documento RFC 2508 con la invención cuando la extrapolación lineal da como resultado reconstrucción de encabezamientos incorrecta, el transmisor envía información de diferencia FO. A diferencia del documento RFC 2508, la información de diferencia se calcula con respecto al paquete de referencia que se sabe que se recibió correctamente, en lugar de el inmediatamente anterior al paquete actual. Esta característica asegura que el encabezamiento actual se puede reconstruir fiablemente incluso si se perdieron uno o más paquetes pasados. Puesto que el encabezamiento se puede reconstruir fiablemente de esta manera, no es necesario enviar un encabezamiento completo. Se determina y actualiza la referencia mediante el compresor del receptor de acuerdo con los acuses de recibo recibidos desde el descompresor.

El compresor usa como un encabezamiento de referencia un encabezamiento que se sabe que se descomprimió

correctamente en base a los acuses de recibo recibidos (ACK) como se ilustra en general en la Figura 6. El compresor envía unas series de paquetes de encabezamientos completos FH(n)…FH(n+i+1)… que cubren una secuencia de tiempo justo anterior a t2 momento en el que se recibe el acuse de recibo ACK(n) producido por el compresor que recibe el paquete de encabezamiento completo FH(n). La transición de FH a FO (FO(n+j) como se ilustra) es síncrona. La secuencia de tiempo a t2 depende del tiempo de ida y vuelta de la transmisión de radio.

La Figura 7 ilustra la transición del compresor a partir de transmitir paquetes de primer orden FO (FO(n), a FO (n+i+1)… con al menos un acuse de recibo ACK(n) y opcionalmente ACK(n+1) que se generan por el descompresor antes de que el compresor transicione sincrónicamente a los paquetes de segundo orden SO (SOn+j) con un retardo de radio de ida y vuelta al momento t2 requerido para sincronización. El número de ACK requeridos por el compresor antes de transicionar del estado FO al estado SO depende de las variaciones entre paquetes. Por ejemplo, si la variación entre paquetes es lineal con parámetros constantes, únicamente se requiere un ACK para transicionar del estado FO al estado SO. Para poder descomprimir el encabezamiento actual, el descompresor únicamente necesita conocer el encabezamiento de referencia en lugar del encabezamiento inmediatamente anterior como en el documento RFC 2508. En este esquema, el compresor envía encabezamientos completos (encabezamientos de tipo FH) en la inicialización. Envía información de diferencia de primer orden (encabezamientos de tipo FO) cuando no se aplica extrapolación lineal. Sin embargo, el compresor no transmite encabezamientos de diferencia SO hasta que se ha realizado acuse de recibo del FH o FO anterior, y se aplica extrapolación lineal.

En el compresor, se define el paquete de referencia como el último cuyo ACK se ha recibido. Específicamente, cuando el transmisor recibe ACK(n), un acuse de recibo para el paquete n, recuperará el paquete n previamente almacenado en memoria y lo grabará como el paquete de referencia (el paquete n se almacenó en memoria cuando se envió). Posteriormente, toda la compresión de encabezamientos se realiza con referencia a ese paquete, hasta que se recibe un nuevo ACK, punto en el cual el paquete que se acaba de realizar ACK se convierte en el nuevo paquete de referencia. La memoria en el transmisor donde se almacenan los paquetes de referencia potenciales se denomina como la ventana de envío de encabezamiento (HSW) representada como la entidad 117 en la Figura 2. Si una información de diferencia FO tiene que enviarse en el encabezamiento comprimido, el compresor incluirá explícitamente el número de secuencia del paquete de referencia (número de secuencia de referencia).

En el descompresor, cuando se envía un ACK(n), el encabezamiento(n) se almacena en la ventana de anticipación de acuse de recibo (OAW) representada como la entidad 135 de la Figura 2. Posteriormente, cuando se recibe un encabezamiento de diferencia FO, el descompresor determinará el paquete de referencia a partir del número de secuencia de referencia, recupera el paquete de referencia correspondiente de la OAW 135 y lo usa para reconstruir el encabezamiento completo.

La invención usa la linealidad de las indicaciones de tiempo RTP generadas en el compresor que siguen estrechamente un patrón lineal como una función de la hora del día. En base al temporizador 134 mantenido en el descompresor del receptor y usando un número de secuencia extendido para paquetes FO definidos por f bits extendidos, se puede detectar y recuperar toda una gran pérdida dentro de un umbral.

Suponiendo una conversación, si el intervalo de tiempo entre muestras de conversación y paquetes consecutivos es t ms, entonces la indicación de tiempo RTP del encabezamiento n (generada en el momento n* t ms) es igual a la indicación de tiempo RTP del encabezamiento 0 (generada en el momento 0) más TS_stride * n, donde TS_stride es una constante que depende un códec de voz de la fuente de voz del transmisor. Por consiguiente, la indicación de tiempo RTP en los encabezamientos recibidos por el descompresor sigue un patrón lineal como una función del tiempo, pero menos estrechamente que el compresor, debido a la fluctuación de fase del retardo entre el compresor y el descompresor. En funcionamiento normal (ausencia de bloqueos o fallos), se limita la fluctuación de fase del retardo, para cumplir los requisitos del tráfico conversacional en tiempo real.

Aparece una cadena como una secuencia de encabezamientos que todos se ajustan a un patrón particular. Específicamente, el número de secuencia RTP (SN) se incrementa en I de un encabezamiento al siguiente. La indicación de tiempo RTP (TS) no se disminuye, y sigue algún patrón predecible: si los encabezamientos n1 y n2 están en la misma cadena, el TS del encabezamiento n2 se puede derivar del TS del encabezamiento n1 y la función de patrón. Los otros valores de campo, excepto quizás para suma de control de UDP e Id de IP, no cambian en la cadena. Por lo tanto, una vez que un encabezamiento, por ejemplo n1 ha sido descomprimido correctamente, los encabezamientos posteriores en la misma cadena se pueden descomprimir por extrapolación de acuerdo con el patrón. Una vez que el compresor determina que un encabezamiento se ha descomprimido satisfactoriamente, y el patrón obtenido por el descompresor, solamente tiene que enviar un k-bit número de secuencia, denominado (CD_SN)k, como un encabezamiento comprimido para los paquetes posteriores en la misma cadena. (CD_SN)k son los k bits menos significativos de un número de secuencia de descompresor (compresor) mayor (CD_SN).

En este esquema, el descompresor usa el temporizador 134 u otro temporizador no ilustrado en la Figura 2 para obtener el tiempo transcurrido entre dos paquetes recibidos consecutivamente. En base a tal información de temporización y la regla de compresión particular que se usa por el compresor junto con el número de secuencia, el descompresor puede detectar y/o recuperar la gran pérdida.

Sea

•

HDR(i) el encabezamiento con número i de secuencia corta

•

HDR(n1) el último encabezamiento que se ha descomprimido satisfactoriamente

•

HDR(n2) el encabezamiento que se ha recibido justo después de HDR(n1)

•

TS_stride el incremento RTP TS cada t ms

•

SEC_CICLO el ciclo de número de secuencia usado en HDR

•

DIFF(n2, n1) la diferencia entre paquetes con número de secuencia n2 y n1.

Se define como sigue:

•

DIFF(n2,n1) = n1 cuando n2>n1

•

DIFF(n2, n1) = n2+2k-n1 cuando n2≤ni

Tras recibir HDR(n2) justo después de recibir HDR(n1), el descompresor determina si ha ocurrido o no una gran pérdida entre estos dos paquetes, es decir, si hay o no DIFF(n2, n1) paquetes perdidos o hay SEC_CICLO * p + DIFF(n2, n1) (p>1) paquetes perdidos. El esquema de detección también se basa en el tipo de HDR(n2). En base a los tres tipos de encabezamientos definidos en los esquemas de compresión de encabezamientos, se enumeran 2 casos como sigue.

Caso 1: HDR(n1), SO(n2)

Caso 2: HDR(n1), FO(n2)

Detección y recuperación de grandes pérdidas para el Caso 1

Para detectar si hay o no grandes pérdidas en el caso 1, se mantiene un temporizador (por ejemplo el temporizador 134) en el compresor, y se comprueba y actualiza siempre que se recibe un paquete. Sea

•

T el momento cuando se recibe HDR(n1)

•

T+ΔT el momento cuando se recibe HDR(n2)

El compresor envía paquetes SO únicamente si el uno o más paquetes FH o FO anteriores se les ha realizado acuse de recibo, y se aplica también extrapolación lineal a partir del encabezamiento al que realizó acuse de recibo. Por lo tanto, si HDR(n2) es SO y no importa de qué tipo es HDR(n1), se aplica extrapolación lineal desde HDR(n1) hasta HDR(n2). Esto significa básicamente que la indicación de tiempo RTP y el número de secuencia RTP para el paquete n1 hasta n2 cuando se generaron en el compresor, siguen estrechamente un patrón lineal como una función de la hora del día. Por consiguiente, los encabezamientos que van al descompresor también siguen un patrón lineal como una función del tiempo, pero con fluctuación debido a la fluctuación de fase entre transmisor y receptor.

Bajo la suposición de que el límite superior de fluctuación de fase es siempre menor que (SEC_CICLO * t) ms, se aplica la siguiente regla para detectar grandes pérdidas:

[Regla 1]

•

si (DIFF(n2,n1) * t ms. ≤ΔT < (DIFF(n2,n1) + SEC_CICLO) * t ms ), únicamente se pierden DIFF(n2,n1) paquetes;

•

si ((DIFF(n2,n1) + SEC_CICLO) * t ms ≤ΔT < (DIFF(n2,n1) + 2 * SEC_CICLO) * t ms ), se pierden (SEC_CICLO

+ DIFF (n2,n1)) paquetes;

•

En general, si ((DIFF(n2,n1) + i* SEC_CICLO) * t ms ≤ΔT < (DIFF(n2,n1) + (i +1) * SEC_CICLO) * t ms ), se pierden (i *SEC_CICLO + DIFF(n2,n1)) paquetes;

Para recuperar la indicación de tiempo RTP y el número de secuencia RTP de tal gran pérdida, únicamente se necesita el número de paquetes perdidos.

Sea

•

Nperdidos el número de paquetes perdidos entre el paquete n1 y el paquete n2 que se puede obtener en base a la regla 1

•

TS(i) y SEC(i) son la indicación de tiempo RTP y el número de secuencia RTP del paquete i

La indicación de tiempo RTP y el número de secuencia RTP se pueden derivar mediante la indicación de tiempo RTP y el número de secuencia RTP del paquete n1 así como Nperdidos que se muestran en la siguiente fórmula.

La Figura 8 ilustra una realización de la invención que detecta y recupera de grandes pérdidas en el caso 1 para detectar grandes pérdidas cuando aparece una vuelta a cero en la pérdida donde se pierden más paquetes que 2k en el que k es el número de bits en el número de secuencia SN(n) de los paquetes. Suponiendo que el descompresor recibe HDR(n) que se envió en el momento t0, y se han perdido todos los paquetes enviados entre t1 a t3, y a continuación el descompresor recibe SO(n+1) que se envió en el momento t3. Puesto que el paquete n+1 enviado en el momento t3 es un paquete SO que indica que todos los paquetes enviados desde t0 a t3 cayeron en la misma cadena, es decir el número de secuencia RTP Sn(n) de estos paquetes sigue un patrón lineal como una función del tiempo de la hora del día, se puede detectar el número de paquetes perdidos entre t0 y t3 mediante el temporizador 134 mantenido en el descompresor. El procedimiento es como sigue:

Suponiendo que el intervalo de tiempo entre muestras de conversación y paquetes consecutivos es t ms., el descompresor inicia su temporizador 134 local (con valor ts) cuando recibe HDR(n) enviado en el momento t0, a continuación el temporizador aumenta en base al reloj diario. Cuando se recibe SO(n+1) enviado en el momento t3 en el descompresor, el temporizador alcanzaría lo que aproximadamente es igual a ts+(2k+1)t debido a la fluctuación de fase. Puesto que la diferencia temporal entre ts y te (aproximadamente (2k+1)t) es mayor que t ms., el paquete n enviado en el momento t0 y el paquete n+1 enviado en momento t3 no serán paquetes enviados consecutivamente y ocurre una gran pérdida entre estos dos paquetes. Además, puesto que la diferencia temporal entre ts y te es menor que (2k+1+1)t, no habrá más de un ciclo de secuencia de pérdida de paquetes. Por lo tanto, el descompresor puede concluir que hay 2k paquetes perdidos.

Detección y recuperación de grandes pérdidas para el Caso 2

El esquema de detección y recuperación de grandes pérdidas no se puede aplicar al caso 2 donde se recibe el encabezamiento FO después de un encabezamiento SO, FO o FH. En este caso, incluso si la diferencia temporal Δt entre el paquete n2 y n1 es mayor que (DIFF (n2,n1) + SEC_CICLO) * t ms, no significa que ocurrió una gran pérdida porque puede ser debido al periodo de silencio del compresor. En este caso, en base a la información proporcionada en el encabezamiento FO, se puede regenerar el RTP TS satisfactoriamente, pero no el número de secuencia RTP debido a que no se puede distinguir solamente la gran pérdida o el silencio en base a la temporización. Para resolver este problema, se usa un número de secuencia extendido que tiene f bits extendidos (f_extendido>k bits no extendido) para los primeros paquetes FO en unas series FO donde todos los paquetes pertenecen a la misma cadena, hasta que hay un ACK por FO enviado de vuelta desde el descompresor. Este esquema detecta y recupera de grandes pérdidas bajo la suposición que el límite superior de la gran pérdida es menor que 2f_extendido * t ms.

Para implementar este esquema, se mantiene un contador interno CD_SN 139 para paquetes mediante el compresor. El CD_SN 139 cuenta cada paquete enviado desde el compresor del transmisor. El número de secuencia enviado en el encabezamiento completo modificado y el encabezamiento comprimido es solo una instantánea de los f_extendido bits menos significativos o k no extendido del CD_SN 139. En base a la regla del esquema de compresión/descompresión de encabezamientos, el descompresor puede reconstruir el número absoluto actual de paquetes recibidos.

Sea

CD_SN_LAST el número absoluto de paquetes del último paquete recibido, es decir, paquete n,; CD_SN_CURR el número absoluto de secuencia para el paquete FO actual, es decir, paquete n2; y DIFF(CD_SN_CURR, CD_SN_LAST) se define como (CD_SN_CURR)-(CD_SN_LAST). En base a la siguiente regla, se puede detectar una gran pérdida en el límite superior de 2f_extendido * t ms satisfactoriamente.

[Regla 2]

Si (DIFF(CD_SN_CURR, CD_SN_LAST) > 2k, se detecta una gran pérdida.

Se puede calcular el número de paquetes perdidos Nperdidos con la siguiente fórmula:

En base a Nperdidos, se puede regenerar el número de secuencia RTP mediante el descompresor bajo las siguientes fórmulas y se puede regenerar la indicación de tiempo RTP en base al encabezamiento de referencia y el delta correspondiente.

Puesto que el número de secuencia extendido usa más ancho de banda que el número de secuencia normal en vista de su mayor número de bits, no se sugiere usarlo frecuentemente, sino solo para los primeros paquetes FO hasta que vuelve al compresor el ACK para estas series de FO.

Debe tenerse en cuenta que este esquema no puede detectar y recuperarse de grandes pérdidas que son mayores que 2f_extendido * t ms; por lo tanto, se debería seleccionar f_extendido cuidadosamente de modo que pueda detectar la gran pérdida que no se puede indicar a partir de la capa inferior de la pila de protocolos. Si la gran pérdida es mayor que 2f_extendido * t ms, se requiere que una capa inferior pueda proporcionar indicación de tal pérdida extremadamente grande y se aplica desconexión en la capa inferior u otros procedimientos de recuperación de grandes pérdidas, por ejemplo enviar una solicitud al compresor.

Cuando el compresor necesita enviar una serie de paquetes de tipo FO donde todos los paquetes pertenecen a la misma cadena, usa número de secuencia con f_bits extendidos hasta que vuelve al menos un ACK para esta serie de paquetes desde el descompresor. Pero cuando se necesita enviar un paquete SO, el compresor solo usa un número k-bit de secuencia.

En el compresor, se inicia el temporizador 134 (u otro temporizador no ilustrado en la Figura 2) siempre que llega un paquete. El temporizador se ejecuta hasta que llega el siguiente paquete. Si el paquete entrante es de tipo FH, no se necesita información de temporización y se debe resetear el temporizador.

Si el paquete entrante es de tipo FO, se aplica la regla 2 para comprobar si ha ocurrido o no una gran pérdida y el esquema de recuperación correspondiente para transmisión de paquetes FO debe…

Una realización adicional de la invención, practicada con el sistema de la Figura 2, usa el hecho que los campos IP/UDP/RTP son constantes o se pueden extrapolar a partir de un patrón predecible. En estos casos, el encabezamiento comprimido solo lleva un número de secuencia no extendido que tiene k bits que proporcionan información suficiente para extrapolación. Cuando la extrapolación da como resultado descompresión incorrecta para uno o más campos, el compresor envía la información adicional requerida para esos campos (información de actualización).

Para proporcionar robustez para errores y ráfagas de errores, el compresor codifica la información de actualización con respecto a un encabezamiento de referencia conocido que se descomprime correctamente. El compresor sabe que un encabezamiento se descomprime correctamente cuando recibe el acuse de recibo correspondiente. Un mecanismo ACK asegura que el encabezamiento actual se puede reconstruir fiablemente incluso si se perdieron uno

o más encabezamientos pasados.

Una cadena se define como una secuencia de encabezamientos que se ajustan todos a un patrón particular. El número de secuencia RTP (SN) se incrementa en 1 de un encabezamiento al siguiente. La indicación de tiempo RTP (TS) no se disminuye, y sigue algún patrón predecible. Si los encabezamientos n1 y n2 están en la misma cadena, se puede derivar el TS del encabezamiento n2 a partir del producto del desplazamiento del número de secuencia p entre n2 y n1 y TS y la función de patrón. Los otros valores de campo, excepto quizás para una suma de control de UDP e Id de IP, no cambian en la cadena. Por lo tanto, una vez que se ha descomprimido un encabezamiento n1 correctamente, se pueden descomprimir los siguientes encabezamientos en la misma cadena por extrapolación de acuerdo con el patrón. Una vez que se informa al compresor que se ha descomprimido un encabezamiento satisfactoriamente, y se ha adquirido el patrón mediante el descompresor (como se muestra por los ACK), solamente envía un número de secuencia, como un encabezamiento comprimido para los siguientes paquetes en la misma cadena.

En el caso de voz, el TS tiene un patrón de incremento lineal. Por lo tanto se puede calcular el TS del encabezamiento (n2) como: TS(n2) = TS(n1) + TS_stride * p, donde TS_stride es el incremento de la indicación de tiempo entre dos encabezamientos consecutivos y p es el desplazamiento del número de secuencia entre los paquetes n2 y n1. Un intervalo silencioso corta la relación lineal y causa que una cadena termine. Se inicia una nueva cadena con una nueva secuencia hablada.

Por lo tanto, el compresor pasa tres fases diferentes: inicialización, actualización y extrapolación. Se inicia una sesión con una fase de inicialización. En esa fase, el compresor envía encabezamientos completos al descompresor hasta que se recibe un ACK. Después de que se completa la inicialización, cuando se inicia una cadena, el compresor del transmisor entra en una fase de actualización, donde envía la información de actualización necesaria al descompresor. Una vez que el compresor recibe un ACK o unos ACK que indican que el descompresor ha adquirido la información necesaria para realizar la extrapolación, el compresor transiciona a la fase de extrapolación. En la fase de extrapolación, el compresor únicamente envía un número de secuencia como cada encabezamiento comprimido, hasta que se finaliza la cadena. Cuando se inicia otra cadena, el compresor del transmisor entra en otra fase de actualización, y se repite el procedimiento completo. Los encabezamientos enviados en las fases de inicialización, actualización y extrapolación son FH, FO y SO. FH, FO y SO todos llevan un número de secuencia incrementado en 1 en cada encabezamiento enviado por el compresor, SO consiste esencialmente únicamente de ese número de secuencia. A continuación, los ACK enviados en respuesta a FH y FO se denominan ACK FH y ACK FO respectivamente.

Ráfagas de grandes errores y pérdida de sincronización - ACK periódicos

Si se codifica el anterior número de secuencia con k bits, volverá a cero casa sec_ciclo encabezamientos (sec_ciclo = 2k). Por lo tanto, si una ráfaga de errores dura más que la duración de sec_ciclo encabezamientos, el

descompresor no puede determinar sin ambigüedad el número de encabezamientos transcurridos solo a partir del número de secuencia, y por consiguiente no puede realizar descompresión apropiada. Para tratar este problema de vuelta a cero y grandes ráfagas, se usan acuses de recibos periódicos (ACK). La Figura 9 ilustra el funcionamiento de la invención usando los números de secuencia de k bits y números de bit de f bits extendidos en asociación con acuses de recibo periódicos (ACK) que se generan sincrónicamente mediante el descompresor cada 2k paquetes recibidos detectados. Suponiendo que el compresor recibe el ACK(n) para el paquete n antes de que envíe el paquete SO n+i con un número de secuencia k bit, el compresor está esperando otro ACK para el paquete (n+2k+N_RT) del descompresor antes que envíe el paquete (n+i+2k+N_RT). Suponiendo que se pierde el ACK(n+2k+N_RT) durante la transmisión, el compresor se transfiere al estado extendido usando f bits y envía el paquete (n+i+2k+N_RT) con un número de secuencia de bits f extendido. Cuando el descompresor recibe el paquete (n+i+2k+N_RT) con un número de secuencia f extendido, envía un ACK (n+i+2k+N_RT) de vuelta al compresor. Cuando el compresor recibe el ACK(N+1+2k+N_RT), se transfiere de vuelta al estado no extendido, y envía el paquete SO(n+j) con solo un número de secuencia k-bit. El descompresor está esperando para enviar un ACK a intervalos regulares, suficientemente estrechamente espaciados de modo que el compresor recibe un ACK al menos una vez cada 2k sec_ciclo encabezamientos. El compresor mantiene un contador, N_elapsed, para seguir la pista del número de paquetes transcurridos desde el último ACK que recibió. Si N_elapsed >2ksec_ciclo encabezamientos, el compresor funciona en modo extendido, donde se usan f bits extendidos para el número de secuencia, en lugar de un número menor de k bits no extendido, con el número de f bits extendido > el número de k bits no extendido. El número de secuencia f bit extendido y el número reducido de k bits en el número de secuencia no extendido se puede observar como los bits menos significativos del número de secuencia no extendido y siendo f bits extendidos los bits menos significativos del conteo CD_SN 139 del transmisor. Se denominan (CD_SN) k y (CD_SN) f_extendido respectivamente. N_elapsed se incrementará en 1 por cada paquete enviado por el compresor. El número de secuencia SN únicamente disminuye cuando el compresor recibe un ACK desde el descompresor, y permite al compresor conmutar de vuelta al modo normal, es decir usar el número presente de bits menos significativos de CD_SN. Estos ACK se denominan como ACK periódicos. Los ACK pueden no ser periódicos como se describe a continuación cuando, por ejemplo, el canal en el que se envían los ACK está ocupado lo que requiere retrasar el ACK de una manera no periódica.

Para considerar el retardo de ida y vuelta, es necesario que el descompresor del receptor anticipe cuando envía un ACK periódico. El descompresor tiene que enviar un ACK periódico suficientemente pronto de modo que el compresor reciba normalmente ACK al menos una vez cada sec_ciclo. Teniendo en cuenta el tiempo de ida y vuelta, el descompresor tiene que enviar ACK al menos una vez cada (sec_ciclo - N_RT) encabezamientos. Se calcula la cantidad N_RT como EST_RTT/T_H, redondeado hasta el número entero inmediatamente superior. La cantidad EST_RTT es una estimación del retardo de ida y vuelta actual calculada por el descompresor y se puede evaluar dinámicamente en base a mediciones recientes, o simplemente se establece a RTT_n (definido a continuación). En la práctica, T_H se puede derivar a partir de las características de códec del transmisor, o a partir del espaciado real observado.

Supuestos

Para asegurar corrección y conseguir alto rendimiento, necesitan realizarse algunas suposiciones acerca del canal de comunicaciones entre el compresor y el descompresor (CD-CC). El canal puede ser un enlace o una concatenación de enlaces (red o redes).

Los paquetes transferidos a través del canal directo e inverso se pueden perder o corromper, pero se mantienen sus órdenes (es decir, tubería FIFO). La cantidad MAX_EB se define como el número máximo de paquetes consecutivos que se pueden perder sobre el CD-CC. En la práctica, para enlaces celulares, se aplica MAX_EB por las capas inferiores de la pila de protocolo que decide eliminar la conexión cuando se alcanza un umbral de paquetes perdidos consecutivos.

El canal puede realizar fragmentación y reensamble en el descompresor, pero preserva y proporciona el tamaño de los paquetes que se transfieren. Obsérvese que esta fragmentación es diferente de la fragmentación IP.

Este esquema supone que hay un mecanismo para detectar errores entre el compresor y el descompresor. Se supone que el canal proporciona esa detección de errores. Si no está disponible detección de errores del canal, se puede extender el esquema de una manera simple añadiendo un código de detección de errores en el nivel del compresor-descompresor. La corrección de errores es beneficiosa pero opcional.

Se define el retardo de ida y vuelta entre el compresor y descompresor como el tiempo para enviar y procesar un encabezamiento(n), para procesarlo, y devolver un ACK(n). Para evitar cualquier ambigüedad sobre qué mensaje original se está realizando un ACK, el ACK no debe experimentar un retardo de ida y vuelta tan largo que el (CD_SN)f_extendido en la dirección directa haya vuelto a cero. Es razonable suponer que el tiempo para enviar el encabezamiento(n) y procesarlo está limitado, debido a los requisitos de tráfico en tiempo real. El tiempo para devolver el ACK(n) depende del canal inverso usado para transmitirlo. Por ejemplo, si el canal está basado en contienda, puede experimentar retardo de cola de espera. Se supone que las capas inferiores aplican un límite de retardo en la transmisión de ACK, si fuera necesario descartando esos ACK que han permanecido en la cola durante demasiado tiempo. En base a estas consideraciones, se supone que hay un límite superior del retardo de ida y

vuelta RTT_UB. Además, existe un retardo de ida y vuelta nominal, denominado RTT_n, que es el retardo de ida y vuelta más probable durante el funcionamiento normal. Evidentemente, RTT_n < RTT_UB. Se debe realizar la estimación de RTT_n antes de la implementación, puesto que se usa RTT_n para determinar el valor óptimo de k (véase a continuación para explicación). Obsérvese que en el tiempo de ejecución, el receptor necesita estimar el retardo de ida y vuelta real. Se analizan los detalles a continuación.

En base a las suposiciones 1 y 4, para garantizar la corrección del esquema propuesto, el valor de f_extendido debe satisfacer las siguientes condiciones:

1.

2f_extendido * T_H ≥ RTT_UB, donde T_H es el espaciado de tiempo entre dos encabezamientos consecutivos; se requiere esto para evitar ambigüedad en los ACK

2.

2f_extendido

> MAX_EB; se requiere esto para mantener sincronización de secuencia incluso cuando aparecen grandes ráfagas

Existe alguna flexibilidad para elegir el valor de f. Sin embargo, para conseguir rendimiento óptimo, se debe ajustar bien en base a la distribución de ráfagas de errores de canal (tanto dirección directa como inversa) y el retardo de ida y vuelta. Las siguientes son algunas consideraciones:

3.

2k * T_H ≥ RTT_n, para reducir la posibilidad de que el compresor conmute al modo extendido debido a ACK retrasados.

4.

2k > el número más probable de pérdidas de paquetes consecutivos. Esto se necesita para reducir la posibilidad de que el compresor conmute al modo extendido debido a grandes ráfagas de errores.

5.

K no debería ser demasiado pequeño. De otra manera, se enviarán demasiados ACK periódicos desde el descompresor al compresor, causando inundación del canal inverso y bajando la eficacia de compresión. Por otro lado, un valor grande de k dará como resultado tara llevada en cada encabezamiento.

El concepto básico es que, cuando la condición del canal se deteriora, el compresor y el descompresor se repliegan usando (CD_SN) f bits extendidos para garantizar corrección. Por otro lado, se usará (CD_SN) k bits más cortos durante condiciones de canal normales para conseguir mejor eficacia. Se analizan los detalles de conmutación entre los dos modos a continuación.

La Figura 10 ilustra una realización de reducción de ancho de banda que envía al menos una secuencia de paquetes de datos, que transicionan en cada secuencia entre diferentes estados de consumo de encabezamiento, desde el compresor hasta el descompresor antes de que se reciba por el compresor un acuse de recibo (ACK) generado por el descompresor, para causar al compresor transicionar la compresión de encabezamientos a un mayor grado de compresión de encabezamientos. Debido a que el compresor transmite periódicamente, antes de recibir algún acuse de recibo, encabezamientos con al menos alguna compresión, el número menor resultante de bits transmitidos antes de recibir un acuse de recibo ahorra ancho de banda. En la fase de inicialización, el compresor puede, sin limitación, alternar entre encabezamientos completos (FH) y encabezamientos de primer orden (FO), es decir, un conjunto de FH, a continuación un conjunto de FO, a continuación un conjunto de FH, a continuación un conjunto de FO y así sucesivamente, hasta que se recibe un ACK. Cada uno de los conjuntos puede incluir al menos un encabezamiento. El descompresor transmite un ACK cuando recibe correctamente un FH. En la Figura 10, se transmiten los encabezamientos alternativos FH y FO uno después de otro, es decir, FH(0), FO(1), FH(2), FO(3), hasta que el compresor recibe el ACK(0) para el paquete 0 y usa el FH(0) como encabezamiento de referencia en adelante para descompresión.

Las Figuras 14A-F ilustran un ejemplo del formato de paquetes SO, ACK, FO, FH, FO EXT y FH REQ que se pueden usar con la práctica de la presente invención. Se aplican las siguientes abreviaturas: PT es el tipo de paquete, C_RTP_SN es el número de secuencia RTP comprimido, C_RTP_TS es la indicación de tiempo RTP comprimida y C_IP_ID es la IP_ID comprimida. Sin embargo, se debe entender que la presente invención no está limitada a los mismos. El campo PT para el paquete SO se puede codificar como 0, el paquete ACK como 10, el paquete FO como 110, el paquete FH como 1110, el paquete FO_EXT como 11110 y el paquete FH_REQ como 111110. En los paquetes FO y FO_EXT, M es un marcador de un bit en el encabezamiento RTP. En el paquete FO, T es un indicador de un bit que es 1 si C_RTP_TS está presente y cero de otra manera e I es un indicador de un bit que se establece a si C_IP_ID está presente y es cero de otra manera. En paquetes FH, los encabezamientos IP y UDP se pueden comprimir si se proporciona el tamaño del paquete mediante una capa inferior en el descompresor. El paquete FO_EXT se transmite únicamente si han cambiado varios campos no esenciales; la máscara de bit se usa para indicar qué campos están presentes y C_RTP_TS y C_IP_ID siempre están presentes no haciendo necesarios los indicadores de bit T e I. Finalmente, se envía el paquete FH_REQ únicamente bajo circunstancias excepcionales, tales como un bloqueo de sistema.

Se puede necesitar un campo de identificador de contexto (CID) para añadirse a cada uno de los encabezamientos anteriores si se comprimen múltiples flujos RTP y la capa inferior no proporciona diferenciación entre los flujos. Se puede necesitar únicamente el CID para una dirección, tal como en un sistema celular cuando la estación móvil (MS) tiene únicamente un flujo RTP en cada dirección, y no se necesita CID para el tráfico del enlace descendente (incluyendo los ACK). La cantidad de CID se debe incluir para tráfico del enlace ascendente (incluyendo los ACK) puesto que la descompresión en el lado de red siempre maneja múltiples flujos.

Lo siguiente es un ejemplo de pseudocódigo que se puede usar para escribir código para el compresor.

Este ejemplo ilustra el caso donde se necesitan dos ACK para transicionar desde la fase de actualización a la fase de extrapolación. Por simplicidad, no se ilustran en el pseudocódigo la alternación de paquetes FH y FO, como se ilustra en la Figura 8, ni la compensación del número de secuencia.

5 En este ejemplo, se suponen S_DFOD y R_DFOD no estáticos. Se determinan por lo tanto por el compresor y descompresor de una manera dinámica como sigue:

•

Se calcula la cantidad de S_DFOD como CFO(m) cuando el compresor recibió ACK(n) y ACK(n-p) y (n-p) ≥ N_Last_Interr. Obsérvese que p no es necesariamente igual a 1.

•

El descompresor calcula R_DFOD cuando recibe el primer paquete SO después de un paquete no SO. Se

10 calcula la cantidad R_DFOD usando una extrapolación lineal en base a los últimos dos encabezamientos de acuse de recibo almacenados en OAW 135.

El comportamiento del compresor se puede modelar como una máquina de estados, especificados por la tabla a continuación.

Para tratar el problema de vuelta a cero del contador y grandes ráfagas de errores, el compresor espera recibir un

15 ACK al menos una vez cada sec_ciclo encabezamientos y mantiene un indicador extendido. Si el indicador es verdadero, el compresor deberá funcionar en el modo extendido, es decir enviar (CD-SN)f_extendido. De otra manera, envía (CD-SN)k. El indicador extendido se establece a verdadero siempre que N_elapsed > sec_ciclo. De otra manera, se establece a falso. Obsérvese que N_elapsed sigue aumentando a menos que el transmisor reciba un ACK (consúltese pseudocódigo para detalles). En el modo extendido, si ha transcurrido ext_ciclo sin un acuse de

20 recibo, el transmisor transiciona al estado FH.

El compresor entra en el estado SO cuando se ha realizado acuse de recibo de al menos dos paquetes con CD_SN≥ N_Last_Interr. A continuación establece S_DFOD igual al CFO más reciente.

Inicialmente, el compresor inicia la sesión en el estado FH. La HSW 117 está vacía. Se establece la cantidad N_elapsed a cero. Se establece Extended_flag a falso.

25 Se necesitan ejecutar procedimientos extra en el caso de traspaso. Por simplicidad, no están incluidos en el presente documento.

Estado FH

Evento

Acción

recibir ACK(n) por FH(n)

• véase pseudocódigo procesamiento de compresor ACK(n) • estado ← FO_STATE;

En el estado FH, el procedimiento para enviar encabezamiento(n) es

{ 30 calcular CFO(n) y actualizar N_Last_Interr;

enviar como FH(n); almacenar encabezamiento(n) en HSW, color B rojo; /* n en FH se codifica en k_bits extendidos */ }

Estado FO

Evento

Acción

recibir ACK(n) por FH(n,m)

• véase pseudocódigo de procesamiento de Compresor ACK(n)

Recibir FH_Req

• estado ← FO_STATE;

En el estado FO, el procedimiento para enviar encabezamiento(n) es

{ 40 calcular CFO(n) y actualizar N_Last_Interr; si N_elapsed >= sec_ciclo extended_flag B VERDADERO; sino extended_flag B FALSO; 45 si {N_elapsed >= ext_ciclo {

enviar FH(n), almacenar encabezamiento(n) en SHW, color B rojo; estado β FH_STATE; N_elapsed B 0; } 5 si se recibieron más de dos ACK, Y los dos más recientes CD_SN se les realizó ACK >= N_Last_Interr { S_DFOD B CFO(n); 10 enviar SO(n), almacenar encabezamiento(n) en HSW, color B color_actual(); /* véase función a continuación */ estado B SO_STATE; } sino 15 enviar FO(n, S_RFH); almacenar encabezamiento (n) en HSW, color B color_actual(); } N_elapsed B N_elapsed + 1; } color_actual() { 20 si extended_flag = VERDADERO devolver rojo; sino devolver verde; }

Estado SO

Evento

Acción

Recibir ACK(n)

• véase pseudocódigo de procesamiento de Compresor ACK(n)

Recibir FH_Req

• estado ← FH_STATE;

En el estado SO, el procedimiento para enviar encabezamiento(n) es

{ 30 calcular CFO(n) y actualizar N_Last_Interr; si N_elapsed >= sec_ciclo extended_flag B VERDADERO; sino extended_flag B FALSO; 35 si N_elapsed >= ext_ciclo

{ enviar FH(n), almacenar encabezamiento(n) en SHW, color = rojo; estado B FH_STATE; N_elapsed B 0;

40 } si CFO(n) = S_DFOD

enviar SO(n); almacenar encabezamiento(n) en HSW, color B color_actual(); sino {

45 enviar FO(n, S_RFH); almacenar encabezamiento(n) en HSW, color B color_actual(); estado B FO_STATE;

} N_elapsed BN_elapsed + 1;

50 } Procesamiento de compresor ACK(n) { si color de ACK(n) es verde /* n se codifica en k bits */

h_ack β un encabezamiento verde en HSW 117 cuyo (CD_SN)k = n; /* véase a 55 continuación para detalles */ sino /* n se codifica en k bits extendidos */

h_ack β un encabezamiento rojo en HSW 117 cuyo (CD_SN)k_extendido = n; S_RFH β CD_SN de h_ack; Borrar todos los encabezamientos anteriores en HSW (más antiguos) h_ack;

Mover h_ack a Encabezamiento(S_RFH); N_elapsed � Diff(actual|CD_SN, S_RFH): | }

Se puede probar que en el procedimiento anterior, uno y solamente un encabezamiento en la HSW 117 se puede identificar correctamente como el encabezamiento al que se está realizando ACK, en otras palabras, no habrá ambigüedad del ACK. Si el ACK(n) es rojo, es decir, n se codifica usando f bits extendidos, únicamente un encabezamiento rojo puede corresponder al ACK, puesto que hay al menos 2f_extendido encabezamientos en la HSW

117. De otra manera, si el ACK(n) es verde, los presentes inventores mostrarán que todavía se puede asignar únicamente a un encabezamiento verde en la HSW 117.

Suponiendo que se toma una instantánea de la HSW 117 cada momento después de que el compresor envía un paquete, y lo representa con una cadena de letras R (para encabezamientos rojos) y G (para encabezamientos verdes). Siendo S la cadena correspondiente a una instantánea arbitraria. Obsérvese que S se inicia con el paquete más antiguo enviado por el transmisor, y finaliza con el más nuevo. Adicionalmente, entre el envío de dos paquetes consecutivos por el compresor, la cadena S no cambia a menos que llegue un ACK durante el periodo, que serán algunas letras desde el comienzo de la S.

Ahora, si G1 denota la G más a la derecha (más nueva) en S, y S1 como el prefijo de S hasta (incluyendo) G1. A continuación hay únicamente dos posibles casos, como se muestra a continuación.

Si len(S1) denota el tamaño de S1. En el caso 1, puesto que hay una R después de G1, len(S1) debe ser igual a sec_ciclo (=2k). De otra manera, el compresor no habría enviado el paquete después de G1 como una roja. En el caso 2, len (S1) s sec_ciclo debe ser verdadero. De otra manera, el compresor habría enviado G1 como una roja. Por lo tanto, en cualquier caso, len(S1) es menor o igual a sec_ciclo.

Puesto que G1 es la letra verde más a la derecha en S, está probado que al menos pueden existir 2k encabezamientos verdes en HSW 117 en cualquier momento. Por lo tanto, cuando se recibe un ACK verde por el compresor, se puede usar el k-bit CD_SN en el ACK para identificar únicamente un encabezamiento verde en el HSW.

Obsérvese que el descompresor debe cooperar con el compresor para asegurar que se mantiene la sincronización de CD_SN durante la transición entre los dos modos. En primer lugar, si el descompresor recibe un paquete rojo y decide realizar un ACK a ese paquete, debe enviar un ACK rojo que lleva (CD_SN) f_extendido.

En segundo lugar, si el descompresor recibe un paquete FO, FO(n, m), el encabezamiento de referencia correcto debe ser el encabezamiento más nuevo (más reciente) en OAW 135, cuyos k bits menos significativos (si m es k-bit)

o f_extendido (si m es k_bit extendido) corresponden con m. Obsérvese que esto se basa en la suposición que, en cada dirección, el canal se comporta como un FIFO.

La Figura 19 ilustra la segunda condición. En este ejemplo, NT0 y NT2 son los valores de CD_SN en el momento T0 y T2, respectivamente. Suponiendo que en T1, el compresor envía el paquete ACK(NT0), en el que se codifica NT0 en f_bits extendidos. En T2, el compresor recibe el ACK(NT0). A continuación calcula N_elapsed igual a (NT2-NT0) y averigua que N_elapsed<sec_ciclo. Al mismo tiempo, llega un paquete RTP en el compresor y el compresor decide enviarlo como un paquete FO, usando el encabezamiento(NT0) como referencia. Puesto que N_elapsed<sec_ciclo(=2k), el NT2 y NT0 en el paquete FO se codifican en k bits. En T3, el FO llega al descompresor. Para recuperar el encabezamiento de referencia correcto, el descompresor simplemente busca en su OAW desde la cola (el más reciente) a la cabeza (el más antiguo), y encuentra el primer encabezamiento cuyos k bits menos significativos de su CD_SN corresponden con (NT0)k.

Obsérvese que en T3, la OAW 135 del descompresor puede contener más de 2k encabezamientos. Sin embargo, la operación anterior siempre da el encabezamiento de referencia correcto. Debido a que la propiedad FIFO del canal directo, recibido independientemente (y por lo tanto realizado ACK) por el descompresor entre T1 y T3, se debe enviar por el compresor entre T0 y T2. En otras palabras, si A denomina el conjunto de encabezamientos en OAW 135 que se añadieron después de encabezamiento (NT0), y B el conjunto de encabezamientos en HSW 117 en T2, entonces siempre se mantiene A ⊆ B. Puesto que |A |<2k, tenemos que |B |<2k. Por lo tanto, no hay dos encabezamientos en el conjunto B de manera que los k bits menos significativos de sus CD_SN corresponden con (NT0)k en el paquete FO(NT2, NT0).

Lo siguiente es un ejemplo de pseudocódigo para el descompresor:

El descompresor está activado mayoritariamente por lo que se recibe desde el compresor (es decir FH, FO o 5 SO).

A continuación, "correctamente recibido" significa que no se detecta error en el encabezamiento recibido (FH, FO o SO). Además del estado de información anteriormente mencionado, el descompresor también mantiene una copia del último encabezamiento reconstruido, es decir, encabezamiento (R_Last_Decomp). Cuando recibe un paquete FO el descompresor usará el procedimiento descrito anteriormente con referencia al pseudocódigo del compresor

10 para recuperar el encabezamiento de referencia correcto.

Si se recibe correctamente FH(n)

{ reconstruir encabezamiento(n) desde FH(n); enviar ACK(n);

15 R_Last_Acked�n; almacenar encabezamiento(n) en la OAW 135 y también encabezamiento(R_Last_Decomp); } si FO(n, m) se recibe correcto

20 { si encabezamiento(m) no se puede encontrar en la OAW 135 /* puede ocurrir únicamente debido a fallos de sistema */

Enviar FH_Req; si no

25 recuperar encabezamiento(m) de la OAW 135 o encabezamiento (R_RFH); borrar encabezamientos en OAW que son más antiguos que encabezamiento (R_RFH); reconstruir encabezamiento(n)-FO_DIFF(n, m) + encabezamiento(m); si R_RFH!=m

30 R_RFH-m y almacenar encabezamiento(m) como encabezamiento(R_RFH);

si FO(n, m) es uno de los dos primeros paquetes FO recibidos o se han recibido N_RT FO paquetes desde el último paquete FO al que se realizó ACK

35 { Enviar ACK(n); R_Last_Acked�n; almacenar encabezamiento(n) en la OAW:

} almacenar encabezamiento reconstruido(n) en

40 encabezamiento(R_Last_Decomp); } Si SO(n) se recibe correctamente {

si es el primer paquete SO después de un paquete no SO

45 { encontrar los dos encabezamientos reconstruidos más recientemente en OAW 135; si no encontrado /* puede ocurrir únicamente debido a fallo del sistema */

50 Enviar FH_Req; sino /*dejar que los dos encabezamientos sean encabezamiento(p) y encabezamiento(q), p<q*/ R_DFOD+FO_DIFF(q,p)/Diff(q,p); }

55 reconstruir encabezamiento(n)�R_DFOD * Diff(n, R_Last_Decomp) + encabezamiento(R_Last_Decomp); almacenar encabezamiento(n) en encabezamiento(R_Last_Decomp); si 1) han transcurrido (sec_ciclo - N_RT) paquetes desde R_Last_ACKed, o, /* tiempo para enviar un ack periódico */

60 2) extended_flag en SO está ACTIVO y este es el primer paquete tal, o, /* el compresor conmuta al modo extendido; envía ack de modo que el compresor vuelve al modo normal */

3) recibidos más de N_RT paquetes con extended_flag ACTIVO desde R_Last_ACK /* el ack previo fue aparentemente no recibido; enviar otro ack */ { Enviar ACK(n); n se codifica en modo extendido si se cumplen las condiciones

5 2 o 3 R_Last_Acked n: almacenar Encabezamiento (n) en la OAW;

}

} almacenar encabezamiento(n) en la OAW 135 y también encabezamiento(R_Last_Dccomp);

} si FO(n, m) se recibe correctamente {

15 si encabezamiento(m) no se puede encontrar en la OAW 135 5 /* puede ocurrir únicamente debido a fallos del sistema */ Enviar FH_Req; sino

{ recuperar encabezamiento (m) desde la OAW 135 o encabezamiento (R_RFH); eliminar encabezamientos en OAW que son más antiguos que el encabezamiento (R_RFH); reconstruir encabezamiento(n) FO_DEFF(n, m) + encabezamiento(m);

25 si R_RFH!=m R_RFH m y almacenar encabezamiento(m) como encabezamiento(R_RFH);

si FO(n, m) es uno de los primeros dos paquetes FO recibidos o se han recibido N_RT FO paquetes desde el último paquete FO al que se realizó ACK

{ Enviar ACK(n); R_Last_Acked-n; almacenar encabezamiento (n) en la OAW:

} 35 almacenar encabezamiento reconstruido (n) en

encabezamiento(R_Last_Decomp); } Si SO(n) se recibe correctamente {

si no es el primer paquete SO después de un paquete no SO

{ Encontrar los dos encabezamientos más recientemente reconstruidos en OAW 135; si no encontrados /* puede ocurrir únicamente debido a fallo de

45 sistema */

Enviar FH_Req; sino /*dejar que los dos encabezamientos sean (p) y encabezamiento (q), p<q*/ R_DFOD+FO_DIFF(q,p)/Diff(q,p);

} reconstruir encabezamiento(n) R_DFOD * Diff(n, R_Last_Decomp) + encabezamiento(R_Last_Decomp); almacenar encabezamiento(n) en encabezamiento(R_Last_Decomp); si 1) han transcurrido (sec_ciclo - N_RT) paquetes desde R_Last_ACKed, o,

55 /* tiempo para enviar un ack periódico */ 2) extended_flag en SO es ACTIVO y este es el primer paquete tal, o, /* el compresor conmuta al modo extendido; enviar ack de modo que el compresor vuelve al modo normal */

3) recibidos más de N_RT paquetes sin extended_flag ACTIVO desde R_Last_ACK /* el ack precio fue aparentemente no recibido; enviar otro ack */

{ Enviar ACK(n); n se codifica en modo extendido si se cumplen las condiciones 2 o 3 R_Last_Acked n:

65 almacenar Encabezamiento(n) en la OAW; } }

HSW 117 y OAW 135

En el peor caso, donde el retardo de ida y vuelta es realmente igual a RTT_UB, la OAW 135 o la HSW 117 pueden necesitar mantener 2f-extendido encabezamientos. Sin embargo, eso es muy improbable que ocurra. En muchos casos, se necesitan mantener menos de 2k entradas en la HSW 117 u OAW 135. En la práctica esto significa un número bastante pequeño de entradas para tanto OAW como HSW. Por ejemplo, 16 (k=4) entradas proporcionarán 320 ms de tiempo de ida y vuelta, suponiendo 20 ms de espaciado por paquete.

No es necesario almacenar los campos estáticos como múltiples entradas en la HSW 117 u OAW 135. Únicamente se necesita una sola copia de los campos estáticos.

En el documento RFC 2508, cada encabezamiento comprimido lleva un número de secuencia. En muchos casos, el número de secuencia es suficiente para reconstruir el encabezamiento completo mediante extrapolación lineal. Para esos paquetes donde la extrapolación lineal daría como resultado reconstrucción de encabezamientos incorrecta, el compresor envía información de diferencia de primer orden con respecto al paquete inmediatamente anterior. Por lo tanto, la pérdida de un paquete invalidará los paquetes posteriores con encabezamientos comprimidos, puesto que el paquete perdido puede estar llevando información de diferencia FO. El documento RFC 2508 se basa únicamente en los números de secuencia de 4-bit para detectar pérdidas de paquetes. El número de secuencia vuelve a cero cada 16 paquetes. Cuando ocurre una ráfaga de errores mayor de 16 paquetes, hay una probabilidad de 1 a 16 de no detectar errores, que es inaceptablemente alta. Adicionalmente, incluso si el descompresor pudiera detectar errores, recuperarse de errores, el descompresor tiene que solicitar al compresor enviar un encabezamiento de gran tamaño enviando un mensaje CONTEXT_STATE. Por lo tanto hay un retardo de ida y vuelta causado antes de que el encabezamiento solicitado alcance el receptor. En el caso de tráfico conversacional en tiempo real, este retardo se traduce en un corte en la conversación. Además, enviar un encabezamiento de gran tamaño es caro en términos de ancho de banda.

Una realización de la presente invención usa un número de secuencia de k-bit (k puede establecerse igual a 4) para extrapolación lineal. Al igual que el documento RFC 2508, cuando la extrapolación lineal diera como resultado reconstrucción de encabezamientos incorrecta, el compresor envía una información de diferencia FO. A diferencia del documento RFC 2508, se calcula la diferencia con respecto al paquete de referencia que se sabe que se recibió correctamente. Ese paquete no es necesariamente el inmediatamente anterior al paquete actual. Esta característica asegura que el encabezamiento actual se puede reconstruir fiablemente incluso si se perdieron uno o más paquetes pasados. Puesto que el encabezamiento se puede reconstruir fiablemente de esa manera, no hay necesidad de enviar un encabezamiento completo. La información de diferencia de primer orden se puede codificar la mayoría del tiempo con menos bits que el valor absoluto del encabezamiento completo. El encabezamiento de diferencia FO tiene un campo adicional que lleva el número de referencia, es decir número de secuencia del paquete de referencia. Para garantizar que se detectarán errores incluso en la presencia de grandes ráfagas de errores, el descompresor envía un ACK con suficiente frecuencia de modo que el compresor recibe un ack al menos una vez cada sec_ciclo paquetes. En ausencia de ACK tal, el compresor supondrá que puede haber una grande ráfaga de errores. En muchos casos, entonces es suficiente que el compresor simplemente conmute a número de secuencia de f_bit extendido, donde f_extendido es suficientemente grande para evitar cualquier ambigüedad. En cualquier evento, la pérdida de un paquete no invalidará los paquetes posteriores con encabezamientos comprimidos. Por lo tanto, cuando el descompresor detecta una pérdida de paquete, no tiene que solicitar retransmisión.

La Figura 20 a continuación muestra resultados comparativos de la técnica anterior del documento RFC 2508 con la invención. Se supone un retardo en un sentido (fijo) de 60 ms en este ensayo. El interespaciado entre paquetes RTP es 30 ms. El modelo de error aleatorio se usa con diferentes medias de tasas de errores de paquetes. La proporción de compresión se define como la proporción entre el tamaño medio de los encabezamientos comprimidos y el tamaño de los encabezamientos IP/UDP/RTP originales. Obsérvese que con la invención, el tamaño de los paquetes ACK se incluye en el cálculo del promedio del tamaño del encabezamiento comprimido. La invención supera el documento RFC 1508 tan pronto como la tasa de error de paquetes es mayor del 0,4 %.

El esquema robusto de la invención requiere que el compresor y descompresor mantengan las colas HSW 117 y OAW 135, respectivamente. Suponiendo que las vueltas a cero son menores que 320 ms, el tamaño de las colas es 16 entradas + una copia de los campos estáticos.

lpv4

lpv6

Tamaño de campos estáticos (en bytes)

18 40

Tamaño de una entrada (en bytes)

22 20

Tamaño total de HSW u OAW para una sesión bidireccional (en bytes)

(16*22 + 18)* 2 = 740 (16*20 + 40)*2 = 720

procesamiento para gestionar las colas es muy moderada, ya que implica manipulación de punteros.

Aunque la invención se ha descrito en términos de sus realizaciones preferidas, debe entenderse que se pueden realizar numerosas modificaciones de la invención sin alejarse del alcance de la invención. Se pretende que tales modificaciones estén dentro del alcance de las reivindicaciones adjuntas.

Claims (11)

1. REIVINDICACIONES

   1.

   Un procedimiento de funcionamiento de un descompresor (115, 137) en un sistema que tiene un transmisor (110, 120) que transmite una pluralidad de paquetes, conteniendo cada uno un encabezamiento, a un receptor (130, 150), comprendiendo el procedimiento descomprimir un encabezamiento comprimido contenido en un paquete actual recibido por el receptor:

   determinando con un contador (134) en el receptor un tiempo transcurrido Δt entre paquetes recibidos consecutivamente, siendo el tiempo transcurrido Δt la diferencia entre tiempos en los que se recibieron el paquete actual y un paquete recibido inmediatamente antes; determinando si el tiempo transcurrido Δt es mayor que o igual a un lapso de tiempo que indica que al menos un paquete se ha perdido entre el paquete actual y el paquete recibido inmediatamente antes; procesando el tiempo transcurrido Δt que indica que al menos se ha perdido un paquete para determinar un número de paquetes perdidos entre el paquete recibido inmediatamente antes y el paquete actual; añadiendo el número de paquetes perdidos a un número de paquete del paquete recibido inmediatamente antes para actualizar un número del paquete actual en una secuencia de transmisión de la pluralidad de paquetes; y descomprimiendo el encabezamiento comprimido del paquete actual usando el número actualizado del paquete actual.

2. 2.

   Un procedimiento de acuerdo con la reivindicación 1 en el que el encabezamiento del paquete actual es un encabezamiento comprimido de segundo orden.

3. 3.

   Un procedimiento de acuerdo con la reivindicación 1 o 2 en el que:

   se calcula el número de paquetes perdidos como i*SEC_CICLO+DIFF (n2, n1) si (DIFF(n2, n1) + i*SEC_CICLO)*(t unidades de tiempo) ≤Δt < (DIFF(n2, n1) + (i+1)*SEC_CICLO)*(t unidades de tiempo), en el que i es un número entero igual a o mayor de cero, n2 es un número de secuencia del paquete actual en una secuencia de transmisión de los paquetes, n1 es un número de secuencia del paquete recibido inmediatamente antes en la secuencia de transmisión de los paquetes, SEC_CICLO es igual a 2k en el que k es el número de bits del número de secuencia, DIFF(n2, n1) es la diferencia en el número de secuencia entre los paquetes actual y el recibido inmediatamente antes y donde DIFF(n2, n1)=n2-n1 cuando n2>n1 y DIFF(n2, n1) = n2+2k-n1 cuando n2 ≤n1, y en el que t unidades de tiempo es el intervalo de tiempo entre paquetes consecutivos.

4. 4.

   Un procedimiento de acuerdo con cualquier reivindicación precedente en el que descomprimir el encabezamiento comprimido comprende usar extrapolación lineal.

5. 5.

   Un procedimiento de acuerdo con la reivindicación 4, en el que la extrapolación lineal comprende calcular una indicación de tiempo RTP TS del paquete actual como TS(n2) = TS(n1) + Nperdidos*(TS_STRIDE) y calcular un número de secuencia RTP SEC del paquete actual como SEC(n2) = SEC(n1) + Nperdidos, en el que TS_STRIDE es un incremento RTP TS cada t unidades de tiempo y Nperdidos es el número de paquetes perdidos.

6. 6.

   Un procedimiento de acuerdo con cualquier reivindicación precedente que comprende resetear el contador (134) después de determinar el tiempo transcurrido Δt.

7. 7.

   Un procedimiento de acuerdo con cualquier reivindicación precedente en el que k es cuatro.

8. 8.

   Un receptor (130, 150) que está dispuesto para recibir una pluralidad de paquetes transmitidos, conteniendo cada uno un encabezamiento; en el que el receptor comprende un contador (134) que está dispuesto para determinar un tiempo transcurrido Δt entre paquetes recibidos consecutivamente, siendo el tiempo transcurrido Δt la diferencia de tiempos entre un tiempo de recepción en el receptor de un paquete actual y un tiempo de recepción en el receptor de un paquete recibido inmediatamente antes, estando el receptor dispuesto para determinar si el tiempo transcurrido Δt es mayor que o igual a un lapso de tiempo que indica que al menos se ha perdido un paquete entre el paquete actual, para procesar el tiempo transcurrido Δt, para añadir el número de paquetes perdidos a un número de paquete del paquete recibido inmediatamente antes para actualizar un número del paquete actual en una secuencia de transmisión de la pluralidad de paquetes, y para descomprimir el encabezamiento comprimido del paquete actual usando el número actualizado del paquete actual.

9. 9.

   Un receptor de acuerdo con la reivindicación 8 en el que el encabezamiento del paquete actual es un encabezamiento comprimido de segundo orden.

10. 10.

    Un receptor de acuerdo con la reivindicación 8 o 9 en el que:

    el receptor (130, 150) está dispuesto para calcular el número de paquetes perdidos como i*SEC_CICLO+DIFF (n2, n1) si (DIFF(n2, n1) + i*SEC_CICLO)* (t unidades de tiempo) ≤Δt < (DIFF(n2, n1) + (i+1)*SEC_CICLO)*(t unidades de tiempo), en el que i es un número entero igual a o mayor de cero, n2 es un número de secuencia del paquete actual en una secuencia de transmisión de los paquetes, n1 es un número de secuencia del paquete recibido inmediatamente antes en la secuencia de transmisión de los paquetes, SEC_CICLO es igual a 2k en el que k es el número de bits del número de secuencia, DIFF(n2, n1) es la diferencia en el número de secuencia entre los paquetes actual y recibido inmediatamente antes y donde DIFF(n2, n1)=n2-n1 cuando n2>n1 y DIFF(n2, n1) = n2+2k-n1 cuando n2�n1, y en el que t unidades de tiempo es el intervalo de tiempo entre

    5 paquetes consecutivos.
11. 11. Un receptor de acuerdo con la reivindicación 10, en el que el receptor (130, 150) está dispuesto para calcular una indicación de tiempo RTP TS del paquete actual como TS(n2) = TS(n1) + Nperdidos *(TS_STRIDE) y para calcular un número de secuencia RTP SEC del paquete actual como SEC(n2) = SEC(n1) + Nperdidos, en el que TS_STRIDE es un incremento RTP TS cada t unidades de tiempo y Nperdidos es el número de paquetes perdidos.

    10 12. Un receptor de acuerdo con una cualquiera de las reivindicaciones 8 a 11, en el que el receptor (130, 150) está dispuesto para resetear el contador (134) después de determinar el tiempo transcurrido Δt.

    A COMPRIMIR