Proxy de GGSN para una solución de un túnel.

Un método para itinerancia de una unidad de comunicación de telefonía móvil inalámbrica (401) desde unaprimera Red de Telefonía Móvil Terrestre Pública visitada,

VPLMN, (VPLMN1) a una segunda VPLMN (VPLMN2),comprendiendo la primera VPLMN un primer nodo de soporte de servicio (403) y un primer nodo de soporte depuerta de enlace de proxy (404); comprendiendo la segunda VPLMN un segundo nodo de soporte de servicio (408)y un segundo nodo de soporte de puerta de enlace de proxy (409), en el que la carga útil es enviada directamenteentre una red de radio respectiva de la VPLMN respectiva a un nodo de soporte de puerta de enlace local (405) enuna Red de Telefonía Móvil Terrestre Pública Local, HPLMN, a través de respectivos túneles (417, 418), sinatravesar los nodos de soporte de servicio primero y segundo,

comprendiendo el método las etapas de:

a.enviar una solicitud de contexto desde el segundo nodo de soporte de servicio (408) en la segunda VPLMNal primer nodo de soporte de servicio (403) en la primera VPLMN;

b.recibir una respuesta de contexto en el segundo nodo de soporte de servicio desde el primer nodo desoporte de servicio;

c.enviar un reconocimiento de contexto desde el segundo nodo de soporte de servicio al primer nodo desoporte de servicio;

d.enviar una solicitud de reubicar contexto de Protocolo de Datos en Paquetes, es decir, PDP (Packet DataProtocol, en inglés), desde el segundo nodo de soporte de servicio al segundo nodo de soporte de puerta deenlace de proxy (409) en la segunda VPLMN;

e.enviar una solicitud de actualizar contexto de PDP al nodo de soporte de puerta de enlace local (405) en laHPLMN de la unidad de comunicación de telefonía móvil inalámbrica desde el segundo nodo de soporte depuerta de enlace de proxy;

f. recibir en el segundo nodo de soporte de puerta de enlace de proxy una respuesta de actualizar contexto dePDP;

g.enviar una respuesta de reubicar contexto de PDP al segundo nodo de soporte de servicio desde elsegundo nodo de soporte de puerta de enlace de proxy;

h.enviar un mensaje de actualizar ubicación desde el segundo nodo de soporte de servicio a un registro deubicación local (406) en la HPLMN de la unidad de comunicación de telefonía móvil inalámbrica (401);

i. recibir un mensaje de reconocimiento de actualizar ubicación en el segundo nodo de soporte de serviciodesde el registro de ubicación local.

Proxy de GGSN para una solución de un túnel

CAMPO TÉCNICO La presente invención se refiere al área de la Red de Núcleo de GRPS y a una arquitectura mejorada para proporcionar carga útil de GPRS entre la red de radio y una red de datos en paquetes externa a través de la red de núcleo de PS de GPRS.

ANTECEDENTES DE LA INVENCIÓN En el 3GPP existe una iniciativa en curso para definir una mejora del GPRS conocida como la Solución de Un Túnel (OTS – One Tunnel Solution, en inglés) . El método fue propuesto ya en la Versión 4 del 3GPP y elaborado en el documento TR 23.873 (véase la figura 1a) . El TR propone eliminar el plano de usuario de un SGSN (Nodo de Soporte de GPRS de Servicio – Serving GPRS Support Node, en inglés) y enviar carga útil directamente entre el GGSN (Nodo de Soporte de GPRS de Puerta de Enlace – Gateway GPRS Support Node, en inglés) y un RNC (Controlador de Red de Radio – Radio Network Controller, en inglés) . El plano de control está todavía implementado en el nodo SGSN, el cual se convierte en un nodo de señalización de control puro sin plano de usuario. No obstante, la propuesta tenía ciertos inconvenientes, por ejemplo, la solución no estaba diseñada para móviles en itinerancia. Para itinerar, el plano de usuario estará conectado a través del SGSN en la red (NW – NetWork, en inglés) visitada hacia el GGSN en la PLMN (Red de Telefonía Móvil Terrestre Pública – Public Land Mobile Network, en inglés) Local, lo que significa que el plano de usuario no puede ser eliminado completamente del SGSN.

