FR2904913A1

FR2904913A1 - Procede de gestion d'interfonctionnement pour le transfert de sessions de service multiples entre un reseau mobile et un reseau local sans fil, et equipement correspondant

Info

Publication number: FR2904913A1
Application number: FR0653324A
Authority: FR
Inventors: Laurence Gras; Olivier Marce
Original assignee: Alcatel SA
Current assignee: Alcatel Lucent SAS
Priority date: 2006-08-09
Filing date: 2006-08-09
Publication date: 2008-02-15
Anticipated expiration: 2026-08-09
Also published as: US20090323635A1; EP2052492A1; WO2008017709A1; CN101523817A; FR2904913B1

Abstract

Un procédé est dédié à la gestion de l'interfonctionnement entre un réseau WLAN et un réseau mobile raccordés à un coeur de réseau comprenant au moins deux noeuds GGSN (G1, G2) raccordés respectivement à des réseaux de services, un noeud SGSN (NS) raccordé au réseau mobile et aux noeuds GGSN, et au moins deux passerelles TTG (T1, T2) raccordées au réseau WLAN et aux noeuds GGSN. Ce procédé consiste, en cas de génération par une station mobile (MS), ayant établi des sessions de communication via des tunnels entre les passerelles (T1, T2) et les noeuds GGSN (G1, G2), d'un message signalant un transfert des sessions de communication du réseau local sans fil vers le réseau mobile, i) à déterminer des identifiants de communication des passerelles (T1, T2), ii) à utiliser un équipement d'interface (ED), connecté aux passerelles (T1, T2) et au noeud SGSN (NS) pour récupérer des contextes SGSN de transfert de la station mobile (MS) auprès des passerelles (T1, T2) identifiées, et iii) à effectuer auprès des noeuds GGSN (G1, G2) identifiés par les contextes SGSN de transfert reçus une mise à jour de contextes PDP de service destinée à supprimer et/ou modifier les tunnels, et à établir de nouveaux tunnels entre la station mobile (MS) et les noeuds GGSN (G1, G2), via le noeud SGSN (NS), pour assurer la continuité du service pendant le transfert des sessions de communication.

Description

PROCÉDÉ DE GESTION D'INTERFONCTIONNEMENT POUR LE TRANSFERT DE SESSIONS DE

