Titre de l'invention : Procédé et dispositif de configuration d’une unité d’accès dans un environnement virtualisé

1. Domaine technique

L'invention concerne le déploiement automatisé ou la mise à jour d’une infrastructure d’accès d’un réseau de communications dans un environnement virtualisé basé sur une plate-forme de services s’appuyant sur des applications logicielles d’exploitation, telles que des conteneurs ou des machines virtuelles. Le déploiement automatisé de l’infrastructure d’accès prend en compte des paramètres de performances réseau, sécurité, énergie, coûts d’entités pour la distribution fonctionnelle et géographique des entités composant cette infrastructure.

2. Etat de la technique

Les architectures d’accès de réseaux de communications, et plus particulièrement les infrastructures d’accès de réseaux mobiles sont sujettes à des évolutions importantes. D’une infrastructure où l’ensemble des traitements (allocation de ressources, modulation, encodage...) permettant l’accès des terminaux étaient distribués dans les sites radio, au plus près des antennes, on s’oriente vers une centralisation plus ou moins importante de certaines de ces traitements en fonction de critères de disponibilité, de qualité de service et notamment de latence. Ainsi, notamment au 3GPP et au sein de l’alliance Open RAN, des travaux sont menés pour spécifier ces nouvelles infrastructures d’accès. On distingue dans ces nouvelles infrastructures trois entités identifiées CU (en anglais Centralized Unit), RU (en anglais Radio Unit) et DU (en anglais Distributed Unit). Ces unités se différencient par leur position dans le réseau de communication et donc également par leur nombre dans le réseau puisque plus une unité est proche de la station radio, plus il faut en déployer. Pour envisager le déploiement de telles nouvelles infrastructures, les traitements doivent être mis en œuvre dans l’une ou l’autre de ces entités. Il apparaît assez clairement que si une centralisation d’un traitement est plus avantageuse en termes de coût et de gestion, il présente également des inconvénients en termes de vulnérabilité et de latence notamment. De telles infrastructures d’accès peuvent donc avoir différentes instanciations selon le placement des traitements retenu dans les différentes unités et donc selon les interfaces requises entre les unités. Ces nouvelles infrastructures, nommées Cloud RAN (en anglais Cloud Radio Access Networks), sont en outre caractérisées par des mises en œuvre de logiciels déployés sur des serveurs informatiques banalisés, à moindre coût, l’intelligence et les services avancés étant mis en œuvre à partir des logiciels. Le déploiement de ces nouvelles architectures, notamment dans le cadre du développement des nouvelles architectures 5 G mais aussi pour les versions futures des réseaux mobiles, repose sur des techniques de virtualisation qui peuvent plus spécifiquement être des techniques de conteneurisation, cette dernière technique se caractérisant par l’absence d’hyperviseur en charge de gérer les différentes machines virtuelles. Une technique de gestion de conteneurs, par exemple mise en œuvre à partir d’une solution telle que Kubemetes, d’ores et déjà très utilisée dans les centres de données pourrait s’avérer très pertinente pour déployer au mettre à jour de façon automatique de telles architectures Cloud RAN. Kubemetes est une plate-forme permettant d'automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d'application sur des groupes (ou clusters) de serveurs. Kubemetes est composé de deux parties, à savoir

- Les maîtres (en anglais masters) permettant de gérer l’ensemble des déploiements dans un groupe de serveurs. Il est composés de trois parties, à savoir une base de données ETCD (en anglais /etc distributed) stockant toutes les données du groupe de serveurs, un serveur (an anglais API server) qui permet entre autres au master de communiquer avec les nœuds comprenant les conteneurs, et les contrôleurs qui ont pour objet de vérifier le bon fonctionnement du groupe ainsi que les déploiements et les mises à jour.

- Les nœuds, qui peuvent être des machines physiques ou des machines virtuelles. Les conteneurs sont instanciés sur les nœuds. Un nœud comprend un kublet qui permet de communiquer avec le master et de gérer les déploiements sur le nœud, un kube-proxy permettant une communication externe au groupe de serveurs et un Pod dans lequel est exécuté un conteneur.

Le terme de cluster utilisé dans une telle solution de conteneurisation correspond à un ensemble Masters/Nodes tel que décrit ci-dessus.

Si la mise en œuvre d’une infrastructure Cloud RAN à partir d’une solution de conteneurisation, telle que Kubemetes, présente un intérêt certain, une telle mise en œuvre présente cependant quelques problèmes notamment relatifs au déploiement d’une telle solution sur des sites distribués. Une telle solution doit permettre de déployer un Cloud RAN dont certaines caractéristiques sont rappelées ci-après :

- une association unique entre un CU et un DU ainsi qu’entre un DU, un RU et une antenne doit être instanciée

L’architecture retenue doit permettre de respecter les critères de performance et notamment un délai maximal de 1 ms entre un DU et un RU - Un démarrage du Cloud RAN et donc des conteneurs des entités CU, DU, RU, est permis par des configurations initiales. Ainsi le DU doit connaître l’adresse IP du RU, le DU doit connaître l’adresse IP du CU etc...

Des contraintes spécifiques à une solution de conteneurisation, telle que Kuberenetes, dans un tel environnement distribué sont en outre rappelées ci-dessous:

La solution de conteneurisation ne permet pas de gérer des allocations externes à la solution elle-même et notamment pas l’allocation des antennes au conteneur du RU

La solution ne permet pas non plus l’échange de configurations entre les différents conteneurs permettant le déploiement du Cloud RAN et notamment le partage des informations d’adressage des conteneurs comprenant les entités CU, DU et RU du Cloud RAN

La vérification que le déploiement de conteneurs supportant les fonctions CU, DU et RU permettent de respecter les contraintes de performance de telles architectures distribuées d’infrastructure d’accès.

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 configuration d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, ledit procédé étant mis en œuvre dans une entité d’administration du réseau de communication et comprenant

- une réception en provenance d’une entité de médiation de l’au moins une application logicielle d’exploitation d’un message d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,

