ES2202041T3 - Transporte de informacion de correspondencia qos en una red de radiocomunicaciones por paquetes. - Google Patents

Abstract

Método para enviar paquetes de datos (DP) desde un primer subsistema (11, 12) de comunicaciones a través de un primer elemento (GGSN) de red hacia un segundo elemento (MS) de red en un segundo subsistema (13) de comunicaciones; comprendiendo dicho método las etapas siguientes: envío de los paquetes de datos (DP) en una primera pluralidad de flujos de datos en dicho primer subsistema (11, 12) de comunicaciones; establecimiento de una correspondencia de dicha primera pluralidad de flujos de datos con una segunda pluralidad de flujos de datos en dicho segundo subsistema (13) de comunicaciones; caracterizado por: establecer por lo menos un filtro (FI) para controlar dicho establecimiento de una correspondencia; asociar dicho por lo menos un filtro (FI) a un flujo de datos dentro de dicha segunda pluralidad; establecer una correspondencia de por lo menos un flujo de datos basándose en dicho filtro (FI); y configurar dicho filtro (FI) a partir de dicho segundo elemento (MS) de red.

Description

Transporte de información de correspodencia QoS en una red de radiocomunicaciones por paquetes.

Antecedentes de la invención

La presente invención se refiere a métodos y a un equipo para establecer una correspondenciade paquetes de datos de una primera pluralidad de flujos de datos en un primer subsistema de comunicaciones con una segunda pluralidad de flujos de datos en un segundo subsistema de comunicaciones. Más específicamente, la invención se refiere a un método según el preámbulo de la reivindicación 1, a un elemento de red según el preámbulo de la reivindicación 17, a una señal de configuración digital generada en una estación móvil según el preámbulo de la reivindicación 18 y a una estación móvil según el preámbulo de la reivindicación 19. Por ejemplo, en los documentos WO 99/16266, WO 99/05828, GB A 2312592, EP 0774848, WO 97/36405 y WO 98/28938 se da a conocer un procesado de paquetes de datos.

Para sistemas de fase 2 GPRS (Servicio General de Radiocomunicaciones por Paquetes) y UMTS (Sistema de Telecomunicaciones Móviles Universales) se requiere un soporte de QoS más exhaustivo. Con esta finalidad, en los elementos límites de la red, por ejemplo, en una Estación Móvil (MS) y un GGSN (Nodo de Soporte de la Pasarela GPRS), se debe mantener información relacionada con la QoS.

Actualmente no es posible transformar la información requerida para realizar funciones de correspondencia y de traducción de QoS entre los mecanismos QoS de redes externas y mecanismos QoS específicos de la red móvil. Esto significa que los nodos límites de la red móvil pueden llevar a cabo solamente una traducción QoS muy estática. Para proporcionar diferentes valores de QoS para diferentes aplicaciones (tales como multimedia en tiempo real o en tiempo no real, transmisión de archivos, transferencia de correos electrónicos, de fondo, etcétera) se necesitan medios para mantener información consistente en la estación móvil y los nodos GGSN.

Para redes GPRS/UMTS no se conocen soluciones para este problema. Para internet, existen mecanismos disponibles que se pueden utilizar para transportar información de QoS ó específica del flujo. No obstante, esta información es interpretada por cada nodo a lo largo del camino de transmisión de extremo a extremo y no solamente por los puntos extremos (la MS y el GGSN).

Descripción de la invención

Un objetivo de la invención es proporcionar un mecanismo para permitir un suministro QoS más dinámico para aplicaciones individuales. Este objetivo se consigue con un método y un equipo que están caracterizados por los aspectos que se dan a conocer en las reivindicaciones independientes adjuntas. En las reivindicaciones dependientes adjuntas se dan a conocer formas de realización preferidas de la invención.

La invención se basa en una previsión de que entre los límites de red GPRS/UMTS se debe transferir información de correspondencia QoS. En otras palabras, la invención proporciona un mecanismo para establecer una correspondencia de múltiples flujos IP (FlujoIP1, ... FlujoIPn) de enlace descendente (con terminación en estaciones móviles) con diferentes necesidades QoS con flujos GPRS (o UMTS...). Estos últimos flujos se definen por medio de contextos PDP (Protocolo de Datos por Paquetes) o perfiles QoS (QoSp1 ... QoSm) dentro de un perfil que satisface las necesidades. La idea básica de la invención es que para al menos algunos flujos de datos (tales como aplicaciones en tiempo real), la correspondencia que se realiza en el nodo límite (por ejemplo, el GGSN) se basa en un filtro que es configurable (por selección o modificación) desde un usuario/terminal. Dicho filtro se puede implementar como un conjunto de parámetros y/o condiciones predeterminados que se utilizan para identificar paquetes o flujos de datos. Un filtro para una estación móvil debería comprender por lo menos la dirección IP de la estación móvil en cuestión. La dirección IP de la estación móvil se conoce a partir del registro de contexto PDP, y no es necesario transmitirla en la especificación del filtro entre la MS y el GGSN. (Son excepcionales aquellos casos en los que una estación móvil puede tener más de una dirección IP). Adicionalmente, el filtro puede comprender cualquier dato que se pueda utilizar para identificar paquetes de datos que requieran una cierta QoS, y que por lo tanto se deberían multiplexar en ciertos contextos PDP, tales como una Dirección de Origen, un Identificador de Flujo RSVP, un Número de Puerto (por ejemplo, el número de puerto TCP o UDP utilizado), un Protocolo de capa superior (por ejemplo, UDP, RTP, etcétera), un Tipo de Servicio (lPv4), un Tipo de Conexión (lPv6) y/o un campo de Clase de Tráfico (lPv6). El filtro puede comprender también el Espacio de Direcciones IP para proporcionar una QoS mayor a paquetes provenientes de una red empresarial (por ejemplo, una intranet) que para paquetes de la internet usual.

El filtro según la invención se utiliza para definir las características de los flujos IP de los que se va a establecer una correspondencia con el flujo GPRS o UMTS en cuestión. El terminal puede controlar el filtro identificando los parámetros del filtro en un elemento de información que se puede incluir, por ejemplo, en un mensaje de activación de contexto PDP o de modificación de contexto PDP. El filtro también se puede definir/redefinir en relación con la activación o modificación del perfil QoS.

Según una forma de realización preferida de la invención, se define una clase QoS por defecto. Con los flujos de datos que no se ajustan a ningún filtro definido se establece una correspondencia con esta clase QoS por defecto.

El problema resuelto por la invención es pertinente en la fase 2 del GPRS y su futura evolución, por ejemplo el UMTS.

Según una forma de realización, la información de QoS para el perfil/contexto se incluye en el elemento de información del Perfil QoS como en la fase 1 del GPRS. La información de correspondencia y filtrado se puede transferir en el elemento de información "opciones de configuración de protocolo", opciones específicas del fabricante, o en un elemento nuevo de información introducido y dedicado a este fin. Esta información puede incluir direcciones IP de origen y/o destino, números de puertos TCP y UDP utilizados, información de protocolo de capa superior, posiblemente un Índice de Parámetros Seguros (si se utiliza IPSEC), parámetros de servicios diferenciados, y especificaciones de filtros RSVP y flujos, o algún otro identificador o parámetros en los paquetes.

