FR3006140A1 - Dispositif et procede de controle d'un cœur de reseau ip - Google Patents

Abstract

Le dispositif de contrôle (16) comprend : - un module de communication avec une entité de contrôle de transfert de données (17) pour déclencher la sélection par cette entité d'une passerelle de transfert de données (15A) et obtenir de celle-ci des paramètres de communication à utiliser lors d'une session de communication entre un terminal (11) connecté à une station de base (14A) et une passerelle d'interconnexion (13) connecté à un réseau PDN (12) ; - un module de contrôle (16A) de la station de base via une règle de traitement à appliquer à des données relatives à la session et comprenant des paramètres de communication à utiliser lors de la session entre la station de base et la passerelle de transfert ; et - un module de contrôle (16B) de la passerelle de transfert via une règle de traitement à à des données relatives à la session et comprenant des paramètres de communication à utiliser lors de la session entre la passerelle de transfert et la passerelle d'interconnexion.

Description

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. 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.

L'architecture LTE/EPC définie par le consortium 3GPP est aujourd'hui en pleine évolution. Les modèles de trafic envisagés changent en effet de manière très dynamique et souvent imprédictible, de sorte que de nouvelles contraintes techniques s'imposent aux opérateurs des réseaux de télécommunications. L'une de ces contraintes consiste à transférer, de manière transparente pour l'utilisateur, des tunnels de communication actifs (c'est-à-dire, en cours d'utilisation pour des transmissions de données) établis avec un premier équipement du coeur de réseau vers un second équipement en cas de défaillance du premier équipement, par exemple parce que ce premier équipement est en situation de surcharge, ou pour des raisons d'optimisation d'énergie ou encore de limitation du nombre d'équipements actifs du réseau.

Dans l'architecture LTE/EPC actuelle, une défaillance d'un équipement du coeur de réseau est très contraignante pour l'opérateur gérant ce coeur de réseau car elle est susceptible d'entraîner une interruption du service offert par cet opérateur.

