ES2297798T3 - Metodo para una pasarela de seleccion de un canal para transferir paquetes de datos. - Google Patents

Abstract

Un método para habilitar un nodo de pasarela (12) de una primera red de datos (10) de conmutación de paquetes, para seleccionar un primer canal, para transferir un paquete de datos canalizados a una dirección de protocolo de datos de paquetes de destino, de un servicio provisto de nodos móviles (18) en la primera red (44), estando el nodo de la pasarela (12) configurado para seleccionar el primer canal de una pluralidad de canales, estando cada uno para transferir paquetes de datos a la dirección del protocolo de datos por paquetes de destino del nodo móvil (18), habiéndose enviado el paquete de datos canalizados desde un nodo correspondiente y canalizado por un nodo de canalización (48) de una segunda red externa a la primera red (44), comprendiendo el método la etapa en que el nodo (12 de la pasarela selecciona el primer canal por la coincidencia de igualación de la dirección del protocolo de datos por paquetes asociada con el paquete de datos canalizados recibidos por el nodo de la pasarela (12) a un primer filtro de paquetes de datos asociado con el primer canal, por lo que el método está caracterizado porque tiene la etapa de: la asociación del nodo de canalización (48) con el paquete de datos canalizados, de una dirección de protocolo de datos por paquetes del nodo correspondiente.

Description

Método para una pasarela de selección de un canal para transferir paquetes de datos.

Campo de la presente invención

La presente invención está relacionada con un aparato y unos métodos para que se habilite un nodo de pasarela de una primera red de datos conmutados por paquetes para seleccionar un primer canal para transferir un paquete de datos canalizado a una dirección de destino de un protocolo de datos de paquetes de un servicio provisto en el nodo móvil en la primera red, estando configurado el nodo de la pasarela para seleccionar el primer canal a partir de una pluralidad de canales, los cuales están preparados para transferir los paquetes de datos a la dirección de destino del protocolo de datos de paquetes del nodo móvil, ejecutando la selección mediante la correspondencia de una dirección del protocolo de datos de paquetes, asociada con un paquete de datos recibido por medio del nodo de pasarela, con respecto a uno o más filtros de paquetes de datos asociados con la pluralidad de los canales.

Más en particular, aunque no en forma exclusiva, la presente invención está relacionada con un aparato y unos métodos para habilitar un Nodo de Soporte de una Pasarela del Servicio General de Radio por Paquetes (GGSN) de una red del Servicio General de Radio por Paquetes (GPRS) 2G ó 3G, para poder seleccionar un Contexto del Protocolo de Datos por Paquetes (PDP), para transferir un paquete de datos, enviado por un Nodo de Correspondencia (CN) en una red IP externa, a un Nodo Móvil (MN) en la red GPRS, en donde la macro-movilidad del MN está soportada utilizando el Protocolo de Internet Móvil, estando la MN alejada de su Red de Origen (HN), y en donde el paquete de datos está diseccionado a la Dirección de Origen de la MN, y siendo canalizado por un Agente de Origen de la MN en su HN.

Antecedentes

Aunque las redes móviles 2G convencionales, tales como el Sistema Global para los estándares de Comunicaciones Móviles (GSM), han proporcionado los servicios de voz y datos de circuitos conmutados para las estaciones móviles del usuario (MS), está presente un gran impulso en la industria de las telecomunicaciones para el despliegue de las redes móviles de paquetes conmutados. Las redes móviles de paquetes conmutados tienen ventajas significativas en los términos de la eficiencia de recursos de radio en las redes, y permiten también la provisión de servicios de usuario más avanzados. Con la convergencia de las redes fijas y móviles de telecomunicaciones, el Protocolo de Internet (IP), desplegado ampliamente en las redes fijas, es la elección natural como el mecanismo de enrutamiento de paquetes para las redes móviles por paquetes. La versión IP 4 actual (IPv4) se utiliza ampliamente en el dominio de las redes fijas. No obstante, se espera gradualmente la migración a la versión IP 6 (IPv6), la cual ofrece ventajas bien reconocidas sobre la versión IPv4, notablemente en términos de un espacio de direccionamiento ampliado significativamente, con un enrutamiento más eficiente, mayor estabilidad, seguridad mejorada, con integración de la Calidad de Servicio (QoS), soportando la multidifusión y otras funciones.

Los ejemplos en particular de los servicios móviles de conmutación de paquetes que se despliegan actualmente incluyen el Servicio General de Radio de Paquetes (GPRS) según lo implementado en ambas redes GSM 2G, y en las redes del Sistema Universal Móvil de Telecomunicaciones 3G (UMTS) (denominadas de ahora en adelante como redes GPRS). Se espera también que las tecnologías de acceso radioeléctrico distintas al GPRS, tales como las Redes de Área Local radioeléctricas (wLAN), proporcionaran un complemento flexible y eficiente de bajo costo al sistema GPRS para el acceso a servicios de banda ancha locales en algunas áreas tales como en los puntos activos (centros de conferencias, aeropuertos, centros de exhibiciones, etc.). En consecuencia, los operadores de redes móviles necesitarán el soporte de la itineración de las estaciones móviles entre las redes o subredes GPRS y no GPRS.

Aunque las redes GPRS se han diseñado desde el principio como redes móviles, tienen la gestión de la movilidad incorporada (para las MS dentro de la red GPRS) y la funcionalidad de itineración (para las MS itinerantes entre las redes GPRS), se ha desarrollado un trabajo de diseño en la Fuerza de Tareas de Ingeniería de Internet (IETF) para soportar la movilidad de los terminales de usuario IP en general. A tal fin, el IETF ha desarrollado los protocolos de Móviles IP (MIP). El sistema MIP está diseñado para soportar la movilidad cuando las estaciones móviles (o los nodos móviles (MN) en la terminología MIP) se desplazan entre las redes IP con distintos prefijos de subredes (macro-movilidad). Por ejemplo, el sistema MIP puede ser utilizado para soportar la movilidad entre una red GPRS y una red no GPRS, tal como una red wLAN. El sistema IP móvil no es espera que se utilice para la gestión de la movilidad dentro de una red o subred (micro-movilidad), la cual se gestiona típicamente mediante los mecanismos de la capa 2 específica de la tecnología, tales como la transferencia por software WCD-MA.

Estas dos versiones del MIP que se corresponden con las dos versiones del sistema IP. La versión MIP 4 (MIPv4) está diseñada para proporcionar la movilidad de direcciones IP para las direcciones de la versión 4 de IP (IPv4), mientras que la nueva versión MIP 6 (MIPv6) el sistema MIP está diseñado para proporcionar la movilidad de direcciones IP para las direcciones de la versión 6 de IP (IPv6). El sistema MIPv4 está descrito en el documento de Petición de Comentarios del IETF (RFC) 2002 disponible en el sitio WEB del IETF \underbar{http://www.ieft.org/rfc/rfc2002.tx?number=2002}. El borrador MIPv6 de Internet está descrito en el documento del borrador del IETF de Internet "Soporte de movilidad en el sistema IPv6" disponible en el sitio WEB \underbar{http://search.ieft.org/internet-drafts/draft-ietf-mobileip-ipv6-18.tx}, y referenciado como draft-ieft-mobileip-ipv6-18.tx.

La gestión de la movilidad del sistema MIPv4 se muestra en la figura 1. El MN40 está asignado a una dirección IP de inicio (HAddr) en su Red Inicial 42 (HN). Los procedimientos de enrutamiento en el HN aseguran que cuando el MN está dentro del HN, el paquete IP enviado desde un Nodo de Correspondencia (CN) 46 alcanzará al MN. No obstante, cuando el MN efectúa la itineración a una red exterior 44 (FN), los paquetes IP direccionados a su HAddr necesitarán ser enrutados a su nuevo emplazamiento en el FN. En el sistema MIPv4, el enrutador 48 en la red HN conocido como el Agente de Origen (HA) se utiliza para actuar como un servicio de envío de paquetes, en nombre del MN, cuando esté alejado del origen. En un primer modo de trabajo del MIPv4 (conocido como modo FA-CoA), al llegar al FN, al MN se le asigna un Cuidado de Dirección (CoA) por el enrutador 50 en el FN conocido como el Agente Exterior (FA). Debido a las limitaciones percibidas del espacio de direcciones IPv4, se prevé que más de un MN podrá compartir el mismo CoA. Después de la asignación del CoA, el FA 50 envía una actualización de unión al HA para registrar el CoA. Posteriormente, cuando el CN envía un paquete a la HAddr del MN en su HN (caso 1), el paquete es interceptado por el HA y canalizado al FA en el FN a través del canal 52 sobre la base del CoA.

La canalización incluye el encapsulado de un primer paquete de datos (con un encabezado y una carga útil) conforme la carga útil de un segundo paquete de datos tenga un nuevo encabezado indicando como las direcciones de la fuente y el destino, los puntos de inicio y terminación del canal, y transfiriendo el segundo paquete de datos como normal hacia el punto final del canal, en donde se encapsulará para poder obtener el primer paquete. Después del encapsulado, el punto final del canal, el FA, enruta el paquete original al MN utilizando los procedimientos de enrutado en el FN. En el MIP, la canalización incluye el IP en el encapsulado IP utilizando la Petición IETF para Comentario 2003 (RFC). Así pues, en el MIPv4, el paquete IPv4 se canaliza mediante el encapsulado dentro de otro paquete IPv4.

Como un procedimiento opcional en la versión MIPv4, el MN puede entonces enviar una actualización de unión al CN para registrar su CoA. Posteriormente, el CN puede enviar los paquetes directamente al MN al igual que su CoA actual, en lugar de hacerlo indirectamente a través de su HAddr (caso 2), y estos paquetes se recibirán mediante el FA en la red FN y siendo enrutados al nodo móvil MN utilizando los procedimientos de enrutado en la red FN. Esto se conoce como optimización del enrutamiento puesto que evita un enrutamiento triangular potencialmente ineficiente por medio del HA, el cual en general no será un trayecto de enrutamiento eficiente entre el CN y el FA.

En un segundo modo de trabajo opcional del MIPv4 (conocido como modo CoCoA), no existe el poder compartir el CoAs mediante los nodos MN alejados de su red de origen, no utilizándose ningún agente FA. Los nodos MN se asignan a un CoA único, conocido como CoA co-asignado (CoCoA), utilizando unos procedimientos de asignación de direcciones IP dinámicas estándar, por ejemplo utilizando un Protocolo de Control de Servidores Dinámicos (DHCP). En este modo de trabajo, el nodo MN tiene que enviar por sí mismo una actualización de unión a su HA para registrar su CoCoA recién asignado. Posteriormente, los paquetes enviados por un CN y direccionados al MN en su HAddr se canalizan desde la HA directamente al MN. Al igual que con el modo FA-CoA, como un procedimiento opcional en el modo CoCoA, el MN puede enviar también una actualización de unión a un CN para registrar su CoCoA. Posteriormente, los paquetes pueden ser enviados por el CN directamente al MN en su CoCoA.

La gestión de movilidad de la versión MIPv6 se muestra en la figura 2. Existen dos diferencias notables del sistema MIPv6 con respecto el MIPv4 tal como se expone a continuación. En primer lugar, debido al espacio de direcciones notablemente incrementado en el sistema IPv6, las CoAs asignadas a un MN en un FN no se comparten nunca (es decir, se corresponden con un CoCoA opcional en el sistema MIPv4). En segundo lugar, como resultado de ello, no hay necesidad de desplegar un FA en el FN. Con referencia a la figura 2, con el sistema MIPv6, cuando un MN 40 se desplaza desde su HN 42 a un FN 44, se asigna un CoA único y envía una actualización de unión a su HA 48 en su NH para registrar el CoA. Los paquetes desde el CN 46 direccionados al HAddr se interceptan por el HA (48) (caso 1), y siendo canalizados al CoA vía el canal 54. Esta canalización puede conseguirse utilizando el Mecanismo Genérico de Canalización de Paquetes IPv6, que se describe en el RFC IETF 2473. No obstante, en el sistema MIPv6, la optimización del enrutamiento no es una opción, sino la parte fundamental del protocolo, y en general el MN deberá enviar una actualización de unión al CN, de forma que pueda direccional paquetes directamente al MN en su CoA (caso 2). Cuando un MN recibe un paquete canalizado desde un CN a través de las HA del MN, puede considerar éste como una actualización de unión del CN. Se observará que el MIPv6 la actualización de unión del CN tiene que utilizar la nueva CoA del MN como la dirección de origen en el encabezado del IPv6 (véase la cláusula 11.6.2 del borrador de Internet MIPv6 IETF.

El Proyecto de Asociación de la tercera generación (3GPP) responsable de los estándares GPRS ha reconocido que el MIP puede ser necesario que esté soportado en las redes GPRS. La cláusula 5.7 de la Especificación técnica 23.060 expone que "Para soportar los servicios IP Móviles opcionales, véase el documento 3G TS 23.121 de forma eficiente en el dominio de los paquetes, la funcionalidad del Agente Exterior (FA) necesita que esté suministrada en el GGSN. La interfaz entre el GGSN y la FA, incluyendo la correspondencia entre el cuidado de la dirección IP el canal GTP en el PLMN se supone que no está estandarizada tal como se consideran el GGSN y la FA para que sean un nodo integrado". Además de ello, el documento 3G TS 23.121 (disponible a partir del sitio WEB 3GPP, en \underbar{http://www.3gpp.org/ftp/specs/2002-06/R1999/23\_series/}) expone que "... es importante el ofrecer IP Móvil también a los usuarios de UMTS y GPRS para permitirles poder itinerar hacia/desde otras tecnologías de acceso, manteniendo mientras tanto las secciones de datos actuales, por ejemplo, TCP o UDP'', y puesto que escasean las direcciones IP en IPv4, se tiene que suponer que el sistema IPv4 Móvil se utilizará preferiblemente con el cuidado de las direcciones del Agente Exterior (FA). En comparación con la utilización de direcciones de cuidado consignadas, las direcciones de cuidado FA no solo conservan las direcciones IP, siendo más eficientes a través de la interfaz de radio".

No obstante, pueden existir circunstancias en las cuales sean falsas las suposiciones anteriores. En primer lugar, un operador de la red GPRS puede necesitar el poder utilizar los CoCoAs en el sistema MIPv4 en lugar de las CoAs FA. Por ejemplo, las direcciones IPv4 puede no ser escasas dentro de una red GPRS en particular, y prefiriéndose el sistema CoCoA para mejorar la estabilidad y la eficiencia del enrutamiento. En segundo lugar, pueden existir circunstancias en las cuales el operador de la red GPRS podría no necesitar el integrar la funcionalidad FA en el Nodo de Soporte GPRS de la Pasarela (GGSN), que es la pasarela de conexión de la red GPRS a las redes de paquetes conmutados exteriores. Por ejemplo, el sistema GGSN puede estar cargado excesivamente y separando la funcionalidad del GGSN y FA, mejorando así el equilibrio de las cargas. Además de ello, puede considerarse beneficioso el asignar la FA en nodos, que estén más cerca de los bordes de la red GPRS, tales como nodos de acceso, para una estabilidad mejorada. En tercer lugar, el sistema 3GPP ha determinado recientemente que el IPv6 tiene que estar soportado en el Sistema Multimedia UMTS R5 IP y en las redes de acceso por radio IP en general. Así pues, está claro que las redes GPRS necesitarán poder soportar el MIPv6 así como también el MIPv4 en el futuro, y según lo descrito anteriormente, el MIPv6 no tiene FA y utiliza las CoAs que son exclusivas del MN (es decir, siempre "co-asignadas").

Los presentes inventores han observado que surgen problemas en las redes GPRS implementadas de acuerdo con las descripciones del servicio actual (Publicación de 1999) en cada unas de las tres circunstancias enumeradas anteriormente. Una característica en particular de las redes GPRS, que cumple con la Versión de 1999 y las posterior versión de 1999 (por ejemplo, R4, R5) de la Descripción del Servicio GPRS, es soportar lo que se conoce como el contexto del protocolo de datos de paquetes (PDP). La especificación de varios contextos PDP distintos es útil por varias razones. En particular, los contextos PDP permitir distintos niveles del QsO y otros parámetros a especificar para el tráfico hacia/desde una única dirección PDP de una MS. Esto permite la transferencia eficiente de una diversidad de tráfico de datos, tales como el tráfico no en tiempo real (por ejemplo, transferencias de datos intermitentes y por ráfagas, transferencias ocasionales de grandes volúmenes de datos) y tráfico en tiempo real (por ejemplo, voz, vídeo). Por ejemplo, una MS en una red GPRS, que tenga una dirección PDP, tal como una dirección IPv4 ó IPv6, pueden comunicar con una pluralidad de otros dispositivos de telecomunicaciones en las redes de paquetes conmutados externas, utilizando distintos contextos PDP con distintos parámetros QoS para cada uno. Es generalmente el trabajo de la MS el crear y modificar los contextos PDP según sea preciso.

Los paquetes de datos entrantes desde una red exterior para el enlace descendente a una MS se reciben en la red GPRS por la red GGSN. Si la dirección PDP de la MS tiene múltiples contextos PDP establecidos, será esencial que la red GGSN sea capaz de determinar el contexto PDP apropiado para cada paquete, de forma que pueda ser transferidos debidamente a la MS. Esto se consigue con la utilización de unas Plantillas de Flujo de Tráfico (TFT) asociadas con los contextos PDP. Las TFT pueden contener información de filtrado de los paquetes utilizados por la red GGSN para determinar el contexto PDP apropiado para el enlace descendente de los paquetes de datos. De acuerdo con los estándares 3GPP actuales, el elemento especificado de información para la utilización en el filtrado de paquetes es la dirección de origen del paquete de datos entrante, por ejemplo la dirección IP del nodo de origen según lo especificado en el encabezado del paquete IP. Cuando un paquete de datos entrante llega a la red GGSN, su dirección de origen es comprobada con respecto a las TFT existentes asociadas con la dirección PDP de la MS. Si se encuentra una coincidencia, el paquete es transferido a la MS en su dirección PDP de acuerdo con el contexto PDP apropiado. No obstante, si no se encuentra ninguna coincidencia, el paquete puede depositarse por la red GGSN. Aquí es donde surge el problema.

Supongamos que la MS en la red GPRS está provista con macro-movilidad a través del MIPv6, y que se ha desplazado justamente a la red GPRS, la cual es un FN, es decir tiene un FN y una HAddr en un HN (que puede ser o no una red GPRS), y que se desplazado hacia la red GPRS, en donde se ha asignado una CoA. Llamemos ahora a la MS con una MN y el dispositivo de telecomunicaciones en la red exterior una CN por consistencia con la terminología MIP. Después de desplazarse por la red GPRS, la MN enviará una actualización de unión a su HA en su HN informando de su nueva CoA. Esto hará que se envíe también normalmente una actualización de unión de su nueva CoA a la CN. No obstante, incluso aunque lo realice, la CN enviará todavía los paquetes de datos a la MN en su HAddr por varias razones. Tales paquetes de datos serán interceptados por la HA de la MN, y siendo canalizados hacia la MN utilizando la canalización IPv6 (RFC 2473). De acuerdo con la RFC 2473, "en la encapsulación, el campo de origen del encabezado IPv6 del canal se rellenará con la dirección del IPv6 del nodo del punto de entrada del canal", es decir, la dirección IPv6 de la HA. Así pues, el paquete de datos canalizado que llega a la red GGSN en la red GPRS no tendrá la dirección IP de la CN como la dirección de origen, pero la dirección IP de HA (esta no es la HAddr de la MN). Esta dirección no puede ser reconocida por la GGSN utilizando una TFT que identifique la dirección de origen de la CN y el paquete de datos puede ser depositado.

Conceptualmente, el problema puede estar a través del canal MIP que se extiende pasando por la GGSN y "escondiendo" la dirección de origen de la CN de la GGSN. Esto será el caso también en el sistema MIPv4 en caso de que la FA no esté integrada dentro de la GGSN, pero localizándose más allá hacia los bordes de la red, o bien si las CoCoAs se utilizan, puesto que en ambos casos, el punto final del canal se extenderá de nuevo más allá de la red GGSN. Se observará también que este problema es aplicable también en el caso general en donde la MN se desplaza hacia la red GPRS como un FN, incluso aunque no esté establecida la sesión de comunicaciones con un CN en particular. Puede esperarse que un futuro CN posible necesite enviar paquetes de datos al MN por medio de su HAddr por varias razones, y que ello será canalizado por medio de la HA. En consecuencia el problema surge en forma generalizada.

La presente invención proporciona una solución para el problema anterior.

La solicitud de la patente WO 02/23831 está relacionada con una configuración y un método en un sistema de comunicaciones que soporta la comunicaciones de datos por paquetes con una serie de estaciones de usuario, una red básica, varios medios de acceso para proporcionar acceso entre las estaciones de los usuarios y las redes de daos por paquetes externas. Se proporcionan medios de control de la información, los cuales están controlados por los usuarios, de forma tal que el usuario final pueda selectivamente controlar la recepción de los paquetes de datos a partir de las redes de datos por paquetes exteriores.

Sumario de la presente invención

De acuerdo con un aspecto de la presente invención, se proporciona un método para habilitar un nodo de pasarela de una primera red de datos de conmutación de paquetes, para seleccionar un primer canal, para transferir un paquete de datos canalizados a una dirección de protocolo de datos de paquetes de destino, de un servicio provisto de nodos móviles en la primera red, estando el nodo de la pasarela configurado para seleccionar el primer canal en una pluralidad de canales, estando cada uno para transferir paquetes de datos a la dirección de protocolo de datos por paquetes de destino del nodo móvil, en donde los paquetes de datos canalizados se han enviando desde un nodo correspondiente y canalizados mediante un nodo de canalización de una segunda red externa a la primera red, comprendiendo el método:

a)

el nodo de canalización que asocia, con el paquete de datos canalizados, una dirección del protocolo de los datos por paquetes del nodo correspondiente;

b)

el nodo de la pasarela de selección del primer canal mediante la igualdad de la dirección del protocolo de datos por paquetes asociados con el paquete de datos canalizados recibidos por el nodo de la pasarela a un primer filtro de paquetes de datos asociado con el primer canal.

Los aspectos adicionales de la presente invención incluyen un nodo de pasarela y un nodo de canalización configurados de acuerdo con el método del segundo aspecto descrito anteriormente.

Los aspectos adicionales de la presente invención se encuentran descritos en las reivindicaciones adjuntas.

Se expone a continuación a modo solo de ejemplo una descripción detallada de las realizaciones preferidas de la presente invención, en la cual:

Breve descripción de los diagramas

La figura 1 es un diagrama conceptual que muestra la gestión de la movilidad según lo previsto en MIPv4;

la figura 2 es un diagrama conceptual que muestra la gestión de la movilidad según lo previsto en MIPv6;

la figura 3 es un diagrama de la arquitectura de la red que muestra una red GPRS y una red wLAN conectada a través de un diagrama en forma de nube de la red exterior de paquetes conmutados;

la figura 4 es un diagrama de flujo de los mensajes, que muestra un procedimiento de modificación del contexto PDP en una red GPRS, permitiendo que una red GGSN pueda hacer coincidir los paquetes canalizados para el enlace descendente hacia un MN hasta el canal apropiado del contexto PDP, de acuerdo con la primera y tercera realizaciones de la presente invención;

la figura 5 es un diagrama de flujo que muestra el procedimiento modificado seguido por un GGSN de una red GPRS, de acuerdo con la primera y tercera realizaciones de la presente invención;

las figuras 6A y 6B son diagramas de bloques que muestran la estructura modificada de los paquete de datos IPv6 enviados por el HA de acuerdo con una segunda realización de la presente invención;

la figura 7 es un diagrama de flujo que muestra el procedimiento modificado seguido por una GGSN de una red GPRS de acuerdo con la segunda realización de la presente invención;

las figuras 8A, 8B y 8C son diagramas de bloques que muestran la estructura modificada de los paquetes de datos IPv6 enviados por el HA de acuerdo con una cuarta realización de la presente invención; y

la figura 9 es un diagrama de flujo que muestra el procedimiento modificado seguido por una GGSN de una red GPRS de acuerdo con la cuarta realización de la presente invención.

Descripción detallada de las realizaciones de la presente invención

La figura 3 muestra la arquitectura de la red en la cual tanto la red GPRS 10 como la red wLAN 20 están conectadas ambas con una o más redes de paquetes exteriores en la zona de la nube de la red de paquetes exterior 30.

La red GPRS 10 está conectada a las redes externas de paquetes a través de una o más Nodos de Soporte GPRS de Pasarela (GGSN) (aunque aquí solo se muestra un nodo GGSN 12), que se comunica con uno o más Nodos de Soporte GPRS de Servicio (SGSN) (aunque aquí solo se muestra un SGSN 14) a través de una red central de paquetes conmutados basados en IP. El nodo SGSN 14 mantiene el seguimiento del emplazamiento de las Estaciones móviles individuales (MS) pertenecientes al servicio GPRS, y que ejecutan las funciones de seguridad y de control del acceso. El SGSN 14 está conectada en sí a una o más Redes de Acceso de Radio (RAN) 16 (sea el Subsistema de la Estación Base (BSS) en la red GSM 2G o en la Red de Acceso de Radio Terrestre UMTS (UTRAN) en la red UMTS 3G). Las RAN controlan la comunicación radioeléctrica con una o más estaciones MS 18.

Se omiten en aras de la claridad otros componentes principales de la red GPRS 10, tales como el Registro de Emplazamientos de Origen (HlR), el cual almacena los datos GSM de abonados de UMTS, y el Registro de Emplazamientos del Centro de Conmutación Móvil / Visitantes (MSC/VLR), el cual gestiona los servicios de circuitos conmutados, y que mantiene también el seguimiento del emplazamiento de las Estaciones Móviles individuales (MS). El lector deberá consultar la Especificación Técnica de la Descripción del Servicio GPRS (versión de 1999), denominada como 3G TS 23.060v3.12.0 (2002-06), y disponible a partir del sitio WEB 3GPP en http:/www.3gpp.orgl/ftp/specs/2002-06/R1999/23_series/, el cual proporciona una descripción del servicio detallada para las redes de paquetes móviles 2G (GPRS/GSM) y 3G (GPRS/UMTS). La funcionalidad de las redes GPRS es bien conocida en general, aunque se describirán aspectos adicionales más adelante.

La red WLAN 20 está conectada a las redes de paquetes exteriores a través de un Controlador de Acceso (AC) 22, el cual controla uno o más Puntos de Acceso 24, los cuales se comunican radioeléctricamente con una o más estaciones MS 26. La funcionalidad de las redes wLAN es bien conocida en general y por tanto no se describirá aquí con detalle.

Con el fin de tener acceso a los servicios de paquetes conmutados GPRS, la estación MS ejecuta en primer lugar un procedimiento de conexión GPRS con el nodo SGSN (bien una conexión 2g GSM GPRS o una conexión 3G UMTS GPRS). Se ejecutan entonces los procedimientos de autenticación y localización, y en caso de tener éxito, el procedimiento de conexión GPRS hace que la estación MS esté disponible para la radiobúsqueda a través del SGSN y la notificación de los datos de los paquetes entrantes. No obstante, para enviar realmente y recibir los datos de los paquetes, la MS tiene que tener asignada la dirección del Protocolo de Datos de los Paquetes (PDP) (por ejemplo, una dirección IP), y tiene que activar al menos un contexto PDP para su utilización con dicha dirección PDP. Cada dirección PDP para una estación MS puede tener uno o más contextos PDP asociados con la misma y datos que definan los contextos PDP que se almacenarán en la MS, en el SGSN y GGSN. El proceso de la activación del contexto PDP hace que la MS sea conocida no solo en el SGSN, sino también para el GGSN correspondiente y pudiendo iniciarse la interconexión de las redes de datos exteriores.

Los contextos PDP se utilizan para mantener el estado tal como con la información de enrutamiento y los requisitos de la Calidad de Servicio (QoS) en los nodos de la red GPRS. En particular, los múltiples contextos PDP permiten uno o más niveles de QoS a especificar para una única dirección PDP de una estación MS, para permitir la transferencia eficiente de una amplia variedad de tráfico de datos, tal como un tráfico en tiempo no real (por ejemplo, transferencias de datos intermitentes o por ráfagas, transferencias ocasionales de grandes volúmenes de datos), y tráfico en tiempo real (por ejemplo, voz, vídeo). Así pues, la aplicación que se ejecute en una MS con una única dirección PDP puede utilizar uno o más niveles de QoS, de acuerdo con sus necesidades, mediante la utilización de uno o más contextos PDP. El contexto PDP puede estar en uno de dos estados, activo o inactivo. Al estar en estado inactivo, el contexto PDP no contiene información de enrutamiento o de correlación para procesar los paquetes relacionados con la dirección PDP. No pueden ser transferidos ninguno de los datos. Al estar en estado activo, el contexto PDP para la dirección PDP se activa en la MS, SGSN y GGSN. El contexto PDP contiene información de correlación y de enrutamiento para transferir los paquetes PDP para dicha dirección PDP en particular entre la estación MS y el nodo GGSN.

Los datos del usuario se transfieren entre las redes externas y la estación MS, utilizando los procedimientos de canalización, los cuales difieren entre las redes 2G GSM y 3G UMTS. No obstante, entre el nodo GGSN y SGSN, los paquetes se canalizan utilizando un procedimiento de encapsulado común, de acuerdo con el Protocolo de Canalización GPRS (GTP). La red central PLMN en el dominio de los paquetes encapsula el paquete de datos con un encabezado GTP, e inserta este paquete GTP en un paquete UDP que se inserta de nuevo en un paquete IP. Los encabezados de los paquetes IP y GTP contienen las direcciones GSN y el identificador del punto final del canal, necesarias para direccional en forma exclusiva un contexto PDP. En caso de que existan múltiples contextos PDP para una única dirección PDP de una estación MS, será necesario que exista un número correspondiente de canales GTP establecidos entre el GGSN y el SGSN para la transferencia de datos de los paquetes. Se observará que los canales GTP utilizado en las redes GPRS no tienen que ser confundidos con los canales MIP.

Cuando existen múltiples contextos PDP para una dirección PDP, el GGSN enruta los paquetes del enlace descendente a los distintos canales GTP, basándose en lo que se denominan como Plantillas de Flujo de Tráfico (TFT) asignadas a los contextos PDP. Cada contexto PDP puede estar asociado con una TFT. No obstante, como una regla estricta, a lo máximo un contexto PDP asociado con la misma dirección PDP podrá existir en cualquier momento sin tener asignada ninguna plantilla TFT. Así pues, con n contextos múltiples PDP, serán siempre n TFT o (n-1) TFT, correspondientes cada uno a los individuales de los n contextos PDP. En caso de existir una correlación 1 a 1 entre las TFT y los canales GTP correspondientes a cada contexto PDP, se llevará a cabo la selección del canal GTP sobre la base de la plantilla TFT. Si existe una correlación de (n-1) a n, la selección será directa también, pero podrá incluir un simple proceso de la eliminación en caso de no poder encontrar una coincidencia para una plantilla TFT.

\newpage

Las TFT se priorizan también utilizando índices de predicción de evaluación. A la recepción de un paquete de datos, el GGSN evalúa para obtener una coincidencia, en primer lugar el filtro de paquetes de entre todas las TFT que tengan el menor índice de predicción de evaluación, y en caso de no encontrar ninguna coincidencia, se procederá con la evaluación de los filtros de los paquetes en orden ascendente de su índice de prioridad de la evaluación. Este procedimiento se ejecuta hasta encontrar una coincidencia, en cuyo caso el paquete datos se canaliza hacia el SGSN a través del canal GTP que esté asociado con el contexto PDP, correspondiente al filtro del paquete TFT de coincidencia. De acuerdo con la Cláusula 9.3 de 3G TS 23.060, si no se encuentra una coincidencia, el paquete de datos se canalizará a través del contexto PDP que no tenga una TFT asignada al mismo, pero si todos los contextos PDP tiene una TFT asignada, el GGSN tendrá que descartar silenciosamente el paquete de dato.

Las TFT contienen atributos relativos a los encabezados de los paquetes de datos del enlace descendente, los cuales se utilizan para filtrar los paquetes de datos, y por tanto enrutar o correlacionar los mismos hacia el canal GTP para un correcto contexto PDP. Los atributos están definidos en los términos de campos de los encabezados IP. De acuerdo con la Cláusula 15.3.2 de 3G TS 23060, los atributos del encabezado del paquete de datos contenidos en las TFT se especifican en los términos de ambos campos de los encabezados de IPv4 e IPv6. Cada TFT comprende entre 1 y 8 filtros de paquetes, identificados cada uno mediante un identificador único del filtro de paquetes. El filtro de paquetes tiene también un índice de prioridad de evaluación que es exclusivo dentro de todas las TFT asociadas con los contextos PDP que comparten la misma dirección PDP. De acuerdo con la Cláusula 15.3.2 de 3G TS 23.060, cada filtro de paquetes válido contiene un único identificador dentro de una TFT dada, un índice de prioridad de evaluación que es exclusivo dentro de todas las TFT para una dirección PDP, y al menos uno de los siguientes atributos del encabezado siguientes de IPv4 o IPv6:

\bullet

Dirección de origen y Máscara de Subred.

\bullet

Número de Protocolo (IPv4) o Encabezado Siguiente (IPv6).

\bullet

Rango del puerto de destino.

\bullet

Rango del Puerto de Origen.

\bullet

Índice del Parámetro de Seguridad IPSec (SPI).

\bullet

Tipo de Servicio (TOS) (IPv4) o clase de Tráfico (IPv6) y Máscara.

\bullet

Etiqueta de flujo (IPv6).

No obstante, no todos estos atributos podrán ser utilizados en combinación sin dar lugar a una incompatibilidad. En la práctica, la Dirección de Origen y la Máscara de Subred se utilizarán de forma común, en casos de uso común, en donde una MS establecerá un distinto contexto PDP para sus direcciones PDP para cada dirección PDP del nodo correspondiente distinto. Se observará que la lista de atributos no contiene el atributo de la Dirección de Destino, solo el Puerto de Destino. Esto es porque los filtros TFT de paquetes no se utilizan para correlacionar paquetes con una dirección de la pluralidad de direcciones de destino, sino para el canal GTP correspondientes a uno de una pluralidad de contextos PDP establecidos para una única dirección de destino en una única estación MS.

No obstante, según se ha expuesto anteriormente, el atributo de la Dirección de Origen puede no ser suficiente para el GGSN para correlacionar los paquetes entrantes para el enlace descendente hacia la estación MS bajo ciertas circunstancias. De acuerdo con la presente invención, el procedimiento seguido por una MIPv4 o MIPv6 habilita la MS (le llamaremos ahora un MN) para su modificación. Al desplazarse hacia la red GPRS, el MN se conecta en la red GPRS, y se proporciona un CoA (o CoCoA), es decir, una dirección IPv4 o IPv6, para su utilización durante su permanencia en la red GPRS. Con la utilización de procedimientos MIP, el MN registra su dirección con su HA en su HN utilizando el procedimiento de actualización de unión de origen de MIPv4 o MIPv6. Para realizarlo así, tiene que primeramente activar un contexto PDP en la red GPRS utilizando el Procedimiento de Activación del Contexto PDP iniciado por la estación MS, que está descrito en la Cláusula 9.2.2 de 3G TS 23.060 aquí incorporada como referencia.

Primera realización

De acuerdo con una primera realización de la presente invención, con la conexión de origen con éxito, el MN modifica entonces el contexto PDP activado, para incluir, en un TFT asociado con el contexto PDP, la dirección del Agente de Origen, es decir una dirección IPv4 o IPv6, para habilitar a que el GGSN filtre los paquetes canalizados a través del HA. El MN utiliza el Procedimiento de Modificación del Contexto PDP iniciado por la estación MS, descrito en la Cláusula 9.2.3 de 3G TS 23.06, e incorporada aquí como referencia. La figura 4 muestra el procedimiento de modificación del contexto PDP. En la etapa 60, el MN 18 ejecuta el procedimiento de unión de Origen MIP, con su HA en su HN (no mostrado) utilizando el contexto PDP activado. Suponiendo que tiene éxito, en la etapa 62, el MN envía una Petición de Contexto PDP de Modificación a su SGSN 14. El mensaje de la Modificación de la Petición de Contexto PDO contiene una instrucción para añadir o modificar una TFT asociada con el contexto PDP para incluir la dirección IP del Agente de Origen del MN en el HN. Se observará que el MN puede enviar también opcionalmente una instrucción para modificar el perfil QoS en el mensaje de Petición de Contexto PDP de Modificación. En la etapa 64, el SGSN envía un mensaje de Petición de Contexto PDP de actualización al GGSN 12, incluyendo una instrucción para añadir o modificar la TFT tal como se ha expuesto anteriormente. El GGSN 12 comprueba la instrucción (por ejemplo para ver si los atributos en el filtro de paquetes de la TFT forma una combinación válida), y en caso de que sea aceptable, almacena o modifica la TFT para el contexto PDP en la forma adecuada. A continuación, en la etapa 66, el GGSN 12 envía un mensaje de Respuesta de Contexto PDP de Actualización al SGSN 14 indicando el éxito. En la etapa 68, la modificación del soporte de acceso por radio puede ser ejecutado (por ejemplo, en una red 36 GPRS en el modo en que se cambia el perfil QoS del contexto PDP). En la etapa 70, el SGSN 14 envía un mensaje de Aceptación del Contexto PDP de Modificación al MN para confirmar la modificación con éxito del contexto PDP (es decir, la TFT).

En una versión alternativa de la primera realización, se utiliza un filtro de los paquetes TFT modificados, en donde la lista de los posibles atributos del encabezado de los paquetes IPv4 ó IPv6 puedan ser incluidos en el filtro de los paquetes aumentándose de la forma siguiente:

\bullet

Dirección de Origen y Máscara de Subred.

\bullet

Dirección del Agente de Origen

\bullet

Número de protocolo (IPv4) o Encabezado Siguiente (IPv6)

\bullet

Rango del Puerto de Destino

\bullet

Rango del Puerto de Origen

\bullet

Índice del Parámetro de Seguridad IPSec (SPI)

\bullet

Tipo de Servicio (TOS) (IPv4) o clase de Tráfico (IPv6) y Máscara.

\bullet

Etiqueta del flujo (IPv6).

en donde el termino de Dirección del Agente de Origen es la dirección IPv4 o IPv6 del HA de MIPv4 o MIPv6 para el MN en su HN.

Así pues, para un contexto PDP, los filtros de los paquetes TFT almacenados en el MN, y el GGSN pueden incluir la dirección IPv4 o IPv6 del Agente de Origen del MN en un campo especialmente identificado. El comportamiento del atributo de la Dirección del Agente de Origen, en términos de la validez de la combinación con otros atributos, es el mismo que el comportamiento del atributo de la Dirección de Origen (véase la Cláusula 15.3.2 de 3G TS 23.060. No obstante, una TFT puede comprender un filtro de paquetes que tenga los atributos de la Dirección de Origen y la Dirección del Agente de Origen en forma individual, o ambos atributos de la Dirección de Origen y la Dirección del Agente de Origen en forma combinada. En el caso en donde ambos atributos están especificados en un único filtro de los paquetes TFT, se tratarán como alternativas, es decir, se combinarán utilizando el operador lógico OR. Así pues, el paquete de datos que tenga una dirección de origen que coincida con el atributo OR de la Dirección de Origen que tenga una dirección de origen que coincida con el atributo de la Dirección del Agente de Origen coincidirá al menos con dichos atributos del filtro de los paquetes TFT. La funcionalidad del GGSN se modifica para ejecutar el proceso de coincidencia de los paquetes de datos entrantes para el enlace descendente a una MS, utilizando los filtros de los paquetes TFT modificados. Se observará que se consigue el mismo efecto mediante la inclusión de dos filtros de paquetes en una TFT, uno con el atributo de la Dirección de Origen definido, y el otro con el atributo definido de la Dirección del Agente de Origen.

El proceso modificado seguido por un GGSN de acuerdo con esta primera versión de la primera realización se muestra en el diagrama de flujo de la figura 5. El proceso se inicia en la etapa 80. En la etapa 82, el GGSN recibe un paquete de datos para el enlace descendente a un MN en particular, teniendo un CoA en la red GPRS. En la etapa 84, el GGSN comprueba la dirección de origen del paquete de datos con respecto a los campos de la Dirección de Origen de las TFT del contexto PDP asociado con la CoA del MN. Si se determina, en la etapa 86, que existe una coincidencia, el proceso continuará hasta la etapa 88, en donde el paquete es transferido al MN, utilizando el contexto PDP que contenga la TFT de coincidencia. El proceso continua entonces hasta la etapa 96 y termina. Esto corresponde a la operación convencional de un GGSN. No obstante, si se determina, en la etapa 86, que no existe ninguna coincidencia, el proceso continua hasta la etapa 90, en donde el GGSN comprueba la dirección de origen del paquete de datos con respecto a los campos de la Dirección del Agente de Origen de las TFT de los contextos PDP asociados con la CoA del MN. Si se determina en la etapa 92, que existe una coincidencia, el proceso continúa hasta la etapa 94, en donde el paquete es transferido al MN, utilizando el contexto PDP que contenga la TFT de coincidencia. El proceso continua entonces a la etapa 96 y concluye. No obstante, si se determina en la etapa 92, que no existe ninguna coincidencia, el proceso continua entonces hasta la etapa 96 y concluye. Se observará que la falta de coincidencia de la dirección de origen del paquete de datos con una TFT, puede dar lugar a que se deposite el paquete de datos, o alternativamente, sea transferido al MN utilizando un contexto PDP sin ninguna TFT asociada, si existiera alguno.

Alternativamente, en una segunda versión de la primera realización, se utilizan los atributos del filtro de paquetes TFT estándar, y se utiliza el procedimiento de la Modificación del Contexto PDP iniciado por la MS, que se describe anteriormente con referencia a la figura 4, para añadir uno nuevo o bien modificar una TFT existente, para añadir un nuevo filtro de paquetes, incluyendo la dirección HA del MN en el atributo de la Dirección de Origen estándar. El nuevo filtro de paquetes sería para la adición a cualquier filtro de paquetes existente para la TFT. Alternativamente, el filtro de paquetes puede reemplazar o modificar un filtro existente de paquetes.

Aunque se ha descrito anteriormente que el contexto PDP activado después de ejecutar el procedimiento de actualización de la conexión de origen MIP puede modificarse, será evidente que cualquier contexto PDP activado puede modificarse para incluir uno nuevo o bien modificar un filtro de paquetes TFT existente, para incluir la dirección HA del MN. Así pues, por ejemplo, el contexto PDP activado para una sesión de comunicación con un CN puede ser modificado para poder tener una TFT asociada con 1) un filtro de paquetes que tenga tanto la dirección de origen del CN como la Dirección HA del MN (utilizando la lista de atributos aumentada) o alternativamente 2) dos filtros de paquetes, uno teniendo la dirección de origen del CN y el otro la Dirección HA del MN (utilizando la lista de atributos aumentada o la estándar). De esta forma, los paquetes enviados por el CN a la HAddr del MN y canalizados a través del HA pueden ser filtrados por el GGSN para el contexto PDP apropiado, así como también los paquetes enviados por el CN directamente a la CoA (o CoCoA) del MN.

Será evidente también que el contexto PDP puede ser activado conjuntamente con un filtro de paquetes TFT asociado, incluyendo la dirección HA del MN utilizando el Procedimiento de Activación de Contexto PDP iniciado por la MS, descrito en la Cláusula 9.2.2 de 3G TS 23.060, aquí incorporado como referencia. Así pues, por ejemplo, puede activarse un contexto PDP para una sesión de comunicación con un CN, y en el procedimiento de activación puede estar asociada una TFT con el contexto PDP que tenga: 1) un filtro de paquetes que tenga la dirección de origen del CN y la Dirección HA del MN (utilizando la lista de atributos aumentada) o alternativamente, 2) dos filtros de paquetes, uno teniendo la dirección de origen del CN y el otro la Dirección HA del MN (utilizando la lista de atributos aumentada o estándar). De esta forma, los paquetes enviados por el CN a la HAddr del MN y canalizados a través del HA pueden ser filtrados por el GGSN al contexto PDP apropiado, así como también los paquetes enviados por el CN directamente a la CoA (o CoCoA) del MN.