- préalablement ou suite à la réception du message d’enregistrement, une détermination de l’au moins une application logicielle d’exploitation pour accueillir l’au moins une unité en fonction d’un résultat d’un test relatif à un critère de placement relatif à un flux de données acheminé par l’au moins une unité,

- une émission à destination de l’entité de médiation de l’au moins une application logicielle d’exploitation déterminée d’un message de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée, ledit message de configuration comprenant un identifiant d’au moins une autre unité accès du réseau de communication.

Un déploiement d’une unité d’accès d’un réseau de communication, notamment de type mobile, dans un environnement virtualisé, tel qu’une architecture virtualisée requiert l’instanciation d’ applications logicielles d’exploitation, qui peuvent être des conteneurs ou des machines virtuelles ou toutes autres solutions permettant d’installer des solutions logicielles assurant l’acheminement de données dans un réseau. Un tel déploiement requiert de s’assurer que le positionnement de l’unité permette de respecter des contraintes de placement et notamment d’acheminement mais aussi que l’unité puisse avoir les informations de configuration suffisantes pour émettre et recevoir des données d’une autre unité de l’infrastructure. Typiquement, dans une architecture Cloud RAN, l’unité DU doit être déployée dans un conteneur permettant de respecter un certain débit ou une certaine latence par exemple, mais aussi que l’unité DU soit configurée avec des identifiants, tel que des adresses IP, d’un CU et d’un RU. Le procédé de configuration permet ainsi d’une part d’obtenir des identifiants d’applications logicielles d’exploitation et de nœuds, physiques ou virtualisés, supportant ces conteneurs, ce qui permet d’acheminer les données d’un nœud et d’une application logicielle d’exploitation à une autre. Le procédé permet en outre de s’assurer du respect de contraintes de déploiement d’une unité par rapport à la position et à la capacité des applications logicielles d’exploitation et donc des nœuds comprenant ces applications logicielles d’exploitation grâce à une détermination de l’application logicielle d’exploitation à partir d’un test. A partir du résultat de ce test, il est alors possible de pouvoir configurer l’unité (CU, DU, ou RU dans l’exemple) dans une application logicielle d’exploitation déterminée, puisqu’il a été déterminé que l’application logicielle d’exploitation pouvait effectivement satisfaire le besoin. L’infrastructure d’accès peut en outre être initialisée grâce aux informations de configuration puisque chaque unité détient une information de configuration d’une autre unité avec laquelle l’unité configurée émet et reçoit des données en provenance ou à destination de terminaux attachés à l’infrastructure d’accès.

Selon un aspect de l'invention, dans le procédé de configuration, le critère de placement relatif à un flux de données correspond à un ou plusieurs des critères de la liste suivante :

- une sécurité du flux du flux de données,

- une qualité de service d’acheminement du flux de données,

- une consommation énergétique lié au flux de données,

- une latence du flux de données, - une gigue du flux de données,

- une perte de données dans le flux,

- un acheminement du flux de données par l’intermédiaire d’un nœud du réseau de communication,

- un acheminement du flux de données par l’intermédiaire d’une suite ordonnée de nœuds du réseau de communications.

Le déploiement d’unités d’infrastructure d’accès, qu’il s’agisse d’un déploiement initial ou d’une mise à jour d’une infrastructure d’accès avec de nouvelles unités, doit respecter certaines contraintes. Ainsi, le choix d’un conteneur est avantageusement déterminé en fonction d’un critère relatif à un critère de sécurité et de confidentialité de données gérées par un conteneur comprenant une unité, à un critère de QoS d’acheminement des données, de disponibilité d’une application logicielle d’exploitation et donc de l’unité supportée par l’application logicielle d’exploitation, de consommation énergétique de l’application logicielle d’exploitation dans l’environnement virtualisé pour acheminer le flux de données, ou bien encore de latence des données transitant par l’application logicielle d’exploitation. La détermination et la disponibilité d’un nœud du réseau par lequel un flux de données doit transiter peut également être utilisé comme critère de placement. Plusieurs de ces critères peuvent avantageusement être considérés dans le test pour déterminer l’application logicielle d’exploitation optimal pouvant héberger l’unité à configurer.

Selon un autre aspect de l’invention, dans le procédé de configuration, le test relatif à un critère de placement comprend une comparaison d’un délai d’acheminement d’un flux de données en provenance, respectivement à destination, de l’au moins une application logicielle d’exploitation et à destination, respectivement en provenance d’une autre application logicielle d’exploitation de l’environnement virtualisé, avec une valeur d’acheminement d’un flux de données de référence.

De façon plus spécifique, et parce que le délai d’acheminement doit être pris en compte par rapport à un trafic type (par exemple de type IoT (en anglais Internet of Things), de type streaming vidéo, de type voix...), il peut être avantageux d’évaluer une application logicielle d’exploitation par sa capacité à effectivement assurer un acheminement correspondant aux prérequis d’un trafic type sélectionné, par exemple en choisissant le service le plus contraignant en terme de délai de transit dans un ensemble de données associées à une pluralité de services. Selon un autre aspect de l’invention, dans le procédé de configuration, le test relatif à un critère de placement comprend une comparaison d’un délai d’acheminement et une mesure de qualité de service d’un flux de données en provenance, respectivement à destination, de l’au moins une application logicielle d’exploitation et à destination, respectivement en provenance d’une autre application logicielle d’exploitation de l’environnement virtualisé, avec des valeurs théoriques d’acheminement propres à une architecture spécifique du réseau de communication.

Les architectures des infrastructures, et notamment le choix du positionnement des différentes fonctions (modulation, codage...) dans une unité induit des capacités d’acheminement et de qualité de service spécifiques entre les unités. Par exemple, dans le cadre d’une architecture Cloud RAN, différents scénarios de déploiement ont été spécifiés, donnant lieu à des besoins spécifiques d’acheminement, telle que de débit, de latence ou plus globalement de qualité de service, par exemple. La comparaison de mesures de tests avec de tels besoins permet de déterminer le ou les application(s) logicielle(s) d’exploitation le(s) plus adapté(s) pour héberger une unité d’accès du réseau de communication.

