ES2385964T3 - Método y sistema para manejar datos de abonado - Google Patents

Método y sistema para manejar datos de abonado Download PDF

Info

Publication number
ES2385964T3
ES2385964T3 ES00964559T ES00964559T ES2385964T3 ES 2385964 T3 ES2385964 T3 ES 2385964T3 ES 00964559 T ES00964559 T ES 00964559T ES 00964559 T ES00964559 T ES 00964559T ES 2385964 T3 ES2385964 T3 ES 2385964T3
Authority
ES
Spain
Prior art keywords
network entity
subscriber
subscriber profile
new
previous
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES00964559T
Other languages
English (en)
Inventor
Johan Rune
Yun Chao Hu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2385964T3 publication Critical patent/ES2385964T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/12—Mobility data transfer between location registers or mobility servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un método para manejar datos de abonado para un abonado que se desplaza o transita en una red que incluye una entidad de red doméstica o local que contiene información relativa a abonados a la red y una o más entidades de red visitante que contiene información relativa a abonados a una o más de otras redes, comprendiendo el método: - recibir una petición (1100) de actualización de situación en una nueva entidad de red visitante que sirve una zona hacia la que se desplaza el abonado desde una zona servida por una entidad de red visitante previa; - indicar la petición (1110) de actualización de situación a la entidad de red domestica; - determinar si necesita actualización (1120) un perfil de abonado del abonado almacenado en la nueva entidad de red visitante; - determinar si se cumplen (1130) condiciones para actualizar el perfil de abonado almacenado en la nueva entidad de red visitante desde la entidad de red visitante previa; y - si el perfil de abonado necesita actualización y se cumplen las condiciones, actualizar el perfil de abonado almacenado en la nueva entidad de red visitante desde la entidad de red visitante previa.

Description

