ES2430367T3

ES2430367T3 - Dispositivo, método y programa de ordenador para detectar la activación de un abonado en una red de telefonía móvil celular

Info

Publication number: ES2430367T3
Application number: ES04380106T
Authority: ES
Inventors: Pedro Almenar Belenguer; Rogelio Martinez Perea
Original assignee: Vodafone Group PLC
Current assignee: Vodafone Group PLC
Priority date: 2003-05-12
Filing date: 2004-05-12
Publication date: 2013-11-20
Anticipated expiration: 2024-05-12
Also published as: EP1478205B1; EP1478205A3; EP1478205A2; ES2226562A1; ES2226562B1

Abstract

Un dispositivo (10) para detectar la activación de un equipo de abonado en una red de telefonía móvilcelular, considerando detectar la activación como el momento en el cual el citado equipo de abonado se conecta auna red de telefonía móvil celular por primera vez, caracterizado porque comprende: un medio (11) para recibir y almacenar datos relativos al menos a un abonado en la red de telefonía móvilen una base de datos (12); un medio (13) para generar y enviar una solicitud de Actualizar Ubicación (S11) a un Registro de UbicaciónLocal, HLR, (9) de la red para al menos un abonado, incluyendo la solicitud de actualización una indicación ficticiadel área de ubicación confirmada de manera que el Registro de Ubicación Local, HLR, (9) envía, tras recibir del MSC(5) una subsiguiente solicitud de actualizar ubicación (S16) correspondiente al mismo abonado, un subsiguientemensaje de Cancelar Ubicación correspondiente al mismo abonado al dispositivo (10); un medio (14) para recibir el citado mensaje de Cancelar Ubicación (S18) desde el Registro de UbicaciónLocal, HLR, (9); un medio (15) para modificar el contenido de un primer campo de datos (12AN, 12BN) asociado al abonadocomo respuesta a la recepción del citado mensaje de Cancelar Ubicación (S18), siendo el primer campo de datos uncampo que indica una hora de activación del equipo de abonado y/o un estado de activado / no activado del equipode abonado.

Description

Dispositivo, método y programa de ordenador para detectar la activación de un abonado en una red de telefonía móvil celular

Campo de la invención

La invención se encuentra dentro del campo de la telefonía móvil. Como es conocido, acrónimos y términos ingleses son utilizados normalmente en el citado campo para referirse a elementos y conceptos que pertenecen al campo. Los acrónimos y términos ingleses utilizados en esta memoria se explicarán en el texto.

Antecedentes de la invención

El propósito de la invención es detectar, de una manera sencilla y que sea aplicable en las actuales redes de telefonía móvil, el momento en el cual un abonado activa su teléfono móvil, por ejemplo cuando un abonado con una tarjeta de prepago empieza a utilizar la tarjeta de prepago en una red de telefonía móvil.

La red troncal de telefonía móvil está formada por ciertos nodos principales que llevan a cabo las funciones básicas en la red, tales como conectar y desconectar los terminales, encaminar llamadas de voz y enviar mensajes cortos.

Para la red de telefonía móvil PLMN (Red de Telefonía Móvil Terrestre Pública – Public Land Mobile Network, en inglés), el área geográfica está dividida en celdas, cada una de las cuales está servida por una “estación de base” o BTS (Estación Transceptora de Base - Base Transceptor Station, en inglés). La figura 1 muestra una red de este tipo, en la que puede verse cómo un teléfono móvil 1 (en este documento, un teléfono móvil, el abonado - la persona que posee el teléfono móvil - y el cliente se nombran indistintamente) se encuentra en una celda 2 correspondiente a la estación de base 3; otras estaciones de base 3 corresponden a otras celdas de la red.

Cada estación de base (BTS – Base Transceiver Station, en inglés) depende de un nodo controlador de estación de base o BSC (Controlador de Estación de Base - Base Station Controller, en inglés) 4. El BSC gestiona la actividad de varias estaciones de base 3 que están a cargo, por ejemplo, del encaminamiento de las llamadas y mensajes a la estación de base que cubre el teléfono móvil de destino.

A su vez, varios BSCs 4 dependen de un centro de conmutación o MSC (Centro de Conmutación de Telefonía Móvil

– Mobile Switching Center, en inglés) (5, 6), un nodo de red que controla varios BSCs y que gestiona el control de la ubicación de los abonados que están en su área de control.

Además, la red mostrada en la figura 1 comprende varios Registros de Ubicación de Visitante o VLR (Visitor Location Register, en inglés) (7, 8). El VLR es una base de datos de abonados “visitantes” que almacena temporalmente ciertos datos relativos a los abonados que están en el área de red correspondiente al VLR. Ejemplos de datos almacenados en el VLR son la IMSI (Identidad de Abonado de Telefonía Móvil Internacional – International Mobile Subscriber Identity, en inglés), el MSISDN (el propio número de teléfono que se marca para llamar al teléfono móvil), o la TMSI ((Identidad de Abonado de Telefonía Móvil Temporal -Temporary Mobile Subscriber Identity, en inglés) diferente de la IMSI por razones de seguridad), el área de ubicación en la que el abonado ha sido registrado y los servicios suplementarios de los clientes que se abonan los cuales, en ese momento, se encuentran en el área de la red cubierta por ese VLR. Cada VLR cubre un área de ubicación. Puede haber varios VLRs en el área cubierta por un MSC, pero también es posible que un VLR contenga información de áreas cubiertas por varios MSCs. En algunos sistemas, hay un VLR para cada MSC, y a veces el MSC y el VLR están integrados en la misma unidad física, la cual es en ocasiones denominada “MSC/VLR”.

