Brevet FR2869186A1 — publié le 20051021

PROCEDE POUR ENREGISTRER UN TERMINAL AUPRES D'UN SYSTEME CELLULAIRE DE RADIOCOMMUNICATION, RESEAU D'ACCES RADIO ET RESEAU COEUR POUR LA MISE EN OEUVRE DU PROCEDE La présente invention concerne les systèmes cellulaires de radiocommunication avec les mobiles. Elle s'applique aux systèmes cellulaires dont l'architecture se décompose en réseaux coeurs et en réseaux d'accès radio. Dans les systèmes de seconde génération, de type GSM ou dérivé, le réseau coeur est appelé sous-système de commutation de réseau (NSS, "Network Switching Subsystem"), et le réseau d'accès radio est appelé sous-système de stations de base (BSS, "Base Station Subsystem"). La terminologie "réseau coeur" (CN, "Core Network") et "réseau d'accès radio" (RAN, "Radio Access Network") est celle employée dans les systèmes de troisième génération tels que l'UMTS, mais elle correspond essentiellement aux mêmes notions. Ces systèmes supportent des communications en mode circuit (domaine CS, "Circuit Switched") et des communications en mode paquets (domaine PS, "Packet Switched"). Dans les systèmes GSM, le service du domaine PS est appelé GPRS ("General Packet Radio Service"). Dans les spécifications du réseau UMTS, on fait référence à un découpage en strates permettant de séparer des niveaux de service indépendants. La strate AS ("Access Stratum") gère les fonctions liées au réseau d'accès, notamment la gestion des ressources radio, tandis que la strate NAS ("Non Access Stratum") a en charge des fonctions indépendantes du réseau d'accès (gestion d'appels, gestion de la mobilité des terminaux, ...). Dans les systèmes de troisième génération, le même réseau coeur peut coopérer avec plusieurs réseaux d'accès radio, par exemple le RAN terrestre de l'UMTS (UTRAN, "UMTS Terrestrial RAN"), un réseau de satellites (SRAN), un BSS du GSM, un RAN de type GPRS / EDGE (GERAN), toutes sortes de réseaux d'accès radio à large bande, ... Le réseau coeur se compose de commutateurs interconnectés appelés MSC ("Mobile Switching Center") pour le domaine CS et GSN ("GPRS Support Node") pour le domaine PS. Les MSC qui servent de passerelles avec d'autres réseaux sont appelés GMSC ("Gateway MSC"). Les GSN interfacés avec un RAN sont appelés SGSN ("Serving GSN"), tandis que ceux qui servent de passerelles avec d'autres réseaux sont appelés GGSN ("Gateway GSN"). L'interface entre un MSC et un contrôleur de station de base d'un BSS GSM est appelée interface A. L'interface entre un SGSN et un BSS GSM pour le transport des données GPRS est appelée interface Gb. L'interface entre un o contrôleur de réseau radio (RNC, "Radio Network Controller") de l'UTRAN et un MSC ou un SGSN est appelée interface lu. Outre les commutateurs, le réseau coeur comporte habituellement des organes intervenant dans la gestion des abonnés: registre de localisation nominal (HLR, "Home Location Register"), centre d'authentification (AuC, "Authentication Center"), etc. La configuration du système à laquelle on s'intéresse dans le cadre de la présente invention est une configuration où un RAN est partagé par plusieurs CN. Dans la suite de la présente description, on considérera plus particulièrement le cas où ce réseau d'accès radio est de type UTRAN, sans que ceci limite la généralité du propos. Ces systèmes à réseau partagé sont décrits dans les rapports techniques 3GPP TR 22.951, version 6.1.0 et 3GPP TR 23.851, version 6.0.0 publiés respectivement en mars et en mars 2004 par l'organisation 3GPP ("3rd Generation Partnership Project"). Les architectures à partage de réseau permettent à différents opérateurs de réseaux coeurs de se connecter à un même RAN dont ils partagent les éléments ainsi que les ressources spectrales. Ces opérateurs peuvent détenir par ailleurs des RAN qui leur sont propres. Certains d'entre eux peuvent être simplement opérateurs de réseau coeur sans bénéficier d'une licence sur le spectre radio. L'architecture plus particulièrement envisagée ici est celle dite MOCN ("Multi-Operator Core Network"), dans laquelle plusieurs réseaux coeurs gérés par des opérateurs différents sont connectés au même réseau d'accès radio. L'opérateur du RAN peut ou non être l'un des opérateurs de CN. De tels schémas de partage de réseau sont prévus dans les systèmes de troisième génération de la "release 6". Les terminaux radio "release 6" peuvent ainsi sélectionner l'opérateur de CN devant traiter leurs appels, en particulier en situation de roaming. Cependant, lorsque des équipements "release 6" seront déployés, il existera un important parc de terminaux en circulation qui ne seront pas munis des fonctions de la "release 6" et qui devront néanmoins être en mesure de bénéficier du système et en particulier des particularités liées au partage de réseau. Pour être en mesure de communiquer, un terminal mobile s'enregistre auprès d'un réseau coeur dans une procédure d'attachement ou de mise à jour de localisation. Cet enregistrement permet ensuite de rechercher le terminal pour l'avertir d'appels entrants. Il permet aussi de servir les requêtes de communication issues du terminal. Dans le contexte MOCN, cet enregistrement ne pose pas de problème pour un terminal "release 6", qui est capable de sélectionner d'emblée le CN auprès duquel il souhaite s'enregistrer. Les CN disponibles sont identifiés dans les informations système diffusées par le RAN partagé, ce qui permet au terminal de les identifier, d'effectuer la sélection de celui qui lui convient et de préciser cette sélection au RAN partagé lors de sa demande d'enregistrement. La requête d'enregistrement du terminal est alors relayée par le RAN au CN sélectionné par le terminal via une connexion de signalisation dédiée à ce terminal sur l'interface lu (voir la description du mode de service connection oriented data transfer service du protocole RANAP décrit dans la norme ETSI TS 125.413 version 5.6.0 publiée en septembre 2003). Pour un terminal "pré-release 6", cette sélection n'est pas possible de sorte que la requête d'enregistrement peut être relayée par le RAN partagé vers un CN susceptible de ne pas convenir. Le rapport technique 3GPP TR 23.851 version 6.0.0 précité suggère que si le CN sélectionné, et vers lequel la requête du terminal est relayée, n'est pas capable de desservir le terminal, un re-routage de ladite requête du terminal vers un autre CN est possible: le CN indique au RAN que la requête d'enregistrement est à transmettre à un autre CN, le RAN se chargeant alors de la re-router. Cette solution présente des inconvénients. Il faut prévoir un mécanisme pour empêcher le RNC de se mettre en boucle en essayant les différents CN de façon répétitive. Il faut s'assurer que les références de signalisation entre le terminal et le CN sont toujours synchrones, même si certains messages sont gérés par un CN et d'autres par un autre CN. En outre, le fait de relayer la requête d'enregistrement du terminal à une multitude de CN successivement, en attendant après chaque requête une réponse du CN concerné pour savoir s'il est en mesure de traiter la requête d'enregistrement ou bien si cette dernière doit être relayée à un autre CN, peut se révéler très consommateur en temps. A ceci s'ajoute le temps d'établissement de la connexion de signalisation sur l'interface lu pour le transfert de la requête du terminal. Le temps finalement mis pour répondre à la requête d'enregistrement du terminal peut devenir excessif et faire expirer les temporisations appliquées par le terminal. Il en résulte de plus un désagrément vu de l'utilisateur qui s'attend à avoir un temps d'enregistrement ou un temps d'accès identique quelle que soit la configuration du réseau, i.e. que le RAN soit partagé ou non. Cela est d'autant plus sensible que le nombre de CN connectés au même RAN est élevé. Un but de la présente invention est de proposer un mécanisme rapide et efficace pour le routage de ces requêtes d'enregistrement. L'invention propose ainsi un procédé pour enregistrer un terminal radio auprès d'un système cellulaire de radiocommunication comprenant un groupe de réseaux coeurs et un réseau d'accès radio partagé entre les réseaux coeurs du groupe. Le procédé comprend les étapes suivantes: émettre une requête d'enregistrement du terminal vers le réseau d'accès radio partagé ; effectuer une transmission sans connexion d'un message depuis le réseau d'accès radio partagé vers au moins un réseau coeur du groupe, ledit message requérant une indication relative à un support de o l'enregistrement du terminal par ledit réseau coeur du groupe; effectuer une transmission sans connexion d'une réponse audit message depuis chaque réseau coeur du groupe ayant reçu ledit message; et - lorsque le réseau d'accès radio partagé reçoit, depuis un ensemble de réseaux coeurs du groupe, des réponses indiquant le support de l'enregistrement du terminal par respectivement chaque réseau coeur dudit ensemble, relayer ladite requête d'enregistrement du terminal vers l'un au moins parmi les réseaux coeurs dudit ensemble. Les mécanismes dits "luFlex" permettant de spécifier les ressources de réseau coeur à employer pour l'acheminement ultérieur des messages provenant des terminaux ont été prévus pour permettre le partage de charge entre différents noeuds d'un réseau coeur. Ces mécanismes peuvent être étendus au cas où il y a plusieurs réseaux coeurs. Les transmissions sans connexion ("connectionless") sont décrites dans le protocole RANAP ("RAN Application Part") décrit dans la norme ETSI TS 125. 413, version 5.6.0, publiée en septembre 2003. Elles sont effectuées indépendamment de toute connexion avec un terminal radio donné, contrairement aux transmissions dites "orientées connexion" ("connectionoriented"). Elles ont l'avantage d'être plus rapides et elles peuvent être adressées à plusieurs entités de communication simultanément. La transmission sans connexion d'un message depuis le réseau d'accès radio partagé, peut être effectuée vers un seul réseau coeur à la fois. Par exemple, la transmission sans connexion d'un message depuis le réseau d'accès radio partagé est d'abord effectuée vers un premier réseau coeur du groupe, et la transmission sans connexion d'un message depuis le réseau d'accès radio partagé vers un second réseau coeur du groupe est effectuée seulement lorsque le réseau d'accès radio partagé a reçu une réponse audit message transmise depuis le premier réseau coeur indiquant une absence de support de l'enregistrement du terminal par ledit premier réseau coeur. L'utilisation de cette transmission sans connexion permet un gain de temps comparé à l'utilisation d'une transmission avec connexion. La transmission sans connexion d'un message depuis le réseau d'accès radio partagé peut aussi être effectuée vers au moins deux réseaux coeurs du groupe sensiblement simultanément. Les transmissions sont alors effectuées en parallèle, ce qui permet un gain significatif dans le temps de réponse des réseaux coeurs et par conséquent dans la réponse finale vers le terminal. Avant de transmettre une réponse audit message, chaque réseau coeur du groupe ayant reçu ledit message vérifie s'il supporte l'enregistrement du terminal, c'est-à-dire s'il valide la présence du terminal dans sa nouvelle localisation ou si des restrictions dites de roaming empêche le terminal de s'attacher à ce coeur de réseau. Les restrictions de roaming sont décrites dans la norme ETSI TS 123.060. La vérification est effectuée à partir d'une information relative à une identité du terminal (IMSI) pouvant être déduite d'une identité temporaire du terminal (TMSI/P-TMSI). Cette identité du terminal (IMSI ou TMSI/P-TMSI) est fournie par le réseau d'accès dans la transmission sans connexion, le réseau d'accès l'ayant trouvé dans la requête initiale d'enregistrement du terminal. Si le réseau d'accès a fourni l'identifiant temporaire au coeur du réseau, il se peut que le coeur de réseau ne puisse déduire l'identifiant IMSI du terminal et ne puisse vérifier s'il accepte le terminal. Le coeur de réseau demande alors avantageusement l'établissement d'une connexion sur l'interface lu afin de demander l'IMSI au terminal. L'invention propose en outre un réseau d'accès radio d'un système cellulaire de radiocommunication comprenant en outre un groupe de réseaux coeurs, ledit réseau d'accès radio étant partagé entre les réseaux coeurs du groupe et comprenant, relativement à un terminal radio: - des moyens pour détecter une requête d'enregistrement émise par le terminal; - des moyens pour effectuer une transmission sans connexion d'un message vers au moins un réseau coeur du groupe, ledit message requérant une indication relative à un support de l'enregistrement du terminal par ledit réseau coeur du groupe; des moyens pour recevoir une réponse audit message transmise sans connexion depuis chaque réseau coeur du groupe ayant reçu ledit message; et - des moyens, sur réception, depuis un ensemble de réseaux coeurs du groupe, de réponses indiquant le support de l'enregistrement du terminal par respectivement chaque réseau coeur dudit ensemble, pour relayer ladite requête d'enregistrement du terminal vers l'un au moins parmi les réseaux coeurs dudit ensemble. Le réseau d'accès radio comprend avantageusement des moyens pour mettre en oeuvre les étapes du procédé susmentionné. L'invention propose également un réseau coeur d'un groupe de réseaux coeurs d'un système cellulaire de radiocommunication comprenant en outre un réseau d'accès radio partagé entre les réseaux coeurs du groupe. Le réseau coeur comprend, relativement à un terminal radio agencé pour émettre une requête d'enregistrement vers le réseau d'accès radio partagé : des moyens pour recevoir un message transmis sans connexion depuis le réseau d'accès radio partagé, ledit message requérant une indication relative à un support de l'enregistrement du terminal par ledit réseau coeur; des moyens pour effectuer une transmission sans connexion d'une réponse audit message, ladite réponse incluant l'indication relative à un support de l'enregistrement du terminal par ledit réseau coeur; et des moyens pour recevoir ladite requête d'enregistrement du terminal relayée par le réseau d'accès radio partagé. Le réseau coeur est constitué avantageusement d'une pluralité de commutateurs dont certains au moins sont agencés pour mettre en oeuvre des étapes du procédé susmentionné. D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels: la figure 1 est un schéma montrant un système cellulaire adapté à la mise en oeuvre de l'invention; et - la figure 2 est un diagramme montrant des échanges de signalisation intervenant dans un mode de réalisation de l'invention. L'invention est décrite ci-après dans son application à un système de troisième génération de type UMTS, dans le cas particulier de communications en mode circuit (domaine CS). On remarquera que les caractéristiques de l'invention décrites ci-après se transposent aisément au domaine PS ou encore à d'autres types de systèmes cellulaires. Le système cellulaire représenté sur la figure 1 comporte trois réseaux coeurs 1, 2, 3 qui partagent les ressources d'un réseau d'accès radio 4. Pour en faciliter la lecture, le dessin montre une représentation simplifiée du réseau d'accès radio 4 de type UTRAN, avec un contrôleur de réseau radio (RNC) 5 supervisant deux stations de base (ou "nodes B") 6 à travers une interface dite lub. Ces nodes B 6 offrent une interface radio Uu avec les terminaux mobiles 7 qui, dans le jargon de l'UMTS, sont appelés UE ("User Equipment"). En pratique, un RAN 4 comporte généralement des RNC et des nodes B beaucoup plus nombreux. Chaque réseau coeur 1, 2, 3 comporte des commutateurs de type MSC pour le mode circuit, dont des GMSC 10 pour servir de passerelle avec des réseaux externes tels que par exemple le réseau téléphonique commuté. Les autres MSC 11 sont reliés à un ou plusieurs RAN afin de desservir des terminaux mobiles. Dans l'exemple représenté, le RNC 5 du réseau d'accès radio est relié à un MSC du CN 1, à deux MSC du CN 2 et à un MSC du CN 3 à travers des interfaces lu. La connexion du RNC 5 à plusieurs MSC 11 d'un même réseau coeur (le CN 2 sur la figure 1) peut être réalisée suivant les mécanismes "luFlex" décrits dans la spécification technique 3GPP TS 23. 236, version 5.2.0, publiée en mars 2002 par le 3GPP. Chaque réseau coeur 1, 2, 3 comporte en outre un registre d'abonnés 12 de type HLR permettant à l'opérateur du réseau coeur d'assurer la gestion de ses abonnés et de savoir les localiser dans le système cellulaire. Pour faire communiquer entre eux les commutateurs 10, 11, les HLR 12 et les autres organes du réseau coeur, celui-ci a, de façon classique, une infrastructure basée sur le protocole IP ("Internet Protocol"). Dans le cas de CN partageant un même RAN, les infrastructures IP sur lesquelles sont construits ces CN sont prévues pour communiquer entre elles afin que les commutateurs puissent échanger certaines informations utiles au partage. L'interface entre deux MSC, appelée interface E dans la norme (et qui est une interface SS7), peut ainsi être étendue à travers l'infrastructure IP à des MSC n'appartenant pas au même CN. Les protocoles suivants servent à la gestion des abonnés dans les réseaux coeurs: - le protocole MAP ("Mobile Application Part") entre les différents noeuds du réseau coeur, décrit dans la norme ETSI TS 129.002, version 5.7. 0, publiée en septembre 2003; et - les protocoles MM ("Mobility Management") entre les terminaux et les MSC pour le domaine CS et GMM ("GPRS Mobility Management") entre les terminaux et les noeuds SGSN pour le domaine PS, décrits dans la spécification technique 3GPP TS 24.008, version 5.9.0, publiée en septembre 2003 par le 3GPP. Entre le terminal 7 et le RNC 5, les informations NAS du protocole MM sont transportées dans des messages du protocole RRC ("Radio Ressource Control") décrit dans la norme ETSI TS 125.331, version 5.6.0, publiée en septembre 2003. Sur l'interface lu, les informations NAS du protocole MM sont transportées dans des messages du protocole RANAP ("RAN Application Part") décrit dans la norme ETSI TS 125.413 version 5.6.0 précitée. Dans le diagramme de la figure 2, le transfert des informations NAS du protocole MM est représenté en montrant les messages RRC ou RANAP dans lesquels ces informations sont encapsulées. L'enregistrement d'un UE auprès d'un CN est initialisé par l'UE, dans l'un des cas suivants: - l'UE est mis sous tension et déclenche une procédure dite "IMSI attach" pour se signaler au système; - l'UE en mode veille détecte qu'il a changé de zone de localisation, et déclenche une procédure de mise à jour de localisation pour le faire savoir au système afin que celui-ci puisse le localiser plus efficacement si un appel entrant survient. Dans les deux cas, l'UE 7 commence par établir une connexion RRC avec le RAN 4 dont il détecte les signaux de balise, puis il émet un message MM de requête de mise à jour de localisation (LUR, "Location Updating Request", 3GPP TS 24.008, v5.9.0, ≈4.4.4.1). Cette requête LUR est incluse dans le champ "NAS Message" d'un message INITIAL DIRECT TRANSFER du protocole RRC (ETSI TS 125.331, v5.6.0, ≈10.2.16c). Si l'UE est conforme à la "release 6", il spécifie dans ce message RRC le CN auprès duquel il y a lieu de l'inscrire, et le RNC route la requête LUR en conséquence. Ce routage direct ne peut cependant pas s'appliquer à un UE de type antérieur à la "release 6", pour lequel on pourra avoir recours à l'un des mécanismes de routage illustré par la figure 2. Les opérations incombant aux réseaux coeurs sur ces figures sont exécutées par des programmes installés dans les commutateurs, à savoir les MSC raccordés au RAN partagé. Dans certains cas, ces programmes peuvent être en partie décentralisés vers d'autres organes du réseau coeur. Sur réception de la requête LUR à l'UTRAN 4, ce dernier effectue une transmission sans connexion d'un message à certains au moins des CN du système de radiocommunication. Ce message ("requête support enregistrement" sur la figure 2) vise à obtenir une réponse de chaque CN auquel il est adressé, pour savoir si ce CN est apte à effectuer un enregistrement de l'UE 7. La transmission est effectuée sans connexion ("connectionless") selon le mode prévu dans le protocole RANAP (ETSI TS 25.413), par opposition au mode orienté connexion ("connection-oriented"), c'est-à-dire indépendamment de toute connexion avec l'UE 7. Dans un premier mode de réalisation, ce message ("requête support enregistrement") est transmis à un seul CN à la fois. Par exemple, l'UTRAN 4 transmet ce message au CN 1, puis, lorsqu'il a reçu une réponse du CN 1 indiquant que le CN 1 n'est pas apte à effectuer un enregistrement de l'UE 7, transmet le message au CN 2, etc. Si, en revanche, le CN 1 est capable d'enregistrer l'UE 7, le message n'est avantageusement pas transmis aux autres CN. Dans un mode de réalisation alternatif, le message ("requête support enregistrement") est transmis quasi-simultanément à plusieurs CN. Ce mode de réalisation est illustré sur la figure 2, où le message est transmis en mode non connecté en parallèle à CN 1 et CN 2. Sur réception de ce message, chaque CN vérifie s'il supporte l'enregistrement de l'UE 7, c'est-à-dire s'il convient pour un tel enregistrement. A cet effet, il vérifie les droits d'itinérance ou de "roaming" associés à cet UE. Cette vérification est basée sur l'identification fixe internationale de l'UE 7 (IMSI, International Mobile Subscriber Identity). L'IMSI est soit directement obtenu de l'UTRAN, soit déduit de l'identifiant temporaire du terminal (TMSI, "Temporary Mobile Subscriber Identity") obtenu de l'UTRAN, l'UTRAN obtenant cet IMSI ou ce TMSI dans la requête LUR initiale. En effet, cette requête contient l'identité fixe internationale (IMSI, "International Mobile Subscriber Identity") ou temporaire (TMSI,) du terminal. Cette identité est ensuite retransmise depuis l'UTRAN 4 dans la "requête support enregistrement" pour être disponible au niveau de chaque CN. On note que lorsque le TMSI est transmis dans la requête, le CN peut être amené à rechercher l'IMSI de l'UE pour effectuer l'étape de vérification du support de l'enregistrement de cet UE. Cela peut être fait de façon classique, par interrogation des tables préétablies établissant la relation entre identité temporaire (TMSI) et IMSI localement dans le CN ou bien dans le CN auprès o duquel l'UE était précédemment enregistré. Si un CN ne parvient pas à obtenir l'IMSI de l'UE 7, ce qui représente un cas particulièrement rare, on peut alors prévoir que le CN transmette, en guise de réponse au message transmis par l'UTRAN 4, un message rejetant la transmission sans connexion. Sur réception de ce rejet, l'UTRAN 4 peut alors relayer la requête LUR vers ce CN, en mode orienté connexion cette fois. Le CN est alors en mesure de retrouver l'IMSI de l'UE 7 en mettant en oeuvre une procédure d'identification standard avec le terminal. Après avoir vérifié son aptitude à enregistrer l'UE 7, chaque CN effectue une transmission sans connexion en réponse à l'UTRAN 4. Cette réponse indique à l'UTRAN 4 si l'enregistrement de l'UE 7 est supporté par ce CN. Dans l'exemple illustré sur la figure 2, on considère que la réponse renvoyée par le CN 1 atteste du support d'un tel enregistrement par le CN 1 ("support enregistrement"), tandis que celle transmise par le CN 2 indique que le CN 2 n'est pas apte à enregistrer l'UE 7 ("absence support enregistrement"). Sur réception de ces messages de réponse, l'UTRAN 4 est alors capable de choisir le CN qui mettra en oeuvre l'enregistrement de l'UE 7, c'est-àdire le CN1 dans l'exemple illustré. Si le message ("requête support") a été transmis en parallèle à différents CN et que plusieurs de ces CN indiquent en réponse qu'ils supporteraient l'enregistrement de l'UE 7, l'UTRAN 4 peut alors choisir le CN qui effectuera l'enregistrement. Ce choix peut être aléatoire ou il peut tenir compte de différents paramètres, comme un partage de charge entre les CN par exemple. Si tous les CN auxquels le message ("requête support") a été transmis répondent en indiquant qu'ils ne conviennent pas pour l'enregistrement de l'UE 7, l'UTRAN 4 peut alors avantageusement relayer la requête LUR initiale du terminal vers l'un quelconque de ces CN, de manière à ce que ce dernier puisse clore la procédure par un rejet de l'enregistrement adressé à l'UE 7. Dans le cas où les CN sont interrogés tour à tour sur leur support éventuel d'un enregistrement de l'UE 7, l'UTRAN 7 peut alors choisir le premier o CN lui indiquant en réponse au message ("requête support") qu'il est apte à effectuer un tel enregistrement. Si tous les CN du système de radiocommunication ont été interrogés tour à tour par l'UTRAN 4, à l'exception d'un seul CN, par exemple le CN 3, on peut ne pas effectuer de transmission sans connexion du message ("requête support") à ce dernier CN. Au contraire, l'UTRAN peut relayer la requête LUR initiale du terminal depuis l'UTRAN 4 vers ce dernier CN, de manière à ce qu'il puisse clore la procédure par un rejet de l'enregistrement adressé à l'UE 7 ou bien par la mise en oeuvre de l'enregistrement de l'UE 7. On se place désormais dans le cas où l'UTRAN 4 a sélectionné un CN, par exemple le CN 1 dans l'exemple illustré sur la figure 2, pour effectuer l'enregistrement de l'UE 7. Dans ce cas, le message MM de requête de mise à jour de localisation est routé par l'UTRAN 4 vers ce CN 1, en étant inclus dans le champ "NAS-PDU " d'un message INITIAL UE du protocole RANAP (ETSI TS 25.413, v5.6.0, ≈9.1.33). Contrairement à la transmission précédente, cette transmission est en mode orienté connexion. Le MSC recevant la requête peut à nouveau examiner si le CN 1 convient pour procéder à l'enregistrement du terminal, sur la base de l'identité fixe internationale IMSI ou temporaire TMSI indiquée par le terminal mobile dans sa requête. - 14 - De façon avantageuse, on peut éviter ce nouvel examen puisqu'une telle vérification a déjà été effectuée au préalable, avant la transmission par le CN 1 du message "support enregistrement". A cet effet, LUTRAN 4 peut incorporer dans le message INITIAL UE une indication selon laquelle le CN 1 a déjà vérifié qu'il convenait pour l'enregistrement de l'UE 7. Le CN 1 recevant le message INITIAL UE peut alors dialoguer avec l'UE 7 à travers IUTRAN 4 pour exécuter la procédure standard, de mise à jour de localisation c'est-à-dire le déclenchement de la procédure standard d'authentification du terminal et le déclenchement du mode de sécurité, afin o que les transmissions ultérieures entre le CN et l'UE soient chiffrées conformément à des paramètres dérivés lors de l'authentification. Le CN 1 peut ensuite retourner au terminal un message LUA ("Location Updating Accept", 3GPP TS 24.008, v5.9.0, ≈4.4.4.6) s'il accepte sa mise à jour de localisation. Ce message indique à l'UE l'identité temporaire TMSI que le CN 1 vient de lui allouer. L'UTRAN le relaie à l'UE dans un message DOWNLINK DIRECT TRANSFER du protocole RRC (ETSI TS 125.331, v5.6. 0, ≈10.2.11). Conformément aux mécanismes luFlex, le TMSI a un champ NRI ("Network Resource Identifier", 3GPP TS 23.236, v5.2.0, ≈4.3) qui indique à l'UE des ressources de réseau à fournir pour le routage ultérieur desunités de données qu'il émettra. Ce champ NRI du TMSI alloué et transmis par le CN 1 désigne avantageusement des ressources du CN 1 dans ce cas. Par ailleurs, le CN 1 effectue la mise à jour de la localisation de l'UE 7 ("UPDATE LOCATION" sur la figure 2) auprès de son HLR 12, qui peut appartenir au même CN ou à un autre (voir norme ETSI TS 23.012, version 5.2.0, publiée en septembre 2003, ≈4.1). L'UE peut ensuite solliciter le CN 1 via IUTRAN s'il souhaite faire une requête de service. Il est cependant possible que le CN 1 n'effectue pas l'enregistrement de l'UE 7, même si ce CN 1 convient pour un tel enregistrement. Dans ce cas, il peut avantageusement retourner à l'UE 7 un message de rejet ("Location Updating Reject", 3GPP TS 24.008, v5.9.0, ≈4.4.4.7). L'invention a été décrite ci-dessus dans son application au domaine CS. Naturellement, les mêmes procédures sont transposables au domaine PS, seuls les noms des messages étant différents. L'invention qui a été décrite a pour avantage que le routage des requêtes d'enregistrement des UE "pré-release 6" dans un contexte MOCN ne requiert pas d'adaptation particulière au niveau de l'UE. En outre, les commutateurs des CN requièrent une adaptation assez légère, consistant essentiellement en un support d'un échange de signalisation supplémentaire avec l'UTRAN partagé, en mode non connecté. o De plus, grâce à l'utilisation de transmissions sans connexion entre l'UTRAN partagé et les différents CN pour savoir lequel ou lesquels parmi les CN conviennent pour la mise en oeuvre de l'enregistrement d'un UE, on réduit de façon notable le temps nécessaire pour identifier le CN auprès duquel l'UE sera enregistré finalement. On minimise ainsi le risque que la temporisation déclenchée par l'UE à l'émission de sa requête LUR vienne à expiration. Le gain en temps est particulièrement significatif lorsque le système de radiocommunication comprend un nombre élevé de réseaux coeurs. La possibilité d'interrogation en parallèle des différents CN en mode non connecté améliore encore ce gain. 2869186 -16- REVENDICATIONS 1. Procédé pour enregistrer un terminal radio (7) auprès d'un système cellulaire de radiocommunication comprenant un groupe de réseaux coeurs (1-3) et un réseau d'accès radio (4) partagé entre les réseaux coeurs du groupe, le procédé comprenant les étapes suivantes: - émettre une requête d'enregistrement du terminal vers le réseau d'accès radio partagé ; effectuer une transmission sans connexion d'un message depuis le réseau d'accès radio partagé vers au moins un réseau coeur du groupe, ledit message requérant une indication relative à un support de l'enregistrement du terminal par ledit réseau coeur du groupe; - effectuer une transmission sans connexion d'une réponse audit message depuis chaque réseau coeur du groupe ayant reçu ledit message; et - lorsque le réseau d'accès radio partagé reçoit, depuis un ensemble de réseaux coeurs du groupe, des réponses indiquant le support de l'enregistrement du terminal par respectivement chaque réseau coeur dudit ensemble, relayer ladite requête d'enregistrement du terminal vers l'un au moins parmi les réseaux coeurs dudit ensemble. 2. Procédé selon la revendication 1, dans lequel ledit ensemble de réseaux coeurs du groupe est constitué d'un unique réseau coeur. 3. Procédé selon la revendication 1 ou 2, dans lequel la transmission sans connexion d'un message depuis le réseau d'accès radio partagé est effectuée vers au moins deux réseaux coeurs du groupe sensiblement simultanément. 4. Procédé selon la revendication 3, dans lequel, lorsque chacun des réseaux coeurs du groupe ayant reçu ledit message effectue une transmission sans connexion d'une réponse audit message indiquant qu'il ne supporte pas l'enregistrement du terminal, on relaye ladite requête d'enregistrement du terminal vers l'un parmi lesdits réseaux coeurs du groupe ayant reçu ledit message. 5. Procédé selon la revendication 1 ou 2, dans lequel la transmission sans connexion d'un message depuis le réseau d'accès radio partagé est effectuée vers un seul réseau coeur du groupe à la fois. 6. Procédé selon la revendication 5, dans lequel la transmission sans connexion d'un message depuis le réseau d'accès radio partagé est d'abord effectuée vers un premier réseau coeur du groupe, et dans lequel la transmission sans connexion d'un message depuis le réseau d'accès radio partagé vers un second réseau coeur du groupe est effectuée seulement lorsque le réseau d'accès radio partagé a reçu une réponse audit message transmise depuis le premier réseau coeur, indiquant une absence de support de l'enregistrement du terminal par ledit premier réseau coeur. 7. Procédé selon la revendication 5 ou 6, dans lequel la transmission sans connexion d'un message depuis le réseau d'accès radio partagé est effectuée vers un seul réseau coeur du groupe à la fois jusqu'à un avantdernier réseau coeur du groupe, et dans lequel, lorsque chacun des réseaux coeurs du groupe ayant reçu ledit message a effectué une transmission sans connexion d'une réponse audit message indiquant qu'il ne supporte pas l'enregistrement du terminal, on relaie ladite requête d'enregistrement du terminal vers un dernier réseau coeur du groupe. 8. Procédé selon l'une quelconque des revendications précédentes, dans lequel, avant de transmettre une réponse audit message, chaque réseau coeur du groupe ayant reçu ledit message vérifie s'il supporte l'enregistrement du terminal, ladite vérification étant effectuée à partir d'une information relative à une identité du terminal. 9. Procédé selon la revendication 8, dans lequel l'information relative à une identité du terminal est incluse dans la requête d'enregistrement du terminal et retransmise aux réseaux coeurs du groupe avec ledit message. 10. Procédé selon la revendication 9, dans lequel l'information relative à une identité du terminal incluse dans la requête d'enregistrement du terminal est une identité temporaire du terminal, et dans lequel ladite vérification est effectuée par chaque réseau coeur du groupe à partir d'une identité fixe du terminal obtenue à partir de ladite identité temporaire du terminal. 11. Procédé selon la revendication 9, dans lequel l'information relative à une identité du terminal incluse dans la requête d'enregistrement du terminal est une identité temporaire du terminal, et dans lequel, lorsqu'un réseau coeur du groupe ne parvient pas à obtenir une identité fixe du terminal à partir de ladite identité temporaire du terminal, on effectue une transmission sans connexion d'une réponse audit message depuis ledit réseau coeur du groupe, ladite réponse rejetant ledit message, et dans lequel on relaie ladite requête d'enregistrement du terminal vers ledit réseau coeur du groupe lorsque ladite réponse rejetant ledit message a été reçue au réseau d'accès radio partagé. 12. Procédé selon l'une quelconque des revendications précédentes, dans lequel, après avoir reçu ladite requête d'enregistrement relayée du terminal à un réseau coeur dudit ensemble, on enregistre le terminal audit réseau coeur dudit ensemble. 13. Procédé selon la revendication 12, dans lequel on enregistre le terminal audit réseau coeur dudit ensemble sans vérification supplémentaire du support de l'enregistrement du terminal par ledit réseau coeur. 14. Procédé selon la revendication 13, dans lequel l'absence de vérification supplémentaire du support de l'enregistrement du terminal par ledit réseau coeur résulte de la présence d'une indication correspondante dans ladite requête d'enregistrement relayée du terminal audit réseau coeur. 15. Réseau d'accès radio (4) d'un système cellulaire de radiocommunication comprenant en outre un groupe de réseaux coeurs (1-3), ledit réseau d'accès radio étant partagé entre les réseaux coeurs du groupe et comprenant, relativement à un terminal radio (7) : - des moyens pour détecter une requête d'enregistrement émise par le terminal; - des moyens pour effectuer une transmission sans connexion d'un message vers au moins un réseau coeur du groupe, ledit message requérant une indication relative à un support de l'enregistrement du terminal par ledit réseau coeur du groupe; des moyens pour recevoir une réponse audit message transmise sans connexion depuis chaque réseau coeur du groupe ayant reçu ledit message; et des moyens, sur réception, depuis un ensemble de réseaux coeurs du groupe, de réponses indiquant le support de l'enregistrement du terminal par respectivement chaque réseau coeur dudit ensemble, pour relayer ladite requête d'enregistrement du terminal vers l'un au moins parmi les réseaux coeurs dudit ensemble. 16. Réseau d'accès radio (4) selon la revendication 15, dans lequel ledit ensemble de réseaux coeurs du groupe est constitué d'un unique réseau coeur. 17. Réseau d'accès radio (4) selon la revendication 15 ou 16, dans lequel les moyens pour effectuer une transmission sans connexion d'un message vers au moins un réseau coeur du groupe sont agencés pour effectuer une transmission vers au moins deux réseaux coeurs du groupe sensiblement simultanément. 18. Réseau d'accès radio (4) selon la revendication 17, comprenant en outre des moyens pour relayer ladite requête d'enregistrement du terminal vers l'un parmi lesdits réseaux coeurs du groupe ayant reçu ledit message, lorsque chacun des réseaux coeurs du groupe ayant reçu ledit message effectue une transmission sans connexion d'une réponse audit message indiquant qu'il ne supporte pas l'enregistrement du terminal. 19. Réseau d'accès radio (4) selon la revendication 15 ou 16, dans lequel les moyens pour effectuer une transmission sans connexion d'un message vers au moins un réseau coeur du groupe sont agencés pour effectuer une transmission sans connexion d'un message depuis le réseau d'accès radio partagé vers un seul réseau coeur du groupe à la fois. 20. Réseau d'accès radio (4) selon la revendication 19, dans lequel les moyens pour effectuer une transmission sans connexion d'un message vers au o moins un réseau coeur du groupe sont agencés pour effectuer d'abord une transmission vers un premier réseau coeur du groupe, puis une transmission vers un second réseau coeur du groupe seulement lorsque le réseau d'accès radio partagé a reçu une réponse audit message transmise depuis le premier réseau coeur, indiquant une absence de support de l'enregistrement du terminal par ledit premier réseau coeur. 21. Réseau d'accès radio (4) selon la revendication 19 ou 20, dans lequel les moyens pour effectuer une transmission sans connexion d'un message vers au moins un réseau coeur du groupe sont agencés pour effectuer une transmission sans connexion d'un message depuis le réseau d'accès radio partagé vers un seul réseau coeur du groupe à la fois jusqu'à un avantdernier réseau coeur du groupe, et comprenant en outre des moyens, lorsque chacun des réseaux coeurs du groupe ayant reçu ledit message a effectué une transmission sans connexion d'une réponse audit message indiquant qu'il ne supporte pas l'enregistrement du terminal, pour relayer ladite requête d'enregistrement du terminal vers un dernier réseau coeur du groupe. 22. Réseau d'accès radio (4) selon l'une quelconque des revendications 15 à 21, dans lequel une information relative à une identité du terminal est incluse dans la requête d'enregistrement émise par le terminal et retransmise aux réseaux coeurs du groupe avec ledit message. 23. Réseau d'accès radio (4) selon la revendication 22, dans lequel l'information relative à une identité du terminal incluse dans la requête d'enregistrement du terminal est une identité temporaire du terminal, et comprenant en outre des moyens, lorsqu'un réseau coeur du groupe ne parvient pas à obtenir une identité fixe du terminal à partir de ladite identité temporaire du terminal, pour recevoir une transmission sans connexion d'une réponse audit message depuis ledit réseau coeur du groupe, ladite réponse rejetant ledit message, et comprenant des moyens pour relayer ladite requête d'enregistrement du terminal vers ledit réseau coeur du groupe lorsque ladite o réponse rejetant ledit message a été reçue au réseau d'accès radio partagé. 24. Réseau d'accès radio (4) selon l'une quelconque des revendications 15 à 23, dans lequel les moyens, sur réception, depuis un ensemble de réseaux coeurs du groupe, de réponses indiquant le support de l'enregistrement du terminal par respectivement chaque réseau coeur dudit ensemble, pour relayer ladite requête d'enregistrement du terminal vers l'un au moins parmi les réseaux coeurs dudit ensemble, comprennent des moyens pour incorporer dans ladite requête d'enregistrement relayée une indication selon laquelle aucune vérification supplémentaire du support de l'enregistrement du terminal ne doit être effectuée par les réseaux coeurs dudit ensemble. 25. Réseau coeur d'un groupe de réseaux coeurs (1-3) d'un système cellulaire de radiocommunication comprenant en outre un réseau d'accès radio (4) partagé entre les réseaux coeurs du groupe, ledit réseau coeur comprenant, relativement à un terminal radio (7) agencé pour émettre une requête d'enregistrement vers le réseau d'accès radio partagé : - des moyens pour recevoir un message transmis sans connexion depuis le réseau d'accès radio partagé, ledit message requérant une indication relative à un support de l'enregistrement du terminal par ledit réseau coeur; - des moyens pour effectuer une transmission sans connexion d'une réponse audit message, ladite réponse incluant l'indication relative à un support de l'enregistrement du terminal par ledit réseau coeur; et - des moyens pour recevoir ladite requête d'enregistrement du terminal relayée par le réseau d'accès radio partagé. 26. Réseau coeur selon la revendication 25, comprenant en outre des moyens pour vérifier s'il supporte l'enregistrement du terminal, ladite vérification étant effectuée à partir d'une information relative à une identité du terminal. 27. Réseau coeur selon la revendication 26, dans lequel l'information relative à une identité du terminal est incluse dans la requête d'enregistrement du terminal, ledit réseau coeur comprenant des moyens pour recevoir ladite information relative à une identité du terminal avec ledit message depuis le réseau d'accès radio partagé. 28. Réseau coeur selon la revendication 27, dans lequel l'information relative à une identité du terminal incluse dans la requête d'enregistrement du terminal est une identité temporaire du terminal, et dans lequel les moyens pour vérifier si ledit réseau coeur supporte l'enregistrement du terminal sont mis en oeuvre à partir d'une identité fixe du terminal obtenue à partir de ladite identité temporaire du terminal. 29. Réseau coeur selon la revendication 28, dans lequel l'information relative à une identité du terminal incluse dans la requête d'enregistrement du terminal est une identité temporaire du terminal, et comprenant des moyens pour, lorsque ledit réseau coeur du groupe ne parvient pas à obtenir une identité fixe du terminal à partir de ladite identité temporaire du terminal, effectuer une transmission sans connexion d'une réponse audit message depuis ledit réseau coeur du groupe, ladite réponse rejetant ledit message. 30. Réseau coeur selon l'une quelconque des revendications 25 à 29, comprenant en outre des moyens pour enregistrer le terminal après réception de ladite requête d'enregistrement du terminal relayée par le réseau d'accès radio partagé. 31. Réseau coeur selon la revendication 30, comprenant des moyens pour détecter, dans ladite requête d'enregistrement relayée du terminal, la présence d'une indication visant à inhiber une vérification supplémentaire du support de l'enregistrement du terminal par ledit réseau coeur, et comprenant des moyens pour inhiber une vérification supplémentaire du support de l'enregistrement du terminal par ledit réseau coeur lorsque ladite indication est détectée. 32. Réseau coeur selon l'une quelconque des revendications 25 à 31, dans lequel lesdits moyens sont mis en oeuvre par au moins un commutateur appartenant au réseau coeur.