FR2805430A1 - Procede de gestion de mobilite dans un reseau de telecommunications, et serveur de mobilite pour la mise en oeuvre du procede - Google Patents

Abstract

Le réseau comporte plusieurs sous-réseaux (11-13) équipés de serveurs de mobilité (8) fonctionnant selon un protocole de signalisation de couche application. Pour un utilisateur mobile donné, l'un des sous-réseaux (11) constitue un sous-réseau nominal et est équipé d'un registre nominal (9) contenant une première information de localisation de l'utilisateur. Lorsque l'utilisateur mobile est localisé auprès d'un point d'accès (7) relié à un sous-réseau visité (12), la première information de localisation désigne le serveur de mobilité de ce sous-réseau visité, le serveur de mobilité du sous-réseau visité tient dans un registre de visiteurs (10) une seconde information de localisation de l'utilisateur mobile, permettant de lui transmettre des informations à travers ledit point d'accès, et chaque flux d'information destiné à ou provenant de l'utilisateur mobile, dans le cadre d'une communication avec un correspondant distant, est adressé au serveur de mobilité du sous-réseau visité.

Description

PROCEDE <U>DE GESTION DE</U> MOBILITE <U>DANS UN</U> RESEAU <U>DE</U> TELECOMMUNICATIONS, <U>ET SERVEUR DE</U> MOBILITE <U>POUR LA MISE EN</U> CEUVRE <U>DU</U> PROCEDE La présente invention concerne les services de mobilité d'utilisateur, et trouve notamment application dans les réseaux de télécommunications comprenant plusieurs sous-réseaux interconnectés.

La mobilité d'utilisateur dont il est question ici consiste en la capacité offerte à l'utilisateur de communiquer par le réseau en se raccordant à celui-ci en différents points d'accès. L'utilisateur peut ainsi emporter son terminal lorsqu'il se déplace. C'est le cas typique d'un réseau de radiocommunication avec les mobiles, les points d'accès étant constitués par les relais fixes. Sans déplacer d'équipement, l'utilisateur peut aussi se connecter en différents points par une procédure d'inscription comprenant la transmission, à un organe de gestion de mobilité, de données d'identification fournies par l'utilisateur. Une autre possibilité est que l'utilisateur dispose d'un support de données amovible qu'il présente au point d'accès visité équipé d'un lecteur approprié pour automatiser la procédure d'inscription.

On peut distinguer deux types de mobilité, l'une appelée ici micromobilité consistant à permettre à l'utilisateur de changer de point d'accès à l'intérieur d'un sous-réseau, et l'autre appelée ici macromobilité par laquelle l'utilisateur peut se raccorder par l'intermédiaire de points d'accès appartenant à des sous-réseaux distincts.

On distingue d'autre part la capacité d'un utilisateur de changer de point d'accès en dehors d'une session, c'est-à-dire en l'absence de flux de données actif ( roaming ), et la capacité d'un utilisateur équipé d'un terminal sans fil de changer de point d'accès en cours de session ( handover ).

Aux fins de l'administration du réseau, chaque utilisateur mobile a généralement un sous-réseau nominal auquel est connecté un organe appelé ici registre de localisation nominal, auquel sont initialement adressées les requêtes concernant l'utilisateur et provenant de sources qui ne connaissent pas sa localisation. Lorsqu'il se déplace dans un autre sous-réseau, un autre organe connecté à ce sous-réseau visité, appelé ici gestionnaire de visiteurs, peut coopérer avec le registre de localisation nominal pour la mise en oeuvre des services de mobilité. Le développement des applications sur les réseaux fonctionnant selon le protocole IP (J. Postel, Internet Protocol , Request For Comments (RFC) 791, IETF, septembre 1981), notamment celles de transport de la voix et de données, contemporain à l'essor des systèmes de communication avec les mobiles, a naturellement conduit à considérer la question de la mobilité dans les réseaux IP, qu'il s'agisse de réseaux étendus, (WAN, Wide Area Network ), tel que le réseau Internet, ou de réseaux locaux (LAN, Local Area Network ).

L'organisation IETF ( Internet Engineering Task Force ) a normalisé un protocole de couche réseau supportant la mobilité dans un réseau IP (C. Perkins, IP Mobility Support , RFC 2002, IETF, octobre 1996). Après que l'utilisateur mobile a quitté son sous-réseau nominal, son équipement s'adresse à un organe appelé agent étranger ( foreign agent ), connecté au sous-réseau visité, pour envoyer une information d'inscription vers un organe appelé agent nominal ( home agent ), connecté au sous-réseau nominal. L'identité du sous-réseau visité est également fournie à l'agent nominal. L'une des principales fonctions de l'agent nominal est alors d'intercepter les données destinées à l'utilisateur mobile pour les retransmettre, par un mécanisme d'encapsulation, vers une adresse temporaire de l'utilisateur mobile (dite adresse c/o ou care-of address ) fournie par l'agent étranger. Une fois parvenues à cette adresse temporaire, les données peuvent être remises à leur destinataire.

Ce schéma de mobilité impose ainsi un chemin triangulaire aux paquets IP à destination de l'utilisateur mobile. En revanche, les données en provenance de l'utilisateur mobile sont remises à leur destination par l'intermédiaire des mécanismes usuels de routage IP.

De plus, il suppose l'utilisation d'une adresse fixe pour l'utilisateur mobile. Sa mise en couvre pose donc des difficultés dans des réseaux où la gestion d'adresse est dynamique, ce qui est le cas par exemple lorsqu'un serveur DHCP est utilisé dans le sous-réseau nominal (voir par exemple EP-A-0 938 217). Le protocole DHCP est spécifié dans la RFC 2131 publiée par l'IETF (R. Droms, Dynamic Host Configuration Protocol , mars 1997).

Un procédé d'optimisation de chemin, conçu comme une extension du protocole de la RFC 2002 a été proposé (C. Perkins, D. Johnson, Route Optimization in Mobile IP , Internet Draft, IETF, 25 février 1999) afin de pallier les inconvénients du mode de routage triangulaire. Ce procédé prévoit notamment l'envoi de messages de mise à jour permettant aux éventuels correspondants d'un utilisateur mobile de conserver en mémoire les adresses temporaires c/o de ce dernier. Ceux-ci peuvent alors émettre directement vers l'adresse temporaire de l'utilisateur mobile, évitant ainsi les opérations effectuées sur les données par l'agent nominal.