SERVICE MULTIPLES ENTRE UN RÉSEAU MOBILE ET UN RÉSEAU LOCAL SANS FIL, ET ÉQUIPEMENT CORRESPONDANT L'invention concerne l'interfonctionnement (ou inter-working ) entre des réseaux locaux sans fil de type WLAN ( Wireless Local Area Network ) et des réseaux de communication mobile de type 3GPP, et plus précisément io les situations dans lesquelles une station mobile, ayant plusieurs applications (ou sessions) ouvertes vers des serveurs de service(s) interfacés à un coeur de réseau mobile 3GPP via différents noeuds de type GGSN, a besoin de maintenir ouvertes ses sessions lors d'un transfert (ou handover ) d'un réseau WLAN vers un réseau mobile 3GPP, ou inversement. 15 On entend ici par réseaux de type 3GPP tous les réseaux de communication disposant d'une interface radio 3GPP permettant un accès IP ( Internet Protocol ), et notamment les réseaux mobiles (ou cellulaires) dits de deuxième génération (2G), comme par exemple les réseaux GSM, les réseaux mobiles (ou cellulaires) dits 2,5G, comme par exemple les réseaux 20 GPRS/EDGE, et les réseaux mobiles (ou cellulaires) dits de troisième génération (3G), comme par exemple les réseaux UMTS ou CDMA2000, ainsi que toutes leurs variantes. Par ailleurs, on entend ici par réseaux locaux sans fil tous les réseaux locaux de communication disposant d'une interface radio WLAN 25 permettant un accès IP (standards IEEE 802.11, Bluetooth et Hiperlan/2), et notamment les réseaux WiFi et WiMAX. En outre, on entend ici par interfonctionnement (3GPP/WLAN) la possibilité offerte à un réseau WLAN d'utiliser certaines infrastructures de cour de réseau 3GPP pour permettre à l'utilisateur d'une station mobile 30 hybride (3GPP/WLAN), connectée à ce réseau WLAN ou sur le point de s'y connecter, d'accéder à des services (ou en anglais Packet Services ) offerts par un ou plusieurs fournisseurs d'accès à l'Internet (ou ISP pour 2 2904913 Internet Service Provider ). Cet interfonctionnement est notamment défini par la version 7 ( release 7 ) du 3GPP (spécifications techniques 3GPP TS 23.234 et TS 23.934). Comme le sait l'homme de l'art, la version 7 de l'interfonctionnement s 3GPP/WLAN (et plus précisément son scénario n 4) prévoit la continuité de service lors d'un transfert de session de communication (impliquant un service) d'un réseau d'accès radio WLAN vers un réseau d'accès radio 3GPP, et réciproquement. En d'autres termes, lorsqu'une station mobile utilise un service via un réseau d'accès radio WLAN, elle doit pouvoir io continuer à utiliser ce service lorsqu'elle quitte ce réseau d'accès radio 3GPP (respectivement WLAN) pour poursuivre sa communication via un réseau d'accès radio WLAN (respectivement 3GPP). Il est rappelé qu'une station mobile peut par exemple utiliser un service, via un réseau d'accès radio WLAN, lorsque des tunnels de type bout 15 en bout (ou end-to-end ) ont été établis d'une part entre cette station mobile et une passerelle de terminaison de tunnel dite TTG (pour Tunnel Termination Gateway ) d'un coeur de réseau 3GPP, et d'autre part entre cette passerelle TTG et un noeud de type GGSN (pour Gateway GPRS Support Node ) assurant la connexion du coeur de réseau 3GPP au réseau 20 IP offrant le service. Il existe une autre possibilité d'architecture avec un tunnel établi entre une station mobile et un équipement de type PDG, mais l'invention ne s'applique pas à celle-ci. Par ailleurs, une station mobile peut utiliser un service, via un réseau d'accès radio 3GPP, lorsque des tunnels ont été établis d'une part entre cette 25 station mobile et un noeud de type SGSN (pour Serving GPRS Support Node ) du coeur de réseau 3GPP, et d'autre part entre ce noeud SGSN et le noeud GGSN assurant la connexion du coeur de réseau 3GPP au réseau IP offrant le service. Dans un réseau 3GPP, le noeud GGSN est considéré comme un 30 point d'ancrage y compris lorsqu'une station mobile se déplace d'une zone de couverture d'un réseau WLAN vers celle d'un réseau (mobile) 3GPP. Par conséquent, pendant une procédure de transfert de session (ou handover ) d'un réseau WLAN vers un réseau 3GPP, le noeud SGSN qui 3 2904913 est contacté pour poursuivre la session doit déterminer l'identité de la passerelle TTG utilisée jusqu'alors pour cette session, afin d'obtenir de celle-ci le contexte SGSN de transfert (ou SGSN context ), qui inclus le contexte PDP de service (ou PDP context pour Packet Data Protocol context ), 5 et initier une procédure de transfert de contexte PDP de service (qui correspond à la connexion IP station mobile / noeud GGSN). De même, pendant une procédure de transfert de session (ou handover ) d'un réseau 3GPP vers un réseau WLAN, la passerelle TTG qui est contactée pour poursuivre la session doit déterminer l'identité du noeud SGSN utilisé lo jusqu'alors pour cette session, afin d'obtenir de celui-ci le contexte SGSN de transfert et initier une procédure de transfert de contexte PDP de service. La passerelle TTG est donc considérée, du point de vue du coeur de réseau, comme un noeud SGSN, ce qui implique qu'elle doit supporter les mécanismes de gestion de localisation, comme par exemple le transfert de 15 contexte SGSN (ou SGSN context ), la mise à jour de contexte PDP de service (ou PDP context ) et la mise à jour de serveur de localisation (appelé HLR (pour Home Location Register )), afin de permettre le maintien de la continuité de service pendant un transfert (ou handover). L'inconvénient de l'architecture à base de passerelles TTG présentée 20 ci-dessus réside dans le fait qu'elle n'est pas adaptée aux situations dans lesquelles l'utilisateur d'une station mobile utilise simultanément plusieurs services (actifs), et donc a établi plusieurs sessions de communication (ou ouvert plusieurs applications). Dans ces situations dites à APN multiple (ou multi-Access Point Name ), plusieurs passerelles TTG peuvent être 25 impliquées dans plusieurs services de commutation de paquets (ou packet switched services ) 3GPP. Il est en effet rappelé que la connexion d'une station mobile d'un utilisateur à un couple passerelle TTG / GGSN est liée à un APN qui a été demandé par cet utilisateur. Par conséquent, si un utilisateur a requis plusieurs APNs pour plusieurs sessions, sa station mobile 30 peut se retrouver connectée simultanément à plusieurs passerelles TTG. Un noeud SGSN n'étant conçu que pour récupérer un contexte PDP de service dans un unique noeud, il n'est donc pas en mesure de supporter un transfert (ou handover) WLAN/3GPP ou 3GPP/WLAN impliquant simultanément 4 2904913 plusieurs sessions de communication (ou plusieurs applications). Pour remédier à cet inconvénient, il serait possible de modifier le mode de fonctionnement des noeuds SGSN, mais cela n'est pas très réaliste compte tenu du nombre élevé de noeuds SGSN déjà implantés. En outre, 5 cela impose de modifier le serveur de localisation HLR afin de mémoriser plusieurs points d'attachements (ici des passerelles TTG) pour une station mobile à la place d'un seul noeud SGSN habituellement. L'invention a donc pour but de proposer une solution permettant de maintenir la continuité de service lors du transfert de plusieurs sessions de io communication (ou applications ouvertes) d'une même station mobile (impliquant plusieurs services) d'un réseau d'accès radio WLAN vers un réseau d'accès radio 3GPP, et réciproquement. Elle propose à cet effet un procédé, dédié à la gestion de l'interfonctionnement entre un réseau local sans fil (WLAN) et un réseau 15 mobile 3GPP raccordés à un coeur de réseau comprenant au moins deux noeuds GGSN raccordés respectivement à des réseaux de services, au moins un noeud SGSN raccordé au réseau mobile et aux noeuds GGSN, et au moins deux passerelles de terminaison de tunnel (TTG) raccordées au réseau local sans fil et respectivement aux noeuds GGSN. 20 Ce procédé se caractérise par le fait qu'il consiste en cas de génération par une station mobile, ayant établi au moins deux sessions de communication via des tunnels établis entre les passerelles TTG (respectivement le noeud SGSN) et les noeuds GGSN, d'un message signalant un transfert des sessions de communication du réseau local sans fil 25 (respectivement le réseau mobile) vers le réseau mobile (respectivement le réseau local sans fil) : i) à déterminer des identifiants de communication ces passerelles TTG (respectivement un identifiant de communication du noeud SGSN), ii) à utiliser un équipement d'interface, connecté aux passerelles TTG et au 30 noeud SGSN pour récupérer des contextes SGSN de transfert de la station mobile auprès des passerelles TTG identifiées (respectivement auprès du noeud SGSN identifié), et iii) à effectuer auprès des noeuds GGSN identifiés par les contextes SGSN de 5 2904913 transfert reçus une mise à jour de contextes PDP de service destinée à supprimer et/ou modifier les tunnels, et à établir de nouveaux tunnels entre la station mobile et les noeuds GGSN, via le noeud SGSN (respectivement les passerelles TTG), pour assurer la continuité du service pendant le 5 transfert des sessions de communication. Le procédé selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : en cas de transfert des sessions de communication du réseau local sans fil vers le réseau mobile, a) la station mobile peut adresser au noeud SGSN io une notification de mise à jour d'aire de routage (ou de zone) de sorte qu'il adresse à l'équipement d'interface un message requérant les contextes SGSN de transfert de la station mobile, et b) à réception du message de requête l'équipement d'interface peut récupérer auprès d'un serveur de type AAA du réseau mobile les identifiants de communication des 15 passerelles TTG impliquées dans les sessions de la station mobile (en cours de transfert), afin de récupérer auprès des passerelles TTG identifiées les contextes SGSN de transfert de la station mobile ; > au iii), avant d'effectuer la mise à jour des contextes PDP de service, on peut effectuer des opérations de sécurisation ; 20 > au iii) le noeud SGSN peut transmettre à chacun des noeuds GGSN une demande de mise à jour de contexte PDP de service, puis il peut adresser au serveur de localisation un message signalant qu'il se substitue aux passerelles TTG, de sorte qu'il ordonne au serveur de type AAA de procéder à la suppression des tunnels établis entre la station 25 mobile et les passerelles TTG ; • le noeud SGSN peut générer le message de signalement de substitution à réception de messages de confirmation de substitution en provenance des noeuds GGSN ; - au iii), à réception du message de signalement de substitution, le 30 serveur de localisation peut stocker un identifiant de communication de l'équipement d'interface ; - en cas de transfert des sessions de communication du réseau mobile vers le réseau local sans fil, a') la station mobile peut adresser à une première 6 2904913 des passerelles TTG une première demande d'établissement de tunnel bout en bout contenant un identifiant d'utilisateur et un premier APN, b') à réception de cette première demande la première passerelle TTG peut adresser au serveur de type AAA une demande d'autorisation 5 d'établissement de tunnels pour la station mobile, contenant l'identifiant d'utilisateur et le premier APN, et d'obtention d'informations pour l'établissement du tunnel, et c') une fois en possession de l'autorisation et de ces informations la première passerelle TTG peut démarrer une procédure d'authentification et d'autorisation de type EAP pour le premier APN, avec la station mobile et le serveur de type AAA, de manière à pré-établir un tunnel entre la station mobile et la première passerelle TTG ; - une fois la procédure de type EAP terminée, la première passerelle TTG peut adresser à l'équipement d'interface un message requérant les contextes SGSN de transfert de la station mobile, et à réception de ce message de requête l'équipement d'interface peut interroger le serveur de localisation pour déterminer l'identifiant de communication du noeud SGSN, puis il peut alors récupérer auprès du noeud SGSN identifié les contextes SGSN de transfert de la station mobile, qui sont associés au premier APN et à un second APN, puis il peut adresser à la première passerelle TTG un message contenant le contexte SGSN de transfert associé au premier APN ; -au iii) la première passerelle TTG peut transmettre à un premier des noeuds GGSN une demande de mise à jour de contexte PDP de service, puis elle peut adresser au serveur de type AAA un premier message signalant qu'elle se substitue au noeud SGSN pour la session associée au premier APN ; • la première passerelle TTG peut générer le premier message de signalement de substitution à réception d'un message de confirmation de substitution en provenance du premier noeud GGSN ; • au iii), après que le premier message de signalement de substitution a été adressé au serveur de type AAA, l'équipement d'interface peut adresser à la seconde passerelle TTG un message contenant le contexte SGSN de transfert associé au second APN. A réception de 7 2904913 ce message la seconde passerelle TTG peut démarrer une procédure d'authentification et d'autorisation de type EAP pour le second APN avec la station mobile et le serveur de type AAA, de manière à pré-établir un tunnel entre la station mobile et la seconde passerelle 5 TTG ; o au iii), après avoir reçu le message contenant le contexte SGSN de transfert associé au second APN, la seconde passerelle TTG peut transmettre à un second des noeuds GGSN une demande de mise à jour de contexte PDP de service, puis elle peut adresser au lo serveur de type AAA un second message signalant qu'elle se substitue au noeud SGSN pour la session associée au second APN ; ^ la seconde passerelle TTG peut générer le second message de signalement de substitution à réception d'un message de confirmation de substitution en provenance du second noeud GGSN. Dans ce cas, à réception du second message de signalement de substitution le serveur de type AAA peut adresser au serveur de localisation un message signalant que les passerelles TTG ont été substituées au noeud SGSN, afin qu'il informe le noeud SGSN de cette substitution, et à réception de cette information de substitution le noeud SGSN peut supprimer les tunnels jusqu'alors établis entre lui et la station mobile, puis il peut adresser au serveur de localisation un message d'accusé de réception lui signalant qu'il a supprimé les tunnels vers la station mobile. Par ailleurs, à réception de ce message d'accusé de réception le serveur de localisation peut adresser au serveur de type AAA un message lui signalant que les tunnels vers la station mobile ont été supprimés, puis, à réception de ce message de signalement de suppression le serveur de type AAA peut adresser à la première passerelle TTG un message d'acquittement de fin de procédure d'établissement des nouveaux tunnels, et à réception de ce message d'acquittement la première passerelle TTG peut 15 20 25 30 8 2904913 adresser à la station mobile un message de signalement de fin de procédure ; les identifiants de communication peuvent par exemple être des adresses IP et/ou des identifiants ISDN. 5 L'invention propose également un équipement d'interface, pour un coeur de réseau 3GPP, comprenant des moyens de traitement chargés, lorsqu'ils reçoivent un message requérant des contextes SGSN de transfert d'une station mobile souhaitant transférer entre le réseau local sans fil et le réseau mobile des sessions de communication établies via des tunnels entre io les noeuds GGSN et les passerelles TTG (respectivement le noeud SGSN), de récupérer les contextes SGSN de transfert de la station mobile auprès des passerelles TTG (respectivement le noeud SGSN), afin de les communiquer au noeud SGSN (respectivement aux passerelles TTG), pour qu'il puisse être substitué (respectivement qu'elles puissent être substituées) aux passerelles is TTG (respectivement au noeud SGSN), et établir de nouveaux tunnels entre lui (respectivement eux) et la station mobile. Cet équipement d'interface peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : - en cas de transfert des sessions de communication du réseau local sans fil 20 vers le réseau mobile et de réception en provenance du noeud SGSN d'un message requérant les contextes SGSN de transfert de la station mobile, ses moyens de traitement peuvent être chargés de récupérer auprès d'un serveur de type AAA du réseau mobile les identifiants de communication des passerelles TTG impliquées dans les sessions de la station mobile (en 25 cours de transfert), puis de récupérer auprès des passerelles TTG identifiées les contextes SGSN de transfert de la station mobile ; en cas de transfert des sessions de communication du réseau mobile vers le réseau local sans fil et de réception en provenance d'une première des passerelles TTG d'un message requérant les contextes SGSN de transfert 30 de la station mobile, ses moyens de traitement peuvent être chargés d'adresser une requête au serveur de localisation pour récupérer l'identifiant de communication du noeud SGSN, puis récupérer auprès du noeud SGSN identifié, au moyen d'une autre requête, les contextes SGSN 9 2904913 de transfert de la station mobile, qui sont associés à des premier et second APNs, puis d'adresser à la première passerelle TTG un message contenant le contexte SGSN de transfert associé au premier APN ; - en cas de substitution du noeud SGSN par la première passerelle TTG, 5 ses moyens de traitement peuvent être chargés d'adresser à la seconde passerelle TTG un message contenant le contexte SGSN de transfert associé au second APN, D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur io lesquels : - la figure 1 illustre de façon très schématique et fonctionnelle un réseau mobile 3GPP, comprenant un réseau d'accès radio 3GPP et un coeur de réseau 3GPP muni d'une passerelle de terminaison de tunnel connectée à un réseau d'accès radio WLAN, d'un noeud SGSN connecté au réseau 15 d'accès radio 3GPP, d'un exemple de réalisation d'un équipement d'interface selon l'invention, de deux passerelles TTG, et de deux noeuds GGSN connectés à deux réseaux de service(s), - la figure 2 illustre de façon schématique les principales étapes d'un exemple de procédé de transfert de sessions de communication selon 20 l'invention du réseau d'accès radio WLAN vers le réseau d'accès radio 3GPP de la figure 1, et - la figure 3 illustre de façon schématique les principales étapes d'un exemple de procédé de transfert de sessions de communication selon l'invention du réseau d'accès radio 3GPP vers le réseau d'accès radio 25 WLAN de la figure 1. Les dessins annexés pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant. L'invention a pour objet de permettre le maintien de la continuité de service lors du transfert de plusieurs (au moins deux) sessions de 30 communication ou applications (impliquant plusieurs services utilisés simultanément par une station mobile) d'un réseau d'accès radio WLAN vers un réseau d'accès radio 3GPP, et réciproquement. Dans ce qui suit, on considère à titre d'exemple illustratif et non i o 2904913 limitatif que le réseau d'accès radio 3GPP appartient à un réseau mobile (ou cellulaire) 3GPP de type UMTS. Mais, l'invention n'est pas limitée à ce type de réseau mobile. Elle concerne en effet tous les réseaux de communication disposant d'une interface radio 3GPP permettant un accès IP et notamment 5 les réseaux 2G (par exemple GSM), les réseaux 2,5G (par exemple GPRSIEDGE), et les réseaux 3G (par exemple UMTS ou CDMA2000), ainsi que toutes leurs variantes et leurs équivalents. Par ailleurs, on considère dans ce qui suit, à titre d'exemple illustratif et non limitatif, que le réseau d'accès radio WLAN fait partie d'un réseau local io sans fil (WLAN) de type WiFi ou WiMAX. Mais, l'invention n'est pas limitée à ce type de réseau WLAN. Elle concerne en effet tous les réseaux locaux sans fil disposant d'une interface radio WLAN permettant un accès IP (standards IEEE 802.11, Bluetooth et Hiperlan/2). L'invention propose un procédé dédié à la gestion de 15 l'interfonctionnement entre un réseau local sans fil (WLAN) et un réseau mobile 3GPP. Ce procédé peut être mis en oeuvre au moyen d'une architecture de réseaux du type de celle illustrée sur la figure 1 et comprenant un coeur de réseau 3GPP CRD, au moins des premier RS1 et second RS2 réseaux (ou ensembles) de service(s) (ou Packet Services) offerts par des 20 fournisseurs d'accès à l'Internet (ou ISPs) ou à des Intranets, au moins un réseau d'accès radio 3GPP RAN, et au moins un réseau d'accès radio WLAN W1 d'un réseau WLAN. On notera que l'invention s'applique à toute situation dans laquelle le coeur de réseau CRD est connecté (via des noeuds de type GGSN) à au moins deux réseaux (ou ensembles) de services. 25 On considère dans ce qui suit que le réseau d'accès radio 3GPP RAN et le coeur de réseau 3GPP CRD font partie d'un même réseau UMTS dont les utilisateurs des stations mobiles MS sont clients. Par conséquent, dans l'exemple décrit ci-après le coeur de réseau 3GPP CRD constitue pour les stations mobiles MS un coeur de réseau de domicile (ou home core 30 network ). Mais cela n'est pas une obligation. Il est important de noter que l'invention ne concerne que les stations mobiles MS de type hybride 3GPP/WLAN, c'est-à-dire disposant d'une carte de communication (par exemple de type UICC pourvu d'un (U)SIM) leur 11 2904913 permettant de se connecter à la fois aux réseaux d'accès radio WLAN (WAN) et aux réseaux d'accès radio 3GPP (RAN). Il pourra donc s'agir de tout type d'équipement de communication mobile et notamment d'un téléphone mobile, d'un ordinateur portable ou d'un assistant numérique personnel (ou PDA) s équipé d'une carte du type précité. Le procédé selon l'invention doit être mis en oeuvre chaque fois qu'une station mobile MS a établi au moins deux sessions de communication avec au moins deux réseaux (ou ensembles) de services RS1 et RS2, par l'intermédiaire d'un réseau d'accès radio WLAN W1 (respectivement d'un 10 réseau d'accès radio 3GPP RAN) et au moins de son coeur de réseau de domicile CRD, afin d'utiliser simultanément au moins deux services différents, et que cette station mobile MS doit se connecter à un réseau d'accès radio 3GPP RAN (respectivement un réseau d'accès radio WLAN W1), éventuellement visité, afin de poursuivre ses sessions de communication 15 utilisées pour lesdits services. Le procédé s'applique donc soit lorsque des tunnels ont été établis entre une station mobile MS et au moins deux passerelles de terminaison de tunnel ou TTGs (pour Tunnel Termination Gateways ) T1 et T2 (appartenant au coeur de réseau CRD et raccordées au réseau d'accès radio 20 WLAN W l) et entre ces dernières et au moins deux noeuds de type GGSN (pour Gateway GPRS Support Node ) G1 et G2 (appartenant au coeur de réseau CRD et raccordées au réseaux de services RS1 et RS2), soit lorsque des tunnels ont été établis entre une station mobile MS et un noeud SGSN (pour Serving GPRS Support Node ) NS (appartenant au coeur de réseau 25 CRD et raccordé au réseau d'accès radio 3GPP RAN) et entre ce dernier et au moins deux noeuds GGSN G1 et G2. Le procédé selon l'invention consiste à effectuer les trois phases décrites ci-dessous chaque fois qu'une station mobile MS, qui a établi au moins deux sessions de communication via des tunnels établis entre les 30 passerelles TTG Ti et T2 (ou le noeud SGSN NS) et les noeuds GGSN G1 et G2, génère un message signalant le besoin de transférer ses sessions de communication du réseau d'accès radio WLAN W1 (ou du réseau d'accès radio 3GPP RAN) vers le réseau d'accès radio 3GPP RAN (ou le réseau 12 2904913 d'accès radio WLAN W 1). La première phase consiste à déterminer des identifiants de communication des passerelles TTG T1 et T2 (ou un identifiant de communication du noeud SGSN NS). 5 La deuxième phase consiste à utiliser un nouvel équipement d'interface ED, connecté aux passerelles TTG T1 et T2 et au noeud SGSN NS afin de récupérer des contextes SGSN de transfert de la station mobile MS auprès des passerelles TTG Ti et T2 (ou auprès du noeud SGSN NS) identifié(es) lors de la première phase. 10 La troisième phase consiste à effectuer auprès des noeuds GGSN G1 et G2, identifiés par les contextes SGSN de transfert récupérés lors de la deuxième phase, une mise à jour de contextes PDP de service destinée à supprimer et/ou modifier les tunnels établis entre la station mobile MS et les noeuds GGSN G1 et G2, via les passerelles TTG T1 et T2 (ou le noeud SGSN 1s NS), et à établir de nouveaux tunnels entre la station mobile MS et les noeuds GGSN G1 et G2, via le noeud SGSN NS (ou les passerelles TTG Ti et T2), afin d'assurer la continuité du service pendant le transfert des sessions de communication de cette station mobile MS. Ces trois phases vont être détaillées ciaprès dans le cadre de 20 premier et second exemples de mise en oeuvre du procédé, correspondant respectivement au transfert de deux sessions de communication d'une station mobile MS du réseau d'accès radio WLAN W1 vers le réseau d'accès radio 3GPP RAN (en référence à la figure 2), et au transfert de deux sessions de communication d'une station mobile MS du réseau d'accès radio 3GPP RAN 25 vers le réseau d'accès radio WLAN W1 (en référence à la figure 3). On se réfère maintenant aux figures 1 et 2 pour présenter le premier exemple de mise en oeuvre du procédé selon l'invention. Ce premier exemple concerne une situation dans laquelle la station mobile MS a déjà établi deux sessions de communication avec les premier 30 RS1 et second RS2 réseaux de services, via des tunnels établis entre elle et les noeuds GGSN G1 et G2 (respectivement connectés aux premier RS1 et second RS2 réseaux de services), via les passerelles TTG Ti et T2. Dans cette situation, un premier APN (pour Access Point Name ) APN1 a été 13 2904913 attribué au premier couple (première passerelle TTG Ti, premier noeud GGSN G1) et un second APN APN2 a été attribué au second couple (seconde passerelle TTG T2, second noeud GGSN G2). La procédure d'établissement d'une session de communication 5 initiale via le réseau d'accès radio WLAN W1 est bien connue de l'homme de l'art. Elle ne sera donc pas décrite ici en détail. Il est simplement rappelé qu'une station mobile MS peut se connecter au réseau d'accès radio WLAN W1 par l'intermédiaire d'un point d'accès (ou access point ) AP. Un point d'accès AP est connecté au coeur de réseau CRD soit par au moins un lo routeur de son réseau WLAN et des passerelles TTGs Ti et T2, via une interface appelée Wp, soit directement à des passerelles TTGs Ti et T2, via l'interface Wp, lorsque ces passerelles TTG assurent également la fonction de routeur. Chaque passerelle TTG Ti, T2 est connectée, via une interface appelée Gn', à un noeud GGSN G1, G2 servant de point d'accès, via une 15 interface appelée Gi, à un ou plusieurs services à commutation de paquets (PS) offerts par exemple par au moins un serveur d'application d'un réseau de service(s) RS1, RS2. Chaque passerelle TTG T1, T2 dispose d'au moins un identifiant de communication, comme par exemple une adresse IP, ainsi qu'éventuellement d'un numéro (ou identifiant) ISDN. 20 Lorsqu'une session de communication doit être établie pour une station mobile MS et pour un service donné, cette dernière doit tout d'abord trouver l'identifiant de communication (par exemple l'adresse IP) d'une passerelle TTG T1 ou T2. Pour ce faire, la station mobile MS peut parexemple effectuer une demande dite DNS (pour Domain Name System ) 25 (flèche F1 de la figure 2). Puis, une fois qu'elle dispose de l'adresse IP d'une passerelle TTG T1 ou T2, la station mobile MS transmet à cette passerelle TTG Ti ou T2, via un point d'accès AP du réseau d'accès radio WLAN V VI, une requête d'établissement d'un tunnel de bout en bout (ou end-to-end ), de type Tunnel Establishment Request (comportant notamment des 30 champs User-ID et W-APN), conformément aux spécifications techniques 3GPP TS 23.234. Ce tunnel de type bout en bout est par exemple de type VPN/IPSec. Une fois qu'il a été établi entre la station mobile MS et une passerelle TTG Tl ou T2 (flèche F2 ou F4 de la figure 2), via une interface 14 2904913 appelé Wu, la passerelle TTG Ti ou T2 établit, via l'interface Gn', un autre tunnel de type bout en bout avec le noeud GGSN G1 ou G2 qui fournit l'accès au service objet de la session requise (flèche F3 ou F5 de la figure 2). Cet autre tunnel de type bout en bout est par exemple de type GTP (pour GPRS 5 Tunnelling Protocol ). La passerelle TTG T1 ou T2 transmet, via une interface appelée Gr', un identifiant de communication de la station mobile MS et au moins sa propre adresse IP ainsi que généralement son propre numéro (ou identifiant) ISDN à un serveur de localisation du coeur de réseau CRD, appelé HLR (pour 10 Home Location Register ), afin qu'il les stocke en correspondance les uns des autres. Lorsque la station mobile MS s'apprête à quitter le réseau d'accès radio WLAN W1 pour se connecter au réseau d'accès radio 3GPP RAN (flèche FO de la figure 1), elle démarre une procédure de transfert de ses 15 sessions de communication (ou handover ). Comme indiqué précédemment, le procédé selon l'invention intervient précisément à ce stade. Dans ce premier exemple de mise en oeuvre du procédé selon l'invention, un noeud SGSN NS, connecté via une interface appelée Gn aux 20 noeuds GGSN G1 et G2, doit prendre la relève des passerelles TTG T1 et T2 qui étaient jusqu'alors impliquées dans les deux sessions de la station mobile MS. Il est rappelé que le réseau d'accès radio 3GPP RAN comprend des stations de base et des contrôleurs de réseau radio appelés respectivement 25 Node Bs et RNCs (pour Radio Network Controlers ) dans le cas d'un réseau UMTS. Généralement, un RNC est connecté à au moins un Node B ainsi qu'au coeur de réseau 3GPP CRD par l'un de ses noeuds SGSN NS, via une interface appelée lu-PS. Chaque noeud SGSN NS dispose d'au moins un identifiant de communication, comme par exemple une adresse IP, ainsi 30 qu'éventuellement d'un numéro (ou identifiant) ISDN, et est connecté à au moins un noeud de type GGSN du coeur de réseau 3GPP CRD, via un tunnel, de préférence de type GTP (pour GPRS Tunnelling Protocol ), qui emprunte une interface appelée Gn. 15 2904913 Lorsque la station mobile MS (en sessions) quitte la zone de couverture radio du réseau d'accès radio WLAN W1 et parvient dans la zone de couverture radio du réseau d'accès radio 3GPP RAN, elle établit une connexion UMTS avec le noeud SGSN NS qui est connecté aux noeuds 5 GGSN G1 et G2 qui fournissent les accès aux services objets des sessions, via un Node B et le RNC associé (flèche F6 de la figure 2). Puis, la station mobile MS génère à destination du noeud SGSN NS une notification de mise à jour d'aire de routage (ou zone), par exemple de type Routing Area Update Request() . Cette notification est transmise au noeud SGSN NS par 10 le réseau d'accès radio WLAN W1 (flèche F7 de la figure 2). Lorsque le noeud SGSN NS reçoit la notification de mise à jour d'aire de routage, il doit déterminer les contextes SGSN de transfert (ou SGSN contexts ) (objets des sessions à transférer) utilisés par la station mobile MS, afin de pouvoir se substituer aux passerelles TTG T1 et T2. Pour ce faire, il 15 génère un message requérant les contextes SGSN de transfert, puis il transmet ce message (flèche F8 de la figure 2) à l'équipement d'interface ED qui est, selon l'invention, chargé de récupérer les contextes SGSN de transfert relatifs aux sessions en cours de transfert impliquant les passerelles TTG Ti et T2 auxquelles il est connecté (ou couplé). Le message de requête 20 contient des informations telles que, notamment, l'identifiant de communication de la station mobile MS. II est rappelé que le serveur de localisation HLR stocke ces informations en correspondance d'au moins un identifiant de communication de chaque passerelle TTG Ti, T2 qui permet d'accéder à chaque service objet d'une session en cours de transfert. 25 Chaque contexte SGSN de transfert qui doit être récupéré contient un contexte PDP de service (ou PDP conte)t ) ainsi que des éléments de sécurité propres à la station mobile MS concernée. Un contexte PDP de service (pour Packet Data Protocol ) représente la définition d'un service en cours. Il comprend notamment l'adresse IP du noeud GGSN Cl, G2 qui 30 sert de point d'accès au service considéré, ainsi qu'éventuellement le numéro (ou identifiant) ISDN dudit noeud GGSN Cl, G2. Par ailleurs, le message requérant les contextes SGSN de transfert est par exemple de type SGSN Context Request() . 16 2904913 L'équipement d'interface ED est un nouvel équipement de réseau proposé par l'invention. Il est connecté, d'une première part, au noeud SGSN NS, par exemple via une interface appelée Gn, d'une deuxième part, à chaque passerelle TTG Ti, T2, par exemple via une autre interface Gn, et 5 d'une troisième part, à un serveur de type AAA ( Authentication, Authorization and Accounting -authentification, autorisation et comptabilité) SA du coeur de réseau CRD, par exemple via une interface appelée Wm. Cet équipement d'interface ED peut par exemple constituer une passerelle TTG de type proxy, c'est-à-dire une passerelle supportant un sous-ensemble des fonctions supportées par une passerelle TTG T1, T2 classique (ou standard). Plus précisément, l'équipement d'interface ED est chargé i) de recevoir des demandes d'obtention de contexte SGSN, ii) d'identifier soit des passerelles TTG auprès du serveur de type AAA SA, soit un noeud SGSN auprès du serveur de localisation HLR, jusqu'alors connecté(s) à une station 15 mobile MS, et iii) de requérir les contextes SGSN correspondants pour les transmettre au(x) élément(s) qui les ont (a) requis, à savoir de nouvelles passerelles TTG ou un nouveau noeud SGSN. Tout comme les autres passerelles TTG T1 et T2, l'équipement d'interface ED dispose d'au moins un identifiant de communication, comme par exemple une adresse IP, ainsi 20 qu'éventuellement d'un numéro (ou identifiant) ISDN. On notera que l'équipement d'interface ED peut être éventuellement implanté dans le serveur de type AAA SA. On notera qu'un coeur de réseau peut comporter plusieurs équipements d'interface ED selon l'invention, par exemple pour des raisons 25 de sécurité et/ou de répartition de charge. La récupération des contextes SGSN de transfert se fait en deux phases : une première dans laquelle l'équipement d'interface ED doit récupérer au moins un identifiant de communication de chaque passerelle TTG Ti, T2 concernée par le transfert, et une seconde dans laquelle 30 l'équipement d'interface ED doit récupérer les contextes SGSN de transfert auprès des passerelles TTG T1 et T2 qu'il a identifiées. L'équipement d'interface ED comprend par exemple un module de traitement MT chargé de récupérer auprès du serveur de type AAA les 17 2904913 identifiants de communication des passerelles TTG Ti et T2. Par conséquent, lorsque l'équipement d'interface ED reçoit du noeud SGSN NS un message par exemple de type SGSN Context Request() , son module de traitement MT génère une demande, par exemple de type TTG Location Request() , 5 comprenant les informations nécessaires à la récupération des identifiants de communication des passerelles TTG (ici Ti et T2) qui sont impliquées dans les sessions de la station mobile MS. Ce message est transmis par l'équipement d'interface ED à destination du serveur de type AAA SA, via l'interface Wm (flèche F9 de la figure 2). io Lorsque le serveur de type AAA SA reçoit le message de type TTG Location Request(), par exemple, il recherche dans sa mémoire ou base de données les identifiants de communication, par exemple les adresses IP, des passerelles TTG qui permettent le déroulement des sessions en cours de transfert de la station mobile MS. Puis, le serveur de type AAA SA génère un is message de réponse contenant ces identifiants de communication et le transmet à l'équipement d'interface ED, via l'interface Wm (flèche F10 de la figure 2). A réception de ces identifiants de communication, le module de traitement MT génère un nouveau message requérant le (premier) contexte 20 SGSN de transfert de la première session (associée à l'APN1) de la station mobile MS qui a demandé le transfert. Ce message (requérant le premier contexte SGSN de transfert) est par exemple de type SGSN Context Request() . L'équipement d'interface ED transmet alors ce message de type SGSN Context Request(), par exemple, à destination de la première 25 passerelle TTG Ti identifiée dans le message de réponse reçu, via l'interface Gn (flèche F11 de la figure 2). En réponse à ce message reçu, la première passerelle TTG Ti génère un message de réponse contenant le premier contexte SGSN de transfert requis et le transmet à l'équipement d'interface ED, via l'interface Gn 30 (flèche F12 de la figure 2). A réception de ce premier contexte SGSN de transfert, le module de traitement MT génère un nouveau message requérant le (second) contexte SGSN de transfert de la seconde session (associée à l'APN2) de la station 18 2904913 mobile MS qui a demandé le transfert. Ce message (requérant le second contexte SGSN de transfert) est par exemple de type SGSN Context Request() . L'équipement d'interface ED transmet alors ce message de type SGSN Context Request(), par exemple, à destination de la seconde s passerelle TTG T2 identifiée dans le message de réponse reçu, via l'interface Gn (flèche F13 de la figure 2). En réponse à ce message reçu, la seconde passerelle TTG T2 génère un message de réponse contenant le second contexte SGSN de transfert requis et le transmet à l'équipement d'interface ED, via l'interface Gn 10 (flèche F14 de la figure 2). Une fois en possession des deux contextes SGSN de transfert, le module de traitement MT les insère dans un message de réponse qui est transmis au noeud SGSN NS, via l'interface Gn (flèche F15 de la figure 2). Lorsque le noeud SGSN NS reçoit le message de réponse, il peut 15 éventuellement effectuer des opérations de sécurisation auprès de la station mobile MS et du serveur de localisation HLR, avant de mettre à jour les contextes PDP de service (flèches F16 et F17 de la figure 2). Ces opérations de sécurisation consistent par exemple et notamment en des échanges de clefs pour la sécurisation des échanges. 20 Une fois ces éventuelles opérations de sécurisation effectuées, le noeud SGSN NS met à jour les contextes PDP de service afin de supprimer et/ou modifier les tunnels bout en bout (de types VPN/IPSec et GTP) établis entre la station mobile MS et les noeuds GGSN G1 et G2, via les passerelles TTG T1 et T2 (flèches (F2 et F3) et (F4 et F5) de la figure 2), pour permettre 25 le déroulement des sessions en cours de transfert. Pour ce faire, il génère par exemple une première demande de mise à jour de contexte PDP de service. Cette première demande est par exemple de type Update PDP Context Request() . Elle est destinée à signaler au premier noeud GGSN G1 que le noeud SGSN NS se substitue à la première 30 passerelle TTG T1 pour la première session de service de la station mobile MS. Elle comprend par conséquent le ou les identifiants de communication du noeud SGSN NS, l'identifiant de la station mobile MS ainsi que d'autres informations liées à celle-ci. La première demande est transmise par le noeud 19 2904913 SGSN NS à destination du premier noeud GGSN G1, identifié par le premier contexte SGSN de transfert reçu, via l'interface Gn (flèche F18 de la figure 2). A

réception de cette première demande, le premier noeud GGSN G1 enregistre les informations qu'elle contient, puis il adresse à destination du 5 noeud SGSN NS un premier message d'accusé de réception (flèche F19 de la figure 2). II est important de noter que cette mise à jour du premier contexte PDP n'entraîne pas la suppression effective du tunnel GTP associé à la première session en cours de transfert, mais sa modification. En fait, cela ne fait que remplacer son extrémité côté première passerelle TTG T1 par une lo autre extrémité côté noeud SGSN NS, l'adresse IP du premier service restant la même. A réception de ce premier message d'accusé de réception, le noeud SGSN NS génère par exemple une seconde demande de mise à jour de contexte PDP de service. Cette seconde demande est par exemple de type 15 Update PDP Context Request() . Elle est destinée à signaler au second noeud GGSN G2 que le noeud SGSN NS se substitue à la seconde passerelle TTG T2 pour la seconde session de service de la station mobile MS. Elle comprend par conséquent le ou les identifiants de communication du noeud SGSN NS, l'identifiant de la station mobile MS ainsi que d'autres informations 20 liées à celle-ci. La seconde demande est transmise par le noeud SGSN NS à destination du second noeud GGSN G2, identifié par le second contexte SGSN de transfert reçu, via l'interface Gn (flèche F20 de la figure 2). A réception de cette seconde demande, le second noeud GGSN G2 enregistre les informations qu'elle contient, puis il adresse à destination du 25 noeud SGSN NS un second message d'accusé de réception (flèche F21 de la figure 2). II est important de noter que cette mise à jour du second contexte PDP n'entraîne pas la suppression effective du tunnel GTP associé à la seconde session en cours de transfert, mais sa modification. En fait, cela ne fait que remplacer son extrémité côté seconde passerelle TTG T2 par une 30 autre extrémité côté noeud SGSN NS, l'adresse IP du second service restant la même. Une fois que le noeud SGSN NS a reçu les deux messages d'accusé de réception, il doit mettre à jour le serveur de localisation HLR. Pour ce faire, 20 2904913 il génère par exemple un message de signalisation de substitution des points d'accès de la station mobile MS pour les sessions en cours de transfert. Ce message est par exemple de type Update Location() . Il comprend par conséquent le ou les identifiants de communication du noeud SGSN NS et 5 l'identifiant de la station mobile MS. Le message est transmis par le noeud SGSN NS à destination du serveur de localisation HLR, via l'interface Gr (flèche F22 de la figure 2). A réception de ce message, le serveur de localisation HLR met à jour sa mémoire ou base de données avec les informations qu'il contient, puis il lo adresse à destination du serveur de type AAA SA un message requérant la suppression des tunnels de type bout en bout (VPN/IPSec) établis entre la station mobile MS et les passerelles TTG T1 et T2, via une interface D'/Gr' (flèche F23 de la figure 2). Ce message est par exemple de type Cancel Location() . Il comprend par conséquent le ou les identifiants de 15 communication du noeud SGSN NS, l'identifiant de la station mobile MS, les identifiants de communication des passerelles TTG Ti et T2 qui doivent être remplacés par celui (ceux) du noeud SGSN NS en correspondance de l'identifiant de la station mobile MS (IMSI). A réception de ce message, le serveur de type AAA SA met à jour sa 20 mémoire ou base de données avec les informations qu'il contient, puis il adresse, à destination de la première passerelle TTG T1 identifiée dans ledit message, via l'interface Wm (flèche F24 de la figure 2), une première demande de suppression du tunnel de type bout en bout (VPN/IPSec) établi entre elle et la station mobile MS. Cette première demande est par exemple 25 de type Tunnel Disconnection Command() . A réception de cette première demande, la première passerelle TTG T1 procède à la suppression du tunnel VPN/IPSec identifié, puis elle adresse au serveur de type AAA SA un premier message d'accusé de réception, via l'interface Wm (flèche F25 de la figure 2).

30 A réception de ce premier message d'accusé de réception, le serveur de type AAA SA adresse, à destination de la seconde passerelle TTG T2 identifiée dans ledit message, via l'interface Wm (flèche F26 de la figure 2), une seconde demande de suppression du tunnel de type bout en bout 21 2904913 (VPN/l PSec) établi entre elle et la station mobile MS. Cette seconde demande est par exemple de type Tunnel Disconnection Command() . A réception de cette seconde demande, la seconde passerelle TTG T2 procède à la suppression du tunnel VPN/IPSec identifié, puis elle adresse 5 au serveur de type AAA SA un second message d'accusé de réception, via l'interface Wm (flèche F27 de la figure 2). Une fois que le serveur de type AAA SA a reçu les deux messages d'accusé de réception, il adresse au serveur de localisation HLR un message d'accusé de réception, via l'interface Wm (flèche F28 de la figure 2), pour lui lo signaler que les deux tunnels VPN/IPSec ont bien été supprimés. Ce message est par exemple de type Cancel Loc Ack() . A réception de ce message d'accusé de réception le serveur de localisation HLR adresse à destination du noeud SGSN NS un message d'accusé de réception, via l'interface Gr (flèche F29 de la figure 2), afin de lui 15 signaler que les mises à jour ont bien été effectuées. Ce message est par exemple de type Update Location Ack() . A réception de ce message d'accusé de réception le noeud SGSN NS adresse à destination de la station mobile MS (qui a requis le transfert) un message d'acceptation de mise à jour d'aire de routage, via l'interface lu-PS 20 (flèche F30 de la figure 2), afin de lui signaler qu'elle peut maintenant établir de nouveaux tunnels pour poursuivre ses sessions de service via le réseau d'accès radio 3GPP RAN. Ce message est par exemple de type Routing Area Update Accept() . A réception de ce message, la station mobile MS procède alors à 25 l'établissement de deux nouveaux tunnels entre elle et le noeud SGSN NS (flèches F31 et F33 de la figure 2), les deux autres nouveaux tunnels (GTP) ayant été précédemment modifiés (changement d'extrémité) afin de s'établir entre le noeud SGSN NS et les noeuds GGSN G1 et G2 (flèches F32 et F34 de la figure 2).

