EP4699275A1

EP4699275A1 - Emulateur d'un réseau à topologie variable et procédé d'émulation

Info

Publication number: EP4699275A1
Application number: EP25710887.8A
Authority: EP
Inventors: Duc Pham-Minh
Original assignee: Airbus Defence and Space SAS
Current assignee: Airbus Defence and Space SAS
Priority date: 2024-03-18
Filing date: 2025-03-11
Publication date: 2026-02-25
Also published as: FR3160287A1; WO2025195857A1; FR3160287B1

Abstract

L'invention concerne un système (10) d'émulation d'un réseau à topologie variable, comportant un contrôleur (20), un système (30) de commutation et des noeuds (40) de réseau. Chaque nœud comporte un module d'émulation permettant d'émuler une couche physique, et un module applicatif avec des couches protocolaires de niveau supérieur à tester. Au cours de l'exécution d'un scénario de test, le module d'émulation de chaque nœud est configuré pour calculer des informations instantanées d'état du nœud et des caractéristiques instantanées des liens en provenance et à destination du nœud. Le module applicatif du nœud est adapté pour émettre et recevoir des paquets via le module d'émulation, et pour réaliser un routage des paquets en fonction des informations instantanées du nœud et des liens. Chaque module d'émulation est configuré pour contrôler l'émission et la réception de paquets en fonction des caractéristiques instantanées des liens de communication.

Description

Emulateur d’un réseau à topologie variable et procédé d’émulation

Domaine de l’invention

La présente invention appartient au domaine des télécommunications, et plus particulièrement aux systèmes permettant de prototyper, développer et tester des applicatifs fonctionnant sur des réseaux à topologie variable. L’invention concerne notamment un système d’émulation d’un réseau à topologie variable. L’invention est particulièrement bien adaptée pour émuler un réseau non-terrestre comportant une composante spatiale et/ou aérienne et impliquant un grand nombre de noeuds.

Etat de la technique

La sixième génération de technologies de communication cellulaire, ou 6G, promet d'apporter des améliorations significatives notamment en termes de vitesse, de fiabilité, de couverture et de nouvelles fonctionnalités. Parmi ces évolutions, la standardisation des réseaux non-terrestres (ou NTN pour « Non-Terrestrial Networks » en anglais) est un sujet de grande importance.

Les réseaux non-terrestres comprennent les réseaux de communication qui ne sont pas basés exclusivement sur une infrastructure terrestre fixe, par exemple les systèmes de communication par satellite, y compris les constellations en orbite basse (LEO pour « Low Earth Orbit »), en orbite moyenne (MEO pour « Medium Earth Orbit ») et en orbite géostationnaire (GEO pour « Geostationary Orbit »), ainsi que d'autres plateformes aériennes telles que les HAPS (acronyme anglais pour « High Altitude Pseudo- Satellites », en français « pseudo-satellites à haute altitude), les ballons ou les drones.

Les réseaux non-terrestres subissent des modifications fréquentes de leur topologie en particulier en raison de la mobilité de certaines de leurs infrastructures, des délais de propagation variables dans le temps, des perturbations (obstructions, atténuation atmosphérique, interférences, doppler, erreurs de transmission, etc.) des liens de communication radio ou optiques. Les protocoles réseaux terrestres, qui fonctionnent pour des topologies quasi fixe avec des liens à faible latence et faible taux d’erreur (fibre optique, câble, faisceau hertzien) doivent donc être adaptés pour fonctionner dans un réseau NTN. Dans le cadre de la norme 6G, la standardisation des NTN porte notamment sur la gestion de la mobilité et sur l'intégration transparente des réseaux terrestres et non-terrestres. Il apparaît donc le besoin de fournir un outil permettant de prototyper, développer et tester les réseaux non-terrestres. Il existe des solutions pour émuler un lien physique point à point (solution de type HIL, acronyme anglais de « Hardware In the Loop », en français « matériel dans le circuit (de simulation) »). Ces solutions se focalisent sur l’aspect modulation/démodulation pour un lien spécifique entre deux noeuds. Ces solutions nécessitent des équipements matériels et ne sont donc pas adaptées pour des réseaux comportant plusieurs centaines de noeuds et plusieurs milliers de liens entre ces noeuds notamment en raison du coût du matériel, des difficultés pratiques liées au câblage et à l’encombrement qui en résulterait.

La demande de brevet EP2955876A1 propose la simulation de multiples liens de communication entre les noeuds d’un réseau, en utilisant un ensemble de modules simulés interconnectés virtuellement. Une telle solution ne permet pas notamment de maîtriser de manière précise l'évolution au cours du temps de la qualité de transmission (débit, délai, gigue, taux d’erreur, rapport signal à bruit, interférences, doppler, etc.) des liens de communication et donc manque de précision pour tester de façon réaliste les algorithmes de routage.

Exposé de l’invention

La présente invention vise à fournir une solution de test pour prototyper, développer et tester un réseau de communication à topologie variable tout en permettant une meilleure représentativité du réseau. La solution est particulièrement bien adaptée pour émuler un réseau non-terrestre comprenant une composante spatiale et/ou aérienne et comportant plusieurs centaines de noeuds mobiles.

A cet effet, et selon un premier aspect, il est proposé un système d’émulation d’un réseau à topologie variable, comportant un contrôleur, un système de commutation et des noeuds de réseau comprenant chacun un module applicatif.

Le contrôleur est adapté pour générer, en fonction d’un scenario de test mémorisé, des informations d’états des noeuds et des caractéristiques de liens de communication susceptibles d’être établis entre les modules applicatifs des noeuds au cours du scénario, les informations d’états des noeuds et les caractéristiques des liens de communication étant établies sous forme de séries temporelles.

Chaque nœud comporte un module d’émulation de liens émulant une couche protocolaire physique et s’interfaçant avec le module applicatif, le module applicatif comprenant des couches protocolaires de niveau supérieur à la couche protocolaire physique, chaque module d’émulation comportant une mémoire pour stocker des informations d’états spécifiques à ce nœud et des caractéristiques des liens de communication en provenance et à destination de ce nœud fournies sous forme de séries temporelles par le contrôleur.

Le contrôleur est configuré pour transmettre aux modules d’émulation de liens une commande de début d’exécution commune à l’ensemble des nœuds.

Chaque nœud est configuré pour fonctionner de manière autonome en cours d’exécution pour traiter des paquets en émission ou en réception et pour traiter les séries temporelles spécifiques à ce nœud en fonction d’un temps virtuel :

- chaque module d’émulation de liens est adapté à mettre à jour régulièrement, à partir des séries temporelles spécifiques au nœud, des informations instantanées d’état du nœud et des caractéristiques instantanées des liens de communication en provenance et à destination du nœud,

- chaque module d’émulation est configuré pour contrôler l’émission et la réception de paquets de trafic en fonction des caractéristiques instantanées des liens de communication, et

- chaque module applicatif est adapté pour émettre et recevoir des paquets via le module d’émulation et réaliser un routage pouvant être fonction des informations instantanées d’état et des caractéristiques instantanées des liens de communication mises à jour par le module d’émulation.

Avantageusement, le système selon l’invention permet d'évaluer les performances d’un réseau non-terrestre en prenant en compte les spécificités de la couche physique (délai variable, erreurs, pertes de paquet) et de développer et tester des algorithmes de routage avancés exploitant des informations relatives à l’état des nœuds et les caractéristiques des liens de communication entre les nœuds.

Dans des modes particuliers de réalisation, le système d’émulation peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles.

Dans des modes particuliers de réalisation, le contrôleur est colocalisé avec le système de commutation.

Dans des modes particuliers de réalisation, le contrôleur est distant et connecté au système de commutation au travers d’un réseau étendu WAN (acronyme anglais pour « Wide Area Network ») public ou privé.

Dans des modes particuliers de réalisation, les informations d’états des nœuds générées par le contrôleur, en fonction du scenario de test, comprennent des informations géographiques relatives à des trajectoires des noeuds, sous forme de série temporelle.

Dans des modes particuliers de réalisation, les informations d’états des noeuds générées par le contrôleur, en fonction du scenario de test, comprennent des informations géométriques relatives aux géométries des noeuds, sous forme de série temporelle.

Dans des modes particuliers de réalisation, le scénario de test contient des paramètres géographiques et géométriques des noeuds, des paramètres de communication des noeuds, des propagateurs utilisés pour calculer des trajectoires des noeuds et une définition des liens de communication à prendre en compte entre les noeuds. Le scenario de test comprend aussi une heure de début et une heure de fin.

