FR3131815A1 - Procédé, dispositif et système de modification d’une infrastructure de communication - Google Patents

Procédé, dispositif et système de modification d’une infrastructure de communication Download PDF

Info

Publication number
FR3131815A1
FR3131815A1 FR2200222A FR2200222A FR3131815A1 FR 3131815 A1 FR3131815 A1 FR 3131815A1 FR 2200222 A FR2200222 A FR 2200222A FR 2200222 A FR2200222 A FR 2200222A FR 3131815 A1 FR3131815 A1 FR 3131815A1
Authority
FR
France
Prior art keywords
terminal
virtualized
function
term1
functions
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR2200222A
Other languages
English (en)
Inventor
Bruno Chatras
Antoine Mouquet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR2200222A priority Critical patent/FR3131815A1/fr
Priority to PCT/EP2023/050119 priority patent/WO2023135043A1/fr
Publication of FR3131815A1 publication Critical patent/FR3131815A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H04L41/0897—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H04L41/342—Signalling channels for network management communication between virtual entities, e.g. orchestrators, SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/32—Reselection being triggered by specific parameters by location or mobility data, e.g. speed data
    • H04W36/322—Reselection being triggered by specific parameters by location or mobility data, e.g. speed data by location data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Abstract

Procédé, dispositif et système de modification d’une infrastructure de communication L’invention concerne un procédé, un dispositif et un système de modification d’une infrastructure (Res) de communication apte à fournir un service de communication à un terminal (Term1, Term2) par l’intermédiaire d’une pluralité de fonctions virtualisées (VF1,…,VFn), ledit procédé étant mis en œuvre dans un dispositif de gestion de l’infrastructure (Res), et comprenant une réception d’une information relative à un attachement ou à un détachement dudit terminal (Term1, Term2) à une station d’accès (Acc1, Acc2, Acc3) de l’infrastructure (Res) de communication, ainsi que la détermination d’une adaptation de la pluralité de fonctions virtualisées (VF1,…,VFn) en fonction de la localisation de la station d’accès (Acc1, Acc2, Acc3) à laquelle le terminal (Term1, Term2) est attaché ou à la localisation du terminal (Term1, Term2). L’invention concerne en outre un procédé et dispositif d’adaptation permettant d’instancier la mise à jour de l’infrastructure de communication en fonction de l’adaptation déterminée par le dispositif de gestion. Figure pour l'abrégé : Fig. 1

Description