30 Grâce à ces nouveaux tunnels (flèches F31 à F34), la continuité des services est donc assurée pour la station mobile MS pendant le transfert de ses sessions de communication du réseau WLAN vers le réseau mobile 3GPP.

22 2904913 On se réfère maintenant aux figures 1 et 3 pour présenter le second exemple de mise en oeuvre du procédé selon l'invention. Ce second exemple concerne une situation dans laquelle la station mobile MS a déjà établi deux sessions de communication avec les premier 5 RS1 et second RS2 réseaux de services, via des tunnels établis entre elle et les noeuds GGSN G1 et G2 (respectivement connectés aux premier RS1 et second RS2 réseaux de services), via le noeud SGSN NS (flèches F1' à F5' de la figure 3). Dans cette situation, un premier APN (pour Access Point Name ) APN1 a été attribué au premier couple (noeud SGSN NS, premier io noeud GGSN G1) et un second APN APN2 a été attribué au second couple (noeud SGSN NS, second noeud GGSN G2). La procédure d'établissement d'une session de communication initiale via le réseau d'accès radio 3GPP RAN est bien connue de l'homme de l'art. Elle ne sera donc pas décrite ici en détail. Il est simplement rappelé 15 qu'une station mobile MS peut se connecter au réseau d'accès radio 3GPP RAN par l'intermédiaire de l'une de ses stations de base (Node Bs). Un tel Node B est connecté à un contrôleur de réseau radio (RNC) qui fait également partie du réseau d'accès radio 3GPP RAN. Le RNC est connecté au coeur de réseau 3GPP CRD par l'un de ses noeuds SGSN NS via 20 l'interface lu-PS. Ce noeud SGSN NS dispose d'au moins un identifiant de communication, comme par exemple une adresse IP, ainsi que généralement d'un numéro (ou identifiant) ISDN, et est connecté, via un tunnel de préférence de type GTP, empruntant une interface appelée Gn, à l'un au moins des noeuds GGSN G1, G2.

