ES2230062T3 - Compresion de encabezados en servicios en tiempo real. - Google Patents

Abstract

Método para la transferencia de un paquete de datos desde un compresor (MS) a un descompresor (SGSM), incluyendo dicho paquete de datos un encabezado con campos de datos del encabezado, almacenándose en el descompresor algunos de los campos de datos del encabezado que permanecen constantes durante la transferencia de datos, incluyendo dicho método: el envío desde el compresor y la recepción en el descompresor de un paquete de datos que incluye información sobre uno o más campos de datos del encabezado que experimentan variaciones durante la transferencia de datos; la descompresión del encabezado utilizando los campos de datos del encabezado almacenados y la información recibida en el o los campos de datos del encabezado que varían durante la transferencia de datos, caracterizado porque: Después de la configuración de la sesión y en relación con un campo de datos de encabezado variable, se envía desde el compresor y se recibe en el descompresor tan sólo un valor comprimido, identificando dicho valor comprimido el paquete de datos de una secuencia de compresión y consistiendo dicho valor comprimido en un primer número de bits menos significativos del campo de datos del encabezado; manteniendo en el descompresor datos de contexto que incluyen información para relacionar el valor comprimido recibido con la correspondiente secuencia de compresión, actualizándose la información en función de los valores comprimidos recibidos; utilizando el valor comprimido y la información de la correspondiente secuencia de compresión para transformar el valor comprimido en un campo de datos del encabezado descomprimido.

Description

Compresión de encabezados en servicios en tiempo real.

La presente invención hace referencia a la transmisión de datos y en especial a un método para la transferencia de un paquete de datos desde un compresor a un descompresor, incluyendo dicho paquete de datos un encabezado con campos de datos de encabezado, almacenándose en el descompresor algunos de los campos de datos del encabezado que permanecen constantes a lo largo de la transferencia de datos. El método incluye el envío desde el compresor y la recepción en el descompresor de un paquete de datos que incluye información en uno o más campos de datos de encabezado que varían a lo largo de la transferencia de datos; y la descompresión del encabezado, utilizando los campos de datos de encabezado almacenados y la información recibida en el o los campos de datos de encabezado que experimentan variaciones durante la transferencia de datos. La invención también hace referencia a los elementos de la red de acceso que implementan el método inventado.

Los servicios en tiempo real constituyen un conjunto emergente de tecnologías que permiten comunicaciones de voz, datos y vídeo a través de redes conmutadas por paquetes. Durante el proceso de normalización de sistemas de radio conmutada por paquetes se ha suscitado un gran interés por facilitar también servicios en tiempo real a través de redes inalámbricas. En los servicios en tiempo real, la transmisión de paquetes se efectúa utilizando diversos protocolos. Esto nos lleva a una gran saturación de protocolos y provoca una utilización ineficaz del ancho de banda. Teniendo en cuenta que las velocidades de transmisión en sistemas inalámbricos son limitadas, la transferencia de grandes encabezados significa un desperdicio de la capacidad.

Para superar el problema de los encabezados de gran tamaño se han presentado diversos métodos de compresión de encabezados. La publicación "Compressing IP / UD / RTP Headers for Low-Speed Serial Links" de S. Casner y V. Jacobson, Internet engineering Task Force, INTERNET-DRAFT, draft-ietf-avt-crtp-05.txt, de julio de 1998, presenta unos eficaces algoritmos de compresión de encabezados que permiten reducir el tamaño del encabezado en una magnitud. La compresión de encabezados presentada se basa en el hecho de que algunos de los bytes de los encabezados IP, UDP y RTP permanecen constantes a lo largo de toda la conexión. Tras el envío de un encabezado no comprimido, estos campos pueden eliminarse de los siguientes encabezados comprimidos. Además, se utiliza una codificación diferencial en los campos que cambian a fin de reducir sus dimensiones. En el encabezado RTP la diferencia de un paquete a otro suele ser constante y, por lo tanto, la diferencia de segundo orden es también cero. Al mantener tanto el encabezado no comprimido como las diferencias de primer orden en la sesión compartida entre el compresor y el descompresor, es imprescindible indicar que la diferencia de segundo orden entre los sucesivos paquetes es cero. También se ha sugerido que una implementación de compresor podría mantener un estado para contextos de multisesión. La utilización de una función hash en ciertos campos predefinidos para indexar una tabla de contextos de sesión almacenados, y la inclusión de un identificador de contexto de sesión en los paquetes comprimidos, permitirían al descompresor indexar directamente una tabla de contextos de sesión almacenados.

El documento US 5.293.379 presenta un método de compresión de datos basado en paquetes en el que cada paquete de datos es re-formateado asociando su campo de datos a una primera región de paquetes y sus campos dinámicos a una segunda región de paquetes. Se forma una tabla estática que incluye información estática procedente de una primera región de paquetes del paquete de datos y se identifica la información común de los campos estáticos de la primera región de paquetes de los paquetes de datos posteriores. La información estática común se codifica para reducir su longitud de datos.

Los servicios en tiempo real imponen unos estrictos límites a las demoras en la transmisión, por lo que en general, no son aplicables los procedimientos ordinarios de retransmisión (por ejemplo, el Protocolo de Control de Transporte TCP, utilizado generalmente para la transmisión de paquetes IP). De este modo, en la práctica, un enlace en servicios en tiempo real se considerará como un enlace simplex. En las referencias a la técnica anterior, para los enlaces simplex se sugiere un sistema de actualización periódica. Cuando el descompresor detecta un error en una cadena de paquetes descarta todos los paquetes de dicha cadena y no reanuda la descompresión hasta que no recibe un encabezado no comprimido transmitido de forma normal (refresh header). Esto significa que, con posterioridad a un error en la transmisión, se perderán todos los paquetes hasta el siguiente refresh packet, o paquete de actualización. En los enlaces de transmisión en los que los errores se dan con relativa poca frecuencia, este hecho no tiene muchos efectos sobre el rendimiento de la transmisión. En cualquier caso, cuando se trata de un enlace con un elevado riesgo de múltiples errores de transmisión, el efecto es disruptivo. Este es especialmente el caso de las transmisiones inalámbricas.

El documento Handley, Mark: "GeRM Generic RTP Multiplexing" Internet engineering Task Force, 11 de noviembre de 1998 (1998-11-11) páginas 1-7, XP002129359, draft-ieft-avt-germ-00.ps presenta la reducción de la saturación del encabezado mediante un método de multiplexión en el cual se combinan diversas cadenas diferentes RTP sin relación entre sí en un solo paquete RTP, aunque este documento también enseña que en el caso general debe evitarse dicha multiplexión. El documento muestra la compresión de encabezados RTP basados en los bits menos significativos para el campo SSRC de encabezados de paquetes procedentes de distintas fuentes, es decir de las diferentes cadenas. Cada paquete multiplexado RTP tiene un encabezado RTP completo que contiene el SSRC, el número de secuencia, la marca temporal, etc. y, de este modo, los paquetes RTP incluyen el contexto completo con el cual se lleva a cabo la descompresión.