Dans des modes particuliers de réalisation, le système de commutation est configuré par le contrôleur pour établir des réseaux virtuels au-dessus de liens physiques (31 , 33, 35) du système de commutation. Ces réseaux virtuels sont destinés à être gérés par le système de commutation et configurés en fonction des liens de communication susceptibles d’être établis entre les modules applicatifs au cours du scénario. Ces réseaux virtuels restent inchangés au cours du scenario

Dans des modes particuliers de réalisation, l’étendue des réseaux virtuels est strictement limitée aux liens susceptibles d’être établis selon le scenario.

Dans des modes particuliers de réalisation, le contrôleur mémorise une pluralité de scénarios de test sélectionnables par un utilisateur et exécutés séparément.

Dans des modes particuliers de réalisation, au moins un des noeuds du réseau correspond à un satellite ou un aéronef.

Dans des modes particuliers de réalisation, pour chaque nœud, la mémoire du module d’émulation pour stocker les informations d’états spécifiques au nœud et les caractéristiques des liens de communication en provenance et à destination du nœud fournies sous formes de séries temporelles est une mémoire non partagée. Seules les informations instantanées d’état du nœud et les caractéristiques instantanées des liens de communication, mises à jour régulièrement par le module d’émulation, sont rendues accessibles au module applicatif.

Dans des modes particuliers de réalisation, chaque module d’émulation est configurable en mode pas à pas, en mode ralenti, en mode accéléré ou en mode temps réel, à partir de commandes de mode opératoire envoyées par un mécanisme de diffusion à l’ensemble des nœuds. Le module d’émulation de liens est configuré pour calculer un temps virtuel à partir de la commande de mode opératoire, tandis que le module applicatif est configuré pour fonctionner en temps réel.

Dans des modes particuliers de réalisation, le traitement d’un paquet en réception par le module d’émulation de liens en provenance d’un autre nœud comporte l’une au moins des opérations suivantes, en fonction de caractéristiques instantanées en réception du lien sur lequel le paquet est reçu :

- une suppression du paquet si le lien n’est pas opérationnel,

- un ajout d’un délai de transmission,

- un ajout d’au moins une erreur au niveau bit ou au niveau trame dans le paquet pour simuler une erreur de transmission.

Dans des modes particuliers de réalisation, le traitement d’un paquet en émission par le module d’émulation de liens vers un autre nœud comporte une fonction de lissage du trafic en fonction de caractéristiques instantanées en émission du lien sur lequel le paquet est à émettre.

Dans des modes particuliers de réalisation, dans au moins un des nœuds, le module d’émulation de liens est configuré pour multiplexer plusieurs liens virtuels entre le module applicatif et un ou plusieurs autres modules applicatifs sur un unique lien physique du système de commutation.

Dans des modes particuliers de réalisation, dans au moins un des nœuds, le module d’émulation de liens est configuré pour multiplexer plusieurs liens virtuels entre le module applicatif et un ou plusieurs autres modules applicatifs sur plusieurs liens physiques du système de commutation.

Dans des modes particuliers de réalisation, au moins un serveur implémente une pluralité de nœuds, chaque nœud étant implémenté sur une machine virtuelle du serveur, chaque machine virtuelle implémentant un module d’émulation de liens sur un premier cœur et un module applicatif sur un deuxième cœur.

Dans des modes particuliers de réalisation, au moins un des nœuds est réalisé par un équipement réel comprenant le module applicatif, l’équipement réel étant interfacé avec le module d’émulation.

Dans des modes particuliers de réalisation, au moins un serveur implémente une pluralité de nœuds, les modules d’émulation des nœuds étant implémenté sur un cœur dédié du serveur et les modules applicatifs étant implémentés sur un ou plusieurs cœurs distincts du cœur dédié.

Selon un deuxième aspect, il est proposé un procédé d’émulation d’un réseau à topologie variable. Le procédé est mis en œuvre par un système d’émulation comportant un contrôleur, un système de commutation et des nœuds de réseau comprenant chacun un module applicatif. Le procédé comprend :

- une étape de simulation, dans laquelle le contrôleur génère, en fonction d’un scenario de test mémorisé, des informations d’états des nœuds et des caractéristiques de liens de communication susceptibles d’être établis entre les modules applicatifs des nœuds au cours du scénario, les informations d’états des nœuds et les caractéristiques des liens de communication étant établies sous forme de séries temporelles,

- une étape de configuration des nœuds, dans laquelle le contrôleur fournit à chaque nœud les informations d’états spécifiques à ce nœud et les caractéristiques des liens de communication en provenance et à destination de ce nœud, chaque nœud comportant un module d’émulation de liens émulant une couche protocolaire physique et s’interfaçant avec le module applicatif, le module applicatif comprenant des couches protocolaires de niveau supérieur à la couche protocolaire physique,

- une étape de lancement du scénario de test, dans laquelle le contrôleur transmet aux modules d’émulation de liens une commande de début d’exécution commune à l’ensemble des nœuds,

- une étape d’exécution du scénario de test dans laquelle chaque nœud fonctionne de manière autonome pour traiter des paquets en émission ou en réception et pour traiter les séries temporelles spécifiques à ce nœud en fonction d’un temps virtuel, l’étape d’exécution comprenant pour chaque nœud les sous-étapes suivantes : o une mise à jour régulière, par le module d’émulation de liens, à partir des séries temporelles spécifiques au nœud, d’informations instantanées d’état du nœud et de caractéristiques instantanées des liens de communication en provenance et à destination du nœud, o un contrôle de paquets en réception ou en émission par le module d’émulation à partir des caractéristiques instantanées des liens de communication en provenance et à destination du module applicatif, o un routage de paquets, dans lequel le module applicatif émet et reçoit des paquets via le module d’émulation et réalise un routage pouvant être fonction des informations instantanées d’état du nœud et des caractéristiques instantanées des liens de communication mises à jour par le module d’émulation.

Dans des modes particuliers de mise en œuvre, le procédé d’émulation peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles.

Dans des modes particuliers de mise en œuvre, le procédé d’émulation comprend, préalablement à l’étape de simulation, une étape préliminaire de définition, par un utilisateur, d’un scénario de test contenant des paramètres géographiques et géométriques des nœuds, des paramètres de communication des nœuds, des propagateurs utilisés pour calculer des trajectoires des nœuds et une définition des liens de communication à prendre en compte entre les nœuds, une heure de début et une heure de fin.

Dans des modes particuliers de mise en œuvre, le procédé d’émulation comprend, préalablement à l’exécution du scénario, une étape de configuration du système de commutation dans laquelle le contrôleur établit des réseaux virtuels au-dessus de liens physiques (31 , 33, 35) du système de commutation. Ces réseaux virtuels sont destinés à être gérés par le système de commutation et sont configurés en fonction des liens de communication susceptibles d’être établis entre les modules applicatifs au cours du scénario, ces réseaux virtuels restant inchangés au cours du scenario.

Dans des modes particuliers de mise en œuvre, l’étendue des réseaux virtuels est strictement limitée aux liens de communications susceptibles d’être établis durant le scénario.

Dans des modes particuliers de mise en œuvre, le procédé d’émulation comprend une étape de configuration, pilotée par le contrôleur, d’au moins un serveur implémentant une pluralité de nœuds, chaque nœud étant implémenté sur une machine virtuelle du serveur, chaque machine virtuelle implémentant un module d’émulation de liens sur un premier cœur et un module applicatif sur un deuxième cœur.

Dans des modes particuliers de mise en œuvre, le procédé d’émulation comprend une diffusion, par le contrôleur à destination des nœuds du système, d’une commande de mode opératoire permettant de configurer l’exécution en mode pas à pas, en mode ralenti, en mode accéléré ou en mode temps réel, et une étape de traitement de la commande de mode opératoire par le module d’émulation de liens de chaque nœud, la commande de mode opératoire comportant optionnellement un temps virtuel de synchronisation entre les noeuds.

Dans des modes particuliers de mise en oeuvre, le procédé d’émulation comprend une étape de validation et/ou d’analyse comprenant une analyse de traces et/ou de statistiques de chaque nœud acquises directement par les modules applicatifs et/ou par un nœud de supervision du réseau récupérant des informations en provenance des modules applicatifs supervisés.

Présentation des figures

L’invention sera mieux comprise à la lecture de la description suivante, donnée à titre d’exemple nullement limitatif, et faite en se référant aux figures 1 à 9 qui représentent :

[Fig. 1] une représentation schématique d’un système d’émulation selon l’invention pour un réseau non-terrestre impliquant des communications par satellite,

[Fig. 2] une représentation schématique des couches protocolaires du modèle OSI mises en œuvre respectivement dans le système réel et le système émulé selon l’invention,

[Fig. 3] un exemple de réalisation du contrôleur du système d’émulation, avec une illustration schématique de son fonctionnement,