25 Lorsqu'une session de communication doit être établie pour une station mobile MS et pour un service donné, cette dernière doit tout d'abord trouver un identifiant de communication du noeud SGSN NS qui est connecté au noeud GGSN qui fournit l'accès au service concerné par cette session. Puis, la station mobile MS transmet sa requête d'établissement de tunnels au 3o noeud SGSN concerné. Une fois les tunnels établis le noeud SGSN NS transmet au serveur de localisation HLR, via une interface appelée Gr, un identifiant de la station mobile MS et au moins sa propre adresse IP ainsi que généralement son propre numéro (ou identifiant) ISDN, afin qu'il les stocke en 2 3 2904913 correspondance les uns des autres. Lorsque la station mobile MS s'apprête à quitter le réseau d'accès radio 3GPP RAN pour se connecter à un réseau d'accès radio WLAN W1 (flèche F0' de la figure 1), elle démarre une procédure de transfert de session 5 de communication (ou handover ). Comme indiqué précédemment, le procédé selon l'invention intervient précisément à ce stade. Dans ce second exemple de mise en oeuvre du procédé selon l'invention, les passerelles TTG Ti et T2, connectées via l'interface Gn aux io noeuds GGSN G1 et G2, doivent prendre la relève du noeud SGSN NS qui était jusqu'alors impliqué dans les deux sessions de la station mobile MS. Lorsque la station mobile MS (en sessions) quitte la zone de couverture radio du réseau d'accès radio 3GPP RAN et parvient dans la zone de couverture radio du réseau d'accès radio WLAN W1, elle établit une 15 connexion WLAN avec le réseau WLAN (flèche F6' de la figure 3). Puis, la station mobile MS doit trouver l'adresse IP de la passerelle TTG, ici Ti, qui est connectée au noeud GGSN G1 qui fournit l'accès au premier service objet de la première session. Elle effectue pour ce faire une demande dite DNS (pour Domain Name System ). Puis, une fois qu'elle dispose de l'adresse 20 I F de la première passerelle TTG T1, la station mobile MS transmet à cette première passerelle TTG T1, via un point d'accès AP du réseau d'accès radio WLAN W1 (flèche F7' de la figure 3), une demande (ou requête) d'établissement d'un tunnel bout en bout, par exemple de type Tunnel Establishment Request() , comportant notamment l'identifiant de l'utilisateur 25 de la station mobile MS (User-ID) et l'APN1 associé à la première session, conformément aux spécifications techniques 3GPP TS 23.234. Lorsque la première passerelle TTG Ti reçoit la demande d'établissement de tunnel, il doit tout d'abord générer à destination du serveur de type AAA (flèche F8' de la figure 3) une demande i) d'autorisation 30 d'établissement de tunnels pour la station mobile MS concernée, contenant l'identifiant d'utilisateur (User-ID) et le premier APN APN1, et ii) d'obtention d'informations pour l'établissement du tunnel. Cette demande est par exemple de type Access Request / Identity() .

24 2904913 A réception de cette demande, le serveur de type AAA le serveur de type AAA SA génère à destination de la première passerelle TTG T1 qui l'a interrogé (flèche F9' de la figure 3) un message de réponse comprenant une autorisation d'établissement de tunnel et des informations pour établir le s tunnel entre lui et la station mobile MS. A réception de ce message de réponse, la première passerelle TTG Ti peut démarrer une procédure d'authentification et d'autorisation de type EAP pour la première session associée au premier APN APN1, d'une part avec la station mobile MS (flèche F10' de la figure 3), et d'autre part avec le io serveur de type AAA SA (flèche F11' de la figure 3). Cette procédure permet de pré-établir un tunnel entre la station mobile MS et la première passerelle TTG T1. Une fois la procédure EAP terminée, la première passerelle TTG Ti doit déterminer les contextes SGSN de transfert (ou SGSN contexts ) 15 (objets des sessions à transférer) utilisés par la station mobile MS, afin de pouvoir se substituer au noeud SGSN NS impliqué dans le transfert des sessions. Pour ce faire, elle génère un message requérant les contextes SGSN de transfert, puis elle transmet ce message (flèche F12' de la figure 3) à l'équipement d'interface ED qui est, selon l'invention, chargé de récupérer 20 les contextes SGSN de transfert relatifs aux sessions en cours de transfert impliquant le noeud SGSN NS auquel elle est connectée (ou couplée). Le message de requête contient des informations telles que, notamment, l'identifiant de communication de la station mobile MS. Ce message requérant les contextes SGSN de transfert est par 25 exemple de type SGSN Context Request() . A réception de ce message de requête, l'équipement d'interface ED génère à destination du serveur de localisation HLR (flèche F13' de la figure 3) une demande (ou requête) lui demandant de lui transmettre au moins un identifiant de communication du noeud SGSN NS qui est concerné par les 30 sessions de la station mobile MS. Cette demande comprend au moins l'identifiant de communication de la station mobile MS. Elle est par exemple de type Location Request() . A réception de cette demande, le serveur de localisation HLR 25 2904913 récupère dans sa mémoire ou sa base de données le ou les identifiants de communication (par exemple l'adresse IP) du noeud SGSN NS qui est impliqué dans les sessions ouvertes de la station mobile MS. Puis, il génère à destination de l'équipement d'interface ED (flèche F14' de la figure 3) un 5 message de réponse comprenant le ou les identifiants de communication du noeud SGSN NS. A réception de ce message de réponse, le module de traitement MT de l'équipement d'interface ED doit récupérer les contextes SGSN de transfert auprès du noeud SGSN NS. Pour ce faire, il génère un message requérant les lo contextes SGSN de transfert des sessions de la station mobile MS qui a demandé le transfert. Ce message est par exemple également de type SGSN Context Request() . L'équipement d'interface ED transmet ce message de type SGSN Context Request(), par exemple, via l'interface Gn (flèche F15' de la figure 3), à destination du noeud SGSN NS identifié dans le 15 message de requête transmis par la première passerelle TTG T1. En réponse à ce message reçu, le noeud SGSN NS génère un message de réponse contenant les premier et second contextes SGSN de transfert requis et le transmet à l'équipement d'interface ED, via l'interface Gn (flèche F16' de la figure 3).

20 A réception de ces contextes SGSN de transfert, le module de traitement MT génère un message de réponse contenant lesdits contextes SGSN de transfert. L'équipement d'interface ED transmet alors ce message de réponse à destination de la première passerelle TTG Ti qui est à l'origine du transfert de sessions et qui l'a précédemment chargé de récupérer 25 les contextes, via l'interface Gn (flèche F17' de la figure 3). Lorsque la première passerelle TTG T1 reçoit le message de réponse, elle débute les mises à jour des contextes PDP de service destinées à supprimer et/ou modifier les tunnels bout en bout (de types VPN/IPSec et GTP) établis entre la station mobile MS et les noeuds GGSN G1 et G2, via le 30 noeud SGSN NS (flèches (F2' et F3') et (F4' et F5') de la figure 3), pour permettre le déroulement des sessions en cours de transfert. Pour ce faire, elle génère par exemple une première demande de mise à jour de contexte PDP de service. Cette première demande est par 26 2904913 exemple de type Update PDP Context Request() . Elle est destinée à signaler au premier noeud GGSN G1 que la première passerelle TTG T1 se substitue aunoeud SGSN NS pour la première session de service de la station mobile MS. Elle comprend par conséquent le ou les identifiants de s communication de la première passerelle TTG T1, l'identifiant de la station mobile MS ainsi que d'autres informations liées à celle-ci. La première demande est transmise par la première passerelle TTG T1 à destination du premier noeud GGSN G1, identifié par le premier contexte SGSN de transfert reçu, via une interface appelée Gn' (flèche F18' de la figure 3). io A réception de cette première demande, le premier noeud GGSN G1 enregistre les informations qu'elle contient, puis il adresse à destination de la première passerelle TTG T1 un premier message d'accusé de réception qui constitue un message de confirmation de substitution (flèche F19' de la figure 3). Il est important de noter que cette mise à jour du premier contexte PDP 15 n'entraîne pas la suppression effective du tunnel GTP associé à la première session en cours de transfert, mais sa modification. En fait, cela ne fait que remplacer son extrémité côté noeud SGSN NS par une autre extrémité côté première passerelle TTG T1, l'adresse IP du premier service restant la même. A réception de ce premier message d'accusé de réception, la 20 première passerelle TTG Ti adresse un message d'accusé de réception à l'équipement d'interface ED (flèche F20' de la figure 3) pour lui signaler qu'elle a bien récupéré les contextes SGSN de transfert. On notera que cette étape optionnelle pourrait survenir avant la génération de la première demande de mise à jour de contexte PDP de service (flèche F18').

