ES2280780T3 - Metodo para una pasarela de seleccion de un canal para transferir paquetes de datos. - Google Patents
Metodo para una pasarela de seleccion de un canal para transferir paquetes de datos. Download PDFInfo
- Publication number
- ES2280780T3 ES2280780T3 ES03750969T ES03750969T ES2280780T3 ES 2280780 T3 ES2280780 T3 ES 2280780T3 ES 03750969 T ES03750969 T ES 03750969T ES 03750969 T ES03750969 T ES 03750969T ES 2280780 T3 ES2280780 T3 ES 2280780T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- packet
- address
- node
- protocol
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/04—Wireless resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/14—Multichannel or multilink protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/16—Gateway arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
- Small-Scale Networks (AREA)
- Computer And Data Communications (AREA)
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(10), estando el nodo de la pasarela (12) 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 (18), siendo ejecutada la selección mediante la coincidencia de la dirección del protocolo de datos de los paquetes, asociados con un paquete de datos recibido por el nodo de la pasarela (12), a uno o más filtros de paquetes de datos, asociados con la pluralidad de canales, estando caracterizado el método por las etapas de:: a) la detección de un evento de disparo que indique que el nodo de la pasarela está adaptado para recibir un paquetede datos canalizado por medio de un nodo de canalización (48) de una segunda red externa de datos de paquetes conmutados a la primera red (10); y b) en repuesta a la detección, configurar para un primera dirección del protocolo de datos por paquetes para ser incluida en un primer filtro de paquetes de datos asociados con el primer canal, en donde la primera dirección del protocolo de datos por paquetes, al asociarse con un paquete de datos recibido por el nodo de la pasarela (12), será indicativo de que el paquete de datos haya sido canalizado a través del nodo de canalización, en el que el primer filtro del paquete de datos será para el uso del nodo de la pasarela (12) cuando se realice la selección a partir de la pluralidad de canales para transferir los paquetes de datos al nodo móvil (18) en la dirección del protocolo de datos de los paquetes de destino.
Description
Método para una pasarela de selección de un
canal para transferir paquetes de datos.
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.
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
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
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 trafico 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,
video). 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.
De acuerdo con un primer 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, siendo ejecutada la
selección mediante la coincidencia de la dirección del protocolo de
datos de los paquetes, asociados con un paquete de datos recibido
por el nodo de la pasarela, a uno o más filtros de paquetes de
datos, asociados con la pluralidad de canales, comprendiendo el
método:
- a)
- la detección de un evento de disparo que indique que el nodo de la pasarela está adaptado para recibir un paquete de datos canalizado por medio de un nodo de canalización de una segunda red externa de datos de paquetes conmutados a la primera red; y
- b)
- en repuesta a la detección, configurar para un primera dirección del protocolo de datos por paquetes para ser incluida en un primer filtro de paquetes de datos asociados con el primer canal, en donde la primera dirección del protocolo de datos por paquetes, al asociarse con un paquete de datos recibido por el nodo de la pasarela, será indicativo de que el paquete de datos haya sido canalizado a través del nodo de canalización, en el que el primer filtro del paquete de datos será para el uso del nodo de la pasarela cuando se realice la selección a partir de la pluralidad de canales para transferir los paquetes de datos al nodo móvil en la dirección del protocolo de datos de los paquetes de destino.
En una realización en donde el nodo de la
pasarela está configurado para seleccionar a partir de la pluralidad
de canales mediante la coincidencia de una dirección de origen de
un paquete de datos recibido, con respecto a uno o más filtro de
paquetes de datos asociados con la pluralidad de canales, la
primera dirección del protocolo de datos del paquete es la
dirección del protocolo de datos del paquete del nodo de
canalización. Así pues, el primer problema puede ser resuelto con o
sin la modificación de la funcionalidad estandarizada del nodo de
la pasarela.
Preferiblemente, el evento de disparo se detecta
por el nodo móvil, y el nodo móvil configura la inclusión de la
primera dirección del protocolo de datos del paquete en el primer
filtro de paquetes de datos. Preferiblemente, el nodo móvil tiene
una dirección de origen del protocolo de datos del paquete en la
segunda red, y el evento de disparo es el nodo móvil que registra
su dirección de destino del protocolo de datos del paquete en el
nodo de canalización, de forma que los paquetes de datos
direccionados por el nodo móvil en su dirección de origen del
protocolo de datos de los paquetes pueden canalizarse por el nodo de
canalización hacia el nodo móvil como su dirección de destino del
protocolo de datos de los paquetes.
Los aspectos adicionales de la presente
invención incluyen un nodo de pasarela configurado de acuerdo con
el método del primer aspecto anteriormente descrito.
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:
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.
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 trafico 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, video). 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.
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
- Numero 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 caos 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
- Numero 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 Encabezado Siguiente 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 identificada 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 trafico
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.
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 realizació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 (24)
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(10), estando el nodo de la pasarela (12)
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 (18), siendo ejecutada la selección mediante la coincidencia
de la dirección del protocolo de datos de los paquetes, asociados
con un paquete de datos recibido por el nodo de la pasarela (12), a
uno o más filtros de paquetes de datos, asociados con la pluralidad
de canales, estando caracterizado el método por las etapas
de:
- a)
- la detección de un evento de disparo que indique que el nodo de la pasarela está adaptado para recibir un paquete de datos canalizado por medio de un nodo de canalización (48) de una segunda red externa de datos de paquetes conmutados a la primera red (10); y
- b)
- en repuesta a la detección, configurar para un primera dirección del protocolo de datos por paquetes para ser incluida en un primer filtro de paquetes de datos asociados con el primer canal, en donde la primera dirección del protocolo de datos por paquetes, al asociarse con un paquete de datos recibido por el nodo de la pasarela (12), será indicativo de que el paquete de datos haya sido canalizado a través del nodo de canalización, en el que el primer filtro del paquete de datos será para el uso del nodo de la pasarela (12) cuando se realice la selección a partir de la pluralidad de canales para transferir los paquetes de datos al nodo móvil (18) en la dirección del protocolo de datos de los paquetes de destino.
2. Un método de acuerdo con la reivindicación
1, en el que el nodo de la pasarela (12) está configurado para
seleccionar a partir de la pluralidad de canales, mediante la
coincidencia de una dirección de origen de un paquete de datos
recibido para uno o mas filtros de paquetes de datos asociados con
la pluralidad de canales, y en el que la primera dirección de
protocolo de datos del paquete es la dirección del protocolo de
datos del paquete del nodo de canalización (48).
3. Un método de acuerdo de cualquier
reivindicación anterior, en el que el evento de disparo se detecta
por el nodo móvil (18), y el nodo móvil (18) se configura para la
inclusión de la primera dirección del protocolo de datos del
paquete en el primer filtro del paquete de datos.
4. Un método de acuerdo con la reivindicación 3,
en el que el nodo móvil (18) tiene una dirección de origen del
protocolo de datos del paquete en la segunda red (20), y en el que
el evento de disparo es el nodo móvil (18) que registra su
dirección de protocolo de datos del paquete de destino, con el nodo
de canalización, de forma que los paquetes de datos direccionados
hacia el nodo móvil (18) en su dirección de protocolo de datos del
paquete de origen pueda canalizarse mediante el nodo de canalización
hacia el nodo móvil (18) en su dirección de protocolo de datos de
paquetes de destino.
5. Un método de acuerdo con la reivindicación 3,
en el que el evento de disparo es el nodo móvil (18) que recibe un
paquete de datos canalizado enviado desde el nodo de la pasarela
(12) a través de un segundo canal que no tiene un filtro de
paquetes de datos asociados.
6. Un método de acuerdo con cualquier
reivindicación anterior, en el que la movilidad del nodo móvil (18)
entre las redes o subredes, está soportada mediante la utilización
de los estándares del Protocolo de Internet Móvil (MIP), siendo el
nodo de canalización (48) un agente de origen (HA) del nodo móvil, y
la dirección del protocolo de datos del paquete de destino
incorpora el cuidado de direcciones (CoA, CoCoA) del nodo móvil
(18).
7. Un método de acuerdo con la reivindicación 6,
en el que la primera dirección del protocolo de datos del paquete
es la dirección del agente de origen (HA) del nodo móvil (18) en la
segunda red (20).
8. Un método de acuerdo con cualquier
reivindicación anterior, en el que el primer filtro de los paquetes
ya habría sido creado, con antelación a la etapa b), para habilitar
el nodo de la pasarela (12), para seleccionar el primer canal para
transferir los paquetes de datos enviados por un nodo
correspondiente involucrado en una sesión de comunicaciones con el
nodo móvil, y en la etapa b), el primer filtro de los paquetes de
datos se modifica para incluir la primera dirección del protocolo
de datos de los paquetes.
9. Un método de acuerdo con la reivindicación 8,
en el que la primera dirección del protocolo de datos de los
paquetes reemplaza a la dirección del protocolo de paquetes de datos
del nodo correspondiente en el primer filtro de paquetes de
datos.
10. Un método de acuerdo con la reivindicación
8, en el que la primera dirección del protocolo de datos del
paquete está sumada al primer filtro del paquete de datos, el cual
comprende también una dirección del protocolo de paquetes de datos
del nodo correspondiente.
\newpage
11. Un método de acuerdo con cualquiera de las
reivindicaciones 1 a 10, en el que el primer filtro de paquetes se
crea nuevamente en la etapa b).
12. Un método de acuerdo con cualquier
reivindicación anterior, en el que la primera red (10) cumple con
los estándares del Servicio General de Radio de Paquetes (GPRS), y
en donde la pluralidad de canales corresponde a una pluralidad de
contextos de protocolos de datos de paquetes en la primera red
(10).
13. Un nodo de pasarela (12) de una primera red
de datos de paquetes conmutados (10), en el que el nodo de la
pasarela (12) está configurado para seleccionar un canal, para
transferir un paquete de datos a una dirección de destino de los
datos del paquete de un servicio provisto con nodo móvil en la
primera red (10), desde una pluralidad de canales, estando los
mismos para transferir los paquetes de datos a la dirección de
destino del protocolo de datos de los paquetes del nodo móvil (18),
ejecutándose la selección mediante la coincidencia de una dirección
del protocolo de datos del paquete, asociados con un paquete de
datos recibido por el nodo de la pasarela, a uno o más filtros de
paquetes de datos asociados con la pluralidad de canales,
caracterizado porque, en respuesta a la
detección de un evento de disparo indicando que el nodo de la
pasarela (12) está adaptado para recibir un paquete de datos
canalizados a través de un nodo de canalización (48) de una segunda
red de datos de paquetes conmutados (20) exterior a la primera red
(10), estando configurado el nodo de la pasarela (12) para que sea
capaz de seleccionar un primer canal a partir de la pluralidad de
canales, mediante la coincidencia de una dirección del protocolo de
datos de los paquetes, asociados con un paquete de datos recibidos,
a una primera dirección del protocolo de datos del paquete incluidos
en una primer filtro de datos asociados con el primer canal, en el
que la primera dirección del protocolo de datos de los paquetes es
indicativo de que el paquete de datos se haya canalizado a través
del nodo de canalización (48).
14. Un nodo de pasarela (12) de acuerdo con la
reivindicación 13, en el que el nodo de la pasarela (12) está
configurado para seleccionar a partir de una pluralidad de canales,
mediante la coincidencia de una dirección de origen de un paquete
de datos recibidos a uno o más filtros de paquetes de datos
asociados con la pluralidad de canales, y en el que la primera
dirección del protocolo de datos del paquete es la dirección del
protocolo de datos del paquete del nodo de canalización (48).
15. Un nodo de pasarela (12) de acuerdo con la
reivindicación 13 ó 14, en el que el evento de disparo se detecta
por el nodo móvil (18), y el nodo de la pasarela (12) recibe
ordenes del nodo móvil (18) para incluir la primera dirección del
protocolo de datos del paquete en el primer filtro del paquete de
datos.
16. Un nodo de pasarela (12) de acuerdo con la
reivindicación 15, en el que el nodo móvil (18) tiene una dirección
de protocolo de datos de paquetes de origen en la segunda red (10),
y el evento de disparo es el nodo móvil (18) que registra su
dirección de protocolo de datos de paquetes de destino con el nodo
de canalización (48), de forma que los paquetes de datos
direccionados al nodo móvil (18) en su dirección del protocolo de
datos de paquetes de origen puedan ser canalizados por el nodo de
canalización (48) al nodo móvil (18) en su dirección del protocolo
de datos de paquetes de destino.
17. Un nodo de pasarela (12) de acuerdo con la
reivindicación 16, en el que el evento de disparo es el nodo móvil
(18) que está recibiendo un paquete de datos canalizados enviado
desde el nodo de la pasarela (12) a través de un segundo canal que
no tiene ningún filtro de paquetes de datos asociados.
18. Un nodo de pasarela (12) de acuerdo con
cualquiera de las reivindicaciones 13 a 17, en el que la movilidad
del nodo móvil entre las redes o subredes está soportada por la
utilización de los estándares del Protocolo de Internet Móvil
(MIP), en el que el nodo de canalización (48) es un agente de origen
(HA) del nodo móvil (18), y la dirección del protocolo de datos de
paquetes de destino es un servicio de cuidado de las direcciones
(CoA, CoCoA) del nodo móvil (18).
19. Un nodo de pasarela (12) de acuerdo con la
reivindicación 18, en el que la primera dirección de datos de
paquetes es la dirección del agente de origen (HA) del nodo móvil
(18) en la segunda red (10).
20. Un nodo de pasarela (12) de acuerdo con
cualquiera de las reivindicaciones 13 a 19, en el que el primer
filtro de paquetes se había creado, con antelación a la respuesta a
la detección del evento de disparo de acuerdo con la reivindicación
13, para habilitar a que el nodo de pasarela (12) seleccione el
primer canal para transferir los paquetes de datos enviados por un
nodo correspondiente involucrado en una sesión de comunicaciones
con el nodo móvil (18), y en la etapa b), el primer filtro de
paquetes de datos se modifica para poder incluir la primera
dirección del protocolo de datos del paquete.
21. Un nodo de pasarela (12) de acuerdo con la
reivindicación 20, en el que la primera dirección del protocolo de
datos de paquetes reemplaza a la dirección del protocolo de paquetes
de datos del nodo correspondiente en el primer filtro de paquetes
de datos.
22. Un nodo de pasarela (12) de acuerdo con la
reivindicación 20, en el que la primera dirección del protocolo de
datos de paquetes se suma al filtro de paquetes de datos, que
comprende también una dirección de protocolo de los paquetes de
datos del nodo correspondiente.
23. Un nodo de pasarela (12), de acuerdo con
cualquiera de las reivindicaciones 13 a 19, en el que el primer
filtro de paquetes se crea nuevamente en respuesta a la detección
del evento de disparo de acuerdo con la reivindicación 13.
24. Un nodo de pasarela (12) de acuerdo con
cualquiera de las reivindicaciones 13 a 23, en el que la primera
red cumple con los estándares del Servicio General de Radio de
Paquetes (GPRS), y en donde la pluralidad de canales corresponde a
una pluralidad de contextos de protocolos de datos de paquetes en la
primera red.
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0222187 | 2002-09-24 | ||
GB0222187A GB2393609A (en) | 2002-09-24 | 2002-09-24 | Macro-mobility in a mobile radio communication unit using packet data protocols and tunnelling |
GBGB0230336.0A GB0230336D0 (en) | 2002-09-24 | 2002-12-31 | Telecommunications |
GB0230336 | 2002-12-31 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2280780T3 true ES2280780T3 (es) | 2007-09-16 |
Family
ID=32044457
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES06075558T Expired - Lifetime ES2297798T3 (es) | 2002-09-24 | 2003-09-24 | Metodo para una pasarela de seleccion de un canal para transferir paquetes de datos. |
ES03750969T Expired - Lifetime ES2280780T3 (es) | 2002-09-24 | 2003-09-24 | Metodo para una pasarela de seleccion de un canal para transferir paquetes de datos. |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES06075558T Expired - Lifetime ES2297798T3 (es) | 2002-09-24 | 2003-09-24 | Metodo para una pasarela de seleccion de un canal para transferir paquetes de datos. |
Country Status (8)
Country | Link |
---|---|
US (3) | US7995523B2 (es) |
EP (1) | EP1543666B1 (es) |
JP (1) | JP4426451B2 (es) |
AT (2) | ATE355693T1 (es) |
AU (1) | AU2003269191A1 (es) |
DE (1) | DE60312184T2 (es) |
ES (2) | ES2297798T3 (es) |
WO (1) | WO2004030309A2 (es) |
Families Citing this family (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7218634B1 (en) * | 2000-10-10 | 2007-05-15 | Nortel Networks Limited | Assisted power-up and hand-off system and method |
ATE355693T1 (de) | 2002-09-24 | 2006-03-15 | Orange Sa | Verfahren eines gateways zum auswählen eines kanals zur übertragung von datenpaketen |
CN1617626A (zh) * | 2003-11-10 | 2005-05-18 | 皇家飞利浦电子股份有限公司 | 使移动终端能够在无线广域网与无线局域网之间无缝切换的通信方法和装置 |
US20060029014A1 (en) * | 2004-08-04 | 2006-02-09 | Jagadish Maturi | System and method for establishing dynamic home agent addresses and home addresses using the mobile IPv6 protocol |
JP4585002B2 (ja) * | 2004-08-20 | 2010-11-24 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 高速ネットワーク接続機構 |
CN100438489C (zh) * | 2004-08-27 | 2008-11-26 | 华为技术有限公司 | 二次激活数据转发方法及其设备 |
US8145908B1 (en) * | 2004-10-29 | 2012-03-27 | Akamai Technologies, Inc. | Web content defacement protection system |
US20140105129A1 (en) * | 2008-12-16 | 2014-04-17 | Orange Sa | Packet radio communications system |
DE102005014852A1 (de) * | 2005-03-30 | 2006-10-05 | Siemens Ag | Entscheidung zur Zuordnung und Ressourcenvergabe für mindestens einem Datenstrom und mindestens eine Nutzverbindung |
US8332926B2 (en) * | 2006-05-12 | 2012-12-11 | Qualcomm Incorporated | Efficient modification of packet filters in a wireless communication network |
KR100885812B1 (ko) * | 2006-12-07 | 2009-02-27 | 한국전자통신연구원 | 인터넷 프로토콜 기반의 이동통신 서비스 액세스게이트웨이 장치 및 이를 이용한 서비스 방법 |
US20090034451A1 (en) * | 2007-08-03 | 2009-02-05 | Utstarcom, Inc. | System and method for handling QoS flows in a roaming scenario |
CN101472271B (zh) * | 2008-03-13 | 2012-07-04 | 华为技术有限公司 | 对承载的处理方法及移动管理设备 |
US8451714B2 (en) * | 2008-03-24 | 2013-05-28 | Shoretel, Inc. | PSTN bypass for IP media |
US9106452B2 (en) * | 2008-03-24 | 2015-08-11 | Shoretel, Inc. | Cloud VoIP system with bypass for IP media |
US8483045B2 (en) * | 2008-03-24 | 2013-07-09 | Shoretel, Inc. | User activated bypass for IP media |
CN103181134B (zh) * | 2011-10-20 | 2015-09-09 | 华为技术有限公司 | 用于发送和接收IPv6数据包的方法和装置 |
US8819275B2 (en) | 2012-02-28 | 2014-08-26 | Comcast Cable Communications, Llc | Load balancing and session persistence in packet networks |
FR3004037A1 (fr) * | 2013-04-02 | 2014-10-03 | France Telecom | Procede de transport d'information de localisation au travers d'une authentification |
US9553899B2 (en) * | 2013-08-30 | 2017-01-24 | Comcast Cable Communications, Llc | Single pass load balancing and session persistence in packet networks |
Family Cites Families (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6496505B2 (en) * | 1998-12-11 | 2002-12-17 | Lucent Technologies Inc. | Packet tunneling optimization to wireless devices accessing packet-based wired networks |
FI108601B (fi) * | 1999-01-05 | 2002-02-15 | Nokia Corp | QoS-kartoitustiedon välitys pakettiradioverkossa |
FI108832B (fi) * | 1999-03-09 | 2002-03-28 | Nokia Corp | IP-reitityksen optimointi accessverkossa |
US6992995B2 (en) * | 2000-04-17 | 2006-01-31 | Telcordia Technologies, Inc. | Telecommunication enhanced mobile IP architecture for intra-domain mobility |
JP3639200B2 (ja) * | 2000-09-08 | 2005-04-20 | 株式会社東芝 | 通信システム、移動端末装置、ゲートウェイ装置、アドレス割り当て方法及び検索サービス方法 |
SE0003275L (sv) * | 2000-09-15 | 2002-03-16 | Ericsson Telefon Ab L M | Anordning och förfarande releterande till kommunikation |
EP1209875B1 (en) * | 2000-11-21 | 2004-10-20 | Samsung Electronics Co., Ltd. | Regional tunnel management method in a mobile communication system using mobile IP |
KR100464017B1 (ko) * | 2000-12-26 | 2004-12-30 | 엘지전자 주식회사 | 이동 ip 서비스를 제공하는 패킷 데이터 전송장치 |
FI20010095A (fi) * | 2001-01-16 | 2002-07-17 | Nokia Corp | Varmennusmenetelmä, monitoroiva verkkoelementti tietoliikenneverkoissa ja tietoliikennejärjestelmä |
JP3727309B2 (ja) * | 2001-01-18 | 2005-12-14 | 株式会社エヌ・ティ・ティ・ドコモ | パケット通信システム |
DE60134305D1 (de) * | 2001-03-08 | 2008-07-17 | Lucent Technologies Inc | Verbessertes UMTS |
US20040151155A1 (en) * | 2001-03-14 | 2004-08-05 | Jarkko Jouppi | Method for activating a connection in a communications system, mobile station, network element and packet filter |
US7054945B2 (en) * | 2001-04-09 | 2006-05-30 | Nokia Corporation | Technique for providing announcements in mobile-originated calls |
DE10120772A1 (de) * | 2001-04-24 | 2002-11-07 | Siemens Ag | Heterogenes Mobilfunksystem |
US7492733B2 (en) * | 2001-04-24 | 2009-02-17 | Alcatel-Lucent Usa Inc. | Method of transmitting packets in a mobile 3G network system |
WO2003007544A2 (en) * | 2001-07-10 | 2003-01-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Traffic flow template for managing packet data flows |
EP1434396A4 (en) * | 2001-10-02 | 2008-10-29 | Ntt Docomo Inc | MOBILITY CONTROL SYSTEM, MOBILE NODE USED IN THIS SYSTEM, MOBILITY CONTROL METHOD, MOBILITY CONTROL PROGRAM, AND MOBILITY CONTROL KNOT |
US7248582B2 (en) * | 2002-02-13 | 2007-07-24 | Sun Microsystems, Inc. | Method and system for labeling data in a communications system |
US7461169B2 (en) * | 2002-03-05 | 2008-12-02 | Cisco Technology, Inc. | DHCP based home address management of mobile IP clients |
EP1532792B1 (en) * | 2002-06-10 | 2011-10-05 | Qualcomm, Incorporated | Packet flow processing in a communication system |
US7039404B2 (en) * | 2002-06-27 | 2006-05-02 | Intel Corporation | Continuous mobility across wireless networks by integrating mobile IP and GPRS mobility agents |
ATE355693T1 (de) | 2002-09-24 | 2006-03-15 | Orange Sa | Verfahren eines gateways zum auswählen eines kanals zur übertragung von datenpaketen |
JP4444833B2 (ja) * | 2002-09-24 | 2010-03-31 | オレンジュ・エスエー | 電気通信 |
US7539186B2 (en) * | 2003-03-31 | 2009-05-26 | Motorola, Inc. | Packet filtering for emergency service access in a packet data network communication system |
US8238326B2 (en) * | 2004-11-18 | 2012-08-07 | Ruckus Wireless, Inc. | Maintaining consistent network connections while moving through wireless networks |
-
2003
- 2003-09-24 AT AT03750969T patent/ATE355693T1/de not_active IP Right Cessation
- 2003-09-24 WO PCT/GB2003/004152 patent/WO2004030309A2/en active IP Right Grant
- 2003-09-24 JP JP2004539215A patent/JP4426451B2/ja not_active Expired - Lifetime
- 2003-09-24 ES ES06075558T patent/ES2297798T3/es not_active Expired - Lifetime
- 2003-09-24 AU AU2003269191A patent/AU2003269191A1/en not_active Abandoned
- 2003-09-24 EP EP03750969A patent/EP1543666B1/en not_active Expired - Lifetime
- 2003-09-24 DE DE60312184T patent/DE60312184T2/de not_active Expired - Lifetime
- 2003-09-24 AT AT06075558T patent/ATE384383T1/de not_active IP Right Cessation
- 2003-09-24 ES ES03750969T patent/ES2280780T3/es not_active Expired - Lifetime
-
2005
- 2005-03-23 US US11/089,524 patent/US7995523B2/en active Active
-
2011
- 2011-08-08 US US13/205,487 patent/US8611296B2/en not_active Expired - Lifetime
-
2013
- 2013-12-13 US US14/106,393 patent/US9949238B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
ATE355693T1 (de) | 2006-03-15 |
US20050243820A1 (en) | 2005-11-03 |
EP1543666A2 (en) | 2005-06-22 |
ATE384383T1 (de) | 2008-02-15 |
US20140177553A1 (en) | 2014-06-26 |
JP2006500844A (ja) | 2006-01-05 |
WO2004030309A3 (en) | 2004-09-23 |
US9949238B2 (en) | 2018-04-17 |
US7995523B2 (en) | 2011-08-09 |
AU2003269191A1 (en) | 2004-04-19 |
JP4426451B2 (ja) | 2010-03-03 |
EP1543666B1 (en) | 2007-02-28 |
US8611296B2 (en) | 2013-12-17 |
WO2004030309A2 (en) | 2004-04-08 |
DE60312184D1 (de) | 2007-04-12 |
ES2297798T3 (es) | 2008-05-01 |
DE60312184T2 (de) | 2007-11-08 |
AU2003269191A8 (en) | 2004-04-19 |
US20110286425A1 (en) | 2011-11-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2280780T3 (es) | Metodo para una pasarela de seleccion de un canal para transferir paquetes de datos. | |
JP4444833B2 (ja) | 電気通信 | |
US9641999B2 (en) | Telecommunications | |
JP4834133B2 (ja) | 電気通信 | |
JP2007520963A6 (ja) | 通信 | |
GB2393608A (en) | Selecting an appropriate PDP context at a GPRS gateway support node for transferring a data packet from a mobile node to a correspondent node |