Metodo y sistema para manejar datos de abonado
La invenci6n se refiere en general a metodos y sistemas para manejar datos de abonado. Mas particularmente, esta invenci6n se refiere a metodos y sistemas para actualizar y modificar datos de abonado, desasignar identidades de 5 abonado e indicar que han sido purgadas identidades de abonado.
Existen muchos tipos de redes de m6viles terrestres publicas (PLMNs), por ejemplo un Sistema Global para Comunicaciones con M6viles (GSM), un Sistema Celular Digital para Comunicaciones con M6viles (DCS 1800), y un Sistema de Comunicaci6n Personal (PCS). Estas redes proporcionan una amplia gama de servicios e instalaciones para abonados de m6viles que estan discurriendo o navegando entre celulas individuales de las redes
10 de comunicaci6n de radio con m6viles.
Un Sistema Universal de Telecomunicaciones con M6viles (UMTS) esta siendo actualmente normalizado dentro del Proyecto de Asociaci6n de 3a Generaci6n (3GPP), que es un proyecto cooperativo regional cruzado para desarrollar una norma de tercera generaci6n que pueda ser aceptada en tantas regiones del mundo como sea posible. El UMTS sera incorporado en el exito de GSM.
15 Las entidades de redes comunican a traves de un sistema de senalizaci6n comun. Por ejemplo, en el Sistema GSM, la Parte de Aplicaci6n de M6viles (MAP) del Sistema de Senalizaci6n No. 7 especificado por CCITT se usa para comunicar entre entidades en la PLMN. Detalles del sistema de senalizaci6n se dan en Sistema de Telecomunicaciones Celulares Digitales (Fase 2+), especificaci6n de Parte de Aplicaci6n de M6viles (MAP), TS GSM 09.02 v.5.6.00. La MAP del UMTS estara basada en la ultima versi6n de la MAP de GSM, con el numero
20 mfnimo de modificaciones posibles.
El UMTS soportara tanto comunicaci6n de datos de circuito conmutado, segun se usa en redes de voz tradicionales y comunicaci6n conmutada en paquetes, segun es proporcionada, por ejemplo, por el Servicio General de Radio en Paquetes (GPRS). De ese modo, el UMTS sera util para intercambiar rapida y eficazmente datos de voz y de no voz.
La figura 1 ilustra una estructura de red ejemplar para UMTS. En la figura 1, una estaci6n m6vil (MS) comunica con
25 una o mas Redes de M6viles Terrestres Publicas (PLMN). Cada PLMN incluye uno o mas Centros de Conmutaci6n de M6viles (MSCs) para realizar conmutaci6n de circuito para el MS.
Una primera red (PLMNI) es considerada la PLMN Domestica o Local (HPLMN) e incluye un Registro de Situaci6n Domestico (HLR) que contiene datos de abonado para abonados a la red. La HPLMN incluye tambien un Nodo de Soporte de GPRS de Compuerta (GGSN) para habilitar comunicaci6n conmutada en paquetes.
30 PLMN2 y PLMN3 se consideran PLMN visitante e incluyen uno o mas Registros de Situaci6n de Visitante (VLRs) para almacenar datos relativos a abonados a otras redes que pueden discurrir por la red. PLMN2 y PLMN3 incluyen tambien Nodos de Soporte de GPRS de Servicio (SGSNs) para soportar comunicaci6n conmutada en paquetes.
El HLR de PLMN1 comunica con VLR1 (de PLMN2) y VLR2 y VLR3 (de PLMN3) para actualizar informaci6n de abonado, por ejemplo, cuando un abonado discurre o se desplaza en una zona servida por uno de estos VLRs. Los
35 VLRs se comunican tambien entre sf. Por ejemplo, cuando un abonado discurre en una zona de situaci6n nueva servida por un VLR, se hace referencia a este VLR como "VLR nuevo", sirviendo el VLR la zona de situaci6n en la que estaba situado anteriormente el abonado, es decir, el "VLR previo" comunica con el VLR nuevo, proporcionando informaci6n de abonado.
Las SGSNs estan en el mismo nivel jerarquico y funcionan de una manera similar que los MSCNVLRs, pero para
40 comunicaci6n conmutada en paquetes para abonados que navegan o discurren entre las zonas de servicio de las SGSNs. Las SGSNs mantienen el seguimiento de la situaci6n del usuario de GPRS, realizan funciones de seguridad, y controlan de acceso de manejo. Las SGSNs comunican con el HLR para obtener perfiles de abonado. Las SGSNs se comunican tambien entre sf, y la SGSN de PLMN3 se comunica con el BSS el cual, a su vez, comunica con MSC conectado al VLR2.
45 La GGSN es el punto de interconexi6n para datos en paquetes entre la red de GPRS y la red de datos publica. La GGSN esta conectada a las SGSNs a traves de una columna vertebral de Protocolo de Internet (IP). Los datos de usuario, por ejemplo procedentes de un terminal de GPRS conectado a la Internet, son enviados encapsulados sobre la columna vertebral de IP. La GGSN esta conectada al HLR para obtener informaci6n de encaminamiento para encaminar datos en paquetes hacia y desde las SGSNs. La GGSN puede estar tambien conectada a otras
50 GGSNs para facilitar el transito.
En lo que sigue se describira la diferencia entre los procedimientos de gesti6n de movilidad, en particular los procedimientos de actualizaci6n de situaci6n para el caso de no-GPRS, en redes estandar de GSM y los procedimientos en redes de UMTS que usan el concepto de Super-Cargador. Las diferencias son ilustradas describiendo primeramente los procedimientos de actualizaci6n de situaci6n en redes de GSM estandar y 55 describiendo a continuaci6n los correspondientes procedimientos (y algunos procedimientos adicionales) utilizados
en redes de UMTS que emplean el concepto de Super-Cargador
Durante un procedimiento de actualizaci6n de situaci6n de GSM estandar, durante el cual un abonado discurre en una zona servida por u nuevo VLR, el nuevo VLR recupera la Identidad Internacional de Abonado de M6vil (IMSI) del abonado pertinente. Si el abonado utiliza la IMSI para identificaci6n en una petici6n de actualizaci6n de situaci6n enviada al nuevo VLR desde el abonado, la IMSI esta ya disponible para el nuevo VLR. Sin embargo, si el abonado utiliza una Identidad Temporal de Abonado de M6vil (TMSI) para identificaci6n de modo que proteja la integridad de la identidad de abonado, el nuevo VLR tiene que recuperar la IMSI del VLR previo.
Esto se puede entender con referencia a la figura 2, que ilustra una secuencia de senalizaci6n para un procedimiento de actualizaci6n de situaci6n en una red de GSM estandar en la que el MS se identifica el mismo con la TMSI. En la figura 2 han sido omitidos para simplificar los nodos de BSS y el procedimiento de autenticaci6n.
Como se muestra en la figura 2, el procedimiento de actualizaci6n de situaci6n comienza con el MS que envfa una petici6n de actualizaci6n de situaci6n al nuevo VLR. El VLR previo es identificado por medio de una antigua identidad de zona de situaci6n, que es incluida en la petici6n de actualizaci6n de situaci6n desde el MS. El nuevo VLR solicita entonces la IMSI desde el VLR previo enviando un mensaje de petici6n ENVIAR ID DE MAP, incluyendo la TMSI, al VLR previo. El MSCNVLR previo devuelve el IMSI del abonado en el mensaje de respuesta ENVIAR ID DE MAP, junto con cualesquiera tripletes de autenticaci6n no usados.
Cuando se recupera la IMSI, el nuevo VLR envfa un mensaje de indicaci6n SITUACION DE ACTUALIZACION DE MAP al HLR de la red domestica del usuario pertinente, es decir, la HPLMN. La HPLMN puede, por supuesto, ser la misma PLMN que aquella a la que pertenece el nuevo VLR. El HLR envfa entonces un mensaje de indicaci6n SITUACION DE CANCELACION DE MAP al VLR previo. El VLR previo anula entonces el registro del abonado pertinente de su base de datos y envfa un mensaje de confirmaci6n SITUACION DE CANCELACION DE MAP al HLR: El HLR envfa entonces el perfil de abonado del abonado pertinente al nuevo VLR en uno o varios mensajes de indicaci6n INSERTAR DATOS DE ABONADO DE MAP (ISD), dependiendo de la cantidad de datos. El nuevo VLR responde con un mensaje de respuesta SITUACION DE ACTUALIZACION DE MAP al nuevo VLR, y es enviado un acuse de recibido similar al MS por el nuevo VLR. Con ello se completa el procedimiento de actualizaci6n de situaci6n en la red.
Mas detalles de los procedimientos de actualizaci6n de situaci6n en GSM se pueden encontrar en TS GSM, 9.02, sistema de telecomunicaci6n Celular Digital (Fase 2+); especificaci6n de MAP.
En el caso de GPRS, la senalizaci6n correspondiente es similar. La senalizaci6n entre la nueva SGSN y el HLR y entre el HLR y la previa SGSN es, en principio, la misma que entre el nuevo VLR y el HLR y entre el HLR y el VLR previo en el caso de no-GPRS. Sin embargo, la senalizaci6n entre el nuevo SGSN y el previo SGSN es algo diferente.
Esto se puede entender con referencia a las figuras 3 y 4, que ilustran las secuencias de senalizaci6n para un procedimiento de Asignaci6n de GPRS y una Petici6n de Actualizaci6n de Zona de Encaminamiento, respectivamente, en una red de GSM GPRS estandar. Los nodos de BSS y el procedimiento de autenticaci6n han sido omitidos para simplificar.
En el caso de Asignaci6n de GPRS, el MS solicita servicio de GPRS de un nuevo SGSN. Si tiene exito la petici6n, esto cambia el estado de gesti6n de movilidad del MS desde INACTIVO a DISPUESTO. Haciendo referencia a la figura 3, en el procedimiento de Asignaci6n de GPRS, si el MS usa la TMSI en Paquetes, (P-TMSI), es decir, la identidad temporal correspondiente a la TMSI en el dominio de no-GPRS para identificaci6n, la nueva SGSN solicita la IMSI desde la SGSN previa con un mensaje de Petici6n de Identificaci6n. La IMSI (y cualesquiera tripletes de autenticaci6n) es devuelta desde la SGSN previa a la nueva SGSN en un mensaje de Respuesta de Identificaci6n. Desde este punto, el proceso prosigue, en principio, como en el caso de GPRS descrito anteriormente con respecto a la figura 2.
En el caso de Actualizaci6n de Zona de Encaminamiento inter-SGSN, el MS unido a GPRS, es decir, un MS que esta en un estado de ESPERA o DISPUESTO se mueve desde una zona de encaminamiento servida por una SGSN a otra zona de encaminamiento servida por otra SGSN. Haciendo referencia a la figura 4, la IMSI y tripletes de autenticaci6n no usados son transferidos desde la previa SGSN a la nueva SGSN. La nueva SGSN solicita datos de la previa SGSN con un mensaje de Petici6n de Contexto de SGSN. La IMSI y mas datos, por ejemplo, el Contexto de Protocolo de Datos en Paquetes (PDP), que es necesario para habilitar transferencia de paquetes de datos desde la previa SGSN a la nueva SGSN y desde la GGSN a la nueva SGSN, son devueltos desde la previa SGSN a la nueva SGSN en un mensaje Respuesta de Contexto de SGSN. En este caso, la GGSN esta tambien implicada en al proceso de senalizaci6n. Desde este punto, el proceso prosigue, en principio, como en el caso de no-GPRS descrito anteriormente con respecto a la figura 2.
Cada vez que un abonado se desplaza a un lugar servido por un nuevo VLR o SGSN, los datos de abonado deben ser descargados del HLR en la HPLMN al nuevo VLR o SGSN que sirve al usuario y suprimido en el previo VLR o SGSN. Si las zonas de situaci6n asociadas con estas entidades son pequenas o el abonado se desplaza con frecuencia entre las zonas de situaci6n, esta descarga crea una gran carga de senalizaci6n. Esto se aplica a
abonados que se mueven dentro de su red domestica y a abonados itinerantes. Para abonados itinerantes, se incurre en costes de senalizaci6n internacionales.
Los mensajes INSERTAR DATOS DE ABONADO DE MAP (ISD), que son usados para transmitir el perfil de abonado de un abonado pertinente al nuevo VLR, incluyen mas bien grandes cantidades de datos, poniendo de ese modo una carga de senalizaci6n en las redes de senalizaci6n, especialmente en los enlaces de senalizaci6n internacionales en el caso de transitar entre diferentes PLMNs.
Un concepto de Super-Cargador esta siendo disenado para reducir la senalizaci6n en las redes, principalmente eliminando la mayorfa de los mensajes, pero tambien eliminando los mensajes SITUACION DE CANCELACION DE MAP, mediante los cuales son suprimidos los perfiles de abonado en las previos VLRs y SGSNs. Esto se consigue no suprimiendo los datos de abonado de la base de datos de VLR cuando el abonado abandona la zona de servicio del VLR. En su lugar, los datos de abonado son retenidos en el previo VLR y se pueden volver a utilizar la siguiente vez que el abonado se registra en el mismo VLR. Puesto que los datos de abonado son retenidos en el VLR, es innecesario el mensaje SITUACION DE CANCELACION DE MAP del HLR y se puede eliminar. Cuando ya esta presente el perfil de abonado en un nuevo VLR, no hay necesidad de transferir el perfil de abonado desde el HLR, siempre que, por supuesto, el abonado haya sido registrado antes en ese VLR. Por ello, son eliminados tambien los mensajes ISD.
Es importante que el perfil de abonado utilizado en el VLR este actualizado, es decir, que el perfil de abonado utilizado en el VLR sea el mismo que el actualmente almacenado en el HLR. Para asegurar esta compatibilidad de datos, es necesaria la misma clase de mecanismo de gesti6n de revisi6n para los perfiles de abonado. Se han sugerido una marca de tiempo y un numero de secuencia asociados con cada nueva versi6n de perfil de abonado, entre otras soluciones. Se puede hacer generalmente referencia a la marca de tiempo, al numero de secuencia o a otro tipo de parametro como parametro de gesti6n de revisi6n.
En la figura 5 esta representada una secuencia de senalizaci6n que ilustra un procedimiento de actualizaci6n de situaci6n cuando se usa el concepto de Super-Cargador, siempre que el abondo haya sido registrado previamente en el nuevo VLR y siempre que el perfil de abonado retenido este actualizado. Los nodos de BSS y el procedimiento de autenticaci6n han sido omitidos para simplificar.
Haciendo referencia a la figura 5, cuando es enviado por el nuevo VLR el mensaje de indicaci6n SITUACION DE ACTUALIZACION DE MAP al HLR, se incluye en el nuevo VLR el parametro de gesti6n de revisi6n asociado con la versi6n del perfil de abonado actualmente almacenado. El HLR compara el parametro de gesti6n derevisi6n recibido con el asociado con la versi6n de perfil de abonado actualmente almacenada en el HLR y determina si el perfil de abonado almacenado en el nuevo VLR precisa ser actualizado. Si se precisa la actualizaci6n, el HLR transfiere el perfil de abonado actualizado y su parametro de gesti6n de revisi6n asociado al nuevo VLR en el mensaje o los mensajes ISD. El nuevo VLR suprime entonces el perfil de abonado previamente almacenado (y su parametro de gesti6n de revisi6n asociado) de su base de datos y almacena el perfil de abonado recibido (y su parametro de gesti6n de revisi6n asociado) en su lugar. Si el HLR determina que la versi6n de perfil de abonado en el nuevo VLR es el mismo que el almacenado en el HLR, no es enviado mensaje ISD al nuevo VLR. En su lugar, el HLR envfa el mensaje de respuesta SITUACION DE ACTUALIZACION DE MAP al nuevo VLR, como se muestra en la figura 5. Si el parametro de gesti6n de revisi6n no esta incluido en el mensaje SITUACION DE ACTUALIZACION DE MAP recibido desde el nuevo VLR, el HLR realiza los procedimientos estandar de actualizaci6n de situaci6n, es decir el perfil de abonado (sin su parametro de gesti6n de revisi6n asociado) es transferido al nuevo VLR en el mensaje o mensajes ISD.
Cuando el HLR recibe un mensaje SITUACION DE ACTUALIZACION DE MAP que incluye un parametro de gesti6n de revisi6n, aquel marca el nuevo VLR como "soportando el concepto de Super-Cargador" en su base de datos. El HLR verifica tambien su base de datos para determinar si el previo VLR soporta el concepto de Super-Cargador. Si el VLR previo soporta el concepto de Super-Cargador, el HLR no envfa un mensaje SITUACION DE ACTUALIZACION DE MAP. De otro modo, es enviado el mensaje SITUACION DE ACTUALIZACION DE MAP como en el sistema GSM estandar.
Mas detalles sobre los procedimientos de actualizaci6n de situaci6n cuando se utiliza el concepto de Super-Cargador se pueden encontrar en Tdoc, 3GPP N2-99 972, "Proyecto de Asociaci6n de 3a Generaci6n; Red de Nucleo de Grupo de Especificaci6n Tecnica; Informe Tecnico sobre Super-Cargador" de 3GPP.
El concepto de Super-Cargador es igualmente aplicable para SGSN en el dominio de GPRS. En principio funciona del mismo modo en este caso. Existen algunas diferencias que se explicaran en lo que sigue, segun resulten relevantes.
Existen numerosos problemas asociados con el concepto convencional de Super-Cargador. Un problema es la eficacia.
La eficacia del concepto de Super-Cargador puede ser mejorada de varios modos. Un modo consiste en intentar reducir mas la carga de senalizaci6n internacional debida a la transferencia de perfiles de abonado actualizados en mensajes INSERTAR DATOS DE ABONADO DE MAP.
Otros dos problemas estan relacionados con la Identidad Temporal de Abonado de M6vil (TMSI). La TMSI es un corto identificador temporal, que es unico s6lo dentro de una zona de situaci6n y que es reutilizado a medida que vienen y van abonados en la zona de situaci6n. Por tanto, la gama de valores de TMSI es un recurso limitado. Normalmente, una TMSI se asigna a un abonado tras una actualizaci6n de situaci6n en una nueva zona de situaci6n. La TMSI es desasignada cuando el abonado abandona la zona de situaci6n, haciendola con ello disponible para asignaci6n a otros abonados. Entonces puede, a discreci6n del operador, ser reasignada durante subsiguientes contactos entre el abonado y la red.
Si la nueva zona de situaci6n es gestionada por el mismo VLR, el VLR tiene pleno control de lo que esta sucediendo y puede desasignar la TMSI en la antigua zona de situaci6n tan pronto como el abonado envfa una petici6n de actualizaci6n de situaci6n en la nueva zona de situaci6n. Sin embargo, si la nueva zona de situaci6n es gestionada por otro VLR, la desasignaci6n de la TMSI en la antigua zona de situaci6n es disparada por el mensaje SITUACION DE CANCELACION DE MAP desde el HLR al previo VLR.
En el concepto Super-Cargador, el mensaje SITUACION DE CANCELACION DE MAP es suprimido, y en consecuencia la TMSI no es desasignada de la manera normal. De hecho, el previo VLR no es hecho sabedor de que el abonado ha abandonado su zona de servicio. Para el caso de GPRS, la P-TMSI es gestionada del mismo modo que la gesti6n de TMSI por la eliminaci6n del mensaje SITUACION DE CANCELACION DE MAP.
Actualmente, no existe provisi6n en el concepto de Super-Cargador para desasignar la TMSI y la P-TMSI. De ese modo, es disminuida la eficacia de la TMSI y de la P-TMSI.
Otro problema del concepto de Super-Cargador es que no existe actualmente provisi6n para suprimir perfiles de abonado de un VLR e indicaci6n de que los perfiles han sido suprimidos al HLR:
En el sistema actual de GSM, un perfil de abonado puede ser retirado de un VLR despues de cierto periodo, por ejemplo de varios dfas, de inactividad. En tal caso, es enviado un mensaje MS DE PURGA DE MAP desde el VLR al HLR para informar al HLR de la acci6n y para evitar innecesarios mensajes PROPORCIONAR NUMERO DE ITINERANCIA DE MAP relativos al abonador purgado.
A medida que son servidos nuevos abonados, la base de datos del VLR se mantendra creciendo. De ese modo, no existe aquf necesidad de una funci6n de gesti6n de base de datos en el VLR para descartar datos antiguos de abonado (de acuerdo con algun algoritmo) para evitar que la base de datos resulte llena.
De acuerdo con el concepto de Super-Cargador, cuando es suprimido un registro de abonado debido a razones de gesti6n de base de datos, el HLR no es informado, como oposici6n al sistema de GSM estandar, en el que es enviado un mensaje MS DE PURGA DE MAP al HLR.
La eliminaci6n del mensaje MS DE PURGA DE MAP significa que existe la posibilidad de que el HLR crea que el abonado (cuyo registro fue suprimido del VLR) esta todavfa registrado en el mismo VLR (si el HLR no ha recibido un mensaje SITUACION DE ACTUALIZACION DE MAP relativo al mismo abonado desde otro VLR). Esto, a su vez, significa que el HLR puede enviar un mensaje de petici6n PROPORCIONAR NUMERO DE ITINERANCIA DE MAP al VLR cuando se haya de encaminar una llamada al abonado pertinente. Entonces se supone que el VLR retorna el mensaje de respuesta PROPORCIONAR NUMERO DE ITINERANCIA DE MAP que incluye un Error de Abonado Ausente con la nueva informaci6n de diagn6stico "Purgado MS". Tras la recepci6n de esta indicaci6n de "Purgado MS", el HLR puede establecer la indicaci6n o bandera "Purgado MS para No-GPRS" en el registro de abonado del abonado pertinente.
Esta manipulaci6n de la petici6n PROPORCIONAR NUMERO DE ITINERANCIA DE MAP tiene todavfa otra consecuencia. Ello significa que tras la recepci6n de una petici6n PROPORCIONAR NUMERO DE ITINERANCIA DE MAP para un abonado para el cual no existe registro de datos en el VLR, el VLR debe ser capaz de distinguir entre el caso en que el perfil de abonado fue retirado por la funci6n de gesti6n de base de datos de Super-Cargador, en cuyo caso el mensaje de respuesta PROPORCIONAR NUMERO DE ITINERANCIA DE MAP es devuelto al HLR con la informaci6n de error descrita anteriormente, y el caso en que cuando se perdi6 el perfil de abonado debido a una reiniciaci6n de VLR, en cuyo caso se inicia el procedimiento normal de restauraci6n de la base de datos de VLR.
Tambien se ha propuesto eliminar los mensajes MAP SEN ENVIA IDENTIFICACION mediante lo cual el nuevo VLR recupera la IMSI del previo VLR, en caso de que el abonado usara la TMSI para identificaci6n en la petici6n de actualizaci6n de situaci6n. Ciertamente, se supone que el nuevo VLR recupera la IMSI del MS a traves del procedimiento MAP PROPORCIONA IMSI.
En el sistema de GSM actual, el HLR puede incluir un parametro "Congelar TMSI" en el mensaje de respuesta MS DE PURGA DE MAP. Este parametro puede ser utilizado si el numero de VLR almacenado para el abonado pertinente en el HLR es el mismo que el numero de VLR recibido en el mensaje MS DE PURGA DE MAP. Esto es una precauci6n para evitar la doble asignaci6n de una TMSI, es decir, cuando, de acuerdo con los registros del HLR, el abonado esta todavfa situado en la zona de servicio del VLR de la cual fue purgado el registro de abonado. La TMSI congelada se hace disponible de nuevo en una actualizaci6n de situaci6n subsiguiente por el abonado pertinente en el mismo VLR, a la recepci6n de un mensaje SITUACION DE CANCELACION DE MAP para el
abonado correspondiente, o, en casos extremos, mediante intervenciones de operaci6n y mantenimiento.
En una red Super-cargada, es retirada la protecci6n anteriormente descrita contra doble asignaci6n de una TMSI, junto con el mensaje MS DE PURGA DE MAP, creando asf problemas de ambiguedad. La gesti6n de P-TMSI es efectuada de manera similar por la retirada del mensaje MS DE PURGA DE MAP desde la SGSN al HLR y la consiguiente posibilidad eliminada para que HLR replique con un parametro "Congelar P-TMSI".
La retirada del mensaje MS DE PURGA DE MAP crea tambien un problema en la activaci6n del contexto de PDP requerida por la red, en preparaci6n para el suministro de paquetes de GPRS que terminan en m6vil. Para ilustrar este problema es util describir los casos de exito y de no exito de la activaci6n de contexto de PDP requerida por la red. La figura 6 ilustra una secuencia de senalizaci6n para el caso de exito de una activaci6n de contexto de PDP requerida por la red. Los nodos de BSS han sido omitidos para simplificar.
Como se muestra en la figura 6, cuando una Unidad de Datos en Paquetes de PDP (PDU) terminados en m6vil, es decir, un paquete de datos, llega a la GGSN, la GGSN interroga al HLR para encaminar informaci6n que utiliza un mensaje de petici6n ENVIAR INFORMACION DE ENCAMINAMIETO DE MAP PARA GPRS. Si el abonado correspondiente no es conocido por el HLR como inalcanzable, el HLR retorna la Direcci6n de SGSN de la SGSN que sirve actualmente al abonado en un mensaje de respuesta ENViAR INFORMACION DE ENCAMINAMIENTO DE MAP PARA GPRS. La GGSN envfa entonces una Petici6n de Notificaci6n de PDU a la SGSN, incluyendo la IMSI, el Tipo de PDP y la Direcci6n de PDP. La SGSN acusa recibo de este mensaje enviando una Respuesta de Notificaci6n de PDU a la GGSN y envfa un mensaje de Activaci6n de Contexto de PDP de Petici6n al SM. Despues de esto, comienza el Procedimiento real de Activaci6n de Contexto de PDP entre la GGSN y el MS.
La GGSN puede almacenar la direcci6n de la SGSN con la cual la GGSN estableci6 el ultimo contexto de PDP para el abonado pertinente. La direcci6n de SGSN almacenada serfa valida durante un cierto tiempo limitado, durante el cual se impedirfa una interrogaci6n al HLR. Sin embargo, es muy improbable que el registro de abonado fuera purgado de la base de datos de SGSN durante este tiempo limitado. Si el registro de abonado iba a ser desechado, mas bien se elegirfa una funci6n de gesti6n de base de datos para desechar un registro de abonado que no habfa sido utilizado durante un periodo de tiempo grande.
Si el abonado de destino esta marcado como no alcanzable en el HLR, el HLR indica esto en su mensaje de respuesta ENViAR INFO DE ENCAMINAMIENTO DE MAP PARA GPRS a la GGSN de manera que la GGSN puede evitar el desperdicio de recursos de senalizaci6n y energfa de tratamiento en una Petici6n de Notificaci6n de PDU sin exito a la SGSN.
La secuencia de senalizaci6n para el caso sin exito de una activaci6n de contexto de PDP requerida por red se ilustra en la figura 7. Los nodos de BSS han sido omitidos para simplificar.
Como se muestra en la figura 7, si la activaci6n de Contexto de PDP falla antes de que sea enviado el mensaje de Activaci6n de Contexto de PDP de petici6n al MS, por ejemplo debido a que no es conocida la IMSI pertinente en la SGSN, por ejemplo debido a que fue previamente desechada por la funci6n de gesti6n de la base de datos, la SGSN retorna una indicaci6n de error a la GGSN en el mensaje de Respuesta de Notificaci6n de PDP. La causa del error indicado puede ser, por ejemplo, "IMSI No Conocida" o "GPRS de MS separado". Otro escenario es que el mensaje de Activaci6n de Contexto de PDP de petici6n sea enviado al MS, y entonces falla la Activaci6n de Contexto de PDP. La SGSN indica entonces la causa del error en un mensaje de Petici6n de Rechazo de Notificaci6n de PDU a la GGSN, pero este escenario no es relevante para esta explicaci6n.
Cuando la GGSN recibe un mensaje de Respuesta de Notificaci6n de PDU (o una Petici6n de Rechazo de Notificaci6n de PDU) con una indicaci6n de error desde la SGSN, informa del fallo y de la raz6n del fallo al HLR en un mensaje de Indicaci6n de INFORME DE FALLO DE MAP. Las causas del error informadas en el mensaje de indicaci6n de INFORME DE FALLO DE MAP al HLR pueden ser, por ejemplo, "Fallo del Sistema", "Carencia de Datos", "Valor Inesperado de Datos" o "Abonado Desconocido" (todos los cuales son valores del parametro de Error de Usuario). Tras la recepci6n del mensaje de indicaci6n de INFORME DE FALLO DE MAP, el HLR establece una bandera de "Estaci6n M6vil No Alcanzable para GPRS (MNRG) para el abonado correspondiente (si la bandera no esta ya fijada). El HLR puede indicar tambien la raz6n en un parametro "Raz6n de M6vil no Alcanzable (MNRR).
Antes de enviar el mensaje de indicaci6n INFORME DE FALLO DE MAP, si la causa del error fue "IMSI No Conocido", la GGSN puede intentar recuperar una nueva direcci6n de SGSN (suponiendo que el MS podrfa haber sido movido a otra SGSN) enviando un mensaje de petici6n ENVIAR INFO DE ENCAMINACIENTO DE MAP PARA GPRS a la HLR. Si es devuelta desde el HLR una direcci6n de SGSN distinta de la ya intentada, comienza de nuevo el procedimiento de activaci6n de contexto de PDP requerido por la red. De otro modo, el mensaje de indicaci6n INFORME DE FALLO DE MAPA es enviado al HLR.
Como se ha descrito anteriormente, una petici6n para un numero de transito relativo a un abonado cuyo registro ha sido desechado del VLR por la funci6n de gesti6n de la base de datos del Super-Cargador da lugar a una indicaci6n de "MS Purgado" desde el VLR al HLR, de manera que el HLR puede establecer a continuaci6n la bandera "MS Purgado para No-GPRS" para el abonado correspondiente, evitando con ello subsiguientes intentos de alcanzar el abonado pertinente con llamadas terminadas en m6vil o mensajes cortos. Sin embargo, no existe manera
correspondiente para que el HLR reciba la informaci6n de que el MS pertinente has sido descartado de la base de datos del GPRS. Por tanto, la bandera o indicaci6n "MS Purgado para GPRS" nunca es establecida en el HLR. De ese modo, la activaci6n sin exito de contexto de PDP requerida por la red (es decir, intentos de suministro de paquetes de GPRS terminados en m6vil) y de mensajes cortos terminados en m6vil, destinados al abonado correspondiente, pueden ser todavfa encaminados hacia la SGSN si el HLR no ha recibido el mensaje de indicaci6n SITUACION DE ACTUALIZACION DE MAP DE GPRS desde otra SGSN. Este paquete o mensaje corto no puede ser enviado por la SGSN al MS. Si el estado de "MS Purgado" pudiera ser transportado desde la SGSN hasta el HLR como una consecuencia de una activaci6n de contexto de PDP requerida por la red sin exito para un abonado cuyo registro ha sido desechado de la SGSN por la funci6n de gesti6n de la base de datos del Super-Cargador, se mejorarfa la eficacia del concepto de Super-Cargador.
Por tanto, existe la necesidad de tecnicas paras resolver los problemas en el manejo de datos de abonado en el concepto de Super-Cargador.
El documento WO 99N56492 se refiere a un metodo de manejar datos de abonado para abonados que navegan o transitan en una red.
El documento WO 99N43175 se refiere a un metodo para tratar datos de estaci6n m6vil. El metodo comprende definir tiempo de almacenamiento para datos de abonado y suprimir datos de abonado cuando ha transcurrido el tiempo de almacenamiento.
SUMARIO
Es por lo tanto un objeto de la invenci6n mejorar la eficacia del manejo de datos de abonado.
De acuerdo con realizaciones ejemplares, estos y otros objetos se cumplen mediante un metodo y un sistema para manejar datos de abonado para un abonado que navega en una red que incluya una entidad de red domestica que contenga informaci6n relativa a abonados a la red y una o mas entidades de red visitantes que contenga informaci6n relativa a abonados a una o mas de otras redes. La red puede soportar comunicaci6n de circuito conmutado yNo comunicaci6n de paquetes conmutados.
De acuerdo con una primera realizaci6n, se proporcionan un metodo y un sistema para actualizar un perfil de abonado. Una petici6n de situaci6n de actualizaci6n es recibida en una nueva entidad de red visitante que sirve una zona en la que discurre el abonado desde una zona servida por una entidad previa de red visitante, y la petici6n de situaci6n de actualizaci6n es indicada a la entidad de red domestica. Se efectua una determinaci6n de si un perfil de abonado del abonado, almacenado en la nueva entidad de red visitante, necesita actualizaci6n y de si se cumplen las condiciones para la actualizaci6n del perfil de abonado almacenado en la nueva entidad de red visitante desde la entidad red visitante previa. Si el perfil de abonado necesita actualizaci6n y las condiciones se cumplen, el perfil de abonado en la nueva entidad de red visitante es actualizado desde la entidad previa de red visitante.
De acuerdo con una segunda realizaci6n, se proporcionan un metodo y un sistema para enviar s6lo modificaciones a un perfil para actualizar el perfil. En la entidad de red domestica, es recibida una petici6n para actualizar un perfil de abonado almacenado en una entidad de red visitante. Se efectua una determinaci6n de si modificaciones registradas en la entidad de red domestica son suficientes para habilitar la actualizaci6n del perfil de abonado. Si las modificaciones registradas son suficientes, las modificaciones son enviadas desde la entidad de red domestica a la entidad de red visitante.
De acuerdo con una tercera realizaci6n, se proporcionan un metodo y un sistema para manejar la desasignaci6n de identidades de abonado. Como una alternativa, una identidad de abonado puede ser desasignada tras la recepci6n de una petici6n para identificaci6n de un abonado en una entidad previa de red visitante que sirve una zona desde la cual ha navegado el abonado. Como otra alternativa, se efectua una determinaci6n de si ha transcurrido una cantidad predeterminada de tiempo desde el ultimo contacto entre el abonado y la red. Si es asf, se evita el uso de una identidad de abonado del abonado en la red.
De acuerdo con una cuarta realizaci6n, se proporcionan un metodo y un sistema para manejar un fallo de activaci6n en contexto de paquetes. Se hace una determinaci6n de si tiene exito una activaci6n de paquetes intentada por la red para un abonado en una de las entidades visitantes. Si falla la activaci6n de paquetes, el fallo es indicado a la entidad de red domestica, y se efectua una determinaci6n de si el fallo fue causado debido a que fue purgado un registro de abonado. Si el fallo fue causado debido a que fue purgado un registro de abonado, la entidad de red domestica registra que ha sido purgado un perfil de abonado para el abonado.
BREVE DESCRIPCION DE LOS DIBUJOS
Las caracterfsticas, objetos y ventajas de la invenci6n resultaran evidente por la lectura de esta descripci6n en combinaci6n con los dibujos que se acompanan, en los cuales los mismos numeros de referencia se refieren a elementos analogos y en los cuales:
La figura 1 ilustra un ejemplo de arquitectura o estructura de red para UMTS;
La figura 2 ilustra una secuencia de senalizaci6n tfpica para un procedimiento de actualizaci6n de situaci6n;
La figura 3 ilustra una secuencia de senalizaci6n tfpica para un procedimiento de Asignaci6n de GPRS;
La figura 4 ilustra una secuencia de senalizaci6n tfpica para un procedimiento de Actualizaci6n de Zona de Encaminamiento inter-SGSN;
La figura 5 ilustra una secuencia de senalizaci6n tfpica para un procedimiento de actualizaci6n de situaci6n usando el concepto de Super-Cargador;
La figura 6 ilustra una secuencia de senalizaci6n tfpica para el caso de exito de una activaci6n de contexto de PDP requerida por la red;
La figura 7 ilustra una secuencia de senalizaci6n tfpica para el caso de fracaso de una activaci6n de contexto de PDP requerida por la red;
La figura 8 ilustra una secuencia de senalizaci6n para un procedimiento de actualizaci6n de situaci6n con exito cuando el abonado se identifica con la IMSI de acuerdo con una primera realizaci6n;
Las figuras 9 y 10 ilustran secuencias de senalizaci6n para procedimientos de actualizaci6n de situaci6n con exito cuando el abonado se identifica con la TMSI de acuerdo con una primera realizaci6n;
La figura 11 ilustra un metodo para manejar datos de abonado de acuerdo con una primera realizaci6n;
Las figuras 12A-12F ilustran diferentes versiones de un ejemplo de perfil de abonado;
Las figuras 13A-13E ilustran tablas de registro de modificaciones;
La figura 14 ilustra un mensaje de datos de abonado delta ejemplar;
La figura 15 ilustra un metodo para manejar datos de abonado de acuerdo con una segunda realizaci6n;
Las figuras 16A y 16B ilustran metodos para manejar datos de abonado de acuerdo con una tercera realizaci6n; y
La figura 17 ilustra un metodo para manejar datos de abonado de acuerdo con una cuarta realizaci6n.
DESCRIPCION�DEAALLADA
De acuerdo con realizaciones ejemplares, se reproporcionan tecnicas para manejar datos de abonado usando el concepto de Super-Cargador de una manera eficiente.
De acuerdo con una primera realizaci6n, se proporciona una tecnica para actualizar datos de abonado de una manera eficiente.
De acuerdo con el concepto de Super-Cargador, cuando el perfil de abonado retenido en un VLR en el que el abonado se esta intentando registrar esta anticuado, es actualizado por medio de uno o mas mensajes INSERTAR DATOS DE ABONADO desde el HLR. Cuando el abonado se esta desplazando desde otra PLMN, esto significa lo mas probable que el mensaje o mensajes de ISD son enviados por medio de enlaces de senalizaci6n internacional. Estos enlaces de senalizaci6n internacional imponen una pesada carga sobre los recursos del sistema.
Un modo de reducir la senalizaci6n internacional es, a la discreci6n del HLR, recuperar el perfil de abonado actualizado del VLR previo, siempre que el VLR previo este situado en la misma PLMN que el VLR nuevo, por ejemplo cuando el MS de la figura 1 se desplaza desde, por ejemplo, la zona de servicio de VLR3 a la zona de servicio de VLR2.
La secuencia de senalizaci6n es diferente cuando el abonado proporciona la IMSI que cuando el abonado proporciona la TMSI para identificaci6n en la petici6n de actualizar situaci6n. En ambos casos, el VLR nuevo puede determinar si el VLR previo esta situado en la misma PLMN mirando al parametro de Identidad de Zona de Situaci6n Previo recibido en la petici6n MAP ACTUALIZA ZONA DE SITUACION. El HLR puede conseguir el mismo resultado comparando los numeros de VLR, por ejemplo, los C6digos de Pafs y los C6digos de Destino Nacional, del VLR nuevo y el VLR previo.
La senalizaci6n internacional puede ser evitada si el VLR previo esta situado en el mismo pafs que el VLR nuevo. El pafs del VLR previo puede ser obtenido por el VLR nuevo a partir del c6digo de pafs incluido en el parametro de Identidad de Zona de Situaci6n Previo, recibido en la petici6n MAP ACTUALIZA ZONA DE SITUACION. El HLR puede conseguir el mismo resultado comparando los numeros de VLR (concretamente los C6digos de Pafs) del nuevo VLR y el previo VLR.
La figura 8 ilustra un procedimiento exitoso de actualizaci6n de situaci6n en el que el abonado utiliza la IMSI para
identificaci6n. Cuando el abonado proporciona la IMSI para identificaci6n, el VLR nuevo envfa un mensaje de indicaci6n SITUACION DE ACTUALIZACION DE MAP (incluyendo el nuevo parametro de gesti6n de revisi6n) al HLR. El HLR determina si necesita actualizaci6n el perfil de abonado en el nuevo VLR. Esta determinaci6n puede hacerse comparando el parametro de gesti6n de revisi6n (por ejemplo la marca de tiempo o el numero de versi6n) recibido en el mensaje de indicaci6n SITUACION DE ACTUALIZACION DE MAP a partir del VLR nuevo con el parametro de gesti6n de revisi6n (por ejemplo la marca o el numero de versi6n) asociado con l perfil de abonado almacenado en el HLR desde el abonado pertinente. Si los parametros de gesti6n de revisi6n son los mismos, esto indica que los perfiles de abonado son los mismos, y no se considera necesaria la actualizaci6n. Por el contrario, si los parametros de gesti6n de revisi6n no coinciden, el perfil de abonado en el VLR nuevo necesita ser actualizado. En este caso, el HLR indica, usando un nuevo parametro en el mensaje de respuesta SITUACION DE ACTUALIZACION DE MAP, al VLR nuevo que puede recuperar el perfil de abonado actualizado del VLR previo. Antes de dar instrucciones al VLR nuevo para hacer esto, el HLR confirma que se han cumplido las condiciones para actualizar el perfil de abonado, por ejemplo, que el VLR previo esta usando el concepto de Super-Cargador, que el VLR previo esta situado en la misma PLMN (o el mismo pafs) que el VKR nuevo, y que el perfil de abonado no ha sido actualizado desde que el abonado abandon6 la zona servida por el VLR previo. Esto significa que el HLR debe retener el parametro de gesti6n de revisi6n, por ejemplo, marca de tiempo, numero de secuencia, etc. de la ultima revisi6n del perfil de abonado. El VLR nuevo puede entonces recuperar el perfil de abonado actualizado desde el VLR previo utilizando un servicio de MAP nuevo, es decir, mensajes nuevos. Los mensajes nuevos pueden ser denominados, por ejemplo petici6n TRANSFERIR DE DATOS DE ABONADO DE MAP (para requerir el perfil de abonado del VLR previo) y respuesta TRANSFERIR DE DATOS DE ABONADO DE MAP (para retornar el perfil de abonado al VLR nuevo). El mensaje de respuesta puede ser in mensaje unico o multiples mensajes, dependiendo de la cantidad de datos que se han de transferir.
Si falla esta recuperaci6n, el nuevo VLR puede recuperar todavfa un perfil de abonado actualizado desde el HLR iniciando un procedimiento RESTABLECER DATOS DE MAP (para al abonado correspondiente) hacia el HLR o iniciando un nuevo dialogo ACTUALIZAR SITUACION DE MAP con el HLR. Si es enviado un nuevo mensaje de indicaci6n ACTUALIZAR SITUACION DE MAP al HLR, el mismo no ha de incluir esta vez el parametro de gesti6n de revisi6n con el fin de disparar un procedimiento normal INSERTAR DATOS DE ABONADO DE MAP (sin inclusi6n del parametro de gesti6n de revisi6n) desde el HLR. Una alternativa es disponer de una indicaci6n explfcita en el mensaje de indicaci6n SITUACION DE ACTUALIZACION DE MAP, posiblemente un valor especial del parametro de gesti6n de revisi6n, que indique que tanto el perfil de abonado como su parametro de gesti6n de revisi6n asociado han de ser transferidos desde el HLR.
Si, tras la recepci6n del primer mensaje SITUACION DE ACTUALIZACION DE MAP (incluyendo el parametro de gesti6n de revisi6n), el HLR determina que necesita ser actualizado el perfil de abonado en el nuevo VLR, pero que no se han cumplido las condiciones para la recuperaci6n del perfil de abonado del previo VLR, el HLR inicia el procedimiento INSERTAR DATOS DE ABONADO DE MAP (e incluye el parametro de gesti6n de revisi6n con el perfil de abonado en el mensaje o mensajes ISD) hacia el nuevo VLR antes de que sea enviado el mensaje de respuesta ACTUALIZAR SITUACION DE MAP (es decir, justo como en el procedimiento de actualizaci6n de situaci6n en el concepto de Super-Cargador actualmente propuesto).
La figura 9 ilustra un procedimiento de actualizaci6n de situaci6n con exito en el que el abonado utiliza la TMSI para identificaci6n, y el VLR nuevo recupera la IMSI desde el VLR previo en la manera de GSM estandar (a traves del servicio ENViAR IDENIFICACION DE MAP) o del MS (a traves del servicio PROPPORCIONA IMSI DE MAP). Para el caso de tener exito, el HLR determina que se han cumplido las condiciones para la recuperaci6n del perfil de abonado del VLR previo.
Como se muestra en la figura 9, el VLR envfa el mensaje de indicaci6n SITUACION DE ACTUALIZACION DE MAP al HLR, y el procedimiento continua de la misma manera que el caso en el que el abonado utiliz6 la IMSI para identificaci6n.
De acuerdo con otra alternativa, el VLR nuevo recupera el perfil de abonado, junto con la IMSI desde el VLR previo. La figura 10 ilustra una secuencia de senalizaci6n de esta alternativa cuando el abonado se identifica con la TMSI. En el mensaje de petici6n ENViAR IDENIFICACION DE MAP, el VLR nuevo, despues de determinar que el VLR previo esta situado en la misma PLMN o en el mismo pafs, incluye el parametro de gesti6n de revisi6n del perfil de abonado recibido (por ejemplo, marca de tiempo, numero de secuencia, etc.) asociado con la versi6n de perfil de abonado ya almacenada en el nuevo VLR.
Como se muestra en la figura 10, el VLR previo compara el parametro de gesti6n de revisi6n recibido con el asociado a la versi6n de perfil de abonado almacenada en su propia base de datos y, si el VLR previo determina que el perfil de abonado almacenado en el VLR necesita ser actualizado, el VLR previo incluye su propia revisi6n del perfil de abonado y el correspondiente parametro de gesti6n de revisi6n junto con la IMSI (y posibles tripletes de autenticaci6n) en el mensaje de respuesta ENViAR IDENTIFICACION DE MAP. Esto, naturalmente, significa que los formatos de los mensajes ENViAR IDENTIFICACION DE MAP han siso modificados. Tambien serfa posible disenar nuevos mensajes de MAP para este procedimiento. Los nuevos mensajes pueden ser denominados por ejemplo, petici6n ENVIAR IMSI Y DATOS DE ABONADO DE MAP y respuesta ENVIAR IMSI Y DATOS DE ABONADO DE MAP. Si es necesario, el VLR previo puede usar varios mensajes para transferir todos los datos de abonado. Si el
perfil de abonado no precisa ser actualizado, el VLR previo simplemente omite el perfil de abonado en su mensaje de respuesta.
El nuevo VLR sustituye su versi6n de perfil de abonado previamente almacenada con la (si existe) recibida del VLR previo. Entonces envfa un mensaje de indicaci6n SITUACION DE ACTUALIZACION DE MAP al HLR que incluye el parametro de gesti6n de revisi6n que ha recibido del VLR previo.
Existe, en este punto, el pequeno riesgo de que el perfil de abonado fuera modificado en el HLR desde que el abonado abandonara la zona servida por el VLR previo o desde que el perfil de abonado fuera recuperado del VLR previo. En tal caso, despues de determinar a partir del parametro de gesti6n de revisi6n recibido que precisa ser actualizado el perfil de abonado en el VLR nuevo, el HLR envfa el perfil de abonado actualizado en uno o varios mensajes INSERTAR DATOS DE ABONADO DE MAP, y habra sido en vano la transferencia del perfil de abonado entre los VLRs. Sin embargo, en la amplia mayorfa de los casos el HLR determina que el perfil de abonado en el nuevo VLR no precisa ser actualizado y entonces se evita la transferencia del perfil de abonado por enlaces de senalizaci6n internacional.
Si falla el VLR nuevo por alguna raz6n en recuperar el perfil de abonado actualizado desde el VLR previo, aquel simplemente incluira su parametro de gesti6n de revisi6n previamente retenido en el mensaje de indicaci6n SITUACION DE ACTUALIZACION DE MAP al HLR, y el HLR actuara como se ha descrito anteriormente.
Aunque no se ilustra, se pueden utilizar metodos similares para actualizar un perfil de abonado en una nueva SGSN utilizando el perfil de abonado almacenado en la previa SGSN.
La figura 11 ilustra un metodo ejemplar para manejar datos de abonado de acuerdo con la primera realizaci6n. El metodo comienza en el paso 1100, en el que es recibida en el nuevo VLR una petici6n para actualizaci6n de situaci6n. En el paso 1110, el nuevo VLR indica la petici6n de actualizaci6n de situaci6n al HLR. En el paso 1120 se efectua una determinaci6n, por ejemplo por el HLR, de si el perfil de abonado precisa actualizaci6n en el nuevo VLR. Si es asf, en el paso 1130, se efectua una determinaci6n, por ejemplo por el HLR, de si se cumplen las condiciones para actualizar el perfil de abonado en el nuevo VLR desde el previo VLR, por ejemplo de si el previo VLR esta usando el concepto de Super-Cargador, de si el nuevo VLR esta situado en la misma PLMN o el mismo pafs que el VLR previo y de si el perfil de abonado ha sido actualizado desde que el abonado a abandonado el VLR previo. Se apreciara que los pasos 1120 y 1130 pueden ser realzados en el orden inverso por el nuevo VLR y el previo VLR, respectivamente, por ejemplo el nuevo VLR puede determinar si se cumplen las condiciones de actualizaci6n del perfil de abonado, y el previo VLR puede determinar si precisa actualizaci6n del perfil de abonado.
Si se ha determinado que el perfil de abonado necesita actualizaci6n y se cumplen las condiciones para la actualizaci6n, el perfil de abonado es actualizado en el paso 1140, por ejemplo por el VLR previo, enviando el perfil de abonado al nuevo VLR. Si se determina, en el paso 1120, que el perfil de abonado no necesita actualizaci6n, en el paso 1150, el perfil no es actualizado. Si se determina, en el paso 1130, que no se cumplen las condiciones para actualizar el perfil desde los previos VLRS, en el paso 1160 es transferido el perfil de abonado desde el HLR al nuevo VLR.
De acuerdo con esta realizaci6n, mediante recuperaci6n del perfil de abonado actualizado desde el VLR previo en lugar del HLR, se puede reducir significativamente la senalizaci6n internacional causada por procedimientos de actualizaci6n de situaci6n en los casos en que el abonado esta discurriendo por otra PLMN y el previo VLR esta situado en la misma PLMN (o en el misma pafs) que el nuevo VLR. Esto es una mejora significativa del concepto de Super-Cargador.
En lugar de actualizar un perfil de abonado completo, puede ser suficiente actualizar un perfil existente con modificaciones que hayan sido hechas en el perfil, desde la ultima actualizaci6n. De acuerdo con una segunda realizaci6n, se proporciona una tecnica para actualizar un perfil de abonado s6lo con modificaciones hechas en el perfil desde la ultima actualizaci6n.
En la siguiente descripci6n se describe el uso de los mensajes INSERTAR DATOS DE ABONADO DE MAP y SUPRIMR DATOS DE ABONADO DE MAP. Estos mensajes pueden ser utilizados entre el HLR y el VLR o entre el HLR y la SGSN. Los procedimientos usados entre el HLR y el VLR y los procedimientos usados entre el HLR y la SGSN son identicos, aunque pueden diferir los parametros de mensajes. La invenci6n es igualmente aplicable en ambos casos.
En el sistema actual de GSM no son retenidos datos de abonado en un VLR o una SGSN despues de abandonar el abonado la zona de servicio del VLR o de la SGSN. Por lo tanto, una recepci6n de un mensaje INSERTAR DATOS DE ABONADO DE MAP en el VLR o en la SGSN significa que los datos son simplemente copiados del mensaje o mensajes ISD en la base de datos de VLR o en la base de datos de SGSN.
En el caso de datos de abonado que estan solos, es decir, cuando se envfa uno o mas mensajes de ISD al VLR actual o a la SGSN actual debido a que el perfil de abonado ha sido actualizado en el HLR, los parametros recibidos en el mensaje o mensajes de ISD exageran los correspondientes parametros previamente almacenados en el VLR o la SGSN. Si hay parametros almacenados en el VLR o la SGSN para los cuales no hay correspondientes
parametros incluidos en el mensaje o mensajes de ISD, estos parametros previamente almacenados son retenidos en el VLR o en la SGSN. Para suprimir parametros en el perfil de abonado almacenado en el VLR o en la SGSN, el HLR tiene que usar el mensaje SUPRIMIR DATOS DE ABONADO DE MAP.
Puesto que cada modificaci6n del perfil de abonado necesita ser reflejada en el VLR actual o en la SGSN actual, es decir, el HLR no acumula modificaciones antes de informar al VLR yNo SGSN, es improbable que tanto el mensaje INSERTAR DATOS DE ABONADO DE MAP como el mensaje SUPRIMIR DATOS DE ABONADO DE MAP tengan que ser usados para reflejar una modificaci6n de perfil de abonado. En casi todos los casos, serfa suficiente uno cualquiera de ellos.
En contraposici6n, en una red de Super-Cargador, un mensaje de indicaci6n INSERTAR DATOS DE ABONADO DE MAP recibido durante el procedimiento de actualizaci6n de situaci6n o el procedimiento de Asignaci6n de GPRS o el procedimiento de Actualizaci6n de Zona de Encaminamiento da lugar a que los datos recibidos sean completamente copiados en la base de daos de VLR o en la base de datos de SGSN, es decir, el perfil de abonado previamente retenido es completamente suprimido y el perfil de abonado recibido es almacenado en su lugar. No es retenido ninguno de los parametros previamente almacenados del perfil de abonado, incluso si no esta presente parametro correspondiente en el mensaje o mensajes INSERTAR DATOS DE ABONADO DE MAP. Esto da lugar a un desperdicio de recursos de senalizaci6n que se propone ahorrar el concepto de Super-Cargador.
En muchos casos, s6lo se cambia una pequena parte del perfil de abonado. Por lo tanto, el enviar la totalidad del perfil de abonado desde el HLR es un desperdicio de recursos de senalizaci6n. Serfa mejor que se enviaran s6lo las modificaciones, por ejemplo un "mensaje de datos de abonado delta".
Puede ser posible utilizar los principios de los procedimientos de gesti6n de datos de abonado que estan solos para indicar modificaciones del perfil de abonado. Sin embargo, en una red que soporte el concepto de Super-Cargador, la diferencia entre el perfil de abonado retenido en el VLR o en la SGSN (en los que se esta intentando registrar un abonado) y el perfil de abonado actualizado en el HLR puede ser el resultado de varias modificaciones del perfil de abonado en el HLR. Por lo tanto, los principios de los procedimientos de gesti6n de datos de abonado que estan solos, segun se ha descrito anteriormente, pueden no ser apropiados para indicar las modificaciones del perfil de abonado durante un procedimiento de actualizaci6n de situaci6n o un procedimiento de Asignaci6n de GPRS o un procedimiento de Actualizaci6n de Zona de Encaminamiento usando el concepto de Super-Cargador. En muchos casos, tendrfa que ser enviado tanto el mensaje INSERTAR DATOS DE ABONADO DE MAP como un mensaje SUPRIMIR DATOS DE ABONADO.
De acuerdo con una realizaci6n de ejemplo, se puede usar una "mensaje de datos de abonado delta" para indicar modificaciones. Este mensaje puede incluir tanto parametros modificados como nuevos parametros, una lista de los parametros a suprimir y el parametro de gesti6n de revisi6n asociado con el perfil actualizado de abonado. La totalidad de esta informaci6n puede ser enviada en un mensaje unico que sea mucho mas corto que el uno o mas mensajes de ISD. Posibles nombres para tal mensaje nuevo y la respuesta apropiada pueden ser, por ejemplo, indicaci6n de MODIFICACION DE DATOS DE ABONADO DE MAP y respuesta MODIFICACION DE DATOS DE ABONADO DE MAP. Este nuevo mensaje de MAP mejora la eficacia del concepto de Super-Cargador. En casos extremos, puede ser necesario que el "mensaje de datos de abonado delta" se envfe como mensajes multiples si la cantidad de datos que es necesario transferir es muy grande debido a, por ejemplo, extensas modificaciones del perfil de abonado.
Tras la recepci6n de uno o mas "mensajes de datos de abonado delta" desde el HLR, el VLR o la SGSN utiliza las indicaciones de modificaci6n recibidas en el mensaje o mensajes para actualizar la versi6n previamente almacenada del perfil de abonado o reflejar la versi6n del perfil de abonado actualmente almacenada en el HLR. El VLR o la SGSN sustituyen entonces el parametro de gesti6n de revisi6n previamente almacenado por el parametro de gesti6n de revisi6n recibido del HLR.
Para que esto funcione, el HLR debe mantener seguimiento de al menos las ultimas modificaciones del perfil de abonado. Siempre que sean registradas todas las modificaciones en la versi6n del perfil de abonado retenidas en el VLR o la SGSN y la versi6n almacenada en el HLR, se puede usar el "mensaje de datos de abonado delta". De otro modo, el perfil de abonado completo tiene que ser transferido junto con el parametro de gesti6n de revisi6n, justo como en el concepto actualmente propuesto de Super-Cargador.
Serfa posible, por supuesto, utilizar los nuevos mensajes para los casos de gesti6n de datos de abonado que estan solos.
Esta realizaci6n puede ser comprendida por medio del ejemplo siguiente, con referencia a las figuras 12A-F, que ilustran diferentes versiones de un ejemplo de perfil de abonado, las figuras 13A-E, que ilustran registros de modificaci6n ejemplares, y la figura 14, que ilustra un ejemplo de mensaje de datos de abonado delta.
Sup6ngase que se usan las letras A-Z del alfabeto como el conjunto de parametros que pueden aparecer en un perfil de abonado, representando estos parametros, por ejemplo, servicios. Diferentes perfiles de abonado contendran diferentes subconjuntos de estos 26 parametros, y algunos perfiles de abonado pueden incluso contener todos estos parametros, dependiendo, por ejemplo, de a que servicios se subscribe un abonado.
Cada parametro tiene un cierto valor, que puede variar de perfil a perfil. Algunos de los parametros pueden tener una estructura de datos interna.
Sup6ngase que un abonado con la IMSI "imsi-�" tiene un perfil de abonado que contiene 10 parametros. Ademas, sup6ngase que el parametro de gesti6n de revisi6n es un numero de secuencia unico, que es actualizado secuencialmente para cada versi6n del perfil de abonado. Suponiendo que la versi6n actual del perfil de abonado "imsi-�" es 6, en la figura 12A se muestra un perfil ejemplar de abonado.
Sup6ngase ahora que el perfil de abonado se modifica anadiendo un nuevo parametro S con el valor 4 al perfil, por ejemplo debido a que se cambia una subscripci6n del servicio. La figura 13A ilustra c6mo puede parecer el registro de modificaci6n resultante.
La figura 12B ilustra un perfil de abonado (versi6n 7) con modificaciones hechas de acuerdo con el registro de modificaci6n mostrado en la figura 13A. El antiguo perfil de abonado (versi6n 6) no es almacenado, pero se almacena el registro de modificaci6n.
Sup6ngase que, a continuaci6n, se anade un nuevo parametro D con el valor 5 al perfil, y que se cambia a 8 el valor del parametro G. Un nuevo registro de modificaci6n se anade a la tabla de modificaciones para reflejar estos cambios, como se muestra en la figura 13B. La figura 12C ilustra el perfil de abonado resultante (versi6n 8).
A continuaci6n sup6ngase que se suprime el parametro G y que se cambia a 7 el valor del parametro P. De nuevo, se anade un nuevo registro de modificaci6n a la tabla de modificaciones, como se muestra en la figura 13C. El perfil de abonado resultante (versi6n 9) se muestra e la figura 12D.
A continuaci6n, sup6ngase que se suprime el parametro S. Un registro de modificaci6n apropiado se anade a la tabla de modificaciones, como se muestra en la figura 13D. El perfil de abonado resultante (versi6n 10) aparece en la figura 12E.
Sup6ngase que se anade entonces el nuevo parametro W, con el valor 6. Sup6ngase ahora que el HLR s6lo ahorra registros de modificaciones para cuatro versiones. Esto significa que los contenidos de los registros de modificaci6n son ahora desplazados un paso hacia la izquierda de la tabla. El resultado es que el contenido del registro 1 se elimina de la tabla, y los datos que reflejan las modificaciones mas recientes se ponen en el registro 4. La tabla de modificaciones resultante se muestra en la figura 13E. La figura 12F muestra el perfil de abonado resultante (versi6n 11).
Continuando este escenario de modificaciones de perfil de abonado, sup6ngase ahora que es recibido de un VLR un mensaje de Petici6n ACTUALIZAR SITUACION DE MAP que corresponde al abonado con la IMSI "imsi-�". El mensaje incluye un parametro de gesti6n de revisi6n, de manera que el VLR soporta aparentemente el concepto de Super-Cargador, que indica que la versi6n de perfil de abonado almacenada en el VLR tiene numero 7 de revisi6n.
Es muy facil para el HLR determinar si las modificaciones registradas son suficientes para crear un "mensaje de datos de abonado delta" para actualizar la versi6n de perfil de abonado en el VLR para el almacenado en el HLR. La tabla de modificaciones descrita anteriormente permite al HLR el nuevo seguimiento de cambios en versiones de perfil y hacer posible acumular modificaciones de hasta cuatro versiones. Por lo tanto, si se indica como "C" el numero actual de versi6n de perfil de abonado, entonces se puede usar un "mensaje de datos de abonado delta" si el numero de versi6n de la versi6n de perfil de abonado en el VLR, indicado como V, esta en el intervalo C � 4 a C � 1, es decir, si C � 4� V � C �1. El caso en que V � C es trivial, ya que esto significa que el perfil de abonado en el VLR no necesita ser actualizado, y no tiene que ser enviado ni un mensaje de datos de abonado delta ni un mensaje INSERTAR DATOS DE ABONADO DE MAP. En el ejemplo en cuesti6n, C � 11 y V � 7 � C � 4. De ese modo, se puede utilizar un "mensaje de datos de abonado delta" para actualizar la versi6n de perfil de abonado en el VLR.
Para constituir un "mensaje de datos de abonado delta" que indique esas modificaciones requeridas para actualizar el perfil de abonado desde la versi6n 7 a la versi6n 11, el HLR tiene que acumular las modificaciones de la tabla de modificaciones y poner las modificaciones acumuladas resultantes en el mensaje. El "mensaje de datos de abonado delta" en este ejemplo tendrfa entonces los contenidos ilustrados en la figura 14, en la cual los nuevos parametros y los parametros modificados estan incluidos en una clase de parametros "nueva o modificada". Cuando este mensaje es recibido en el VLR, el VLR extrae las modificaciones del mensaje, modifica su versi6n de perfil de abonado y, por lo tanto, sustituye el parametro de gesti6n de revisi6n.
La figura 15 ilustra un metodo ejemplar para manejar datos de abonado de acuerdo con la segunda realizaci6n. El metodo comienza en el paso 1500, en el que es recibida en el HLR una petici6n para actualizar un perfil de abonado. Esta petici6n puede ser recibida, por ejemplo, durante un procedimiento de actualizaci6n de situaci6n, un procedimiento de Asignaci6n de GPRS o un Procedimiento de Actualizaci6n de Zona de Encaminamiento. En el paso 1510, se efectua una determinaci6n, por ejemplo por el HLR, de si las modificaciones registradas en el HLR son suficientes para describir las diferencias entre la versi6n del perfil de abonado almacenada en el VLR o la SGSN y la versi6n actualmente almacenada en el HLR. Esta determinaci6n puede ser hecha comparando los numeros de versi6n de los perfiles y determinando si el numero de versi6n del perfil en el VLR esta dentro del margen predeterminado del numero de versi6n del perfil almacenado en el HLR. Si las modificaciones son suficientes, por
ejemplo si el numero de versi6n del perfil almacenado en el VLR esta dentro del margen predeterminado del numero de versi6n del perfil almacenado en el HLR, en el paso 1520, las modificaciones son enviadas por el HLR en un "mensaje de datos de abonado delta". Si las modificaciones registradas no son suficientes, por ejemplo si el numero de versi6n del perfil almacenado en el VLR esta fuera del margen predeterminado de la versi6n del perfil almacenado en el HLR, la totalidad del perfil de abonado es enviada por el HLR en el paso 1530.
De acuerdo con esta realizaci6n, enviando s6lo las modificaciones del perfil de abonado desde el HLR al VLR durante el procedimiento de actualizaci6n de situaci6n o a la SGSN durante un procedimiento de Asignaci6n de GPRS o un Procedimiento de Actualizaci6n de Zona de Encaminamiento usando el concepto de Super-Cargador, la cantidad de datos de senalizaci6n se reduce significativamente en comparaci6n con el concento de Super-Cargador propuesto actualmente.
Aunque estas realizaciones se dirigen a la reducci6n de datos de senalizaci6n, haciendo mas eficaz el concepto de Super-Cargador, permanece el problema de desasignaci6n y ambiguedad de TMSLNP-TMSI.
De acuerdo con una tercera realizaci6n, esta se enfrenta a los problemas de la desasignaci6n de TMSINP-TMSI descritos anteriormente. De acuerdo con un aspecto de esta realizaci6n, en la amplia mayorfa de los casos (cuando el abonado se identifica con la TMSI en la petici6n de actualizaci6n de situaci6n o la P-TMSI en la petici6n de Asignaci6n de GPRS o petici6n de Actualizaci6n de Zona de Encaminamiento), una recepci6n de un mensaje de petici6n ENViAR IDENTIFICACION DE MAP en el VLR previo o la recepci6n de un mensaje de Petici6n de Identificaci6n o un mensaje de Petici6n de Contexto de SGSN en la SGSN previa tiene el mismo efecto que un mensaje SITUACION DE CANCELACION DE MAP (excepto que el perfil de abonado es retenido de acuerdo con el concepto de Super-Cargador de curso), es decir, es desasignada la TMSINP-TMSI del abonado pertinente.
La figura 16A ilustra un metodo de manejar datos de abonado de acuerdo con este aspecto. El metodo comienza en el paso 1600, en el que es recibida una petici6n para identificaci6n de abonado en un previo VLR o SGSN que sirve una zona desde la cual se ha desplazado el abonado. En el paso 1610, es desasignada la identidad de abonado del abonado correspondiente el previo VLR o SGSN.
Para cubrir la pequena minorfa restante de los casos (o la totalidad de los casos en el caso de no-GPRS si es suprimido el mensaje de identificaci6n ENVIO DE MAP), es tambien necesario otro mecanismo como un respaldo. De ese modo, de acuerdo con otro aspecto, una TMSINP-TMSI se puede hacer valida durante s6lo un cierto periodo de tiempo especificado, por ejemplo, "T", despues del ultimo contacto entre el MS y la red. Esto significa que si el tiempo T ha transcurrido desde el ultimo contacto con la red, el MS no es asignado para usar la TMSINP-TMSI para identificarse en la red en un intento de acceso subsiguiente y no ha de responder a subsiguientes mensajes de pagina que incluyan la TMSINP-TMSI. En otras palabras, despues del tiempo T desde el ultimo contacto con el MS, la TMSINP-TMSI es suprimida en el MS: Para permitir alguna discrepancia de tiempo, la red no desasigna la TMSINP-TMSI hasta que haya transcurrido el tiempo T + � (donde � es una pequena fracci6n de T) desde el ultimo contacto con el MS: La red no usa la TMSINP-TMSI en un mensaje de pagina entre los tiempos T-� y T+� desde el ultimo contacto con el MS.
Incluso aunque los parametros de la TMSI y la P-TMSI fueron tratados conjuntamente en los anteriores parrafos, puede haber un par de parametros de temporizaci6n para la TMSI y uno para la P-TMSI, por ejemplo, TTMSI y �TMSI, y TP-TMSI y �P-TMSI, y estos no necesitan tener los mismos valores.
Como un ejemplo, T puede ser 48 horas, y � puede ser 2 horas. Otros valores ejemplares para T pueden ser 24 horas o 72 horas, y otros valores ejemplares para � pueden ser 1 hora o 3 horas.
Los valores de los parametros T y �, ya sean los mismos o diferentes para la TMSI y la P-TMSI, respectivamente, pueden ser normalizados y codificados fuertemente o pueden ser especificados como formando parte de la radiodifusi6n de informaci6n del sistema en cada celula, dejando con ello a cada operador la elecci6n de los valores exactos. El ultimo metodo hace posible disponer de diferentes valores de parametros no s6lo en diferentes PLMNs sino tambien diferentes zonas de situaci6n dentro de la misma PLMN (para la TMSI) y en diferentes zonas de servicio de SGSN dentro de la misma PLMN (para la P-TMSI). Esto proporciona alguna flexibilidad a los operadores, que puede ser util, ya que diferentes operadores pueden tener diferentes esquemas de c6digos para el parametro de TMSI y posiblemente tambien para el parametro de P-TMSI. La radiodifusi6n de los valores de parametros como informaci6n del sistema hace tambien posible disponer de diferentes valores de parametros para la TMSI (que es unica dentro de una zona de situaci6n) en diferentes zonas de situaci6n dentro de la misma PLMN. Para la P-TMSI, que es unica dentro de la zona de servicio de una SGSN, serfa posible tener diferentes valores de parametros en diferentes zonas de servicio de SGSN dentro de la misma PLMN. Esto puede ser una caracterfstica util, ya que, por ejemplo, en zonas de situaci6n en que hay normalmente muchos abonados, por ejemplo mas que el promedio, registrados simultaneamente, es mas importante reutilizar valores de TMSI, y por tanto el parametro T (y en consecuencia tambien el parametro �) ha de ser fijado en un valor menor que en las zonas de situaci6n en las que hay normalmente registrados simultaneamente pocos abonados.
La figura 16B ilustra un metodo para manejar datos de abonado de acuerdo con este aspecto. El metodo comienza en el paso 1620, en el que se efectua una determinaci6n, por ejemplo por el HLR, de si ha transcurrido un tiempo T
� � desde el ultimo contacto del MS con la red. Si no, se repite el paso 1620. Si ha transcurrido el tiempo T � �, la red no utiliza la TMSINP-TMSI para localizaci6n en el paso 1630. A continuaci6n, en el paso 1640, se efectua una la determinaci6n, por ejemplo por el HLR, de si ha transcurrido el tiempo T desde el ultimo contacto del MS con la red. Si no, el proceso vuelve al paso 1640. Si ha transcurrido el tiempo T, la TMSINP-TMSI no es utilizada mas por el MS en el paso 1650. A continuaci6n, en el paso 1660, se efectua una determinaci6n, por ejemplo por el HLR, de si ha transcurrido el tiempo T + � desde el ultimo contacto del MS con la red. Si no, el proceso vuelve al paso 1660. Si ha transcurrido el tiempo T + �, la TMSINP-TMSI es desasignada por la red en el paso 1670.
De acuerdo con esta realizaci6n, se resuelven los problemas de TMSINP-TMSI asociados con el concepto de Super-Cargador (es decir, disminuyen la eficacia de gesti6n de TMSINP-TMSI y los problemas de ambiguedad de TMSINP-TMSI). La desasignaci6n de la TMSINP-TMSI se puede conseguir de una manera controlada y dentro de un tiempo razonable. Asf mismo, dejando la aplicaci6n del principio de temporizaci6n incluso cuando se desecha un registro de abonado del VLR o la SGSN por la funci6n de gesti6n de la base de datos del Super-Cargador, se resuelve tambien el problema de ambiguedad de TMSINP-TMSI en relaci6n con el mensaje PURGAR MS DE MAP eliminado. Una desventaja de esta tecnica es que el MS puede a veces tener que identificarse con la IMSI (o puede tener que ser localizado con la IMSI), cuando, si no fuera utilizado el tiempo lfmite, podrfa de otro modo ser utilizada la TMSI o la P-TMSI. Por ello, se reduce algo la utilidad de la TMSINP-TMSI, aunque, de manera probable, marginalmente, dependiendo del valor elegido para el lfmite de tiempo T.
Las realizaciones descritas anteriormente se enfrentan a varios problemas del concepto de Super-Cargador. Otro problema en relaci6n con el concepto de Super-Cargador se presenta en relaci6n con la activaci6n de contexto de PDP.
Los procedimientos descritos en lo que sigue aseguran que una activaci6n de contexto de PDP requerida por la red, sin exito, para un abonado cuyo registro ha sido desechado de la SGSN por la funci6n de gesti6n de la base de datos del Super-Cargador, da lugar a que la bandera "MS Purgado para GPRS" es fijada para el abonado pertinente en el HLR. Para ayudar en su entendimiento, se puede hacer referencia a las figuras 6 y 7.
Tras la recepci6n de un mensaje de Petici6n de Notificaci6n de PDU referente a un abonado cuyo registro ha sido desechado de la SGSN por la funci6n de gesti6n de la base de datos del Super-Cargador, la SGSN retorna al mensaje de Respuesta de Notificaci6n de PDU que incluye una indicaci6n de error con el nuevo valor de causa "MS Purgado" o "MS Purgado para GPRS". La indicaci6n de error puede tambien ser de la forma de un parametro de Error de Usuario que indique el nuevo error "GPRS de Abonado Ausente" con la informaci6n de diagn6stico "MS Purgado" o "MS Purgado para GPRS".
Como una alternativa, puede ser incluido un nuevo parametro en el mensaje de indicaci6n INFORME DE FALLO DE MAP, que indica que la IMSI pertinente ha sido purgada en la SGSN. Con el fin de que el HLR sea capaz de verificar si el abonado correspondiente fue purgado de la SGSN que esta actualmente almacenada en el registro de abonado del HLR, la Direcci6n de SGSN (de la SGSN que retorna el mensaje de Respuesta de Notificaci6n de PDU a la GGSN) puede ser incluida en el mensaje de indicaci6n MAP INFORME. Esto puede ser un parametro obligatorio o un parametro incluido s6lo cuando se informa de una indicaci6n "MS Purgado" o "MS Purgado para GPRS" de cualquier clase.
Tras la recepci6n de la indicaci6n de error (transportando la informaci6n de que el MS ha sido purgado en la SSN) en el mensaje de indicaci6n INFORME DE FALO DE MAP, el HLR fija la bandera "MS Purgado para GPRS" para el abonado pertinente (siempre que la Direcci6n de SGSN recibida en el mensaje de indicaci6n INFORME DE FALLO DE MAP sea la misma que la Direcci6n de SGSN actualmente almacenada para el abonado pertinente en el HLR). El HLR tambien fija la bandera MNRG para el abonado correspondiente y puede fijar tambien el parametro MNRR en el registro de abonado al nuevo valor "MS Purgado para GPRS", "MS Purgado" o "MS Purgado para No-GPRS o GPRS". El HLR confirma entonces el fallo informado con el mensaje de confirmaci6n INFORME DE FALLO DE MAP a la GGSN. La GGSN puede fijar tambien una bandera MNRG para el abonado pertinente.
Aunque en el procedimiento anteriormente descrito la bandera "MS Purgado para GPRS" se fija para un abonado cuyo registro de abonado ha sido desechado por la funci6n de gesti6n de la base de datos del Super-Cargador en la SGSN y para el cual acaba de fallar una activaci6n de contexto de PDP requerida por la red, en preparaci6n para transferencia de paquetes de datos de GPRS terminados en m6vil.
La figura 17 ilustra un metodo para manejar datos de abonado de acuerdo con la cuarta realizaci6n. El metodo comienza en el paso 1700, en el que se efectua una determinaci6n de si tiene exito la activaci6n de PDP. Si no, se hace una determinaci6n en el paso 1710 por el HLR de si fue purgado el registro de MS: Esta determinaci6n puede hacerse basandose, por ejemplo, en mensajes de error desde la SGSN, segun es confirmada con la GGSN. Si el HLR determina que el registro de MS fue purgado, el HLR fija el MS purgado para que la bandera de GPRS sea fijada en el paso 1720. De otro modo, el proceso vuelve al paso 1700.
De acuerdo con esta realizaci6n una activaci6n de contexto de PDP requerida por la red, sin exito, para un abonado, cuya registro ha sido desechado de la SGSN por la funci6n de gesti6n de la base de datos del Super-Cargador, da lugar a que se fije un "MS Purgado para indicaci6n de GPRS" para el abonado pertinente en el HLR. Por tanto, se impiden intentos de activaci6n de contexto de PDP requerida por la red (es decir, intentos para suministrar paquetes de datos de GPRS terminados en m6vil) o intentos de suministrar mensajes cortos al abonado correspondiente.
De acuerdo con las realizaciones ejemplares, se proporcionan metodos para manejar datos de abonado. Las tecnicas propuestas imponen s6lo modificaciones poco importante del MAP de GSM actual (GSM TS 09.02) o el concepto de Super-Cargador actualmente propuesto.