Certains auteurs ont critiqué la complexité de mise en oeuvre d'un tel procédé, et ont suggéré de supporter la mobilité sous IP en utilisant un protocole de signalisation de couche application tel que le protocole SIP (M. Handley et al., SIP : Session Initiation Protocol , RFC 2543, IETF, mars 1999).

SIP décrit des entités clients et serveurs, ainsi que des procédures leur permettant de communiquer (voir aussi H.G. Schulzrinne et J.D. Rosenberg, The Session Initiation Protocol : Providing Advanced Telephony Services Across the Internet , Bell Labs Technical Journal, octobre-décembre 1998, pages 144-159). On distingue deux types de serveurs SIP : les serveurs proxy et les serveurs de redirection. A réception d'une requête, un serveur proxy détermine le prochain noeud du chemin vers le destinataire puis transfère la requête vers ce noeud, alors qu'un serveur de redirection se contente d'indiquer au client le prochain noeud auquel il doit adresser sa requête.

Les adresses SIP sont similaires à des adresses de messagerie électronique, c'est-à-dire de la forme user(ahost, où le champ user désigne par exemple un nom d'utilisateur ou un numéro de téléphone, et le champ host un nom de domaine ou une adresse sous forme numérique. Le protocole SIP prévoit notamment des méthodes appelées INVITE, BYE, REGISTER, OPTIONS, ACK et CANCEL. Les réponses aux messages émis dans le cadre de ces méthodes sont définies par des classes de codes. La méthode INVITE est utilisée pour initialiser une session d'appel entre deux utilisateurs SIP.

Le protocole SIP prévoit des capacités de mobilité personnelle, et permet à un utilisateur d'obtenir les mêmes services indépendamment de sa localisation ou du terminal utilisé, notamment grâce aux méthodes REGISTER. II a été proposé (E. Wedlund, H. Schulzrinne, Mobility Support using SIP , Proc. of the 2"d ACM International Workshop on Wireless Mobile Multimedia, Seattle, 20 août 1999, pages 76-82) des procédés de mobilité utilisant le protocole SIP dans lesquels un équipement sans fil relié au réseau par l'intermédiaire d'une interface air peut, après des échanges de signalisation appropriés, exécuter un handover, c'est-à-dire changer d'adresse réseau (1P) par un mécanisme DHCP alors qu'une communication est en cours. Un serveur SIP connecté au sous-réseau nominal de l'utilisateur gère le registre de localisation nominal pour ce dernier. Les serveurs SIP utilisés dans la gestion de mobilité peuvent être des serveurs proxy ou des serveurs de redirection. Toute mobilité donne lieu à une inscription auprès du serveur SIP nominal, qui peut ensuite traiter les requêtes provenant des autres clients SIP à destination de l'utilisateur mobile. Lorsque l'équipement sans fil détermine le besoin d'exécuter un handover (par détection de balises émises par les points d'accès sans fil), il obtient une adresse dynamique par une transaction DHCP, puis il envoie un message INVITE à son correspondant en indiquant la référence de l'appel en cours et sa nouvelle adresse réseau pour que le correspondant mette à jour l'adresse IP de destination des paquets qu'il émet. Parallèlement, l'équipement sans fil communique sa nouvelle adresse à son serveur SIP nominal, par la méthode REGISTER. Une option prévoit une décentralisation des serveurs SIP utilisés dans la gestion de mobilité : un serveur SIP proxy connecté au sous-réseau visité gère la micromobilité, de sorte que les méthodes REGISTER vers le serveur SIP nominal, de redirection, peuvent ne concerner que la macromobilité (changement de serveur de micromobilité).

Le principal inconvénient du procédé est le retard qu'il peut introduire dans l'exécution du handover. La méthode INVITE vers le correspondant de l'utilisateur mobile requiert un temps d'acheminement non négligeable si ce correspondant est éloigné du sous-réseau visité. Ce retard peut entraîner une coupure perceptible de la communication en cours.

II est à noter qu'un inconvénient similaire existe dans le cadre du protocole de mobilité IP de la RFC 2002. Lorsque l'équipement mobile est relié à un sous-réseau visité distant du sous-réseau nominal, il est nécessaire de router un message de mise à jour de localisation vers l'agent nominal en cours d'exécution du handover, ce qui prend du temps. Si le protocole est mis en oeuvre avec le procédé d'optimisation de chemin précité, il s'y ajoute le temps nécessaire à l'acheminement d'un paquet de mise à jour d'adresse c/o vers le correspondant de l'utilisateur mobile.

Un but de la présente invention est de proposer une gestion de mobilité d'utilisateur qui permette de limiter les retards dus à la signalisation dans l'exécution de handovers.

Selon l'invention, il est proposé un procédé de gestion de mobilité dans un réseau de télécommunications comportant plusieurs sous-réseaux respectivement équipés de serveurs de mobilité fonctionnant selon un protocole de signalisation de couche application, dans lequel un des sous- réseaux constitue un sous-réseau nominal pour un utilisateur mobile et est équipé d'un registre nominal contenant une première information de localisation dudit utilisateur. Lorsque l'utilisateur mobile est localisé auprès d'un point d'accès relié à un sous-réseau visité, la première information de localisation désigne un serveur de mobilité dudit sous-réseau visité, ledit serveur de mobilité du sous-réseau visité tient dans un registre de visiteurs une seconde information de localisation de l'utilisateur mobile, permettant de lui transmettre des informations à travers ledit point d'accès, et chaque flux d'information destiné à ou provenant de l'utilisateur mobile, dans le cadre d'une communication avec un correspondant distant, est adressé audit serveur de mobilité du sous-réseau visité.

Un autre aspect de la présente invention se rapporte à un serveur de mobilité adapté à la mise en oeuvre du procédé ci-dessus. Ce serveur de mobilité est à relier à un sous-réseau appartenant à un réseau de télécommunications, et fonctionne selon un protocole de signalisation de couche application. II comprend des moyens de gestion d'un registre de visiteurs contenant, pour au moins un utilisateur mobile localisé auprès d'un point d'accès relié audit sous-réseau, une information de localisation de l'utilisateur mobile, permettant de lui transmettre des informations à travers ledit point d'accès, des moyens pour recevoir des flux d'information provenant de l'utilisateur mobile dans le cadre d'une communication avec un correspondant distant et les retransmettre à destination du correspondant distant, et des moyens pour recevoir des flux d'information provenant du correspondant distant dans le cadre de ladite communication et les retransmettre à l'utilisateur mobile.

Le serveur de mobilité du sous-réseau visité joue un rôle d'agent proxy à la fois pour les flux de signalisation, concernant notamment la mobilité de l'utilisateur, et pour les flux de trafic (voix, images, données, ... ). Ainsi, lors d'un handover, seuls les flux locaux entre le serveur de mobilité et l'utilisateur sont affectés. L'utilisateur mobile voit le serveur proxy comme étant son correspondant, de sorte que c'est à lui qu'il s'adresse pour signaler son changement de point d'accès. En revanche, rien n'est changé pour les échanges entre le serveur et le correspondant distant. Il n'est pas nécessaire que de l'information de signalisation soit envoyée à distance pendant le handover, vers le sous-réseau nominal ou vers le correspondant. Comme en général l'acheminement des messages à l'intérieur d'un sous-réseau est très rapide, il en résulte une optimisation du temps d'exécution du handover.

Ce procédé de gestion de mobilité n'implique en lui-même aucune adaptation particulière au niveau des terminaux communiquant avec l'équipement mobile.

Le procédé peut être appliqué avec divers protocoles de signalisation de couche application. Actuellement, SIP est un protocole préféré car il constitue un bon compromis entre richesse fonctionnelle et complexité de mise en oeuvre, tout en ayant une bonne capacité d'extension. D'autres exemples, bien connus de l'homme du métier, sont les protocoles H.225.0 ( Call signalling protocols and media stream packetization for packet-based multimedia communication systems ) et H.245 ( Control protocol for multimedia communication ) spécifiés par l'Union Internationale des Télécommunications (UIT-T) dans le cadre de la Recommandation H.323 ( Packet-based multimedia communications systems , février 1998), et le protocole MGCP (M. Arango et al., Media Gateway Controller Protocol (MGCP) , RFC 2705, IETF, octobre 1999) ou sa variante Megaco (F. Cuervo et al., Megaco Protocol , Internet Draft, IETF, 8 février 2000).

La première information de localisation mémorisée dans le registre nominal de l'utilisateur sera typiquement l'adresse IP du serveur de mobilité du sous-réseau visité, mise à jour seulement lorsque le déplacement de l'utilisateur lui fait changer de sous-réseau visité (et éventuellement lorsque le sous-réseau visité comporte plusieurs serveurs de mobilité et que l'utilisateur mobile change de serveur de mobilité sans changer de sous-réseau visité). Le serveur de mobilité du sous-réseau nominal pourra alors être un serveur de redirection vers celui du sous-réseau visité.