La red comprende también un Registro de Ubicación Local o HLR (Home Location Register, en inglés) 9 que es la base de datos en la que todos los datos relativos al servicio de telefonía móvil de los abonados de la red están almacenados, tales como su identidad IMSI y MSISDN, el VLR en el cual están situados (cada cambio de área de ubicación llevado a cabo por un móvil es detectado por la red y su dirección de VLR es automáticamente actualizada en la base de datos HLR). Existe también información relativa al tipo de servicio ofrecido al abonado, así como los servicios suplementarios proporcionados a él/ella. Normalmente en las redes con muchos abonados, los datos del abonado están distribuidos en varios HLRs.

El procedimiento de ubicación se describe ampliamente en el documento ETSI 123 909 V4.0.0 (2001-03), un informe técnico del Instituto de Estándares de Telecomunicaciones Europeo (ETSI - European Telecommunications Standards Institute, en inglés).

Lógicamente, para que un abonado sea capaz de recibir una llamada, es importante que pueda ser “localizado” en la red, de manera que una llamada pueda ser encaminada a su terminal mediante los correspondientes MSC y BTS 3. Con este fin, es importante que siempre que un abonado esté activo (con el teléfono móvil encendido), exista información centralizada en la red que permita conocer en qué área de ubicación se encuentra el abonado, para poder así encaminar la llamada a la citada área de ubicación. Es asimismo importante que haya información centralizada en la red, que indique si el abonado está activo y dónde. La solución adoptada en el GSM (Sistema Global para Comunicaciones mediante Telefonía Móvil - Global System for Mobile Communications, en inglés) se basa en la notificación por parte del teléfono móvil de los cambios de posición que está sufriendo. Este proceso comprende dos diálogos independientes: el diálogo de actualización de la nueva posición y el diálogo de desactualización de la posición previa, que se describirán con referencia a las figuras 2 y 3:

1) Proceso de actualización: este proceso es llevado a cabo cuando el abonado enciende el terminal de telefonía móvil y, además, cada vez que el abonado cambia de área de ubicación (es decir, cuando pasa del área de ubicación correspondiente a un VLR al área de ubicación correspondiente a otro VLR). Cada área de ubicación está formada por un conjunto de celdas y corresponde a un VLR.

Como se muestra esquemáticamente en la figura 2, cuando el abonado se conecta a la red (encendiendo su teléfono) o cuando él/ella cambia de área de ubicación (entrando en el área de ubicación correspondiente a un VLR 7), el MSC 5 correspondiente al BSC 4 que corresponde a la estación de base 3 en la celda en la cual está situado en abonado, envía (etapa S1 en la figura 2) una solicitud de Actualizar Ubicación al HLR 9, de manera que el HLR 9 envíe los datos de suscripción del cliente al MSC 5. Estos datos incluyen los datos que especifican los servicios disponibles para el citado cliente.

El HLR 9 almacena la dirección del VLR 7 (unívocamente correspondientes al área de ubicación en la cual está situado el abonado) para saber dónde está situado el abonado y poder dirigir llamadas entrantes a la citada área de ubicación, y envía uno o varios mensajes de Insertar Datos de Abonado con la información solicitada al MSC 5 (etapa S2 en la figura 2); el MSC 5 almacena los datos en el VLR 7 asociado. Para comprobar que las operaciones son llevadas a cabo correctamente, hay un intercambio de mensajes entre el MSC y el HLR. El MSC 5 responde (etapa S3) con un Insertar Resultado de Datos del Abonado para informar al HLR 9 acerca de si los datos le han llegado correctamente, y en último lugar, el HLR 9 envía (etapa S4) un Actualizar Resultado de Ubicación, donde comunica si el proceso de actualización ha sido llevado a cabo correctamente.

2) Proceso de Desactualización: este proceso consiste en que el HLR informe a un VLR (por medio de un MSC asociado) de que un abonado previamente situado en su área de ubicación ha cambiado de área de ubicación, como resultado de lo cual él/ella es controlado/controlada por otro MSC.

Esto ocurre, por ejemplo, si el abonado del teléfono móvil 1 de la figura 1 se mueve desde la celda 2 asociada al MSC 5 (área de ubicación del VLR 7) a una celda asociada al MSC 6, correspondiente al área de ubicación del VLR

8.

En ese caso, como se muestra esquemáticamente en la figura 3, el proceso de actualización (etapas S1-S4) explicado en relación con la figura 2 y esquemáticamente mostrado en la figura 3) es llevado a cabo primero, y a continuación, una vez que el proceso de actualización ha sido completado con éxito (por medio del cual el HLR 9 “sabe” que el abonado está en el área de ubicación correspondiente al VLR 8), el HLR 9 informa al VLR 7 de que el abonado previamente situado en su área de ubicación ha cambiado de área de ubicación, como resultado de lo cual él/ella es controlado/controlada por un MSC correspondiente a otro VLR.

Con este fin, el HLR envía (etapa S5 en la figura 3) un mensaje de Cancelar Ubicación al MSC 5 indicando para el citado MSC que elimine los datos del citado cliente temporalmente almacenados en el VLR 7. El MSC 5 responde con un mensaje de Cancelar Resultado de Ubicación (etapa S6) al HLR confirmando que la operación ha sido llevada a cabo correctamente.