Será evidente que en la primera realización, los eventos distintos a los que el MN ejecute un procedimiento de conexión de origen podrán utilizarse para hacer disparar la creación o modificación de los filtros de los paquetes TFT según lo descrito. En general, cualquier nodo de la red GPRS podrá detectar que un paquete para el MN podrá ser canalizado, y por tanto podrá dirigir al MN o bien configurar la creación o modificación de los filtros de los paquetes TFT según lo descrito.

Segunda realización

De acuerdo con una segunda realización de la presente invención, que se aplica a los MN que tengan una HAddr IPv6, el HA del MN se modifica para poder incluir la dirección IP del CN en un encabezado de extensión de las Opciones de Salto-Salto IPv6 del paquete IPv6 de encapsulación para todos los paquetes de datos de canalización hacia el MN. La figura 6A muestra la estructura del paquete de datos de encapsulación. El encabezado IPv6 básico 100 llega en primer lugar. La existencia del encabezado 102 de extensión de las Opciones de Salto-Salto IPv6 está indicada, de acuerdo con el IPv6 estándar (RFC2460), mediante la inserción de un cero en el campo del Encabezado Siguiente del IPv6 del encabezado básico 100 IPv6. El encabezado 102 de extensión de las Opciones de Salto-Salto sigue entonces inmediatamente al encabezado básico IPv6 100. Finalmente, la carga útil 104, es decir el encabezado de la capa superior tal como TCP o UDP y el paquete de datos encapsulados, sigue al encabezado 102 de extensión de las Opciones de Salto-Salto. Figura 68, mostrando la estructura del encabezado 102 de extensión de las Opciones de Salto-Salto. Los campos del EncabezadoSiguiente y HdrExtLen del encabezado 102 de extensión de las Opciones de Salto-Salto se omiten en aras de la claridad. La dirección IP del CN se incluye en una poción codificada de Tipo-Longitud-Valor (TLV) en el encabezado 102 de extensión de las Opciones de Salto-Salto. Así pues, el numero (8 bits) del Tipo de Opciones adecuado 106 se utiliza para identificar el tipo de opción (es decir, la especificación de la HAddr del MN para un paquete canalizado a través de la HA del MN), seguido por la Longitud de Datos de Opción 108 (que depende de la longitud de la dirección de CN) seguido por los propios Datos de Opción, es decir, la dirección
CN 110.