Selon un autre aspect de l’invention, dans le procédé de configuration, l’au moins une application logicielle d’exploitation est en outre déterminée en fonction de la position géographique d’un équipement d’attachement du réseau de communication.

Notamment, pour la détermination de l’application logicielle d’exploitation apte à accueillir une entité positionnée au plus près d’un équipement d’attachement, tel qu’une antenne, le choix d’une application logicielle d’exploitation tient compte de la position de l’équipement d’attachement pour des raisons de déploiement, de latence des données, et de respects de conditions d’acheminement lié aux services dont les données sont acheminées sur le réseau de communication comprenant les applications logicielles d’exploitation.

Selon un autre aspect de l’invention, le procédé de configuration comprend en outre

- au moins une émission à destination d’une entité d’administration de l’environnement virtualisé d’un message de requête de l’au moins un nœud dans l’environnement virtualisé

- au moins une réception en provenance de l’entité d’administration de l’environnement virtualisé d’un message de réponse comprenant un identifiants de l’au moins un nœud. Le procédé peut avantageusement comprendre des étapes permettant à l’entité d’administration du réseau de communication d’obtenir régulièrement une mise à jour de l’environnement virtualisé et une liste des nœuds effectivement déployés supportant une application logicielle d’exploitation pouvant théoriquement accueillir une unité d’une infrastructure d’accès. Ces étapes, répétées dans le temps de façon périodique ou non, procure à l’entité d’administration du réseau de communication une connaissance à jour de l’environnement virtualisé utilisé pour le déploiement ou la mise à jour de l’infrastructure d’accès. L’entité d’administration de l’environnement virtualisé est, selon un exemple, un nœud « master Kubemetes ».

Selon un autre aspect de l’invention, dans le procédé de configuration, le message de réponse comprend en outre une donnée de localisation de l’au moins un nœud.

Le message de réponse reçu en provenance de l’entité d’administration de l’environnement virtualisé peut avantageusement comprendre des données de localisation des nœuds notamment dans la perspective de pouvoir déployer une unité de l’infrastructure au plus près d’un équipement d’attachement ou pour gérer les interactions nécessaires entre les unités de l’infrastructure en tenant compte des contraintes géographiques de leur instanciation dans les conteneurs compris dans les nœuds.

Selon un autre aspect de l’invention, le procédé de configuration comprend en outre la réception d’un message de commande d’une mise à jour du réseau de communication comprenant une donnée géographique d’au moins une unité d’accès du réseau.

Le message de réponse reçu en provenance de l’entité d’administration de l’environnement virtualisé peut avantageusement comprendre des données de localisation des nœuds notamment dans la perspective de pouvoir déployer une unité de l’infrastructure au plus près d’un équipement d’attachement ou pour gérer les interactions nécessaires entre les unités de l’infrastructure en tenant compte des contraintes géographiques de leur instanciation dans les conteneurs compris dans les nœuds.

Selon un autre aspect de l’invention, le procédé de configuration comprend en outre la réception d’un message de commande d’une mise à jour du réseau de communication comprenant une donnée géographique d’au moins une unité d’accès du réseau.

Le message de commande correspond par exemple à une nouvelle affiliation d’une unité d’accès. L’entité d’administration du réseau de communication reçoit une commande de mise à jour, pouvant correspondre à une instanciation initiale, d’une infrastructure d’accès du réseau de communication par exemple, un déploiement d’une unité CU, d’une unité DU et d’une unité RU. La commande comprend une donnée géographique, par exemple une donnée GPS, d’une unité d’accès pour couvrir ou améliorer la couverture d’une nouvelle zone géographique par exemple. Ce message de commande peut être émis par un administrateur réseau ou un logiciel externe tel qu’un logiciel ONAP (en anglais Open Network Automation Platform).

Selon un autre aspect de l’invention, dans le procédé de configuration, le message de configuration comprend en outre un paramètre de configuration relatif à un équipement d’attachement au réseau de communication.

Des paramètres de configuration relatifs à l’équipement d’attachement, par exemple à une antenne, peuvent être avantageusement transmis à une entité de médiation, notamment s’il s’agit d’une entité de médiation d’une unité en charge des fonctions devant être activées au plus près de l’équipement d’attachement, tel qu’une unité RU dans une infrastructure Cloud RAN. Il existe une dépendance forte entre un équipement d’attachement, tel qu’une antenne et un RU en particulier. Pour que le système d’accès déployé fonctionne correctement, le RU obtient un minimum d’information sur le type de l’antenne. Par exemple, concernant les paramètres de configuration, un code FPGA qui s’exécute dans l’antenne est nécessaire et il est avantageux d’avoir la version précise de l’antenne pour exécuter le bon code ou encore comment contacter l’antenne (port USB, interface réseau,...).

Selon un autre aspect de l’invention, le procédé de configuration comprend en outre un message d’obtention auprès d’une base de données d’un ensemble d’applications logicielles d’exploitation, ledit ensemble étant relatif à la donnée géographique d’une unité d’accès de l’infrastructure.

Notamment lorsqu’il a reçu un message de commande d’une mise à jour, l’entité d’administration du réseau de communication sollicite une base de données comprenant les nœuds et les applications logicielles d’exploitation de l’environnement virtualisé. La base de données retourne à l’entité d’administration des applications logicielles d’exploitation et possiblement des identifiants des nœuds supportant les applications logicielles d’exploitation correspondant à une donnée géographique, par exemple une donnée GPS, d’une unité d’accès, par exemple située au plus proche d’une antenne de l’infrastructure d’accès. Avantageusement, la base de données renvoie les adresses IP des applications logicielles d’exploitation pouvant accueillir des unités du réseau de communication ainsi que les adresses IP des nœuds comprenant ces applications logicielles d’exploitation. Ainsi, l’entité d’administration dispose d’une liste d’applications logicielles d’exploitation possibles parmi lesquels il déterminera les applications logicielles d’exploitation en charge d’accueillir les unités respectives en fonction de résultats de tests. La base de données peut en outre avantageusement comprendre et renvoyer des paramètres d’un équipement d’attachement (antenne), le type d’équipement d’attachement pouvant influer sur la localisation des unités de l’infrastructure dans applications logicielles d’exploitation.