La publicación "Low-loss TCP/IP header compressión for wireless networks" de Mikael Degermark, Mathias Engan, Björn Nordgren y Stephen Pink, Wireless Networks 3 (1997) 375-387, J. C. Balzer AG, Science Publishers, presenta unos métodos de compresión de encabezados para los protocolos UDP/IP y TCP/IP donde se aborda el problema de los enlaces simplex y de los enlaces con tendencia a la pérdida. En el sistema presentado, el compresor envía un encabezado completo y un identificador de compresión que es un pequeño número único que es también transportado por los encabezados comprimidos. El descompresor almacena el encabezado completo en estado comprimido. Los identificadores de la compresión en encabezados comprimidos se utilizan para buscar el estado de compresión apropiado para usar en la descompresión. A fin de evitar una descompresión incorrecta debido a estados de compresión incoherentes, se introducen algunos mecanismos adicionales. Todas las versiones del estado de compresión se asocian con una generación, representada por un número, transportada por encabezados completos que instalan o actualizan dicho estado de compresión, así como en encabezados que han sido comprimidos utilizándolo. De este modo, el descompresor puede detectar cuándo su estado de compresión no está actualizado, comparando su generación con la generación de los encabezados comprimidos. Además, para evitar largos períodos de descarte de paquetes cuando se pierden encabezados completos y, por otra parte, para alcanzar unas tasas de compresión lo más elevadas posible, el compresor comienza con un breve intervalo entre encabezados completos y el intervalo de actualización se incrementa exponencialmente a cada actualización hasta que se alcanza un período de actualización constante (inicio lento de compresión). También se sugiere una modesta negociación de algún tipo de compresión de encabezados.

Aunque el uso de la generación de estados de compresión facilita una detección más sencilla de estados de compresión incoherentes, de cualquier modo se perderán los paquetes hasta que un encabezado completo instale un estado de compresión adecuado. El inicio lento de la compresión ayuda a encontrar una negociación adecuada entre la tasa de compresión y el tiempo de recuperación aceptable, pero en condiciones de transmisión difíciles la tasa de compresión siempre se verá comprometida y se reducirán las ventajas de la compresión de los encabezados.

Ahora se ha inventado un método y unos elementos de red que implementan dicho método, con cuya ayuda pueden evitarse estos problemas o reducir su efecto.

De acuerdo con un primer aspecto de la presente invención, se facilita un método para transferir un paquete de datos desde un compresor a un descompresor, incluyendo dicho paquete de datos un encabezado con campos de datos de encabezado, almacenándose en el descompresor algunos de los campos de datos del encabezado que permanecen constantes a lo largo de la transferencia de datos. El método incluye el envío desde el compresor y la recepción en el descompresor de un paquete de datos que incluye información sobre uno o más de los campos de datos del encabezado que varían a lo largo de la transferencia de datos y la descompresión del encabezado utilizando los campos de datos del encabezado almacenados y la información recibida en el o los campos de datos del encabezado que experimentan variaciones durante la transferencia de datos. El método se caracteriza por su configuración posterior a la sesión que afecta a un campo de datos de encabezado variable enviándose desde el compresor y recibiéndose en el descompresor tan sólo un valor comprimido para un campo de datos de encabezado, identificando dicho valor comprimido el paquete de datos en una secuencia de compresión y consistiendo el valor comprimido en un primer número de bits menos significativos del campo de datos del encabezado; manteniendo en el descompresor datos de contexto que incluyen información para relacionar el valor comprimido recibido con su correspondiente secuencia de compresión, y actualizándose la información en función de los valores comprimidos recibidos; y utilizando el valor comprimido y la información de la secuencia de compresión correspondiente para transformar el valor comprimido en un campo de datos de encabezado descomprimido.

La ventaja de la invención está basada en el hecho de que la mayoría de los campos del paquete de la capa de red permanecen constantes a lo largo de una sesión. La capa de red en este contexto se refiere a las capas de protocolo de nivel de red de datos de paquetes, haciéndose referencia por ejemplo a los protocolos IP, UDP y RTP. Además, cabe señalar que los cambios en los campos que varían de un paquete a otro son predecibles. Dichos campos se envían en formato comprimido a un descompresor. En función del conocimiento previo de los cambios previstos, el descompresor generará y mantendrá unos datos de contexto que se actualizan con la información procedente de los paquetes que se reciben en el descompresor. Los datos comprimidos hacen referencia inequívocamente a un cambio en un valor descomprimido en una serie de paquetes de datos consecutivos, o una secuencia de compresión. En los datos de contexto se mantiene la información sobre una o más secuencias de compresión. Esta información proporciona medios para asociar los datos comprimidos recibidos a una secuencia de compresión correcta. Utilizando los datos comprimidos recibidos con los datos de contexto correspondientes mantenidos en el descompresor se consigue que los datos comprimidos se refieran inequívocamente a un campo completo del encabezado de los datos del paquete que se encuentra en el descompresor a lo largo de la sesión. Preferiblemente, los paquetes de datos que transportan información que no puede asociarse correctamente a ninguna de las secuencias de compresión de los datos de contexto que se mantienen en el descompresor ya se han filtrado en el compresor.

En comparación con soluciones anteriores, el nivel de compresión del método inventado es mayor, dado que también pueden comprimirse los campos variables relacionados con la identificación de paquetes. Sin embargo, los errores de transmisión sólo afectarán a la transmisión de paquetes individuales, por lo que los problemas de transmisión de un paquete no se trasladan a los paquetes posteriores. Este método de actualización de la información del encabezado puede diseñarse de forma que se produzca a intervalos más largos o incluso puede descartarse por completo.

En las reivindicaciones independientes 9 y 11 se presentan aspectos adicionales de la invención. Las realizaciones preferidas se muestran en las reivindicaciones dependientes.

Para una mejor comprensión de la presente invención y a fin de mostrar cómo esta puede llevarse a efecto, se hará referencia a continuación, a modo de ejemplo, a los dibujos adjuntos en los cuales:

La Figura 1 presente la acumulación de saturación del encabezado por las diferentes capas en la transmisión de una trama de voz 10 a través de una conexión IP inalámbrica;

La Figura 2 muestra algunos de los elementos funcionales y las estructuras de protocolo relacionadas de una red GPRS;

La Figura 3 muestra campos de los encabezados RTP, UDP e IP de la capa de red;

La Figura 4 muestra las funciones de la entidad receptora de acuerdo con la invención;

La Figura 5 representa un formato para un encabezado comprimido utilizado en una realización de la invención;

La Figura 6 muestra las fases de la realización del método inventado en el que se utiliza la marca temporal abreviada;

La Figura 7 presenta un ejemplo de un algoritmo de filtrado de acuerdo con la invención;

La Figura 8 muestra el formato de un PDU SNDCP SN-UNITDATA;

