ES2292990T3 - Compresion de encabezamientos de extension. - Google Patents
Compresion de encabezamientos de extension. Download PDFInfo
- Publication number
- ES2292990T3 ES2292990T3 ES03740872T ES03740872T ES2292990T3 ES 2292990 T3 ES2292990 T3 ES 2292990T3 ES 03740872 T ES03740872 T ES 03740872T ES 03740872 T ES03740872 T ES 03740872T ES 2292990 T3 ES2292990 T3 ES 2292990T3
- Authority
- ES
- Spain
- Prior art keywords
- package
- extension
- header
- packet
- size
- 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
- 238000007906 compression Methods 0.000 title claims abstract description 58
- 230000006835 compression Effects 0.000 title claims abstract description 58
- 230000006837 decompression Effects 0.000 claims abstract description 38
- 238000000034 method Methods 0.000 claims abstract description 22
- 230000005540 biological transmission Effects 0.000 claims abstract description 11
- 230000007704 transition Effects 0.000 claims description 12
- 230000004044 response Effects 0.000 claims description 4
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 claims 2
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 claims 2
- 230000032258 transport Effects 0.000 description 8
- 230000001413 cellular effect Effects 0.000 description 4
- 230000015654 memory Effects 0.000 description 4
- 230000002457 bidirectional effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000000737 periodic effect Effects 0.000 description 3
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000012885 constant function Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000000135 prohibitive effect Effects 0.000 description 1
- 230000008263 repair mechanism Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- 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
-
- 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
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/43—Assembling or disassembling of packets, e.g. segmentation and reassembly [SAR]
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- 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/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Time-Division Multiplex Systems (AREA)
- Sub-Exchange Stations And Push- Button Telephones (AREA)
- Superconductors And Manufacturing Methods Therefor (AREA)
- Machine Translation (AREA)
- Communication Control (AREA)
Abstract
Método de control de compresión de encabezamientosMétodo de control de compresión de encabezamientos para un enlace de una red de datos por paquetes e para un enlace de una red de datos por paquetes en la cual se usa una transmisión de datos por paqun la cual se usa una transmisión de datos por paquetes con encabezamientos de extensión de tamaño vaetes con encabezamientos de extensión de tamaño variable, comprendiendo dicho método las etapas en lriable, comprendiendo dicho método las etapas en las que: a) se fija (S100) un tamaño predeterminadoas que: a) se fija (S100) un tamaño predeterminado de los encabezamientos de extensión para dicho en de los encabezamientos de extensión para dicho enlace; b) se recibe (S101) un primer paquete con unlace; b) se recibe (S101) un primer paquete con un encabezamiento de extensión; c) se comprime el en encabezamiento de extensión; c) se comprime el encabezamiento de dicho primer paquete para obtener cabezamiento de dicho primer paquete para obtener un segundo paquete; y d) se transmite (S108) dichoun segundo paquete; y d) se transmite (S108) dicho segundo paquete a un descompresor; caracterizado segundo paquete a un descompresor; caracterizado porque se genera (S105, S106) dicho segundo paquetporque se genera (S105, S106) dicho segundo paquete como un paquete que no se va a usar como referene como un paquete que no se va a usar como referencia para actualizar un contexto en dicho descomprecia para actualizar un contexto en dicho descompresor para una descompresión subsiguiente, si se ha sor para una descompresión subsiguiente, si se ha recibido una lista de encabezamientos de extensiónrecibido una lista de encabezamientos de extensión de un tamaño mayor que dicho tamaño predeterminad de un tamaño mayor que dicho tamaño predeterminado de los encabezamientos de extensión. o de los encabezamientos de extensión.
Description
Compresión de encabezamientos de extensión.
La presente invención se refiere a un método, a
aparatos y a un sistema para controlar la compresión y la
descompresión de encabezamientos en una red de datos por paquetes,
tal como, por ejemplo, una red basada en el IP (Protocolo de
Internet).
En las redes de comunicaciones que usan un
transporte de datos por paquetes, los paquetes de datos individuales
contienen en una sección de encabezamientos una información
necesaria para transportar el paquete de datos desde una aplicación
de origen a una aplicación de destino. Los datos concretos a
transmitir están incluidos en una sección de carga útil.
La vía de transporte de un paquete de datos
desde una aplicación de origen a una aplicación de destino implica
habitualmente múltiples etapas intermedias representadas por nodos
de la red interconectados a través de enlaces de comunicaciones.
Estos nodos de la red, denominados conmutadores de paquetes o
encaminadores, reciben el paquete de datos y lo reenvían hacia el
siguiente encaminador intermedio hasta que se alcanza un nodo de red
de destino el cual entregará la carga útil del paquete de datos a
la aplicación de destino. Debido a las contribuciones de las
diferentes capas de los protocolos al transporte del paquete de
datos, la longitud de una sección de encabezamiento de un paquete
de datos puede incluso superar la longitud de la sección de carga
útil.
Por esta razón, se puede utilizar la compresión
de datos de la sección de encabezamientos para obtener una mejor
utilización de la capa de enlace con vistas a entregar la carga útil
a una aplicación de destino. La compresión de los encabezamientos
reduce el tamaño de un encabezamiento al eliminar campos del
encabezamiento o al reducir el tamaño de campos del encabezamiento.
Esta operación se realiza de tal manera que un descompresor puede
reconstruir el encabezamiento si su estado de contexto es idéntico
al estado de contexto usado cuando se comprimió el encabezamiento.
La compresión de encabezamiento se puede realizar en el nivel de la
capa de red (por ejemplo, para encabezamientos IP), ver, por
ejemplo, la especificación RFC 2507 del IETF (Grupo de Trabajo de
Ingeniería de Internet), en un nivel de la capa de transporte (por
ejemplo, para encabezamientos del Protocolo de Datagrama de Usuario
(UDP) o encabezamientos del Protocolo de Control de Transporte
(TCP)), e incluso en el nivel de la capa de aplicación (por
ejemplo, para encabezamientos del Protocolo de Transporte de
Hipertexto (http)).
En la especificación RFC 3095 del IETF (Grupo de
Trabajo de Ingeniería de Internet), se especifica un esquema de
compresión robusta de encabezamientos (ROHC) en forma de un esquema
de compresión de encabezamientos altamente robusto y eficaz para
encabezamientos RTP/UDP/IP (Protocolo de Transporte de Tiempo Real,
Protocolo de Datagrama de Usuario, Protocolo de Internet), UDP/IP,
y ESP/IP (Carga Útil de Seguridad de Encapsulación). Los esquemas
existentes de compresión de encabezamientos no funcionan
satisfactoriamente cuando se usan a través de enlaces con tasas de
errores significativas y tiempos de ida y vuelta prolongados. Para
muchos enlaces de ancho de banda limitado en los que la compresión
de encabezamientos es esencial, dichas características son comunes.
Habitualmente, durante los últimos años, el público general ha
acabado usando en particular dos tecnologías de comunicación: la
telefonía celular e Internet. La telefonía celular ha proporcionado
a sus usuarios la posibilidad revolucionaria de estar siempre
accesibles con una calidad de servicio razonable sin importar el
lugar en el que se encuentren. Por otro lado, Internet se ha
diseñado desde el principio para múltiples servicios y su
flexibilidad para todos tipos de uso ha sido uno de sus puntos
fuertes. La telefonía IP está cobrando impulso gracias a la mejora
de las soluciones técnicas. Los teléfonos celulares se han
convertido en dispositivos más polivalentes, y pueden disponer de
pilas de protocolo IP que soporten no solamente el audio y el
vídeo, sino también la navegación web, el correo electrónico,
juegos, etcétera. De este modo, dos terminales móviles que se
comuniquen entre sí pueden estar conectados a estaciones base a
través de enlaces celulares, y las estaciones base pueden
conectarse a una red por cable basada en IP. Si fuera técnica y
económicamente viable, una solución exclusivamente con IP en todo
momento de un terminal a otro presentaría ciertas ventajas. No
obstante, para conseguir que esta alternativa sea viable, debe
hacerse frente a una serie de problemas, en particular problemas
referentes a la eficacia del ancho de banda.
Para sistemas telefónicos celulares, es de vital
importancia el uso eficaz de los escasos recursos de
radiocomunicaciones. Es crucial disponer de un número suficiente de
usuarios por célula, de otro modo los costes del despliegue serán
prohibitivos. Además, la calidad del servicio de voz debería ser tan
buena como en los sistemas celulares actuales. Es probable que
incluso con soporte para servicios nuevos, la calidad inferior del
servicio de voz sea aceptable únicamente si los costes se reducen
significativamente.
Uno de los problemas con los enlaces celulares
sobre IP cuando se usan para conversaciones de voz interactivas es
la gran tara de los encabezamientos. De este modo, es evidente la
necesidad de reducir los tamaños de los encabezamientos por razones
de eficacia. No obstante, los enlaces celulares presentan
características que provocan que la compresión de los
encabezamientos se comporte a un nivel inferior al satisfactorio. Un
esquema viable de compresión de encabezamientos para enlaces
celulares debe poder gestionar las pérdidas en el enlace entre el
punto de compresión y de descompresión así como las pérdidas antes
del punto de compresión.
El contexto del compresor es el estado que este
último usa para comprimir un encabezamiento. El contexto del
descompresor es el estado que este último usa para descomprimir un
encabezamiento. Cuando queda claro de qué se está hablando, a
cualquiera de ellos o a los dos combinados se les hace referencia
habitualmente como "contexto". El contexto contiene
información relevante de encabezamientos anteriores del flujo
continuo de paquetes, tal como campos estáticos y posibles valores
de referencia para la compresión y la descompresión. Por otra parte,
también forma parte del contexto la información adicional que
describa el flujo continuo de paquetes, por ejemplo, información
sobre cómo cambia el campo identificador IP y el incremento típico
entre paquetes de los números de secuencia o las indicaciones de
tiempo.
En general, un paquete se corresponde con una
unidad de transmisión y recepción, por ejemplo, una unidad de datos
de protocolo. El paquete se comprime y a continuación se
descomprime, por ejemplo, mediante la ROHC. El flujo continuo de
paquetes se corresponde con una secuencia de paquetes en la que los
valores de los campos y los patrones de cambio de valores de los
campos son tales que los encabezamientos se pueden comprimir usando
el mismo contexto. Cuando el contexto del descompresor no es
consistente con el contexto del compresor, puede que la
descompresión no consiga reproducir el encabezamiento original. Esta
situación se puede producir cuando el contexto del descompresor no
se ha inicializado correctamente o cuando entre el compresor y el
descompresor se han perdido o se han dañado paquetes. Los
mecanismos de reparación de contextos son mecanismos que sitúan los
contextos en sincronización cuando los mismos no se encontraban en
dicha situación. Esta operación es necesaria para evitar pérdidas
excesivas debidas a daños en el contexto.
La razón principal por la que tan siquiera puede
realizarse la compresión de encabezamientos es el hecho de que
existe una redundancia significativa entre los campos de los
encabezamientos, tanto dentro de un encabezamiento del mismo
paquete como, en particular, entre paquetes consecutivos
pertenecientes al mismo flujo continuo de paquetes. Mediante el
envío de la información de los campos estáticos solo inicialmente y
la utilización de dependencias y predictibilidad para otros campos,
el tamaño del encabezamiento se puede reducir significativamente
para la mayor parte de paquetes. En este caso, la información
relevante de paquetes anteriores se mantiene en el contexto. La
información de contexto se usa para comprimir o descomprimir
paquetes subsiguientes. El compresor y el descompresor actualizan
sus contextos al producirse ciertos acontecimientos. Los contextos
quedan identificados por un identificador de contexto (CID) el cual
se envía junto con los encabezamientos comprimidos y la información
de realimentación. La información de realimentación transporta
información desde el descompresor al compresor. Para acusar el
recibo de una descompresión satisfactoria de un paquete se usa una
información de acuse de recibo (ACK), lo cual significa que el
contexto está actualizado con una alta probabilidad. Además, para
indicar que el contexto dinámico del descompresor está
desincronizado se usa una información de acuse de recibo negativo
(NACK). Esta información de realimentación se genera cuando no se
ha conseguido descomprimir correctamente varios paquetes
sucesivos.
El esquema de compresión de encabezamientos ROHC
tiene tres modos de funcionamiento, denominados modo unidireccional
(modo U), modo optimista bidireccional (modo O), y modo fiable
bidireccional (modo R). El modo óptimo en el que funcionar depende
de las características del entorno del protocolo de compresión,
tales como capacidades de realimentación, probabilidades y
distribuciones de errores, efectos de la variación del tamaño de los
encabezamientos, etcétera.
Cuando se encuentra en el modo U, los paquetes
se envían solamente en una dirección, desde el compresor al
descompresor. Por esta razón, este modo es utilizable sobre enlaces
en los que no esté disponible o no sea deseable un camino de
retorno desde el descompresor al compresor. En el modo U, las
transiciones entre los estados del compresor se realizan basándose
solamente en temporizaciones periódicas e irregularidades de los
patrones de cambio de los campos de los encabezamientos en el flujo
continuo de paquetes comprimidos. Debido a las restauraciones
periódicas y a la falta de realimentación para el inicio de la
recuperación de errores, la compresión en el modo U será menos
eficaz y presentará una probabilidad ligeramente mayor de
propagación de pérdidas en comparación con cualquiera de los modos
bidireccionales. La compresión con la ROHC debe comenzar en el modo
U. La transición a cualquiera de los modos bidireccionales se puede
realizar en cuanto un paquete haya alcanzado al descompresor y el
mismo haya respondido con un paquete de realimentación indicando que
se desea una transición de modo.
El modo O es similar al modo U. La diferencia es
que se usa un canal de realimentación para enviar solicitudes de
recuperación de errores y opcionalmente acuses de recibo de
actualizaciones de contexto significativas desde el descompresor al
compresor. En el modo O no se usan restauraciones periódicas. El
modo O pretende maximizar la eficacia de compresión y el uso escaso
del canal de retorno. Reduce el número de encabezamientos alterados
entregados a las capas superiores debidos a errores residuales o
invalidación de contextos.
Finalmente, el modo R es diferente en muchos
aspectos con respecto a los dos modos anteriores. Las diferencias
más importantes son un uso más intensivo del canal de realimentación
y una lógica más estricta tanto en el compresor como en el
descompresor que evita la pérdida de sincronización de contextos
entre el compresor y el descompresor excepto para índices de
errores de bits residuales muy elevados. La realimentación se envía
para acusar el recibo de todas las actualizaciones de contexto. El
modo R tiene como objetivo maximizar la robustez contra la
propagación de pérdidas y la propagación de daños, es decir,
minimizar la probabilidad de invalidación del contexto, incluso
bajo unas condiciones de pérdidas de encabezamientos/ráfagas
erróneas.
La ROHC se ha diseñado bajo la suposición de que
los paquetes pueden sufrir daños entre el compresor y el
descompresor, y que dichos paquetes dañados se pueden entregar al
descompresor. La ROHC detecta encabezamientos dañados usando
códigos de comprobación de redundancia cíclica (comprobaciones CRC)
sobre los encabezamientos originales. En los modos U y O, los
encabezamientos más pequeños incluyen una CRC de 3 bits, mientras
que en el modo R los encabezamientos más pequeños no incluyen
ninguna CRC. Por lo tanto, en el modo R no se detectan daños en los
encabezamientos más pequeños. Cuando se trabaja en el modo U, todos
los encabezamientos comprimidos transportan una CRC la cual se debe
usar para verificar la descompresión.
En el modo R, el descompresor usa la siguiente
estructura lógica de realimentación. Cuando se descomprime
correctamente un paquete de actualización, es decir, un paquete que
transporta una CRC de 7 u 8 bits, al compresor se le envía un acuse
de recibo (ACK(R)) con un parámetro de modo que indica el
modo R como modo de compresión deseado. Por otra lado, para
paquetes que no actualicen el contexto, es decir, paquetes que no
transportan ninguna CRC, no se envía ninguna realimentación.
La decisión de cambiar de un modo de compresión
a otro la toma el descompresor. Para cada contexto, el compresor y
el descompresor mantienen una variable cuyo valor es el modo de
compresión y el modo de descompresión actual, respectivamente, para
dicho contexto. El valor de esta variable controla, para el contexto
en cuestión, qué tipos de paquete usar, qué acciones realizar,
etcétera. En el lado del compresor, se proporcionan los parámetros
MODO_C y TRANS_C. Los valores posibles para el parámetro MODO_C son
"U" para unidireccional, "O" para optimista, y "R"
para fiable. El parámetro MODO_C debe inicializarse a "U".
Además, los valores posibles para el parámetro TRANS_C son "P"
para pendiente y "D" para realizado. El parámetro TRANS_C debe
inicializarse a "D". Cuando el parámetro TRANS_C se fija a
"P", se requiere que el compresor únicamente use formatos de
paquete comunes para todos los modos, que en los paquetes enviados
se incluya una información de modo, por lo menos periódicamente, y
que se ignoren las solicitudes nuevas de transición de modo.
En el lado del descompresor, se proporcionan los
parámetros MODO_D y TRANS_D. Los valores posibles para el parámetro
MODO_D son "U" para unidireccional, "O" para optimista y
"R" para fiable. El parámetro MODO_D debe inicializarse a
"U". Además, los valores posibles para el parámetro TRANS_D son
"I" para iniciado, "P" para pendiente, y "D" para
realizado. El parámetro TRANS_D debe inicializarse a "D". Una
transición de modo únicamente puede iniciarse cuando el parámetro
TRANS_D se fija a "D". Mientras el parámetro TRANS_D está
fijado a "I", el descompresor envía un acuse de recibo
negativo (NACK) o un acuse de recibo (ACK) que transporta una opción
de CRC para cada paquete recibido.
Debido al aumento de los tamaños de los campos
de direcciones IP, en los encabezamientos IP se ha introducido una
extensión de encabezamiento IP para minimizar los cambios necesarios
con vistas a soportar extensiones de direcciones IP. No obstante,
cuando un paquete entrante presenta un encabezamiento de extensión
IP de tamaño elevado, el compresor y el descompresor pueden perder
consistencia entre ellos debido, por ejemplo, a daños en el
contexto, lo cual derivará en un fallo de compresión y/o
descompresión. Por ejemplo, los daños en el contexto pueden
aparecer si el compresor comprime una lista de encabezamientos de
extensión IP más grande que la que el descompresor está preparado
para almacenar, debido al hecho de que el descompresor no ha
asignado memoria suficiente para la lista de encabezamientos de
extensión IP de tamaño máximo. Cuando se producen daños en el
contexto, la reparación del mismo puede ocupar un tiempo prolongado,
aunque durante este periodo se descartan muchos paquetes debido a
una descompresión incorrecta. A continuación, se usa un tipo de
paquete sin comprimir para sincronizar nuevamente el contexto lo
cual provoca una baja eficacia de la compresión. Según otra de las
soluciones, al descompresor se le puede asignar memoria suficiente
para la lista de encabezamientos de extensión IP de tamaño máximo.
No obstante, esta situación dará como resultado la utilización de
memorias enormes, ya que el tamaño máximo de la lista de
encabezamientos de extensión IP es el mismo que el tamaño máximo de
los paquetes de entrada.
Por esta razón, uno de los objetivos de la
presente invención es proporcionar un esquema mejorado de compresión
de encabezamientos, por medio del cual se puedan evitar
inconsistencias en el contexto entre el compresor y el descompresor
debido a encabezamientos de extensión IP de tamaño elevado.
Este objetivo se alcanza con un método según la
reivindicación 1.
Además, el objetivo anterior se alcanza con un
aparato de compresión según la reivindicación 8.
Finalmente, el objetivo anterior se alcanza con
un sistema según la reivindicación 10.
Por consiguiente, se proporciona un esquema de
compresión y de descompresión de encabezamientos el cual mantiene
el funcionamiento del descompresor y el compresor de una manera
normal incluso cuando se recibe un paquete con un encabezamiento de
extensión IP de tamaño elevado. La solución es compatible con la
norma ROHC existente y evita inconsistencias de contextos entre un
compresor y un descompresor. Se logra una eficacia más alta en la
compresión, ya que no es necesario reparar contextos y los paquetes
descomprimidos se entregan correctamente a capas de protocolo
superiores sin descartar ningún paquete. Por otra parte, se puede
reducir considerablemente el uso de memoria de la
implementación.
La compresión de encabezamientos se puede basar
en un esquema ROHC. En este caso, el paquete no referencial
transmitido desde el lado del compresor del enlace puede ser un
paquete sin ningún identificador de generación si el modo de
funcionamiento es el modo U ó el modo O, en los que el identificador
de generación se usa para indicar una misma generación de listas de
extensiones de encabezamientos. Por otro lado, el paquete no
referencial puede ser un paquete de modo fiable ROHC el cual no
actualiza ningún contexto de descompresión si el modo de
funcionamiento es el modo R. En particular, este modo de paquete
fiable puede ser un paquete de modo R-1.
En el caso del esquema ROHC, la descompresión de
encabezamientos puede estar adaptada para realizar una transición a
un modo fiable en respuesta a la recepción del encabezamiento de
extensión de tamaño elevado.
Además, la supresión se puede mantener hasta que
se haya recibido un encabezamiento de extensión de un tamaño menor
que o igual al tamaño predeterminado de la extensión del
encabezamiento.
A continuación se describirá más detalladamente
la presente invención basándose en una forma de realización
preferida y haciendo referencia a los dibujos adjuntos, en los
cuales:
la Fig. 1 muestra una representación esquemática
de un formato de un campo de encabezamiento de extensión IP;
la Fig. 2 muestra un diagrama de bloques
esquemático de un enlace de transmisión que comprende un compresor
y un descompresor según la forma de realización preferida;
la Fig. 3 muestra un diagrama de flujo
esquemático de un procedimiento de control de compresión según la
forma de realización preferida;
la Fig. 4 muestra un diagrama de flujo
esquemático de un procedimiento de control de descompresión según la
forma de realización preferida; y
la Fig. 5 muestra un ejemplo de un diagrama de
flujo de paquetes según la forma de realización preferida.
A continuación se describirá la forma de
realización preferida basándose en un enlace de transmisión de datos
por paquetes entre una entidad transmisora 200 y una entidad
receptora 300 que usan ambas un esquema ROHC, tal como se indica en
la Fig. 2. La entidad de transmisión 200 y la entidad receptora 300
pueden ser encaminadotes de una red basada en IP, por ejemplo, una
red celular basada en IP.
El presente esquema de compresión y de
descompresión según la forma de realización preferida está diseñado
para tratar encabezamientos o listas de encabezamientos de extensión
IP de tamaño elevado los cuales se pueden presentar adjuntados a
encabezamientos IPv4 ó IPv6.
La Fig. 1 muestra una representación esquemática
de un formato de un campo de encabezamiento de extensión según se
especifica en la especificación RFC 3095 del IETF para un paquete
comprimido en ROHC. Según la Fig. 1, el campo de encabezamiento de
extensión comprende un octeto de bandera 120 para indicar la
presencia de números de secuencia comprimidos específicos
proporcionados en los siguientes octetos 130. Las banderas de 1 bit
se activan cuando el elemento correspondiente del encabezamiento de
los octetos 120 está comprimido. Cuando una bandera respectiva no
está activada, el elemento de encabezamiento correspondiente se
envía sin comprimir o no está presente. Una primera bandera
específica CL indica la presencia de una lista de encabezamientos
comprimida de longitud variable. De este modo, basándose en la
primera bandera CL, se puede determinar si la lista de
encabezamientos comprimida 140 se adjunta al campo de encabezamiento
de extensión 100.
La Fig. 3 muestra un diagrama de flujo
esquemático de un procedimiento de control de compresión realizado
en una unidad de control de compresión 202 para controlar la
compresión de un compresor 201 de la entidad transmisora 200
mostrada en la Fig. 2. De forma similar, en la unidad receptora 300
se proporciona una unidad de control de descompresión 302 para
controlar la descompresión de un descompresor 301. La unidad de
control de compresión 202 y el compresor 201 de la entidad
transmisora 200 pueden estar dispuestos en forma de una única
unidad o como rutinas de software de un programa almacenado en la
entidad transmisora 200. Se puede aplicar lo mismo para la unidad
de control de control de descompresión 302 y el descompresor 301 en
la entidad receptora 300.
Debe indicarse que la conexión de dos líneas
mostradas en la Fig. 2 y que comprende un canal de control cch, el
cual puede ser un canal fuera de banda, y un canal de datos dch para
conectar el compresor 201 y el descompresor 301, debe considerarse
como una representación general o simplificada, ya que el canal de
datos dch y el canal de control cch también pueden hacer referencia
a diferentes flujos continuos de señalización o unidades de
paquetes de diferentes capas de protocolo. Debido, por ejemplo, a
limitaciones de recursos individuales para la ROHC, se fijan de
forma independiente para el enlace en cuestión, por ejemplo, por
parte del operador o de una rutina de inicialización
correspondiente en la entidad transmisora y en la entidad receptora,
unos números o tamaños predeterminados respectivos del
encabezamiento de extensión o lista de encabezamientos de extensión
IP. De este modo, el tamaño máximo del encabezamiento de extensión o
la lista de encabezamientos de extensión se configura localmente en
el compresor 201 y el descompresor 301, y ninguno de ellos sabe qué
valor está usando el otro.
Según el diagrama de flujo mostrado en la Fig.
3, en la etapa S100 se configura inicialmente un modo de compresión.
En el transcurso de esta configuración de modo, se fija o configura
un tamaño permisible o soportado máximo para la lista de
encabezamientos de extensión. En la etapa S101 de la Fig. 3, se
recibe un paquete con un encabezamiento de extensión IP 140, el
cual puede ser detectado por el compresor 201, por ejemplo, durante
un análisis del paquete entrante. La unidad de control 202 comprueba
si el tamaño del encabezamiento de extensión IP 140 recibido es
mayor que el tamaño máximo configurado de la lista de
encabezamientos de extensión fijado para la compresión en la
entidad transmisora 200. En caso negativo, en la etapa S102 se
comprueba si se ha fijado el modo U ó el modo O. En caso
afirmativo, al paquete recibido se le asigna un identificador de
generación en la etapa S103. Si no se ha fijado ninguno de entre el
modo U ó el modo O, en la etapa S107 se genera un paquete de modo
R. En el presente caso, se supone que el compresor se encontraba en
el modo U ó O cuando se recibió el paquete. En estos modos, una
secuencia de listas idénticas se considera como perteneciente a la
misma generación y a todas ellas se les asigna el mismo
identificador de generación. El identificador de generación se
incrementa en "1" cada vez que la lista cambia y se transporta
en listas comprimidas y sin comprimir que son candidatas para ser
usadas como listas de referencia. En esquemas de compresión basados
en referencias, es decir, esquemas basados en la adición o la
supresión, la compresión y la descompresión de una lista se basan
en la lista de referencia que se considera que está presente en el
contexto tanto del compresor 201 como del descompresor 301. La
lista comprimida es una codificación de las diferencias entre la
lista actual y la lista de referencia. Al producirse la recepción
de una lista comprimida, el descompresor 301 aplica las diferencias
a su lista de referencia para obtener la lista original.
Normalmente, el identificador de generación se debe haber repetido
en por lo menos un número predeterminado de encabezamientos antes de
que la lista se pueda usar como lista de referencia. No obstante,
en el modo O ó U se pueden enviar algunos acuses de recibo, y
siempre que se recibe un acuse de recibo para un encabezamiento, la
lista de dicho encabezamiento se considera como conocida y no es
necesario repetirla más. A partir de la anterior especificación RFC
3095 del IETF se pueden obtener otros detalles en relación con este
esquema de compresión basado en referencias.
En la etapa S108, el paquete procesado se
reenvía al descompresor 301 y el procedimiento vuelve a la etapa
S101.
Si la operación de comprobación de la etapa S101
de la Fig. 3 deriva en el resultado de que el tamaño de la lista de
encabezamientos de extensión IP recibida es mayor que el tamaño
máximo configurado de la lista de extensiones de encabezamientos,
en la etapa S104 se comprueba si el compresor 201 se encuentra en el
modo U u O. Si en la etapa S104 se determina que el compresor 201
se encuentra en el modo U u O, el compresor 201 genera un paquete
con la lista de encabezamientos de extensión 104 aunque sin ningún
identificador de generación (etapa S105). A dichas listas sin
identificador de generación no se les asigna un identificador de
generación nuevo y no se usan como listas de referencia futuras.
Por lo tanto, no se usan para actualizar el contexto en el
descompresor 301.
Por otro lado, si en la etapa S104 se determina
que el compresor 201 no se encuentra en el modo U u O, es decir, se
encuentra en el modo R, el compresor 201 envía un paquete R1-*, el
cual se puede corresponder con cualquier tipo de paquete R1
definido en la RFC 3095 (etapa S106). Dichos paquetes no disponen de
ningún campo CRC y por lo tanto tampoco se usarán como referencia
para actualizar el contexto en el descompresor 301. Finalmente, en
la etapa S108, el paquete generado se reenvía al descompresor
301.
La Fig. 4 muestra un diagrama de flujo
esquemático de un procedimiento de control de descompresión sobre
cuya base la unidad de control de descompresión 302 controla al
descompresor 301 en la entidad receptora 300. Después de la
configuración de un tamaño permisible o soportado máximo del
encabezamiento de extensión para la descompresión en la etapa S200,
de forma similar a la etapa S100 de la Fig. 3, en la etapa S201 se
comprueba si el tamaño de una lista recibida de encabezamientos de
extensión IP es mayor que el tamaño máximo configurado. Si el
tamaño recibido no es mayor que el tamaño máximo configurado, se
permite el envío de un acuse de recibo normal hacia el compresor
201 en la etapa S202. Debe indicarse que el descompresor 301 no debe
enviar necesariamente un acuse de recibo en esta etapa, ya que en
el modo U ó el modo O/R no se acusa el recibo de todos los
paquetes.
Por otro lado, si el tamaño recibido es mayor
que el tamaño máximo configurado, en la etapa S203 se comprueba si
el descompresor 301 se encuentra en el modo U u O. En caso
afirmativo, la unidad de control de descompresión 302 inicia una
transición al modo R, en el que el descompresor 301 no enviará
ningún acuse de recibo después de situarse en el modo R (etapa
S204). Esta supresión de acuses de recibo dura hasta que se haya
recibido un paquete con una lista de encabezamientos de extensión
IP de un tamaño menor que el tamaño máximo configurado. Si en la
etapa S203 se determina que el descompresor 301 no se encuentra en
el modo U u O, es decir, se encuentra en el modo R, en la etapa
S205 se suprime la transmisión de un acuse de recibo. Finalmente,
después de las etapas S202, S204 y S205, respectivamente, el
procedimiento vuelve a la etapa S201. De este modo, desde el
descompresor 301 no se envían acuses de recibo hacia el compresor
201 mientras se reciban encabezamientos de extensión IP con un
tamaño excesivo.
La Fig. 5 muestra un ejemplo específico
correspondiente a un esquema de transmisión de paquetes entre el
compresor 201 con un tamaño máximo configurado de la lista de
encabezamientos de extensión IP_EXTC y el descompresor 301 con un
tamaño máximo configurado de la lista de encabezamientos de
extensión IP_EXTD, cuando se recibe un paquete k con un
encabezamiento de extensión de tamaño elevado.
En este ejemplo, se supone que el tamaño máximo
configurado de la lista de encabezamientos de extensión IP_EXTC en
el compresor 201 es mayor que o por lo menos igual al tamaño máximo
configurado de la lista de encabezamientos de extensión IP_EXTD en
el descompresor 301. La lista de encabezamientos de extensión en el
paquete k es mayor que el tamaño máximo configurado de la lista de
encabezamientos de extensión IP_EXTD en el descompresor 301 aunque
menor que el tamaño máximo configurado de la lista de
encabezamientos de extensión IP_EXTC. Como se supone que el
compresor 210 se encuentra en el modo U u O, el mismo transmite el
paquete con un identificador de generación. Además, según el
procedimiento de la Fig. 4, el descompresor 310 no acusa el recibo
del paquete k y envía un acuse de recibo negativo NACK(R)
con un parámetro que indica una transición de modo hacia el modo R.
Tras recibir este mensaje NACK(R), el compresor 210 realiza
además la transición hacia el modo R tal como se indica mediante el
parámetro MODO_C. Por otra parte, como no se ha recibido ningún
acuse de recibo, el parámetro TRANS_C se fija al estado "P",
ya que el paquete k no se puede usar como referencia. A continuación
el descompresor 201 envía un tipo de paquete 2, por ejemplo, un
UOR-2, el cual se puede usar como referencia para
la descompresión subsiguiente en el descompresor 301. Como
alternativa, el compresor 201 puede enviar un paquete
IR-DYN el cual comunica la parte dinámica del
contexto, es decir, parámetros de funciones no constantes, según se
define en la RFC 3095. No obstante, la lista en este paquete sigue
siendo mayor que el tamaño máximo configurado de la lista de
encabezamientos de extensión IP_EXTD del descompresor 301.
Cuando el descompresor 301, el cual se encuentra
en este momento en el modo R y en el estado "P" del parámetro
TRANS_D, recibe el paquete UOR-2 ó
IR-DYN, no envía ningún acuse de recibo, tal como se
indica en la etapa S205 de la Fig. 4. Este procedimiento continúa
hasta que en el compresor 201 se haya recibido un paquete N con una
lista de encabezamientos de extensión de un tamaño menor que o igual
al tamaño máximo configurado de la lista de encabezamientos de
extensión IP_EXTD y el mismo se haya reenviado al descompresor 301.
En respuesta a la recepción de este paquete con un tamaño
permisible de la lista de encabezamientos de extensión, el
descompresor 301 genera un acuse de recibo ACK, y el compresor 201
fija el parámetro TRANS_C al estado "D" y usa la lista del
paquete N como lista de referencia para una futura compresión.
Si el descompresor 301 recibe un paquete con una
lista de encabezamientos de extensión mayor que el tamaño máximo
configurado IP_EXTD para la descompresión aunque sin ningún
identificador de generación en la lista de encabezamientos de
extensión, no se inicia ninguna transición al modo R. Esta situación
se podría producir si el tamaño de la lista recibida es mayor que
el tamaño máximo configurado IP_EXTD en el descompresor 301 y
también es mayor que el tamaño máximo configurado IP_EXTC.
Cuando se produce un desbordamiento de una
ventana deslizante definida en el compresor 201, este último puede
mantener todos los elementos de la ventana deslizante y puede enviar
un paquete R1-* usando la lista de referencia actual. Como
alternativa, de la ventana deslizante se puede eliminar el elemento
más antiguo y se puede insertar un paquete con CRC. Si no se recibe
ninguna realimentación, lo cual significa que los paquetes de la
ventana deslizante no se pueden usar como lista de referencia, para
la compresión puede seguir usándose la lista de referencia
actual.
Debe indicarse que la presente invención no se
limita a la anterior forma de realización preferida, sino que se
puede implementar en cualquier enlace de transmisión por paquetes
con acuse de recibo, en el que se usen encabezamientos de extensión
de tamaño variable. De este modo, la forma de realización preferida
puede variar dentro del alcance de las reivindicaciones
adjuntas.
Claims (11)
1. Método de control de compresión de
encabezamientos para un enlace de una red de datos por paquetes en
la cual se usa una transmisión de datos por paquetes con
encabezamientos de extensión de tamaño variable,
comprendiendo dicho método las etapas en las
que:
- a)
- se fija (S100) un tamaño predeterminado de los encabezamientos de extensión para dicho enlace;
- b)
- se recibe (S101) un primer paquete con un encabezamiento de extensión;
- c)
- se comprime el encabezamiento de dicho primer paquete para obtener un segundo paquete; y
- d)
- se transmite (S108) dicho segundo paquete a un descompresor;
caracterizado porque
se genera (S105, S106) dicho segundo paquete
como un paquete que no se va a usar como referencia para actualizar
un contexto en dicho descompresor para una descompresión
subsiguiente, si se ha recibido una lista de encabezamientos de
extensión de un tamaño mayor que dicho tamaño predeterminado de los
encabezamientos de extensión.
2. Método según la reivindicación 1, en el que
dicha compresión de encabezamientos se basa en un esquema de
compresión robusta de encabezamientos (ROHC).
3. Método según la reivindicación 2, en el que
dicho segundo paquete es un paquete sin ningún identificador de
generación si un modo de funcionamiento es el modo unidireccional
(U) u optimista (O), usándose dicho identificador de generación
para indicar una misma generación de listas de encabezamientos de
extensión.
4. Método según la reivindicación 2 ó 3, en el
que dicho segundo paquete es un paquete del modo fiable ROHC el
cual no actualiza ningún contexto de descompresión si un modo de
funcionamiento es el modo fiable (R).
5. Método según la reivindicación 4, en el que
dicho paquete de modo fiable es un paquete de modo
R-1.
6. Método según cualquiera de las
reivindicaciones anteriores, que comprende asimismo las etapas en
las que:
- -
- se recibe dicho segundo paquete en dicho descompresor;
- -
- se descomprime dicho segundo paquete; y
- -
- se transmite un acuse de recibo negativo NACK para indicar que un contexto dinámico de dicho descompresor está desincronizado, si dicha lista de encabezamientos de extensión de dicho segundo paquete es mayor que un tamaño predeterminado de los encabezamientos de extensión fijado en dicho descompresor.
7. Método según la reivindicación 6, en el que
dicha etapa de descompresión se basa en un esquema de compresión
robusta de encabezamientos (ROHC), y en el que se realiza una
transición a un modo fiable (R) en respuesta a la recepción de
dicha lista de encabezamientos de extensión de tamaño elevado de
dicho segundo paquete.
8. Aparato de compresión para controlar la
compresión de encabezamientos sobre un enlace de una red de datos
por paquetes en la cual se usa una transmisión de datos por paquetes
con encabezamientos de extensión de tamaño variable, que
comprende:
- a)
- unos medios de control (202) para fijar un tamaño predeterminado de los encabezamientos de extensión para dicho enlace;
- b)
- unos medios para recibir un primer paquete con un encabezamiento de extensión;
- c)
- unos medios de compresión de encabezamientos (201) para comprimir el encabezamiento de dicho primer paquete con vistas a obtener un segundo paquete; y
- d)
- unos medios para transmitir un segundo paquete; y
caracterizado porque
- e)
- dichos medios de compresión de encabezamientos están adaptados para generar dicho segundo paquete de manera que no se use como referencia para actualizar un contexto en un descompresor para una descompresión subsiguiente, si una lista de encabezamientos de extensión de dicho primer paquete es mayor que dicho tamaño predeterminado de los encabezamientos de extensión.
9. Aparato según la reivindicación 8, en el que
dichos medios de compresión de encabezamientos (201) se basan en un
esquema de compresión robusta de encabezamientos (ROHC) y dichos
medios de compresión de encabezamientos (201) están dispuestos para
generar un paquete de modo unidireccional (U) u optimista (O) sin
ningún identificador de generación o un paquete de modo fiable como
dicho segundo paquete.
10. Sistema que comprende un aparato de
compresión según la reivindicación 8 ó 9, y un aparato de
descompresión para controlar la descompresión de encabezamientos
para dicho enlace, comprendiendo dicho aparato de descompresión:
- a)
- unos medios de control (302) para fijar un tamaño predeterminado de los encabezamientos de extensión para dicho enlace;
- b)
- unos medios para recibir dicho segundo paquete; y
- c)
- unos medios de descompresión de encabezamientos (301) para transmitir un acuse de recibo negativo NACK con vistas a indicar que un contexto dinámico de dicho aparato de descompresión está desincronizado, si dicha lista de encabezamientos de extensión de dicho segundo paquete es mayor que dicho tamaño predeterminado de la extensión de los encabezamientos fijado por dichos medios de control (302) de dicho aparato de descompresión.
11. Sistema según la reivindicación 10, en el
que dichos medios de descompresión de encabezamientos (301) están
dispuestos para realizar dicha descompresión de encabezamientos
basándose en un esquema ROHC, y para realizar una transición a un
modo fiable en respuesta a la recepción de dicha lista de
encabezamientos de extensión de tamaño elevado.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US223318 | 1981-01-08 | ||
| US10/223,318 US7647421B2 (en) | 2002-08-20 | 2002-08-20 | Extension header compression |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2292990T3 true ES2292990T3 (es) | 2008-03-16 |
Family
ID=31886652
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03740872T Expired - Lifetime ES2292990T3 (es) | 2002-08-20 | 2003-07-02 | Compresion de encabezamientos de extension. |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7647421B2 (es) |
| EP (1) | EP1421765B1 (es) |
| KR (1) | KR100697355B1 (es) |
| CN (1) | CN100454920C (es) |
| AT (1) | ATE372637T1 (es) |
| AU (1) | AU2003290957A1 (es) |
| DE (1) | DE60316094T2 (es) |
| ES (1) | ES2292990T3 (es) |
| WO (1) | WO2004019586A1 (es) |
Families Citing this family (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2432588C (en) * | 2002-06-12 | 2007-12-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for fast change of internet protocol headers compression mechanism |
| KR100602633B1 (ko) * | 2003-11-08 | 2006-07-19 | 삼성전자주식회사 | 패킷의 헤더를 압축하는 방법 및 그 장치 |
| DE10353289B4 (de) * | 2003-11-14 | 2009-10-15 | Infineon Technologies Ag | Verfahren und Vorrichtung zur Kompression von Datenpaketen |
| 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 |
| US7924731B2 (en) * | 2004-11-15 | 2011-04-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for handling out-of-sequence packets in header decompression |
| KR20060054662A (ko) * | 2004-11-15 | 2006-05-23 | 삼성전자주식회사 | 광대역 무선 통신 시스템에서 헤더 압축 장치 및 방법 |
| US20060262788A1 (en) * | 2005-05-23 | 2006-11-23 | Broadcom Corporation | Dynamic payload header suppression extensions for IPV6 |
| US8804765B2 (en) | 2005-06-21 | 2014-08-12 | Optis Wireless Technology, Llc | Dynamic robust header compression |
| JP2007067584A (ja) * | 2005-08-29 | 2007-03-15 | Kyocera Corp | タイムスロット制御方法、通信システム、通信装置、及びプログラム |
| US9100407B2 (en) * | 2006-03-23 | 2015-08-04 | Cisco Technology, Inc. | Method and system to enhance performance of a session initiation protocol network and its elements |
| US8331313B2 (en) * | 2006-06-14 | 2012-12-11 | Interdigital Technology Corporation | Efficient media independent handover protocol operation enhancements |
| KR101265643B1 (ko) * | 2006-08-22 | 2013-05-22 | 엘지전자 주식회사 | 무선 통신 시스템에서의 핸드오버 수행 및 그 제어 방법 |
| TW200816700A (en) * | 2006-09-29 | 2008-04-01 | Interdigital Tech Corp | Method and apparatus of adaptive sequence numbering in a wireless communication system |
| KR101430449B1 (ko) * | 2006-10-02 | 2014-08-14 | 엘지전자 주식회사 | 무선 통신 시스템에서의 페이징 메시지 송수신 방법 |
| WO2008054119A2 (en) * | 2006-10-30 | 2008-05-08 | Lg Electronics Inc. | Methods for transmitting access channel message and response message, and mobile communication terminals |
| EP2084928B1 (en) | 2006-10-30 | 2017-08-23 | LG Electronics Inc. | Method of performing random access in a wireless communication system |
| US8543089B2 (en) * | 2007-04-30 | 2013-09-24 | Lg Electronics Inc. | Method for performing an authentication of entities during establishment of wireless call connection |
| KR101455999B1 (ko) | 2007-04-30 | 2014-11-03 | 엘지전자 주식회사 | 무선 통신 시스템에서의 데이터 블록 생성 방법 |
| KR100917205B1 (ko) | 2007-05-02 | 2009-09-15 | 엘지전자 주식회사 | 무선 통신 시스템에서의 데이터 블록 구성 방법 |
| US8463300B2 (en) * | 2007-06-18 | 2013-06-11 | Lg Electronics Inc. | Paging information transmission method for effective call setup |
| EP2627146B1 (en) | 2007-06-18 | 2017-09-20 | LG Electronics Inc. | Method and user equipment for performing uplink synchronization in wireless communication system |
| KR101387537B1 (ko) * | 2007-09-20 | 2014-04-21 | 엘지전자 주식회사 | 성공적으로 수신했으나 헤더 압축 복원에 실패한 패킷의 처리 방법 |
| US8400982B2 (en) * | 2007-09-20 | 2013-03-19 | Lg Electronics Inc. | Method for handling correctly received but header compression failed packets |
| KR101066377B1 (ko) * | 2008-08-01 | 2011-09-20 | 삼성전자주식회사 | Ｒｔｐ 헤더 확장 필드의 압축 방법 및 상기 방법에 의해형성되는 압축 헤더 |
| US8787242B2 (en) * | 2009-11-06 | 2014-07-22 | Qualcomm Incorporated | Header compression for relay nodes |
| CN101895548B (zh) * | 2010-07-15 | 2014-08-13 | 中兴通讯股份有限公司 | 鲁棒性头压缩中一种列表压缩方法及装置 |
| CN102137439B (zh) * | 2010-09-17 | 2013-09-11 | 上海华为技术有限公司 | 压缩控制方法、设备和系统 |
| US9923695B2 (en) | 2014-09-24 | 2018-03-20 | Samsung Electronics Co., Ltd. | Call processing method and apparatus for use in LTE system |
| WO2016093586A1 (ko) * | 2014-12-10 | 2016-06-16 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
| EP3393168B1 (en) * | 2015-12-15 | 2021-08-04 | LG Electronics Inc. | User equipment and data reception method, and network node and data transmission method |
| KR102747545B1 (ko) * | 2017-02-21 | 2024-12-27 | 삼성전자주식회사 | 무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법 |
| CN111507072A (zh) * | 2019-01-31 | 2020-08-07 | 瑞昱半导体股份有限公司 | 基于健壮性头压缩的压缩端与解压缩端及其数据处理方法 |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI107000B (fi) * | 1999-02-17 | 2001-05-15 | Nokia Mobile Phones Ltd | Otsikon pakkaaminen reaaliaikaisissa palveluissa |
| AU4603800A (en) * | 1999-05-10 | 2000-11-21 | Nokia Networks Oy | Header compression |
| JP3730835B2 (ja) * | 2000-03-03 | 2006-01-05 | 株式会社エヌ・ティ・ティ・ドコモ | パケット伝送方法、中継装置およびデータ端末 |
| 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 | パナソニック株式会社 | ヘッダ圧縮装置およびヘッダ圧縮方法 |
| US6967964B1 (en) * | 2000-10-03 | 2005-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Context identification using header compression key at link layer |
| CA2361255C (en) * | 2000-11-06 | 2006-01-24 | Matsushita Electric Industrial Co., Ltd. | Scheme, apparatus, and program for header compression |
| US7046672B2 (en) * | 2000-11-16 | 2006-05-16 | Microsoft Corporation | Robust, inferentially synchronized transmission of compressed transport-layer-protocol headers |
| US6883035B2 (en) * | 2000-11-16 | 2005-04-19 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for communicating with temporary compression tables |
| JP3512177B2 (ja) * | 2001-05-16 | 2004-03-29 | 松下電器産業株式会社 | パケット受信装置及びパケット伝送方法 |
| JP3600189B2 (ja) * | 2001-06-19 | 2004-12-08 | 松下電器産業株式会社 | パケット送受信装置及びパケット伝送方法 |
| JP2005509381A (ja) * | 2001-11-06 | 2005-04-07 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | ヘッダ圧縮を行う無線通信装置 |
| US7106733B2 (en) * | 2002-03-20 | 2006-09-12 | Intel Corporation | Method and apparatus for network header compression |
-
2002
- 2002-08-20 US US10/223,318 patent/US7647421B2/en not_active Expired - Lifetime
-
2003
- 2003-07-02 CN CNB03801517XA patent/CN100454920C/zh not_active Expired - Lifetime
- 2003-07-02 WO PCT/IB2003/002589 patent/WO2004019586A1/en not_active Ceased
- 2003-07-02 KR KR1020057002822A patent/KR100697355B1/ko not_active Expired - Lifetime
- 2003-07-02 AU AU2003290957A patent/AU2003290957A1/en not_active Abandoned
- 2003-07-02 EP EP03740872A patent/EP1421765B1/en not_active Expired - Lifetime
- 2003-07-02 AT AT03740872T patent/ATE372637T1/de not_active IP Right Cessation
- 2003-07-02 ES ES03740872T patent/ES2292990T3/es not_active Expired - Lifetime
- 2003-07-02 DE DE60316094T patent/DE60316094T2/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| ATE372637T1 (de) | 2007-09-15 |
| WO2004019586A1 (en) | 2004-03-04 |
| KR100697355B1 (ko) | 2007-03-20 |
| EP1421765B1 (en) | 2007-09-05 |
| KR20050058371A (ko) | 2005-06-16 |
| CN100454920C (zh) | 2009-01-21 |
| US7647421B2 (en) | 2010-01-12 |
| US20040039830A1 (en) | 2004-02-26 |
| DE60316094D1 (de) | 2007-10-18 |
| CN1593051A (zh) | 2005-03-09 |
| EP1421765A1 (en) | 2004-05-26 |
| DE60316094T2 (de) | 2008-05-29 |
| AU2003290957A1 (en) | 2004-03-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2292990T3 (es) | Compresion de encabezamientos de extension. | |
| ES2739470T3 (es) | Procedimiento para transmitir informe de estado de capa de PDCP en sistema de telecomunicaciones móviles y receptor de telecomunicaciones móviles | |
| ES2626082T3 (es) | Método de transmisión de datos en un sistema de comunicación inalámbrica | |
| RU2461147C2 (ru) | Способ обработки радиопротокола в системе подвижной связи и передатчик подвижной связи | |
| ES2328342T3 (es) | Sistema y procedimiento de comunicacion movil. | |
| ES2236319T3 (es) | Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos. | |
| ES2536071T3 (es) | Procedimiento para mover una ventana de recepción en una red de acceso de radio | |
| ES2272350T3 (es) | Metodo para realizar una transmision de datos mas eficaz y protocolo de transmision de datos. | |
| US8532106B2 (en) | Header compression mechanism for transmitting RTP packets over wireless links | |
| EP1122925A1 (en) | Header compression for general packet radio service tunneling protocol (GTP) | |
| JP2005509381A (ja) | ヘッダ圧縮を行う無線通信装置 | |
| JP2005509381A6 (ja) | ヘッダ圧縮を行う無線通信装置 | |
| JP2013502755A (ja) | マルチホップ・リレー通信システムにおいてダウンリンク・データ伝送を制御するための方法および装置 | |
| ES2277849T3 (es) | Un metodo de control del contexto de compresion de encabezado durante una transferencia en redes moviles de comunicacion de datos. | |
| JP2007189697A (ja) | 分散した局のネットワークでデータパケットを交換する方法、データパケットを圧縮する装置及びデータパケットを解凍する装置 | |
| US7466680B2 (en) | Transport efficiency optimization for Mobile IPv6 | |
| KR20170004598A (ko) | 헤더 압축을 이용한 패킷 통신 방법 및 장치 | |
| CN101605355B (zh) | 一种用于LTE-advanced网络中继节点上的ROHC混合工作方式 | |
| EP1565022A2 (en) | Method of resuming header decompression in a multimedia broadcast/mulitcast service system | |
| CN115022922A (zh) | 用于lte系统中的呼叫处理方法和装置 | |
| KR101147346B1 (ko) | 전술 데이터 링크에서의 ｉｐ서비스를 위한 헤더 압축 시스템 및 방법 | |
| US20050086383A1 (en) | Optimizing the compression efficiency in a packet data communication | |
| US6785731B1 (en) | Methods for efficient transmission of signaling messages in a packet-based network | |
| KR100918735B1 (ko) | 이동통신 시스템에서 패킷 송수신 방법 및 장치 | |
| ES2335571T3 (es) | Procedimiento para la transmision de paquetes de datos. |