ES2236319T3 - Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos. - Google Patents
Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos.Info
- Publication number
- ES2236319T3 ES2236319T3 ES01978490T ES01978490T ES2236319T3 ES 2236319 T3 ES2236319 T3 ES 2236319T3 ES 01978490 T ES01978490 T ES 01978490T ES 01978490 T ES01978490 T ES 01978490T ES 2236319 T3 ES2236319 T3 ES 2236319T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- compression
- connections
- context
- packet
- 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
- 230000006835 compression Effects 0.000 title claims abstract description 159
- 238000007906 compression Methods 0.000 title claims abstract description 159
- 238000000034 method Methods 0.000 claims abstract description 38
- 230000005540 biological transmission Effects 0.000 claims abstract description 25
- 230000006837 decompression Effects 0.000 claims description 73
- 238000010295 mobile communication Methods 0.000 claims description 24
- 230000004044 response Effects 0.000 claims description 11
- 239000000969 carrier Substances 0.000 claims description 3
- 238000004891 communication Methods 0.000 claims 2
- 230000011664 signaling Effects 0.000 description 10
- 238000012546 transfer Methods 0.000 description 10
- 230000007704 transition Effects 0.000 description 10
- 230000007246 mechanism Effects 0.000 description 8
- 230000002457 bidirectional effect Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 230000008034 disappearance Effects 0.000 description 2
- 230000005641 tunneling Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000010606 normalization Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
-
- 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
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- 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)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Connections Effected By Soldering, Adhesion, Or Permanent Deformation (AREA)
Abstract
Método para definir la compresión de campos de cabecera para una conexión de paquetes de datos en una capa de protocolo de convergencia de un sistema de comunicaciones móviles, incluyendo dicho método: definir un contexto para unos módulos de compresión y descompresión como uno de los parámetros de la conexión para controlar el funcionamiento de dichos módulos de compresión y descompresión, definir una longitud para un identificador de contexto utilizado para identificar las conexiones de paquetes de datos en la transmisión de datos entre el módulo de compresión y el módulo de descompresión, definiendo dicha longitud el número máximo de conexiones de paquetes de datos comprimidos transmitido en una conexión, identificar cada conexión de paquetes de datos mediante su propio identificador de contexto. caracterizado por señalizar el número máximo de conexiones simultáneas de paquetes de datos, definido para cada soporte de radio efectuadas a una entidad de un sistema de comunicaciones móvilesque al establecer una nueva conexión de paquetes de datos decide a cual soporte de radio será asociada, y gobernar el sistema de comunicaciones móviles en respuesta a la superación del número de conexiones de paquetes de datos permitido por el valor máximo de la longitud del identificador de contexto, para definir un nuevo soporte de radio para las conexiones de paquetes de datos extra.
Description
Definición de la compresión de campos de cabecera
para conexiones de paquetes de datos.
La invención hace referencia a definir la
compresión de campos de cabecera para una conexión de paquetes de
datos, especialmente cuando se aplica la compresión a sistemas
móviles.
El rápido progreso alcanzado por la tecnología IP
(Protocolo Internet) durante los últimos años ha ampliado también
el potencial de utilización de diferentes aplicaciones basadas en
IP, además de la transferencia de datos convencional a través de
Internet. Particularmente, las aplicaciones de telefonía basadas en
IP se han desarrollado a un ritmo vertiginoso, como resultado de lo
cual puede implementarse, utilizando en principio la tecnología IP,
una parte cada vez mayor de la ruta de transmisión de la llamada,
incluso en redes telefónicas convencionales (PSTN/ISDN, Red
Telefónica Conmutada Pública/Red Digital de Servicios Integrados) y
en redes móviles (PLMN, Red Móvil Terrestre Pública).
La tecnología IP ofrece muchas ventajas,
especialmente en el caso de las redes móviles, dado que además de
los servicios convencionales de voz de las redes móviles que pueden
prestarse mediante diversas aplicaciones de voz basadas en IP, las
redes móviles facilitarán cada vez más servicios de datos
diferentes, como la navegación por Internet, servicios de correo
electrónico, juegos, etc. que normalmente suelen implementarse como
servicios conmutados por paquetes basados en IP. De este modo, las
capas IP configuradas en protocolos del sistema móvil podrían
prestar tanto servicios de audio y vídeo como diversos servicios de
datos.
En las redes móviles, resulta especialmente
importante utilizar, de la forma más eficaz posible, los limitados
recursos de radio. A su vez, esto complica la utilización de los
protocolos IP en el interfaz de radio, debido a que, en los
protocolos basados en IP, la proporción de los diversos campos de
cabecera de los datos transferidos es muy grande, por lo que la
proporción de datos útiles es muy reducida. Además, la tasa de
errores de bits (BER) del interfaz de radio y el tiempo de ida y
vuelta combinado (RTT) de las direcciones de subida y bajada pueden
incrementarse mucho en malas condiciones, lo que causa problemas en
los métodos de compresión de campos de cabecera más conocidos. Esto
ha generado la necesidad de desarrollar un método de compresión de
campos de cabecera adecuado para los diferentes protocolos IP, que
estaría especialmente adaptado para la transferencia de datos a
través del interfaz de radio: una compresión de campos de cabecera
eficiente que pueda, no obstante, utilizarse en situaciones en las
que se producen grandes aumentos de las tasas de errores de bits y
de los tiempos de ida y vuelta.
Con este fin, la IETF (Internet Engineering Task
Force) ha estado trabajando últimamente en la normalización de un
método de compresión de campos de cabecera conocido como ROHC
(Robust Header Compression). Una de las ideas subyacentes al
desarrollo de ROHC es que existen muchas redundancias entre los
diversos campos de cabeceras IP utilizados en la transferencia de
paquetes de datos, no sólo en el interior de los paquetes de datos
sino también entre ellos. Dicho de otro modo, una gran cantidad de
la información que contienen los campos de cabecera no se modifica
en absoluto durante la transferencia de los paquetes de datos y, de
este modo, puede reconstruirse con facilidad aun cuando no se haya
transmitido. Tan sólo una parte muy pequeña de los campos de
cabecera tiene unas características tales que la información que
incluye exige atención durante la compresión. Además, ROHC incluye
diversos niveles de compresión mediante los cuales la eficiencia de
la compresión aumenta cuando se produce la transición a un nivel
superior. ROHC siempre trata de utilizar el método de compresión más
eficaz posible, de tal forma, sin embargo, que antes de efectuar la
transición al siguiente nivel se garantice en todo momento un grado
suficiente de fiabilidad en el funcionamiento de dicho nivel. ROHC
también tiene la característica típica de que permite que diversos
aspectos esenciales para el uso de un método de compresión sean
gestionados por la capa de enlace inferior.
Uno de dichos aspectos a negociar a través de la
capa de enlace inferior entre un emisor y un receptor, es decir
entre un módulo de compresión y un módulo de descompresión, es
definir la longitud de un identificador de contexto (CID) utilizado
en un enlace de radio determinado. El identificador de contexto CID
se utiliza para distinguir entre sí, los diversos flujos de datos
de paquetes transmitidos a través del mismo enlace de radio. La
longitud del identificador de contexto CID puede ser un valor grande
o un valor pequeño, por lo cual, con un valor grande, la longitud
del identificador de contexto es de 1 ó 2 octetos (8 ó 16 bits) y
con un valor pequeño es de 0 octetos (0 bits). Con una pequeña
longitud CID (0 octetos) no es posible, de este modo, distinguir
entre sí diversos flujos de datos simultáneos mediante el
identificador de contexto CID, pero no obstante ROHC también
incluye un mecanismo interno mediante el cual pueden distinguirse
entre sí un máximo de 16 flujos de datos simultáneos aún cuando la
longitud del campo del identificador de contexto se hubiese definido
en cero octetos. La longitud del CID puede, de este modo,
negociarse antes de iniciar la compresión de los datos que van a
transmitirse y la longitud negociada del identificador de contexto
CID se utiliza posteriormente tanto en sentido ascendente como
descendente.
Un problema de la configuración que se ha
descrito anteriormente es, por ejemplo, una situación en la cual se
transmite a través de un soporte de radio un número máximo de
conexiones de datos simultáneas, permitido por la longitud definida
del identificador de contexto, y el usuario del terminal desea
formar un flujo de datos simultáneo más. Dado que ya se encuentra
en uso un número máximo de identificadores de contexto, no puede
definirse un identificador de contexto para el nuevo flujo de datos.
Entonces, si el nuevo flujo de datos necesita transmitirse
comprimido se definirá para él un contexto de flujo de datos que ya
se encuentre en uso. Esto significa que se establecerán dos
conexiones de datos comprimidos con el mismo identificador de
contexto, siendo el módulo de descompresión incapaz de
distinguirlas, por lo que se producirá una situación de error en el
sistema de compresión. Teniendo en cuenta que la práctica actual de
ROHC no define qué acción debe adoptarse ante un nuevo flujo de
datos "extra", el problema que acabamos de describir ocurre
siempre que un soporte de radio utiliza el número máximo de
conexiones de datos permitido por el identificador de contexto CID y
el usuario del terminal trata de abrir un nuevo flujo de datos.
Además, un terminal utilizado en algunas situaciones, por ejemplo
cuando se aplica ROHC a sistemas móviles, puede fijar sus propias
limitaciones internas derivadas del espacio disponible en memoria,
por ejemplo, en conexiones de datos simultáneas, y estas
limitaciones pueden ser más estrictas de lo que requeriría
ROHC.
El documento "MPLS/IP header compression",
Berger Lou et. Al.,
Draft-IEFT-MPLS-HDR-COMP-00.txt,
julio 2000, que muestra el estado más reciente de la técnica,
revela un método para la compresión de las cabeceras de los
datagramas IP que se transportan a través de MPLS. El documento
revela cómo los métodos existentes de compresión de cabeceras IP e
IP/UDP/RTP se extienden para operar a través de entradas de la pila
de etiqueta MPLS y comprimirlas.
El documento ''[ROHC]
keyword-draft cutouts (y anexos), capítulo 5.7.2,
"State transitions using keywork packets", Burmeister Carsten,
16 de junio de 2000, revela un mecanismo de utilización de paquetes
de claves para transitar con seguridad del estado FO al SO en la
compresión ROHC.
Por lo tanto, uno de los objetos de la invención
consiste en desarrollar un método y un dispositivo para llevar a
cabo dicho método a fin de reducir los inconvenientes que
anteceden. El objeto de la invención se consigue mediante un método
y un sistema caracterizados por lo indicado en las reivindicaciones
independientes. Las realizaciones preferidas de la invención se
recogen en las reivindicaciones dependientes.
La invención está basada en la idea de que a
pesar de que se supere el número de conexiones de paquetes de datos
permitidas por la longitud del identificador de contexto, los
parámetros del soporte de radio se definen de forma que puede
comprimirse, al menos, el número de campos de cabecera de la
conexión de paquetes de datos permitido por la longitud del
identificador de contexto definida. De acuerdo con un primer
aspecto de la invención, esto puede llevarse a cabo señalizando el
número máximo de conexiones simultáneas de paquetes de datos,
definido para cada soporte de radio a una entidad de un sistema de
comunicaciones móviles que, al establecer una nueva conexión de
paquetes de datos, decide a cual soporte de radio se asociará, y
gobernando el sistema de comunicaciones móviles, en respuesta a la
superación del número de conexiones de paquetes de datos permitido
por el valor máximo de la longitud del identificador de contexto,
para definir un nuevo soporte de radio para las conexiones de
paquetes de datos extra. De acuerdo con un segundo aspecto de la
invención, esto puede llevarse a cabo gobernando la capa de
protocolo de convergencia o el módulo de compresión de la misma, en
respuesta a la superación del número de conexiones de paquetes de
datos permitido por el valor máximo de la longitud del
identificador de contexto, para transmitir las conexiones de
paquetes de datos extra sin compresión del campo de cabecera. De
acuerdo con una realización preferida adicional de la invención, al
menos un valor de la longitud del identificador de contexto
definido se reserva para un flujo de datos sin comprimir.
El método y el sistema de la invención
proporcionan la ventaja de que, al menos, pueden comprimirse en
todas las situaciones tantas conexiones de datos transmitidas a
través del soporte de radio como lo permita la longitud máxima del
campo del identificador de contexto. Adicionalmente, el
procedimiento de la invención proporciona la ventaja de evitar la
interrupción de la compresión para las conexiones de datos que se
transmiten comprimidas. Otra ventaja adicional de la invención es
que permite la aplicación de compresión de campos de cabecera a las
conexiones de datos de la forma más eficiente posible, lo que
resulta ventajoso para la utilización eficiente de los recursos de
radio.
A continuación se describirá la invención en
mayor detalle a través de realizaciones preferidas y haciendo
referencia a los dibujos adjuntos, en los cuales:
La figura 1 es un diagrama de bloques de las
transiciones entre los distintos niveles de compresión de ROHC.
La figura 2 es un diagrama de bloques de las
transiciones entre los diferentes modos de funcionamiento de
ROHC.
La figura 3 es un diagrama de bloques de una
estructura simplificada del sistema UMTS.
La figura 4a y 4b muestran las pilas de protocolo
del servicio de datos por paquetes UMTS para el control de la
señalización y la transmisión de datos del usuario.
Las figuras 5a y 5b muestras modelos operativos
de la capa PDCP.
La figura 6 muestra definir identificadores de
paquetes de datos de acuerdo con una realización de la
invención.
En los siguientes párrafos se describirá como
llevar a cabo el método de compresión de campos de cabecera ROCH en
cuestión para las partes esenciales de la invención. Para una
descripción más detallada del método de compresión en cuestión, se
hace referencia a un borrador que se encuentra en Internet y que no
está concluido todavía "Robust Header Compressión (ROHC)",
versión 04, 11 de octubre de 2000.
En diferentes métodos de compresión se define
normalmente un contexto tanto para un módulo de compresión como para
un módulo de descompresión, siendo el contexto un estado que
utiliza el módulo de compresión para comprimir un campo de cabecera
que va a transmitirse y que el módulo de descompresión utiliza para
descomprimir un campo de cabecera recibido. Normalmente, el contexto
incluye una versión no comprimida del campo de cabecera
anteriormente transmitido (módulo de compresión) o recibido (módulo
de descompresión) durante una conexión de transferencia de datos.
Además, el contexto puede incluir información que identifique un
flujo de paquetes, como números de secuencia o marcas temporales de
los paquetes de datos. De este modo, el contexto incluye normalmente
tanto información estática, que sigue siendo la misma para todo el
flujo de paquetes de datos, como información dinámica que cambia a
lo largo del flujo de paquetes de datos, pero a menudo lo hace, de
acuerdo con un patrón definido.
ROHC utiliza tres niveles de compresión de tal
forma que la compresión se inicia en el nivel inferior y continúa
gradualmente hacia los niveles superiores. El principio básico es
que la compresión se lleva siempre a cabo en el nivel más elevado
posible, de forma que, no obstante, el módulo de compresión está
suficientemente seguro del hecho de que el módulo de descompresión
cuenta con suficiente información para llevar a cabo la
descompresión en el nivel en cuestión. Los factores que afectan a la
transición entre los distintos niveles de compresión son la
variación en los campos de cabecera consecutivos, los acuses de
recibo positivos y negativos recibidos desde el módulo de
descompresión y cuando no hay acuses de recibo, la expiración de
contadores secuenciales específicos. Es posible, por lo tanto,
pasar a un nivel inferior desde un nivel de compresión
superior.
Los niveles de compresión que utiliza ROHC en
relación con los protocolos IP (Protocolo Internet), UDP (Protocolo
Datagrama Usuario) y RTP (Protocolo en tiempo real) son
iniciación/actualización (IR), primer orden (FO) y segundo orden
(SO), y las transiciones entre estos niveles se describen en el
diagrama de la figura 1. El nivel IR se utiliza para crear el
contexto del módulo de descompresión o para recuperarse de una
situación de error. El módulo de compresión pasa al nivel IR cuando
se inicia la compresión del campo de cabecera, a solicitud del
módulo de descompresión, o cuando expira un contador interno. En el
nivel IR, el módulo de compresión envía campos de cabecera IR en un
formato sin comprimir. El módulo de compresión trata de pasar a un
nivel superior cuando está seguro de que el módulo de descompresión
ha recibido la información de actualización.
El nivel FO se utiliza para informar al receptor
acerca de irregularidades en los campos de cabecera del flujo de
datos de paquetes. Tras el nivel IR, el módulo de compresión opera
en el nivel FO en una situación en la que los campos de cabecera no
forman un patrón uniforme (dicho de otro modo, los campos de
cabecera consecutivos cambian de manera aleatoria de tal forma que
no pueden predecirse los cambios) o el módulo de compresión no
puede asegurarse de que el módulo de descompresión ha recibido los
parámetros que definen el patrón uniforme de los campos de cabecera.
Esta es una situación típica cuando se inicia, por ejemplo, una
transmisión de voz, especialmente durante las primeras ráfagas de
voz. En el nivel FO, el módulo de compresión envía campos de
cabecera FO comprimidos. El módulo de compresión trata nuevamente de
pasar a un nivel superior si los campos de cabecera forman un
patrón uniforme y está seguro de que el módulo de descompresión ha
recibido los parámetros que definen el patrón uniforme. Los
paquetes de datos del nivel FO incluyen normalmente información de
actualización del contexto, lo que significa que una descompresión
satisfactoria también requiere una transmisión satisfactoria de
campos de cabecera FO consecutivos. De este modo, el éxito en el
proceso de descompresión depende de los paquetes del nivel FO
perdidos o dañados.
En el nivel SO, la compresión es óptima. Los
campos de cabecera forman un patrón uniforme que el módulo de
compresión describe mediante campos de cabecera SO que, en la
práctica, son números de secuencia de los paquetes de datos. La
información ya se ha transmitido en el nivel FO al módulo de
descompresión en relación con los parámetros que definen el patrón
uniforme de los campos de cabecera, y en función de los parámetros
y del número de secuencia recibido, el módulo de descompresión puede
extrapolar los campos de cabecera originales. Debido a que los
paquetes de datos enviados en el nivel SO son, en la práctica,
independientes entre sí, la sensibilidad al error de la
descompresión también es baja. Cuando los campos de cabecera dejan
de formar un patrón uniforme, el módulo de compresión pasa de nuevo
al nivel FO.
La descompresión también tiene tres niveles que
están vinculados a definir el contexto del módulo de descompresión.
El módulo de descompresión siempre comienza a funcionar desde el
nivel más bajo cuando no se ha definido todavía un contexto
(ausencia de contexto). El módulo de descompresión, por lo tanto, no
ha descomprimido aún ningún paquete de datos. Cuando el módulo de
descompresión ha descomprimido el primer paquete de datos que
incluye información de contexto, tanto estática como dinámica,
puede pasar directamente, saltándose el nivel medio (Contexto
Estático), al nivel superior (Contexto Total). Como resultado de
diversas situaciones de error en el nivel superior, el módulo de
descompresión pasa al nivel medio, pero normalmente incluso un
paquete de datos descomprimido con éxito hace que el módulo de
descompresión vuelva a pasar al nivel superior.
Además de los diferentes niveles de compresión,
ROHC tiene tres modos de funcionamiento diferentes: modo
unidireccional (modo U), modo bidireccional optimista (modo O) y
modo bidireccional fiable (modo R), que se muestran en el diagrama
de la figura 2. De acuerdo con la figura 2, todos los niveles de
compresión (IR, FO, SO) descritos anteriormente funcionan en todos
los modos, pero cada modo funciona independientemente en cada nivel
y también toma decisiones sobre las transiciones entre niveles de
forma independiente. 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 utilizada, como la posibilidad de utilizar
un canal de retorno, las probabilidades y la distribución de errores
o los efectos de la variación del tamaño de los campos de
cabecera.
En el modo unidireccional, los paquetes de datos
se transmiten únicamente desde el módulo de compresión al módulo de
descompresión de forma que el modo U de ROHC resulta útil en
aquellas situaciones en las que no es posible o deseable la
utilización de un canal de retorno. En el modo U, las transiciones
entre los distintos niveles de compresión se efectúan como
resultado de la expiración de ciertos contadores secuenciales o a
partir de la variación de los patrones de los campos de cabecera. Al
no utilizarse ningún canal de retorno, la compresión en el modo U
es menos eficiente y la desaparición de paquetes de datos a lo
largo de la vía de transmisión es más probable que en cualquiera de
los modos bidireccionales. Cuando se utiliza ROHC siempre se
comienza en el modo U y la transición a cualquiera de los modos
bidireccionales puede tener lugar cuando el módulo de descompresión
ha recibido al menos un paquete y, en respuesta al paquete, el
módulo de descompresión indica que es necesario un cambio de
modo.
El modo bidireccional optimista es similar al
modo unidireccional con la excepción de que en el modo O se utiliza
un canal de retorno para corregir situaciones de error y para
acusar recibo de actualizaciones significativas del contexto desde
el módulo de descompresión al módulo de compresión. En el modo O no
se llevan a cabo actualizaciones secuenciales. El modo O resulta
preferiblemente adecuado para conexiones que requieren una
eficiencia de compresión óptima con un pequeño tráfico en el canal
de retorno. El modo O proporciona una transferencia de paquetes de
datos razonablemente fiable en la cual normalmente puede mantenerse
bien la sincronización entre el módulo de compresión y el módulo de
descompresión y los paquetes de datos se pierden muy raramente y,
si es que se pierden, lo hacen en cantidades muy pequeñas. No
obstante, con tasas de error binario muy elevadas, pueden perderse
paquetes de datos en la vía de transmisión.
El modo bidireccional fiable difiere claramente
de los modos mencionados anteriormente. El modo R utiliza un canal
de retorno para acusar recibo de todas las actualizaciones de
contexto, así como para acusar recibo de las actualizaciones de
números de secuencia. De este modo, en el modo R los paquetes de
datos pueden transmitirse de forma fiable casi en su totalidad
entre el módulo de compresión y el módulo de descompresión. La
compresión de los campos de cabecera no puede provocar la
desaparición de paquetes de datos en el modo R. Un inconveniente del
modo R es que, en algunos casos, el tamaño de los campos de
cabecera es ligeramente mayor que en los modos mencionados
anteriormente, y que el tráfico del canal de retorno aumenta
considerablemente.
Los tres modos de funcionamiento y los tres
niveles de compresión de ROHC forman diferentes situaciones de
funcionamiento para la compresión de los campos de cabecera y cada
situación requiere que se defina el funcionamiento del módulo de
compresión y del módulo de descompresión, así como la transmisión de
paquetes entre ambos. ROHC utiliza diferentes paquetes en
diferentes situaciones de funcionamiento. En este momento, se han
definido seis tipos de paquetes de datos diferentes para ROHC,
cuatro de los cuales se utilizan para la transmisión desde el módulo
de compresión al módulo de descompresión y dos como paquetes de
datos del canal de retorno desde el módulo de descompresión al
módulo de compresión. El número de tipos de paquetes de datos
utilizados puede cambiar en el futuro, pero todos los tipos de
paquetes de datos están caracterizados porque se adjunta a cada
paquete de datos un identificador de contexto CID que define el
contexto utilizado en cada ocasión antes de enviar el paquete a la
vía de transmisión.
La longitud del identificador de contexto CID se
negocia separadamente para cada soporte de radio entre el módulo de
compresión y el módulo de descompresión. De acuerdo con las
definiciones ROHC, la capa de protocolo inferior (capa de enlace)
utilizada en cada ocasión debe proporcionar un mecanismo para la
negociación de los parámetros utilizados en la compresión de campos
de cabecera, como la longitud del identificador de contexto. Los
parámetros se negocian antes de iniciar la compresión y, en esta
conexión, puede definirse la longitud del identificador de contexto
del flujo de paquetes de datos, de acuerdo con la técnica anterior,
para que sea de 0, 8 ó 16 bits. En un canal lógico de transferencia
de datos, es posible transmitir simultáneamente varios flujos de
paquetes de datos cuyos contextos se identifican y distinguen entre
sí mediante el identificador de contexto CID. Si sólo se transmite
un flujo de paquete de datos a través del canal, lo que es típico
de distintas aplicaciones VoIP (voz a través de IP), por ejemplo, la
longitud del identificador de contexto CID se hace "pequeña",
es decir se le asigna el valor 0. No obstante, incluso en este
momento, es posible distinguir mediante mecanismos internos ROHC un
máximo de 16 flujos de datos simultáneos, es decir que siempre
pueden abrirse 15 nuevas conexiones de datos además del flujo de
datos original, aun cuando la longitud del identificador de
contexto CID se haya definido como cero. Esto se implementa, de tal
forma que la primera conexión de datos se transmite siempre sin
ningún identificador de contexto y a las siguientes conexiones de
datos se les adjunta un octeto cuyos primeros cuatro bits indican
que se trata de un identificador de contexto y cuyos siguientes
cuatro bits indican el valor real del identificador de contexto.
Si, cuando se define el soporte de radio, resulta evidente que van
a transmitirse varios flujos de paquetes de datos a través del mismo
canal, un valor grande, es decir, de 1 ó 2 octetos (8 ó 16 bits),
se define preferiblemente como la longitud del identificador de
contexto en función de la aplicación, del protocolo de transmisión
de datos y de las condiciones del canal utilizado en el soporte de
radio.
Un sistema de telecomunicaciones, al cual se
aplica el método de compresión de campos de cabecera de acuerdo con
las especificaciones ROHC, es un sistema móvil de tercera
generación también conocido como UMTS (Universal Mobile
Telecommunication System) e IMT-2000 (International
Mobile Telephone System). En los siguientes párrafos se describirá
de forma simplificada la estructura del sistema UMTS basándose en la
figura 3.
La figura 3 sólo contiene aquellos bloques que
son esenciales para explicar la invención, pero es evidente para
cualquier persona versada en la materia que un sistema convencional
de telefonía móvil también incluye otras funciones y estructuras
que no precisan describirse en mayor detalle en el presente
documento. Los componentes principales de un sistema de telefonía
móvil son una red troncal CN, una red UTRAN de acceso por radio
terrestre al sistema de telefonía móvil UMTS, que constituye la red
fija del sistema de telefonía móvil y una estación móvil o equipo de
usuario UE. El interfaz entre CN y UTRAN se denomina Iu y el
interfaz por aire entre UTRAN y UE se denomina Uu.
Una red UTRAN incluye típicamente una pluralidad
de Subsistemas de Red de Radio RNS, y al interfaz entre los
subsistemas se denomina Iur (no mostrado). El subsistema RNS incluye
un Controlador de Red vía Radio RNC y una o más estaciones base BS,
a las que también se les denomina nodo B. El interfaz entre el RNC y
la BS se denomina Iub. Normalmente, una estación base BS es
responsable de la implementación de la vía de radio, y el
controlador de red vía radio RNC gestiona al menos los siguientes
elementos: gestión de recursos de radio, control del mecanismo de
traspaso o handover entre células, el ajuste de la potencia, la
temporización y la sincronización, y la llamada al equipo del
usuario.
La red troncal CN está constituida por una
infraestructura perteneciente a un sistema de telefonía móvil y
externa a la UTRAN. En la red troncal, un Centro Móvil de
Conmutación/Registro de Localización de Visitantes
3G-MSC/VLR se conecta a un Registro de localización
de abonados propios HLR, y también, preferiblemente, a un Punto de
Control del Servicio SCP de una red inteligente. El Registro de
localización de abonados propios HLR y el Registro de Localización
de Visitantes VLR incluyen información sobre abonados móviles: el
Registro de localización de abonados propios HLR incluye
información sobre todos los abonados de una red móvil y los
servicios a los que estos están suscritos, y el Registro de
localización de visitantes VLR incluye información sobre las
estaciones móviles que visitan el área de un centro de conmutación
móvil específico MSC. Se establece una conexión a un nodo de
servicio de un sistema de radio por paquetes
3G-SGSN (Nodo de Soporte GPRS de Servicio) a través
de un interfaz Gs', y a una red de telefonía fija PSTN/ISDN a
través de un centro de conmutación móvil de puerta de enlace GMSC
(no mostrado). Se establece una conexión desde el nodo de servicio
3G-SGSN a las redes de datos externas PDN a través
de un interfaz GN con un nodo de puerta de enlace GGSN (Gateway
GPRS Support Node) que cuenta con una conexión adicional con las
redes de datos externas PDN. La conexión tanto desde el centro de
conmutación móvil 3G-MSC/VLR y el nodo de servicio
SG-SGSN con la red de radio UTRAN (UMTS Terrestrial
Radio Access Network) se configura a través del interfaz Iu. Cabe
señalar que el sistema UMTS está diseñado de tal forma que la red
troncal CN puede ser idéntica a la red troncal de un sistema GSM,
por ejemplo, en cuyo caso no es necesario reconstruir toda la
infraestructura de la red.
De este modo, el sistema UMTS también incluye un
sistema de radio por paquetes que, en buena medida, se lleva a cabo
de acuerdo con un sistema GPRS conectado a una red GSM, lo que
explica las referencias a un sistema GPRS en los nombres de los
elementos de la red. El sistema de radio por paquetes UMTS puede
incluir un número plural de nodos de puerta de enlace y de
servicio, estando normalmente varios nodos de servicio
3G-SGSN conectados a un nodo de puerta de enlace
3G-GGSN. Ambos nodos 3G-SGSN y
3G-GGSN funcionan como encaminadores (routers) que
soportan la movilidad de una estación móvil controlando dichos
encaminadores, el sistema móvil y encaminando los paquetes de datos
hacia la estación móvil, independientemente de su ubicación y del
protocolo utilizado. El nodo de servicio 3G-SGSN se
encuentra en contacto con una estación móvil UE a través de la red
de radio UTRAN. Una de las tareas del nodo de servicio
SG-SGSN consiste en detectar estaciones móviles con
capacidad para conexiones de radio por paquetes en su área de
servicios, para transmitir y recibir paquetes de datos desde dichas
estaciones móviles y efectuar el seguimiento de la ubicación de las
estaciones móviles en su área de servicio. Además, el nodo de
servicio 3G-SGSN está en contacto con el centro de
comunicación móvil 3G-MSC y con el registro de
localización de visitantes VLR a través del interfaz de
señalización Gs' y con el registro de localización de abonados
propios HLR a través del interfaz Gr. Los registros relacionados con
servicios de radio por paquetes y que incluyen contenidos de
protocolo de datos por paquetes específicos del abonado también se
almacenan en el registro de localización de abonados propios
HLR.
El nodo de puerta de enlace
3G-GGSN actúa como puerta de enlace entre el sistema
de radio por paquetes de la red UMTS y la red de datos externa PDN
(Red de Paquetes de Datos). Entre las redes de datos externas se
incluyen las redes UMTS o GPRS de un segundo operador de red,
Internet, una red X.25 o redes de área local privadas. El nodo de
puerta de enlace 3G-GGSN está en contacto con dichas
redes de datos a través del interfaz Gi. Los paquetes de datos
transmitidos entre el nodo de puerta de enlace
3G-GGSN y el nodo de servicio
3G-SGSN siempre están encapsulados de acuerdo con el
protocolo de tunelización de puerta de enlace GTP. El nodo de
puerta de enlace 3G-GGSN también incluye
direcciones PDP (Protocolo de Paquetes de Datos) de las estaciones
móviles y su información de encaminado, es decir una dirección
3G-SGSN. La información de encaminado se utiliza
para enlazar los paquetes de datos entre la red de datos externa y
el nodo de servicio 3G-SGSN. La red situada entre el
nodo de puerta de enlace 3G-GGSN y el nodo de
servicio 3G-SGSN utiliza un protocolo IP,
preferiblemente el Ipv6 (Protocolo Internet, versión 6).
Las figuras 4a y 4b muestran las pilas de
protocolos UMTS utilizadas para la señalización de control (plano de
control) y la transmisión de datos de usuario (plano de usuario) en
el servicio de radio por paquetes del sistema UMTS. La figura 4a
muestra la pila de protocolos utilizada para la señalización de
control entre la estación móvil MS y la red troncal CN. La gestión
de la movilidad MM, el control de llamadas CC y la gestión de la
sesión SM de la estación móvil MS están señalizadas en las capas
más altas del protocolo entre la estación móvil MS y la red troncal
CN de forma que las estaciones base BS y el controlador de red vía
radio RNC situado entre ellas son transparentes para esta
señalización. La gestión de recursos de radio de los enlaces por
radio entre las estaciones móviles MS y las estaciones base BS se
lleva a cabo mediante un sistema de gestión de recursos de radio
RRM que transmite los datos de control procedentes del controlador
de la red de radio RNC a las estaciones base BS. Estas funciones
asociadas a la gestión general de un sistema móvil constituyen un
grupo denominado protocolos de la red troncal (protocolos CN),
también conocido como Estrato de No Acceso. Igualmente, la
señalización relativa al control de la red de radio entre la
estación móvil MS, la estación base BS y el controlador de la red
de radio RNC se lleva a cabo en capas de protocolo denominadas
protocolos de la red de acceso vía radio (protocolos RAN), es decir
el Estrato de Acceso. Estos incluyen protocolos de transferencia en
el nivel inferior y la señalización de control transmitida por los
protocolos de transferencia se transfiere a los niveles superiores
para su posterior procesamiento. La más esencial de las capas
superiores de Estratos de Acceso es el protocolo de control de
recursos de radio RRC que es el responsable, por ejemplo, del
establecimiento, la configuración, el mantenimiento y la liberación
de enlaces vía radio entre la estación móvil MS y la red vía radio
UTRAN y de la transmisión de información de control desde la red
troncal CN y la red vía radio RAN a las estaciones móviles MS.
Además, el protocolo de control de recursos vía radio RRC es el
responsable de la asignación de capacidad suficiente para el soporte
de radio de acuerdo con las instrucciones del sistema de gestión de
recursos de radio RRM en operaciones de asignación de capacidad
basada en aplicaciones, por ejemplo.
Los datos de usuario conmutados por paquetes UMTS
se transmiten utilizando una pila de protocolos mostrada en la
figura 4b. En el interfaz Uu entre la red vía radio UTRAN y la
estación móvil MS se lleva a cabo la transmisión de datos de nivel
inferior sobre la capa física de acuerdo con un protocolo WCDMA o
TD-CDMA. Una capa MAC situada sobre la capa física
transmite los paquetes de datos entre la capa física y una capa
RLC, siendo la capa RLC la que se ocupa de la gestión lógica de los
enlaces vía radio de las diferentes portadoras de radio. Las
funciones RLC incluyen, por ejemplo, la segmentación de los datos
de usuario (RLC-SDU) a transmitir en uno o más
paquetes de datos RLC, RLC-PDU. Los campos de
cabecera IP de los paquetes de datos (PDCP-PDU) de
la capa PDCP situada por encima de RLC pueden comprimirse
opcionalmente. Con posterioridad, los PDCP-PDUs se
envían a RLC y se hacen corresponder con un RLC-SDU.
Los datos de usuario y los RLC-SDU se segmentan y
transmiten en tramas RLC a las cuales se añade información sobre
direccionamiento y verificación esencial para la transmisión de
datos. La capa RLC también se ocupa de la retransmisión de las
tramas dañadas. El nodo de servicio 3G-SGSN es el
responsable del enrutamiento de los paquetes de datos procedentes
de la estación móvil MS a través de la red vía radio RAN hasta el
nodo de puerta de enlace correcto 3G-GGSN. Esta
conexión utiliza un protocolo de tunelización GTP que encapsula y
tuneliza todos los datos de usuario y señalizaciones que van a
transmitirse a través de la red troncal. El protocolo GTP se
ejecuta por encima del IP utilizado por la red troncal.
La figura 5a muestra un modelo funcional de la
capa PDCP en el cual se define una entidad PDCP por cada soporte de
radio. Teniendo en cuenta que en los sistemas actuales se define un
contexto individual PDP para cada soporte de radio, también se
define una entidad PDCP para cada contexto PDP y se define una
determinada entidad RLC para cada entidad PDCP de la capa RLC. Como
se ha indicado anteriormente, la capa PDCP también puede
implementarse funcionalmente, en principio, de tal forma que se
multiplexen varios contextos PDP en la capa PDCP, en cuyo caso, en
la capa RLC situada por debajo de la capa PDCP, una entidad RLC
reciba paquetes de datos procedentes de varias portadoras de radio
de forma simultánea.
En la figura 5b se muestra una situación en la
cual una entidad PDCP recibe paquetes de datos a través de un
soporte de radio procedentes de dos aplicaciones diferentes, A y B.
Los flujos de datos que contiene el soporte de radio se distinguen
entre sí en función de los campos de cabecera IP antes del módulo de
compresión de campos de cabecera de la entidad PDCP, tras lo cual
los flujos de datos pasan a ser comprimidos. El módulo de
compresión distingue los flujos de datos entre sí definiendo para
ellos distintos identificadores de contexto, mediante lo cual el
módulo de descompresión del receptor puede nuevamente distinguir
entre sí los flujos de datos y proceder a su descompresión. Para
ilustrar esta operación, la figura 5b muestra la entidad módulo de
compresión como dos bloques separadas pero, en la práctica, existen
dos contextos de compresión dentro de la misma entidad de
compresión. No obstante, los flujos de datos comprimidos se
transmiten a través de la misma conexión RLC.
Cada entidad PDCP puede utilizar uno o más
algoritmos de compresión de campos de cabecera o no utilizar
ninguno. Varias entidades PDCP pueden también utilizar el mismo
algoritmo. El controlador de recursos vía radio RRC negocia un
algoritmo adecuado para cada entidad PDCP, así como unos parámetros
de control del algoritmo y, a continuación, notifica el algoritmo
seleccionado y los parámetros a la capa PDCP a través de un punto
PDCP-C-SAP (PDCP Control Service
Access Point). El método de compresión utilizado depende del tipo
de protocolo de nivel de red utilizado en la conexión, indicándose
dicho tipo al controlador de recursos vía radio cuando se activa el
contexto PDP.
En el sistema UMTS, la compresión de campos de
cabecera de los paquetes de datos que se transmiten y la
descompresión de los paquetes de datos que se reciben se llevan a
cabo, por lo tanto, en la capa de protocolo de convergencia PDCP.
Entre las tareas de la capa PDCP se incluyen funciones relacionadas
con la mejora de la eficiencia del canal, que normalmente se basan
en diferentes métodos de optimización, como la utilización de
algoritmos de compresión de campos de cabecera de paquetes de datos.
Debido a que en la actualidad los protocolos de nivel de red
previstos para UMTS son protocolos IP, los algoritmos de compresión
utilizados son aquellos normalizados por IETF (Internet Engineering
Task Force). De este modo, el método de compresión ROHC resulta
especialmente adecuado para el sistema UMTS. La capa PDCP del
terminal suele soportar diversos métodos de compresión de los
campos de cabecera a fin de permitir el establecimiento de la
conexión con tantos tipos de protocolos de nivel de red como sea
posible.
Al aplicar el método ROHC a la capa de protocolo
de convergencia de UMTS, tanto el PDCP transmisor como el PDCP
receptor incluyen una pareja de módulo de
compresión-módulo de descompresión para comprimir
los paquetes de datos transmitidos y descomprimir los paquetes de
datos recibidos. La capa de protocolo de convergencia PDCP
proporciona al método de compresión ROHC un mecanismo para negociar
la longitud del identificador de contexto para cada soporte de
radio. En la práctica, el mecanismo se realiza de forma que la capa
PDCP transmite los mensajes del módulo de compresión y del módulo
de descompresión a RRC y la negociación real se efectúa mediante la
señalización RRC. Para poder utilizar los recursos de radio en la
forma más eficaz posible, la longitud del identificador de contexto
se define preferiblemente como cero para el soporte de radio.
Si la longitud del identificador de contexto CID
definida para el soporte de radio es "pequeña", es decir cero
octetos, y todas las 16 posibles conexiones de datos se encuentran
en uso, y si el usuario del terminal desea establecer un flujo de
datos simultáneo adicional para un soporte de radio que tenga dicha
definición, se produce una situación problemática, ya que no se
pueden distinguir entre sí 17 flujos de datos simultáneos con un
identificador de contexto "pequeño". Dado que un nuevo flujo de
datos no puede identificarse mediante su propio identificador de
contexto de acuerdo con las especificaciones ROHC, se definirá para
él un identificador de contexto de un flujo de datos existente. En
tal caso, se transmitirán simultáneamente dos flujos de datos con
el mismo identificador de contexto, lo que producirá una situación
de error en el módulo de descompresión debido a que el módulo de
descompresión ya no podrá distinguir entre sí las conexiones de
datos. También se produce un problema similar con cualquier otro
valor de longitud CID definido, cuando el soporte de radio utiliza
el número máximo de conexiones de datos definido para la longitud
del identificador de contexto CID y el usuario del terminal trata
de abrir un nuevo flujo de datos. La transmisión de varios flujos
de datos a través de un interfaz de radio sin compresión de campos
de cabecera produce una utilización no óptima de los recursos de
radio, lo que resulta un obstáculo para un uso eficiente de todo el
sistema móvil.
Actualmente, los problemas que se acaban de
describir puede reducirse, no obstante, gracias al procedimiento de
la invención en el cual se definen los parámetros del soporte de
radio de tal forma que pueda comprimirse al menos el número de
campos de cabecera de la conexión de paquetes de datos permitido
por la longitud del identificador de contexto definido, a pesar del
hecho de que se haya superado el número de conexiones de paquetes
de datos permitido por la longitud de dicho identificador de
contexto. De este modo, es posible garantizar que, por ejemplo,
cuando la longitud del identificador de contexto del soporte de
radio se fija en cero y el usuario del terminal desea establecer un
17º flujo de datos simultáneo para el soporte de radio, podrán
transmitirse al menos los 16 flujos de datos originales y,
preferiblemente, la totalidad de los 17 utilizando ROHC.
Igualmente, con cualquier otro valor definido para la longitud del
CID, cuando el soporte de radio utiliza el número máximo de
conexiones de datos definido para la longitud del identificador de
contexto CID, y el usuario del terminal trata de abrir un nuevo
flujo de datos, es posible garantizar que al menos un número
correspondiente al número original de conexiones de datos, y
preferiblemente todos los flujos de datos, puedan transmitirse
utilizando ROHC.
De acuerdo con una primera realización de la
invención, descrita anteriormente puede llevarse a cabo mediante
ROHC de forma que el algoritmo ROHC se defina, de tal manera que
siempre se reserve para un flujo de datos sin comprimir al menos un
valor, y preferiblemente el último, de la longitud del identificador
de contexto CID, es decir el espacio CID, negociado para cada
soporte de radio. De este modo es posible garantizar que las
conexiones de datos que ya se encuentran en uso pueden transmitirse
comprimidas y que, al mismo tiempo, puede establecerse una nueva
conexión de datos sin compresión. El algoritmo ROHC puede, por
ejemplo, definirse en función de la negociación entre el módulo de
compresión y el módulo de descompresión de tal forma que si la
longitud del campo identificador de contexto se establece en cero,
los primeros 15 flujos de datos estén comprimidos y si el usuario
del terminal trata de generar un nuevo flujo de datos (16º), este y
cualesquiera flujos de datos simultáneos generados con posterioridad
al mismo se transmitirán al receptor sin comprimir. Se adjunta un
campo CID a los paquetes de datos sin comprimir para informar al
receptor de que sus campos de cabecera no se han comprimido y que,
por lo tanto, deberían saltarse el módulo de descompresión. También
es posible reservar para los flujos de datos sin comprimir diversos
valores del espacio CID del campo identificador de contexto
negociado para el soporte de radio.
De acuerdo con una segunda realización de la
invención, la capa de protocolo de convergencia PDCP supervisa el
número de conexiones de datos y si se supera el número de
conexiones de datos permitido, la capa PDCP informará en este
sentido al protocolo de control de recursos de radio RRC el cual, a
su vez, realizará una re-configuración del soporte
de radio durante la cual se redefinirán los parámetros del soporte
de radio, especialmente la longitud del identificador de contexto,
de forma que los campos de cabecera de cada flujo de datos puedan
comprimirse de acuerdo con ROHC. Por ejemplo, si la longitud del
identificador de contexto del soporte de radio se fija en cero y la
capa PDCP detecta 17 o más flujos de datos simultáneos, se
reconfigurará el soporte de radio, con lo cual el valor máximo del
campo identificador de contexto se definirá como mayor que cero.
Esto requiere añadir una nueva función a la capa PDCP para controlar
el número de conexiones de datos de cada soporte de radio. Si el
número de conexiones de datos de un soporte de radio se corresponde
con el valor máximo de la longitud del identificador de contexto y
se establece una nueva conexión de datos, PDCP informará a RRC como
se ha descrito anteriormente. También es posible que a causa de las
limitadas propiedades del terminal, por ejemplo, el número de
conexiones de datos simultáneas se fije a través de la señalización
RRC en cuatro flujos de datos, por ejemplo. En este caso, será
necesario que la capa PDCP pueda supervisar el número de conexiones
de datos simultáneas como se ha descrito anteriormente, debido a
que los mecanismos ROHC no afectan a una situación en la cual el
número más elevado de conexiones de datos simultáneas es inferior al
valor máximo del campo identificador de contexto.
La primera y la segunda realización descritas
anteriormente pueden utilizarse de acuerdo con una realización
preferida mediante la capa PDCP, de tal forma que la capa PDCP
supervise de acuerdo con dicha segunda realización el número de
conexiones de datos existentes en un soporte de radio y, en caso
necesario, defina de acuerdo con dicha primera realización que no
se lleve a cabo la compresión de los campos de cabecera en las
conexiones de datos extra por encima del número de conexiones de
datos permitido por el máximo valor del identificador de contexto.
Esto garantiza que al menos los flujos de datos originales se
puedan transmitir con una compresión óptima. En este caso, si la
longitud del identificador de contexto del soporte de radio se
define como cero, por ejemplo, y la capa PDCP detecta 17 flujos de
datos simultáneos, dicho último flujo (17º) se transmitirá sin
compresión del campo de cabecera y la funcionalidad de la capa PDCP
ordenará que el nuevo flujo de datos se salte el módulo de
compresión. De acuerdo con una realización preferida, esta
funcionalidad de la capa PDCP puede también seleccionar los flujos
de datos comprimidos, en cuyo caso los flujos de datos que se saltan
el módulo de compresión no son automáticamente el último flujo de
datos generado.
De acuerdo con una tercera realización, la
entidad UMTS (por ejemplo, el protocolo de gestión de sesión SM)
que, cuando se establece una conexión de datos decide a qué soporte
de radio pertenecen los nuevos flujos de datos, es informada cuando
se establece la conexión de datos de las limitaciones introducidas
por el valor máximo del identificador de contexto en el número de
conexiones de datos simultáneas, especialmente cuando la longitud
del identificador de contexto del soporte de radio se fija en cero.
Si en ese momento se encuentran en uso 16 flujos de datos y se
detecta la necesidad de 17 o más flujos de datos simultáneos, podrá
definirse un nuevo flujo de datos "extra", reconfigurándose su
propia soporte de radio o la primera soporte de radio y otorgándose
a la longitud del campo identificador de contexto un valor superior
a cero. En ambos casos, los campos de cabecera de cada flujo de
datos pueden comprimirse de acuerdo con ROHC. También en esta
realización debe tenerse especialmente en cuenta una situación en
la cual, a causa de las limitadas propiedades del terminal, el mayor
número de conexiones de datos simultáneas es tan sólo de cuatro
flujos de datos, por ejemplo. En tal caso, será necesario que la
identidad que controle el establecimiento de la conexión de datos
sea capaz de supervisar el número de conexiones de datos
simultáneas, como se ha descrito anteriormente.
De acuerdo con una cuarta realización, los
identificadores de paquete (PID) de la estructura de paquetes de
datos de la capa PDCP se utilizan para indicar los cambios
necesarios en la longitud del identificador de contexto. En la capa
PDCP, los distintos métodos de compresión se denotan y distinguen
entre sí mediante identificadores de paquete PID adjuntos a los
paquetes de datos PDU. Para cada entidad PDCP se crea una tabla
para los valores del identificador del paquete PID, en la cual los
distintos algoritmos de compresión se equiparan con los diferentes
paquetes de datos, y el valor del identificador de paquetes PID se
determina como una combinación de ambos. Si no se utiliza ningún
algoritmo de compresión, el identificador de paquete PID obtiene el
valor cero. Los valores PID se definen consecutivamente para cada
algoritmo de compresión y su combinación con diferentes tipos de
paquetes de datos de tal forma que los valores PID de cada
algoritmo de compresión comienzan a partir de n + 1, donde n es el
último valor PID definido para el algoritmo de compresión anterior.
El orden de los algoritmos de compresión se determina mediante
negociaciones con el controlador de recursos de radio RRC. A partir
de la tabla de valores PID, las entidades PDCP de ambos extremos de
la conexión de datos por paquetes pueden identificar los algoritmos
de compresión de los paquetes de datos enviados y recibidos.
Estos valores PID pueden, en esta realización de
la invención, utilizarse de tal forma que se asignen tres valores
PID para distintos valores del campo identificador de contexto (0,
1 ó 2 octetos) de ROHC de acuerdo con la tabla mostrada en la Figura
6. Alternativamente, pueden asignarse dos valores PID de forma que
representen los valores del espacio CID "pequeño" (0 octetos)
y "grande" (1 ó 2 octetos). Posteriormente, con un valor de
espacio CID "grande", los bits de ampliación del campo CID se
pueden utilizar para indicar con mayor detalle sí esta situación
afecta a un campo CID de 8 ó 16 bits. Si la longitud del
identificador de contexto del soporte de radio se fija en cero y la
capa PDCP detecta 17 flujos de datos simultáneos, podrá indicarse la
variación de la longitud del campo CID a la entidad PDCP receptora
mediante estos valores PID. Los valores PID se transmiten
preferentemente hasta que se reconfigura el soporte de radio o el
número de conexiones de datos vuelve a ser de 16.
De acuerdo con una quinta realización, no se
redefine la longitud del campo CID, aun cuando se haya excedido el
máximo valor del espacio CID, sino que puede establecerse una
conexión RLC independiente para las diferentes conexiones de datos.
Esto puede implementarse de tal forma que cuando se sobrepasa el
valor máximo del espacio CID cada nueva conexión de datos obtiene
una conexión RLC independiente cuya longitud del campo CID es
preferiblemente cero. Alternativamente, para cada flujo de datos
puede definirse una conexión RLC independiente cuya longitud del
campo CID se establece en cero. Además, los flujos de datos pueden
distribuirse hacia las dos conexiones RLC en una situación en la
que se encuentren en uso 32 flujos de datos, en cuyo caso los flujos
de datos podrán distribuirse hacia dos conexiones RLC cuyas
longitudes de campo CID puedan, preferiblemente, mantenerse en cero.
A continuación, deberían modificarse las especificaciones de la capa
PDCP a fin de permitir que una entidad PDCP utilice simultáneamente
varias conexiones RLC. Esta realización resulta óptima para la
utilización de los recursos de radio debido a que cada flujo de
datos simultáneo puede transmitirse sin un campo CID (longitud CID
= 0), en cuyo caso puede maximizarse la proporción de datos útiles
contenida en los datos transmitidos.
De acuerdo con una sexta realización, no se
aceptan para su transmisión las conexiones de datos simultáneas que
superen el valor máximo definido del identificador de contexto. Si
la longitud del identificador de contexto del soporte de radio se
ha fijado en cero, por ejemplo, y hay 16 flujos de datos en uso, y
se intenta generar un 17º flujo de datos simultáneo, la capa PDCP
y/o el módulo de compresión no aceptarán el establecimiento de dicha
17ª conexión de datos, y se rechazarán paquetes de datos.
De este modo, el procedimiento de la invención
garantiza que en todas las situaciones sea posible comprimir, al
menos, tantas conexiones de datos transmitidas a través del soporte
de radio como lo permita la longitud máxima del campo identificador
de contexto definido para el soporte de radio. Además, se evita la
interrupción de la compresión de las conexiones de datos que van a
transmitirse comprimidas mediante el procedimiento de la invención.
El procedimiento de la invención permite la aplicación de
compresión de campos de cabecera a conexiones de datos en la forma
más eficiente posible, lo que resulta ventajoso para una
utilización eficaz de los recursos de radio.
El procedimiento de la invención se ha descrito
anteriormente utilizando como ejemplo el sistema UMTS. No obstante,
la compresión de campos de cabecera de acuerdo con ROHC no está
vinculada al sistema UMTS, sino que preferiblemente puede aplicarse
a cualquier sistema de telecomunicaciones que transmita paquetes de
datos IP. El procedimiento de la invención puede aplicarse
preferiblemente, por ejemplo, a los proyectos de desarrollo
adicional de sistemas móviles de segunda generación, como la red
GERAN (GSM/Edge Radio Access Network).
Resulta evidente para cualquier persona versada
en la materia que a medida que avance la tecnología la idea básica
de la invención podría implementarse de muchas formas diferentes.
Por lo tanto, la invención y sus realizaciones no se limitan a los
ejemplos descritos anteriormente, sino que pueden variar dentro del
ámbito de las reivindicaciones.
Claims (14)
1. Método para definir la compresión de campos de
cabecera para una conexión de paquetes de datos en una capa de
protocolo de convergencia de un sistema de comunicaciones móviles,
incluyendo dicho método:
definir un contexto para unos módulos de
compresión y descompresión como uno de los parámetros de la conexión
para controlar el funcionamiento de dichos módulos de compresión y
descompresión,
definir una longitud para un identificador de
contexto utilizado para identificar las conexiones de paquetes de
datos en la transmisión de datos entre el módulo de compresión y el
módulo de descompresión, definiendo dicha longitud el número máximo
de conexiones de paquetes de datos comprimidos transmitido en una
conexión,
identificar cada conexión de paquetes de datos
mediante su propio identificador de contexto,
caracterizado por
señalizar el número máximo de conexiones
simultáneas de paquetes de datos, definido para cada soporte de
radio efectuadas a una entidad de un sistema de comunicaciones
móviles que al establecer una nueva conexión de paquetes de datos
decide a cual soporte de radio será asociada, y
gobernar el sistema de comunicaciones móviles en
respuesta a la superación del número de conexiones de paquetes de
datos permitido por el valor máximo de la longitud del identificador
de contexto, para definir un nuevo soporte de radio para las
conexiones de paquetes de datos extra.
2. Método para definir la compresión de campos de
cabecera para una conexión de paquetes de datos en una capa de
protocolo de convergencia de un sistema de comunicaciones móviles,
incluyendo dicho método
definir un contexto para unos módulos de
compresión y descompresión como uno de los parámetros de la conexión
para controlar el funcionamiento de dichos módulos de compresión y
descompresión,
definir una longitud para un identificador de
contexto utilizado para identificar las conexiones de paquetes de
datos durante la transmisión de datos entre el módulo de compresión
y el módulo de descompresión, definiendo dicha longitud el número
máximo de conexiones de paquetes de datos comprimidos transmitido en
una conexión,
identificar cada conexión de paquetes de datos
mediante su propio identificador de contexto, caracterizado
por
gobernar la capa de protocolo de convergencia o
el módulo de compresión de la misma, en respuesta a la superación
del número de conexiones de paquetes de datos permitido por el
valor máximo de la longitud del identificador de contexto, para
transmitir las conexiones de paquetes de datos extra sin compresión
de los campos de cabecera.
3. Método de acuerdo con cualquiera de las
reivindicaciones 1 ó 2, caracterizado por
reservar, al menos, un valor de la longitud del
identificador de contexto definido para un flujo de datos sin
comprimir.
4. Método de acuerdo con la reivindicación 2,
caracterizado por
incorporar en dichas conexiones de paquetes de
datos extras un identificador en función del cual, los paquetes de
datos se reciben sin descomprimir.
5. Método de acuerdo con cualquiera de las
reivindicaciones 1 a 4, caracterizado por
limitar mediante terminal del sistema de
comunicaciones móviles, el número de conexiones de paquetes de datos
simultáneas a un número inferior al número de conexiones de paquetes
de datos permitidas por el valor máximo de la longitud del
identificador de contexto.
6. Sistema de comunicaciones móviles que incluye
un sistema de compresión de campos de cabecera que comprende un
módulo de compresión y un módulo de descompresión, estando dispuesto
el sistema de compresión de campos de cabecera para
definir un contexto para la conexión de paquetes
de datos entre el módulo de compresión y el módulo de descompresión
como parámetro de la conexión, controlando el contexto el
funcionamiento de dichos módulos de compresión y descompresión e
incorporar un identificador de contexto para identificar las
conexiones de paquetes de datos,
definir una longitud para el identificador de
contexto para la transmisión de datos entre el módulo de compresión
y el módulo de descompresión, definiendo dicha longitud el número
máximo de conexiones de paquetes de datos comprimidos transmitido en
una conexión,
identificar cada conexión de paquetes de datos
mediante su propio identificador de contexto, caracterizado
porque
una capa de protocolo de convergencia del sistema
de comunicaciones móviles está dispuesta para señalizar a una
entidad de un sistema de comunicaciones móviles el número máximo de
conexiones simultáneas de paquetes de datos definido para cada
soporte de radio, cuya entidad decide a cual soporte de radio, será
asociada al establecer una nueva conexión de paquetes de datos,
y
dicha entidad está dispuesta para gobernar el
sistema de comunicaciones móviles, en respuesta a la superación del
número de conexiones de paquetes de datos permitido por el valor
máximo de la longitud del identificador de contexto, para definir un
nuevo soporte de radio para las conexiones de paquetes de datos
extra.
7. Sistema de comunicaciones móviles que incluye
un sistema de compresión de campos de cabecera que comprende un
módulo de compresión y un módulo de descompresión, estando dispuesto
el sistema de compresión de campos de cabecera para
definir un contexto para la conexión de paquetes
de datos entre el módulo de compresión y el módulo de descompresión
como parámetro de la conexión, controlando el contexto el
funcionamiento de dichos módulos de compresión y descompresión e
incorporar un identificador de contexto para identificar las
conexiones de paquetes de datos,
definir una longitud para el identificador de
contexto para la transmisión de datos entre el módulo de compresión
y el módulo de descompresión, definiendo dicha longitud el número
máximo de conexiones de paquetes de datos comprimidos transmitidos
en una conexión,
identificar cada conexión de paquetes de datos
mediante su propio identificador de contexto, caracterizado
porque
el sistema de comunicaciones móviles, está
dispuesto para gobernar una capa de protocolo de convergencia del
sistema de comunicaciones móviles o el módulo de compresión de la
misma, en respuesta a la superación del número de conexiones de
paquetes de datos permitido por el valor máximo de la longitud del
identificador de contexto, para transmitir las conexiones de
paquetes de datos extra sin compresión los campos de cabecera.
8. Sistema de acuerdo con cualquiera de las
reivindicaciones 6 ó 7, caracterizado porque
al menos un valor de la longitud del
identificador de contexto definido se reserva para un flujo de datos
sin comprimir.
9. Sistema de acuerdo con la reivindicación 7,
caracterizado porque
la capa de protocolo de convergencia del sistema
de comunicaciones móviles, o el módulo de compresión de la misma,
están configurados para incorporar a dichas conexiones de paquetes
de datos extra, un identificador a partir del cual los paquetes de
datos se reciben sin comprimir.
10. Sistema de acuerdo con cualquiera de las
reivindicaciones 6 a 9, caracterizado porque
un terminal del sistema de comunicaciones móviles
está dispuesto para limitar el número de conexiones simultáneas de
paquetes de datos a un número inferior al número de conexiones de
paquetes de datos permitidas por el máximo valor de la longitud del
identificador de contexto.
11. Elemento de red (RNC) para un sistema de
comunicaciones móviles que comprende un sistema de compresión de
campos de cabecera, incluyendo un módulo de compresión y un módulo
de descompresión, estando dispuesto el sistema de compresión del
campo de cabecera para
definir un contexto para la conexión de paquetes
de datos entre el módulo de compresión y el módulo de descompresión
como parámetro de la conexión, controlando el contexto el
funcionamiento de dichos módulos de compresión y descompresión e
incorporar un identificador de contexto para identificar las
conexiones de paquetes de datos,
definir una longitud para el identificador de
contexto para la transmisión de datos entre el módulo de compresión
y el módulo de descompresión, definiendo dicha longitud el número
máximo de conexiones de paquetes de datos comprimidos transmitido en
una conexión,
identificar cada conexión de paquetes de datos
mediante su propio identificador de contexto, caracterizado
porque
dicho elemento de red está dispuesto para recibir
una señal de una capa de protocolo de convergencia del sistema de
comunicaciones móviles, indicando dicha señal el número máximo de
conexiones simultáneas de paquetes de datos, definido para cada
soporte de radio, y
dicho elemento de red está dispuesto para
gobernar el sistema de comunicaciones móviles, en respuesta a la
superación del número de conexiones de paquetes de datos permitido
por el valor máximo de la longitud del identificador de contexto,
para definir un nuevo soporte de radio para las conexiones de
paquetes de datos extra.
12. Estación móvil para un sistema de
comunicaciones móviles que comprende un sistema de compresión de
campos de cabecera, incluyendo un módulo de compresión y un módulo
de descompresión, estando dispuesto el sistema de compresión del
campo de cabecera para
definir un contexto para la conexión de paquetes
de datos entre el módulo de compresión y el módulo de descompresión
como parámetro de la conexión, controlando el contexto el
funcionamiento de dichos módulos de compresión y descompresión e
incorporar un identificador de contexto para identificar las
conexiones de paquetes de datos,
definir una longitud para el identificador de
contexto para la transmisión de datos entre el módulo de compresión
y el módulo de descompresión, definiendo dicha longitud el número
máximo de conexiones de paquetes de datos comprimidos transmitidos
en una conexión,
identificar cada conexión de paquetes de datos
mediante su propio identificador de contexto, caracterizada
porque
dicha estación móvil está dispuesta para
señalizar a una entidad del sistema de comunicaciones móviles, en su
capa de protocolo de convergencia, el número máximo de conexiones
simultáneas de paquetes de datos definido para cada uno de sus
portadoras de radio, cuya entidad decide a cual soporte de radio se
asociará al establecer una nueva conexión de paquetes de datos,
y
dicha estación móvil está dispuesta para recibir
un comando desde dicha entidad, en respuesta a la superación del
número de conexiones de paquetes de datos permitido por el valor
máximo de la longitud del identificador de contexto para definir un
nuevo soporte de radio para las conexiones de paquetes de datos
extra.
13. Elemento de red (RNC) para un sistema de
comunicaciones móviles que comprende un sistema de compresión de
campos de cabecera, incluyendo un módulo de compresión y un módulo
de descompresión, estando dispuesto el sistema de compresión del
campo de cabecera para
definir un contexto para la conexión de paquetes
de datos entre el módulo de compresión y el módulo de descompresión
como parámetro de la conexión, controlando el contexto el
funcionamiento de dichos módulos de compresión y descompresión e
incorporar un identificador de contexto para identificar las
conexiones de paquetes de datos,
definir una longitud para el identificador de
contexto para la transmisión de datos entre el módulo de compresión
y el módulo de descompresión, definiendo dicha longitud el número
máximo de conexiones de paquetes de datos transmitidos en una
conexión,
identificar cada conexión de paquetes de datos
mediante su propio identificador de contexto, caracterizado
porque
dicho elemento de red está dispuesto para
gobernar una capa de protocolo de convergencia del sistema de
comunicaciones móviles o el módulo de compresión de la misma, en
respuesta a la superación del número de conexiones de paquetes de
datos permitido por el valor máximo de la longitud del identificador
de contexto, para transmitir las conexiones de paquetes de datos
extra sin compresión del campo de cabecera.
14. Estación móvil para un sistema de
comunicaciones móviles que comprende un sistema de compresión de
campos de cabecera, incluyendo un módulo de compresión y un módulo
de descompresión, estando dispuesto el sistema de compresión del
campo de cabecera para
definir un contexto para la conexión de paquetes
de datos entre el módulo de compresión y el módulo de descompresión
como parámetro de la conexión, controlando el contexto el
funcionamiento de dichos módulos de compresión y descompresión e
incorporar un identificador de contexto para identificar las
conexiones de paquetes de datos,
definir una longitud para el identificador de
contexto para la transmisión de datos entre el módulo de compresión
y el módulo de descompresión, definiendo dicha longitud el número
máximo de conexiones de paquetes de datos comprimidos transmitidos
en una conexión,
identificar cada conexión de paquetes de datos
mediante su propio identificador de contexto, caracterizada
porque
dicha estación móvil está dispuesta para recibir
un comando procedente de una entidad del sistema de comunicaciones
móviles que, al establecer una nueva conexión de paquetes de datos,
decide a cual soporte de radio se asociará para transmitir las
conexiones de paquetes de datos extra sin compresión del campo de
cabecera, en respuesta a la superación del número de conexiones de
paquetes de datos permitido por el valor máximo de la longitud del
identificador de contexto.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FI20002307A FI110739B (fi) | 2000-10-18 | 2000-10-18 | Otsikkokenttien kompressoinnin määrittäminen datapakettiyhteydelle |
FI20002307 | 2000-10-18 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2236319T3 true ES2236319T3 (es) | 2005-07-16 |
Family
ID=8559327
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES01978490T Expired - Lifetime ES2236319T3 (es) | 2000-10-18 | 2001-10-17 | Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos. |
Country Status (14)
Country | Link |
---|---|
US (1) | US7035287B2 (es) |
EP (1) | EP1329078B1 (es) |
JP (1) | JP3834001B2 (es) |
KR (1) | KR100610658B1 (es) |
CN (1) | CN100401729C (es) |
AT (1) | ATE287610T1 (es) |
AU (1) | AU2002210602A1 (es) |
BR (1) | BRPI0114670B1 (es) |
CA (1) | CA2425916C (es) |
DE (1) | DE60108514T2 (es) |
ES (1) | ES2236319T3 (es) |
FI (1) | FI110739B (es) |
WO (1) | WO2002033931A1 (es) |
ZA (1) | ZA200303033B (es) |
Families Citing this family (66)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6766376B2 (en) | 2000-09-12 | 2004-07-20 | Sn Acquisition, L.L.C | Streaming media buffering system |
JP3323483B2 (ja) * | 2000-09-12 | 2002-09-09 | 松下電器産業株式会社 | パケット送信装置およびパケット伝送方法 |
US7290063B2 (en) * | 2001-01-10 | 2007-10-30 | Nokia Corporation | Relocating context information in header compression |
KR100389819B1 (ko) * | 2001-07-09 | 2003-07-02 | 삼성전자주식회사 | 부호분할다중접속 이동통신시스템에서 패킷 데이터 전송방법 |
ATE502472T1 (de) * | 2001-11-24 | 2011-04-15 | Lg Electronics Inc | Verfahren zur übertragung von paketdaten in komprimierter form in einem kommunikationssystem |
IL149165A (en) * | 2002-04-15 | 2006-12-10 | Veraz Networks Ltd | Method and apparatus for efficient transmission of voip traffic |
WO2003096647A1 (en) * | 2002-05-08 | 2003-11-20 | Nokia Corporation | Dynamic allocation of a radio resource |
DE60304055T8 (de) * | 2002-06-12 | 2007-05-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Verfahren und Vorrichtung zur Initialisierung der Komprimierung von Paketköpfen des Internet-Protokolls |
US8619592B2 (en) * | 2002-06-12 | 2013-12-31 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for increased internet protocol (IP) headers compression performance by reporting cause of missing packets |
EP1372310A1 (en) * | 2002-06-12 | 2003-12-17 | Motorola, Inc. | Apparatus and method for communicating data using header compression |
KR100497357B1 (ko) * | 2002-06-26 | 2005-06-23 | 삼성전자주식회사 | 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법 |
JP4317403B2 (ja) * | 2002-08-09 | 2009-08-19 | パナソニック株式会社 | ヘッダ圧縮装置及びヘッダ圧縮方法 |
KR100884956B1 (ko) * | 2002-08-14 | 2009-02-23 | 엘지전자 주식회사 | 비대칭 양방향 패킷데이터 송수신 방법 및 시스템 |
US7324516B2 (en) * | 2002-08-14 | 2008-01-29 | Intel Corporation | Data packet header conversion |
KR100936586B1 (ko) * | 2002-09-19 | 2010-01-13 | 엘지전자 주식회사 | 멀티미디어 방송 및 멀티캐스트 서비스에서의 데이터 전송 방법 및 시스템 |
TWI250724B (en) * | 2002-10-11 | 2006-03-01 | Ericsson Telefon Ab L M | Method and communication system for packeting messaging, and header compressor unit |
US7286536B2 (en) * | 2002-10-28 | 2007-10-23 | Nokia Corporation | Method and system for early header compression |
DE10252535A1 (de) * | 2002-11-08 | 2004-05-27 | Philips Intellectual Property & Standards Gmbh | Vorrichtung und ein Verfahren zur Übertragung von Datenpaketen verschiedener Verbindungen an einen Empfänger |
US7272658B1 (en) | 2003-02-13 | 2007-09-18 | Adobe Systems Incorporated | Real-time priority-based media communication |
JP3838511B2 (ja) * | 2003-03-24 | 2006-10-25 | 株式会社Kddi研究所 | 動画像圧縮符号化送受信装置 |
US7317724B2 (en) * | 2003-07-08 | 2008-01-08 | Cisco Technology, Inc. | Performing compression of user datagram protocol packets |
US7234007B2 (en) * | 2003-09-15 | 2007-06-19 | Broadcom Corporation | Adjustable elasticity FIFO buffer have a number of storage cells equal to a frequency offset times a number of data units in a data stream |
US7512715B2 (en) * | 2003-09-26 | 2009-03-31 | Nokia Corporation | System and method for requesting a resource over at least one network with reduced overhead |
KR100602633B1 (ko) * | 2003-11-08 | 2006-07-19 | 삼성전자주식회사 | 패킷의 헤더를 압축하는 방법 및 그 장치 |
CN1311673C (zh) * | 2003-12-03 | 2007-04-18 | 华为技术有限公司 | 传送多协议标签交换协议数据单元的方法 |
US7430617B2 (en) * | 2003-12-19 | 2008-09-30 | Nokia Corporation | Method and system for header compression |
US7260400B2 (en) * | 2004-03-05 | 2007-08-21 | Samsung Electronics Co., Ltd. | Method and apparatus for transmitting and receiving control message in wireless access communication system |
CA2557535C (en) * | 2004-03-12 | 2012-05-15 | Samsung Electronics Co., Ltd. | Method and apparatus for constructing map ie using reduced cid in broadband ofdma systems |
FI20045258A0 (fi) * | 2004-06-30 | 2004-06-30 | Nokia Corp | Solukohtaisen tiedon hallinta |
FI20045256A0 (fi) * | 2004-06-30 | 2004-06-30 | Nokia Corp | Solukohteisen tiedon tukisolmuperusteinen hallinta |
US20060007925A1 (en) * | 2004-07-12 | 2006-01-12 | Wright Steven A | Methods, systems, and computer program products for compressing a multiprotocol label switching (MPLS) shim header in a packet |
US7924731B2 (en) * | 2004-11-15 | 2011-04-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for handling out-of-sequence packets in header decompression |
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 |
US20060139869A1 (en) * | 2004-12-29 | 2006-06-29 | Matusz Pawel O | Extended compression arrangements within telecommunication systems and associated methods |
KR100918435B1 (ko) * | 2005-01-31 | 2009-09-24 | 삼성전자주식회사 | 무선 통신 시스템에서 데이터 트래픽 제어 시스템 및 방법 |
US7609700B1 (en) * | 2005-03-11 | 2009-10-27 | At&T Mobility Ii Llc | QoS channels for multimedia services on a general purpose operating system platform using data cards |
US8804765B2 (en) * | 2005-06-21 | 2014-08-12 | Optis Wireless Technology, Llc | Dynamic robust header compression |
KR101228277B1 (ko) * | 2005-11-15 | 2013-01-30 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | 메시징에 관한 장치 및 방법 |
KR100901137B1 (ko) * | 2006-01-03 | 2009-06-04 | 삼성전자주식회사 | 다중 홉 릴레이 방식 무선 접속 통신시스템에서 연결식별자관리 방법 및 장치 |
US20080096557A1 (en) * | 2006-10-04 | 2008-04-24 | Nokia Corporation | Efficient and dynamic identification of allocations in a wireless packet communication system |
KR100938090B1 (ko) * | 2006-10-19 | 2010-01-21 | 삼성전자주식회사 | 이동통신 시스템에서 핸드오버 수행 방법 및 장치 |
KR100885812B1 (ko) * | 2006-12-07 | 2009-02-27 | 한국전자통신연구원 | 인터넷 프로토콜 기반의 이동통신 서비스 액세스게이트웨이 장치 및 이를 이용한 서비스 방법 |
US8358669B2 (en) * | 2007-05-01 | 2013-01-22 | Qualcomm Incorporated | Ciphering sequence number for an adjacent layer protocol in data packet communications |
US8331399B2 (en) * | 2007-05-07 | 2012-12-11 | Qualcomm Incorporated | Re-using sequence number by multiple protocols for wireless communication |
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 |
US7961878B2 (en) | 2007-10-15 | 2011-06-14 | Adobe Systems Incorporated | Imparting cryptographic information in network communications |
JP5018890B2 (ja) * | 2007-10-31 | 2012-09-05 | 富士通株式会社 | 通信方法並びに通信端末、データ転送装置及び制御装置 |
KR101476813B1 (ko) * | 2007-11-30 | 2014-12-29 | 삼성전자주식회사 | 패킷 중계 노드의 패킷 재조립 시스템 및 방법 |
US7953881B1 (en) * | 2008-06-12 | 2011-05-31 | Juniper Networks, Inc. | Network characteristic-based compression of network traffic |
US8867566B2 (en) * | 2008-08-20 | 2014-10-21 | Qualcomm Incorporated | Methods of header compression within a wireless communications network |
US20100260109A1 (en) * | 2009-04-10 | 2010-10-14 | Qualcomm Incorporated | Optimized inter-access point packet routing for ip relay nodes |
US9674311B2 (en) | 2009-08-14 | 2017-06-06 | Qualcomm Incorporated | Robust header compression for relay nodes |
US8787242B2 (en) * | 2009-11-06 | 2014-07-22 | Qualcomm Incorporated | Header compression for relay nodes |
CN102131234B (zh) * | 2010-01-18 | 2013-12-04 | 华为技术有限公司 | Ip数据包的压缩及解压缩方法和装置 |
EP2567524B1 (en) * | 2010-05-03 | 2019-06-26 | Nokia Technologies Oy | Protocol overhead reduction |
JP5734680B2 (ja) * | 2011-01-26 | 2015-06-17 | 京セラ株式会社 | 移動通信方法及び基地局 |
EP2536098A1 (en) * | 2011-06-16 | 2012-12-19 | Alcatel Lucent | Method and apparatuses for controlling encoding of a dataflow |
US9071927B2 (en) * | 2011-12-05 | 2015-06-30 | Verizon Patent And Licensing Inc. | Collapsed mobile architecture |
JP2015156524A (ja) * | 2014-02-19 | 2015-08-27 | 株式会社Nttドコモ | 通信装置、及びコンテクスト制御方法 |
WO2018070465A1 (ja) * | 2016-10-14 | 2018-04-19 | 株式会社Nttドコモ | 無線通信装置 |
US10299162B2 (en) | 2017-01-16 | 2019-05-21 | Qualcomm Incorporated | Robust header compression (RoHC) techniques for a dynamically changing extension bit |
US10432761B2 (en) * | 2017-01-18 | 2019-10-01 | Qualcomm Incorporated | Techniques for handling internet protocol flows in a layer 2 architecture of a wireless device |
CN111277556B (zh) * | 2019-01-30 | 2023-04-07 | 维沃移动通信有限公司 | 处理方法及通信设备 |
CN114128241A (zh) * | 2019-03-27 | 2022-03-01 | 苹果公司 | 以太网标头压缩 |
US11778509B2 (en) * | 2020-04-02 | 2023-10-03 | Qualcomm Incorporated | Ethernet header compression for data sent over non-access stratum (NAS) control plane |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6859442B1 (en) * | 1997-10-20 | 2005-02-22 | Comsat Corporation | Method and system for transport of frame relay traffic over satellite/wireless networks |
FI107000B (fi) | 1999-02-17 | 2001-05-15 | Nokia Mobile Phones Ltd | Otsikon pakkaaminen reaaliaikaisissa palveluissa |
US6366961B1 (en) | 1999-03-03 | 2002-04-02 | Nokia Telecommunications, Oy | Method and apparatus for providing mini packet switching in IP based cellular access networks |
US6754231B1 (en) * | 1999-06-18 | 2004-06-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Robust header compression in packet communications |
EP1601157B1 (en) | 1999-08-06 | 2020-01-15 | Godo Kaisha IP Bridge 1 | Data transmission and reception apparatus and method |
US6700888B1 (en) * | 1999-09-28 | 2004-03-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Manipulating header fields for improved performance in packet communications |
US6791982B2 (en) * | 1999-09-29 | 2004-09-14 | Telefonaktiebolaget Lm Ericsson | Segmentation protocol that supports compressed segmentation headers |
US6839339B1 (en) * | 2000-02-02 | 2005-01-04 | Lucent Technologies Inc. | Header compression for general packet radio service tunneling protocol (GTP)-encapsulated packets |
US6999429B1 (en) | 2000-03-03 | 2006-02-14 | Telefonaktiebolaget Lm Ericsson | Access technology integrated header compression |
-
2000
- 2000-10-18 FI FI20002307A patent/FI110739B/fi not_active IP Right Cessation
-
2001
- 2001-10-16 US US09/978,479 patent/US7035287B2/en not_active Expired - Lifetime
- 2001-10-17 WO PCT/FI2001/000902 patent/WO2002033931A1/en not_active Application Discontinuation
- 2001-10-17 ES ES01978490T patent/ES2236319T3/es not_active Expired - Lifetime
- 2001-10-17 DE DE60108514T patent/DE60108514T2/de not_active Expired - Lifetime
- 2001-10-17 KR KR1020037005318A patent/KR100610658B1/ko active IP Right Grant
- 2001-10-17 JP JP2002536806A patent/JP3834001B2/ja not_active Expired - Lifetime
- 2001-10-17 CA CA002425916A patent/CA2425916C/en not_active Expired - Lifetime
- 2001-10-17 AU AU2002210602A patent/AU2002210602A1/en not_active Abandoned
- 2001-10-17 EP EP01978490A patent/EP1329078B1/en not_active Expired - Lifetime
- 2001-10-17 AT AT01978490T patent/ATE287610T1/de not_active IP Right Cessation
- 2001-10-17 BR BRPI0114670A patent/BRPI0114670B1/pt active IP Right Grant
- 2001-10-17 CN CNB018176003A patent/CN100401729C/zh not_active Expired - Lifetime
-
2003
- 2003-04-17 ZA ZA200303033A patent/ZA200303033B/en unknown
Also Published As
Publication number | Publication date |
---|---|
CN100401729C (zh) | 2008-07-09 |
DE60108514D1 (de) | 2005-02-24 |
FI110739B (fi) | 2003-03-14 |
ATE287610T1 (de) | 2005-02-15 |
US20020097723A1 (en) | 2002-07-25 |
DE60108514T2 (de) | 2006-02-09 |
CN1554175A (zh) | 2004-12-08 |
AU2002210602A1 (en) | 2002-04-29 |
EP1329078A1 (en) | 2003-07-23 |
CA2425916C (en) | 2007-09-25 |
JP2004512743A (ja) | 2004-04-22 |
KR100610658B1 (ko) | 2006-08-09 |
BRPI0114670B1 (pt) | 2016-09-06 |
US7035287B2 (en) | 2006-04-25 |
ZA200303033B (en) | 2003-10-08 |
BR0114670A (pt) | 2003-10-07 |
JP3834001B2 (ja) | 2006-10-18 |
CA2425916A1 (en) | 2002-04-25 |
WO2002033931A1 (en) | 2002-04-25 |
EP1329078B1 (en) | 2005-01-19 |
FI20002307A0 (fi) | 2000-10-18 |
KR20030036936A (ko) | 2003-05-09 |
FI20002307A (fi) | 2002-04-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2236319T3 (es) | Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos. | |
ES2272691T3 (es) | Reubicacion de la informacion de contexto en la compresion de encabezamientos. | |
ES2286660T3 (es) | Sistema distribuido de gestion de calidad de servicio. | |
ES2218389T3 (es) | Numeracion de paquetes de datos en una transmision de datos por conmutacion de paquetes. | |
ES2218388T3 (es) | Numeracion de paquetes de datos en una transmision de datos por conmutacion de paquetes. | |
ES2442871T3 (es) | Transmisión de unidades de datos de protocolo a través del control de enlace de radiocomunicaciones transparente | |
US7460475B2 (en) | Allocating data transmission resources in packet-switched data transmission | |
US7301947B2 (en) | Transmission of compression identifier of headers on data packet connection | |
ES2232159T3 (es) | Control de calidad de servicio en un sistema de comunicaciones moviles. | |
ES2292616T3 (es) | Definicion de un identificador de contexto en la compresion de campos de encabezamientos. | |
US20040042491A1 (en) | Synchronization of data packet numbers in packet-switched data transmission | |
ES2277849T3 (es) | Un metodo de control del contexto de compresion de encabezado durante una transferencia en redes moviles de comunicacion de datos. | |
FI111210B (fi) | Datapakettinumeroiden synkronointi pakettivälitteisessä tiedonsiirrossa | |
WO2001061959A2 (en) | Method and system for communicating data between a mobile and packet switching communications architecture | |
ES2335571T3 (es) | Procedimiento para la transmision de paquetes de datos. |