MXPA03009870A

MXPA03009870A - Un sistema y un metodo para seleccionar un ggsn en una red de comunicaciones movil.

Info

Publication number: MXPA03009870A
Application number: MXPA03009870A
Authority: MX
Inventors: A Naqvi Shamim
Original assignee: Winphoria Networks Inc
Priority date: 2001-04-30
Filing date: 2002-04-24
Publication date: 2004-12-06
Also published as: EP1391129A4; CN1281081C; AU2002250606B2; CA2446067A1; US6545992B2; CA2446067C; KR20030096340A; KR100596597B1; BR0209309A; US20020159420A1; CN1535546A; JP2004531134A; EP1391129A1; WO2002089509A1

Abstract

Se proporciona un metodo y sistema para determinar un GGSN para dar servicio a llamadas de datos en una red de comunicaciones movil. Los mensajes se reciben de un SGSN, y se analizan para determinar si el mensaje esta pidiendo la identidad de un GGSN. S i el mensaje recibido esta pidiendo la identidad de un GGSN, un algoritmo de seleccion de GGSN se ejecuta para identificar un GGSN para dar servicio a llamadas de datos desde una MS especifica. Entonces una respuesta se construye y envia al SGSN que identifica el GGSN seleccionado.

Description

WO 02/089509 A 1 II I ! I f f I M 11 ' ??? I ?? I ,fl III III 11 1 II (BF, BJ, CF, CG, CI, CM, GA, GN, GQ, G , ML, MR, For two-lelter codes and other abbreviations, refer lo ihe "Guid- NE, SN, TD, TG). anee Notes on Codes and Abbreviations" appearing at the begin- ning of ach regular issue ofthe PCT GuzcUe. Published: — wilh inlernational search report SISTEMA Y MÉTODO PARA SELECCIONAR GGSN EN UNA RED DE COMUNICACIONES MÓVIL 1. Campo de la Invención I Esta invención se refiere a comunicaciones móviles, y más particularmente, a la selección de GGSN para agregar llamadas de datos en una red de comunicación móvil .