Pour mieux illustrer ce propos, 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 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 10, juin 2010. 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. Plus précisément sur la figure 1, le coeur de réseau EPC 1 permet à un terminal utilisateur UE 2, associé à (autrement dit, servi par) une station de base eNB 3A d'un réseau d'accès tel qu'un réseau de télécommunications mobiles, d'accéder à des services offerts par un réseau de paquets de données externe PDN 4. 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 S-GW (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 P-GW (pour « PDN GateWay »), permettant de connecter le coeur de réseau 1 au réseau externe 4 de paquets de 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, (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 S-GW 5 par l'intermédiaire d'interfaces S1-MME et 51-U respectivement. L'équipement MME 7 gère la connectivité réseau du terminal 2. Elle 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é intra-3GPP. Les passerelles S-GW 5 et P-GW 6 sont responsables du transfert des données au sein du coeur de réseau 1, de la mobilité IP et du contrôle de la qualité de service dans le plan de données.

L'équipement MME 7 est relié directement à la passerelle de transfert de données S- GW 5 par l'intermédiaire d'une interface S11. La passerelle de transfert de données S-GW 5 est connectée à la passerelle d'interconnexion P-GW 6 par l'intermédiaire d'une interface S5.

L'architecture LTE/EPC telle que proposée par le consortium 3GPP s'appuie sur le protocole GTP (GPRS Tunneling Protocol), qui a deux composantes : - le protocole GTP-U, utilisé pour le transfert (échange) de données utilisateur entre deux tunnels de communication séparés pour gérer les situations de mobilité du terminal utilisateur sur les interfaces S1 et S5 ; et - le protocole GTP-C utilisé pour établir, mettre à jour et maintenir les tunnels de communication GTP. Ainsi, les échanges de signalisation sur les interfaces S11 et S5 s'appuient sur le protocole GTP-C. L'équipement MME 7 utilise le protocole Si-AP sur l'interface S1-MME pour indiquer les paramètres radio et les paramètres des tunnels GTP aux stations de base 3A et 3B. Ces paramètres sont désignés plus généralement sous l'appellation de « paramètres de communication » dans la suite de la description. De façon connue en soi, un tunnel GTP est identifié au niveau de chaque noeud du réseau par un identifiant de point d'extrémité du tunnel ou TEID (Tunnel Endpoint IDentifier), une adresse IP et un numéro de port UDP (User Datagram Protocol). C'est l'extrémité « réceptrice » du tunnel GTP qui attribue localement la valeur de l'identifiant TEID, utilisée par l'extrémité émettrice du tunnel pour transmettre des données ou de la signalisation dans ce tunnel à destination de l'extrémité réceptrice. Ainsi, dans l'exemple illustré à la figure 1, la passerelle P-GW 6 utilise la valeur d'identifiant TEID allouée par la passerelle S-GW 5 pour le trafic descendant émis sur l'interface S5. Les valeurs d'identifiants TEID sont échangées entre les extrémités des tunnels en utilisant les protocoles GTP-C et S1-AP. Selon la définition actuelle de l'architecture LTE/EPC, lorsqu'un équipement du coeur de réseau 1, tel que par exemple la passerelle de transfert de données S-GW 5, est subitement défaillant, les sessions de communication en cours gérées par cet équipement sont automatiquement interrompues. Le standard 3GPP prévoit alors le recours à une procédure de restauration décrite dans le document 3GPP TS 23.007 intitulé « Technical Specification Group Core Network and Terminals ; Restoration procedures », Release 10, et illustrée schématiquement à la figure 2. Conformément à cette procédure, la défaillance de la passerelle de transfert de données S-GW 5 (étape E10) est détectée par l'équipement MME 7 ou par la passerelle P-GW 6. Sur détection de cette défaillance (étape E20), l'équipement MME 7 initie une procédure de libération de l'interface S1 pour les sessions actives passant par la passerelle de transfert de données S-GW 5 (étape E30). Puis, l'équipement MME 7 alloue une nouvelle passerelle de transfert de données (non représentée sur la figure 1, référencée par « S-GW' » sur la figure 2) aux terminaux concernés (i.e. aux terminaux actifs ou non associés à la passerelle de transfert de données 5 défaillante), comme le terminal 2, et met à jour l'interface S5 en envoyant à la nouvelle passerelle de transfert de données S-GW' un message « Creation Session Request » requérant une création de session (étape E40). Ce message inclut l'adresse de la passerelle P-GW 6 et la valeur P-GW-TEID allouée par la passerelle P-GW 6 pour le trafic en liaison montante sur l'interface S5. La passerelle de transfert de données S-GW' alloue alors une valeur S-GW'-TEID pour le trafic en liaison descendante associé au terminal 2 sur l'interface S5. Puis elle notifie la passerelle P-GW 6 du changement de passerelle de transfert de données en lui envoyant un message « Modify Bearer Request » (étape E50). Les passerelles S-GW' et P-GW 6 accusent alors réception des différents messages (étapes E60 et E70). L'équipement MME 7 rétablit ensuite le canal radio et le canal S1 de chaque terminal impacté (étape E80). Toutefois, à cet effet, conformément à la norme 3GPP, l'équipement MME 7 attend de recevoir un message de requête de service du terminal 2 ou un message de notification de la présence de données destinées au terminal 2 en provenance de la nouvelle passerelle de transfert de données S-GW'. Autrement dit, cette procédure de restauration n'est pas transparente pour l'utilisateur du terminal 2 puisqu'elle met fin aux sessions de communication en cours et attend, pour rétablir ces sessions, que le terminal 2 initie une nouvelle requête de service. L'expérience de l'utilisateur du terminal 2 est donc dégradée. Par ailleurs, le rétablissement d'une session de communication engendre une signalisation importante selon cette procédure du fait de l'établissement de nouveaux tunnels GTP entre les différents équipements du coeur de réseau.

On peut envisager d'autres situations dans lesquelles l'architecture LTE/EPC telle que définie actuellement par le consortium 3GPP présente certaines insuffisances. Ainsi, à titre illustratif, l'engouement des utilisateurs pour des applications gourmandes en bande passante telles que le téléchargement de vidéos, génère un trafic particulièrement imprévisible qui peut créer des goulots d'étranglement et/ou de congestion dans le plan de données du coeur de réseau LTE/EPC, typiquement au niveau des passerelles de transfert de données S-GW, des stations de base eNB et des passerelles P-GW. Pour résoudre ce problème, il est possible de recourir à des techniques de répartition de la charge entre les équipements du coeur de réseau, aussi connues sous le nom de techniques de « load balancing ».

Dans l'état actuel de la norme, et comme décrit précédemment, l'équipement MME sélectionne pour une session de communication d'un terminal utilisateur, une passerelle de transfert de données S-GW et une passerelle d'interconnexion P-GW en se basant sur des facteurs de poids (ou WF pour « Weight Factors ») qui sont obtenus du serveur DNS (pour « Domain Name Server ») du coeur de réseau. Le poids associé par le serveur DNS à une passerelle dépend de sa capacité par rapport à des passerelles concurrentes servant une même région. Ainsi, l'équipement MME considère la capacité d'une passerelle de transfert de données avant de l'attribuer à une session de communication d'un terminal utilisateur, et met en oeuvre une répartition en quelque sorte « proactive » de la charge.

Toutefois, l'équipement MME n'a aucun moyen de connaître la charge en temps réel de cette passerelle de transfert de données, et d'anticiper ou gérer une éventuelle surcharge due par exemple à une augmentation soudaine du trafic engendré par les utilisateurs associés à cette passerelle de transfert de données. Par conséquent, en situation de surcharge, l'équipement MME va continuer d'assigner aux terminaux utilisateur lui adressant une requête de service la même passerelle de transfert de données. En outre, la norme ne spécifie aujourd'hui aucun mécanisme permettant de transférer de manière transparente des sessions de communication en cours d'une passerelle de transfert de données à une autre. Comme illustré précédemment, un transfert du plan de données d'un équipement du coeur de réseau à un autre requiert le rétablissement de tunnels de communication GTP, ce qui entraîne des interruptions de sessions et une signalisation importante au sein du coeur de réseau EPC. Les deux situations précédemment décrites montrent que le couplage étroit du plan de données et du plan de contrôle au sein d'une même entité du coeur de réseau (typiquement au sein d'une même passerelle de transfert de données S-GW) tel qu'il est envisagé actuellement dans l'architecture LTE/EPC défini par le 3GPP induit de fortes contraintes dès lors que l'on souhaite rendre cette architecture plus flexible ou plus fiable en termes de connectivité IP pour les utilisateurs. 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, plus communément connu sous l'appellation SDN pour « Software Defined Networking ».

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 tels que les commutateurs (« switches » en anglais) ou les routeurs est 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 à cette fin notamment sur le protocole de communication OpenFlow défini par l'ONF (Open Networking Foundation), qui permet une programmation simplifiée, via une interface standard, des équipements périphériques du réseau. 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 de la passerelle de transfert de données S-GW et de la passerelle d'interconnexion P-GW, dans un dispositif de contrôle exécuté par une machine virtuelle dans un centre de données externe aussi connu sous l'appellation de nuage informatique ou de « cloud » en anglais. Les équipements du plan de données du coeur de réseau EPC sont remplacés par des commutateurs OpenFlow, et le dispositif de contrôle est responsable de l'établissement du plan de données. Toutefois, cette proposition s'appuie sur les mêmes interfaces entre les entités de contrôle du réseau que celles définies par le consortium 3GPP décrites précédemment, et notamment sur l'interface S1-MME entre la station de base eNB et l'équipement MME. Par ailleurs le document de J. Kempf et al. ne décrit aucune autre procédure de restauration pouvant être mise en oeuvre en cas de défaillance ou de surcharge d'une passerelle de transfert de données S-GW que celle définie par le consortium 3GPP et rappelée ci-dessus. 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 d'améliorer l'expérience de l'utilisateur final dans les situations critiques envisagées précédemment (défaillance ou surcharge d'une passerelle de transfert de données). 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 comprenant : un module de communication apte à communiquer avec une entité de contrôle de transfert de données du coeur de réseau IP, et configuré pour déclencher la sélection par l'entité de contrôle de transfert de données d'une passerelle de transfert de données du coeur de réseau IP, le module de communication étant en outre configuré pour obtenir de l'entité de contrôle de transfert de données des paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal, connecté à une station de base d'un réseau d'accès, et une passerelle d'interconnexion du coeur de réseau IP connecté à un réseau de paquets de données, cette session de communication transitant par la station de base et la passerelle de transfert de données ; un premier module de contrôle de la station de base au moyen d'une première règle de traitement destinée à être appliquée par cette station de base suite à la réception de données relatives à la session de communication, la première règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la passerelle de transfert de données ; et un deuxième module de contrôle de la passerelle de transfert de données au moyen d'une deuxième règle de traitement destinée à être appliquée par cette passerelle de transfert de données suite à la réception de données relatives à la session de communication, la deuxième règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données et la passerelle d'interconnexion.

Corrélativement, l'invention vise également un procédé de contrôle destiné à être mis en oeuvre par un dispositif de contrôle d'un coeur de réseau IP, et comprenant : une étape de communication avec une entité de contrôle de transfert de données du coeur de réseau IP, comprenant un déclenchement d'une sélection par l'entité de contrôle de transfert de données d'une passerelle de transfert de données du coeur de réseau IP, et une obtention auprès de l'entité de contrôle de transfert de données de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal, connecté à une station de base d'un réseau d'accès, et une passerelle d'interconnexion du coeur de réseau IP connectée à un réseau de paquets de données, cette session de communication transitant par la station de base et la passerelle de transfert de données ; une étape de contrôle de la station de base au moyen d'une première règle de traitement destinée à être appliquée par cette station de base suite à la réception de données relatives à la session de communication, la première règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la passerelle de transfert de données; et une étape de contrôle de la passerelle de transfert de données au moyen d'une deuxième règle de traitement destinée à être appliquée par cette passerelle de transfert de données suite à la réception de données relatives à la session de communication, la deuxième règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données et la passerelle d'interconnexion. Par session de communication, on entend ici une session initiée par le terminal ou par le coeur de réseau dans le cadre d'un service offert par un réseau externe de paquets de données géré par le coeur de réseau. Cette session de communication est le support d'un échange de données entre le terminal et le réseau externe via le coeur de réseau. Chaque session de communication est associée à une qualité de service qui dépend du type de trafic échangé lors de la session (ex. session FTP (File Transfer Protocol), session de communication de voix sur IP, etc.).

Par données relatives à une session de communication, on entend ici des données échangées lors de cette session en liaison montante (du terminal vers le réseau externe) ou descendante (du réseau externe vers le terminal). L'invention propose ainsi de découpler les plans de données et de contrôle dans le coeur de réseau IP, en appliquant les principes SDN du réseau défini par logiciel à l'architecture du coeur de réseau IP. Plus précisément elle propose de contrôler, par l'intermédiaire d'un dispositif de contrôle par exemple logiciel, non seulement les passerelles de transfert de données du coeur de réseau mais également les stations de base des réseaux d'accès au coeur de réseau. Les stations de base du réseau d'accès et les passerelles de transfert de données sont ainsi connectées directement au dispositif de contrôle. Conformément à l'invention, le contrôle opéré par le dispositif de contrôle est réalisé à l'aide de règles de traitement des données, élaborées par le dispositif de contrôle logiciel et transmises aux passerelles de transfert de données et aux stations de base pour application lors d'une session de communication d'un terminal. Ces règles de traitement sont par exemple des règles de transfert des données. Ainsi, dans un mode particulier de réalisation de l'invention : les paramètres de communication de la première règle comprennent une adresse de la passerelle de transfert de données et un identifiant de point d'extrémité d'un tunnel de communication établi entre la passerelle de transfert de données et la station de base pour le transfert des données, alloué par l'entité de contrôle de transfert de données ; et/ou les paramètres de communication de la deuxième règle comprennent une adresse de la passerelle d'interconnexion et un identifiant de point d'extrémité d'un tunnel de communication établi entre la passerelle de transfert de données et la passerelle d'interconnexion pour le transfert des données, alloué par l'entité de contrôle de transfert de données. Les règles de traitement transmises par le dispositif de contrôle logiciel peuvent être mises à jour facilement directement au niveau des équipements commandés par le dispositif de contrôle. La gestion du coeur de réseau, et en particulier les procédures d'établissement et de maintien des sessions de communication au sein du coeur de réseau, sont ainsi simplifiées. Grâce au découplage proposé par l'invention, et plus précisément en centralisant au niveau du dispositif de contrôle la sélection des passerelles de transfert de données impliquées dans la session de communication, l'invention offre la possibilité de mettre aisément en oeuvre des procédures de restauration en cas de surcharge et/ou de défaillance d'un équipement du coeur de réseau tel une passerelle de transfert de données, et ce, sans nécessiter de signalisation excessive, et transparentes pour les utilisateurs des terminaux. 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 ainsi privilégiée.

L'invention s'applique de façon privilégiée à une architecture de coeur de réseau LTE/EPC. Dans un tel contexte, elle propose de modifier les protocoles de communications prévus sur les interfaces de communication S1-MME (entre les stations de base et l'entité de gestion de la mobilité du coeur de réseau) et S11 (entre l'entité de gestion de la mobilité et les passerelles de transfert de données S-GW).

Ainsi, contrairement à l'état de la technique décrit dans le document de J. Kempf et al., l'invention propose de modifier les interfaces de l'architecture LTE/EPC prévues par le consortium 3GPP. La nouvelle architecture de coeur de réseau définie par l'invention permet ainsi de revoir la procédure de restauration en cas de défaillance d'un équipement du coeur de réseau proposée actuellement par le consortium 3GPP, et d'offrir aux terminaux une procédure plus souple et plus transparente en termes de connectivité IP. Dans un mode particulier de réalisation de l'invention, le module de communication communique avec l'entité de contrôle de transfert de données par l'intermédiaire d'une interface de programmation. Dans un autre mode particulier de réalisation, le premier module de contrôle et le deuxième module de contrôle sont configurés pour communiquer respectivement avec la station de base et avec la passerelle de transfert de données par l'intermédiaire du protocole OpenFlow. L'utilisation du protocole OpenFlow facilite l'implémentation de l'invention.

En outre, ce protocole offre la possibilité au dispositif de contrôle de collecter en temps réel des statistiques de charge auprès des passerelles de transfert de données, et d'envisager ainsi une sélection des équipements impliqués dans la session de communication d'un terminal en fonction de la charge courante de ces équipements. Il est également possible d'appliquer aisément des algorithmes de répartition de la charge lors de cette sélection pour améliorer l'expérience des utilisateurs. Ainsi, dans un mode particulier de réalisation, le dispositif de contrôle comprend en outre un module d'obtention d'informations représentatives d'une charge courante d'au moins une passerelle de transfert de données du coeur de réseau IP connectée au dispositif de contrôle, le module de communication étant en outre configuré pour fournir ces informations à l'entité de contrôle de transfert de données via une interface de programmation. Dans un autre mode de réalisation de l'invention, le module de communication du dispositif de contrôle est en outre configuré pour déclencher par l'intermédiaire d'une interface de programmation, sur réception d'une requête d'attachement du terminal au coeur de réseau IP, une authentification du terminal par une entité de gestion de la mobilité appartenant au coeur de réseau IP. Ainsi, dans ce mode de réalisation, l'authentification du terminal est géré par une application s'exécutant au-dessus du dispositif de contrôle logiciel et interagissant avec celui-ci via une interface de programmation ou API. Dans un autre mode de réalisation de l'invention, le dispositif de contrôle comprend en outre un module de détection d'une défaillance ou d'une surcharge de la passerelle de transfert de données, le module de communication étant en outre configuré pour informer l'entité de contrôle de transfert de données de cette défaillance ou de cette surcharge et pour déclencher la sélection par l'entité de contrôle de transfert de données d'une nouvelle passerelle de transfert de données pour la session de communication, et dans lequel : - le premier module de contrôle est configuré pour mettre à jour la première règle de traitement appliquée par la station de base avec des paramètres de communication, obtenus de l'entité de contrôle de transfert de données par le module de communication du dispositif de contrôle et destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la nouvelle passerelle de transfert de données ; et le deuxième module de contrôle est configuré pour contrôler la nouvelle passerelle de transfert de données à l'aide d'une troisième règle de traitement destinée à être appliquée par cette nouvelle passerelle de transfert de données suite à la réception de données relatives à la session de communication, la troisième règle comprenant des paramètres de communication, obtenus de l'entité de contrôle de transfert de données par le module de communication du dispositif de contrôle et destinés à être utilisés lors de la session de communication pour le transfert de données entre la nouvelle passerelle de transfert de données et la passerelle d'interconnexion. Par exemple, la première règle de traitement est mise à jour avec une adresse de la nouvelle passerelle de transfert de données. En outre, les paramètres de communication de la deuxième règle de traitement et de la troisième règle de traitement peuvent comprendre un même identifiant de point d'extrémité de tunnel alloué par l'entité de contrôle de transfert de données et destiné à être utilisé entre la passerelle de transfert de données et la passerelle d'interconnexion, et entre la nouvelle passerelle de transfert de données et la passerelle d'interconnexion. Autrement dit, l'identifiant de point d'extrémité de tunnel alloué par l'entité de contrôle de transfert de données est invariant par rapport à la passerelle de transfert de données sélectionnée pour la session de communication. La signalisation nécessaire pour gérer un changement de passerelle de transfert de données est ainsi avantageusement limitée : seule l'adresse de la nouvelle passerelle de transfert de données sélectionnée nécessite d'être signalée par le dispositif de contrôle pour assurer la continuité de la session de communication.

Pour permettre le découplage des plans de contrôle et de données, l'invention s'appuie non seulement sur un dispositif de contrôle, mais également sur une entité de contrôle de transfert de données du coeur de réseau IP apte à communiquer avec le dispositif de contrôle logiciel, par exemple via une interface de programmation, autrement dit, s'exécutant au-dessus du dispositif de contrôle logiciel.

Ainsi, l'invention vise également une entité de contrôle de transfert de données d'un coeur de réseau IP comprenant : un module de communication apte à communiquer avec un dispositif de contrôle du coeur de réseau IP selon l'invention ; un module de sélection, déclenché par le dispositif de contrôle via le module de communication, et configuré pour sélectionner une passerelle de transfert de données du coeur de réseau IP ; un module d'obtention de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal connecté à une station de base d'un réseau d'accès et une passerelle d'interconnexion du coeur de réseau IP connectée à un réseau de paquets de données, cette session de communication transitant par la station de base et la passerelle de transfert de données ; un module de fourniture à la passerelle d'interconnexion de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données et la passerelle d'interconnexion ; le module de communication étant configuré pour fournir au dispositif de contrôle des paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la passerelle de transfert de données. Corrélativement, l'invention vise aussi un procédé de sélection destiné à être mis en oeuvre par une entité de contrôle de transfert de données d'un coeur de réseau IP, et comprenant : une étape de sélection, déclenchée par un dispositif de contrôle du coeur de réseau IP, d'une passerelle de transfert de données du coeur de réseau IP ; une étape d'obtention de paramètres de communication destinés à être utilisés lors d'une session de communication entre une terminal connecté à une station de base d'un réseau d'accès et une passerelle d'interconnexion du coeur de réseau IP connectée à un réseau de paquets de données, cette session de communication transitant par la station de base et la passerelle de transfert de données ; - une étape de fourniture o à ladite passerelle d'interconnexion, de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données et la passerelle d'interconnexion ; et o au dispositif de contrôle, de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la passerelle de transfert de données.

L'entité de contrôle de transfert de données et le procédé de sélection selon l'invention bénéficient des mêmes avantages que ceux cités précédemment pour le dispositif de contrôle et le procédé de contrôle selon l'invention. Dans un mode particulier de réalisation, le module d'obtention de paramètres de communication de l'entité de contrôle de transfert de données est configuré pour allouer à la session de communication un identifiant de point d'extrémité d'un tunnel de communication entre la passerelle de transfert de données et la station de base et un identifiant de point d'extrémité d'un tunnel de communication entre la passerelle de transfert de données et la passerelle d'interconnexion.

Par exemple, les identifiants alloués par l'entité à la session de communication sont invariants durant la session de communication, de sorte à simplifier la signalisation échangée lors de session notamment en cas de changement de passerelle de transfert de données en cours de session.

Dans un autre mode de réalisation, le module de sélection de l'entité de contrôle de transfert de données est configuré pour sélectionner la passerelle de transfert de données parmi une pluralité de passerelles de transfert de données contrôlées par le dispositif de contrôle en utilisant des informations représentatives d'une charge courante de ces passerelles de transfert de données fournies par le dispositif de contrôle via une interface de programmation.

L'invention offre ainsi la possibilité de mettre en oeuvre des algorithmes de répartition de la charge entre les différents équipements du coeur de réseau et notamment les passerelles de transfert de données, de sorte à améliorer l'expérience des utilisateurs en matière de connectivité IP. Grâce à cette connaissance de la charge des passerelles de transfert de données, il est possible d'envisager en cas de surcharge d'une passerelle de transférer tout ou partie des sessions transitant par cette passerelle de transfert de données vers une autre passerelle de transfert de données. Ainsi, par exemple, dans un mode particulier de réalisation de l'invention : - le module de sélection est configuré pour sélectionner une nouvelle passerelle de transfert de données pour la session de communication du terminal lorsqu'il est informé par le dispositif de contrôle, via une interface de programmation, d'une défaillance ou d'une surcharge de la passerelle de transfert de données ; - le module de fourniture et le module de communication sont configurés pour fournir respectivement à la passerelle d'interconnexion et au dispositif de contrôle cette adresse de la nouvelle passerelle de transfert de données.

Selon un autre aspect, l'invention vise également un coeur de réseau IP comprenant : - une pluralité de passerelles de transfert de données ; - un dispositif de contrôle selon l'invention, apte à contrôler au moins une station de base d'un réseau d'accès auquel est connecté un terminal et la pluralité de passerelles de transfert de données ; et - une entité de contrôle de transfert de données selon l'invention, apte à communiquer avec le dispositif de contrôle, et à sélectionner une passerelle de transfert de données parmi la pluralité de passerelles de transfert de données contrôlées par le dispositif de contrôle pour une session de communication du terminal. Dans un mode particulier de réalisation de l'invention, ce coeur de réseau IP comprend en outre une entité de gestion de la mobilité configurée pour authentifier le terminal, cette authentification étant déclenchée par le dispositif de contrôle via une interface de programmation. Selon un autre aspect encore, l'invention vise aussi une station de base d'un réseau d'accès, apte à servir un terminal lors d'une session de communication, et comprenant : des moyens de réception, en provenance d'un dispositif de contrôle d'un coeur de réseau IP selon l'invention, d'une règle de traitement destinée à être appliquée par cette station de base suite à la réception de données relatives à cette session de communication du terminal, la règle de traitement comprenant des paramètres de communication destinés à être utilisés lors de cette session de communication pour le transfert de données entre la station de base et une passerelle de transfert de données du coeur de réseau IP ; et des moyens d'application de cette règle de traitement à des données relatives à la session de communication. Le coeur de réseau IP et la station de base selon l'invention présentent les mêmes avantages que ceux cités précédemment pour le dispositif de contrôle et l'entité de contrôle de transfert de données. Dans un mode particulier de réalisation, les différentes étapes du procédé de contrôle et/ou du procédé de sélection 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. L'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans une entité de contrôle de transfert de données 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 sélection tel que décrit ci-dessus. Chacun de ces programmes 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. 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 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 du procédé en question.

On peut également envisager, dans d'autres modes de réalisation, que le procédé de contrôle, le procédé de sélection, le dispositif de contrôle, l'entité de contrôle de transfert de données, la station de base et le coeur de réseau selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.

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 des exemples de 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 ; - la figure 2, déjà décrite, illustre une procédure de restauration supportée par l'architecture de la figure 1 et proposée par le consortium 3GPP en cas de défaillance d'une passerelle de transfert de données ; - les figures 3 et 4 illustrent les principes d'un réseau défini par logiciel (SDN) ; - la figure 5 représente, dans son environnement, un coeur de réseau, un dispositif de contrôle, une entité de contrôle de transfert de données et une station de base conformes à l'invention dans un mode particulier de réalisation ; - la figure 6 représente schématiquement l'architecture matérielle d'un dispositif informatique implémentant le dispositif de contrôle et l'entité de contrôle de transfert de données illustrés à la figure 6; - la figure 7 représente les principales étapes d'une procédure d'attachement d'un terminal au coeur de réseau de la figure 5, pouvant être mise en oeuvre par le coeur de réseau de la figure 5, conformément à l'invention ; - la figure 8 représente les principales étapes d'une procédure d'établissement d'un plan de données pouvant être mise en oeuvre par le coeur de réseau de la figure 5, conformément à l'invention ; et - la figure 9 représente les principales étapes d'une procédure de restauration en cas de défaillance d'une passerelle de transfert de données, pouvant être mise en oeuvre par le coeur de réseau de la figure 5, conformément l'invention. 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 en effet de mettre en oeuvre aisément des procédures de restauration transparentes pour les utilisateurs en cas de défaillance d'un équipement du coeur de réseau et/ou d'équilibre de la charge afin de privilégier l'expérience des utilisateurs. Plus précisément, l'invention définit un nouveau plan de contrôle selon lequel une pluralité de passerelles de transfert de données du coeur de réseau et de stations de bases du réseau d'accès (via lesquelles des terminaux peuvent accéder aux services offerts par le coeur de réseau) sont commandées par un dispositif de contrôle. Dans le mode de réalisation décrit ici, ce dispositif de contrôle est un dispositif de contrôle logiciel, relié par l'intermédiaire d'une interface de programmation (ou API pour Application Programming Interface) à une entité responsable de la sélection des équipements du coeur de réseau impliqués dans les sessions de communication pour le transfert des données (i.e. les passerelles de transfert de données S-GW et passerelles d'interconnexion P-GW)) et l'établissement de tunnels de communication, dans le plan de données notamment, entre les équipements ainsi sélectionnés. Pour faciliter la compréhension de l'invention, nous allons dans un premier temps rappeler brièvement, en référence aux figures 3 et 4, les principes généraux d'une architecture SDN. Dans l'exemple retenu pour illustrer ces principes, on suppose que cette architecture repose sur l'utilisation du protocole OpenFlow, connu de l'homme du métier et décrit notamment dans le document « Openflow switch specification, version 1.3.1 », Septembre 2012. 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 appliquées au niveau du réseau. 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 tels que les commutateurs ou les routeurs en présence de données relatives à une session de communication est alors défini par le dispositif de contrôle au moyen de règles dites de traitement qu'il transmet aux équipements du réseau. Ces règles sont stockées par les équipements du réseau et sont destinées à être appliquées par ceux-ci sur réception de données relatives à une session de communication. Elles spécifient par exemple les équipements du réseau vers lesquels transférer les données (i.e. le trafic) en liaisons montante et descendante. La figure 3 résume ce mode de fonctionnement en modélisant schématiquement une architecture SDN selon trois couches : une couche inférieure DP, modélisant le plan de données et comprenant les commutateurs/routeurs R du réseau commandés (contrôlés) par le dispositif de contrôle (ces commutateurs/routeurs R peuvent être indifféremment physiques ou virtuels) ; une couche intermédiaire NW CTRL, modélisant à proprement parler le dispositif de contrôle 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 commutateurs/routeurs R 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 programmation ou API appelées « NorthBound API » et « SouthBound API » (notées respectivement « NB API » et « SB API » sur la figure 3). Le dispositif de contrôle OpenCTR communique par ailleurs avec d'autres contrôleurs via des interfaces de programmation appelées « East/West Bound API » (et notées « E/WB API » sur la figure 3). 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 OpenFlow. Les interfaces de programmation NB API et E/WB API sont basées sur n'importe quel protocole de communication ouvert, choisi par exemple parmi les protocoles connus SOAP (pour « Simple Object Access Protocol »), RPC (pour « Remote Procedure Call ») ou REST (pour « Representational State Transfer »).