Para vencer el problema de la itinerantica, Nortel propuso una arquitectura alternativa, que implicaba el llamado Repetidor de Portador de GGSN en la V-PLMN (véase la figura 1b) . Con esta solución el plano de usuario pasará, en caso de itinerancia, a través del GGSN visitado y del RNC, sin pasar a través del SGSN. El SGSN será un nodo de control puro. En la solución del Repetidor de Portador de GGSN, la señalización de control para usuarios en itinerancia será enviada en una interfaz Gp ordinaria entre el V-SGSN y el GGSN Local. Habrá también una interfaz Gn entre el SGSN y el GGSN en la red visitada. Para un usuario en itinerancia estas dos interfaces de control serán utilizadas simultáneamente para señalizar al H-GGSN (GGSN Local – Home-GGSN, en inglés) y al V-GGSN (GGSN Visitado – Visited-GGSN, en inglés) .

El Repetidor de Portador de GGSN para la Solución de Un Túnel resuelve algunos, pero no todos, los problemas de la Solución de Un Túnel original en Versión 4.

1. Habrá un problema de seguridad en el Repetidor de Portador de GGSN. Cuando la interfaz Gp se utiliza para usuarios en itinerancia, la topología de la PLMN visitada será abiertamente visible fuera de la V-NW (Red Visitada – Visited-NetWork, en inglés) . Los nodos SGSN y sus direcciones de IP están expuestos a las redes GRX y externas además de a los Proxies del GGSN. La señalización de control externa finaliza en varios puntos menos protegidos en el interior de la red, en lugar de en unos pocos puntos bien protegidos en el borde de la NW (Red – NetWork, en inglés) .

2. Las configuraciones de cortafuego son complejas cuando el CP (Plano de Control -Control Plane, en inglés) y el UP (Plano de Usuario – User Plane, en inglés) están separados. Los cortafuegos con información de estado no son posibles puesto que la ISRAU (Actualización de Área de Encaminamiento de Inter SGSN – Inter SGSN Routing Area Update, en inglés) será reportada fuera de la V-PLMN.

3. Problema de Itinerancia en la PLMN. Existe un problema en el Repetidor de Portador de GGSN con procedimientos de MM (Gestión de Movilidad – Mobility Management, en inglés) cuando se está itinerando entre diferentes PLMNs. Esto es debido a que el GGSN en la V-PLMN antigua ya no se utilizará, y necesita ser reemplazado con un GGSN en la nueva V-PLMN. 4. Otro problema con la arquitectura de 3GPP de Versión 6 actual es que el tráfico basado en PS (Paquetes Conmutados – Packet Switched, en inglés) , por ejemplo, Telefonía sobre IP, está siempre encaminado a la PLMN Local. No hay modo de enviar tráfico localmente en la PLMN Visitada. El Proxy de GGSN proporciona una alternativa para terminar el tráfico de PS en la V-PLMN. Con una implementación específica en el Proxy de GGSN, un Contexto de PDP puede ser forzado a terminar en la V-PLMN. Esto puede, por ejemplo, ser muy importante cuando el dominio de PS deba soportar Telefonía sobre IP de Emergencia, donde el llamante necesita ser conectado a un centro de llamadas de emergencia local en la V-PLMN.

El documento TR 23.809 V0.3.0 (2006-07) del 3GPP de la técnica anterior muestra en 5.3, “GGSN Bearer Relay” que se sugiere un concepto de un túnel en el cual toda la funcionalidad de transporte de plano de usuario es eliminada del SGSN. El nuevo controlador de SGSN (cSGSN) sólo lleva a cabo funciones de control de un SGSN heredado, mientras que el GGSN mejorado (xGGSN) es responsable de la funcionalidad del transporte de plano de usuario de todos los SGSN heredados y del GGSN (véase la Figura 3a) . Durante el procedimiento de Activación de Contexto de PDP el cSGSN asigna primero un recurso de plano de portador (TEID y dirección de plano de usuario) del xGGSN. El cSGSN proporciona a continuación el TEID y la dirección del plano de usuario del xGGSN en la solicitud de Crear PDP de Gn. Durante el procedimiento de Establecimiento de RAB el cSGSN pasa el TEID y la dirección del plano de usuario del xGGSN al RNC. Debe observarse que la interacción con el GGSN heredado en