Claims (31)

  1. REIVINDICACIONES
    1. Un metodo para manejar datos de abonado para un abonado que se desplaza o transita en una red que incluye una entidad de red domestica o local que contiene informaci6n relativa a abonados a la red y una o mas entidades de red visitante que contiene informaci6n relativa a abonados a una o mas de otras redes, comprendiendo el metodo:
    -
    recibir una petici6n (1100) de actualizaci6n de situaci6n en una nueva entidad de red visitante que sirve una zona hacia la que se desplaza el abonado desde una zona servida por una entidad de red visitante previa;
    -
    indicar la petici6n (1110) de actualizaci6n de situaci6n a la entidad de red domestica;
    -
    determinar si necesita actualizaci6n (1120) un perfil de abonado del abonado almacenado en la nueva entidad de red visitante;
    -
    determinar si se cumplen (1130) condiciones para actualizar el perfil de abonado almacenado en la nueva entidad de red visitante desde la entidad de red visitante previa; y
    -
    si el perfil de abonado necesita actualizaci6n y se cumplen las condiciones, actualizar el perfil de abonado almacenado en la nueva entidad de red visitante desde la entidad de red visitante previa.
  2. 2.
    El metodo de la reivindicaci6n 1, en el que el paso de determinar si el perfil de abonado precisa actualizaci6n comprende comparar en la entidad de red domestica un parametro de versi6n que indica una versi6n del perfil de abonado almacenada en la nueva entidad de red visitante con un parametro deversi6n que indica una versi6n del perfil de abonado almacenado en la entidad de red domestica.
  3. 3.
    El metodo de la reivindicaci6n 1, en el que el paso de determinar si se cumplen las condiciones para actualizar el perfil de abonado en la nueva entidad de red visitante desde la entidad de red visitante previa incluye determinar si la entidad de red visitante previa esta situada en la misma Red de M6viles Terrestre Publica, PLMN, o en el mismo pafs que la nueva entidad de red visitante.
  4. 4.
    El metodo de la reivindicaci6n 3, en el que esta determinaci6n se efectua en la entidad de red domestica.
  5. 5.
    El metodo de la reivindicaci6n 1, que comprende ademas enviar desde la entidad de red domestica una respuesta de situaci6n de actualizaci6n a la nueva entidad de red visitante que indica que el perfil de abonado actualizado ha de ser recuperado de la entidad de red visitante previa.
  6. 6.
    El metodo de la reivindicaci6n 5, que comprende ademas enviar desde la nueva entidad de red visitante un mensaje a la entidad de red visitante previa que solicita que el perfil de abonado actualizado sea transferido a la nueva entidad de red visitante.
  7. 7.
    El metodo de la reivindicaci6n 6, que comprende ademas devolver desde la entidad de red visitante previa el perfil de abonado actualizado en uno o varios mensajes de respuesta.
  8. 8.
    El metodo de la reivindicaci6n 6, que comprende ademas, si el perfil de abonado no puede ser recuperado de la entidad de red visitante previa, enviar a la entidad de red domestica un mensaje de restauraci6n que incluye la identidad del abonado pertinente.
  9. 9.
    El metodo de la reivindicaci6n 8, en el que el mensaje incluye una indicaci6n explfcita de que el perfil de abonado y su parametro de gesti6n de revisi6n asociado ha de ser enviado desde la entidad de red domestica a la nueva entidad de red visitante.
  10. 10.
    El metodo de la reivindicaci6n 3, en el que esta determinaci6n se efectua en la nueva entidad de red visitante.
  11. 11.
    El metodo de la reivindicaci6n 10, que comprende ademas enviar a la entidad de red visitante previa un mensaje requiriendo la transferencia de un perfil de abonado mas nuevo.
  12. 12.
    El metodo de la reivindicaci6n 1, en el que el paso de determinar si el perfil de abonado necesita ser actualizado comprende comparar en la entidad de red visitante previa un parametro de versi6n que indica una versi6n del perfil de abonado almacenado en la nueva entidad de red visitante con un parametro de versi6n que indica la versi6n del perfil de abonado actualmente almacenado en la entidad de red visitante previa.
  13. 13.
    El metodo de la reivindicaci6n 1, en el que el paso de actualizar comprende enviar desde la entidad de red visitante previa a la entidad de red visitante nueva el nuevo perfil de abonado y su parametro de versi6n asociado en uno o mas mensajes de respuesta.
  14. 14.
    El metodo de la reivindicaci6n 13, que comprende ademas, tras la recepci6n del uno o mas mensajes de respuesta desde la entidad de red visitante previa, sustituir el perfil de abonado previamente almacenado y el
    parametro de versi6n asociado por el perfil de abonado y parametro de versi6n asociado recibido en el mensaje de respuesta.
  15. 15.
    El metodo de la reivindicaci6n 1, en el que la red soporta comunicaci6n de circuito conmutado, la entidad de red domestica es un registro de situaci6n domestico, HLR, y las entidades de red visitantes son registros de situaci6n visitantes, VLRs.
  16. 16.
    El metodo se la reivindicaci6n 1, en el que la red soporta Servicio General de Radio en Paquetes, GPRS, la entidad de red domestica es un registro de situaci6n domestico, HLR, conectado a un Nodo de Soporte de GPRS de Compuerta, GGSN, y las entidades de red visitantes son Nodos de Soporte de GPRS de Servicio, SGSNs.
  17. 17.
    Un sistema para manejar datos de abonado para un abonado que se desplaza en una red que incluye una entidad de red domestica que contiene informaci6n relativa a abonados a la red y una o mas entidades de red visitantes que contienen informaci6n relativa a abonados a una o mas de otras redes, comprendiendo el sistema:
    -
    medios para recibir una petici6n de situaci6n de actualizaci6n en una nueva entidad de red visitante que sirve una zona hacia la que se ha desplazado el abonado desde una zona servida por una entidad de red visitante previa;
    -
    medio para indicar la petici6n de situaci6n de actualizaci6n a la entidad de red domestica;
    -
    medios para determinar si necesita actualizaci6n un perfil de abonado del abonado almacenado en la nueva entidad de red visitante;
    -
    medios para determinar si se cumplen condiciones para actualizar el perfil de abonado almacenado en la nueva entidad de red visitante desde la entidad de red visitante previa; y
    -
    medios para actualizar, si el perfil de abonado necesita actualizaci6n y se cumplen las condiciones, el perfil de abonado almacenado en la nueva entidad de red visitante desde la entidad de red visitante previa.
  18. 18.
    El sistema de la reivindicaci6n 17, en el que los medios para determinar si el perfil de abonado necesita actualizaci6n comprenden medios para comparar en la entidad de red domestica un parametro de versi6n que indica una versi6n del perfil de abonado almacenada en la nueva entidad de red visitante con un parametro de versi6n que indica una versi6n del perfil de abonado almacenada en la entidad de red domestica.
  19. 19.
    El sistema de la reivindicaci6n 17, en el que los medios para determinar si se cumplen las condiciones para actualizar el perfil de abonado en la nueva entidad de red visitante desde la entidad de red visitante previa incluyen medios para determinar si la entidad de red visitante previa esta situada en la misma Red de M6viles Terrestre Publica, PLMN, o en el mismo pafs, que la nueva entidad de red visitante.
  20. 20.
    El sistema de la reivindicaci6n 19, en el que esta determinaci6n se hace en la entidad de red domestica.
  21. 21.
    El sistema de la reivindicaci6n 17, que comprende ademas medios para enviar desde la entidad de red domestica una respuesta de situaci6n de actualizaci6n a la nueva entidad de red visitante que indica que el perfil de abonado actualizado debe ser recuperado de la entidad de red visitante previa.
  22. 22.
    El sistema de la reivindicaci6n 21, que comprende ademas medios para enviar desde la nueva entidad de red visitante un mensaje a la entidad de red visitante previa solicitando que sea transferido el perfil de abonado actualizado a la nueva entidad de red visitante.
  23. 23.
    El sistema de la reivindicaci6n 22, que comprende ademas medios para devolver desde la entidad de red visitante previa el perfil de abonado actualizado en uno o varios mensajes de respuesta.
  24. 24.
    El sistema de la reivindicaci6n 22, que comprende ademas medios para enviar a la entidad de red domestica un mensaje de restauraci6n que incluye la identidad del abonado pertinente si el perfil de abonado no puede ser recuperado de la entidad de red visitante previa.
  25. 25.
    El sistema de la reivindicaci6n 24, en el que el mensaje incluye una indicaci6n explfcita de que el perfil de abonado y su parametro de gesti6n de revisi6n asociado debe ser enviado desde la entidad de red domestica a la nueva entidad de red visitante.
  26. 26.
    El sistema de la reivindicaci6n 19, en el que esta determinaci6n es efectuada en la nueva entidad de red visitante.
  27. 27.
    El sistema de la reivindicaci6n 26, que comprende ademas medios para enviar a la entidad de red visitante previa un mensaje que requiere la transferencia a un nuevo perfil de abonado.
  28. 28.
    El sistema de la reivindicaci6n 17, en el que los medios para determinar si el perfil de abonado necesita ser actualizado comprende comparar en la entidad de red visitante previa un parametro de versi6n que indica una
    versi6n del perfil de abonado almacenado en la nueva entidad de red visitante con un parametro de versi6n que indica la versi6n del perfil de abonado actualmente almacenada en la entidad de red visitante previa.
  29. 29.
    El sistema de la reivindicaci6n 17, en el que los medios para actualizar comprenden medios para enviar
    desde la entidad de red visitante previa a la entidad de red visitante nueva el perfil de abonado mas nuevo y su 5 parametro de versi6n asociado en uno o mas mensajes de respuesta.
  30. 30. El sistema de la reivindicaci6n 29, que comprende ademas medios para sustituir el perfil de abonado previamente almacenado y el parametro de versiones asociado por el perfil de abonado y parametro de versi6n asociado recibido en el mensaje de respuesta, tras la recepci6n del uno o mas mensajes de respuesta procedentes de la entidad de red visitante previa.
    10 31. El sistema de la reivindicaci6n 17, en el que la red soporta comunicaci6n de circuito conmutado, la entidad de red domestica es un registro de situaci6n domestico, HLR, y las entidades de red visitantes son registros de situaci6n visitantes, VLRs.
  31. 32. El sistema de la reivindicaci6n 17, en el que la red soporta Servicio General de Radio en Paquetes, GPRS,
    la entidad de red domestica es un registro de situaci6n domestico, HLR, conectado a un Nodo de Soporte de GPRS 15 de Compuerta, GGSN, y las entidades de red visitantes son Nodos de Soporte de GPRS de Servicio, SGSBs.
