ES2525641T3

ES2525641T3 - Método y sistema para comprimir y descomprimir encabezamientos de paquetes

Info

Publication number: ES2525641T3
Application number: ES00970868.6T
Authority: ES
Inventors: Khiem Le; Christopher Clanton; Haihong Zheng; Zhigang Liu
Original assignee: Nokia Inc
Current assignee: Nokia Inc
Priority date: 1999-10-14
Filing date: 2000-10-13
Publication date: 2014-12-26
Anticipated expiration: 2020-10-13
Also published as: JP2006311517A; JP5091893B2; EP2034691B1; JP2003511981A; PT1221239E; EP2323337A3; PT1926282E; EP2323337A2; EP2383953A3; EP2383953A2; EP1221239B1; EP2381639A2; EP2034691A1; EP2381639A3; CA2386837C; US6882637B1; EP1221239A2; JP4364877B2; DK1926282T3; ES2397710T3

Abstract

Un método para hacer funcionar un sistema que tiene un transmisor que transmite una pluralidad de paquetes conteniendo cada uno un encabezamiento a un receptor, comprendiendo el método sincronizar la transmisión de encabezamientos comprimidos entre el transmisor y el receptor mediante: transmisión de un paquete actual desde el transmisor al receptor que contiene información de que el transmisor está preparado para enviar paquetes transmitidos posteriormente en los que los encabezamientos en los mismos se han de comprimir en comparación con el encabezamiento contenido en el paquete actual, en donde el encabezamiento del paquete actual es un encabezamiento completo o un encabezamiento comprimido de primer orden; transmisión desde el receptor al transmisor de un paquete de acuse de recibo de que el receptor ha recibido el paquete actual; y en respuesta a recibir en el transmisor el paquete de acuse de recibo, envío posteriormente de paquetes transmitidos en los que el encabezamiento comprimido de los paquetes transmitidos posteriormente es un encabezamiento comprimido de segundo orden.

Description

15

25

35

45

55

65

E00970868

16-12-2014

DESCRIPCIÓN

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

Para la multimedia en tiempo real basada en el Protocolo de Internet (IP), se usa predominantemente el Protocolo de Transferencia en Tiempo Real (RTP) en la parte superior del Protocolo de Datagramas de Usuario (UDP/ IP). RTP se describe en detalle en el RFC 1889. El tamaño de los encabezamientos de IP/UDP/RTP combinados es al menos 40 bytes para IPv4 y al menos 60 bytes para IPv6. Un total de 40-60 bytes de tara por paquete puede considerarse fuerte en sistemas (por ejemplo, tales como redes celulares) donde la eficacia espectral es una preocupación principal. En consecuencia, existe una necesidad para mecanismos de compresión de encabezamientos de IP/UDP/RTP adecuados. Un esquema de compresión de encabezamientos actual se describe en el RFC 2508, por S. Casner, V. Jacobson, “Compressing IP/UDP/RTP Headers for Low Speed Serial Links”, Internet Engineering Task Force (IETP), febrero de 1999, y que puede comprimir el encabezamiento de IP/UDP/RTP de 40/60 bytes hasta 2 o 4 bytes a través de enlaces punto a punto. Los algoritmos de compresión de encabezamientos existentes están basados en la observación de que la mayoría de los campos de los encabezamientos de paquetes de IP permanecen constantes en una corriente 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 mínima cantidad de información de encabezamiento desde el compresor al des-compresor. Los esquemas de compresión de encabezamientos de IP/UDP/RTP, como se describen por ejemplo en el RFC 2508, aprovechan el hecho de 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 deben transmitirse en alguna forma en cada paquete (es decir no son compresibles).

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

Ejemplos de los campos de encabezamiento de Tipo 2 son la indicación de tiempo de RTP, el número de secuencia de RTP y los campos de 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 es necesario transmitir estos valores en cada encabezamiento. Se requiere únicamente que el receptor/descompresor tenga conocimiento del valor de incremento constante, denominado posteriormente 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’.

Cabe destacar 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 real (por ejemplo, para voz, el comportamiento puede variar de un altavoz a otro) y las sesiones en número que comparten simultáneamente la misma dirección de IP.

Un ejemplo de un campo de encabezamiento de Tipo 3 es el M-bit (Marcador) de RTP, que indica la aparición de algún límite en los medios (por ejemplo, fin de un fotograma de vídeo). Puesto que los medios varían normalmente de maneras impredecibles, esta información no puede predecirse verdaderamente. Los campos de Tipo 3 son parte de campos ‘variables’.

El descompresor mantiene la 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 de FOD y otra información. Cuando los paquetes se pierden o corrompen, el descompresor puede perder sincronización con el compresor de manera que ya no puede reconstruir correctamente los paquetes. La pérdida de la sincronización puede aparecer cuando se eliminan o corrompen paquetes durante la transmisión entre el compresor y el 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 de FH únicamente al comienzo de la sesión (para establecer datos de Tipo 1 en el receptor). La transmisión de paquetes de FH adicionales tiene efectos adversos

15

25

35

45

55

65

E00970868

16-12-2014

en la eficacia del algoritmo de compresión. Cuando el compresor transmite paquetes de FH, se dice que está en el ‘estado de FH’.

 Primer Orden (FO): contiene mínima información de encabezamiento (por ejemplo campos de Tipo 3), campos de control específicos de compresor/descompresor (específicos para el algoritmo de compresión en uso) e información que describe cambios en campos de FOD actuales. Un paquete de FO es básicamente un paquete de SO (descrito a continuación), con información adicional que establece nueva información de FOD para uno o más campos de Tipo 2 en el descompresor. Si se está aplicando compresión de encabezamientos a una corriente de VoIP (voz sobre el protocolo de internet), la transmisión de un paquete de FO podría activarse mediante la aparición de una secuencia hablada después de un intervalo de silencio en la voz. Un evento de este tipo da como resultado algún cambio inesperado en el valor de la indicación de tiempo de RTP, y una necesidad para actualizar la indicación de tiempo de RTP en el receptor mediante un valor distinto de la FOD actual. El tamaño de los paquetes de 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 de FO, se dice que está en el ‘estado de FO’.

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

El RFC 2508 está basado en el concepto que la mayoría del tiempo, los campos de RTP que cambian de un paquete al siguiente, tal como la indicación de tiempo de RTP, pueden predecirse mediante extrapolación lineal de paquetes de SO transmitidos. Esencialmente la única información que tiene que enviarse 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 puede aplicarse extrapolación lineal al paquete actual con respecto al paquete inmediatamente anterior, se transmite un paquete de FO. Para iniciar la sesión, se transmite un paquete de FH. Además, cuando el receptor determina que existe pérdida de paquetes (como se detecta mediante un número de secuencia que incrementa en más de 1) el receptor pedirá explícitamente al transmisor transmitir el encabezamiento completo para permitir una resincronización.

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

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

El RFC 2508 sufre de falta de robustez para soportar errores o pérdidas de encabezamientos, puesto que la descompresión del encabezamiento actual puede hacerse únicamente si el encabezamiento inmediatamente anterior se recibió y descomprimió también sin error. La compresión de encabezamientos definida en el RFC 2508 no es bien adecuada para entornos celulares, donde el ancho de banda es muy preciado y las ráfagas de errores largas no son poco comunes. En el RFC 2508, cuando se detecta una pérdida de paquete, se invalidan los paquetes posteriores con encabezamientos comprimidos, con un requisito adicional que es necesario para 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.

Solamente usar un número de secuencia corto (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 pérdidas largas en cualquier momento. En este caso, se definen las pérdidas largas como pérdida del ciclo de secuencia o paquetes en una fila. Bajo la situación de una pérdida larga, pueden perderse una serie de paquetes en el número de paquetes del ciclo de secuencia que tienen una identificación de paquete definida mediante un número limitado de bits y, como resultado, el número de secuencia en el paquete recibido mediante el descompresor (dispositivo de recepción en el enlace ascendente o en el enlace descendente) del receptor continúa el ciclo (repite). Por ejemplo, suponiendo que el número de secuencia consiste de 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) envió el paquete con seq=n en el tiempo t0, y los siguientes 2k paquetes, comenzando desde el paquete con seq=n+1 en el tiempo t1 y finalizando en el paquete con seq=n en el tiempo t2. En el tiempo t3, el compresor envía un paquete con el número de secuencia igual a n+1 de nuevo. Se supone que se envía un paquete con un número de secuencia igual a n+1 en el tiempo t1 hasta que se envía el paquete con el número de secuencia

E00970868

16-12-2014

igual a n en el tiempo t2, que se pierden todos debido a pérdidas largas, a continuación el descompresor únicamente recibe el paquete con el número de secuencia igual a n enviado en el tiempo t0, y el paquete con el número de secuencia igual a n+1 enviado en el tiempo t3. Basándose en el esquema de detección de pérdida de paquetes actual definido en el RFC 2508, el descompresor concluye que no existe pérdida de paquetes y descomprime el 5 paquete de una manera incorrecta. Esto no afecta únicamente a la corrección de la descompresión de paquetes con un número de secuencia igual a n+1, sino también a los paquetes posteriores. La compresión de encabezamiento se desvela en, por ejemplo, ‘Compressing headers over WAN media (CIPX)’, IETFIREQUEST FOR COMMENTS 1553.

La invención se define mediante las reivindicaciones. La presente invención puede proporcionar transmisión y recepción mejorada de paquetes en entornos, tales como comunicaciones inalámbricas, que son propensas a interrupciones periódicas de recepción de paquetes tales como las producidas por el desvanecimiento, etc. La invención proporciona rendimiento mejorado de transmisión y recepción de paquetes en comparación con el RFC 2508 incluyendo eliminación del problema de continuar el ciclo 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

15 invención no depende de la descompresión correcta de un paquete inmediatamente anterior como con el documento RFC 2508.

Esta invención proporciona un mecanismo que puede detectar pérdidas largas en el nivel de compresión de encabezamientos, así como un esquema de recuperación correspondiente después de la detección de la pérdida larga. La invención en general es aplicable a protocolos de comunicación donde la sincronización de secuencia debe mantenerse entre el transmisor y el receptor, en la presencia de ráfagas de errores largas.

La compresión de encabezamientos adaptiva es un marco general para compresión de encabezamientos robusta, que puede parametrizarse para tener en cuenta la existencia/no existencia y características de rendimiento de un 25 canal inverso. El marco incluye tres modos básicos de operación:

 Modo determinístico bidireccional: este modo se usa en el caso donde existe un canal inverso ‘bien definido’, que puede usarse para llevar diversos tipos de información de realimentación desde el descompresor al compresor. Un ejemplo de tal retroalimentación desde el descompresor es un acuse de recibo, usado, por ejemplo, para avanzar de un estado de compresión inferior a un estado de compresor superior.

 Modo oportunístico bidireccional: este modo de operación 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.  Modo unidireccional (pesimista u optimista): este modo de operación se usa cuando no existe canal inverso de ningún tipo.

35 La Figura 1 ilustra la deficiencia de pérdida de paquetes CON el RFC 2508. La Figura 2 ilustra un ejemplo de una arquitectura de sistema que puede usarse para poner en práctica la presente invención. La Figura 3 ilustra conceptualmente la información de contexto de compresión. La Figura 4 ilustra conceptualmente la información de contexto de descompresión. Las Figuras 5A y 5B ilustran una primera realización de la presente invención. La Figura 6 ilustra el paso de un compresor de encabezamientos de transmisión que tienen un número de bits superior a encabezamientos que tienen un número de bits inferior usando acuses de recibo de acuerdo con la presente invención.

45 La Figura 7 ilustra el paso de un compresor de encabezamientos de transmisión con un primer orden de compresión a encabezamientos con un segundo orden de compresión de acuerdo con la presente invención. La Figura 8 ilustra la detección y recuperación de paquetes cuando aparece una continuación de ciclo que tiene un número de paquetes mayor de 2k donde se usan k bits para codificar números de secuencia n definidos mediante los k bits. La Figura 9 ilustra la operación de un compresor y descompresor usando acuses de recibo para controlar el paso entre números de secuencia que tienen k bits y ℓ extendido bits y de vuelta a k bits de acuerdo con la presente invención. La Figura 10 ilustra la reducción de ancho de banda de acuerdo con la presente invención conseguida transmitiendo una secuencia de paquetes de FH y de FO antes de que se genere un acuse de recibo mediante el

55 descompresor que significa la recepción de un paquete de FH. La Figura 11 ilustra la extrapolación de paquetes recibidos mediante el descompresor para recuperar encabezamientos de paquetes perdidos de acuerdo con la presente invención. La Figura 12 ilustra la compensación del número de secuencia de acuerdo con la presente invención cuando se pierden paquetes. La Figura 13 ilustra la detección de errores corriente arriba de un descompresor para reducir el ancho de banda de transmisión de acuerdo con la presente invención. 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 de compresión superior únicamente después de que se recibe un acuse de recibo desde un descompresor de acuerdo con la