En esta realización, el GGSN está habilitado para IPv6, y examina el encabezamiento de la extensión Salto-Salto de cualquier paquete IPv6 recibido que tenga dicho encabezado. Se observará que puesto que el canal de la HA se extiende en todo el recorrido hasta el MN, el GGSN es un nodo intermedio y de acuerdo con la especificación IPv6 (RFC 2460), el GGSN tiene que examinar el encabezado de extensión de Salto-Salto. Al revés, se observará que de acuerdo con la especificación IPv6 (RFC 2460), el GGSN no tiene que examinar cualquier otro encabezado de extensión IPv6, puesto que es un nodo intermedio. Además de ello, el GGSN está modificado para intentar correlacionar la dirección IP del CN identificadla en un paquete de datos IPv6 que contenga un encabezado de extensión de Salto-Salto con los filtros de los paquetes TFT, almacenados para los contextos PDP asociados con la CoA del MN, y si se encuentra una coincidencia, transferir los paquetes de datos, en la forma apropiada. El proceso seguido por el GGSN se muestra en la figura 7. El proceso se inicia en la etapa 120. En la etapa 122, el GGSN recibe un paquete de datos para el enlace descendente hasta un MN en particular, que tenga una CoA en la red GPRS. En la etapa 124, el GGSN examina el encabezado de extensión de las Opciones de Salto-Salto del paquete recibido. En la etapa 126, el GGSN comprueba la dirección CN especificada en el encabezado de extensión de las Opciones de Salto-Salto con respecto a los campos de la Dirección de Origen de las TFT de los contextos PDP asociados con la dirección IP del MN (es decir, su CoA). Si se determina, en la etapa 128, que existe una coincidencia, el proceso continuará hasta la etapa 130, en donde el paquete se transferirá al MN, utilizando el contexto PDP que contenga la TFT de coincidencia. El proceso continua entonces hasta la etapa 132 y concluye. No obstante, si de determina en la etapa 128 que no existe ninguna coincidencia, el proceso continua entonces hasta la etapa 132 y concluye.