La Figura 9 muestra una realización alternativa; y

La Figura 10 muestra los bloques responsables de las diferentes funciones en una estación móvil de acuerdo con la invención.

La invención se ilustrará con una realización en la que se están utilizando un codificador de voz ITU-T G.723.1, Internet Protocol versión 4 y General Packet Radio System (GRPS) de ETSI, los cuales son conocidos en general para cualquier persona versada en la materia. Cabe señalar que para todos estos sistemas existen tecnologías paralelas o correspondientes, y que evolucionarán otras más. En consecuencia, el ámbito de la protección no se limita a los detalles de los protocolos utilizados en la siguiente descripción. El método presentado en este documento también es aplicable a las redes fijas, pero el problema es más abstruso en comunicaciones inalámbricas, como la estructura utilizada en este ejemplo.

La Figura 1 presenta la acumulación de sobrecarga del encabezado por parte de las diferentes capas en la transmisión de una trama de voz 10 a través de una conexión inalámbrica IP. Los bloques sombreados representan encabezados y los bloques blancos representan la carga de datos útil de una trama de datos. En primer lugar, la trama de voz 10 se encapsula en un paquete de protocolo de tiempo real (RTP) 11, que se coloca en un paquete de protocolo de datos de usuario (UDP) 12 y, posteriormente, en un paquete de protocolo de Internet (IP) 13. El paquete IP 13 se encapsula adicionalmente utilizando el protocolo de convergencia dependiente de subred (SNDCP) 14 y el protocolo de control de enlaces lógicos (LLC) en un bloque LLC 15, que se divide en un número adecuado de bloques RLC, conteniendo cada uno de ellos un encabezado independiente. Como puede verse, la sobrecarga acumulada es muy grande. Ya en la capa IP la sobrecarga del protocolo es de 40 bytes y la utilización del ancho de banda de aproximadamente un 33% cuando se utiliza un codificador G723.1. Teniendo en cuenta que los encabezados de protocolo del enlace inalámbrico generan todavía más sobrecarga, la situación empeora aún más.

En esta realización, la compresión y la descompresión del encabezado se llevan a cabo en la capa de protocolo específica de la red de acceso, en este caso la capa SNDCP. La Figura 2 muestra algunos de los elementos funcionales y las correspondientes estructuras de protocolo de una red GPRS. La transmisión GPRS se implementa de forma lógica como una estructura general GSM mediante dos elementos de red, un nodo de soporte de puerta de enlace GPRS (GGSN) y un nodo de soporte de servicio GPRS (SGSN). El GGSN es el primer punto de acceso a la red de datos de paquetes en una red GSM que soporte GPRS. Los paquetes de datos cuya dirección PDP (Protocolo de Datos de Paquete, por ejemplo IP o X.25) indican que un abonado GPRS está enrutado al GGSN. El GGSN proporciona la información necesaria para enrutar los paquetes de datos hacia el nodo de acceso SGSN actual del abonado. El GGSN puede consultar los datos relativos al emplazamiento del abonado en un registro de emplazamientos iniciales GSM (HLR). El SGSN es un nodo de acceso que presta servicio a la estación móvil (MS). Para establecer una conexión GPRS, el SGSN establece una funcionalidad de gestión de la movilidad hacia la MS y la funcionalidad PDP hacia la red de datos de paquete para encaminar los paquetes de datos hacia el GGSN. El SGSN y el GGSN pueden integrarse en el mismo nodo físico o pueden estar situados en diferentes nodos.

La función SNDC de la red de acceso proporciona a la capa de red un servicio para transferir una cantidad mínima de datos entre el SGSN y la MS mediante diferentes técnicas de compresión. El GPRS proporciona un procedimiento que se implementa en relación con la negociación del servicio, para que la MS y el SGSN lleguen a un acuerdo sobre el algoritmo de compresión a utilizar en la sesión. En el método inventado, las partes del encabezado que supuestamente permanecen constantes se almacenan en las entidades SNDCP. A continuación se estudiará en más detalle la estructura y los contenidos de un encabezado de protocolo de capa de red.

En la Figura 3 se muestran los campos de la capa de red RTP, UDP y los encabezados IP. En el caso del RTP, el campo 310 indica la versión de RTP que se está utilizando y no experimenta variaciones a lo largo de la sesión. El campo 311 incluye el bit de relleno y no varía a menos que se incluya un relleno adicional al final del encabezado, por ejemplo para algoritmos de cifrado en la capa de aplicación. El campo 312 indica si un encabezado fijo va seguido de una extensión del encabezado y no cambiará durante la sesión. El campo 313 corresponde al recuento CSRC que es necesario para la multiplexión, por ejemplo para indicar cuántos usuarios han contribuido a los datos útiles. En muchos casos, este valor permanecerá constante a lo largo de la sesión. El campo 315 indica el tipo de datos útiles y es constante para un tipo de datos. Por lo general, la fuente contribuyente y la fuente de sincronización se mantienen constantes a lo largo de la transmisión a través del interfaz por aire y, por lo tanto, el campo 318 permanecerá constante.

El campo 314 incluye un bit marcador que se utiliza opcionalmente para marcar acontecimientos importantes de la cadena del paquete, por ejemplo el comienzo de un desbordamiento de voz o el último paquete de una trama de vídeo. Si se utiliza el bit marcador 314, deberá transmitirse en el encabezado comprimido. El campo 316, que indica el número de secuencia, y el campo 317, que indica la marca temporal, cambiarán para todos los paquetes RTP.

En lo tocante al UDP, el campo 321, que indica el número de puerto de origen, y el campo 322, que indica un número de puerto de destino, se utilizan para separar diferentes cadenas de datos asociadas a la misma aplicación. Por ejemplo, los datos y la información de control de la capa RTP pueden dirigirse a diferentes puertos, es decir, los diferentes tipos de datos útiles pueden utilizar diferentes pares de puertos UDP. Estos campos permanecerán constantes siempre que se transmita el mismo tipo de datos. El campo 323, que indica la longitud del paquete UDP, permanece constante siempre que la longitud del paquete RTP contenido en su interior permanezca constante. En los casos en los que la longitud UDP es variable a lo largo e la sesión (por ejemplo, transmisión de vídeo), la longitud del paquete debe transmitirse en el encabezado comprimido. El campo 324 corresponde a la suma de control UDP y se utiliza para detectar los errores de la transmisión. Este campo no tiene que transmitirse a través del enlace de transmisión que cuenta con un potente mecanismo de protección contra errores o con medios para detectar errores en la transmisión (por ejemplo, las sumas de control de la capa inferior del protocolo). En esta realización, la función de descompresión SNDCP puede, por ejemplo, calcular la suma de control para los campos descomprimidos y utilizar dicha suma de control calculado en el paquete descomprimido.