[Fig. 4] un exemple de réalisation du système d’émulation selon l’invention, avec un grand nombre de nœuds implémentés par des machines virtuelles sur des serveurs et un équipement réel,

[Fig. 5] un premier exemple d’implémentation d’un nœud sur une machine virtuelle d’un serveur,

[Fig. 6] un deuxième exemple d’implémentation d’un nœud sur une machine virtuelle d’un serveur permettant de maximiser les débits en entrée et sortie de nœud,

[Fig. 7] un exemple d’implémentation de plusieurs nœuds sur une machine virtuelle d’un serveur,

[Fig. 8] une représentation schématique du traitement des liens de communication en émission et en réception par le module d’émulation des liens,

[Fig. 9] une représentation schématique des principales étapes d’un procédé d’émulation d’un réseau à topologie variable.

Dans ces figures, des références identiques d’une figure à une autre désignent des éléments identiques ou analogues. Pour des raisons de clarté, les éléments représentés ne sont pas nécessairement à une même échelle, sauf mention contraire.

Description détaillée de l’invention

Comme expliqué précédemment, l’invention permet de réaliser, dans un environnement de laboratoire, un jumeau numérique d’un réseau réel existant ou en cours de développement. L’invention est particulièrement bien adaptée à un réseau présentant un grand nombre de noeuds dont les positions peuvent varier au cours du temps. Cette variabilité de la topologie du réseau peut concerner non seulement les noeuds utilisateurs, mais aussi les noeuds correspondant à des éléments de l’infrastructure du réseau, comme par exemple des routeurs embarqués dans des satellites en orbite autour de la Terre, dans des plateformes aériennes (drones, avions, ballons), ou dans des véhicules terrestres (trains, bateaux).

La figure 1 illustre, à titre d’exemple, une communication entre un serveur et un utilisateur au sein d’un réseau non-terrestre. La communication implique différents noeuds intermédiaires de routage entre le serveur et l’utilisateur, notamment une station passerelle, un satellite géostationnaire, un satellite en orbite basse, et un avion. La partie supérieure de la figure 1 représente le réseau réel, tandis que sa partie inférieure représente le jumeau numérique du réseau réel, c’est-à-dire le réseau émulé.

Tel qu’illustré sur la figure 1 , un système 10 d’émulation permet de d’émuler le réseau réel. Le système 10 d’émulation comporte un contrôleur 20, un système 30 de commutation et des noeuds 40 interconnectés par le système 30 de commutation. Par exemple, le contrôleur 20 peut être implémenté sur un ordinateur (station de travail), les noeuds 40 peuvent être implémentés par des machines virtuelles exécutées sur une baie de serveurs ou des machines réelles, et le système 30 de commutation peut comprendre un ou plusieurs commutateurs Ethernet et des liens physiques d’interconnexion tels que des câbles Ethernet.

Le contrôleur 20 peut notamment permettre de créer un scénario de test via une interface homme-machine (IHM), de définir les caractéristiques des noeuds et des liens de communication reliant les différents noeuds au cours du scénario, de configurer le système, puis de lancer et contrôler l’exécution du scénario à distance.

Les caractéristiques des noeuds définissent notamment les mouvements des différents noeuds au cours du scénario (par exemple en termes de position, de vitesse, d’attitude, de trajectoire, d’orientation d’une ou plusieurs antennes du nœud, etc.). Les caractéristiques des liens de communication définissent notamment une qualité de transmission (autrement dit un bilan de liaison, par exemple en termes de débit, de délai de propagation, de taux d’erreur, d’atténuation, etc.) de chaque lien susceptible d’être établi entre deux noeuds dans le scénario considéré. Chaque lien de communication du système émulé peut ainsi correspondre à un lien filaire, un lien radio ou un lien optique du réseau réel.

La solution proposée suit une approche mixte combinant simulation et émulation. Dans un premier temps, les mouvements des différents noeuds et les caractéristiques des liens de communication sont simulés dans un scénario de test, sans nécessiter de temps réel ; dans un deuxième temps, le comportement de la couche physique des différents noeuds au cours du scénario est émulé en temps réel. De telles dispositions permettent de déboguer les couches de niveau supérieur à la couche physique en temps réel.

La figure 2 illustre schématiquement comment les différentes couches protocolaires du modèle OSI (acronyme anglais de « Open Systems Interconnection », en français « interconnexion des systèmes ouverts ») sont implémentées dans le système 10 d’émulation. Chaque nœud 40 comporte un module 41 d’émulation de liens permettant d’émuler la couche physique (couche de plus bas niveau), et un module 42 applicatif comprenant des couches protocolaires de niveau supérieur à tester. Ces couches de niveau supérieur correspondent aux couches du modèle OSI situées au-dessus de la couche physique (couche de liaison, couche de réseau, couche de transport, couche de session, couche de présentation et couche d’application). Il s’agit des couches protocolaires telles qu’elles sont destinées à être implémentées dans les équipements du réseau réel. Tel qu’illustré sur la figure 2, le système 30 de commutation assure la communication entre les modules 41 d’émulations de lien.

Ainsi, en exécutant le scénario de test dans le système 10 d’émulation, il est possible de déboguer, tester et valider en temps réel les couches protocolaires situées au- dessus de la couche physique.

En particulier, le système 10 d’émulation permet de tester les couches protocolaires relatives au routage des paquets de données échangés sur le réseau (notamment la couche de liaison, la couche de réseau et la couche de transport). Dans un réseau à topologie fixe (par exemple un réseau internet), le routage est généralement optimisé en fonction du trafic et des contraintes de coût et de qualité de service. Dans un réseau de type cellulaire, il convient en outre d’optimiser le routage en fonction de critères radio et de la mobilité des utilisateurs. Dans un réseau non-terrestre, il convient de prendre également en compte la position des éléments mobiles d’infrastructure du réseau (plateformes spatiales ou aériennes notamment). Les algorithmes de routage deviennent alors particulièrement complexes. A titre d’exemple nullement limitatif, dans un réseau de communication impliquant des satellites en orbite basse (LEO) ou en orbite moyenne (MEO), les algorithmes de routage doivent prendre en compte la nécessité de limiter voire d’empêcher les émissions dans certaines régions géographiques, notamment aux alentours de l’arc géostationnaire, au niveau des pôles, ou au-dessus de certains pays. Les algorithmes de routage peuvent également prendre en compte la position des noeuds pour déterminer s’ils sont en visibilité l’un de l’autre (« en ligne de vue », LOS en anglais pour « Line Of Sight »), ainsi que l’orientation des antennes des noeuds.

Le module 41 d’émulation de liens et le module 42 applicatif sont des modules logiciels implémentés sur une même machine (une machine réelle, une machine virtuelle, ou un équipement du réseau). Comme on le verra par la suite, chaque module 41 d’émulation de liens s’interface directement avec un ou plusieurs liens physiques du système 30 de commutation.

La figure 3 représente schématiquement un exemple de réalisation du contrôleur 20 du système 10 d’émulation, et ses interactions avec le système 30 de commutation et les différents noeuds 40.

Tel qu’illustré sur la figure 3, le contrôleur 20 comporte une interface 21 homme-machine (IHM), un module 22 de génération de scénario, un module 23 de simulation et un module 24 d’orchestration.

L’interface 21 homme-machine permet à un utilisateur de créer un scénario 26 de test, de configurer le système 10 d’émulation, et de lancer et de contrôler l’exécution de l’émulation. L’interface 21 homme-machine comporte par exemple une interface de programmation (API pour « Application Programming Interface ») pour la création du scénario 26 et une interface graphique (GUI pour « Graphical User Interface ») pour l’analyse des résultats de simulation, pour le contrôle de l’exécution de l’émulation et/ou pour l’analyse des résultats d’émulation.

Le module 22 de génération de scénario permet de créer des scénarios de test à partir d’une bibliothèque 25 d’objets et de l’interface 21 homme-machine. La bibliothèque 25 contient différents types d’objets et différents types de liens de communication entre les objets. Chaque objet associe par exemple une plateforme (satellite, avion, station sol, utilisateur piéton, etc.) avec des fonctions de communication bas niveau (émetteur, récepteur) et une charge utile applicative (routeur, serveur, générateur de trafic, etc.). Les liens de communication sont unidirectionnels et permettent de relier des émetteurs et des récepteurs pour des calculs de bilans de liaison.

Il convient toutefois de noter que le module 22 de génération de scénario n’est pas indispensable à l’invention. Rien n’empêcherait par exemple que le scénario de test soit généré par un dispositif distinct du contrôleur 20 et fourni au contrôleur 20 (par exemple via un moyen de communication ou via une mémoire de stockage amovible). Aussi, le contrôleur 20 peut optionnellement mémoriser une pluralité de scénarios prédéterminés et sélectionnâmes par un utilisateur (chaque scénario étant destiné à être exécuté individuellement).

