[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

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
Application number
ES01978490T
Other languages
English (en)
Inventor
Ari Tourunen
Juha Kalliokulju
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Inc
Original Assignee
Nokia Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Inc filed Critical Nokia Inc
Application granted granted Critical
Publication of ES2236319T3 publication Critical patent/ES2236319T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing 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.
Antecedentes de la invención
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.
Breve descripción de la invención
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.
Breve descripción de las figuras
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.
Descripción detallada 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.
ES01978490T 2000-10-18 2001-10-17 Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos. Expired - Lifetime ES2236319T3 (es)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

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.