La seconde information de localisation mémorisée dans le registre de visiteurs dépend quant à elle de l'architecture du sous-réseau visité. Elle peut consister en une adresse physique de couche MAC ( Medium Access Control ), permettant d'atteindre l'utilisateur mobile à travers le point d'accès. Elle peut aussi être une adresse IP de l'utilisateur mobile dans le sous-réseau visité, par exemple une adresse dynamique obtenue auprès d'un serveur DHCP du sous-réseau visité ou une adresse IP composite (sous- réseau + adresse d'équipement) de la version 6 du protocole IP (IPv6). Si le sous-réseau visité est un LAN lui-même subdivisé en sous-sous-réseaux interconnectés à travers des routeurs, on peut également envisager d'utiliser, à l'intérieur du sous-réseau visité, un protocole de mobilité de couche réseau tel que celui de la RFC 2002, le serveur de mobilité jouant le rôle d'agent nominal pour retransmettre les paquets destinés à l'utilisateur mobile, par un mécanisme d'encapsulation, vers une adresse c/o fournie par un agent étranger connecté au sous-sous-réseau comportant le point d'accès courant de l'équipement mobile, cette adresse c/o de l'utilisateur mobile étant alors enregistrée en tant que seconde information de localisation.

Le procédé ci-dessus permet de minimiser le temps d'exécution d'un handover n'impliquant pas de changement du serveur proxy gérant localement la mobilité de l'utilisateur. Ceci est largement le cas le plus fréquent puisque on pourra souvent avoir un seul serveur de mobilité par site (sous-réseau) pour les visiteurs et les handovers se produisent normalement à l'intérieur d'un même site. II peut toutefois y avoir des cas dans lesquels un même site est pourvu de plusieurs serveurs de mobilité, soit parce qu'il y a plusieurs sous- réseaux sur le site, soit parce que des serveurs multiples sont prévus pour des raisons de partage de charge. Dans un tel cas, lorsqu'un équipement mobile détecte en cours de session un nouveau point d'accès associé à un serveur de mobilité différent de celui qui jouait le rôle de proxy avant le handover, il reste nécessaire d'échanger des messages entre le nouveau serveur de mobilité et le correspondant distant, afin que ce dernier prenne en compte un changement d'adresse IP où envoyer ses paquets. Dans ce dernier cas, des moyens supplémentaires doivent être employés si on souhaite minimiser le temps d'exécution du handover.

L'un de ces moyens consiste à inclure, dans un signal de balise émis sur une interface air par au moins un point d'accès auprès duquel l'utilisateur mobile est susceptible d'être localisé, et/ou dans au moins un message transmis sur l'interface air par ledit point d'accès vers l'utilisateur mobile dans le cadre d'une procédure d'inscription d'un protocole propre à l'interface air, une adresse de réseau d'un serveur de mobilité associé audit point d'accès.

Ainsi, la première action de l'équipement mobile après son inscription auprès du point d'accès pourra être d'envoyer, au serveur de mobilité dont il a obtenu l'adresse réseau (1P), le message lui permettant de mettre à jour sa localisation. Le déroulement du handover ne sera pas retardé par des échanges supplémentaires visant à l'obtention de cette adresse IP.

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 d'un réseau de télécommunications auquel l'invention est appliquée ; - les figures 2 à 4 sont des diagrammes illustrant des échanges de messages intervenant dans la gestion de mobilité selon un mode de réalisation de l'invention ; - la figure 5 est un schéma d'un sous-réseau auquel une réalisation de l'invention peut s'appliquer; - la figure 6 est un diagramme illustrant des échanges de messages pouvant intervenir dans la gestion de mobilité au sein d'un sous-réseau selon la figure 5 ; et - les figures 7 et 8 sont des diagrammes montrant des exemples de blocs d'information qui peuvent être transmis par des points d'accès sans fil dans une réalisation de l'invention.

La figure 1 montre schématiquement un réseau Intranet réparti sur trois sites 1, 2, 3. Sur chaque site, un sous-réseau 11, 12, 13 est installé pour offrir des accès à un certain nombre d'utilisateurs. Ces sous-réseaux 11-13 sont par exemple de type Ethernet (norme ISO 8802-3, Local Area Networks, Part 3 - Carrier Sense Multiple Access with Collision Detection - Access Method and Physical Layer Specifications ), et fonctionnent selon le protocole de réseau IP. Dans l'exemple représenté, chaque sous-réseau a un routeur de sortie 4 relié à un réseau dorsal 5 tel que le réseau Internet.

Le réseau peut être notamment prévu pour supporter des communications de signaux en temps réel, par exemple de téléphonie, entre des utilisateurs qui lui sont raccordés et/ou avec des correspondants accessibles par le réseau dorsal 5. Dans ce cas, les terminaux peuvent utiliser de façon connue le protocole de couche transport UDP (J. Postel, User Datagram Protocol , RFC 768, IETF, août 1980) et le protocole en temps réel RTP (H. Schulzrinne et al., RTP: A Transport Protocol for Real-Time Applications , RFC 1889, IETF, janvier 1996) pour la transmission de la parole codée ou de la vidéo. Pour la signalisation d'appel, une réalisation préférée de l'invention fait appel au protocole SIP, qui fonctionne également avec le protocole de transport UDP. Toutefois, d'autres protocoles de signalisation (H.323, MGCP, ... ) seraient utilisables, en complément ou à la place de SIP.

Certains au moins des utilisateurs du réseau sont des utilisateurs mobiles équipés de terminaux sans fil 6. Pour leur permettre d'accéder au réseau, celui-ci comporte des points d'accès radio 7 raccordés aux sous- réseaux 11-13. Les points d'accès radio 7 sont par exemple des stations de base DECT (norme de l'ETSI, European Telecommunications Standards Institute ) ou encore selon la norme IEEE 802.11, etc., selon le type de terminaux sans fil utilisés. Chacun de ces points d'accès radio 7 diffuse un signal de balise sur l'interface air. Sur la base des signaux de balise qu'il capte, un terminal actif sélectionne le point d'accès qui lui fournit le meilleur lien radio. Ce point d'accès est utilisé pour les communications mettant en jeu le terminal.