25 Puis, la première passerelle TTG T1 adresse au serveur de type AAA (flèche F21' de la figure 3) un premier message destiné à lui signaler qu'elle se substitue au noeud SGSN NS pour la première session associée au premier APN APN1. Par exemple ce premier message est de type Tunnel Connection Report() . Le serveur de type AAA enregistre alors cette 30 information de substitution. Ensuite, le module de traitement MT de l'équipement d'interface ED génère un message contenant le second contexte SGSN de transfert. L'équipement d'interface ED transmet alors ce message, via l'interface Gn 27 2904913 (flèche F22' de la figure 3), à destination de la seconde passerelle TTG T2 précédemment identifiée afin qu'elle effectue la mise à jour du second contexte PDP. A réception de ce message, la seconde passerelle TTG T2 peut s démarrer une procédure de type EAP pour la seconde session associée au second APN APN2, d'une part avec la station mobile MS (flèche F23' de la figure 3), et d'autre part avec le serveur de type AAA SA (flèche F24' de la figure 3). Une fois la procédure EAP terminée, la seconde passerelle TTG T2 io génère par exemple une seconde demande de mise à jour de contexte PDP de service. Cette seconde demande est par exemple de type Update PDP Context Request() . Elle est destinée à signaler au second noeud GGSN G2 que la seconde passerelle TTG T2 se substitue au noeud SGSN NS pour la seconde session de service de la station mobile MS. Elle comprend par 15 conséquent le ou les identifiants de communication de la seconde passerelle TTG T2, l'identifiant de la station mobile MS ainsi que d'autres informations liées à celle-ci. La seconde demande est transmise par la seconde passerelle TTG T2 à destination du second noeud GGSN G2, identifié par le second contexte SGSN de transfert reçu, via l'interface Gn' (flèche F25' de la figure 20 3). A réception de cette seconde demande, le seconde noeud GGSN G2 enregistre les informations qu'elle contient, puis il adresse à destination de la seconde passerelle TTG T2 un second message d'accusé de réception qui constitue un message de confirmation de substitution (flèche F26' de la figure 25 3). Il est important de noter que cette mise à jour du second contexte PDP n'entraîne pas la suppression effective du tunnel GTP associé à la seconde session en cours de transfert, mais sa modification. En fait, cela ne fait que remplacer son extrémité côté noeud SGSN NS par une autre extrémité côté seconde passerelle TTG T2, l'adresse IP du second service restant la même.

30 A réception de ce second message d'accusé de réception, la seconde passerelle TTG T2 peut éventuellement adresser un message d'accusé de réception à l'équipement d'interface ED (flèche F27' de la figure 3) pour lui signaler qu'elle a bien mis à jour le second contexte PDP de 28 2904913 service. Puis, la seconde passerelle TTG T2 adresse au serveur de type AAA (flèche F28' de la figure 3) un second message destiné à lui signaler qu'elle se substitue au noeud SGSN NS pour la seconde session associée au second s APN APN2. Par exemple ce second message est de type Tunnel Connection Report() . Le serveur de type AAA enregistre alors cette information de substitution dans sa mémoire ou base de données. Puis, il doit mettre à jour le serveur de localisation HLR. Pour ce faire, il génère par exemple un message de signalisation de substitution des points d'accès de la lo station mobile MS pour les sessions en cours de transfert. Ce message est par exemple de type Update Location() . II comprend l'identifiant de la station mobile MS. Le message est transmis par le serveur de type AAA à destination du serveur de localisation HLR, via une interface appelée D'/Gr' (flèche F29' de la figure 3).

15 A réception de ce message, le serveur de localisation HLR met à jour sa mémoire ou base de données avec les informations qu'il contient, puis il adresse à destination du noeud SGSN NS un message requérant la suppression des tunnels de type bout en bout établis entre lui et la station mobile MS, via l'interface Gr (flèche F30' de la figure 3). Ce message est par 20 exemple de type Cancel Location() . II comprend par conséquent au moins l'identifiant de la station mobile MS. A réception de ce message, le noeud SGSN NS supprime les tunnels établis avec la station mobile MS identifiée, puis il adresse à destination du serveur de localisation HLR, via l'interface Gr (flèche F31' de la figure 3), un 25 message d'accusé de réception pour lui signaler qu'il a bien supprimé lesdits tunnels. A réception de ce message d'accusé de réception, le serveur de localisation HLR adresse au serveur de type AAA SA, via l'interface D'/Gr' (flèche F32' de la figure 3) un message destiné à lui signaler que les tunnels 30 précédemment établis entre la station mobile MS et le noeud SGSN NS ont bien été supprimés. A réception de ce message le serveur de type AAA SA met à jour sa mémoire ou sa base de données, puis il adresse à destination de la première 29 2904913 passerelle TTG Ti qui est à l'origine du transfert, via l'interface Wm (flèche F33' de la figure 3), un message d'acquittement de fin de procédure d'établissement des nouveaux tunnels. A réception de ce message d'acquittement la première passerelle s TTG T1 adresse à destination de la station mobile MS (qui a requis le transfert) un message de signalement de fin de procédure, via l'interface lu-PS (flèche F34' de la figure 3), afin de lui signaler que la procédure d'établissement des nouveaux tunnels est terminée. Ce message est par exemple de type E2E Tunnel Establishment Ack() . lo A réception de ce message, la station mobile MS peut alors utiliser les deux nouveaux tunnels (VPN/IPSec) établis entre elle et les passerelles TTG T1 et T2 (flèches F35' et F37' de la figure 3) et les deux autres nouveaux tunnels (GTP), précédemment modifiés par changement d'extrémité et établis respectivement entre les passerelles TTG Ti et T2 et les 15 noeuds GGSN G1 et G2 (flèches F36' et F38' de la figure 3). Grâce à ces nouveaux tunnels (flèches F35' à F38'), la continuité des services est donc assurée pour la station mobile MS pendant le transfert de ses sessions de communication du réseau mobile 3GPP vers le réseau WLAN.

20 Le module de traitement MT de l'équipement d'interface ED peut être réalisé sous la forme de circuits électroniques, de modules logiciels (ou informatiques), ou d'une combinaison de circuits et de logiciels. L'invention est particulièrement avantageuse car elle ne nécessite ni la modification ou l'adaptation des noeuds SGSN et des noeuds GGSN déjà 25 implantés dans les coeurs de réseau 3GPP, ni la création de nouveaux protocoles. En outre, l'invention permet d'utiliser les interfaces 3GPP standards. L'invention ne se limite pas aux modes de réalisation d'équipement d'interface ED et de procédé de gestion décrits ci-avant, seulement à titre 30 d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après. 30

Claims

REVENDICATIONS

1. Procédé de gestion d'un interfonctionnement entre un réseau local sans fil et un réseau mobile raccordés à un coeur de réseau comprenant au s moins deux noeuds GGSN (G1, G2) raccordés respectivement à des réseaux de service(s), au moins un noeud SGSN (NS) raccordé audit réseau mobile et auxdits noeuds GGSN (G1, G2), et au moins deux passerelles de terminaison de tunnel (Ti, T2) raccordées audit réseau local sans fil et respectivement auxdits noeuds GGSN (G1, G2), caractérisé en ce qu'il consiste en cas de lo génération par une station mobile (MS), ayant établi au moins deux sessions de communication via des tunnels établis entre lesdites passerelles (Ti, T2), respectivement ledit noeud SGSN (NS), et lesdits noeuds GGSN (G1, G2), d'un message signalant un transfert desdites sessions de communication dudit réseau local sans fil, respectivement ledit réseau mobile, vers ledit 15 réseau mobile, respectivement ledit réseau local sans fil, i) à déterminer des identifiants de communication desdites passerelles (Ti, T2), respectivement un identifiant de communication dudit noeud SGSN (NS), ii) à utiliser un équipement d'interface (ED), connecté auxdites passerelles (Ti, T2) et audit noeud SGSN (NS) pour récupérer des contextes SGSN de transfert de ladite 20 station mobile (MS) auprès desdites passerelles (T1, T2) identifiées, respectivement auprès dudit noeud SGSN (NS) identifié, et iii) à effectuer auprès desdits noeuds GGSN (G1, G2) identifiés par lesdits contextes SGSN de transfert reçus une mise à jour de contextes PDP de service destinée à supprimer et/ou modifier lesdits tunnels, et à établir de nouveaux tunnels 25 entre ladite station mobile (MS) et lesdits noeuds GGSN (G1, G2), via ledit noeud SGSN (NS), respectivement lesdites passerelles (T1, T2), pour assurer la continuité du service pendant le transfert des sessions de communication.

2. Procédé selon la revendication 1, caractérisé en ce qu'en cas de transfert desdites sessions de communication dudit réseau local sans fil vers 30 ledit réseau mobile, a) ladite station mobile (MS) adresse audit noeud SGSN (NS) une notification de mise à jour d'aire de routage de sorte qu'il adresse audit équipement d'interface (ED) un message requérant les contextes SGSN de transfert de ladite station mobile (MS), et b) à réception dudit message de 31 2904913 requête ledit équipement d'interface (ED) récupère auprès d'un serveur de type AAA (SA) dudit réseau mobile lesdits identifiants de communication desdites passerelles (T1, T2) impliquées dans les sessions de la station mobile (MS) en cours de transfert, de manière à récupérer auprès desdites passerelles (T1, T2) identifiées lesdits contextes SGSN de transfert de ladite station mobile (MS).

3. Procédé selon la revendication 2, caractérisé en ce qu'au iii) avant d'effectuer ladite mise à jour des contextes PDP de service on effectue des opérations de sécurisation.

4. Procédé selon l'une des revendications 2 et 3, caractérisé en ce qu'au iii) ledit noeud SGSN (NS) transmet à chacun desdits noeuds GGSN (G1, G2) une demande de mise à jour de contexte PDP de service, puis adresse audit serveur de localisation (HLR) un message signalant qu'il se substitue auxdites passerelles (Ti, T2), de sorte qu'il ordonne audit serveur de type AAA (SA) de procéder à la suppression des tunnels établis entre ladite station mobile (MS) et lesdites passerelles (Ti, T2).

5. Procédé selon la revendication 4, caractérisé en ce que ledit noeud SGSN génère ledit message de signalement de substitution à réception de messages de confirmation de substitution en provenance desdits noeuds GGSN (G1, G2).

6. Procédé selon l'une des revendications 2 à 5, caractérisé en ce qu'au iii) à réception dudit message de signalement de substitution ledit serveur de localisation (HLR) stocke un identifiant de communication dudit équipement d'interface (ED).

7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'en cas de transfert desdites sessions de communication dudit réseau mobile vers ledit réseau local sans fil, a') ladite station mobile (MS) adresse à une première (Ti) desdites passerelles une première demande d'établissement de tunnel bout en bout contenant un identifiant d'utilisateur et un premier APN (APN1), b') à réception de ladite première demande ladite première passerelle (Ti) adresse audit serveur de type AAA (SA) une demande d'autorisation d'établissement de tunnels pour ladite station mobile (MS), contenant lesdits identifiant d'utilisateur et premier APN (APN1), 32 2904913 d'obtention d'informations pour ledit établissement du tunnel, et d'obtention d'au moins un identifiant de communication dudit noeud SGSN (NS) impliqué dans ledit transfert de sessions, et c') une fois en possession de ladite autorisation et desdites informations ladite première passerelle TTG (Ti) s démarre une procédure d'authentification et d'autorisation de type EAP pour ledit premier APN (APN1), avec ladite station mobile (MS) et ledit serveur de type AAA (SA), de manière à pré-établir un tunnel entre la station mobile (MS) et la première passerelle TTG (Ti).

8. Procédé selon la revendication 7, caractérisé en ce qu'une fois lo ladite procédure de type EAP terminée ladite première passerelle (Ti) adresse audit équipement d'interface (ED) un message requérant les contextes SGSN de transfert de ladite station mobile (MS) et comportant ledit identifiant de communication du noeud SGSN (NS) impliqué dans ledit transfert de sessions, et à réception dudit message de requête ledit ls équipement d'interface (ED) interroge ledit serveur de localisation (HLR) pour déterminer l'identifiant de communication dudit noeud SGSN (NS), puis il récupère auprès dudit noeud SGSN (NS) identifié lesdits contextes SGSN de transfert de ladite station mobile (MS), qui sont associés au premier APN (APN1) et à un second APN (APN2), puis il adresse à ladite première 20 passerelle (Ti) un message contenant le contexte SGSN de transfert associé audit premier APN (APN1).

9. Procédé selon l'une des revendications 7 et 8, caractérisé en ce qu'au iii) ladite première passerelle (Ti) transmet à un premier (G1) desdits noeuds GGSN une demande de mise à jour de contexte PDP de service, puis 25 adresse audit serveur de type AAA (SA) un premier message signalant qu'il se substitue audit noeud SGSN (NS) pour la session associée audit premier APN (APN1).