Procédé, dispositif et système de modification d’une infrastructure de communication
1. Domaine technique
L'invention vise à être mise en œuvre dans un réseau de communication acheminant des données en provenance ou à destination de terminaux aptes à être attachés à des points d’accès distincts du réseau de communication. L’invention décrit plus précisément un procédé, un dispositif et un système permettant de modifier un réseau composé de fonctions virtualisées en fonction de la localisation du terminal utilisateur ou du point d’accès auquel est attaché le terminal.
2. Etat de la technique
Les réseaux de communication, et notamment les réseaux de communication mobiles, intègrent des procédures permettant à leurs utilisateurs de rester joignables en situation de mobilité et d'assurer la continuité des communications qu'ils reçoivent et émettent tout en se déplaçant et en étant attachés à différents points d’accès d’un réseau de communication.
Il est par ailleurs admis que les réseaux mobiles de cinquième génération et des générations suivantes seront déployés en utilisant les techniques de virtualisation, consistant à ce que les différentes fonctions du réseau de communication requises pour l’enregistrement des terminaux, leur authentification et l’acheminement de leurs données seront mises en œuvre sous une forme virtualisée. Ainsi, les fonctions réseau d'un cœur de réseau 5G ainsi que certaines fonctions applicatives (AF) sous responsabilité de l'opérateur et accessibles depuis le cœur de réseau sont typiquement déployées sous forme de fonctions réseau virtualisées (VNF). Une fonction réseau virtualisée comprend un logiciel assurant la fourniture du service requis et s'exécutant dans une machine virtuelle ou un conteneur créé sur un serveur physique banalisé, c’est-à-dire non spécifique à la fonction mise à disposition. Ainsi, une infra de communication comprend une ou plusieurs fonctions virtualisées déployée(s) sur une infrastructure de virtualisation comprenant des serveurs physiques hébergeant lesdites fonctions virtualisées et des équipements interconnectant les serveurs physiques. L’infrastructure de virtualisation est typiquement constituée de pools de serveurs banalisés répartis géographiquement sur plusieurs sites, par exemple dans des centres de données (en anglais data centers) aussi appelés centres de calcul plus ou moins distants des terminaux utilisateurs.
La technologie NFV, développée par l’ETSI et utilisée pour déployer une infrastructure de communication s’appuyant sur une infrastructure de virtualisation, permet de créer et même déplacer une instance de fonction virtualisée au sein de l’infrastructure de virtualisation, et donc la ou les instances de fonctions réseau ou de fonctions applicatives correspondantes. La fonction virtualisée peut ainsi être par exemple déplacée d'un serveur à un autre, d'un centre de données à un autre, en fonction de divers critères d'optimisation tels que la charge des serveurs d'un centre de données ou la latence de communication induite par la position d'une fonction virtualisée ou d’une fonction applicative par rapport à celles des utilisateurs desservis. En effet, la position d’une fonction réseau ou d’une fonction applicative par rapport au terminal utilisateur qu'elle dessert influe de façon assez nette sur la latence de la session de données du terminal utilisateur, notamment dans le cas d'une fonction réseau ou applicative traitant les flux du plan utilisateur, c’est-à-dire les données utiles entre le terminal utilisateur et un autre terminal utilisateur ou un serveur de données. La localisation d’un serveur supportant une entité UPF (User Plane Function) d’un cœur de réseau 5G, une passerelle de transcodage vidéo, ou un serveur cache CDN (en anglais Content Delivery Network) intervient par exemple de façon significative sur la latence des données de terminaux utilisateurs utilisant l’une ou l’autre de ces fonctions.
L’art antérieur, et notamment les spécifications 3GPP pour les réseaux 5G, définit comment instancier de façon prédéfinie la répartition des fonctions UPFs sur un territoire et sélectionner ou resélectionner la mieux placée pour router un flux de trafic donné en provenance ou à destination d’un utilisateur. Il s’agit dans ce cas, de sélectionner, en fonction de la localisation d’un terminal utilisateur, une instance de fonction réseau ou applicative d’ores et déjà déployée. L'approche consistant à déployer plusieurs instances d'une même fonction réseau ou applicative, ces instances étant réparties géographiquement, n'est pas optimale lorsque ces fonctions sont dédiées à un utilisateur ou groupe d'utilisateurs et/ou lorsque le territoire sur lequel est déployé ces instances est très vaste mais la densité de population faible. Cette solution est d’autre part assez statique et ne permet pas de façon simple et non coûteuse de répondre aux besoins des terminaux utilisateurs se déplaçant et requérant néanmoins une bonne qualité de service et notamment un délai de latence suffisamment faible pour maintenir une bonne expérience utilisateur notamment ou pour respecter les besoins d’une application par exemple. Si l’on souhaite que les utilisateurs disposent d’une bonne qualité de service, il convient alors de déployer de nombreuses fonctions virtualisées de façon à pouvoir toujours disposer de telles fonctions quelle que soit la localisation de l’utilisateur, ce qui représente un coût important et une infrastructure plus complexe à gérer sur le plan technique.
La présente invention a pour objet d’apporter des améliorations par rapport à l’état de la technique.
3. Exposé de l'invention
L'invention vient améliorer la situation à l'aide d'un procédé de modification d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, ledit procédé étant mis en œuvre dans un dispositif de gestion de l’infrastructure, et comprenant
- une réception d’une information relative à un attachement ou à un détachement dudit terminal à une station d’accès de l’infrastructure de communication,
- la détermination d’une adaptation de la pluralité de fonctions virtualisées en fonction de la localisation de la station d’accès à laquelle le terminal est attaché ou à la localisation du terminal
Le procédé de modification est nouveau et inventif puisqu’il permet d’adapter une infrastructure de communication comprenant des fonctions virtualisées, qu’il s’agisse de fonctions réseaux ou fonctions applicatives, en fonction de la localisation d’un terminal.
L’infrastructure de communication est établie sur une infrastructure de virtualisation, comprenant notamment des serveurs physiques, et la modification de l’infrastructure de communication par l’adaptation des fonctions virtualisées comprend la mise à jour de l’infrastructure de virtualisation, telle que la création ou la suppression de machines virtuelles ou de conteneurs.
La localisation d’un terminal, notamment lorsque celui-ci se déplace ou bien s’attache à une nouvelle station d’accès tout en restant statique, peut requérir une modification d’une ou plusieurs fonctions virtualisées par exemple pour corriger une trop grande distance entre la localisation du terminal et la fonction virtualisée, ou bien encore pour adapter les capacités d’une fonction virtualisée qui doit supporter plus de trafic en raison d’un nombre de terminaux plus conséquent dans la zone géographique que la fonction dessert ou bien encore pour s’adapter aux capacités ou aux fonctions de la nouvelle station d’accès à laquelle est attaché le terminal. Ainsi en recevant une information sur la localisation du terminal par exemple par rapport à une localisation de la station d’accès, le dispositif de gestion détermine la mise à jour de la pluralité de fonctions virtualisées, par exemple par l’ajout et/ou la mise à jour d’une ou plusieurs fonctions virtualisées du réseau. Le dispositif de gestion peut recevoir l’information relative à l’attachement directement du terminal, ou bien de la station d’accès à laquelle le terminal s’attache ou bien encore d’un autre dispositif du réseau tel qu’un équipement de type MME (en anglais Mobility Management entity), AMF (en anglais Access and Mobility Management Function) ou bien encore NWDAF (en anglais Network Data Analytics Function).
Selon un aspect de l’invention, dans le procédé de modification, l’information relative à l’attachement fait suite à un changement de station d’accès de l’infrastructure de communication à laquelle le terminal est attaché.
Le procédé est notamment intéressant lorsque le terminal est en situation de mobilité et s’attache successivement à des stations d’accès distantes les unes des autres, par exemple mais pas uniquement, tout en ayant une session active. Il convient alors que des fonctions réseaux et/ou applicatives soient adaptées au changement de localisation du terminal pour que la session active maintienne le même niveau de qualité et de disponibilité.
Selon un autre aspect de l'invention, dans le procédé de modification, l’adaptation comprend au moins une des opérations parmi :
- un déploiement d’une fonction virtualisée dans l’infrastructure de communication
- un déplacement d’une fonction virtualisée dans l’infrastructure de communication,
- un retrait d’une fonction virtualisée dans l’infrastructure de communication,
- une modification d’une fonction virtualisée dans l’infrastructure de communication.
L’adaptation, ou mise à jour, peut se caractériser par une ou plusieurs opérations selon le type de terminal, selon la nouvelle station d’accès, selon les caractéristiques de la session de donnée possiblement en cours lors du changement de station d’accès et selon la fonction virtualisée à mettre à jour. Ainsi, une nouvelle fonction virtualisée peut être requise et ajoutée à la pluralité pour une adaptation fonctionnelle à la session ou au terminal ou pour assurer un acheminement en conformité avec le besoin de qualité de service. Une fonction virtualisée peut également être déplacée d’un centre de données à un autre, ce qui peut notamment se justifier lorsqu’un centre de données se trouve à proximité d’une station s’accès, par exemple dans les architectures MEC (en anglais Mobile Edge Computing). Une fonction virtualisée de la pluralité peut également être retirée si celle-ci n’est plus requise à la suite de l’attachement, ou au détachement ou bien encore une fonction virtualisée peut être modifiée pour s’adapter au volume de données reçues du terminal ou acheminées vers le terminal ou bien pour supporter un nouveau protocole ou une version de protocole par exemple. L’adaptation peut concerner une pluralité de fonctions virtualisées par exemple dans le cas où une session est établie suivant un chainage de fonctions virtualisées et la mise à jour peut être différente, conformément aux options ci-dessus indiquées, selon la fonction virtualisée considérée.
L’infrastructure de communication s’appuyant sur une infrastructure de virtualisation, le déploiement, le déplacement, le retrait ou la modification d’une fonction virtualisée dans l’infrastructure de communication comprend la mise à jour de l’infrastructure de virtualisation et le positionnement des fonctions virtualisées dans les serveurs physiques de l’infrastructure de virtualisation. Notamment, le déplacement d’une fonction virtualisée dans l’infrastructure de communication peut correspondre à un déplacement de fonction virtualisée d’un serveur à un autre de l’infrastructure de virtualisation.
Selon un autre aspect de l'invention, dans le procédé de modification, l’adaptation de la pluralité comprend l’ajout, et/ou le déplacement, et/ou le retrait et/ou la modification d’un composant d’au moins une fonction virtualisée de la pluralité.
Une fonction virtualisée peut avantageusement comprendre des composants distincts tels que des protocoles réseaux ou applicatifs, des fonctions relatives à la qualité de service, des fonctions d’administration et la mise à jour peut avantageusement être relative à la mise à jour d’un ou plusieurs de ces composants. La modification d’un composant comprend de façon non exhaustive la création, la suppression, la mise à jour et le déplacement d’une instance de composant dans une ou plusieurs fonctions virtualisées de la pluralité adaptées par une mise à jour d’un ou plusieurs composants. L’adaptation mise en œuvre à partir d’un composant comprend notamment des actions (ajout, déplacement, retrait, modification) portant sur un composant dans une fonction virtualisée ou une action portant sur un composant dans un serveur de l’infrastructure de virtualisation. Ainsi, le déplacement d’un composant comprend le déplacement d’un composant d’une fonction vers une autre fonction virtualisée possiblement dans un même serveur ou bien le déplacement d’un serveur à un autre serveur de l’infrastructure de virtualisation.
Selon un autre aspect de l'invention, le procédé de modification comprend au préalable une émission à destination d’un dispositif de gestion de la mobilité dudit terminal d’une requête de souscription à une information relative à un attachement à une station d’accès du terminal.
De façon à limiter les émissions d’information de localisation des terminaux reçus par le dispositif de gestion et ainsi pour éviter les surcharges du réseau de communication par des messages de signalisation, le procédé peut comprendre au préalable une souscription du dispositif de gestion aux informations relatives à l’attachement du terminal. La souscription peut être faite auprès de l’équipement (Station d’accès, AMF, MME, NWDAF) en charge d’émettre les messages relatifs à l’attachement d’un terminal ou bien auprès d’un équipement d’administration du réseau en charge de la configuration de ces équipements.
Selon un autre aspect de l'invention, le procédé de modification comprend en outre la comparaison d’un identifiant dudit terminal avec une liste d’identifiants de terminaux aptes à bénéficier du procédé de modification.
Le procédé peut être mis en œuvre pour un nombre limité de terminaux, par exemple en fonction de leur type, de leur abonnement, des services applicatifs qu’ils supportent, et le dispositif de gestion peut alors mettre en œuvre le procédé seulement si le terminal concerné par le message d’attachement est dans la liste de terminaux concernés. La liste de terminaux peut être maintenue par le dispositif de gestion ou bien par un autre dispositif, par exemple de type UDM (en anglais Unified Data Management), qui peut interagir avec le dispositif de gestion. Cette liste peut être avantageusement négociée avec l’émetteur des messages relatifs à l’attachement du terminal.
Selon un autre aspect de l'invention, le procédé de modification comprend en outre la configuration d’une fonction apte à interagir avec une fonction virtualisée de la pluralité adaptée suite à l’attachement ou au détachement du terminal.
L’adaptation d’une fonction virtualisée, ou d’un composant élémentaire de celle-ci, de la pluralité, peut s’accompagner d’une configuration d’une fonction, virtualisée ou non, liée ou communiquant avec la fonction virtualisée mise à jour. Ainsi dans le cas d’un chainage de fonctions virtualisées ou d’un graphe de fonctions virtualisées, la modification d’une des fonctions virtualisées de la chaîne peut nécessiter de modifier une ou plusieurs autres fonctions ne faisant pas partie de la pluralité. Par exemple, si la mise à jour consiste à ajouter un nouveau protocole, il est possible que ce nouveau protocole soit également requis dans d’autres fonctions ou équipements de l’infrastructure de communication.
Selon un autre aspect de l'invention, le procédé de modification comprend en outre la réception d’une donnée relative à une session dudit terminal et la détermination de l’adaptation en fonction de la donnée reçue.
La réception d’une information sur l’attachement d’un terminal peut être complétée par une information sur une session du terminal. L’information sur la session, par exemple sur son débit, sur sa qualité de service en terme par exemple de latence, voire sur le type ou le nombre de destinataires des données de la session, peut être prise en compte pour adapter la mise à jour la plus opportune, typiquement entre une modification d’une fonction virtualisée existante et l’ajout d’une nouvelle fonction virtualisée.
Selon un autre aspect de l'invention, le procédé de modification comprend en outre la transmission à un dispositif d’orchestration et/ou à la fonction virtualisée de la pluralité impactée par l’action déterminée d’au moins un message de configuration.
Une fois l’adaptation déterminée, c’est-à-dire qu’une ou plusieurs fonctions virtualisées ou des composants de celles-ci doivent être modifiés, déplacés, ajoutés ou retirés, la mise en œuvre de cette adaptation peut être avantageusement réalisée en transmettant un message de configuration à un dispositif d’orchestration en charge de la gestion de services déployés à partir des fonctions virtualisées de la pluralité et/ou un message de configuration à destination d’une fonction virtualisée impactée par l’adaptation. Selon l’adaptation déterminée, seul le dispositif d’orchestration doit recevoir un message de configuration, ou bien seul une ou plusieurs fonctions virtualisées impactées reçoivent un message de configuration ou bien encore l’adaptation requiert un message de configuration à destination du dispositif d’orchestration et un message de configuration à destination d’une ou plusieurs fonctions virtualisées. Dans ce dernier cas, les messages de configuration peuvent avantageusement être spécifiques au dispositif de configuration et à chacune des fonctions virtualisées concernées par l’adaptation déterminée.
Les différents aspects du procédé de modification qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L’invention concerne également un dispositif de modification d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, mis en œuvre dans un dispositif de gestion de l’infrastructure et comprenant :
- un récepteur, apte à recevoir une information relative à un attachement ou à un détachement dudit terminal à une station d’accès de l’infrastructure de communication,
- un module de détermination, apte à déterminer une adaptation de la pluralité de fonctions virtualisées en fonction de la localisation de la station d’accès à laquelle le terminal est attaché ou à la localisation du terminal.
Ce dispositif de modification est apte à mettre en œuvre dans tous ses modes de réalisation le procédé de de modification qui vient d'être décrit.
L’invention concerne également un procédé d’adaptation d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, ledit procédé étant mis en œuvre dans une fonction virtualisée ou un dispositif d’orchestration de la pluralité de fonctions virtualisées, et comprenant :
- la réception en provenance du dispositif de gestion d’un message de configuration d’au moins une fonction virtualisée de la pluralité en fonction de la localisation d’une station d’accès à laquelle le terminal est attaché ou à la localisation du terminal,
- la mise à jour de ladite au moins une fonction virtualisée relative au message de configuration reçu.
L’invention concerne également un dispositif d’adaptation d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, ledit dispositif étant mis en œuvre dans une fonction virtualisée ou un dispositif d’orchestration de la pluralité de fonctions virtualisées, comprenant:
- un récepteur, apte à recevoir en provenance du dispositif de gestion un message de configuration d’au moins une fonction virtualisée de la pluralité en fonction de la localisation d’une station d’accès à laquelle le terminal est attaché ou à la localisation du terminal,
- un module de mise à jour, apte à mettre à jour ladite au moins une fonction virtualisée relative au message de configuration reçu.
Ce dispositif d’adaptation est apte à mettre en œuvre dans tous ses modes de réalisation le procédé d’adaptation qui a été décrit ci-dessus.
L’invention concerne également un système de modification d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, caractérisé en ce qu’il comprend :
- un dispositif de modification,
- au moins un dispositif d’adaptation.
L'invention concerne aussi des programmes d'ordinateur comprenant des instructions pour la mise en œuvre des étapes des procédés respectifs de modification et d’adaptation qui viennent d'être décrits, lorsque ces programmes sont l’un et l’autre exécutés par un processeur et un support d’enregistrement lisible respectivement par un dispositif de modification et d’adaptation sur lesquels sont enregistrés les programmes d’ordinateurs.
Les programmes mentionnés ci-dessus peuvent 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.
Les supports d'informations mentionnés ci-dessus peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un 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.
Un tel moyen de stockage peut par exemple être un disque dur, une mémoire flash, etc.
D'autre part, un 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. Un programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, un support d'informations peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question.
4. Brève description des dessins
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
La décrit une infrastructure de communications dans laquelle est mis en œuvre le procédé de modification selon un mode de réalisation de l’invention,
La décrit une infrastructure de communications dans laquelle est mis en œuvre le procédé de modification selon un autre mode de réalisation de l’invention,
La décrit la mise en œuvre du procédé de modification selon un autre mode de réalisation de l'invention,
La décrit un dispositif de modification d’une infrastructure de communication selon un aspect de l’invention,
La décrit un dispositif d’adaptation d’une infrastructure de communication selon un aspect de l’invention.
5. Description des modes de réalisation
Dans la suite de la description, on présente des modes de réalisation de l'invention dans une infrastructure de communication. Cette infrastructure peut être mise en œuvre pour acheminer des données de communication à destination de terminaux fixes ou mobile. L’infrastructure est mise en œuvre au moins en partie à partir de fonctions virtualisées, ces fonctions pouvant correspondre à des fonctions réseau (adressage, routage, sécurité, gestion de qualité de service…) ou à des fonctions applicatives (enrichissement, optimisation, répartition de charge, sécurisation applicative…). Cette infrastructure peut également comprendre des équipements mettant en œuvre les fonctions selon un mode non virtualisé. Cette infrastructure peut être utilisée pour l’acheminement et/ou le traitement de données utiles et de contrôle de clientèle résidentielle ou d’entreprises et peut comprendre des fonctions relatives à l’accès et/ou à un cœur de réseau.
On se réfère tout d’abord à la qui présente une infrastructure de communications dans laquelle quel est mis en œuvre le procédé de modification selon un mode de réalisation de l’invention.
L’infrastructure Res de communication, que l’on peut également nommer réseau de communication, comprend 3 stations d’accès respectivement nommées Acc1, Acc2 et Acc3. Les 3 stations d’accès Acc1, Acc2, Acc3 mettent en œuvre des technologies distinctes, respectivement une technologie de type cellulaire (3G, 4G, 5G…) pour Acc1, une technologie de type satellitaire pour Acc2 et une technologie de type Wi-Fi pour Acc3. Ces technologies sont prises à titre d’exemples et ne sont pas exhaustives, ni requises. Les 3 technologies d’accès pourraient par exemple être de même type, par exemple de type cellulaire et l’infrastructure Res pourrait également comprendre un plus grand nombre de stations d’accès ou bien seulement une ou deux stations d’accès. Selon un autre exemple, une ou plusieurs des stations d’accès Acc1, Acc2, Acc3 sont de types « fixes » et peuvent correspondre à des points d’accès filaires pour des accès de type fibre ou xDSL (en anglais digital subscriber line) par exemple. Les stations d’accès dans ce cas peuvent alors être par exemple un CPE (en anglais Customer Premises Equipment) tel qu’une Box ou un équipement d’accès d’un réseau d’opérateur (DSLAM (en anglais Digital Subscriber Line Multiplexer) ou nœud de raccordement optique).
L’infrastructure Res de communication comprend en outre un réseau Res1 d’acheminement qui pourrait être par exemple être un réseau cœur auquel sont connectées les différentes stations d’accès, ce réseau Res1 étant par exemple opéré par un opérateur de télécommunications. Ce réseau Res1 comprend une pluralité de fonctions virtualisées VF1, VF2,…, VFn en charge d’appliquer un traitement à des données transitant sur le réseau Res1. Par exemple, si une session de données est établie entre le terminal Term1 et le serveur de données Srv1, les informations nécessaires à la gestion, au contrôle ou à l’établissement de cette session ainsi que les données transmises dans cette session pourront être traitées par une partie ou toutes les fonctions virtualisées VF1, VF2, VF3, VF4, VF5 et VF6, VF7 avant d’être reçues par le serveur Srv1. Ces fonctions virtualisées peuvent fournir un traitement relatif à la gestion des terminaux (enregistrement, mobilité) ou à l’acheminement des données et on qualifiera alors ces fonctions de fonctions virtualisées de niveau réseau ou bien elles peuvent fournir un traitement aux données utiles transférées, c’est-à-dire aux données applicatives, et on se référera alors à des fonctions virtualisées applicatives. Selon un exemple, une ou plusieurs des fonctions virtualisées VF1, …, VF7 peut également être mise en œuvre à partir d’équipement « hardware » non virtualisé interagissant avec les autres fonctions virtualisées.
Les fonctions virtualisées VF1, VF2, …, VFn sont mises en œuvre dans des centres de données aussi appelés des centres de calculs. Ces centres de données peuvent être plus ou moins distribués, et dans certains réseaux, des centres de données distribués sont déployés au plus près des stations d’accès notamment pour que les services de données des terminaux bénéficient d’une bonne qualité de service, notamment en terme de latence. Cela peut notamment intervenir dans le cas des architectures MEC (en anglais Mobile Edge Computing). Les différents terminaux Term1 et Term2, et notamment les applications sur les terminaux à l’origine de l’échange de données avec le serveur de données Srv1, ne requièrent pas nécessairement les mêmes fonctions virtualisées, ni les mêmes exigences en termes d’acheminement ou de traitement des données. De même, le type de station d’accès, peut intervenir sur le type de fonction virtualisée à invoquer pour le transport de données. Par exemple, une fonction virtualisée pourra être nécessaire pour gérer la qualité de service pour le terminal Term1 attaché à un accès satellitaire (Acc2) alors que cette même fonction virtualisée sera non nécessaire s’il s’agit d’un accès cellulaire (Acc1). Dans ce cas, le type de la station d’accès (satellitaire ou cellulaire) intervient donc dans la mise à jour du réseau de communication en nécessitant une nouvelle fonction virtualisée ou un nouveau composant dans une fonction virtualisée pour gérer par exemple la qualité de service (latence) dégradée due à l’accès satellitaire.
L’attachement d’un terminal à une station d’accès requiert la mise à jour de l’infrastructure Res de communication et plus particulièrement, d’une ou plusieurs des fonctions virtualisées de l’infrastructure Res. Par exemple, l’attachement du terminal Term1 à la station d’accès Acc1 requiert, selon un exemple, d’instancier une fonction virtualisée au plus près de la station d’accès Acc1. En effet, dans le cas où des fonctions virtualisées sont instanciées dans un centre de données centralisé et donc assez éloigné de la station d’accès Acc1, il peut être nécessaire de déployer une nouvelle fonction virtualisée à proximité de la station d’accès Acc1 par exemple pour améliorer les temps de connexion du terminal Term1 ou bien pour améliorer la qualité du service de données du terminal Term1. La fonction virtualisée VF1 à instancier peut-être une fonction réseau virtualisée si l’on souhaite par exemple optimiser un routage des données du terminal Term1 dans le réseau Res1 ou bien une fonction virtualisée applicative s’il s’agit par exemple d’améliorer la latence du service de données et/ou la qualité d’expérience pour le client du terminal Term1. Selon un exemple, la fonction virtualisée VF1 peut déjà être instanciée et il n’est pas nécessaire d’intervenir sur cette fonction virtualisée lors de l’attachement du terminal Term1. Si le Term1 se déplace ou bien si la station d’accès Acc1 devient indisponible ou bien encore si le terminal Term1 sélectionne une autre station d’accès Acc2, alors il peut être nécessaire de déplacer la fonction VF1 initialement déployée au plus près de la station d’accès Acc1 vers un centre de données plus adapté, par exemple au plus près de la station de réception du signal satellite de la station d’accès Acc2 ou bien dans un centre de données adapté aux flux de données transmis par liaison satellite. Dans l’exemple de la , la mise à jour de l’infrastructure Res de communication, et donc du réseau Res1 composé des fonctions virtualisées VF1, …, VF7, consiste, selon le cas, au déploiement ou à la création d’une fonction virtualisée ou encore au déplacement d’une fonction virtualisée. Dans un autre cas non décrit sur la , la mise à jour peut consister à retirer une fonction virtualisée. Par exemple, dans le cas où une fonction virtualisée VF1a n’est plus utilisée par les terminaux attachés à la station d’accès Acc3, il peut être envisagé de retirer cette fonction V1Fa du centre de données dans lequel elle est déployée de façon par exemple à préserver des ressources de calcul pour d’autres fonctions virtualisées du centre de données, ou bien pour réduire le nombre de licences requises pour le maintien des différentes instances d’une même fonction virtualisée dans l’infrastructure Res. Selon encore un autre exemple, la modification d’une fonction virtualisée peut être envisagée pour l’adaptation du réseau composé des différentes fonctions virtualisées VF1, …, VF7. Par exemple, il peut s’agir d’instancier à la fonction virtualisée VF1a un nouveau protocole approprié lorsque le terminal Term2 s’attache à la station d’accès Acc3. Par exemple, le terminal Term2 étant un PC nomade, il peut être nécessaire de déployer un nouveau module de sécurité ou un serveur VPN (en anglais Virtual Private Network) dans une des fonctions virtualisées VF1, …, VF7 de l’infrastructure Res. Selon un autre exemple, la modification de la fonction virtualisée VF1a peut consister à ajouter de nouvelles ressources d’acheminement et/ou de traitement de données en raison du nombre plus important de terminaux attachés à la station d’accès Acc3. Une telle adaptation de l’ensemble des fonctions virtualisées VF1, …, VF7, consistant dans ce cas à modifier une des fonctions virtualisées de l’infrastructure Res de communication, permet ainsi d’adapter de façon fonctionnelle et de façon quantitative les ressources de l’infrastructure Res de communications aux besoins des terminaux s’attachant à cette infrastructure. Il est à noter en outre que la modification du réseau de fonctions virtualisées VF1, …, VF7 de l’infrastructure Res de communication par ajout et/ou retrait et/ou déplacement et/ou modification d’une fonction virtualisée peut en outre requérir de modifier une autre fonction virtualisée ou un autre équipement physique interagissant avec la fonction virtualisée objet de la modification, telle qu’une ou plusieurs fonctions virtualisées parmi VF1, VF2, VF3,…, VF7 ou un équipement de l’infrastructure Res ou extérieur à l’infrastructure Res non représenté sur la . Par exemple, si une nouvelle fonction virtualisée est ajoutée, il peut être nécessaire de modifier les configurations de sécurité d’une ou plusieurs des fonctions virtualisées citées ci-dessus, voire également la configuration du serveur Srv1.
Selon un exemple, la modification de l’infrastructure Res de communication, à la suite de l’attachement d’un terminal Term1, est mise en œuvre seulement si le terminal Term1 appartient à une liste de terminaux pour lesquels la modification est autorisée, cette liste étant gérée par un dispositif de gestion du réseau Res ou dans une base de données externe à ce dispositif de gestion mais accessible au dispositif de gestion. Par exemple, un opérateur de l’infrastructure peut considérer que si le client du terminal Term1 fait partie des clients ayant souscrit un abonnement permettant par exemple de maintenir une qualité de service stable, alors l’adaptation des fonctions virtualisées peut être mise en œuvre. Selon une autre option, la modification peut être mise en œuvre seulement si le terminal Term1 est identifié comme un terminal d’un certain type (PC, smartphone...), ou bien si le terminal Term1 dispose d’un protocole particulier, par exemple de sécurité) et requérant une fonction virtualisée particulière ou un composant particulier dans une ou plusieurs fonctions virtualisées par exemple.
Selon un autre exemple, la modification de l’infrastructure Res de communication est mise en œuvre en fonction d’une donnée d’une session de données utiles ou de signalisation établie par le terminal Term1. Ainsi, par exemple, si la donnée permet d’identifier une session requérant une faible latence et/ou si la session est sécurisée et/ou si la session est établie en utilisant un protocole particulier, alors la modification de l’infrastructure Res sera déterminée en fonction de la donnée reçue.
Une combinaison de ces différents exemples de mise en œuvre, par exemple à partir d’une identification du terminal et d’une session de données, peut également être exploitée selon un autre exemple.
On se réfère ensuite à la qui présente une infrastructure de communications dans laquelle est mis en œuvre le procédé de modification selon un autre mode de réalisation de l’invention.
Dans ce mode de réalisation, sont représentés les éléments de l’infrastructure telle que présentée dans la . Ce mode de réalisation se distingue du mode de réalisation de la par la structuration ou la composition des fonctions virtualisées VF1 et VF1b. Les autres fonctions virtualisées VF1a, VF2, …, VF7 peuvent elles-mêmes être structurées comme les deux fonctions VF1 et VF1b.
La fonction virtualisée VF1 comprend 4 composants dénommés C1, C2, C3, C4. Ces quatre composants peuvent respectivement fournir des composants logiciels proposant des fonctions réseaux ou des fonctions applicatives. La fonction virtualisée VF1b comprend 3 composants dénommés C1, C5, C6. Il n’existe pas de limite au nombre de composants compris dans les fonctions virtualisées VF1 et VF1b et un composant peut lui-même comprendre une pluralité de composants. Par exemple, on pourrait considérer qu’une fonction virtualisée VF1 comprend 3 composants respectifs réseau, applicatif et sécurité et que chacun de ces composants comprend lui-même des composants.
Le terminal Term1 initialement attaché à la station d’accès Acc1 utilise des composants de la fonction VF1 ainsi que des composants des autres fonctions virtualisées VF2, VF3, …, VF7 lors d’une session de données, qu’il s’agisse d’une session applicative avec le serveur Srv1 ou d’une procédure de signalisation avec le réseau Res1.
Lorsque le terminal Term1 change de point d’attachement et se trouve ensuite attaché à la station d’accès Acc2, alors un dispositif de gestion non représenté sur la , lorsqu’il est informé par le terminal Term1 ou la station d’accès Acc1 ou bien encore par la station d’accès Acc2 du changement de station d’accès pour le terminal Term1, modifie l’infrastructure Res de communication. Cette modification comprend notamment le déplacement du composant C4 de la fonction virtualisée VF1 vers la fonction virtualisée VF1b. Selon un autre exemple, il peut s’agir de déplacer le composant C4 d’un serveur physique hébergeant une fonction virtualisée vers un autre serveur physique de l’infrastructure de communication et plus particulièrement de l’infrastructure de virtualisation sur laquelle est mise en œuvre l’infrastructure de communication. Il est à noter que cette modification peut intervenir alors que la session de données est établie et maintenue lors du changement de station d’accès Acc1 vers Acc2 pour le terminal Term1, conformément aux techniques de handover ou bien en l’absence de session établie, lorsque le terminal Term1 change de station d’accès alors que celui-ci n’émet pas et/ou ne reçoit pas de données. Cette modification peut également se produire lorsque le terminal Term1 initie une nouvelle session de données avec le serveur Srv1, la modification pouvant par exemple prendre en compte une caractéristique de la session. Le composant C4 déplacé, correspondant à l’adaptation des fonctions virtualisées dans ce mode de réalisation, peut indifféremment être un composant réseau ou applicatif, ou bien encore un ensemble de composants, permettant au terminal Term1 de pouvoir disposer ou continuer de disposer de la fonctionnalité mise à disposition par le composant C4 et/ou pour obtenir une qualité d’expérience telle qu’attendue lors du changement de station d’accès Acc1 vers Acc2.
Dans ce mode de réalisation, il est fait référence à un déplacement d’un composant d’une fonction virtualisée VF1 vers une fonction virtualisée VF1b mais la mise en œuvre de composants permet également de pouvoir selon les cas, déployer un nouveau composant dans la fonction virtualisée VF1b, retirer un composant de la fonction VF1 si celui-ci n’est plus requis, modifier un composant de la fonction virtualisée VF1 et/ou VF1b.
De façon identique au mode de réalisation de la , la modification de l’infrastructure Res de communication par adaptation de fonctions virtualisées, comprenant l’ajout et/ou le retrait et/ou le déplacement et/ou la modification d’un composant d’une ou plusieurs fonctions virtualisées, peut en outre requérir de modifier une autre fonction virtualisée ou un équipement physique, telle qu’une ou plusieurs fonctions virtualisées parmi VF2, VF3,…, VF6, VF7 du réseau Res1 ou externe au réseau Res1 voire à l’infrastructure Res. Par exemple, si un nouveau composant correspondant à un protocole d’acheminement est ajouté à la fonction virtualisée VF1b, il peut être nécessaire de modifier les différentes fonctions virtualisées ou équipements physiques de l’infrastructure Res de communication, par exemple les fonctions VF4, VF5 et VF6, ainsi que le serveur Srv1, avec ce même composant pour que les flux de données du terminal Term1 puissent être acheminés jusqu’au serveur Srv1 en utilisant ce nouveau protocole et l’infrastructure Res modifiée avec le nouveau composant.
Les exemples de mise en œuvre de la modification de l’infrastructure Res de communication, basés notamment sur l’identification du terminal Term1 et sur la donnée d’une session de bout-en-bout établie par le terminal Term1, tels que décrits ci-dessus pour la , sont également possibles dans ce mode de réalisation.
On se réfère ensuite à la qui décrit la mise en œuvre du procédé de modification selon un autre mode de réalisation de l'invention.
Les entités Term1, Acc1 et Acc2 présentées dans les et sont reprises dans cette . En outre, l’infrastructure Res de communication comprend un dispositif de gestion GEST comprenant un dispositif de modification mettant en œuvre le procédé de modification qui va être décrit ci-après. Ce dispositif de gestion GEST peut être mis en œuvre sous une forme virtualisée ou non dans l’infrastructure Res de communication et peut être colocalisé dans un même équipement que les dispositifs d’orchestration ORCH et/ou de mobilité MOB qui vont être décrits ci-après. Le dispositif de mobilité MOB est apte à gérer l’attachement du Term1 aux entités d’accès Acc1 et Acc2 de l’infrastructure Res de communication et peut être mis en œuvre par exemple dans un équipement de type MME (en anglais Mobility Management Entity) ou AMF (en anglais Access and Mobility Management Function), ou GMLC (en anglais Gateway Mobile Location Center) ou bien encore NWDAF (en anglais NetWork Data Analytics Function) ou bien encore une station d’accès Acc1, Acc2. Les équipements MME, AMF, GMLC NWDAF peuvent en outre être implémentés dans une ou plusieurs fonctions virtualisées, telles que les fonctions VF1…VF7 de la ou de la . Le dispositif MOB est apte à possiblement communiquer avec les entités d’accès Acc1 et Acc2, ainsi que possiblement avec le terminal Term1 et avec le dispositif ORCH. Le dispositif ORCH d’orchestration est un dispositif apte à gérer les instances de fonctions virtualisées VF1, VF1a, ..., VF7 de l’infrastructure Res de communication, voire les instances des composants C1, C2, …, Cn lorsque de tels composants sont déployés. Un tel dispositif ORCH peut par exemple être mis en œuvre dans une entité de type orchestrateur gérant les instances virtuelles de l’infrastructure Res de communication, en lien par exemple avec des gestionnaires des fonctions virtualisées, s’il s’agit d’une infrastructure de communication, par exemple déployée selon les principes NFV (en anglais Network Function Virtualization).
Lors d’une première étape 100 optionnelle, le dispositif de gestion GEST émet à destination du dispositif de de mobilité MOB un message de requête de souscription à une information relative à un attachement du terminal Term1 à une station d’accès Acc1 et Acc2. Par ce message, lorsque le dispositif de gestion GEST est informé d’un nouvel attachement du terminal Term1 à l’une des stations d’accès Acc1, Acc2, ou bien d’un changement d’attachement du terminal Term1 de la station d’accès Acc1 vers Acc2 ou inversement, ou bien encore d’un détachement du terminal Term1 de l’une des stations d’accès Acc1 et Acc2, voire à une modification de l’attachement du terminal Term1 à l’une des stations d’accès Acc1 et/ou Acc2, le dispositif de mobilité MOB en informe le dispositif de gestion GEST. Cette étape est optionnelle, car selon un autre exemple, le terminal Term1 peut informer lui-même le dispositif de gestion GEST de l’un des changements indiqués ci-dessus ou bien encore selon encore un autre exemple, les dispositifs d’accès Acc1 et Acc2 peuvent en informer le dispositif de gestion GEST. La mise en œuvre d’un dispositif de mobilité MOB est avantageuse pour que le dispositif de gestion GEST puisse recevoir des informations liés à des attachements concernant possiblement plusieurs terminaux et entités d’accès dans un seul message, réduisant le nombre de messages reçus et à traiter par le dispositif de gestion GEST, mais aussi pour que le dispositif de mobilité MOB effectue un pré-traitement et ne transmette pas toutes les modifications d’attachement si celles-ci ne requièrent pas de modification de l’infrastructure Res de communication.
Selon une alternative, le message de requête de souscription émis lors de l’étape 100, comprend un ou plusieurs identifiants de terminaux pour lesquels le dispositif de gestion GEST souhaite être notifié d’une modification d’un attachement à une station d’accès Acc1 et Acc2.
Lors d’une étape 101, le dispositif de gestion GEST reçoit une information relative à l’attachement du terminal Term1 à la station d’accès Acc1 de type 5G de l’infrastructure Res de communication, cet attachement ayant eu lieu lors de l’étape 100a. La station d’accès est par exemple une entité de type gNB. Cette information peut être émise au dispositif GEST par le dispositif de mobilité MOB si le dispositif de gestion GEST a souscrit aux informations d’attachement conformément à l’étape 100 ou bien cette information d’attachement peut être émise par la station d’accès Acc1 accueillant le terminal Term1 ou bien encore par le terminal Term1. Selon un autre exemple, l’information est relative au détachement du terminal Term1 de la station d’accès Acc1 voire à une modification de l’attachement du terminal Term1 à la station d’accès Acc1, cette modification pouvant être liée à un changement de qualité de service, à un changement de paramètre de sécurité, voire à l’établissement d’une nouvelle session de données par le terminal Term1. Selon ce dernier exemple, l’établissement d’une nouvelle session de données peut exiger plus de ressources dans l’infrastructure Res de communication pour le terminal Term1 ou un changement de caractéristiques des ressources déjà allouées à ce terminal Term1.
A la réception de l’information sur l’attachement du terminal Term1 à la station d’accès Acc1, le dispositif de gestion GEST détermine, lors d’une étape 102, une action d’adaptation des fonctions virtualisées de l’infrastructure Res de communication. Cette détermination peut tenir compte de la localisation géographique et/ou topographique, c’est-à-dire dans l’infrastructure Res de communication, de la station d’accès Acc1 et/ou de la localisation géographique et/ou topologique du terminal Term1. L’information sur la localisation du terminal Term1 peut être obtenue dans le message d’information reçu lors de l’étape 101, ou bien directement du terminal Term1 dans une étape non représentée sur la . L’action de détermination peut consister à déployer une nouvelle fonction virtualisée par exemple tel que décrit dans la spécification ETSI GS NFV-SOL016 (https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/016/02.08.01_60/gs_NFV-SOL016v020801p.pdf), à déplacer une fonction virtualisée existante, à retirer une fonction virtualisée existante si celle-ci n’est plus requise suite à l’attachement ou au détachement du Term1, ou bien encore à modifier une fonction virtualisée, par exemple en ajoutant des ressources de traitement ou une nouvelle fonction applicative. L’adaptation peut également comprendre l’ajout, la modification, le retrait ou le déplacement de plusieurs fonctions virtualisées.
La création ou le déplacement des fonctions virtualisées, ou plus précisément des ressources virtualisées qui leur servent de support, est ensuite effectué selon des mécanismes de migration de ressources spécifiques à la technologie de gestion de ressources virtualisées employée, par exemple OpenStack ou Kubernetes.
Toutes ces actions de détermination peuvent également uniquement concerner un composant d’une ou plusieurs fonctions virtualisées dans le cas où cette fonction virtualisée est composée d’un ou plusieurs composants liés à l’acheminement ou au traitement applicatif. Cette action de détermination peut également dépendre d’une session de données établie entre le terminal et un serveur applicatif distant, tel que le serveur Srv1 présenté dans les et .
Selon une alternative, l’action de détermination peut en outre comprendre une comparaison d’un identifiant du terminal Term1 avec une liste d’identifiants de terminaux gérés par le dispositif de gestion ou par une entité externe non représentée avec laquelle le dispositif de gestion communique. Cette liste de terminaux permet de pouvoir déterminer si une action de détermination doit être mise en œuvre et/ou si une action de détermination est mise en œuvre, le type d’action à déterminer. Par exemple, le procédé de modification peut être valide uniquement pour une liste de terminaux déterminés par leurs identifiants ou bien encore, un ajout d’un composant dans une fonction virtualisée peut être valide uniquement pour certains terminaux. Cette liste d’identifiants permet ainsi de déterminer des actions distinctes en fonction d’un type de terminal ou d’un type d’abonnement pour un terminal. L’identifiant du terminal Term1 peut être obtenu lors de l’étape d’information 101 ou bien directement du terminal Term1.
Selon une autre alternative, l’action de détermination comprend la modification d’une autre fonction virtualisée ou d’un autre équipement non virtualisé de l’infrastructure Res de communication ou d’un équipement externe à l’infrastructure Res. Dans ce dernier cas, l’adaptation pourra comprendre un échange avec une entité de gestion en charge de cet équipement externe à l’infrastructure Res. Selon un exemple, le déplacement d’une fonction virtualisée peut requérir de mettre à jour une table d’acheminement d’autres fonctions ou d’autres équipements de l’infrastructure Res. Selon un autre exemple, une modification de fonction virtualisée est déterminée et cette mise à jour est enregistrée dans une base de données du dispositif de GEST ou du dispositif d’orchestration ORCH à la suite de l’étape décrite ci-après, ou dans une base externe, par exemple de type NRF (en anglais Network Repository Function) ou de type DNS (en anglais Domain Name System) dans une étape non représentée sur la sachant qu’il est également possible de déployer une base de données externe en plus d’une base de données dans le dispositif GEST ou ORCH. L’enregistrement dans une base de données d’une mise à jour d’une fonction virtualisée est valide que la mise à jour corresponde à une modification, à une création, à un déplacement ou à une suppression d’une fonction virtualisée et/ou d’un composant d’une fonction virtualisée. Les autres fonctions virtualisées et/ou équipements de l’infrastructure Res peuvent ainsi accéder à cette base de données, quelle que soit sa forme ci-dessus, pour interagir avec la fonction virtualisée déplacée ou nouvellement déployée.
Lors d’une étape 103 optionnelle, le dispositif de gestion GEST transmet au dispositif d’orchestration ORCH un message de configuration permettant de mettre en œuvre l’adaptation déterminée lors de l’étape 102. Selon un exemple, ce message de configuration peut comprendre le type de fonction virtualisée à instancier s’il s’agit d’une création, et les informations de configuration (localisation, paramétrage…) de cette fonction virtualisée, ou bien encore la modification à apporter à une fonction virtualisée identifiée dans le message de mise à jour, ainsi que possiblement le délai de mise à jour requis. Dans cet exemple, l’action de mise à jour comprend la création d’une fonction virtualisée VNF1 dans l’infrastructure Res de communication. Selon un exemple, dans le cas où le dispositif ORCH est une entité de type NFVO, le dispositif de gestion GEST transmet une requête UpdateNs, telle que décrite dans ETSI GS NFV-IFA 013, au dispositif ORCH (NFVO) pour ajouter une instance de fonction virtualisée (VNF) au service réseau NS (en anglais Network Service) correspondant dans cet exemple au réseau Res. L’action de configuration comprend aussi bien l’action de modifier une fonction virtualisée existante que l’instanciation d’une nouvelle fonction virtualisée. En effet, un message de configuration transmis au dispositif ORCH pour instancier une nouvelle fonction virtualisée permet d’adapter le réseau de communication à l’événement intervenant à l’accès du réseau de communication. Selon une autre alternative, lors de l’étape 103, le dispositif GEST transmet le message de configuration directement à la fonction virtualisée impactée par l’adaptation ou aux fonctions virtualisées impactées s’il y en a plusieurs. Selon cet exemple, le dispositif GEST configure la ou les fonctions virtualisées impactées par l’adaptation. Selon encore une autre alternative, un message de configuration est envoyé au dispositif ORCH et à une ou plusieurs fonctions virtualisées. Dans ce cas, le message de configuration transmis au dispositif ORCH et le message transmis à une ou plusieurs fonctions virtualisées peuvent être différents. Par exemple, l’adaptation peut consister à transmettre un message au dispositif ORCH pour qu’une fonction virtualisée ait plus de ressources de traitement et un message de configuration distinct peut être envoyé à une ou plusieurs des fonctions virtualisées pour mise à jour applicative, ce qui peut être réalisé sans l’intervention du dispositif ORCH. Les messages de configuration envoyés à des fonctions virtualisées distinctes, peuvent eux-mêmes être spécifiques aux fonctions virtualisées, par exemple dans le cas où des protocoles distincts sont instanciés dans les fonctions virtualisées impactées par l’adaptation.
Lors de l’étape 104, le dispositif d’orchestration ORCH et/ou le dispositif GEST, via le message envoyé à la ou les fonction(s) virtualisée(s), effectue la mise à jour en créant la fonction virtualisée VF1 et en configurant cette fonction VF1 conformément aux informations reçues lors de l’étape 103, la configuration pouvant comprendre un ajout ou un retrait de ressources logicielles par exemple et/ou une configuration d’un protocole ou d’une application exécutée par la fonction VF1. Cette configuration peut être effectuée consécutivement à une réservation de ressources dans un centre de données d’accueil de la fonction virtualisée VF1 créée. Cette configuration peut s’accompagner d’une mise à jour de la base de données telle que décrite ci-dessus. Cette action de mise à jour peut être mise en œuvre de façon autonome par le dispositif d’orchestration ORCH et/ou le dispositif GEST ou bien en collaboration avec une autre entité telle qu’une entité VNFM (en anglais Virtual Network Function Manager) de l’infrastructure Res.
Lors de l’étape 105, le terminal Term1, initialement attaché à la station d’accès Acc1 se détache de la station d’accès Acc1 et s’attache à la station d’accès Acc3, par exemple conformément aux techniques de handover ou bien lorsque le terminal Term1 est en mode « idle », c’est-à-dire lorsque le terminal Term1 n’est pas en communication lors du changement de station d’accès. Une session de donnée établie entre le terminal Term1 et un serveur de données non représenté est maintenue lors de ce changement de station d’accès.
Lors de l’étape 106, l’entité d’accès Acc3 transmet au dispositif de gestion GEST une information relative à un changement d’accès, et à l’attachement du terminal Term1 à la station d’accès Acc3. Selon un exemple, l’information relative au changement d’accès du Terminal Term1 peut être transmise par le terminal Term1 ou bien par le dispositif de Mobilité MOB lors de l’étape 106.
Selon une alternative, l’entité d’accès Acc3 transmet en outre une information sur la session de données en cours du terminal Term1.
Lors de l’étape 107, le dispositif de gestion GEST détermine qu’une fonction virtualisée VF1a doit être mise à jour par l’ajout d’un composant apte à gérer la session de données en cours du terminal Term1. Ce composant est un module d’optimisation du service applicatif relatif à la session de données. Le dispositif de gestion GEST prend en compte la nouvelle localisation du terminal Term1 ainsi que qu’une donnée de la session en cours, selon cet exemple.
Lors de l’étape 108, le dispositif de gestion GEST informe le dispositif d’orchestration ORCH de l’action de mise à jour à mettre en œuvre en transmettant l’identité de la fonction virtualisée VF1a, le composant à ajouter, identifié par exemple par un nom de composant, à cette fonction virtualisée ainsi que possiblement le centre de données dans lequel le composant peut être obtenu. Selon une alternative, le dispositif GEST ne transmet pas au dispositif ORCH le nom d’un composant mais une information relative au déploiement de service qui sera ensuite exploitée par un dispositif de gestion de la fonction virtualisée VF1a, tel qu’un VNFM (en anglais Virtual Network Function Manager) qui identifie un ou plusieurs composants à ajouter à partir de l’information relative au déploiement de service retransmis par le dispositif ORCH.
Lors de l’étape 109, le dispositif d’orchestration ORCH met à jour la fonction virtualisée VF1a conformément à l’information de mise à jour reçue lors de l’étape 108.
Selon une alternative, lors de l’étape 110, le dispositif d’orchestration ORCH transmet au dispositif de gestion GEST un message indiquant la mise à jour effective de la fonction virtualisée VF1a de façon que le dispositif de gestion GEST ait toutes les informations à jour sur les fonctions virtualisées dans l’infrastructure Res de communication et puisse exploiter ces informations lors d’une prochaine modification de l’infrastructure.
On se réfère ensuite à la qui présente un dispositif 200 de modification d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, selon un mode de réalisation de l'invention.
Un tel dispositif de modification peut être mis en œuvre dans un dispositif de gestion, telle qu’une entité d’administration d’une infrastructure de communication ou bien dans une entité d’administration d’une infrastructure de communication s’appuyant sur une infrastructure de virtualisation (VNF manager, orchestrateur…).
Par exemple, le dispositif 200 de modification comprend une unité de traitement 230, équipée par exemple d'un microprocesseur μP, et pilotée par un programme d'ordinateur 210, stocké dans une mémoire 220 et mettant en œuvre le procédé de modification selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 210 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 230. Un tel dispositif 200 de modification comprend :
  • un récepteur 201, apte à recevoir une information Attach relative à un attachement ou à un détachement dudit terminal à une station d’accès de l’infrastructure de communication,
    - un module 202 de détermination, apte à déterminer une adaptation de la pluralité de fonctions virtualisées en fonction de la localisation de la station d’accès à laquelle le terminal est attaché ou à la localisation du terminal.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 200 afin qu’il effectue les étapes du procédé de modification tel que détaillé ci-dessus, en relation avec les , et , dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où le dispositif 200 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