65 invención. La Figura 16 ilustra la conmutación de un estado de compresión de un compresor a un estado de compresión

15

25

35

45

55

65

E00970868

16-12-2014

superior antes de que llegue un número de paquetes presente 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 estado de compresión superior después de que llega un número de paquetes preestablecido en un descompresor antes de que 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 superior únicamente después de que llega un número de paquetes presente en una descompresión. La Figura 19 ilustra gráficamente una comparación de la invención con el RFC 2508. La Figura 20 ilustra un análisis gráfico del rendimiento de la presente invención.

Mejor modo para llevar a cabo la invención

La Figura 2 ilustra un sistema ejemplar en el que las diversas realizaciones de la presente invención pueden ponerse en práctica. Sin embargo, debería entenderse que la presente invención no está limitada al mismo siendo igualmente aplicables otras arquitecturas de sistema para la práctica de la invención. Un terminal 102 está conectado a una red 108 de IP. El terminal 102 puede ser, sin limitación, un ordenador personal o similar que ejecuta RTP/UDP/IP, y que proporciona muestras de voz empaquetadas en paquetes de RTP para transmisión a través de la red 108 de IP. El terminal 102 incluye un punto final 104 de RTP que identifica este terminal (por ejemplo, que incluye la dirección de IP, número de puerto, etc.) como una fuente y/o destino para paquetes de RTP. Aunque la red 108 de IP se proporciona como un ejemplo de una red de paquetes, sin embargo, pueden usarse otros tipos de redes con conmutación de paquetes o similares en lugar de la misma. El terminal 102 incluye también 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 de IP. Las ANI son entidades de red y nodos de red. 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 130 y 150 inalámbricos) están acoplados mediante enlaces 140 de frecuencia de radio (RF) a las ANI 110 y 120. Cuando uno de los terminales 130 y/o 150 móviles se mueve, es necesario de vez en cuando para el terminal o terminales móviles, como una consecuencia del movimiento más allá de la conexión de radio con una ANTI, para transferirse a otra ANI. Este proceso requiere también, cuando se usa compresión y descompresión de encabezamientos y se localiza en la ANI, la transferencia de información de contexto de compresión y descompresión de una ANI (antigua) a otra ANI (nueva) para conseguir continuidad, por ejemplo si los terminales 130 y/o 150 móviles se mueven y se transfieren de la ANI 110 a la ANI 120. La transferencia, como se analiza a continuación, puede ocurrir en diversos tiempos pero para minimizar la interrupción, debería completarse en el tiempo en que la nueva ANI se hace cargo del papel de compresión/descompresión de encabezamientos de la ANI antigua. La relocalización de funciones de compresión/descompresión aparece cuando la nueva entidad de red se hace cargo en un punto en el tiempo. Por otro lado, la transferencia de información de contexto puede extenderse a través de un tiempo material y precede a la relocalización. El enlace 140 de RF incluye, como se ilustra, un tráfico 142 de enlace ascendente (desde los terminales 130 y 150 móviles a la ANI 110) y tráfico 144 de enlace descendente (desde la ANI 110 a los terminales 130 y 150 móviles). Los terminales 130 y/o 150 móviles se transfieren de una ANI, tal como la ANI 110 cuando uno o más de los terminales móviles se mueven a otra ANI, por ejemplo la ANI 120. Cada ANI hace de interfaz con uno o más de los terminales (incluyendo el terminal 130) inalámbricos (o de frecuencia de radio) en una región para la red 108 de IP, incluyendo convertir entre señales de línea alámbrica (proporcionadas desde la red 108 de IP) e inalámbrica (proporcionadas a o desde los terminales 130 y 150). Por lo tanto, cada ANI permite a los paquetes, tales como, pero sin limitación, paquetes de RTP transmitidos y recibidos desde la red 108 de IP enviarse a través del enlace 140 de RF a al menos uno de los terminales 130 y 150 inalámbricos, y permite transmisión de paquetes, tales como paquetes de RTP pero sin limitación a paquetes de RTP, transmitirse desde los terminales 130 y 150 para transmitirse mediante la red 108 de IP a otro terminal, tal como el terminal 102.

Cada ANI incluye una pluralidad de entidades. La descripción y explicación más detallada de la ANI 110 se proporciona para facilitar el entendimiento de la arquitectura y operación de todas las ANI en la red. Todas las ANI pueden ser de la misma arquitectura como la ANI 110 pero no se ilustran en el mismo grado de detalle. La ANI 110 incluye uno o más adaptadores de ANI (ANI_AD), tal como el ANI_AD 112 (ilustrado en detalle) y el ANI_AD 114, cada uno de los cuales incluye preferentemente un temporizador 113 para proporcionar una indicación de tiempo. Cada ANI_AD realiza compresión (antes del tráfico de enlace descendente) y descompresión (después del tráfico de enlace ascendente) de encabezamientos. Los encabezamientos (uno o más campos de encabezamiento, tales como una indicación de tiempo y el número de secuencia) para los paquetes de RTP recibidos desde la red 108 de IP se comprimen mediante el ANI_AD 112 antes de la transmisión a los terminales 130 y 150 a través del tráfico 142 de enlace descendente, y los encabezamientos de paquetes recibidos desde los terminales 130 y 150 móviles se descomprimen mediante el ANI_AD 112 antes de transmisión a la red 108 de IP. El 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. El ANI_AD 110 hace de interfaz con terminales localizados en un área específica o diferente en la región para la red 108 de IP. El ANI_AD 112 incluye un temporizador 113 para implementar una técnica de descompresión basada en temporizador. El ANI_AD 112 incluye también una función 116 de reducción

15

25

35

45

55

65

E00970868

16-12-2014

de fluctuación (JRF) que funciona para medir la fluctuación en paquetes (o encabezamientos) recibidos a través de la red 108 y descarta cualquier paquete/encabezamiento que tiene fluctuación excesiva.

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

Los paquetes de RTP, incluyendo paquetes con encabezamientos comprimidos y no comprimidos, se transmiten en la red tal como, pero sin limitación, la red ejemplar de la Figura 2 a través de un enlace de datos (tal como el enlace 140 inalámbrico) donde el ancho de banda es muy preciado y los errores no son poco 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 alámbricos, etc.).

La Figura 3 ilustra conceptualmente información y ejemplos de contexto de compresión. La información de contexto 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 usado mediante el compresor como una entrada al algoritmo de compresión para producir un encabezamiento comprimido y puede transmitirse de una entidad a otra entidad. La otra entrada es desde la fuente de encabezamiento de los encabezamientos a comprimir.

La Figura 4 ilustra conceptualmente información y ejemplos de contexto de descompresión. La información de 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 usado mediante la descompresión como una entrada al algoritmo de descompresión para producir un encabezamiento descomprimido y puede transmitirse de una entidad a otra entidad. La otra entrada es desde la fuente de encabezamiento de los encabezamientos a descomprimir.

Tanto las informaciones de contexto de compresión como de descompresión son dinámicas, es decir, pueden actualizarse mediante el compresor y el descompresor respectivamente. La frecuencia de las actualizaciones depende del esquema de compresión de encabezamientos. 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 entrante, o la recepción de realimentació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 de un encabezamiento de entrada.

La Compresión de Encabezamientos Adaptiva (ACE) es un marco general para compresión de encabezamientos robusta que puede parametrizarse para tener en cuenta la existencia/no existencia y características de rendimiento de un canal de realimentación. El marco incluye tres modos básicos de operación:

 Modo determinístico bi-direccional: este modo se usa en el caso donde existe un canal inverso ‘bien definido’,

que puede usarse para llevar diversos tipos de información de realimentación desde el descompresor al

compresor. Un ejemplo de tal realimentación desde el descompresor es el acuse de recibo (ACK), usado, por

ejemplo, para avanzar desde un estado de compresión inferior a un estado de compresor superior. Mediante la

recepción de ACK mediante un canal bien definido, el compresor obtiene el conocimiento de que se ha recibido

algún encabezamiento específico. El compresor se aprovecha de ese conocimiento para comprimir más

fiablemente y más eficazmente.  Modo oportunístico bi-direccional: este modo de operación 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.

Existen muchas aplicaciones importantes que son bi-direccionales bilaterales. Un ejemplo principal es la voz o el

vídeo conversacional. En tales casos, existe intrínsecamente un canal inverso, que puede llevar la

realimentación.

E00970868

16-12-2014

 Modo unidireccional (pesimista u optimista): este modo de operación se usa cuando no existe canal inverso de ningún tipo. Puesto que no existe realimentación en absoluto desde el descompresor en relación con su estado actual, el compresor debe enviar ocasionalmente alguna información de refresco al descompresor, que puede usarse para re-establecer sincronismo en el caso de que algo haya ido mal. Dependiendo de diversos factores

5 (por ejemplo, condiciones de canal), que pueden conocerse para el compresor, el enfoque en este modo podría ser pesimista (refrescos más frecuentes) u optimista (refrescos menos frecuentes). Además, existen eventos que pueden activar al compresor para que envíe información de FH, para refrescar el descompresor y reducir la posibilitad de descompresión incorrecta.

El compresor de ACE puede caracterizarse como que progresa a través de una serie de estados. El compresor deja un estado de compresión inferior y entra en un estado de compresión superior cuando tiene suficiente confianza de que el descompresor ha recibido alguna información.

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

 Estado de encabezamiento completo (FH): el compresor entra en este estado cuando el tiempo de inicialización

o cuando aparece algún evento excepcional (avería de CPU o pérdida de memoria). En este estado, el compresor transmite esencialmente información de encabezamientos de FH al descompresor. Un encabezamiento de 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 de que el descompresor ha recibido la información de encabezamiento de FH. Los paquetes de FH son los menos óptimos para transmitir debido a su gran tamaño

25 (por ejemplo, al menos 40 bytes para IPv4, 60 bytes para IPv6). El compresor deja este estado y entra en el estado de FO cuando tiene suficiente confianza de que el descompresor ha recibido correctamente un encabezamiento de FH. Esa confianza podría 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 de FH. En este estado, el compresor transmite esencialmente información de encabezamientos de FO. Un encabezamiento de FO contiene campos específicos de compresor/descompresor y alguna información que describe cambios irregulares que han aparecido en los campos variables esenciales. El compresor permanece en este estado hasta que ha adquirido suficiente confianza de que la información de encabezamiento de FO se ha recibido mediante el descompresor. Esa confianza podría venir, por ejemplo, de la

35 recepción de acuses de recibo desde el descompresor o enviando un número predefinido de FO.  Estado de Segundo Orden (SO): el compresor está en este estado cuando el encabezamiento a comprimirse se ajusta al patrón de una cadena, y el compresor está suficientemente confiado de que el descompresor ha adquirido el patrón de cadena. En este estado, el compresor transmite encabezamientos de SO. Un encabezamiento de SO contiene esencialmente solo un número de secuencia. El modo de operación preferido para el compresor/descompresor es la transmisión/recepción de paquetes de SO, debido a su mínimo tamaño (en el orden de solo unos pocos bits). En resumen, una sesión se inicia con el compresor en el estado de 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 de FO o de SO. En el estado de FO, envía la

45 información de actualización de campos variables esencial necesaria al descompresor. En el estado de SO, envía mínima información al descompresor. El descompresor hace una extrapolación sencilla basándose en la información intercambiada en los paquetes de FH y de SO previos hasta que la cadena finaliza. Cuando se inicia otra cadena, el compresor entra el estado de FO de nuevo y el proceso se repite. Los modos de transmisión bi-direccional utilizan acuses de recibo para diversas funciones:  para informar al compresor que se ha recibido la información de FH; en ese caso, el compresor conoce que el descompresor ha adquirido la información necesaria para descomprimir encabezamientos de FO y por lo tanto el compresor puede pasar fiablemente al estado de compresión superior, FO; este tipo de ACK se denomina como FH-ACK para informar al compresor que se ha recibido información de FO; en ese caso, el compresor conoce que el descompresor ha adquirido la información necesaria para descomprimir encabezamientos de SO y por lo

55 tanto el compresor puede pasar fiablemente al estado de compresión superior, SO; este tipo de ACK se denomina como FO-ACK para informar al compresor que se ha recibido un encabezamiento con un número específico n; en ese caso, el compresor conoce que el descompresor puede determinar el número de secuencia sin ninguna ambigüedad producida mediante la continuación del ciclo del contador hasta el número de encabezamiento n + seq_cycle, donde seq_cycle es el ciclo de contador; el compresor puede usar fiablemente k bits para el número de secuencia de encabezamiento, sin preocupaciones de ambigüedades o decodificación de número de secuencia incorrecta en el descompresor; este tipo de ACK se denomina SO-ACK.

El control del paso de los estados de FH a FO a SO mediante acuses de recibo asegura que no exista propagación de errores. Es decir, un encabezamiento comprimido que no se recibió en error puede descomprimirse siempre