10. Procédé selon la revendication 9, caractérisé en ce que ladite première passerelle (Ti) génère ledit premier message de signalement de 30 substitution à réception d'un message de confirmation de substitution en provenance dudit premier noeud GGSN (G1).

11. Procédé selon l'une des revendications 9 et 10, caractérisé en ce qu'au iii) après que ledit premier message de signalement de substitution a 33 2904913 été adressé audit serveur de type AAA (SA) ledit équipement d'interface (ED) adresse à ladite seconde passerelle (T2) un message contenant ledit contexte SGSN de transfert associé audit second APN (APN2).

12. Procédé selon la revendication 11, caractérisé en ce qu'à réception 5 dudit message ladite seconde passerelle (T1) démarre une procédure d'authentification et d'autorisation de type EAP pour ledit second APN (APN2) avec ladite station mobile (MS) et ledit serveur de type AAA (SA), de manière à pré-établir un tunnel entre ladite station mobile (MS) et ladite seconde passerelle TTG (T2). io

13. Procédé selon l'une des revendications 11 et 12, caractérisé en ce qu'au iii), après avoir reçu ledit message contenant ledit contexte SGSN de transfert associé audit second APN (APN2), ladite seconde passerelle (T2) transmet à un second (G2) desdits noeuds GGSN une demande de mise à jour de contexte PDP de service, puis adresse audit serveur de type AAA 15 (SA) un second message signalant qu'il se substitue audit noeud SGSN (NS) pour la session associée audit second APN (APN2).