Comme rappelé précédemment et illustré à la figure 4, le protocole OpenFlow permet au dispositif de contrôle logiciel OpenCTR de commander aisément chaque commutateur/routeur R au moyen d'un 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 le routeur 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 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 commutateur sur réception d'un paquet d'un flux de données associé à une session de communication d'un terminal déterminé, et des paquets suivants associés au même flux. Ces règles de traitement sont stockées au niveau de chaque commutateur R sous la forme de tables de flux FTAB (ou « flow tables » en anglais), dont les entrées peuvent être aisément modifiées par le dispositif de contrôle OpenCTR à l'aide du protocole OpenFlow (ex. ajout, mise à jour, suppression d'entrées dans la table). A titre illustratif, une entrée E d'une telle table de flux FTAB est représentée sur la figure 4. Elle se présente sous la forme de plusieurs champs ou paramètres destinés à être examinés par le commutateur R sur réception d'un paquet de données pour identifier quel traitement appliquer sur ce paquet (ex. vers quel équipement du coeur de réseau transférer le paquet de données). Ces champs incluent par exemple un champ MF (pour « Match Fields ») indiquant les champs de l'entête des paquets concernés par cette entrée E de la table, ainsi qu'un champ INST (pour « Instructions ») définissant le traitement à appliquer sur les paquets dont l'entête comprend les champs identifiés par MF. D'autres champs peuvent bien entendu être également définis pour chaque entrée de la table FTAB en sus de ces deux champs, comme illustré sur la figure 4, tels que par exemple un champ TO (pour « Time Out), PRIO (pour « Priority »), COOK (pour « Cookie ») ou CNT (pour « Counters »). Le commutateur R utilise les tables de flux FTAB ainsi définies de la façon suivante.

