ES2225563T3 - Procedimiento para transferir un tunel entre nodos de un sistema gprs. - Google Patents

Abstract

Procedimiento para transferir un túnel desde un primer nodo de control (SGSN1) de un sistema de comunicación de radio móvil, especialmente de un sistema GPRS, sobre un segundo nodo (SGSN2), en el que el sistema de comunicación de radio móvil presenta nodos de control (SGSN1, SGSN2) y un nodo de puerta de acceso (GGSN), en el que al menos uno de estos nodos es un nodo según la Versión 0 del protocolo GTP y otros de estos nodos son nodos según la Versión 1 del Protocolo GTP, en el que el segundo nodo (SGSN2) recibe un mensaje sobre la necesidad de la transferencia del túnel (solicitud RAU) desde un terminal (MS) y a continuación dirige una solicitud para la adaptación del contexto que afecta al túnel al nodo de la puerta de acceso (GGSN), caracterizado porque en el caso de que el primer nodo de control (SGSN1) sea un nodo según la Versión 0 y el segundo no de control (SGSN2) y el nodo de la puerta de acceso (GGSN) sean nodos según la Versión 1, la solicitud para la adaptación del contexto contiene una indicación de la IMSI y del NSAPI del túnel respectivo.

Description

Procedimiento para transferir un túnel entre nodos de un sistema GPRS.

La presente invención se refiere a un procedimiento para transferir un túnel desde un primer nodo de control de un sistema GPRS (Servicio General de Radio en Paquetes) a un segundo nodo.