En lo tocante a IP, el campo 331, que indica la versión de IP, el campo 332, que indica la longitud del encabezado, el campo 333, que indica el tipo de servicio y el campo 334, que indica la longitud total del paquete se supone que permanecen constantes al menos durante la transmisión de tramas de voz codificadas a una tasa de bits constante. El campo 336, que indica los marcadores, se puede suponer que permanece constante mientras no se utilice la fragmentación. El campo 337, que incluye el desplazamiento del fragmento de 13 bits, se supone que permanece constante, así como el campo 339, que indica el protocolo. Los campos 338, que indica su período de vida útil, y 340, que indica la suma de control, pueden ser definidos por la función SNDCP. Durante la transmisión de datos, la fuente y el destino IP permanecerán constantes, del mismo modo que los campos 341 y 342, que indican las direcciones IP de origen y de destino, respectivamente, se supone que permanecen constantes. El campo de identificación 335 es utilizado principalmente para la fragmentación de paquetes IP. Si no se utiliza la fragmentación no será necesario enviar este campo. Si se utiliza la fragmentación, la función SNDCP debería, en primer lugar, reconstruir el paquete antes de comprimirlo.

Los campos que se supone que permanecen constantes durante la mayor parte del tiempo se agrupan en un conjunto de campos invariables. En esta realización, y en relación con las tramas de voz procedentes de un codificador con tasa de bits constante, el conjunto incluirá los siguientes campos: 310, 311, 312, 313, 315, 318, 321, 322, 331, 332, 333, 334, 335, 336, 337, 338, 339, 341, 342, 343. Estos campos constituirán un estado de compresión que se mantendrá, al menos, en el extremo receptor (descompresión) del enlace.

Como se ha mencionado anteriormente, además de los campos invariables, puede omitirse en el encabezado comprimido un segundo conjunto de campos cuyo contenido puede deducirse a partir de la información recibida. Dichos campos no causan ningún efecto en el estado de compresión. Dichos campos, en las realizaciones presentadas, son los campos 324 y 340, que incluyen las sumas de control utilizadas para comprobar la validez de los paquetes. Dichas sumas pueden calcularse en el descompresor a partir de los campos de datos descomprimidos. La validez de los paquetes puede calcularse utilizando las sumas de control del nivel inferior, por ejemplo las unidades de datos del nivel de red de acceso.

La solución de acuerdo con la invención para la gestión de los campos que varían para cada paquete se indica de forma general en la figura 4, donde se muestran las funciones de la entidad receptora, que en esta realización es la SGSN (igualmente: descompresor). En relación con la información de configuración de la sesión necesaria para el estado de compresión esta se recibe en el descompresor (por ejemplo, un encabezado completo). Para asegurar que se utiliza un estado de compresión correcto puede incluirse un procedimiento de reconocimiento en las señales de configuración de la sesión. En la fase 40, el estado de compresión SoC se almacena en el descompresor. En la fase 41 se inicia en el descompresor un contexto de sesión que incluye uno o más valores de contexto Cj, relativo cada uno de ellos a una determinada secuencia de compresión. Se recibe un paquete de la entidad transmisora, en este caso el MS (igualmente: compresor) (etapa 42). El paquete incluye un campo de datos comprimidos Dcom. En caso de que se mantenga más de un valor de contexto (máximo valor para j>1), se definirá un conjunto de reglas de decisión Dm para relacionar un Dcom recibido con el correspondiente valor de contexto Cj. Se determina una regla de decisión Dm que se ajusta al Dcom recibido (etapa 43), obteniéndose el valor descomprimido Dfull (etapa 44) a partir del valor de la IDcom recibida y del valor de contexto Cm del Dm determinado. De acuerdo con la evolución prevista de los campos, se actualizarán ninguno, uno o más valores de contexto Cm (etapa 45) para mantener los datos del contexto. Este procedimiento se repetirá para nuevos paquetes a lo largo de la sesión de transferencia de datos.

Los campos variables que se transmiten en esta realización son el campo 316, que indica el número de secuencia RTP, el campo 317, que indica la marca temporal RTP y el campo 335, que indica la identificación IP. Teniendo en cuenta el hecho de que los incrementos en estos campos suelen permanecer constantes generalmente a lo largo de la sesión, podría sugerirse un sistema de codificación delta, conocido a través de la técnica anterior (en referencia a un paquete transmitido anteriormente). En cualquier caso, para evitar los problemas presentados anteriormente, se facilita una identificación independiente para cada paquete de la capa de red sometido a la compresión.

En la primera realización, los campos de encabezado se comprimen en campos abreviados y se transmiten a través del enlace. La longitud de un campo abreviado se selecciona para facilitar la transmisión de la información que facilita una correcta identificación del paquete durante una secuencia de compresión, un intervalo que suele ser más breve que la sesión. La identificación a corto plazo proporcionada por los campos abreviados, combinada con un contexto a más largo plazo mantenido en el descompresor, proporciona una identificación coherente de los paquetes a lo largo de la sesión de transferencia de datos y, de este modo, permite una transformación inequívoca de los campos de encabezados comprimidos en campos de encabezado completos a lo largo de una sesión completa de transferencia de datos.

Como ejemplo de este tipo de sistema, se presenta el caso de una marca temporal abreviada. La Figura 5 representa un formato para un encabezado comprimido utilizado en esta realización. El campo 51 indica el tipo T del paquete comprimido. Si T = 0, el último octeto 56 no se incluirá y los últimos seis bits 53 del primer octeto se pondrán a cero utilizándose para cualquier otro fin, como la comprobación CRC o una marca temporal abreviada. Si T = 1, el encabezado comprimido incluirá el octeto de longitud, y los bits 53 y el último octeto 56 se utilizarán para indicar la longitud de los datos útiles RTP. Esta información sobre la longitud es necesaria con cadenas de bits en las que la longitud del paquete puede variar, como por ejemplo las cadenas de bits de vídeo. El campo 52 indica el bit marcador del encabezado RTP, como se ha explicado anteriormente. La marca temporal abreviada en esta realización es un campo de 16 bits que indica los 16 bits menos significativos de la marca temporal RTP. Los datos de contexto incluyen los 16 bits más significativos de la marca temporal RTP y se mantendrán, al menos, en el lado del enlace correspondiente al descompresor.

El organigrama de la Figura 6 muestra las fases de la realización del método inventado cuando se utiliza la marca temporal abreviada. En la etapa 61 se recibe el estado de compresión, como en este caso en una marca temporal completa TSfull recibida al comienzo de la sesión. Al comienzo de la sesión se inicializan los datos de contexto, en este caso TSmem1 que incluye los 16 bits menos significativos de la marca temporal original, y TSmem2 que incluye los 16 bits más significativos de la marca temporal original (etapa 62). En la etapa 63 se recibe una nueva marca temporal abreviada TSabb que transporta los 16 bits menos significativos de la marca temporal de un nuevo paquete de datos de la capa de red comprimido. Como se verá más adelante, el valor de TSmem1 incluirá los 16 bits menos significativos de la marca temporal mayor recibida hasta ese momento.