Sur réception d'un paquet de données, il cherche dans les tables FTAB stockées si le champ MF d'une entrée coïncide avec les champs de l'entête de ce paquet. Le cas échéant, les instructions associées à cette entrée spécifiées dans le champ INST correspondant sont exécutées par le commutateur R 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 le 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 au commutateur R pour qu'il la stocke dans une table de flux associée au terminal. On comprend bien dès lors, au vu du mode de fonctionnement qui vient d'être décrit, que selon une architecture de réseau SDN, les plans de contrôle et de données sont découplés. Nous allons maintenant décrire, en référence aux figures 5 à 9, comment l'invention 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 l'architecture de coeur de réseau IP présentée (ex. passerelles de transfert de données telles que des passerelles SGW, passerelles d'interconnexion telles que des passerelles P-GW, stations de bases en particulier de type eNodeB, équipement de gestion de mobilité tel qu'un équipement MME, établissement des tunnels de communication selon le protocole GTP, 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 ici. L'invention ne se limite toutefois pas aux seuls réseaux de 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 propriétaire.

La figure 5 représente un coeur de réseau LTE/EPC 10 conforme à l'invention, dans un mode particulier de réalisation dans lequel le coeur de réseau 10 permet à un terminal UE 11 d'accéder à des services offerts par un (ou des) réseau(x) externe(s) de paquets de données PDN 12.

Le réseau PDN 12 est relié au coeur de réseau 10 par l'intermédiaire d'une passerelle d'interconnexion 13, pouvant être une passerelle P-GW telle que définie dans le document 3GPP TS 23.401, permettant l'accès du coeur de réseau 10 au réseau PDN 12 et vice versa.

On suppose ici, que pour accéder aux services offerts par le réseau PDN 12 via le coeur de réseau LTE/EPC 10, le terminal UE 11 est connecté à une station de base 14 (typiquement une 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, les fonctions de contrôle d'une pluralité de passerelles de transfert de données 15 du coeur de réseau 10 (lesquelles peuvent typiquement être des passerelles S-GW telles que définies dans le document 3GPP TS 23.401), qui permettent de relier les stations de base 14 à la passerelle d'interconnexion 13 et donc au coeur de réseau 10, sont séparées des fonctions de transfert de données destinées à être appliquées par ces passerelles de transfert de données (autrement dit du plan de données). Cette séparation du plan de contrôle (signalisation) et du plan de données est assurée par l'introduction d'un dispositif de contrôle logiciel 16 dans le coeur de réseau 10, reprenant les fonctions du dispositif de contrôle OpenCTR décrites précédemment.

Le dispositif de contrôle logiciel 16 centralise ainsi l'intelligence réseau des passerelles de transfert de données et détermine les règles de traitement devant être appliquées aux paquets de données reçus par celles-ci. Il assure l'établissement et le maintien des sessions de communication des terminaux des utilisateurs accédant au coeur de réseau 10. Afin de mieux illustrer la séparation des plans préconisée par l'invention, l'entité rassemblant les fonctions de contrôle des passerelles de transfert de données est référencée par « SGW-C » sur la figure 5 et dans la description. Une telle entité SGW-C est désignée comme étant une entité de contrôle de transfert de données. Pour leur part, les équipements appliquant les fonctions de traitement ou de transfert dans le plan de données de ces passerelles de transfert de données sont référencés par « SGW-D ».

Dans le mode de réalisation décrit ici, les passerelles de transfert de données SGW-D 15 commandées par l'intermédiaire du dispositif de contrôle logiciel 16 sont aptes à encapsuler et à désencapsuler des paquets échangés sur un tunnel de communication établi conformément au protocole GTP-U comme défini par le consortium 3GPP, et appartiennent à une même région prédéterminée. Ainsi, dans l'exemple illustré à la figure 5, le dispositif de contrôle logiciel 16 centralise, via l'entité logicielle SGW-C 17, les fonctions de contrôle de trois passerelles de transfert de données SGW-D 15A, 15B et 15C. Bien entendu, ce nombre peut varier, notamment en fonction de contraintes opérationnelles et/ou de dimensionnement des équipements du coeur de réseau. L'entité logicielle SGW-C 17 est une entité de contrôle de transfert de données conforme à l'invention, qui se présente plus précisément ici sous la forme d'une application s'exécutant au-dessus du dispositif de contrôle logiciel 16 et communiquant avec celui-ci via une interface de programmation ou API notée API17. De même, dans le mode de réalisation décrit ici, le coeur de réseau 10 comprend une entité de gestion de la mobilité 18 qui se présente sous forme logicielle, en particulier sous la forme d'une application s'exécutant au-dessus du dispositif de contrôle logiciel 16 et qui communique avec celui-ci via une interface de programmation notée API18. Ainsi, en référence à la figure 3 commentée précédemment et aux principes généraux du SDN, les interfaces de programmation API17 et API18 remplissent le rôle d'interfaces de programmation « NorthBound ». L'entité de gestion de la mobilité 18 est chargée d'authentifier les terminaux cherchant à accéder au coeur de réseau 10 (autrement dit de vérifier que ces terminaux sont bien autorisés à accéder au coeur de réseau 10 et/ou aux services offerts par le réseau PDN 12), selon des techniques d'authentification et d'autorisation connues de l'homme du métier. L'entité de gestion de la mobilité 18 est également responsable de la gestion de la mobilité des terminaux au sein d'un même réseau. Cette entité 18 peut notamment être un équipement MME tel que décrit dans le document 3GPP TS 23.401. Toutefois, contrairement à l'équipement MME décrit dans le document 3GPP TS 23.401 et conformément à l'invention, l'entité 18 de gestion de mobilité n'est plus responsable de la sélection, pour une session de communication associée à un terminal, de la passerelle de transfert de données SGW et de la passerelle P-GW impliquées lors de cette session dans l'échange de données entre le terminal et le réseau PDN 12. Cette fonction est en effet assurée, conformément à l'invention, par l'entité de contrôle de transfert de données SGW-C 17 du coeur de réseau 10, comme décrit plus en détail ultérieurement.

Il convient de noter que dans le mode de réalisation décrit ici, le dispositif de contrôle 16, et les entités SGW-C 17 et 18 sont des entités logicielles, autrement dit des applications ou des programmes d'ordinateur qui s'exécutent sur un même dispositif informatique ou ordinateur 19. En variante, ces applications peuvent s'exécuter sur des dispositifs informatiques distincts communiquant entre eux de façon connue de l'homme du métier.

La figure 6 illustre schématiquement l'architecture matérielle d'un tel dispositif informatique 19. Ce dispositif comprend un processeur 20, une mémoire morte 21, une mémoire vive 22, une mémoire non volatile 23 et des moyens de communication 24, aptes en particulier à communiquer avec les passerelles de transfert de données SGW-D 15, la passerelle d'interconnexion 13 et les stations de base 14 selon des protocoles de communication précisés ultérieurement. La mémoire morte 21 du dispositif informatique 19 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 20 et sur lequel sont enregistrés 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, et un programme d'ordinateur conforme à l'invention comportant des instructions pour l'exécution d'un procédé de sélection selon l'invention, dont les étapes sont illustrées ultérieurement en référence aux figures 7 à 9.

En d'autres termes, les programmes d'ordinateur précités définissent le dispositif de contrôle logiciel 16 et les entités logicielles SGW-C 17 et 18 (ainsi que les modules fonctionnels mis en oeuvre par ces entités), de sorte que dans la description les références 16, 17 et 18 peuvent désigner aussi bien les entités fonctionnelles correspondantes que le dispositif informatique 19 associé permettant d'exécuter ces entités. Pour en revenir à la figure 5, dans le mode de réalisation décrit ici, le dispositif de contrôle 16 contrôle le comportement des stations de base 14 (deux stations de base 14A et 14B étant représentées sur la figure 5, de manière non limitative) par l'intermédiaire d'un module de contrôle 16A (premier module de contrôle au sens de l'invention) implémentant le protocole de communication OpenFlow. Les stations de base 14A et 14B constituent des stations de base dont les fonctions radio peuvent être les mêmes que celles des stations de base eNodeB spécifiées dans le document 3GPP TS 23.401. Elles sont toutefois, conformément à l'invention et à la différence des stations de base eNodeB spécifiées dans le document 3GPP TS 23.401, commandées par le dispositif de contrôle 16 par l'intermédiaire du module 16A pour ce qui concerne le transfert des données vers les passerelles de transfert de données SGW-D 15, au moyen de règles de traitement définies par celui-ci et stockées dans des tables de flux FTAB14 mémorisées par les stations de base 14. Les tables FTAB14 sont similaires ou identiques aux tables FTAB décrites précédemment en référence à la figure 4. Ces règles de traitement identifient par exemple ici la passerelle de transfert de données SGW-D 15 vers laquelle transférer les paquets de données reçus d'un terminal en liaison montante par une station de base 14 lors d'une session de communication. Elles comprennent notamment les paramètres de communication destinés à être utilisés lors de ce transfert, c'est-à- dire typiquement les paramètres identifiant le tunnel de communication GTP-U destiné à être établi ou établi. Le dispositif de contrôle 16 contrôle en outre le comportement des passerelles de transfert de données SGW-D 15 (i.e. des passerelles de transfert de données actives dans le plan de données) par l'intermédiaire d'un module de contrôle 16B implémentant également le protocole de communication OpenFlow. Ce module de contrôle 16B constitue un deuxième module de contrôle au sens de l'invention. Il est configuré pour transmettre aux passerelles de transfert de données SGW-D 15 des règles de traitement (deuxièmes et troisièmes règles de traitement au sens de l'invention) définies par le dispositif de contrôle 16 et destinées à être appliquées par les passerelles de transfert de données SGW-D 15 sur réception de données relatives à une session de communication d'un terminal d'un utilisateur (notamment ici du terminal 11).

Ces règles de traitement sont stockées au niveau des passerelles de transfert de données SGW-D 15 dans des tables de flux FTAB15, similaires ou identiques aux tables FTAB décrites précédemment en référence à la figure 4. Elles identifient par exemple ici : d'une part, la passerelle d'interconnexion 13 (par exemple via une adresse IP) vers laquelle transférer les paquets de données reçus par les passerelles de transfert de données SGW-D 15 en liaison montante lors d'une session de communication associée à ce terminal, et les paramètres de communication destinés à être utilisés lors de ce transfert ; et d'autre part, la station de base 14A (par exemple via son adresse IP) vers laquelle transférer les paquets de données reçus par les passerelles de transfert de données SGW-D 15 en liaison descendante lors d'une session de communication associée à ce terminal, et les paramètres de communication destinés à être utilisés lors de ce transfert Les paramètres de communication stockés dans les tables de flux FTAB15 incluent typiquement les paramètres identifiant les tunnels de communication GTP-U destinés à être établis ou établis en liaison montante et en liaison descendante entre la passerelle de transfert de données SGW-D concernée, et la passerelle d'interconnexion et la station de base identifiées dans la table. Il convient de noter que le protocole OpenFlow étant connu de l'homme du métier, il n'est pas détaillé davantage ici. Dans le mode de réalisation décrit ici, on suppose que les stations de base 14 et les passerelles de transfert de données SGW-D 15 mettent en oeuvre, pour communiquer entre elles dans le plan de données, une interface basée sur l'établissement de tunnels de communication en liaisons montante et descendante conformes au protocole GTP-U, qui peut être similaire ou identique à l'interface S1-U spécifiée dans le document 3GPP TS 23.401. De même, les passerelles de transfert de données SGW-D 15 et la passerelle d'interconnexion 13 mettent en oeuvre, pour communiquer entre elles dans le plan de données, une interface basée sur l'établissement de tunnels de communication en liaisons montante et descendante conformes au protocole GTP-U, qui peut être similaire ou identique à l'interface S5-U spécifiée dans le document 3GPP TS 23.401. Selon l'architecture proposée par l'invention, le dispositif de contrôle 16 est, comme mentionné précédemment, chargé de l'établissement des sessions de communication pour les terminaux utilisateur, et en particulier pour le terminal UE 11. A cet effet, il interagit avec l'entité SGW-C 17 et l'entité MME 18 via les interfaces de programmation API17 et API18 respectivement. L'entité SGW-C 17 a, quant à elle, pour fonction d'établir les tunnels de communication GTP supportant les échanges de données en liaison descendante et en liaison montante transitant par les différents équipements du coeur de réseau 10 lors des sessions de communication des terminaux, et notamment entre les stations de base 14 et les passerelles de transfert de données SGW-D 15, et entre les passerelles de transfert de données SGW-D 15 et la passerelle d'interconnexion 13.

Ces tunnels de communication sont, comme rappelé précédemment, définis (i.e. identifiés) par différents paramètres de communication tels que les identifiants de points d'extrémités du tunnel TEID, ainsi qu'une adresse IP et un numéro de port UDP (User Datagram Protocol) de ces points.

On rappelle que, dans l'état actuel de la technique défini par le consortium 3GPP, c'est l'extrémité « réceptrice » du tunnel GTP qui attribue localement la valeur de l'identifiant TEID, utilisée par l'extrémité émettrice du tunnel pour transmettre des données ou de la signalisation dans ce tunnel à destination de l'extrémité réceptrice. Conformément à l'invention, pour les tunnels de communication GTP ayant comme extrémités réceptrices les passerelles de transfert de données SGW-D 15 (autrement dit pour les tunnels de communication établis en liaison montante entre les stations de base 14 et les passerelles de transfert de données SGW-D 15 gérées par le dispositif de contrôle 16, et pour les tunnels de communication établis en liaison descendante entre la passerelle d'interconnexion 13 et les passerelles de transfert de données SGW-D 15), c'est l'entité SGW-C 17 qui est configurée pour allouer à chaque tunnel GTP une unique valeur d'identifiant TEID. Par unique, on entend que cette valeur est invariante tout au long de la session de communication du terminal. Autrement dit, l'entité SGW-C 17 alloue une seule valeur de TEID pour le trafic en liaison montante échangé lors d'une session de communication entre une station de base 14 et une passerelle SGW-D 15 sur l'interface S1-U, et une seule valeur de TEID pour le trafic en liaison descendante échangé lors d'une session de communication entre la passerelle P-GW 13 et une passerelle SGW-D 15 sur l'interface S5-U. En d'autres termes, dans le mode de réalisation décrit ici, cette valeur d'identifiant TEID ne change pas (i.e. elle est invariante) si la session de communication est transférée d'une passerelle de transfert de données SGW-D 15 à une autre, par exemple en raison d'une défaillance ou d'une surcharge de la passerelle de transfert de données initialement considérée pour la session. Par ailleurs, conformément à l'invention, c'est également l'entité SGW-C 17 qui a pour fonction de sélectionner, pour chaque session de communication d'un terminal utilisateur et sur requête du dispositif de contrôle 16 via l'interface de programmation API17, la passerelle de transfert de données parmi les passerelles de transfert de données SGW-D 15 et la passerelle d'interconnexion 13 qui sont utilisées pour le transfert des données entre le terminal utilisateur et les réseaux PDN externes 12. Dans le mode de réalisation décrit, l'entité SGW-C 17 est configurée pour réaliser cette sélection en prenant en compte l'état courant de la charge des passerelles de transfert de données SGW-D 15. A cet effet, elle utilise des informations représentatives de la charge courante des passerelles de transfert de données S-GW-15 fournies par le dispositif de contrôle 16. Ces informations sont obtenues par le dispositif de contrôle 16 à partir de statistiques de charge périodiques établies à l'aide du protocole OpenFlow mis en oeuvre entre le dispositif de contrôle 16 et les passerelles de transfert de données SGW-D 15. L'obtention en soi de telles statistiques à l'aide du protocole OpenFlow, via le positionnement de compteurs idoines par le dispositif de contrôle 16 au niveau de chaque passerelle de transfert de données SGW-D, ne pose pas de difficultés à l'homme du métier et n'est donc pas décrit plus en détail ici. Le dispositif de contrôle 16 peut ensuite exploiter aisément les statistiques de charge ainsi obtenues en les comparant aux capacités des passerelles de transfert de données SGW-D et à la qualité de service requise pour la session de communication (représentées par exemple sous forme de quantités ou de seuils prédéterminées), de sorte à évaluer l'état courant de la charge de ces passerelles de transfert de données et mettre en oeuvre avec l'entité SGW-C 17 des algorithmes performants d'équilibre de la charge entre les différentes passerelles de transfert de données 15. De tels algorithmes d'équilibre de charge sont connus de l'homme du métier et non détaillés ici.