El GGSN intentará también buscar la coincidencia de la dirección de origen del paquete de datos recibido con los campos de la Dirección de Origen de las TFT del contexto PDP asociados con el MN de acuerdo con la funcionalidad GGSN estándar. Así pues, el paquete de datos que tenga una dirección de origen coincidente con el atributo OR de la Dirección de Origen, que tenga una dirección IP especificada en un Encabezado de Opciones de Salto-Salto, siendo la dirección IP del nodo CN, coincidirá al menos en los atributos del filtro del paquete TFT, y se enrutarán al canal GTP correspondiente al contexto PDP apropiado. Se observará el fallo en la coincidencia del paquete de datos con una TFT podrá dar lugar a depositar el paquete de datos, o alternativamente, a la transferencia al MN, utilizando un contexto PDP sin TFT asociada, en caso de existir alguna. Opcionalmente, después de recibir el paquete de datos canalizado, el MN puede entonces modificar o crear un nuevo contexto PDP, para habilitar a los paquetes de datos canalizados para su transferencia por el GGSN al MN, según lo descrito anteriormente en relación con la primera realización.

En una variante de la segunda realización, el HA del MN se modifica para incluir selectivamente la dirección IP del CN en un encabezado de extensión de las Opciones de Salto-Salto IPv6 del paquete IPv6 de encapsulado, para los paquetes de datos canalizados hacia el MN. La inclusión se ejecuta solamente cuando el HA detecte que el MN está proporcionando un servicio en una red GPRS. Así pues, los encabezados de procesamiento de a) el HA incluyendo un encabezado de extensión de las Opciones de Salto-Salto en el paquete de datos canalizados, y b) los nodos intermedios del trayecto hacia el MN (incluyendo el GGSN), examinando el encabezado de extensión de las Opciones de Salto-Salto se eliminan cuando no sean necesarios.

