FR2923128A1 - Procede de determination automatique du profil de personnalisation gprs d'un mobile. - Google Patents

Abstract

Système selon lequel (a) on analyse le trafic du réseau, (b) on établit une base de données (BDIMEI) avec les paires de numéros (IMSI/IMEI) des mobiles, (c) on établit une base (BDmod) des mobiles par les numéros (TAC) extraits des numéros (IMEI), (d) on renseigne la base (BDmod) en déterminant les profils (P1, P2) compatibles avec les numéros (TAC), (e) on établit un fichier des mobiles non confirmés, (f) on fait un envoi de masse aux mobiles de ce fichier avec un profil (P1), (g) on analyse le trafic de ces mobiles pour renseigner les bases (BDmod et BDIMEI), (h) on répète l'envoi en masse vers les autres mobiles non confirmés en leur adressant un autre profil (P2), (i) on répète l'envoi, (j) on répète l'envoi à une certaine périodicité.

Description

Domaine de l'invention La présente invention concerne un procédé de détermination automatique du profil de personnalisation GPRS d'un mobile. Pour qu'un mobile puisse accéder aux services de données fournis par la norme GPRS qui est une extension du protocole GSM, il est nécessaire que le mobile soit adapté, c'est-à-dire qu'un profil approprié soit inscrit dans le mobile. Ce profile contient les données propres au ré-seau auquel appartient le mobile ainsi que des données adaptées au modèle de téléphone mobile.