Il convient de noter, que grâce à cette architecture et à cette configuration du dispositif de contrôle 16 et de l'entité logicielle SGW-C 17, les situations de défaillance ou de surcharge d'une passerelle de transfert de données SGW-D active pour une session de communication d'un terminal évoquées précédemment peuvent être gérées de manière transparente pour l'utilisateur de ce terminal.

En effet, lorsque le dispositif de contrôle 16 déclenche la sélection par l'entité SGW-C 17 d'une nouvelle passerelle de transfert de données SGW-D 15 pour servir une session de communication courante, et reçoit de l'entité SGW-C 17 les paramètres de communication destinés à être utilisés par cette passerelle de transfert de données nouvellement sélectionnée et par les stations de base communiquant avec cette passerelle, il n'a qu'à définir des règles de traitement reflétant ces paramètres de communication. Ceci peut être réalisé via la mise à jour de règles de traitement existantes précédemment définies et/ou la création de nouvelles règles de traitement. Ces règles de traitement sont ensuite transmises aux équipements concernés afin d'être stockées dans les tables de flux correspondantes et appliquées pour le traitement des paquets de données reçus par ces équipements. Ainsi l'invention ne nécessite pas de signalisation importante pour permettre le transfert d'une session de communication entre deux passerelles de transfert de données SGW-D du coeur de réseau 10. Nous allons maintenant illustrer plus en détails la gestion opérée par le coeur de réseau 10 d'une session de communication du terminal utilisateur UE 11 grâce à cette nouvelle architecture. Plus particulièrement, trois procédures sont décrites en référence respectivement aux figures 7 à 9, à savoir : - une procédure d'attachement du terminal 11 au coeur de réseau 10, - une procédure d'établissement d'un plan de données en liaison montante et en liaison descendante entre une station de base 14 utilisée par le terminal 11 pour communiquer avec le coeur de réseau 10 et une passerelle d'interconnexion 13 connectée aux réseaux externes PDN 12, et - une procédure de restauration transparente mise en oeuvre suite à la détection d'une défaillance de la passerelle de transfert de données S-GW-15 courante utilisée pour la session de communication. Ces trois procédures reprennent les principales étapes des procédés de contrôle et de sélection selon l'invention dans un mode particulier de réalisation.

La procédure d'attachement illustrée à la figure 7 permet au terminal UE 11 de s'enregistrer auprès du coeur de réseau 10, par exemple suite à la mise sous tension du terminal 11. A cet effet, le terminal 11 envoie une requête d'attachement « ATTACH REQUEST » à la station de base 14A (étape F10). La station de base 14A traduit cette requête en un message OpenFlow « PACKET-IN » et le transfère vers le dispositif de contrôle 16 (étape F20). Le dispositif de contrôle 16 transfère le message OpenFlow reçu vers l'entité de gestion de mobilité 18, via l'interface de programmation API18, pour déclencher une authentification du terminal 11 (en vue de vérifier que le terminal 11 est bien autorisé à accéder aux services gérés par le coeur de réseau 10 et offerts par les réseaux PDN 12). Cette authentification est réalisée par l'entité de gestion de mobilité 18 en interrogeant le serveur HSS du coeur de réseau 10 de façon connue en soi. Elle s'appuie sur la mise en oeuvre d'un échange avec le terminal 11 via le dispositif de contrôle 16 (étape F30).