Un terminal sans fil a ainsi la possibilité de se connecter au réseau par l'intermédiaire de plusieurs points d'accès 7 appartenant à des sous-réseaux différents (macromobilité) ou au même sous-réseau (micromobilité). Lorsque le terminal a une communication en cours et se déplace dans un site, il lui est possible de changer de point d'accès tout en maintenant la continuité de la communication (handover). Lorsqu'une communication de signaux en temps réel, par exemple de téléphonie, est en cours, il est souhaitable que ces handovers soient exécutés en un temps minimal afin d'éviter les coupures perceptibles.

Pour la gestion des services de mobilité, chaque sous-réseau (au moins ceux ayant des points d'accès sans fil) possède un serveur de mobilité 8 utilisant le protocole SIP dans la réalisation préférée de l'invention.

Chaque utilisateur mobile a un sous-réseau nominal. Dans l'illustration de la figure 1, le sous-réseau 11 est nominal pour le détenteur du terminal sans fil 6. Le serveur SIP 8 de ce sous-réseau est associé à un registre de localisation 9 dit registre nominal, qui contient l'adresse IP du serveur SIP 8 du sous-réseau 12 visité par l'utilisateur mobile. Le serveur SIP 8 du sous-réseau visité 12 est quant à lui associé à un registre de localisation 10 dit registre de visiteurs, qui contient une adresse permettant d'atteindre le terminal 6 à l'intérieur du sous-réseau visité 12, par exemple une adresse IP associée au terminal.

Chaque serveur SIP 8 peut être associé à un registre nominal 9 pour les utilisateurs rattachés à son sous-réseau et à un registre de visiteurs pour les utilisateurs rattachés à d'autres sous-réseaux, seuls les registres se rapportant au terminal 6 étant représentés sur la figure 1. En pratique, les registres 9, 10 peuvent faire partie de la même unité que le serveur SIP 8 auquel ils sont associés, ou ils peuvent être des entités distinctes reliées séparément au sous-réseau. D'autre part, il est possible de prévoir plusieurs serveurs SIP par sous-réseau, par exemple dans le cas où les fonctions de serveur SIP nominal et de serveur SIP visité sont assurées par des machines distinctes, ou dans le cas où plusieurs serveurs SIP sont prévus pour répartir la charge de signalisation dans le sous-réseau.

La figure 2 montre comment peut se dérouler l'inscription et la mise à jour de localisation d'un utilisateur mobile en visite dans un sous-réseau 12 différent de son sous-réseau nominal 11, et l'initialisation d'une communication avec cet utilisateur à l'initiative d'un correspondant distant.

Dans l'illustration de la figure 1, le correspondant distant utilise un terminal fixe 15 relié à un sous-réseau 13 différent du sous-réseau nominal 11 et du sous-réseau visité 12. On notera cependant qu'une procédure similaire s'applique également - si ce correspondant est un autre utilisateur mobile ; - s'il est connecté au sous-réseau 11 ou 12 ou au réseau dorsal 5 ; - si la liaison avec le correspondant passe par un autre réseau, par exemple un réseau téléphonique commuté, pour lequel le réseau Intranet est équipé d'une passerelle (dans ce dernier cas, c'est cette passerelle qui constitue le client SIP relatif au correspondant distant illustré par les figures 2 à 4).

En référence à la figure 2, le terminal sans fil 6 relevant du sous- réseau nominal 11 capte d'abord sur l'interface air le signal de balise émis par un point d'accès 7 appartenant au sous-réseau visité 12. En réponse à cette détection, il déclenche une procédure d'inscription du protocole de couche MAC employé sur l'interface air, en adressant au point d'accès un message d'inscription (Register). En réponse à ce message, le point d'accès 7 retourne un acquittement (Register Ack) validant l'inscription du terminal sans fil auprès du point d'accès.