Tercera realización

De acuerdo con una tercera realización de la presente invención, se estable siempre un contexto PDP sin TFT asociada cuando un el MN habilitado con MIP se encuentra alejado del origen en una red GPRS. Así pues, a la recepción del paquete de datos, el GGSN intentará buscar la coincidencia del paquete con los contextos PDP con las TFT asociadas, pero si falla esto, el paquete será enrutado utilizando el contexto PDP sin TFT asociadas. Así pues, el paquete canalizado a través del HA del MN será transferido por el GGSN al MN en donde podrá ser encapsulado. El MN podrá entonces asociar el paquete con una sesión de comunicaciones existente, en caso de existir alguna, mediante el examen de la dirección de origen del paquete encapsulado. El MN puede entonces modificar o crear un nuevo contexto PDP para habilitar a los paquetes de datos canalizados para ser transferidos por el GGSN al MN, según lo descrito anteriormente en relación con la primera realización.

Las soluciones de la primera y segunda realizaciones son preferibles a la solución de la tercera realización, puesto que no pueden soportarse los QoS en esta solución, porque el contexto PDP no tiene TFT asociadas. Así mismo, la solución desperdicia recursos del operador puesto que el canal GTP y el contexto PDP tienen que ser mantenidos para que el tráfico sea enrutado posiblemente a través del HA del MN, a pesar de que son un contexto PDP y el canal GTP correspondiente ya establecido para la sesión de comunicaciones con el CN. No obstante, la solución puede ser útil para algunos servicios sin requisitos específicos del QoS, tales como los servicios de Clase de Fondo y los servicios ejecutados no en tiempo real.