Para cada Dirección PDP se puede solicitar un perfil diferente de calidad de servicio (QoS). Por ejemplo, algunas direcciones PDP pueden estar asociadas a correo electrónico que puede tolerar tiempos de respuesta largos. Otras aplicaciones, tales como aplicaciones interactivas, no pueden tolerar un retardo, y demandan un nivel de rendimiento muy alto. Dichos requisitos diferentes se reflejan en el perfil QoS. Si un requisito de QoS va mas allá de las capacidades de una PLMN (Red Móvil Terrestre Pública), la PLMN negocia el perfil QoS de manera que sea lo más próximo posible al perfil QoS solicitado. La MS bien acepta el perfil QoS negociado o bien desactiva el contexto PDP.

Una ventaja de la invención es que no es necesario que los elementos de red (tales como los nodos SGSN y el Subsistema de Estaciones Base) de una red de radiocomunicaciones por paquetes interpreten todos los mecanismos QoS de las redes externas (IP, X.25, etcétera). En su lugar, el establecimiento de la correspondencia se puede configurar en el extremo de la estación móvil, y esta configuración se transporta al otro nodo límite (es decir, el GGSN) de la red de radiocomunicaciones por paquetes. De este modo, no es necesario actualizar toda la red de radiocomunicaciones por paquetes para soportar todos los mecanismos QoS nuevos.

El mecanismo según la invención es muy genérico. En otras palabras, es aplicable a una amplia variedad de situaciones y configuraciones. Permite un acceso, una configuración y un uso flexibles de la información del filtro en la base de datos del GGSN. El uso del filtro según la invención es completamente específico según el caso y el operador. El abonado de la MS está provisto de medios para indicar al nodo de pasarela en el límite de la red móvil/fija cómo se deberían tratar las diferentes aplicaciones, conexiones, flujos, u otros atributos y qué QoS se debería utilizar dentro de la red GPRS/UMTS para transportar los paquetes asociados. Preferentemente, el GGSN también debería mantener información específica de la aplicación/QoS/flujo.

Todavía otra ventaja es que la especificación del flujo/QoS transferida según la invención (es decir, en el procedimiento de establecimiento del perfil QoS o en la activación del contexto PDP o un mensaje dedicado) es muy flexible. Puede incluir direcciones IP de origen y destino, números de puertos TCP y UDP utilizados, información de protocolo de capa superior, posiblemente un Índice de Parámetros Seguros en el caso de que se utilice IPSEC, parámetros de servicios diferenciados, y especificaciones de filtros RSVP y flujos, todos ellos utilizados para identificar aplicaciones, usos y flujos externos de los que se debería establecer una correspondencia con clases o contextos QoS internos específicos. Una ventaja de la flexibilidad es que una aplicación nueva no requiere necesariamente un flujo nuevo en la red de radiocomunicaciones por paquetes. En su lugar, la invención permite una reutilización flexible de flujos existentes de una manera eficaz.

Como alternativa, la información se puede configurar de una manera más estática, en cuyo caso no es posible ningún cambio dinámico de atributos. En este caso el operador configura condiciones estáticas y la traducción de un QoS externo en un QoS interno, por ejemplo, sobre la base de los números de puertos TCP/UDP utilizados. Todavía otra opción consiste en no proporcionar en absoluto ninguna función de correspondencia QoS y ninguna QoS de extremo a extremo.

Breve descripción de los dibujos

A continuación se describirá la invención más detalladamente por medio de formas de realización preferidas haciendo referencia a los dibujos adjuntos en los cuales:

la Figura 1 muestra la arquitectura de una red GPRS conocida;

la Figura 2 muestra un plano de transmisión GPRS conocido;

la Figura 3 muestra el interfuncionamiento entre diferentes elementos de red;

la Figura 4 muestra un GGSN que comprende el filtro según la invención;

la Figura 5 muestra el uso del filtro según la invención;

las Figs. 6 y 7 muestran, respectivamente, el transporte de información de filtro en un procedimiento de activación o de modificación de contexto; y

\newpage

las Figs. 8 y 9 muestran dos implementaciones diferentes para configurar la información de filtro en mensajes dedicados.

Descripción detallada de la invención

Tal como se muestra en las Figuras 1 y 2, la presente invención se puede aplicar a cualquier sistema de comunicaciones móviles que disponga de una capacidad de transmisión de datos por paquetes.

Debería entenderse que la expresión "protocolo de datos por paquetes" (PDP) o "contexto PDP" tal como se utilizan en el presente documento se refieren en general a cualquier estado en una estación móvil y en por lo menos un elemento de red o funcionalidad, proporcionando dicho estado un camino de transmisión de paquetes de datos o un túnel con un conjunto específico de parámetros a través de la red de comunicaciones móviles. Debería entenderse que el término "nodo" tal como se utiliza en el presente documento se refiere en general a cualquier elemento de red o funcionalidad que manipula los paquetes de datos transferidos a través del canal PDP.

De forma preferente la invención se puede utilizar especialmente para proporcionar un servicio general de radiocomunicaciones por paquetes GPRS en el sistema paneuropeo de comunicaciones móviles digitales GSM o en los sistemas de comunicaciones móviles correspondientes, tales como el DCS1800 (conocido también como GSM1800) y el PCS (Sistema de Comunicación Personal). A continuación, se describirán formas de realización preferidas de la invención por medio de una red de radiocomunicaciones por paquetes GPRS formada por el servicio GPRS y el sistema GSM sin limitar la invención a este sistema específico de radiocomunicaciones por paquetes.

La invención se puede aplicar igualmente a redes móviles de tercera generación, tales como el UMTS. En este caso, la interfaz de radiocomunicaciones GSM se puede sustituir por una interfaz de radiocomunicaciones UMTS, tal como se muestra en la Figura 2.

La Figura 3 ilustra el interfuncionamiento entre diferentes elementos de red. Después de estas modificaciones, se puede proporcionar una correspondencia a nivel de parámetros entre servicios diferenciados y RSVP en internet y en el GPRS, por ejemplo, de la manera siguiente:

Se establece una correspondencia de la información de prioridad en internet con la precedencia de servicio en el GPRS. Se establece una correspondencia de una indicación referente a requisitos de tiempo real con respecto a tiempo no real en internet con una clase de retardo y/o información de fiabilidad en el GPRS: se necesitan por lo menos dos tipos de retardo, aunque también es posible establecer una correspondencia de tipos de tráfico con varias clases de retardo de una forma más precisa.

La información de fiabilidad se puede utilizar para indicar los requisitos de fiabilidad de cada aplicación en forma de una de entre por lo menos dos clases de fiabilidad. Si es necesaria una transmisión fiable (retransmisiones, sumas de comprobación y/ó TCP), el perfil asociado a los paquetes de datos indica la clase de fiabilidad 1. Si es necesaria una distribución fiable a través de la interfaz de radiocomunicaciones, aunque el UDP en el eje dorsal del GPRS sea suficiente, el perfil asociado a los paquetes de datos indica la clase de fiabilidad 2. Dependiendo de los requisitos, el perfil asociado a los paquetes de datos puede indicar como alternativa la clase de fiabilidad 3, 4 ó 5. Las clases de fiabilidad 4 y 5 se utilizan para tráfico en tiempo real.