Dans l'exemple de la figure 2, l'information de localisation du terminal sans fil enregistrée dans le registre de visiteurs 10 est une adresse IP dynamique obtenue par le terminal après son inscription auprès du point d'accès 7. Le sous-réseau 12 est équipé d'un serveur DHCP 16 qui gère localement les adresses dynamiques. Une transaction DHCP classique (messages DHCP_Discover, DHCP_Offer, DHCP_Request, DHCP Ack) est exécutée entre le terminal en itinérance 6 et le serveur DHCP 16, après quoi le terminal 6 dispose d'une adresse IP.

Dans une autre réalisation utilisant le protocole IPv6, la transaction DHCP est inutile puisque l'adresse IPv6 permet intrinsèquement une hiérarchie sous-réseau/équipement.

L'étape suivante consiste en l'envoi par le client SIP dont est pourvu le terminal 6 d'un message SIP REGISTER à destination du serveur SIP 8 du sous-réseau visité 12.

L'adresse IP du serveur SIP 8 a été fournie par le point d'accès 7 dans le signal de balise diffusé sur l'interface air, ce qui permet au terminal sans fil de disposer de cette adresse IP sans avoir eu à effectuer de transactions à cette fin par l'intermédiaire du sous-réseau 12. Si le signal de balise diffusé sur l'interface air ne comporte pas de champ disponible suffisamment grand pour contenir l'adresse IP du serveur SIP 8, celle-ci peut être complétée, ou fournie en totalité, dans le message Register Ack validant l'inscription du terminal sur l'interface air.

Le message SIP REGISTER envoyé par le terminal 6 permet au serveur SIP visité 8 de déterminer l'adresse IP du terminal, obtenue dans l'en tête IP du paquet contenant le message SIP REGISTER, et de l'associer à l'adresse SIP (de la forme user host) contenue dans le message SIP REGISTER. Cette association est enregistrée dans le registre 10.

Après avoir reçu ce message SIP REGISTER, le serveur SIP visité 8, s'il ne gère pas déjà l'utilisateur mobile, transmet un autre message SIP REGISTER vers le serveur SIP 8 du sous-réseau nominal 11. Celui-ci met à jour l'entrée du registre nominal 9 concernant l'utilisateur mobile identifié dans le message SIP REGISTER, en mémorisant l'adresse IP du serveur SIP visité qui a émis ce message SIP REGISTER. II retourne ensuite un message de validation (code 200 OK) du protocole SIP. Le serveur SIP visité renvoie à son tour au terminal 6, à travers le point d'accès 7, le message de validation 200 OK.

A ce stade, le terminal sans fil 6 a effectué son inscription auprès du point d'accès 7, et mis à jour sa localisation vis-à-vis des serveurs SIP 8.

A l'initialisation d'un appel provenant du correspondant distant 15, celui-ci émet à destination du serveur SIP 8 du sous-réseau nominal 11 de l'utilisateur mobile un message SIP INVITE demandant l'utilisateur mobile. Le serveur SIP nominal étant un serveur de redirection dans l'exemple considéré, il renvoie au correspondant distant un message SIP (code 302 Move) indiquant à celui-ci qu'il doit diriger sa méthode INVITE vers le serveur SIP du sous-réseau visité 12 dont il fournit l'adresse IP. Le correspondant transmet de nouveau le message SIP INVITE vers ce serveur SIP visité.

Le serveur SIP visité initialise alors une autre session avec l'utilisateur mobile, en lui transmettant un message SIP INVITE, que le terminal sans fil acquitte par un message SIP 200 OK s'il est disponible pour l'établissement de la communication. La session entre le terminal sans fil et le serveur SIP visité est ouverte lorsque ce dernier a reçu le message 200 OK. II retransmet alors vers le correspondant distant un autre message SIP 200 OK pour valider l'ouverture de la session avec celui-ci. A partir de ce moment, le correspondant distant communique avec le serveur SIP visité comme si ce dernier était le terminal sans fil, et le terminal sans fil communique avec le serveur SIP visité comme s'il était le terminal du correspondant distant. Dans chaque session ouverte avec le serveur SIP visité, des données (Data) sont échangées, typiquement selon la pile de protocole RTP/UDP/IP lorsqu'elles représentent de la parole codée ou de la vidéo, et de la signalisation supplémentaire peut être fournie selon la pile de protocole SIP/UDP/IP. Le serveur SIP visité 8 répercute vers le terminal sans fil 6 le flux RTP/UDP reçu du correspondant distant. De même, le flux de données RTP/UDP reçu dans la session établie avec le terminal sans fil est répercuté vers le correspondant distant. Le serveur SIP visité joue aussi ainsi un rôle d'agent proxy.

La figure 3 illustre l'inscription du terminal sans fil 6 auprès d'un autre point d'accès 7 du même sous-réseau visité 12, et la mise à jour de localisation effectuée auprès du serveur SIP de ce sous-réseau. L'inscription du terminal sans fil auprès du nouveau point d'accès radio s'effectue par une transaction de couche MAC identique à celle décrite en référence à la figure 2. Le cas échéant, une transaction DHCP (non représentée) peut être effectuée pour que le terminal acquière une nouvelle adresse IP. Le terminal sans fil envoie ensuite un message SIP REGISTER au serveur SIP visité, dont il a obtenu l'adresse dans la balise du nouveau point d'accès et/ou dans le message Register Ack. Comme le terminal sans fil ne change pas de serveur SIP visité, celui-ci n'a pas besoin d'envoyer un message SIP REGISTER vers le serveur SIP du sous-réseau nominal 11. Après avoir modifié l'entrée du registre de visiteurs 10 relative à l'utilisateur mobile, le serveur SIP visité valide sa mise à jour de localisation, en lui retournant un message SIP 200 OK.

Pour initialiser un appel vers un correspondant distant (partie inférieure de la figure 3), le terminal sans fil envoie un message SIP INVITE à son serveur SIP visité et celui-ci, qui joue toujours le rôle de serveur proxy, transmet un autre message SIP INVITE vers le serveur SIP nominal du correspondant appelé. Ce serveur SIP nominal, de redirection, retourne un message SIP 302 Move indiquant l'adresse IP à laquelle le correspondant peut être joint. Cette adresse IP peut être l'adresse du correspondant distant dans son sous-réseau nominal 13 ou, comme dans le cas de la figure 2, l'adresse d'un serveur SIP visité si le correspondant distant utilise un terminal sans fil en dehors de son sous-réseau nominal.