Cuarta realización

De acuerdo con una cuarta realización de la presente invención, el procedimiento de canalización del HA se modifica en la forma expuesta a continuación. En primer lugar, el HA no direcciona los paquetes de datos canalizados al CoA del MN, sino a la dirección del GGSN en la red GPRS. Se describirá en forma abreviada la forma en que el HA puede estar provisto con la dirección del GGSN en caso de que ya la conozca. En segundo lugar, el HA incluye la dirección CN en un Encabezado de Opciones de Destino IPv6, que puede ser leída por el GGSN a la llegada del paquete de datos canalizado. En tercer lugar, el CoA del MN está incluido en un encabezado de extensión del Tipo 0 del Encabezado de Enrutamiento IPv6 del paquete canalizado. Este Encabezamiento de Enrutamiento habilita al paquete IPv6 para ser enrutado a través de una pluralidad de nodos en varias direcciones, comenzando la entrega a la dirección de destino del paquete (en este caso el GGSN), y a continuación siendo reenviado a cada nodo correspondiente a una lista de direcciones de enrutado adicionales en el Encabezado de Enrutamiento (en este caso justamente el CoA del MN).

La figura 8A muestra la estructura del paquete de datos encapsulado. El encabezado básico IPv6 140 llega en primer lugar. La existencia del Encabezado de Enrutamiento IPv6 (Tipo 0) 142 se indica, de acuerdo con el IPv6 estándar (RFC 2460), en el campo del Encabezado Siguiente IPv6 del encabezado básico IPv6 100. Se observará que la dirección de destino en el encabezado básico IPv6 140 es la dirección del GGSN. El encabezado de Enrutamiento IPv6 (Tipo 0) 142 sigue inmediatamente al encabezamiento IPv6 básico 140. La existencia del encabezado 144 de extensión de la Opción de Destino IPv6 se encuentra indicada, de acuerdo con el IPv6 estándar (RFC 2460), en el campo del Encabezado Siguiente IPv6 142 (Tipo 0). El encabezado de extensión 144 de la Opción de Destino IPv6 sigue inmediatamente al Encabezado de Enrutamiento IPv6 (Tipo 0) 142. Finalmente, la carga útil 140, es decir el encabezado de la capa superior tal como TCP o UDP y el paquete de datos encapsulados, sigue al encabezado de extensión 144 de la Opción de Destino.

