ES2287572T3 - Metodo de compresion de cabecera. - Google Patents

Metodo de compresion de cabecera. Download PDF

Info

Publication number
ES2287572T3
ES2287572T3 ES03808009T ES03808009T ES2287572T3 ES 2287572 T3 ES2287572 T3 ES 2287572T3 ES 03808009 T ES03808009 T ES 03808009T ES 03808009 T ES03808009 T ES 03808009T ES 2287572 T3 ES2287572 T3 ES 2287572T3
Authority
ES
Spain
Prior art keywords
mode
header
rejection
unit
decompressor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES03808009T
Other languages
English (en)
Inventor
Ghyslain Pelletier
Lars-Erik Jonsson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2287572T3 publication Critical patent/ES2287572T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Auxiliary Devices For And Details Of Packaging Control (AREA)
  • Prostheses (AREA)

Abstract

Método para producir una banda multicapa (14) que comprende al menos tres capas de material flexible, tal como papel y material no tejido, encolando las capas, en el que un primer rodillo de transferencia de cola con diseño (5), que tiene un diseño tridimensional de protuberancias (6), se pone en contacto con un primer dispositivo de aplicación de cola (4), y transfiere cola a un primer (1) material flexible en forma de banda (1) en un diseño de encolado que corresponde a la configuración de las protuberancias (6), un segundo material flexible en forma de banda (7) que se pone en contacto con el lado en el que se ha aplicado la cola de dicho primer material flexible en forma de banda (1), un segundo rodillo de transferencia de cola con diseño (14) que tiene un diseño tridimensional de protuberancias (15), se pone en contacto con un segundo dispositivo de aplicación de cola (13), y transfiere cola a un lado externo de los materiales flexibles en forma de banda primero y segundo combinados (1, 7) en un segundo diseño de encolado que corresponde a al configuración de las protuberancias (15) del segundo rodillo de transferencia de cola, un tercer material flexible en forma de banda (16) que se pone en contacto con el lado en el que se ha aplicado cola de dichos primer y segundo materiales flexibles en forma de banda combinados (1, 7) en una pinza de prensado entre un rodillo de laminación con diseño (18) que tiene un diseño tridimensional de protuberancias (19) que corresponde a los diseño de encolado primero y/o segundo, caracterizado porque el diseño de encolado de dicho segundo rodillo de transferencia de cola (14) se aplica, como se observa, a lo ancho de la banda multicapa, alineado sustancialmente con el diseño de encolado aplicado por el primer rodillo de transferencia de cola (5), el rodillo de laminación (18) y el primer y segundo rodillos de transferencia de cola (5, 14) se hacen funcionar en coincidencia exacta entre sí, de modo que al menos tres capas del material flexible en forma de banda (1, 7, 16) se prensan y encolan conjuntamente en un diseño que corresponde a los diseños de encolado alineados.

Description