L'établissement de la communication se termine alors comme dans le cas de la figure 2. Des messages SIP 200 OK sont envoyés du correspondant distant vers le serveur SIP du sous-réseau visité 12, et de ce serveur SIP vers le terminal sans fil 6, après quoi le serveur SIP visité gère les deux flux UDP comme expliqué précédemment pour relayer la communication.

La figure 4 illustre la procédure de handover exécutée lorsque le terminal sans fil 6 a une communication en cours et change de point d'accès radio 7 en se déplaçant à l'intérieur du site visité 2. On suppose ici que le même serveur SIP visité 8 est associé aux deux points d'accès 7, c'est-à-dire que l'adresse IP de ce serveur 8 est indiquée dans le signal de balise de ces points d'accès et/ou dans le message Register Ack. La partie supérieure de la figure 4 montre les flux de données relayés par le serveur SIP visité comme expliqué précédemment.

Après que le terminal sans fil 6 a détecté la balise du nouveau point d'accès et décidé de changer de point d'accès, la procédure d'inscription auprès du nouveau point d'accès et de mise à jour de localisation auprès du serveur SIP visité est exécutée comme dans le cas de la figure 3. Lorsque le terminal sans fil a reçu l'acquittement de sa mise à jour de localisation (message SIP 200 OK), il adresse un message INVITE au serveur SIP visité, contenant notamment une référence de l'appel en cours. Après validation de le méthode INVITE (message SIP 200 OK retourné au terminal sans fil par le serveur SIP visité), l'échange de données reprend sans qu'il y ait eu la moindre signalisation du serveur SIP visité vers le serveur SIP nominal ou le correspondant distant.

L'exécution du handover est particulièrement rapide étant donné que les messages de signalisation échangés restent à l'intérieur du sous-réseau visité 12 sans avoir à être acheminés par le réseau d'interconnexion étendu 5.

D'autre part, le fait pour le terminal sans fil 6 de disposer directement de l'adresse IP du serveur SIP visité, dans la balise radio ou dans la signalisation de couche MAC radio, permet de gagner du temps en évitant un processus de recherche de cette adresse dans le réseau IP. La figure 5 montre schématiquement une autre architecture possible du sous-réseau installé sur le site visité 2, comprenant plusieurs sous-sous- réseaux 120, 121 interconnectés au moyen d'un ou plusieurs routeurs. Dans l'exemple dessiné, le routeur 4 relié au réseau dorsal 5 sert également à interconnecter les sous-sous- réseaux 120, 121.

Le serveur SIP 129 du sous-réseau visité, qui gère localement la mobilité du détenteur du terminal sans fil 6 de la manière précédemment expliquée, est relié à l'un des sous-sous-réseaux 120. II joue également le rôle d'agent nominal dans une adaptation du protocole Mobile IP faisant l'objet de la RFC 2002. Ce protocole Mobile IP adapté est mis en oeuvre à l'intérieur du sous-réseau visité afin de gérer dans la couche réseau la mobilité des utilisateurs entre les sous-sous-réseaux qui le composent (mais non à l'échelle du groupement de sous-réseaux, où on utilise un protocole de couche application, à savoir SIP dans l'exemple considéré). Dans la mesure où l'agent 129 n'appartient pas au sous-réseau nominal de l'utilisateur mobile, on l'appellera agent pseudo-nominal , et on dira qu'on met en ceuvre un protocole pseudo-mobile IP .

Dans chaque sous-sous-réseau 121 différent de celui pourvu de l'agent pseudo-nominal 129 et équipé d'un ou plusieurs points d'accès radio 7, un module de routage est prévu en tant qu'agent étranger 130 au sens de la RFC 2002.

Après que le terminal sans fil 6 a détecté la balise d'un nouveau point d'accès 7 appartenant à un tel sous-sous-réseau 121 et décidé de changer de point d'accès, la procédure d'inscription auprès du nouveau point d'accès est exécutée comme dans le cas de la figure 3 ou 4 (partie supérieure de la figure 6). Le terminal 6 émet ensuite une requête d'enregistrement du protocole Mobile IP (REGISTRATION REQUEST dans la terminologie de la RFC 2002) à destination de l'agent étranger 130, qui la relaie vers l'agent pseudo-nominal 129.

Le terminal 6 place dans le message REGISTRATION REQUEST, en plus de sa propre adresse IP, l'adresse IP de l'agent pseudo-nominal et l'adresse c/o qui lui a été préalablement fournie. Cette adresse c/o peut avoir été obtenue par les mécanismes de découverte d'agent spécifiés dans la RFC 2002. Mais dans une réalisation préférée, les deux adresses IP (celle de l'agent pseudo-nominal et l'adresse c/o) sont fournies dans le signal de balise diffusé par le point d'accès 7, et/ou dans le message Register Ack. L'adresse clo est alors une adresse IP de l'agent étranger 130, et peut être utilisée comme adresse de destination par le terminal pour l'envoi du message REGISTRATION REQUEST.

Après acquittement de la requête d'enregistrement (messages REGISTRATION REPLY de la figure 6), le terminal mobile émet son message SIP REGISTER pour mettre à jour sa localisation vis-à-vis du serveur SIP visité 129. Le message SIP REGISTER peut être envoyé directement à l'adresse IP du serveur SIP visité 129. Comme ce message est vu comme des données par le protocole Mobile IP, il peut également être relayé par l'agent étranger 130 vers le serveur SIP visité I agent pseudo-nominal 129. Pour acquitter la méthode SIP REGISTER (après un échange avec le serveur SIP du sous-réseau nominal 11 s'il y a eu changement de sous-réseau visité), le serveur SIP visité 129 utilise deux niveaux d'en-tête IP pour transmettre le message SIP 200 OK, le niveau interne ayant l'adresse IP du terminal sans fil 6 et le niveau externe ayant l'adresse c/o qui a été fournie par l'agent étranger 130. L'agent étranger 130 enlève le niveau externe pour retransmettre le message 200 OK vers le terminal.

