FR 2904914 A1 20080215 FR 0653326 A 20060809 il 2904914 PROCÉDÉ DE GESTION D'INTERFONCTIONNEMENT POUR LE TRANSFERT DE SESSIONS DE SERVICE D'UN RÉSEAU LOCAL SANS FIL VERS UN RÉSEAU MOBILE, ET NOEUDS SGSN CORRESPONDANTS L'invention concerne I'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 le transfert (ou handover ) de sessions de communication des premiers réseaux (WLAN) vers les seconds (3GPP). On entend ici par réseaux locaux sans fil tous les réseaux locaux de communication disposant d'une interface radio WLAN permettant un accès IP (standards IEEE 802.11, Bluetooth et Hiperlan/2), et notamment les 15 réseaux WiFi et WiMAX. Par ailleurs, 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 20 réseaux GSM, les réseaux mobiles (ou cellulaires) dits 2,5G, comme par exemple les réseaux 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. En outre, on entend ici par interfonctionnement (3GPP/WLAN) la 25 possibilité offerte à un réseau WLAN d'utiliser certaines infrastructures de coeur de réseau 3GPP pour permettre à l'utilisateur d'une station mobile hybride (3GPP/WLAN), connectée à ce réseau WLAN, d'accéder à des services (ou en anglais Packet Services ) offerts par un ou plusieurs fournisseurs d'accès à l'Internet (ou ISP pour Internet Service Provider ). 30 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 2 2904914 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) entre un réseau d'accès radio WLAN et un réseau d'accès radio 3GPP. En d'autres termes, lorsqu'une station mobile utilise un service via un 5 réseau d'accès radio WLAN, elle doit pouvoir continuer à utiliser ce service lorsqu'elle quitte ce réseau d'accès radio WLAN pour poursuivre sa communication via un réseau d'accès radio 3GPP. II 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 io 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 15 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 ne peut utiliser un service, via un réseau d'accès radio 3GPP, qu'à condition que des tunnels aient été établis 20 d'une part entre cette 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 25 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 est contacté pour poursuivre la session doit déterminer l'identité de la 30 passerelle TTG utilisée jusqu'alors pour ladite 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 ), et initier une procédure de transfert de contexte PDP de service (qui 3 2904914 correspond à la connexion IP station mobile / noeud GGSN). Pour atteindre cet objectif, il a été proposé de modifier les noeuds SGSN afin que, chaque fois qu'ils reçoivent ce que l'homme de l'art appelle une notification de changement de zone (ou aire de routage) contenant un 5 identifiant d'aire de routage WLAN spécifique (par défaut une station mobile utilise la même valeur de RAI ( Routing Area Identifier -identifiant d'aire de routage), pour tous les WLANs), ils puissent contacter un serveur de localisation, appelé HLR (pour Home Location Register ), afin de lui demander l'identifiant de la passerelle TTG en vue d'initier le transfert de io contexte. Pour qu'un noeud SGSN puisse s'adresser au HLR pour obtenir l'identifiant et l'adresse IP d'une passerelle TTG, son comportement par défaut doit être modifié : dans un contexte inter SGSN il retrouve ces informations grâce à un RAI relatif à une zone de couverture et donc à un noeud SGSN particulier, par l'intermédiaire d'un serveur de type DNS (pour 15 Domain Name Server ). Cette solution présente deux inconvénients : comme indiqué ci-avant elle nécessite de modifier le mode de fonctionnement des noeuds SGSN, ce qui n'est pas très réaliste compte tenu du nombre élevé de noeuds SGSN déjà implantés, et elle implique que chaque fois qu'un noeud SGSN reçoit une 20 notification de changement de zone (ou aire de routage) qui déclenche la procédure de transfert (ou handover), il effectue un nouveau test afin de vérifier si le RAI est valide (ce qui signifie que le handover est de type inter-SGSN et qu'il doit exécuter la procédure normale avec un appel DNS) ou bien non signifiant (ce qui signifie que le handover est de type WLAN-3GPP et qu'il 25 doit demander au HLR les références de la passerelle TTG). L'invention a donc pour but de proposer une solution qui permet de maintenir la continuité de service lors du transfert d'une session de communication (impliquant un service) d'un réseau d'accès radio WLAN vers un réseau d'accès radio 3GPP, sans présenter tout ou partie des 30 inconvénients précités. Elle propose à cet effet un procédé, dédié à la gestion de l'inter-fonctionnement entre un réseau local sans fil (WLAN) et un réseau mobile 3GPP, et consistant, lorsqu'un noeud SGSN du réseau mobile reçoit 4 2904914 une notification de changement d'aire de routage (ou zone) émise par une station mobile lors d'une tentative de transfert du réseau local sans fil vers le réseau mobile d'une session de communication relative à un service impliquant cette station mobile et une passerelle de terminaison de tunnel et s un noeud GGSN du réseau mobile, via des tunnels de type bout en bout : i) à déterminer un identifiant de communication d'un noeud SGSN de type proxy du réseau mobile à partir de l'identifiant d'aire de routage qui est contenu dans la notification, afin de transmettre à ce noeud SGSN de type proxy un message requérant le contexte SGSN de transfert (ou SGSN lo context ) de la station mobile, ii) à récupérer auprès d'un serveur de localisation du réseau mobile, au moyen du noeud SGSN de type proxy, un identifiant de communication de la passerelle de terminaison de tunnel (TTG), afin de lui transmettre un message requérant le contexte SGSN de transfert de la station mobile, et 15 iii) en cas de réception du contexte SGSN de transfert par le noeud SGSN de type proxy, à transférer celui-ci vers le noeud SGSN afin d'effectuer une procédure de mise à jour de contexte PDP de service (ou PDP context ) destinée à supprimer et/ou modifier les tunnels de type bout en bout établis entre la station mobile et le noeud GGSN, via la passerelle de terminaison 20 de tunnel, et d'établir de nouveaux tunnels entre la station mobile et le noeud GGSN, via le noeud SGSN, pour assurer la continuité du service pendant le transfert de session de communication. Cette dernière phase permet notamment de conserver l'adresse IP attribuée au service durant son établissement (elle fait partie du PDP 25 context ) et de garder ainsi le service ouvert durant le handover, car l'attribution d'une nouvelle adresse IP entraînerait la fermeture du service puis sa réouverture. Le procédé selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : 30 - au iii) le noeud SGSN peut transmettre au noeud GGSN une demande de mise à jour de contexte PDP de service, puis adresser au serveur de localisation un message lui signalant qu'il se substitue à la passerelle de terminaison de tunnel, afin qu'il ordonne à un serveur de type AAA 5 2904914 ( Authentication, Authorization and Accounting - authentification, autorisation et comptabilité) du réseau mobile de procéder à la suppression du tunnel de type bout en bout entre la station mobile et la passerelle de terminaison de tunnel ; 5 - le noeud SGSN peut par exemple générer le message de signalement de substitution lorsqu'il reçoit un message de confirmation de substitution en provenance du noeud GGSN ; les identifiants de communication peuvent par exemple être des adresses IP et/ou des identifiants ISDN ; au iii), avant d'effectuer la procédure de mise à jour de contexte PDP de service on peut éventuellement effectuer des opérations de sécurisation ; au iii) on peut établir un tunnel bout en bout de type GTP (pour GPRS Tunnelling Protocol ) entre le noeud GGSN et le noeud SGSN. L'invention propose également un noeud SGSN, pour un réseau de communication mobile 3GPP, chargé, en cas de réception d'une notification de changement d'aire de routage émise par une station mobile lors d'une tentative de transfert d'un réseau local sans fil vers le réseau mobile d'une session de communication relative à un service impliquant cette station mobile et une passerelle de terminaison de tunnel (TTG) et un noeud GGSN du réseau mobile, via des tunnels de type bout en bout : i) de déterminer un identifiant de communication d'un noeud SGSN de type proxy du réseau mobile à partir de l'identifiant d'aire de routage contenu dans la notification (valeur par défaut, pour tous les WLANs qui renvoie vers le noeud SGSN de type proxy, via un serveur DNS), puis ii) de transmettre au noeud SGSN de type proxy un message requérant un contexte SGSN de transfert de la station mobile, et iii) en cas de réception du contexte SGSN de transfert, d'initier une procédure de mise à jour de contexte PDP de service destinée à supprimer et/ou modifier les tunnels de type bout en bout établis entre la station mobile et le noeud GGSN, via la passerelle de terminaison de tunnel (TTG), puis d'établir de nouveaux tunnels entre la station mobile et le noeud GGSN, via le noeud SGSN pour assurer la continuité du service pendant le transfert de session de communication. 6 2904914 Ce noeud SGSN peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : - il peut être chargé de transmettre au noeud GGSN une demande de mise à jour de contexte PDP de service, puis d'adresser à un serveur de 5 localisation du réseau mobile un message signalant qu'il se substitue à la passerelle de terminaison de tunnel, afin qu'il ordonne à un serveur de type AAA du réseau mobile de procéder à la suppression des tunnels de type bout en bout entre la station mobile et le noeud GGSN, via la passerelle de terminaison de tunnel ; io - il peut être chargé de générer le message de signalement de substitution en cas de réception d'un message de confirmation de substitution en provenance du noeud GGSN ; il peut être chargé de déterminer des identifiants de communication de type adresse IP et/ou identifiant ISDN ; 15 il peut être chargé d'effectuer des opérations de sécurisation auprès de la station mobile et du noeud GGSN avant d'effectuer la procédure de mise à jour du contexte PDP de service ; il peut être chargé d'établir un tunnel bout en bout de type GTP avec le noeud GGSN. 20 L'invention propose également un noeud SGSN de type proxy, pour un réseau de communication mobile, comprenant des moyens de traitement chargés en cas de réception, en provenance d'un noeud SGSN du type de celui présenté ci-avant, d'un message requérant un contexte SGSN de transfert d'une station mobile en cours de transfert, entre un réseau local sans 25 fil et le réseau mobile, d'une session de communication relative à un service, de récupérer auprès d'un serveur de localisation du réseau mobile un identifiant de communication d'une passerelle de terminaison de tunnel du réseau mobile, impliquée dans la session en cours de transfert, puis, en cas de réception de cet identifiant de communication, de récupérer auprès de la 30 passerelle de terminaison de tunnel le contexte SGSN de transfert requis afin de le transférer vers le noeud SGSN. De tels moyens de traitement peuvent par exemple être chargés de déterminer des identifiants de communication de type adresse IP et/ou 7 2904914 identifiant ISDN. 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 lesquels : 5 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 d'accès radio 3GPP, d'un exemple de réalisation d'un noeud SGSN de type lo proxy selon l'invention, et d'un noeud GGSN connecté à un réseau de service(s), et la figure 2 illustre de façon schématique les principales étapes d'un exemple de procédé de transfert de session de communication selon l'invention au sein du réseau mobile 3GPP illustré sur la figure 1 15 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 d'une session de communication (impliquant un service utilisé par une station mobile) d'un réseau d'accès radio WLAN vers 20 un réseau d'accès radio 3GPP. Dans ce qui suit, on considère à titre d'exemple illustratif et non 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 25 disposant d'une interface radio 3GPP permettant un accès IP et notamment les réseaux 2G (par exemple GSM), les réseaux 2,5G (par exemple GPRS/EDGE), 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 30 et non limitatif, que le réseau d'accès radio WLAN fait partie d'un réseau local 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 8 2904914 IEEE 802.11, Bluetooth et Hiperlan/2). L'invention propose un procédé dédié à la gestion de 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 s architecture de réseaux du type de celle illustrée sur la figure 1 et comprenant un coeur de réseau 3GPP CRD, un réseau (ou ensemble) de services (ou Packet Services) offerts par un ou plusieurs fournisseurs d'accès à l'Internet (ou ISP), 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. lo 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 15 network ). Mais cela n'est pas une obligation. II 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 permettant de se connecter à la fois aux réseaux d'accès radio WLAN (WAN) 20 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) équipé d'une carte du type précité. Le procédé selon l'invention doit être mis en oeuvre chaque fois 25 qu'une station mobile MS a établi une session de communication avec un réseau (ou ensemble) de services RS, par l'intermédiaire d'un réseau d'accès radio WLAN W1 et au moins de son coeur de réseau de domicile CRD, afin d'utiliser un service, et que cette station mobile MS doit se connecter à un réseau d'accès radio 3GPP RAN (éventuellement visité) afin de poursuivre 30 cette session de communication utilisée pour ledit service. La procédure d'établissement de la session de communication 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. II est simplement rappelé qu'une 9 2904914 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 routeur de son réseau WLAN et une passerelle de terminaison de tunnel ou TTG (pour s Tunnel Termination Gateway ), appartenant au coeur de réseau 3GPP CRD, via une interface appelée Wp, soit directement à une passerelle TTG, via l'interface Wp, lorsque cette passerelle TTG assure également la fonction de routeur. La passerelle TTG est connectée, via une interface appelée Gn', à un noeud de type GGSN (pour Gateway GPRS Support Node ) GSN io faisant également partie du coeur de réseau 3GPP CRD et servant de point d'accès, via une 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) RS. La passerelle TTG dispose d'au moins un identifiant de communication, comme par exemple une adresse IP, is ainsi qu'éventuellement d'un numéro (ou identifiant) ISDN. 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. La station mobile MS effectue pour ce faire une demande 20 dite DNS (pour Domain Name System ) (flèche FI de la figure 2). Puis, une fois qu'elle dispose de l'adresse IP de la passerelle TTG, la station mobile MS transmet à la passerelle TTG, via un point d'accès AP du réseau d'accès radio WLAN W1, une requête d'établissement d'un tunnel de bout en bout (ou end-to-end ), de type Tunnel Establishment Request (comportant 25 notamment des champs User-ID et W-APN), conformément aux spécifications techniques 3GPP TS 23.234. Ce tunnel de type bout en bout (ou end-to- end ) est par exemple de type VPN/Ipsec. Une fois qu'il a été établi entre la station mobile MS et la passerelle TTG (flèche F2 de la figure 2), via une interface appelé Wu, la passerelle TTG établit, via l'interface Gn', 30 un autre tunnel de type bout en bout avec le noeud GGSN NG qui fournit l'accès au service objet de la session requise (flèche F3 de la figure 2). Cet autre tunnel de type bout en bout est par exemple de type GTP (pour GPRS Tunnelling Protocol ). io 2904914 La passerelle TTG 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 s 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 session io de communication (ou handover ). Le procédé selon l'invention intervient précisément à ce stade. Le procédé a pour objectif de permettre à un noeud de type SGSN (pour Serving GPRS Support Node ) SN, appartenant au coeur de réseau 3GPP CRD et connecté via une interface appelée Gn au noeud GGSN NG qui 15 fournit l'accès au service objet de la session dont le transfert est requis, de prendre la relève de la passerelle TTG qui est impliquée dans cette session. 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 Node Bs et RNCs (pour Radio Network Controlers ) dans le cas d'un 20 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, via une interface appelée lu-PS. Chaque noeud SGSN dispose d'au moins un identifiant de communication, comme par exemple une adresse IP, ainsi qu'éventuellement d'un numéro (ou identifiant) ISDN, et est connecté à un 25 noeud de type GGSN NG 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. Lorsque la station mobile MS (en session) quitte la zone de couverture radio du réseau d'accès radio WLAN W1 et parvient dans la zone 30 de couverture radio du réseau d'accès radio 3GPP RAN, elle établit une connexion UMTS avec le noeud SGSN S1 qui est connecté au noeud GGSN NG qui fournit l'accès au service objet de la session, via un Node B et le RNC associé (flèche F4 de la figure 2). Puis, la station mobile MS génère à 11 2904914 destination du noeud SGSN S1 une notification de mise à jour d'aire de routage (ou zone), par exemple de type Routing Area Update Request() . Cette notification, qui comprend notamment un identifiant d'aire de routage (ou RAI pour Routing Area Identifier ) par défaut qui indique le s rattachement à un WLAN, est transmise au noeud SGSN S1 par le réseau d'accès radio WLAN W1 (flèche F5 de la figure 2). Lorsque le noeud SGSN Si reçoit la notification de mise à jour d'aire de routage, il doit tout d'abord déterminer un identifiant de communication d'un noeud SGSN de type proxy S2 que comprend le coeur de réseau CRD. 10 Le noeud SGSN de type proxy S2 est un nouvel équipement de réseau proposé par l'invention. Il est connecté, d'une première part, au noeud SGSN S1 via une interface appelée Gn, d'une deuxième part, à la passerelle TTG, par exemple via une autre interface Gn, et d'une troisième part, au serveur de localisation HLR, par exemple via une interface appelée Gr. Tout 15 comme l'autre noeud SGSN S1, le noeud SGSN de type proxy S2 dispose d'au moins un identifiant de communication, comme par exemple une adresse IP, ainsi qu'éventuellement d'un numéro (ou identifiant) ISDN. On notera qu'il est possible d'implanter plusieurs noeuds SGSN de type proxy dans un même coeur de réseau, par exemple pour effectuer une 20 répartition de charge, mais cela rend plus complexe la gestion de la valeur par défaut du RAI. Dans cette situation, il est par exemple possible d'utiliser plusieurs RAIs afin de répartir la charge vers plusieurs noeuds SGSN de type proxy associés respectivement à ces différents RAIs. Dans une variante, on peut utiliser un serveur DNS capable de changer de noeud SGSN de type 25 proxy lorsque le nombre de demandes reçues atteint un niveau choisi. On entend ici par noeud SGSN de type proxy un équipement de réseau qui supporte un sous-ensemble des fonctions supportées par un noeud SGSN classique (ou standard). Notamment, un tel équipement n'a pas besoin d'une interface vers la partie circuit du réseau, qui est dédiée au 3o transport de voix. La valeur par défaut du RAI renvoie systématiquement le noeud SGSN S1 vers le même noeud SGSN de type proxy S2. Le noeud SGSN S1 qui reçoit la notification de mise à jour interroge par exemple un serveur de 12 2904914 type DNS (pour Domain Name Server ) qui dispose d'une liste d'adresses IP (ou d'identifiants de communication) de noeuds SGSN de type proxy stockées en correspondance de l'identifiant d'aire de routage (ou RAI) par défaut. s Une fois que le noeud SGSN S1 a déterminé l'identifiant de communication du noeud SGSN de type proxy S2, il doit déterminer le contexte SGSN de transfert (ou SGSN context ) (objet de la session à transférer) utilisé par la station mobile MS, afin de pouvoir se substituer à la passerelle TTG. Pour ce faire, il génère un message requérant le contexte 10 SGSN de transfert, puis il transmet ce message (flèche F6 de la figure 2) au noeud SGSN de type proxy S2 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 auxquelles il est connecté (ou couplé). Le message de requête contient des informations telles que, notamment, 15 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 la passerelle TTG qui permet d'accéder au service objet de la session en cours de transfert. Le contexte SGSN de transfert qui doit être récupéré contient le 20 contexte PDP de service (ou PDP context ) ainsi que des éléments de sécurité propres à la station mobile MS concernée. Le contexte PDP de service (pour Packet Data Protocol ) représente la définition du service en cours. Il comprend notamment l'adresse IP du noeud GGSN NG qui sert de point d'accès à ce service, ainsi qu'éventuellement le numéro (ou identifiant) 25 ISDN dudit noeud GGSN NG. Par ailleurs, le message requérant le contexte SGSN de transfert est par exemple de type SGSN Context Request() . La récupération du contexte SGSN de transfert doit se faire en deux phases : une première dans laquelle on doit récupérer au moins un identifiant 30 de communication de la passerelle TTG concernée par le transfert, et une seconde dans laquelle on récupère le contexte SGSN de transfert auprès de ladite passerelle TTG. Le noeud SGSN de type proxy S2 comprend par exemple un module 13 2904914 de traitement MT chargé de récupérer auprès du serveur de localisation HLR les contextes SGSN de transfert relatifs aux passerelles TTG. Par conséquent, lorsque le noeud SGSN de type proxy S2 reçoit du noeud SGSN S1 un message par exemple de type SGSN Context Request() , son 5 module de traitement MT génère une demande comprenant les informations nécessaires à la récupération du contexte SGSN de transfert de la station mobile MS (pour la session en cours de transfert). Ce message est transmis par le noeud SGSN de type proxy S2 à destination du serveur de localisation HLR, via l'interface Gr (flèche F7 de la figure 2). Ce message est par exemple lo de type Location Request() . Lorsque le serveur de localisation HLR reçoit le message de type Location Request(), par exemple, il recherche dans sa mémoire ou base de données l'identifiant (ou les identifiants) de communication, par exemple l'adresse IP, de la passerelle TTG qui permet le déroulement de la session en 15 cours de transfert de la station mobile MS. Puis, le serveur de localisation HLR génère un message de réponse contenant cet (ces) identifiant(s) de communication et le transmet au noeud SGSN de type proxy S2, via l'interface Gr (flèche F8 de la figure 2). A réception de cet(ces) identifiant(s) de communication, le module de 20 traitement MT génère un nouveau message requérant le contexte SGSN de transfert de la station mobile MS qui a demandé le transfert. Ce message (requérant le contexte SGSN de transfert) est par exemple de type SGSN Context Request() . Le noeud SGSN de type proxy S2 transmet alors ce message de type SGSN Context Request(), par exemple, à destination de la 25 passerelle TTG identifiée dans le message de réponse reçu, via l'interface Gn (flèche F9 de la figure 2). En réponse à ce message reçu, la passerelle TTG génère un message de réponse contenant le contexte SGSN de transfert requis et le transmet au noeud SGSN de type proxy S2, via l'interface Gn (flèche F10 de 30 la figure 2). A réception de ce contexte SGSN de transfert, le module de traitement MT l'insère dans un message de réponse qui est transmis au noeud SGSN S1, via l'interface Gn (flèche F11 de la figure 2). 14 2904914 Lorsque le noeud SGSN S1 reçoit le message de réponse, il peut éventuellement effectuer des opérations de sécurisation auprès de la station mobile MS et du noeud GGSN identifié par le message reçu, avant d'effectuer une procédure de mise à jour du contexte PDP de service (flèches F12 et F13 s 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. Une fois ces éventuelles opérations de sécurisation effectuées, le noeud SGSN effectue une procédure de mise à jour de contexte PDP de service destinée à supprimer et/ou modifier les tunnels bout en bout (de types 10 VPN/IPSec et GTP) établis entre la station mobile MS et le noeud GGSN, via la passerelle de terminaison de tunnel TTG (flèches F2 et F3 de la figure 2), pour permettre le déroulement de la session en cours de transfert. Pour ce faire, il génère par exemple une demande de mise à jour de contexte PDP de service. Cette demande est par exemple de type Update 15 PDP Context Request() . Elle est destinée à signaler au noeud GGSN NG que le noeud SGSN S1 se substitue à la passerelle TTG pour la session de service de la station mobile MS. Elle comprend par conséquent le ou les identifiants de communication du noeud SGSN SI, l'identifiant de la station mobile MS ainsi que d'autres informations liées à celle-ci. La demande est 20 transmise par le noeud SGSN S1 à destination du noeud GGSN NG, identifié par le contexte SGSN de transfert reçu, via l'interface Gn (flèche F14 de la figure 2). A réception de cette demande, le noeud GGSN NG enregistre les informations qu'elle contient, puis il adresse à destination du noeud SGSN SI 25 un message d'accusé de réception (flèche F15 de la figure 2). Il est important de noter que cette mise à jour du contexte PDP de service n'entraîne pas la suppression effective du tunnel GTP associé à la session en cours de transfert, mais sa modification. En fait, cela ne fait que remplacer son extrémité côté passerelle TTG par une autre extrémité côté noeud SGSN, 30 l'adresse IP du service restant la même. A réception de ce message d'accusé de réception, le noeud SGSN SI doit alors mettre à jour le serveur de localisation HLR. Pour ce faire, il génère par exemple un message de signalisation de substitution du point d'accès de 15 2904914 la station mobile MS pour la session 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 S1 et l'identifiant de la station mobile MS. Le message est transmis par le noeud SGSN S1 à 5 destination du serveur de localisation HLR, via l'interface Gr (flèche F16 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 adresse à destination d'un serveur de type AAA SA du réseau mobile un lo message requérant la suppression du tunnel de type bout en bout (VPN/IPSec) entre la station mobile MS et la passerelle de terminaison de tunnel TTG, via une interface D'/Gr' (flèche F17 de la figure 2). Ce message est par exemple de type Cancel Location() . Il comprend par conséquent le ou les identifiants de communication du noeud SGSN S1, l'identifiant de la 15 station mobile MS, le ou les identifiants de communication de la passerelle TTG qui doi(ven)t être remplacé(s) par celui (ceux) du noeud SGSN SI en correspondance de l'identifiant de la station mobile MS (ou IMSI). A réception de ce message, le serveur de type AAA SA met à jour sa mémoire ou base de données avec les informations qu'il contient, puis il 20 adresse, à destination de la passerelle TTG identifiée dans ledit message, via une interface appelée Wm (flèche F18 de la figure 2), une demande de suppression du tunnel de type bout en bout (VPN/IPSec) établi entre elle et la station mobile MS. Cette demande est par exemple de type Tunnel Disconnection Command() . 25 A réception de cette demande, la passerelle TTG procède à la suppression du tunnel VPN/IPSec identifié, puis elle adresse au serveur de type AAA SA un message d'accusé de réception, via l'interface Wm (flèche F19 de la figure 2). A réception de ce message d'accusé de réception, le serveur de type 30 AAA SA adresse au serveur de localisation HLR un message d'accusé de réception, via l'interface Wm (flèche F20 de la figure 2), pour lui signaler que le tunnel VPN/IPSec a bien été supprimé. Ce message est par exemple de type Cancel Loc Ack() . 16 2904914 A réception de ce message d'accusé de réception le serveur de localisation HLR adresse à destination du noeud SGSN SI un message d'accusé de réception, via l'interface Gr (flèche F21 de la figure 2), afin de lui signaler que les mises à jour ont bien été effectuées. Ce message est par 5 exemple de type Update Location Ack() . A réception de ce message d'accusé de réception le noeud SGSN SI 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 (flèche F22 de la figure 2), afin de lui signaler qu'elle peut maintenant établir 10 de nouveaux tunnels pour poursuivre sa session 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 à l'établissement du nouveau tunnel entre elle et le noeud SGSN S1 (flèche F23 15 de la figure 2), l'autre nouveau tunnel (GTP) ayant été précédemment modifié (changement d'extrémité) afin de s'établir entre le noeud SGSN S1 et le noeud GGSN NG (flèche F24 de la figure 2). Grâce à ces deux nouveaux tunnels (flèches F23 et F24), la continuité du service est donc assurée pour la station mobile MS pendant le 20 transfert de la session de communication du réseau WLAN vers le réseau mobile 3GPP. Le module de traitement MT du noeud SGSN de type proxy S2 peut être réalisé sous la forme de circuits électroniques, de modules logiciels (ou informatiques), ou d'une combinaison de circuits et de logiciels. 25 L'invention est particulièrement avantageuse car elle ne nécessite pas de modification ou d'adaptation des noeuds SGSN et des noeuds GGSN déjà implantés dans les coeurs de réseau 3GPP. L'invention ne se limite pas aux modes de réalisation de noeud SGSN, de noeud SGSN de type proxy et de procédé de gestion décrits ci-30 avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après. 17 REVENDICATIONS 1. Procédé de gestion d'un interfonctionnement entre un réseau local sans fil et un réseau mobile, caractérisé en ce qu'il consiste, en cas de réception par un noeud de type SGSN (Si) dudit réseau mobile d'une notification de mise à jour d'aire de routage émise par une station mobile (MS) lors d'une tentative de transfert dudit réseau local sans fil vers ledit réseau mobile d'une session de communication relative à un service impliquant cette station mobile (MS) et une passerelle de terminaison de tunnel (TTG) et un io noeud de type GGSN (NG) dudit réseau mobile, via des tunnels de type bout en bout, i) à déterminer un identifiant de communication d'un noeud SGSN de type proxy (S2) dudit réseau mobile à partir de l'identifiant d'aire de routage contenu dans ladite demande de manière à transmettre à ce noeud SGSN de type proxy (S2) un message requérant un contexte SGSN de transfert de is ladite station mobile (MS), ii) à récupérer auprès d'un serveur de localisation (HLR) dudit réseau mobile, au moyen dudit noeud SGSN de type proxy (S2), un identifiant de communication de ladite passerelle de terminaison de tunnel (TTG) de manière à lui transmettre un message requérant ledit contexte SGSN de transfert de la station mobile (MS), et iii) en cas de réception dudit 20 contexte SGSN de transfert par ledit noeud SGSN de type proxy (S2), à transférer ce contexte SGSN de transfert vers ledit noeud SGSN (Si) de manière à effectuer une procédure de mise à jour de contexte PDP de service destinée à supprimer et/ou modifier lesdits tunnels de type bout en bout établis entre ladite station mobile (MS) et ledit noeud GGSN (NG), via ladite 25 passerelle de terminaison de tunnel (TTG), et à établir de nouveaux tunnels entre ladite station mobile (MS) et ledit noeud GGSN (NG), via ledit noeud SGSN (Si), pour assurer la continuité du service pendant ledit transfert de session de communication. 2. Procédé selon la revendication 1, caractérisé en ce qu'au iii) ledit 30 noeud SGSN (Si) transmet audit noeud GGSN (NG) une demande de mise à jour de contexte PDP de service, puis adresse audit serveur de localisation (HLR) un message signalant qu'il se substitue à ladite passerelle de terminaison de tunnel (TTG), de sorte qu'il ordonne à un serveur de type AAA ls 2904914 (SA) dudit réseau mobile de procéder à ladite suppression du tunnel de type bout en bout entre ladite station mobile (MS) et ladite passerelle de terminaison de tunnel (TTG). 3. Procédé selon la revendication 2, caractérisé en ce que ledit noeud 5 SGSN génère ledit message de signalement de substitution à réception d'un message de confirmation de substitution en provenance dudit noeud GGSN (NG). 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que lesdits identifiants de communication sont des adresses IP et/ou des io identifiants ISDN. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'au iii) avant d'effectuer ladite procédure de mise à jour de contexte PDP de service on effectue des opérations de sécurisation. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce 15 qu'au iii) on établit un tunnel bout en bout de type GTP entre ledit noeud GGSN (NG) et ledit noeud SGSN (Si). 7. Noeud SGSN (SI) pour un réseau de communication mobile, caractérisé en ce qu'il est agencé, en cas de réception d'une notification de mise à jour d'aire de routage émise par une station mobile (MS) lors d'une 20 tentative de transfert d'un réseau local sans fil vers ledit réseau mobile d'une session de communication relative à un service impliquant cette station mobile (MS) et une passerelle de terminaison de tunnel (TTG) et un noeud de type GGSN (NG) dudit réseau mobile, via des tunnels de type bout en bout, i) pour déterminer un identifiant de communication d'un noeud SGSN de type 25 proxy (S2) dudit réseau mobile à partir de l'identifiant d'aire de routage contenu dans ladite demande, puis ii) pour transmettre audit noeud SGSN de type proxy (S2) un message requérant un contexte SGSN de transfert de ladite station mobile (MS), et iii) en cas de réception dudit contexte SGSN de transfert, pour initier une procédure de mise à jour de contexte PDP de 30 service destinée à supprimer et/ou modifier lesdits tunnels de type bout en bout établis entre ladite station mobile (MS) et ledit noeud GGSN (NG), via ladite passerelle de terminaison de tunnel (TTG), puis à établir de nouveaux tunnels entre ladite station mobile (MS) et ledit noeud GGSN (NG), via ledit 19 2904914 noeud SGSN (Si) pour assurer la continuité du service pendant ledit transfert de session de communication. 8. Noeud SGSN selon la revendication 7, caractérisé en ce qu'il est agencé pour transmettre audit noeud GGSN (NG) une demande de mise à s jour de contexte PDP de service, puis pour adresser à un serveur de localisation (HLR) dudit réseau mobile un message signalant qu'il se substitue à ladite passerelle de terminaison de tunnel (TTG), de sorte qu'il ordonne à un serveur de type AAA (SA) dudit réseau mobile de procéder à ladite suppression des tunnels de type bout en bout entre ladite station mobile (MS) lo et ledit noeud GGSN (NG), via ladite passerelle de terminaison de tunnel (TTG). 9. Noeud SGSN selon la revendication 8, caractérisé en ce qu'il est agencé pour générer ledit message de signalement de substitution à réception d'un message de confirmation de substitution en provenance dudit 15 noeud GGSN (NG). 10. Noeud SGSN selon l'une des revendications 7 à 9, caractérisé en ce qu'il est agencé pour déterminer des identifiants de communication de type adresse IP et/ou identifiant ISDN. 11. Noeud SGSN selon l'une des revendications 7 à 10, caractérisé en 20 ce qu'il est agencé pour effectuer des opérations de sécurisation auprès de ladite station mobile (MS) et dudit noeud GGSN (NG) avant d'effectuer ladite procédure de mise à jour de contexte PDP de service. 12. Noeud SGSN selon l'une des revendications 7 à 11, caractérisé en ce qu'il est agencé pour établir un tunnel bout en bout de type GTP avec ledit 25 noeud GGSN (NG). 13. Noeud SGSN de type proxy (S2) pour un réseau de communication mobile, caractérisé en ce qu'il comprend des moyens de traitement (MT) agencés en cas de réception, en provenance d'un noeud SGSN (Si) selon l'une des revendications 7 à 12, d'un message requérant un contexte SGSN 30 de transfert d'une station mobile (MS), en cours de transfert entre un réseau local sans fil et ledit réseau mobile, d'une session de communication relative à un service, i) pour récupérer auprès d'un serveur de localisation (HLR) dudit réseau mobile un identifiant de communication d'une passerelle de 20 2904914 terminaison de tunnel (TTG) dudit réseau mobile, impliquée dans ladite session en cours de transfert, puis ii) à réception de cet identifiant de communication, pour récupérer auprès de ladite passerelle de terminaison de tunnel (TTG) ledit contexte SGSN de transfert requise afin de la transférer s vers ledit noeud SGSN (SI). 14. Noeud SGSN de type proxy selon la revendication 13, caractérisé en ce que lesdits moyens de traitement (MT) sont agencés pour déterminer un identifiant de communication de type adresse IP et/ou identifiant ISDN.