ES00964559T 1999-08-24 2000-08-24 Método y sistema para manejar datos de abonado Expired - Lifetime ES2385964T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US15046399P 1999-08-24 1999-08-24
US150463P 1999-08-24
US15454399P 1999-10-19 1999-10-19
US154543P 1999-10-19
PCT/IB2000/001433 WO2001015463A2 (en) 1999-08-24 2000-08-24 Methods and systems for handling subscriber data

Publications (1)

Publication Number Publication Date
ES2385964T3 true ES2385964T3 (es) 2012-08-06

Family

ID=26847689

Family Applications (1)

Application Number Title Priority Date Filing Date
ES00964559T Expired - Lifetime ES2385964T3 (es) 1999-08-24 2000-08-24 Método y sistema para manejar datos de abonado

Country Status (7)

Country Link
EP (1) EP1206893B1 (es)
CN (1) CN1203715C (es)
AT (1) ATE554611T1 (es)
AU (1) AU7548100A (es)
CA (1) CA2376370C (es)
ES (1) ES2385964T3 (es)
WO (1) WO2001015463A2 (es)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI109164B (fi) 2000-05-15 2002-05-31 Sonera Oyj Pakettidataprotokollakontekstin aktivoiminen verkon pyynnöstä
US7054629B2 (en) * 2001-08-24 2006-05-30 Telefonaktiebolaget Lm Ericsson (Publ) Method and means for redistribution of subscriber information in UMTS networks where the nodes are arranged in pools
ES2281690T3 (es) * 2002-08-21 2007-10-01 Intellprop Limited Aparatos y procedimientos de servicios de telecomunicaciones.
GB0227777D0 (en) 2002-11-28 2003-01-08 Nokia Corp Performing authentication
ES2226562B1 (es) * 2003-05-12 2005-12-01 Vodafone España, S.A. Dispositivo, metodo y programa de ordenador para la deteccion de activacion de un abonado en una red de telefonia movil celular.
EP1569475B1 (de) * 2004-02-27 2007-12-12 ORGA Systems enabling services GmbH Vorrichtung und Verfahren zur Aktualisierung der Konfiguration des Datenspeichers der Chipkarte eines mobilen Endgeräts
US9113334B2 (en) * 2008-02-01 2015-08-18 Tekelec, Inc. Methods, systems, and computer readable media for controlling access to voice resources in mobile networks using mobility management signaling messages
CN102136963B (zh) * 2010-10-27 2013-06-05 华为软件技术有限公司 一种数据一致性校验方法及系统
US9992663B2 (en) 2014-09-26 2018-06-05 Telefonaktiebolaget Lm Ericsson (Publ) Methods and nodes for handling updated subscriber data

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE505444C2 (sv) * 1995-10-18 1997-08-25 Ericsson Telefon Ab L M Anordning och förfarande för överföring av information som tillhör en mobil abonnent som förflyttar sig inom ett cellulärt telekommunikationssystem
FI106354B (fi) * 1998-02-18 2001-01-15 Nokia Networks Oy Menetelmä matkaviestimen tietojen käsittelemiseksi
WO1999056492A1 (en) * 1998-04-27 1999-11-04 Telefonaktiebolaget Lm Ericsson (Publ) Selective subscriber profile download from a persistant storage node to a transient storage node

