Procedimiento y sistema para comprimir y descomprimir encabezamientos de paquetes.

Un procedimiento de funcionamiento de un descompresor (115, 137) en un sistema que tiene un transmisor (110,

120) que transmite una pluralidad de paquetes, conteniendo cada uno un encabezamiento, a un receptor (130, 150),comprendiendo el procedimiento descomprimir un encabezamiento comprimido contenido en un paquete actualrecibido por el receptor:

determinando con un contador (134) en el receptor un tiempo transcurrido Dt entre paquetes recibidosconsecutivamente, siendo el tiempo transcurrido Dt la diferencia entre tiempos en los que se recibieron elpaquete actual y un paquete recibido inmediatamente antes;

determinando si el tiempo transcurrido Dt es mayor que o igual a un lapso de tiempo que indica que al menosun paquete se ha perdido entre el paquete actual y el paquete recibido inmediatamente antes;

procesando el tiempo transcurrido Dt que indica que al menos se ha perdido un paquete para determinar unnúmero de paquetes perdidos entre el paquete recibido inmediatamente antes y el paquete actual;

añadiendo el número de paquetes perdidos a un número de paquete del paquete recibido inmediatamenteantes para actualizar un número del paquete actual en una secuencia de transmisión de la pluralidad depaquetes; y

descomprimiendo el encabezamiento comprimido del paquete actual usando el número actualizado del paqueteactual.

Procedimiento y sistema para comprimir y descomprimir encabezamientos de paquetes La presente invención se refiere a compresión y descompresión de encabezamientos en transmisiones de paquetes de datos.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A COMPRIMIR