14. Procédé selon la revendication 13, caractérisé en ce que ladite seconde passerelle (T2) génère ledit second message de signalement de substitution à réception d'un message de confirmation de substitution en 20 provenance dudit second noeud GGSN (G2).

15. Procédé selon la revendication 14, caractérisé en ce qu'à réception dudit second message de signalement de substitution ledit serveur de type AAA (SA) adresse audit serveur de localisation (HLR) un message signalant que lesdits passerelles (T1, T2) ont été substituées audit noeud SGSN (NS), 25 de sorte qu'il informe ledit noeud SGSN (NS) de cette substitution, et à réception de cette information de substitution ledit noeud SGSN (NS) supprime lesdits tunnels jusqu'alors établis entre lui et ladite station mobile (MS), puis il adresse audit serveur de localisation (HLR) un message d'accusé de réception lui signalant qu'il a supprimé lesdits tunnels vers ladite station 30 mobile (MS).

16. Procédé selon la revendication 15, caractérisé en ce qu'à réception dudit message d'accusé de réception ledit serveur de localisation (HLR) adresse audit serveur de type AAA (SA) un message lui signalant que lesdits 34 2904913 tunnels vers ladite station mobile (MS) ont été supprimés, en ce qu'à réception de ce message de signalement de suppression ledit serveur de type AAA (SA) adresse à ladite première passerelle (Ti) un message d'acquittement de fin de procédure d'établissement des nouveaux tunnels, et s en ce qu'à réception de ce message d'acquittement ladite première passerelle TTG (Ti) adresse à ladite station mobile (MS) un message de signalement de fin de procédure.