65 correctamente, puesto que la sincronización nunca se pierde.

15

25

35

45

55

65

E00970868

16-12-2014

Existe una gran cantidad de flexibilidad con respecto a cuándo y con qué frecuencia el descompresor envía los acuses de recibo. La ACE es también extremadamente resistente a que los ACK se pierdan o retarden. El compresor adapta constantemente su estrategia de compresión basándose en la información actual a comprimir y los ACK recibidos. Por ejemplo, la pérdida o retardo de un FO-ACK puede dar como resultado que el compresor permanezca más tiempo en el estado de FO. La pérdida o retardo de un SO-ACK puede dar como resultado que el compresor envíe más bits para el número de secuencia, para evitar cualquier descompresión incorrecta en el descompresor producida mediante la continuación del ciclo del contador.

Los ACK pueden transmitirse periódicamente o no periódicamente. La frecuencia de los acuses de recibo no periódicos puede disminuirse o aumentarse a partir de una velocidad periódica. Puede enviarse un ACK menos frecuentemente puesto que los ACK se pierden debido a errores o congestión de red, o los ACK pueden no transmitirse debido la disponibilidad intermitente del canal inverso o a algunas condiciones del descompresor. Un ACK puede transmitirse también más estrechamente espaciado que los ACK periódicos tradicionales. Por ejemplo, cuando el canal inverso está muy ligeramente cargado y disponible, el descompresor puede transmitir ACK más a menudo y como resultado el compresor puede operar más eficazmente y fiablemente.

En consecuencia, el canal de realimentación utilizado para transmitir los ACK puede tener requisitos muy flexibles. Esto es puesto que los ACK únicamente tienen un efecto en la eficacia de compresión, no en la corrección. El retardo o la pérdida de los ACK puede producir que el tamaño de los encabezamientos comprimidos aumente, pero incluso en tales casos el incremento es logarítmico.

En el modo determinístico bi-direccional, el paso del FH/FO al FO/SO está basado en acuse de recibo. En el modo unidireccional, nunca se envía un ACK, por lo que el número de paquetes de FH/FO que se envían antes de pasar al estado de FO/SO depende de un valor predefinido o uno seleccionado dinámicamente/adaptativamente. En el modo oportunístico bi-direccional, el ACK puede llegar tarde, por lo que el paso de FH/FO a FO/SO no es está basado estrictamente en ACK, sino que depende de cualquiera que venga en primer lugar de 1) transmisión de un número predefinido o seleccionado dinámicamente/adaptativamente de FH/FO, o 2) recepción de al menos un ACK.

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

La Figura 15 ilustra la conmutación del estado de compresión del compresor basándose únicamente en la llegada de un ACK apropiado. Una secuencia de al menos un encabezamiento de un estado particular que, como se ilustra sin limitación son los encabezamientos de FH o de FO, se transmite al descompresor. El descompresor, tras recibir el primer encabezamiento de FH(n) o de FO(n) (podría ser un encabezamiento distinto del primer encabezamiento) transmite de vuelta un Ack(n) que, tras la recepción, produce al compresor pasar a un estado de compresión superior que, 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 del ACK(n).

Las Figuras 16 y 17 ilustran la conmutación del estado de compresión del compresor basándose en un parámetro m que es un número de encabezamientos transmitidos o ACK (conmutar acceso siempre que se transmitan m encabezamientos de FO/FH o se reciba el ACK). La realización de la Figura 16 no está limitada a la transmisión de encabezamientos de FH/FO/SO mediante el compresor. En la Figura 16, llega un ACK(n) antes de que el número de encabezamientos de FO/FH transmitidos alcance m, que como el resultado del número preestablecido de encabezamientos de FH/FO que se transmiten, produce que el compresor conmute a un estado de compresión superior y transmita el paquete FO(n+i) o SO(n+i). La realización de la Figura 17 no está limitada a la transmisión de encabezamientos de FH/FO/SO mediante el compresor. En la Figura 17, llega un ACK después de que se transmiten m encabezamientos.

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

Bajo diferentes modos, la estrategia de operación del compresor y el descompresor es diferente.

Modos de operación del compresor

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

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 menos comprimido, por ejemplo, aumentando la longitud de los campos de

codificación, y únicamente puede conmutar de vuelta a un modo más comprimido después de que recibe ACK

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

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

E00970868

16-12-2014

comprimido a un estado más comprimido basándose en otros criterios, por ejemplo, enviando un cierto número de encabezamientos menos comprimidos, en lugar de la recepción del ACK.  No basado en ACK: el compresor normalmente opera en este modo cuando no está disponible el canal inverso. En este modo, el criterio para pasar de un estado menos comprimido a un estado más comprimido no está

5 basado en ACK. En su lugar, el compresor puede conmutar de un estado menos comprimido a un estado más comprimido después de que se haya transmitido un cierto número de encabezamientos menos comprimidos. Tal número puede ser un parámetro ajustable. Además, existen eventos que pueden activar al compresor para enviar menos información comprimida para refrescar al descompresor y reducir la posibilidad de descompresión incorrecta.

Modos de operación del descompresor

 Enviar ACK determinístico: en este modo, el descompresor envía periódicamente ACK y cuando recibe paquetes de FH/FO. Además, el descompresor puede enviar ACK de vuelta al compresor más frecuentemente que 15 periódicamente cuando el canal inverso está ligeramente cargado y disponible.

 Enviar ACK oportunístico: en este modo, el descompresor no envía estrictamente ACK 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 de IP) a través de sistemas celulares. Cuando se aplica la VoIP a sistemas celulares, es importante minimizar la tara del encabezamiento de IP/UDP/RTP debido al ancho de banda limitado de la interfaz inalámbrica o aérea (RF). En un sistema de este tipo, por ejemplo, los ANI_AD

25 hacen de interfaz de la red IP a un terminal informático que ejecuta RTP/UDP/IP (por ejemplo, el terminal 130) que tiene una interfaz celular o de RF para recibir paquetes de RTP a través del enlace inalámbrico o de 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 mediante el compresor y llevado en los encabezamientos. El número n siempre se incrementa en 1 para cada nuevo paquete e independiente del número de secuencia de RTP. Obsérvese que n puede codificarse en k-bits (=(CD_SN)k ) o ℓ_extendido bits ( = (CD_SN)ℓ_extendido ). CD_SN 139: contador interno que corresponde a n. El compresor y el descompresor mantienen sus contadores.

35 El tamaño de los contadores internos puede elegirse suficientemente grande para evitar cualquier ambigüedad para 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)ℓ_extendido: ℓ_extendido bits menos significativos de CD_SN. (CD_SN)ℓ_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 mediante el descompresor; S_RFH se actualiza continuamente mediante el compresor basándose en la realimentación desde el descompresor. S_RFH se envía en la forma de k o ℓ_extendido bits menos significativos. N_elapsed: un contador mantenido mediante el compresor para seguir el número de paquetes que se han enviado desde el

45 último paquete que se realizó un ACK. N_elapsed = CD_SN actual -S_RFH, si S_RFH se establece siempre igual al último paquete que se realizó ACK mediante el compresor cuando recibe un ACK. R_RFH: CD_SN del paquete de referencia en el descompresor, que se establece igual a S_RFH cuando se recibe un paquete de FO(n, S_RFH). SN(n): el número de secuencia de RTP del enésimo paquete enviado mediante 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 en valores de bit de los k o ℓ extendido bits. TS(n): la indicación de tiempo de RTP del enésimo paquete enviado mediante 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