Les services ainsi fournis par la norme GPRS sont notamment l'accès à Internet et l'envoi de messages MMS. Les données propres au réseau auquel appartient le mobile sont, par exemple, les suivantes : Dans le cas du mode circuit ou mode GSM : le numéro de 15 téléphone d'une passerelle constitue un modem et l'adresse IP de la passerelle WAP. Dans le cas de la norme GPRS, il s'agit des informations suivantes : APN, adresse IP de la passerelle WAP. Ces paramètres sont connus de l'opérateur du réseau qui 20 peut ainsi les intégrer dans le profil mais l'opérateur ne connaît pas automatiquement le code IMEI qui est le numéro unique identifiant un mobile et se composant du code TAC fourni par l'autorité de certification avec le code du pays où le mobile a été immatriculé suivi du numéro de série de fabrication et d'un chiffre de contrôle de somme des chiffres des co- 25 des TAC et SNR. Mais ce code n'est pas connu automatiquement de l'opérateur. Ainsi, il existe des bases de données disponibles commercialement ou sur Internet et qui permettent de connaître la marque et le modèle d'un téléphone. Mais actuellement, il y a plus de 10 000 modèles 30 de téléphones répertoriés et plus de 20 000 codes IMEI car un modèle peut avoir plusieurs codes ou numéros IMEI. Pour la personnalisation, l'opérateur dispose de deux for-mats principaux de personnalisation des profils. Ces formats sont soit le format OMA (Open Mobile Alliance) et le forme NE développé par Nokia- 35 Ericsson avec quelques variantes en nombres finis. Mais les constructeurs de téléphones ne préparent pas uniformément tous leurs mobiles pour recevoir l'un ou l'autre de ces for-mats et même, de façon inexpliquée, les opérateurs tels que Nokia peuvent adopter le format OMA pour un modèle de téléphone et le format NE pour un autre. Or, si l'opérateur n'introduit pas dans le mobile, le profil accepté par le format pour lequel est prévu le mobile par le constructeur, le 5 mobile ne pourra pas accéder aux services de données GPRS. L'opérateur en chargeant le profil, n'a pas d'informations en retour et ne peut savoir s'il a chargé le bon profil. Il ne peut s'en apercevoir que si l'utilisateur du mobile qui tente d'accéder à un service de don-nées, échoue dans ses tentatives et en informe l'opérateur. Celui-ci charge 10 alors un autre profil dans le mobile et l'opération peut être rejetée si cet autre profil ne convient pas. Le chargement du profil est fait par l'opérateur au moment de la préparation du mobile avant que celui-ci ne soit fourni à son client. Mais l'opérateur peut également charger un nouveau profil par un centre 15 de messages courts SMSC lorsqu'un abonné change de téléphone mais conserve sa carte SIM. Il est usuel de pouvoir charger à distance le profil d'un mobile par une suite de SMS. Mais dans tous les cas, même si le profil n'est pas le bon, le chargement apparaît réussi au niveau du SMSC émetteur. 20 Cette situation peut encore être compliquée par le fait que l'opérateur ne peut savoir par le simple examen de ses bases de données si les abonnés du réseau ont reçu un profil approprié. Les causes sont di-verses à la fois parce que le chargement de profil dans les téléphones que fournit l'opérateur peut ne pas avoir été fait avec le bon profil en fonction 25 des types de mobiles ainsi chargés. Cela peut également provenir du fait qu'un abonné arrive dans le réseau avec sa carte SIM sans que l'opérateur n'ait pu lui fournir d'emblée le profil correct pour l'accès aux services de données GPRS. Ainsi, ne connaissant pas le profil applicable à un modèle 30 de mobile particulier, seul l'essai effectif des fonctions de données par le mobile permet de savoir si le mobile a été chargé avec le bon profil parmi les deux possibles (suivant le format OMA ou NE du mobile). Dans ces conditions, les opérateurs ne peuvent charger automatiquement de façon certaine, qu'un nombre limité de modèles de 35 mobiles puisqu'il n'existe pas de documentation concernant l'ensemble des modèles disponibles (plus de 10 000 modèles différents et plus de 20 000 IMEI caractéristiques car certains modèles ont plusieurs co- des IMEI actuellement) n'existe pas et que ce nombre augmente de jour en jour. Le travail d'obtenir la documentation de 10 000 modèles, pour déterminer le type de profil est impraticable et n'a pas été fait. Les opérateurs ne peuvent donc charger automatiquement qu'un nombre limité de modèles. Ce travail est d'autant plus compliqué et incertain si l'opérateur a un grand nombre d'abonnés pour le service de données. En conclusion, actuellement quelles que soient les dispositions prises par l'opérateur de téléphonie mobile, il ne peut pas savoir si les mobiles de son réseau ont été chargés du profil de personnalisation approprié pour l'accès aux services de données ni quels mobiles le sont ou ne le sont pas. Ce n'est que par la réaction d'un abonné qui ne peut accéder aux services de données que l'opérateur saura que le profil qu'il a mis dans le mobile n'est pas le bon profil et qu'il doit en essayer un autre, en général l'autre des deux profils P1, P2 pour les formats OMA et NE. But de l'invention La présente invention a pour but de développer un procédé permettant à un opérateur de charger des profils en pouvant déterminer automatiquement et rapidement le type de profil de tous les mobiles de ses abonnés jusqu'à ce que chaque abonné ait dans son mobile, un profil qui lui permet d'accéder aux services de données . Exposé et avantages de l'invention A cet effet, la présente invention concerne un système de 25 gestion de profils intégrés dans les mobiles d'un réseau de téléphonie mobile d'un opérateur caractérisé en ce que a- on analyse le trafic des mobiles du réseau, b- on établit une base de données (BDIMEI) avec les paires de numéros (IMSI/IMEI) des mobiles, 30 c- on établit une base de modèles de mobiles (BDmod) des mobiles du ré-seau par les numéros (TAC) extraits des numéros (IMEI), d- on renseigne la base des modèles (BDmod) en déterminant les profils (P1, P2) compatibles avec les numéros (TAC) de la base (BDmod), e-on établit un fichier des mobiles non confirmés (c'est-à-dire dont on n'a 35 pas pu savoir s'ils contiennent le bon profil) en prenant dans l'ensemble des mobiles du réseau ceux (ou une partie de ceux-ci) au- tres que ceux confirmés, f- on fait un envoi de masse aux mobiles de ce fichier avec un premier profil (P1), g- on analyse le trafic des mobiles objet de cet envoi en masse, pour en extraire les mobiles ayant un trafic MMS, considérés alors comme mo- biles confirmés, pour obtenir leur numéro (TAC) et renseigner les bases de données (BDmod et BDIMEI), h- on répète l'envoi en masse vers les autres mobiles non confirmés en leur adressant un autre profil (P2), i- on répète éventuellement l'envoi en masse pour les mobiles non confirmés après ce nouvel envoi, j- on répète l'envoi en masse d'un profil à une périodicité dépendant de la fréquence de l'arrivée de nouveaux mobiles dans le réseau. Suivant une autre caractéristique avantageuse, on construit la base BDIMEI par l'analyse des fichiers de facturation du réseau dont on 15 extrait les paires de numéros IMSI/IMEI. Suivant une autre caractéristique avantageuse, - on construit la fonction EIR qui, à l'émission d'un SMS-MO par un mobile, reçoit une requête MAP_CHECK_IMEI contenant le numéro IMEI qu'il peut appairer avec le numéro IMSI à partir du numéro MSISDN en 20 interrogeant le registre HRL avec ce numéro du mobile émetteur, - en implémentant la requête MAP_OBTAIN_IMEI en recevant un mes-sage SMS et en interrogeant le centre MSC/VLR, visité par le mobile pour obtenir son numéro IMEI et ensuite obtenir, à partir du numéro MSISDN, le numéro IMSI e interrogeant le registre HLR, 25 - par une fonction du registre HLR qui envoie le numéro IMEI dans une requête MAP_Add_IMEI suivie d'une interrogation du registre HLR pour obtenir le numéro IMSI, - avec un outil SIM Tool Kit (STK) de la carte SIM du mobile qui envoie le nouveau numéro IMEI par un message SMS au centre SMSC. 30 Suivant une autre caractéristique, le système détermine automatiquement le type de profil en utilisant en retour des messages SMS de notification MMS envoyés à la fonction MMS et capables de déco-der le protocole SMS et les messages WAP contenus, soit en l'extrayant du champ TP-originating-addresse dans le SMS de type SMS-DELIVER, ou 35 en décodant selon le protocole WAP le champ From dans le message de notification codé suivant le standard WAP et contenu dans la partie TP-User-Data du message SMS-DELIVER.