Les différents aspects du procédé de configuration 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 procédé de gestion d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, ledit procédé étant mis en œuvre dans une entité de médiation de l’au moins une application logicielle d’exploitation et comprenant

- une émission à destination d’une entité d’administration du réseau de communication d’un message d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,

- une réception en provenance de l’entité d’administration du réseau de communication d’un message de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée par l’entité d’administration, ledit message de configuration comprenant un identifiant d’au moins une autre unité du réseau de communication,

- une configuration de l’au moins une application logicielle d’exploitation sur la base du message de configuration reçu,

- une activation de l’au moins une unité d’accès dans l’au moins application logicielle d’exploitation configurée.

L’invention concerne également un dispositif de configuration d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, et comprenant

- un récepteur, apte à recevoir en provenance d’une entité de médiation de l’au moins une application logicielle d’exploitation d’un message d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,

- un module de détermination, apte à déterminer, préalablement ou suite à la réception du message d’enregistrement, l’au moins une application logicielle d’exploitation pour accueillir l’au moins une unité en fonction d’un résultat d’un test relatif à un critère de placement relatif à un flux de données acheminé par l’au moins une unité,

- un émetteur, apte à émettre à destination de l’entité de médiation de l’au moins une application logicielle d’exploitation déterminée d’un message de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée, ledit message de configuration comprenant un identifiant d’au moins une autre unité accès du réseau de communication.

Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de configuration qui vient d'être décrit, est destiné à être mis en œuvre dans un équipement d’administration d’un réseau de communication ou bien dans un équipement de gestion d’une infrastructure d’accès, telle qu’une infrastructure C-RAN.

L’invention concerne également un dispositif de gestion d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, comprenant

- un émetteur, apte à émettre à destination d’une entité d’administration du réseau de communication, un message d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,

- un récepteur, apte à recevoir en provenance de l’entité d’administration du réseau de communication, un message de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée par l’entité d’administration, ledit message de configuration comprenant un identifiant d’au moins une autre unité du réseau de communication,

- un configurateur, apte à configurer l’au moins une application logicielle d’exploitation sur la base du message de configuration reçu,

- un activateur, apte à activer l’au moins une unité d’accès dans l’au moins application logicielle d’exploitation configurée.

Ce dispositif, apte à mettre en œuvre le procédé de gestion qui vient d'être décrit, est destiné à être mis en œuvre dans un équipement physique ou virtualisé, tel qu’un serveur ou une station d’accueil banalisée.

L’invention concerne également un système de configuration d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, et comprenant un dispositif de configuration et un dispositif de gestion.

L'invention concerne aussi des programmes d'ordinateur comprenant des instructions pour la mise en œuvre des étapes des procédés respectifs de configuration et de gestion 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 configuration et de gestion 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 [Fig 1] présente une vue simplifiée d’un réseau de communication dans lequel sont mis en œuvre le procédé de configuration et le procédé de gestion selon un aspect de l’invention,

La [Fig 2] présente une vue simplifiée d’un réseau de communication dans lequel sont mis en œuvre le procédé de configuration et le procédé de gestion selon un autre aspect de l’invention, La [Fig 3] présente un aperçu du procédé de configuration et du procédé de gestion selon un mode de réalisation de l’invention,

La [Fig 4] présente un dispositif de configuration selon un mode de réalisation de l'invention,

La [Fig 5] présente un dispositif de gestion selon un mode de réalisation 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 un réseau de communication. Ce réseau peut être mise en œuvre pour acheminer des données de communication à destination de terminaux fixes ou mobiles. L’invention peut être destinée à déployer ou mettre à jour des unités d’accès d’un réseau de communications, les unités d’accès étant définies comme des unités permettant à des terminaux d’acheminer des données à destination de serveurs de données ou d’autres terminaux via le réseau de communications.

On se réfère tout d’abord à la [Fig 1] qui présente une vue simplifiée d’un réseau de communication dans lequel sont mis en œuvre le procédé de configuration et le procédé de gestion selon un aspect de l’invention.