Método de compresión de cabecera.
Campo técnico
La presente invención se refiere en general a sistemas de comunicación basados en paquetes y en particular a un método y medios para la compresión de cabecera.
Antecedentes
Debido al tremendo éxito de Internet, hacer uso del protocolo de Internet (IP, Internet Protocol) sobre todos los tipos de enlacesse ha convertido en una tarea que supone un reto. Sin embargo, esto es especialmente difícil para enlaces de banda estrecha tales como enlaces celulares, ya que las cabeceras de los paquetes de protocolo IP son en general bastante grandes comparadas con los datos (carga útil, payload). Por ejemplo, cuando los datos de habla normales se transportan mediante los protocolos utilizados para voz sobre IP (VoIP, Voice-over-IP), la cabecera representa a menudo como mucho el 70% del paquete, lo que da como resultado una utilización muy ineficiente del enlace.
La compresión de cabecera se refiere a técnicas para minimizar el ancho de banda necesario para información llevada en cabeceras en una base por salto sobre enlaces punto a punto. Hay varios protocolos de compresión de cabecera, incluyendo RFC 1144 [1], RFC 2507 [2] y RFC 2508 [3]. Los principios de compresión de cabecera se aprovechan del hecho de que algunos campos de cabecera no cambian dentro de un flujo, o cambian alternativamente con valores pequeños o predecibles. Estas características se utilizan por los esquemas de compresión de cabecera, que envían información estática sólo inicialmente, mientras que los campos cambiantes se envían con sus valores absolutos o como diferencias de paquete a paquete. La información completamente aleatoria tiene que enviarse sin ningún tipo de compresión.
La compresión de cabecera es un componente importante para realizar VoIP sobre inalámbrico (VoIPoW, Voice-over-IP Wireless) una alternativa económicamente viable para poner en circuito voz conmutada, y para este propósito se han desarrollado soluciones para compresión robusta de cabecera (ROHC, Robust Header Compression). ROHC, tal como se define en RFC 3095 [4], es una estructura (framework) extensible para la que pueden definirse perfiles de compresión de diversos protocolos. Para VoIP, los datos de aplicación se transportan de extremo a extremo dentro de un flujo IP/ protocolo de datagrama de usuario (UDP, User Datagram Protocol)/protocolo de transporte en tiempo real (RTP, Real-time Transport Protocol). La compresión de cabecera de IP/UDP/RTP está definida por el perfil ROHC 0x0001 (ROHC RTP) y es aplicable para servicios VoIP entre otros. El esquema de compresión de cabecera ROHC RTP se ha diseñado para comprimir eficientemente cabeceras sobre una capa de enlace arbitraria. El mismo esquema ROHC RTP maneja la mayor parte de la funcionalidad y, excepto para la negociación, sólo la estructuración de tramas y la detección de errores necesitan proporcionarse mediante la capa de enlace.
ROHC tiene tres modos de funcionamiento, que, para un contexto específico, controlan las acciones y la lógica a realizar así como los tipos de paquete a utilizar durante estados diferentes del funcionamiento de compresión de cabecera. Los formatos y tipos de paquete permitidos pueden variar de un modo a otro. El modo unidireccional (modo U) se utiliza al principio de cualquier compresión ROHC antes de que pueda ocurrir la transición a otro modo. El modo optimista bidireccional (modo O) tiene como objetivo maximizar la eficacia de la compresión y está asociado con la poca utilización del canal de retroalimentación. El modo fiable bidireccional (modo R) tiene como objetivo maximizar la robustez contra propagación del daño de contexto y pérdida.
Cuando está en modo U, los paquetes se envían sólo desde el compresor al descompresor; este modo puede utilizarse por tanto sobre enlaces en los que una vía de retorno desde el descompresor al compresor es o bien no deseada o bien no está disponible, y en este modo se utilizan refrescos periódicos. El modo O es similar al modo U con la diferencia de que se utiliza un canal de retroalimentación para enviar solicitudes de recuperación de errores y (opcionalmente) confirmaciones de actualizaciones de contexto significativas desde el descompresor al compresor. Al modo U y al modo O se les hace referencia con frecuencia como el modo U/O debido a la naturaleza tan similar de los mismos. El modo R es significativamente diferente de los otros dos modos, principalmente por una utilización más extensa del canal de retroalimentación y una lógica más estricta para realizar actualizaciones de contexto. El modo R también utiliza algunos tipos de paquetes distintos sólo entendidos y útiles en este modo.
Cada modo de funcionamiento tiene diferentes propiedades en términos de eficacia de compresión, robustez y complejidad de procesamiento. ROHC no especifica cómo y cuándo deberían utilizarse los modos respectivos (excepto que la compresión ROHC debe empezar siempre en el modo U), por los que la lógica para las transiciones entre modos se convierte en un asunto de implementación. Las transiciones entre modos pueden iniciarse sólo mediante el descompresor, y según la especificación actual para la compresión robusta de cabecera (RFC3095) cada implementación debe soportar todos los modos de funcionamiento.
Las características y requisitos anteriores de los esquemas de compresión de cabecera de la técnica anterior están asociadas con un número de inconvenientes.
\newpage
Es probable que los proveedores de compresión de cabecera optimicen sus implementaciones de compresor para modos específicos de funcionamiento, por ejemplo para minimizar las necesidades de memoria o la potencia de procesamiento requerida. Sin embargo, no hay garantía de que una implementación particular se utilice realmente en su modo preferido. En su lugar, puede forzarse en funcionamiento por debajo del óptimo, dando como resultado una eficacia de compresión y rendimiento de enlace reducidos.
Otro problema es que se necesita mucha funcionalidad para una implementación ROHC para soportar todos los modos de compresión. Tienen que realizarse acciones de implementación, validación y pruebas considerables, lo que a su vez implica tiempos de implementación relativamente largos y altos costes de implementación. Puede que no todos los modos sean necesariamente útiles en un entorno específico. Además, para minimizar el campo de influencia del programa y/o el tiempo requerido para construir un algoritmo ROHC interoperable, sería a veces deseable soportar sólo el/los modo(s) que concuerden con la estrategia de despliegue de un implementador particular.
Por consiguiente, la compresión de cabecera de los sistemas de telecomunicación convencionales dista mucho de ser satisfactoria y hay una necesidad considerable de un método de compresión de cabecera mejorado, en particular uno que ofrezca flexibilidad del modo de compresión.
Un método y aparato convencional para compresión de cabecera se conocen del documento EP 1 180 871.
\vskip1.000000\baselineskip
Sumario
Un objetivo general de la presente invención es conseguir una compresión de cabecera más eficaz. Un objetivo específico es proporcionar mecanismos para compresión de cabecea más flexible con respecto a modos de compresión. Otro objetivo es habilitar fácilmente esquemas de compresión de cabecera implementados.
Estos objetivos se consiguen según las reivindicaciones adjuntas.
Brevemente, la presente invención consigue una compresión de cabecera más eficaz por medio de un mecanismo que permite a un compresor rechazar una solicitud de un descompresor para un cambio de modo no deseable. Según el método propuesto, el compresor indica, preferiblemente mediante señalización implícita o explícita, al descompresor que la solicitud de cambio de modo se está rechazando/ignorando. En respuesta a esta indicación, el descompresor puede abortar a partir de entonces la transición iniciada, con el entendimiento de que el compresor tiene razones válidas para rehusar la transición entre modos. Si el descompresor tiene constancia del rechazo indicado, responde mediante una acción de confirmación de rechazo, que implica un rechazo satisfactorio. La acción de confirmación de rechazo puede por ejemplo implicar una frecuencia de retransmisión disminuida o la retransmisión suspendida de la solicitud de cambio de modo, o un mensaje de confirmación de rechazo explícito. El compresor determina preferiblemente si el rechazo fue satisfactorio monitorizando e interpretando el comportamiento de señalización del descompresor y en caso de un rechazo satisfactorio, el compresor permanece en su modo actual.
Las realizaciones preferidas de la invención consiguen la señalización de rechazo explícito enviando un mensaje de rechazo de cambio de modo con un valor de modo redefinido desde el compresor al descompresor, y señalización de rechazo implícito ignorando intencionadamente las solicitudes por un periodo de tiempo predeterminado. También puede haber realizaciones con señalización combinada de rechazo explícito e implícito.
Por lo tanto, por medio de un método de mensajería según la presente invención, un compresor de cabecera puede o bien ignorar de manera segura una solicitud de un descompresor o bien señalizar explícitamente el rechazo de la solicitud de cambio de modo. Esto hace posible al compresor deshabilitar la transición a un modo particular, si se prefiere, considerando factores diferentes, incluyendo algunos desconocidos para el descompresor. También permite implementaciones de compresor que sólo soportan un subconjunto de todos los modos de funcionamiento para la compresión de cabecera. En particular, sólo pueden proporcionarse implementaciones en modo U/O ventajosas que concuerden con las especificaciones ROHC.
Según otros aspectos de la invención, se proporcionan un sistema de comunicación y una unidad de compresor de cabecera.
La compresión de cabecera según la presente invención ofrece las siguientes ventajas:
-
eficacia mejorada de compresión de cabecera
-
utilización eficiente del ancho de banda disponible
-
campo de influencia de la implementación reducido
-
necesidades reducidas de memoria
-
menos funcionalidad que implementar, validar y probar
-
tiempo y coste de implementación mejorados
-
productos ROHC más fácilmente desplegables
-
implementaciones específicas de un modo (por ejemplo U/O) extendidas
Breve descripción de los dibujos
La invención, junto con los objetivos y ventajas adicionales de la misma, se entiende mejor haciendo referencia a la siguiente descripción y a los dibujos adjuntos, en los que:
la figura 1 es un diagrama de bloques esquemático que ilustra una red de comunicación a modo de ejemplo, en la que puede utilizarse la presente invención;
la figura 2 ilustra un mecanismo de compresión de cabecera, en el que puede utilizarse la presente invención;
la figura 3 es un diagrama de flujo de un método de compresión de cabecera según una primera realización a modo de ejemplo de la presente invención; y
la figura 4 es un diagrama de flujo de un método de compresión de cabecera según una segunda realización a modo de ejemplo de la presente invención.
Descripción detallada
La figura 1 es un diagrama de bloques esquemático que ilustra una red de comunicación a modo de ejemplo de un sistema global para comunicación móvil / servicio general de radiocomunicación por paquetes (GSM, Global System for Mobile communication / GPRS, General Packet Radio Service) en la que puede utilizarse la presente invención. Se muestra una red radio que comprende un número de estaciones móviles/ terminales 10, tales como teléfonos móviles, ordenadores portátiles y retransmisores inalámbricos, que se comunica con un subsistema de estación base (BSS, Base Station Subsystem) sobre enlaces 11 inalámbricos. El BSS contiene normalmente un gran número de estaciones 12 transceptoras base (BTS, Base Transceiver Stations) y controladores 13 de estación base (BSC, Base Station Controllers). Cada BTS sirve a los terminales móviles dentro de su respectiva área de cobertura y varias BTS se controlan mediante un BSC, que a su vez proporciona acceso a la red central, que comprende un centro 14 de conmutación móvil (MSC, Mobile Switching Center) y un centro 15 de conmutación móvil de pasarela (GMSC, Gateway Mobile Switching Center). El tráfico GSM se encamina a través del MSC 14, que está asociado con un registro de localización de visitantes (VLR, Visitor Location Register) responsable de la localización actual de un terminal 10 móvil. La comunicación a y desde redes externas se maneja mediante el GMSC 15. Volviendo a la subred conmutada por paquetes, comprende un nodo 16 de soporte de servicio GPRS (SGSN, Serving GPRS Support Node) y un nodo 17 de soporte de pasarela GPRS (GGSN, Gateway GPRS Support Node). El GGSN actúa como una interfaz hacia redes externas de datos por paquetes, mientras que el SGSN es responsable de la entrega de paquetes a y desde terminales dentro de su área de servicio.
En la práctica, la mayoría de la redes comprenden múltiples nodos de red dispuestos en formas mucho más complejas que en el ejemplo básico de la figura 1. Además, la figura 1 es un ejemplo de un tipo de sistema de comunicación en el que puede utilizarse la presente invención. La invención también puede aplicarse en otras redes de comunicación de datos por paquetes, incluyendo por ejemplo redes de comunicación inalámbricas de datos por paquetes cdma2000 así como sistemas que utilizan otras tecnologías de radio para IP inalámbrico tal como Wlan.
La compresión de cabecera se utiliza normalmente para reducir el ancho de banda requerido de uno o más enlaces en la red de comunicación ilustrada y mejora de ese modo su eficacia y velocidad de transmisión. En particular, la comunicación inalámbrica requiere a menudo tal reducción de ancho de banda, pero la compresión de cabecera puede ser útil también para otros enlaces también, incluyendo enlaces estáticos/cableados. Generalmente, hay tanto un compresor como un descompresor en cada extremo de un enlace en el que se aplica compresión de cabecera. En un sistema inalámbrico, éstos se ubican con frecuencia en la estación 10 móvil para el extremo terminal del enlace 11 pero también puede ubicarse por ejemplo a cada lado de un transceptor y receptor utilizado como un retransmisor. En el lado de la red del enlace 11, el compresor y el descompresor pueden estar dispuestos en uno o más de los siguientes nodos: un SGSN 16 o GGSN 17 para un sistema de datos por paquetes basado en GPRS, un nodo de servicio de datos por paquetes (PDSN, Packet Data Serving Node) (no mostrado) para un sistema de datos por paquetes cdma2000, o en la estación 12 base u otro nodo de la red de acceso por radio.
En la figura 2 se ilustra el principio general de la compresión de cabecera. Se muestran una unidad 20 de compresor de cabecera y una unidad 22 de descompresor de cabecera. Estas unidades 20, 22 se comunican sobre un enlace con un canal directo (desde el compresor hasta el descompresor) así como un canal de retroalimentación opcional. Además de los datos/carga útil reales, cada entrada de paquete IP a la unidad de compresor de cabecera consiste en una parte de cabecera (representada en la figura 2 por un campo de rayas) con campos de direcciones origen y destino, comprobación de errores, puerto y protocolo, etc. La parte de cabecera constituye con frecuencia un parte mayor del paquete que los datos. El mandar el paquete completo requeriría por tanto un gran ancho de banda y por lo tanto el paquete se comprime eliminando información de cabecera redundante en la unidad 20 de compresor de cabecera antes de transferirse sobre el enlace limitado en ancho de banda (11 en la figura 1). La unidad 22 de descompresor de cabecera reconstruye el paquete en un paquete descomprimido idéntico substancialmente al paquete de entrada original.
La compresión de cabecera se basa normalmente en el reconocimiento de que muchos campos de cabecera de paquetes que pertenecen al mismo flujo son constantes o raramente cambiantes, y por lo tanto los campos de cabecera llenos sólo tienen que enviarse ocasionalmente. Los detalles y reglas de compresión de cabecera se proporcionan en varios protocolos de compresor de cabecera. En esta descripción la atención radicará principalmente en ROHC para fines a modo de ejemplo, pero aunque la presente invención es muy útil junto con ROHC, y en particular en los perfiles (RFC 3095 [4]), el perfil [5] ROHC UDP-Lite, el perfil [6] ROHC sólo IP, el perfil (RFC 3242 [7]) LLA así como la extensión del modo R al perfil [8] LLA, no está de ningún modo restringida al mismo. Otros esquemas de compresión de cabecera actuales o futuros, ROHC o no, también están dentro del alcance de la invención.
Como se indica en la sección de los antecedentes, la especificación de compresión robusta de cabecera (RFC3095) establece que "todas las implementaciones ROHC DEBEN implementar y soportar todos los tres modos de funcionamiento". Las transiciones entre modos han de realizar como sigue.
\vskip1.000000\baselineskip
Desde modo U al modo O
Si un canal de retroalimentación está disponible, el descompresor puede decidir iniciar una transición entre modos desde el modo U al modo O, enviando un paquete de retroalimentación que lleva una solicitud de un cambio de modo al modo O. Se permite al descompresor pasar ya al modo O, ya que los tipos de paquete utilizados tanto para el modo U como para el modo O son los mismos. El compresor pasará al modo O tan pronto como se reciba la solicitud.
\vskip1.000000\baselineskip
Desde el modo O al modo R
El descompresor puede iniciar una transición de modo desde el modo O al modo R enviando una solicitud al compresor. Una vez que se ha iniciado la transición, no se permite al compresor utilizar ninguno de los tipos de paquete que utilizan un identificador común salvo para los que la interpretación entre el modo U/O y el modo R difiere, normalmente los formatos de paquetes más eficaces. Hasta que el descompresor recibe una confirmación desde el compresor acerca del cambio de modo, el descompresor seguirá enviando esta solicitud de modo para cada paquete recibido desde el compresor. El compresor utiliza el campo "modo" de los tipos de paquete específicos permitidos durante una transición, y lo fija al modo requerido para confirmar el cambio. La semántica del campo de modo de 2 bits se define como:
modo de compresión
0 = reservado
\quad
1 = unidireccional (modo U)
\quad
2 = optimista bidireccional (modo O)
\quad
3 = fiable bidireccional (modo R)
\vskip1.000000\baselineskip
Desde el modo U al modo R
Mismo procedimiento que desde el modo O al modo R.
\vskip1.000000\baselineskip
Desde el modo R al modo O
Mismo procedimiento que desde el modo O al modo R.
Una transición de vuelta al modo U también es siempre posible.
Según ROHC (RFC 3095), el proceso de compresión debe empezar en el modo U. En la práctica, el modo U y el modo O son muy similares entre sí y por tanto los dos se soportan fácilmente. Como el modo R es significativamente diferente de los otros dos modos, sería conveniente en muchos casos excluir el modo R y utilizar implementaciones sólo en modo U/O.
Es evidente que implementaciones de modos flexibles de ROHC, tales como implementaciones sólo en modo U/O, que habilitan compresores de cabecera optimizados con menos funcionalidad que implementar serían muy ventajosos. Muchos compresores preferirían a veces no pasar a otro modo, por ejemplo al modo R, incluso cuando se solicite por el descompresor. También podría ser deseable evitar implementar soportes para modo(s) particular(es), por ejemplo el modo R, y ajustarse todavía de manera segura a las especificaciones ROHC.
Sin embargo, ROHC no permite la posibilidad de crear implementaciones sólo en modo U/O y similares. Conforme a [4], sólo el descompresor dicta las transiciones entre modos. Esto a su vez pone una necesidad a la implementación de compresor de soportar siempre todos los modos definidos. Por tanto, puede forzarse a un compresor a un funcionamiento por debajo del óptimo simplemente porque una implementación de descompresor de un origen distinto puede favorecer un modo diferente que para el que se optimizó al compresor.
La presente invención tiene como objetivo ofrecer una solución que suprima la restricción impuesta por el algoritmo ROHC a las implementaciones de compresor para soportar siempre y absolutamente todos los modos de funcionamiento incluso cuando pueda ser necesario o deseable soportar sólo un subconjunto.
Una primera idea sería simplemente ignorar la solicitud de cambio de modo del descompresor. Sin embargo, para la transición de modo desde el modo U u O al modo R, por ejemplo, las especificaciones ROHC actuales establecen "Mientras que D_TRANS sea I, el descompresor envía un NACK o ACK que lleva una opción CRC para cada paquete recibido". En otras palabras, cuando el descompresor ha enviado una solicitud de modo, el descompresor envía de nuevo la solicitud para cada paquete recibidos hasta que reciba una confirmación de cambio de modo desde el compresor. Además, también se establece que "Siempre que el descompresor no haya recibido un UOR-2, IR-DYN, o paquete IR con el parámetro de transición entre nodos fijado a R, debe quedarse en el modo optimista". Esto significa que no se permite al descompresor cambiar de modo (por ejemplo al modo R) antes de que reciba una confirmación de cambio de modo desde el compresor. Una consecuencia de esto es que la descompresión puede continuar de forma segura hasta que el compresor realiza realmente la transición de modo y confirma la solicitud.
Ya que el descompresor ROHC debe estar en el modo U/O hasta que se reciba una confirmación del cambio de modo desde el compresor, una implementación de compresor que ignora la solicitud de cambio de modo al modo R desde el descompresor no detendrá al descompresor de continuar realizando descompresión robusta. Sin embargo, producirá un aumento en el canal de retroalimentación debido a las retransmisiones de la solicitud por el descompresor, llevando a una utilización no óptima del ancho de banda. Dependiendo de la implementación de descompresor, este comportamiento puede ser persistente, intermitente o transitorio. Así, el ignorar simplemente una solicitud de cambio de modo al modo R desde el descompresor sufre el inconveniente de generar una cantidad de tráfico aumentada sobre el canal de retroalimentación de una manera menos controlada y para un tiempo no especificado.
En su lugar, la presente invención propone un procedimiento de mensajería en el que el compresor puede indicar al descompresor que se está rechazando una solicitud de cambio de modo. En respuesta es este rechazo indicado, el descompresor puede entonces abortar la transición iniciada con el entendimiento de que el compresor tiene razones válidas para rechazar la transición entre modos. Tales razones pueden ser por ejemplo que el compresor tenga un mejor conocimiento de las condiciones de enlace, que el compresor está optimizado para el modo actual de funcionamiento y/o que el modo solicitado no esté disponible.
Según el método propuesto, un compresor que ha recibido una solicitud para un cambio de modo no deseado indica así al descompresor un rechazo de la solicitud de cambio de modo, normalmente a través de señalización explícita o implícita. Si el descompresor tiene constancia del rechazo indicado, responde confirmando la recepción del rechazo por ejemplo a través del comportamiento de señalización cambiado y/o un mensaje explícito. Una acción de confirmación de recepción de rechazo de este tipo se interpreta como un rechazo satisfactorio por el compresor, que permanece en su modo actual.
La presente invención permite así a un compresor rechazar o bien implícitamente o bien explícitamente una solicitud de cambio de modo de un descompresor. Esto hace posible al compresor deshabilitar la transición a un modo particular e incluso suprime la necesidad de que los compresores implementen todos los modos de funciona-
miento.
Para ilustrar los principios de la invención, se describirán ahora una primera y segunda realización de la misma con referencia a las figuras 3 y 4. Los ejemplos se dirigen principalmente a la transición entre modos desde el modo U u O al modo R y se basan en el comportamiento de compresor descrito anteriormente cuando se inicia una solicitud de transición entre modos. Sin embargo, las realizaciones con otras solicitudes de cambio de modo (con respecto a los modos ROHC así como a otros modos de compresión de cabecera de funcionamiento) también están dentro del alcance de la invención. Cualquier solicitud para una transición entre modos desde un primer modo de compresión de cabecera a un segundo modo de compresión de cabecera puede así manejarse según la invención, por ejemplo una solicitud a/desde modos seleccionados desde el grupo de un modo (U) unidireccional, un modo (O) optimista bidireccional, un modo (R) fiable bidireccional y un modo (B) bidireccional.
\vskip1.000000\baselineskip
Señalización de rechazo explícita
Según un primer enfoque, el compresor señaliza explícitamente al descompresor que la solicitud de cambio de modo se ignorará/rechazará. El descompresor puede utilizar entonces esta señal para abortar la transición iniciada, permanecer en el modo U/O y parar de enviar las solicitudes de cambio de modo.
\newpage
Una realización preferida utiliza bits de modo redefinidos para señalizar explícitamente el rechazo de la solicitud de cambio de modo. Como se observó anteriormente, el valor de modo se define en ROHC (RFC3095) como:
modo de compresión
0 = reservado
\quad
1 = unidireccional (modo U)
\quad
2 = optimista bidireccional (modo O)
\quad
3 = fiable bidireccional (modo R)
\vskip1.000000\baselineskip
El valor de modo del UOR-2, IR-DYN o paquete IR de ROHC (RFC3095) se redefine según este enfoque como:
modo de compresión
0 = solicitud de cambio de modo ignorada/cancelada
\quad
1 = unidireccional (modo U)
\quad
2 = optimista bidireccional (modo O)
\quad
3 = fiable bidireccional (modo R)
\vskip1.000000\baselineskip
El valor 0, que previamente estaba reservado (es decir, no tenía un significado particular en el sentido de que todos los bits con valor 0 iban a ignorarse), se utiliza consecuentemente para indicar que la solicitud de cambio de modo se rechaza/ignora por la unidad de compresor de cabecera. En consecuencia, el compresor envía un paquete al descompresor con valor de modo 0 en respuesta a una solicitud de cambio de modo no deseado. Siempre que el descompresor tenga constancia de las nuevas definiciones de modo, puede tomar acciones apropiadas, tales como abortar transmisiones de solicitud adicionales. Para otras implementaciones puede requerirse algún esfuerzo de normalización para tomar consciencia de la señal.
Debe entenderse que la presente invención también cubre realizaciones que utilizan otros mecanismos para señalizar explícitamente (dentro de banda o fuera de banda) a un descompresor de que se ignorará una solicitud de cambio de modo. Así, en lugar de la redefinición del valor de modo ROHC preferido, pueden utilizarse otros bits/valores para la señalización explícita, que incluyen un tipo de paquete especial, otro indicador de bit distinto al bit de modo, una opción dentro del formato de paquete, una opción dentro de una extensión, etc.
La figura 3 es un diagrama de flujo de un método de compresión de cabecera según una realización a modo de ejemplo de la presente invención con señalización de rechazo explícita. En la etapa S1, la unidad de descompresor de cabecera inicia un modo de transición y transmite a la unidad de compresor de cabecera una solicitud de un cambio a un nuevo modo sobre el enlace de transferencia por paquetes. En caso de que la transición entre modos implique un cambio al modo R, por ejemplo, el modo de compresión de la solicitud se fija al MODO = 3 (modo R). Entonces el descompresor se queda en su modo actual y espera una confirmación desde el compresor. Para cada paquete recibido hasta la confirmación, el descompresor reenvía la solicitud sobre el canal de retroalimentación.
El compresor recibe la solicitud de cambio de modo, pero prefiere permanecer en el modo actual de funcionamiento. Señaliza explícitamente al descompresor el rechazo de la solicitud de cambio de modo, enviando preferiblemente un mensaje de rechazo de cambio de modo sobre el enlace de transferencia de paquetes (etapa S2). En la realización preferida que utiliza la redefinición anterior del valor de modo de los paquetes ROHC, el compresor envía uno o más UOR-2, IR-DYN o paquete IR y fija MODO = 0 (solicitud cancelada).
Ahora, el procedimiento toma diferentes caminos dependiendo de si el descompresor entiende el rechazo de la solicitud de cambio de modo cuando recibe paquetes de MODO = 0 u otras señales explícitas (etapa S3). Si el descompresor tiene constancia de la señal de rechazo, por ejemplo la semántica recientemente definida del valor de modo, para de enviar la solicitud de cambio de modo sobre el canal de retroalimentación en la etapa S4. Entonces se aborta la transición entre modos y el descompresor continúa en el modo actual de funcionamiento. Preferiblemente, el descompresor también envía un mensaje al compresor, que indica que el rechazo está confirmado de recepción (etapa S5). Una confirmación de recepción de rechazo de este tipo puede comprender por ejemplo paquetes ROHC de vuelta con el parámetro MODO fijado a 0 o al valor del modo activo en el momento en el que el descompresor inició la solicitud para un cambio de modo, es decir, el modo ("primero"/"actual") que el compresor quiere mantener.
El compresor determina preferiblemente si el rechazo fue satisfactorio a través de la interpretación del comportamiento de señalización del descompresor. Generalmente, esto implica monitorizar el enlace de transferencia de paquetes para algún tipo de indicación de que se ha entendido y confirmado la recepción del rechazo por el descompresor. Esta indicación puede ser el mensaje de confirmación de recepción de rechazo anterior. Como alternativa, la indicación de que el rechazo de la solicitud de cambio de modo fue satisfactorio puede consistir en que el compresor deja de recibir solicitudes de cambio de modo con el nuevo modo sobre el canal de retroalimentación con una alta fiabilidad de que la señal ha llegado al descompresor. Una seguridad suficiente normalmente requeriría al menos 1 enlace de tiempo de ida y vuelta (RTT, Round-Trip Time), y normalmente en el intervalo de 1 a 2 RTT. En respuesta a un rechazo satisfactorio, el compresor continúa utilizando el modo actual (etapa S6).
Si, por otro lado, el descompresor no entiende la señalización de rechazo, por ejemplo el valor de modo redefinido, la ignorará y permanecerá en el modo actual de funcionamiento. La descompresión normalmente continúa y conforme a [4] el descompresor espera todavía la confirmación desde el compresor. En este caso el compresor todavía recibirá solicitudes de cambio de modo con el nuevo modo sobre el canal de retroalimentación, aún siendo altamente fiable que la señal ha llegado al descompresor. El compresor concluye que la señalización de rechazo no fue satisfactoria y la etapa S7 pregunta si la solicitud va a aceptarse. Si se acepta, el compresor cambia el modo de compresor y preferiblemente devuelve una confirmación, tal como un paquete con el nuevo valor de modo, al descompresor (etapa S8), que consecuentemente cambia el modo y aborta la transmisión de solicitudes adicionales (etapa S9). Como alternativa, no se acepta la solicitud a pesar del rechazo fallido. En su lugar, el compresor preferiblemente baja al comportamiento de señalización explícita que se describirá posteriormente con referencia a la figura 4.
La decisión en la etapa 7 se determina o bien mediante características específicas de implementación generales o bien basándose en la interpretación de cada situación particular. Si, por ejemplo, una implementación no soporta el modo solicitado, aceptar el modo no es una opción y consecuentemente todas las solicitudes para este modo se ignorarán. Sin embargo, un compresor puede también rehusar una transición basándose en caso a caso por razones como que el lado de compresor tiene actualmente bajos recursos de procesamiento, mejor entendimiento de las propiedades de los enlaces, etc.
El enfoque ilustrado por la figura 3 tiene la ventaja de ser la manera más eficiente para un compresor de señalizar al descompresor que no se aceptará una solicitud de cambio de modo, y un descompresor que puede interpretar un señal de este tipo tomará las acciones apropiadas. Un descompresor de este tipo permanece en el modo actual y no incrementa el tráfico del canal de retroalimentación reenviando la solicitud de cambio de modo.
Otra ventaja es que un método según esta realización de la invención permanece interoperable y compatible a la norma cuando un compresor que soporta todos los modos pero preferiblemente los modos U/O se utiliza junto una implementación de descompresor que no tiene constancia de la redefinición propuesta. Un descompresor que no entienda esta redefinición simplemente ignorará este valor, conforme a las especificaciones ROHC. El compresor puede entonces recurrir a la señalización implícita siguiente o aceptar la solicitud de cambio de modo.
Señalización de rechazo implícita
Otro enfoque es para un compresor que indica implícitamente el rechazo de la solicitud de cambio de modo. En una realización preferida, la señalización implícita se consigue ignorando deliberadamente la solicitud de cambio de modo del descompresor y quedándose en el modo actual, pero sólo durante un tiempo limitado. En otras palabras, se propone ignorar de forma segura la solicitud en una manera controlada para indicar el rechazo de la misma al descompresor. Si las solicitudes de cambio de modo enviadas sobre el canal de retroalimentación se suspenden o se vuelven intermitentes después de un cierto periodo de tiempo, el compresor puede quedarse en el modo actual, por ejemplo el modo U/O, sin repercusión en el rendimiento. Por otro lado, es decir, si el tráfico en el canal de retroalimentación es persistente, el compresor puede decidir realizar el cambio de modo y aceptar la solicitud de cambio de modo.
La longitud del periodo de tiempo durante el que el compresor va a ignorar la(s) solicitud(es) de cambio de modo y esperar una posible reacción del descompresor está normalmente del orden de 1a 2 RTT. Esto es porque el descompresor generalmente puede esperar recibir una "respuesta" del compresor aproximadamente de 1 RTT (mínimo) después de enviar la solicitud. Puede tardar más y los RTT de algunos enlaces también varían con el tiempo. Sin embargo, en la mayoría de los casos, el periodo de tiempo predeterminado para la señalización de rechazo implícita puede representarse mediante el intervalo de l a 2 RTT.
La figura 4 es un diagrama de flujo de un método de compresión de cabecera según una realización a modo de ejemplo de la presente invención con rechazo implícito. Como antes, la unidad de descompresor de cabecera inicia una transición entre nodos y envía una solicitud de cambio de modo a la unidad de compresor de cabecera (etapa S10). El descompresor se queda en su modo actual y espera una confirmación del compresor. Para cada paquete recibido hasta la confirmación, el descompresor reenvía la solicitud sobre el canal de retroalimentación.
El compresor recibe la solicitud de cambio de modo pero prefiere quedarse en el modo actual de funcionamiento. Por lo tanto, el compresor indica el rechazo de cambio de modo, en este caso a través de señalización de rechazo implícita. Preferiblemente, ignora de este modo la solicitud y continúa en el modo actual, al mimo tiempo de que inicia un temporizador y monitoriza el canal de retroalimentación (etapa S11). El temporizador se fija a un valor para el que el compresor consigue una alta fiabilidad de que el descompresor pueda notar la falta de respuesta a la solicitud de cambio de modo, por ejemplo en el intervalo de 1a 2 RTT. En lugar del temporizador, pueden utilizarse mecanismos alternativos por ejemplo basados en números de secuencia para conseguir el rechazo implícito controlado.
A partir de entonces, el procedimiento toma diferentes caminos dependiendo de si el descompresor tiene constancia del rechazo implícito de la solicitud de cambio de modo (etapa S12). Si el descompresor ha conseguido una alta fiabilidad de que la solicitud ha llegado al compresor y por lo tanto de que el cambio debería haberse realizado, pero aún nota pasividad/falta de respuesta del compresor, interpretada como rechazo, deja de reenviar la solicitud de cambio de modo sobre el canal de retroalimentación en la etapa S13. Como alternativa, el descompresor baja la frecuencia de las transmisiones de solicitud de cambio de modo. La transición entre modos se aborta y el descompresor permanece en el modo actual de funcionamiento.
En cuanto a la unidad de compresor, ésta decide de nuevo si el rechazo fue satisfactorio. Preferiblemente, esta interpretación del resultado del rechazo implica la monitorización de los enlaces e interpretación del comportamiento de señalización del descompresor. Si el compresor nota una frecuencia más baja o la ausencia de las transmisiones de solicitud de cambio de modo sobre el canal de retroalimentación antes de que el temporizador haya finalizado, el rechazo fue satisfactorio y el compresor permanece en el modo actual (etapa S14).
Si, por otro lado, el descompresor no tiene constancia del rechazo, el temporizador fijado por el compresor finalizará sin ningún cambio en las retransmisiones de la solicitud de cambio de modo sobre el canal de retroalimentación. El compresor interpreta este comportamiento como un rechazo fallido y el procedimiento continúa con la etapa S15, que pregunta si va a aceptarse la solicitud de cambio de modo. Si este es el caso, el compresor cambia el modo de compresor y devuelve normalmente una confirmación, tal como un paquete con el nuevo valor de modo, al descompresor (etapa S16), que consecuentemente cambia el modo y aborta transmisiones de solicitud adicionales (etapa S17). De otra manera, el compresor continúa ignorando la solicitud y permanece en el modo actual (etapa S18). El resultado de la etapa S15 se basa en consideraciones similares a los de la etapa S7 en la figura 3. La etapa S18 no sería generalmente la opción preferida pero puede ser útil en caso de que el compresor no haya implementado el modo que el descompresor está solicitando.
Este enfoque tiene la ventaja de ser interoperable y compatible al estándar. Tampoco requiere ningún cambio del estándar. El método ilustrado en la figura 4 puede utilizarse también como un mecanismo de reserva cuando se utiliza una señal explícita para rechazar solicitudes de cambio de modo y el descompresor no entiende la semántica de la señal enviada por el compresor. Sin embargo, lleva a una generación de una cantidad aumentada de tráfico sobre el canal de retroalimentación, aunque de una manera controlada y durante un periodo de tiempo limitado.
Las realizaciones ilustradas en la figura 3 y en la figura 4, respectivamente, están cada una asociadas con ventajas y la elección del método más adecuado implica factores de ponderación como interoperabilidad y rendimiento entre sí. Los esquemas de señalización respectivos pueden utilizarse de manera separada o en combinación, por ejemplo con la señalización implícita (figura 4) como un mecanismo de reserva adicional si la señalización explícita (figura 3) no diera como resultado un rechazo satisfactorio.
En resumen, la presente invención permite a un compresor de cabecera rechazar una solicitud de cambio de modo de un descompresor de cabecera y continuar utilizando el modo de funcionamiento actual, si se considera apropiado, considerando diferentes factores, incluyendo factores no conocidos por el descompresor. También permite implementaciones de compresor que sólo soportan un subconjunto de todos los modos de funcionamiento para la compresión de cabecera. En particular, por medio de la invención, es posible crear implementaciones sólo en modo U/O eficaces mientras que aún cumplen enteramente la especificación [4] ROHC.
La invención elimina las dependencias del compresor del descompresor con respecto a las transiciones entre modos. Esto da como resultado mejor eficacia en la compresión de cabeceras y también puede reducir las necesidades de memoria, tiempo de implementación y coste de implementación. Especialmente mediante el enfoque de señalización explícita, se consigue un uso más eficaz del ancho de banda disponible, sin impactos adversos en el receptor o en el comportamiento y funcionamiento de la aplicación. Además, la invención permite implementaciones racionalizadas y menos complejas de ROHC, tales como implementaciones que sólo utilizan el modo U y O.
Aunque la invención se ha descrito con referencia a realizaciones ilustradas específicas, debería enfatizarse que también cubre equivalentes a las características descritas, así como modificaciones y variantes obvias para un experto en la técnica. Por ejemplo, aunque la invención se ha mostrado a modo de ejemplo para ROHC (RFC3095 [4]), también podría aplicarse a otros esquemas de compresión de cabeceras, incluyendo esquemas asociados con otros modos de funcionamiento que los ejemplos descritos. El alcance de la invención sólo está limitado por las reivindicaciones adjuntas.
Referencias
[1] Van Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links. IETF RFC 1144, IETF Network Working Group, febrero 1990.
[2] Mikael Degermark, Björn Nordgren, Stephen Pink. IP Header Compression. IETF RFC 2507, IETF Network Working Group, febrero 1999.
[3] Steven Casner, Van Jacobson. Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. IETF RFC 2508, IETF Network Working Group, febrero 1999.
[4] Carsten Bormann, et. al. RObust Header Compression (ROHC): Framework and tour profiles: RTP, UDP, ESP and uncompressed. IETF RFC 3095, abril 2001.
[5] Ghyslain Pelletier. RObust Header Compression (ROHC): Profiles for UDP-Lite, Internet draft, abril 2003.
(http://www.ietf.org/internet-drafts/drafts-ietf-rohc-udp-lite-00.txt)
[6] Lars-Erik Jonsson, Ghyslain Pelletier. RObust Header Compression (ROHC): A compression profile for IP, Internet draft, junio 2003.
(http://www.ietf.org/internet-drafts/draft-ietf-rohc-ip-only-02.txt)
[7] Lars-Erik Jonsson, Ghyslain Pelletier. RObust Header Compression (ROHC): A Link-Layer Assisted ROHC Profile for IP/UDP/RTP. IETF RFC 3242, abril 2002.
[8] Zhigang Liu, Khiem Le, 0-byte Support for R-mode in Extended Link-Layer Assisted ROHC profile. Internet draft, abril 2002.

Claims (32)

1. Método para mensajería de paquetes en un sistema de comunicación que incluye una unidad (20) de compresor de cabecera y una unidad (22) de descompresor de cabecera, que comprende la etapa de
transmitir una solicitud de cambio de modo que implica un cambio desde un primer modo de compresión a un segundo modo de compresión desde la unidad de descompresor de cabecera a la unidad de compresor de cabecera sobre un enlace (11) de transferencia de paquetes, y que se caracteriza por las etapas adicionales de
indicar, en la unidad de compresor de cabecera, el rechazo de la solicitud de cambio de modo a la unidad de descompresor de cabecera;
realizar, si la unidad de descompresor de cabecera tiene constancia del rechazo indicado, una acción de confirmación de recepción de rechazo en la unidad de descompresor de cabecera, implicando dicha acción de confirmación de recepción de rechazo un rechazo satisfactorio; y
permanecer, en la unidad de compresor de cabecera, en el primer modo de compresión en respuesta a un rechazo satisfactorio.
2. Método según la reivindicación 1, caracterizado porque la etapa de indicación comprende señalizar, implícitamente en o explícitamente desde la unidad (20) de compresor de cabecera, el rechazo de la solicitud de cambio de modo.
3. Método según la reivindicación 2, caracterizado porque la etapa de indicación comprende enviar un mensaje de rechazo de cambio de modo desde la unidad (20) de compresor de cabecera a la unidad (22) de descompresor de cabecera.
4. Método según la reivindicación 3, caracterizado porque el mensaje de rechazo de cambio de modo comprende un valor de modo redefinido.
5. Método según la reivindicación 2, caracterizado porque la etapa de indicación comprende ignorar, en la unidad (20) de compresor de cabecera, la solicitud de cambio de modo durante un periodo de tiempo predeterminado.
6. Método según la reivindicación 3 ó 4, caracterizado por, en caso de un rechazo fallido por el mensaje de rechazo de cambio de modo, una señalización de rechazo adicional ignorando, en la unidad (20) de compresor de cabecera, la solicitud de cambio de modo durante un periodo de tiempo predeterminado.
7. Método según la reivindicación 1, caracterizado porque la acción de confirmación recepción de rechazo implica disminuir la frecuencia de las transmisiones de solicitud de cambio de modo desde la unidad (22) de descompresor de cabecera en respuesta al rechazo indicado.
8. Método según la reivindicación 1, caracterizado porque la acción de confirmación de recepción de rechazo implica además abortar la transmisión de la solicitud de cambio de modo desde la unidad (22) de descompresor de cabecera en respuesta al rechazo indicado.
9. Método según la reivindicación 8, caracterizado porque la acción de confirmación recepción de rechazo implica enviar un mensaje de confirmación de recepción de rechazo desde la unidad (22) de descompresor de cabecera a la unidad (20) de compresor de cabecera en respuesta al rechazo indicado.
10. Método según cualquiera de las reivindicaciones anteriores, caracterizado por la etapa adicional de determinar, en la unidad (20) de compresor de cabecera, si el rechazo fue satisfactorio monitorizando el enlace (11) de transferencia de paquetes.
11. Método según cualquiera de las reivindicaciones anteriores, caracterizado por la etapa adicional de cambiar al segundo modo de compresión en la unidad (20) de compresor de cabecera en caso de un procedimiento de rechazo global fallido.
12. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque la unidad (20) de compresor de cabecera está dispuesta para soportar sólo un subconjunto de todos los modos de compresión posibles.
13. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque al menos una de la unidad (20) de compresor de cabecera y la unidad (22) de descompresor de cabecera está implementada según un esquema de compresión de cabecera robusto (ROHC).
14. Método según la reivindicación 13, caracterizado porque el primer y segundo modo de compresión se seleccionan del grupo de un modo (U) unidireccional, un modo (O) optimista bidireccional, un modo (R) fiable bidireccional y un modo (B) bidireccional, incluyendo combinaciones de los mismos.
15. Sistema de comunicación para mensajería de paquetes que comprende una unidad (20) de compresor de cabecera, una unidad (22) de descompresor de cabecera y medios para transmitir una solicitud de cambio de modo que implica un cambio desde un primer modo de compresión a un segundo modo de compresión desde la unidad de descompresor de cabecera hasta la unidad de compresor de cabecera sobre un enlace (11) de transferencia de paquetes, caracterizándose dicho sistema de comunicación por
medios para indicar, en la unidad de compresor de cabecera, un rechazo de la solicitud de cambio de modo a la unidad de descompresor de cabecera;
medios para realizar, si la unidad de descompresor de cabecera tiene constancia del rechazo indicado, una acción de confirmación de recepción de rechazo en la unidad de descompresor de cabecera, implicando dicha acción de confirmación de recepción de rechazo un rechazo satisfactorio; y
medios para permanecer, en la unidad de compresor de cabecera, en el primer modo de compresión en respuesta a un rechazo satisfactorio.
16. Sistema de comunicación según la reivindicación 15, caracterizado porque los medios para indicar comprenden medios para señalizar, implícitamente en o explícitamente desde la unidad (20) de compresor de cabecera, el rechazo de la solicitud de cambio de modo.
17. Sistema de comunicación según la reivindicación 16, caracterizado porque los medios para indicar comprenden medios para enviar un mensaje de rechazo de cambio de modo desde la unidad (20) de compresor de cabecera a la unidad (22) de descompresor de cabecera.
18. Sistema de comunicación según la reivindicación 17, caracterizado porque el mensaje de rechazo de cambio de modo comprende un valor de modo redefinido.
19. Sistema de comunicación según la reivindicación 16, caracterizado porque los medios para indicar comprenden medios para ignorar, en la unidad (20) de compresor de cabecera, la solicitud de cambio de modo durante un periodo de tiempo predeterminado.
20. Sistema de comunicación según cualquiera de las reivindicaciones 15 a 19, caracterizado por medios para abortar además la transmisión de solicitud de cambio de modo desde la unidad (22) de descompresor de cabecera en respuesta al rechazo indicado.
21. Sistema de comunicación según la reivindicación 20, caracterizado por medios para enviar un mensaje de confirmación de recepción de rechazo desde la unidad (22) de descompresor de cabecera a la unidad (20) de compresor de cabecera en respuesta al rechazo indicado.
22. Sistema de comunicación según cualquiera de las reivindicaciones 15 a 21, caracterizado por medios para monitorizar el enlace (11) de transferencia de paquetes para determinar, en la unidad (20) de compresor de cabecera, si el rechazo fue satisfactorio.
23. Sistema de comunicación según cualquiera de las reivindicaciones 15 a 22, caracterizado porque la unidad (20) de compresor de cabecera está dispuesta para soportar sólo un subconjunto de todos los modos de compresión posibles.
24. Sistema de comunicación según cualquiera de las reivindicaciones 15 a 23, caracterizado porque al menos una de la unidad (20) de compresor de cabecera y la unidad (22) de descompresor de cabecera está implementada según un esquema de compresión de cabecera robusto (ROHC).
25. Sistema de comunicación según la reivindicación 24, caracterizado porque el primer y segundo modo de compresión se seleccionan del grupo de un modo (U) unidireccional, un modo (O) optimista bidireccional, un modo (R) fiable bidireccional y un modo (B) bidireccional, incluyendo combinaciones de los mismos.
26. Unidad (20) de compresor de cabecera para comunicación de datos por paquetes que comprende medios para recibir, desde una unidad (22) de descompresor de cabecera, una solicitud de cambio de modo que implica un cambio desde un primer modo de compresión a un segundo modo de compresión sobre un enlace (11) de transferencia de paquetes, y caracterizándose por
medios para indicar rechazo de la solicitud de cambio de modo a la unidad de descompresor de cabecera;
medios para interpretar el comportamiento de señalización de la unidad de descompresor de cabecera para determinar si el rechazo fue satisfactorio; y
medios para permanecer en el primer modo de compresión en respuesta a un rechazo satisfactorio.
\newpage
27. Unidad de compresor de cabecera según la reivindicación 26, caracterizada porque los medios para indicar comprenden medios para enviar un mensaje de rechazo de cambio de modo a la unidad (22) de descompresor de cabecera.
28. Unidad de compresor de cabecera según la reivindicación 27, caracterizada porque el mensaje de rechazo de cambio de modo comprende un valor de modo redefinido.
29. Unidad de compresor de cabecera según la reivindicación 26, caracterizada porque los medios para indicar comprenden medios para ignorar la solicitud de cambio de modo para un periodo de tiempo predeterminado.
30. Unidad de compresor de cabecera según cualquiera de las reivindicaciones 26 a 29, caracterizada porque los medios para interpretar comprenden medios para monitorizar el enlace (11) de transferencia de paquetes.
31. Unidad de compresor de cabecera según cualquiera de las reivindicaciones 26 a 30, caracterizada por estar dispuesta para soportar sólo un subconjunto de todos los modos de compresión posibles.
32. Unidad de compresor de cabecera según cualquiera de las reivindicaciones 26 a 31, caracterizado por estar implementada según un esquema de compresión de cabecera robusto (ROHC) con el primer y segundo modo de compresión seleccionados del grupo de un modo (U) unidireccional, un modo (O) optimista bidireccional, un modo (R) fiable bidireccional y un modo (B) bidireccional, incluyendo combinaciones de los mismos.
ES03808009T 2002-10-11 2003-09-16 Metodo de compresion de cabecera. Expired - Lifetime ES2287572T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US41782202P 2002-10-11 2002-10-11
US417822P 2002-10-11

Publications (1)

Publication Number Publication Date
ES2287572T3 true ES2287572T3 (es) 2007-12-16

Family

ID=32094099

Family Applications (1)

Application Number Title Priority Date Filing Date
ES03808009T Expired - Lifetime ES2287572T3 (es) 2002-10-11 2003-09-16 Metodo de compresion de cabecera.

Country Status (10)

Country Link
US (1) US7512716B2 (es)
EP (1) EP1554858B1 (es)
JP (1) JP4347810B2 (es)
CN (1) CN100574313C (es)
AT (1) ATE363802T1 (es)
AU (1) AU2003263706A1 (es)
DE (1) DE60314169T2 (es)
ES (1) ES2287572T3 (es)
TW (1) TWI250724B (es)
WO (1) WO2004034675A1 (es)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8619592B2 (en) * 2002-06-12 2013-12-31 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for increased internet protocol (IP) headers compression performance by reporting cause of missing packets
US20050265284A1 (en) * 2003-10-10 2005-12-01 Hsu Liangchi Alan Apparatus, and associated method, for facilitating communication handoff in multiple-network radio communication system
US7430617B2 (en) * 2003-12-19 2008-09-30 Nokia Corporation Method and system for header compression
SE0401346D0 (sv) * 2004-05-24 2004-05-24 Ericsson Telefon Ab L M Methods for Increased Tolerance Against Packet Reordering for the Secure Reference Principle in Robust Header Compression
US8254379B1 (en) * 2004-07-15 2012-08-28 Sprint Spectrum L.P. Method and system for application based compression profile selection
KR100703494B1 (ko) * 2004-08-09 2007-04-03 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을 포함하는 음성패킷망의 패킷 송/수신 방법 및 장치
US8804765B2 (en) * 2005-06-21 2014-08-12 Optis Wireless Technology, Llc Dynamic robust header compression
JP2007150911A (ja) * 2005-11-29 2007-06-14 Kyocera Corp 無線通信システム及び方法並びに無線基地局
CN101453298B (zh) * 2007-12-07 2013-06-05 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置
US7948913B1 (en) * 2008-10-30 2011-05-24 Clear Wireless Llc Communicating data in various modes using header-compression algorithms
WO2010106663A1 (ja) 2009-03-19 2010-09-23 富士通株式会社 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法
CN101848491A (zh) * 2010-04-21 2010-09-29 中兴通讯股份有限公司 鲁棒性头压缩中一种模式转换的方法及装置
CN102860108B (zh) * 2010-05-03 2017-05-24 皇家飞利浦电子股份有限公司 用于操作移动台的方法
CN101835196B (zh) * 2010-05-14 2014-08-13 中兴通讯股份有限公司 鲁棒性头压缩中一种模式转换的方法和装置
CN102137439B (zh) * 2010-09-17 2013-09-11 上海华为技术有限公司 压缩控制方法、设备和系统
CN102571540B (zh) * 2010-12-20 2015-12-16 华为技术有限公司 一种解压的方法及装置
US20130016725A1 (en) 2010-12-24 2013-01-17 Telefonaktiebolaget L M Ericsson (Publ) Method and system for intra-node header compression
JPWO2013001814A1 (ja) * 2011-06-30 2015-02-23 パナソニック株式会社 通信装置、通信システム、サーバ装置及び通信方法
WO2015102406A1 (en) * 2014-01-03 2015-07-09 Lg Electronics Inc. Method and apparatus for transmitting/receiving broadcast signal including robust header compression packet stream
US10405278B2 (en) * 2014-10-31 2019-09-03 Qualcomm Incorporated Low power scheduling
KR102254396B1 (ko) 2014-12-17 2021-05-24 삼성전자주식회사 통신 시스템에서 단말의 헤더 압축 기능을 제어하는 방법 및 장치
JPWO2016208568A1 (ja) * 2015-06-25 2018-04-12 日本電気株式会社 データ圧縮装置及びデータ圧縮承認装置
US11019530B2 (en) * 2017-05-05 2021-05-25 The Regents Of The University Of California Trans-layer bidirectional robust header compression system
CN111092844B (zh) * 2018-10-23 2023-12-01 瑞昱半导体股份有限公司 进行压缩操作的模式转换的方法、及传输装置
CN111507072A (zh) * 2019-01-31 2020-08-07 瑞昱半导体股份有限公司 基于健壮性头压缩的压缩端与解压缩端及其数据处理方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5131016A (en) * 1991-01-09 1992-07-14 International Business Machines Corporation Communications network data compression control system and method
US5546395A (en) * 1993-01-08 1996-08-13 Multi-Tech Systems, Inc. Dynamic selection of compression rate for a voice compression algorithm in a voice over data modem
US5535199A (en) * 1994-09-06 1996-07-09 Sun Microsystems, Inc. TCP/IP header compression X.25 networks
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
US7539130B2 (en) * 2000-03-28 2009-05-26 Nokia Corporation Method and system for transmitting and receiving packets
JP4520032B2 (ja) * 2000-08-17 2010-08-04 パナソニック株式会社 ヘッダ圧縮装置およびヘッダ圧縮方法
FI111493B (fi) * 2000-09-22 2003-07-31 Nokia Corp Kontekstitunnisteen määrittäminen otsikkokenttien kompressoinnissa
FI110739B (fi) * 2000-10-18 2003-03-14 Nokia Corp Otsikkokenttien kompressoinnin määrittäminen datapakettiyhteydelle
US7069495B2 (en) * 2000-10-30 2006-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Bit error resilience for an internet protocol stack
US7290063B2 (en) * 2001-01-10 2007-10-30 Nokia Corporation Relocating context information in header compression
US8837471B2 (en) * 2001-08-01 2014-09-16 Certicom Corp. Disabling header compression over point-to-point protocol (PPP)
US8619592B2 (en) * 2002-06-12 2013-12-31 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for increased internet protocol (IP) headers compression performance by reporting cause of missing packets

Also Published As

Publication number Publication date
CN100574313C (zh) 2009-12-23
AU2003263706A1 (en) 2004-05-04
TWI250724B (en) 2006-03-01
EP1554858A1 (en) 2005-07-20
EP1554858B1 (en) 2007-05-30
WO2004034675A1 (en) 2004-04-22
JP2006502654A (ja) 2006-01-19
TW200419928A (en) 2004-10-01
US7512716B2 (en) 2009-03-31
DE60314169D1 (de) 2007-07-12
CN1689301A (zh) 2005-10-26
ATE363802T1 (de) 2007-06-15
DE60314169T2 (de) 2008-01-24
JP4347810B2 (ja) 2009-10-21
US20040073711A1 (en) 2004-04-15

Similar Documents

Publication Publication Date Title
ES2287572T3 (es) Metodo de compresion de cabecera.
ES2337633T3 (es) Metodo para transmitir informes de estatus de memoria intermedia y datos de enlace ascendente en un sistema de comunicaciones inalambricas, dispositivo inalambrico para implementar dicho metodo.
ES2272691T3 (es) Reubicacion de la informacion de contexto en la compresion de encabezamientos.
KR100580141B1 (ko) 패킷 데이터 시스템의 성능을 강화하기 위한 장치 및 방법
ES2236319T3 (es) Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos.
ES2328342T3 (es) Sistema y procedimiento de comunicacion movil.
ES2362173T3 (es) Método de comunicación inalámbrica para transmitir una secuencia de unidades de datos entre un dispositivo inalámbrico y una red.
CA2306813C (en) Device and method for communicating packet voice data in mobile communication system
US8310988B2 (en) Method of MAC header generation and data transmitting
JP3593121B2 (ja) 移動インターネットのためのパケット伝送方法
US7286536B2 (en) Method and system for early header compression
ES2382826T3 (es) Transferencia sin interrupciones entre redes de acceso con información de sesión guardada
EP2464063A1 (en) Method and apparatus for header compression in network relay scenarios
KR102300300B1 (ko) 헤더 압축을 이용한 패킷 통신 방법 및 장치
WO2016068308A1 (ja) ゲートウェイ装置及びゲートウェイ装置の制御方法
WO2006058501A1 (fr) Systeme destine a mettre en oeuvre une fonction de protocole de convergence de paquets de donnees et procede associe
WO2011137789A1 (zh) 一种压缩方法与装置
JP5063467B2 (ja) 無線通信システム、無線基地局、無線端末および無線通信方法
EP3103279B1 (en) Mtc device, serving node, and various methods for implementing an uplink stack reduction feature
TWI652953B (zh) 重排方法及其裝置
JP2009267841A (ja) 無線通信システム、無線基地局および無線通信方法
JP5054567B2 (ja) パケット通信システム、無線基地局及びパケット通信方法
WO2009036647A1 (fr) Procédé de libération de session de transmission de données par paquet, destiné à un réseau d'accès mobile à ultra large bande
JP2009267840A (ja) 無線通信システム、無線基地局および無線通信方法