Il convient de noter que le protocole OpenFlow, dans sa définition actuelle, ne prévoit pas de messages pour gérer l'authentification d'un terminal et doit donc être adapté de façon idoine pour couvrir cette authentification. Une telle adaptation ne présente pas de difficulté pour l'homme du métier et n'est donc pas décrite davantage ici. Si le terminal 11 est authentifié avec succès, le dispositif de contrôle 16 déclenche la sélection par l'entité SGW-C 17 : - d'une passerelle de transfert de données SGW-D parmi les passerelles de transfert de données commandées par le dispositif de contrôle 16 (autrement dit ici, parmi les passerelles de transfert de données 15A, 15B et 15C) ; et - d'une passerelle d'interconnexion au réseau PDN (ici, la passerelle d'interconnexion 13) ; pour le transfert des données échangées lors de la session de communication du terminal 11 (étape F40). Dans le mode de réalisation décrit ici, la sélection de la passerelle SGW-D est réalisée par l'entité SGW-C 17 via un module de sélection logiciel, à partir d'informations représentatives d'une charge courante de chacune des passerelles SGW-D 15 du coeur de réseau 10 commandées par le dispositif de contrôle 16. Ces informations de charge sont communiquées par le dispositif de contrôle 16 à l'entité SGW-C 17, via l'interface de programmation API17, et dérivées d'informations statistiques de charge collectées par le dispositif de contrôle 16, par l'intermédiaire d'un module d'obtention d'informations statistiques, auprès des passerelles de transfert de données SGW-D 15 via le protocole OpenFlow, comme mentionné précédemment. On suppose ici que la passerelle de transfert de données SGW-D 15A est sélectionnée par l'entité SGW-C 17. L'entité SGW-C 17 alloue à ce stade une valeur V1 d'identifiant TEID de point d'extrémité de tunnel, pour une session de communication du terminal 11, pour le trafic en liaison descendante sur l'interface entre la passerelle d'interconnexion 13 et la passerelle de transfert de données SGW-D 15A. Cette valeur V1 permet l'identification de la terminaison de ce tunnel au niveau de cette passerelle de transfert de données SGW-D 15A. L'entité SGW-C 17 alloue également une valeur V4 d'identifiant TEID de point d'extrémité de tunnel, pour une session de communication du terminal 11, pour le trafic en liaison montante sur l'interface entre la station de base 14A et la passerelle de transfert de données SGW- D 15A. Cette valeur V4 permet l'identification de la terminaison de ce tunnel au niveau de cette passerelle de transfert de données SGW-D 15A. Puis, l'entité SGW-C 17 crée une nouvelle entrée dans une table de flux FTAB17 associée au terminal 11 et stockée par exemple dans une mémoire non volatile (ex. dans la mémoire 23 du dispositif informatique 19). La table FTAB17 est similaire ou identique aux tables FTAB décrites précédemment en référence à la figure 4. Cette nouvelle entrée comprend l'adresse IP de la passerelle de transfert de données S-GW 15A sélectionnée par l'entité SGW-C 17, ainsi que la valeur V1 de TEID (paramètres de communication au sens de l'invention destinés à être utilisés lors de la session entre la passerelle d'interconnexion 13 et la passerelle de transfert de données SGW-D 15A dans le plan de données). L'entité SGW-C 17 fournit ensuite ces paramètres de communication à la passerelle d'interconnexion 13 en lui envoyant une requête de création de session (message « Create Session Request ») comprenant l'adresse IP de la passerelle de transfert de données SGW-D 15A et la valeur V1 (étape F50). Sur réception de cette requête, la passerelle d'interconnexion 13 crée à son tour une nouvelle entrée dans une table de flux maintenue en mémoire pour ce terminal 11 et cette session de communication, contenant les paramètres de communications transmis par l'entité SGW-C 17. La passerelle d'accès 13 alloue ensuite une valeur V2 d'identifiant TEID, cette valeur V2 permettant l'identification de la terminaison du tunnel au niveau de la passerelle d'accès 13 pour le trafic en sens montant, dans le plan de données, sur l'interface entre cette passerelle d'accès 13 et la passerelle de transfert de données SGW-D 15A (étape F55).

Puis elle envoie un message de réponse à l'entité SGW-C 17 (message « Creation Session Response »), incluant une adresse IP allouée au terminal 11, ainsi que cette valeur V2 d'identifiant TEID (étape F60). Sur réception de ce message, l'entité SGW-C 17 met à jour sa table de flux associée au terminal 11 avec les paramètres de communication obtenus de la passerelle P-GW 13 (adresse IP du terminal 11 et valeur V2) (étape F70). L'entité SGW-C 17 notifie alors au dispositif de contrôle 16, via l'interface de programmation API17, l'adresse IP et la qualité de service allouées au terminal 11. Le dispositif de contrôle 16 informe l'équipement de gestion de mobilité 18 de l'adresse IP allouée au terminal 11 via l'interface de programmation API18. Cette adresse IP allouée au terminal constitue un paramètre de communication au sens de l'invention destiné à être utilisé lors d'une session de communication entre la station de base 14A, la passerelle de transfert de données SGW-D 15A et la passerelle d'interconnexion 13 pour le transfert de données. L'équipement de gestion de mobilité 18 inclut cette adresse IP dans un message de réponse « Attach Response Message » et l'envoie au terminal 11 via le dispositif de contrôle 16 (i.e. via l'interface de programmation API18) et la station de base 14 (étape F80). Après avoir conclu avec succès cette procédure d'attachement, le terminal 11 est autorisé à accéder au coeur de réseau LTE/EPC 10 en utilisant à cet effet l'adresse IP allouée par le coeur de réseau 10.

Nous allons maintenant décrire, en référence à la figure 8, une procédure d'établissement d'un plan de données pour une session de communication du terminal 11, pouvant être mise en oeuvre suite à la procédure d'attachement précédemment décrite. Il convient de noter que l'établissement d'un tel plan de données peut résulter d'une session de communication initiée soit par le terminal 11, soit par le réseau (i.e. coeur de réseau 10 suite à un message reçu en provenance d'un réseau PDN 12). Session de communication initiée par le terminal 11 On suppose ainsi que le terminal 11 envoie un paquet de données « initial » à la station de base 14A. Sur réception de ce paquet, la station de base 14A vérifie les tables de flux associées au terminal 11 stockées dans sa mémoire (étape G10). Si aucune entrée des tables de flux ne coïncide avec l'entête du paquet et les champs définis dans ces tables, la station de base 14A envoie un message OpenFlow « PACKET-IN » au dispositif de contrôle 16. Ce message inclut l'entête du paquet initial ainsi qu'une valeur V3 d'identifiant TEID, allouée par la station de base 14A pour le trafic descendant destiné au terminal 11 dans le plan de données sur l'interface entre la station de base 14A et la passerelle SGW-D 15A sélectionnée précédemment pour ce terminal 11 (étape G20). En d'autres termes, cette valeur v3 identifie la terminaison du tunnel au niveau de la station de base 14A pour le trafic en sens descendant, dans le plan de données, sur l'interface entre cette station de base 14A et la passerelle de transfert de données SGW-D 15A. Le dispositif de contrôle 16 vérifie l'entête du paquet pour identifier l'adresse source à l'origine de ce paquet et le type de session correspondant (ex. transfert FTP, voix sur IP, etc.) (étape G30). A partir de l'adresse IP source du paquet (i.e. ici l'adresse IP du terminal 11 allouée lors de la procédure d'attachement précédemment décrite), le dispositif de contrôle 16 interroge l'entité SGW-C 17 pour obtenir l'adresse IP de la passerelle SGW-D 15A sélectionnée précédemment pour le terminal 11, stockée dans la table FTAB17. Le dispositif de contrôle 16 récupère également auprès de l'entité SGW-C 17 les valeurs V1,V2 et V4 allouées précédemment lors de l'attachement du terminal 11. L'identification du type de session associée au paquet permet au dispositif de contrôle 16 de s'assurer que la passerelle SGW-D 15A sélectionnée lors de la procédure d'attachement permet d'offrir au terminal 11 la qualité de service requise pour cette session. Si par exemple, le paquet correspond à une session de type voix sur IP et le dispositif de contrôle 16 détecte que la passerelle de transfert de données 15A sélectionnée est surchargée, il peut décider de déclencher la sélection d'une nouvelle passerelle de transfert de données SGW-D par l'entité SGW-C 17 comme décrit précédemment.

Le dispositif de contrôle 16 crée ensuite un message OpenFlow « PACKET-OUT » et l'envoie à la station de base 14A (étape G40). Ce message contient une règle de traitement du paquet de données reçu par la station 14A (première règle au sens de l'invention), indiquant le traitement destiné à être appliqué par cette station sur ce paquet (et sur les paquets suivants associés au même flux). Cette règle de traitement est ici une règle de transfert qui indique à la station de base 14A vers quelle passerelle de transfert de données transférer ce paquet, autrement dit qui commande la station de base 14A de sorte que celle-ci transfère le paquet de données reçu vers la passerelle de transfert de données SGW-D 15A. A cet effet, la règle de traitement transmise par le dispositif de contrôle 16 comprend les paramètres de communication obtenus de l'entité SGW-C 17 par le dispositif de contrôle 16, et destinés à être utilisés lors de la session de communication en liaison montante entre la station de base 14A et la passerelle de transfert de données SGW-D 15A. Ces paramètres de communication comprennent l'adresse IP de la passerelle de transfert de données 15A, et la valeur V4 d'identifiant TEID associée au tunnel de communication sur l'interface destinée à être établie entre la station de base 14A et la passerelle SGW-D 15A pour l'échange de données en liaison montante. La station de base 14A dispose alors des valeurs V3 et V4 identifiant les extrémités du tunnel de communication destiné à être établi sur l'interface entre la passerelle SGW-D 15A et la station de base 14A.

De façon similaire, le dispositif de contrôle 16 crée un message OpenFlow « PACKETOUT » et l'envoie à la passerelle SGW-D 15A (étape G50). Ce message contient une règle de traitement du paquet initial (reçu par la station de base 14A et destiné à être transféré à la passerelle SGW-D 15A selon la première règle de traitement) indiquant le traitement destiné à être appliqué par la passerelle de transfert de données 15A sur ce paquet (et sur les paquets suivants associés au même flux). Cette règle de traitement (deuxième règle au sens de l'invention) est ici une règle de transfert qui indique à la passerelle SGW-D 15A vers quelle passerelle d'interconnexion transférer ce paquet, autrement dit qui commande la passerelle de transfert de données 15A de sorte que celle-ci transfère le paquet de données initial vers la passerelle d'interconnexion 13. A cet effet, la règle de traitement transmise par le dispositif de contrôle 16 à la passerelle SGW-D 15A comprend les paramètres de communication obtenus de l'entité SGW-C 17 par le dispositif de contrôle 16, et destinés à être utilisés en liaison montante lors de la session de communication entre la passerelle SGW-D 15A et la passerelle d'interconnexion 13. Ces paramètres incluent l'adresse IP de la passerelle d'interconnexion 13, et les valeurs V1 et V2 d'identifiant TEID allouées aux extrémités du tunnel destiné à être établi sur l'interface entre la passerelle SGW-D 15A et la passerelle d'interconnexion 13. Dans le mode de réalisation décrit ici, le message OpenFlow « PACKET-OUT » contient également une règle de traitement destinée à être appliquée par la passerelle de transfert de données SGW-D 15A en liaison descendante sur le trafic destiné au terminal 11 associé à la session de communication. Cette règle de traitement est ici une règle de transfert qui indique à la passerelle de transfert de données 15A vers quelle station de base de base transférer les paquets relatifs à la session de communication et destinés au terminal 11. Autrement dit cette règle de traitement commande la passerelle SGW-D 15A de sorte que celle-ci transfère les paquets de données reçus vers la station de base 14A. A cet effet, cette règle de traitement comprend les paramètres de communication obtenus par le dispositif de contrôle 16 et destinés à être utilisés en liaison descendante entre la passerelle SGW-D 15A et la station de base 14A lors de la session de communication, à savoir l'adresse IP de la station de base 14A et les valeurs V3 et V4 d'identifiant TEID d'identifiant TEID allouées aux extrémités du tunnel destiné à être établi sur l'interface entre la passerelle SGW-D 15A et la station de base 14A. A l'issue de cette procédure, un premier tunnel de communication, typiquement GTP- U, est établi en liaisons montante et descendante pour l'interface (par exemple de type S1-U) entre la station de base 14A et la passerelle de transfert de données SGW-D 15A, les valeurs V3,V4 d'identifiant TEID étant insérées dans les paquets GTP transmis dans ce premier tunnel. En outre, un deuxième tunnel de communication, typiquement GTP-U, est établi en liaisons montante et descendante pour l'interface (par exemple de type S5-U) entre la passerelle de transfert de données SGW-D 15A et la passerelle d'interconnexion 13 (étape G60), les valeurs V1,V2 d'identifiant TEID étant insérées dans les paquets GTP transmis dans ce deuxième tunnel. Session de communication initiée par le coeur de réseau 10 (non représentée sur la figure 8) On suppose ici que l'établissement du plan de données est déclenché par l'arrivée d'un paquet de données « initial » destiné au terminal 11 au niveau de la passerelle d'interconnexion 13 du coeur de réseau 10. A partir de la table de flux FTAB13 associée au terminal 11 maintenue par la passerelle d'interconnexion 13 suite à la procédure d'attachement du terminal 11, la passerelle d'interconnexion 13 détermine que ce paquet doit être envoyé à la passerelle de transfert de données SGW-D 15A (vers l'adresse IP spécifiée dans la table). Sur réception de ce paquet, la passerelle de transfert de données SGW-D 15A consulte les tables de flux FTAB15 stockées dans sa mémoire volatile pour identifier si une entrée coïncide avec l'entête du paquet reçu pour le terminal 11.

Si ce n'est pas le cas, la passerelle de transfert de données SGW-D 15A envoie un message OpenFlow PACKET-IN au dispositif de contrôle 16. Le dispositif de contrôle 16 détermine la localisation du terminal 11 en interrogeant l'entité de gestion de mobilité 18 via l'interface de programmation API18, et identifie une station de base 14 appropriée pour transmettre le paquet destiné au terminal 11. En l'espèce ici, on suppose que c'est la station de base 14A qui est identifiée. Le dispositif de contrôle 16 envoie à la station de base 14A un message OpenFlow PACKET-OUT comprenant une règle de traitement (première règle de traitement au sens de l'invention) destinée à être appliquée par celle-ci sur réception de paquets de données du terminal 11 relatifs à la session de communication en cours.

Cette règle de traitement comprend l'adresse IP de la passerelle de transfert de données SGW-D 15A ainsi que la valeur V4 d'identifiant TEID allouée par l'entité SGW-C 17 à la passerelle SGW-D 15A pour le trafic montant de ce terminal 11 dans le plan de données, sur l'interface entre cette station de base 14A et la passerelle de transfert de données SGW-D 15A. La station de base 14A établit le canal radio avec le terminal 11, et répond au dispositif de contrôle 16 en lui envoyant un message OpenFlow contenant la valeur V3 de l'identifiant TEID alloué par la station de base 14A pour le trafic descendant destiné au terminal 11 dans le plan de données, toujours sur l'interface entre cette station de base 14A et la passerelle de transfert de données SGW-D 15A. Il convient de noter que le protocole OpenFlow dans sa version actuelle n'inclut pas de message permettant à la station de base 14A d'envoyer la valeur V3 au dispositif de contrôle 16 et doit être adapté de façon idoine. Cette adaptation ne présente aucune difficulté pour l'homme du métier.

Sur réception de ce message, le dispositif de contrôle 16 envoie une règle de traitement (deuxième règle de traitement au sens de l'invention) à la passerelle de transfert de données SGW-D 15A contenant l'adresse IP de la station de base 14A et les valeurs V3 et V4 de TEID. Ces paramètres sont des paramètres de communication destinés à être utilisés pour transférer le trafic en liaison descendante entre la passerelle SGW-D 15A et la station de base 14A lors de la session de communication. Nous allons maintenant décrire en référence à la figure 9 une procédure de restauration pouvant avantageusement être mise en oeuvre par le coeur de réseau 10 grâce à l'architecture proposée par l'invention, en cas de défaillance d'une passerelle de transfert de données SGW-D impliquée dans la session de communication du terminal 11. Une procédure similaire peut également être utilisée lorsque le dispositif de contrôle 16 détecte une surcharge d'une passerelle de transfert de données SGW-D impliquée dans la session de communication du terminal 11.

Pour illustrer cette procédure, on se place ici à l'issue de la procédure d'établissement d'un plan de données (étape G60) décrite précédemment en référence à la figure 8. Ce plan de données s'appuie ainsi sur deux tunnels bidirectionnels GTP-U établis respectivement entre la station de base 14A et la passerelle de transfert de données SGW-D 15A, et entre la passerelle de transfert de données SGW-D 15A et la passerelle d'interconnexion 13 pour la session de communication en cours du terminal 11. On suppose maintenant que la passerelle de transfert de données SGW-D 15A connaît une défaillance (étape H10). Le dispositif de contrôle 16 dispose d'un module logiciel apte à détecter, en utilisant le protocole OpenFlow, une défaillance d'une des passerelles de transfert de données SGW-D 15 qu'il commande. Plus précisément, conformément à ce protocole, le dispositif de contrôle 16 et les passerelles de transfert de données SGW-D 15 s'échangent périodiquement des messages de type « Echo Request/Reply ». La détection de l'absence de réponse de la passerelle de transfert de données SGW-D 15A à un tel message permet au dispositif de contrôle 16 d'identifier qu'un problème affecte cette passerelle (étape H20).

Sur détection de cette défaillance, le dispositif de contrôle 16 déclenche, par l'intermédiaire de l'interface de programmation API17, la sélection par l'entité SGW-C 17 d'une nouvelle passerelle de transfert de données pour la session de communication du terminal 11 (et pour chaque session de communication de manière plus générale impactées par cette défaillance), comme décrit précédemment pour la passerelle SGW-D 15A en prenant en compte la charge courante des passerelles de transfert de données SGW-D 15. On suppose par exemple que la passerelle SGW-D 15B est ainsi sélectionnée. L'entité SGW-C 17 envoie un message « Modify Bearer Request » à la passerelle d'interconnexion 13 pour l'informer de cette nouvelle sélection (via une interface « E/W Bound » telle que décrite en référence à la figure 3) (étape H30). Ce message comprend l'adresse IP de la nouvelle passerelle de transfert de données SGW-D 15B. La valeur V1 d'identifiant TEID du tunnel GTP-U pour la liaison descendante reste invariante malgré le changement de passerelle de transfert de données pour chaque session de communication.

La passerelle d'interconnexion 13 met à jour la table FTAB13 associée au terminal 11 et à la session de communication avec l'adresse IP de la passerelle SGW-D 15B et envoie un message « Modify Bearer Response » à l'entité SGW-C 17 (étape H40). Le dispositif de contrôle 16 envoie ensuite, par le biais de son module de contrôle 16A, un message OpenFlow « MODIFY-STATE » à la station de base 14A pour mettre à jour l'adresse de la passerelle de transfert de données SGW-D associée à la session de communication du terminal 11 dans la table FTAB14. Ce message constitue une mise à jour par le module 16A du dispositif de contrôle 16 de la règle de traitement appliquée par la station de base 14A et contient de nouveaux paramètres de communication (en l'occurrence, l'adresse IP de la passerelle de transfert de données SGW-D 15B) obtenus de l'entité SGW-C 17 et destinés à être utilisés entre la station de base 14A et la passerelle de transfert de données SGW-D 15B lors de la session de communication. En revanche, la valeur V4 d'identifiant TEID de tunnel destinée à être par la station de base 14A pour la liaison montante sur l'interface avec la nouvelle passerelle de transfert de données SGW-D 15B reste inchangée. Par ailleurs, la station de base 14A ne changeant pas, la valeur V3 reste inchangée.

Autrement dit, l'invention, en centralisant au niveau de l'entité SGW-C 17 l'allocation des identifiants TEID pour les tunnels de communication du plan de données établis avec les passerelles de transfert de données SGW-D 15, permet de s'affranchir de l'allocation de nouveaux identifiants TEID lorsque la passerelle de transfert de données active change et de la communication de ces nouveaux identifiants aux équipements du réseau amenés à établir un tunnel avec cette passerelle de transfert de données. La signalisation requise pour notifier le changement de passerelle de transfert de données est ainsi avantageusement limitée : seule l'adresse IP de la nouvelle passerelle de transfert de données nécessite d'être notifiée par le dispositif de contrôle 16. Le dispositif de contrôle 16 envoie ensuite, par l'intermédiaire de son module de contrôle 16B, un message OpenFlow « PACKET-OUT » à la nouvelle passerelle de transfert de données SGW-D 15B, contenant une règle de traitement (troisième règle de traitement au sens de l'invention) destinée à être appliquée par la passerelle de transfert de données SGW-D 15B en liaison montante sur réception de données relatives à la session de communication du terminal 11 (étape H60).

Cette règle de traitement est ici une règle de transfert qui indique à la passerelle de transfert de données SGW-D 15B vers quelle passerelle d'interconnexion transférer les paquets relatifs à la session de communication et reçus du terminal 11. Autrement dit cette règle de traitement commande la passerelle de transfert de données SGW-D 15B de sorte que celle-ci transfère les paquets de données reçus vers la passerelle d'interconnexion 13. Cette règle de traitement comprend des paramètres de communication obtenus de l'entité SGW-C 17 destinés à être utilisés en liaison montante entre la passerelle de transfert de données SGW-D 15B et la passerelle d'interconnexion 13 lors de la session de communication. Ces paramètres de communication incluent notamment l'adresse IP de la passerelle d'interconnexion 13, et la valeur V2 de TEID allouée par la passerelle d'interconnexion 13 à la session du terminal 11. Ils sont mémorisés dans une table de flux FTAB15 stockés par la passerelle de transfert de données SGW-D 15B en association avec la session de communication du terminal 11.

Le message « PACKET-OUT » comprend en outre une autre règle de traitement destinée à être appliquée par la passerelle de transfert de données SGW-D 15B en liaison descendante sur le trafic destiné au terminal 11 associé à la session de communication. Cette règle de traitement est ici une règle de transfert qui indique à la passerelle de transfert de données SGW-D 15B vers quelle station de base transférer les paquets relatifs à la session de communication et destinés au terminal 11. Autrement dit cette règle de traitement commande la passerelle de transfert de données SGW-D 15B de sorte que celle-ci transfère les paquets de données reçus vers la station de base 14A. A cet effet, cette règle de traitement comprend les paramètres de communication obtenus par le dispositif de contrôle 16 et destinés à être utilisés en liaison descendante entre la passerelle de transfert de données SGW-D 15B et la station de base 14A lors de la session de communication, à savoir l'adresse IP de la station de base 14A et la valeur V3 d'identifiant TEID. A l'issue de cette procédure, un tunnel de communication GTP-U est établi en liaisons montante et descendante pour l'interface (typiquement de type S1-U) entre la station de base 14A et la nouvelle passerelle de transfert de données SGW-D 15B, et un tunnel de communication GTP- U est établi en liaisons montante et descendante pour l'interface (typiquement de type S5-U) entre cette nouvelle passerelle de transfert de données SGW-D 15B et la passerelle d'interconnexion 13 (étape H70). Comme mentionné précédemment, cette procédure peut être aisément appliquée pour gérer également une situation de surcharge de la passerelle de transfert de données SGW-D 15A.

Une telle situation peut être détectée par le dispositif de contrôle 16 à partir des statistiques de charge qu'il collecte en temps réel à l'aide du protocole OpenFlow auprès des passerelles de transfert de données SGW-D 15 qu'il gère. Grâce à la connaissance en temps réel de ces statistiques, le dispositif de contrôle 16 peut déclencher un changement de passerelle de transfert de données SGW-D selon la procédure décrite en référence à la figure 9, afin d'équilibrer la charge résultant des sessions de communication actives des terminaux sur les différentes passerelles de transfert de données SGWD 15. A cette fin, des algorithmes de répartition ou d'équilibre de la charge connus en soi (algorithmes de « load balancing ») peuvent être utilisés par le dispositif de contrôle 16 pour permettre à l'entité SGW-C 7 de sélectionner une nouvelle passerelle de transfert de données pour la session du terminal 11. Le transfert d'une passerelle de transfert de données à une autre de la session de communication est alors mis en oeuvre de manière similaire à celle décrite en référence à la figure 9, autrement dit de façon transparente pour la connectivité IP de l'utilisateur.

Claims (21)

1. REVENDICATIONS1. Dispositif de contrôle (16) d'un coeur de réseau IP (10) comprenant : un module de communication apte à communiquer avec une entité de contrôle de transfert de données (17) du coeur de réseau IP, et configuré pour déclencher la sélection par l'entité de contrôle de transfert de données d'une passerelle de transfert de données (15A) du coeur de réseau IP, le module de communication étant en outre configuré pour obtenir de l'entité de contrôle de transfert de données des paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal (11), connecté à une station de base (14A) d'un réseau d'accès, et une passerelle d'interconnexion (13) du coeur de réseau IP connecté à un réseau de paquets de données (12), ladite session de communication transitant par la station de base et la passerelle de transfert de données ; un premier module de contrôle (16A) de la station de base au moyen d'une première règle de traitement destinée à être appliquée par ladite station de base suite à la réception de données relatives à la session de communication, la première règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la passerelle de transfert de données (15A) ; et un deuxième module de contrôle (16B) de la passerelle de transfert de données au moyen d'une deuxième règle de traitement destinée à être appliquée par ladite passerelle de transfert de données suite à la réception de données relatives à la session de communication, la deuxième règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13).
2. 2. Dispositif de contrôle (16) selon la revendication 1 dans lequel le module de communication communique avec l'entité de contrôle de transfert de données par l'intermédiaire d'une interface de programmation (API17).
3. 3. Dispositif de contrôle (16) selon la revendication 1 ou 2 dans lequel : les paramètres de communication de la première règle comprennent une adresse de la passerelle de transfert de données (15A) et un identifiant de point d'extrémité d'un tunnel de communication établi entre la passerelle de transfert de données et la station de base pour le transfert des données, alloué par l'entité de contrôle de transfert de données ; et/ou les paramètres de communication de la deuxième règle comprennent une adresse de la passerelle d'interconnexion (13) et un identifiant de point d'extrémité d'un tunnel de communication établi entre la passerelle de transfert de données et la passerelled'interconnexion pour le transfert des données, alloué par l'entité de contrôle de transfert de données.
4. 4. Dispositif de contrôle (16) selon l'une quelconque des revendications 1 à 3 dans lequel le premier module de contrôle (16A) et le deuxième module de contrôle (16B) sont configurés pour communiquer respectivement avec la station de base et avec la passerelle de transfert de données par l'intermédiaire du protocole OpenFlow.
5. 5. Dispositif de contrôle (16) selon l'une quelconque des revendications 1 à 4 dans lequel le module de communication est en outre configuré pour déclencher, par l'intermédiaire d'une interface de programmation (API18), sur réception d'une requête d'attachement du terminal au coeur de réseau IP, une authentification du terminal par une entité (18) de gestion de la mobilité appartenant au coeur de réseau IP.
6. 6. Dispositif de contrôle selon l'une quelconque des revendications 1 à 5 comprenant en outre un module d'obtention d'informations représentatives d'une charge courante d'au moins une passerelle de transfert de données du coeur de réseau IP connectée au dispositif de contrôle, le module de communication étant en outre configuré pour fournir lesdites informations à l'entité de contrôle de transfert de données, via une interface de programmation (API17).
7. 7. Dispositif de contrôle selon l'une quelconque des revendications 1 à 6 comprenant en outre un module de détection d'une défaillance ou d'une surcharge de la passerelle de transfert de données, le module de communication étant en outre configuré pour informer l'entité de contrôle de transfert de données de ladite défaillance ou de ladite surcharge et pour déclencher la sélection par l'entité de contrôle de transfert de données d'une nouvelle passerelle de transfert de données (15B) pour la session de communication, et dans lequel : - le premier module de contrôle est configuré pour mettre à jour la première règle de traitement appliquée par la station de base avec des paramètres de communication, obtenus de l'entité de contrôle de transfert de données par le module de communication du dispositif de contrôle et destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la nouvelle passerelle de transfert de données (15B) ; et - le deuxième module de contrôle est configuré pour contrôler la nouvelle passerelle de transfert de données (15B) à l'aide d'une troisième règle de traitement destinée à être appliquée par ladite nouvelle passerelle de transfert de données suite à la réception de données relatives à la session de communication, la troisième règle comprenant des paramètres de communication, obtenus de l'entité de contrôle de transfert de données par le module de communication du dispositif de contrôle et destinés à être utilisés lors de la session de communication pour letransfert de données entre la nouvelle passerelle de transfert de données (15B) et la passerelle d'interconnexion (13).
8. 8. Dispositif de contrôle selon la revendication 7, dans lequel la première règle de traitement est mise à jour avec une adresse de la nouvelle passerelle de transfert de données (15B).
9. 9. Dispositif de contrôle selon la revendication 7, dans lequel les paramètres de communication de la deuxième règle de traitement et de la troisième règle de traitement comprennent un même identifiant de point d'extrémité de tunnel, alloué par l'entité de contrôle de transfert de données et destiné à être utilisé entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13), et entre la nouvelle passerelle de transfert de données (15B) et la passerelle d'interconnexion (13).
10. 10. Entité de contrôle de transfert de données (17) d'un coeur de réseau IP (10) comprenant : un module de communication apte à communiquer avec un dispositif de contrôle (16) du coeur de réseau IP selon l'une quelconque des revendications 1 à 9 ; un module de sélection, déclenché par le dispositif de contrôle (16) via le module de 20 communication, et configuré pour sélectionner une passerelle de transfert de données (15A) du coeur de réseau IP ; un module d'obtention de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal (11), connecté à une station de base (14A) d'un réseau d'accès, et une passerelle d'interconnexion (13) du coeur de réseau IP connectée à un 25 réseau de paquets de données (12), ladite session de communication transitant par la station de base et la passerelle de transfert de données ; un module de fourniture à la passerelle d'interconnexion de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données (15A) 30 et la passerelle d'interconnexion (13) ; le module de communication étant configuré pour fournir au dispositif de contrôle des paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la passerelle de transfert de données (15A). 35
11. 11. Entité selon la revendication 10, dans laquelle le module d'obtention de paramètres de communication est configuré pour allouer à la session de communication un identifiant de point d'extrémité d'un tunnel de communication entre la passerelle de transfert dedonnées (15A) et la station de base (14A) et un identifiant de point d'extrémité d'un tunnel de communication entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13).
12. 12. Entité selon la revendication 11, dans laquelle les identifiants alloués par l'entité à la session de communication sont invariants durant la session de communication.
13. 13. Entité selon l'une quelconque des revendication 10 à 12 dans laquelle le module de sélection est configuré pour sélectionner la passerelle de transfert de données (15A) parmi une pluralité de passerelles de transfert de données (15A,15B,15C) contrôlées par le dispositif de contrôle en utilisant des informations représentatives d'une charge courante desdites passerelles de transfert de données fournies par le dispositif de contrôle via une interface de programmation.
14. 14. Entité selon l'une quelconque des revendications 10 à 13 dans laquelle : le module de sélection est configuré pour sélectionner une nouvelle passerelle de transfert de données (15B) pour la session de communication du terminal lorsqu'il est informé par le dispositif de contrôle, via une interface de programmation, d'une défaillance ou d'une surcharge de la passerelle de transfert de données (15A) ; le module de fourniture et le module de communication sont configurés pour fournir respectivement à la passerelle d'interconnexion (13) et au dispositif de contrôle (16) ladite adresse de la nouvelle passerelle de transfert de données (15B).
15. 15. Coeur de réseau IP (10) comprenant : une pluralité de passerelles de transfert de données (15A,15B,15C) ; un dispositif de contrôle (16) selon l'une quelconque des revendications 1 à 9, apte à contrôler au moins une station de base (14A) d'un réseau d'accès auquel est connecté un terminal et la pluralité de passerelles de transfert de données ; et une entité de contrôle de transfert de données (17) selon l'une quelconque des revendications 10 à 14, apte à communiquer avec le dispositif de contrôle, et à sélectionner une passerelle de transfert de données (15A) parmi la pluralité de passerelles de transfert de données contrôlées par le dispositif de contrôle pour une session de communication du terminal.
16. 16. Coeur de réseau IP (10) selon la revendication 15, comprenant en outre une entité (18) de gestion de la mobilité configurée pour authentifier le terminal, ladite authentification étant déclenchée par le dispositif de contrôle via une interface de programmation.
17. 17. Procédé de contrôle destiné à être mis en oeuvre par un dispositif de contrôle (16) d'un coeur de réseau IP, et comprenant :une étape de communication avec une entité de contrôle de transfert de données (17) du coeur de réseau IP, comprenant un déclenchement d'une sélection (F40) par l'entité de contrôle de transfert de données d'une passerelle de transfert de données (15A) du coeur de réseau IP, et une obtention auprès de l'entité de contrôle de transfert de données de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal connecté à une station de base (14A) d'un réseau d'accès et une passerelle d'interconnexion (13) du coeur de réseau IP connectée à un réseau de paquets de données (12), ladite session de communication transitant par la station de base et la passerelle de transfert de données ; une étape de contrôle (G40) de la station de base au moyen d'une première règle de traitement destinée à être appliquée par ladite station de base suite à la réception de données relatives à la session de communication, la première règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la passerelle de transfert de données (15A) ; et une étape de contrôle (G50) de la passerelle de transfert de données au moyen d'une deuxième règle de traitement destinée à être appliquée par ladite passerelle de transfert de données suite à la réception de données relatives à la session de communication, la deuxième règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13).
18. 18. Procédé de sélection destiné à être mis en oeuvre par une entité de contrôle de transfert de données (17) d'un coeur de réseau IP, et comprenant : une étape de sélection (F40), déclenchée par un dispositif de contrôle (16) du coeur de réseau IP, d'une passerelle de transfert de données (15A) du coeur de réseau IP ; une étape d'obtention de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal (11) connecté à une station de base (14A) d'un réseau d'accès et une passerelle d'interconnexion (13) du coeur de réseau IP connectée à un réseau de paquets de données (12), ladite session de communication transitant par la station de base et la passerelle de transfert de données ; une étape de fourniture o à ladite passerelle d'interconnexion (50), de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13) ; eto au dispositif de contrôle (16), de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la passerelle de transfert de données (15A).
19. 19. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de contrôle selon la revendication 17 ou du procédé de sélection selon la revendication 18 lorsque ledit programme est exécuté par un ordinateur.
20. 20. 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 la revendication 17 ou du procédé de sélection selon la revendication 18.
21. 21. Station de base d'un réseau d'accès (14A), apte à servir un terminal (11) lors d'une session de communication, et comprenant : - des moyens de réception d'un dispositif de contrôle d'un coeur de réseau IP selon l'une quelconque des revendications 1 à 9 d'une règle de traitement destinée à être appliquée par la station de base suite à la réception de données relatives à ladite session de communication du terminal, la règle de traitement comprenant des paramètres de communication destinés à être utilisés lors de ladite session de communication pour le transfert de données entre la station de base et une passerelle de transfert de données (15A) du coeur de réseau IP ; et - des moyens d'application de cette règle de traitement à des données relatives à ladite session de communication.