Suivant une autre caractéristique avantageuse, le système comporte un serveur (OTA-GPRS) intégré au SMSC pour s'adresser aux mobiles du réseau et mettre à jour leur profil. Ainsi, de façon générale, l'invention constitue un système stochastique permettant, par une suite de téléchargements, d'aboutir au bout d'un certain tems à la détermination exacte des types de mobile pour la personnalisation GPRS de tous les mobiles d'un opérateur existant en nombre suffisant pour que l'absence de trafic soit déterminée avec une certitude statistique avec un critère de choix optimisé de l'ordre des es-sais. Dessins La présente invention sera décrite ci-après de manière plus détaillée à l'aide des dessins annexés dans lesquels - La figure 1 est un schéma général du procédé appliqué dans le système 15 selon l'invention, pour déterminer de manière automatique et stochas- tique le type de profil de personnalisation GPRS d'un mobile, - La figure 2 est un schéma du système et de ses bases de données, - la figure 3 montre cinq méthodes dont quatre basées sur des fonction- nalités du réseau pour constituer les paires IMSCl/IMEI dans la base 20 de données IMEI, - la figure 4 montre la détermination automatique et stochastique des types de profils, - la figure 5 est le type de profil en version NE et ONA, - la figure 6 est l'abaque permettant de déterminer au bout de combien 25 de jours le système a convergé, - la figure 7 donne le détail d'un MMS de notification pour en obtenir le numéro MSISDN d'origine. Description de modes de réalisation préférentiels de l'invention Pour simplifier la présentation de l'invention, on utilisera 30 les abréviations usuelles de la technique des téléphones mobiles et un glossaire de ces abréviations est donné en fin de description. Il convient tout d'abord de rappeler qu'un téléphone mobile (ou plus simplement, un mobile) présente les éléments et attributs caractéristiques individuels suivants, nécessaires à la compréhension de 35 l'invention : a- un numéro IMEI Il est formé du code TAC et du code SNR. Le code TAC identifie le modèle de téléphone. Il est attribué à chaque modèle de télé- phone par une autorité administrative. Le code SNR est le numéro de fabrication du mobile, donné par le fabricant. Le numéro IMEI est complété par un code de contrôle C. Le numéro IMEI est unique pour chaque mobile. b- un numéro IMSI : Il s'agit du numéro attribué à la carte SIM utilisée dans le mobile. c- un numéro MSISDN : Il s'agit du numéro d'abonné utilisé pour appeler l'abonné 10 ou lui transmettre un message. Ces trois numéros apparaissent les uns et/ou les autres différemment dans les échanges faits à partir du mobile ou pour le mobile. Le numéro IMEI est inscrit dans la carte SIM, le numéro IMSI et le numéro MSISDN sont connus et utilisés régulièrement par l'opérateur. Celui-ci 15 a des tables de conversion contenant des paires de numéros IMSI/MSISDN dans son registre HLR. Un mobile a des caractéristiques techniques de fabrication particulières appelées format correspondant soit à un format OMA (Open Mobile Alliance), soit à un format NE (Nokia Ericsson). Il existe 20 également d'autres formats mais beaucoup moins répandus, voire très peu répandus. Le format OMA principalement utilisé et le format NE secondairement. Un même fabricant peut utiliser l'un ou l'autre format pour les modèles de téléphone qu'il produit. 25 Le format OMA ou NE du mobile n'est pas connu de l'utilisateur du téléphone et, à priori, il ne l'est pas non plus de l'opérateur. Pour utiliser les services de données GPRS, un mobile doit avoir un profil personnalisé GPRS. Il s'agit d'un programme établi par 30 l'opérateur du réseau dont dépend le mobile. Ce profil personnalisé n'est pas le même si le mobile est au format OMA ou au format NE ou à un autre format, chez le même opérateur. On utilisera les abréviations suivantes : - profil P1 pour un profil compatible avec le format OMA, 35 - profil P2 pour un profil compatible avec le format NE, - profil Px pour un profil autre que celui des formats OMA ou NE. Pour les besoins de la description de l'invention, on distinguera parmi les mobiles chez un opérateur : a- les mobiles dits confirmés, c'est-à-dire ayant le bon profil pour accéder aux services de données GPRS, b- les autres mobiles, c'est-à-dire les mobiles non confirmés et qui ont probablement le mauvais profil ou n'utilisent pas les services de don- nées. Lorsqu'un opérateur reçoit un mobile dans son réseau, il peut s'agir : - d'un mobile nouveau fourni par l'opérateur et qui doit être chargé du profil (pour un lot de nouveaux mobiles, il est probable que l'opérateur io connaisse le format et charge les mobiles avec le profil approprié) ; ou - d'un nouveau mobile d'un client du réseau qui utilise son ancienne carte SIM. Vis-à-vis d'un mobile dont l'opérateur ne connaît pas le format, la procédure de chargement du profil est empirique. En général, 15 l'opérateur charge le profil P1 qui correspond au format OMA le plus fréquent sans pouvoir confirmer ce choix par une réponse que lui adresserait le mobile ou l'ensemble des mobiles chargés avec ce profil et s'il s'avère que ce profil ne convient pas, il charge le second profil P2 qui a alors des chances d'être le bon profil sauf si le mobile est préparé avec un format 20 très particulier ne correspondant pas à la majorité constituée par les deux formats OMA, NE. En régime de fonctionnement courant, le parc des mobiles du réseau de l'opérateur peut se décomposer comme suit : - les mobiles dits confirmés, qui ont le bon profil et, dans ce cas, 25 l'opérateur n'a rien à faire ; -les mobiles dits non confirmés, qui ont le mauvais profil mais n'utilisent pas le service des données GPRS et dans ce cas, l'opérateur n'a rien à faire ; - les mobiles dits non confirmés, qui ont le mauvais profil mais souhai- 30 tent utiliser le service de données GPRS et demandent le bon profil à l'opérateur. Cet état du réseau n'est pas figé car de nouveaux modèles de mobile apparaissent tous les jours, qui souhaitent recevoir le profil permettant d'accéder aux services de données GPRS. 35 Pour connaître l'état des mobiles de son réseau et obtenir des informations permettant de charger autant que faire se peut, le bon profil personnalisé notamment dans les nouveaux mobiles entrant dans le réseau, l'invention prévoit de gérer le réseau en établissant automatique- ment une base de données de modèles (BDmod) et une base de numéros IMEI, (BDIMEI) à partir de l'analyse des mobiles du réseau, fondée sur le trafic de messages échangés par les mobiles du réseau. Les bases BDmod et BDIMEI se constituent progressivement comme cela sera vu ensuite. La base BDmod est une base de données contenant la liste des modèles par leur numéro TAC et la forme du profil P1, P2, Px associé à chaque modèle en fonction de son format OMA ou NE ou autre. La base BDIMEI contient des paires de numéros IMSI/IMEI des mobiles du réseau, obtenus également par l'analyse du trafic des mobiles du réseau comme cela sera vu ci-après. La construction de la base BDmod se fait en analysant les mobiles de l'opérateur : le numéro MSISDN d'un mobile en trafic MMS permet d'obtenir le numéro IMEI du mobile d'où l'on peut extraire le code TAC. Cette analyse permet ainsi de renseigner les deux bases de données comme suit : - base de données BDmod : On y inscrit le code TAC du modèle de ce mobile et son type de profil Pl, P2, Px puisque ce mobile ayant pu en- voyer un MMS, cela signifie qu'il a le bon profil pour ce modèle ; - base de données BDIMEI : On y inscrit la paire de numéros IMSI/IMEI de ce mobile. Le numéro IMEI fait le lien entre les deux base BDmod et BDIMEI ayant un numéro IMEI d'un mobile obtenu à partir de son nu- méro IMSI ou MSISDN, puisque le numéro IMEI contient le code TAC, il est possible dans la base BDmod, de savoir si le modèle de téléphone correspondant à ce code TAC est un modèle confirmé et de connaître le type de profil correspondant. Parallèlement ayant le numéro IMEI pour la base BDIMEI, on pourra avoir le numéro d'appel MSISDN de ce mobile.