A partir du scénario 26, le module 23 de simulation permet de définir, sous forme de séries temporelles, d’une part des informations 27 d’états des noeuds 40 et d’autre part des caractéristiques 28 de liens de communication susceptibles d’être établis entre les modules 42 applicatifs des noeuds 40 au cours du scénario 26. Les informations 27 d’états des noeuds sont des informations relatives au mouvement des noeuds au cours du scénario. Chaque lien correspond à un lien unidirectionnel virtuel, simulé par le scénario de test, reliant directement deux noeuds entre eux. Les caractéristiques du lien sont des informations relatives à une qualité de transmission du lien. L’expression « sous forme de séries temporelles » signifie que les informations comportent des valeurs prises par différents paramètres à différents instants au cours du scénario, chaque instant correspondant à un pas de simulation du scénario, par exemple toutes les secondes, toutes les dix secondes ou toutes les minutes.

Le module 23 de simulation peut notamment être mis en oeuvre par un simulateur orbital tel que STK (acronyme de « System Tool Kit » en anglais).

Les informations 27 d’états (ou informations de plateforme) d’un nœud 40 concernent par exemple la position, la vitesse ou l’attitude d’un nœud au cours du temps (elles représentent par exemple la position orbitale et l’attitude d’un satellite en orbite autour de la Terre). Elles peuvent également concerner des informations relatives aux géométries des nœuds, comme par exemple l’orientation d’une ou plusieurs antennes du nœud. Ces caractéristiques sont déterminées pour chaque pas de simulation du scénario, et elles permettent de déterminer les liens de communication existant au pas de simulation considéré. Par exemple, pour deux nœuds correspondant à des satellites en orbite, il est possible de déterminer, à chaque pas de simulation, si les deux satellites sont en visibilité directe (LOS). Si c’est le cas, on considère qu’un lien de communication est opérationnel entre les deux nœuds, et les caractéristiques 28 du lien de communication peuvent être calculées. Les caractéristiques 28 d’un lien de communication sont par exemple relatives à un débit, un délai de propagation, une gigue, un taux d’erreur au niveau bit (BER pour « Bit Error Rate » en anglais) ou au niveau trame (FER pour « Frame Error Rate » en anglais), un niveau de doppler, un taux d’interférence, un rapport signal sur bruit, une atténuation de signal, un bruit thermique, etc.

Le module 24 d’orchestration permet notamment de configurer le système 30 de commutation, de piloter un hyperviseur 51 d’un logiciel de virtualisation (par exemple un logiciel de type VMWare) pour créer les machines virtuelles destinées à implémenter des noeuds 40 sur un ou plusieurs serveurs 50, de configurer les modules 41 d’émulation des différents noeuds 40 du système 10, puis de lancer et contrôler l’exécution du scénario en temps réel.

Lors de la configuration, le contrôleur 20 télécharge dans chaque module 41 d’émulation de liens les informations 27 d’états spécifiques à ce nœud et les caractéristiques 28 des liens de communication en provenance et à destination du module 42 applicatif de ce nœud.

A la fin de la phase de configuration, le contrôleur 20 transmet aux modules 41 d’émulation de liens une commande de début d’exécution commune à l’ensemble des nœuds. Cette commande de début d’exécution peut être transmise aux différents modules 41 d’émulation de liens par un mécanisme de diffusion (« broadcast » en anglais) sur le système 30 de commutation. La commande de début d’exécution peut comporter une heure virtuelle correspondant au début du scénario de test. Alternativement, chaque nœud peut être configuré par défaut avec une heure virtuelle de début de scénario.

Au cours de l’exécution du scénario (c’est-à-dire pendant la phase d’émulation), le contrôleur 20 n’intervient plus pour définir l’état du système à un instant donné. Au contraire, la détermination des caractéristiques des nœuds et des liens de communication à un instant donné est effectuée de façon autonome par les modules 41 d’émulation de liens.

Cette distribution, au niveau des modules 41 d’émulations de liens, de la détermination des caractéristiques des nœuds et des liens de communication permet d’éviter les problèmes inhérents à une architecture centralisée (notamment en termes de synchronisation, de charge de calcul du contrôleur 20, et de flux de contrôle entre le contrôleur 20 et les nœuds 40). Elle permet en outre un contrôle à distance sans impact sur les performances de l’émulation.

Pendant l’émulation, il est possible de tirer parti du fait que l’exécution des couches protocolaires est beaucoup plus rapide (de l’ordre de la milliseconde) que le pas de simulation (de l’ordre d’une ou plusieurs secondes) pour adapter la vitesse de l’émulation au besoin de l’utilisateur : vitesse ralentie ou en mode pas à pas pour le débogage, vitesse accélérée pour la validation, ou temps réel pour une démonstration.

Ainsi, un ou plusieurs des modes opératoires suivants peuvent être supportés pendant la phase d’exécution du scénario :

- mode temps réel,

- mode ralenti, avec une exécution plus lente que le temps réel,

- mode accéléré, avec une exécution plus rapide que le temps réel,

- mode pas à pas.

Chaque mode opératoire est basé sur le temps réel (le système 10 d’émulation est donc un système « compatible temps réel »). Chaque mode opératoire peut éventuellement être effectué en avant ou en arrière (c’est-à-dire selon le sens normal d’écoulement du temps, ou en sens inverse). A chaque changement de mode opératoire au cours de l’exécution du scénario, le contrôleur 20 est configuré pour diffuser une commande (commande de mode opératoire) au module 41 d’émulation de liens de chacun des noeuds 40. Le contrôle de l’émulation par l’utilisateur peut se faire via l’interface 21 homme-machine. On peut également prévoir la possibilité de démarrer l’exécution d’un scénario 26 à partir d’un instant spécifié par l’utilisateur. Le module 41 d’émulation de liens de chaque nœud 40 est configuré pour calculer un temps virtuel (T_v) en fonction de l’heure virtuelle du début du scénario (T_o), d’une horloge interne (T_R), et du mode opératoire courant (T_v = T_o + k.T_R, avec k > 1 en mode accéléré, k < 1 en mode ralenti et k = 1 en mode temps réel). L’horloge interne du module 41 d’émulation de liens correspond par exemple à une horloge du serveur hébergeant la machine virtuelle sur laquelle le nœud est implémenté. Les horloges des différents nœuds sont synchronisées avant le lancement de l’exécution de l’émulation (par exemple via la commande de début d’exécution), et on considère qu’une éventuelle dérive temporelle entre les horloges des différents nœuds est ensuite négligeable pendant l’exécution du scénario. Optionnellement, la commande de mode opératoire peut comporter un temps virtuel de synchronisation entre les nœuds.

La figure 4 représente schématiquement un exemple de réalisation d’un système 10 d’émulation selon l’invention, avec un grand nombre de nœuds 40 implémentés par des machines virtuelles exécutées sur différents serveurs 50.

Dans l’exemple considéré, chaque serveur 50 peut implémenter un ou plusieurs noeuds 40. Chaque serveur 50 comporte une ou plusieurs interfaces physiques (par exemple des ports Ethernet) pour s’interconnecter avec le système 30 de commutation.

Il convient de noter que, tel qu’illustré sur la figure 4, un nœud 40 peut aussi être implémenté par un équipement réel 60 destiné à être embarqué dans une charge utile d’un satellite, d’un avion, d’un drone ou d’une plateforme terrestre. Ces dispositions permettent de valider les couches protocolaires à tester (c’est-à-dire le module 42 applicatif) sur le véritable matériel sur lequel elles seront implémentées dans le réseau réel. L’équipement réel est dans ce cas interfacé avec un module 41 d’émulation de liens.

Le système 30 de commutation permet de relier chaque nœud 40 au contrôleur 20 et aux autres nœuds 40 par l’intermédiaire de liens physiques 31 , 33, 35. Les liens physiques correspondent par exemple à des câbles Ethernet (câble électrique ou fibre optique). Dans l’exemple considéré, le système 30 de commutation comporte un commutateur 32 haut débit directement relié au contrôleur et plusieurs commutateurs 34 d’accès de débit inférieur reliés chacun au commutateur 32 haut débit et à plusieurs nœuds 40. Les différents commutateurs 34 d’accès permettent d’offrir un nombre suffisant de ports Ethernet.