Si la nueva marca temporal abreviada TSabb es mayor que el valor almacenado TSmem1, se comprobará nuevamente si la nueva marca temporal abreviada TSabb es mayor que la suma del valor almacenado TSmem1 y un valor predefinido \Delta. El valor \Delta representa un cambio máximo en los bits menos significativos que puede interpretarse como causado por algún fenómeno previsto como silencio, paquetes perdidos o paquetes que llegan en un orden ligeramente equivocado. Cuando el número representado por los 16 bits menos significativos de la marca temporal ha llegado al valor máximo, se reinicializará y comenzará de nuevo a partir del valor más pequeño (secuencia de compresión). Cuando un paquete llega tarde al compresor, es posible que el valor almacenado TSmem1 haya completado el bucle y, de este modo, el valor de la marca temporal abreviada recibida TSabb sea considerablemente mayor que TSmem1. Mediante la definición de un valor adecuado para \Delta pueden detectarse estos casos en la cadena de paquetes recibidos. Si la marca temporal abreviada recibida TSabb es mayor que TSmem1, pero la diferencia no es demasiado grande (inferior a \Delta), la marca temporal podrá reconstruirse utilizando los 16 bits más significativos almacenados en el valor TSmem2 y combinándolos con los 16 bits menos significativos recibidos desde el compresor (etapa 64). La marca temporal abreviada recibida TSabb es la mayor marca temporal abreviada recibida hasta el momento, por lo que se almacena como TSmem1. Si la marca temporal abreviada recibida TSabb es mayor que TSmem1 y la diferencia es superior a \Delta, se asume que TSabb ha llegado tarde y que TSmem1 ya ha completado el bucle. Para estos casos, se mantiene en los datos de contexto un valor de datos de contexto adicional TSmem3 relativo a la secuencia de compresión anterior. TSmem3 incluye el valor de TSmem2 almacenado anteriormente. La reconstrucción de la marca temporal se lleva ahora a cabo utilizando los 16 bits más significativos almacenados en el valor TSmem3 y combinándolos con los 16 bits menos significativos recibidos desde el compresor. No se llevan a cabo actualizaciones de los valores de TSmem1, TSmem2 y TSmem3.

Si el valor de la marca temporal abreviada recibida TSabb es inferior a TSmem1, se comprueba si la diferencia es mayor que \Delta. En ese caso, la marca temporal abreviada que incluye los 16 bits menos significativos de la marca temporal ha llegado al máximo, ha completado el bucle y el valor almacenado TSmem2 deberá incrementarse al siguiente valor posible (etapa 67). Después, podrá reconstruirse la marca temporal y actualizarse el valor almacenado TSmem1, como se ha explicado en las etapas 64 y 65. Por ejemplo, consideremos un caso en el que los valores almacenados de la marca temporal son TSmem1 = FF FF (hex), TSmem2 = 02 FF (hex), \Delta = 0FFF (hex) y el valor de la marca temporal abreviada recibida es TSabb = 00 0A (hex). Ahora el valor de la marca temporal abreviada 00 0A es menor que el valor almacenado de la marca temporal FF FF, la diferencia es superior a \Delta y, por lo tanto, los 16 bits más significativos 02 FF de TSmem2 deben actualizarse uno a uno a un valor 03 00. El valor resultante de la marca temporal será de este modo 03 00 00 0A. Si la diferencia es inferior a \Delta significa que el paquete corresponde a la secuencia actual pero ha llegado con retraso. En este caso, la marca temporal podrá reconstruirse utilizando los 16 bits más significativos almacenados en el valor TSmem2 y combinándolo con la marca temporal abreviada TSabb recibida desde el compresor. Debido a que esta no es la marca temporal abreviada más grande recibida hasta el momento, no se actualizará el valor TSmem1. Este procedimiento se seguirá a medida que siguen llegando nuevos paquetes.

Esta misma idea es aplicable también a otros campos. Por ejemplo, examinemos un número de secuencia completo del encabezado RTP. Si los números de la secuencia original son (en forma binaria) 00010000, 00010001, 00010010, los números de secuencia abreviados que se transmiten al descompresor son 0000, 0001, 0010. En el descompresor se mantienen los datos de contexto que incluyen al menos los bits más significativos actuales. Con un tipo similar de reglas de decisión, los datos comprimidos pueden asociarse a las secuencias de compresión del descompresor y transformarse en un campo de encabezado completo.

También es posible otro tipo de relación entre los datos comprimidos y los incrementos utilizados en el descompresor. Por ejemplo, cuando se sabe que la marca temporal puede cambiar en 240 para cada paquete, un incremento de uno en el compresor puede transformarse en un incremento de 240 en el descompresor. En este (valor de compresión \rightarrow
marca temporal descomprimida): 0001 \rightarrow 240 0010 \rightarrow 480 0011 \rightarrow 720 0100 \rightarrow 960, etc.

Como se muestra, los datos de contexto se actualizan en función de la información que contienen los campos abreviados recibidos. El grado de abreviatura, es decir, la cantidad de bits utilizada para representar el campo abreviado, tiene un efecto sobre la velocidad a la cual se actualiza la información de contexto en el descompresor. Por ejemplo, cuanto más breve sea la secuencia de compresión, con más frecuencia deberá actualizarse el valor de la marca temporal TSmem2 en la que se encuentran almacenados los bits más significativos de la marca temporal. Aun cuando puedan perderse algunos paquetes o aunque puedan cambiar ligeramente, las comparaciones de validez mostradas anteriormente se ocupan de que los datos puedan regenerarse correctamente. En conexiones inalámbricas, la pérdida de una larga secuencia de paquetes suele llevar a una caída de la llamada en curso. De este modo, mientras pueda mantenerse la conexión, también es posible mantener una información de contexto coherente en el descompresor con un grado razonable de compresión. Por ejemplo, con 6 bits es posible distinguir 64 paquetes. Es poco probable perder 64 paquetes sucesivos y seguir manteniendo la conexión, por lo que el método inventado funcionará bien mientras pueda mantenerse la conexión.

En el caso de paquetes que puedan dificultar la compresión, es decir los que llegan muy tarde al compresor y, por tanto, podrían perturbar el orden de actualización de la información de compresión, se dispone preferiblemente de una función adicional en el compresor. La recepción de un paquete retrasado cuando se detecta el campo que va a abreviarse plantea un riesgo de error en la información de compresión y, como resultado, se producirá una corrección ya en el lado del compresor. Por ejemplo, dichos paquetes pueden ser descartados en conjunto. Por ejemplo, los paquetes que lleguen tarde, pero pertenezcan a la secuencia de compresión anterior, podrán recuperarse mediante la utilización del valor de contexto TSmem3, como se ha explicado en relación con la figura 6. Un paquete que pertenezca a una secuencia de compresión anterior a la secuencia de compresión anterior no podría regenerarse correctamente y, por lo tanto, dichos paquetes son gestionados preferiblemente ya en el compresor. El organigrama de la figura 7 presenta un ejemplo de un algoritmo de filtrado de este tipo que puede añadirse al método inventado en el lado del compresor para gestionar situaciones en las que haya muchos paquetes retrasados.