Los teléfonos móviles incluyen tarjetas, proporcionadas por un operador de telefonía móvil y que permiten al cliente utilizar el teléfono móvil; normalmente se considera que tal teléfono móvil, también llamado equipo de abonado, está constituido por el terminal y por la tarjeta. En GSM, la tarjeta se denomina SIM (Módulo de Identidad de Abonado – Subscriber Identity Module, en inglés) y es el elemento al cual corresponde realmente la suscripción a la red, de manera que si un cliente cambia los terminales, manteniendo la misma tarjeta, él/ella conserva aún su perfil de suscripción y teléfono móvil. En UMTS (Sistema de Telecomunicación mediante Telefonía Móvil Universal – Universal Mobile Telecommunications System, en inglés), también llamado Telefonía Móvil de Tercera Generación – Third Generation Mobile Telephony, en inglés), esta tarjeta se denomina normalmente USIM (Módulo de Identidad de Abonado Universal – Universal Subscriber Identity Module, en inglés); el Módulo de Identidad del Abonado – Subscriber Identity Module, en inglés) en UMTS).

Las tarjetas de un operador situado en el canal de distribución se denominan tarjetas preactivadas, un término que indica que no han sido utilizadas todavía por el abonado, pero que han sido ya definidas en los sistemas del operador para su funcionamiento subsiguiente. Las suscripciones bases de datos a esas tarjetas deben estar definidas en los correspondientes HLRs, es decir, deben ser llevadas a cabo una serie de acciones para insertar los citados datos de suscripción, incluyendo la IMSI (Identidad de Abonado de Telefonía Móvil Internacional – International Mobile Subscriber Identity, en inglés), MSISDN (Número ISDN Internacional de Estación de Telefonía Móvil – Mobile Station International ISDN Number, en inglés) - el número de teléfono real), y los servicios disponibles para el cliente, en los HLRs; si el HLR correspondiente a una tarjeta no incluye estos datos, la tarjeta no puede ser utilizada.

Si el momento en cual una tarjeta se considera que está en uso se denomina “activación”, en el caso de las tarjetas correspondientes a suscripciones de post-pago, la activación acurre cuando el cliente correspondiente firma el contrato de suscripción con el operador. Desde ese momento, el cliente puede, en teoría, utilizar su tarjeta.

En el caso de tarjetas correspondientes a suscripciones de prepago, puesto que el teléfono móvil puede ser utilizado desde el momento en el cual es colocada en el paquete de venta (la caja que incluye el terminal, sus accesorios, la tarjeta SIM y cierta información adicional para utilizar el terminal y la tarjeta es normalmente llamada así), podría considerarse que la activación ocurre cuando el cliente enciende el teléfono y se registra en la red por primera vez con la tarjeta en cuestión.

Si la “activación” de una tarjeta de prepago se considera que ocurre cuando el cliente enciende el teléfono por primera vez, actualmente no hay medio de averiguar cuándo ocurrió la citada “activación”. En el modo en el que la telefonía móvil funciona hoy en día, ni los MSCs/VLRs ni los HLRs proporcionan esta información a sistemas externos.

Conocer el “momento de activación” puede ser importante, por ejemplo, para definir comisiones a vendedores, definir promociones de validez temporal, etc. Por ejemplo, si se define una promoción de X euros en llamadas, que dura durante Y meses, y ese dirige hacia nuevos clientes, ¿desde cuándo empiezan a contarse los Y meses? Si es desde la pre-activación de la tarjeta, dado que el tiempo entre la pre-activación y la venta de la tarjeta es normalmente largo (a veces incluso meses), en muchos casos el cliente no se beneficiará nunca de la promoción, o quizás él/ella se beneficiaría sólo de ella durante algunos días hasta que expira. Con este fin, es preferible empezar a contar el tiempo del periodo de promoción desde el momento en el que la tarjeta empieza a ser utilizada; no obstante, el operador del sistema actualmente no conoce cuándo ocurre esto; incluso no puede asumirse que sea el momento de la venta: el paquete podría ser vendido como un regalo y ser abierto semanas tras la venta.

De la misma manera, cuando existe una lista de clientes que no han estado registrados en la red durante mucho tiempo, puede ser interesante conocer el momento en el cual los citados clientes se registran en la red tras un periodo de tiempo tan largo, por ejemplo para poder realizar acciones de marketing que intentan hacerlos utilizar más el teléfono móvil (enviándoles mensajes, activando posibles promociones, etc.) Actualmente no hay medio de poder informar a los sistemas responsables de tales acciones del registro del abonado en la red.

Con este fin, existe la necesidad de proporcionar un medio para que una entidad (por ejemplo, un proveedor de servicios de telefonía móvil) pueda averiguar cuándo se registra un cliente en la red, por ejemplo, cuando se registra por primera vez (lo que puede ser de interés en el caso de tarjetas pre-activadas) o cuándo se registra un cliente en la red tras un largo periodo de tiempo sin que se haya registrado.

Descripción de la invención

La invención se realiza de acuerdo con las reivindicaciones independientes 1, 3 y 5.

Un primer aspecto de la invención se refiere a un dispositivo para detectar la activación de un cliente en un área de telefonía móvil celular, que comprende:

un medio para recibir y almacenar datos relativos al menos a un cliente en la red de telefonía móvil en una base de datos (estos datos pueden incluir la IMSI y el MSISDN del cliente, así como datos relativos al tipo de tarjeta: prepago, post-pago, etc.; los datos pueden ser recibidos en forma de una lista que comprende estos datos para una pluralidad de clientes, y los datos pueden ser almacenados en una base de datos interna del dispositivo para la activación de la detección);

un medio para generar y enviar una solicitud de Actualizar Ubicación para el citado al menos un cliente a un Registro de Ubicación Local (HLR – Home Location Register, en inglés) de la red, incluyendo la solicitud de activación una indicación ficticia del área de de ubicación configurada de tal manera que el Registro de Ubicación Local (HLR – Home Location Register, en inglés) envíe un subsiguiente mensaje de Cancelar Ubicación correspondiente a la ubicación del mismo cliente al dispositivo para detectar la activación;

un medio para recibir el citado mensaje de Cancelar Ubicación desde el Registro de Ubicación Local (HLR – Home Location Register, en inglés);

un medio para modificar el contenido de un primer campo de datos asociado al cliente como respuesta a la recepción del citado mensaje de Cancelar Ubicación, siendo el primer campo de datos un campo que indica una hora de activación y/o un estado activado / no activado del cliente.

El dispositivo de la invención “engaña” así al HLR; puede decirse que se hace pasar por un VLR / MSC ficticio, haciendo que el HLR, a continuación del proceso de desactualización convencional, envíe un mensaje de desactualización al dispositivo de la invención cuando el abonado activa su teléfono en la red e inicia la comunicación con una estación de base (BTS – Base Transceiver Station, en inglés) asociada con un MSC/VLR (y, por lo tanto, inicia los correspondientes procesos de actualización y de desactualización). Así, una parte de los datos que indica una hora de activación del cliente (que puede corresponder al momento en el cual se recibe el mensaje de cancelar localización o al momento en el cual el contenido del campo de datos es modificado), y/o un estado activado / no activado del cliente (por ejemplo, el contenido del campo de datos puede pasar de un código correspondiente a un estado “no activado” a que sea un código correspondiente a un estado “activado”) se introduce en un campo de datos (el “primer campo”). El campo de datos puede ser parte de la misma lista de datos explicada anteriormente, o parte de otra lista o base de datos, por ejemplo, una base de datos externa. En otras palabras, la invención contempla la posibilidad de modificar un “primer campo” en una base de datos externa, por medio del envío de un mensaje a la citada base de datos.

De esta manera y verificando el contenido del citado “primer campo”, la activación de un cliente (o una tarjeta) puede ser detectada de manera prácticamente instantánea.

El término “dispositivo” debe ser interpretado en un sentido amplio: no es necesario que todos los componentes que constituyen el dispositivo estén integrados en una única entidad física (caja, módulo,…), sino que por el contrario los diferentes componentes del dispositivo pueden constituir entidades físicas separadas, dispuestas se manera que pueden comunicarse e interactuar entre sí, de acuerdo con lo descrito anteriormente y de acuerdo con lo que se describe a continuación.

El medio para generar y enviar la solicitud de Actualizar Ubicación puede estar configurado para enviar la citada solicitud a los clientes que aparecen en la base de datos de una manera secuencial y de acuerdo con el contenido de al menos un segundo campo de datos, asociado con el cliente, de la citada base de datos. El citado segundo campo de datos puede parcial o completamente coincidir con el citado primer campo de datos, es decir, por ejemplo, el medio para generar y enviar la solicitud de actualizar ubicación puede ser configurado para enviar la solicitud sólo a

-: los clientes para los cuales el primer campo de datos no incluye todavía una parte de los datos que indica una “hora de activación”;

-: los clientes para los cuales el primer campo de datos incluye un código que indica que aún no han sido activados; y/o

-: los clientes para los cuales el primer campo de datos incluye una parte de los datos que indica una “hora de activación” que excede un “nivel de antigüedad” predeterminado, es decir, indica que el abonado no ha estado activo en la red “durante un largo periodo de tiempo”.

El segundo campo de datos puede alternativa o complementariamente incluir una o varias posiciones que indican el número de veces que la solicitud de Actualizar Ubicación ha sido enviada y/o cuándo fue la última vez que la citada solicitud se envió al HLR para los clientes de la lista. La invención puede de este modo estar configurada de manera que tiene en cuenta esta parte de datos en el momento de decidir cuándo y en qué orden enviar las posiciones de actualización de ubicación para los diferentes clientes de la base de datos. Puede haber también un tercer campo de datos que incluye estos datos.

El medio para generar y enviar la solicitud de actualización de ubicación puede ser configurado para enviar la citada solicitud a los clientes que aparecen en la citada base de datos en una manera espaciada en el tiempo y/o durante ciertos periodos de tiempo del día y/o de la noche, con el propósito de evitar que enviar tal solicitud para un número grande de clientes provoque una sobrecarga en la red.

Como se ha sugerido en lo anterior, el primer campo de datos puede ser un campo de datos en la base de datos, por ejemplo, un campo en la misma lista que incluye la IMSI y el MSISDN de cada cliente.

Otro aspecto de la invención se refiere a un método para detectar la activación de un cliente en un área de telefonía móvil celular, que comprende las etapas de:

recibir y almacenar datos relativos al menos a un cliente en la red de telefonía móvil en una base de datos (estos datos pueden incluir la IMSI y el MSISDN del cliente, así como los datos relativos al tipo de tarjeta; prepago, post-pago, etc.; los datos pueden ser recibidos en forma de una lista que comprende estos datos para una pluralidad de clientes);

un medio para generar y enviar un Registro de Ubicación Local (HLR – Home Location Register, en inglés) de la red, una solicitud de Actualizar Ubicación para el citado al menos un cliente, incluyendo la solicitud de actualización una indicación ficticia del área de ubicación de manera que el Registro de Ubicación Local (HLR – Home Location Register, en inglés) envía un mensaje de Cancelar Ubicación subsiguiente que corresponde a la ubicación del mismo abonado al dispositivo para la detección de la activación;

recibir el citado mensaje de Cancelar Ubicación desde el Registro de Ubicación Local (HLR – Home Location Register, en inglés):

recibir el citado mensaje de Cancelar Ubicación desde el Registro de ubicación Local (HLR – Home Location Register, en inglés);

modificar el contenido de un primer campo de datos asociado con el cliente como respuesta a la recepción del citado mensaje de Cancelar Ubicación, siendo el citado primer campo de datos un campo que indica una hora de activación del cliente y/o un estado de activado / no activado del cliente.

Lo que se ha explicado anteriormente en relación con el dispositivo es también aplicable al método, mutatis mutandis.

La citada solicitud de Actualizar Ubicación para los clientes que aparecen en la citada base de datos es enviada de una manera secuencial y de acuerdo con el contenido de al menos un segundo campo de datos, asociado al cliente, de la citada base de datos. Este segundo campo ha sido ya explicado con detalle anteriormente, en la descripción del dispositivo.

Como se ha explicado ya:

-: el citado campo de datos puede al menos parcialmente coincidir con el citado primer campo de datos;

-: la solicitud para los clientes que aparecen en la citada base de datos puede ser enviada de una manera separada en el tiempo y/o durante ciertos periodos de tiempo del día y/o de la noche, con el propósito de evitar que el envío de la citada solicitud para un número grande de clientes provoque una sobrecarga de la red;

-: el primer campo de datos puede ser un campo de datos en la base de datos.

Otro aspecto de la invención se refiere a un programa de ordenador que comprende instrucciones de programación para hacer que un ordenador lleve a cabo el método descrito en lo anterior, cuando el programa de ordenador es ejecutado en el ordenador.

Otro aspecto de la invención se refiere al citado programa de ordenador en un medio de soporte; el medio de soporte puede ser, por ejemplo, un disquete, un CD-ROM, una memoria de ordenador o cualquier otro tipo de datos y de medio de soporte de instrucciones. El medio de soporte puede ser también una señal eléctrica u óptica, por ejemplo, una señal propagada a través de una red de telecomunicaciones.

Breve descripción de los dibujos

Una serie de dibujos pueden ser explicados a continuación muy brevemente, lo que ayudará en la mejor comprensión de la invención y que se refieren expresamente a una realización de la citada invención, lo que se presenta como un ejemplo ilustrativo y no limitativo de la misma.

La figura 1 muestra esquemáticamente algunos de los nodos principales de una red de telefonía móvil convencional, de acuerdo con el estado de la técnica.

La figura 2 muestra esquemáticamente un proceso de actualización de acuerdo con el estado de la técnica.

La figura 3 muestra esquemáticamente un proceso de desactualización de acuerdo con el estado de la técnica.

La figura 4 muestra esquemáticamente las diferentes etapas llevadas a cabo de acuerdo con una realización preferida de la invención.

La figura 5 muestra esquemáticamente el dispositivo de acuerdo con una realización preferida de la invención.

Las figuras 6A y 6B muestran esquemáticamente ejemplos de configuración de los datos de un cliente almacenados en la base de datos del dispositivo, de acuerdo con una realización preferida de la invención.

Descripción de una realización preferida de la invención

La figura 4 muestra un dispositivo 10 para detectar la activación de un cliente, de acuerdo con una realización preferida de la invención, integrada en una red de telefonía móvil que incluye un HLR 9 y varios VLRs y MSCs, de los cuales se muestran un MSC 5 y un VLR 7, así como un BSC 4, una BTS 3 y un cliente o teléfono móvil 1; la red puede ser una red tal como la descrita en relación con las figuras 2 y 3, sólo el dispositivo 10 ha sido añadido a él. La figura 5 muestra esquemáticamente los principales módulos funcionales que forman parte del dispositivo 10.

Como puede verse en las figuras 4 y 5, el dispositivo comprende un medio 11 para recibir y almacenar datos relativos a una pluralidad de clientes en la red de telefonía móvil. El medio 11 recibe los datos en una etapa mostrada esquemáticamente como etapa S10, y los almacena en una lista, en una base de datos 12. Los datos son proporcionados por la entidad (o entidades) que desean registrar la primera vez que un cliente accede a la red. La lista puede ser completada con nuevos clientes a medida que la entidad o entidades envían estos datos en etapas S10 sucesivas.