\newpage

La figura 8B muestra la estructura de encabezado 144 de extensión de la Opción de Destino. El formato de este encabezado de extensión está descrito en el Borrador de Internet MIPv6 en la Cláusula 6.3. El Encabezado Siguiente y los campos Dirección-Extensión-Longitud del encabezado de extensión 144 de la Opción de Destino se omiten en aras de la claridad. La dirección del CN está incluida en una opción codificada del Tipo-Longitud-Valor (TLV) en el encabezado de extensión 144 de la Opción de Destino. Así pues, el numero 148 del Tipo de Opciones se utiliza para identificar el tipo de opción (en este caso 201 según lo especificado en el MIPv6) seguido por la Longitud de Datos de Opción 150 (que depende de la longitud de la dirección del CN) seguido por los propios Datos de Opción, es decir, la dirección CN 152.

La figura 8C muestra la estructura del encabezado de extensión 142 del Encabezado de Enrutamiento (Tipo 0). El formato de este encabezamiento de extensión está descrito en el IPv6 (RFC 2460). El Encabezado Siguiente y los campos de Dirección-Extensión-Longitud del encabezado de extensión 142 del Encabezado de Enrutamiento (Tipo 0) se omiten en aras de la claridad. El campo 154 del Tipo de Enrutamiento (es decir, 0 en este caso) sigue a continuación, seguido por el campo de Segmentos de Izquierda, que se inicializan con una configuración de 1 mediante el HA (este realiza la cuenta atrás hasta 0 conforme se envía el paquete de datos desde el GGSN al CoA del MN). Siguen entonces un campo reservado (configurado a 0) y a continuación el CoA del propio MN.

En esta realización, el GGSN está habilitado con IPv6, y examina el encabezado de extensión 144 de la Opción de Destinos del paquete IPv6 recibido antes de enviarlo de acuerdo con el encabezado de extensión 142 del Encabezado de Enrutamiento (tipo 0). Se observará que proporcionando la dirección del GGSN como la dirección de destino, el paquete canalizado será enviado en primer lugar al GGSN, el cual será un nodo de destino (en lugar de un nodo intermedio como en la tercera realización), y siendo capaz por tanto de leer el encabezado de extensión 144 de la Opción de Destinos. Además de ello, el GGSN se modifica para intentar realizar una correlación de la dirección del CN, identificado en el encabezado de la Opción de Destinos, a los filtros de los paquetes TFT almacenados para los contextos PDP asociados con la CoA del MN, que se incluyen en la Opción de Tipo 0 del Encabezado de Enrutamiento IPv6. Si se encuentra una coincidencia, el GGSN transferirá los paquetes de datos al canal GTP asociado con el contexto PDP apropiado en la CoA del MN en la forma correspondiente.

El proceso seguido por el GGSN se muestra en la figura 9. El proceso se inicia en la etapa 172. En la etapa 172, el GGSN recibe un paquete de datos con un Encabezado de Enrutamiento IPv6 de Tipo 0, indicando que el paquete es para el enlace descendente hacia la CoA de un MN en particular teniendo un CoA en la red GPRS. En la etapa 174, el GGSN examina el encabezado de extensión de la Opción de Destinos del paquete recibido. En la etapa 176, el GGSN comprueba la dirección CN especificada en el encabezado de extensión de la Opción de Destinos, con respecto a los campos de Direcciones de Origen de los contextos TFT de DPD asociados con la CoA del MN. Si se determina, en la etapa 178, que existe una coincidencia, el proceso continua a la etapa 180, en donde el paquete es transferido al MN, utilizando el contexto PDP que contenga la TFT de coincidencia. El proceso continúa después con la etapa 182 y concluye. No obstante, si se determina en la etapa 178, que no existe ninguna coincidencia, el proceso continúa entonces a la etapa 182 y concluye.

El GGSN intentará también realizar la coincidencia de la dirección de origen del paquete de datos recibido con los campos de la Dirección de Origen de las TFT de los contextos PDP asociados con el MN, de acuerdo con la funcionalidad GGSN estándar. Así pues, un paquete de datos que tenga una dirección de origen que coincida con el atributo OR de la Dirección de Origen, teniendo una dirección IP especificada en el Encabezado de Opción de Destinos, coincidente con el atributo de la Dirección IP de Origen, siendo la dirección IP del CN, coincidirá al menos con dichos atributos del filtro de paquetes TFT, y se enrutará al canal GTP correspondiente al contexto PDP apropiado. Opcionalmente, el MN puede entonces modificar o crear un nuevo contexto PDP para habilitar los paquetes de datos canalizados a transferir por el GGSN al MN, según se ha descrito anteriormente en relación con la primera realiza-
ción.

No obstante, según lo indicado anteriormente, este procedimiento requiere que el HA conozca o bien que esté provisto con la dirección del GGSN en la red GPRS. El HA puede conocer la dirección del GGSN en la red GPRS con motivo de una configuración comercial entre las dos redes, tal como un acuerdo de itineración por ejemplo. No obstante, si no es así, puede estar provisto con la dirección de la forma siguiente. Preferiblemente al mismo tiempo de ejecutar un procedimiento de actualización de conexión de origen, aunque posiblemente después, el MN puede enviar un mensaje o preferiblemente dar ordenes al propio GGSN para enviar un mensaje al HA conteniendo la dirección IP del GGSN. El MN puede dar orden a su GGSN para enviar dicho paquete utilizando las Opciones de Configuración PDP, las cuales están descritas en la Cláusula 9.2.2 de SG TS 23.060, que se incorporan aquí como referencia. Las Opciones de Configuración PDP contienen parámetro PDP opcionales, en donde el GGSN puede transferir a una estación MS. El envío de estos parámetros PDP opcionales puede estar solicitado por el MN en el mensaje de Petición de Contexto PDP de Activación, utilizado para establecer un contexto PDP para su utilización al enviar la actualización de conexión de origen al HA, al realizarse el desplazamiento primero del HN hacia la red GPRS.

En una variante de la cuarta realización, la funcionalidad del HA se modifica para utilizar selectivamente el procedimiento descrito anteriormente, solo cuando el HA es informado por el MN de que está siendo provisto con el servicio en una red GPRS.

Es evidente que la presente invención es aplicable a redes distintas a la red GPRS. En general, se aplica a cualquier red en donde un nodo de pasarela pueda necesitar la selección de un canal a partir de una pluralidad de canales (sean contextos PDP o lo contrario), para transferir paquetes del enlace descendente hacia un nodo, sea un usuario o un nodo del lado de la red.

Es evidente también que la presente invención es aplicable a situaciones en donde el nodo (sea un nodo de usuario o un nodo de red) puede recibir paquetes canalizados por razones distintas a ser un MN habilitado con MIP. En general, la presente invención se aplica cuando los paquetes puedan ser canalizados entre redes o subredes, en donde el nodo de la pasarela pueda necesitar el tener que seleccionar un canal a partir de una pluralidad de canales para transferir paquetes del enlace descendente hacia un nodo, y en donde el canal se extienda más allá del nodo o nodos de la pasarela de la red de destino. Por ejemplo, la presente invención tiene aplicación en las Redes Privadas Virtuales, utilizando el Protocolo de Canalización de Capa 2 (L2TP) o bien otros protocolos de canalización.

La presente invención es aplicable también a situaciones en donde los nodos de la pasarela necesiten la ejecución del filtrado de paquetes en general, y/o funciones de cortafuegos para la protección contra el acceso no autorizado del servicio/operador y/o ataques contra el servicio.

Claims (21)

