ES2287572T3 - Metodo de compresion de cabecera. - Google Patents
Metodo de compresion de cabecera. Download PDFInfo
- 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
Links
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion 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/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols 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)
- Prostheses (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)
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.
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.
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
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
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.
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
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
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
Mismo procedimiento que desde el modo O al modo
R.
\vskip1.000000\baselineskip
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.
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
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.
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.
[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.
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)
| 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)
| 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 |
-
2003
- 2003-09-08 TW TW092124734A patent/TWI250724B/zh not_active IP Right Cessation
- 2003-09-16 AU AU2003263706A patent/AU2003263706A1/en not_active Abandoned
- 2003-09-16 JP JP2004542941A patent/JP4347810B2/ja not_active Expired - Fee Related
- 2003-09-16 DE DE60314169T patent/DE60314169T2/de not_active Expired - Lifetime
- 2003-09-16 WO PCT/SE2003/001448 patent/WO2004034675A1/en active IP Right Grant
- 2003-09-16 EP EP03808009A patent/EP1554858B1/en not_active Expired - Lifetime
- 2003-09-16 AT AT03808009T patent/ATE363802T1/de not_active IP Right Cessation
- 2003-09-16 ES ES03808009T patent/ES2287572T3/es not_active Expired - Lifetime
- 2003-09-16 CN CNB038239906A patent/CN100574313C/zh not_active Expired - Fee Related
- 2003-09-30 US US10/673,345 patent/US7512716B2/en not_active Expired - Fee Related
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) | 無線通信システム、無線基地局および無線通信方法 |