Para cada cliente, los datos recibidos y almacenados en la base de datos 12 comprenden su IMSI, MSISDN y, preferiblemente el tipo de tarjeta (prepago, post-pago), la fecha en la que el cliente fue insertado en la lista, la hora en la que el cliente fue insertado en la lista, una marca de actualización (indicando si el proceso de actualización ficticio ha sido llevado a cabo correctamente), el número de reintentos de actualización, etc. Estos datos son insertados en los campos (12A1,…, 12B1,…) de la base de datos. Hay un primer campo de datos (12AN,… 12BN,…) para cada cliente que es un campo que indica un estado activado / no activado, y que comprende una marca de activado / no activado y, además, una hora de activación. Cuando los datos de un abonado son introducidos en la base de datos, la marca de activado / no activado tiene un valor que corresponde a “no activado” (por ejemplo, “0”) por defecto, y la hora de activación se sitúa como fecha y hora 0 (por ejemplo, “000000-00”) por defecto. La marca de actualización asimismo indica que el proceso de actualización no ha sido llevado a cabo todavía.

El medio 13 para generar y enviar la solicitud de Actualizar Ubicación al HLR 9 lleva a cabo la solicitud de Actualizar Ubicación (etapa S11) para los diferentes clientes de una lista de una manera consecutiva y de acuerdo con una secuencia predeterminada, de acuerdo con la actualización y las marcas de activado / no activado, así como de acuerdo con el número de intentos de actualización llevados a cabo, y también de acuerdo con la fecha y hora en la que cada abonado fue insertado en la lista, y a un ritmo predefinido establecido con el propósito de impedir una sobrecarga de la red. Tanto el ritmo como la secuencia de envío para los diferentes clientes pueden ser configurados, por ejemplo, para adaptar el ritmo a la distribución temporal de la carga de trabajo del HLR (por ejemplo, estas operaciones pueden ser llevadas a cabo durante horas en las cuales el tráfico es bajo, aprovechando el hecho de que el HLR tiene capacidad libre).

La solicitud de Actualizar Ubicación S11 es una operación de Actualizar Ubicación de MAPv3 y comprende una indicación ficticia del área de ubicación, incluyendo la dirección (de acuerdo con el número del plan de numeración) asignada al dispositivo 10, de manera que el HLR 9 envía un subsiguiente mensaje de Cancelar Ubicación al dispositivo 10. Hasta la etapa S11, sigue una serie de etapas similares a las etapas descritas en relación con el proceso convencional de la figura 2: el HLR 9 almacena la dirección asignada al dispositivo 10 (correspondiente a un área de ubicación ficticia), y envía uno o varios mensajes de Insertar Datos de Abonado (etapa S12) al dispositivo 10; el dispositivo simplemente desestima estos mensajes (puesto que no proporcionan nada relevante) y responde (etapa S13) con un Insertar Resultado de Datos de Abonado para indicar al HLR 9 que los datos han llegado correctamente, y por último, el HLR 9 envía (etapa S14) un Actualizar Resultado de Ubicación, en el que comunica si el proceso de actualización ha sido llevado a cabo correctamente. Si ha sido llevado a cabo correctamente, el dispositivo 10 cambia la marca de actualización indicando que el proceso de actualizar ubicación ha sido llevado a cabo para el cliente en cuestión. Si no ha sido llevado a cabo correctamente, la parte de datos correspondiente al número de reintentos de actualizar ubicación aumenta en la base de datos 12 (pasa de 0 a 1, y a continuación de 1 a 2, etc.); esta parte de datos puede ser tenida en cuenta por el dispositivo para determinar cuándo debería ser realizado el siguiente intento de actualizar ubicación para el cliente en cuestión.

Cuando el cliente se conecta a la red por primera vez con una estación de base BTS 3 asociada al MSC/VLR 5/7, comienza el proceso de actualizar ubicación de acuerdo con lo explicado en relación con la figura 2: el MSC 5 correspondiente al BSC 4 que corresponde a la estación de base 3 en la celda en la cual está situado el cliente, envía (etapa S16 de la figura 4) una solicitud de Actualizar Ubicación al HLR 9 de manera que el HLR 9 envía los datos de suscripción del cliente al MSC 5. El HLR 9 almacena la dirección del VLR 7 y envía uno o varios mensajes de Insertar Datos de Abonado con la información solicitada, etc., al MSC 5 (etapa S17 de la figura 4).

Por otro lado y una vez que el proceso de actualizar ubicación se ha completado, se lleva a cabo el proceso de desactualización: el HLR informa al VLR ficticio (es decir, el dispositivo 10 en este caso) de que el cliente en cuestión está ahora controlado por el VLR/MSC 7/5.

Con ese fin, el HLR envía (etapa S18 en las figuras 4 y 5) un mensaje de Cancelar Ubicación al dispositivo 10, el cual responde con un mensaje de Cancelar Resultado de Ubicación (etapa S19) al HLR confirmando que la operación ha sido llevada a cabo correctamente.

En otras palabras, el proceso de la invención es transparente para el HLR: desde el punto de vista del HLR, lo que ha ocurrido es que el cliente simplemente se ha movido de un área de ubicación a otra.

El mensaje de Cancelar Ubicación es recibido en el dispositivo 10 por el medio 14 para recibir el mensaje de Cancelar Ubicación. Como respuesta a la citada recepción, el medio 15 para modificar el contenido de un primer campo de datos modifica el citado campo para el abonado en cuestión: específicamente, cambia la marca de activado / no activado que toma el valor correspondiente a activado (por ejemplo, de “0” a “1”) y la hora de activación: por ejemplo, la parte de datos “000000-00” es reemplazada por la fecha y hora en la que fue recibido el mensaje de Cancelar Ubicación, como resultado de lo cual las correspondientes posiciones del primer campo pueden cambiar, por ejemplo, a “200403-15”.