Par la paire IMSI/IMEI, on connaît le numéro IMSI et, par suite, grâce à la table HLR, on aura le numéro MSISDN de ce mobile. Réciproquement, à partir des codes TAC des modèles confirmés dans la base BDmod, on pourra déterminer les numéro MSISDN des mobiles confirmés par différence, en éliminant ces numéros dans l'ensemble des numéros des abonnés du réseau de l'opérateur, on aura le numéro des mobiles non confirmés, du moins non inscrits en tant que tels dans la combinaison des deux bases de données BDIMEI et BDmod.

Cela permet de faire un fichier pour un envoi de masse vers ces mobiles non confirmés en leur envoyant un profil, par exemple le pro-fil P1 par le serveur OTA-GPRS intégré au centre SMSC. L'analyse des conséquences de ce premier envoi en masse permet de déterminer les mobiles qui ont ainsi reçu le bon profil. En effet, ces mobiles pourront avoir (et auront par hypothèse), une activité MMS ce qui est le signe que le profil qu'ils ont reçu est le bon profil. On pourra mettre à jour les deux bases de données BDmod et BDIMEI, pour y inscrire le ou les nouveaux modèles de mobile qui seront confirmés avec le profil correspondant et les paires de numéros IMSI/IMEI. Ensuite, il restera éventuellement un ensemble de mobiles non confirmés c'est-à-dire qui ont reçu le profil P1 alors qu'il leur faudrait le profil P2. On établit un nouveau fichier d'envoi en masse en procédant 15 comme cela a été décrit ci-dessus pour procéder à un second envoi en masse aux mobiles non confirmés pour les charger de l'autre profil P2. L'analyse du trafic après ce second envoi en masse permet d'obtenir les mobiles ayant reçu le bon profil P2 et de renseigner les deux bases de donnes BDmod et BDIMEI. 20 Les mobiles non confirmés, qui seront en nombre très ré-duit, devront recevoir un autre profil. Cet essai peut se répéter avec un autre profil en procédant comme indiqué ci-dessus. Ainsi, pour déterminer automatiquement et rapidement le type de profil des mobiles de ses abonnés et la mise à jour de cet état du 25 réseau, l'opérateur procède selon le schéma de la figure 1, en appliquant le procédé de l'invention, comprenant les étapes suivantes à l'aide du serveur OTA-GPRS associé au centre de messages courts SMSC : a- On analyse le trafic des mobiles du réseau pour déterminer les mobiles qui ont un trafic de service de données MMS et on établit un fichier de 30 ces mobiles confirmés comme vu ci-après. b- On établit une base de données BDIMEI avec les paires de numéros IMSI/IMEI des mobiles en récupérant successivement le code IMSI à partir du numéro MSISDN de chaque mobile ayant du trafic des mes-sages MMS, puis on obtient le code IMEI de ce mobile et on inscrit la 35 paire des numéros dans la base de données BDIMEI. c- On établit une base de modèles BDmod pour les mobiles du réseau à l'aide des numéros TAC extraits des numéros IMEI des mobiles confirmés. d- On renseigne cette base de modèles BDmod en déterminant les pro-fils P1, P2 compatibles avec les codes TAC de la base BDmod en utilisant l'information relative aux profils Pl, P2 envoyés initialement aux mobiles confirmés dont le numéro IMSI et par suite, le code TAC est associé aux profils P1, P2 (Px). e- On établit par différence un fichier F1 des mobiles non confirmés à partir du fichier de tous les mobiles du réseau et du fichier des mobiles confirmés ; ce fichier destiné à un envoi en masse peut comporter l'ensemble des mobiles non confirmés ou seulement une partie de ceux-ci. f- Dans cette étape, on fait un envoi en masse aux mobiles du fichier F1 en utilisant un premier profil P1. Cet envoi en masse est fait par le serveur OTA-GPRS en utilisant une suite de messages SMS. g- On analyse le trafic des mobiles objets de cet envoi en masse pour ex- traire les mobiles ayant un trafic de messages MMS. Ces mobiles sont considérés comme confirmés. En procédant comme ci-dessus, on recherche le numéro IMEI pour en extraire le code TAC et renseigner les bases de données BDIMEI pour inscrire les paires IMSCl/IMEI associées à ces mobiles qui viennent d'être confirmés. On renseigne égale- ment la base de modèles BDmod pour y inscrire les numéros TAC des modèles qui viennent d'être confirmés et le profil P1 associé à ces modèles. h- Comme ce premier envoi n'a probablement pas réussi pour tous les mobiles destinataires, on établit un nouveau fichier F2 pour un envoi de masse à destination de ces mobiles restants, mobiles non confirmés. Il est à remarquer que les fichiers F1 et F2 contiennent les mêmes données sous une présentation différente. On leur adresse alors un autre profil, c'est-à-dire le second profil le plus fréquent P2. i- Puis, on analyse le résultat de cet envoi par l'examen du trafic des mo- biles correspondant à ce second fichier d'envoi en masse. j- On met à jour les banques de données BDIMEI et BDmod pour déterminer les mobiles non confirmés et on répète l'envoi en masse avec un autre profil Px. A la suite de cet envoi, on peut répéter l'analyse. Enfin, on répète périodiquement l'opération en déterminant les mobiles non confirmés pour établir un fichier Fj qui correspond à de nouveaux mobiles entrant dans le réseau. L'opération se répète par l'envoi du pro-fil Pl, l'analyse du trafic à la suite de cet envoi, la détermination des mobiles restants, non confirmés, pour effectués un nouvel envoi avec le profil P2 et ainsi de suite. De telles opérations cycliques, de nature stochastique, per-mettent de compléter progressivement les bases de données du réseau et de pouvoir mettre à jour automatiquement les nouveaux mobiles entrant dans le réseau si le modèle du mobile correspond à un modèle déjà conte-nu dans la base de données. Dans le cas contraire, les opérations se ré-pètent avec l'essai du profil P1 puis du profil P2 et éventuellement du profil Px. io Le principe de ce procédé est la création d'une boucle de contrôle automatique entre les essais de chargement avec un type arbitraire OMA ou NE, encore indéterminé, et le trafic du service des données effectivement généré par les mobiles. Si un mobile est capable d'utiliser le mode données , cela signifie le profil est correct (ainsi que tous les mobi-15 les du même modèle). Sinon, on utilise l'autre type et on recommence le chargement. Et on attend que du trafic soit observé pour un mobile de ce modèle. La figure 2 montre schématiquement l'organisation du système selon l'invention. Ce système intégré dans le centre SMSC comprend 20 une base de modèles BDmod, une base BDIMEI de paires IMSI/IMEI et une base de profils GPRS associés au serveur OTA-GPRS. Dans ce système, on a le fichier d'envoi en masse. Le fichier d'envoi en masse est fourni au serveur OTA-GPRS qui fait l'envoi en masse avec un premier profil puis un second profil et éventuellement d'autres 25 profils extraits de la base BD Profils GPRS. Le détail de l'établissement de la base de données BDIMEI sera expliqué ci-après à l'aide de la figure 3. La base BDIMEI est constituée au moins initialement et/ou partiellement selon un premier procédé, par traitement des tickets de 30 facturation du réseau ; ces tickets comprennent les numéros IMSI et IMEI des mobiles du réseau. Il existe des variantes pour constituer de manière dynamique cette base de données comme illustré par la figure 3 dans les cas suivants : 35 1) Le système est chargé de la fonction EIR qui permet de bloquer les mobiles volés. Quand un mobile B émet un SMS-MO (avec son numéro MSISDN), le centre SMSC (qui a la fonction EIR) a reçu une requête MAP_CHECK_IMEI qui contient le numéro IMEI, et on peut l'appairer avec le numéro IMSI qui peut être obtenu (Etape obtenir l'IMSI à partir du MSISDN B ) en interrogeant le registre HLR avec le numéro MSISDN du mobile émetteur du message SMS-MO. 2) Le réseau implémente la requête MAP_OBTAIN_IMEI, en recevant un message SMS, le centre SMSC peut interroger le centre MSC/VLR visité par le mobile pour obtenir son numéro IMEI. Comme précédemment, avec le numéro MSISDN de l'émetteur, on interroge le registre HLR pour obtenir son numéro IMSI. 3) Le réseau a des fonctions spéciales étendant les fonctions spéciales du registre HLR, c'est le cas des registres HLR de marque Ericsson : chaque fois qu'un abonné change de mobile (donc la première fois aussi), le registre HLR envoie le numéro IMEI dans une requète MAP_Add_IMEI; comme dans les deux cas précédents, on reçoit un message SMS-MO après (avec le numéro MSISDN B) et l'interrogation du registre HLR permet d'obtenir le numéro IMSI. Cela fonctionne comme pour le cas MAP_CHECK_IMEI mais seulement à chaque changement de téléphone, donc économise du trafic sur le réseau. 4) Un outil SIM Tool Kit(STK) est prévu dans la carte SIM des mobiles : la situation est voisine de la précédente, mais c'est la carte SIM qui détecte un changement de mobile et envoie le nouvel IMEI par un SMS-MO au SMSC. 5) On peut également exploiter les tickets de facturation qui comprennent IMSI et IMEI. La figure 4 est un autre schéma synoptique du système se- lon l'invention, montrant la boucle de détermination du type de profil pour une détermination automatique et stochastique des types de profils. Le système de la figure 2 constitue le système de charge-ment du profil de personnalisation d'un mobile, à condition que son type soit OMA ou NE.

