FR 3025387 A1 20160304 FR 1458246 A 20140903 1 Arrière-plan de l'invention L'invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement une architecture de coeur de réseau IP (Internet Protocol). L'invention s'applique ainsi de façon privilégiée mais non limitative aux réseaux de communication conformes à la norme LTE (Long Term Evolution) définie par le consortium de standardisation 3GPP (Third Generation Partnership Project), et plus spécifiquement à l'architecture d'un coeur de réseau LTE/EPC (Evolved Packet Core). Une augmentation exponentielle du trafic des télécommunications mobiles est attendue dans les prochaines années, dynamisée par l'apparition de nouvelles applications, de nouveaux terminaux et de débits de communication de plus en plus élevés, ainsi que de nouveaux acteurs dans le domaine des télécommunications mobiles, tels que les opérateurs de réseaux mobiles virtuels aussi connus sous l'appellation de MVNO (Mobile Virtual Network Operator). De façon connue en soi, ces opérateurs MVNO disposent généralement de leurs propres coeurs de réseau, ce qui leur permet de développer et de proposer leurs propres applications aux utilisateurs, mais s'appuient sur les réseaux d'accès des opérateurs traditionnels. Dans ce contexte, l'architecture LTE/EPC a été définie par le consortium 3GPP pour fournir une connectivité IP transparente entre un terminal d'un utilisateur, autrement désigné par équipement utilisateur (ou UE pour « User Equipment »), et des réseaux de paquets de données (ou PDNs pour « Packet Data Networks ») aptes à offrir à ce terminal divers services de communication, tels que des services de voix sur IP ou VoIP (Voice over IP), de téléchargements de données, de vidéos à la demande, etc. Cette architecture repose sur : un réseau d'accès (ou E-UTRAN pour « Evolved-Universal Terrestrial Radio Access Network ») auquel est connecté le terminal de l'utilisateur via une station de base désignée par « eNodeB » (eNB) ; et un coeur de réseau IP (ou EPC) gérant les échanges de données, en liaisons montante et descendante, entre ce terminal et les réseaux de paquets de données reliés au coeur de réseau. La figure 1 représente schématiquement les différents équipements de réseau sur lesquels s'appuie l'architecture LTE/EPC dans sa définition actuelle par le consortium 3GPP, et telle que décrite notamment dans le document 3GPP TS 23.401 intitulé « Technical Specification Group Services and System aspects ; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access », Release 12, mars 2013. A titre indicatif, les échanges prévus entre ces équipements pour le transfert des données (i.e. dans le plan de données ou plan utilisateur) sont modélisés par des traits pleins, tandis que les échanges de signalisation prévus entre ces équipements pour supporter ces transferts de données (i.e. dans le plan de contrôle ou de signalisation) sont modélisés par des traits discontinus. 3025387 2 Plus précisément sur la figure 1, le coeur de réseau EPC 1 permet à un terminal utilisateur UE 2, rattaché à (i.e. servi par) une station de base eNB 3A d'un réseau d'accès tel qu'un réseau de télécommunications mobile, d'accéder à des services offerts par un réseau de paquets de données externe PDN 4. 5 A cet effet, le coeur de réseau EPC 1 comprend quatre types d'équipements, à savoir : une passerelle de transfert de données 5, autrement appelée passerelle SGW (pour « Serving GateWay »), située entre le réseau d'accès et le coeur de réseau 1 ; une passerelle d'interconnexion 6, autrement appelée passerelle PGW (pour « PDN GateWay »), permettant de connecter le coeur de réseau 1 au réseau externe 4 de paquets de 10 données ; un équipement 7 de gestion de mobilité des terminaux, autrement désigné par équipement MME (pour « Mobility Management Entity »), en charge d'assurer la connectivité IP des terminaux lorsque ceux-ci sont en situation de mobilité ; et une base de données utilisateurs 8, autrement appelée serveur d'abonnés du réseau HSS 15 (pour « Home Subscriber Server »). Les stations de base 3A et 3B sont connectées directement à l'équipement MME 7 et à la passerelle de transfert de données SGW 5 par l'intermédiaire d'interfaces S1-MME et S1-U respectivement. L'équipement MME 7 gère la mobilité et la connectivité réseau (IP) du terminal 2. Elle 20 est responsable de son authentification (en vue de l'autoriser à accéder au coeur de réseau 1), et gère l'établissement de sessions de communication pour ce terminal ainsi que la mobilité intra3GPP. Les passerelles SGW 5 et PGW 6 sont responsables du transfert des données au sein du coeur de réseau 1, de la gestion de la mobilité et du contrôle de la qualité de service dans le 25 plan de données. L'équipement MME 7 est connecté à la passerelle de transfert de données SGW 5 par l'intermédiaire d'une interface logique S11. La passerelle de transfert de données SGW 5 est connectée à la passerelle d'interconnexion PGW 6 par l'intermédiaire d'une interface S5. La gestion de la mobilité des terminaux au sein du réseau s'appuie selon la définition 30 actuelle de l'architecture LTE/EPC sur le protocole GTP (GPRS Tunneling Protocol). Ce protocole comporte plusieurs composantes, dont : le protocole GTP-U, utilisé pour le transfert (échange) de données utilisateur entre deux tunnels de communication séparés, afin de gérer les situations de mobilité du terminal utilisateur sur les interfaces 51 et S5 ; et 35 - le protocole GTP-C utilisé pour établir, mettre à jour et maintenir les tunnels de communication GTP. Les échanges de signalisation sur les interfaces S11 et S5 s'appuient ainsi sur le protocole GTP-C. 3025387 3 Des tunnels de communication GTP distincts sont établis pour les différents types de trafic échangés dans le réseau (i.e. pour chaque qualité de service), et plus spécifiquement, pour chaque session de communication PDP (Packet Data Protocol) gérée par le coeur de réseau. Le protocole de communication GTP contribue donc non seulement à la gestion de la mobilité des 5 terminaux mais également à la gestion de la qualité de service dans le réseau. L'architecture LTE/EPC telle qu'elle est actuellement définie par le consortium 3GPP n'est pas réellement optimisée et rend difficile l'intégration de nouveaux services par les opérateurs des coeurs de réseau IP, qu'il s'agisse d'opérateurs traditionnels ou de type MVNO. En effet, outre la quantité de signalisation importante induite par l'utilisation du 10 protocole GTP pour gérer la mobilité des terminaux et la qualité de service dans le réseau, les passerelles PGW d'interconnexion avec les réseaux de paquets externes, les passerelles SGW de transfert de données et l'équipement MME de gestion de mobilité sont prévus sur des équipements matériels (i.e. « hardware ») spécialisés qui sont conçus spécifiquement pour répondre à la demande des opérateurs. Ces équipements sont donc particulièrement coûteux et difficiles à gérer. 15 Ils sont figés et doivent être provisionnés et configurés de manière statique. Ce choix d'implémentation offre peu de flexibilité en matière de réutilisation et/ou de réorganisation des ressources, notamment en cas d'incidents affectant le réseau (telle une congestion du réseau par exemple). Le réseau est dimensionné en tenant compte de la charge du réseau aux heures de pointe (ou de pic) et pour augmenter la capacité du réseau, il est nécessaire 20 de déployer de nouveaux équipements matériels sur des sites spécifiques du réseau. La maintenance et le fonctionnement d'un tel réseau, configuré ainsi de manière statique, sont donc particulièrement coûteux, consommateurs en temps, et laborieux à mettre en oeuvre. Il apparait bien dès lors les limites de l'architecture LTE/EPC actuelle par rapport à l'intégration de nouveaux services par les opérateurs de télécommunications mobiles. 25 Le document de J. Kempf et al. intitulé « Moving the Mobile Evolved Packet Core to the Cloud », 5th International Workshop on Selected Topics in Mobile and Wireless Computing, 2012, propose une évolution de l'architecture de coeur de réseau LTE/EPC définie par le consortium 3GPP dans laquelle les plans de données et de contrôle sont séparés, et qui utilise le principe de réseau défini par logiciel communément désigné par SDN pour « Software Defined Networking ». 30 De façon connue, une architecture de réseau SDN permet de découpler les plans de contrôle et de données en centralisant l'intelligence du réseau (c'est-à-dire les fonctions de contrôle du réseau) au niveau d'un dispositif de contrôle logiciel. Le comportement des équipements du réseau est alors défini par des règles reçues du dispositif de contrôle, telles que des règles de traitement ou de transfert des données (i.e. du trafic). Le concept SDN s'appuie sur 35 le protocole de communication OpenFlowTM défini par l'ONF (Open Networking Foundation), qui permet une programmation simplifiée, via une interface standard, des équipements du réseau. Plus spécifiquement, le document de J. Kempf et al. propose de déplacer les fonctions actuelles de l'équipement MME ainsi que le plan de contrôle des passerelles de transfert de 3025387 4 données SGW et de la passerelle d'interconnexion PGW, dans des applications s'exécutant au-dessus d'un dispositif de contrôle implémenté par une machine virtuelle localisée dans un centre de données externe. Un tel centre de données externe est aussi connu sous l'appellation de nuage informatique ou de « cloud » en anglais. Les applications interagissent avec le dispositif de 5 contrôle logiciel par le biais d'interfaces de programmation ou API (Application Programming Interfaces). Les équipements du plan de données des passerelles de transfert et de la passerelle d'interconnexion sont remplacés par des commutateurs OpenFlowTM. Le dispositif de contrôle est responsable de l'établissement du plan de données. Cette proposition s'appuie toutefois sur les mêmes interfaces entre les entités de 10 contrôle du réseau que celles définies par le consortium 3GPP et mentionnées précédemment (typiquement sur les interfaces S1, S11 et S5 utilisant le protocole GTP). Ces interfaces reposent sur des procédures qui peuvent s'avérer complexes (ex. procédure de restauration), notamment en cas de dysfonctionnement détecté au niveau d'un équipement du plan de données tel que par exemple une surcharge ou une défaillance d'une passerelle de transfert SGW, et qui ne sont pas 15 toujours transparentes pour les utilisateurs, entraînant de ce fait une dégradation de l'expérience des utilisateurs. De façon similaire, l'architecture proposée par J. Kempf et al. ne permet pas de gérer facilement une défaillance ou une surcharge d'une fonction du plan de contrôle du coeur de réseau, telle que par exemple de la fonction MME. 20 Par conséquent, la solution proposée par J. Kempf et al., même si elle offre la possibilité de simplifier la maintenance et la configuration des équipements du coeur de réseau, ne permet pas de fournir une qualité d'expérience aux utilisateurs adaptée à leurs besoins et qui répond à la demande croissante des opérateurs d'intégrer aisément de nouveaux services. 25 Objet et résumé de l'invention L'invention offre une solution notamment à ce problème en proposant un dispositif de contrôle d'un coeur de réseau IP, apte à commander une station de base d'un réseau d'accès, un commutateur du coeur de réseau IP et une passerelle d'interconnexion du coeur de réseau IP à un réseau externe de paquets de données, ce dispositif de contrôle comprenant : 30 un module de communication, apte à communiquer avec un serveur de connexion à un système informatique en nuage et, par l'intermédiaire de ce serveur, avec une pluralité de fonctions virtuelles d'un plan de contrôle du coeur de réseau IP instanciées dans le système informatique en nuage ; un module de gestion : 35 o d'une première base de données identifiant, pour au moins un terminal d'un utilisateur géré par le coeur de réseau IP et servi par la station de base, au moins une des fonctions virtuelles allouée à ce terminal ; et 3025387 5 o d'une seconde base de données associant à au moins une des fonctions virtuelles, un identifiant de cette fonction auprès du serveur de connexion et un état de cette fonction ; ce module de gestion étant apte à mettre à jour la première et/ou la seconde base de données 5 à partir d'informations reçues par le module de communication en provenance du serveur de connexion et/ou des fonctions virtuelles ; et un module de commande apte à utiliser des données des bases de données pour établir et/ou maintenir, pour un terminal géré par le coeur de réseau IP, un plan usager entre la station de base, le commutateur et la passerelle d'interconnexion. 10 Corrélativement, l'invention vise également un procédé de contrôle d'un coeur de réseau IP comprenant : une étape de réception d'informations en provenance d'un serveur de connexion à un système informatique en nuage, et/ou d'au moins une fonction virtuelle d'un plan de contrôle du coeur de réseau IP instanciée dans le système informatique en nuage par l'intermédiaire du serveur 15 de connexion ; une étape de gestion : o d'une première base de données identifiant, pour au moins un terminal d'un utilisateur géré par le coeur de réseau IP au moins une des fonctions virtuelles allouée à ce terminal ; et/ou 20 o d'une seconde base de données associant à au moins une des fonctions virtuelles, un identifiant de cette fonction auprès du serveur de connexion et un état de cette fonction ; cette étape de gestion comprenant une mise à jour de la première et/ou de la seconde base de données à partir desdites informations reçues ; et 25 une étape d'établissement et/ou de maintien, pour un terminal géré par le coeur de réseau IP, d'un plan usager entre une station de base d'un réseau d'accès servant le terminal, un commutateur du coeur de réseau IP et une passerelle d'interconnexion du coeur de réseau IP à un réseau externe de paquets de données, en utilisant des données de la première et/ou de la deuxième base de données. 30 L'invention s'appuie ainsi sur les principes SDN du réseau défini par logiciel pour découpler les plans usager (ou de données) et de contrôle (ou de signalisation) dans le coeur de réseau IP. Il en résulte une nouvelle architecture de coeur de réseau IP programmable, permettant une (re)configuration dynamique du plan usager et du plan de contrôle. Plus précisément, l'invention propose d'établir et de commander, par l'intermédiaire 35 d'un dispositif de contrôle par exemple logiciel, un plan usager relativement simple s'appuyant sur des passerelles d'interconnexion du coeur de réseau IP à des réseaux externes de paquets de données, des commutateurs déployés dans le coeur de réseau IP (et opérant au niveau de la couche 2 du modèle OSI (Open Systems Interconnection)), et des stations de base de réseaux 3025387 6 d'accès connectés à ces commutateurs. Les stations de base des réseaux d'accès, les commutateurs et les passerelles d'interconnexion sont connectées directement au dispositif de contrôle, ce qui facilite le contrôle exercé par ce dernier. Dans un mode particulier de réalisation, le procédé de contrôle comprend une étape 5 de commande de la station de base et/ou du commutateur et/ou de la passerelle d'interconnexion, cette étape de commande comprenant la transmission à la station de base et/ou au commutateur et/ou à la passerelle d'interconnexion d'au moins une règle de traitement de flux de données relatifs au terminal, ladite au moins une règle de traitement étant définie à partir de données de la première et/ou de la seconde base de données et étant destinée à être appliquée lors d'un 10 transfert de données dans le plan usager. Autrement dit, le contrôle exercé par le dispositif de contrôle sur les équipements de réseau du plan usager se traduit notamment par la transmission de règles de traitement et de routage des flux de données relatifs aux terminaux gérés par le coeur de réseau IP (autrement dit destinés à ou en provenance de ces terminaux), ces règles de traitement étant destinées à être 15 appliquées par les équipements de réseau commandés par le dispositif de contrôle (i.e. commutateurs, stations de base et passerelles d'interconnexion). Elles sont définies par le dispositif de contrôle à partir des informations stockées dans les première et seconde bases de données, et de ses interactions avec les fonctions du plan de contrôle du coeur de réseau IP. Les fonctions du plan de contrôle du coeur de réseau IP comprennent par exemple : 20 - au moins une fonction de gestion de la mobilité de terminaux dans le coeur de réseau IP ; et/ou - au moins une fonction de contrôle de la passerelle d'interconnexion et/ou du commutateur. On note qu'il peut s'agir d'une fonction unique qui gère à la fois une passerelle d'interconnexion et les commutateurs connectés à cette passerelle, ou une fonction distincte pour la passerelle 25 d'interconnexion et pour les commutateurs. De façon avantageuse, ces fonctions du plan de contrôle sont des fonctions virtuelles instanciées dans un système informatique en nuage, par exemple sur des machines virtuelles distinctes, ce qui permet d'adapter aisément en temps réel leur nombre, leurs configurations et/ou encore leurs capacités, en fonction des besoins de l'opérateur du coeur de réseau IP et des 30 terminaux gérés par ce dernier. On peut en particulier, grâce à l'invention, instancier plusieurs fonctions de contrôle d'un même type, par exemple plusieurs fonctions de gestion de la mobilité des terminaux, la gestion et le provisionnement de ces fonctions étant facilités par les bases de données maintenues par le dispositif de contrôle. Ces fonctions de contrôle communiquent avec le dispositif de contrôle par 35 l'intermédiaire d'un serveur de connexion au système informatique en nuage qui tient informé le dispositif de contrôle de l'état de ces fonctions, notamment en termes de disponibilité et/ou de charge. Ce serveur de connexion permet de provisionner facilement de nouvelles fonctions dans le système informatique en nuage en cas de besoin. Ces informations de disponibilité et d'état 3025387 7 fournies par le serveur de connexion sont stockées par le dispositif de contrôle dans la seconde base de données en association avec un identifiant de chaque fonction du plan de contrôle instanciée dans le système informatique en nuage. Ces informations viennent compléter les informations stockées dans la première base de données qui permettent au dispositif de contrôle 5 d'identifier aisément les fonctions du plan de contrôle allouées à un terminal de sorte à pouvoir établir et maintenir (incluant une adaptation du plan usager si besoin) de manière simple et efficace un plan usager pour le transfert de flux de données pour ce terminal. Le serveur de connexion qui réalise l'intermédiaire entre le dispositif de contrôle et les fonctions virtuelles du plan de contrôle instanciées dans le système informatique en nuage est par 10 exemple un serveur dont le dispositif de contrôle et les fonctions virtuelles sont des clients, et avec lesquels il communique en utilisant le protocole de communication XMPP (eXtensible Messaging and Presence Protocol). Un tel serveur permet en outre de sécuriser l'accès au coeur de réseau IP en n'ouvrant cet accès qu'à des applications ou des fonctions virtuelles autorisées et authentifiées. 15 Ainsi, l'invention vise également un serveur de connexion à un système informatique en nuage, ce serveur comprenant : un module de gestion d'une base de données associant à au moins un client du serveur de connexion un identifiant de ce client auprès du serveur de connexion et un état du client, ledit au moins un client comprenant au moins une fonction virtuelle d'un plan de contrôle d'un coeur 20 de réseau IP instanciée dans le système informatique en nuage et un dispositif de contrôle du coeur de réseau IP selon l'invention ; et - un module de communication apte à communiquer avec ladite au moins une fonction virtuelle et le dispositif de contrôle, et apte à transmettre au dispositif de contrôle des informations extraites de la base de données relatives à ladite au moins une fonction virtuelle. 25 Les capacités d'un tel serveur (et notamment la base de données clients qu'il maintient), ainsi que ses interactions avec le dispositif de contrôle et les fonctions virtuelles du plan de contrôle du coeur de réseau IP permettent au dispositif de contrôle de surveiller l'état de ces fonctions en temps réel et d'adapter en temps réel, en fonction de cet état, la topologie du plan de contrôle du coeur de réseau IP. 30 Ainsi, par exemple, si une fonction de gestion de la mobilité des terminaux (ou fonction MME) est surchargée, le dispositif de contrôle en est informé par l'intermédiaire du serveur de connexion et peut agir de manière appropriée. Il peut notamment sélectionner une nouvelle fonction virtuelle de contrôle instanciée dans le système informatique en nuage, ou demander l'instanciation d'une nouvelle fonction virtuelle dans le système informatique en nuage, 35 ou encore équilibrer le trafic entre les fonctions virtuelles de gestion de la mobilité déjà instanciées. L'action du serveur de connexion dans une telle situation peut être : - réactive, en informant le dispositif de contrôle de l'état de surcharge courant de la fonction de gestion de la mobilité pour que celui-ci envisage une action appropriée ; ou 3025387 8 - proactive, en fournissant au dispositif de contrôle une liste de fonctions de gestion de la mobilité disponibles. Il en résulte une flexibilité de la gestion du coeur de réseau et une amélioration de la fiabilité de la connectivité IP offerte aux terminaux par celui-ci. L'expérience des utilisateurs est 5 ainsi privilégiée. L'invention s'applique ainsi de façon privilégiée à une architecture de coeur de réseau LTE/EPC. Dans un tel contexte, et contrairement à l'état de la technique décrit dans le document de J. Kempf et al, l'architecture proposée par l'invention offre d'autres interfaces entre les équipements de réseau sur lesquels s'appuie le plan usager et les fonctions du plan de contrôle du 10 coeur de réseau IP que les interfaces définies actuellement dans le standard LTE. Plus spécifiquement, l'invention propose de remplacer les protocoles de communication prévus sur les interfaces de communication S1-MME (entre les stations de base eNodeB et l'entité de gestion de la mobilité MME du coeur de réseau), S5 (entre les passerelles de transfert de données SGW et les passerelles d'interconnexion du coeur de réseau IP aux réseaux externes de paquets de données 15 PGW) et S11 (entre l'entité de gestion de la mobilité et les passerelles de transfert de données SGW). La nouvelle architecture de coeur de réseau définie par l'invention permet ainsi de simplifier certaines procédures définies par le standard. Ainsi notamment, elles permettent une mise à jour directe par le dispositif de contrôle des stations de base en cas de défaillance d'un commutateur. L'invention offre par ce biais aux terminaux des procédures plus souples et plus 20 transparentes en termes de connectivité IP, qui ne nécessitent pas de signalisation excessive. En outre, comme mentionné précédemment, le fait que les fonctions du plan de contrôle soient instanciées dans un système informatique en nuage, et la gestion de ces fonctions par le dispositif de contrôle permise par le maintien à jour des première et seconde bases de données du dispositif de contrôle et de la base de données clients du serveur de connexion, 25 permettent de provisionner ces fonctions virtuelles suivant les besoins des opérateurs de télécommunications. Ceci peut permettre notamment de faciliter l'intégration de nouveaux opérateurs de télécommunications, et notamment d'opérateurs virtuels, en simplifiant le contrôle de l'accès offert à ces derniers et leur utilisation des équipements (éventuellement virtuels) de l'opérateur 30 traditionnel auquel ils sont rattachés. L'invention permet de ne pas se limiter à un partage classique du réseau d'accès tel qu'il est généralement mis en oeuvre aujourd'hui entre les opérateurs traditionnels et les opérateurs virtuels, mais d'envisager d'autres façons d'intégrer des opérateurs virtuels. On peut ainsi par exemple allouer une fonction virtuelle distincte du plan de contrôle à chaque opérateur virtuel utilisant l'infrastructure de l'opérateur traditionnel considéré. La 35 gestion et l'activité des fonctions virtuelles allouées respectivement à plusieurs opérateurs virtuels sont simplifiées grâce à la base de données clients maintenue par le serveur de connexion. Dans un mode particulier de réalisation, le dispositif de contrôle selon l'invention comprend en outre un module d'allocation apte à allouer au terminal géré par le coeur de réseau IP 3025387 9 au moins une dite fonction virtuelle instanciée dans le système informatique en nuage en fonction d'une information représentative d'un état de disponibilité et/ou de charge courant de cette fonction virtuelle, transmise par le serveur de connexion. Corrélativement, le module de communication est apte à transmettre au dispositif de 5 contrôle une information représentative d'un état de disponibilité et/ou de charge courant d'au moins une dite fonction virtuelle identifiée dans la base de données. Corrélativement encore, le procédé de contrôle comprend en outre une étape d'allocation d'une des fonctions virtuelles du plan de contrôle au terminal en fonction d'une information représentative d'un état de disponibilité et/ou de charge courant de cette fonction 10 transmis par le serveur de connexion. Cette information de disponibilité ou d'état de charge courant peut être aisément obtenue par le serveur de connexion, notamment lorsque celui-ci est un serveur XMPP. Le module d'allocation du dispositif de contrôle (respectivement l'étape d'allocation du procédé de contrôle) permet de gérer efficacement et rapidement les situations de surcharge ou 15 de défaillance des fonctions du plan de contrôle pouvant affecter le coeur de réseau IP. En outre, il joue également un rôle important lors de l'établissement du plan usager supportant une session de communication d'un terminal, pour allouer à ce terminal des fonctions du plan de contrôle aptes à gérer les communications de ce terminal. Dans un autre mode de réalisation, la première base de données utilisateurs du 20 dispositif de contrôle comprend en outre, pour le terminal, au moins un paramètre de communication destiné à être utilisé pour un transfert de données dans le plan usager établi par le module de commande. Par exemple, ledit au moins un paramètre de communication comprend une adresse de la passerelle d'interconnexion, une adresse du commutateur et des identifiants de points 25 d'extrémité d'un tunnel de communication établi dans le plan usager. Ces paramètres de communication permettent l'établissement d'un tunnel de communication dans le plan usager entre la station de base et la passerelle d'interconnexion : ce tunnel de communication est par exemple un tunnel GTP. Ces paramètres de communication sont centralisés au niveau du dispositif de contrôle ce qui lui permet de définir facilement des règles de 30 traitement des flux de données destinés ou émis par le terminal, avec lesquelles il commande les équipements de réseau définissant le plan usager établi pour ce terminal. Il convient de noter qu'avantageusement, l'invention permet l'établissement d'un tunnel de communication unique entre la station de base et la passerelle d'interconnexion avec le réseau externe. Au contraire, dans l'état de la technique présenté par J. Kempf et al. comme dans 35 le standard 3GPP, un premier tunnel de communication est établi entre la station de base et la passerelle de transfert de données SGW à laquelle la station de base est connectée, et un second tunnel de communication est établi entre la passerelle de transfert de données et la passerelle d'interconnexion avec le réseau externe. L'établissement de ces tunnels (conformes au protocole 3025387 10 GTP dans le standard 3GPP) requiert à chaque fois l'échange de diverses informations et notamment d'identifiants de tunnels, ce qui induit une forte signalisation et peut s'avérer complexe notamment lorsque des procédures de restauration de ces tunnels sont mises en oeuvre. L'invention permet donc de limiter la signalisation induite dans le coeur de réseau IP. 5 Selon un autre aspect, l'invention vise aussi : un dispositif de contrôle selon l'invention ; un serveur de connexion à un système informatique en nuage selon l'invention ; et au moins une fonction virtuelle d'un plan de contrôle du coeur de réseau IP instanciée dans le système informatique en nuage ; 10 le dispositif de contrôle et ladite au moins une fonction virtuelle étant des clients du serveur de connexion. Le coeur de réseau IP bénéficie des mêmes avantages que ceux cités précédemment pour le dispositif de contrôle et le serveur de connexion. Dans un mode particulier de réalisation, les différentes étapes du procédé de contrôle 15 sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un dispositif de contrôle ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de contrôle tel que décrit ci-dessus. 20 Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 25 Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un 30 signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution 35 du procédé en question. On peut également envisager, dans d'autres modes de réalisation, que le procédé de contrôle, le dispositif de contrôle, le serveur de connexion et le coeur de réseau IP selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. 3025387 11 Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de 5 réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1, déjà décrite, représente l'architecture d'un coeur de réseau LTE/EPC telle que proposée par le consortium 3GPP ; les figures 2 et 3 illustrent les principes d'un réseau SDN défini par logiciel ; la figure 4 représente, dans son environnement, un coeur de réseau comprenant un dispositif 10 de contrôle et un serveur de connexion conformes à l'invention dans un mode particulier de réalisation ; les figures 5A et 5B représentent schématiquement l'architecture matérielle d'un dispositif informatique implémentant le dispositif de contrôle et celle d'un dispositif informatique implémentant le serveur de connexion illustrés à la figure 4 ; et 15 les figures 6 et 7 représentent respectivement les principales étapes mise en oeuvre par le coeur de réseau IP illustré à la figure 4 pour établir dans deux contextes différents un plan usager permettant le transfert de données d'un terminal, ces étapes reprenant les principales étapes d'un procédé de contrôle selon l'invention. 20 Description détaillée de l'invention Comme mentionné précédemment, l'invention propose d'implémenter une architecture SDN de réseau défini par logiciel au sein d'un coeur de réseau IP, tel que par exemple un coeur de réseau LTE/EPC, de sorte à améliorer la flexibilité et la fiabilité en termes de connectivité IP de ce coeur de réseau. Cette nouvelle architecture permet de répondre plus efficacement aux besoins des 25 utilisateurs et des opérateurs, d'intégrer plus facilement de nouveaux services et d'ouvrir de façon sécurisée le réseau à des tiers tels que des opérateurs mobiles virtuels. Plus précisément, l'invention définit un nouveau plan de contrôle (signalisation) et un nouveau plan usager (de données) dans le coeur de réseau IP selon lesquels : - une pluralité de passerelles d'interconnexion du coeur de réseau IP avec des réseaux de 30 paquets de données externes et une pluralité de commutateurs (opérant au niveau de la couche 2 du modèle OSI (Open Systems Interconnection)) connectés à ces passerelles ainsi qu'à des stations de base d'un (ou de plusieurs) réseau d'accès, sont commandées par un dispositif de contrôle centralisé ; et une pluralité de fonctions du plan de contrôle sont instanciées sur des machines virtuelles d'un 35 système informatique en nuage et communiquent avec le dispositif de contrôle par l'intermédiaire d'un serveur de connexion au système informatique en nuage. Dans le mode de réalisation décrit ici, le dispositif de contrôle est un dispositif de contrôle logiciel, programmable, qui commande les passerelles d'interconnexion, les commutateurs 3025387 12 et les stations de base du réseau d'accès à l'aide de règles de traitement, via le protocole OpenFlowTM. Le protocole OpenFlowTM est décrit notamment dans le document « Openflow switch specification, version 1.3.1 », Septembre 2012. Les fonctions du plan de contrôle, telles que les fonctions MME de gestion de la 5 mobilité des terminaux, les fonctions de contrôle des passerelles d'interconnexion et des commutateurs, sont quant à elles déplacées sur des machines virtuelles dans un système informatique en nuage, dont l'accès est encadré par un serveur de connexion XMPP. Ainsi, dans le mode de réalisation décrit ici, le dispositif de contrôle communique avec les fonctions du plan de contrôle selon le protocole XMPP connu en soi. 10 Grâce à cette architecture et au découplage des plans usager et de contrôle, il est très facile de provisionner des équipements dans le plan usager et de connecter les fonctions de contrôle correspondantes dans le système informatique en nuage. On obtient ainsi plus de flexibilité que dans l'architecture LTE/EPC proposée actuellement dans le standard 3GPP. 15 Pour faciliter la compréhension de l'invention, nous allons dans un premier temps rappeler brièvement, en référence aux figures 2 et 3, les principes généraux d'une architecture SDN. Une telle architecture est décrite en détail dans le document édité par l'ONF intitulé « Software-Defined Networking: The New Norm for Networks », 13 avril 2012. Dans l'exemple retenu pour illustrer ces principes, l'architecture SDN repose sur l'utilisation du protocole 20 OpenFlowTM Comme mentionné précédemment, le concept SDN permet de spécifier le comportement d'équipements réseau à l'aide de programmes de contrôle haut niveau, ce qui permet d'automatiser aisément certaines tâches comme la configuration des équipements du réseau ou la gestion des politiques (ou services) appliquées au niveau du réseau. 25 A cet effet, l'architecture SDN centralise l'intelligence du réseau (i.e. les fonctions de contrôle du réseau et de ses équipements) dans un dispositif de contrôle (ou contrôleur) logiciel. Le comportement des équipements du réseau en présence de données relatives à un terminal ou plus précisément à une session de communication, est alors défini par le dispositif de contrôle au moyen de règles dites de traitement ou de transfert, transmises à ces équipements. Ces règles 30 sont stockées par les équipements du réseau dans des tables dites de flux (ou « flow tables » en anglais) et sont destinées à être appliquées par ceux-ci sur réception de paquets ou de flux de données. Elles spécifient notamment les équipements du réseau vers lesquels transférer les données (i.e. le trafic) en liaisons montante et descendante. 35 La figure 2 résume ce mode de fonctionnement en modélisant schématiquement une architecture SDN selon trois couches : 3025387 13 une couche inférieure DP, modélisant le plan de données et comprenant des équipements D de réseau commandés (contrôlés) par le dispositif de contrôle (ces équipements D peuvent être indifféremment physiques ou virtuels) ; une couche intermédiaire NW CTRL, modélisant à proprement parler le dispositif de contrôle 5 logiciel référencé par « OpenCTR » ; et une couche supérieure APPL, modélisant diverses applications ou fonctions de contrôle APP utilisées par le dispositif de contrôle OpenCTR pour commander les équipements de réseau D du plan de données DP et élaborer les règles de traitement. Les différentes couches précitées communiquent entre elles via des interfaces de 10 programmation ou API appelées « NorthBound API » et « SouthBound API » (notées respectivement « NB API » et « SB API » sur la figure 2). Les interfaces de programmation SB API entre le dispositif de contrôle OpenCTR et le plan de données implémentent ici le protocole de communication OpenFlowTM Conformément à l'invention, le plan usager s'appuie sur des passerelles 15 d'interconnexion du coeur de réseau IP avec des réseaux externes, des commutateurs connectés à ces passerelles, et des stations de base d'un ou plusieurs réseaux d'accès connectées aux commutateurs. Une interface de programmation SB API implémentant le protocole de communication OpenFlowTM est en effet prévue conformément à l'invention entre le dispositif de contrôle OpenCTR et les stations de base. Par souci de simplification dans la suite de la 20 description, on inclut dans les équipements de réseau D contrôlés par le dispositif de contrôle OpenCTR à l'aide du protocole OpenFlowTM, les passerelles d'interconnexion, les commutateurs et les stations de base. Les interfaces de programmation NB API peuvent implémenter n'importe quel protocole de communication ouvert. Dans le mode de réalisation décrit ici, elles sont basées sur le 25 protocole de communication XMPP comme précisé plus en détail ultérieurement. Comme rappelé précédemment et illustré à la figure 3, le protocole OpenFlowTM permet au dispositif de contrôle logiciel OpenCTR de commander aisément chaque équipement D de réseau (passerelles d'interconnexion, commutateurs et stations de base) au moyen d'un 30 ensemble de règles de traitement de données, incluant notamment des règles de transfert (ou de routage) de données destinées à être appliquées par l'équipement de réseau sur réception de données relatives à une session de communication (autrement dit, échangées lors d'une session de communication). Ces règles de traitement sont déterminées par le dispositif de contrôle OpenCTR en 35 fonction par exemple de la politique de l'opérateur envisagée pour la gestion du réseau. Elles spécifient le traitement devant être appliqué par chaque équipement sur réception d'un paquet d'un flux de données associé à une session de communication d'un terminal, et des paquets suivants associés au même flux. 3025387 14 Ces règles de traitement sont stockées au niveau de chaque équipement de réseau D sous la forme de tables de flux FTAB, dont les entrées peuvent être aisément modifiées par le dispositif de contrôle OpenCTR à l'aide du protocole OpenFlowTM (ex. ajout, mise à jour, suppression d'entrées dans la table). 5 A titre illustratif, une entrée E d'une telle table de flux FTAB est représentée sur la figure 3. Elle se présente sous la forme de plusieurs champs ou paramètres destinés à être examinés par l'équipement de réseau D sur réception d'un paquet de données, en vue d'identifier quel traitement appliquer sur ce paquet (par exemple vers quel équipement du coeur de réseau ou du réseau d'accès transférer ce paquet). 10 Ces champs incluent par exemple des champs d'adresses sources et/ou destinataires, tels que des adresses MAC (Medium Access Control), MACsrc et MACdest, et/ou des adresses IP, IPsrc et IPdest. Un ou plusieurs champs peu(ven)t être spécifié(s) pour chaque entrée. II(s) spécifie(nt) les adresses qui doivent être présentes dans l'entête des paquets auxquels se rapporte cette entrée E de la table de flux. Chaque entrée E de la table spécifie également un champ 15 ACTION définissant le traitement à appliquer sur les paquets correspondant à cette entrée E. D'autres champs peuvent bien entendu être également définis pour chaque entrée de la table FTAB en sus des champs précités, comme illustré sur la figure 4, tels que par exemple un champ CNT (pour « Counter »), un champ définissant un port d'entrée et/ou de sortie, etc. L'équipement de réseau D utilise les tables de flux FTAB ainsi définies de la façon 20 suivante. Sur réception d'un paquet de données, il cherche dans les tables FTAB stockées si le(s) champ(s) MACsrc, MACdest, IPsrc, IPdest spécifié(s) d'une entrée coïncide avec le(s) champs de l'entête de ce paquet. Le cas échéant, les instructions associées à cette entrée indiquées dans le champ 25 ACTION sont exécutées par l'équipement de réseau D sur le paquet de données (ex. transférer le paquet vers un équipement déterminé du réseau, ou modifier ou supprimer le paquet). Si en revanche, aucune entrée ne coïncide avec l'entête du paquet reçu, celui-ci est transféré vers le dispositif de contrôle OpenCTR qui crée une nouvelle entrée de table de flux et un traitement associé à cette entrée (autrement dit une nouvelle règle de traitement), et la transmet à 30 l'équipement de réseau D pour qu'il la stocke dans une table de flux. Les plans de contrôle et de données au sein de l'architecture SDN sont ainsi bien découplés. Nous allons maintenant décrire, en référence aux figures 4 à 7, comment l'invention 35 propose avantageusement d'appliquer ce principe à une architecture de coeur de réseau IP, et plus particulièrement à une architecture de coeur de réseau LTE/EPC. Par souci de simplification de l'exposé, lorsqu'aucune précision n'est apportée dans la description, les fonctions et les modes de fonctionnement des équipements de réseau considérés 3025387 15 (en particulier des stations de bases de type eNodeB, des terminaux mobiles de type UE, des serveurs HSS (Home Subscriber Server) et PCRF (Policy and Charging Rules Function), etc.) sont similaires ou identiques à ceux décrits dans le document 3GPP TS 23.401 édité par le 3GPP et ne sont pas détaillés davantage ici. L'invention ne se limite toutefois pas aux seuls réseaux de 5 télécommunications LTE et peut être également appliquée à d'autres architectures de coeurs de réseau basés sur le protocole IP (« all IP networks »), tels que par exemple une architecture de coeur de réseau IP propriétaire. La figure 4 représente un coeur de réseau 10 conforme à l'invention, dans un mode 10 particulier de réalisation dans lequel ce coeur de réseau permet à un terminal UE 11 d'accéder à des services offerts par un réseau externe de paquets de données PDN 12. Ce réseau PDN 12 est par exemple le réseau public Internet. Par souci de simplification, on considère un unique réseau externe. On suppose ici, que pour accéder à ces services, le terminal UE 11 est connecté à une 15 station de base 13A (typiquement une station eNodeB) d'un réseau d'accès tel que par exemple un réseau de télécommunications mobiles UMTS. Aucune limitation n'est toutefois attachée à la nature du réseau d'accès utilisé par le terminal UE 11 dès lors que celui-ci est compatible avec le coeur de réseau 10. Conformément à l'invention et aux principes du SDN rappelés précédemment, les plans 20 de contrôle et de données sont découplés dans le coeur de réseau 10. Ce découplage est assuré par un dispositif de contrôle 14 conforme à l'invention, reprenant les principes de fonctionnement du dispositif de contrôle OpenCTR précédemment décrits en référence aux figures 2 et 3. Ce dispositif de contrôle 14 commande différents équipements du coeur de réseau 10 participant au plan usager, à savoir : 25 une (ou plusieurs) passerelle(s) d'interconnexion 15 vers le réseau externe de paquets de données PDN 12 ; et une pluralité de commutateurs 16A, 16B et 16C connectés à la passerelle d'interconnexion 15 et opérant au niveau de la couche 2 du modèle OSI, chaque commutateur 16A, 16B et 16C (plus généralement désigné par la référence 16) étant connecté à une ou plusieurs stations de 30 base du réseau d'accès désignée(s) généralement par la référence 13. Ainsi, dans l'exemple illustré à la figure 4, le commutateur 16A est relié aux stations de base 13A et 13B et le commutateur 16B est relié à la station de base 13C. Le dispositif de contrôle 14 commande également, conformément à l'invention, les stations de base 13 (13A, 13B et 13C sur la figure 4) connectées aux commutateurs 16 du coeur de 35 réseau IP 10. Bien entendu, aucune limitation n'est attachée au nombre de commutateurs reliés à la passerelle d'interconnexion au réseau externe ni au nombre de stations de base connectées à ces commutateurs. 3025387 16 Le dispositif de contrôle 14 commande ces différents équipements de réseau par l'intermédiaire d'un module de commande 14A. Plus précisément, il établit par le biais de ce module de commande 14A un plan usager pour les flux de données relatifs à un terminal géré par le coeur de réseau 10 en définissant des règles de traitement devant être appliquées par la 5 passerelle d'interconnexion 15, les commutateurs 16 et les stations de base 13 aux paquets de données qu'ils reçoivent en liaisons montante et descendante pour ce terminal. Ces règles de traitement sont fournies par le dispositif de contrôle 14 aux équipements de réseau qu'il contrôle en s'appuyant sur le protocole OpenFlowTM Les règles de traitement fournies par le dispositif de contrôle 14 sont stockées au 10 niveau de chaque équipement de réseau (i.e. commutateurs 16, passerelle d'interconnexion 15 et stations de base 13) dans des tables de flux (non représentées sur la figure 4), dont les entrées peuvent être aisément modifiées (ex. ajout, mise à jour, suppression d'entrées dans la table) par le module de commande 14A à l'aide du protocole OpenFlowTM. Ces tables sont similaires ou identiques aux tables FTAB décrites précédemment en référence à la figure 3. 15 Les règles de traitement utilisées par le dispositif de contrôle 14 pour commander les équipements du réseau 13, 15 et 16 sont ici des règles de transfert des paquets de données IP reçus par ces équipements identifiant en fonction de différents critères vérifiés par l'entête de ces paquets (ex. adresse MAC ou IP source ou destinataire, comme illustré à la figure 3), l'équipement du réseau vers lequel transférer ces paquets. 20 Ainsi, selon un premier exemple, pour la passerelle d'interconnexion 15, une telle règle de traitement identifie l'un des commutateurs 16A, 16B et 16C vers lequel transférer un paquet de données (ou plus généralement un flux de données) en fonction des champs présents dans son entête lorsque celui-ci est reçu en liaison descendante. Selon un deuxième exemple, pour le commutateur 16A, une telle règle de traitement 25 identifie la passerelle d'interconnexion 15 vers laquelle transférer un paquet en liaison montante, et, la station de base 13A ou 13B du réseau d'accès vers laquelle transférer un paquet de données en liaison descendante. Enfin, selon un troisième exemple, pour une station de base 13A ou 13B du réseau d'accès, une telle règle de traitement identifie le commutateur 16A vers lequel transférer en liaison 30 montante un paquet reçu d'un terminal servi par cette station de base. La passerelle d'interconnexion 15, les commutateurs 16 et les stations de base 13 sont par ailleurs aptes à solliciter le dispositif de contrôle 14 via un message du protocole OpenFlowTM, lorsqu'ils reçoivent un paquet de données ne correspondant à aucune entrée de leurs tables de flux respectives. Sur réception de ce message, le dispositif de contrôle 14 par l'intermédiaire de son 35 module de commande 14A, crée une règle de traitement appropriée et met à jour les tables de flux des équipements de réseau concernés. Conformément à l'invention, les fonctions de contrôle des commutateurs 16 et de la passerelle d'interconnexion 15 sont séparées des fonctions de transfert de données mises en 3025387 17 oeuvre par ces équipements. Conformément au principe SDN, ces fonctions de contrôle s'exécutent au-dessus du dispositif de contrôle logiciel 14. Plus précisément, conformément à l'invention, ces fonctions définissant le plan de contrôle du coeur de réseau IP 10 sont des fonctions virtuelles instanciées sur des machines virtuelles d'un système informatique en nuage 17. Ces fonctions 5 virtuelles communiquent avec le dispositif de contrôle 14, et plus spécifiquement avec un module de communication 14B du dispositif de contrôle 14, par l'intermédiaire d'un serveur de connexion XMPP 18. Afin de mieux illustrer cette séparation des plans usager et de contrôle mise en oeuvre par l'invention, la fonction rassemblant les fonctions de contrôle de la passerelle d'interconnexion 10 et des commutateurs est référencée par « S/PGW-C 19 » sur la figure 4 et dans la description. Pour leur part, les équipements appliquant dans le plan usager les fonctions de transfert de données des commutateurs et des passerelles d'interconnexion sont référencés respectivement par « SW » et par « PGW-D ». Il convient de noter que dans le mode de réalisation décrit ici, le plan de contrôle de la passerelle d'interconnexion 15 et des commutateurs 16 connectés à cette 15 passerelle est assuré par une même fonction virtuelle S/PGW-C instanciée sur une machine virtuelle. En revanche, on peut envisager comme représenté à la figure 4 plusieurs fonctions virtuelles distinctes susceptibles de contrôler la passerelle d'interconnexion 15 et les commutateurs 16 qui lui sont connectés. En variante, des fonctions virtuelles distinctes et/ou instanciées sur des machines 20 virtuelles différentes peuvent être envisagées pour contrôler d'une part la passerelle d'interconnexion 15 (fonction virtuelle PGW-C) et d'autres part les commutateurs 16 qui lui sont connectés (fonction virtuelle SGW-C). Le dispositif de contrôle 14, via ses interactions avec les fonctions 19 de contrôle virtuelles S/PGW-C, centralise ainsi l'intelligence réseau des commutateurs 16 et de la passerelle 25 d'interconnexion 15, et détermine les règles de traitement devant être appliquées aux paquets de données reçus par ceux-ci et par les stations de base 13. A cet effet, il s'appuie sur un ensemble de processus de contrôle mis en oeuvre notamment par les fonctions de contrôle virtuelles instanciées dans le système informatique en nuage 17, ainsi que par d'autres modules du dispositif de contrôle 14, comme par exemple, un module de gestion de la topologie du réseau, un module 30 de gestion de la qualité de service, un module d'équilibre de la charge, un module de gestion du routage dans le réseau, etc., dont les fonctions sont connues en soi. Ces modules sont regroupés sur la figure sous la référence 14C et désignés par « modules de contrôle » dans la suite de la description, par souci de simplification. Ils sont garants en particulier de certains attributs spécifiques aux utilisateurs ou aux services gérés par le coeur de réseau IP, notamment en termes 35 de sécurité, mobilité, application de politiques fixées par l'opérateur, etc. D'autres fonctions virtuelles peuvent être instanciées dans le système informatique en nuage 17 et assurent des fonctions classiques du plan de contrôle du coeur de réseau IP. Il s'agit notamment ici d'une pluralité de fonctions virtuelles MME 20 de gestion de la mobilité des 3025387 18 terminaux dans le coeur de réseau IP, d'une fonction virtuelle 21 de serveur HSS, et d'une fonction virtuelle 22 de serveur PCRF. Il convient de noter que les fonctions virtuelles MME 20 se distinguent des fonctions des entités MME telles que définies dans le standard LTE en ce qu'elles ne sont pas responsables ici de la sélection des commutateurs 16 et/ou de la passerelle 5 d'interconnexion 15 définissant le plan usager associé à un terminal. Cette sélection est assurée, comme détaillée davantage ultérieurement, par le dispositif de contrôle 14 lui-même au moyen de ses modules de contrôle 14C notamment. Dans le mode de réalisation décrit ici, certaines des fonctions virtuelles instanciées dans le système informatique en nuage 17 communiquent entre elles par l'intermédiaire des 10 interfaces décrites dans le standard LTE. Ainsi, à titre d'exemple, les fonctions virtuelles MME 20 et la fonction virtuelle 21 de serveur HSS communiquent selon une interface S6a telle que définie dans le document 3GPP TS 29.272 intitulé « Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol », Release 12, v12.5.0, juin 15 2014. De manière similaire, la fonction virtuelle 22 du serveur PCRF communique avec les fonctions virtuelles S/PGW-C 19 selon une interface Gx telle que définie dans le document 3GPP TS 29.210 intitulé « Technical Specification Group Core Network and Terminals; Charging rule provisionning over Gx interface, version 6.7.0. ». D'autres fonctions virtuelles instanciées dans le système informatique en nuage 17 20 communiquent entre elles via le serveur de connexion XMPP 18 en utilisant le protocole de communication XMPP. Plus précisément ici, les fonctions virtuelles de contrôle S/PGW-C 19 et les fonctions virtuelles MME 20 de gestion de la mobilité des terminaux sont des clients du serveur de connexion XMPP 18 au même titre que le dispositif de contrôle 14. Autrement dit, cela signifie que les 25 fonctions virtuelles 19 et 20 et le dispositif de contrôle 14 communiquent entre eux par l'intermédiaire d'un canal de communication direct et dédié, établi par le serveur XMPP 18, et en utilisant sur ce canal le protocole XMPP. Le serveur XMPP 18 communique avec les fonctions virtuelles 19 et 20 et le dispositif de contrôle 14 par l'intermédiaire d'un module de communication 18B apte à mettre en oeuvre le protocole XMPP, et selon un mode de communication client-serveur 30 bien connu en soi (i.e. sous forme d'échanges de requêtes des clients et de réponses du serveur à ces requêtes). Le serveur XMPP 18 est un serveur de connexion au système informatique en nuage 17 conforme à l'invention. Il est configuré pour authentifier ses clients (autrement dit ici, les fonctions virtuelles de contrôle 19 et 20 et le dispositif de contrôle 14) et refuser l'accès au 35 système informatique en nuage 17 et à ses services aux utilisateurs (clients) non autorisés. Il maintient en outre, au moyen d'un module de gestion de base de données 18A, une base de données clients 23 contenant des informations relatives à ces derniers. Par base de données, on 3025387 19 entend ici tout type de structure dans laquelle sont stockées des données (ex. une table, vecteur, etc.). Ainsi, notamment, la base de données clients 23 contient ici pour chaque client du serveur XMPP 18 : 5 un identifiant unique de ce client auprès du serveur XMPP 18 : cet identifiant est plus communément appelé un « Jabber ID » ou encore une adresse Jabber ; et au moins un état de ce client. Dans le mode de réalisation décrit ici, le serveur XMPP 18 stocke dans la base de données clients 23 un état de disponibilité et un état de charge courants du client considéré. Ces états sont obtenus grâce au protocole XMPP mis en oeuvre par le serveur 10 18 et conformément au fonctionnement classique d'un serveur XMPP. Conformément à l'invention, le serveur XMPP 18 est apte à transmettre, par l'intermédiaire de son module de communication 18B, des informations (données) stockées dans la base de données clients 23 au dispositif de contrôle 14 afin de lui permettre d'établir et de contrôler un plan usager pour un terminal géré par le coeur de réseau IP, et de traiter les 15 messages relatifs à ce terminal échangés dans ce plan usager. Ces informations permettent au dispositif de contrôle 14 de maintenir à jour, par l'intermédiaire d'un module de gestion de base de données 14D, une base de données 24 dite de contrôle comprenant, pour chaque fonction virtuelle MME 20 et S/PGW-C 19, un identifiant de cette fonction auprès du serveur XMPP 18 (ici, le Jabber ID alloué de façon unique à cette fonction 20 par le serveur XMPP 19) et au moins un état de cette fonction. Dans l'exemple envisagé ici, la base de données 24 contient un état de disponibilité et un état de charge courant de chaque fonction virtuelle 19 et 20. En outre, dans le mode de réalisation décrit ici, la base de données 24 contient également pour chaque fonction virtuelle identifiée dans la base, les identifiants des terminaux 25 gérés par le coeur de réseau IP 10 auxquels est allouée cette fonction. Le dispositif de contrôle 14, par le biais de son module de gestion 14D de base de données, maintient également à jour une base de données dite utilisateurs 25 identifiant pour au moins un terminal d'un utilisateur géré par le coeur de réseau IP 10, les fonctions virtuelles parmi les fonctions 19 et 20 instanciées dans le système informatique en nuage 17 allouées à ce 30 terminal. Dans le mode de réalisation décrit ici, la base de données utilisateurs 25 comprend également pour au moins un terminal identifié dans la base, un ou plusieurs paramètres de communication destinés à être utilisés pour un transfert de données dans un plan usager établi pour ce terminal entre une station de base 13 servant ce terminal et la passerelle d'interconnexion 35 15. Ces paramètres de communication comprennent notamment ici une adresse du commutateur 16 connecté à la station de base 13 servant le terminal, une adresse de la passerelle d'interconnexion 15, et des identifiants de points d'extrémité d'un tunnel de communication établi entre la station de base 13 et la passerelle 16 pour le transfert des données, ces identifiants ayant 3025387 20 été attribués au terminal par la station de base 13 et par la fonction de contrôle virtuelle 19 de la passerelle d'interconnexion 16 respectivement. Il convient de noter que conformément à l'invention, le plan usager établi par le dispositif de contrôle 14 s'appuie sur des commutateurs 16 plutôt que sur des passerelles de 5 transfert de données de type SGW telle que définie dans l'architecture LTE/EPC du standard 3GPP. L'utilisation de commutateurs opérant au niveau de la couche 2 du modèle OSI (Open Systems Interconnection)) permet d'échanger directement dans le plan usager des paquets de données IP entre d'une part les stations de base 13 et les commutateurs 16, et d'autre part, entre les commutateurs 16 et la passerelle d'interconnexion 15. De ce fait, grâce à l'invention, on peut se 10 contenter d'établir un unique tunnel de communication GTP entre une station de base 13 et une passerelle d'interconnexion 16, au lieu de deux tunnels GTP distincts entre la station de base 13 et le commutateur 16 auquel elle est reliée, puis entre le commutateur 16 et la passerelle d'interconnexion 15 auquel le commutateur 16 est relié. Ce tunnel de communication unique est défini (i.e. identifié) par différents paramètres 15 de communication tels que notamment des identifiants de points d'extrémité du tunnel ou TEID (Tunnel Endpoint IDentifier), ainsi qu'une adresse IP (Internet Protocol) de la passerelle 15, une adresse IP du commutateur 16 et des numéros de port UDP (User Datagram Protocol) de ces équipements. En permettant l'établissement d'un unique tunnel de communication entre la station de base 13 et la passerelle d'interconnexion 15, l'invention résulte en un gain en termes de 20 signalisation échangée sur le coeur de réseau. Dans le mode de réalisation décrit ici, le dispositif de contrôle 14 et le serveur XMPP 18 sont des entités logicielles, autrement dit des applications ou des programmes d'ordinateur, qui s'exécutent sur des dispositifs informatiques ou ordinateurs 26 et 27 respectivement. La figure 5A illustre schématiquement l'architecture matérielle du dispositif 25 informatique 26 implémentant le dispositif de contrôle 14. Ce dispositif informatique 26 comprend un processeur 26A, une mémoire morte 26B, une mémoire vive 26C, une mémoire non volatile 26D et des moyens de communication 26E. Ces moyens de communication 26E sont aptes en particulier à communiquer : - avec les stations de base 13, avec les commutateurs 16 et avec les passerelles 30 d'interconnexion 15 selon le protocole OpenFlowTm ; et - avec le serveur XMPP 18, et par le biais de ce serveur, avec les fonctions virtuelles 19 et 20 du plan de contrôle selon le protocole XMPP. La mémoire morte 26B du dispositif informatique 26 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 26A et sur lequel est enregistré 35 un programme d'ordinateur conforme à l'invention comportant des instructions pour l'exécution des étapes d'un procédé de contrôle selon l'invention dont les étapes sont illustrées ultérieurement en référence aux figures 6 et 7. Ce programme d'ordinateur définit de façon équivalente les modules fonctionnels 14A, 14B, 14C et 14D du dispositif de contrôle 14 décrits précédemment. 3025387 21 La figure 5B illustre schématiquement l'architecture matérielle d'un dispositif informatique 27 implémentant le serveur XMPP 18. Ce dispositif informatique 27 comprend un processeur 27A, une mémoire morte 27B, une mémoire vive 27C, une mémoire non volatile 27D et des moyens de communication 27E. Ces moyens de communication 27E sont aptes en particulier à 5 communiquer avec le dispositif de contrôle 14 et avec les fonctions virtuelles 19 et 20 en utilisant le protocole XMPP. La mémoire morte 27B du dispositif informatique 27 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 27A et sur lequel est enregistré un programme d'ordinateur définissant les modules fonctionnels 18A et 18B du serveur de 10 connexion XMPP 18 décrits précédemment. Nous allons maintenant illustrer plus en détail la gestion opérée par le coeur de réseau 10 grâce à cette nouvelle architecture proposée par l'invention. Cette gestion est opérée dans le mode de réalisation décrit en s'appuyant et en adaptant la procédure d'identification d'un terminal 15 proposée par le standard LTE ainsi que la procédure d'identification d'une entité cliente par un serveur XMPP. Plus spécifiquement, on suppose ici que chaque terminal UE 11 géré par le coeur de réseau IP 10 dispose d'un identifiant temporaire unique, tel que par exemple une identité de type GUTI (pour Globally Unique Temporary Identity) telle que définie dans le standard LTE. Cette 20 identité est de façon connue utilisée pour éviter d'exposer et d'échanger fréquemment sur le lien radio l'identité permanente du terminal UE 11, aussi désignée par IMSI (International Mobile Subscriber Identity). L'identité GUTI est constituée : - d'une identité GUMMEI (pour Globally Unique MME Identity) qui désigne de façon unique 25 l'entité MME qui a alloué l'identité GUTI au terminal UE 11 ; et - une identité M-TMSI (pour MME Temporary Mobile Subscriber Identity) qui identifie de manière unique le terminal UE 11 au sein de l'entité MME. L'identité GUMMEI comprend : un identifiant du réseau ou PLMN (pour Public Land Mobile Network) ; et 30 - un identifiant de MME ou MMEI (pour MME Identifier), qui est constitué d'un identifiant de groupe MME (ou MMEGI pour MME Group Id) et un code MME (ou MMEC pour MME Code). Le code MME constitue un identifiant unique d'une entité MME (fonction virtuelle 20 ici) au sein d'un groupe d'entités MME, et l'identifiant MMEGI désigne un groupe d'entités MME parmi différents groupes d'entités MME. 35 Conformément à l'invention, les entités MME considérées ici sont les fonctions virtuelles MME 20 décrites précédemment, instanciées dans le système informatique en nuage 17, et connectées au dispositif de contrôle SDN 14 par le biais du serveur XMPP 18. On suppose 3025387 22 qu'une pluralité de fonctions virtuelles MME sont ainsi instanciées dans le système informatique en nuage 17 et connectées au même dispositif de contrôle 14. Lorsque le terminal UE 11 souhaite communiquer avec le coeur de réseau IP 10, il envoie une requête à la station de base 13 qui le sert, cette requête contenant le cas échéant son 5 identité GUTI. Cette requête est transférée au dispositif de contrôle 14 pour traitement. Le dispositif de contrôle 14 extrait alors l'identité GUMMEI de l'identité GUTI contenue dans cette requête et identifie la fonction virtuelle MME 20 allouée au terminal UE 11. Il met à jour sa base de données 25 avec l'identifiant de la fonction virtuelle MME 20 allouée au terminal UE 11. Le dispositif de contrôle 14 recherche par ailleurs si une adresse IP a déjà été 10 attribuée au terminal UE 11, et le cas échéant identifie la fonction virtuelle S/PGW-C 19 qui lui a allouée en utilisant le préfixe IP. Il met à jour sa base de données 25 avec l'identifiant de la fonction virtuelle S/PGW-C 19 allouée au terminal UE 11. Si le terminal UE 11 n'est pas attaché au réseau et/ou s'il ne dispose pas d'identité GUTI préalablement attribuée (c'est le cas notamment lorsque le terminal se connecte pour la 15 première fois au coeur de réseau, la requête du terminal ne contenant alors pas de GUTI mais l'identité IMSI du terminal), le dispositif de contrôle 14 sélectionne et alloue une fonction virtuelle MME 20 pour le terminal 11 parmi l'ensemble des fonctions virtuelles MME 20 instanciées dans le système informatique en nuage 17. Cette allocation est réalisée sur la base d'un état courant de disponibilité et/ou de charge des fonctions virtuelles MME 20 transmis par le serveur XMPP 18 ou 20 par un serveur DNS (non représenté sur la figure). La fonction virtuelle MME 20-11 ainsi sélectionnée attribue au terminal UE 11 une identité GUTI contenant l'identité GUMMEI la désignant. De manière similaire, une fonction virtuelle S/PGW-C 19-11 est sélectionnée et allouée sur la base du même type d'informations pour le terminal UE 11. 25 Les bases de données 24 et 25 sont mises à jour par le module de gestion 14D du dispositif de contrôle 14 pour refléter l'allocation des fonctions virtuelles 19-11 et 20-11 au terminal UE 11 et l'attribution à ce terminal UE 11 d'un identifiant GUTI correspondant (i.e. la base de données de contrôle 24 identifie maintenant le terminal 11 (par l'intermédiaire de ses identités IMSI et GUTI) parmi les terminaux alloués aux fonctions virtuelles 19-11 et 20-11, et la base de 30 données utilisateurs 25 identifie maintenant les fonctions virtuelles 19-11 et 20-11 à l'aide de leurs adresses Jabber comme étant allouées au terminal 11). Comme mentionné précédemment, la gestion opérée par le coeur de réseau IP 10 s'appuie également et adapte les procédures existantes d'identification et d'authentification d'une 35 entité cliente par un serveur XMPP. Dans le système informatique en nuage 17, toute fonction virtuelle et plus généralement toute entité connectée au serveur XMPP 18 est un client de ce serveur identifié par 3025387 23 une adresse Jabber (Jabber ID) unique. Une telle adresse est connue en soi et est configurée par le serveur XMPP 18. Le serveur XMPP 18 met ensuite à jour sa base de données clients 23 avec cette adresse Jabber et la transmet au dispositif de contrôle 14 conformément à l'invention. Si de 5 nouvelles fonctions virtuelles sont instanciées et connectées au serveur XMPP 18 (ex. fonctions virtuelles S/PGW-C 19 et/ou MME 20), ce dernier met à jour sa base de données 23 et transmet les adresses Jabber de ces nouvelles fonctions au dispositif de contrôle 14 pour lui permettre de communiquer avec celles-ci directement. Il convient de noter que bien que cette communication soit considérée comme « directe » dans le sens où le dispositif de contrôle 14 utilise directement 10 les adresses Jabber des fonctions virtuelles connectées au serveur XMPP 18 pour communiquer avec celles-ci, cette communication est orchestrée par l'intermédiaire du serveur XMPP 18, c'est-à-dire qu'elle passe par le serveur XMPP 18 qui oriente la communication vers la fonction virtuelle identifiée de manière unique par l'adresse Jabber fournie par le dispositif de contrôle 14. Le serveur XMPP 18 ne donne un accès au coeur de réseau IP 10 qu'à des clients 15 autorisés et authentifiés. Quand un nouveau client, telle qu'une nouvelle fonction virtuelle S/PGW- C 19 ou MME 20 est instanciée dans le système informatique en nuage 17, ce nouveau client doit être authentifié et configuré par le serveur XMPP 18. Durant cette configuration, le client s'enregistre auprès du serveur XMPP 18 avec son adresse Jabber. Plus précisément, il envoie au serveur XMPP 18 un message XMPP IQ-get pour 20 obtenir les champs d'authentification nécessaires à son authentification. Sur réception de ce message, le serveur XMPP 18 envoie un message XMPP IQ-result au client contenant les champs d'authentification requis. Le client envoie au serveur XMPP 18 l'information correspondant aux champs d'authentification dans un message XMPP IQ-get ; cette information comprend par exemple un nom d'utilisateur et un mot de passe. Le mot de passe peut être transmis en l'état ou 25 sous la forme d'un condensé cryptographique obtenu au moyen de l'algorithme connu SHA1 (Secure Hash Algorithm). Sur réception du message du client (requête d'authentification), le serveur XMPP 18 crée une entrée dans sa base de données clients 23 et met à jour les informations relatives à ce client dans la base (adresse Jabber allouée par l'opérateur du système informatique en nuage, 30 adresse IP, état courant de disponibilité et de charge du client). Il envoie un message XMPP IQ- result notifiant le succès de l'authentification au client. Par ce message, le serveur XMPP 18 et le nouveau client sont configurés et le serveur alloue des ressources au client pour de futures communications. Il maintient ensuite à jour sa base de données clients 23, et en particulier l'état de ses clients. 35 Nous allons maintenant décrire plus en détail en référence aux figures 6 et 7 deux procédures mises en oeuvre par le coeur de réseau 10 en s'appuyant sur l'architecture. 3025387 24 La figure 6 représente les principales étapes d'une procédure d'établissement d'un plan usager entre une station de base 13A servant un terminal UE 11 d'un utilisateur et une passerelle d'interconnexion 15 du coeur de réseau IP 10 à un réseau externe PDN 12, pour permettre à ce terminal de communiquer (autrement dit d'émettre ou de recevoir des données). 5 L'établissement d'un plan usager consiste à enregistrer le terminal UE 11 auprès du coeur de réseau IP 10 et à établir un support de communication (ou « bearer ») entre la station de base 13 et la passerelle d'interconnexion 15 pour qu'il puisse émettre et recevoir des paquets de données IP, et disposer ainsi d'une connectivité IP avec le réseau de paquets externe PDN 12. Généralement, cette procédure est mise en oeuvre à l'allumage du terminal UE 11. 10 On suppose donc que le terminal UE 11 envoie à la station de base 13A dont il dépend (c'est-à-dire généralement la station de base qui sert la cellule dans laquelle il se trouve), une requête d'attachement au coeur de réseau 10 (étape E10). Cette requête comprend une requête de connectivité au réseau externe PDN 12 et les identités du terminal UE 11, notamment son identité permanente IMSI et le cas échéant, son identité temporaire GUTI. 15 La station de base 13A encapsule cette requête dans un message PACKET_IN conforme au protocole OpenFlowTM et l'envoie au dispositif de contrôle 14 (étape E20). Dans ce message, la station de base 13A inclut également un identifiant du terminal UE 11, noté eNB_OF_UE11_ID, utilisé pour identifier de manière unique le terminal UE 11 entre la station de base 13A et le dispositif de contrôle 14. Cet identifiant est par exemple similaire à l'identifiant S1- 20 AP UE utilisé dans le standard 3GPP. Sur réception du message PACKET_IN, le dispositif de contrôle 14 extrait la requête du terminal UE 11 les identifiants IMSI et le cas échéant GUTI de ce dernier et consulte sa base de données utilisateurs 25 à partir de ce ou ces identifiants. On suppose ici qu'aucune entrée correspondant au terminal UE 11 (IMSI ou GUTI) 25 n'existe dans la base de données 25. Le dispositif de contrôle 14 envoie alors, par l'intermédiaire de son module de communication 14B, une requête IQ-get conforme au protocole XMPP au serveur XMPP 18 (étape E30). Le serveur XMPP 18 consulte sa base de données clients 23 et répond à cette requête 30 en transmettant au dispositif de contrôle 14 les fonctions virtuelles MME 20 disponibles instanciées dans le système informatique en nuage 17 (i.e. un identifiant de ces fonctions tel que leur adresse Jabber), ainsi que leur état de charge courant (étape E40). Le dispositif de contrôle 14 crée alors une entrée dans sa base de données utilisateurs 25 pour le terminal UE 11 à laquelle il associe l'IMSI du terminal UE 11. 35 Il sélectionne par ailleurs pour le terminal UE 11, en utilisant ses modules de contrôle 14C, une fonction virtuelle MME référencée par 20-11 parmi les fonctions virtuelles MME 20 disponibles en fonction notamment de leurs charges courantes et éventuellement d'autres paramètres tels que par exemple la localisation géographique du terminal. 3025387 25 Le dispositif de contrôle 14 alloue la fonction virtuelle MME 20-11 ainsi sélectionnée au terminal UE 11 et met à jour, via son module de gestion de base de données 14D, la base de données 25 avec l'adresse Jabber de la fonction virtuelle MME 20-11 (étape E50). Il met également à jour la base de données 24 en associant à la fonction virtuelle MME 20-11 l'identité IMSI du 5 terminal UE 11. Puis le dispositif de contrôle 14 émet directement, par l'intermédiaire de son module de communication 14B, une requête XMPP IQ-get vers la fonction virtuelle MME 20-11 (étape E60). Cette requête utilise l'adresse Jabber de la fonction virtuelle MME 20-11 et transite par le serveur XMPP 18 de façon connue en soi comme mentionné précédemment. Cette requête contient tous 10 les paramètres d'attachement classiques d'un terminal à un coeur de réseau, comme notamment les identités IMSI et GUTI du terminal, etc., ainsi que l'adresse Jabber du dispositif de contrôle 14. Sur réception de cette requête, la fonction virtuelle MME 20-11 allouée au terminal UE 11 vérifie si le terminal UE 11 est identifié dans sa base de données (étape E70). 15 On suppose ici que le terminal UE 11 n'est pas identifié dans la base de données de la fonction virtuelle MME 20-11. La fonction virtuelle MME 20-11 envoie alors un message d'authentification à la fonction virtuelle de serveur HSS 21 pour obtenir à partir de l'identité IMSI du terminal UE 11, les identités et paramètres d'authentification alloués au terminal UE 11 par le coeur de réseau IP 10 20 (ex. GUTI, adresse IP, station de base à laquelle le terminal est attaché, clés de protection de l'intégrité et de chiffrement pour la couche réseau NAS (couche réseau Non-Access Stratum de communication entre le terminal UE et l'entité MME dans le modèle LTE), etc.) (étape E80). Pour rappel, la fonction virtuelle MME 20-11 et la fonction virtuelle HSS 21 communiquent ici entre elles selon l'interface S6a définie dans le standard LTE. 25 La fonction virtuelle HSS 21 dérive les identités et les paramètres d'authentification du terminal UE 11, et les transmet à la fonction virtuelle MME 20-11 dans un message de réponse (étape E90). De façon connue, la fonction virtuelle MME 20-1 extrait du message de réponse les identités et les paramètres d'authentification du terminal UE 11 et les stocke dans sa base de 30 données (étape E100). Les clés NAS sont alors envoyées dans un message de réponse XMPP IQ-result au dispositif de contrôle 14 (étape E110). Ce message inclut également une requête d'authentification du terminal UE 11. Le dispositif de contrôle 14 transmet par l'intermédiaire de son module de 35 communication 14A la requête d'authentification à la station de base 13A (étape E120). Cette requête est encapsulée dans un message OpenFlowTM PACKETOUT et contient un identifiant CONT_OF_UE11_ID identifiant de manière unique le terminal UE 11 sur l'interface entre la station de base 13A et le dispositif de contrôle 14, ainsi que l'identifiant eNB_OF_UE11_ID. 3025387 26 La station de base 13A identifie le terminal UE 11 à partir de l'identifiant eNB_OF_UE11_ID et met à jour sa base de données utilisateurs avec l'identifiant CONT_OF_UE11_ID (étape E130). On note que les identifiants eNB_OF_UE11_ID et CONT_OF_UE11_ID permettent 5 avantageusement de pouvoir utiliser une même interface entre la station de base 13A et le dispositif de contrôle 14 pour la pluralité de terminaux UE servis par la station de base, le dispositif de contrôle 14 étant lui-même connecté à une pluralité de stations de base. Ces identifiants permettent au dispositif de contrôle 14 de différencier les messages provenant et destinés à une station de base spécifique, pour et/ou en provenance d'un terminal UE donné. De même, ils 10 permettent à une station de base de différencier facilement les terminaux. Puis, la station de base 13A extrait la requête d'authentification en provenance de la fonction MME 20-11 contenue dans le message PACKET_OUT et la relaie vers le terminal UE 11 (étape E140). Le terminal UE 11 transmet sa réponse à la requête d'authentification à la station de 15 base 13A (étape E150). Cette réponse est relayée par la station de base 13A au dispositif de contrôle 14, encapsulée dans un message OpenFlowTM PACKET_IN (étape E160). Le dispositif de contrôle 14 relaie à son tour la réponse du terminal UE 11 vers la fonction virtuelle MME 20-11 dans un message XMPP IQ-set par l'intermédiaire de son module de 20 communication 14B (étape E170). Sur réception du message IQ-set, la fonction virtuelle MME 20-11 compare les informations fournies par le terminal UE 11 (ex. clés NAS) avec les paramètres d'authentification transmis par la fonction virtuelle HSS 21 au cours de l'étape E90 (étape E180). Si les paramètres correspondent, la fonction virtuelle MME 20-11 authentifie le terminal 25 UE 11. Sinon elle rejette la requête du terminal. On suppose ici que les paramètres coïncident, autrement dit le terminal UE 11 est authentifié avec succès. La fonction virtuelle MME 20-11 envoie alors un message XMPP IQ-result au dispositif de contrôle 14 pour établir un plan usager pour ce terminal (étape E190). Le dispositif de contrôle 14 envoie alors, par l'intermédiaire du serveur XMPP 18, un 30 message XMPP IQ-get à la fonction virtuelle S/PGW-C 19 allouée au terminal UE 11 selon sa base de données utilisateurs 25 comme mentionné précédemment, en vue d'établir un tunnel de communication GTP pour les sessions de communication du terminal UE (étape E200). La fonction virtuelle S/PGW-C 19 allouée au terminal UE 11 est par la suite désignée par la référence 19-11. La fonction virtuelle S/PWG-C 19-11 sélectionne un commutateur 16A et une 35 passerelle d'interconnexion 15 pour le plan usager sur la base d'informations de charge de ces équipements de réseau (étape E210). Ces informations de charge sont par exemple obtenues en utilisant l'interface Gx entre la fonctionne virtuelle S/PWG-C 19-11 et la fonction virtuelle PCRF 22. Elle crée par ailleurs des paramètres de communication identifiant un tunnel de communication 3025387 27 entre la station de base 13A et la passerelle 15 pour les communications du terminal UE 11 en liaison montante. Ces paramètres de communication comprennent notamment un identifiant de point d'extrémité du tunnel ou TEID. En outre, la fonction virtuelle S/PWG-C 19-11 extrait l'adresse IP du terminal d'un 5 serveur DHCP (non représenté) et la qualité de service du support de communication (bearer) en interrogeant via l'interface Gx, la fonction virtuelle PCRF 22. Le serveur DHCP peut être implémenté à l'aide d'une fonction virtuelle instanciée dans le système informatique en nuage 7 ou être intégrée dans une fonction virtuelle S/PWG-C déjà instanciée. La fonction virtuelle S/PWG-C 19-11 transmet un message de réponse XMPP IQ-result 10 au dispositif de contrôle 14 comprenant l'identifiant TEID alloué par la fonction virtuelle S/PGW-C 19-11, les adresses IP du commutateur 16A et de la passerelle d'interconnexion 15, l'adresse IP du terminal UE 11 et la qualité de service du support de communication (étape E220). Le dispositif de contrôle 14 met à jour, via son module de gestion de bases de données 14D, la base de données utilisateurs 25 avec les adresses IP du commutateur 16A et de la 15 passerelle d'interconnexion 15, l'adresse IP du terminal UE 11 et l'identifiant TEID du tunnel de communication alloué par la fonction virtuelle S/PGW-C 19-11 (étape E230). Puis il envoie à la station de base 13A un message OpenFlowTM PACKET_OUT acceptant la requête d'attachement du terminal UE 11 et d'établissement de support de communication (étape E240). Ce message contient les adresses IP du commutateur 16A et de la 20 passerelle d'interconnexion 15 et l'identifiant TEID, stockés dans la base de données utilisateurs 25. Ce message contient une règle de traitement au sens de l'invention destinée à commander la station de base 13A lors de transfert de données destinées au terminal UE 11. Sur réception du message PACKET_OUT, la station de base 13A met à jour sa table de flux avec la règle de traitement contenu dans le message, autrement dit avec les adresses IP du 25 commutateur 16A, de la passerelle d'interconnexion 15 et l'identifiant de tunnel TEID (étape E250). Ces paramètres définissent un tunnel de communication unique entre la station de base 13A et la passerelle d'interconnexion 15 pour le transfert de données en liaison montante. La station de base 13A établit alors une connexion RRC (Radio Resource Control) avec le terminal UE 11 (étape E260). 30 Puis elle crée un identifiant de point d'extrémité de tunnel en liaison descendante et l'envoie au dispositif de contrôle 14 par l'intermédiaire du protocole OpenFlowTM (étape E270). Le dispositif de contrôle 14 met à jour dans sa base de données utilisateurs 25 les paramètres de communication alloués au terminal UE 11 (étape E280). Il envoie ces paramètres à la fonction virtuelle MME 20-11 dans un message XMPP IQ- 35 set (étape E290). Par ailleurs, il commande, par le biais de son module de commande 14A, le commutateur 16A et la passerelle 15 en leur envoyant un message OpenFlowTM PACKET_OUT comprenant des règles de traitement des flux de données relatifs au terminal UE 11 (étape E300). 3025387 28 Par exemple, une telle règle peut être de router les flux de données destinés au terminal UE 11 vers la station de base 13A. Le commutateur 16A et la passerelle 15 mettent à jour leurs tables de flux à partir de ces règles de traitement. Cette étape clôture l'établissement du plan usager pour les communications du 5 terminal UE 11. Nous allons maintenant décrire, en référence à la figure 7, les principales étapes d'une procédure de traitement d'une requête de service à l'initiative du coeur de réseau 10 et destinée à un terminal UE 11 se trouvant dans un état non actif ou « idle » pour lequel des 10 données ont été reçues par le coeur de réseau (étape F10). Cette procédure comprend l'établissement d'un plan usager permettant au terminal UE 11 de recevoir des données en liaison descendante. On suppose donc qu'un flux de données destiné au terminal UE 11 a été reçu par le coeur de réseau IP 10 en provenance du réseau externe PDN 12, au niveau de la passerelle 15 d'interconnexion 15 (étape F10). Dans les architectures de type SDN, les tables de flux maintenues par les équipements du réseau sont généralement de dimensions limitées afin d'optimiser l'espace mémoire de ces équipements. Les entrées de ces tables de flux ont à cet effet une durée de vie limitée : lorsqu'un terminal UE 11 n'utilise pas un service du réseau pendant une période de temps déterminée, le 20 coeur de réseau 10 relâche l'information relative au terminal UE 11 dans le plan utilisateur et au niveau de la station de base 13A qui le servait. Autrement dit, il supprime les règles de traitement relatives aux données destinées au terminal UE 11 stockées dans les tables de flux maintenues par le commutateur 16A, la passerelle d'interconnexion 15 et la station de base 13A. Ainsi, durant cette période d'inactivité, lorsque le terminal UE 11 reçoit des données en 25 voie descendante en provenance du réseau externe PDN 12 et que la passerelle d'interconnexion 15 avec le réseau externe PDN 12 interroge sa table de flux pour déterminer vers quel équipement de réseau transférer ces données, elle ne trouve aucune règle de traitement à appliquer à ces données (étape F20). La passerelle d'interconnexion 15 envoie donc une requête au dispositif de contrôle 14, 30 dans un message OpenFlowTM PACKET_IN dans lequel elle insère l'entête du paquet IP reçu pour le terminal UE 11 (étape F30). Sur réception de ce message, le dispositif de contrôle 14 obtient à l'aide de son module de gestion 14D de base de données les paramètres du terminal UE 11 en interrogeant sa base de données utilisateurs 25 (étape F40). Ces paramètres incluent notamment les paramètres 35 de liste de recherche aussi appelée « tracking area list » (TAL) et l'identité GUTI du terminal UE 11. Il envoie ensuite un message de radiomessagerie (ou paging en anglais) aux stations de base 13 identifiées dans la liste de recherche selon une procédure connue en soi et 3025387 29 implémentée par le module de contrôle correspondant 14C (étape F50). Cette liste de recherche inclut notamment la station de base 13A servant la cellule dans laquelle se trouve le terminal UE 11. La station de base 13A transmet le message de radiomessagerie au terminal UE 11 5 (étape F60). Sur réception de ce message, le terminal UE 11 passe dans un état actif et envoie un message de requête de service à la station de base 13A comprenant ses clés de couche réseau NAS (étape F70). La station de base 13A relaie ce message dans un message OpenFLowTM au dispositif 10 de contrôle 14 (étape F80). Le dispositif de contrôle 14 met à jour sa base de données utilisateurs 25 avec l'identifiant de la station de base 13A (étape F90) et envoie la clé NAS à la fonction virtuelle MME 20-11 de gestion de la mobilité allouée au terminal UE 11 selon sa base de données utilisateurs 25 dans un message XMPP IQ-get (étape F100). 15 La fonction virtuelle MME 20-11 vérifie si la clé fournie par le terminal UE 11 correspond à la clé fournie par la fonction virtuelle de serveur HSS 21, stockée dans sa base de données en association avec le terminal UE 11 (étape F110). Elle envoie le résultat de cette authentification au dispositif de contrôle 14 dans un message XMPP IQ-result (étape F120). 20 Si le résultat est positif (i.e. le terminal UE 11 a été authentifié par la fonction MME 20- 11), le dispositif de contrôle 14 demande à la station de base 13A un identifiant TEID de tunnel de communication en voie descendante pour le terminal UE 11 (étape F130). La station de base 13A établit une connexion RRC avec le terminal UE 11 (étape F140). 25 Elle envoie au dispositif de contrôle 14 l'identifiant de tunnel TEID requis dans un message OpenFlowTM (étape F150). Le dispositif de contrôle 14 met à jour la base de données utilisateurs 25 avec cet identifiant de tunnel et le transmet dans un message OpenFlowTM PACKET_OUT au commutateur 16A et à la passerelle 15 sous forme de règles de traitement (étape F160). 30 Cette commande du dispositif de contrôle 14 du commutateur 16A et de la passerelle 15 permet de router de façon appropriée les flux de données destinés au terminal UE 11 dans le réseau. Dans les deux exemples de procédures décrites ici, on a envisagé l'établissement d'un 35 plan usager pour permettre à un terminal de communiquer avec un réseau externe de paquets de données. L'architecture proposée par l'invention permet également de maintenir et de mettre à jour ce plan usager en cas de dysfonctionnement (ex. défaillance ou surcharge) d'un équipement de réseau du plan usager ou d'une fonction de contrôle instanciée dans le système informatique en 3025387 30 nuage 17. Ainsi, notamment, si une fonction virtuelle MME 20-11 allouée au terminal UE 11 est surchargée, le dispositif de contrôle 14 en est informé par l'intermédiaire du serveur XMPP 18 et peut agir de manière appropriée après avoir mis à jour sa base de données de contrôle 24. Il peut notamment sélectionner une nouvelle fonction virtuelle MME 20 instanciée dans 5 le système informatique en nuage 17, ou demander l'instanciation d'une nouvelle fonction virtuelle MME 20 dans le système informatique en nuage 17, ou encore équilibrer le trafic entre les fonctions virtuelles de gestion de la mobilité MME 20 déjà instanciées. L'action du serveur XMPP 18 dans une telle situation peut être : - réactive, en informant le dispositif de contrôle 14 de l'état de surcharge courant de la fonction 10 de gestion de la mobilité 20-11 allouée au terminal UE 11 pour que le dispositif de contrôle 14 envisage une action appropriée ; ou proactive, en fournissant au dispositif de contrôle 14 une liste de fonctions MME 20 disponibles dans le système informatique en nuage 17 pour que le dispositif de contrôle 14 sélectionne une fonction parmi les fonctions disponibles et l'alloue au terminal UE 11. 15 Suite à cette allocation, le dispositif de contrôle 14 met à jour ses bases de données 24 et 25 de façon correspondante. REVENDICATIONS1. Dispositif de contrôle (14) d'un coeur de réseau IP, apte à commander une station de base (13) d'un réseau d'accès, un commutateur (15) du coeur de réseau IP et une passerelle d'interconnexion (16) du coeur de réseau IP à un réseau externe de paquets de données (12), le dispositif de contrôle comprenant : un module de communication (14B), apte à communiquer avec un serveur de connexion (18) à un système informatique en nuage et, par l'intermédiaire de ce serveur, avec une pluralité de fonctions virtuelles d'un plan de contrôle du coeur de réseau IP instanciées dans le système informatique en nuage ; un module de gestion (14D) : o d'une première base de données (25) identifiant, pour au moins un terminal d'un utilisateur géré par le coeur de réseau IP et servi par la station de base, au moins une desdites fonctions virtuelles allouée à ce terminal ; et o d'une seconde base de données (24) associant à au moins une desdites fonctions virtuelles, un identifiant de cette fonction auprès du serveur de connexion et un état de cette fonction ; ce module de gestion étant apte à mettre à jour la première et/ou la seconde base de données à partir d'informations reçues par le module de communication du serveur de connexion et/ou des fonctions virtuelles ; et un module de commande (14A) apte à utiliser des données de la première et/ou de la deuxième base de données pour établir et/ou maintenir, pour un terminal (11) géré par le coeur de réseau IP, un plan usager entre ladite station de base, ledit commutateur et ladite passerelle d'interconnexion. 2. Dispositif de contrôle selon la revendication 1, dans lequel le serveur de connexion (18) est un serveur dont le dispositif de contrôle et les fonctions virtuelles sont des clients, le module de communication étant apte à communiquer avec le serveur de connexion et les fonctions virtuelles en utilisant le protocole de communication XMPP. 3. Dispositif de contrôle selon la revendication 1 ou 2, dans lequel les fonctions virtuelles du plan de contrôle instanciées dans le système informatique en nuage comprennent : au moins une fonction (20) de gestion de la mobilité de terminaux dans le coeur de réseau IP ; au moins une fonction (19) de contrôle de ladite passerelle d'interconnexion et/ou dudit commutateur. 4. Dispositif de contrôle selon l'une quelconque des revendications 1 à 3, comprenant en outre un module d'allocation (14C) apte à allouer au terminal géré par le coeur de réseau IP au 3025387 32 moins une dite fonction virtuelle instanciée dans le système informatique en nuage en fonction d'une information représentative d'un état de disponibilité et/ou de charge courant de cette fonction virtuelle, transmise par le serveur de connexion. 5 5. Dispositif de contrôle selon l'une quelconque des revendications 1 à 4, dans lequel la première base de données (25) comprend en outre, pour le terminal, au moins un paramètre de communication destiné à être utilisé pour un transfert de données dans le plan usager établi par le module de commande. 10 6. Dispositif de contrôle selon la revendication 5, dans lequel ledit au moins un paramètre de communication comprend une adresse de la passerelle d'interconnexion, une adresse du commutateur et des identifiants de points d'extrémité d'un tunnel de communication établi dans le plan usager. 15 7. Serveur de connexion (18) à un système informatique en nuage comprenant : un module de gestion (18A) d'une base de données associant à au moins un client du serveur de connexion un identifiant unique de ce client auprès du serveur de connexion et un état du client, ledit au moins un client comprenant au moins une fonction virtuelle d'un plan de contrôle d'un coeur de réseau IP, instanciée dans le système informatique en nuage, et un 20 dispositif de contrôle du coeur de réseau IP selon l'une quelconque des revendications 1 à 6 ; un module de communication (18B) apte à communiquer avec ladite au moins une fonction virtuelle et le dispositif de contrôle, et apte à transmettre au dispositif de contrôle des informations extraites de la base de données relatives à ladite au moins une fonction virtuelle. 25 8. Serveur de connexion selon la revendication 7, dans lequel le module de communication communiquant avec ladite au moins une fonction virtuelle et le dispositif de contrôle utilisent le protocole de communication XMPP. 9. Serveur de connexion selon la revendication 7 ou 8, dans lequel le module de 30 communication est apte à transmettre au dispositif de contrôle une information représentative d'un état de disponibilité et/ou de charge courant d'au moins une dite fonction virtuelle identifiée dans la base de données. 10. Coeur de réseau IP (10) comprenant : 35 un dispositif de contrôle (14) selon l'une quelconque des revendications 1 à 6 ; un serveur de connexion (18) à un système informatique en nuage selon l'une quelconque des revendications 7 à 9 ; et 3025387 33 - au moins une fonction virtuelle (19,20) d'un plan de contrôle du coeur de réseau IP instanciée dans le système informatique en nuage ; le dispositif de contrôle et ladite au moins une fonction virtuelle étant des clients du serveur de connexion. 5 11. Procédé de contrôle d'un coeur de réseau IP comprenant : une étape de réception d'informations en provenance d'un serveur de connexion à un système informatique en nuage, et/ou d'au moins une fonction virtuelle d'un plan de contrôle du coeur de réseau IP instanciée dans le système informatique en nuage par l'intermédiaire du serveur 10 de connexion ; une étape de gestion : o d'une première base de données identifiant pour au moins un terminal d'un utilisateur géré par le coeur de réseau IP au moins une dite fonction virtuelle allouée à ce terminal ; et/ou 15 o d'une seconde base de données associant à au moins une dite fonction virtuelle, un identifiant de cette fonction auprès du serveur de connexion et un état de cette fonction ; ladite étape de gestion comprenant une mise à jour de la première et/ou de la seconde base de données à partir desdites informations reçues ; et 20 une étape d'établissement et/ou de maintien, pour un terminal géré par le coeur de réseau IP, d'un plan usager entre une station de base d'un réseau d'accès servant le terminal, un commutateur du coeur de réseau IP et une passerelle d'interconnexion du coeur de réseau IP à un réseau externe de paquets de données, en utilisant des données de la première et/ou de la deuxième base de données. 25 12. Procédé de contrôle selon la revendication 11, comprenant en outre une étape de commande de la station de base et/ou du commutateur et/ou de la passerelle d'interconnexion, cette étape de commande comprenant la transmission à la station de base et/ou au commutateur et/ou à la passerelle d'interconnexion d'au moins une règle de traitement de flux de données 30 relatifs au terminal, ladite au moins une règle de traitement étant définie à partir de données de la première et/ou de la seconde base de données et étant destinée à être appliquée lors d'un transfert de données dans le plan usager. 13. Procédé de contrôle selon la revendication 11 ou 12, comprenant en outre une 35 étape d'allocation d'une desdites fonctions virtuelles du plan de contrôle au terminal en fonction d'une information représentative d'un état de disponibilité et/ou de charge courant de cette fonction transmis par le serveur de connexion. 3025387 34 14. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de contrôle selon l'une quelconque des revendications 11 à 13 lorsque ledit programme est exécuté par un ordinateur. 5 15. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de contrôle selon l'une quelconque des revendications 11 à 13. 10