Dans un exemple de réalisation, le système 10 d’émulation comporte une baie de seize serveurs 50, un système 30 de commutation et un contrôleur 20. Chaque serveur 50 comporte vingt-quatre interfaces Ethernet à 25 Gbps (vingt-cinq gigabits par seconde). Le système 30 de commutation comporte un commutateur 32 offrant huit ports Ethernet à 100 Gbps et un port à 10 Gbps ainsi que quatre commutateurs 34 offrant 96 ports Ethernet à 25 Gbps. Le lien 31 de connexion entre le contrôleur 20 et le commutateur 32 est un câble Ethernet à 10 Gbps dans le cas où le contrôleur 20 et le système 30 de commutation sont situés sur le même réseau local (LAN Local Area Network) ou une liaison longue distance au travers un réseau WAN (Wide Area Network) privé ou public si le contrôleur 20 et le système de commutation ne sont pas colocalisés. Les liens 33 de connexion entre le commutateur 32 et les commutateurs 34 sont des câbles Ethernet à 100 Gbps. Les liens 35 de raccordement entre les commutateurs 34 les nœuds 40 sont des câbles Ethernet à 25 Gbps.

Le système 30 de commutation permet de faire une séparation physique entre les différents nœuds 40. Chaque nœud 40 est raccordé au système 30 de commutation par l’intermédiaire du module 41 d’émulation de liens et d’au moins un lien 35 de raccordement. Les noeuds 40 peuvent communiquer entre eux uniquement par l’intermédiaire du système 30 de commutation. Même pour des noeuds implémentés sur une même machine virtuelle ou sur plusieurs machines virtuelles hébergées sur un même serveur, il n’y a aucune communication directe entre les noeuds 40. De telles dispositions permettent de maximiser la représentativité du système sous test.

L’architecture matérielle formée par le système 30 de commutation permet également de garantir la bande passante nécessaire pour les communications en provenance ou à destination des noeuds 40. Le délai de transit introduit par le réseau de commutateur est généralement inférieur à dix microsecondes ; la gigue introduite est généralement inférieure à 2 microsecondes.

Pour limiter la bande passante nécessaire sur le système 30 de commutation, le contrôleur 20 peut être configuré pour déterminer une pluralité de réseaux locaux virtuels (VLAN pour « Virtual Local Area Network » en anglais) sur le système 30 de commutation. Des VLANs différents peuvent être associés aux différents liens possibles entre les noeuds afin de réduire les engorgements au niveau des commutateurs 32, 34. La configuration du système 30 de commutation consiste à définir des réseaux virtuels entre les noeuds susceptibles d’être interconnectés au cours du scénario. Dans des modes particuliers de mise en oeuvre, l’étendue des réseaux virtuels est strictement limitée aux liens susceptibles d’être établis selon le scenario le test.

Ainsi, la configuration matérielle du système 30 de commutation peut rester la même d’un scénario à l’autre (le branchement du contrôleur 20, des différents noeuds 40 et des commutateurs 32, 34 avec les liens physiques 31 , 33, 35 reste inchangé), mais des VLANs différents peuvent être configurés sur le système 30 de commutation d’un scénario à l’autre. La configuration des VLANs reste fixe pendant la durée d’une émulation (exécution d’un scénario) et a pour but de réduire les besoins en bande passante sur le système 30 de commutation. La possibilité ou non de communiquer entre deux noeuds à un instant donné est gérée dynamiquement par les modules 41 d’émulation de liens.

Un VLAN commun à tous les noeuds permet au contrôleur 20 de communiquer avec l’ensemble des noeuds 40 en utilisant des mécanismes de diffusion Ethernet, notamment pour l’envoi de la commande de début d’exécution ou pour une commande relative à un changement de mode opératoire (mise en pause, passage en mode pas à pas, lecture ralentie ou accélérée, etc.). Les figures 5 à 7 représentent schématiquement différents exemples d’implémentation d’un nœud 40 sur une machine virtuelle d’un serveur 50.

Dans le premier exemple d’implémentation illustré à la figure 5, et dans le deuxième exemple d’implémentation illustré à la figure 6, chaque nœud 40 est implémenté par une machine virtuelle. Chaque machine virtuelle est gérée par un hyperviseur 51 d’un logiciel de virtualisation exécuté sur le serveur 50. Chaque machine virtuelle est formée par deux cœurs 52 de processeur du serveur 50. Le premier cœur (« cœur 1 ») est utilisé pour faire fonctionner le module 41 d’émulation de liens. Le deuxième cœur (« cœur 2 ») est utilisé pour faire fonctionner le module 42 applicatif (c’est-à-dire les couches protocolaires situées au-dessus de la couche physique).

Le module 42 applicatif s’interface au système 30 de commutation par l’intermédiaire du module 41 d’émulation de liens. Dans ce but, le module 42 applicatif s’interface au module 41 d’émulation de liens par l’intermédiaire d’un ou plusieurs liens 45 virtuels représentant chacun un lien unidirectionnel entre le nœud 40 et un autre nœud. Des interfaces 44 virtuelles sont associées respectivement à chaque lien 45 virtuel établi entre le module 42 applicatif et le module 41 d’émulation de lien. A titre d’exemple, un nœud 40 de type satellite peut présenter simultanément plus d’une dizaine de liens 45 virtuels opérationnels, par exemple quatre liens inter-satellite, deux liens « feeder » et sept liens utilisateurs. Le module 41 d’émulation de liens s’interface avec le système 30 de commutation via au moins une interface 43 Ethernet physique (port Ethernet) et au moins un lien 35 physique (câble Ethernet de raccordement).

Dans le premier exemple d’implémentation illustré à la figure 5, le module 41 d’émulation de liens est configuré pour multiplexer plusieurs liens 45 virtuels sur un unique lien physique 35 du système 30 de commutation. La norme VXLAN (acronyme anglais de « Virtual extensible Local Area Network ») peut être utilisée pour le multiplexage des liens.

Dans le deuxième exemple d’implémentation illustré à la figure 6, le module 41 d’émulation de liens est configuré pour multiplexer plusieurs liens 45 virtuels sur plusieurs liens 35 physiques du système 30 de commutation. Par exemple, chaque lien 45 virtuel peut être associé respectivement à un lien 35 physique. Rien n’empêcherait toutefois d’envisager d’autres configuration de multiplexage, comme par exemple multiplexer plusieurs liens 45 de type « utilisateur » sur un même lien physique, mais associer chaque lien 45 de type « inter-satellite » ou « feeder » à un lien physique différent. Ainsi, la bande passante d’un lien 35 physique peut être plus ou moins partagée entre un ou plusieurs liens 45 virtuels. Cela permet de gérer des noeuds présentant des liens 45 virtuels avec de fortes contraintes de débit. En contrepartie, le nombre de noeuds pouvant être supporté par le système est réduit.

Dans le troisième exemple d’implémentation illustré à la figure 7, une même machine virtuelle implémente plusieurs noeuds 40. En particulier, le premier cœur implémente les différents modules 41 d’émulation de liens, tandis que le deuxième cœur implémente les modules 42 applicatifs des différents nœuds 40. De telles dispositions permettent d’augmenter la capacité d’émulation (augmentation du nombre de nœuds 40 pouvant être supporté par le système 10 d’émulation).

Dans ces différents exemples, la séparation du module 41 d’émulation de liens et du module 42 applicatif d’un même nœud 40 sur deux cœurs distincts permet une meilleure isolation des fonctionnalités de chacun. Cela permet d’éviter que l’émulation n’impacte le fonctionnement des couches protocolaires à tester. On obtient ainsi une meilleure représentativité du système sous test.

Il convient de noter que les exemples de réalisation décrits en référence aux figures 5 à 7 ne sont nullement limitatifs. D’autres modes de réalisation d’un nœud 40 peuvent être envisagés. Par exemple, il est envisageable d’implémenter le module 41 d’émulations de liens et le module 42 applicatif d’un nœud 40 sur un même cœur dans deux conteneurs logiciels distincts.

Une mémoire de type RAM (« Random Access Memory », en français « mémoire à accès aléatoire », également appelée « mémoire vive ») est par exemple associée à chaque module 41 d’émulation de liens pour stocker les informations 27 d’états et les caractéristiques 28 de liens de communication spécifiques au nœud associé pour le scénario considéré.

Au cours de l’exécution du scénario de test, chaque nœud 40 est configuré pour fonctionner de manière autonome pour traiter des paquets en émission ou en réception et pour traiter les séries temporelles spécifiques à ce nœud en fonction du temps virtuel calculé par le module 41 d’émulation.