55 (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 que corresponde a la interrupción más reciente (es decir cambio no lineal). Se actualiza (mediante 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 mediante el compresor para determinar si el encabezamiento actual se ajusta al patrón. El encabezamiento actual n se ajusta al patrón si 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 en una base

65 dinámica. TS_DFOD y SN_DFOD: los componentes en S_DFOD que corresponden a la indicación de tiempo de RTP y al

E00970868

16-12-2014

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 mediante el descompresor para descomprimir encabezamientos de 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

5 determinar R_DFOD en una base dinámica. Por diseño, S_DFOD y R_DFOD son siempre iguales durante el estado de SO. Extended_flag: una bandera mantenida mediante el compresor. Si es VERDADERO, entonces se usa ℓ_extendido bits para 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 esta bandera en sí misma se lleva también en los encabezamientos de modo que el descompresor conoce qué codificación CD_SN se usa. Encabezamiento(n): un término usado genéricamente para significar la información de encabezamiento enviada mediante el compresor. Encabezamiento(n) puede enviarse 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)ℓ_extendido, dependiendo de la bandera extendida.

15 Diff(n2, n1): la verdadera distancia entre n2 y n1, que se codifica como (CD_SN)k o (CD_SN)ℓ_extendido. Diff(n2, n1) = CD_SN(n2) -CD_SN(ni), donde CD_SN(n2) y CD_SN(n1) son los CD_SN que corresponden a n2 y n1 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 mediante el descompresor para pedir al compresor operar en el estado de FH. Esto se usa, por ejemplo, cuando el descompresor acaba de recuperarse de una avería 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. Seq_cycle: Seq_cycle-1 es el máximo número alcanzado mediante el número de secuencia antes de continuar el ciclo y volver a 0. Seq_cycle = 2k.

25 SEC Ext_cycle: = 2 ℓ_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 podrían haberse 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 mueve también el Encabezamiento(p=n) al Encabezamiento(S_RFH). Los campos estáticos no necesitan almacenarse como múltiples entradas en la HSW. Únicamente es necesaria una única copia de los campos estáticos. Obsérvese que en la HSW, cada encabezamiento se marca 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 ℓ extendido bits. En la implementación, puede usarse una

35 bandera de 1 bit para almacenar el color. El color se usa para ayudar al compresor a identificar únicamente un encabezamiento cuando se 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 no se conoce con seguridad que los ACK se reciben mediante el compresor. La ventana se denominará como la ventana de Ack pendiente (OAW). Los campos estáticos no necesitan almacenarse como múltiples entradas en la OAW. Únicamente es necesaria una única copia de los campos estáticos. R_Last_Decomp: el CD_SN del último paquete reconstruido mediante el descompresor. El descompresor mantiene el encabezamiento completo correspondiente que se denomina como FH(Last_Decomp). Obsérvese:

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

 El campo longitud total del encabezamiento de IP (2 bytes) se sustituye con extended_flag (1 bit), seq_num (4 u 8 bits) y otra información opcional. Si extended_flag es igual a 1, seq_num es de 8 bits de largo, es decir el paquete se envía en modo extendido.

 El campo longitud en el encabezamiento de UDP (2 bytes) se sustituye también con el ID de contexto para compresión de encabezamientos, denominado como CID. El compresor puede comprimir simultáneamente múltiples flujos de RTP independientes entre sí. A cada flujo se asigna un único CID. En la implementación, el CID podría ser de 1 byte o 2 bytes de largo, dependiendo del máximo número de

55 flujos de RTP en cualquier momento dado.

Una primera realización de la invención, que puede ponerse en práctica con el sistema de la Figura 2, aumenta la probabilidad de recepción de paquetes de tipo de FH y FO de modo que existe una progresión oportuna hacia el estado de SO más óptimo. La probabilidad de recepción puede aumentarse aplicando protección de errores adicional a los paquetes de FH y FO en la forma de

 Códigos de corrección de errores  Códigos de corrección de errores + intercalado  Duplicar transmisión de datos de encabezamientos de FH y FO

65

15

25

35

45

55

65

E00970868

16-12-2014

La primera realización de la invención proporciona protección extra frente a pérdida de paquetes de datos a través de un medio de transmisión con pérdidas, por ejemplo inalámbrico sin asignar recursos de canal adicionales al compresor y al descompresor. El ancho de banda extra se obtiene retardando la transmisión de la corriente de datos en algún intervalo de tiempo, ‘T’, como se ilustra en las Figuras 5A y 5B, de manera que existe suficiente tiempo para enviar los paquetes de datos extra. El intervalo de retardo puede usarse para enviar paquetes de FH iniciales y paquetes de FO en cualquier momento.

Transmisión de paquetes de FH iniciales: se supone que el ancho de banda en el canal de comunicación se ha asignado bajo la suposición de que se transmitirán principalmente paquetes de FO y SO (es decir, se transmiten muy pocos paquetes de FH). Esto es una suposición razonable en la mayoría de los casos, ya que la efectividad del esquema de compresión en su conjunto depende de la operación principalmente en el estado de SO. Sin embargo, existe siempre una necesidad para enviar algún número de paquetes de FH (idealmente, solamente uno) en el inicio de una sesión. El tamaño de un paquete de FH es significativamente más que el de los paquetes de SO o FO. Esto significa que se requiere ancho de banda adicional para entregar el paquete en el mismo periodo de tiempo que el asignado para los paquetes de SO y FO. La transmisión de parte del paquete de FH aparece en el canal primario y el resto en algún canal secundario.

El intervalo de retardo anteriormente mencionado, ‘T’ ilustrado en las Figuras 5A y 5B, se utiliza para transmitir los datos adicionales llevados en un paquete de FH. Hacer esto elimina la necesidad de usar un canal secundario. Los ahorros pueden ser significativos, ya que el canal secundario puede ser difícil (en términos de protocolo), costoso (si necesita ser un canal especializado que se usa únicamente ocasionalmente) y lento de establecer (si necesita ser un canal basado en paquetes compartido, podrían observarse retardos de contienda indeseados). Obsérvese que, dependiendo del valor de ‘T’ y el tamaño de los bloques de transmisión, puede ser posible incluir la codificación de corrección de errores (ECC) en el bloque de ancho de banda ‘extra’ también.

Transmisión de paquetes de FO: este esquema es aplicable únicamente cuando la necesidad de transmitir el paquete de FO coincide con una pausa en la transmisión de la corriente de datos. Puesto que, por definición, los paquetes de FO se generan cuando existe una interrupción en el flujo de datos normal, esta condición casi siempre se cumple. Por ejemplo, los intervalos de silencio producen saltos irregulares en la indicación de tiempo de RTP que puede activar la transmisión de paquetes de FO.

El transmisor o transmisores/receptor o receptores (compresor o compresores/descompresor o descompresores de la Figura 2) pueden operar en un estado más óptimo cuando se usa protección de errores adicional. En la técnica anterior, aparece menos operación frecuente en el estado de SO óptimo.

La penalización para esta operación aumentada en el estado óptimo es un retardo fijo que siempre está presente en la corriente de datos. Sin embargo, este retardo puede tolerarse fácilmente en los límites específicos a los datos que se transmiten.

Como un ejemplo, suponer que datos de habla + datos de encabezamiento de tipo de FO se ajustan fácilmente en un bloque de transmisión celular de tamaño de p bytes, que corresponden a un intervalo de tiempo equivalente a 20 ms. Suponiendo un retardo, se aplica ‘T’ = 20 ms de la manera anteriormente descrita, es posible enviar el FO + datos de habla + una cantidad equivalente de datos para aumentar la probabilidad de recepción. Algunas configuraciones posibles son:

 Datos de habla + encabezamiento de tipo de FO + bits de código convolucional de tasa ½ se envían para

aumentar la probabilidad de recepción de datos. Esto aumenta considerablemente la probabilidad de recepción

correcta. Un código de tasa ½ utiliza completamente el ancho de banda adicional permitido mediante el retardo.  Dos copias idénticas de los datos de habla + encabezamiento de tipo de FO pueden enviarse; que aumenta la

probabilidad de recepción, particularmente cuando el medio de transmisión están sometido a pérdida de

paquetes aleatoria.

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

15

25

35

45

55

65

E00970868

16-12-2014

El compresor usa como un encabezamiento de referencia un encabezamiento que se conoce que se descomprimió correctamente basándose en acuses de recibo (ACK) recibidos como se ilustra en general en la Figura 6. El compresor envía una serie de paquetes de encabezamientos completos FH(n)…FH(n+i+1)… que cubren una secuencia de tiempo justo anterior a t2 tiempo en el que se recibe el acuse de recibo ACK(n) producido mediante el compresor que recibe el paquete de encabezamiento completo FH(n). El paso de FH a FO (FO(n+j) como se ilustra) es síncrono. La secuencia de tiempo a t2 depende del tiempo de transmisión de radio de ida y vuelta.

La Figura 7 ilustra el paso del compresor 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 mediante el descompresor antes de que el compresor pase de manera síncrona a los paquetes de segundo orden SO (SOn+j) con un retardo de radio de ida y vuelta para el tiempo t2 requerido para sincronización. El número de ACK requeridos mediante el compresor antes de pasar del estado de FO al estado de SO depende de las variaciones entre los paquetes. Por ejemplo, si la variación entre los paquetes es lineal con parámetros constantes, únicamente se requiere un ACK para pasar del estado de FO al estado de SO. Para poder descomprimir el encabezamiento actual, el descompresor únicamente necesita conocer el encabezamiento de referencia en lugar del encabezamiento inmediatamente anterior como con el RFC 2508. En este esquema, el compresor envía encabezamientos completos (encabezamientos de tipo de FH) en la inicialización. Envía información de diferencia de primer orden (encabezamientos de tipo de FO) cuando no se aplica extrapolación lineal. Sin embargo, el compresor no transmite encabezamientos de diferencia de SO hasta que se ha realizado acuse de recibo del FH o del FO anteriores, y se aplica extrapolación lineal.

En el compresor, se define el paquete de referencia para que sea el último cuyo ACK se haya 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 hace con referencia a ese paquete, hasta que se recibe un nuevo ACK, punto en el cual el paquete que al se acaba de realizar ACK se hace el nuevo paquete de referencia. La memoria en el transmisor donde se almacenan los posibles paquetes de referencia 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 de 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 acuse de recibo pendiente (OAW) representada como la entidad 135 de la Figura 2. Posteriormente, cuando se recibe un encabezamiento de diferencia de FO, el descompresor determinará el paquete de referencia a partir del número de secuencia de referencia, recupera el paquete de referencia correspondiente desde la OAW 135 y lo usa para reconstruir el encabezamiento completo.

La invención usa la linealidad de las indicaciones de tiempo de RTP generadas en el compresor que siguen estrechamente un patrón lineal como una función de la hora del día. Basándose en el temporizador 134 mantenido en el descompresor del receptor y usando un número de secuencia extendido para paquetes de FO definido mediante ℓ extendido bits, puede detectarse y recuperarse toda una pérdida larga en un umbral.

Suponiéndose con el habla, si el intervalo de tiempo entre las muestras y paquetes de habla consecutivos es t ms, entonces la indicación de tiempo de RTP del encabezamiento n (generada en el tiempo n* t ms) es igual a la indicación de tiempo de RTP del encabezamiento 0 (generada en el tiempo 0) más TS_stride * n, donde TS_stride es una constante que depende de un códec de voz de la fuente de voz del transmisor. En consecuencia, la indicación de tiempo de RTP en los encabezamientos recibidos mediante 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 retardo entre el compresor y el descompresor. En operación normal (ausencia de averías o fallos), la fluctuación de retardo está limitada, para cumplir los requisitos de tráfico en tiempo real conversacional.

Aparece una cadena como una secuencia de encabezamientos que todos se ajustan a un patrón particular. Específicamente, el número de secuencia de RTP (SN) se incrementa en 1 desde un encabezamiento al siguiente. La indicación de tiempo de RTP (TS) no disminuye, y sigue algún patrón predecible: si los encabezamientos n1 y n2 están en la misma cadena, la TS del encabezamiento n2 puede obtenerse de la TS del encabezamiento n1 y la función del patrón. Los otros valores de campo, excepto quizás para la 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, se ha descomprimido correctamente, los encabezamientos posteriores en la misma cadena pueden descomprimirse mediante 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 adquirido mediante el descompresor, solamente tiene que enviar un número de secuencia de k-bit, indicado (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 (CD_SN) de secuencia de descompresor mayor (compresor).

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. Basándose en tal información de temporización y la regla de compresión particular que se usa mediante el compresor junto con el número de

E00970868

16-12-2014

secuencia, el descompresor puede detectar y/o recuperarse de la pérdida larga.

Sea

5  HDR(i) el encabezamiento con el número de secuencia corto i  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 de la TS de RTP cada t ms  SEQ_CYCLE el ciclo del número de secuencia usado en HDR

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

Se define como sigue:

 DIFF(n2,n1) = n1 cuando n2n1 15  DIFF(n2, n1) = n2+2k-n1 cuando n2ni

Tras recibir el HDR(n2) justo después de recibir el HDR(n1), el descompresor determina si ha ocurrido o no una pérdida larga entre estos dos paquetes, es decir, si existen o no DIFF(n2, n1) paquetes perdidos o si existen SEQ_CYLE * p + DIFF(n2, n1) (p1) paquetes perdidos. El esquema de detección también está basado en el tipo de

20 HDR(n2). Basándose en 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) 25 Detección y recuperación de pérdida larga para el caso 1

Para detectar si existen o no pérdidas largas 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

30  T el tiempo cuando se recibe el HDR(n1)  T+T el tiempo cuando se recibe el HDR(n2)

El compresor envía paquetes de SO únicamente si el uno o más paquetes de FH o FO anteriores se les ha realizado

35 acuse de recibo, y se aplica también extrapolación lineal desde el encabezamiento al que se realizó acuse de recibo. Por lo tanto, si el HDR(n2) es de SO y no importa de qué tipo es el HDR(n1), se aplica extrapolación lineal desde el HDR(n1) al HDR(n2). Esto significa básicamente que la indicación de tiempo de RTP y el número de secuencia de RTP para el paquete n1 hasta el n2 cuando se generaron en el compresor, siguen estrechamente un patrón lineal como una función de la hora del día. En consecuencia, los encabezamientos que llegan al descompresor también

40 siguen un patrón lineal como una función del tiempo, pero con fluctuación debido a la fluctuación entre el transmisor y el receptor.

Bajo la suposición de que el límite superior de la fluctuación es siempre menor que (SEQ_CYCLE * t) ms, se aplica la siguiente regla para detectar pérdidas largas: 45 [Regla 1]

 si (DIFF(n2,n1) * t ms T  (DIFF(n2,n1) + SEQ_CYCLE) * t ms ), únicamente se pierden DIFF(n2,n1) paquetes;  si ((DIFF(n2,n1) + SEQ_CYCLE) * t ms T  (DIFF(n2,n1) + 2 * SEQ_CYCLE) * t ms ), se pierden (SEQ_CYCLE 50 + DIFF (n2,n1)) paquetes;  En general, si ((DIFF(n2,n1) + i * SEQ_CYCLE) * t ms T  (DIFF(n2,n1) + (i +1) * SEQ_CYCLE) * t ms), se pierden (i *SEQ_CYCLE + DIFF(n2,n1)) paquetes;

Para recuperar la indicación de tiempo de RTP y el número de secuencia de RTP de tal pérdida larga, únicamente 55 es necesario el número de paquetes perdidos.

Sea

 Nperdidos el número de paquetes perdidos entre el paquete n1 y el paquete n2 que puede obtenerse basándose en 60 la regla 1  TS(i) y SEQ(i) son la indicación de tiempo de RTP y el número de secuencia de RTP del paquete i

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

imagen1

E00970868

16-12-2014

SEQ(n2) = SEQ(n1) + Nperdidos

5 La Figura 8 ilustra una realización de la invención que detecta y se recupera de pérdidas largas en el caso 1 para detectar pérdidas largas cuando aparece una continuación de ciclo 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 el HDR(n) que se envía en el tiempo 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 tiempo t3. Puesto que el paquete n+1

10 enviado en el tiempo t3 es un paquete de SO que indica que todos los paquetes enviados desde t0 a t3 cayeron en la misma cadena, es decir el número de secuencia de RTP Sn(n) de estos paquetes sigue un patrón lineal como una función del tiempo de la hora del día, puede detectarse el número de paquetes perdidos entre t0 y t3 mediante el temporizador 134 mantenido en el descompresor. El procedimiento es como sigue:

15 Suponiendo que el intervalo de tiempo entre muestras y paquetes de habla consecutivos es t ms., el descompresor inicia su temporizador 134 local (con el valor ts) cuando recibe el HDR(n) enviado en el tiempo t0, a continuación el temporizador aumenta basándose en el reloj del día. Cuando se recibe el SO(n+1) enviado en el tiempo t3 en el descompresor, el temporizador alcanzaría t0 que aproximadamente es igual a ts+(2k+1)t debido a la fluctuación. Ya que la diferencia temporal entre ts y tc (alrededor de (2k+1)t) es mayor que t ms., el paquete n

20 enviado en el tiempo t0 y el paquete n+1 enviado en tiempo t3 no serán paquetes enviados consecutivamente y ocurre una pérdida larga entre estos dos paquetes. Además, ya que la diferencia de tiempo entre ts y te es menor que (2k+1+1)t, no será más de un ciclo de secuencia de pérdida de paquetes. Por lo tanto, el descompresor puede concluir que existen 2k paquetes perdidos.

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

El esquema de detección y recuperación de pérdidas largas no se puede aplicar al caso 2 donde se recibe el encabezamiento de FO después de un encabezamiento de SO, FO o FH. En este caso, incluso si la diferencia de tiempo t entre el paquete n2 y n1 es mayor que (DIFF(n2,n1) + SEQ_CYCLE) * t ms, no significa que ocurrió la 30 pérdida larga puesto que puede deberse al periodo de silencio del compresor. En este caso, basándose en la información proporcionada en el encabezamiento de FO, puede regenerarse la TS del RTP satisfactoriamente, pero no el número de secuencia de RTP puesto que no puede distinguirse la pérdida larga o el silencio solamente basándose en la temporización. Para resolver este problema, se usa un número de secuencia extendido que tiene ℓ_extendido bits (ℓ_extendidok bits no extendido) para los primeros paquetes de FO en una serie de FO donde

35 todos los paquetes pertenecen a la misma cadena, hasta que exista el ACK para el FO enviado de vuelta desde el descompresor. Este esquema detecta y se recupera de pérdidas largas bajo la suposición que el límite superior de la pérdida larga es menor de 2ℓ_extendido * t ms.

Para implementar este esquema, se mantiene un contador interno CD_SN 139 para paquetes mediante el

40 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 en el encabezamiento comprimido es solo una instantánea de los k no extendido o ℓ_extendido bits menos significativos del CD_SN 139. Basándose en la regla del esquema de compresión/descompresión de encabezamientos, el descompresor puede reconstruir el número absoluto actual de paquetes recibidos.

45 Sea

CD_SN_LAST el número de paquetes absoluto del último paquete recibido, es decir, paquete n1;

50 CD_SN_CURR el número de secuencia absoluto para el paquete de FO actual, es decir, el paquete n2; y

DIFF(CD_SN_CURR, CD_SN_LAST) definido como (CD_SN_CURR)-(CD_SN_LAST).

Basándose en la siguiente regla, puede detectarse satisfactoriamente una pérdida en el límite superior de 2ℓ_extendido * 55 t ms.

[Regla 2]

Si (DIFF(CD_SN_CURR, CD_SN_LAST)  2k, 60 se detecta una pérdida larga.

Puede calcularse el número de paquetes perdidos Nperdidos con la siguiente fórmula:

5

10

15

20

25

30

35

40

45

50

55

60

E00970868

16-12-2014

imagen2

Basándose en Nperdidos, puede regenerarse el número de secuencia de RTP mediante el descompresor bajo las siguientes fórmulas y puede regenerarse la indicación de tiempo de RTP basándose en el encabezamiento de referencia y el delta correspondiente.

imagen3

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 de FO hasta que vuelva del compresor el ACK para esta serie de FO.

Debería observarse que este esquema no puede detectar y recuperarse de pérdidas largas que son más largas de 2ℓ_extendido * t ms; por lo tanto, debería seleccionarse ℓ_extendido cuidadosamente de modo que pueda detectar la pérdida larga que no puede indicarse desde la capa inferior de la pila del protocolo. Si la gran pérdida es más larga de 2ℓ_extendido * t ms, se requiere que una capa inferior pueda proporcionar indicación de tal pérdida extremadamente larga y se aplica desconexión en la capa inferior u otros métodos de recuperación de pérdidas largas, por ejemplo, enviar una petición al compresor.

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

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

Si el paquete entrante es de tipo de FO, se aplica la regla 2 para comprobar si ha ocurrido o no una pérdida larga y debería usarse el esquema de recuperación correspondiente para la transmisión del paquete de FO para recuperarse de pérdidas largas si ocurrieron. No es necesaria información de temporización y el temporizador debería resetearse.

Si el paquete entrante es de tipo de SO, debería calcularse la diferencia de tiempo de llegada entre el paquete actual y el paquete anteriormente recibido de acuerdo con el temporizador, y se aplicará la regla 1 para comprobar si ocurrió o no pérdidas largas y debería usarse el esquema de recuperación correspondiente para transmisión de paquetes de SO para recuperarse de pérdidas largas si ocurrieron. El temporizador 134 (u otro temporizador) debería resetearse justo después de la comprobación.

En resumen, el uso del temporizador 134 (u otro temporizador) y un número de secuencia extendido para los primeros paquetes de FO pueden detectar satisfactoriamente y recuperarse de pérdidas largas en un umbral (2ℓ_extendido * t ms) y mejorar la robustez sin añadir demasiada tara y complejidad.

Una realización adicional de la invención, puesta en práctica con el sistema de la Figura 2, usa el hecho que los campos de IP/UDP/RTP son constantes o pueden extrapolarse 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 proporciona información suficiente para la extrapolación. Cuando la extrapolación diera 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 a errores y ráfagas de errores, el compresor codifica la información de actualización con respecto a un encabezamiento de referencia que se conoce que se descomprimió correctamente. El compresor conoce que un encabezamiento se descomprimió correctamente cuando recibe el acuse de recibo correspondiente. Un mecanismo de ACK asegura que el encabezamiento actual puede reconstruirse fiablemente incluso si se perdieron uno o más encabezamientos pasados.

Una cadena se define como una secuencia de encabezamientos que todos se ajustan a un patrón particular. El número de secuencia de RTP (SN) se incrementa en 1 de un encabezamiento al siguiente. La indicación de tiempo de RTP (TS) no se disminuye, y sigue algún patrón predecible. Si los encabezamientos n1 y n2 están en la misma cadena, puede obtenerse la 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 del 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 correctamente un encabezamiento n1, pueden descomprimirse los encabezamientos posteriores en la misma cadena mediante

15

25

35

45

55

65

E00970868

16-12-2014

extrapolación de acuerdo con el patrón. Una vez que se informa al compresor que se ha descomprimido satisfactoriamente un encabezamiento, y el patrón se ha adquirido mediante el descompresor (como se demuestra mediante los ACK), solo envía un número de secuencia, como un encabezamiento comprimido para los paquetes posteriores en la misma cadena.

En el caso de voz, la TS tiene un patrón de aumento lineal. Por lo tanto puede calcularse la 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 sucesivo entre los paquetes n2 y n1. Un intervalo de silencio corta la relación lineal y produce que una cadena termine. Se inicia una nueva cadena con una nueva secuencia hablada.

Por lo tanto el compresor pasa a través de 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 hacer la extrapolación, el compresor pasa 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 la cadena se finaliza. Cuando se inicia otra cadena, el compresor del transmisor entra en otra fase de actualización, y se repite el proceso completo. Los encabezamientos enviados en las fases de inicialización, actualización y extrapolación son de FH, FO y SO. Los FH, FO y SO todos llevan un número de secuencia incrementado en 1 en cada encabezamiento enviado mediante 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 de FH y ACK de FO respectivamente.

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

Si se codifica el anterior número de secuencia con k bits, continuará el ciclo cada seq_cycle encabezamientos (seq_cycle = 2k). Por lo tanto, si una ráfaga de errores dura más de la duración de seq_cycle encabezamientos, el descompresor no puede determinar sin ambigüedad el número de encabezamientos transcurridos solo a partir del número de secuencia, y en consecuencia no puede realizar la descompresión apropiada. Para tratar este problema de continuación del ciclo y ráfagas largas, se usan acuses de recibo (ACK) periódicos. La Figura 9 ilustra la operación de la invención usando los números de secuencia de k bits y números de bit de ℓ bits extendidos en asociación con acuses de recibo (ACK) periódicos que se generan de manera síncrona mediante el descompresor en cada 2k paquetes recibidos detectados. Suponiendo que el compresor recibe el ACK(n) para el paquete n antes de que envíe el paquete de SO n+i con un número de secuencia de k bits, el compresor está esperando otro ACK para el paquete (n+2k+N_RT) del descompresor antes de 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 ℓ bits y envía el paquete (n+i+2k+N_RT) con un número de secuencia de ℓ extendido bits. Cuando el descompresor recibe el paquete (n+i+2k+N_RT) con un número de secuencia ℓ 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 de k-bit. El descompresor espera para enviar un ACK a intervalos regulares, espaciados suficientemente estrechamente de modo que normalmente el compresor recibe un ACK al menos una vez cada 2k seq_cycle encabezamientos. El compresor mantiene un contador, N_elapsed, para seguir el número de paquetes transcurridos desde el último ACK que recibió. Si N_elapsed 2kseq_cycle encabezamientos, el compresor opera en modo extendido, donde se usan ℓ_extendido bits para el número de secuencia, en lugar de un número menor de k bits no extendido, con el número de ℓ_extendido bits  el número de k bits no extendido. El número de secuencia ℓ_extendido bit y el número reducido de k bits en el número de secuencia no extendido pueden observarse como los bits menos significativos del número de secuencia no extendido y siendo los ℓ_extendido bits los bits menos significativos del recuento CD_SN 139 del transmisor. Se indican (CD_SN) k y (CD_SN) ℓ_extendido respectivamente. N_elapsed se incrementará en 1 por cada paquete enviado mediante 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 que se retarde el ACK de una manera no periódica.

Para tener en cuenta el retardo de ida y vuelta, el descompresor del receptor necesita anticiparse cuando envía un ACK periódico. El descompresor tiene que enviar un ACK periódico suficientemente pronto para que el compresor reciba normalmente los ACK al menos una vez cada seq_cycle. Teniendo en cuenta el tiempo de ida y vuelta, el descompresor tiene que enviar los ACK al menos una vez cada (seq_cycle -N_RT) encabezamientos. La cantidad N_RT se calcula como EST_RTT/T_H, redondeado hasta el siguiente entero superior. La cantidad EST_RTT es una estimación del retardo de ida y vuelta actual calculada mediante el descompresor y puede evaluarse dinámicamente basándose en mediciones recientes, o simplemente establecerse a RTT_n (definido a continuación). En la práctica, T_H puede obtenerse a partir de las características del códec del transmisor o a partir del espaciado real observado.

15

25

35

45

55

65

E00970868

16-12-2014

Suposiciones

Para asegurar la 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 podría ser un enlace o una concatenación de enlaces (red o redes).

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

El canal puede realizar fragmentación en y reensamblaje en el descompresor, pero conserva y proporciona la longitud de los paquetes que se transfieren. Obsérvese que esta fragmentación es diferente de la fragmentación de IP.

Este esquema supone que existe 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 la detección de errores desde el canal, el esquema puede extenderse de una manera directa añadiendo un código de detección de errores en el nivel de compresor-descompresor. La corrección de errores es beneficiosa pero opcional.

El retardo de ida y vuelta entre el compresor y el descompresor se define como el tiempo para enviar y procesar un encabezamiento(n), para procesarlo, y devolver un ACK(n). Para evitar cualquier ambigüedad en qué mensaje original se está realizando el ACK, el ACK no debe experimentar un retardo de ida y vuelta tan largo que el (CD_SN)ℓ_extendido en la dirección directa haya continuado el ciclo. 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 hacen cumplir un límite de retardo en la transmisión del ACK, si fuera necesario descartando esos ACK que han permanecido en la cola durante demasiado tiempo. Basándose en estas consideraciones, se supone que existe un límite superior del retardo de ida y vuelta: RTT_UB. Además, existe un retardo de ida y vuelta nominal, indicado RTT_n, que es el retardo de ida y vuelta más probable durante la operación normal. Evidentemente, RTT_n  RTT_UB. Debería realizarse la estimación de RTT_n antes de la implementación, ya 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. Los detalles se analizan a continuación.

Basándose en la suposición 1 y 4, para garantizar la corrección del esquema propuesto, el valor de ℓ_extendido debería satisfacer las siguientes condiciones:

1.: 2ℓ_extendido * T_H  RTT_UB, donde T_H es el espaciado de tiempo entre dos encabezamientos consecutivos; esto se requiere para evitar ambigüedad en los ACK

2.: 2ℓ_extendido  MAX_EB; esto se requiere para mantener la sincronización de secuencia incluso cuando aparecen ráfagas largas

Existe alguna flexibilidad para elegir el valor de ℓ. Sin embargo, para conseguir rendimiento óptimo, debería ajustarse con precisión basándose en la distribución de las ráfagas de errores de canal (tanto en dirección directa como inversa) y en el retardo de ida y vuelta. Lo siguiente son algunas consideraciones:

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

4.: 2k  el número más probable de pérdidas de paquetes consecutivos. Esto es necesario para reducir la posibilidad de que el compresor conmute al modo extendido debido a ráfagas de errores largas.

5.: K no debería ser demasiado pequeño. De otra manera, se enviarán demasiados ACK periódicos desde el descompresor al compresor, produciendo la inundación del canal inverso y reduciendo 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) ℓ_extendido bits para garantizar la corrección. Por otro lado, usará (CD_SN) k bits más cortos durante condiciones de canal normales para conseguir mejor eficacia. Los detalles de conmutación entre los dos modos se analizan a continuación.

10

15

20

25

30

35

40

45

50

55

60

65

E00970868

16-12-2014

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 pasan en cada secuencia entre diferentes estados de consumo de encabezamiento, desde el compresor hasta el descompresor antes de que se reciba mediante el compresor un acuse de recibo (ACK), generado mediante el descompresor, para producir al compresor pasar la compresión de encabezamientos a un mayor grado de compresión de encabezamientos. Puesto que el compresor transmite encabezamientos periódicamente, antes de recibir cualquier acuse de recibo, 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 de FH y FO alternativos 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 el encabezamiento de referencia a partir de entonces para la descompresión.

Extrapolación múltiple

La Figura 11 ilustra una realización de la invención en la que el descompresor realiza extrapolación múltiple. Cuando uno o múltiples encabezamientos de SO consecutivos que pertenecen a una cadena se pierden o corrompen, el descompresor puede descomprimir los encabezamientos de SO posteriores aplicando una función de extrapolación un número de veces necesario. Como se muestra en la Figura 11, se supone que SO(n+1) y SO(n+2) todos se pierden. Siendo el valor variable correspondiente en SO(i) X(i), entonces X(n+3) puede regenerarse. En el caso donde la función de extrapolación es lineal y el desplazamiento entre dos paquetes enviados consecutivamente es X_Stride, se realiza la regeneración de SO(n+3) aplicando una función de extrapolación dos veces basándose en SO(n), es decir, X(n+3)=X(n) + X_Stride *((n+3)-n).

En el caso donde la función de extrapolació6n no es lineal y varía en un patrón o patrones no lineales, el descompresor puede regenerar los encabezamientos de acuerdo con el patrón o patrones no lineales. Por ejemplo, si un valor variable de X entre paquetes consecutivos cae en el patrón X_Stride1, X_Stride2, X_Stride1, X_Stride2, y así sucesivamente, entonces el descompresor regenera X(n+3) como X(n+3)=X(n)+(X_Stride1+X_Stride2).

Ejemplos de X podrían ser la indicación de tiempo y el número de secuencia en el encabezamiento de RTP usándose múltiples extrapolaciones que usan diferentes funciones de extrapolación. Una función de una función de extrapolación es, por ejemplo, un producto de diferentes constantes y una función de extrapolación constante.

Cada encabezamiento que llega en el compresor del transmisor puede modelarse como un vector multi-dimensional siendo cada componente igual al valor de un campo variable en el encabezamiento. Por ejemplo, si el número de secuencia de RTP SN y la indicación de tiempo de RTP son los únicos campos variables en un encabezamiento, cada encabezamiento a comprimir corresponde a un punto en el espacio bidimensional. Por lo tanto, con el paso del tiempo el compresor simplemente observa una secuencia de puntos en este espacio multi-dimensional.

Las coordenadas de un punto pueden obtenerse aplicando una función de extrapolación multidimensinal al punto inmediatamente anterior en la secuencia. La función de extrapolación puede variar de paquete a paquete (o de punto a punto en el espacio). Sin embargo, si permanece la misma durante una sub-secuencia de puntos, esa subsecuencia se hace una cadena. Obsérvese que la función de extrapolación puede tener cualquier característica, aunque normalmente es lineal.

El concepto de la cadena puede optimizarse adicionalmente mediante el descompresor realizando extrapolación múltiple. Cuando uno o más encabezamientos de SO consecutivos que pertenecen a una cadena se pierden o corrompen entre el compresor y el descompresor, el descompresor puede descomprimir todavía encabezamientos de SO posteriores aplicando la función de extrapolación el número de veces necesario. El número de veces se determina mediante el salto en CD_SN. Obsérvese que la sincronización en el CD_SN se mantiene cuando el contador ha continuado el ciclo.

Si se corrompen uno o múltiples encabezamientos de SO durante la transmisión, el descompresor es capaz de reparar los encabezamientos corruptos basándose en los encabezamientos recibidos correctamente anteriormente y actualmente y en las funciones de extrapolación. Cuando el descompresor recibe paquetes con encabezamientos corruptos, almacena en memoria intermedia el paquete corregido en lugar de descartar el paquete corregido. Después de que el descompresor recibe el siguiente paquete sin corrupción, el descompresor compara el número de paquetes almacenados en memoria intermedia en el mismo y el desplazamiento del número de secuencia entre el paquete recibido correctamente actual y el paquete recibido correctamente anterior. Si el desplazamiento del número de secuencia coincide con el número de paquetes que almacenó en la memoria intermedia, y todos esos paquetes están en la misma cadena, a continuación el descompresor puede recuperar los encabezamientos corruptos basándose en la función o funciones de extrapolación conocidas.

15

25

35

45

55

65

E00970868

16-12-2014

Como se ilustra en la Figura 11, suponiendo que la función de extrapolación para el valor X en el encabezamiento es lineal y el desplazamiento entre dos paquetes enviados consecutivamente es X_Stride, cuando el descompresor recibe SO(n+1) y SO(n+2) con encabezamientos corruptos, el descompresor almacena en memoria intermedia los paquetes y espera al siguiente paquete. Cuando el descompresor recibe SO(n+3) y observa que el desplazamiento del número de secuencia entre el paquete recibido correctamente actual SO(n+3) y el paquete recibido correctamente anterior SO(n) es 2 y el número de paquetes almacenados en memoria intermedia en el mismo entre estos dos paquetes es 2 también, el descompresor puede regenerar el valor X de los dos paquetes con encabezamientos corruptos como X(n+1)=X(n)+X_Stride y X(n+2)=X(n)+2*X_Stride. Ejemplos del valor X pueden ser la indicación de tiempo y el número de secuencia en el encabezamiento de RTP. Este proceso tiene aplicaciones en las que el retardo puede tolerarse tal como con el fluido continuo.

Otra mejora es la compensación del número de secuencia del compresor. El compresor realiza compensación del número de secuencia cuando el número de secuencia de RTP del encabezamiento a comprimir no aumenta en 1 (aumenta en más de 1 o disminuye), pero el compresor determina que el encabezamiento pertenece todavía a la misma cadena que la cadena anterior. Esto ocurre cuando algunos encabezamientos en una cadena se pierden o desordenan en el camino al compresor. En ese caso, el encabezamiento se comprime como un encabezamiento de FO, pero únicamente se envía una diferencia de número de secuencia de RTP SND como información de actualización. SND = (SN de RTP real del encabezamiento comprimido) -(SN de RTP del encabezamiento obtenido mediante extrapolación directa a partir del CD_SN). SND permite al descompresor determinar el número de secuencia de RTP correcto. Por ejemplo, se considera la secuencia de encabezamientos con el Número de Secuencia de RTP = 5, 6, 7, 8 y 9 perteneciendo todos a la misma cadena. En el camino al compresor del transmisor, los encabezamientos 7 y 8 se pierden. En consecuencia, el compresor observa un incremento de más de 1 cuando se recibe el encabezamiento 9. Sin embargo, a partir de la inspección de los campos no comprimidos, el compresor del transmisor determina que el encabezamiento 9 pertenece a la misma cadena que el encabezamiento

6. Suponiendo que el encabezamiento 6 se comprimió con CD_SN = 3. Ahora el encabezamiento 9 se comprime con CD_SN = 4, ya que CD_SN siempre se incrementa en 1. El compresor del transmisor también envía una SND = 9 -7 = 2. El descompresor del receptor añade la SND al CD_SN, a continuación aplica el algoritmo de descompresión normal para el SO.

En un caso de únicamente desordenación (no de pérdida de paquetes antes del compresor), habrá una secuencia de encabezamientos de SO con SND, pero eventualmente la SND se hará cero. Una vez que la SND es cero, no es necesaria la SND en el encabezamiento comprimido, y el encabezamiento comprimido es solo un SO normal. Si los paquetes se pierden antes de que alcancen el compresor del transmisor, la SND no irá a cero. La SND necesita llevarse en cada encabezamiento hasta que el compresor recibe un acuse de recibo desde el descompresor. De otra manera, si el encabezamiento que contiene la SND se pierde, el descompresor no puede descomprimir correctamente.

La Figura 12 ilustra una realización de la invención en la que aparece la compensación del número de secuencia del compresor cuando el número de secuencia de RTP del encabezamiento a comprimir no aumenta en 1 debido a la pérdida de paquetes, y el compresor determina que el encabezamiento pertenece todavía a la misma cadena que la anterior. Se supone en este ejemplo, que los paquetes con el número de secuencia de RTP N+1, N+2, N+3 se pierden todos. El compresor únicamente recibe paquetes con el número de secuencia de RTP N y N+4, perteneciendo N y N+4 a la misma cadena. Cuando el compresor envía el encabezamiento comprimido para el paquete con el número de secuencia de RTP N+4, además del número de secuencia corto n+2, el compresor necesita también enviar una diferencia de número de secuencia de RTP SND que en el ejemplo es igual a (N+5)(N+2). Cuando el descompresor recibe tal paquete, añade la SND al CD_SN para obtener el número de secuencia correcto, a continuación aplica el algoritmo de descompresión normal para el SO.

La Figura 13 ilustra una realización de la invención que realiza detección de errores y regeneración de código de detección de errores que se usa para limitar el ancho de banda de transmisión. Se supone en la siguiente descripción que un mecanismo de detección de errores, tal como una suma de control de UDP (2 bytes), no se transfiere a través del canal de comunicación entre el compresor y el descompresor como el (CD_CC). Esto no es un problema si la suma de control de UDP no se usa mediante la aplicación final. Si la aplicación final usa la suma de control de UDP, y es necesario enviar la suma de control de UDP de extremo a extremo, la realización puede extenderse de una manera directa añadiendo la suma de control de UDP no comprimida en cada encabezamiento comprimido. Sin embargo, incluso si la suma de control de UDP no se envía como el CD_CC, alguna información relacionada con la suma de control de UDP puede transportarse al compresor.

Una opción es dividir la suma de control de UDP de extremo a extremo en dos partes: el segmento entre la fuente y el compresor se denomina como el segmento corriente arriba y el segmento entre el compresor y el descompresor se denomina como el segmento corriente abajo. El proceso de detección de errores que usa la suma de control puede llevarse a cabo únicamente en el segmento corriente arriba. Antes de enviar un paquete de UDP, el compresor comprueba si la suma de control es coherente con los datos y el compresor comprime el paquete. Si no lo es, el paquete se descartará o el paquete se enviará con la suma de control descartada y una bandera de error añadida que informa al descompresor que el paquete recibido contiene datos erróneos con el descarte de los bits de detección de errores en la forma de la suma de control (u otros bits de detección de errores) antes de la transmisión

15

25

35

45

55

65

E00970868

16-12-2014

ahorrando por lo tanto ancho de banda de transmisión. El descompresor se basa en su lugar en las capacidades de detección de errores del CD_CC. Si no se informan errores al descompresor, el descompresor recalcula la suma de control después de descomprimir el paquete.

Las soluciones anteriores trabajan únicamente si existe un mecanismo de detección de errores en el CD_CC y tiene la misma o mayor capacidad que la suma de control de UDP.

Antes de comprimir un paquete, el compresor comprueba si la suma de control es coherente con los datos. Si lo es, como se ha indicado anteriormente, el compresor comprime el paquete sin incluir la suma de control en el paquete comprimido y transmite el paquete comprimido al descompresor. Si no lo es, el compresor puede descartar el paquete, o transmitir el paquete con la suma de control, o transmitir el paquete sin la suma de control pero con o sin la indicación de error.

Las Figuras 14A-F ilustran un ejemplo del formato de paquetes de SO, ACK, FO, FH, FO EXT y FH REQ que pueden usarse 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 de RTP comprimido, C_RTP_TS es la indicación de tiempo de RTP comprimida y C_IP_ID es la IP_ID comprimida. Sin embargo, debería entenderse que la presente invención no está limitada a los mismos. El campo PT para el paquete de SO puede codificarse como 0, el paquete de ACK como 10, el paquete de FO como 110, el paquete de FH como 1110, el paquete de FO_EXT como 11110 y el paquete de FH_REQ como 111110. En los paquetes de FO y FO_EXT, M es un marcador de un bit en el encabezamiento de RTP. En el paquete de FO, T es una bandera de un bit que es 1 si C_RTP_TS está presente y cero de otra manera e I es una bandera de un bit que se establece a 1 si C_IP_ID está presente y es cero de otra manera. En paquetes de FH, los encabezamientos de IP y UDP pueden comprimirse si se proporciona la longitud del paquete mediante una capa inferior en el descompresor. El paquete de 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 haciendo a las banderas de bits T e I no necesarias. Finalmente, se envía el paquete de FH_REQ únicamente bajo circunstancias excepcionales, tales como una avería del sistema.

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

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

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

En este ejemplo, se supone S_DFOD y R_DFOD no estáticos. Se determinan por lo tanto mediante el compresor y el descompresor en una base dinámica como sigue:

Se calcula la cantidad de S_DFOD como CFO(m) cuando el compresor recibió el ACK(n) y el 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 de SO después de un paquete no de SO. Se calcula la cantidad de R_DFOD usando una extrapolación lineal basándose en los últimos dos encabezamientos realizados el acuse de recibo almacenados en la OAW 135.

El comportamiento del compresor puede modelarse como una máquina de estado, especificada mediante la tabla a continuación.

Para tratar el problema de la continuación del ciclo del contador y las ráfagas de errores largas, el compresor espera recibir un ACK al menos una vez cada seq_cycle encabezamientos, y mantiene una bandera extendido. Si la bandera es verdadero, el compresor deberá operar en el modo extendido, es decir enviar (CD-SN)ℓ_extendido. De otra manera, envía (CD-SN)k. La bandera extendida se establece a verdadera siempre que N_elapsed  seq_cycle. 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_cycle sin un acuse de recibo, el transmisor pasa al estado de FH.

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

E00970868

16-12-2014

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

Necesitan ejecutarse procedimientos extra en el caso de transferencia. Por simplicidad, no están incluidos en este punto.

Estado de FH

Evento: Acción

recibir ACK(n) para FH(n):  véase pseudocódigo de procesamiento de ACK(n) del compresor  estado  ESTADO DE FO;

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

{ calcular CFO(n) y actualizar N_Last_Interr;enviar como FH(n);

15 almacenar encabezamiento(n) en HSW, color B rojo; /* n en FH está codificado en k_extendido bits */}

Estado de FO

20

Evento: Acción

recibir ACK(n) para FO(n, m):  véase pseudocódigo de procesamiento de ACK(n) del compresor

Recibir FH_Req:  estado  ESTADO DE FH;

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

{25 calcular CFO(n) y actualizar N_Last_Interr; si N_elapsed >= seq_cycleextended_flag B VERDADERO;sino extended_flag B FALSO;30 si N_elapsed >= ext_cycle {

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

35 }

si se recibieron más de dos ACK, Y los dos CD_SN más recientes se les realizó ACK >= N_Last_Interr

{

40 S_DFOD B CFO(n);enviar SO(n), almacenar encabezamiento(n) en HSW, color B color_actual(); /* véasefunción a continuación */estado B SO_STATE;

}45 sino

enviar FO(n, S_RFH); almacenar encabezamiento(n) en HSW, color B color_actual();N_elapsed B N_elapsed + 1;}color_actual() {

50 si extended_flag = VERDADEROdevolver rojo;sino devolver verde;}

55

E00970868

16-12-2014

Estado de SO

Evento: Acción

Recibir ACK(n):  véase pseudocódigo de procesamiento de ACK(n) del compresor

Recibir FH_Req:  Estado  ESTADO DE FH

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

{calcular CFO(n) y actualizar N_Last_Interr;si N_elapsed >= seq_cycleextended_flag B VERDADERO;10 sino

extended_flag B FALSO;si N_elapsed >= ext_cycle{

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

N_elapsed B 0;}si CFO(n) = S_DFOD

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

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

}25 N_elapsed BN_elapsed + 1;}