Otra característica opcional de la presente invención es un establecimiento de una correspondencia de los parámetros QoS utilizados en la red de comunicaciones móviles con los correspondientes utilizados en una aplicación de usuario en el terminal móvil de datos por paquetes o los correspondientes utilizados en el sistema de comunicaciones externas, y viceversa. La MS, conociendo los requisitos de las aplicaciones, determina los valores del perfil QoS correspondiente, establece un nuevo contexto PDP para estos paquetes e indica al GGSN cómo reconocer paquetes pertenecientes a este contexto. A continuación, se proporcionarán dos ejemplos del establecimiento de la correspondencia.

Ejemplo 1

Proporcionado como ejemplo sobre cómo la MS puede decidir qué valores de los parámetros del GPRS escoge para el contexto.

El Acceso Sencillo a Medios Integrados (SIMA) es un nuevo enfoque sencillo presentado como un Borrador de Internet por K. Kilkki, Nokia Research Center, Junio de 1997. Los Borradores de Internet son documentos de trabajo del Grupo Especial sobre Ingeniería de Internet (IETF), sus áreas, y grupos de trabajo. El SIMA se utiliza como ejemplo de un esquema de QoS de internet ya que es capaz de proporcionar un concepto de servicio uniforme para diferentes necesidades desde aplicaciones de transferencia de archivos utilizando un protocolo TCP/IP con requisitos flexibles de retardo y de pérdida de paquetes hasta aplicaciones en tiempo real con requisitos de calidad y disponibilidad muy estrictos. Según el concepto del SIMA, cada usuario define únicamente dos términos antes de establecer la conexión: una velocidad binaria nominal (NBR) y una selección entre clases de servicio en tiempo real y en tiempo no real. La NBR puede tener ocho valores de 0 a 7. El establecimiento de la correspondencia del SIMA con el GPRS y viceversa se puede producir, por ejemplo, de la siguiente manera:

Bit de tiempo real/tiempo no real: si este bit indica requisitos de tiempo real, se establece una correspondencia con la clase de retardo 1 del GPRS, de otro modo se establece una correspondencia con la clase de retardo 4. No obstante, la clase de retardo 3 se puede utilizar para servicios en tiempo no real en el caso de que haya una manera especial de indicar el tráfico con el mejor esfuerzo, por ejemplo, no es necesario que este bit esté presente siempre, o se utiliza una definición más precisa para diferenciar el tráfico en tiempo real, en tiempo no real, y con el mejor esfuerzo. Al tráfico en tiempo real se le puede asignar un valor de clase de fiabilidad menor que al tráfico en tiempo no real en el GPRS. Generalmente, las clases de fiabilidad 1, 2, y 3 se utilizan habitualmente para el tráfico en tiempo no real y las clases 3, 4 y 5 para el tráfico en tiempo real en el GPRS. Para el tráfico en tiempo no real, cuanto mayor sea la NBR, menor será el valor de la clase de fiabilidad adecuado para la transmisión.

Valores de NBR	Valor de precedencia de servicio GPRS
6 y 7	1
3, 4 y 5	2
0, 1 y 2	3

Para los parámetros se pueden escoger también nombres diferentes, tales como prioridad o Velocidad Binaria Nominal y tipo de tráfico. El perfil QoS puede incluir todos los parámetros existentes (precedencia de servicio, clase de fiabilidad, clase de retardo, velocidad binaria media y velocidad binaria de pico). Como alternativa, podría incluir únicamente algunos de los parámetros, tales como las velocidades binarias media y de pico. El perfil QoS podría incluir también un parámetro de tamaño máximo de la ráfaga para simplificar el procedimiento de asignación de memoria intermedia.

La planificación QoS en los elementos de red del GPRS (por ejemplo, en un SGSN y un GGSN) se basa en la clase de retardo. Puede que esto requiera por lo menos dos memorias intermedias: una para paquetes en tiempo real (¡esta memoria intermedia debería ser mucho menor!) y otra para paquetes en tiempo no real. El tráfico en tiempo real se debería enviar siempre antes que el tráfico en tiempo no real. La precedencia de servicio define el orden en el que se sueltan los paquetes en el caso de congestión de la red.

Ejemplo 2

Describe cómo escoger valores QoS y establecer un perfil especial para soportarun punto de código de servicios diferenciados determinado, para proporcionar valores adecuados del perfil QoS y un valor del punto de código de servicios diferenciados como información de filtro para configurar el filtro.

Establecimiento de una correspondencia de un octeto Tipo de Servicio (ToS) en los encabezamientos de las unidades PDU (Unidades de Datos por Paquetes) IP con atributos del GPRS. El octeto ToS en un encabezamiento IP no se utiliza mucho actualmente. Su finalidad original era incluir información del tipo de tráfico y especificar qué clase de servicio se requiere desde la distribución del paquete. Como hoy en día el octeto ToS no se utiliza habitualmente, es posible redefinir los bits en dicho octeto de cara a los objetivos de la presente invención. En RFC 791 se proporciona una definición del octeto ToS. Los bits 0 a 2 del ToS proporcionan la preferencia, los bits 3 a 5 proporcionan el ToS requerido por el paquete (por ejemplo, los niveles de retardo, rendimiento y fiabilidad solicitados), y los bits 6 a 7 se reservan para el uso futuro. RFC 1349 amplía el campo ToS en un bit (tomado de los bits "reservados para el futuro"). De este modo, para indicar un ToS se pueden utilizar 4 bits.

El establecimiento de la correspondencia entre los bits de precedencia (0 a 2 en ToS) y la precedencia de servicio del GPRS puede producirse de la manera siguiente:

valores de bits (0 a 2)	valor de precedencia de servicio
111 y 110	001 (prioridad más alta)
101, 100 y 011	010 (prioridad normal)
010, 001 y 000	011 (prioridad más baja)

Existen tres formas diferentes de establecer la correspondencia entre la información de tipo de tráfico (es decir, el campo ToS en el octeto ToS) y la clase de retardo del GPRS:

Si para indicar los requisitos de retardo en el encabezamiento IP se utiliza únicamente el bit 3 en el campo ToS: se establece una correspondencia del valor 0 del bit 2 con la clase de retardo 1 ó 2 del GPRS y se establece una correspondencia del valor 1 del bit 2 con la clase de retardo 4 del GPRS (mejor esfuerzo).

Si para indicar los requisitos de retardo se utiliza todo el campo ToS en el ToS, es decir, hay disponibles 4 bits (bits 3 a 6) para esa finalidad, un establecimiento posible de la correspondencia podría ser: se hace que el valor de los bits 1000 se corresponda con la clase de retardo 1 del GPRS (es decir, con el valor de bits 000), el valor de bits 01000 con la clase de retardo 2 del GPRS (es decir, con el valor 001), los valores 0010 y 0001 del ToS con la clase de retardo 3 del GPRS (es decir, con el valor 010), y el valor 0000 del ToS con la clase de retardo 4 del GPRS (es decir, con el valor 011).