En la etapa 71 se almacena toda la marca temporal del primer paquete recibido. Cuando se recibe un nuevo paquete (etapa 72) se lee su marca temporal Tsnew (etapa 73) y la diferencia D entre la marca temporal TS almacenada y se calcula la nueva temporal Tsnew (etapa 74). Si la diferencia D es superior a un cierto valor predefinida Dmax, el compresor considerará que el paquete está demasiado retrasado e iniciará una acción correctora (etapa 75). Dicha acción, por ejemplo, consiste en enviar campos completos en lugar de campos abreviados e incluir una indicación al descompresor para que no actualice los datos de contexto. Dicha acción también puede consistir en limitarse a descartar dichos paquetes retrasados. Esto sería una acción natural en relación con paquetes de datos en tiempo real puesto que los paquetes que llegan muy tarde resultan en algunos casos inútiles para las aplicaciones y, por lo tanto, pueden descartarse ya en el lado del compresor. Si la diferencia D no es mayor que Dmax, la marca temporal TS se comprimirá de acuerdo con el método inventado. Si la diferencia es superior a cero significa que el paquete ha llegado ligeramente retrasado. Preferiblemente, el valor almacenado TS representa el valor superior de la marca temporal transmitida hasta el momento y, por tanto, no se actualizará el valor de la marca temporal almacenada. Si la diferencia D es inferior a cero, se actualizará el valor de la marca temporal almacenada (etapa 77). Este procedimiento se seguirá para cada paquete a lo largo de la sesión.

En algunos casos, los datos de identificación pueden comprimirse al mínimo en el encabezado comprimido y, sin embargo, la secuencia de compresión abarcará toda la sesión. Esta realización incluye una transformación entre campos de la capa de red y protocolos de la capa de la red de acceso. La capa de red, en este contexto, se refiere a capas de protocolo de la capa de red de datos de paquete y en la realización mostrada aquí se hará referencia a los protocolos IP, UDP y RTP. En este contexto, la capa de red de acceso se refiere a la capa de protocolo específica de la red de acceso y responsable de las funciones de compresión y descompresión, en este caso SNDCP. Una unidad de paquete de datos (PDU) de la SNDCP contiene un número entero de octetos, un encabezado y una sección de datos. Se han definido dos formatos diferentes de SN-PDU, SN-DATA PDU para las transferencias de datos reconocidas y SN-UNITDATA PDU para las transferencias de datos no reconocidas. La figura 8 muestra el formato de una SNDCP SN-UNITDATA PDU utilizada en una transmisión no reconocida de GPRS. SN-UNITDATA PDU incluye un campo número N-PDU 81 que es un número que va incrementándose a lo largo de la sesión.

Puede generarse una transformación entre los paquetes de datos de la capa de red y los paquetes de datos de la capa de protocolo responsables de la compresión. En esta realización, se muestra una transformación entre el campo SNDCP SN-UNITDATA PDU número N-PDU y el número de secuencia RTP, la identificación IP y la marca temporal RTP. Cuando el número N-PDU se incrementa en uno, los valores del campo número de secuencia RTP 316 y del campo identificación IP 335 suelen incrementarse en un valor que es constante a lo largo de la sesión. Además, existen codificadores-decodificadores (codecs) para los cuales la diferencia entre marcas temporales RTP posteriores es constante. Utilizando una representación hexadecimal, para un caso en el que dicha diferencia sea F0 y los incrementos para el número de secuencia RTP sea uno y para la identificación IP sea 0100, la siguiente transformación resultará eficaz:

Número N-PDI = 5

Número de secuencia RTP = 16C5

Marca temporal RTP = 02 FFBFEF

Identificación IP = E7E6

Número N-PDI = 6

Número de secuencia RTP = 16C6

Marca temporal RTP = 02 FFC0DF

Identificación IP = E8E6

Número N-PDI = 7

Número de secuencia RTP = 16C7

Marca temporal RTP = 02 FFC1 DF

Identificación IP = E9E6

Aunque en este caso se han utilizado incrementos constantes, pueden implementarse también las transformaciones de diversas formas diferentes. Por ejemplo, puede establecerse una función de transformación entre los campos protocolo de la capa de red de acceso y encabezado del protocolo de la capa de red. Además, dependiendo de la aplicación, también puede utilizarse una transformación entre cualesquiera otros campos del protocolo de la capa de la red de acceso. Los datos de contexto en el descompresor incluyen la información necesaria para la transformación del campo protocolo de capa de red de acceso al campo protocolo de capa de red. La fase de comparación del método presentado en la figura 4 incluirá una simple comprobación de la validez de los contenidos del campo capa de red de acceso. Los datos de contexto, preferiblemente, permanecerán constantes, por lo que no precisan de actualización (véase etapa 45).

Para los paquetes de la capa de red, cuando existe una posibilidad de que los campos invariables experimenten cambios durante una sesión, se sugiere una realización alternativa que se muestra en la figura 9. La realización se presenta nuevamente utilizando el ejemplo cuando la entidad transmisora es la MS y la entidad receptora es el SGSN. En relación con la configuración de la sesión, el estado de compresión se almacena tanto en la MS (SoC_{c}) como en la SGSN (etapa 91) (SoC_{d}). Cuando se recibe un paquete desde el codec de voz para su transmisión al SGSN (etapa 9), se comprueba (etapa 93) si se ha producido algún cambio en los campos invariables del encabezado que va a comprimirse y en los campos en estado de compresión. Si no se detectan cambios, se comprime el encabezado como se ha descrito anteriormente (etapa 94) y el paquete comprimido se envía al descompresor (etapa 95). En cualquier caso, cuando se detectan cambios, una nueva función SNDCP extraerá del nuevo encabezado únicamente los cambios invariables que se hayan modificado (etapa 96), los actualizará de acuerdo con el estado de compresión almacenado (etapa 97), transmitirá dichos valores al SGSN (etapa 98) y actualizará también los valores de acuerdo con el estado de compresión almacenado en el SGSN (etapa 98). La transmisión de dicha información puede efectuarse utilizando el modo reconocido o la protección contra graves errores.

En un algoritmo de compresión/descompresión puede utilizarse cualquier combinación de estas realizaciones. A continuación se facilita un ejemplo de la utilización del método inventado. La tabla 1 representa campos de un encabezado completo correspondientes a los protocolos de capa de red IP, UDP, IP. Los campos sombreados corresponden a los campos que permanecen constantes a lo largo de la sesión, y los campos blancos representan los campos que pueden modificarse durante la sesión.

TABLA 1 Ejemplo de encabezado IP, UDP y RTP

1