Procesamiento de ACK(n) del compresor

30 {

si color de ACK(n) es verde /* n está codificado en k bits */h_ack  un encabezamiento verde en HSW 117 cuyo (CD_SN)k = n; /* véase a continuación para detalles */

sino /* n está codificado en k_extendido35 bits */

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 en HSW anteriores (más antiguos) h_ack;Mover h_ack a Encabezamiento(S_RFH);

40 N_elapsed β Diff(actual |CD_SN, S_RFH): |}

Puede probarse que en el procedimiento anterior, uno y solamente un encabezamiento en la HSW 117 puede identificarse correctamente como el encabezamiento al que se está realizando ACK, en otras palabras, no existirá

45 ambigüedad del ACK. Si el ACK(n) es rojo, es decir, n está codificado usando ℓ_extendido bits, únicamente un encabezamiento rojo puede coincidir con el ACK, puesto que existen al menos 2ℓ_extendido encabezamientos en la HSW 117. De otra manera, si el ACK(n) es verde, se mostrarán que puede mapearse todavía únicamente a un encabezamiento verde en la HSW 117.

50 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 mediante el compresor, la cadena S no cambia a menos que llegue un ACK durante el tiempo, que

55 serán algunas letras desde el comienzo de la S.

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

E00970868

16-12-2014