Otra forma de establecer una correspondencia de los bits del ToS de la IP con las clases de retardo del GPRS sería: 11x con la clase de retardo 1, 10x con la clase de retardo 2, 01x con la clase de retardo 3, y 00x con la clase de retardo 4. En este caso, x significa que podría haber uno o más bits adicionales utilizados para el ToS, pero no tienen ningún efecto sobre el proceso de selección de la clase de retardo del GPRS. Si posteriormente se definen más clases de retardo para el GPRS, el establecimiento de la correspondencia también podría tener en cuenta dichos bits adicionales.

Actualmente también existe un bit en el campo ToS de la IP que especifica el nivel de fiabilidad deseado. Si este bit está todavía disponible en el futuro, por ejemplo, si se escoge la primera opción anterior, este bit podría portar información de fiabilidad y se podría establecer una correspondencia del mismo con la clase de fiabilidad del GPRS de la siguiente manera: se hace que un valor 0 en el bit 5 dentro del octeto ToS se corresponda con la clase de fiabilidad 000 (clase de fiabilidad suscrita) y se hace que un valor 1 se corresponda con la clase de fiabilidad 001 (que define el servicio más fiable). No obstante, el uso de dicho bit puede ser demasiado impreciso ya que el GPRS define también muchos otros niveles de fiabilidad y estos no se pueden expresar utilizando solamente un bit.

Según una forma de realización preferida de la invención, se define una clase QoS por defecto, y se establece una correspondencia de los flujos de datos que no se ajustan a ninguno de los criterios de correspondencia definidos por el(los) filtro(s) con la clase QoS por defecto.

La correspondencia descrita anteriormente en el Ejemplo 2 se puede aplicar de forma bastante similar en el IPv6. En este caso el nombre del campo adecuado es Clase de Tráfico en lugar de ToS.

La Figura 3 ilustra el funcionamiento de una estación móvil GPRS y elementos de red GPRS, así como la integración con conceptos QoS de redes externas. La MS o el software en el equipo terminal TE (por ejemplo, en un ordenador portátil) proporciona la correspondencia de requisitos QoS de redes externas con mecanismos QoS del GPRS. Por ejemplo, el TE podría proporcionar funciones de gestión QoS a través de una Interfaz de Programa de Aplicación (API). El software de nivel de aplicación puede insertar información QoS o una etiqueta de perfil en los paquetes de datos, por ejemplo, dentro del propio encabezamiento IP, o puede indicar el flujo correcto al que pertenece el paquete utilizando algún otro medio adecuado. También puede utilizar el RSVP para transportar la información necesaria a través de capas de correspondencia adecuadas hacia capas inferiores. Como alternativa, el software de la MS puede decidir el perfil QoS sobre la base de, por ejemplo, las direcciones IP de origen y de destino utilizadas, o los números de puerto de origen y de destino, o alguna otra información configurada para la MS.

Para datos Originados en el Móvil (MO), la MS planifica los paquetes de datos basándose en la información QoS recibida desde la aplicación o desde la sucesión de protocolos GPRS en el Equipo Terminal. La MS planifica los paquetes MO según su clase de retardo. En la capa SNDC, la MS selecciona el SAP (Punto de Acceso al Servicio) LLC adecuado indicado por el SGSN durante la activación o la modificación del contexto PDP.

La Figura 4 ilustra un GGSN que comprende el filtro según la invención. El GGSN recibe paquetes de datos que terminan en la MS desde múltiples fuentes, a las que se hace referencia en conjunto como Proveedores de Servicios SP. La Figura 4 muestra tres proveedores de servicios típicos: un Proveedor de Servicios de Internet ISP para proporcionar acceso a internet; un Servidor de Red de Empresa CNS para proporcionar acceso a áreas cerradas de internet, denominadas comúnmente intranets y extranets; y Proveedores de Contenido CP para proporcionar acceso a varios servicios recreativos y de noticias, tales como vídeo bajo demanda, etcétera.

El GGSN comprende un planificador/traductor ST. Tal como su nombre implica, planifica la transmisión de paquetes basándose en la carga de la red, la prioridad de los paquetes, el tiempo de llegada, etcétera. La parte de planificación del ST es ampliamente conocida para el lector experto.

La parte de traducción del ST hace uso del filtro FI según la invención. Establece una correspondencia de paquetes de datos de las redes IP (elementos 11 y 12 en la Figura 1) con la red de radiocomunicaciones por paquetes (elemento 13 en la Figura 1). La invención proporciona una solución para una situación en la que varias aplicaciones y flujos de datos comparten una dirección IP común aunque requieren valores QoS diferentes.

La Figura 5 ilustra el uso del filtro FI según la invención en el GGSN. En la etapa 5-1 el GGSN recibe un paquete de datos dirigido a una estación móvil MS determinada. El GGSN lee la dirección IP de la MS del encabezamiento correspondiente del protocolo y utiliza el filtro FI para determinar el contexto PDP o el perfil QoS correspondiente. La IMSI de la MS se puede determinar a partir de la dirección IP de destino de los paquetes En la etapa 5- 2, el GGSN obtiene el Identificador de Túnel TID correspondiente. A continuación, en la etapa 5-3, el GGSN envía el paquete de datos a través del SGSN hacia la MS a través de ese contexto específico que está asociado a una QoS adecuada para este paquete.

La Figura 6 muestra cómo una estación móvil puede configurar las acciones de establecimiento de correspondencia y de interfuncionamiento QoS por medio de un procedimiento de activación del contexto según la invención. En la etapa 6-1, la MS envía hacia el SGSN una Solicitud de Activación de Contexto PDP que comprende una NSAPI, un tipo de PDP, una dirección PDP, un Nombre de Punto de Acceso, la QoS Solicitada, una Especificación de Filtro y opciones de configuración del PDP. (Para entender la presente invención, los parámetros importantes son el Filtro y la información QoS). La MS puede utilizar la Dirección PDP para indicar si requiere el uso de una dirección PDP estática o dinámica. En este último caso, la MS dejará vacía la dirección PDP. La MS puede utilizar el Nombre de Punto de Acceso para seleccionar un punto de referencia hacia una cierta red externa. El Nombre de Punto de Acceso es un nombre lógico que hace referencia a la red externa de datos por paquetes con la que desea conectar el abonado. La QoS Solicitada indica el perfil QoS deseado. La Especificación de Filtro indica qué paquetes de datos externos están asociados a un contexto PDP específico. Los paquetes indicados por las condiciones de filtrado de este filtro se deberían considerar como pertenecientes a este contexto PDP específico. Las Opciones de Configuración PDP se pueden utilizar para solicitar parámetros PDP opcionales del GGSN (ver recomendación GSM 09,60). Las Opciones de Configuración PDP se envían de forma transparente a través del SGSN.

El uso de configuración dinámica y direcciones PDP dinámicas implica el problema de cómo garantizar que la activación del contexto afecta al GGSN correcto, y cómo sabe el GGSN si activar un contexto nuevo con la misma dirección IP o una dirección diferente. Se pueden encontrar tres soluciones para este problema:

1. Uso de un Nombre de Punto de Acceso que apunta a un cierto nodo GGSN e indica que se necesita otro contexto, y uso de la misma dirección IP.