. Antecedentes de la Invención Las redes inalámbricas digitales o de comunicación móviles actuales son predominantemente redes de segunda generación ("2G"). Los protocolos dominantes son TDMA, GSM y CDMA. Estas redes tienen capacidad limitada en dar servicio a llamadas de datos (contrario a las de voz) . El ancho de banda típico es de aproximadamente 9.6Kbits/segundos . Se han propuesto las redes de tercera generación (n3G") . CD A2000 y UMTS son dos de las redes de 3G propuestas más populares. Estas propuestas se pretenden para dar servicio a más usuarios de voz en una red dada y soportar velocidades de datos más altas (por ejemplo, mayores a 144 Kbits/segundo) a una estación móvil tal como un "teléfono celular" . La Figura 1 muestra una disposición ejemplar de 2 una red 100 de UMTS . Una "área de cobertura geográfica" se divide en un número de áreas geográficas más pequeñas llamadas "celdas" (no mostradas) . Las estaciones 101 móviles (las MS) accionadas en el área de cobertura se comunican mediante un canal de radio a un nodo 102 correspondiente. Una pluralidad de nodos 102a-n se comunica mediante los enlaces 103a-n con un Controlador 104 de Red de Radio correspondiente (RNC) . El RNC 104 agrega el tráfico de comunicación desde los nodos y proporciona funcionalidad, tal como detectando los puntos de servicio activados por la MS 101. La combinación de nodos 102 y RNC 104 es llamada Red 105 de Acceso de Radio Terrestre Universal (UTRAN) . Potencialmente existen muchas UTRAN en una red. Cada UTRAN 105 se comunica con un servidor 108 de llamadas (también llamado servidor de MSC o un administrador de control de sesión) mediante los enlaces 105 de señalización y las líneas 107 principales de soporte y se comunica con un SCSN 111 mediante el enlace 110 de IP. El tráfico entre la UTRAN y el servidor de llamadas, es decir, las llamadas de voz, puede basarse en ATM y la interfase se define por la interfaz Iu-cs. El servidor de llamadas tiene lógica de control para manejar llamadas de voz y un plano de soporte para conmutar el tráfico de voz entrante. 3 El tráfico entre una UTRAN y un SGSN se basa en paquetes . El ingreso al SGSN son los túneles de GTP (Protocolo de Formación de Túneles de GPRS) , y el SGSN conmuta estos túneles basándose en las instrucciones de la lógica de control en el servidor de llamadas. Estas instrucciones se contienen en paquetes de IP y son enviadas desde SGSN al servidor de llamadas mediante el enlace 120 a la red 118 de IP, de la cual lo recibe el servidor de llamadas. Analógicamenté, la UTRAN puede comunicar el tráfico de IP al servidor de llamadas mediante el SGSN y la red 118, 120 de IP. El tráfico en los túneles de GTP puede ser tráfico de datos, por ejemplo tráfico a un sitio web, o pueden ser voz en paquetes en cuyo caso la lógica de control puede requerirse que de manejo especial a tal tráfico, por ejemplo, las consideraciones de QoS (SGSN es el acrónimo industrial para "Nodo de Soporte de GPRS de Servicio") . Un servidor 108 de llamadas y un SGSN 111 puede manejar cada uno una pluralidad (potencialmente diferente) de las UTRAN 105a-n. El servidor 108 de llamadas es responsable de manejar las llamadas de voz con base de circuito si se implementa la interfaz de Iu-CS. La UTRAN 105 es responsable de detectar la activación de las llamadas y, en respuesta a tal activación, coopera con el servidor de 4 llamadas para establecer los enlaces 106 de señalización necesarios y los circuitos 107 de soporte al servidor 108 de llamadas. El servidor de llamadas, además de cooperar con la UTRAN, establece los enlaces 112 de señalización correspondientes y los circuitos 114 de soporte a la red de voz. Más específicamente, el servidor de llamadas establece los enlaces de señalización con la red 113 de señalización de SS7 y los circuitos de soporte con la red 115 de circuito de soporte de PSTN. Las llamadas de voz pueden enrutarse de este modo a una parte llamada que utiliza señalización convencional y conmutación y utiliza las técnicas con base de circuito. Un SGSN 111 es responsable de manejar las llamadas de datos, ambas llamadas de datos convencionales como las peticiones de Internet y las llamadas de voz sobre la red de datos. La UTR I 105 es responsable de detectar la activación de las llamadas, y en respuesta a la activación, coopera con el SGSN 111 para establecer las trayectorias de datos necesarias mediante el enlace 109 de IP al SGSN 111. El SGSN entonces ayuda a establecer un túnel de GTP que inicia desde la UTRAN y se extiende a un GGSN 119 para establecer una red privada virtual, o "VPN" . La lógica de control para esta conducta de conmutación puede residir en el servidor de llamadas . (GGSN es el acrónimo industrial para "Nodo de Soporte de 5 GPRS de Pasarela") . El SSGN entonces procesa la información recibida y la forma en paquetes de IP que pueden transportarse en el túnel en la red 118 de IP privada. El GGSN recibe los paquetes de IP de potencialmente muchos SGSN lllj-1 y agrega el tráfico además de proporcionar otros servicios, tal como seguridad. El tráfico de IP agregado entonces puede comunicarse a una red 120 de IP pública tal como la Internet 121. La administración de movilidad necesita realizarse para llamadas de voz y datos. Para las llamadas de voz conmutadas de circuito, el servidor 108 de llamadas es responsable de manejar las terminales móviles . La lógica de control es el servidor de llamadas que tiene acceso a un Registro 116 de Ubicación de Visita (VLR) típicamente co-localizado con el servidor de llamadas para llevar a cabo esta función. El VLR mantiene la información de suscriptor que típicamente es un subconjunto de la información almacenada en el registro 117 de ubicación local (HLR) . El HLR se actualiza para manejar la administración de movilidad para llamadas de voz y datos . Cuando un suscriptor hace rooming mientras hace una llamada de voz conmutada de circuito, las conexiones de circuito a la UTRAN apropiadas desde el servidor de llamadas tiene que mantenerse. Para las 6 llamadas de datos (incluyendo las llamadas de voz en paquete) , el servidor de llamadas también es responsable de la administración de movilidad. En este caso, el túnel de GTP desde el SGSN apropiado a la UTRAN apropiada necesita mantenerse cuando el suscriptor hace rooming en la red. La administración de movilidad en el caso de llamadas de datos implica la selección y mantenimiento de tales túneles. La lógica para llevar a cabo esta función reside en el servidor de llamadas y tiene acceso al HLR y al VLR para realizar esta función. Cuando una MS 101 hace una llamada de datos (es decir, cuando inicia una sesión de paquete) , la UTRAM 105 recibe la información de señalización, detecta que una llamada de datos está próxima y comienza a recibir los paquetes de la MS 101. Con la detección de que una llamada de datos está próxima, el software de agente que se ejecuta en el módulo de administración de movilidad del servidor de llamadas tiene acceso al HLR 117 utilizando la ID de suscritos de la MS y el número de MS (MSN) , el código de identificación de terminal, o similar, o una clave para obtener cierta información de perfil de suscriptor incluyendo el GGSN "local" para ese suscriptor. Cuando continua la llamada de datos, el SSGF que recibe los paquetes de datos de la UTRAN envía los paquetes de datos sobre la red 118 de IP al GGSN local 7 que agrega los paquetes para la transmisión subsecuente a la red 121, 122 de IP pública. Se cree que la asignación estática de un GGSN provoca ciertas ineficacias y desventajas. Por ejemplo, si un usuario está haciendo rooming, el GGSN al final del túnel puede estar más alejado del usuario. No solo en este uso ineficiente de la red (ya que los paquetes de IP pueden tener que encontrar muchos saltos en la red) sino que padecerá el rendimiento. Esta desventaja de rendimiento puede hacer al procedimiento menos adecuado para utilizar el lado de los datos de la red sobre las llamadas de IP y para cierto tráfico de multimedia.

Sumario de la Invención De acuerdo con la presente invención, un método y sistema para determinar un GGSN para dar servicio a llamadas de datos en una red de comunicaciones móvil se proporciona. Los mensajes se reciben de la lógica de control en el servidor de llamadas, y se analizan para determinar si el mensaje está pidiendo la identidad de un GGSN. Si el mensaje recibido está pidiendo la identidad de un GGSN, un algoritmo de selección de GGSN se ejecuta para identificar un GGSN para dar servicio a las llamadas de datos desde una S específica. Una réplica entonces es construida y es enviada al SGSN que identifica al GGSN 8 seleccionado . De acuerdo con un aspecto de la invención, el GGSN que está más cerca del SGSN se selecciona. De acuerdo con otro aspecto de la invención, un GGSN que tiene la capacidad de dar servicio a llamadas de datos desde la S específica se selecciona. De acuerdo con otro aspecto de la invención, un GGSN se selecciona en consideración del estado operacional de los segmentos de red que conectan un GGSN a la red. De acuerdo con aún otro aspecto de la invención, una lógica de recepción de paquete de IP recibe los mensajes de la lógica de control de un servidor de llamadas, y la lógica de análisis de paquete de IP determina si el mensaje recibido está pidiendo la identidad de un GGSN. La lógica de selección de GGSN, la cual es responsable de la lógica de análisis de paquete de IP, identifica un GGSN para dar servicio a las llamadas de datos desde una MS específica, y la lógica de réplica de paquetes de IP construye y envía un paquete de réplica al SGSN que identifica el GGSN seleccionado. De acuerdo con aún otro aspecto de la invención, la lógica es lógica de software que se ejecuta en una plataforma de conmutación y comunicación con un HLR y con una red de IP. De acuerdo con aún otro aspecto de la invención, la lógica es lógica de software que se 9 ejecuta en el HLR. De acuerdo con aún otro aspecto de la invención, la lógica es lógica de software que se ejecuta en un adjunto que coopera con el HLR. Bajo aún otra modalidad de la invención, una lógica de selección de GGSN es de tipo lote. El algoritmo de selección de GGSN se ejecuta para identificar un GGSN para dar servicio a llamadas de datos desde el SGSN y el GGSN identificado se proporciona a una HLR para asociar el GGSN identificado con el SGSN.

Breve Descripción de los Dibujos En los dibujos, la figura 1 es un diagrama de sistemas de una red móvil de 3G ilustrativa; la figura 2 es un diagrama de sistema de una red móvil de 3G ilustrativa de acuerdo con una modalidad de la invención; la figura 3 muestra la lógica de selección de GGSN de acuerdo con una modalidad de la invención; las figuras 4-6 son diagramas de arquitectura que muestran modalidades alternativas de la invención.

Descripción Detallada de la Invención Las modalidades preferidas de la invención proporcionan nuevos sistemas y métodos para determinar e 10 identificar un GGSN para dar servicio a una llamada de datos dentro de una red de comunicación móvil . Más específicamente, las modalidades preferidas de la invención seleccionan un GGSN de servicio basándose en una variedad de criterios, en lugar de solamente el uso de GGSN local en todos los casos . La selección puede basarse en (entre otras cosas) la proximidad geográfica de un GGSN, la capacidad disponible de un GGSN, la capacidad en segmentos de red que conectan un GGSN, y el estado operacional de los GGSN o enlaces a los GGSN. Adicionalmente, el proveedor de servicio puede establecer políticas para seleccionar un GGSN que, a la vez, puede incluirse dentro de la lógica de selección de GGSN. Aunque modalidades preferidas dinámicamente seleccionan los GGSN (en casi tiempo real) , ciertas modalidades hacen la selección basándose en la selección de tipo lote como parte de la administración de red. La Figura 2 muestra una red 200 inalámbrica ejemplar de acuerdo con una modalidad preferida de la invención. Números similares se utilizan para explicar los mismos o componentes similares como aquellos en la figura 1 pero la descripción se repite para brevedad. El sistema 200 difiere de la figura 1 mediante la inclusión de un conmutador 205 de procuración de HLR colocado entre y se comunica con la red 118 de IP privada y el HLR 117. 11 (Aquellas personas con experiencia en la técnica apreciarán que aunque el HLR 117 es una base de datos singular lógica su realización física es una base de datos distribuida que tiene muchos casos) . Bajo las modalidades preferidas, la procuración 205 de HLR se implementa al utilizar el conmutador de procuración descrito en la Solicitud de Patente Norteamericana co-pendiente No. de Serie 09/721,329, presentada el 22 de noviembre del 2000 (asignada al cesionario de la presente invención) la cual se incorpora a la presente para referencia en su totalidad. Más específicamente, el conmutador de procuración descrito en la solicitud co-pendiente se modifica para comunicarse de acuerdo con el protocolo de IP y con los enlaces de IP y para incluir la lógica de selección de GGSN discutida en la presente. Como se describe en la solicitud co-pendiente, el conmutador de procuración acepta todos los mensajes de señalización y puede configurarse para hacer una o más de varias acciones específicas dependiendo del mensaje de señalización recibido y sobre el estado de la cesión y el sistema. Esa conducta se utiliza en ciertas modalidades de la presente invención, excepto que la información de señalización se transporta como paquetes de IP en lugar de mediante señalización de SS7 o similar. 12 Bajo ciertas modalidades, el conmutador 205 de procuración de HLR realiza uno o más de lo siguiente en respuesta a los paquetes de IP recibidos de la red 118 de IP privada: 1. La procuración 205 de HLR pasa el mensaje sin alteración al HLR o al SGSN o 2. La procuración 205 de HLR intercepta los mensajes, no los pasa, y más bien maneja el mensaje, incluyendo por ejemplo, generar una respuesta al mensaje. Los tipos de acciones realizadas en cada caso junto con los eventos de disparo se describen en lo siguiente. Como se describe en lo siguiente, la procuración 205 de HLR puede implementarse al utilizar la capacidad del conmutador de procuración para interceptar los mensajes pre-especificados mientras que permite que los otros pasen a través de éste sin alteración. El conmutador de procuración se modifica para manejar los protocolos de señalización de 3G u otros y para generar respuestas a los mensajes interceptados como se describe en lo siguiente. La Figura 3 es un diagrama de flujo que ilustra la lógica de selección de GGSN de una modalidad preferida. La lógica inicia en 300 y procede para recibir los paquetes de IP 310 de la red, por ejemplo, desde el 13 servidor 108 de llamadas y se dirige al HLR 117. Cada paquete se monitorea 315 para ver si el paquete es un comando que pide un elemento de información (IE) correspondiente al GGSN para un usuario dado. (Tales peticiones, como se representa en lo anterior, se inician por el servidor 108 de llamadas y se envían al HLR 117 para determinar cuál GGSN debe agregar el tráfico de IP para un usuario dado. Como se representa en lo anterior, ordinariamente la petición se recibe por el HLR 117 que entonces contesta con el GGSN local del usuario) . El IE específico utilizado se determina basándose en el estándar de red como provisionado por el proveedor de servicio específico. Si el paquete no contiene tal comando, la lógica procede para enviar 320 el paquete sin alteración, por ejemplo, al HLR 117. El HLR entonces maneja el paquete por consiguiente. Si como parte de manejar el paquete, el HLR 117 envía un paquete de réplica, la procuración 205 de HLR lo procesa similar a lo anterior. Específicamente, la procuración 205 de HLR recibirá 310, monitoreará 315, y pasará 320 el paquete de réplica sin alteración (responde del HLR mediante la definición de no tener comandos que requieran un IE que tenga el GGSN) . En esta forma, la respuesta se envía al solicitante, por ejemplo, el SSGN 111. 14 Si el paquete contiene un comando que requiere que el IE tenga el GGSN, la lógica selecciona 325 un GGSN basándose en un algoritmo predefinido {más abajo) . El GGSN seleccionado entonces se encapsula en un paquete de respuesta y se envía 330 al solicitante, es decir, el SSGN 111. El paquete de IP original jamás se envía al HLR. Una vez que el SSGN 111 recibe el paquete de petición que identifica el GGSN para utilizarse, el SSGN establece un túnel de GTP al GGSN seleccionado como se representa en lo anterior, excepto que en este caso el GGSN no es el GGSN "local" sino más bien es uno seleccionado dinámicamente. El GGSN seleccionado entonces agregará los paquetes de IP que se originan desde, o que se destinan al usuario, mediante este GGSN. Como se establece en lo anterior, el algoritmo predefinido para seleccionar un GGSN puede ser de muchas formas. Una modalidad selecciona el GGSN que está geográficamente más cerca de la MS y el SSGN. En este caso, la procuración 205 de HLR como parte de determinar 325 un GGSN consulta una base de datos de topología de red (no mostrada) y decide que encuentren el GGSN más cercano al SSGN que originó la petición. El más cerca, por ejemplo, puede inferirse desde el número más bajo de saltos de red entre el SSGN y el GGSN. 15 Bajo un algoritmo alternativo, los criterios de rendimiento y/o las condiciones se analizan para seleccionar un GGSN. Por ejemplo, la lógica de selección de GGSN puede seguir una base de datos de administración o utilidad que identifique los segmentos de red de IP que no se descargan y entonces puede seleccionar un GGSN de tal segmento. Este procedimiento puede utilizarse junto con el anterior o como un sustituto para lo anterior. Alternativamente, el algoritmo puede seleccionar un GGSN basándose en la información de conflabilidad, tal como evitar los GGSN que experimentan un gran número de condiciones de falla y en lugar de seleccionar un GGSN de "respaldo" . El algoritmo actual puede seleccionarse a partir de un conjunto de algoritmos mediante un administrador. En este ejemplo, la procuración 205 de HLR puede incluir una interfaz de administrador de red (no mostrada) , que permite la selección de un algoritmo mediante un usuario o permitir que el usuario especifique las reglas de selección, por ejemplo, seleccionar un algoritmo durante las horas pesadas de demanda y otros algoritmos en diferentes momentos . Aunque la descripción anterior fue en relación a una procuración 205 de HLR, otras modalidades de la invención pueden poner a la lógica de selección de GGSN 16 en otros lugares en la red. Por ejemplo, la figura 4 muestra una modalidad en la cual la lógica 405 de selección de GGSN (por ejemplo, como se discute en la presente) se incluye dentro del HLR 417. La Figura 5 muestra una modalidad en la cual la lógica 505 de selección se ejecuta en un adjunto 510 que coopera con el HLR 117. La Figura 6 muestra otra modalidad en la cual la lógica 605 de selección de GGSN se corre periódicamente como un trabajo tipo lote como parte de la utilidad o administración de red. Los GGSN pueden seleccionarse para la asociación con las MS basándose en el rendimiento de red y la información de conflabilidad. La lógica 605 entonces puede tener acceso a los HLR mediante una interfaz 610 de datos y especificar los GGSN por consiguiente. Este acceso y actualización pueden operar análogamente a los GGSN locales de programación dentro del HLR, pero en este caso el GGSN puede basarse en otros criterios .

Variaciones Actualmente, existen algunas propuestas para proporcionar servidores de suscriptor de HSS-locales. El HSS servirá a ambas entidades de PSTN y de IP para perfil de suscriptor y las necesidades de datos. El HSS también puede utilizarse como un servidor de transacción móvil 17 que permite que los suscriptores compren artículos en cuyo caso la facturación se unirá al HSS . En tales casos, la selección de GGSN puede unirse a las consideraciones de comercio móvil, por ejemplo, si un suscriptor compra un artículo, la red puede intercambiarlo a una sesión de IP más segura con algún otro GGSN. Habiendo descrito una modalidad ejemplar, debe ser aparente para personas con experiencia en la técnica qué cambios pueden hacerse a la modalidad descrita sin apartarse del espíritu y alcance de la invención.

Claims

18

NOVEDAD DE LA INVENCIÓN Habiendo descrito la presente invención se considera como novedad y por lo tanto se reclama como propiedad lo descrito en las siguientes reivindicaciones.

REIVINDICACIONES 1. Un método para determinar un GGSN para dar servicio a llamadas de datos en una red de comunicaciones móvil que tiene por lo menos dos GGSN y una red de SGSN, caracterizado porque comprende los actos de: recibir mensajes de un SGSN; analizar el mensaje recibido para determinar si está pidiendo la identidad de un GGSN; si el mensaje recibido está pidiendo la identidad de un GGSN, ejecutar un algoritmo de selección de GGSN para identificar un GGSN para dar servicio a llamadas de datos de una MS específica; construir y enviar una respuesta al SGSN que identifica el GGSN seleccionado. 2. El método de conformidad con la reivindicación 1, caracterizado porque el acto de ejecutar un algoritmo de selección de GGSN incluye el acto de determinar un GGSN que está más cerca del SGSN. 3. El método de conformidad con la reivindicación 1, caracterizado porque el acto de 19 ejecutar un algoritmo de selección de GGSN incluye el acto de determinar un GGSN que tiene una capacidad de dar servicio a llamadas de datos a partir de la MS especifica .

4. El método de conformidad con la reivindicación 1, caracterizado porgue el acto de ejecutar un algoritmo de selección de GGSN incluye el acto de considerar el estado operacional de los segmentos de red que conectan un GGSN a la red.

5. Un sistema para determinar un GGSN para dar servicio a llamadas de datos en una red de comunicaciones móvil que tiene por lo menos dos GGSN y una red de SGSN, caracterizado porque comprende: una lógica de recepción de paquete de IP para recibir mensajes de un SGSN; una lógica de análisis de paquete de IP para determinar si el mensaje recibido está pidiendo la identidad de un GGSN; una lógica de selección de GGSN, responsable de la lógica de análisis de paquete de IP, para identificar un GGSN para dar servicio a llamadas de datos de una MS específica; una lógica de respuesta de paquetes de IP para construir y enviar un paquete de respuesta al SGSN que identifica el SGSN seleccionado. 20

6. El sistema de conformidad con la reivindicación 5, caracterizado porque la red incluye un HLR y en donde la lógica de recepción de paquete de IP, la lógica de análisis de paquete de IP, la lógica de selección de GGSN, y la lógica de respuesta de paquete de IP es la lógica de software que se ejecuta en una plataforma de conmutación y comunicación con el HLR y con una red de IP.

7. El sistema de conformidad con la reivindicación 5, caracterizado porque la red incluye un HLR y en donde la lógica de recepción de paquete de IP, la lógica de análisis de paquete de IP, la lógica de selección de GGSN, y la lógica de respuesta de paquete de IP es la lógica de software que se ejecuta en el HLR.

8. El sistema de conformidad con la reivindicación 5, caracterizado porque la red incluye un HLR y en donde la lógica de recepción de paquete de IP, la lógica de análisis de paquete de IP, la lógica de selección de GGSN, y la lógica de respuesta de paquete de IP es la lógica de software que se ejecuta en un adjunto que coopera con el HLR.

9. Un método para determinar un GGSN para dar servicio a llamadas de datos en una red de comunicación móvil que tiene por lo menos dos GGSN en una red de GSGN, caracterizado porque comprende los actos de: 21 ejecutar un algoritmo de selección de GGSN para identificar un GGSN para dar servicio a llamadas de datos a partir del SGSN; proporcionar el GGSN identificado a un HLR para asociar el GGSN identificado con el SGSN.