Un réseau 20 de communication est composé d’une unité d’accès RU, d’une entité DU et d’une entité CU permettant que des flux de données soient acheminés à destination et en provenance d’un réseau cœur CN. Le réseau 20 comprend en outre un équipement d’attachement 130, représenté par une antenne de type cellulaire selon cet exemple, permettant à un terminal 120 de pouvoir transmettre et recevoir des données via le réseau 20. L’équipement d’attachement 130 peut comprendre une pluralité d’antennes. Sur la [Fig 1], une seule unité de type RU, DU, CU ainsi qu’un seul équipement d’attachement n’est représenté mais un réseau peut comprendre une pluralité d’unités et d’équipement d’attachement peuvent être compris dans ce réseau 20. Cette structuration en trois unités RU/DU/CU d’un réseau est également identifiée dans l’art antérieur comme une architecture Cloud-RAN. Ainsi, au sein de l’organisme de normalisation 3GPP, la distribution des fonctions et des traitements permettant l’acheminement de données dans le réseau 20 dans l’une ou l’autre des unités RU/DU/CU donnent lieu à des discussions et à des spécifications. Ainsi, une dizaine d’options aussi appelées Split ont été définies au sein du 3GPP selon que l’on centralise ou non certaines fonctions en considérant l’impact sur les liens entre les unités et sur les services pour les utilisateurs. Par exemple, le split 7.3 prévoit d’encoder et de décoder les signaux dans l’unité DU et ainsi de réduire le coût financier des liaisons entre l’unité RU et l’unité DU, aussi appelée Fronthaul. Cette structuration du réseau 20 en unités s’accompagne par ailleurs d’une virtualisation des unités RU/DU/CU permettant d’en réduire le coût et d’en faciliter le déploiement et/ou la mise à jour par l’utilisation de nœuds banalisés, sous forme de serveurs informatiques, et de logiciels déployés sur ces nœuds, sous formes de VNFs (en anglais Virtual Network Functions) ou CNFs (en anglais Cloud Native Network Functions) selon le type d’infrastructure sélectionnée pour la mise en œuvre du réseau 20. Ces logiciels permettent ainsi de mettre en œuvre les différentes fonctions et traitement requis pour l’acheminement des données. Le déploiement d’un tel réseau 20 de type cloud RAN repose sur un découpage en trois zones géographiques, les espaces de données (en anglais clouds) régionaux, les espaces de données d’extrémité (en anglais edge clouds), les espaces de données de bordure (en anglais far edge clouds) notamment définie par l’alliance O-RAN (en anglais Open Radio Access Network). Dans la [Fig 1], est également représenté un environnement virtualisé 10. Selon cet exemple, l’environnement virtualisé 10 est basé sur une plate-forme Kubemetes, représentant une solution d’orchestration d’applications logicielles d’exploitation représentées ici par des conteneurs, mais il pourrait également s’agir d’une plate-forme de virtualisation distincte de Kubemetes. Cet environnement virtualisé est composé d’un maître Kubemetes KM et de nœuds KN 1 , KN2, KN3 qui peuvent être des machines physiques ou bien des machines virtuelles. Selon une alternative, l’équipement d’attachement 130, comprenant une ou plusieurs antennes, peut lui-même être un nœud tel que les nœuds KN1, KN2, KN3 et peut accueillir une unité CU, DU ou RU. Il est à noter que ce mode de réalisation est notamment pertinent pour le déploiement de l’unité RU dans un équipement disposant également d’une ou plusieurs antennes, de façon à réduire le temps de latence de transmission de données entre une antenne et l’unité RU. Chaque nœud contient les services nécessaires à l’exécution de Pods, c’est-à-dire des lieux d’exécution des applications logicielles d’exploitation. Sur la [Fig 1] sont représentés trois nœuds KN1, KN2 et KN3 mais un plus grand nombre de nœuds peuvent être compris dans l’environnement virtualisé 20. Les nœuds KN1, KN2 et KN3 comprennent respectivement les applications logicielles d’exploitation Cl, C2, C3. Conformément à l’architecture du réseau Cloud RAN décrit ci-dessus, le maître Kubemetes KM est déployé dans l’espace de données régional et les nœuds KN1, KN2 et KN3 sont déployés dans les espaces de données régionaux ou les espaces de données d’extrémité ou les espaces de données de bordure. Un administrateur réseau ou bien encore un logiciel tiers, par exemple de type ONAP (en anglais Open Network Automation Platform) requiert auprès du maître Kubemetes KM le déploiement d’applications logicielles d’exploitation Cl, C2, C3 dans les nœuds KN1, KN2, KN3. A ce stade, les applications logicielles d’exploitation Cl, C2 et C3 ne sont pas activées et ne sont pas en mesure d’acheminer des données. Cette étape permet d’initialiser les applications logicielles d’exploitation. Ces applications logicielles d’exploitation comprennent des entités de médiation permettant de pouvoir interagir avec le maître KM. Ainsi, une unité de type CU est déployée dans une application logicielle d’exploitation Cl du nœud KN1 régional, une unité de type DU est déployée dans une application logicielle d’exploitation C3 d’un nœud KN3 d’extrémité et une unité RU est déployée dans une application logicielle d’exploitation C2 d’un nœud KN2 de bordure. Le procédé de configuration, selon ce mode de réalisation, permet de déterminer le conteneur Cl, C2 ou C3 le plus adapté pour accueillir une unité d’accès donnée et de pouvoir configurer cette unité sur l’application logicielle d’exploitation la plus adaptée, notamment par rapport à la situation géographique de l’équipement d’attachement et/ou de critères de placement relatif à un flux de données, par exemple émis ou reçu par le terminal 120, acheminé par une unité d’accès donnée. Le positionnement de l’unité RU par rapport à l’équipement d’attachement est en particulier à considérer sachant qu’il est important d’éviter une latence trop forte entre l’antenne et l’unité RU.

En relation avec la [Fig 2], on présente une vue simplifiée d’un réseau de communication dans lequel sont mis en œuvre le procédé de configuration et le procédé de gestion selon un autre aspect de l’invention.

Dans cette [Fig 2], on retrouve les mêmes entités que celles présentées dans la [Fig 1] ainsi qu’une entité 100 d’administration du réseau 20 de communications. Cette entité 100 d’administration, qui peut également être dénommée BCRS (en anglais Bootstrapper cloud-RAN server) peut être, selon un exemple, être déployée dans un espace de données régional et permet notamment de gérer la liste des ressources hardware et d’assurer leur gestion. Il permet en outre de mettre en relation les différents éléments du Cloud RAN et notamment les différentes unités RU/DU/CU, ainsi que la gestion des performances et notamment les mesures de performances entre les unités RU/DU/CU. Cette entité est distincte d’un maître KM mais selon une alternative, il peut être instancié dans un maître KM. Dans la [fig 2] sont également représentés des entités de médiation EM1, EM2, et EM3 des applications logicielles respectives d’exploitation Cl, C2, C3. Une entité de médiation EM1 ou EM2 ou EM3 est également dénommée B CRC (en anglais Bootstrapper Cloud-RAN client) et permet notamment à une application logicielle d’exploitation (Cl ou C2 ou C3) d’interagir avec l’entité 100 d’administration.