On se réfère ensuite à la qui présente un dispositif 300 d’adaptation d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, selon un mode de réalisation de l'invention.
Un tel dispositif d’adaptation peut être mis en œuvre sous forme virtualisée ou sous forme d’équipement spécifique et peut être instancié dans une fonction virtualisée (VNF) ou dans un dispositif d’orchestration d’une architecture virtualisée.
Par exemple, le dispositif 300 d’adaptation comprend une unité de traitement 330, équipée par exemple d'un microprocesseur μP, et pilotée par un programme d'ordinateur 310, stocké dans une mémoire 320 et mettant en œuvre le procédé d’adaptation selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 310 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 330.
Un tel dispositif 300 d’adaptation comprend :
- un récepteur 301, apte à recevoir en provenance d’un dispositif de gestion un message Conf de configuration d’au moins une fonction virtualisée de la pluralité en fonction de la localisation d’une station d’accès à laquelle le terminal est attaché ou à la localisation du terminal,
- un module 302 de mise à jour, apte à mettre à jour ladite au moins une fonction virtualisée relative au message de configuration reçu.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 300 afin qu’il effectue les étapes du procédé d’adaptation tel que détaillé ci-dessus, en relation avec les , et , dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où le dispositif 300 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Claims (15)

  1. Procédé de modification d’une infrastructure (Res) de communication apte à fournir un service de communication à un terminal (Term1, Term2) par l’intermédiaire d’une pluralité de fonctions virtualisées (VF1,…,VFn), ledit procédé étant mis en œuvre dans un dispositif de gestion (GEST) de l’infrastructure (Res), et comprenant
    - une réception (101) d’une information (Attach) relative à un attachement ou à un détachement dudit terminal (Term1, Term2) à une station d’accès (Acc1, Acc2, Acc3) de l’infrastructure (Res) de communication,
    - la détermination (102) d’une adaptation de la pluralité de fonctions virtualisées (VF1,…,VFn) en fonction de la localisation de la station d’accès (Acc1, Acc2, Acc3) à laquelle le terminal (Term1, Term2) est attaché ou à la localisation du terminal (Term1, Term2).
  2. Procédé de modification, selon la revendication 1, dans lequel l’information relative à l’attachement fait suite à un changement (106) de station d’accès (Acc1, Acc2, Acc3) de l’infrastructure de communication à laquelle le terminal est attaché.
  3. Procédé de modification, selon la revendication 1 ou la revendication 2, où l’adaptation comprend au moins une des opérations parmi lesquelles :
    - un déploiement d’une fonction virtualisée dans l’infrastructure de communication
    - un déplacement d’une fonction virtualisée dans l’infrastructure de communication,
    - un retrait d’une fonction virtualisée dans l’infrastructure de communication,
    - une modification d’une fonction virtualisée dans l’infrastructure de communication.
  4. Procédé de modification selon l’une des revendications 1 à 3, où l’adaptation de la pluralité comprend l’ajout, et/ou le déplacement, et/ou le retrait et/ou la modification d’un composant (C1, C2, …, Cn) d’au moins une fonction virtualisée de la pluralité (VF1, …, VFn).
  5. Procédé de modification selon l’une des revendications 1 à 4, comprenant au préalable une émission (100) à destination d’un dispositif (MOB) de gestion de la mobilité dudit terminal d’une requête de souscription à une information relative à un attachement à une station d’accès (Acc1, Acc2, Acc3) du terminal (Term1, Term2).
  6. Procédé de modification, selon l’une des revendications 1 à 5, comprenant en outre la comparaison d’un identifiant dudit terminal avec une liste d’identifiants de terminaux (Term1, Term2) aptes à bénéficier du procédé de modification.
  7. Procédé de modification, selon l’une des revendications 1 à 6, comprenant en outre la configuration d’une fonction (VF1, …, VFn, Res1) apte à interagir avec une fonction virtualisée de la pluralité adaptée à la suite de l’attachement ou au détachement du terminal.
  8. Procédé de modification, selon l’une des revendications 1 à 7, comprenant en outre la réception d’une donnée relative à une session dudit terminal et la détermination de l’adaptation en fonction de la donnée reçue.
  9. Procédé de modification, selon l’une des revendications 1 à 8, comprenant en outre la transmission à un dispositif d’orchestration (ORCH) et/ou à la fonction virtualisée (VF1,…,VFn) de la pluralité impactée par l’action déterminée d’au moins un message (Conf) de configuration.
  10. Procédé d’adaptation d’une infrastructure (Res) de communication apte à fournir un service de communication à un terminal (Term1, Term2) par l’intermédiaire d’une pluralité de fonctions virtualisées (VF1,…,VFn), ledit procédé étant mis en œuvre dans une fonction virtualisée (VF1,…,VFn) ou un dispositif d’orchestration (ORCH) de la pluralité de fonctions virtualisées, et comprenant :
    - la réception en provenance du dispositif de gestion (GEST) d’un message de configuration (Conf) d’au moins une fonction virtualisée (VF1,…,VFn) de la pluralité en fonction de la localisation d’une station d’accès (Acc1, Acc2, Acc3) à laquelle le terminal est attaché ou à la localisation du terminal (Term1, Term2),
    - la mise à jour de ladite au moins une fonction virtualisée relative au message de configuration reçu.
  11. Dispositif de modification d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, mis en œuvre dans un dispositif de gestion de l’infrastructure de communication et comprenant :
    - un récepteur, apte à recevoir une information relative à un attachement ou à un détachement dudit terminal à une station d’accès de l’infrastructure de communication,
    - un module de détermination, apte à déterminer une adaptation de la pluralité de fonctions virtualisées en fonction de la localisation de la station d’accès à laquelle le terminal est attaché ou à la localisation du terminal.
  12. Dispositif d’adaptation d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, ledit dispositif étant mis en œuvre dans une fonction virtualisée ou un dispositif d’orchestration de la pluralité de fonctions virtualisées, comprenant :
    - un récepteur, apte à recevoir en provenance du dispositif de gestion un message de configuration d’au moins une fonction virtualisée de la pluralité en fonction de la localisation d’une station d’accès à laquelle le terminal est attaché ou à la localisation du terminal,
    - un module de mise à jour, apte à mettre à jour ladite au moins une fonction virtualisée relative au message de configuration reçu.
  13. Système de modification d’une infrastructure de communication apte à fournir un service de communication à un terminal par l’intermédiaire d’une pluralité de fonctions virtualisées, caractérisé en ce qu’il comprend :
    - un dispositif de modification selon la revendication 11,
    - au moins un dispositif d’adaptation selon la revendication 12.
  14. Programme d’ordinateur, caractérisé en ce qu’il comprend les instructions pour la mise en œuvre des étapes du procédé de modification selon l’une des revendications 1 à 9, lorsque ledit programme est exécuté par un processeur.
  15. Support d’enregistrement caractérisé en ce qu’il comprend des instructions qui, lorsqu’elles sont exécutées par un ordinateur mettent en œuvre le procédé de modification selon l’une quelconque des revendications 1 à 9.