2. Adición de una indicación (tal como un elemento de información nuevo) a la solicitud de activación de contexto, indicando al GGSN (y al SGSN) que se necesita otro contexto. Este contexto tiene la misma dirección IP que el anterior. En este caso el SGSN selecciona el mismo GGSN que el anterior contexto de ese tipo de PDP.

3. Adición de las direcciones PDP e IP deseadas para el contexto al mensaje de solicitud de activación de contexto. Esta dirección PDP/IP se puede asignar a uno de los contextos anteriores, es decir, una dirección dinámica. En este caso, el SGSN selecciona el GGSN que está manipulando esa dirección específica.

En la etapa 6-2 se pueden realizar funciones de seguridad, aunque no son relevantes para entender la invención.

En la etapa 6-3, el SGSN valida la solicitud 6-1. El SGSN crea un Identificador de Túnel TID para el contexto PDP solicitado combinando la IMSI almacenada en el contexto MM con la NSAPI recibida desde la MS. El SGSN puede limitar los atributos QoS solicitados considerando sus capacidades, la carga actual, y el perfil QoS suscrito. A continuación, en la etapa 6-3 el SGSN envía hacia el GGSN una Solicitud de Creación de Contexto PDP (que comprende un tipo de PDP, una dirección PDP, un Nombre de Punto de Acceso, los Perfiles QoS negociados, el filtro deseado, el TID, y las opciones de configuración del PDP). Además el GGSN puede limitar los atributos QoS solicitados considerando sus capacidades, y la carga actual. Si la MS solicita una dirección dinámica, en ese caso el SGSN deja que un GGSN asigne la dirección dinámica. El SGSN puede limitar los atributos QoS solicitados dadas sus capacidades, la carga actual, y el perfil QoS suscrito. El SGSN envía hacia el GGSN en cuestión un mensaje de Solicitud de Creación de Contexto PDP (Tipo de PDP, Dirección PDP, Nombre de Punto de Acceso, QoS Negociada, Especificación de Filtro, TID, Modo de Selección, Opciones de Configuración del PDP). El Nombre de Punto de Acceso es el Identificador de Red APN de la APN seleccionada. La Dirección PDP estará vacía si se solicita una dirección dinámica. El GGSN puede utilizar el Nombre de Punto de Acceso para encontrar una red externa. El Modo de Selección indica si se seleccionó una APN suscrita, o si se seleccionó una APN no suscrita enviada por la MS o una APN no suscrita escogida por el SGSN. El GGSN puede utilizar el Modo de Selección cuando decide si aceptar o rechazar la activación del contexto PDP. Por ejemplo, si una APN requiere suscripción, en ese caso el GGSN está configurado para aceptar únicamente la activación del contexto PDP que solicita una APN suscrita tal como se indica por medio del SGSN con el Modo de Selección. El GGSN crea una entrada nueva en su tabla de contexto PDP y genera una Id de Cobro. La entrada nueva permite que el GGSN encamine unidades PDU PDP entre el SGSN y la red PDP externa, y que inicie el cobro. Además el GGSN puede limitar la QoS Negociada considerando sus capacidades y la carga actual. El GGSN mantendrá información para la correspondencia QoS y los paquetes de datos entrantes múltiplex provenientes de la red externa sobre los contextos PDP activos según las condiciones de filtrado definidas en el GGSN. Para paquetes salientes, una cierta QoS externa podría estar asociada a los paquetes de un contexto PDP específico. A continuación el GGSN devuelve al SGSN un mensaje de Respuesta de Creación de Contexto PDP (TID, Dirección PDP, Protocolo BB, Reordenación Requerida, Opciones de Configuración PDP, QoS Negociada, Id de Cobro, Causa). Se incluye la Dirección PDP si es que el GGSN asignó una. El Protocolo BB indica si se debería utilizar TCP o UDP para transportar datos de usuario sobre la red principal entre el SGSN y el GGSN. La Reordenación Requerida indica si el SGSN debería reordenar las N-PDU antes de entregar las N-PDU a la MS. Las Opciones de Configuración PDP contienen parámetros PDP opcionales que el GGSN puede transferir a la MS. Estos parámetros PDP opcionales pueden ser solicitados por la MS en el mensaje de Solicitud de Activación del Contexto PDP, o pueden ser enviados sin ser solicitados por el GGSN. Las Opciones de Configuración PDP se envían de forma transparente a través del SGSN. Los mensajes de Creación de Contexto PDP se envían a través de la red dorsal GPRS. Si la QoS Negociada recibida desde el SGSN es incompatible con el contexto PDP que está siendo activado (por ejemplo, la clase de fiabilidad es insuficiente para soportar el tipo PDP), en ese caso el GGSN rechaza el mensaje de Solicitud de Creación de Contexto PDP. Los perfiles QoS compatibles se pueden configurar por medio del operador del GGSN.

En la etapa 6-4, el GGSN devuelve al SGSN una Respuesta de Creación de Contexto PDP (que comprende un TID, una dirección PDP, los Perfiles QoS negociados, y las opciones de configuración PDP). El SGSN inserta la NSAPI con la dirección GGSN en el contexto PDP. Si la MS ha solicitado una dirección dinámica, la dirección PDP recibida desde el GGSN se inserta en el contexto PDP. El SGSN selecciona una Prioridad de Radiocomunicaciones sobre la base de la QoS Negociada, y devuelve a la MS un mensaje de Aceptación de Activación de Contexto PDP (Tipo PDP, Dirección PDP, TI, QoS Negociada, Prioridad de Radiocomunicaciones, Opciones de Configuración PDP). En este momento el SGSN puede encaminar las PDU PDP entre el GGSN y la MS, y puede iniciar el cobro.

A continuación, en la etapa 6-5, el SGSN selecciona un Nivel de Prioridad de Radiocomunicaciones basándose en cada perfil QoS negociado, y devuelve a la MS una Aceptación de Activación de Contexto PDP (que comprende un tipo de PDP, una dirección PDP, una NSAPI, los Perfiles QoS negociados, un Nivel de Prioridad de Radiocomunicaciones y una SAPI para cada perfil QoS, el filtro y las opciones de configuración PDP). En este momento el SGSN puede encaminar las unidades PDU PDP entre el GGSN y la MS. La SAPI indica qué perfil QoS utiliza qué SAPI.

La Figura 7 muestra un procedimiento de modificación de contexto. En la etapa 7-1 la MS envía al SGSN una Solicitud de Modificación de Contexto PDP. En la etapa 7-3 el SGSN envía al GGSN una Solicitud de Actualización de Contexto PDP. Ambas solicitudes mencionadas comprenden el filtro con parámetros modificados. El filtro indica qué paquetes de datos externos están asociados a un contexto PDP específico. Se debería interpretar que los paquetes indicados por las condiciones de filtrado pertenecen a este contexto PDP específico y deberían estar provistos de la QoS negociada para el contexto. El mensaje de Solicitud de Actualización de Contexto PDP se utiliza para añadir, modificar o cancelar un perfil QoS de un contexto PDP. Si el GGSN recibe desde el SGSN una QoS negociada que es incompatible con el contexto PDP que está siendo modificado (por ejemplo, la clase de fiabilidad es insuficiente para soportar el tipo de PDP), el GGSN rechaza la solicitud. Los perfiles QoS compatibles se configuran por medio del operador del GGSN. El GGSN puede limitar nuevamente los atributos QoS solicitados considerando sus capacidades, y la carga actual. El GGSN almacena los valores QoS negociados. El GGSN revisa la información de correspondencia QoS para ajustarse a la nueva especificación del filtro y al Perfil QoS negociado (incluido en el mensaje de solicitud). En las etapas 7-4 y 7-5 a la MS se le devuelve una respuesta positiva.