L’entité d’administration, préalablement à la réception en provenance d’une entité de médiation de l’une des applications logicielles d’exploitation EM1, EM2, EM3 peut, selon un exemple, requérir auprès du maître KM une liste de nœuds KN1, KN2 et KN3 qu’il gère. En retour, le maître KM retourne à l’entité d’administration 100 une liste d’ identifiants, tels que des adresses IP s’il s’agit d’un réseau IP, des nœuds KN1, KN2 et KN3, ainsi qu’une information ou un label sur la zone géographique dans laquelle est déployée un réseau de communication à 3 niveaux : régional, extrémité et bordure dans laquelle se trouve le nœud KN1, KN2 ou KN3 ainsi que possiblement un état du nœud pour indiquer s’il est effectivement actif ou non dans l’espace virtualisé 10. Ces informations reçues par l’entité 100 d’administration pourront être sauvegardées ensuite dans une base de données, et ainsi être disponibles en cas de besoin. Durant cette phase de découverte de l’environnement virtualisé 10 par l’entité 100 d’administration, la recherche de l’ensemble des équipements d’accès, ici représentés par l’antenne 130 est effectuée. Cette recherche est effectuée en sollicitant les nœuds parmi les nœuds KN1, KN2, KN3 se trouvant dans un espace de données de bordure et en outre dans un état actif ou prêt ou encore prêt dans un intervalle de temps, sachant que seul un espace de données de bordure est apte à comprendre une antenne à laquelle le terminal 120 peut s’attacher. En l’occurrence, selon l’exemple décrit pour la [Fig 1], l’entité 100 d’administration sollicite le nœud KN2 pour rechercher si une antenne est disponible mais selon un exemple où une pluralité de nœuds localisés dans des espaces de données de bordure sont disponibles, l’entité 100 d’administration solliciterait ces différents nœuds. En retour, les nœuds sollicités transmettent à l’entité 100 d’administration les paramètres de connexion à une antenne tels que les ports USB, les informations de types FPGA (en anglais Field Programmable Gâte Array) propre à l’antenne, le type d’antenne et les coordonnées de localisation de l’espace de données de bordure, tel qu’une information de localisation GPS (en anglais Global Positioning System). Selon une alternative, l’entité 100 d’administration peut transmettre une requête à une base de données topologique comprenant l’ensemble des informations des déploiements d’équipements physiques d’une zone pour obtenir les informations sur les antennes disponibles dans des espaces de données de bordure. Pour cibler ces espaces de données de bordure, les identifiants des nœuds des espaces de données de bordure peuvent selon un exemple être transmis en paramètre de la requête transmise. L’entité 100 d’administration peut également sauvegarder ces informations reçues sur les antennes dans une base de données. Ces différentes étapes de découvertes de nœuds et d’antennes par l’entité 100 d’administration peuvent être répétées pour que l’entité 100 d’administration ait une cartographie à jour. L’entité 100 d’administration peut également procéder à la configuration d’une unité en l’absence de ces étapes, par exemple en recourant à une base de données qu’il aura lui- même mis à jour ou mise à jour par une autre entité.

Selon une alternative, ou pour mettre à jour un réseau d’accès dans un environnement virtualisé, un administrateur réseau ou bien encore un logiciel tiers, par exemple de type ONAP sollicite l’entité 100 d’administration pour déployer une ou plusieurs unités CU/DU/RU dans l’espace virtualisé 20. Selon un exemple, une information de localisation d’une unité RU est transmise en paramètre de cette sollicitation par exemple pour couvrir ou améliorer la couverture du réseau de communication à trois niveaux donnée correspondant à l’information de localisation de l’entité RU, proche d’une antenne de réception. L’entité 100 d’administration peut ainsi requérir auprès d’une base de données, qu’il aura lui-même précédemment mis à jour ou non, une liste de nœuds KN1, KN2, KN3 susceptibles de répondre aux besoins de la demande de déploiement. La base de données peut rechercher les nœuds KN1, KN2, KN3 les plus proches de l’information de localisation reçue lors de la demande de déploiement et transmise à la base de données. La base de données transmet en retour à l’entité 100 d’administration les associations nœuds (KN1, KN2, KN3)/applications logicielles d’exploitation (Cl, C2, C3) qu’elle juge possible pour le déploiement ou la mise à jour du cloud RAN. L’ensemble des combinaisons pour l’unité CU, c’est-à-dire un identifiant de l’unité CU et identifiant du nœud KN1 ou KN2 ou KN3, et de la même façon pour l’unité DU et l’unité RU. Les paramètres de l’équipement d’attachement peuvent également être transmis. L’entité 100 d’administration procède à une affiliation CU/DU/RU/antenne en fonction de la réponse reçue de la base de données. Les nœuds retenus à cette étape sont alors candidats à une sélection pour évaluer leur capacité à être conforme à des critères de placement voire des critères de localisation.

En lien avec la [Fig 3], on présente un aperçu du procédé de configuration et du procédé de gestion selon un mode de réalisation de l’invention. Dans ce mode de réalisation, les applications logicielles d’exploitation sont des conteneurs. Dans cette [Fig 3], on retrouve les mêmes entités que celles présentées dans la [Fig 1] et le [Fig 2]

Fors d’une étape E 1 , les entités de médiation EM 1 , EM2 et EM3 des conteneurs respectifs Cl, C3, C3 transmettent respectivement à l’entité 100 d’administration des messages d’enregistrement des conteneurs Cl, C2, C3. Ces messages d’enregistrement envoyés individuellement par chaque entité de médiation EM1, EM2 et EM3 comprennent un identifiant du conteneur considéré, tel qu’une adresse IP ainsi qu’un identifiant du nœud sur lequel est déployé le conteneur. Selon ce mode de réalisation, et en cohérence avec les [Fig 1] et [Fig 2], les entités de médiation EM1, EM2, EM3 transmettront respectivement un identifiant, tel qu’une adresse IP, des nœuds KN1, KN2 et KN3. Il est à noter que selon une alternative, seule une ou plusieurs entités de médiation parmi EM1, EM2, EM3 peuvent transmettre un message d’enregistrement à l’entité 100 d’administration. Les identifiants, ici les adresses IP, sont par exemple allouées dynamiquement aux conteneurs Cl, C2 et C3 ainsi qu’aux nœuds KN1, KN2, KN3 et ne peuvent être connues de l’entité 100 d’administration avant cet envoi et le démarrage effective du conteneur.