imagen4

Indicando len(S1) la longitud de S1. En el caso 1, puesto que hay una R después de G1, len(S1) debe ser igual a seq_cycle (=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)  seq_cycle debe ser verdadero. De otra manera, el compresor habría enviado G1 como una roja.

5 Por lo tanto, en cualquier caso, len(S1) es menor o igual a seq_cycle.

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

10 verde en la HSW.

Obsérvese que el descompresor debe cooperar con el compresor para asegurar que se mantiene la sincronización de CD_SN durante el paso 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) ℓ_extendido.

15 En segundo lugar, si el descompresor recibe un paquete de FO, FO(n, m), el encabezamiento de referencia correcto debe ser el encabezamiento más nuevo (más reciente) en la OAW 135, cuyos k (si m es k-bit) o ℓ_extendido (si m es k_extendido bit) bits menos significativos coinciden con m. Obsérvese que esto se basa en la suposición de que, en cada dirección, el canal se comporta como un FIFO.

20 La Figura 19 ilustra la segunda condición. En este ejemplo, NT0 y NT2 son los valores de CD_SN en el tiempo T0 y T2, respectivamente. Suponiendo que en T1, el compresor envía el paquete ACK(NT0), en el que NT0 está codificado en ℓ_extendido bits. En T2, el compresor recibe el ACK(NT0). A continuación calcula N_elapsed igual a (NT2-NT0) y averigua que N_elapsedseq_cycle. Al mismo tiempo, llega un paquete de RTP en el compresor y el