Il comporte trois Bases de Données: - BDIMEI, permet d'obtenir l'IMEI d'un téléphone donné en fonction de l'IMSI de l'utilisateur, - BDModèles de Téléphone, permet à partir du TAC d'un téléphone, d'obtenir son type de téléphone OMA ou N-E, - BDProfil GPRS, permet d'obtenir la liste (2 à 5 en général) des profils correctement formatés pour un type de téléphone. Ces profils sont typiquement l'accès MMS, les services WAP, un portail Internet particulier.

Avec ces trois bases de données, et avec l'IMSI, on obtient de BDIMEI son IMEI, on extrait les 6 premiers chiffres pour avoir le TAC. On obtient le type de téléphone (soit OMA, soit N-E) avec BD Modèles de Téléphone. Puis avec celui-ci on accède à la base BD Profils GPRS pour avoir la liste des profils. Et les profils sont envoyés avec des SMS-MT (en remarquant qu'à l'étape 3 (2) c'est le MSISDN B du mobile destinataire qui est utilisé pour obtenir classiquement l'information de routage (dont l'IMSI) du HLR. BD Profils GPRS est constituée à l'étape 0, par l'exploitant du système en fonction des paramètres de son réseau. Deux exemples à la figure 5 montrent la différence, pour un même réseau entre un profil OMA et un profil N-E pour la fonction accès MMS . On voit qu'ils sont différents. Le fonctionnement des ces différentes méthodes nécessite, ce qui est le cas de l'invention, que le Serveur OTA-GPRS soit intégré avec le SMSC et que la fonction EIR soit intégrée aussi, si on veut déterminer automatiquement la paire IMSI-IMEI avec la variante 1) Grâce à la figure 4, on décrit le fonctionnement principal de l'invention qui va permettre de déterminer automatiquement le type de profil de personnalisation GPRS et constituer une base de données fiable et réutilisable. Au début le type de profil , dans la base BDmod de télé-phone est dans l'état OMA car c'est le plus fréquent et non confirmé. Le chargement d'un profil vers un mobile B se fait (1) selon la description précédente et la figure 1. Mais le type de profil d'un modèle de téléphone n'est pas forcément exact. Dans ce cas, on n'observera aucun trafic GPRS , soit aucun MMS émis par le mobile ni trafic GPRS. Or quand le mobile envoie (2) un MMS vers un autre abonné A , le MMSC envoie un SMS de Notification MMS vers A grâce à une liaison avec le SMSC. Ce SMS, suivant la réalisation du MMSC, contient ou non dans le champ prévu à cet effet, le MSISDN B comme origine du SMS (cela s'affichera sur le mobile A). La première méthode extrait l'adresse MSISDN B dans le champ origine du SMS . C'est le cas le plus habituel (3) et le plus simple. Le SMS-MT est de type SMS-DELIVER ; il contient dans le champ TP-originating-address (TP-OA) , l'adresse du mobile d'origine. On l'obtient donc sans avoir besoin d'analyser la couche de protocole WAP encapsulé dans le protocole SMS.