1. Un método para habilitar un nodo de pasarela (12) de una primera red de datos (10) de conmutación de paquetes, para seleccionar un primer canal, para transferir un paquete de datos canalizados a una dirección de protocolo de datos de paquetes de destino, de un servicio provisto de nodos móviles (18) en la primera red (44), estando el nodo de la pasarela (12) configurado para seleccionar el primer canal de una pluralidad de canales, estando cada uno para transferir paquetes de datos a la dirección del protocolo de datos por paquetes de destino del nodo móvil (18), habiéndose enviado el paquete de datos canalizados desde un nodo correspondiente y canalizado por un nodo de canalización (48) de una segunda red externa a la primera red (44), comprendiendo el método la etapa en que el nodo (12 de la pasarela selecciona el primer canal por la coincidencia de igualación de la dirección del protocolo de datos por paquetes asociada con el paquete de datos canalizados recibidos por el nodo de la pasarela (12) a un primer filtro de paquetes de datos asociado con el primer canal, por lo que el método está caracterizado porque tiene la etapa de:

la asociación del nodo de canalización (48) con el paquete de datos canalizados, de una dirección de protocolo de datos por paquetes del nodo correspondiente.

2. Un método de acuerdo con la reivindicación 1, en donde los paquetes de datos canalizados es un paquete de datos de la versión 6 del Protocolo de Internet (IPv6), y en donde la dirección del protocolo de datos por paquetes del nodo correspondiente está asociada con el paquete de datos canalizados, por la inclusión en un encabezado de extensión de Salto-Salto del paquete de datos canalizados.

3. Un método de acuerdo con la reivindicación 1, en donde la dirección del protocolo de datos de los paquetes del nodo correspondiente está asociado con el paquete de datos canalizados mediante su inclusión en un encabezamiento de la extensión de Opción de Destino del paquete de datos canalizados.

4. Un método de acuerdo con la reivindicación 3, en donde el nodo de canalización está diseccionado al paquete de datos canalizados a la dirección del protocolo de datos por paquetes del nodo de la pasarela (12), y en donde la dirección del protocolo de datos de paquetes de destino del nodo (18) móvil está asociada con el paquete de datos canalizados.

5. Un método de acuerdo con la reivindicación 4, en donde el paquete de datos canalizado es un paquete de datos de la versión 6 (IPv6) del Protocolo de Internet, y la dirección del protocolo de datos de paquetes de destino del nodo móvil (18) está asociada con el paquete de datos canalizados enviados al nodo de la pasarela (12), estando incluidos en el encabezamiento de la Opción de Tipo 0 de Enrutamiento del paquete de datos canalizado.

6. Un método de acuerdo con cualquiera de las reivindicaciones 1 a 5, en donde la movilidad del nodo móvil (18) entre las redes o sub-redes está soportada utilizando los estándares del Protocolo de Internet Móvil (MIP), y en donde el nodo de canalización (48) es un agente de origen (HA) del nodo móvil.

7. Un método de acuerdo con las reivindicaciones 1 a 6, en donde la primera red (44) cumple con los estándares del Servicio General de Radio de Paquetes (GPRS) y la pluralidad de canales corresponden a una pluralidad de contextos del protocolo de datos por paquetes en la primera red (44).

8. Un nodo de pasarela (12) de una primera red de datos de paquetes conmutados, estando configurado el nodo (12) de la pasarela para seleccionar un primer canal para transferir un paquete de datos canalizados a una dirección del protocolo de datos de paquetes de destino de un servicio provisto con un nodo móvil (18) en la primera red (44), siendo seleccionado el primer canal de una pluralidad de canales, estando cada uno para transferir los paquetes de datos a la dirección del protocolo de datos de paquetes de destino del nodo móvil (18), en donde el paquete de datos canalizados se habrá enviado desde un nodo correspondiente y canalizados por un nodo de canalización (48) de una segunda red (42) externa a la primera red (44), caracterizado porque:

el nodo (12) de la pasarela está configurado para seleccionar el primer canal por la coincidencia de una dirección del protocolo de datos de paquetes del nodo correspondiente, asociada con el paquete de datos recibido por el nodo de la pasarela (12), a un primer filtro de paquetes de datos asociado con el primer canal.

9. Un nodo (12) de pasarela de acuerdo con la reivindicación 8, en donde el paquete de datos canalizados es un paquete de datos de la versión 6 (IPv6) del Protocolo de Internet, y en donde la dirección del protocolo de datos del paquete del nodo correspondiente está asociada con el paquete de datos canalizados por estar incluida en un encabezado de extensión de Salto-Salto del paquete de datos canalizados.

10. Un nodo de pasarela (12) de acuerdo con la reivindicación 8, en donde la dirección de protocolo de datos por paquetes del nodo correspondiente está asociada con el paquete de datos canalizados que se encuentran incluidos en un encabezado de extensión de la Opción de Destino del paquete de datos canalizados.

11. Un nodo de pasarela (12) de acuerdo con la reivindicación 10, en donde el paquete de datos canalizados está diseccionado a la dirección del protocolo de datos del paquete del nodo de la pasarela (12), y la dirección del protocolo de datos del paquete de destino del nodo móvil (18) está asociada con el paquete de datos canalizados.

12. Un nodo de pasarela (12) de acuerdo con la reivindicación 11, en donde el paquete de datos canalizados es un paquete de datos de versión 6 (IPv6) del Protocolo de Internet, y la dirección del protocolo de datos del paquete de destino del nodo móvil (18) está asociada con el paquete de datos canalizados enviado al nodo de la pasarela (12), por estar incluido en un encabezado de la Opción de tipo 0 de la pasarela del paquete de datos canalizados.

13. Un nodo de pasarela (12) de acuerdo con cualquiera de las reivindicaciones 8 a 12, en donde la movilidad del nodo móvil (18) entre las redes o sub-redes está soportada utilizando los estándares del Protocolo de Internet Móvil (MIP), y en donde el nodo de canalización (48) es un agente de origen (HA) del nodo móvil (18).

14. Un nodo de pasarela de acuerdo con cualquiera de las reivindicaciones 8 a 13, en donde la primera red (44) cumple con los estándares del Servicio General de Radio de Paquetes, y en donde la pluralidad de los canales corresponde a una pluralidad de contextos del protocolo de datos del paquete en la primera red (44).

15. Un nodo de canalización (48) de una segunda red (42) de datos conmutados por paquetes externa a una primera red (44) de datos conmutados por paquetes, en donde el nodo de canalización (48) está configurado para canalizar un paquete de datos enviado desde un nodo correspondiente a un nodo móvil (18) provisto con servicio en la primera red de datos (44), en donde la primera red de datos (44) comprende un nodo de pasarela (12) dispuesto para seleccionar un primer canal para transferir los paquetes de datos canalizados a una dirección del protocolo de datos de paquetes de destino de un nodo móvil (18), estando configurado el nodo móvil (12) para seleccionar el primer canal de una pluralidad de canales, estando cada uno para transferir paquetes de datos a la dirección del protocolo de datos de paquetes de destino del nodo móvil (18), en donde el nodo de la pasarela (12) está dispuesto para seleccionar el primer canal por la coincidencia de la dirección del protocolo de datos de paquetes asociada con el paquete de datos canalizados recibidos por el nodo de la pasarela (12) a un primer filtro de paquetes de datos asociado con el primer canal, caracterizado porque el nodo de canalización (48) está configurado para asociarse, con el paquete de datos canalizados, con una dirección del protocolo de datos del paquete del nodo correspondiente.

16. Un nodo de canalización (48) de acuerdo con la reivindicación 15, en el que el paquete de datos canalizados es un paquete de datos de la versión 6 (IPv6) del Protocolo de Internet, y en donde la dirección del protocolo de datos de paquetes del nodo correspondiente está asociada con el paquete de datos canalizados por estar incluida en un encabezado de extensión de Salto-Salto del paquete de datos canalizados.

17. Un nodo de canalización (48) de acuerdo con la reivindicación 16, en el que la dirección del protocolo de datos del paquete del nodo correspondiente está asociada con el paquete de datos canalizados, por estar incluida en el encabezado de extensión de la Opción de Destino del paquete de datos canalizados.

18. Un nodo de canalización (48) el nodo de canalización (48) asocia la dirección del protocolo de datos del paquete de destino del nodo móvil (18) con el paquete de datos canalizados y direcciona el paquete de datos canalizado a la dirección del protocolo de datos del paquete del nodo de la pasarela (12).

19. Un nodo de canalización de acuerdo con la reivindicación 18, en el que el paquete de datos canalizados es un paquete de datos de versión 6 (IPv6) del Protocolo de Internet, y en donde la dirección del protocolo de datos de paquetes de destino del nodo móvil (18) está asociada con el paquete de datos canalizados enviado al nodo de la pasarela (12) que está incluido en un encabezado de la Opción de Tipo 0 del Encabezado de Enrutamiento del paquete de datos canalizados.

20. Un nodo de canalización (48) de acuerdo con cualquiera de las reivindicaciones 15 a 19, en donde la movilidad del nodo móvil (18) entre las redes o sub-redes está soportada con el uso de los estándares del Protocolo de Internet Móvil (MIP), y en donde el nodo de canalización (48) es un agente de origen (HA) del nodo móvil (18).

21. Un nodo de canalización (48) de acuerdo con cualquiera de las reivindicaciones 15 a 20, en el que la primera red cumple con los estándares del Servicio General de Radio de Paquetes, y en donde la pluralidad de los canales se corresponden con una pluralidad de contextos del protocolo de datos de paquetes en la primera red (44).