este escenario no requiere ninguna modificación de los procedimientos existentes. En 5.4, se describe un Proxy de GGSN. Este planteamiento es una extensión y mejora del planteamiento de Un Túnel descrito en el TR 23.873 del 3GPP. Este planteamiento es similar al Repetidor de Portador de GGSN de la sub sección 5.3. La diferencia de ese planteamiento es que aquí el xGGSN en lugar del cSGSN realiza la señalización al GGSN de la HPLMN. El SGSN se comunica en la mayoría de los casos con el xGGSN como si fuese el GGSN normal. El xGGSN actualiza a continuación el GGSN de la HPLMN cuando sea necesario. El xGGSN actúa como un SGSN hacia el GGSN de la HPLMN y la interfaz Gp se utiliza entre operadores como en la actualidad. Cuando el cSGSN durante el procedimiento de Activación de Contexto de PDP encuentra un APN que mensaje de Solicitud de Crear Contexto de PDP a ese nodo, por el contrario. El xGGSN crea el Contexto de DPD, asigna los TEIDs adicionales para la interfaz Gp y transmite el mensaje de Solicitud de Crear Contexto de PDP con estos TEIDs al GGSN correspondiente al APN. El mensaje de respuesta del GGSN es devuelto / enviado por el xGGSN al SGSN. En el caso de no itinerancia, el cSGSN podrá descubrir si el GGSN soporta la solución de un túnel o no. Cómo descubrir si el GGSN soporta la solución de un túnel es FFS. Los procedimientos de gestión de movilidad son manejados de la misma manera que cuando la alternativa de Un Túnel es seleccionada en la optimización del portador controlado por el SGSN, no estando el GGSN de la HPLMN implicado en el procedimiento. El xGGSN transmite todas las modificaciones de los Contextos de PDP al GGSN en la HPLMN, a menos que la modificación sea sólo significativa localmente (es decir, que actualice TEIDs y direcciones de IP) .

El capítulo 6.18.3 / 5.4 / Figura 4 en el TR 23.809 V0.3.0 (2006-07) del 3GPP – se refiere sólo a un Proxy de GGSN y no se refiere a ninguna itinerancia entre redes VPLMN y no describe ninguna reubicación de proxy, ni describe ninguna señalización para tal itinerancia. Los procedimientos de gestión de movilidad (último párrafo en 5.4) a los que se hace referencia en relación con la Figura 4 parecen referirse a otra forma de movilidad, a saber, transferencia entre redes de radio para la misma VPLMN y siguientes para el mismo Proxy de GGSN. El capítulo 6.18.3 dice “La itinerancia es soportada con el Proxy de GGSN como un repetidor entre el SGSN de la VPLMN y el GGSN de la HPLMN. El Proxy de GGSN actúa como un SGSN hacia el GGSN de la HPLMN y se utiliza la misma interfaz Gp normal”.

COMPENDIO DE LA INVENCIÓN El objeto de la invención es proporcionar una solución que resuelva al menos algunos de los problemas anteriores.

Este objeto ha sido conseguido mediante el método de acuerdo con la reivindicación 1.

Además, el nodo de soporte de servicio de acuerdo con la reivindicación 6 y el nodo de soporte de puerta de enlace del proxy de la reivindicación 8 también consiguen el objeto anterior.

Se consigue una eficiente reubicación del tráfico de carga útil que es enviado... [Seguir leyendo]

1. Un método para itinerancia de una unidad de comunicación de telefonía móvil inalámbrica (401) desde una primera Red de Telefonía Móvil Terrestre Pública visitada, VPLMN, (VPLMN1) a una segunda VPLMN (VPLMN2) ,

comprendiendo la primera VPLMN un primer nodo de soporte de servicio (403) y un primer nodo de soporte de puerta de enlace de proxy (404) ; comprendiendo la segunda VPLMN un segundo nodo de soporte de servicio (408) y un segundo nodo de soporte de puerta de enlace de proxy (409) , en el que la carga útil es enviada directamente entre una red de radio respectiva de la VPLMN respectiva a un nodo de soporte de puerta de enlace local (405) en una Red de Telefonía Móvil Terrestre Pública Local, HPLMN, a través de respectivos túneles (417, 418) , sin atravesar los nodos de soporte de servicio primero y segundo, comprendiendo el método las etapas de:

a.enviar una solicitud de contexto desde el segundo nodo de soporte de servicio (408) en la segunda VPLMN al primer nodo de soporte de servicio (403) en la primera VPLMN;

b.recibir una respuesta de contexto en el segundo nodo de soporte de servicio desde el primer nodo de soporte de servicio; c.enviar un reconocimiento de contexto desde el segundo nodo de soporte de servicio al primer nodo de soporte de servicio; d.enviar una solicitud de reubicar contexto de Protocolo de Datos en Paquetes, es decir, PDP (Packet Data Protocol, en inglés) , desde el segundo nodo de soporte de servicio al segundo nodo de soporte de puerta de enlace de proxy (409) en la segunda VPLMN; e.enviar una solicitud de actualizar contexto de PDP al nodo de soporte de puerta de enlace local (405) en la HPLMN de la unidad de comunicación de telefonía móvil inalámbrica desde el segundo nodo de soporte de puerta de enlace de proxy;

f. recibir en el segundo nodo de soporte de puerta de enlace de proxy una respuesta de actualizar contexto de PDP; g.enviar una respuesta de reubicar contexto de PDP al segundo nodo de soporte de servicio desde el segundo nodo de soporte de puerta de enlace de proxy; h.enviar un mensaje de actualizar ubicación desde el segundo nodo de soporte de servicio a un registro de ubicación local (406) en la HPLMN de la unidad de comunicación de telefonía móvil inalámbrica (401) ;

i. recibir un mensaje de reconocimiento de actualizar ubicación en el segundo nodo de soporte de servicio desde el registro de ubicación local.

2. El método de acuerdo con la reivindicación 1, en el que el segundo nodo de soporte de puerta de enlace de proxy (409) actúa como un nodo intermedio para toda la comunicación de control en las etapas a a c, es decir, que la solicitud de contexto, respuesta de contexto y reconocimiento de contexto son transmitidas a través del segundo nodo de soporte de puerta de enlace de proxy (409) .

3. El método de acuerdo con la reivindicación 1, en el que un primer nodo de soporte de puerta de enlace de proxy

(404) situado en la primera VPLMN actúa como un nodo intermedio para toda la comunicación de control en las etapas a a c, esto es, que la solicitud de contexto, la respuesta de contexto y el reconocimiento de contexto son transmitidos a través del primer nodo de soporte de puerta de enlace de proxy (404) .

4. El método de acuerdo con la reivindicación 1, que comprende también las etapas de: 45

j. recibir un mensaje de cancelar ubicación desde el registro de ubicación local en la PLMN Local de la unidad de comunicación de telefonía mocil inalámbrica; k.enviar una solicitud de borrar contexto de Protocolo de Datos en Paquetes, es decir, PDP (Packet Data Protocol, en inglés) reubicado desde el primer nodo de soporte de servicio a un primer nodo de soporte de puerta de enlace de proxy (404) en la primera VPLMN;

l. enviar una repuesta de borrar contexto de PDP reubicado al primer nodo de soporte de servicio desde el primer nodo de soporte de puerta de enlace de proxy; y

m. enviar un mensaje de reconocimiento de cancelar ubicación al registro de ubicación local.

5. El método de acuerdo con la reivindicación 1, que comprende también las etapas de

-recibir información de conteo de tráfico desde la unidad de comunicación de telefonía móvil inalámbrica en los nodos de soporte de servicio primero y segundo (403, 408) ; -combinar información de conteo de tráfico desde el equipo de usuario con información de conteo de tráfico desde los nodos de soporte de servicio en un mensaje de tarificación; y -enviar el mensaje de tarificación a un servidor de facturación local.

6. Un nodo de soporte de servicio (408) , para permitir que una unidad de comunicación de telefonía móvil