17. Procédé selon l'une des revendications 1 à 16, caractérisé en ce que lesdits identifiants de communication sont des adresses IP et/ou des lo identifiants ISDN.

18. Equipement de réseau (ED) pour un coeur de réseau comprenant au moins deux noeuds GGSN (G1, G2) raccordés respectivement à des réseaux de service(s), au moins un noeud SGSN (NS) raccordé à un réseau mobile et auxdits noeuds GGSN (G1, G2), et au moins deux passerelles de terminaison 15 de tunnel (Ti, T2) raccordées à un réseau local sans fil et respectivement auxdits noeuds GGSN (G1, G2), caractérisé en ce qu'il comprend des moyens de traitement (MT) agencés, en cas de réception d'un message requérant des contextes SGSN de transfert d'une station mobile (MS) souhaitant transférer entre ledit réseau local sans fil et ledit réseau mobile des sessions de 20 communication établies via des tunnels entre lesdits noeuds GGSN (G1, G2) et lesdites passerelles (T1, T2), respectivement ledit noeud SGSN (NS), pour récupérer lesdits contextes SGSN de transfert de ladite station mobile (MS) auprès desdites passerelles (Ti, T2), respectivement ledit noeud SGSN (NS), de manière à les communiquer audit noeud SGSN (NS), respectivement 25 auxdites passerelles (Ti, T2), pour qu'il puisse être substitué auxdites passerelles (Ti, T2), respectivement qu'elles puissent être substituées audit noeud SGSN (NS), et établir de nouveaux tunnels entre lui, respectivement eux, et ladite station mobile (MS).

19. Equipement de réseau selon la revendication 18, caractérisé en ce 30 qu'en cas de transfert desdites sessions de communication dudit réseau local sans fil vers ledit réseau mobile et de réception en provenance dudit noeud SGSN (NS) d'un message requérant les contextes SGSN de transfert de ladite station mobile (MS), lesdits moyens de traitement (MT) sont agencés 2904913 pour récupérer auprès d'un serveur de type AAA (SA) dudit réseau mobile lesdits identifiants de communication desdites passerelles (T1, T2) impliquées dans les sessions de la station mobile (MS) en cours de transfert, puis pour récupérer auprès desdites passerelles (T1, T2) identifiées lesdits contextes s SGSN de transfert de ladite station mobile (MS).

20. Equipement de réseau selon l'une des revendications 18 et 19, caractérisé en ce qu'en cas de transfert desdites sessions de communication dudit réseau mobile vers ledit réseau local sans fil et de réception en provenance d'une première (Ti) desdites passerelles d'un message io requérant les contextes SGSN de transfert de ladite station mobile (MS), lesdits moyens de traitement (MT) sont agencés pour adresser une requête audit serveur de localisation (HLR) de manière à récupérer l'identifiant de communication du noeud SGSN (NS) impliqué dans ledit transfert de sessions, puis pour récupérer auprès dudit noeud SGSN (NS) identifié, au 15 moyen d'une autre requête, lesdits contextes SGSN de transfert de ladite station mobile (MS), qui sont associés à des premier APN (APN1) et second APN (APN2), puis pour adresser à ladite première passerelle (Ti) un message contenant le contexte SGSN de transfert associé audit premier APN (APN1). 20

21. Equipement de réseau selon la revendication 20, caractérisé en ce qu'en cas de substitution dudit noeud SGSN (NS) par ladite première passerelle (Ti), lesdits moyens de traitement (MT) sont agencés pour adresser à ladite seconde passerelle (T2) un message contenant ledit contexte SGSN de transfert associé audit second APN (APN2), lesdites 25 informations et ledit identifiant de communication du noeud SGSN (NS).