A partir del GPRS fase 2 se conocen versiones básicas de los mensajes 7-1 a 7-5. Según la invención, los mensajes 7-1 y 7-3 se modifican para transportar los parámetros de filtrado deseados (y los mensajes 7-4 y 7-5 se modifican para devolver una confirmación de recepción adecuada).

Según todavía otra forma de realización de la invención, la función de filtro en una primera dirección (por ejemplo, enlace descendente) se puede modificar utilizando información incluida en los paquetes enviados en la segunda dirección (por ejemplo, enlace ascendente). Esta forma de realización no requiere ninguna señalización adicional. Según esta forma de realización ilustrativa, se definen las siguientes clases de tráfico (RT = Tiempo Real, NRT = Tiempo No Real):

Clase	Conversacional (RT)	De flujo continuo (RT)	Interactiva (NRT)	De fondo (NRT)
de tráfico	\bullet capacidad	\bullet capacidad garantizada	\bullet mejor esfuerzo	\bullet mejor esfuerzo
	garantizada	\bullet ARQ (nivel MAC)	\bullet ARQ	\bullet ARQ
	\bullet no ARQ	\bullet Ad. de memoria	\bullet Interactiva	\bullet descarga en el
		intermedia en la	\bullet www, Telnet	fondo de correo
		aplicación	\bullet Canal decontrol	electrónico,
			RT	acontecimientos del
				calendario, etcétera
Retardo	100 ms, 200 ms, 400 ms	< 1 s	2 s	no interesa
BER	10^{-3}, 10^{-4}, 10^{-5}	10^{-5}, 10^{-6}, 10^{-7}, 10^{-8}	< 10^{-9}	< 10^{-9}
Velocidad	Garantizada	Garantizada	No garantizada	No garantizada
binaria max
Precedencia	Alta, media, baja	Alta, media, baja	Alta, media, baja	Alta, media, baja
de servicio

Las clases conversacional y de flujo continuo son clases de tráfico orientadas al tiempo real para las cuales se reservan recursos. Las clases Interactiva y de Fondo son clases con el mejor esfuerzo, que no tienen recursos reservados. Para estas clases, se puede utilizar la asignación de recursos al estilo GPRS, es decir, la MS envía solicitudes de recursos de radiocomunicaciones bajo demanda.

Para las clases en tiempo real, es decir, las clases Conversacional y de Flujo continuo, el método presentado anteriormente es muy eficaz, es decir, la información de filtro es portada en operaciones de contexto PDP hacia el GGSN de manera que el GGSN puede establecer una correspondencia de paquetes IP entrantes con la clase QoS correcta. No obstante, con las clases Interactiva y de Fondo esto implica grandes cantidades de señalización, lo cual en algunas situaciones podría resultar inaceptable. Un ejemplo de una situación de este tipo es una consulta enviada a un Servidor de Nombres de Dominio DNS (no mostrado), en cuyo caso el flujo neto podría consistir en solamente dos paquetes.

En este ejemplo, la clase Interactiva se selecciona como la clase QoS por defecto. Esto significa que si no hay información sobre el requisito QoS de un flujo entrante, o la información del flujo no se ajusta a ninguna de las condiciones del filtro, se seleccionará la clase interactiva. Además, los flujos pertenecientes a la clase de fondo se pueden identificar por medio del GGSN "sobre la marcha". Esto significa que cuando el GGSN capta un paquete de la MS en la clase de Fondo, tendrá conocimiento de la información de la identificación del flujo, y modificará las características del filtro asociadas a la clase de fondo, para establecer una correspondencia del flujo de enlace descendente correspondiente al flujo en cuestión con la clase de Fondo. Cuando un paquete viene en la dirección de enlace descendente, el GGSN comprueba la información de identificación del flujo asociada a la clase de Fondo. Si la información del filtro del flujo asociada a la clase de Fondo coincide con la información del encabezamiento del paquete IP recibido, en ese caso el paquete se dirige a la clase de Fondo.

La información del flujo relacionada con la clase de Fondo se puede manipular de la siguiente manera. La MS tiene conocimiento sobre flujos que deberían llevarse utilizando la clase de Fondo. El usuario puede configurar esta correspondencia de flujos con la clase de Fondo. Por ejemplo, el usuario puede configurar transferencias de archivos para que utilicen la clase de Fondo utilizando una aplicación de configuración adecuada. Como alternativa, la información se puede obtener a partir de, por ejemplo, alguna información QoS externa (por ejemplo, información QoS de internet). En otras palabras, la MS tiene criterios de filtro para que se establezca una correspondencia de los flujos con la clase de fondo. Una característica esencial de esta forma de realización es que la MS tiene conocimiento sobre qué flujos se deberían dirigir hacia la clase de Fondo, y envía estos paquetes hacia el enlace correspondiente. Cuando el GGSN recibe paquetes de la MS, sabe la clase QoS a la que están asociados los paquetes. Cuando el GGSN capta un paquete de la clase de Fondo comprueba si ya tiene una entrada para ese flujo en una lista (no mostrada) que contiene información de flujo de todos los flujos pertenecientes a la clase de Fondo. Si no hay ninguna entrada para ese flujo en la lista, el GGSN modifica el filtro utilizado al establecer la correspondencia de los flujos de enlace descendente con la clase de Fondo de manera que se establecerá una correspondencia del flujo de enlace descendente correspondiente al flujo de enlace ascendente al que pertenece el paquete recibido con la clase de Fondo. Esto se puede realizar incluyendo la información de identificación de flujo del paquete de enlace ascendente en la lista de información de flujos a partir de la cual se establece la correspondencia de los paquetes de enlace descendente con la clase de Fondo. Por lo tanto, los flujos pertenecientes a la clase de fondo se identifican en el GGSN "sobre la marcha".

Cuando el GGSN recibe un paquete de internet o de cualquier otra red externa, comprueba la información de filtro asociada a las clases Conversacional, de Flujo continuo y de Fondo. Si el GGSN encuentra que las características del paquete se ajustan a las condiciones pertinentes del filtro, reenvía el paquete hacia la clase QoS correspondiente. Si no hay ninguna entrada para ese flujo específico, en ese caso el paquete se reenvía a la clase Interactiva, que es la clase por defecto.

Esta forma de realización reduce drásticamente la necesidad de señalización ya que la clase Interactiva será la clase QoS más frecuentemente utilizada. Existen muchos casos en los que los paquetes IP no forman realmente un flujo, sino que en su lugar hay solamente uno o unos pocos paquetes IP que van en la dirección del enlace ascendente y unos pocos paquetes que vienen en la dirección del enlace descendente como respuesta. Una consulta DNS es un buen ejemplo de este tipo de comportamiento. La señalización de la modificación del contexto PDP en estos casos provocaría una cantidad relativamente alta de señalización que se puede evitar utilizando esta forma de realización. En cambio, para obtener una dirección IP para la MS se necesita únicamente la activación del contexto PDP inicial.