Le même mécanisme d'encapsulation sera employé pour tous les paquets envoyés au terminal 6 par le serveur SIP visité 129 (protocole SIP ou données issues d'un correspondant distant). De même, les paquets émis par le terminal 6 sont relayés par l'agent étranger 130 vers leur destination, à savoir le serveur SIP visité 129 puisque celui-ci est vu par le terminal comme s'il était son correspondant.

La mise à jour de localisation exécutée selon la figure 6 intervient de la même manière dans le cas du roaming (figures 2 et 3) et dans le cas du handover (figure 4). L'information de localisation associée au terminal 6 dans le registre de visiteurs 10 consiste alors en l'adresse c/o qui permet au serveur SIP d'acheminer les données jusqu'à leur destination.

La figure 7 illustre une structure possible du signal de balise diffusé par un point d'accès sans fil 7 relié à un sous-réseau. Ce signal est formé par modulation d'un bloc de données numériques B, et est transmis dans une trame de signal radio, ou éventuellement dans un intervalle de temps d'une trame si un accès multiple à répartition dans le temps est employé sur l'interface air.

Les données numériques du bloc B comprennent un motif de synchronisation prédéterminé 20, dont la détection permet aux terminaux sans fil situés à portée du point d'accès de se synchroniser en temps et en fréquence pour démoduler le signal de la trame, et certains champs classiques 21-23 contenant des informations système requises par les -protocoles de couche physique et de couche liaison. Ces informations système comprennent typiquement - une identification du réseau auquel appartient le point d'accès (champ 21); - des informations de synchronisation système (champ 22), repérant la position de la trame courante dans l'organisation temporelle du signal radio émis sur la porteuse de 1a balise (index de trame dans une supertrame courante, numéro de supertrame, ...) ; - d'autres informations système (champ 23), comme par exemple un niveau de champ reçu minimal à partir duquel un terminal sans fil est autorisé à s'inscrire auprès du point d'accès, ou encore des indications des fréquences porteuses des signaux de balise de quelques points d'accès avoisinants pour que les terminaux puissent surveiller ces fréquences porteuses en vue de déterminer le point d'accès procurant le meilleur lien radio.

Avantageusement, le bloc B comprend en outre un champ 24 dans lequel le point d'accès 7 place des données décrivant son environnement.

Ces données peuvent représenter l'environnement géographique où est installé le point d'accès : emplacement du site visité 2, position précise du point d'accès (par exemple bâtiment, couloir, bureau,...). Comme le réseau est fondé sur le protocole IP dans lequel il n'y a aucune notion de connexion physique, une communication avec un terminal sans fil ne suppose aucune connaissance, même implicite, de la localisation géographique du terminal. Les correspondants distants et le registre de localisation nominal 9 ne situent le terminal que de manière logique, par l'intermédiaire d'une ou plusieurs adresses IP. Or un certain nombre d'applications peuvent avoir besoin de telles informations de localisation géographique, par exemple pour rendre des services différenciés selon le lieu où se trouve le terminal ou encore pour fournir une indication de ce lieu aux correspondants de l'utilisateur mobile. En insérant ces informations de localisation géographique (explicitement ou sous forme codée) dans le signal de balise, on les met à disposition des terminaux sans fil qui pourront ensuite les communiquer au serveur de mobilité du sous-réseau nominal ou à des correspondants dans le cadre d'applications de ce genre.

Les données d'environnement placées dans le champ 24 du bloc B peuvent également comprendre une ou plusieurs adresses IP d'organes de gestion de mobilité, à savoir - l'adresse IP du serveur SIP (ou H.323, MGCP, Megaco, ...) visité dans une réalisation selon les figures 1 à 4 ; - dans une réalisation selon les figures 5 et 6, l'adresse IP du serveur SIP (ou H.323, MGCP, Megaco, ... ) jouant aussi le rôle d'agent pseudo- nominal 129 et l'adresse IP de l'agent étranger 130 ; - dans une réalisation où la mobilité entre les sous-réseaux est gérée par un protocole de couche réseau tel celui de la RFC 2002, l'adresse IP de l'agent étranger, Les données d'environnement du champ 24 peuvent encore inclure un numéro de port UDP ou TCP utilisé par le serveur de mobilité 8, 129 associé au point d'accès, si ce n'est pas un numéro de port par défaut. Ceci permet au terminal d'envoyer directement au bon numéro de port les requêtes du protocole de signalisation de couche application. On peut également prévoir d'inclure dans les données d'environnement une adresse MAC (Ethernet) de l'organe de gestion de mobilité 8, 129 relié au même sous-réseau ou sous- sous-réseau que le point d'accès.

Si le champ 24 du bloc B ne procure pas assez de place pour insérer dans le signal de balise toutes les données d'environnement prévues, il est possible d'insérer certaines d'entre elles (voire la totalité) dans le message Register Ack de la figure 2, 3, 4 ou 6. Dans l'exemple illustré par la figure 8, ce message Register Ack est formé à partir d'un bloc de données numériques B' comportant - un champ 25 identifiant la requête d'enregistrement précédente et/ou le terminal sans fil qui l'a émise ; - un champ 26 contenant des codes indiquant la réponse à la requête d'inscription (accès autorisé, refusé ou conditionné, paramètres, ... ) ; - un champ éventuel 27 pour contenir des informations système complémentaires en plus de celles fournies dans les champs 21-23 du bloc B ; - un champ 28 pour répéter les données d'environnement ou fournir celles qui ne l'ont pas été dans le champ 24 du bloc B.

Claims (13)

REVENDICATIONS

1. Procédé de gestion de mobilité dans un réseau de télécommunications comportant plusieurs sous-réseaux (11-13) respectivement équipés de serveurs de mobilité (8) fonctionnant selon un protocole de signalisation de couche application, dans lequel un des sous- réseaux (11) constitue un sous-réseau nominal pour un utilisateur mobile et est équipé d'un registre nominal (9) contenant une première information de localisation dudit utilisateur, dans lequel lorsque l'utilisateur mobile est localisé auprès d'un point d'accès (7) relié à un sous-réseau visité (12), la première information de localisation désigne un serveur de mobilité dudit sous-réseau visité, ledit serveur de mobilité du sous-réseau visité tient dans un registre de visiteurs (10) une seconde information de localisation de l'utilisateur mobile, permettant de lui transmettre des informations à travers ledit point d'accès, et chaque flux d'information destiné à ou provenant de l'utilisateur mobile, dans le cadre d'une communication avec un correspondant distant, est adressé audit serveur de mobilité du sous-réseau visité.

