ES2292616T3 - Definicion de un identificador de contexto en la compresion de campos de encabezamientos. - Google Patents
Definicion de un identificador de contexto en la compresion de campos de encabezamientos. Download PDFInfo
- Publication number
- ES2292616T3 ES2292616T3 ES01967393T ES01967393T ES2292616T3 ES 2292616 T3 ES2292616 T3 ES 2292616T3 ES 01967393 T ES01967393 T ES 01967393T ES 01967393 T ES01967393 T ES 01967393T ES 2292616 T3 ES2292616 T3 ES 2292616T3
- Authority
- ES
- Spain
- Prior art keywords
- context identifier
- cid
- compressor
- decompressor
- length
- 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
- 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
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- 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 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)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Catalysts (AREA)
- Inorganic Insulating Materials (AREA)
Abstract
Método de definición de un identificador de contexto (CID) cuando se comprimen campos de encabezamientos de paquetes de datos, definiéndose en dicho método un contexto para un compresor (C1, C2) y un descompresor (D1, D2) de un flujo de paquetes de datos, controlando el contexto el funcionamiento de dichos compresor y descompresor, quedando identificado dicho contexto por un identificador de contexto (CID) adjuntado al paquete de datos, y negociándose la longitud de dicho identificador de contexto mediante la transferencia de datos (300, 304) entre el compresor y el descompresor, caracterizado porque la definición de la longitud (CID_long) de dicho identificador de contexto (CID) se incluye como parte del campo identificador de contexto del paquete de datos que se está transmitiendo.
Description
Definición de un identificador de contexto en la
compresión de campos de encabezamientos.
La presente invención se refiere a la definición
de un identificador de contexto cuando se comprimen campos de
encabezamientos de paquetes de datos.
El avance rápido en la tecnología IP (Protocolo
de Internet) durante los últimos años ha conseguido también que
aumente el potencial de uso de diferentes aplicaciones basadas en IP
aparte de la transferencia de datos convencional por Internet. En
particular las aplicaciones de telefonía basadas en IP se han
desarrollado a un ritmo rápido, como consecuencia de lo cual, en
principio, utilizando la tecnología IP, se puede implementar una
parte siempre en crecimiento del camino de transmisión de llamadas
incluso en redes de telefonía convencional (PSTN/ISDN, Red
Telefónica Pública Conmutada/Red Digital de Servicios Integrados) y
en redes móviles (PLMN, Red Pública Terrestre de Servicios
Móviles).
Especialmente en las redes móviles, la
tecnología IP ofrece muchas ventajas, ya que además de los servicios
de voz convencionales de las redes móviles, los cuales se podrían
proporcionar por medio de diversas aplicaciones de voz IP, las
redes móviles proporcionarán cada vez más servicios de datos
diferentes, tales como navegación por Internet, servicios de correo
electrónico, juegos, etcétera, los cuales típicamente se implementan
de forma más preferente como servicios basados en IP por
conmutación de paquetes. De esta manera, las capas IP dispuestas en
los protocolos de los sistemas móviles podrían ser aprovechadas
tanto por servicios de audio/vídeo como por diversos servicios
de
datos.
datos.
En las redes móviles, resulta especialmente
importante utilizar de la forma más eficaz posible los recursos de
radiocomunicaciones limitados. Esta situación, por su parte, hace
que se complique la utilización de los protocolos IP en la interfaz
de radiocomunicaciones, ya que en protocolos basados en IP, la
proporción de los diversos campos de los encabezamientos de los
datos transferidos es muy alta, y de forma correspondiente, la
proporción de carga útil es pequeña. Adicionalmente, el índice de
errores de bit (BER) de la interfaz de radiocomunicaciones y el
tiempo de ida y vuelta (RTT) combinado de las direcciones de enlace
ascendente y enlace descendente pueden, en condiciones deficientes,
aumentar notablemente, lo cual genera problemas en los métodos de
compresión de campos de encabezamientos más conocidos. Esta
situación ha creado la necesidad de desarrollar un método de
compresión de campos de encabezamientos adecuado para diferentes
protocolos IP, el cual resultaría especialmente apropiado para la
transferencia de datos a través de la interfaz de
radiocomunicaciones: una compresión eficaz de campos de
encabezamientos la cual, sin embargo, se puede usar en condiciones
en las cuales los índices de errores de bit y los tiempos de ida y
vuelta aumenten considerablemente.
Con este fin, el IETF (Grupo de Trabajo de
Ingeniería de Internet) ha estado trabajando últimamente en la
normalización de un método de compresión de campos de
encabezamientos conocido como ROHC (Compresión Robusta de
Encabezamientos). Una de las ideas que subyace tras el desarrollo de
la ROHC es que se produce una redundancia elevada entre los
diversos campos de encabezamientos IP usados en la transferencia de
paquetes de datos, no solamente dentro del paquete de datos, sino
también entre ellos. En otras palabras, una gran cantidad de la
información de los campos de los encabezamientos no varía en
absoluto durante la transferencia de los paquetes de datos y por lo
tanto dicha información es sencilla de reconstruir incluso aunque no
se transmita. Solamente una pequeña parte de los campos de los
encabezamientos es tal que la información que comprenden requiere
que se le preste atención durante la compresión. Además, la ROHC
comprende varios niveles de compresión, con lo cual la eficacia de
la compresión aumenta cuando se cambia a un nivel superior. Sin
embargo, la ROHC siempre intenta usar la compresión más eficaz
posible, de tal manera que antes de cambiar al nivel siguiente, se
garantice siempre una fiabilidad suficiente de funcionamiento del
nivel. La ROHC presenta además la característica típica de que deja
que varias cuestiones esenciales para el uso de un método de
compresión sean gestionadas por la capa de enlace inferior.
Uno de los aspectos mencionados que se debe
negociar a través de la capa de enlace inferior entre un emisor y
un receptor, es decir, un compresor y un descompresor, es la
definición de la longitud de un identificador de contexto (CID)
usado sobre un cierto enlace de radiocomunicaciones. El
identificador de contexto CID se usa para diferenciar entre sí
varios flujos de datos por paquetes transmitidos sobre el mismo
enlace radiocomunicaciones. La longitud del identificador de
contexto CID puede ser 0, 1 ó 2 bytes (0, 8 ó 16 bits), y el valor
cero se usa cuando el enlace tiene únicamente un flujo de datos. De
este modo, la longitud del CID se negocia antes de que se inicie la
compresión de los datos a transmitir, y la longitud negociada del
identificador de contexto CID se usa después de dicha operación en
la dirección tanto de enlace ascendente como de enlace
descendente.
Uno de los problemas con la disposición antes
descrita es la rigidez de la longitud del identificador de contexto
CID. Como la longitud del CID se ha negociado antes de iniciar la
compresión, su valor únicamente se puede cambiar volviendo a
realizar una negociación entre el compresor y descompresor, en cuyo
caso debe detenerse la compresión. Otro de los problemas es que
cuando se usa un portador de radiocomunicaciones, se debe usar la
misma longitud del CID en la dirección tanto del enlace ascendente
como del enlace descendente. No obstante, en los sistemas móviles,
por ejemplo, una longitud del CID preferible en la dirección del
enlace ascendente es de forma típica considerablemente menor que en
la dirección del enlace descendente. Si en una de las soluciones de
la técnica anterior se define la longitud del CID para un portador
de radiocomunicaciones basándose en el requisito de la dirección
del enlace descendente, en ese caso los recursos de
radiocomunicaciones en la dirección del enlace ascendente no se
usan de forma óptima. Si la longitud del CID se define teniendo en
cuenta únicamente la dirección del enlace ascendente, surgirán
problemas en la descompresión en la dirección del enlace
descendente, ya que la longitud requerida del CID es mayor que la
longitud negociada del CID.
El documento de M. Degermark et al.,
"IP Header Compression", RFC 2507, da a conocer un método para
determinar la longitud del CID mediante un campo de longitud
independiente (un bit) incluido en el encabezamiento del paquete.
No obstante, si la longitud del CID se cambia durante la sesión
según el documento, debe volver a definirse la estructura del
encabezamiento completo del paquete, ya que el campo de longitud
independiente incluido en el encabezamiento del paquete define la
longitud del CID. Por otra parte, cuando se descomprimen los
encabezamientos del paquete según el documento, deben analizarse el
encabezamiento completo del paquete y sus campos con vistas a
determinar la longitud y el valor del CID.
De este modo, es un objetivo de la invención
desarrollar un método y un aparato que implemente el método para
solucionar los problemas antes mencionados. El objetivo de la
invención se alcanza a través de un método y un sistema, los cuales
están caracterizados por los aspectos expresados en las
reivindicaciones independientes. En las reivindicaciones
subordinadas se exponen formas de realización preferidas de la
invención.
La invención se basa en la idea de que cuando se
detecta una necesidad de definir una longitud de un identificador
de contexto para un flujo de paquetes de datos, típicamente como una
redefinición, esta definición se adjunta al siguiente paquete de
datos que se esté transmitiendo, preferentemente a su campo de
identificador de contexto, en el que la longitud nueva del
identificador de contexto se define mediante uno o más bits. Según
una de las formas de realización preferidas de la invención, esta
definición se adjunta a cada paquete de datos que se esté
transmitiendo, con lo cual se comprueba la longitud del
identificador de contexto de cada paquete de datos. De acuerdo con
una segunda forma de realización preferida de la invención, esta
definición se adjunta únicamente al primer paquete de datos que se
esté transmitiendo, después de lo cual esta longitud del
identificador de contexto se usa sobre el flujo de paquetes de
datos hasta que la misma se vuelva a definir nuevamente de forma
correspondiente.
El método y el sistema de la invención
proporcionan la ventaja de que la longitud del identificador de
contexto se puede definir de manera que sea diferente para las
direcciones de enlace ascendente y de enlace descendente,
consiguiendo de este modo que el uso de los recursos de
transferencia de datos resulte más eficaz. Además, el método de la
invención proporciona la ventaja de que no es necesario detener la
compresión y la descompresión y volver a negociar la longitud del
identificador de contexto cada vez que sea necesario cambiar la
longitud. Todavía otra de las ventajas de la invención es que la
misma posibilita además el multiplexado de paquetes de datos que
tengan diferentes longitudes de identificador de contexto en la
misma conexión de transferencia de datos.
A continuación se describirá más detalladamente
la invención por medio de formas de realización preferidas,
haciendo referencia a los dibujos adjuntos, en los cuales
la Figura 1 es un diagrama de bloques de cambios
entre diferentes niveles de compresión de la ROHC,
la Figura 2 es un diagrama de bloques de cambios
entre diferentes modos de compresión de la ROHC,
la Figura 3 es un diagrama de bloques de una
situación problemática provocada por una ROHC de la técnica anterior
con longitudes diferentes de un campo de identificador de contexto
en los canales directo y de retorno, y
la Figura 4 muestra un paquete de datos que
comprende un campo de identificador de contexto de una forma de
realización preferida de la invención.
A continuación se describe la implementación del
método de compresión de campos de encabezamientos ROHC en cuestión
en relación con las partes esenciales para la invención. Para
obtener una descripción más detallada del método de compresión en
cuestión, se hace referencia a un proyecto de Internet todavía
inacabado "Robust Header Compression (ROHC)", versión 02, 18
de septiembre de 2000.
En diferentes métodos de compresión, se define
típicamente un contexto tanto para un compresor como para un
descompresor, siendo el contexto un estado el cual es usado por el
compresor para comprimir el campo del encabezamiento a transmitir y
por el descompresor para descomprimir un campo de un encabezamiento
recibido. Típicamente, el contexto comprende una versión sin
comprimir del campo del encabezamiento anterior transmitido
(compresor) o recibido (descompresor) a través de una conexión de
transferencia de datos. Adicionalmente, el contexto puede
comprender información que identifica un flujo de paquetes de datos,
tal como números de secuencia o indicaciones de tiempo de paquetes
de datos. De este modo, el contexto comprende típicamente tanto
información estática, la cual permanece invariable durante todo el
flujo de paquetes de datos, como información dinámica, la cual
varía durante el flujo de paquetes de datos, aunque con frecuencia
lo hace según un patrón definido.
La ROHC usa tres niveles de compresión de tal
manera que la compresión se inicia en el nivel más bajo y continúa
gradualmente hacia los niveles superiores. El principio básico es
que la compresión se realice siempre en el nivel más alto posible,
aunque de tal manera que el compresor disponga de la seguridad
suficiente del hecho de que el descompresor tiene la información
suficiente para realizar la descompresión en el nivel en cuestión.
Los factores que influyen en el cambio entre diferentes niveles de
compresión son la variación en campos de encabezamientos
consecutivos, los acuses de recibo positivos y negativos recibidos
desde el descompresor, y cuando no se producen acuses de recibo, la
expiración de contadores secuenciales específicos. De forma
correspondiente es posible cambiar a un nivel inferior desde un
nivel de compresión superior.
Los niveles de compresión que usa la ROHC en
relación con los protocolos IP (Protocolo de Internet), UDP
(Protocolo de Datagrama de Usuario) y RTP (Protocolo de Tiempo
Real) son inicio/restauración (IR), primer orden (FO), y segundo
orden (SO), y en el diagrama de la Figura 1 se describen los cambios
entre estos niveles. El nivel IR se usa para crear el contexto
correspondiente al descompresor o para recuperarse de una situación
de error. El compresor cambia al nivel IR cuando se inicia la
compresión de los campos de encabezamientos, solicitada por el
descompresor, o cuando se produce la expiración de un temporizador
de actualización. En el nivel IR, el compresor envía campos de
encabezamiento IR en un formato sin comprimir. El compresor intenta
cambiar a un nivel superior cuando está seguro de que el
descompresor ha recibido la información de actualización.
El nivel FO se usa para informar al receptor
sobre irregularidades en los campos de encabezamientos del flujo de
paquetes de datos. Después del nivel IR, el compresor funciona en el
nivel FO en una situación en la que los campos del encabezamiento
no constituyen un patrón uniforme (en otras palabras, los campos de
encabezamiento consecutivos varían aleatoriamente de tal manera que
no se pueden predecir los cambios) o el compresor no puede estar
seguro de que el descompresor haya recibido los parámetros que
definen el patrón uniforme de los campos de encabezamiento. Esta es
una situación típica que se produce, por ejemplo, cuando se
transmite voz. En el nivel FO, el compresor envía campos de
encabezamiento FO comprimidos. El compresor intenta nuevamente
cambiar a un nivel superior si los campos de los encabezamientos
constituyen un patrón uniforme y está seguro de que el descompresor
ha recibido los parámetros que definen el patrón uniforme. Los
paquetes de datos del nivel FO comprenden típicamente información
de actualización de contextos, lo cual significa que una
descompresión satisfactoria requiere también una transmisión
satisfactoria de campos de encabezamiento FO consecutivos. Por lo
tanto, el éxito del proceso de descompresión es sensible a la
pérdida o alteración de paquetes del nivel FO.
En el nivel SO, la compresión es óptima. Los
campos de los encabezamientos constituyen un patrón uniforme el
cual es representado por el compresor con campos de encabezamiento
SO comprimidos los cuales, en la práctica, son números de secuencia
de los paquetes de datos. Hacia el descompresor se transmite
información sobre parámetros que definen el patrón uniforme de los
campos de encabezamiento, y basándose en los parámetros y el número
de secuencia recibido, el descompresor puede extrapolar los campos
de encabezamiento originales. Como, en la práctica, los paquetes de
datos enviados en el nivel SO no dependen los unos de los otros, la
sensibilidad a los errores de la descompresión también es baja.
Cuando los campos de encabezamiento ya no constituyen un patrón
uniforme, el compresor cambia de nuevo al nivel FO.
La descompresión tiene también tres niveles los
cuales están vinculados con la definición de contexto del
descompresor. El descompresor inicia siempre su funcionamiento a
partir del nivel más bajo cuando todavía no se ha definido ningún
contexto (Sin Contexto). En ese caso, el descompresor todavía no ha
descomprimido ningún paquete de datos. Cuando el descompresor ha
descomprimido el primer paquete de datos el cual comprende
información de contexto tanto estática como dinámica, puede eludir
el nivel medio (Contexto Estático) yendo directamente al nivel
superior (Contexto Completo). Como consecuencia de varias
situaciones de error en el nivel superior, el descompresor cambia
al nivel medio, aunque típicamente incluso un paquete de datos
descomprimido satisfactoriamente devuelve el descompresor al nivel
superior.
Además de diferentes niveles de compresión, la
ROHC dispone de tres modos de funcionamiento diferentes: el modo
unidireccional (modo U), el modo optimista bidireccional (modo O), y
el modo fiable bidireccional (modo R), los cuales se muestran en el
diagrama de la Figura 2. Según la Figura 2, cada nivel de compresión
(IR, FO, SO) antes descrito funciona en cada uno de los modos,
aunque cada modo funciona a su propia manera en cada nivel y
también toma decisiones sobre cambios entre niveles a su propia
manera. La selección del modo para cada situación de compresión
depende de los parámetros de la conexión de transferencia de datos
usada, tales como la posibilidad de usar un canal de retorno, las
probabilidades y la distribución de los errores, los efectos de la
variación en el tamaño de los campos de encabezamiento.
En el modo unidireccional los paquetes de datos
se transmiten solamente desde el compresor hacia el descompresor,
de manera que el modo U de la ROHC resulta útil en situaciones en
las que el uso de un canal de retorno no es posible o deseable. En
el modo U, el cambio entre diferentes niveles de compresión se
realiza como consecuencia de la expiración de ciertos contadores
secuenciales o sobre la base de la variación de los patrones de
campos de encabezamiento. Como no se usa ningún canal de retorno,
la compresión en el modo U es menos eficaz y la desaparición de
paquetes de datos en el camino de transmisión es más probable que en
cualquiera de los modos bidireccionales. El uso de la ROHC se
inicia siempre en el modo U y el cambio a cualquiera de los modos
bidireccionales puede tener lugar cuando el descompresor ha
recibido por lo menos un paquete y como respuesta al paquete, el
descompresor indica que es necesario un cambio de modo.
El modo optimista bidireccional es similar al
modo unidireccional con la excepción de que en el modo O, se usa un
canal de retorno para corregir situaciones de error y para acusar el
recibo de actualizaciones de contexto significativas desde el
descompresor al compresor. En el modo O no se realizan
actualizaciones secuenciales. El modo O es adecuado preferentemente
para conexiones que requieren una eficacia de compresión óptima con
un tráfico reducido del canal de retorno. El modo O proporciona una
transferencia de paquetes de datos razonablemente fiable, en la
cual la sincronización entre el compresor y el descompresor se puede
mantener típicamente de forma satisfactoria y los paquetes de datos
rara vez se pierden y cuando lo hacen, se pierden en un número
insignificante. No obstante, con unos índices de errores de bit muy
altos, los paquetes de datos se pueden perder en el camino de
transmisión.
El modo fiable bidireccional es diferente
claramente con respecto a los modos antes mencionados. El modo R
usa un canal de retorno para acusar el recibo de todas las
actualizaciones de contexto, también para acusar el recibo de
actualizaciones de números de secuencia. De esta manera en el modo
R, los paquetes de datos se pueden transmitir casi por completo de
forma fiable entre el compresor y el descompresor. La compresión de
campos de encabezamientos no puede provocar la desaparición de
paquetes de datos en el modo R. Uno de los inconvenientes del modo
R es que el tamaño del campo del encabezamiento es en algunos casos
ligeramente mayor que en los modos antes mencionados y que el
tráfico del canal de retorno aumenta considerablemente.
Los tres modos de funcionamiento y los tres
niveles de compresión de la ROHC constituyen situaciones de
funcionamiento diferentes para la compresión de los campos de
encabezamientos, requiriendo cada situación la definición del
funcionamiento del compresor y el descompresor y la transmisión de
paquetes entre ellos. La ROHC usa paquetes diferentes en
situaciones de funcionamiento diferentes. En la actualidad, se han
definido seis tipos diferentes de paquetes de datos para la ROHC,
usándose cuatro de ellos para la transmisión desde el compresor al
descompresor y dos como paquetes de datos del canal de retorno
desde el descompresor al compresor. El número de tipos de paquetes
de datos usados puede cambiar en el futuro, aunque todos los tipos
de paquetes de datos están caracterizados porque en el comienzo de
cada paquete de datos se adjunta un identificador de contexto CID
que define el contexto usado cada vez, antes de enviar el paquete
hacia el camino de transmisión.
La longitud del identificador de contexto CID se
negocia por separado para cada flujo de paquetes de datos por parte
del compresor y el descompresor. Según las definiciones de la ROHC,
la capa de protocolo inferior (capa de enlace) usada en cada
momento debe proporcionar un mecanismo para la negociación de los
parámetros, tales como la longitud del identificador de contexto,
usados en la compresión de los campos de los encabezamientos. Los
parámetros se negocian antes de iniciar la compresión y, en relación
con esto, la longitud del identificador de contexto del flujo de
paquete de datos se puede definir, según la técnica anterior, de
manera que sea 0, 8 ó 16 bits. Sobre un canal lógico de
transferencia de datos, es posible transmitir simultáneamente varios
flujos de paquetes de datos cuyos contextos se identifican y
diferencian entre sí por medio del identificador de contexto CID.
Si únicamente se transmite un flujo de paquete de datos sobre el
canal, lo cual es típico por ejemplo de diferentes aplicaciones
VoIP (Voz por IP), a la longitud del identificador de contexto CID
se le asigna el valor 0. Cuando se transmiten varios flujos de
paquetes de datos sobre el mismo canal, la longitud del
identificador de contexto se define a 8 ó 16 bits para cada flujo de
paquetes de datos dependiendo de la aplicación usada, del protocolo
de transferencia de datos y de las condiciones del canal.
La longitud del identificador de contexto CID
negociada en los modos de funcionamiento bidireccionales (modo O y
modo R) descritos anteriormente se usa también sobre el canal de
retorno. No obstante, en los sistemas móviles, por ejemplo, con
frecuencia resultaría preferible usar sobre el canal de retorno
(enlace descendente) un identificador de contexto mayor que sobre
el canal directo (enlace ascendente), ya que especialmente en el
uso de servicios de datos por paquetes, en la dirección del enlace
descendente se transfieren muchos más datos que en la dirección de
enlace ascendente. En este caso, cuando se usa la compresión de
campos de encabezamientos según la ROHC, la longitud del
identificador de contexto se debe dimensionar típicamente según los
requisitos del canal de retorno, en cuyo caso el canal directo
desde el compresor al descompresor se utiliza de forma
ineficaz.
El diagrama de bloques de la Figura 3 describe
un problema que surgiría si en el presente método ROHC, se
definiera un identificador de contexto de 8 bits para el canal
directo y un identificador de contexto de 16 bits para el canal de
retorno. En los sistemas móviles por ejemplo, los canales de enlace
ascendente y de enlace descendente disponen de sus propios pares
compresor-descompresor de tal manera que el
terminal, por ejemplo, dispone de un compresor C1, y en la
dirección de enlace ascendente en el lado de la red, se dispone de
un descompresor D1. De forma correspondiente, en la dirección de
enlace descendente en el lado de la red, se dispone de un compresor
C2 el cual tiene su homólogo, un descompresor D2, en el terminal. De
este modo, el compresor C1 envía paquetes de datos (300) que
comprenden un identificador de contexto de 8 bits sobre el canal de
enlace ascendente hacia el descompresor D1. En cierta fase del
procedimiento, por ejemplo cuando se cambia el nivel de compresión,
el descompresor de la red D1 envía un acuse de recibo hacia el
terminal sobre el canal de enlace ascendente, produciéndose dicho
acuse de recibo mediante la transferencia del paquete de datos
hacia el compresor C2 (302) el cual añade el identificador de
contexto de 8 bits al acuse de recibo, ya que, según las presentes
definiciones ROHC, ambos canales deben usar la misma longitud del
identificador de contexto. El compresor C2 adjunta este paquete de
acuse de recibo al flujo de datos (304) que se está transfiriendo
hacia el terminal sobre el canal de enlace descendente. El
descompresor D2 comprueba dicha paquete de acuse de recibo, aunque
como el descompresor está esperando paquetes de datos con un
identificador de contexto de 16 bits, interpreta el primer byte del
campo del encabezamiento del paquete de datos que sigue al campo del
identificador de contexto de 8 bits como parte del identificador de
contexto CID, lo cual provoca una situación de error bien en la
interpretación de dicho paquete de acuse de recibo o bien en su
descompresión.
En principio, el problema anterior se podría
evitar en el método de la técnica anterior interrumpiendo la
compresión cada vez que llega un acuse de recibo desde el
descompresor sobre el canal de retorno y volviendo a negociar la
longitud del identificador de contexto del canal directo. No
obstante, esta opción ralentizaría la transferencia del flujo de
datos a un nivel tan alto que, en la práctica la utilización de la
ROHC resultaría imposible en varias aplicaciones. En la práctica,
la solución sería interrumpir la compresión y negociar un campo de
identificador de contexto de 16 bits para ambas direcciones, lo cual
nuevamente daría como resultado una no utilización óptima de los
recursos de transferencia de datos.
En este momento los problemas descritos
anteriormente se pueden evitar según el método de la invención, el
cual define la longitud del identificador de contexto en el campo de
identificador de contexto de un paquete de datos en respuesta al
hecho de que deba cambiarse la longitud del identificador de
contexto. Preferentemente, esta operación se puede realizar
reservando uno o más bits del campo de identificador de contexto
para indicar la longitud del identificador de contexto del paquete
de datos, y el identificador de contexto real se puede añadir
preferentemente después de estos bits. De este modo, la longitud del
identificador de contexto se puede definir preferentemente por
separado para cada paquete de datos, en cuyo caso cada paquete de
datos de un flujo de paquetes de datos, y especialmente sus campos
de identificador de contexto, comprende información que define la
longitud. Este método, en el cual a cada paquete de datos,
preferentemente en los primeros bits de su campo de identificador
de contexto, se le adjunta información que define la longitud del
identificador de contexto, garantiza que se transmite el
identificador de contexto nuevo hacia el receptor. Alternativamente,
la longitud del identificador de contexto también se puede definir
según la forma anterior de manera que únicamente el primer paquete
de datos que se esté transmitiendo después de la redefinición de la
longitud del identificador de contexto comprenda dicha información
que define la longitud, aunque este método no resulta tan fiable
para transmitir la longitud de identificador de contexto nueva
hacia el descompresor.
La definición de la longitud de identificador de
contexto se ilustra en la tabla de la Figura 4, la cual a título de
ejemplo muestra un paquete de datos que comprende una estructura de
un campo identificador de contexto de la invención. Según la ROHC,
un campo identificador de contexto (CID) se adjunta al comienzo del
paquete de datos como primer byte, el cual viene seguido por el
campo de información del encabezamiento del paquete (PHI)
correspondiente al paquete de datos y por la carga útil del paquete
de datos. No obstante, el campo identificador de contexto comprende
también sustancialmente en cada paquete de datos un campo que define
la longitud (CID_long) del identificador de contexto del paquete de
datos en cuestión. En el ejemplo de la Figura 4, la longitud del
campo que define la longitud es dos bits, aunque preferentemente
puede variar entre 1 y 8 bits. De este modo, la longitud del
identificador de contexto para el paquete de datos en cuestión se
determina mediante la información del campo que indica la longitud
del identificador de contexto, y la información de longitud del
siguiente paquete de datos vuelve a definir la longitud del
identificador de contexto nuevamente para el paquete de datos en
cuestión. El identificador de contexto real (CID) puede comprender
varios bytes, incluso más de dos, en caso de que fuera
necesario.
De esta manera, el método de la invención
posibilita la definición de diferentes longitudes del identificador
de contexto para los canales directo y de retorno, lo cual consigue
que el uso de los recursos de transferencia de datos sea más
eficaz. Además, con el método de la invención se puede evitar la
detención de la compresión y la descompresión y la renegociación de
la longitud del identificador de contexto cada vez que es necesario
cambiar la longitud. El método de la invención posibilita además el
multiplexado de paquetes de datos con longitudes diferentes del
identificador de contexto en la misma conexión de transferencia.
El método descrito anteriormente se puede
aplicar preferentemente, por ejemplo, a los sistemas móviles de
tercera generación denominados UMTS (Sistema de Telecomunicaciones
Móviles Universales) e IMT-2000 (Sistema de
Telefonía Móvil Internacional), y en los proyectos de desarrollo
adicionales de los sistemas móviles de segunda generación, tales
como la GERAN (Red de Acceso de Radiocomunicaciones Edge GSM). Por
ejemplo, en el servicio de datos por paquetes del sistema UMTS, uno
de los parámetros que define al portador de radiocomunicaciones es
el método de compresión de los campos de los encabezamientos de los
paquetes de datos usados por el terminal. La compresión de los
campos de encabezamientos de paquetes de datos a transmitir y la
descompresión de paquetes de datos recibidos se realiza, en el
sistema UMTS, sobre la capa del protocolo de convergencia de datos
por paquetes PDCP que pertenece al protocolo de datos por paquetes.
Las tareas de la capa PDCP incluyen funciones relacionadas con la
mejora de la eficacia de los canales, las cuales se basan
típicamente en diferentes métodos de optimización, tales como la
utilización de algoritmos de compresión de campos de encabezamientos
de paquetes de datos. Como en la actualidad los protocolos de nivel
de red diseñados para el UMTS son protocolos IP, los algoritmos de
protección usados son los correspondientes normalizados por el IETF
(Grupo de Trabajo de Ingeniería de Internet). De este modo, el
método de compresión ROHC resulta especialmente adecuado para el
sistema UMTS. La capa PDCP del terminal soporta típicamente varios
métodos de compresión de campos de encabezamientos para permitir el
establecimiento de conexiones con tantos tipos de protocolo de nivel
de red como sea posible.
Las cantidades de datos transferidas en las
direcciones de enlace ascendente y de enlace descendente en
aplicaciones usadas en particular en el servicio de datos por
paquetes del sistema UMTS difieren de forma típica considerablemente
las unas con respecto a las otras de manera que en la dirección de
enlace descendente se transfieren considerablemente más datos que
en la dirección de enlace ascendente. De este modo, la disposición
de la invención, en la cual el identificador de contexto se puede
definir de manera que presente una longitud mayor en la dirección
del enlace descendente que en la dirección del enlace ascendente,
mejora el uso de los recursos de radiocomunicaciones en el sistema
UMTS.
Resulta evidente para un experto en la materia
que a medida que la tecnología avance, la idea básica de la
invención se podrá implementar de muchas formas diferentes. Por lo
tanto, la invención y sus formas de realización no se limitan a los
ejemplos descritos anteriormente, sino que pueden variar dentro del
alcance de las reivindicaciones.
Claims (17)
-
\global\parskip0.930000\baselineskip
1. Método de definición de un identificador de contexto (CID) cuando se comprimen campos de encabezamientos de paquetes de datos, definiéndose en dicho método un contexto para un compresor (C1, C2) y un descompresor (D1, D2) de un flujo de paquetes de datos, controlando el contexto el funcionamiento de dichos compresor y descompresor, quedando identificado dicho contexto por un identificador de contexto (CID) adjuntado al paquete de datos, y negociándose la longitud de dicho identificador de contexto mediante la transferencia de datos (300, 304) entre el compresor y el descompresor, caracterizado porque la definición de la longitud (CID_long) de dicho identificador de contexto (CID) se incluye como parte del campo identificador de contexto del paquete de datos que se está transmitiendo. - 2. Método según la reivindicación 1, caracterizado porque dicho identificador de contexto (CID) comprende un campo de por lo menos un bit para definir la longitud del identificador de contexto (CID_long).
- 3. Método según la reivindicación 1 ó 2, caracterizado porque se define la longitud de dicho identificador de contexto (CID_long) en cada paquete de datos que se esté transmitiendo.
- 4. Método según la reivindicación 1 ó 2, caracterizado porque se define la longitud de dicho identificador de contexto (CID_long) únicamente en el identificador de contexto (CID) del paquete de datos transmitido en primer lugar.
- 5. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque se define una longitud
(CID_long) para el identificador de contexto del flujo de paquetes de datos transferido desde un primer compresor (C1) a un primer descompresor (D1) que es diferente con respecto a la del identificador de contexto del flujo de paquetes de datos transferido en la dirección opuesta desde un segundo compresor (C2) a un segundo descompresor (D2). - 6. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque se realiza dicha compresión de campos de encabezamientos según la definición de la ROHC.
- 7. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque se realiza dicha compresión de campos de encabezamientos sobre la interfaz de radiocomunicaciones de un sistema móvil.
- 8. Sistema de compresión para comprimir campos de encabezamientos de paquetes de datos, comprendiendo dicho sistema un compresor (C1, C2) para comprimir un flujo de paquetes de datos que está siendo transmitido y un descompresor (D1, D2) para descomprimir un flujo de paquetes de datos que está siendo recibido, estando dispuestos el compresor y el descompresor de tal manera que el funcionamiento de dichos compresor (C1, C2) y descompresor (D1, D2) está controlado por un identificador de contexto (CID) adjuntado al paquete de datos, y la longitud de dicho identificador de contexto se negocia mediante una transferencia de datos (300, 304) entre el compresor y el descompresor, caracterizado porque el compresor (C1, C2) y el descompresor (D1, D2) están dispuestos de tal manera que la definición de la longitud (CID_long) de dicho identificador de contexto (CID) se incluye como parte del campo identificador de contexto del paquete de datos que se está transmitiendo.
- 9. Sistema según la reivindicación 8, caracterizado porque dicho identificador de contexto (CID) comprende un campo de por lo menos un bit para definir la longitud del identificador de contexto (CID_long).
- 10. Sistema según la reivindicación 8 ó 9, caracterizado porque el compresor y el descompresor están dispuestos de tal manera que la longitud de dicho identificador de contexto (CID_long) está dispuesta para definirse en cada paquete de datos que se esté transmitiendo.
- 11. Sistema según cualquiera de las reivindicaciones 8 a 10, caracterizado porque el compresor (C1, C2) y el descompresor (D1, D2) están dispuestos de tal manera que se define una longitud (CID_long) para el identificador de contexto del flujo de paquetes de datos transferido desde un primer compresor (C1) a un primer descompresor (D1) que es diferente con respecto a la correspondiente al identificador de contexto del flujo de paquetes de datos transferido en la dirección opuesta desde un segundo compresor (C2) a un segundo descompresor (D2).
- 12. Terminal para un sistema de comunicaciones móviles, comprendiendo dicho terminal un sistema de compresión (ROHC) para comprimir campos de encabezamientos de paquetes de datos, comprendiendo dicho sistema de compresiónun compresor (C1) para comprimir un flujo de paquetes de datos que está siendo transmitido en el enlace ascendente dispuesto de tal manera que el funcionamiento de dicho compresor (C1) está controlado por un identificador de contexto (CID) adjuntado al paquete de datos, y la longitud de dicho identificador de contexto se negocia mediante una transferencia de datos entre el compresor (C1) y un descompresor (D1) sobre una entidad de red del sistema de comunicaciones móviles, caracterizado porqueel compresor (C1) del terminal está dispuesto para incluir la definición de la longitud (CID_long) de dicho identificador de contexto (CID) como parte del campo identificador de contexto del paquete de datos que se está transmitiendo en el enlace ascendente (300).
\global\parskip1.000000\baselineskip
- 13. Terminal según la reivindicación 12, caracterizado porque el sistema de compresión comprende asimismo un descompresor (D2) para descomprimir un flujo de paquetes de datos que se está recibiendo en el enlace descendente, dispuesto de tal manera que el funcionamiento de dicho descompresor (D2) está controlado por un identificador de contexto (CID) adjuntado al paquete de datos, y la longitud (CID_long) de dicho identificador de contexto se negocia mediante una transferencia de datos entre el descompresor (D2) y un compresor (C2) sobre una entidad de red del sistema de comunicaciones móviles, y el descompresor (D2) del terminal está dispuesto para recibir la definición de longitud (CID_long) de dicho identificador de contexto (CID) como parte del campo identificador de contexto del paquete de datos transmitido (304) por el compresor (C2) sobre la entidad de red.
- 14. Terminal según la reivindicación 13, caracterizado porque el compresor (C1) y el descompresor (D2) del terminal están dispuestos de tal manera que se define una longitud (CID_long) para el identificador de contexto del flujo de paquetes de datos transferido desde el compresor (C1) del terminal al descompresor (D1) de la entidad de red que es diferente con respecto a la correspondiente al identificador de contexto del flujo de paquetes de datos recibido en la dirección opuesta desde el compresor (C2) de la entidad de red hacia el descompresor (D2) del terminal.
- 15. Entidad de red para un sistema de comunicaciones móviles, comprendiendo dicha entidad de red un sistema de compresión para comprimir campos de encabezamientos de paquetes de datos, comprendiendo dicho sistema de compresiónun compresor (C2) para comprimir un flujo de paquetes de datos que está siendo transmitido en el enlace descendente, dispuesto de tal manera que el funcionamiento de dicho compresor (C2) está controlado por un identificador de contexto (CID) adjuntado al paquete de datos, y la longitud de dicho identificador de contexto se negocia mediante una transferencia de datos entre el compresor (C2) y un descompresor (D2) sobre terminal del sistema de comunicaciones móviles, caracterizada porqueel compresor (C2) de la entidad de red está dispuesto para incluir la definición de la longitud (CID_long) de dicho identificador de contexto (CID) como parte del campo identificador de contexto del paquete de datos que se está transmitiendo en el enlace descendente (304).
- 16. Entidad de red según la reivindicación 15, caracterizada porque el sistema de compresión comprende asimismo un descompresor (D1) para descomprimir un flujo de paquetes de datos que se está recibiendo en el enlace ascendente, dispuesto de tal manera que el funcionamiento de dicho descompresor (D1) está controlado por un identificador de contexto (CID) adjuntado al paquete de datos, y la longitud (CID_long) de dicho identificador de contexto se negocia mediante una transferencia de datos entre el descompresor (D1) y un compresor (C1) sobre un terminal del sistema de comunicaciones móviles, y el descompresor (D1) de la entidad de red está dispuesto para recibir la definición de longitud (CID_long) de dicho identificador de contexto (CID) como parte del campo identificador de contexto del paquete de datos transmitido (300) por el compresor (C1) sobre el terminal.
- 17. Entidad de red según la reivindicación 16, caracterizada porque el compresor (C2) y el descompresor (D1) de la entidad de red están dispuestos de tal manera que se define una longitud (CID_long) para el identificador de contexto del flujo de paquetes de datos transferido desde el compresor (C2) de la entidad de red al descompresor (D2) del terminal que es diferente con respecto a la correspondiente al identificador de contexto del flujo de paquetes de datos recibido en la dirección opuesta desde el compresor (C1) del terminal hacia el descompresor (D1) de la entidad de red.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI20002100A FI111493B (fi) | 2000-09-22 | 2000-09-22 | Kontekstitunnisteen määrittäminen otsikkokenttien kompressoinnissa |
| FI20002100 | 2000-09-22 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2292616T3 true ES2292616T3 (es) | 2008-03-16 |
Family
ID=8559147
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES01967393T Expired - Lifetime ES2292616T3 (es) | 2000-09-22 | 2001-09-20 | Definicion de un identificador de contexto en la compresion de campos de encabezamientos. |
Country Status (14)
| Country | Link |
|---|---|
| US (1) | US7054954B2 (es) |
| EP (1) | EP1334596B1 (es) |
| JP (1) | JP3559271B2 (es) |
| KR (1) | KR100605110B1 (es) |
| CN (1) | CN100496041C (es) |
| AT (1) | ATE373374T1 (es) |
| AU (1) | AU2001287779A1 (es) |
| BR (1) | BRPI0113922B1 (es) |
| CA (1) | CA2421924C (es) |
| DE (1) | DE60130479T2 (es) |
| ES (1) | ES2292616T3 (es) |
| FI (1) | FI111493B (es) |
| WO (1) | WO2002025895A1 (es) |
| ZA (1) | ZA200302221B (es) |
Families Citing this family (49)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100358444B1 (ko) * | 1999-07-27 | 2002-10-25 | 엘지전자 주식회사 | 휴대 무선 전화기의 안테나 매칭 장치 |
| US7290063B2 (en) * | 2001-01-10 | 2007-10-30 | Nokia Corporation | Relocating context information in header compression |
| DE10147773A1 (de) * | 2001-09-27 | 2003-04-17 | Siemens Ag | Verfahren zur Übermittlung komprimierter Daten in paketorientierten Netzwerken |
| ATE369687T1 (de) * | 2002-06-06 | 2007-08-15 | Alcatel Lucent | Verfahren und vorrichtung zur paketenkopfkomprimierung |
| CA2432594C (en) * | 2002-06-12 | 2011-01-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for increased internet protocol (ip) headers compression performance by reporting cause of missing packets |
| KR100497357B1 (ko) * | 2002-06-26 | 2005-06-23 | 삼성전자주식회사 | 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법 |
| JP4317403B2 (ja) * | 2002-08-09 | 2009-08-19 | パナソニック株式会社 | ヘッダ圧縮装置及びヘッダ圧縮方法 |
| KR100884956B1 (ko) * | 2002-08-14 | 2009-02-23 | 엘지전자 주식회사 | 비대칭 양방향 패킷데이터 송수신 방법 및 시스템 |
| TWI250724B (en) * | 2002-10-11 | 2006-03-01 | Ericsson Telefon Ab L M | Method and communication system for packeting messaging, and header compressor unit |
| US7366101B1 (en) * | 2003-06-30 | 2008-04-29 | Packeteer, Inc. | Network traffic synchronization mechanism |
| US7599283B1 (en) * | 2003-06-30 | 2009-10-06 | Packeteer, Inc. | Network traffic synchronization and data compression in redundant network topologies |
| US7317724B2 (en) * | 2003-07-08 | 2008-01-08 | Cisco Technology, Inc. | Performing compression of user datagram protocol packets |
| US7065087B2 (en) * | 2003-07-08 | 2006-06-20 | Cisco Technology, Inc. | Performing compression of user datagram protocol packets |
| US7398325B2 (en) * | 2003-09-04 | 2008-07-08 | International Business Machines Corporation | Header compression in messages |
| KR100602633B1 (ko) * | 2003-11-08 | 2006-07-19 | 삼성전자주식회사 | 패킷의 헤더를 압축하는 방법 및 그 장치 |
| US7430617B2 (en) | 2003-12-19 | 2008-09-30 | Nokia Corporation | Method and system for header compression |
| CN100373900C (zh) * | 2004-06-15 | 2008-03-05 | 中兴通讯股份有限公司 | 头压缩中的上下文标识的拥塞解决方法 |
| KR100584336B1 (ko) * | 2004-06-24 | 2006-05-26 | 삼성전자주식회사 | 광대역 무선 접속 통신 시스템에서 연결 식별자 할당시스템 및 방법 |
| EP1810424A4 (en) * | 2004-10-18 | 2011-04-06 | Lg Electronics Inc | METHOD FOR TRANSMITTING RETURN INFORMATION ON ORTHOGONAL FREQUENCY DIVISION MULTIPLEXING (OFDM) / FORCED ACCESS COMMUNICATION SYSTEM |
| US7817628B2 (en) * | 2004-11-15 | 2010-10-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for header compression with transmission of context information dependent upon media characteristic |
| US7924731B2 (en) * | 2004-11-15 | 2011-04-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for handling out-of-sequence packets in header decompression |
| US7564831B2 (en) * | 2004-12-27 | 2009-07-21 | Lg Electronics, Inc. | Method of transmitting feedback information using an extended subheader |
| CN100450288C (zh) * | 2005-06-15 | 2009-01-07 | 华为技术有限公司 | 一种提高终端接入效率的方法 |
| US8804765B2 (en) * | 2005-06-21 | 2014-08-12 | Optis Wireless Technology, Llc | Dynamic robust header compression |
| CN1992671B (zh) * | 2005-12-28 | 2010-08-11 | 上海原动力通信科技有限公司 | 第三代演进系统中传输ip头压缩数据包的方法 |
| CN100433724C (zh) * | 2006-03-15 | 2008-11-12 | 华为技术有限公司 | 因特网协议首部压缩的上下文表项老化处理方法及装置 |
| US20070294590A1 (en) * | 2006-05-16 | 2007-12-20 | Texas Instruments Incorporated | Compression scheme to reduce the bandwidth requirements for continuous trace stream encoding of system performance |
| US8793361B1 (en) | 2006-06-30 | 2014-07-29 | Blue Coat Systems, Inc. | Traffic synchronization across multiple devices in wide area network topologies |
| US8948206B2 (en) * | 2006-08-31 | 2015-02-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Inclusion of quality of service indication in header compression channel |
| EP2157741B1 (en) * | 2007-05-11 | 2017-03-29 | Fujitsu Limited | Method of controlling header compression in wireless communication, and wireless station and transmitting device |
| US20090003347A1 (en) * | 2007-06-29 | 2009-01-01 | Yang Tomas S | Backhaul transmission efficiency |
| US9269059B2 (en) * | 2008-03-25 | 2016-02-23 | Qualcomm Incorporated | Apparatus and methods for transport optimization for widget content delivery |
| US9747141B2 (en) * | 2008-03-25 | 2017-08-29 | Qualcomm Incorporated | Apparatus and methods for widget intercommunication in a wireless communication environment |
| US9600261B2 (en) * | 2008-03-25 | 2017-03-21 | Qualcomm Incorporated | Apparatus and methods for widget update scheduling |
| US9110685B2 (en) | 2008-03-25 | 2015-08-18 | Qualcomm, Incorporated | Apparatus and methods for managing widgets in a wireless communication environment |
| US9069575B2 (en) | 2008-03-25 | 2015-06-30 | Qualcomm Incorporated | Apparatus and methods for widget-related memory management |
| CN101594290B (zh) * | 2008-05-26 | 2011-11-30 | 中兴通讯股份有限公司 | 一种鲁棒性头压缩上下文标识的处理方法及装置 |
| CN102067554B (zh) * | 2008-06-16 | 2014-06-18 | 艾利森电话股份有限公司 | 发送安全媒体流 |
| US8867566B2 (en) * | 2008-08-20 | 2014-10-21 | Qualcomm Incorporated | Methods of header compression within a wireless communications network |
| US8902805B2 (en) | 2008-10-24 | 2014-12-02 | Qualcomm Incorporated | Cell relay packet routing |
| US8000245B2 (en) * | 2009-01-29 | 2011-08-16 | Alcatel Lucent | Internet protocol header compression reordering |
| US9674311B2 (en) * | 2009-08-14 | 2017-06-06 | Qualcomm Incorporated | Robust header compression for relay nodes |
| US20110149848A1 (en) * | 2009-08-17 | 2011-06-23 | Qualcomm Incorporated | Header compression for relay nodes |
| CN103457614B (zh) * | 2012-05-31 | 2016-09-28 | 国际商业机器公司 | 射频单元、基带处理单元和基站系统 |
| CN102946330B (zh) * | 2012-09-29 | 2017-03-15 | 华为技术有限公司 | 网络丢包测量方法、装置和系统 |
| US9323715B2 (en) * | 2013-11-14 | 2016-04-26 | Cavium, Inc. | Method and apparatus to represent a processor context with fewer bits |
| US10341466B2 (en) * | 2014-11-14 | 2019-07-02 | Qualcomm Incorporated | Evolved data compression scheme signaling |
| JP6692057B2 (ja) | 2014-12-10 | 2020-05-13 | パナソニックＩｐマネジメント株式会社 | 送信方法、受信方法、送信装置及び受信装置 |
| CN110971363B (zh) | 2018-09-28 | 2022-03-08 | 华为技术有限公司 | 用于以太网数据的通信方法的方法和装置 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6300887B1 (en) * | 1999-11-09 | 2001-10-09 | Nokia Networks Oy | Efficient handoff procedure for header compression |
-
2000
- 2000-09-22 FI FI20002100A patent/FI111493B/fi not_active IP Right Cessation
-
2001
- 2001-09-17 US US09/954,562 patent/US7054954B2/en not_active Expired - Lifetime
- 2001-09-20 AT AT01967393T patent/ATE373374T1/de active
- 2001-09-20 KR KR1020037003977A patent/KR100605110B1/ko not_active Expired - Lifetime
- 2001-09-20 JP JP2002528983A patent/JP3559271B2/ja not_active Expired - Lifetime
- 2001-09-20 CN CNB018161332A patent/CN100496041C/zh not_active Expired - Lifetime
- 2001-09-20 ES ES01967393T patent/ES2292616T3/es not_active Expired - Lifetime
- 2001-09-20 CA CA2421924A patent/CA2421924C/en not_active Expired - Lifetime
- 2001-09-20 EP EP01967393A patent/EP1334596B1/en not_active Expired - Lifetime
- 2001-09-20 WO PCT/FI2001/000819 patent/WO2002025895A1/en not_active Ceased
- 2001-09-20 AU AU2001287779A patent/AU2001287779A1/en not_active Abandoned
- 2001-09-20 DE DE60130479T patent/DE60130479T2/de not_active Expired - Lifetime
- 2001-09-20 BR BRPI0113922-3A patent/BRPI0113922B1/pt not_active IP Right Cessation
-
2003
- 2003-03-20 ZA ZA200302221A patent/ZA200302221B/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| DE60130479T2 (de) | 2008-06-12 |
| WO2002025895A1 (en) | 2002-03-28 |
| CN100496041C (zh) | 2009-06-03 |
| KR100605110B1 (ko) | 2006-07-26 |
| FI20002100L (fi) | 2002-03-23 |
| CA2421924A1 (en) | 2002-03-28 |
| FI20002100A0 (fi) | 2000-09-22 |
| DE60130479D1 (de) | 2007-10-25 |
| BRPI0113922B1 (pt) | 2015-05-19 |
| JP2004509566A (ja) | 2004-03-25 |
| CA2421924C (en) | 2011-12-06 |
| FI111493B (fi) | 2003-07-31 |
| AU2001287779A1 (en) | 2002-04-02 |
| US7054954B2 (en) | 2006-05-30 |
| EP1334596A1 (en) | 2003-08-13 |
| BR0113922A (pt) | 2003-07-29 |
| US20020038385A1 (en) | 2002-03-28 |
| ATE373374T1 (de) | 2007-09-15 |
| CN1462534A (zh) | 2003-12-17 |
| EP1334596B1 (en) | 2007-09-12 |
| KR20030030023A (ko) | 2003-04-16 |
| JP3559271B2 (ja) | 2004-08-25 |
| ZA200302221B (en) | 2004-07-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2292616T3 (es) | Definicion de un identificador de contexto en la compresion de campos de encabezamientos. | |
| ES2272691T3 (es) | Reubicacion de la informacion de contexto en la compresion de encabezamientos. | |
| ES2236319T3 (es) | Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos. | |
| CA2329457C (en) | Header compression for general packet radio service tunneling protocol (gtp)-encapsulated packets | |
| ES2360213T3 (es) | Sistema y procedimiento de transmisión bidireccional de paquetes de datos. | |
| JP3751823B2 (ja) | 実時間サービスにおけるヘッダ圧縮 | |
| ES2328342T3 (es) | Sistema y procedimiento de comunicacion movil. | |
| ES2277849T3 (es) | Un metodo de control del contexto de compresion de encabezado durante una transferencia en redes moviles de comunicacion de datos. | |
| ES2287572T3 (es) | Metodo de compresion de cabecera. | |
| US8031659B2 (en) | Telecommunications network | |
| RU2304854C2 (ru) | Способ определения согласованных вариантов конфигурации для линии радиосвязи, использующей сетевую модель | |
| KR100689473B1 (ko) | 통신시스템에서 프로토콜 헤더 압축장치 및 방법 | |
| HK1136098A1 (en) | Method and apparatus for message compression | |
| HK1136098B (en) | Method and apparatus for message compression |