Also Published As

Publication number Publication date
EP1206893A2 (en) 2002-05-22
CN1399853A (zh) 2003-02-26
CA2376370C (en) 2012-07-17
WO2001015463A3 (en) 2001-11-01
ATE554611T1 (de) 2012-05-15
CA2376370A1 (en) 2001-03-01
CN1203715C (zh) 2005-05-25
EP1206893B1 (en) 2012-04-18
WO2001015463A2 (en) 2001-03-01
AU7548100A (en) 2001-03-19

Similar Documents

Publication Publication Date Title
US6731932B1 (en) Methods and systems for handling subscriber data
ES2239762T3 (es) Disposicion para reenvio de llamadas en un centro de conmutacion de servicios moviles.
ES2359736T3 (es) Generación dinámica de csi para abonados itinerantes salientes.
EP1665838B1 (en) Signaling gateway with multiple imsi with multiple msisdn (mimm) service in a single sim for multiple roaming partners
US6611685B1 (en) Home location register fault recovery
ES2235323T5 (es) Entrega de mensajes cortos en una red de radiocomunicaciones por paquetes.
ES2748107T3 (es) Procedimiento y dispositivo para el tratamiento de llamadas telefónicas dirigidas a teléfonos móviles inaccesibles
ES2356108T3 (es) Registro de un terminal móvil en una zona de solapación de cobertura de celdas por primeras y segundas redes.
US7873358B2 (en) Method and system for providing inbound traffic redirection solution
US6181937B1 (en) Method for avoiding unnecessary signalling in a cellular communications system
US20030027572A1 (en) Method and system for primary paging location of mobile terminal
BRPI0608800A2 (pt) sistema e método para gerar informações de assinante (mo-csi) de aplicações personalizadas de origem móvel para lógica avançada de rede móvel (camel) de um roamer entrante e produto de programa de computador
CN1162385A (zh) 用于电信系统中的人工访问者的归属位置登记器
ES2385964T3 (es) Método y sistema para manejar datos de abonado
KR20130121156A (ko) 모바일 통신 디바이스들을 위한 모바일 착신 로밍 전달
ES2231866T3 (es) Transmision de una identidad de abonado en un sistema de comunicaciones moviles.
EP2156696B1 (en) Logical paging areas
ES2313911T3 (es) Plataforma de sevicios de movilidad inalambricos.
ES2626173T3 (es) Procedimiento, entidad de red, red de telecomunicaciones y producto de programa informático para manejar datos de abono en una red de telecomunicaciones
US6788936B1 (en) Gateway location register fault recovery
CN101137222A (zh) 一种接入鉴权处理方法和系统及装置
EP1244324B1 (en) Method for roaming in a network with different access technologies, and system therefor
WO2015101808A1 (en) A steering of roaming system
Lin et al. GSM mobility management
WO2018147749A1 (es) Métodos y sus componentes para identificar equipos celulares irregulares que no deben operar en ninguna red celular en un país o grupo de países