Chaque module 41 d’émulation de liens est configuré pour mettre à jour régulièrement, à partir des séries temporelles spécifiques au nœud, des informations instantanées d’état du nœud et des caractéristiques instantanées des liens de communication en provenance et à destination du nœud, pour le temps virtuel calculé. Tel qu’illustré sur les figures 5 à 7, une mémoire de type RAM, partagée entre les deux cœurs de la machine virtuelle, peut être utilisée pour permettre au module 41 d’émulation de liens de passer les valeurs instantanées 53 des informations d’état et des caractéristiques de liens au module 42 applicatif. Ces valeurs instantanées 53 sont destinées à être utilisées par le module 42 applicatif pour mettre en oeuvre un ou plusieurs algorithmes de routage de paquets. La fréquence à laquelle les informations instantanées sont mises à jour est par exemple définie en fonction du pas de simulation. En particulier, un pas de temps virtuel calculé en fonction du pas de simulation peut être utilisé pour mettre à jour les informations instantanées d’état du nœud et les caractéristiques instantanées des liens de communication en provenance et à destination du nœud. Le pas de temps virtuel peut correspondre au pas de simulation, ou à un sous-échantillonnage ou un suréchantillonnage du pas de simulation.

Ainsi, pendant l’exécution du scénario, chaque module 42 applicatif est adapté pour émettre et recevoir des paquets via le module 41 d’émulation et pour réaliser un routage pouvant être fonction des informations instantanées d’état des nœuds et des caractéristiques instantanées des liens de communication mises à jour par le module 41 d’émulation. Chaque module 41 d’émulation est configuré pour contrôler l’émission et la réception des paquets de trafic en fonction des caractéristiques instantanées des liens de communication.

Les opérations de mise à jour des informations instantanées et de traitement des paquets en émission ou en réception sont effectuées de façon autonome par les modules 41 d’émulations de lien, indépendamment du contrôleur 20. Autrement dit, ces opérations ne sont pas déclenchées par le contrôleur 20 (le système 10 d’émulation repose sur une architecture distribuée, et non pas sur une architecture centralisée). Les modules 41 d’émulation de liens fonctionnent de manière synchronisée sans intervention du contrôleur 20, sauf éventuellement pour ce qui concerne les commandes de changement de mode opératoire.

Dans des modes particuliers de mise en œuvre, la mémoire du module 41 d’émulation pour stocker les informations 27 d’états spécifiques au nœud et les caractéristiques 28 des liens de communication en provenance et à destination du nœud est une mémoire non partagée. Seules les informations instantanées d’état du nœud et les caractéristiques instantanées des liens de communication, mises à jour régulièrement par le module 41 d’émulation, sont rendues accessibles au module 42 applicatif. De telles dispositions permettent d'éviter que le module applicatif n'ait accès à des données auquel il n'a pas accès dans la réalité (notamment sur l'évolution des liens dans le futur). La figure 8 illustre schématiquement le traitement de paquets en émission et en réception par un module 41 d’émulation de liens.

Tel qu’illustré sur la figure 8, les caractéristiques 28 des liens de communication comprennent des caractéristiques 28a en émission (puissance, bande passante, etc.), des caractéristiques 28b en réception (gain d’antenne, puissance du signal d’entrée, taux d’erreur, délai de propagation, atténuations diverses, etc.). Les liens 45 sont unidirectionnels mais chaque module 41 d’émulation gère à la fois l’émission et la réception de paquets. Par exemple, un sous module d’émission utilise les valeurs instantanées 53a des caractéristiques 28a en émission pour traiter des paquets émis par le module 42 applicatif sur un lien 45a virtuel à destination d’un autre nœud. En parallèle, un sous module de réception utilise les valeurs instantanées 53b des caractéristiques 28b en réception pour traiter des paquets reçus en provenance d’un autre nœud à destination du module 42 applicatif.

Le traitement d’un paquet en réception par le module 41 d’émulation de liens en provenance d’un autre nœud comporte l’une au moins des opérations suivantes, en fonction des caractéristiques instantanées 53b en réception du lien sur lequel le paquet est reçu :

- une suppression du paquet si le lien n’est pas opérationnel (par exemple si le lien n’existe pas parce que les deux nœuds reliés par le lien ne sont pas en visibilité directe),

- un ajout d’un délai de transmission (un délai de transmission de plusieurs dizaines voire plusieurs centaines de millisecondes peut être observé pour un lien sol- satellite),

Le traitement d’un paquet en émission par le module 41 d’émulation de liens vers un autre nœud comporte une fonction de lissage du trafic, en fonction des caractéristiques instantanées 53a en émission du lien sur lequel le paquet est à émettre. La fonction de lissage peut notamment comporter une mise en file d’attente du paquet pour respecter un débit de transmission du lien sur lequel le paquet doit être émis.

La figure 9 représente schématiquement les principales étapes d’un procédé 100 d’émulation d’un réseau à topologie variable. Ce procédé 100 est par exemple mis en œuvre par un système 10 d’émulation tel que décrit précédemment en référence aux figures 1 à 8. Tel qu’illustré sur la figure 9, le procédé 100 d’émulation peut comporter tout d’abord une étape de définition 110 d’un scénario 26 de test. Cette étape de définition 1 10 permet de spécifier les types de noeuds formant le réseau, et les types de liens pouvant exister entre ces noeuds 40 au cours du scénario. Cette étape de définition 1 10 est par exemple mise en oeuvre à l’aide de l’interface 21 homme-machine et du module 22 de génération de scénario décrit précédemment en référence à la figure 3. Comme expliqué précédemment, cette étape est optionnelle et rien n’empêcherait de considérer que la génération du scénario 26 de test ne fait pas partie du procédé 100 d’émulation (dans ce cas le scénario de test est une donnée d’entrée du procédé 100 d’émulation).