FR2200222A 2022-01-12 2022-01-12 Procédé, dispositif et système de modification d’une infrastructure de communication Pending FR3131815A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR2200222A FR3131815A1 (fr) 2022-01-12 2022-01-12 Procédé, dispositif et système de modification d’une infrastructure de communication
PCT/EP2023/050119 WO2023135043A1 (fr) 2022-01-12 2023-01-04 Procédé, dispositif et système de modification d'une infrastructure de communication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2200222A FR3131815A1 (fr) 2022-01-12 2022-01-12 Procédé, dispositif et système de modification d’une infrastructure de communication
FR2200222 2022-01-12

Publications (1)

Publication Number Publication Date
FR3131815A1 true FR3131815A1 (fr) 2023-07-14

Family

ID=81580704

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2200222A Pending FR3131815A1 (fr) 2022-01-12 2022-01-12 Procédé, dispositif et système de modification d’une infrastructure de communication

Country Status (2)

Country Link
FR (1) FR3131815A1 (fr)
WO (1) WO2023135043A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170086118A1 (en) * 2015-09-18 2017-03-23 Huawei Technologies Co., Ltd. System and Methods for Network Slice Reselection
US20170311244A1 (en) * 2016-04-21 2017-10-26 At&T Intellectual Property I, L.P. Method and apparatus for providing a virtual network function in a network
WO2020069036A1 (fr) * 2018-09-26 2020-04-02 Intel Corporation Scénarios de déploiement de calcul en périphérie de réseau
WO2020132308A2 (fr) * 2018-12-19 2020-06-25 Apple Inc. Gestion de configuration, gestion de performances, et gestion de défaillance pour prise en charge d'informatique en périphérie

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170086118A1 (en) * 2015-09-18 2017-03-23 Huawei Technologies Co., Ltd. System and Methods for Network Slice Reselection
US20170311244A1 (en) * 2016-04-21 2017-10-26 At&T Intellectual Property I, L.P. Method and apparatus for providing a virtual network function in a network
WO2020069036A1 (fr) * 2018-09-26 2020-04-02 Intel Corporation Scénarios de déploiement de calcul en périphérie de réseau
WO2020132308A2 (fr) * 2018-12-19 2020-06-25 Apple Inc. Gestion de configuration, gestion de performances, et gestion de défaillance pour prise en charge d'informatique en périphérie

