FR2954038A1 - Gestion d'itinerance en mode paquet dans un reseau de radiocommunication - Google Patents

Abstract

L'invention concerne un procédé de gestion d'itinérance en mode paquet dans un réseau de radiocommunication cellulaire, comprenant, lors de la migration d'un équipement d'utilisateur (UE) d'une première cellule (1) gérée par un premier serveur SGSN (SGSN1) vers une seconde cellule (2) gérée par un second serveur SGSN (SGSN2), ledit équipement d'utilisateur (UE) ayant préalablement établi un contexte PDP dans ladite première cellule (1), une étape au cours de laquelle l'équipement d'utilisateur (UE) émet, à destination dudit second serveur (SGSN2), une requête de mise à jour de zone de routage (RAU) paramétrée par l'identifiant de zone de la première cellule (1) au niveau du réseau d'accès (LAI/RAI-air), caractérisé en ce qu'il comprend ensuite les étapes suivantes : a) le second serveur (SGSN2) obtient l'adresse IP d'un serveur, dit "SGSN-mandataire", qui est relié à une passerelle HNB Gateway et qui est déclaré en tant que SGSN coopératif vis-à-vis des SGSN du réseau cœur (CN) ; b) le second serveur (SGSN2) envoie audit serveur SGSN-mandataire une requête d'interrogation paramétrée par un identifiant (P-TMSI) de l'équipement d'utilisateur (UE), et par ledit identifiant de zone de la première cellule (1) au niveau du réseau d'accès (LAI/RAI-air) ; c) le serveur SGSN-mandataire exécute une traduction entre l'identifiant de zone de la première cellule (1) au niveau du réseau d'accès (LAI/RAI-air) et l'identifiant de zone de la première cellule (1) au niveau du cœur de réseau (LAI/RAI-land) ; d) le SGSN-mandataire envoie au second serveur (SGSN2) ledit l'identifiant de zone (LAI/RAI-land) au niveau du cœur de réseau ; e) le second serveur (SGSN2) envoie au SGSN-mandataire une requête de contexte PDP paramétrée par l'identifiant de zone (LAI/RAI-land) au niveau du cœur de réseau ; et f) le second serveur (SGSN2) reçoit de la part du SGSN-mandataire ledit contexte PDP de l'équipement d'utilisateur (UE).

Description