S'il ne contient pas (adresse d'origine commune de type Alphanumérique ou adresse vide), le système est cependant capable d'extraire l'adresse d'origine à partir du champ TP-User-Data (TP-UD) qui contient un message du protocole WAP du type Message Notification . Le système décode alors le protocole WAP qui est donc une couche plus in-terne. La figure 7 illustre ceci et contient l'adresse d'origine dans un champ standardisé du Message Notification appelé Form dans le document 2 alors que, au niveau du protocole SMS, on avait seulement VivaCell dans TP-originating-Address , ce qui ne permet pas de savoir le mobile précis émetteur du MMS. Le système extrait alors MSISDN B suivant cette deuxième méthode (+37493600666 dans l'exemple). Le SMSC (3a) envoie MSISDN B vers un module détermination du type de profil interne au système. Celui-ci envoie une requête (3b) vers le registre HLR pour déterminer l'IMSI B de l'émetteur du MMS-MO. Avec l'IMSI B, il peut (3c) chercher l'IMEI dans BDIMEI et extraire le TAC. Avec celui-ci il peut alors mettre à jour BDmod de télé- phone avec pour ce TAC confirmé. En effet, le mobile B a crée du trafic GPRS donc le type de profil utilisé pour sa personnalisation est exact. (3') constitue une variante si le MMSC n'était pas capable (ce qui constitue une anomalie) de fournir l'origine MSISDN dans le MMS de notification. On utilise les tickets de facturation GPRS. Pour tous les IMSI trouvés, on peut obtenir l'IMEI dans BDIMEI, extraire le TAC et mettre à jour BDmod de téléphone avec pour ce TAC confirmé. Au bout d'un certain temps de fonctionnement, un grand nombre de TAC sont confirmés. On fait alors un nouveau chargement de profils pour cela: On extrait tous les TAC non confirmés de BDmod de télé-phone, On les laisse non confirmé mais on inverse le type de profil (N-E si c'était OMA, OMA si c'était N-E) On crée un fichier d'envoi en masse vers tous les abonnés 35 ayant des modèles de téléphone avec des TAC non confirmés et on télé-charge leurs profils GPRS.

La suite d'opérations 1) (le chargement initial non confirmé de Profil GPRS), 2), 3), 3a), 4) et un nouveau chargement constitue une boucle. Le processus continue sur une certaine période et converge au bout d'une certaine période d'où le titre de détermination automatique et stochastique quand le pourcentage de TAC non confirmés est inférieur à un seuil. Comme de nouveaux modèles de téléphone sont introduits il faut régulièrement refaire l'envoi en masse. Cependant, une fois un Type de profil mis à confirmé cela ne changera pas.

Evaluation quantitative de la convergence du système Soit N le nombre d'accès GPRS moyen/jour/abonné estimons: Probabilité 0 accès GPRS pendant 1 heure: (1 - N/24) donc : Probabilité 0 accès pendant 24 heures: (1-N/24)24 et pendant J jours (1- N/24)24xJ et s'il y a M abonnés ayant ce même modèle, Probabilité qu'aucun des M abonnés avec ce modèle de téléphone ne fasse d'accès GPRS pendant J jours: (1- N/24)24xJxM On peut donc tracer sur la figure 6 un abaque en J et M pour différentes valeurs 0,90, 0,95, 0,99 de la probabilité que au moins un des abonnés de la population est fait un accès, et pour N fixé, soit la fonction (J,M) : (1-N/24)24xJxM = 1 - P Si on prend N = 0,2 GPRS/jour , avec P = 0,99 (une quasi certitude ) et une population de 10 mobiles du même type, on trouve J = 2,29 jours pour être certain, si on n'a pas eu de trafic GPRS, qu'on peut inverser le type de profil et faire un nouveau chargement. Le critère d'arrêt est que pour tous les modèles, en nombres m;, existant dans le parc d'abonnés, on ait P = 0,99 depuis la dernière mise à jour. L'exploitant de l'invention adoptera donc un rythme de mise à jour des chargements de profil en fonction de son trafic moyen N. La convergence n'est pas finie après le 2ème chargement de profil (qui a inversé les types de profil qui sont restés muets), car d'autres modèles apparaissent et le système doit continuer pour assurer le char- 20 25 30 gement des profils GPRS des nouveaux abonnés avec de nouveaux télé-phones. Mais le nombre de chargements nécessaires deviendra modéré. Généralisation Le système de l'invention se généralise au cas où il y aurait 5 plus de deux types de profil (des variantes ou des réalisations propriétaires) que seulement OMA et Nokia-Ericsson. Notons p le nombre total Soient ci, c2,

., cp le coût (par exemple en nombre de SMS) d'un essai de chargement du type de profil #i vers les modèles non confirmés (nombre 10 total M) . Ces coûts sont différents car certains nécessitent plus de SMS que d'autres (voir exemple de la figure 5, le profil OMA nécessite 5 SMS et le profil N-E en nécessite 2) Soient ql, q2, .., qp la probabilité a priori de ces différents types profil (résultant de chiffres d'étude de marché) . 15 Soient j l, j2, ..., jp l'indice réordonné tel que, qi/cjl > qp/q2 >

.> gjp/CJp (on trie les quantités qi/ci par ordre décroissant), un théorème de Recherche Opérationnelle dit que l'ordre optimal d'essai des p types de profil est il ,i2, ••, Jp pour minimiser l'espérance mathématique du coût total en nombre de SMS des essais de chargement de profils jusqu'à convergence (ce n'est pas la même chose, mais plus optimal d'un point de vue opérationnelle, que le nombre total de chargements). Par exemple, s'il n'y a que 2 profils et que goura= 0,65 et qne=0,35,ona 0,35/2sms > 0,65/ 5sms (0,175 > 0,13) et il faut commencer par les profils N-E (ce qui n'est pas intuitif, car ils sont moins fréquents). On peut ainsi vérifier qu'on a en moyenne: 2 + 0,65 x 5 = 5,25 SMS par abonné avec la politique N-E puis OMA, + 0,35 x 2 = 5,70 SMS par abonné avec la politique OMA puis N-E (moins bon) La démonstration générale pour p > 2 fait appel à la pro-35 grammation linéaire avec une matrice p x p! mais la démonstration pour p = 2 est élémentaire. En effet, si et+g2c2<c2+glcl,avec gl+q2= 1,..DTD: 17

(politique 1 puis 2 meilleure que 2 puis 1), cl(1 ù q1) < c2(1-q2), soit clg2 < c2gl, ce qui donne bien gl/cl > q2/c2 comme condition que l'ordre 1 puis 2 donne un nombre moyen de SMS inférieur. io 5 25 30 35 GLOSSAIRE et ABBREVIATIONS UTILISEES HLR Home Location Register Registre de Localisation Principal d'un abonné de mobile IMEI (International Mobile Equipment Identity): Numéro unique de série identifiant tous les mobiles. Les 6 premiers chiffres sont le TAC qui identifie un modèle particulier

10 IMSI (International Mobile Subscriber Identity) : Numérotation interne (15 chiffres en général) aux réseaux de mobiles avec des codes pays différents (208 pour France au lieu de 33) de celui des numéros connus.

MSC/VLR : Message Switching Centre/Visited Location Register, le corn-15 mutateur mobile et sa base de données visitée par le mobile B (figure 3)

MMSC: Multimedia Messaging System, l'équivalent d'un SMSC pour les messages multimedias (photos, etc..)

20 MMS-MO: Message Multimédia généré par un mobile.

MSISDN (Mobile Subscriber International Number) : Numéro connu du mobile connu du monde extérieur à son réseau. Ils commencent par un code pays grand public (33 pour la France)

SIM: Subscriber Identity Module : carte insérée dans un mobile et qui a les données d'abonnement, qui sont donc gardées si on change le télé-phone lui-même (ainsi que la mémoire du dernier modèle pour détecter un changement)

SMSC: Centre de Messages Courts (Short Message Service) qui reçoit des SMS et en envoie

SMS-MO: message SMS envoyé par un mobile vers un centre SMSC SMS-MT : message SMS envoyé par un centre SMSC vers un mobile.

STK : SIM Tool Kit : programme chargé dans la carte SIM et capable notamment de détecter un changement de modèle de téléphone (la carte a une mémoire qui garde le dernier modèle TAC: Type Allocation Code, code en général de 6 chiffres (les premiers de l'IMEI) caractérisant un modèle de téléphone mobile

WAP : Wireless Access Protocol. Il décrit notamment le codage détaillé du "Message Notification" qui peut permettre d'en extraire le numéro du mobile qui a envoyé le MMS

Claims (5)

REVENDICATIONS

1 °) Système de gestion des profils intégrés dans les mobiles d'un réseau de téléphonie mobile d'un opérateur, système de gestion caractérisé en ce qu' a- on analyse le trafic des mobiles du réseau, b- on établit une base de données (BDIMEI) avec les paires de numéros (IMSI/IMEI) des mobiles, c-on établit une base de modèles de mobiles (BDmod) des mobiles du ré-seau par les numéros (TAC) extraits des numéros (IMEI), d- on renseigne la base des modèles (BDmod) en déterminant les profils (P1, P2) compatibles avec les numéros (TAC) de la base (BDmod), e- on établit un fichier des mobiles non confirmés (c'est-à-dire dont on n'a pas pu savoir s'ils contiennent le bon profil) en prenant dans l'ensemble des mobiles du réseau ceux (ou une partie de ceux-ci) au-15 tres que ceux confirmés, f- on fait un envoi de masse aux mobiles de ce fichier avec un premier profil (P1), g- on analyse le trafic des mobiles objet de cet envoi en masse, pour en extraire les mobiles ayant un trafic MMS, considérés alors comme mo- 20 biles confirmés, pour obtenir leur numéro (TAC) et renseigner les bases de données (BDmod et BDIMEI), h- on répète l'envoi en masse vers les autres mobiles non confirmés en leur adressant un autre profil (P2), i- on répète éventuellement l'envoi en masse pour les mobiles non con-25 firmés après ce nouvel envoi, j- on répète l'envoi en masse d'un profil à une périodicité dépendant de la fréquence de l'arrivée de nouveaux mobiles dans le réseau.

2°) Système selon la revendication 1, 30 caractérisé en ce qu' on construit la base (BDIMEI) par l'analyse des fichiers de facturation du réseau dont on extrait les paires de numéros (IMSI/IMEI).

3°) Système selon la revendication 1, 35 caractérisé en ce qu' - on construit la fonction EIR qui, à l'émission d'un SMO par un mobile, reçoit une requête MAP_CHECK_IMEI contenant le numéro IMEI qu'il peut appairer avec le numéro IMSI à partir du numéro MSISDN en interrogeant le registre HRL avec ce numéro du mobile émetteur, - en implémentant la requête MAP_OBTAIN_IMEI en recevant un mes-sage SMS et en interrogeant le centre MSC/VLR, visité par le mobile pour obtenir son numéro IMEI et ensuite obtenir, à partir du numéro MSISDN, le numéro IMSI e interrogeant le registre HLR, - par une fonction du registre HLR qui envoie le numéro IMEI dans une requête MAP_Add_IMEI suivie d'une interrogation du registre HLR pour obtenir le numéro IMSI, - avec un outil SIM Tool Kit (STK) de la carte SIM du mobile qui envoie le nouveau numéro IMEI par un message SMS au centre SMSC.

4°) Système selon la revendication 1, caractérisé en ce qu' il comporte un serveur (OTA-GPRS) intégré au SMSC pour s'adresser aux mobiles du réseau et mettre à jour leur profil.

5°) Système selon la revendication 1, caractérisé en ce qu' il détermine automatiquement le type de profil en utilisant en retour des messages SMS de notification MMS envoyés à la fonction MMS et capables de décoder le protocole SMS et les messages WAP contenus, soit en l'extrayant du champ TP-originating-addresse dans le SMS de type SMS-DELIVER, ou en décodant selon le protocole WAP le champ From dans le message de notification codé suivant le standard WAP et contenu dans la partie TP-User-Data du message SMS-DELIVER.30