Supongamos que este es el primer encabezado RTP / IP / UDP recibido en el compresor SNDCP. Los valores mostrados aquí están en formato hexadecimal y hay 4 octetos por fila. Las primeras 5 filas (20 octetos) representan un encabezado IP. Las dos filas siguientes son octetos de un encabezado UDP, y las últimas tres filas representan el encabezado RTP, y en su conjunto forman un típico encabezado RTP / UDP / IP (40 bytes). El compreso SNDCP copiará estos valores y se enviará el encabezado completo al correspondiente elemento SNDCP.

La tabla 2 presenta un encabezado posterior recibido por el compresor.

TABLA 2 Siguiente encabezado IP / UDP / RTP

2

Los campos que difieren de los valores almacenados están sombreados en las tablas 1 y 2 e incluyen

\bullet

Campo de identificación de 16 bits del encabezado IP:

De E7E6 a E8E6

\bullet

Suma de control del encabezado de 16 bits del encabezado IP:

De 63DC a 62DC

\bullet

Suma de control UDP de 16 bits:

De AF5E a D440

\bullet

Número de secuencia del encabezado RTP:

De 16C5 a 16C6

\bullet

Marca temporal del encabezado RTP:

De 02FFBFEF a 02FFC0DF

Otros campos permanecen sin cambios. A continuación, de acuerdo con la invención, se genera el siguiente encabezado comprimido:

TABLA 3

3

El formato del encabezado comprimido es similar al presentado en relación con la figura 5 y se muestra en formato binario. Como la longitud del paquete no ha cambiado, el séptimo bit del primer octeto es 0, el bit marcador es 0 y, en este caso, el resto de los bits del primer octeto son ceros. Los siguientes dos octetos contienen la marca temporal abreviada (C0 DF en formato hexadecimal). Un paquete SNDCP que incluye el encabezado comprimido y los datos útiles RTP se envía al descompresor.

La marca temporal completa se reproduce a partir del valor de la marca temporal abreviada descrito anteriormente en relación con la figura 6. El número de secuencia del encabezado RTP y el número de identificación de 16 bits del encabezado IP se obtendrán utilizando el número N-PDU del paquete SNDCP como un desplazamiento con respecto al último encabezado completo. Como el descompresor recibió el primer paquete que incluía el encabezado completo, el algoritmo efectuó una asociación entre el número de secuencia RTP y el número N-PDU del paquete SNDCP. En este caso el número de secuencia sería 16 C5 y el número N-PDU será, por ejemplo, x. Cuando el encabezado comprimido se envía a SN-UNITDATA, el número N-PDU será y, lo que indica que la diferencia entre las N-PDU será y-x y dicho número se sumará al número de secuencia almacenado.

Se presentará un terminal móvil de un sistema de comunicaciones móviles como ejemplo de un elemento de red que implementa el método descrito en este documento. La estructura del terminal móvil, de acuerdo con la invención, es la de un terminal móvil tradicional ya conocido por cualquier persona versada en la materia. Haciendo referencia a la figura 10, una unidad central de proceso 101 controla los bloques responsables de las diferentes funciones de la estación móvil: una memoria (MEM) 102, un bloque de radiofrecuencia (RF) 103, un interfaz de usuario (UI) 104 y una unidad de interfaz (IU) 105. La CPU suele implementarse con uno o más microprocesadores que funcionalmente son microprocesadores inter-operativos. La memoria incluye preferiblemente una ROM (memoria de sólo lectura) y una RAM (memoria de acceso aleatorio) y está generalmente suplementada por la memoria facilitada con el módulo de identificación de usuario SIM. De acuerdo con su programa, el microprocesador utiliza el bloque RF 103 para transmitir y recibir mensajes de radio. La comunicación con el usuario está gestionada por el UI 104 que normalmente incluye un altavoz, una pantalla y un teclado. La unidad de interfaz 105 constituye el enlace con una entidad de procesamiento de datos y está controlada por la CPU 101. La entidad de procesamiento de datos 101 puede ser un procesador de datos integrado o un equipo externo de procesamiento de datos.

La figura 10 también muestra los módulos funcionales de una entidad de procesamiento de datos TE de acuerdo con la invención. El equipo terminal TE puede ser, por ejemplo, un ordenador personal ya conocido en los entornos de oficinas, o una estación de trabajo. El TE puede también formar parte integrante de la MS (por ejemplo, los "smartphones") compartiendo elementos como el UI y la CPU con la MS. A la inversa, la MS puede formar parte del TE (por ejemplo, un teléfono de tarjeta). Puede apreciarse que, aunque en la figura 10 se muestren dos bloques independientes, no existe ninguna restricción sobre la configuración.

El TE incluye sustancialmente una unidad de interfaz IU 107 que se corresponde con la de la MS para controlar el interfaz con la MS. También incluye un interfaz de usuario UI 108 para recibir comandos del usuario y transmitir información al usuario, una memoria MEM 109 para almacenar aplicaciones SW APP 110 y datos relacionados con las aplicaciones, y un procesador CPU 111 para controlar las operaciones del TE y llevar a cabo los procedimientos de la aplicación.

Existe una pluralidad de métodos para conectar la estación móvil MS y la entidad de procesamiento de datos, todos ellos conocidos para cualquier persona versada en la materia. Uno de los métodos consiste en interconectar los dispositivos a través de unidades de interfaz IU, incluyendo conexiones mediante cable, el interfaz de interconexión apropiado, por ejemplo un puerto serie, y suplementado con el software de interfaz adecuado en las CPUs que controlan el funcionamiento de las unidades de interfaz IU. Otro método consiste en utilizar conexiones inalámbricas en la gama de longitudes de onda de infrarrojos o utilizar unidades transmisoras / receptoras de radiofrecuencia de baja potencia. Las nuevas soluciones en las que la MS está integrada en el TE también facilitan una plataforma muy factible para el sistema, de acuerdo con la invención.

Cuando un usuario desea acceder a una red de datos de paquetes con el TE, basándose en comandos enviados desde dispositivos de entrada de datos por parte del usuario, el procesador CPU 111 recupera de la memoria MEM 109 una aplicación SW de acceso a datos de paquetes APP 110. La aplicación se procesa en la CPU 111 en forma de paquete y cuando surge la necesidad de enviar información relacionada con la aplicación se envía un paquete al MS a través del IU 107.

En la primera realización, las funciones de compresión y descompresión están implementadas en la capa SNDCP de la pila de protocolo del terminal móvil. En la realización aquí mostrada, los elementos afectados por el funcionamiento de la SNDCP son aquellos que se han descrito en la parte correspondiente a la MS. En dirección de subida, la MS actúa como un compresor y, en dirección de bajada, la MS actúa como un descompresor. Los valores utilizados para las operaciones de compresión y descompresión se envían a la unidad RF 102 para su transmisión al SGSN a través de la BS. Los paquetes comprimidos procedentes del SGSN son recibidos por la unidad RF y enviados a la CPU 111 para su descompresión. Los paquetes descomprimidos se envían al TE a través de las unidades de interfaz 105 y 107.