2. Procédé selon la revendication 1, dans lequel le réseau fonctionne selon le protocole IP.

3. Procédé selon la revendication 2, dans lequel ledit protocole de signalisation de couche application est le protocole SIP, H.323, MGCP ou Megaco.

4. Procédé selon la revendication 2 ou 3, dans lequel la première information de localisation est une adresse IP du serveur de .mobilité (8) du sous-réseau visité (12).

5. Procédé selon la revendication 2 ou 3, dans lequel la seconde information de localisation est une adresse IP de l'utilisateur mobile dans le sous-réseau visité (12).

6. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel au moins un sous-réseau comprend plusieurs sous-sous-réseaux interconnectés (120, 121) respectivement équipés d'agents de mobilité (129, 130) utilisés dans un protocole de gestion de mobilité de couche réseau, dans lequel ledit sous-réseau a un serveur de mobilité (129) relié à l'un des sous- sous-réseaux (120) et constituant un agent de mobilité nominal pour des utilisateurs mobiles en visite dans ledit sous-réseau, et dans lequel lorsqu'un utilisateur mobile est localisé auprès d'un point d'accès (7) relié à un autre des sous-sous-réseaux (121), ledit serveur de mobilité constituant un agent de mobilité nominal mémorise dans le registre de visiteurs (10) une seconde information de localisation de l'utilisateur mobile, consistant en une adresse de réseau, que ledit serveur de mobilité constituant un agent de mobilité nominal place dans des en-têtes de paquets dans lesquels les flux d'information destinés à l'utilisateur mobile sont retransmis par un mécanisme d'encapsulation.

7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel au moins un point d'accès (7) auprès duquel l'utilisateur mobile est susceptible d'être localisé est associé à l'un des serveurs de mobilité (8), et on inclut une adresse de réseau du serveur de mobilité (8) auquel ledit point d'accès est associé dans un signal de balise émis sur une interface air par ledit point d'accès (7), et/ou dans au moins un message transmis sur l'interface air par ledit point d'accès vers l'utilisateur mobile dans le cadre d'une procédure d'inscription d'un protocole propre à l'interface air.

8. Procédé selon la revendication 7, dans lequel, à l'issue de la procédure d'inscription auprès dudit point d'accès (7), un message de mise à jour de localisation du protocole de signalisation de couche application est émis de l'utilisateur mobile vers ladite adresse de réseau.

9. Procédé selon la revendications 7 ou 8, dans lequel au moins un sous-réseau comprend plusieurs sous-sous-réseaux interconnectés (120, 121) respectivement équipés d'agents de mobilité (129, 130) utilisés dans un protocole de gestion de mobilité de couche réseau, dans lequel ledit sous- réseau a un serveur de mobilité (129) relié à l'un des sous-sous-réseaux (120) et constituant un agent de mobilité nominal pour des utilisateurs mobiles en visite dans ledit sous-réseau, dans lequel lorsqu'un utilisateur mobile est localisé auprès d'un point d'accès (7) relié à un autre des sous-sous-réseaux (121), ledit serveur de mobilité constituant un agent de mobilité nominal mémorise dans le registre de visiteurs (10) une seconde information de localisation de l'utilisateur mobile, consistant en une adresse de réseau, que ledit serveur de mobilité constituant un agent de mobilité nominal place dans des en-têtes de paquets dans lesquels les flux d'information destinés à l'utilisateur mobile sont retransmis par un mécanisme d'encapsulation, et dans lequel on inclut en outre dans le signal de balise émis par ledit point d'accès, et/ou dans au moins un message transmis sur l'interface air par ledit point d'accès vers l'utilisateur mobile dans le cadre de la procédure d'inscription du protocole propre à l'interface air, une adresse de réseau d'un agent de mobilité étranger (130) relié au même sous-sous-réseau (121) que ledit point d'accès et correspondant à l'adresse de réseau formant la seconde information de localisation de l'utilisateur mobile.

10. Serveur de mobilité à relier à un sous-réseau (12) appartenant à un réseau de télécommunications, fonctionnant selon un protocole de signalisation de couche application et comprenant des moyens de gestion d'un registre de visiteurs (10) contenant, pour au moins un utilisateur mobile localisé auprès d'un point d'accès (7) relié audit sous-réseau, une information de localisation de l'utilisateur mobile, permettant de lui transmettre des informations à travers ledit point d'accès, des moyens pour recevoir des flux d'information provenant de l'utilisateur mobile dans le cadre d'une communication avec un correspondant distant et les retransmettre à destination du correspondant distant, et des moyens pour recevoir des flux d'information provenant du correspondant distant dans le cadre de ladite communication et les retransmettre à l'utilisateur mobile.

11. Serveur de mobilité selon la revendication 10, dans lequel le réseau fonctionne selon le protocole IP et ledit protocole de signalisation de couche application est le protocole SIP, H.323, MGCP ou Megaco.

12. Serveur de mobilité selon la revendication 10 ou 11, dans lequel la seconde information de localisation est une adresse IP de l'utilisateur mobile dans le sous-réseau visité (12).

13. Serveur de mobilité selon la revendication 10 ou 11, pour un sous- réseau comprenant plusieurs sous-sous-réseaux interconnectés (120, 121) respectivement équipés d'agents de mobilité (129, 130) utilisés dans un protocole de gestion de mobilité de couche réseau, ledit serveur de mobilité étant relié à l'un des sous-sous-réseaux (120) et constituant un agent de mobilité nominal pour des utilisateurs mobiles en visite dans ledit sous-réseau, dans lequel les moyens de gestion du registre de visiteurs (10) sont agencés pour mémoriser, pour au moins un utilisateur mobile localisé auprès d'un point d'accès (7) relié à un autre des sous-sous-réseaux (121), une information de localisation consistant en une adresse de réseau, et les moyens pour retransmettre des flux d'information à l'utilisateur mobile sont agencés pour encapsuler lesdits flux dans des paquets ayant un en-tête comportant ladite adresse de réseau mémorisée dans le registre de visiteurs pour l'utilisateur mobile.