La transferencia de un túnel es necesaria cuando un terminal móvil, que utiliza el túnel respectivo, cambia desde una zona de entrada del primer nodo de control a la zona del segundo nodo. Este cambio tiene como consecuencia una RAU (Actualización de Área de Encaminamiento), en cuya trayectoria se transmiten datos sobre el contexto PDP del terminal desde el primero al segundo nodo de control. La transmisión de estos datos se realiza en forma de mensajes según el Protocolo GTP (Protocolo del Túnel GPRS). Los mensajes del protocolo GTP son utilizados, entre otras cosas, para el establecimiento y la desconexión de contextos PDP y para la transmisión de contextos PDP en el caso de Actualizaciones de Área de Encaminamiento). Para los detalles sobre el Protocolo GTP se remite a la publicación de especificación 3G TS 23.060 Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service Description; Stage 2 (edición 1999), por ejemplo en la Versión V3.3.0 de Abril del 2000 del 3GPP (3rd Generation Partnership Project, www.3GPP.ORG.

Los datos transmitidos entre los dos nudos de control posibilitan al segundo nodo de control establecer un contacto con un nodo de puerta de acceso, y obtener desde allí las informaciones completas necesarias sobre el contexto, se le posibilitan conmutar el túnel GTP, para que se pueda continuar el servicio de forma ininterrumpida para el terminal.

Hasta ahora están normalizadas dos versiones para el Protocolo GTP, por una parte, la versión GTP 0, designada también como Edición 98 ó 97, en GSM 09.60; por otra parte, la versión GTP 1, designada también como Edición 99, en la publicación TS 23.060 ya mencionada. La normalización de la Versión 1 exige que los nodos según la Versión 1 deben poder colaborar con los de la Versión 0, y que el túnel GTP pueda funcionar con la versión más alta posible respectiva.

Para que un nodo receptor pueda reconoce la versión GTP, según la cual ha sido creado un mensaje recibido, los mensajes llevan en cada caso en la cabecera una identificación, que posibilita la asociación a la versión respectiva. Los mensajes, que han sido creados según la Versión 1, no pueden ser interpretados por nodos, que trabajan según la Versión 0 o según normalizaciones todavía más antiguas. Por lo tanto, un nodo según la Versión 1 debe estar en condiciones, según la versión GTP, que utiliza un nodo, al que envía mensajes, de crear estos mensajes o bien según la Versión 1 o la Versión 0.

Otra diferencia esencial entre la Versión 0 y la versión 1 del Protocolo GTP es el procedimiento, según el cual un mensaje es asociado al túnel creado o bien al contexto PDP. En la Versión 0 se utilizan a tal fin los llamados identificadores del túnel, de forma abreviada TID, que se transmiten como parte del mensaje y que se componen por la IMSI (Identidad Internacional del Abonado Móvil) y el NSAPI (Identificador del Punto de Acceso de Servicio de la Capa de la Red). La IMSI es el identificador unívoco de un abonado en todo el mundo; el NSAPI hace referencia a uno de varios contextos PDP, que pueden ser asociados al abonado. Puesto que el identificador del túnel con 12 bytes de largo es realmente poco práctico de manejar, se utilizan en su lugar las llamadas etiquetas de flujo con una longitud de 2 bytes, que posibilitan una asociación rápida de mensajes a un contexto. Pero las etiquetas de flujo no son asignada de una manera necesariamente unívoca, puesto que solamente tienen un intervalo de valores de aproximadamente 65.000 y se pueden establecer claramente más contextos por
nodo.

Las etiquetas de flujo son asignadas en cada caso durante la activación de un túnel GTP; cada nodo implicado en el túnel comunica en este caso al nodo opuesto con qué etiqueta de flujo recibirá los mensajes siguientes sobre este túnel o, lo que es equivalente, para este contexto PDP. En el primer mensaje, que se envía en el marco de la formación de un túnel desde un nodo de control a un nodo de puerta de acceso (Crear la Solicitud de Contexto PDP), la etiqueta de flujo está en 0, porque el nodo de la puerta de acceso no ha podido asignar todavía ninguna etiqueta de flujo, y se transmite el identificador del túnel; todos los mensajes siguientes de este túnel deben emitirse con la etiqueta de flujo asignada por el nodo de la puerta de acceso. Tomado con exactitud, se asignan en cada caso dos etiquetas de flujo, una para la señalización y una para datos. Pero a continuación solamente se considera la etiqueta de flujo para señalización.

En la Versión 1 de GTP se asignan los llamados TEID (Identificadores del Punto Final del Túnel), que tienen la misma función que las etiquetas de flujo, pero poseen una longitud de 4 bytes. Por lo tanto, los TEID no son compatibles con las etiquetas de flujo según la Versión 0, pero se pueden asignar de una manera unívoca. El identificador del túnel conocido a partir de la Versión 0 no está contenido ya en mensajes según la Versión 1. IMSI y NSAPI, que posibilitan una asociación unívoca del mensaje a un contexto PDP, solamente están contenidos en el primer mensaje (Crear la Solicitud de Contexto PDP) desde el nodo de control al nodo de la puerta de acceso.

Dentro de la versión respectiva funcionan perfectamente ambas versiones del GTP. En la normalización se requiere que un nodo para la Versión 1 soporte también la Versión 0, es decir, que sea compatible hacia atrás. Esto es necesario para que puedan colaborar nodos de diferentes Versiones.

Sin embargo, se plantean problemas cuando un abonado de radio móvil se mueve en una red, que contiene nodos de diferentes versiones y en este caso cambia desde la zona de entrada de un nodo de control a otro nodo. Este cambio tiene como consecuencia una RAU (Actualización del Área de Encaminamiento), en la que un túnel es transferido desde el nodo, en cuya zona de entrada se ha mantenido anteriormente el abonado, al nodo de la nueva zona de entrada. En el marco de este procedimiento deben transmitirse datos sobre el contexto PDP desde el nodo antiguo al nodo nuevo con la ayuda de mensajes GTP. Estos datos son requeridos por el nodo nuevo para establecer el contacto con el nodo de la puerta de acceso y para conmutar el túnel GTP, de manera que se puede continuar el servicio para el abonado de forma ininterrumpida. Cuando todos los tres nodos implicados en la conmutación del túnel pertenecen a la misma versión GTP, la conmutación no plantea problemas. Tampoco se plantean problemas aunque dos nodos de ellos sean nodos de la versión 0 y el tercero sea un nodo de la versión 1, puesto que todos los mensajes intercambiados entre los nodos deben ser mensajes según la Versión 0. Sin embargo, cuando dos nodos pertenecen a la Versión 1 y el tercero pertenece a la Versión 0, provoca dificultades el hecho de que los dos nodos según la Versión se comunican entre sí con mensajes de la Versión 1 y se comunican con el tercer nodo con mensajes de la Versión 0. Hay que distinguir tres casos:

1.

El abonado móvil se mueve desde un primer nodo de control según la Versión 0 a un segundo nodo según la versión 1. En esta situación, debe utilizarse la Versión 0 de GTP para la comunicación del primer nodo de control con el segundo nodo y con el nodo de la puerta de acceso; la comunicación entre el nodo de la puerta de acceso y el segundo nodo de servicio tiene lugar según la Versión 1. Durante la formación del túnel, se asocia al nodo de la puerta de acceso una etiqueta de flujo, que es utilizada por el primer nodo de control para la identificación de mensajes que pertenecen al túnel. Cuando los dos nodos de control establecen contacto para preparar la transferencia del túnel, entonces se comunican según la Versión 0, y el primer nodo de control proporciona al segundo nodo la etiqueta de flujo, que ha sido asociada al túnel originalmente por el nodo de la puerta de acceso. Para obtener los datos de contexto necesarios del túnel desde el nodo de la puerta de acceso, el segundo nodo de control debería poder enviar un mensaje con esta etiqueta de flujo al nodo de la puerta de acceso. En cambio, el segundo nodo de control y el nodo de la puerta de acceso se comunican según la Versión 1, que no permite la transmisión de la etiqueta de flujo. En efecto, en lugar de la etiqueta de flujo, se podría transmitir un TEID según la Versión 1, pero éste no está definido en el nodo de la puerta de acceso para el túnel. El nodo de la puerta de acceso no puede asociar, por lo tanto, al canal existente ningún mensaje según la Versión 1 de GTP. Puesto que el mensaje "Actualizar la Solicitud de Contexto PDP" no está contenido ni en la IMSI ni en el NSAPI, el nodo de la puerta de acceso no está entonces en condiciones de encontrar el contexto, cuando ignora el TEID.

2.

El abonado de radio móvil se mueve desde un primer nodo de control según la Versión 1 hacia un nodo según la Versión 0. En este caso, durante la comunicación entre el primer nodo de servicio y el nodo de la puerta de acceso se ha utilizado la Versión 1 de GTP en el marco de la formación del túnel, es decir, que se ha establecido, en efecto, un TEID para el túnel, pero no una etiqueta de flujo. Para la comunicación entre los dos nudos de control debe utilizarse la Versión 0 de GTP, pero ésta sólo permite la etiqueta de flujo. No existe una posibilidad para transmitir el TEID al segundo nodo, y aunque existiera, éste no podría ser procesado. Por lo tanto, el segundo nodo de control no tiene ninguna posibilidad de hallar las etiquetas de flujo, con las que podría solicitar los datos de contexto necesarios del nodo de la puerta de acceso.

3.

El abonado de radio móvil se mueve desde un nodo de control según la Versión 1 hacia otro nodo de la misma versión, pero el nodo de la puerta de acceso trabaja también según la versión 0. En este caso, los nodos de control se comunican entre sí según la Versión 1, pero con el nodo de la puerta de acceso según la Versión 0. De esta manera, el nodo de la puerta de acceso asocia una etiqueta de flujo durante la formación de un túnel, pero ésta no puede ser transmitida desde el primer nodo al segundo nodo, de manera que éste no puede consultar las informaciones de contexto del nodo de la puerta de acceso.

El cometido de la invención consiste en indicar un procedimiento para transferir un túnel desde un primer nodo de control de un sistema GPRS a un segundo nodo, que funcionan también cuando bajo el nodo de servicio y el nodo de la puerta de acceso se encuentran al menos un nodo según la Versión 0 y otro nodo según la Versión 1 del Protocolo GTP.

El cometido se soluciona para el caso de que el primer nodo de servicio sea un nodo según la Versión 0 y el segundo nodo de servicio y el nodo de la puerta de acceso sean nodos según la Versión 1, por medio de un procedimiento según la reivindicación 1. Éste prevé que la solicitud para la adaptación del contexto, que ajusta el segundo nodo de control al nodo de la puerta de acceso, contenga una indicación de IMSI y NSAPI del túnel respectivo. Este cometido permite al nodo de la puerta de acceso establecer una correspondencia unívoca con un contexto memorizado y de esta manera proporcionar los datos de contexto necesarios al segundo nodo.

Las formas de realización preferidas del mismo están indicadas en las reivindicaciones dependientes 2 a 4 respectivas.

La indicación necesaria de IMSI y NSAPI se puede transmitir de una manera muy sencilla porque el segundo nodo de control y el nodo de la puerta de acceso ejecutan el túnel establecido bajo la Versión 0 del Protocolo GTP bajo la misma versión del protocolo. En este caso, la solicitud para la adaptación del contexto, a emitir desde el segundo nodo hacia el nodo de la puerta de acceso, el mensaje "Actualizar la Solicitud de Contexto PDP", contiene desde el principio estos datos necesarios. Por lo tanto, esta solución incluye que el protocolo, que aplica el segundo nodo de control durante la comunicación con el nodo de la puerta de acceso, depende de la historia anterior del túnel, a la que pertenecen los mensajes intercambiados. Cuando un túnel ha sido establecido por el segundo nodo propiamente dicho o por otro nodo según la Versión 1, la comunicación con el nodo de la puerta de acceso tiene lugar según la Versión 1; si el túnel fue establecido originalmente por un nodo según la Versión 0, entonces la comunicación con el nodo de la puerta de acceso tiene lugar en adelante según la Versión 0, aunque ambos nodos dominen la Versión 1.

Un control de este tipo de la versión utilizada se puede realizar de una manera sencilla cuando el primer nodo de servicio emite en primer lugar un mensaje, que inicia el proceso de tendido del túnel, (Respuesta de Contexto SGSN) al segundo nodo de control, el segundo nodo de control utiliza la versión de este mensaje para su solicitud para la adaptación del contexto al nodo de la puerta de acceso y éste contesta todos los mensajes dirigidos al mismo , en la versión que los ha recibido.

Una posibilidad alternativa es que el segundo nodo emite como solicitud para la adaptación del túnel, en lugar del mensaje convencional "Actualizar la Solicitud de Contexto PDP", un mensaje del tipo "Crear la Solicitud de Contexto PDP" según la Versión 1. Este mensaje es procesado de forma correcta, según la publicación citada anteriormente TS 29.060 por el nodo de la puerta de acceso de recepción, es decir, que se recupera el contexto PDP existente y se substituyen los parámetros modificados. De esta manera, tanto se tiende el túnel para el segundo nodo de control como también se modifica en la versión.

Además, de una manera alternativa, se puede prever que también el mensaje "Actualizar la Solicitud de Contexto PDP" pueda ser enviado con un TEID, que tiene el valor 0, y que contiene, adicionalmente a los elementos de información previstos según TS 23.060, también IMSI y NSAPI con el fin de posibilitar una asociación al contexto PDP correspondiente en el nodo de la puerta de acceso.

En el caso de que el segundo nodo de control o el nodo de la puerta de acceso sea un nodo según la Versión 0 y los otros nodos respectivos sean según la Versión 1, el cometido se soluciona por medio del procedimiento según la reivindicación 5, en el que se pone a disposición del segundo nodo de control desde el primer nodo de control una etiqueta de flujo, que necesitan el segundo nodo de control y el nodo de la puerta de acceso, para poder transferir el túnel desde el primero al segundo nodo de control.

Las formas de realización preferidas de los mismos se indican en las reivindicaciones dependientes 6 a 17 respectivas.

En este caso, existe diferentes posibilidades para realizar la asignación de la etiqueta de flujo. Cuando el nodo de la puerta de acceso es un nodo según la Versión 1, por lo que la formación del canal ha tenido lugar según la Versión 1, solamente se ha asignado al túnel durante la formación un TEID, pero no una etiqueta de flujo. En este caso, de una manera más conveniente, el primer nodo de control es el que lleva a cabo la asignación de una etiqueta de flujo al túnel.

Una primera variante prevé que el primer nodo de control asocie al contexto una etiqueta de flujo con un valor, que es específico para la transferencia desde un nodo de control según la Versión 1 a un nodo de control según la Versión 0, es decir, que es diferente de todas las etiquetas de flujo que se utilizan para la comunicación de nodo que trabajan de forma regular según la Versión 0. El segundo nodo de control puede reacciona a la recepción de una etiqueta de flujo específica de este tipo, enviando, en lugar de un mensaje "Actualizar la Solicitud de Contexto PDP", que enviaría normalmente al nodo de la puerta de acceso, si hubiera recibido una etiqueta de flujo correcta desde un primer nodo de control de la misma versión, un mensaje "Crear la Solicitud de Contexto PDP" al nodo de la puerta de acceso, que contiene IMSI y NSAPI y, por lo tanto, permite una identificación unívoca del contexto a adaptar en el nodo de la puerta de acceso. De una manera alternativa, también puede estar previsto que el segundo nodo de control emita un mensaje "Actualizar la Solicitud de Contexto PDP" al nodo de la puerta de acceso, que contiene, sin embargo, a diferencia del protocolo vigente de la Versión 1, adicionalmente IMSI y NSAPI y de esta manera permite de nuevo una identificación. Un modo de proceder de este tipo es posible porque la norma existente no prevé solicitudes de actualización PDP con etiqueta de flujo 0 y, por lo tanto, su procesamiento no está normalizado.

Una segunda variante el procedimiento, que se puede aplicar igualmente cuando el nodo de la puerta de acceso trabaja según la Versión 1 y el segundo nodo de control trabaja según la Versión 0, prevé que el nodo de la puerta de acceso no sólo asocie a cada contexto establecido por el primer nodo de servicio según la Versión 1 un TEID, sino que al mismo tiempo disponga de un procedimiento establecido, según el cual puede asociar una etiqueta de flujo a cada contexto establecido según la Versión 1 o bien dicho más exactamente su TEID. De esta manera, en el nodo de la puerta de acceso, a cada contexto establecido según la versión 1 de GTP corresponde un TEID y una etiqueta de flujo. De una manera más conveniente, el nodo de la puerta de acceso puede tener en cuenta ya durante la asignación de TEIDs las etiquetas de flujo que resultan de ello, en el sentido de que es posible una identificación efectiva de contextos con la ayuda de las etiquetas de flujo. El mismo procedimiento está disponible también para el primer nodo de control. Cuando un túnel, que ha sido establecido por el primer nodo de control según la Versión 1 de GTP, debe ser transferido a un segundo nodo de control según la Versión 0, entonces el primer nodo de control puede calcular a través de la aplicación del procedimiento directamente el valor correcto de la etiqueta de flujo y la puede poner a la disposición del segundo nodo de control, con cuya ayuda el nodo de la puerta de acceso puede identificar el contexto PDP. De esta manera, el segundo nodo de control puede reaccionar al nodo de la puerta de acceso como si hubiera recibido transferido el túnel desde un nodo de control según la Versión 0.

Un procedimiento preferido, porque es especialmente sencillo, para la asignación de la etiqueta de flujo a un TEID es la equiparación de la etiqueta de flujo con dos bytes poco significativos del TEID. En cambio, si el nodo de la puerta de acceso es un nodo según la Versión 0 y los dos nodos de control son nodos según la Versión 1, entonces se ha realizado la asociación de una etiqueta de flujo al túnel ya durante su formación desde el nodo de la puerta de acceso, y esta etiqueta de flujo es conocida por el primer nodo de control. Para transferir esta etiqueta de flujo al segundo nodo -a través de mensajes de la Versión 1-, es conveniente "empaquetarla" en el campo TEID de un mensaje de la Versión 1.

Puesto que la etiqueta de flujo no rellena el campo TEID, es posible de una manera ventajosa utilizar el espacio remanente en el campo TEID para la transmisión de un valor predeterminado, que no se utiliza en otro caso en un TEID y en el que el segundo nodo de control puede reconocer, por lo tanto, que en el valor transmitido no se trata de un TEID, sino de una etiqueta de flujo "empaquetada", y puede procesar de una manera correcta el valor de una forma correspondiente. Un valor predeterminado de este tipo puede ser, por ejemplo, 0.

A continuación se explican en detalle ejemplos de realización con la ayuda de los dibujos. En este caso:

Las figuras 1 a 3 muestran las constelaciones posibles durante la transferencia de un túnel entre dos nodos de control bajo la participación de dos modos respectivos según la Versión 1 de GTP y un nodo según la Versión 0.

Las figuras 4 a 6 muestran el flujo de la señalización durante la transferencia del túnel en las diversas constelaciones.

En la constelación de la figura 1, el primer nodo de control SGSN1, a través del cual ha sido establecido originalmente el túnel del terminal MS, es un nodo según la Versión 0 de GTP; se comunica con el nodo de la puerta de acceso GGSN y con el segundo nodo de control SGSN2 según la Versión 0 de GTP, es decir, que los mensajes intercambiados están identificados por etiqueta de flujo y por TEID. El nodo de la puerta de acceso GGSN y el segundo nodo de control SGSN2 se comunican entre sí según la Versión 1 con mensajes que están identificados por medio de TEIDs.

La figura 4 muestra el diagrama de la señalización entre un terminal MS y los tres nodos SHSN1, SGSN 2 y GGSN, por una parte, durante la activación de un contexto PDP y, por otra parte, durante la transferencia del túnel GTP. En este caso, los mensajes según la Versión 0 de GTP se representan a través de flechas finas y los mensajes según la Versión 1 se representan a través de flechas gruesas. Los mensajes, que no son intercambiados entre los nodos y, por lo tanto, no están vinculados al protocolo GTP lo mismo que los mensajes intercambiados con el terminal MS están representados con líneas de trazos.

En la etapa 1, el terminal MS envía una solicitud para la activación de un contexto PDP (Activar Solicitud de Contexto PDP) al SGSN1, que especifica, entre otras cosas, la NSAPI y el tipo o bien la calidad del servicio deseado. El nodo de control SGSN1 dirige a continuación una solicitud "Crear la Solicitud de Contexto PSP" según la Versión 0 de PDP al nodo de la puerta de acceso GGSN, en la que se comunica la IMSI y el NSAPI al nodo de la puerta de acceso (etapa 2). El nodo de la puerta de acceso genera a continuación una entrada nueva en su Tabla de contextos PDP, que le permite encaminar paquetes de datos del terminal MS entre el SGSGN1 y una red PDP externa, no representada en las figuras y facturar tasas, y le asigna una etiqueta de flujo. Como confirmación, emite en la etapa 3 un mensaje "Crear Respuesta de Contexto PDP" se retorno al primer nodo de control SGSN1, que contiene la etiqueta de flujo asignada. El primer nodo de control configura, por su parte, la instalación del contexto al terminal MS a través de un mensaje "Activar la Aceptación del Contexto PDP" (etapa 4).

A través de la etiqueta de flujo asociada, el SGSN1 está en condiciones de identificar paquetes de datos del terminal MS, que pertenecen al nueva contexto instalado, de tal manera que el nodo de la puerta de acceso GGSN puede diferenciarlo de los paquetes de datos de otros terminales o de paquetes de datos del mismo terminal que pertenecen a otros contextos.

El proceso de la transferencia de un túnel comienza con que el terminal envía en la etapa 5 una solicitud "Solicitud de Actualización del Área de Encaminamiento" al segundo nodo de control SGSN2. Este nodo SGSN2 trabaja según la Versión 1 de GTP.

A través de un mensaje "Solicitud de Contexto SGSN" según la Versión 0 de GTP (etapa 6), da a conocer en primer lugar al primer nodo de control SGSN1 que debe transmitirse el contexto; el SGSN1 confirma esto a través de un mensaje "Respuesta de Contexto SGSN" (etapa 7) y comienza a memorizar temporalmente paquetes de datos que llegan desde la red PDP y que están destinados para la estación de abonado MS. Después de que en la etapa 8 ha confirmado el nuevo nodo de control SGSN2 su disponibilidad para la recepción de datos a través de un mensaje "Reconocimiento del Contexto SGSN", el nodo SGSN1 transmite los paquetes de datos memorizados temporalmente en la etapa 9 al nodo SGSN2.

Para conseguir que los paquetes de datos destinados para la estación de abonados MS no son encaminados ya al SGSN1, sino directamente al nuevo nodo de control SGSN2, el nodo de la puerta de acceso GGSN debe ser informado sobre la modificación. Esto se realiza a través de una solicitud para la adaptación del contexto, que se transmite en la etapa 10 desde el SGSN2 al nodo de la puerta de acceso GGSN.

Mientras que en el caso de la recepción de un contexto desde un nodo de control de la misma versión, la solicitud para la adaptación del contexto sería un mensaje "Actualizar la Solicitud de Contexto PDP", el segundo nodo de control utiliza aquí en el caso considerado aquí como solicitud un mensaje del tipo "Crear la Solicitud de Contexto PDP". Este mensaje, en oposición al mensaje "Actualizar la Solicitud de Contexto PDP" según la Versión 1 de GTP contiene la IMSI y el NSAPI del terminal MS. El nodo de la puerta de acceso no espera en un mensaje de este tipo que se emita con un TEID definido; por lo tanto, no intenta interpretar un TEID de este tipo del mensaje, sino que identifica el contexto respectivo en el índice llevado por él directamente con la ayuda de la IMSI y del NSAPI. La entrada del contexto hallada de esta manera es actualizada asociándole el nuevo nodo de control SGSN2 así como la Versión de GTP, de acuerdo con la cual se desarrolla la comunicación entre el GGSN y el nodo de control.

Si el nodo de la puerta de acceso ha ejecutado esta operación con éxito, entonces lo confirma en la etapa 11 al nuevo SGSN2 a través de un mensaje, que puede ser del tipo "Crear Respuesta de Contexto PDP" o "Actualizar Respuesta de Contexto PDP".

Antes de que el terminal MS reciba en la etapa 18 una confirmación de su solicitud RAU "Aceptación de la Actualización del Área de Encaminamiento", tiene lugar todavía un intercambio de mensajes de los dos nodos de control con el Registro Local HLR del sistema de comunicaciones de radio móvil, en cuyo desarrollo se anota en este registro la asociación del terminal MS al nuevo nodo de control SGSN2. Estas etapas no se diferencian de las etapas conocidas para una comunicación por radio GSM o UMTS y, por lo tanto, no se describen aquí en detalle. De una manera alternativa a la utilización del mensaje "Crear la Solicitud de Contexto PDP" en la etapa 10 se puede aplicar también un mensaje ligeramente modificado con respecto a la Versión 1 vigente de GTP del tipo "Actualizar la Solicitud de Contexto PDP". Es mensaje modificado contiene un TEID con el valor 0 así como una IMSI y un NSAPI del terminal MS. El nodo de la puerta de acceso GGSN no asigna TEIDs con valor 0. Cuando recibe un mensaje "Actualizar la Solicitud de Contexto PDP" con TEID = 0, entonces puede deducir a partir de ello que el TEID no ha sido asignado por el nodo de la puerta de acceso GGSN y que no le corresponde ninguna entrada en el índice de contextos del GGSN. Por lo tanto, el GGSN recurre en tal caso a IMSI y NSAPI, para identificar el contexto afectado por el mensaje "Actualizar la Solicitud de Contexto PDP" y para actualizarlo como se ha descrito anteriormente.

Otra alternativa es que el segundo nodo de control para la solicitud de actualización de la etapa 10 selecciona en cada caso aquella versión GTP, en la que ha recibido en la etapa S7 el mensaje "Reconocimiento del contexto SGSN", por lo tanto aquí la Versión 0. De esta manera, se manifiesta frente al GGSN para el contexto respectivo como nodo de la Versión 10, y puede identificar el contexto a adaptar a éste por medio de la indicación de una etiqueta de flujo, y recibe desde el nodo de la puerta de acceso mensajes de respuesta igualmente en la Versión 0. De esta manera, el contexto es transferido correctamente sobre el nuevo nodo de control SGSN2, aunque se mantiene la versión GTP utilizada.

Un segundo procedimiento para transferir el túnel desde el primer nodo de control GGSN1 sobre el segundo GGSN2 se diferencia del esquema de señalización mostrado en la figura 4 porque también el segundo nodo de control utiliza en la etapa 10 para su solicitud para la actualización del contexto la Versión 0, en la que ya ha recibido en la etapa 7 la etiqueta de flujo del túnel. El nodo de la puerta de acceso contesta a ello en la etapa 11 igualmente utilizando la Versión 0. Es decir, que aunque el segundo nodo de control SGSN2 y el nodo de la puerta de acceso GGSN dominan la Versión 1, transfieren el túnel formado bajo la Versión 0 utilizando la versión 0.

Puesto que en este segundo procedimiento no se modifica la versión del túnel durante la transferencia sobre el segundo nodo de control, no necesarias medidas de prevención especiales en el caso de que el túnel deba ser transferido por segunda vez, sobre un tercer nodo de control según la Versión 1.

Durante la transferencia de este túnel de la Versión 0 desde un segundo nodo de control a un tercer nodo de control, que aplican ambos la Versión 1, se plantean los mismos problemas que en el caso en el que un túnel formado entre un primer nodo de control según la Versión 1 y un nodo de la puerta de acceso según la Versión 0 debe ser transferido a un segundo nodo de control según la Versión 1. Algunas de las soluciones descritas más delante de este problema son aplicables, por lo tanto, también a este caso.

La figura 2 muestra una configuración, en la que se comunican entre sí un primer nodo SGSN1 según la Versión 1 de GTP, un nodo de la puerta de acceso GGSN según la Versión 1 de GTP y un segundo nodo de control SGSN2 según la Versión 0. El primer nodo de control SGSN1 y el nodo de la puerta de Acceso GGSN utilizan entre sí, por lo tanto, mensajes según la Versión 1 identificados por medio del Identificador del Punto Final del Túnel TEID, los segundos nodos de control SGSN1 y SGSN2 utilizan entre sí mensajes según la Versión 0 identificados a través de etiquetas de flujo y TID.

La secuencia de las etapas para la formación y la transferencia del túnel, que se representa en la figura 5, corresponde a la mostrada en la figura 4. No obstante, las versiones GTP utilizadas para los diferentes mensajes, identificadas de nuevo por medio de flechas gruesas y finas, son diferentes. La solicitud de contexto "Crear la Solicitud de Contexto PDP" y la respuesta a ella en las etapas 2 y 3 corresponden en su objetivo a las mostradas en la figura 4, pero con la diferencia de que se emplea para ellas la Versión 1 de GTP, y de que, por lo tanto, el nodo de la puerta de acceso GGSN asocia al contexto un Identificador del Punto Final del Túnel TEID y no retransmite al primer nodo de control SGSN.

La solicitud "Solicitud de Contexto SGSN" según la Versión 0 de GTP, que el segundo nodo de control SGSN2 dirige en la etapa 6 al primer nodo, es contestada por éste con una "Respuesta de Contexto SGSN" según la Versión 0. En el caso de una transferencia de canal, que se desarrolla puramente según la Versión 0, este mensaje ha recibido en su elemento de información (IE) "Contexto PDP" una etiqueta de flujo asignada por el nodo de la puerta de acceso al primer nodo de control para este contexto. Puesto que aquí no existe tal etiqueta de flujo, se calcula en su lugar en el primer nodo de control una etiqueta de flujo de acuerdo con un procedimiento establecido de antemano a partir del TEID asignado por el nodo de la puerta de acceso GGSN. Un procedimiento especialmente sencillo para el cálculo de la etiqueta de flujo consiste en utilizar en cada caso los dos bytes menos significativos de un TEID como etiqueta de flujo y en pasar por alto los dos bytes más significativos. Esta etiqueta de flujo es utilizada por el segundo nodo de control SGSN2 en su solicitud, dirigida en la etapa 10 al nodo de la puerta de acceso, para la adaptación del contexto. Puesto que el nodo de la puerta de acceso GGSN "conoce" el procedimiento, según el cual el primer nodo de control GGSN1 genera etiquetas de flujo a partir de TEIDs, puede localizar a la recepción de la etiqueta de flujo correspondiente en una solicitud para la actualización del contexto en la etapa 10 desde el segundo nodo de control con facilidad un número reducido de contextos en su índice, que podrían estar afectados por la actualización. Entonces es posible sin más calcular entre éstos el contexto real afectado.

Otra posibilidad para actualizar el contexto es la utilización de etiquetas de flujo con el valor 0, de una manera similar a lo que se ha descrito anteriormente con referencia a la figura 4. Puesto que las etiquetas de flujo con este valor no están asignadas o bien son utilizadas en todo caso por un nodo de control según la Versión 0 en mensajes del tipo "Crear la Solicitud de Contexto PDP", en los que no se conoce todavía una etiqueta de flujo del túnel en el instante de la emisión del mensaje, el nodo de la puerta de acceso GGSN, cuando recibe desde el segundo nodo de control SGSN2 un mensaje con una etiqueta de flujo de este tipo con el valor 0, puede deducir a partir de ello que la etiqueta de flujo no puede haber sido asignada por él mismo y que, por lo tanto, debe tener lugar y una asociación del mensaje a un túnel omitiendo la etiqueta de flujo y utilizando información de identificación transmitida al mismo tiempo, es decir, la IMSI y el NSAPI del terminal que están contenido en el TID en la cabecera del mensaje.

Como otra alternativa se puede prever todavía un complemento de la Versión 0 de GTP, en el que el segundo nodo de control SGSN2 envía un mensaje del tipo "Crear la Solicitud de Contexto PDP", cuando recibe desde el primer nodo de control un mensaje con la etiqueta de flujo colocada en 0.

En la tercera constelación mostrada en la figura 3, ambos nodos de control SGSN1 y SGSN2 son nodos según la Versión 1 de GTP y el nodo de la puerta de acceso GGSN es un nodo según la Versión 0. La formación del túnel y su transferencia desde el primer nodo de control SGSN1 al segundo nodo de control SGSN2 se muestran en la figura 6. La formación del túnel en las etapas 1 a 4 se desarrolla exactamente de la misma manera que se ha descrito con referencia a las figuras 1 a 4. Los dos nodos de control deben aplicar entre ellas la Versión 1. Para transmitir la etiqueta de flujo, manipulada entre el nodo de control SGSN1 y el nodo de la puerta de acceso GGSN, al segundo nodo de control SGSN2, debe transportarse, por lo tanto, a través de una comunicación de la Versión 1. Para transportar este etiqueta de flujo hacia el segundo nodo de control SGSN2, el primer nodo de control SGSN1 se completa con dos bytes más significativos sobre el formato de un TEID, que se transmite en la etapa 7 (Respuesta de Contexto SGSN) al segundo nodo SGSN2.

De acuerdo con una primera variante del procedimiento, se intercambian a continuación dos mensajes representados como líneas de trazos en la figura 6: el nodo SGSN envía en la etapa 10' una solicitud para la adaptación del contexto (Actualizar la Solicitud de Contexto PDP) según la versión 1 al nodo de la puerta de acceso GGSN. Puesto que éste solamente domina la Versión 0, señaliza al segundo nodo SGSN2 (etapa 10'') que no puede procesar la solicitud. El segundo nodo reconoce en ello que el nodo de la puerta de acceso necesita un mensaje de la Versión 0 con una etiqueta de flujo y a continuación completa en la etapa 10 una solicitud nueva, esta vez según la Versión 0, en la que introduce los dos bytes menos significativos del TEID recibido por el primer nodo SGSN1 como etiqueta de flujo.

De acuerdo con una segunda variante, el primer nodo de control SGSN1 utiliza dos bytes con un valor predeterminado para completar la etiqueta de flujo asignada al túnel sobre el formato de un TEID. Este valor predeterminado, aquí 0, no debería ser asignado entonces en la generación normal de un contexto PDP de la Versión 1, de manera que el segundo nodo de control SGSN2 puede reconocer en el valor de estos dos bytes que en la información transmitida al mismo en la etapa 7 en el formato de un TEID se trata en realidad de una etiqueta de flujo, la restablece y, por lo tanto, puede seleccionar para la solicitud para la actualización del contexto en la etapa 10 desde el principio el formato de mensajes de la Versión 0 que puede ser interpretado por el nodo de la puerta de acceso GGSN.

Puesto que en esta segunda variante, la versión utilizada por el segundo nodo de control SGSN2 para la solicitud de la actualización no está establecida en el diálogo entre el segundo nodo SGSN2 y el nodo de la puerta de acceso GGSN por este último, sino que está determinada a través de la Versión del mensaje Respuesta de Contexto SGSN, esta variante es adecuada para el caso ya tratado anteriormente, de un túnel que se establece originalmente entre un nodo de control SGSN1 según la Versión 0 y un GGSN según la Versión 1 y luego se transfiere a un segundo nodo de control SGSN2 según la Versión 1 y manteniendo la versión del protocolo utilizada originalmente para el túnel a un tercer nodo de control según la Versión 1.

De acuerdo con una tercera variante, la información del contexto a transmitir en la etapa 7 se puede ampliar también en el sentido de que se pueden transportar tanto etiquetas de flujo como también el TEID, identificadas en cada caso como tales. Esto se puede realizar a través de la adición de un campo de datos adicional a la información del contexto, que recibe la etiqueta de flujo, de manera que, como se conoce, tanto el TEID como también la etiqueta de flujo se pueden transmitir al segundo nodo de control SGSN2. También es concebible la adición de un indicador sencillo, cuyo estado identifica el contenido del campo de TEID de un mensaje como el TEID o como etiqueta de flujo. De esta manera, no se limita el intervalo de valores para el TEID.

También esta tercera variante es adecuada para la transferencia de un túnel accionado bajo la Versión 0 a un tercer nodo de control según la Versión 1.

Una cuarta posibilidad consiste en aplicar también la Versión 0 de GTP entre los nodos de control. En efecto, el segundo nodo de control GGSN2 comienza el diálogo con el primer nodo SGSN1 con Versión 1 de GTP, lo que entiende el primer nodo (SGSN1); por lo tanto, normalmente debería contestar con la Versión 1 de GTP. Sin embargo, si el primer nodo SGSN1 simula "no entender" el mensaje de la Versión 1 de GTP, entonces induce al segundo nodo de control SGSN2 a utilizar la versión 0, de manera que se puede transmitir la etiqueta de flujo. También esta variante permite la transferencia de un túnel de Versión 0 manteniendo la versión a un tercer nodo de control.

Claims (17)

1. Procedimiento para transferir un túnel desde un primer nodo de control (SGSN1) de un sistema de comunicación de radio móvil, especialmente de un sistema GPRS, sobre un segundo nodo (SGSN2), en el que el sistema de comunicación de radio móvil presenta nodos de control (SGSN1, SGSN2) y un nodo de puerta de acceso (GGSN), en el que al menos uno de estos nodos es un nodo según la Versión 0 del protocolo GTP y otros de estos nodos son nodos según la Versión 1 del Protocolo GTP, en el que el segundo nodo (SGSN2) recibe un mensaje sobre la necesidad de la transferencia del túnel (solicitud RAU) desde un terminal (MS) y a continuación dirige una solicitud para la adaptación del contexto que afecta al túnel al nodo de la puerta de acceso (GGSN), caracterizado porque en el caso de que el primer nodo de control (SGSN1) sea un nodo según la Versión 0 y el segundo no de control (SGSN2) y el nodo de la puerta de acceso (GGSN) sean nodos según la Versión 1, la solicitud para la adaptación del contexto contiene una indicación de la IMSI y del NSAPI del túnel respectivo.

2. Procedimiento según la reivindicación 1, caracterizado porque la solicitud es un mensaje del tipo "Crear la Solicitud e Contexto PDP".

3. Procedimiento según la reivindicación 1, caracterizado porque la solicitud es un mensaje del tipo "Actualizar la Solicitud de Contexto PSP", que contiene un TEID con el valor 0 y la indicación sobre la IMSI y el NSAPI del túnel.

4. Procedimiento según la reivindicación 1, caracterizado porque el nodo de la puerta de acceso (GGSN) y el segundo nodo de control (SGSN2) accionan el túnel transferido según la Versión 0 del protocolo GTP.

5. Procedimiento para transferir un túnel desde un primer nodo de control (SGSN1) de un sistema de comunicación de radio móvil, especialmente de un sistema GPRS, sobre un segundo nodo (SGSN2), en el que el sistema de comunicación de radio móvil presenta nodos de control (SGSN1, SGSN2) y un nodo de puerta de acceso (GGSN), en el que al menos uno de estos nodos es un nodo según la Versión 0 del protocolo GTP y otros de estos nodos son nodos según la Versión 1 del Protocolo GTP, en el que el segundo nodo (SGSN2) recibe un mensaje sobre la necesidad de la transferencia del túnel (solicitud RAU) desde un terminal (MS) y a continuación dirige una solicitud para la adaptación del contexto que afecta al túnel al nodo de la puerta de acceso (GGSN), caracterizado porque en el caso de que el primer nodo de control (SGSN1) y el nodo de la puerta de acceso (GGSN) sean nodos según la Versión 1 y el segundo nodo de control (SGSN2) sea un nodo según la Versión 0, o en el caso de que el nodo de la puerta de acceso (GGSN) sea un nodo según la Versión 0 y los nodos de control (SGSN1, SGSN2) sean, respectivamente, nodos según la Versión 1, el primer nodo de control (SGSN1) transmite una etiqueta de flujo asociada al contexto al segundo nodo de control y porque el segundo nodo de control (SGSN2) envía la solicitud para la adaptación del contexto que afecta al túnel insertando esta etiqueta de flujo asociada.

6. Procedimiento según la reivindicación 5, caracterizado porque en el caso de que el primer nodo de control (SGSN1) y el nodo de la puerta de acceso (GGSN) sean nodos según la Versión 1 y el segundo nodo de control (SGSN2) sea un nodo según la Versión 0, el primer nodo de control (SGSN1) asocia al contexto una etiqueta de flujo con un valor predeterminado, que es específico para la transferencia de un túnel desde un nodo de control según la Versión 1 hacia un nodo de control según la Versión 0.

7. Procedimiento según la reivindicación 6, caracterizado porque el valor de la etiqueta de flujo es 0.

8. Procedimiento según una de las reivindicaciones 5 a 7, caracterizado porque el segundo nodo de control (SGSN2) envía como solicitud para la adaptación del contexto que afecta al túnel un mensaje del tipo "Crear la Solicitud de Contexto PDP".

9. Procedimiento según la reivindicación 5, caracterizado porque en el caso de que el primer nodo de control (SGSN1) y el nodo de la puerta de acceso (GGSN) sean nodos según la Versión 1 y el segundo nodo de control (SGSN2) sea un nodo según la Versión 0, el primer nodo de control (SGSN1) asocia a cada contexto establecido según la Versión 1 la etiqueta de flujo según un procedimiento dado, y porque el nodo de la puerta de acceso (GGSN) asocia la misma etiqueta de flujo según el mismo procedimiento.

10. Procedimiento según la reivindicación 9, caracterizado porque el procedimiento para la asociación de la etiqueta de flujo comprende la equiparación de la etiqueta de flujo con los dos bytes menos significativos del TEID.

11. Procedimiento según la reivindicación 5, caracterizado porque en el caso de que el nodo de la puerta de acceso (GGSN) sea un nodo según la Versión 0 y los nodos de control (SGSN1, SGSN2) sean nodos según la Versión 1, se transmite la etiqueta de flujo, asignada al túnel por el nodo de la puerta de acceso (GGSN) en el campo TEID de un mensaje emitido por el primer nodo de control (SGSN1) al segundo nodo de control (SGSN2).

12. Procedimiento según la reivindicación 1, caracterizado porque el segundo nodo de control envía una solicitud para la actualización del contexto según la Versión 1 al nodo de la puerta de acceso (GGSN), y porque cuando el nodo de la puerta de acceso (GGSN) no puede procesar la solicitud, extrae la etiqueta de flujo desde el campo TEID y envía una nueva solicitud según la Versión 0 utilizando la etiqueta de flujo extraída.

13. Procedimiento según la reivindicación 11, caracterizado porque en bytes del campo TEID no rellenos por la etiqueta de flujo se registra un valor predeterminado, que es específico para la transferencia de un túnel entre dos nodos de control según la Versión 1 sobre un nodo de la puerta de acceso según la Versión 0.

14. Procedimiento según la reivindicación 13, caracterizado porque el segundo nodo de control (SGSN2) envía la solicitud para la actualización del contexto según la Versión 0, cuando el campo del TEID contiene el valor predeterminado.

15. Procedimiento según la reivindicación 13 ó 14, caracterizado porque el valor específico es 0.

16. Procedimiento según la reivindicación 11, caracterizado porque adicionalmente al campo del TEID se transmite una identificación, que indica si el campo TEID contiene un TEID o una etiqueta de flujo.

17. Procedimiento según la reivindicación 5, caracterizado porque en el caso de que el nodo de la puerta de paso (GGSN) sea un nodo según la Versión 0 y los nodos de control (SGSN1, SGSN2) sean nodos según la Versión 1, la etiqueta de flujo asignada al túnel por el nodo de la puerta de acceso (GGSN) es transmitida en un campo de datos especial, distinto del campo TEID, de un mensaje desde el primero al segundo nodo de control (SGSN1 y SGSN2, respectivamente).