inalámbrica (401) itinere desde una primera Red de Telefonía Móvil Terrestre Pública visitada, VPLMN (Visited 65 Public Land Mobile Network, en inglés) , (VPLMN1) a una segunda VPLMN, (VPLMN 2) , comprendiendo la primera VPLMN un primer nodo de soporte de servicio (403) y un primer nodo de soporte de puerta de enlace de proxy (404) ; comprendiendo la segunda VPLMN el nodo de soporte de servicio (408) , constituyendo un segundo nodo de soporte de servicio, y un segundo nodo de soporte de puerta de enlace de proxy (409) , en el que se envía carga útil directamente entre una red de radio respectiva de la VPLMN respectiva a un nodo de soporte de puerta de enlace local (405) en una Red de Telefonía Móvil Terrestre Pública Local, HPLMN (Home Public Land Mobile Network, en inglés) , HPLMN, a través de respectivos túneles, sin atravesar los nodos de soporte primero y segundo, comprendiendo el nodo de soporte de servicio (408) una unidad de procesamiento (901) que está adaptada para:

a.enviar una solicitud de contexto al primer nodo de soporte de servicio (403) en la primera VPLMN para la unidad de comunicación de telefonía móvil inalámbrica (401) ; b.recibir una respuesta de contexto desde el primer nodo de soporte de servicio; c.enviar un reconocimiento de contexto al primer nodo de soporte de servicio; d.enviar una solicitud de reubicar contexto de PDP al segundo nodo de soporte de puerta de enlace de proxy

(409) en la PLMN actual;

e.recibir una respuesta de reubicar contexto de PDP desde el segundo nodo de soporte de puerta de enlace de proxy;

f. enviar un mensaje de actualizar ubicación a un registro de ubicación local (406) en la HPLMN de la unidad de comunicación de telefonía móvil inalámbrica (401) ; g.recibir un mensaje de reconocimiento de actualizar ubicación del registro de ubicación local (406) .

7. El nodo de soporte de servicio de acuerdo con la reivindicación 6, en el que además la unidad de procesamiento está también adaptada para h.recibir un mensaje de cancelar ubicación desde el registro de ubicación local;

i. enviar una solicitud de borrar contexto de PDP reubicado a un primer nodo de soporte de puerta de enlace de proxy (404) ;

j. recibir una respuesta de borrar contexto de PDP reubicado desde un primer nodo de soporte de puerta de enlace de proxy; y k.enviar un mensaje de reconocimiento de cancelar ubicación al registro de ubicación local.

8. Un nodo de soporte de puerta de enlace de proxy (409) para permitir que una unidad de comunicación de telefonía móvil inalámbrica (401) itinere de una primera Red de Telefonía Móvil Terrestre Pública visitada, VPLMN (Visited Public Land Mobile Network, en inglés) , VPLMN, (VPLMN1) a una segunda VPLMN, (VPLMN2) , comprendiendo la primera VPLMN un primer nodo de soporte de

servicio (403) y un primer nodo de soporte de puerta de enlace de proxy (404) ; comprendiendo la segunda VPLMN el nodo de soporte de servicio (408) , constituyendo el segundo nodo de soporte de servicio, y el nodo de soporte de puerta de enlace de proxy (409) , que constituye un segundo nodo de soporte de puerta de enlace de proxy, donde se envía carga útil directamente entre una respectiva red de radio de la respectiva VPLMN a un nodo de soporte de puerta de enlace local (405) en una Red de Telefonía Móvil Terrestre Pública Local, HPLMN (Home Public Land

Mobile Network, en inglés) , HPLMN, a través de respectivos túneles, sin atravesar los nodos de soporte primero y segundo, el nodo de soporte de puerta de enlace de proxy comprende una unidad de procesamiento (901) adaptada para:

a.recibir una solicitud de reubicar contexto de Protocolo de Datos en Paquetes, es decir, PDP (Packet Data 45 Protocol, en inglés) desde el segundo nodo de soporte de servicio (408) ; b.enviar una solicitud de actualizar contexto de PDP al nodo de soporte de puerta de enlace local (405) ; c.recibir una respuesta de actualizar contexto de PDP desde el nodo de soporte de puerta de enlace local; d.enviar una respuesta de reubicar contexto de PDP al segundo nodo de soporte de servicio.

9. El nodo de soporte de puerta de enlace de proxy de acuerdo con la reivindicación 8, en el que además la unidad de procesamiento está adaptada para:

e. recibir una solicitud de borrar contexto de Protocolo de Datos en Paquetes, es decir, PDP (Packet Data Protocol, en inglés) reubicado del primer nodo de soporte de servicio (403) ; y 55 f. enviar una respuesta de borrar contexto de PDP reubicado al primer nodo de soporte de servicio.