Le scénario 26 de test peut contenir des paramètres géographiques et géométriques des noeuds, des paramètres de communication des noeuds, des propagateurs utilisés pour calculer des trajectoires des noeuds (notamment pour la prise en compte des perturbations J2 et J4 pour la propagation d'orbite) et une définition des liens de communication à prendre en compte entre les noeuds. Le scénario peut également contenir une heure de début et une heure de fin.

Le procédé 100 d’émulation comporte une étape de simulation 120 au cours de laquelle le contrôleur 20 génère, en fonction du scenario 26 de test, les informations 27 d’états des noeuds et les caractéristiques 28 de liens de communication susceptibles d’être établis entre les modules 42 applicatifs des noeuds 40 au cours du scénario 26. Pour rappel, les informations 27 d’états des noeuds et les caractéristiques 28 des liens de communication sont établies sous forme de séries temporelles. Cette étape de simulation 120 est par exemple mise en oeuvre à l’aide du module 23 de simulation décrit précédemment en référence à la figure 3.

Le procédé 100 comporte ensuite une étape d’initialisation 130, qui comporte notamment la configuration 133 des modules 41 d’émulation de liens.

Pour cette configuration 133, le contrôleur 20 fournit à chaque nœud 40 les informations 27 d’états spécifiques à ce nœud et les caractéristiques 28 des liens de communication en provenance et à destination de ce nœud. La configuration 133 des nœuds peut également comprendre la configuration des interfaces Ethernet 43 et des interfaces 44 virtuelles des modules 41 d’émulation pour les liens 35 et 45 avec respectivement le système 30 de commutation et le module 42 applicatif.

Pour chaque nœud 40 implémenté sur une machine virtuelle d’un serveur 50, l’étape d’initialisation 130 peut également comporter le chargement 132 sur la machine virtuelle d’une image disque correspondant audit nœud 40. Ce chargement de l’image disque du nœud est par exemple mis en œuvre par un hyperviseur 51 d’un logiciel de virtualisation exécuté sur le serveur 50.

L’étape d’initialisation 130 peut également comporter la configuration 131 du système 30 de commutation. Comme cela a été expliqué précédemment, la configuration 131 du système 30 de commutation peut notamment comporter la détermination d’une pluralité de réseaux locaux virtuels sur le système 30 de commutation. Des VLANs différents peuvent ainsi être associés aux différents liens possibles entre les nœuds afin de réduire les besoins en bande passante au niveau du système 30 de commutation.

Une fois l’étape d’initialisation 130 terminée, le procédé 100 comporte une étape de lancement 140 du scénario 26 de test (lancement de l’émulation). Cette étape de lancement 140 du scénario 26 peut être déclenchée par l’utilisateur, par exemple via l’interface 21 homme-machine. Au cours de cette étape de lancement 140, la commande de début d’exécution est transmise aux différents modules 41 d’émulation de liens, par exemple via un mécanisme de diffusion Ethernet sur le système 30 de commutation.

Au cours de l’exécution 150 du scénario de test, chaque nœud 40 fonctionne de manière autonome pour traiter des paquets en émission ou en réception et pour traiter les séries temporelles spécifiques à ce nœud en fonction du temps virtuel.

En particulier, l’exécution 150 du scénario de test comporte, pour chaque nœud 40 :

- une mise à jour 151 régulière, par le module 41 d’émulation de liens, à partir des séries temporelles spécifiques au nœud, des informations instantanées d’état du nœud et des caractéristiques instantanées des liens de communication en provenance et à destination du nœud,

- un contrôle 152 de paquets en réception ou en émission par le module 41 d’émulation à partir des caractéristiques instantanées des liens de communication en provenance et à destination du module 42 applicatif,

- un routage 154 de paquets, dans lequel le module 42 applicatif émet et reçoit des paquets via le module 41 d’émulation et réalise un routage en fonction des valeurs instantanées 53 des informations d’état du nœud et des caractéristiques des liens de communication mises à jour par le module 41 d’émulation.

En particulier, et tel qu’expliqué précédemment en référence à la figure 8, un paquet en provenance du module 42 applicatif, via l’interface 44 virtuelle, est traité de manière à respecter les contraintes de bande passante avant d’être émis sur le système 30 de commutation, à destination d’un autre nœud, via l’interface 43 physique. Un paquet en provenance d’un autre nœud, reçu sur l’interface 43 physique, est soit éliminé (si le lien n’est pas opérationnel au temps virtuel considéré) soit traité en fonction des caractéristiques instantanées 53b en réception du lien (ajout d’un délai, ajout d’une erreur au niveau bit ou au niveau trame, etc.) avant d’être envoyé sur l’interface 44 virtuelle associée au lien.

L’étape d’exécution 150 du scénario 26 de test peut également comporter le traitement 153 des commandes de mode opératoire. Pour rappel, les commandes de mode opératoire sont diffusées par le contrôleur 20 aux modules 41 d’émulation de lien pour changer de mode opératoire pendant l’exécution 150 du scénario (mode temps réel, mode ralenti, mode accéléré, mode pas à pas, en avant ou en arrière, mise en pause, saut à un instant particulier du scénario, etc.). Dans le mode pas à pas, les modules 41 d’émulation de liens effectuent un pas d’émulation en avant ou en arrière et s’arrêtent en attente d’une nouvelle commande. Dans les modes de lecture (temps réel, ralenti ou accéléré), les modules 41 d’émulation de liens fonctionnent de manière autonome. Le pas d’émulation est calculé par les modules 41 d’émulation de lien en fonction du mode opératoire : il correspond par exemple au pas de simulation en mode temps réel, à un sur-échantillonnage du pas de simulation en mode ralenti, ou à un sous-échantillonnage du pas de simulation en mode accéléré.

Tel qu’illustré sur la figure 9, le procédé 100 peut également comporter une phase de validation et/ou d’analyse 150 du module 42 applicatif de l’un au moins des nœuds 40, par exemple à partir de traces de débogage capturées par les modules 42 applicatifs à tester, et/ou par un nœud de supervision du réseau récupérant des informations en provenance des modules 42 applicatifs supervisés.

La solution proposée comporte de nombreux avantages. En particulier, elle permet d’émuler un réseau comportant un grand nombre de nœuds et un grand nombre de liens. Dans l’exemple de réalisation décrit précédemment en référence à la figure 4, avec une baie de seize serveurs et vingt-quatre interfaces physiques par serveur, il est possible d’émuler trois-cent-quatre-vingt-quatre nœuds (16 x 24 = 384) pour lesquels un lien physique avec le système de commutation est réservé pour chaque nœud (comme dans l’exemple illustré à la figure 5). Le nombre de liens de communication différents pouvant être établis entre les nœuds au cours d’un scénario de test peut alors atteindre plusieurs milliers voire plusieurs dizaines de milliers de liens. Il devient ainsi possible d’émuler un réseau de communication non-terrestre comportant une constellation LEO de plusieurs centaines de satellites (par exemple environ trois-cents satellites).

Pendant la phase 150 d’exécution du scénario, la communication entre le contrôleur 20 et les noeuds 40 est limitée à la diffusion des messages de contrôle relatifs aux éventuels changements de mode opératoire. Ainsi, les besoins en bande passante sur le système 30 de commutation pour le contrôle des noeuds 40 pendant la phase 150 d’exécution du scénario sont quasiment nuis. La diffusion des messages de contrôle permet aussi un contrôle du système 30 de commutation et des noeuds 40 depuis un contrôleur 20 distant de plusieurs centaines de kilomètres sans impact sur les performances de l’émulation.

La détermination des caractéristiques instantanées des noeuds et des liens à un instant donné du scénario est entièrement mise en oeuvre par les modules 41 d’émulation de liens. De façon similaire, le contrôle 152 des paquets est entièrement pris en charge par les modules 41 d’émulation de liens. Cette architecture distribuée a notamment pour avantage de mieux répartir la charge de calcul entre le contrôleur 20 et les modules 41 d’émulation de liens, et d’éviter les problèmes de synchronisation entre les noeuds 40 (avec un système centralisé, la mise à jour des noeuds par le contrôleur entraînerait un problème de désynchronisation à cause du séquencement du chargement des caractéristiques des noeuds à chaque pas d’émulation).

La solution proposée offre une très bonne représentativité du système sous test. Plus particulièrement, les modules 41 d’émulation de liens peuvent remonter directement des informations de qualité du signal radio (rapport signal sur bruit, doppler, niveau d’interférence, etc.) et des informations plateformes (position, attitude) aux noeuds 40 afin de tester des algorithmes avancés de routage (algorithmes de « handover » notamment).

La solution proposée permet également de faciliter le prototypage, le débogage, la vérification et la validation du réseau. Le contrôleur 20 permet en effet de mettre en oeuvre différents modes opératoires. Durant des phases de prototypage et de débogage, le mode pas à pas permet d’arrêter l’émulation, d’analyser l’état de noeuds et de corréler les évènements réseaux et la topologie du réseau à un instant donné. Durant des phases de vérification, le temps peut être accéléré de manière à réduire l’exécution d’un scénario de test (les changements de topologie sont moins rapides que la vitesse d’exécution des couches protocolaires sous test). Il est donc possible de vérifier un scénario de plusieurs heures en quelques minutes et de déterminer les marges du système sous test par rapport à des changements de topologie plus fréquents que la réalité. Durant des phases de validation, l’émulateur peut fonctionner en temps réel afin de tester des services temps réel de bout en bout.

La solution proposée offre également une configuration particulièrement simple du système 10 d’émulation. Le branchement du système 30 de commutation avec des câbles Ethernet peut être fait une seule fois. Il n’est pas nécessaire de recâbler le système 30 de commutation pour différents scénarios. La configuration de réseaux locaux virtuels sur le système 30 de commutation est faite par logiciel par le contrôleur 20 à partir des données du scénario. Le module 22 de gestion de scénarios permet de gérer les aspects plateformes, communication et réseau de manière unifiée. Les données issues du scénario sont utilisées à la fois pour la simulation (par le module 23 de simulation) et pour l’émulation (par les modules 41 d’émulation de liens). Cette consistance des données de simulation et d’émulation permet d’éviter des erreurs de manipulation de données qui pourraient être observées dans des systèmes distincts de simulation et d’émulation.

La solution proposée permet avantageusement d’intégrer un équipement réel 60 dans le système 10 d’émulation (comme dans l’exemple illustré sur la figure 4) et de le tester dans des conditions réalistes, par exemple pour mesurer sa consommation électrique, ou pour s’assurer du bon fonctionnement des couches protocolaires testées sur le véritable matériel sur lequel elles seront implémentées dans le réseau réel.

Claims

Revendications

1. Système (10) d’émulation d’un réseau à topologie variable, ledit système (10) comportant un contrôleur (20), un système (30) de commutation et des noeuds (40) de réseau comprenant chacun un module (42) applicatif, caractérisé en ce que le contrôleur (20) est adapté pour générer, en fonction d’un scenario (26) de test mémorisé, des informations (27) d’états des noeuds et des caractéristiques (28) de liens de communication susceptibles d’être établis entre les modules (42) applicatifs des noeuds (40) au cours du scénario, les informations (27) d’états des noeuds et les caractéristiques (28) des liens de communication étant établies sous forme de séries temporelles, chaque nœud (40) comporte un module (41 ) d’émulation de liens émulant une couche protocolaire physique et s’interfaçant avec le module (42) applicatif, le module (42) applicatif comprenant des couches protocolaires de niveau supérieur à la couche protocolaire physique, chaque module (41 ) d’émulation comportant une mémoire pour stocker des informations (27) d’états spécifiques à ce nœud et des caractéristiques (28) des liens de communication en provenance et à destination de ce nœud fournies sous forme de séries temporelles par le contrôleur (20), le contrôleur (20) est configuré pour transmettre aux modules (41 ) d’émulation de liens une commande de début d’exécution commune à l’ensemble des nœuds, chaque nœud est configuré pour fonctionner de manière autonome en cours d’exécution pour traiter des paquets en émission ou en réception et pour traiter les séries temporelles spécifiques à ce nœud en fonction d’un temps virtuel :

- chaque module (41 ) d’émulation de liens est adapté à mettre à jour régulièrement, à partir des séries temporelles spécifiques au nœud, des informations instantanées d’état du nœud et des caractéristiques instantanées des liens de communication en provenance et à destination du nœud,

- chaque module (41 ) d’émulation est configuré pour contrôler l’émission et la réception de paquets de trafic en fonction des caractéristiques instantanées des liens de communication, et

- chaque module (42) applicatif est adapté pour émettre et recevoir des paquets via le module (41 ) d’émulation et réaliser un routage pouvant être fonction des informations instantanées d’état et des caractéristiques instantanées des liens de communication mises à jour par le module (41 ) d’émulation. Tl

2. Système (10) selon la revendication 1 , dans lequel les informations (27) d’états des noeuds générées par le contrôleur (20), en fonction du scenario (26) de test, comprennent des informations géographiques relatives à des trajectoires des noeuds, sous forme de série temporelle.

3. Système (10) selon l’une quelconque des revendications 1 à 2, dans lequel le système (30) de commutation est configuré par le contrôleur (20) pour établir des réseaux virtuels au-dessus de liens physiques (31 , 33, 35) du système de commutation, ces réseaux virtuels étant destinés à être gérés par le système de commutation et configurés en fonction des liens de communication susceptibles d’être établis entre les modules (42) applicatifs au cours du scénario (26), ces réseaux virtuels restant inchangés au cours du scenario.

4. Système (10) selon l’une quelconque des revendications 1 à 3, dans lequel au moins un des noeuds (40) du réseau correspond à un satellite ou un aéronef.

5. Système (10) selon l’une quelconque des revendications 1 à 4, dans lequel chaque module d’émulation (41 ) est configurable en mode pas à pas, en mode ralenti, en mode accéléré ou en mode temps réel, à partir de commandes de mode opératoire envoyées par un mécanisme de diffusion à l’ensemble des noeuds, le module (41 ) d’émulation de liens étant configuré pour calculer un temps virtuel à partir de la commande de mode opératoire, tandis que le module (42) applicatif est configuré pour fonctionner en temps réel.

6. Système (10) selon l’une quelconque des revendications 1 à 5, dans lequel le traitement d’un paquet en réception par le module (41 ) d’émulation de liens en provenance d’un autre nœud comporte l’une au moins des opérations suivantes, en fonction de caractéristiques instantanées (53b) en réception du lien sur lequel le paquet est reçu :

- une suppression du paquet si le lien n’est pas opérationnel,

- un ajout d’un délai de transmission,

7. Système (10) selon l’une quelconque des revendications 1 à 6, dans lequel le traitement d’un paquet en émission par le module (41 ) d’émulation de liens vers un autre nœud comporte une fonction de lissage du trafic en fonction de caractéristiques instantanées (53a) en émission du lien sur lequel le paquet est à émettre.

8. Système (10) selon l’une quelconque des revendications 1 à 7, dans lequel dans au moins un des noeuds (40), le module (41 ) d’émulation de liens est configuré pour multiplexer plusieurs liens (45) virtuels entre le module (42) applicatif et un ou plusieurs autres modules (42) applicatifs sur un unique lien (35) physique du système (30) de commutation.

9. Système (10) selon l’une quelconque des revendications 1 à 8, dans lequel dans au moins un des noeuds (40), le module (41 ) d’émulation de liens est configuré pour multiplexer plusieurs liens (45) virtuels entre le module (42) applicatif et un ou plusieurs autres modules (42) applicatifs sur plusieurs liens (35) physiques du système (30) de commutation.

10. Système (10) selon l’une quelconque des revendications 1 à 9, dans lequel au moins un serveur (50) implémente une pluralité de noeuds (40), chaque nœud étant implémenté sur une machine virtuelle du serveur (50), chaque machine virtuelle implémentant un module (41 ) d’émulation de liens sur un premier cœur et un module (42) applicatif sur un deuxième cœur.

1 1 . Procédé (100) d’émulation d’un réseau à topologie variable, ledit procédé étant mis en œuvre par un système (10) comportant un contrôleur (20), un système (30) de commutation et des nœuds (40) de réseau comprenant chacun un module (42) applicatif, le procédé (100) étant caractérisé en ce qu’il comprend : une étape de simulation (120), dans laquelle le contrôleur (20) génère, en fonction d’un scenario (26) de test mémorisé, des informations (27) d’états des nœuds et des caractéristiques (28) de liens de communication susceptibles d’être établis entre les modules (42) applicatifs des nœuds (40) au cours du scénario (26), les informations (27) d’états des nœuds et les caractéristiques (28) des liens de communication étant établies sous forme de séries temporelles, une étape de configuration (133) des nœuds (40), dans laquelle le contrôleur (20) fournit à chaque nœud (40) les informations (27) d’états spécifiques à ce nœud et les caractéristiques (28) des liens de communication en provenance et à destination de ce nœud, chaque nœud comportant un module (41 ) d’émulation de liens émulant une couche protocolaire physique et s’interfaçant avec le module (42) applicatif, le module (42) applicatif comprenant des couches protocolaires de niveau supérieur à la couche protocolaire physique, une étape de lancement (140) du scénario de test, dans laquelle le contrôleur (20) transmet aux modules (41 ) d’émulation de liens une commande de début d’exécution commune à l’ensemble des noeuds, une étape d’exécution (150) du scénario de test dans laquelle chaque nœud (40) fonctionne de manière autonome pour traiter des paquets en émission ou en réception et pour traiter les séries temporelles spécifiques à ce nœud en fonction d’un temps virtuel, l’étape d’exécution (150) comprenant pour chaque nœud (40) les sous-étapes suivantes :

- une mise à jour (151 ) régulière, par le module (41 ) d’émulation de liens, à partir des séries temporelles spécifiques au nœud, d’informations instantanées d’état du nœud et de caractéristiques instantanées des liens de communication en provenance et à destination du nœud,

- un contrôle (152) de paquets en réception ou en émission par le module (41 ) d’émulation à partir des caractéristiques instantanées des liens de communication en provenance et à destination du module (42) applicatif,

- un routage (154) de paquets, dans lequel le module (42) applicatif émet et reçoit des paquets via le module (41 ) d’émulation et réalise un routage pouvant être fonction des informations instantanées d’état du nœud et des caractéristiques instantanées des liens de communication mises à jour par le module (41 ) d’émulation.

12. Procédé (100) d’émulation selon la revendication 11 , comprenant préalablement à l’étape de simulation (120), une étape préliminaire de définition (1 10), par un utilisateur, d’un scénario (26) de test contenant des paramètres géographiques et géométriques des nœuds, des paramètres de communication des nœuds, des propagateurs utilisés pour calculer des trajectoires des nœuds et une définition des liens de communication à prendre en compte entre les nœuds, le scenario comprenant une heure de début et une heure de fin.

13. Procédé (100) d’émulation selon l’une quelconque des revendications 11 à 12, comprenant en outre préalablement à l’exécution (150), une étape de configuration (131 ) du système (30) de commutation (30) dans laquelle le contrôleur (20) établit des réseaux virtuels au-dessus de liens physiques (31 , 33, 35) du système (30) de commutation (30), ces réseaux virtuels étant destinés à être gérés par le système de commutation et étant configurés en fonction des liens de communication susceptibles d’être établis entre les modules (42) applicatifs au cours du scénario (26), ces réseaux virtuels restant inchangés au cours du scenario.

14. Procédé (100) selon l’une quelconque des revendications 11 à 13, comprenant une diffusion, par le contrôleur (20) à destination des noeuds (40) du système, d’une commande de mode opératoire permettant de configurer l’exécution (150) en mode pas à pas, en mode ralenti, en mode accéléré ou en mode temps réel, et une étape de traitement (153) de la commande de mode opératoire par le module (41 ) d’émulation de liens de chaque nœud (40), la commande de mode opératoire comportant optionnellement un temps virtuel de synchronisation entre les nœuds (40).

15. Procédé (100) selon l’une quelconque des revendications 11 à 14, comportant une étape de validation et/ou d’analyse (160) comprenant une analyse de traces et/ou de statistiques de chaque nœud (40) acquises directement par les modules (42) applicatifs et/ou par un nœud de supervision du réseau récupérant des informations en provenance des modules (42) applicatifs supervisés.