Un problema residual en el enfoque mostrado en las Figuras 6 y 7 es que puede que no quede claro cómo añadir información de filtrado además del filtro para el contexto PDP, o cómo modificar los filtros existentes sin eliminar primero todos los filtros existentes y a continuación reenviar toda la información de los filtros, incluyendo los cambios. En otras palabras, si se utilizan siempre procedimientos de activación y de modificación del contexto PDP, en los mensajes se debe incluir toda la información de filtrado incluso si se va a cambiar solamente un valor de un parámetro. La adición de un filtro nuevo requiere el envío de todos los filtros al mismo tiempo. Consecuentemente, las Figuras 8 y 9 ilustran una forma de realización preferida de la invención que apunta a la resolución de este problema residual.

Se propone que debería haber por lo menos un mensaje dedicado para configurar la información del filtro. En este contexto, "dedicado" significa que el mensaje no porta información de contexto PDP. Se debería definir un asa de filtro para identificar un cierto filtro de un cierto contexto PDP. Este asa de filtro puede consistir en un Identificador de Túnel TID, que indica el usuario y el contexto PDP, y un número de filtro FN. Este último puede ser un número de secuencia seleccionado por la MS cuando se crea un filtro. En resumen, los filtros se pueden configurar por medio de los siguientes procedimientos:

1. Se pueden crear uno o más filtros en asociación con el procedimiento de activación del contexto PDP (ver Figura 6). En este caso, en los mensajes de activación del contexto PDP se incluyen uno o muchos elementos de información de filtro, siendo identificado cada elemento de filtro por un número de filtro distinto (1, 2, 3, etcétera).

2. Se pueden modificar filtros en asociación con el procedimiento de modificación del contexto PDP (ver Figura 7). En este caso, se pueden modificar uno o más parámetros de filtro de uno o más filtros añadiendo elementos de información de filtro en la solicitud de modificación del contexto PDP. Los filtros independientes son identificados por un número de filtro. Asimismo se pueden crear filtros nuevos utilizando este procedimiento. En este caso en el mensaje de solicitud de modificación se incluye un elemento de información de filtro nuevo (por ejemplo, un número de filtro nuevo, no utilizado previamente).

3. Operaciones de filtro nuevo (uno o más mensajes dedicados): Se proponen tres operaciones entre la MS y el GGSN para configurar los filtros:

3.1 Crear filtro: Este mensaje porta información TID, así como el elemento de filtro nuevo y un número de filtro nuevo. El GGSN crea un filtro nuevo según el contenido del mensaje.

3.2 Modificar filtro: Este mensaje porta información TID, así como el elemento de filtro nuevo que sustituye al antiguo y un número de filtro que identifica el filtro específico a sustituir. El GGSN sustituye el(los) atributo(s) de filtro del filtro indicado por el(los) nuevo(s).

3.3 Borrar filtro: Este mensaje porta información TID, así como el número de filtro del filtro a eliminar. El GGSN elimina ese filtro específico.

Se debería indicar que las operaciones 3.1 a 3.3 se pueden combinar para utilizar solamente uno o dos tipos de mensajes diferentes, aunque también se pueden definir tres mensajes diferentes (uno por cada operación). Los mensajes definidos pueden ser mensajes GTP en cuyo caso se deberían definir mensajes GTP nuevos (en otras palabras, identificadores de mensajes nuevos en GTP). En este caso, la información TID se incluye automáticamente en los encabezamientos de los paquetes GTP y no es necesario que sea un elemento de información independiente en el mensaje. Como alternativa, entre la MS y el GGSN se puede definir un protocolo nuevo para operaciones de filtro, en cuyo caso el SGSN sería totalmente transparente a estos mensajes.

La Figura 8 muestra una primera implementación de las operaciones de filtro nuevo 3.1 a 3.3. En la etapa 8-0 se activa un contexto PDP para la MS. Los detalles de esta operación ya se han descrito de forma general en relación con las figuras anteriores. En la etapa 8-1 la MS envía al SGSN un mensaje CREAR FILTRO. Este mensaje tiene como parámetros el Identificador de Túnel TID (que especifica el contexto PDP) y un número de filtro FN (que especifica un cierto filtro dentro del contexto PDP). Naturalmente, el mensaje CREAR FILTRO debería incluir también las características del filtro. En la etapa 8-2 el mensaje se emite desde el SGSN hacia el GGSN. Las etapas 8-3 y 8-4 son confirmaciones de recepción correspondientes. En la etapa 8-5 la transmisión de datos tiene lugar hacia/desde la MS. Las etapas 8-6 a 8-9 se corresponden con las etapas 8-1 a 8-4, excepto que en estas últimas etapas la MS (o una aplicación que esté siendo ejecutada) modifica un filtro existente enviando un mensaje MODIFICAR FILTRO. En las etapas 8-11 a 8-14 se borra un filtro, que ya no se necesita, enviando un mensaje BORRAR FILTRO.

La implementación mostrada en la figura 8 se basa en protocolos existentes. Los mensajes entre la MS y el SGSN pueden ser, por ejemplo, mensajes de gestión de sesión y los mensajes entre el SGSN y el GGSN pueden ser, por ejemplo, mensajes GTP. Tal como puede observarse, la negociación de un filtro entre una MS y un GGSN es innecesariamente compleja ya que no existen protocolos predefinidos entre la MS y el GGSN.

En aras de una mayor claridad, los mensajes 8-1, 8-6 y 8-11 se han mostrado como tres mensajes independientes. Como alternativa, todas estas operaciones podrían utilizar únicamente un mensaje, por ejemplo, CONFIGURAR FILTRO, que incluye un parámetro tal como 1=crear, 2=modificar, 3=borrar.

La Figura 9 muestra una implementación alternativa en la que existe una capa de protocolo entre la MS y el GGSN, y el SGSN es un nodo transparente que no interpreta los mensajes de ninguna manera.

La forma de realización y las diferentes implementaciones mostradas en las figuras 8 y 9 proporcionan un esquema muy flexible en el que se pueden añadir y modificar dinámicamente filtros independientes (por ejemplo, específicos de cada aplicación) utilizando operaciones de filtro especiales. Para identificar los filtros independientes se utiliza un asa de filtro especial.

La descripción ilustra únicamente formas de realización preferidas de la invención. No obstante, la invención no se limita a estos ejemplos sino que puede variar dentro del ámbito de las reivindicaciones adjuntas. Por ejemplo, no es necesario que el terminal receptor sea una estación móvil sino que puede ser cualquier elemento de red. De forma similar, no es necesario que los paquetes de datos MT se originen en la red IP. Por el contrario, la invención es aplicable, por ejemplo, en una llamada de MS a MS a través de un nodo GGSN. En este caso la ramificación de una MS al GGSN es un primer subsistema de comunicaciones y la ramificación del GGSN a la otra MS es un segundo subsistema de comunicaciones.

Claims (19)

1. Método para enviar paquetes de datos (DP) desde un primer subsistema (11, 12) de comunicaciones a través de un primer elemento (GGSN) de red hacia un segundo elemento (MS) de red en un segundo subsistema (13) de comunicaciones;