GESTION D'ITINERANCE EN MODE PAQUET DANS UN RESEAU DE RADIOCOMMUNICATION L'invention concerne, de manière générale, le domaine des télécommunications et se rapporte plus particulièrement à un procédé de gestion d'itinérance en mode paquet dans un réseau de radiocommunication cellulaire. L'invention s'applique notamment aux réseaux cellulaires utilisant la technologie GPRS ou la technologie UMTS, telles que définies notamment dans les normes 23.002, 23.003 et 29.060 du projet 3GPP ("Third-Generation Partnership Project"). Elle s'applique en particulier aux architectures dites "Femto NodeB" (également appelées "Femto 3G") telles que définies dans le document TR 25.820 V8.2.0 (2008-09) du 3GPP, dans lesquelles des mini-stations de base permettent de déployer un réseau mobile domestique à faible coût en utilisant l'infrastructure haut-débit déjà présente chez l'abonné. Le GPRS ("General Packet Radio Service") est une norme pour la téléphonie mobile dérivée du GSM ("Global System for Mobile Communications") et permettant un débit de données plus élevé. Cette norme est définie dans la version 97 et les versions ultérieures de la norme GSM. On le qualifie souvent de "2,5G" : le "G" est l'abréviation de génération, et le "2,5" indique que c'est une technologie à mi-chemin entre le GSM (2e génération) et l'UMTS (3e génération). Le GPRS est une extension du protocole GSM : il ajoute, par rapport au mode de transmission "CS" (initiales des mots anglais "circuit-switched" signifiant "commutation par circuit"), qui comprend tous les services liés à la téléphonie, le mode de transmission "PS" (initiales des mots anglais "packet-switched", signifiant "commutation par paquets"). Plus précisément, dans le mode CS, les ressources requises sont allouées pour toute la durée de la connexion, qu'il y ait des données à transmettre ou pas ; en revanche, le GPRS permet de fournir à une station mobile une connectivité IP ("Internet Protocof') disponible en permanence, mais dans laquelle les ressources radio sont allouées uniquement quand des données doivent être transférées. Les utilisateurs bénéficient ainsi d'un accès bon marché au réseau, et les opérateurs réseau économisent de la ressource radio. De plus, aucun délai de numérotation n'est nécessaire. Le GPRS utilise un protocole de signalisation appelé "GMM" (initiales des mots anglais "GPRS Mobility Management" signifiant "Gestion de la Mobilité GPRS") pour gérer les questions relatives à la mobilité telles que l'itinérance, l'authentification, et le choix d'un algorithme de chiffrement. La norme UMTS ("Universal Mobile Telecommunications System") spécifie un nouveau support de transmission de données en mode paquet, qui permet notamment d'offrir aux abonnés d'un opérateur mobile un accès à des services utilisant le protocole IP (tels que la messagerie électronique, le téléchargement de fichiers, la consultation de sites Web ou WAP). L'UMTS utilise la technologie W-CDMA, normalisée par le 3GPP, et constitue la mise en oeuvre européenne des spécifications IMT-2000 de l'UIT ("Union Internationale des Communications") pour les systèmes radio cellulaires 3G. Grâce à l'UMTS, des données contenues dans des paquets IP peuvent être échangées entre, d'une part, des serveurs appartenant à un réseau extérieur au réseau UMTS tel que le réseau Internet, et d'autre part un réseau GSM. En termes d'architecture, le réseau UMTS est subdivisé en deux sous-réseaux, le réseau d'accès radio dit "terrestre" UTRAN ("UMTS Terrestrial Radio Access Network" en anglais), et le réseau coeur CN ("Core Network" en anglais), tels que représentés sur la figure 1. Le réseau UTRAN comprend une pluralité de stations radio de base, appelées "NodeB", qui sont destinées à communiquer avec des dispositifs d'abonnés UE ("User Equipment') au moyen de ressources radio allouées par un RNC (initiales des mots anglais "Radio Network Controller" signifiant "Contrôleur des Ressources Radio"). Le RNC joue dans les réseaux UMTS un rôle équivalent à celui joué par les BSC (initiales des mots anglais "Base Station Controller" signifiant "Contrôleur de Stations de Base) dans les réseaux GSM : le RNC contrôle les NodeB en leur allouant les ressources UTRAN et CN disponibles, et en leur fournissant des informations à diffuser au sein de leurs cellules. Le RNC sert d'intermédiaire entre les NodeB et le CN ; il communique avec le CN, pour le trafic de données et la signalisation CS et PS, à travers des interfaces appelées "lu" (respectivement, "lu-CS" et "lu-PS"). Dans le cas particulier des réseaux Femto NodeB, en outre, des HNB ("Home NodeB") situés dans des réseaux privés (par exemple des réseaux domestiques) combinent chacun les fonctions de NodeB et de RNC. Chaque HNB est relié à une passerelle ("HNB Gateway") située à l'extérieur du réseau privé dans le réseau d'accès radio de l'opérateur ; la HNB Gateway gère le HNB et le trafic des abonnés, et sert d'intermédiaire avec le réseau coeur CN via des interfaces lu-CS et lu-PS. On notera que les réseaux GSM comprennent eux aussi des passerelles HNB Gateway dotées de fonctionnalités analogues.

Le réseau UTRAN doit être capable de répartir l'intégralité de ses ressources (à savoir les ressources radio, les ressources de transport et la capacité de traitement) entre les différents utilisateurs du système, à partir des paramètres de priorité envoyés par le réseau coeur CN. Le réseau coeur CN des architectures GSM et UMTS héberge un serveur HLR (initiales des mots anglais "Home Location Register" signifiant "Registre de Localisation Nominal"), qui est une base de données commune aux domaines CS et PS et dans laquelle sont stockées les informations relatives à chaque abonné de l'opérateur du réseau, telles que le numéro d'appel de l'abonné, l'identité du mobile et des informations relatives à l'abonnement. Le HLR contient également des informations de qualité de service liées aux abonnés et aux services. C'est donc à partir de cette base de données que s'effectue la gestion des abonnés mobiles au sein du réseau. Le réseau coeur CN des architectures GSM et UMTS héberge également des commutateurs de circuits MSC (initiales des mots anglais "Mobile Switching Center'' signifiant "Centre de Commutation Mobile") et des commutateurs de paquets SGSN (initiales des mots anglais "Serving GPRS Support Node" signifiant "Noeud de Service pour le Support du GPRS"). Ces noeuds de service du réseau coeur assurent la gestion du lien de communication avec le réseau d'accès. Ils stockent le profil de l'abonné issu du HLR après l'enregistrement de l'équipement UE de l'abonné auprès du réseau, et effectuent un contrôle des ressources réseaux demandées par l'abonné. Concernant le domaine circuit, le MSC est associé à un autre noeud de service, à savoir le GMSC ("Gateway Mobile Switching Center") (non représenté sur la figure 1), qui sert de passerelle vers des réseaux fixes tels que le RTC (Réseau Téléphonique Commuté) ou le RNIS (Réseau Numérique à Intégration de Services). Concernant le domaine paquet, le SGSN gère l'itinérance, l'authentification et le chiffrement. Il est associé à un autre noeud de service, le GGSN ("Gateway GPRS Support Node") (non représenté sur la figure 1), qui sert de passerelle vers les réseaux à commutation de paquets extérieurs, notamment le réseau Internet. Le réseau coeur UMTS, en ce qui concerne le domaine paquet, est donc connecté avec l'extérieur via le GGSN, qui contient les informations de routage permettant au mobile de communiquer avec un réseau externe. Le SGSN et le GGSN intègrent des fonctions de routeur IP. Lorsque le GGSN et le SGSN sont situés dans des réseaux différents, ils sont habituellement interconnectés via une interface appelée 30 "Gp", qui comprend des fonctions de sécurité.

Lorsqu'un abonné souhaite accéder à un service PS, son UE doit tout d'abord s'attacher au réseau. Dans la norme GPRS, la procédure correspondante, qui fait partie du protocole de signalisation GMM mentionné ci-dessus, est appelée "GPRS Attach". Elle permet d'établir un lien logique entre l'UE et le serveur SGSN. Selon cette procédure : - l'UE envoie au réseau une requête d'attachement, qui contient le TMSI (initiales des mots anglais "Temporary Mobile Subscriber ldentity'' signifiant "Identité Temporaire de Mobile d'Abonné") précédemment attribué à l'UE au sein de ce réseau ; - cette requête d'attachement est transmise au SGSN ; - le SGSN vérifie l'authenticité de l'UE en envoyant une requête d'authentification au HLR ; - si l'authentification est positive, le profil de l'abonné est transféré du HLR au SGSN, ce profil contenant en particulier l'adresse du GGSN qui sert de passerelle avec le réseau PDN (initiales des mots anglais "Packet Data Network" signifiant "Réseau de Données en Paquets") de l'opérateur de télécommunications ; et - le SGSN confirme à l'UE que ce dernier est dorénavant attaché au réseau.

Pour pouvoir accéder au réseau PDN, l'UE doit ensuite demander au SGSN d'ouvrir un "contexte" de protocole en mode paquet PDP (pour "Packet Data Protocof') ; ce contexte permettra à l'UE de réserver des ressources dans le réseau coeur pour l'exécution du service souhaité par l'abonné. Le SGSN s'adresse alors au GGSN afin d'obtenir une adresse IP de la part du PDN, et établit ensuite une connexion IP entre l'UE et le PDN au moyen d'un protocole de tunnel GTP (pour "GPRS Tunneling Protocof') entre le SGSN et le GGSN. Le contexte PDP contient le logis et le mot de passe de l'abonné, ainsi que des informations de niveau de QoS (initiales des mots anglais "Quality of Service" signifiant "Qualité de Service"). Lors de l'activation d'un contexte PDP, les différents noeuds du réseau UMTS reçoivent les informations de QoS liées au contexte PDP demandé et à la souscription de l'abonné. La localisation d'un UE ainsi identifié dans un réseau de télécommunications mobile est effectuée sur la base d'une information de localisation LAI (initiales des mots anglais "Location Area Identifier" signifiant "Identifiant de Zone de Localisation"), telle que définie dans les documents 3GPP TS 23.002 et TS 23.003. Cette information est composée d'un code de pays MCC (pour "Mobile Country Code" en anglais) et d'un code de réseau mobile MNC (pour "Mobile Network Code" en anglais), ainsi que d'un code de zone de localisation LAC (pour "Location Area Code" en anglais) attribué à une cellule ou à un groupe de cellules au sein du réseau identifié. Les identifiants MCC et MNC forment un identifiant de réseau PLMN (pour "Public Land Mobile Network'), qui identifie le réseau mobile d'un opérateur pour un pays. Une zone de localisation peut donc correspondre à une zone géographique couverte par plusieurs cellules, et sert à gérer la mobilité d'un UE. Dans un réseau de type UMTS, le paramètre LAI peut être également utilisé pour le contrôle d'accès, notamment dans le contexte d'itinérance (ou "roaming" en anglais), de façon à interdire certains changements de réseau, par exemple interdire le passage d'un réseau 2G à un réseau 3G. Dans le cadre du GSM, on utilise une information de localisation analogue, appelée "RAI" (initiales des mots anglais "Routing Area Identifier" signifiant "Identifiant de Zone de Routage"). Cette information est diffusée dans la zone de routage par le réseau à l'attention des UE. Lorsqu'un UE change de zone de routage, il doit en aviser le réseau. On notera qu'il est très complexe d'offrir un service de localisation efficace dans un réseau "hybride" qui offre à la fois une couverture radio dans des cellules radio classiques (qui sont appelées de manière générale des cellules "Macro" dans le cadre de la présente invention) d'un réseau de type GSM ou Macro NodeB UMTS, et une couverture radio dans des cellules radio (qui sont appelées de manière générale des cellules "privées" dans le cadre de la présente invention) de type Home NodeB UMTS, ou Wi-Fi selon la norme IEEE (pour "Institute of Electrical and Electronics Engineers" en anglais) 802.11, ou encore de type Bluetooth. En effet, dans le réseau GSM ou dans le réseau Macro NodeB UMTS, la localisation d'un terminal d'un abonné peut être correctement gérée au moyen du serveur HLR. Les réseaux radio de type GSM ou Macro NodeB UMTS sont des réseaux dont le déploiement, et donc la position géographique des différents équipements du réseau, ont été soigneusement planifiés par un opérateur de télécommunications ; une telle planification concerne notamment l'allocation préalable de valeurs à des paramètres de localisation, tels que les LAI/RAI (selon qu'on considère, respectivement, un réseau de type UMTS ou de type GSM) mentionnés ci-dessus. En revanche, lorsque le terminal entre dans une zone de couverture radio de type Home NodeB, Wi-Fi ou Bluetooth, sa localisation est perdue puisque l'architecture réseau de type UMTS ou GSM n'est pas adaptée pour localiser un terminal situé dans une telle zone dans la mesure où les points d'accès de type Home NodeB ou Wi-Fi ne peuvent être localisés comme peuvent l'être les stations de base de type GSM ou Macro NodeB UMTS. Pour des raisons similaires, il est très complexe de mettre en place 25 un service de contrôle d'accès dans une zone de couverture radio de type Home NodeB ou Wi-Fi. En outre, dans le cas des réseaux de type Home NodeB, on constate le problème suivant : comme deux points d'accès (en anglais "Access Points" ou AP) voisins doivent posséder des LAI/RAI différents, il 30 faut prévoir un grand nombre de zones de localisation/routage ; mais au niveau du coeur de réseau CN, les serveurs MSC et SGSN ne peuvent traiter qu'un nombre assez limité de LAI/RAI. Pour résoudre ce problème, il a été proposé un mécanisme de traduction entre un paramètre "LAI/RAI-land" au niveau CN et un paramètre "LAI/RAI-air" au niveau réseau d'accès. Ce mécanisme est similaire au mécanisme "NAT" (initiales des mots anglais "Network Address Translator" signifiant "Traducteur d'Adresse Réseau") utilisé pour les adresses IP privées et publiques. Toutefois, les auteurs de la présente invention ont réalisé que ce mécanisme présente, dans le cas où un terminal migre d'une zone privée vers une zone Macro, et émet en conséquence une requête de mise à jour de zone de routage RAU (pour "Routing Area Update") dans la cellule Macro, les inconvénients suivants : - le serveur MSC considère (à tort) qu'il s'agit d'un transfert d'un MSC à un autre MSC, et émet une requête de numéro IMSI (I'IMSI, initiales des mots anglais "International Mobile Subscriber Identity", est un identifiant privé utilisé par le réseau pour identifier un terminal) ; et - le serveur SGSN rejette la requête de mise à jour de zone de routage, de sorte que, au cas où il existe un contexte PDP actif pour le terminal, ce contexte est perdu. Le deuxième inconvénient précité peut avoir des conséquences graves, vu que la perte de connexion en mode PS peut entraîner, par exemple, le défaut de réception d'appels ou d'emails entrants, et ce, jusqu'à l'établissement d'un nouveau contexte PDP dans la cellule Macro.

La présente invention concerne donc un procédé de gestion d'itinérance en mode paquet dans un réseau de radiocommunication cellulaire, comprenant, lors de la migration d'un équipement d'utilisateur d'une première cellule gérée par un premier serveur SGSN vers une seconde cellule gérée par un second serveur SGSN, ledit équipement d'utilisateur ayant préalablement établi un contexte PDP dans ladite première cellule, une étape au cours de laquelle l'équipement d'utilisateur émet, à destination dudit second serveur, une requête de mise à jour de zone de routage paramétrée par l'identifiant de zone de la première cellule au niveau du réseau d'accès. Ledit procédé est remarquable en ce qu'il comprend ensuite les étapes suivantes : a) le second serveur obtient l'adresse IP d'un serveur, dit "SGSN-mandataire", qui est relié à une passerelle HNB Gateway et qui est déclaré en tant que SGSN coopératif vis-à-vis des SGSN du réseau coeur; b) le second serveur envoie audit serveur SGSN-mandataire une requête d'interrogation paramétrée par un identifiant de l'équipement d'utilisateur, et par ledit identifiant de zone de la première cellule au niveau du réseau d'accès ; c) le serveur SGSN-mandataire exécute une traduction entre l'identifiant de zone de la première cellule au niveau du réseau d'accès et l'identifiant de zone de la première cellule au niveau du coeur de réseau ; d) le SGSN-mandataire envoie au second serveur ledit l'identifiant de zone au niveau du coeur de réseau ; e) le second serveur envoie au SGSN-mandataire une requête de 20 contexte PDP paramétrée par l'identifiant de zone au niveau du coeur de réseau ; et f) le second serveur reçoit de la part du SGSN-mandataire ledit contexte PDP de l'équipement d'utilisateur. On notera que dans le présent document, l'expression "équipement 25 d'utilisateur" est utilisée pour désigner uniformément tout type de dispositif informatique, par exemple un ordinateur personnel ou un serveur. Grâce à ces dispositions, lorsqu'un équipement d'utilisateur a établi un contexte PDP pour une connexion en mode paquet, on peut maintenir ce contexte PDP actif lors d'une procédure de migration de cet 30 équipement d'utilisateur.

Selon des caractéristiques particulières, l'étape a) ci-dessus comprend les sous-étapes suivantes : - le second serveur envoie à un serveur DNS une requête de consultation DNS paramétrée par des informations de zone de routage relatives auxdites première cellule et seconde cellule ; et - ledit serveur DNS envoie au second serveur l'adresse IP dudit serveur SGSN-mandataire. Grâce à ces dispositions, on peut déclarer tous les LAI/RAI-air sur chaque SGSN du réseau coeur, et leur faire correspondre l'adresse IP du 10 serveur SGSN-mandataire. Corrélativement, l'invention concerne divers dispositifs. Elle concerne ainsi, premièrement, un dispositif, dit "serveur SGSN-mandataire", pour la gestion d'itinérance en mode paquet dans un réseau de radiocommunication cellulaire. Ledit dispositif est remarquable en ce 15 qu'il est relié à une passerelle HNB Gateway, en ce qu'il est déclaré en tant que SGSN coopératif vis-à-vis des SGSN du réseau coeur, et en ce qu'il comprend des moyens pour, lors de la migration d'un équipement d'utilisateur d'une première cellule gérée par un premier serveur SGSN vers une seconde cellule gérée par un second serveur SGSN, ledit 20 équipement d'utilisateur ayant préalablement établi un contexte PDP dans ladite première cellule : - recevoir, de la part dudit second serveur, une requête d'interrogation paramétrée par un identifiant de l'équipement d'utilisateur, et par l'identifiant de zone de la première cellule au niveau du réseau 25 d'accès ; - exécuter une traduction entre l'identifiant de zone de la première cellule au niveau du réseau d'accès et l'identifiant de zone de la première cellule au niveau du coeur de réseau ; - envoyer au second serveur ledit l'identifiant de zone au niveau du 30 coeur de réseau ; - recevoir, de la part dudit second serveur, une requête de contexte PDP paramétrée par l'identifiant de zone au niveau du coeur de réseau ; et - envoyer au second serveur ledit contexte PDP de l'équipement d'utilisateur. L'invention concerne aussi, deuxièmement, un dispositif, dit "serveur DNS", pour la gestion d'itinérance en mode paquet dans un réseau de radiocommunication cellulaire. Ledit dispositif est remarquable en ce qu'il comprend des moyens pour, lors de la migration d'un équipement d'utilisateur d'une première cellule gérée par un premier serveur SGSN vers une seconde cellule gérée par un second serveur SGSN: - recevoir, de la part dudit second serveur, une requête de consultation DNS paramétrée par des informations de zone de routage relatives auxdites première cellule et seconde cellule ; et - envoyer au second serveur l'adresse IP du premier serveur. Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus.

On notera qu'il est possible de réaliser les dispositifs succinctement décrits ci-dessus dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques. L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de télécommunications et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes de l'un quelconque des procédés de gestion d'itinérance succinctement exposés ci-dessus, lorsqu'il est exécuté sur un ordinateur.

Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par lesdits procédés. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles : - la figure 1, déjà décrite, représente schématiquement une architecture classique de réseau UMTS comprenant un Home NodeB, - la figure 2 représente une procédure de consultation DNS selon un mode de réalisation de l'invention, - la figure 3 représente schématiquement une architecture de réseau UMTS comprenant un Home NodeB, selon un mode de réalisation de l'invention, et - la figure 4 représente une procédure de récupération de contexte PDP selon un mode de réalisation de l'invention. On va tout d'abord expliquer en détail en quoi consiste le problème technique visé par la présente invention. Selon les normes 3GPP précitées, les UE communiquent avec le CN au sein d'une couche logique appelée "NAS" (initiales des mots anglais "Non-Access Stratum") pour la distinguer de la "Couche d'Accès". La signalisation pour la gestion d'itinérance des UE est décrite dans la section "MAP" (pour "Mobile Application Parti') des normes 3GPP. Pour la signalisation de contrôle radio entre le CN et le réseau UTRAN, l'UMTS utilise un protocole appelé "RANAP" (initiales des mots anglais "Radio Access Network Application Part" signifiant "Partie Applicative du Réseau d'Accès Radio"). Ce protocole RANAP est mis en oeuvre sur les interfaces lu mentionnées ci-dessus. Il est notamment mis en oeuvre dans les situations d'itinérance, et dans le transport de la signalisation NAS entre l'UE et le CN. Il utilise un paramètre de localisation appelé "RANAP RAI".

Selon l'état de l'art, un équipement d'utilisateur UE qui se trouve dans une cellule de paramètres RAI-land (au niveau du coeur de réseau) et RAI-air (au niveau du réseau d'accès) se comporte de la manière suivante : 1) l'UE émet périodiquement, dans sa cellule, une requête de RAU (mise à jour de zone de routage) sur la base des informations diffusées par le point d'accès de la cellule ; 2) ce point d'accès transmet alors cette requête de RAU après avoir remplacé, pour le paramètre RANAP RAI, la valeur "RAI-air" par la valeur "RAI-land" ; et 3) l'UE met à jour son attachement à la cellule, avec comme paramètres son P-TMSI (le P-TMSI est le TMSI utilisé pour les services faisant appel à un SGSN), et "RAI-land" aux niveaux NAS RAI et RANAP. Lorsqu'à présent l'UE migre d'une cellule privée vers une cellule Macro, on observe les étapes suivantes : 1) l'UE émet une nouvelle requête de RAU dans laquelle il sélectionne la cellule Macro, avec comme paramètres son P-TMSI, et le NAS RAI avec la valeur "RAI-air" (de la cellule privée) ; 2) le SGSN toutefois ne reconnaît pas le NAS RAI "RAI-air" comme étant l'un de ses RAI locaux ou coopératifs, et rejette en conséquence la nouvelle requête de RAU (sans exécuter de vérification de P-TMSI) ; 3) l'UE émet donc une requête GPRS-Attach (avec, comme le prévoit la norme, la valeur par défaut "FFFE" pour le NAS RAI) ; 4) le SGSN traite cette requête GPRS-Attach ; et 5) le HLR est mis à jour en conséquence. Ainsi, le rejet par le SGSN, à l'étape 2) ci-dessus, de la tentative de mise à jour de zone de routage a pour conséquence que l'UE reste pendant un certain temps (i.e., entre le moment où l'UE quitte la cellule privée et le moment où le HLR est mis à jour) sans contexte PDP, et donc injoignable par d'autres abonnés.

On va maintenant illustrer le fonctionnement et les avantages de la présente invention au moyen d'un mode de réalisation. Le premier problème à résoudre est celui de pouvoir déclarer sur chaque SGSN du coeur de réseau tous les LAI-air déployés dans une architecture Femto. Il peut en théorie y avoir jusqu'à 65535 LAI/RAI-air par HNB Gateway dans l'architecture Femto, auxquels correspondent un nombre plus réduit de LAI/RAI-land (la HNB Gateway dispose d'une table de correspondance et de traduction telle que chaque LAI-land englobe un certain ensemble de LAI/RAI-air). En raison de sa complexité, ce problème ne peut pas être résolu par des opérations de maintenance ou de planification de réseau, et n'est, par ailleurs, pas pris en compte par les fournisseurs d'équipements SGSN. Ce premier problème peut être résolu au moyen d'une procédure de consultation DNS (initiales des mots anglais "Domain Name Service" signifiant "Service de Noms de Domaines"). Cette procédure de consultation DNS est illustrée, pour le présent mode de réalisation de l'invention, sur la figure 2. On considère ici la migration d'un UE à partir d'une première cellule 1, gérée par un serveur SGSN désigné par "SGSN1" sur la figure 2, vers une seconde cellule 2, gérée par un serveur SGSN désigné par "SGSN2" sur la figure 2. Comme expliqué ci-dessus, l'UE émet, de manière classique, une requête de RAU mentionnant des données de routage diffusées par les points d'accès des cellules 1 et 2. Pour prendre un exemple numérique, cette requête mentionnera par exemple les éléments : NAS RAI : 208-01-8100-0 /P-TMSI/ RANAP RAI : 208-01-601-10 lorsque, - pour les cellules 1 et 2 : code MCC = 208, code MNC = 01, - pour la cellule 1 : code LAC = 8100, et code RAC = 0 (le code "RAC", initiales des mots anglais "Routing Area Code" signifiant "code de zone de routage", est une portion du RAI), et - pour la cellule 2 : code LAC = 601, et code RAC = 10. La procédure de consultation DNS comprend alors les étapes suivantes : 1) le serveur SGSN2 transforme une partie au moins des informations de zone de routage ci-dessus en un nom logique (dans l'exemple considéré, le serveur SGSN2 pourra créer le nom logique RAC0010.LAC0601.MCC208.MNC01.GPRS) ; 2) le serveur SGSN2 envoie à un serveur DNS une requête de consultation mentionnant ce nom logique ; et 3) ledit serveur DNS envoie au serveur SGSN2 l'adresse IP du serveur SGSN1. On notera que les serveurs DNS peuvent être internes ou externes aux SGSN ; si les serveurs DNS sont externes, on peut n'utiliser qu'un seul serveur DNS partagé par tous les SGSN. Le serveur DNS doit être instruit de toutes les déclarations LAI/RAI-air indiquant une fonction de SGSN par défaut, afin d'établir une correspondance entre les LAI/RAI diffusés dans les réseaux d'accès radio, et les LAI/RAI utilisés dans le réseau coeur. Cette procédure d'interrogation DNS permet à l'opérateur de ne pas avoir à déclarer tous les LAI/RAI-air sur ses serveurs SGSN : il doit seulement maintenir le DNS à jour de manière à pouvoir, notamment lors d'une tentative de récupération de contexte PDP, pointer vers le bon SGSN, c'est-à-dire le SGSN sur lequel l'UE était enregistré avant sa migration. Selon un mode de réalisation de l'invention, la récupération de contexte PDP met en oeuvre l'architecture de réseau UMTS illustrée schématiquement sur la figure 3.

Cette figure 3 montre, dans le réseau d'accès radio de l'opérateur, un noeud intermédiaire, appelé "SGSN-mandataire" ("Proxy SGSN" en anglais) dans le cadre de la présente invention. Ce SGSN-mandataire : • est relié à une HNB Gateway permettant, au moyen d'une procédure d'interrogation, une mise en correspondance entre un LAI/RAI-air et une adresse de SGSN, afin de maintenir un lien entre le LAI/RAI-air diffusé par le HNB et le LAI/RAI-land utilisé dans le réseau coeur UMTS, • possède une interface Gp avec le réseau coeur UMTS classique, et • est déclaré en tant que SGSN coopératif vis-à-vis des SGSN du réseau coeur UMTS, de manière à pouvoir assurer l'interface, lors de la migration d'un UE à partir d'une première cellule 1 vers une seconde cellule 2, entre les serveurs SGSN1 et SGSN2 au moyen du protocole GTP mentionné ci-dessus.

On notera que le SGSN-mandataire pourra optionnellement être physiquement intégré dans la HNB Gateway. Quel que soit le cas, on désigne le SGSN-mandataire sous le nom de "serveur SGSN-mandataire" dans le présent document. La HNB Gateway conserve, et exécute conformément au protocole RANAP sur l'interface lu, la correspondance entre les LAI/RAI-air diffusés et les LAI/RAI-land utilisés dans le réseau coeur UMTS. Grâce à l'invention, on peut donc associer à un LAI/RAI-air l'adresse du SGSN approprié. On notera que la HNB Gateway telle que définie dans la norme 3GPP ne met pas en oeuvre une telle fonctionnalité.

La figure 4 illustre un procédé de récupération de contexte PDP selon un mode de réalisation de l'invention. Ce procédé comprend les étapes suivantes. Lors de la migration d'une couverture HNB à une couverture Macro avec un contexte PDP actif, puisque le LAI/RAI diffusé est différent, l'UE émet, à l'étape E1, une requête de mise à jour (GMM ROUTING AREA UPDATE REQUEST) à destination du serveur SGSN2 (représenté par "Target SGSN" sur la figure 4) du réseau coeur CN. Cette requête mentionne notamment les paramètres LAI/RAI-air diffusés au sein de la zone HNB dans laquelle l'UE était enregistré.

Le serveur SGSN2 ne peut pas reconnaître ce LAI/RAI-air : il exécute donc, à l'étape E2, une procédure de consultation de DNS, comme décrit ci-dessus en référence à la figure 2. Cette interrogation lui fournit l'adresse IP du SGSN-mandataire. A l'étape E3, le serveur SGSN2 envoie au SGSN-mandataire via l'interface Gp une requête d'interrogation (message "Context REQ" sur la figure 4) au moyen du protocole GTP, afin de récupérer l'ancien contexte PDP. Entre autres paramètres, cette requête mentionne le P-TMSI de l'UE et le LAI/RAI-air que le serveur SGSN2 a tiré de la requête de mise à jour qu'il a reçue de l'UE.

Le SGSN-mandataire exécute, à l'étape E4, une traduction entre le LAI/RAI-air et le LAI/RAI-land correspondant (tels que connus de la HNB Gateway). Le SGSN-mandataire envoie, à l'étape E5, ce LAI/RAI-land au SGSN2 (message "Context REQ" sur la figure 4).

A l'étape E6, le SGSN2 envoie au SGSN-mandataire une requête GTP de contexte PDP (message "Context RESP" sur la figure 4), avec le LAI/RAI-land comme paramètre. A l'étape E7, le SGSN2 reçoit de la part du SGSN-mandataire (message "Context RESP" sur la figure 4) le contexte PDP (toujours actif) de l'UE, et confirme cette réception au SGSN-mandataire, et confirme cette réception au SGSN-mandataire (message "Context ACK" sur la figure 4). Enfin, à l'étape E8, le serveur SGSN2 obtient la mise à jour du contexte PDP dans le GGSN (étapes "GTP Update" sur la figure 4), ainsi que la mise à jour de la localisation GPRS dans le HLR (étapes "MAP Update" sur la figure 4). La mise en oeuvre de l'invention au sein des noeuds du réseau de télécommunications (plus précisément, les serveurs DNS et SGSN- mandataire dans le mode de réalisation décrit ci-dessus) peut être réalisée au moyen de composants logiciels et/ou matériels. Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de gestion d'itinérance selon l'invention. En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de télécommunications comprenant des instructions pour l'exécution des étapes d'un procédé de gestion d'itinérance selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette ("floppy disc" en anglais) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de gestion d'itinérance selon l'invention.

Claims (12)

1. REVENDICATIONS1. Procédé de gestion d'itinérance en mode paquet dans un réseau de radiocommunication cellulaire, comprenant, lors de la migration d'un équipement d'utilisateur (UE) d'une première cellule (1) gérée par un premier serveur SGSN (SGSN1) vers une seconde cellule (2) gérée par un second serveur SGSN (SGSN2), ledit équipement d'utilisateur (UE) ayant préalablement établi un contexte PDP dans ladite première cellule (1), une étape au cours de laquelle l'équipement d'utilisateur (UE) émet, à destination dudit second serveur (SGSN2), une requête de mise à jour de zone de routage (RAU) paramétrée par l'identifiant de zone de la première cellule (1) au niveau du réseau d'accès (LAI/RAI-air), caractérisé en ce qu'il comprend ensuite les étapes suivantes : a) le second serveur (SGSN2) obtient l'adresse IP d'un serveur, dit "SGSN-mandataire", qui est relié à une passerelle HNB Gateway et qui est déclaré en tant que SGSN coopératif vis-à-vis des SGSN du réseau coeur (CN); b) le second serveur (SGSN2) envoie audit serveur SGSN-mandataire une requête d'interrogation paramétrée par un identifiant (PTMSI) de l'équipement d'utilisateur (UE), et par ledit identifiant de zone de la première cellule (1) au niveau du réseau d'accès (LAI/RAI-air) ; c) le serveur SGSN-mandataire exécute une traduction entre l'identifiant de zone de la première cellule (1) au niveau du réseau d'accès (LAI/RAI-air) et l'identifiant de zone de la première cellule (1) au niveau du coeur de réseau (LAI/RAI-land) ; d) le SGSN-mandataire envoie au second serveur (SGSN2) ledit l'identifiant de zone (LAI/RAI-land) au niveau du coeur de réseau ; e) le second serveur (SGSN2) envoie au SGSN-mandataire une requête de contexte PDP paramétrée par l'identifiant de zone (LAI/RAI-land) au niveau du coeur de réseau ; etf) le second serveur (SGSN2) reçoit de la part du SGSN-mandataire ledit contexte PDP de l'équipement d'utilisateur (UE).
2. 2. Procédé de gestion d'itinérance selon la revendication 1, caractérisé en ce que ladite étape a) comprend les sous-étapes suivantes : - le second serveur (SGSN2) envoie à un serveur DNS une requête de consultation DNS paramétrée par des informations de zone de routage relatives auxdites première cellule (1) et seconde cellule (2) ; et - ledit serveur DNS envoie au second serveur (SGSN2) l'adresse IP dudit serveur SGSN-mandataire.
3. 3. Procédé de gestion d'itinérance selon la revendication 1 ou la revendication 2, caractérisé en ce que ledit réseau de radiocommunication cellulaire est un réseau GSM.
4. 4. Procédé de gestion d'itinérance selon la revendication 1 ou la revendication 2, caractérisé en ce que ledit réseau de radiocommunication cellulaire est un réseau UMTS.
5. 5. Dispositif, dit "serveur SGSN-mandataire", pour la gestion d'itinérance en mode paquet dans un réseau de radiocommunication cellulaire, caractérisé en ce qu'il est relié à une passerelle HNB Gateway, en ce qu'il est déclaré en tant que SGSN coopératif vis-à-vis des SGSN du réseau coeur (CN), et en ce qu'il comprend des moyens pour, lors de la migration d'un équipement d'utilisateur (UE) d'une première cellule (1) gérée par un premier serveur SGSN (SGSN1) vers une seconde cellule (2) gérée par un second serveur SGSN (SGSN2), ledit équipement d'utilisateur (UE) ayant préalablement établi un contexte PDP dans ladite première cellule (1) : - recevoir, de la part dudit second serveur (SGSN2), une requête d'interrogation paramétrée par un identifiant (P-TMSI) de l'équipementd'utilisateur (UE), et par l'identifiant de zone de la première cellule (1) au niveau du réseau d'accès (LAI/RAI-air) ; - exécuter une traduction entre l'identifiant de zone de la première cellule (1) au niveau du réseau d'accès (LAI/RAI-air) et l'identifiant de zone de la première cellule (1) au niveau du coeur de réseau (LAI/RAI-land) ; - envoyer au second serveur (SGSN2) ledit l'identifiant de zone (LAI/RAI-land) au niveau du coeur de réseau ; - recevoir, de la part dudit second serveur (SGSN2), une requête de 10 contexte PDP paramétrée par l'identifiant de zone (LAI/RAI-land) au niveau du coeur de réseau ; et - envoyer au second serveur (SGSN2) ledit contexte PDP de l'équipement d'utilisateur (UE).
6. 6. Dispositif de gestion d'itinérance selon la revendication 5, 15 caractérisé en ce qu'il est physiquement intégré dans une passerelle HNB Gateway.
7. 7. Dispositif, dit "serveur DNS", pour la gestion d'itinérance en mode paquet dans un réseau de radiocommunication cellulaire, caractérisé en ce qu'il comprend des moyens pour, lors de la migration 20 d'un équipement d'utilisateur (UE) d'une première cellule (1) gérée par un premier serveur SGSN (SGSN1) vers une seconde cellule (2) gérée par un second serveur SGSN (SGSN2) : - recevoir, de la part dudit second serveur (SGSN2), une requête de consultation DNS paramétrée par des informations de zone de routage 25 relatives auxdites première cellule (1) et seconde cellule (2) ; et - envoyer au second serveur (SGSN2) l'adresse IP du premier serveur (SGSN1).
8. 8. Dispositif de gestion d'itinérance selon la revendication 7, caractérisé en ce qu'il est physiquement intégré dans un serveur SGSN.
9. 9. Dispositif de gestion d'itinérance selon l'une quelconque des revendications 5 à 8, caractérisé en ce que ledit réseau de radiocommunication cellulaire est un réseau GSM.
10. 10. Dispositif de gestion d'itinérance selon l'une quelconque des revendications 5 à 8, caractérisé en ce que ledit réseau de radiocommunication cellulaire est un réseau UMTS.
11. 11. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de gestion d'itinérance selon l'une quelconque des revendications 1 à 4.
12. 12. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de gestion d'itinérance selon l'une quelconque des revendications 1 à 4, lorsqu'il est exécuté sur un ordinateur.