El contenido de la base de datos 12 es leído periódicamente y, para los clientes cuya marca de activación ha tomado el valor que indica el estado “activado” (por ejemplo, “1”), se leen los datos que identifican al cliente (por ejemplo, el MSISDN y la IMSI) así como ha hora de activación (por ejemplo, “200403-15”), y estos datos son proporcionados a la entidad que proporcionó los datos de los clientes en el momento en el que los citados datos fueron suministrados. A continuación, los datos correspondientes a estos clientes son borrados de la base de datos 12.

La figura 6A muestra una posible configuración de los datos correspondientes a un primer cliente A en la base de datos 12 justo después de haber introducido los datos del citado cliente (es decir, justo después de la etapa S10); el campo 12A1 incluye la IMSI, el campo 12A2 incluye el MSISDN, el campo 12A3 incluye la marca de actualización (tiene el valor “0” puesto que las etapas S11-S14 no han sido llevadas a cabo aún para este abonado), el campo 12A4 incluye el número de reintentos de actualización (todavía tiene el valor “0” puesto que no se ha realizado ningún intento) y el “primer campo” 12AN comprende la marca de activado / no activado (que tiene valor “0”) seguida por la hora de activación (que tiene el valor inicial 000000-00).

La figura 6B muestra los mismos campos de la base de datos un poco después de la etapa S18; los campos 12A1 y 12A2 no han cambiado, pero la marca de actualización en el campo 12A3 tiene el valor “1” (cambió de “0” a “1” tras la etapa S14), el campo 12A4 con el número de reintentos de actualización tiene el valor “1” (esto indica que sólo se llevó a cabo un reintento de actualización), y el “primer campo” 12AN muestra la marca de activado / no activado con valor “1” (lo que indica que el abonado se ha conectado a la red) seguido por la hora de activación, el valor “20040315” del cual indica que el mensaje S18 fue recibido el 20 de Abril de 2003, entre las 3:00 pm y las 4:00 pm.

En un posible desarrollo de la realización descrita anteriormente, podría añadirse una segunda base de datos (no mostrada en las figuras). En este caso, la primera base de datos 12 podría almacenar la información relativa a las tarjetas preactivadas que no han sido “activadas” todavía en el sistema, es decir, las tarjetas pendientes de ser registradas para su “activación”, y la segunda base de datos podría contener los datos correspondientes a las tarjetas cuya activación ha sido detectada. A continuación, una vez que la activación de una tarjeta es detectada (debido a la recepción del mensaje de cancelar activación en la etapa S18 descrita anteriormente), los datos del cliente en cuestión se pasan de la primera base de datos a la segunda base de datos. Así, la primera base de datos sólo contiene los datos relativos a tarjetas cuya activación no ha sido detectada todavía.

Los datos relevantes contenidos en la segunda base de datos pueden ser enviados periódicamente a la entidad de destino externa que debe recibir la información relativa a los datos y la hora de activación de los clientes, y entonces los datos de los clientes en cuestión pueden ser borrados de la segunda base de datos. En las sucesivas ocasiones en las que los datos son enviados desde la segunda base de datos, sólo se incluirán los datos de los clientes cuyos datos han sido añadidos a la segunda base de datos en el intervalo que ha transcurrido desde el envío previo.

En otras palabras, la primera base de datos puede guardar información relativa a tarjetas preactivadas pendientes de activación (para las cuales el mensaje de Cancelar Ubicación que corresponde a la correspondiente etapa S18 en lo anterior no se ha recibido todavía). La primera base de datos podría incluir los datos siguientes:

•: MSISDN

•: IMSI

•: Tipo de marca de tarjeta, que puede indicar, por ejemplo, si la tarjeta de prepago corresponde a

-: una preactivación (nueva suscripción de un cliente) (0),

-: una conversión (un cliente de post-pago que se convierte en un cliente de prepago) (1),

-: una tarjeta de “saldo arrastrado” (correspondiente a un cliente de otro operador que decide cambiar al operador de la red) (2).

•: Fecha en la cual la preactivación ha sido completamente concluida en los sistemas del operador, es decir, la fecha en la cual la tarjeta es definida en los sistemas del operador para su posterior funcionamiento. Conociendo esta fecha, el tiempo transcurrido desde que la tarjeta es preactivada hasta que la tarjeta es activada puede ser calculado, información interesante, por ejemplo, para marketing y logística.

•: Marca de actualización. Ésta indica si el proceso de actualización ficticia ha sido llevado a cabo correctamente (corresponde al campo 12A3)

•: Número de reintentos de actualización (corresponde al campo 12A4)

La marca de activado / no activado podría ser desestimada puesto que los datos van de la base de datos primera a la segunda tan pronto como ocurre la activación, como resultado de lo cual es conocido que si los datos están en la primera base de datos, el estado de la tarjeta es que está “no activada”, y si están en la segunda base de datos, el estado es que está “activada”.

La segunda base de datos podría incluir los datos siguientes, que estarían almacenados temporalmente y que serían enviados al sistema exterior de vez en cuando; también puede accederse a los datos para preguntas desde el exterior.