comprendiendo dicho método las etapas siguientes:

envío de los paquetes de datos (DP) en una primera pluralidad de flujos de datos en dicho primer subsistema (11, 12) de comunicaciones;

establecimiento de una correspondencia de dicha primera pluralidad de flujos de datos con una segunda pluralidad de flujos de datos en dicho segundo subsistema (13) de comunicaciones;

caracterizado por:

establecer por lo menos un filtro (FI) para controlar dicho establecimiento de una correspondencia;

asociar dicho por lo menos un filtro (FI) a un flujo de datos dentro de dicha segunda pluralidad;

establecer una correspondencia de por lo menos un flujo de datos basándose en dicho filtro (FI); y

configurar dicho filtro (FI) a partir de dicho segundo elemento (MS) de red.

2. Método según la reivindicación 1, caracterizado por configurar dicho filtro (FI) en un mensaje (6-1, 7-1) de activación o modificación del contexto de protocolo de datos por paquetes.

3. Método según la reivindicación 2, caracterizado por configurar por lo menos dos filtros (FI) en un mensaje de activación o modificación del contexto de protocolo de datos por paquetes e identificar cada filtro con un identificador distinto.

4. Método según la reivindicación 1, caracterizado por configurar dicho por lo menos un filtro (FI) en un mensaje dedicado (8-1, 8-6, 8-11; 9-1, 9-4, 9-7).

5. Método según la reivindicación 1, caracterizado por configurar dicho filtro (FI) en un mensaje que es transparente para por lo menos algunos nodos (SGSN) entre el primer y el segundo elementos (GGSN, MS) de red.

6. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque el primer subsistema (11, 12) de comunicaciones es una red de Protocolo de internet, o red IP, y el método comprende la asignación de una dirección IP que es compartida por todos los flujos de datos dentro de dicha segunda pluralidad.

7. Método según cualquiera de las reivindicaciones 1 a 5, caracterizado porque el primer subsistema (11, 12) de comunicaciones es una red de Protocolo de internet, o red IP, y el método comprende la asignación de una dirección IP independiente para cada flujo de datos dentro de dicha segunda pluralidad.

8. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque dicho segundo subsistema (13) de comunicaciones es una red de radiocomunicaciones por paquetes que utiliza el Protocolo de Radiocomunicaciones por Paquetes, o el protocolo PDP, y dicha etapa de configuración comprende el envío de un mensaje (6-1, 6-3) de activación del contexto PDP o un mensaje (7-1, 7-3) de modificación del contexto PDP.

9. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque dicha asociación se basa en la dirección del segundo elemento (MS) de red, preferentemente su dirección IP, en dicho primer subsistema (11, 12) de comunicaciones.

10. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque dicha asociación se basa en el identificador del segundo elemento (MS) de red, preferentemente su IMSI o Identificador de Túnel, en dicho segundo subsistema (13) de comunicaciones.

11. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque comprende las siguientes etapas:

realización de dicho establecimiento de una correspondencia basándose en dicho filtro (FI) con respecto a flujos de datos que transportan información en tiempo real; y

establecimiento de parámetros por defecto para establecer una correspondencia de los flujos de datos restantes.

12. Método según cualquiera de las reivindicaciones anteriores, caracterizado por definir un flujo de datos dentro de la segunda pluralidad como flujo de datos por defecto, con el cual se establece una correspondencia de todos los flujos de datos de la primera pluralidad que no se ajustan al por lo menos un filtro (FI).

13. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque por lo menos uno de los flujos de datos es bidireccional presentando una primera dirección desde la primera pluralidad hacia la segunda pluralidad y una segunda dirección que es inversa a la primera dirección, y el por lo menos un filtro (FI) se modifica sobre la base de paquetes de datos de usuario enviados en la segunda dirección.

14. Método según la reivindicación 13, caracterizado porque un elemento (GGSN) de pasarela que establece una correspondencia de los flujos de datos:

recibe un paquete de datos (DP) en la segunda dirección desde un primer flujo de datos dentro de la segunda pluralidad;

reenvía el paquete de datos hacia un segundo flujo de datos dentro de la primera pluralidad; y

modifica el por lo menos un filtro (FI) para establecer una correspondencia del segundo flujo de datos con el primer flujo de datos.

15. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque por lo menos un flujo de datos dentro de la primera pluralidad forma un túnel a través de un flujo de datos dentro de la segunda pluralidad, y por lo menos dos flujos de datos dentro de la segunda pluralidad tienen características de Calidad de Servicio mutuamente diferentes.

16. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque el segundo elemento (MS) de red es una estación móvil.

17. Primer elemento de red, preferentemente un Nodo de Soporte de Pasarela GPRS (GGSN), para encaminar paquetes de datos (DP) desde un primer subsistema (11, 12) de comunicaciones hacia un segundo elemento (MS) de red en un segundo subsistema (13) de comunicaciones;

estando adaptado dicho primer elemento (GGSN) de red para:

recibir los paquetes de datos (DP) desde dicho primer subsistema (11, 12) de comunicaciones, en una primera pluralidad de flujos de datos;

establecer una correspondencia de dicha primera pluralidad de flujos de datos con una segunda pluralidad de flujos de datos en dicho segundo subsistema (12) de comunicaciones;

caracterizado porque dicho primer elemento (GGSN) de red está adaptado para:

establecer por lo menos un filtro (FI) para controlar dicha correspondencia;

asociar dicho por lo menos un filtro (FI) con un flujo de datos dentro de dicha segunda pluralidad;

establecer una correspondencia de por lo menos un flujo de datos basándose en dicho filtro (FI);

recibir una señal de configuración digital generada en una estación móvil para configurar el filtro; y

configurar el filtro basándose en la señal de configuración digital generada en la estación móvil.

18. Señal de configuración digital generada en estación móvil para crear (6-1, 6-3, 8-1, 9-1) ó modificar (7-1, 7-3, 8-6, 9-4) un contexto de protocolo de datos por paquetes en un nodo (GGSN) de soporte para comunicar por interfaz un primer subsistema (11, 12) de comunicaciones con un segundo subsistema (12) de comunicaciones; caracterizada porque dicha señal de configuración comprende información que define por lo menos parcialmente un filtro (FI) para controlar el establecimiento de una correspondencia de flujos de datos de dicho primer subsistema de comunicaciones con dicho segundo subsistema (13) de comunicaciones por medio de dicho nodo (GGSN) de soporte.

19. Estación móvil para una red (13) de radiocomunicaciones por paquetes, que se puede hacer funcionar de manera que envía una señal de configuración digital para crear (6-1, 6-3, 8-1, 9-1) o modificar (7-1, 7-3, 8-6, 9-4) un contexto de protocolo de datos por paquetes en un nodo de soporte (GGSN) para comunicar por interfaz un subsistema externo (11, 12) de comunicaciones con dicha red (12) de radiocomunicaciones por paquetes; caracterizada porque dicha señal de configuración comprende información que define por lo menos parcialmente un filtro (FI) para controlar el establecimiento de una correspondencia de flujos de datos de dicho subsistema externo de comunicaciones con dicha red (13) de radiocomunicaciones por paquetes por medio de dicho nodo (GGSN) de soporte.