De façon optionnelle, lors d’une étape E2, l’entité 100 de médiation peut sauvegarder les données reçues lors de l’étape El et relatives aux conteneurs dans une base de données, par exemple identique à celle décrite dans la [Fig 2], permettant ainsi de pouvoir être réutilisées le cas échéant.

Il est à noter que cette étape d’enregistrement peut se produire après l’étape d’initialisation des conteneurs telle que décrite dans la [Fig. 1]

En outre, cette étape E 1 peut être exécutée suite ou précédemment à une étape d’ affiliation CU/DU/RU/antenne telle que décrite dans la [Fig 2]

Lors d’une étape E3, l’entité 100 d’administration détermine un conteneur pour accueillir une unité CU/DU/RU en fonction d’un résultat d’un test relatif à un critère de placement lié à un flux de données acheminé par l’unité à déployer dans un conteneur. Il est à noter que cette étape E3 de détermination peut se produire avant l’étape El et suite aux étapes d’initialisation et d’affiliation décrites dans les [Fig 1] et [Fig 2]

Un exemple d’étape de détermination est décrit ci-dessous. Afin de déterminer les conteneurs aptes à accueillir une unité CU et/ou une unité DU et/ou une unité RU, l’entité 100 d’administration demande au master KM (non représenté sur la [Fig 3] mais représentés sur les [Fig 1] et [Fig 2]), la création de l’ensemble des conteneurs nécessaires pour simuler un trafic d’un cloud RAN et en obtenir les informations résultant de cette simulation. Le Master KM crée les conteneurs suivantes dans un espace de données régional : un émetteur pour émettre les données pour simuler le flux de données en aval (en anglais download), un récepteur pour recevoir les données dans le sens amont (en anglais upload), une unité CU de test permettant de router les données d’un flux vers une unité DU de test dans le sens aval et vers le récepteur de l’espace de données régional dans le sens amont. Le Master KM crée en outre une unité DU dans un espace de données d’extrémité pour que celui-ci route les données vers une unité RU dans le sens aval et vers l’unité CU dans le sens amont. Le master KM crée en outre dans un espace de données de bordure un récepteur pour réceptionner les données d’un flux dans le sens aval, un émetteur pour envoyer des données d’un flux simulé dans le sens amont et une unité RU pour acheminer les données vers le récepteur de l’espace de données de bordure dans le sens aval et vers l’unité DU de test dans le sens amont.

Un flux de données de test est généré et transmis par les émetteurs respectifs des espaces de données à destinations des récepteurs respectifs pour simuler les flux de données aval et amont. Selon un exemple, les flux de données caractérisant des options d’architecture d’une infrastructure Cloud RAN sont émis, ces flux de données pouvant être différenciés selon le sens de transmission, amont ou aval, et selon les technologies des interfaces entre les entités de l’infrastructure.

L’entité 100 d’administration récupère ensuite les informations enregistrées dans les différentes entités de tests créées dans les espaces régionaux, d’extrémité et de bordure. Ces informations enregistrées comprennent par exemple des paramètres de qualité d’acheminement du flux de données tel que par exemple le débit réel atteint, des critères de disponibilité de l’unité, des critères énergétiques tels que la consommation énergétique de l’unité pour acheminer le flux de données, un critère de latence, de gigue du flux de données, un critère de perte de données voire un critère d’acheminement par un équipement en particulier ou non. Ces critères de placement obtenus permettent de pouvoir qualifier une unité et son bon ou mauvais placement dans l’environnement virtualisé.

Le test relatif à un ou plusieurs critères de placement peut avantageusement comprendre une comparaison avec une valeur de référence pour le flux de données, tel que par exemple un délai d’acheminement de référence. Notamment, pour déterminer un conteneur apte à accueillir une unité, l’entité 100 d’administration peut comparer un délai d’acheminement d’un flux de données dans une unité déployé dans un conteneur Cl, C2, C3 de l’environnement virtualisé avec une valeur de référence d’une architecture spécifique du réseau de communication Cloud RAN, comme par exemple présentée dans le tableau ci-dessus, et à l’aide du résultat de cette comparaison, déterminer si le conteneur Cl, C2 ou C3 est apte à accueillir une unité CU ou DU ou RU. Selon une autre alternative, la valeur de référence est relative à un flux de données spécifique, par exemple d’un flux de données requérant une exigence particulière en termes de fiabilité et/ou de délai d’acheminement et/ou de latence.

Il est à noter que selon une alternative, le conteneur peut être également déterminé en fonction d’une position géographique d’un équipement d’attachement, tel qu’une antenne d’un réseau cellulaire par exemple. Notamment, le conteneur parmi les conteneurs Cl, C2, C3 pourra être sélectionné pour accueillir une unité RU en fonction de la position géographique d’une antenne de façon à réduire au maximum le délai de transit de données entre l’antenne et l’entité RU.

De façon optionnel, l’entité 100 d’administration requiert auprès des nœuds des espaces de données sur lesquels ont été instanciés les différents entités de tests la suppression de ces entités (émetteurs, récepteurs, CU de test, DU de test, RU de test) créées pour effectuer les tests requis pour la détermination des conteneurs Cl, C2, C3 aptes à accueillir les unités CU/DU/RU en fonction des critères utilisés et possiblement des informations de localisation citées ci-dessus.

Il est à noter que le mode de réalisation développé ci-dessus pour déterminer un ou plusieurs conteneurs est cité à titre d’exemple et que d’autres options sont possibles pour déterminer le(s) conteneur(s) tels que des résultats d’enregistrement de données relatives à des conteneurs déjà déployés ou déployés précédemment ou bien encore en utilisant des valeurs théoriques par exemple à partir d’abaques.