25 compresor decide enviarlo como un paquete de FO, usando el encabezamiento(NT0) como referencia. Puesto que N_elapsedseq_cycle(=2k), el NT2 y NT0 en el paquete de FO están codificados en k bits. En T3, el FO llega en el 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 coinciden con (NT0)k.

30 Obsérvese que en T3, la OAW 135 del descompresor puede contener más de 2k encabezamientos. Sin embargo, la operación anterior siempre proporciona el encabezamiento de referencia correcto. Debido a la propiedad de FIFO del canal directo, cualquiera recibido (y por lo tanto realizado ACK) mediante el descompresor entre T1 y T3, debe enviarse mediante el compresor entre T0 y T2. En otras palabras, si A indica el conjunto de los encabezamientos en

35 la OAW 135 que se añadieron después de encabezamiento (NT0), y B el conjunto de encabezamientos en la HSW 117 en T2, entonces siempre se mantiene A  B. Puesto que |A |<2k, se tiene 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 coinciden con (NT0)k en el paquete de FO(NT2, NT0). Lo siguiente es un ejemplo de pseudocódigo para el descompresor:

40 El descompresor se maneja principalmente por lo que se recibe desde el compresor (es decir, FH, FO o SO).

A continuación, “correctamente recibido” significa que no se detecta errores en el encabezamiento recibido (FH, FO

o SO). Además de la información de estado anteriormente mencionada, el descompresor mantiene también una

45 copia del último encabezamiento reconstruido, es decir, encabezamiento (R_Last_Decomp). Cuando recibe un paquete de FO el descompresor usará el procedimiento anteriormente descrito con referencia al pseudocódigo del compresor para recuperar el encabezamiento de referencia correcto.

Si se recibe correctamente FH(n)

50 {reconstruir encabezamiento(n) a partir de FH(n);enviar ACK(n);R_Last_Acked-n;almacenar encabezamiento(n) en OAW 135 y también encabezamiento(R_Last_Decomp);

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

E00970868

16-12-2014

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

Enviar FH_Req; 5 sino

{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

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

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

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

}

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

si es el primer paquete de SO después de un paquete no SO{25 encontrar los dos encabezamientos reconstruidos más recientemente en OAW 135; si no encontrado /* podría ocurrir únicamente debido a fallo de sistema */

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);}reconstruir encabezamiento(n)-R_DFOD * Diff(n, R_Last_Decomp) +encabezamiento(R_Last_Decomp);almacenar encabezamiento(n) en encabezamiento(R_Last_Decomp);

35 si 1) han transcurrido (seq_cycle -N_RT) paquetes desde R_Last_ACKed, o,

/* tiempo para enviar un ack periódico */2) extended_flag en SO está ACTIVO y este es el primer paquete de este tipo, o,/* el compresor conmuta al modo extendido; envía ack por lo 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 anterior aparentemente no se recibió; enviar otro ack */