•: MSISDN

•: IMSI

•: Tipo de marca de tarjeta (explicado anteriormente)

•: Fecha en la cual la preactivación de los sistemas del operador ha sido completamente concluida (explicado anteriormente)

•: Número de reintentos de actualización; esta parte de los datos podría ser interesante para detectar problemas en el caso de que el número de reintentos sea significativo; esta parte de los datos corresponde a la que estaba en el campo 12A4 antes de que los datos pasasen de la segunda base de datos a la primera base de datos.

•: Fecha y, opcionalmente, hora de activación del cliente (correspondiente a la hora de activación, véase el campo 12AN explicado anteriormente)

•: Marca enviados / no enviados. Esta marca indica si los datos relativos al cliente han sido enviados a la entidad externa. Esta marca es importante si los datos enviados no son inmediatamente borrados después de ser enviados. Si no son borrados inmediatamente, la segunda base de datos puede incluir datos enviados que son también datos no enviados, en cuyo caso es importante poder distinguir entre los datos que han sido enviados al exterior y los datos que aún no han sido enviados, de manera que los datos que han sido ya enviados no sean enviados de nuevo, y/o de manera que sólo los datos que han sido ya enviados sean borrados.

Lógicamente, lo que ha sido descrito anteriormente es sólo una de las posibles maneras de llevar a cabo la invención. El experto en la materia podría fácilmente hacer modificaciones que pueden ser adecuadas en cada caso, de acuerdo con las necesidades y deseos de las entidades implicadas, y escribir los correspondientes programas de ordenador. Por ejemplo, en lugar de modificar un primer campo en la base de datos 12, puede enviarse un mensaje directamente a una entidad externa cuando el mensaje de Cancelar Ubicación sea recibido en la etapa S18 para modificar una base de datos externa.

En toda la presente descripción y reivindicaciones, la palabra “comprende” y variaciones de la misma, tales como “que comprende” o “que comprenden”, no pretenden incluir otras etapas o componentes.

Claims

REIVINDICACIONES

1. Un dispositivo (10) para detectar la activación de un equipo de abonado en una red de telefonía móvil celular, considerando detectar la activación como el momento en el cual el citado equipo de abonado se conecta a una red de telefonía móvil celular por primera vez, caracterizado porque comprende:

un medio (11) para recibir y almacenar datos relativos al menos a un abonado en la red de telefonía móvil en una base de datos (12);

un medio (13) para generar y enviar una solicitud de Actualizar Ubicación (S11) a un Registro de Ubicación Local, HLR, (9) de la red para al menos un abonado, incluyendo la solicitud de actualización una indicación ficticia del área de ubicación confirmada de manera que el Registro de Ubicación Local, HLR, (9) envía, tras recibir del MSC

(5) una subsiguiente solicitud de actualizar ubicación (S16) correspondiente al mismo abonado, un subsiguiente mensaje de Cancelar Ubicación correspondiente al mismo abonado al dispositivo (10);

un medio (14) para recibir el citado mensaje de Cancelar Ubicación (S18) desde el Registro de Ubicación Local, HLR, (9);

un medio (15) para modificar el contenido de un primer campo de datos (12AN, 12BN) asociado al abonado como respuesta a la recepción del citado mensaje de Cancelar Ubicación (S18), siendo el primer campo de datos un campo que indica una hora de activación del equipo de abonado y/o un estado de activado / no activado del equipo de abonado.
2.

Un dispositivo de acuerdo con la reivindicación 1, caracterizado porque el primer campo de datos (12AN, 12BN) es un campo de datos en la base de datos (12).
3.

Un método para detectar la activación de un equipo de abonado en una red de telefonía móvil celular, considerando la detección de la activación como el momento en el cual el citado equipo de abonado se conecta a una red de telefonía móvil celular por primera vez, caracterizado porque comprende las etapas de:

recibir y almacenar datos relativos al menos a un abonado de la red de telefonía móvil en una base de datos (12);

generar y enviar una solicitud de Actualizar Ubicación (S11) a un Registro de Ubicación Local, HLR, (9) de la red para el citado al menos un abonado, incluyendo la solicitud de actualización una indicación ficticia del campo de datos configurada de manera que el Registro de Ubicación Local, HLR, (9) envía, tras recibir desde un MSC (5) una subsiguiente solicitud de Actualizar Ubicación (S16) correspondiente al mismo abonado, un subsiguiente mensaje de Cancelar Ubicación correspondiente al mismo abonado al dispositivo (10);

recibir el citado mensaje de Cancelar Ubicación (S18) desde el Registro de Ubicación Local, HLR, (9);

modificar el contenido de un primer campo de datos (12AN, 12BN) asociado al abonado como respuesta a la recepción del citado mensaje de Cancelar Ubicación (S18), siendo el citado primer campo de datos un campo que indica una hora de activación del equipo de abonado y/o un estado de activado / no activado del equipo de abonado.
4.

Un método de acuerdo con la reivindicación 3, caracterizado porque el primer campo de datos (12AN, 12BN) es un campo de datos en la base de datos (12).
5.

Un programa de ordenador, que comprende instrucciones de programación para hacer que un ordenador ejecute el método de acuerdo con cualquiera de las reivindicaciones 3 a 4, cuando el programa es ejecutado en el ordenador.
6.

Un programa de ordenador de acuerdo con la reivindicación 5, en un medio de soporte.