Also Published As

Publication number Publication date
WO2023135043A1 (fr) 2023-07-20

Similar Documents

Publication Publication Date Title
EP3632087B1 (fr) Sélection d'une tranche de réseau relative à une application
EP3427449B1 (fr) Sélection d'une instanciation de tranche de réseau pour la transmission de paquets montants
EP1590931B1 (fr) Procede de presentation d'etat d'un utilisateur utilisant plusieurs equipements de communication
EP3189430B1 (fr) Dispositifs, programme d'ordinateur, support d'enregistrement lisible par un ordinateur et procédé de contrôle d'un coeur de réseau ip
FR3023108A1 (fr) Procede et dispositif d'orchestration de ressources
EP3053326B1 (fr) Procédé d'accès d'un utilisateur a au moins un service de communication fourni par l'intermédiaire d'un centre informatique d'un système d'informatique en nuage
EP3807760B1 (fr) Procédé d'installation d'une fonction réseau virtualisée
WO2023135043A1 (fr) Procédé, dispositif et système de modification d'une infrastructure de communication
FR3061387A1 (fr) Procede de preparation d'un reseau de communication distribue a l'acheminement d'un flux de donnees a travers ledir reseau
FR3008270A1 (fr) Dispositif de controle d'un cœur de reseau ip et procede de commande mis en œuvre par ce dispositif
EP2446360B1 (fr) Technique de determination d'une chaine de fonctions elementaires associee a un service
FR3072537A1 (fr) Procede de basculement d'un equipement de gestion dans un reseau de telecommunications
WO2017158272A1 (fr) Procédé de gestion dynamique de chemins de communication entre routeurs en fonction de besoins applicatifs
WO2021130440A1 (fr) Procede de configuration d'un equipement utilisateur, equipement utilisateur, et entite de gestion de regles
WO2022034273A1 (fr) Procede de traitement d'un service de transport de donnees
FR3122544A1 (fr) Procédé et dispositif de paramétrage d’un dispositif terminal
EP3542589B1 (fr) Délégation d'instructions à un dispositif en fonction de ses ressources
WO2023217639A1 (fr) Procédé, dispositif et système d'élaboration dynamique d'une infrastructure de données
WO2023217638A1 (fr) Procédé, dispositif et système de certification d'une ressource
WO2024002868A1 (fr) Procédés de fourniture et de collecte, station de base, dispositif de collecte et d'analyse de données et système
FR3129506A1 (fr) Entité applicative ayant une architecture de micro-services, entité de contrôle et procédés mis en œuvre par ces entités
WO2023281181A1 (fr) Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise
WO2023047068A1 (fr) Procede de controle d'un acces a un service applicatif mis en œuvre dans un reseau de telecommunications, procede de traitement d'un message de controle d'un acces audit service applicatif, dispositifs, equipement de controle, equipement client, systeme et programmes d'ordinateur correspondants
FR3124681A1 (fr) Procédé de traitement d’une connexion entre un équipement utilisateur et un équipement distant dans un réseau de communication, procédé de contrôle, dispositifs, satellite, station terrestre, système et programmes d’ordinateur correspondants.
EP2469959B1 (fr) Procédé et dispositif de gestion d´une session de communication entre un terminal multi-accès et un serveur ANDSF

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20230714