Dans le cas où aucun conteneur ne répond aux exigences (débit, latence, fiabilité...), de nouveaux nœuds candidats pour accueillir des conteneurs pourront être sélectionnés et évalués conformément à l’étape de détermination décrite ci-dessus. Ces nouveaux nœuds seraient alors identifiés dans une nouvelle étape d’affiliation.

Lors d’une étape E4, l’entité 100 d’administration émet à destination des entités de médiation EM1, EM2, EM3 des conteneurs Cl, C2, C3 respectifs sélectionnés suite à l’étape E3 de détermination et dûment enregistrés sur les nœuds respectifs KN1, KN2, KN3 un message de configuration d’une unité CU dans le conteneur Cl, d’une unité DU dans le conteneur C3 et d’une unité RU dans le conteneur C2. Le message de configuration comprend, selon un exemple, les adresses IP des unités, la version de logiciels utilisés dans les unités, l’antenne à utiliser pour l’unité RU voire des configurations réseau spécifiques tels que des protocoles et des numéros de ports, vore même une durée de vie des entités de médiation. Le message de configuration transmis à l’entité de médiation EM1 du conteneur Cl, visant à configurer une unité CU, comprend en outre un identifiant, tel que par exemple une adresse IP, de l’unité DU permettant ainsi à l’unité CU de connaître l’entité DU avec laquelle il échangera les données des flux. Le message configuration transmis à l’entité de médiation EM3 du conteneur C3, visant à configurer une unité DU, comprend en outre un identifiant, tel que par exemple une adresse IP, de l’unité CU ainsi qu’un identifiant (adresse IP) d’une unité RU. L’entité DU connaît ainsi les entités CU et RU avec lesquelles il communique dès son initialisation et sans configuration statique des conteneurs Cl et C3. Le message de configuration transmis à l’entité de médiation EM2 du conteneur C2, visant à configurer une unité RU, comprend en outre un identifiant, tel que par exemple une adresse IP, de l’unité DU permettant ainsi à l’unité RU de connaître l’entité DU avec laquelle il échangera les données des flux. Ce message de configuration, transmis à l’entité de médiation EM2 comprend en outre des données caractérisant un équipement d’attachement, tel qu’une antenne, ne serait-ce que pour que l’unité RU puisse communiquer avec l’équipement d’attachement en utilisant la bonne interface et le bon algorithme de codage/décodage des données.

Lors d’une étape E5, les entités de médiation EM1, EM2 et EM3 ayant reçu les informations de configuration des conteneurs Cl, C2, C3 leur permettant d’effectivement accueillir les entités respectives CU, RU et DU configurent ces conteneurs avec les informations obtenues de façon à ce que l’infrastructure Cloud RAN puisse être initialisée ou bien mise à jour.

Lors de l’étape suivante E6, les entités EM1, EM2 et EM3 démarrent les applications logicielles correspondant aux unités CU/DU/RU dans les conteneurs Cl, C3 et C2 respectifs. Le service d’accès au réseau élaboré à partir des unités d’accès CU/DU/RU dans les conteneurs Cl, C3, C2 déterminés en fonction de leur capacité à satisfaire des critères de placement, voire à répondre à une contrainte de localisation et déployés sur des nœuds physiques ou virtualisés KN1, KN3 et KN2, peut démarrer.

Selon une alternative, les étapes E5 et E6 peuvent être exécutées conjointement et le démarrage des applications logicielles peut être effectué lors de la configuration des unités Cl, C2, C3 par les entités de médiation respectives EM1, EM2 et EM3.

En relation avec la [Fig 4], on présente un dispositif 500 de configuration selon un mode de réalisation de l'invention.

Un tel dispositif de configuration peut être mis en œuvre dans un équipement d’administration, tel que l’entité 100 d’administration du réseau selon les [Fig 2] et (Fig 3], d’un réseau de communication ou bien dans un équipement de gestion d’une infrastructure d’accès, telle qu’une infrastructure C-RAN.

Par exemple, le dispositif 500 comprend une unité de traitement 530, équipée par exemple d'un microprocesseur mR, et pilotée par un programme d'ordinateur 510, stocké dans une mémoire 520 et mettant en œuvre le procédé de configuration selon l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 510 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 530. Un tel dispositif 500 de configuration comprend :

- un récepteur 501, apte à recevoir en provenance d’une entité de médiation de l’au moins une application logicielle d’exploitation d’un message Enr d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,

- un module 502 de détermination, apte à déterminer, préalablement ou suite à la réception du message d’enregistrement, l’au moins une application logicielle d’exploitation pour accueillir l’au moins une unité en fonction d’un résultat d’un test relatif à un critère de placement relatif à un flux de données acheminé par l’au moins une unité,

- un émetteur 503, apte à émettre à destination de l’entité de médiation de l’au moins une application logicielle d’exploitation déterminée d’un message Conf de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée, ledit message de configuration comprenant un identifiant d’au moins une autre unité accès du réseau de communication.

La [Fig 5] présente un dispositif 600 de gestion selon un mode de réalisation de l'invention. Un tel dispositif de gestion peut être mis en œuvre dans est destiné à être mis en œuvre dans un équipement physique ou virtualisé, tel qu’un serveur ou une station d’accueil banalisée.

Par exemple, le dispositif 600 comprend une unité de traitement 630, équipée par exemple d'un microprocesseur mR, et pilotée par un programme d'ordinateur 610, stocké dans une mémoire 620 et mettant en œuvre le procédé de configuration selon l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 610 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 630. Un tel dispositif 600 de configuration comprend : - un émetteur 601, apte à émettre à destination d’une entité d’administration du réseau de communication, un message Enr d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,

- un récepteur 602, apte à recevoir en provenance de l’entité d’administration du réseau de communication, un message Conf de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée par l’entité d’administration, ledit message de configuration comprenant un identifiant d’au moins une autre unité du réseau de communication,

- un configurateur 603, apte à configurer l’au moins une application logicielle d’exploitation sur la base du message de configuration reçu,

- un activateur 604, apte à activer l’au moins une unité d’accès dans l’au moins application logicielle d’exploitation configurée.