{Enviar ACK(n); n está codificado en modo extendido si se cumplen las condiciones 2

o 3 45 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 se recibe correctamente FO(n, m){

si no puede encontrarse encabezamiento(m) en la OAW 135 5 /* podría ocurrir únicamente debido a fallos de sistema */

55 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 encabezamiento (R_RFH);reconstruir encabezamiento(n)-FO_DIFF(n, m) + encabezamiento(m);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 de FO recibidos ose han recibido N_RT FO paquetes desde el último paquete FO al que se realizó 65 ACK { Enviar ACK(n);

15

25

35

45

55

65

E00970868

16-12-2014

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

}

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

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

{

encontrar los dos encabezamientos reconstruidos más recientemente en OAW 135;

si no encontrado /* podría ocurrir únicamente debido a fallo de sistema */

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

}

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 (seq_cycle -N_RT) paquetes desde R_Last_ACKed, o,

/* tiempo para enviar un ack periódico */

2) extended_flag en SO está ACTIVO y este es el primer paquete de este tipo, o,

/* el compresor conmuta al modo extendido; envía ack por lo 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 anterior aparentemente no se recibió; enviar otro ack */

{

Enviar ACK(n); n está codificado en modo extendido si se cumplen las condiciones 2

o 3

R_Last_Acked-n: 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 2ℓ-extendido encabezamientos. Sin embargo, eso es muy improbable que ocurra. En muchos casos, necesitan mantenerse menos de 2k entradas en la HSW 117 o en la OAW 135. En la práctica esto significa un número bastante pequeño de entradas para tanto la OAW como la HSW. Por ejemplo, 16 (k=4) entradas proporcionarán 320 ms de tiempo de ida y vuelta, suponiendo un espaciado de 20 ms por paquete.

Los campos estáticos no necesitan almacenarse como múltiples entradas en la HSW 117 o la OAW 135. Únicamente es necesaria una única copia de los campos estáticos.

En el 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 una 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, ya que el paquete perdido podría llevar información de diferencia de FO. El RFC 2508 se basa únicamente el número de secuencia de 4 bits para detectar pérdidas de paquetes. El número de secuencia continúa el ciclo cada 16 paquetes. Cuando aparece una ráfaga de errores más larga de 16 paquetes, existe una probabilidad de 1 a 16 de no detectar errores, que es inaceptablemente alta. Adicionalmente, incluso si el descompresor pudiera detectar errores, para recuperarse de errores, el descompresor tiene que pedir al compresor enviar un encabezamiento de gran tamaño enviando un mensaje de CONTEXT_STATE. Por lo tanto existe un retardo de ida y vuelta causado antes de que el encabezamiento pedido 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 podría establecerse igual a 4) para extrapolación lineal. Al igual que el RFC 2508, cuando la extrapolación lineal diera como resultado reconstrucción de encabezamientos incorrecta, el compresor envía una información de diferencia de FO. A diferencia del RFC 2508, se calcula la diferencia con respecto a un paquete de referencia que se conoce que se recibió correctamente. Ese paquete no es necesariamente el inmediatamente anterior al paquete actual. Esta característica asegura que el encabezamiento actual puede reconstruirse fiablemente incluso si se perdieron uno o más paquetes pasados. Ya que el encabezamiento puede reconstruirse fiablemente de esa manera, no hay necesidad de enviar un encabezamiento completo. La información de diferencia de primer orden puede codificarse la mayor parte del tiempo

E00970868

16-12-2014

con menos bits que el valor absoluto del encabezamiento completo. El encabezamiento de diferencia de FO tiene un campo adicional que lleva el número de referencia, es decir el número de secuencia del paquete de referencia. Para garantizar que se detectarán errores incluso en la presencia de ráfagas de errores largas, el descompresor envía un ACK con suficiente frecuencia de modo que el compresor recibe un ack al menos una vez cada seq_cycle paquetes.

5 En la ausencia de un ACK de este tipo, el compresor supondrá que puede existir una ráfaga de errores larga. En la mayoría de los casos, entonces es suficiente que el compresor conmute simplemente a un número de secuencia de ℓ_extendido-bits, donde ℓ_extendido es suficientemente largo 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 pedir retransmisión.

10 La Figura 20 a continuación muestra resultados comparativos de la técnica anterior del RFC 2508 con la invención. Se supone un retardo en un sentido (fijo) de 60 ms en este ensayo. El inter-espaciado entre paquetes de RTP es 30 ms. El modelo de error aleatorio se usa con diferentes medias de tasas de error de paquetes. La relación de compresión se define como la relación entre el tamaño medio de los encabezamientos comprimidos y el tamaño de

15 los encabezamientos de IP/UDP/RTP originales. Obsérvese que con la invención, el tamaño de los paquetes de ACK está incluido en el cálculo de la media del tamaño del encabezamiento comprimido. La invención supera el RFC 1508 tan pronto como la tasa de error de paquetes es superior al 0,4 %.

El esquema robusto de la invención requiere que el compresor y el descompresor mantengan las colas de la HSW

20 117 y de la OAW 135, respectivamente. Suponiendo que la idas y vueltas son menores de 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 o de OAW para una sesión bidireccional (en bytes): (16*22 + 18)* 2 = 740 (16*20 + 40)*2 = 720

Aproximadamente 1 megabyte de memoria permitirá manejar más de 1400 sesiones simultáneamente. La carga de 25 procesamiento para gestionar las colas es muy moderada, ya que implica manipulación de punteros.

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

30

Claims

15

25

35

45

55

65

E00970868

16-12-2014

REIVINDICACIONES

1.: Un método para hacer funcionar un sistema que tiene un transmisor que transmite una pluralidad de paquetes conteniendo cada uno un encabezamiento a un receptor, comprendiendo el método sincronizar la transmisión de encabezamientos comprimidos entre el transmisor y el receptor mediante:

transmisión de un paquete actual desde el transmisor al receptor que contiene información de que el transmisor está preparado para enviar paquetes transmitidos posteriormente en los que los encabezamientos en los mismos se han de comprimir en comparación con el encabezamiento contenido en el paquete actual, en donde el encabezamiento del paquete actual es un encabezamiento completo o un encabezamiento comprimido de primer orden; transmisión desde el receptor al transmisor de un paquete de acuse de recibo de que el receptor ha recibido el paquete actual; y en respuesta a recibir en el transmisor el paquete de acuse de recibo, envío posteriormente de paquetes transmitidos en los que el encabezamiento comprimido de los paquetes transmitidos posteriormente es un encabezamiento comprimido de segundo orden.

2.: Un método de acuerdo con la reivindicación 1, que comprende:

almacenar el transmisor el encabezamiento del paquete actual, del que se ha realizado acuse de recibo de que se recibe mediante el receptor, como un encabezamiento de referencia que se usa en la transmisión de los paquetes transmitidos posteriormente como un encabezamiento de referencia para usarlo el receptor para descomprimir los encabezamientos posteriores; almacenar el receptor el encabezamiento del paquete actual, del que se ha realizado acuse de recibo para descomprimir los encabezamientos comprimidos de los paquetes transmitidos posteriormente; transmitir el transmisor paquetes posteriores usando el encabezamiento almacenado del paquete actual como un encabezamiento de referencia; y descomprimir el receptor los encabezamientos comprimidos de los paquetes recibidos transmitidos posteriormente usando el encabezamiento de referencia almacenado para producir un encabezamiento completo que no está comprimido.

3.: Un método de acuerdo con la reivindicación 2, que comprende:

detectar el receptor al menos un paquete perdido en los paquetes transmitidos posteriormente mediante comparación de los números de secuencia de paquetes transmitidos recibidos sucesivamente.

4.: Un método de acuerdo con la reivindicación 2 o la reivindicación 3 que comprende:

determinar un número de paquetes perdidos entre un paquete recibido anteriormente inmediatamente y el paquete actual; añadir el número de paquetes perdidos determinado a un número de paquete del paquete recibido anteriormente inmediatamente hasta un número del paquete actual para actualizar un número del paquete actual en una secuencia de transmisión de la pluralidad de paquetes; y descomprimir un número de secuencia del paquete actual usando el número actualizado y descomprimir campos de información adicionales usando el encabezamiento de referencia almacenado.

5.: Un método para hacer funcionar un transmisor que transmite a un receptor una pluralidad de paquetes conteniendo cada uno un encabezamiento, comprendiendo el método sincronizar la transmisión de encabezamientos comprimidos entre el transmisor y el receptor mediante:

transmisión de un paquete actual desde el transmisor al receptor que contiene información de que el transmisor está preparado para enviar paquetes transmitidos posteriormente en los que los encabezamientos en los mismos se han de comprimir en comparación con el encabezamiento contenido en el paquete actual, en donde el encabezamiento del paquete actual es un encabezamiento completo o un encabezamiento comprimido de primer orden; recepción por el receptor de un paquete de acuse de recibo de que el receptor ha recibido el paquete actual; y en respuesta a recibir en el transmisor el paquete de acuse de recibo, enviar posteriormente paquetes transmitidos en los que el encabezamiento comprimido de los paquetes transmitidos posteriormente es un encabezamiento comprimido de segundo orden.

6.: Un método de acuerdo con la reivindicación 5, que comprende:

almacenar el transmisor el encabezamiento del paquete actual, del que se ha realizado acuse de recibo de que se ha recibido mediante el receptor, como un encabezamiento de referencia que se usa en la transmisión de los paquetes transmitidos posteriormente como un encabezamiento de referencia para usarse mediante el receptor para descomprimir los encabezamientos posteriores; y

15

25

35

45

55

65

E00970868

16-12-2014

transmitir el transmisor paquetes posteriores usando el encabezamiento almacenado del paquete actual como un encabezamiento de referencia.

7.: Un sistema que comprende:

un transmisor (108, 110, 120, 130, 150) configurado para transmitir una pluralidad de paquetes conteniendo cada uno un encabezamiento; un receptor (102, 108, 110, 120, 130, 150) configurado para recibir la pluralidad de paquetes transmitidos; y en donde el transmisor está configurado para transmitir un paquete actual al receptor que contiene información de que el transmisor está preparado para enviar paquetes transmitidos posteriormente en los que los encabezamientos en los mismos se han de comprimir en comparación con el paquete actual, en donde el encabezamiento del paquete actual es un encabezamiento completo o un encabezamiento comprimido de primer orden, y el receptor está configurado para transmitir un paquete de acuse de recibo de que el receptor ha recibido el paquete actual; y en respuesta a recibir en el transmisor el paquete de acuse de recibo, enviar posteriormente paquetes transmitidos en los que el encabezamiento comprimido de los paquetes transmitidos posteriormente es un encabezamiento comprimido de segundo orden.

8.: Un sistema de acuerdo con la reivindicación 7, en el que:

el transmisor está configurado para almacenar el encabezamiento del paquete actual, del que se ha realizado acuse de recibo de que se ha recibido mediante el receptor, como un encabezamiento de referencia que se usa en la transmisión de los paquetes transmitidos posteriormente como un encabezamiento de referencia para usarse mediante el receptor para descomprimir los paquetes posteriores; el receptor está configurado para almacenar el encabezamiento del paquete actual, del que se realiza acuse de recibo como un encabezamiento de referencia, para descomprimir los encabezamientos comprimidos de los paquetes transmitidos posteriormente; el transmisor está configurado para transmitir paquetes posteriores que contienen el encabezamiento comprimido de segundo orden usando el encabezamiento almacenado del paquete actual como un encabezamiento de referencia; y el receptor está configurado para descomprimir los encabezamientos comprimidos de los paquetes recibidos transmitidos posteriormente usando el encabezamiento de referencia almacenado para producir un encabezamiento completo que no está comprimido.

9.: Un sistema de acuerdo con la reivindicación 8, en el que:

el receptor está configurado para detectar al menos un paquete perdido en los paquetes transmitidos posteriormente mediante comparación de números de secuencia de paquetes transmitidos recibidos sucesivamente; y el receptor está configurado para descomprimir el encabezamiento de un paquete recibido inmediatamente después de un último paquete perdido en el tiempo usando un número detectado de paquetes perdidos y/o el encabezamiento de referencia almacenado.

10.: Un sistema de acuerdo con la reivindicación 9, en el que:

el receptor está configurado para determinar un número de paquetes perdidos entre un paquete recibido anteriormente inmediatamente y el paquete actual; el receptor está configurado para añadir el número de paquetes perdidos determinado a un número de paquete del paquete recibido inmediatamente hasta un número del paquete actual para actualizar un número del paquete actual en una secuencia de transmisión de la pluralidad de paquetes; y el receptor está configurado para descomprimir un número de secuencia del paquete actual usando el número actualizado y campos de información adicionales usando el encabezamiento de referencia almacenado.

11.: Aparato (110, 120) que comprende:

un transmisor (102, 108, 130, 150) configurado para transmitir una pluralidad de paquetes conteniendo cada uno un encabezamiento a un receptor (102, 108, 130, 150), en el que el transmisor está configurado para transmitir un paquete actual al receptor que contiene información de que el transmisor está preparado para enviar paquetes transmitidos posteriormente en los que los encabezamientos en los mismos se han de comprimir en comparación con el paquete actual, en donde el encabezamiento del paquete actual es un encabezamiento completo o un encabezamiento comprimido de primer orden; estando configurado el aparato para recibir desde el receptor un paquete de acuse de recibo de que el receptor ha recibido el paquete actual; y en respuesta a recibir en el transmisor el paquete de acuse de recibo, enviar posteriormente paquetes transmitidos en los que el encabezamiento comprimido de los paquetes transmitidos posteriormente es un encabezamiento comprimido de segundo orden.

15

25

35

45

55

65

E00970868

16-12-2014

12.: Aparato de acuerdo con la reivindicación 11, en el que:

el transmisor está configurado para almacenar el encabezamiento del paquete actual, del que se ha realizado acuse de recibo de que se ha recibido mediante el receptor, como un encabezamiento de referencia que se usa en la transmisión de los paquetes transmitidos posteriormente como un encabezamiento de referencia para usarse mediante el receptor para descomprimir los paquetes posteriores; y el transmisor está configurado para trasmitir paquetes posteriores que contienen el encabezamiento comprimido de segundo orden usando el encabezamiento almacenado del paquete actual como un encabezamiento de referencia.

13.: Un receptor (102, 130, 150) configurado; para recibir desde un transmisor (108, 130, 150) una pluralidad de paquetes conteniendo cada uno un encabezamiento, en donde el receptor está configurado para recibir un paquete actual que contiene información de que el transmisor está preparado para enviar paquetes en los que los encabezamientos en los mismos se han de comprimir en comparación con el paquete actual, en donde el encabezamiento del paquete actual es un encabezamiento completo o un encabezamiento comprimido de primer orden; para almacenar el encabezamiento del paquete actual como un encabezamiento de referencia; en respuesta a la recepción del paquete actual, para enviar un paquete de acuse de recibo al transmisor que indica que el receptor ha recibido el paquete actual; posteriormente para recibir un paquete transmitido posteriormente que tiene un encabezamiento comprimido de segundo orden; y para usar el encabezamiento del paquete actual para descomprimir el encabezamiento comprimido de segundo orden del paquete transmitido posteriormente para producir un encabezamiento completo que no está comprimido.

14.: Un receptor de acuerdo con la reivindicación 13, en el que:

el receptor está configurado para detectar al menos un paquete perdido en los paquetes transmitidos posteriormente mediante comparación de números de secuencia de paquetes transmitidos recibidos sucesivamente; y el receptor está configurado para descomprimir el encabezamiento de un paquete recibido inmediatamente después de que un último paquete perdido en el tiempo se descomprime usando un número detectado de paquetes perdidos y/o el encabezamiento de referencia almacenado.

15.: Un receptor de acuerdo con la reivindicación 14, en el que:

16.: Un método para hacer funcionar un receptor (102, 130, 150), comprendiendo el método: recibir desde un transmisor (108, 130, 150) una pluralidad de paquetes conteniendo cada uno un encabezamiento, en donde la pluralidad de paquetes incluye un paquete actual que contiene información de que el transmisor está preparado para enviar paquetes en los que los encabezamientos en los mismos se han de comprimir en comparación con el paquete actual, en donde el encabezamiento del paquete actual es un encabezamiento completo o un encabezamiento comprimido de primer orden; almacenar el encabezamiento del paquete actual como un encabezamiento de referencia; en respuesta a la recepción del paquete actual, enviar un paquete de acuse de recibo al transmisor que indica que el receptor ha recibido el paquete actual; recibir posteriormente un paquete transmitido posteriormente que tiene un encabezamiento comprimido de segundo orden; y usar el encabezamiento del paquete actual para descomprimir el encabezamiento comprimido de segundo orden del paquete transmitido posteriormente para producir un encabezamiento completo que no está comprimido.

17.: Un método de acuerdo con la reivindicación 16, comprendiendo el método detectar al menos un paquete perdido en los paquetes transmitidos posteriormente mediante comparación de números de secuencia de paquetes transmitidos recibidos sucesivamente.

18.: Un método de acuerdo con la reivindicación 16 o la reivindicación 17, que comprende:

determinar un número de paquetes perdidos entre un paquete recibido anteriormente inmediatamente y el paquete actual; añadir el número de paquetes perdidos determinado a un número de paquete del paquete recibido anteriormente

E00970868

16-12-2014

inmediatamente hasta un número del paquete actual para actualizar un número del paquete actual en una secuencia de transmisión de la pluralidad de paquetes; y descomprimir un número de secuencia del paquete actual usando el número actualizado y descomprimir campos de información adicionales usando el encabezamiento de referencia almacenado.