Aunque la invención se ha mostrado y descrito como una realización preferida, las personas medianamente versadas en la materia se darán cuenta de que pueden introducirse modificaciones en la realización preferida sin alejarse del ámbito de la invención, tal y como se reivindica más adelante. Por ejemplo, en el futuro también se implementarán servicios GPRS o derivados (derivados GPRS) con otros sistemas de comunicaciones móviles. La norma WCDMA (Wideband Code Division Multiple Access) de tercera generación tiene una estructura cercana a la del GPRS e incluye una capa L3CE que se corresponde con la SNDCP del GPRS. Dicha capa, para la incorporación de las funciones de la invención, es la capa SNDCF de CDMA2000. Es posible aplicar también la invención en redes fijas. De este modo, las posibilidades de realizar y utilizar la invención sólo están limitadas por las reivindicaciones adjuntas.

Claims (13)

1. Método para la transferencia de un paquete de datos desde un compresor (MS) a un descompresor (SGSM), incluyendo dicho paquete de datos un encabezado con campos de datos del encabezado, almacenándose en el descompresor algunos de los campos de datos del encabezado que permanecen constantes durante la transferencia de datos, incluyendo dicho método:

el envío desde el compresor y la recepción en el descompresor de un paquete de datos que incluye información sobre uno o más campos de datos del encabezado que experimentan variaciones durante la transferencia de datos;

la descompresión del encabezado utilizando los campos de datos del encabezado almacenados y la información recibida en el o los campos de datos del encabezado que varían durante la transferencia de datos, caracterizado porque:

Después de la configuración de la sesión y en relación con un campo de datos de encabezado variable, se envía desde el compresor y se recibe en el descompresor tan sólo un valor comprimido, identificando dicho valor comprimido el paquete de datos de una secuencia de compresión y consistiendo dicho valor comprimido en un primer número de bits menos significativos del campo de datos del encabezado;

manteniendo en el descompresor datos de contexto que incluyen información para relacionar el valor comprimido recibido con la correspondiente secuencia de compresión, actualizándose la información en función de los valores comprimidos recibidos;

utilizando el valor comprimido y la información de la correspondiente secuencia de compresión para transformar el valor comprimido en un campo de datos del encabezado descomprimido.

2. Método de acuerdo con la reivindicación 1, caracterizado porque la secuencia de compresión incluye una serie de paquetes de datos sucesivos que pueden diferenciarse entre sí con la resolución proporcionada por el valor de compresión.

3. Método de acuerdo con las reivindicaciones 1 ó 2, caracterizado porque el encabezado es un encabezado
RTP / UDP / IP, y el campo de datos es uno de los siguientes: identificación IP, número de secuencia RTP, marca temporal RTP.

4. Método de acuerdo con la reivindicación 3, caracterizado porque los datos de contexto incluyen, al menos, un segundo número de los bits más significativos del campo de datos.

5. Método de acuerdo con la reivindicación 1, caracterizado porque el compresor y el descompresor son elementos de red de una red de acceso a una red de datos de paquetes IP.

6. Método de acuerdo con la reivindicación 5, caracterizado porque el compresor y el descompresor son elementos de red de una red de acceso inalámbrico a una red de datos de paquetes IP.

7. Método de acuerdo con la reivindicación 6, caracterizado porque el compresor y el descompresor son elementos de red de una red de comunicaciones móviles que soporta GPRS.

8. Método de acuerdo con la reivindicación 7, caracterizado porque las funciones de compresión y descompresión están implementadas en la capa SNDCP del GPRS.

9. Elemento de red de acceso (MS) que incluye:

unos medios (101,103) para transferir un paquete de datos a un descompresor (SGSN), incluyendo dicho paquete de datos un encabezado con campos de datos del encabezado;

unos medios (101,103) para comprimir el encabezado excluyendo los campos de datos del encabezado que permanecen constantes durante la transferencia de datos desde la transmisión;

unos medios (101, 103) para enviar al descompresor un paquete de datos que incluye información sobre uno o más campos de datos del encabezado que varían a lo largo de la transferencia de datos; caracterizado por:

unos medios (101, 103) adaptados para enviar, después de la configuración de la sesión, en relación con unos datos de encabezado variables en su poder, tan sólo un valor comprimido asociado con la identificación del paquete de datos en una secuencia de compresión, consistiendo el valor comprimido en un primer número de bits menos significativos del campo de datos del encabezado.

10. Elemento de red de acceso, de acuerdo con la reivindicación 9, caracterizado por

unos medios (101, 103) para recibir un paquete de datos que incluyen un ordinal, indicando dicho ordinal el orden del paquete en una serie de paquetes transmitidos;

unos medios (101, 103) para comparar el ordinal del paquete recibido con un ordinal almacenado anteriormente;

unos medios (101, 103) para iniciar una función de error como respuesta a la diferencia entre el ordinal del paquete recibido y el ordinal de comparación que supera un límite predefinido;

unos medios (101, 103) para iniciar un algoritmo de compresión del encabezado, como respuesta a la diferencia entre el ordinal del paquete recibido y el ordinal de comparación inferior a un límite predefinido,;

unos medios (101, 103) para almacenar el ordinal del paquete recibido como ordinal de comparación, como respuesta al ordinal del paquete recibido, cuando es superior al ordinal de comparación.

11. Elemento de red de acceso (MS) que incluye:

unos medios (101, 103) para recibir paquetes de datos, incluyendo dichos paquetes de datos un encabezado con campos de datos del encabezado;

unos medios (101, 102) para almacenar los campos de datos del encabezado que permanecen constantes durante la transferencia de datos;

unos medios (101, 103) para recibir paquetes de datos comprimidos que incluyen información sobre uno o más campos de datos de encabezado que varían durante la transferencia de datos;

unos medios (101) de descompresión de paquetes de datos comprimidos, utilizando los campos de datos del encabezado almacenados y la información recibida en el campo o campos de datos del encabezado que varían durante la transferencia de datos; caracterizado por

unos medios (101, 103) adaptados para recibir, tras la configuración de la sesión, en relación con un campo de datos de encabezado variable de un paquete de datos, tan sólo un valor comprimido que identifica el paquete de datos en una secuencia de compresión, consistiendo el valor comprimido en un primer número de bits menos significativos del campo de datos del encabezado;

unos medios (101, 102) para mantener datos de contexto que incluyan información para relacionar el valor comprimido recibido con la correspondiente secuencia de compresión, actualizándose dicha información en función de los valores comprimidos recibidos;

unos medios (101, 102) que utilizan el valor comprimido y la información de la correspondiente secuencia de compresión para transformar el valor comprimido en un campo de datos de encabezado de un paquete de datos descomprimido.

12. Elemento de una red de acceso de acuerdo con las reivindicaciones 9 u 11, caracterizado porque el elemento es un terminal móvil de una red de comunicaciones móviles.

13. Elemento de una red de acceso de acuerdo con las reivindicaciones 9 u 11, caracterizado porque el elemento es un SGSN de una red de comunicaciones móviles que soporta GPRS.