Variable-topology-network emulator and emulation method

Abstract

The invention relates to a system (10) for emulating a variable-topology network, comprising a controller (20), a switching system (30) and network nodes (40). Each node comprises an emulation module for emulating a physical layer, and an application module with higher-level protocol layers to be tested. During execution of a test scenario, the emulation module of each node is configured to compute instantaneous information concerning the state of the node and instantaneous characteristics of the links from and to the node. The application module of the node is designed to transmit and receive packets via the emulation module, and to route the packets depending on the instantaneous information concerning the node and the links. Each emulation module is configured to control the transmission and reception of packets depending on the instantaneous characteristics of the communication links.

Description

[0001] Emulator of a variable topology network and emulation method

[0002] Field of invention

[0003] The present invention belongs to the field of telecommunications, and more particularly to systems for prototyping, developing and testing applications operating on networks with variable topology. The invention relates in particular to a system for emulating a network with variable topology. The invention is particularly well suited to emulating a non-terrestrial network comprising a spatial and / or aerial component and involving a large number of nodes.

[0004] State of the art

[0005] The sixth generation of cellular communications technology, or 6G, promises to bring significant improvements in speed, reliability, coverage, and new features. Among these developments, the standardization of non-terrestrial networks (or NTNs) is a key topic.

[0006] Non-terrestrial networks include communications networks that are not based exclusively on fixed terrestrial infrastructure, for example, satellite communications systems, including Low Earth Orbit (LEO), Medium Earth Orbit (MEO) and Geostationary Orbit (GEO) constellations, as well as other aerial platforms such as High Altitude Pseudo-Satellites (HAPS), balloons or drones.

[0007] Non-terrestrial networks undergo frequent changes in their topology, particularly due to the mobility of some of their infrastructures, time-varying propagation delays, and disturbances (obstructions, atmospheric attenuation, interference, Doppler shifts, transmission errors, etc.) of radio or optical communication links. Terrestrial network protocols, which operate for quasi-fixed topologies with low-latency and low-error links (optical fiber, cable, microwave beam) must therefore be adapted to operate in an NTN network. Within the framework of the 6G standard, NTN standardization focuses in particular on mobility management and the seamless integration of terrestrial and non-terrestrial networks. There is therefore a need to provide a tool for prototyping, developing, and testing non-terrestrial networks.There are solutions for emulating a physical point-to-point link (HIL type solution, acronym for "Hardware In the Loop"). These solutions focus on the modulation / demodulation aspect for a specific link between two nodes. These solutions require hardware equipment and are therefore not suitable for networks with several hundred nodes and several thousand links between these nodes, particularly due to the cost of the hardware, the practical difficulties linked to cabling and the resulting space requirement.

[0008] Patent application EP2955876A1 proposes the simulation of multiple communication links between the nodes of a network, using a set of simulated modules virtually interconnected. Such a solution does not allow for precise control over time of the transmission quality (throughput, delay, jitter, error rate, signal-to-noise ratio, interference, Doppler, etc.) of the communication links and therefore lacks precision for realistic testing of routing algorithms.

[0009] Statement of the invention

[0010] The present invention aims to provide a test solution for prototyping, developing and testing a communication network with variable topology while allowing better representativeness of the network. The solution is particularly well suited to emulating a non-terrestrial network comprising a spatial and / or aerial component and comprising several hundred mobile nodes.

[0011] To this end, and according to a first aspect, a system for emulating a network with variable topology is proposed, comprising a controller, a switching system and network nodes each comprising an application module.

[0012] The controller is adapted to generate, as a function of a stored test scenario, information on the states of the nodes and the characteristics of communication links likely to be established between the application modules of the nodes during the scenario, the information on the states of the nodes and the characteristics of the communication links being established in the form of time series.

[0013] Each node comprises a link emulation module emulating a physical protocol layer and interfacing with the application module, the application module comprising protocol layers of a higher level than the physical protocol layer, each emulation module comprising a memory for storing state information specific to this node and characteristics of the communication links from and to this node provided in the form of time series by the controller.

[0014] The controller is configured to transmit to the link emulation modules a start of execution command common to all nodes.

[0015] Each node is configured to operate autonomously while running to process packets in transmission or reception and to process time series specific to this node according to a virtual time:

[0016] - each link emulation module is adapted to regularly update, from node-specific time series, instantaneous node state information and instantaneous characteristics of communication links to and from the node,

[0017] - each emulation module is configured to control the transmission and reception of traffic packets according to the instantaneous characteristics of the communication links, and

[0018] - each application module is adapted to transmit and receive packets via the emulation module and carry out routing which can be a function of the instantaneous state information and the instantaneous characteristics of the communication links updated by the emulation module.

[0019] Advantageously, the system according to the invention makes it possible to evaluate the performance of a non-terrestrial network by taking into account the specificities of the physical layer (variable delay, errors, packet losses) and to develop and test advanced routing algorithms using information relating to the state of the nodes and the characteristics of the communication links between the nodes.

[0020] In particular embodiments, the emulation system may further comprise one or more of the following features, taken alone or in any technically possible combination.

[0021] In particular embodiments, the controller is co-located with the switching system.

[0022] In particular embodiments, the controller is remote and connected to the switching system through a public or private WAN (Wide Area Network).

[0023] In particular embodiments, the node state information generated by the controller, depending on the test scenario, includes geographic information relating to trajectories of the nodes, in the form of a time series.

[0024] In particular embodiments, the node state information generated by the controller, depending on the test scenario, includes geometric information relating to the geometries of the nodes, in the form of a time series.

[0025] In particular embodiments, the test scenario contains geographic and geometric parameters of the nodes, communication parameters of the nodes, propagators used to calculate trajectories of the nodes and a definition of the communication links to be taken into account between the nodes. The test scenario also includes a start time and an end time.

[0026] In particular embodiments, the switching system is configured by the controller to establish virtual networks over physical links (31, 33, 35) of the switching system. These virtual networks are intended to be managed by the switching system and configured according to the communication links likely to be established between the application modules during the scenario. These virtual networks remain unchanged during the scenario.

[0027] In particular embodiments, the scope of the virtual networks is strictly limited to the links likely to be established according to the scenario.

[0028] In particular embodiments, the controller stores a plurality of test scenarios selectable by a user and executed separately.

[0029] In particular embodiments, at least one of the nodes of the network corresponds to a satellite or an aircraft.

[0030] In particular embodiments, for each node, the memory of the emulation module for storing the node-specific state information and the characteristics of the communication links from and to the node provided in the form of time series is a non-shared memory. Only the instantaneous node state information and the instantaneous characteristics of the communication links, updated regularly by the emulation module, are made accessible to the application module.

[0031] In particular embodiments, each emulation module is configurable in step-by-step mode, slow-motion mode, accelerated mode or real-time mode, from operating mode commands sent by a broadcast mechanism to all the nodes. The link emulation module is configured to calculate a virtual time from the operating mode command, while the application module is configured to operate in real time.

[0032] In particular embodiments, the processing of a packet being received by the link emulation module from another node comprises at least one of the following operations, depending on instantaneous characteristics in reception of the link on which the packet is received:

[0033] - deletion of the package if the link is not operational,

[0034] - an addition of a transmission delay,

[0035] - adding at least one bit-level or frame-level error to the packet to simulate a transmission error.

[0036] In particular embodiments, the processing of a packet being sent by the link emulation module to another node includes a traffic smoothing function based on instantaneous transmission characteristics of the link on which the packet is to be sent.

[0037] In particular embodiments, in at least one of the nodes, the link emulation module is configured to multiplex several virtual links between the application module and one or more other application modules on a single physical link of the switching system.

[0038] In particular embodiments, in at least one of the nodes, the link emulation module is configured to multiplex several virtual links between the application module and one or more other application modules over several physical links of the switching system.

[0039] In particular embodiments, at least one server implements a plurality of nodes, each node being implemented on a virtual machine of the server, each virtual machine implementing a link emulation module on a first core and an application module on a second core.

[0040] In particular embodiments, at least one of the nodes is implemented by real equipment comprising the application module, the real equipment being interfaced with the emulation module.

[0041] In particular embodiments, at least one server implements a plurality of nodes, the node emulation modules being implemented on a dedicated core of the server and the application modules being implemented on one or more cores distinct from the dedicated core.

[0042] According to a second aspect, a method for emulating a variable topology network is provided. The method is implemented by an emulation system comprising a controller, a switching system and network nodes each comprising an application module. The method comprises:

[0043] - a simulation step, in which the controller generates, based on a stored test scenario, information on the states of the nodes and the characteristics of communication links likely to be established between the application modules of the nodes during the scenario, the information on the states of the nodes and the characteristics of the communication links being established in the form of time series,

[0044] - a node configuration step, in which the controller provides each node with state information specific to this node and the characteristics of the communication links coming from and going to this node, each node comprising a link emulation module emulating a physical protocol layer and interfacing with the application module, the application module comprising protocol layers of a higher level than the physical protocol layer,

[0045] - a test scenario launch step, in which the controller transmits to the link emulation modules a start of execution command common to all nodes,

[0046] - a test scenario execution step in which each node operates autonomously to process packets in transmission or reception and to process the time series specific to this node as a function of a virtual time, the execution step comprising for each node the following sub-steps: o a regular update, by the link emulation module, from the time series specific to the node, of instantaneous information on the state of the node and instantaneous characteristics of the communication links coming from and going to the node, o a control of packets in reception or transmission by the emulation module from the instantaneous characteristics of the communication links coming from and going to the application module, o a routing of packets,in which the application module transmits and receives packets via the emulation module and performs routing which may be a function of the instantaneous state information of the node and the instantaneous characteristics of the communication links updated by the emulation module.,

[0047] In particular embodiments, the emulation method may further comprise one or more of the following characteristics, taken individually or in any technically possible combination.

[0048] In particular modes of implementation, the emulation method comprises, prior to the simulation step, a preliminary step of definition, by a user, of a test scenario containing geographical and geometric parameters of the nodes, communication parameters of the nodes, propagators used to calculate trajectories of the nodes and a definition of the communication links to be taken into account between the nodes, a start time and an end time.

[0049] In particular embodiments, the emulation method comprises, prior to the execution of the scenario, a step of configuring the switching system in which the controller establishes virtual networks above physical links (31, 33, 35) of the switching system. These virtual networks are intended to be managed by the switching system and are configured according to the communication links likely to be established between the application modules during the scenario, these virtual networks remaining unchanged during the scenario.

[0050] In particular implementation modes, the scope of virtual networks is strictly limited to the communication links likely to be established during the scenario.

[0051] In particular modes of implementation, the emulation method comprises a configuration step, controlled by the controller, of at least one server implementing a plurality of nodes, each node being implemented on a virtual machine of the server, each virtual machine implementing a link emulation module on a first core and an application module on a second core.

[0052] In particular modes of implementation, the emulation method comprises a broadcast, by the controller to the nodes of the system, of an operating mode command making it possible to configure the execution in step-by-step mode, in slow-motion mode, in accelerated mode or in real-time mode, and a step of processing the operating mode command by the link emulation module of each node, the operating mode command optionally comprising a virtual synchronization time between the nodes.

[0053] In particular modes of implementation, the emulation method comprises a validation and / or analysis step comprising an analysis of traces and / or statistics of each node acquired directly by the application modules and / or by a network supervision node recovering information from the supervised application modules.

[0054] Presentation of figures

[0055] The invention will be better understood by reading the following description, given by way of non-limiting example, and made with reference to figures 1 to 9 which represent:

[0056] [Fig. 1] a schematic representation of an emulation system according to the invention for a non-terrestrial network involving satellite communications,

[0057] [Fig. 2] a schematic representation of the protocol layers of the OSI model implemented respectively in the real system and the emulated system according to the invention,

[0058] [Fig. 3] an example of the implementation of the emulation system controller, with a schematic illustration of its operation,

[0059] [Fig. 4] an exemplary embodiment of the emulation system according to the invention, with a large number of nodes implemented by virtual machines on servers and real equipment,

[0060] [Fig. 5] a first example of implementing a node on a virtual machine of a server,

[0061] [Fig. 6] a second example of implementing a node on a virtual machine of a server allowing to maximize the input and output speeds of the node,

[0062] [Fig. 7] An example of implementing multiple nodes on a virtual machine of a server,

[0063] [Fig. 8] a schematic representation of the processing of communication links in transmission and reception by the link emulation module,

[0064] [Fig. 9] A schematic representation of the main steps of a process for emulating a network with variable topology.

[0065] In these figures, identical references from one figure to another designate identical or similar elements. For reasons of clarity, the elements represented are not necessarily to the same scale, unless otherwise indicated.

[0066] Detailed description of the invention

[0067] As explained above, the invention makes it possible to create, in a laboratory environment, a digital twin of a real network that exists or is under development. The invention is particularly well suited to a network having a large number of nodes whose positions may vary over time. This variability of the network topology may concern not only the user nodes, but also the nodes corresponding to elements of the network infrastructure, such as, for example, routers embedded in satellites orbiting the Earth, in aerial platforms (drones, airplanes, balloons), or in land vehicles (trains, boats).

[0068] Figure 1 illustrates, as an example, a communication between a server and a user within a non-terrestrial network. The communication involves various intermediate routing nodes between the server and the user, including a gateway station, a geostationary satellite, a low-orbit satellite, and an aircraft. The upper part of Figure 1 represents the real network, while its lower part represents the digital twin of the real network, i.e., the emulated network.

[0069] As illustrated in Figure 1, an emulation system 10 makes it possible to emulate the real network. The emulation system 10 comprises a controller 20, a switching system 30 and nodes 40 interconnected by the switching system 30. For example, the controller 20 can be implemented on a computer (workstation), the nodes 40 can be implemented by virtual machines running on a server rack or real machines, and the switching system 30 can comprise one or more Ethernet switches and physical interconnection links such as Ethernet cables.

[0070] The controller 20 can in particular make it possible to create a test scenario via a human-machine interface (HMI), to define the characteristics of the nodes and the communication links connecting the different nodes during the scenario, to configure the system, then to launch and control the execution of the scenario remotely.

[0071] The characteristics of the nodes define in particular the movements of the different nodes during the scenario (for example in terms of position, speed, attitude, trajectory, orientation of one or more antennas of the node, etc.). The characteristics of the communication links define in particular a transmission quality (in other words a link budget, for example in terms of flow rate, propagation delay, error rate, attenuation, etc.) of each link likely to be established between two nodes in the scenario considered. Each communication link of the emulated system can thus correspond to a wired link, a radio link or an optical link of the real network.

[0072] The proposed solution follows a mixed approach combining simulation and emulation. First, the movements of the different nodes and the characteristics of the communication links are simulated in a test scenario, without requiring real time; second, the behavior of the physical layer of the different nodes during the scenario is emulated in real time. Such arrangements allow debugging the layers higher than the physical layer in real time.

[0073] Figure 2 schematically illustrates how the different protocol layers of the OSI model (acronym for "Open Systems Interconnection") are implemented in the emulation system 10. Each node 40 comprises a link emulation module 41 for emulating the physical layer (lowest level layer), and an application module 42 comprising higher level protocol layers to be tested. These higher level layers correspond to the layers of the OSI model located above the physical layer (link layer, network layer, transport layer, session layer, presentation layer and application layer). These are the protocol layers as they are intended to be implemented in the equipment of the real network. As illustrated in Figure 2, the switching system 30 ensures communication between the link emulation modules 41.

[0074] Thus, by running the test scenario in the emulation system 10, it is possible to debug, test and validate in real time the protocol layers located above the physical layer.

[0075] In particular, the emulation system 10 makes it possible to test the protocol layers relating to the routing of data packets exchanged on the network (in particular the link layer, the network layer and the transport layer). In a network with a fixed topology (for example an internet network), routing is generally optimized according to traffic and cost and quality of service constraints. In a cellular network, it is also necessary to optimize routing according to radio criteria and user mobility. In a non-terrestrial network, it is also necessary to take into account the position of mobile network infrastructure elements (space or air platforms in particular). The routing algorithms then become particularly complex.By way of non-limiting example, in a communications network involving satellites in low Earth orbit (LEO) or medium Earth orbit (MEO), the routing algorithms must take into account the need to limit or even prevent emissions in certain geographical regions, in particular around the geostationary arc, at the poles, or above certain countries. The routing algorithms may also take into account the position of the nodes to determine whether they are in line of sight (LOS) of each other, as well as the orientation of the nodes' antennas.

[0076] The link emulation module 41 and the application module 42 are software modules implemented on the same machine (a real machine, a virtual machine, or network equipment). As will be seen later, each link emulation module 41 interfaces directly with one or more physical links of the switching system 30.

[0077] Figure 3 schematically represents an exemplary embodiment of the controller 20 of the emulation system 10, and its interactions with the switching system 30 and the different nodes 40.

[0078] As illustrated in Figure 3, the controller 20 comprises a human-machine interface 21 (HMI), a scenario generation module 22, a simulation module 23 and an orchestration module 24.

[0079] The human-machine interface 21 allows a user to create a test scenario 26, to configure the emulation system 10, and to launch and control the execution of the emulation. The human-machine interface 21 comprises, for example, a programming interface (API for “Application Programming Interface”) for creating the scenario 26 and a graphical interface (GUI for “Graphical User Interface”) for analyzing the simulation results, for controlling the execution of the emulation and / or for analyzing the emulation results.

[0080] The scenario generation module 22 allows test scenarios to be created from a library 25 of objects and the human-machine interface 21. The library 25 contains different types of objects and different types of communication links between the objects. Each object associates, for example, a platform (satellite, aircraft, ground station, pedestrian user, etc.) with low-level communication functions (transmitter, receiver) and an application payload (router, server, traffic generator, etc.). The communication links are unidirectional and allow transmitters and receivers to be connected for link budget calculations.

[0081] It should however be noted that the scenario generation module 22 is not essential to the invention. Nothing would prevent, for example, the test scenario from being generated by a device separate from the controller 20 and provided to the controller 20 (for example via a communication means or via a removable storage memory). Also, the controller 20 can optionally store a plurality of predetermined scenarios selected by a user (each scenario being intended to be executed individually).

[0082] From the scenario 26, the simulation module 23 makes it possible to define, in the form of time series, on the one hand information 27 on the states of the nodes 40 and on the other hand characteristics 28 of communication links likely to be established between the application modules 42 of the nodes 40 during the scenario 26. The information 27 on the states of the nodes is information relating to the movement of the nodes during the scenario. Each link corresponds to a virtual unidirectional link, simulated by the test scenario, directly connecting two nodes together. The characteristics of the link are information relating to a transmission quality of the link. The expression “in the form of time series” means that the information comprises values ​​taken by different parameters at different times during the scenario, each time corresponding to a simulation step of the scenario, for example every second, every ten seconds or every minute.

[0083] Simulation module 23 can in particular be implemented by an orbital simulator such as STK (acronym for “System Tool Kit” in English).

[0084] The state information 27 (or platform information) of a node 40 relates, for example, to the position, speed, or attitude of a node over time (for example, they represent the orbital position and attitude of a satellite orbiting the Earth). They may also relate to information relating to the geometries of the nodes, such as, for example, the orientation of one or more antennas of the node. These characteristics are determined for each simulation step of the scenario, and they make it possible to determine the communication links existing at the simulation step considered. For example, for two nodes corresponding to satellites in orbit, it is possible to determine, at each simulation step, whether the two satellites are in direct visibility (LOS). If this is the case, it is considered that a communication link is operational between the two nodes, and the characteristics 28 of the communication link can be calculated.The characteristics 28 of a communication link relate, for example, to a flow rate, a propagation delay, jitter, an error rate at the bit level (BER for “Bit Error Rate” in English) or at the frame level (FER for “Frame Error Rate” in English), a Doppler level, an interference rate, a signal-to-noise ratio, a signal attenuation, thermal noise, etc.

[0085] The orchestration module 24 makes it possible in particular to configure the switching system 30, to control a hypervisor 51 of virtualization software (for example VMWare type software) to create the virtual machines intended to implement nodes 40 on one or more servers 50, to configure the emulation modules 41 of the different nodes 40 of the system 10, then to launch and control the execution of the scenario in real time.

[0086] During configuration, the controller 20 downloads into each link emulation module 41 the state information 27 specific to this node and the characteristics 28 of the communication links coming from and going to the application module 42 of this node.

[0087] At the end of the configuration phase, the controller 20 transmits to the link emulation modules 41 a start of execution command common to all the nodes. This start of execution command can be transmitted to the different link emulation modules 41 by a broadcast mechanism on the switching system 30. The start of execution command can include a virtual time corresponding to the start of the test scenario. Alternatively, each node can be configured by default with a virtual scenario start time.

[0088] During the execution of the scenario (i.e. during the emulation phase), the controller 20 no longer intervenes to define the state of the system at a given instant. On the contrary, the determination of the characteristics of the nodes and the communication links at a given instant is carried out autonomously by the link emulation modules 41.

[0089] This distribution, at the level of the link emulation modules 41, of the determination of the characteristics of the nodes and the communication links makes it possible to avoid the problems inherent in a centralized architecture (in particular in terms of synchronization, computational load of the controller 20, and control flow between the controller 20 and the nodes 40). It also allows remote control without impacting the performance of the emulation.

[0090] During emulation, it is possible to take advantage of the fact that the execution of the protocol layers is much faster (on the order of milliseconds) than the simulation step (on the order of one or more seconds) to adapt the speed of the emulation to the user's needs: slowed down speed or in step-by-step mode for debugging, accelerated speed for validation, or real time for a demonstration.

[0091] Thus, one or more of the following operating modes can be supported during the execution phase of the scenario:

[0092] - real-time mode,

[0093] - slow motion mode, with execution slower than real time,

[0094] - accelerated mode, with execution faster than real time,

[0095] - step-by-step mode.

[0096] Each operating mode is based on real time (the emulation system 10 is therefore a “real time compatible” system). Each operating mode can optionally be performed forward or backward (i.e., in the normal direction of time flow, or in the opposite direction). At each change of operating mode during the execution of the scenario, the controller 20 is configured to broadcast a command (operating mode command) to the link emulation module 41 of each of the nodes 40. The control of the emulation by the user can be done via the human-machine interface 21. It is also possible to provide the possibility of starting the execution of a scenario 26 from a time specified by the user. The link emulation module 41 of each node 40 is configured to calculate a virtual time (T v ) depending on the virtual time of the start of the scenario (T o ), of an internal clock (T R ), and the current operating mode (T v= T o + kT R , with k > 1 in accelerated mode, k < 1 in slowed mode and k = 1 in real-time mode). The internal clock of the link emulation module 41 corresponds for example to a clock of the server hosting the virtual machine on which the node is implemented. The clocks of the different nodes are synchronized before the launch of the execution of the emulation (for example via the start of execution command), and it is considered that any time drift between the clocks of the different nodes is then negligible during the execution of the scenario. Optionally, the operating mode command can include a virtual synchronization time between the nodes.

[0097] Figure 4 schematically represents an exemplary embodiment of an emulation system 10 according to the invention, with a large number of nodes 40 implemented by virtual machines executed on different servers 50.

[0098] In the example considered, each server 50 can implement one or more nodes 40. Each server 50 comprises one or more physical interfaces (for example Ethernet ports) to interconnect with the switching system 30.

[0099] It should be noted that, as illustrated in FIG. 4, a node 40 can also be implemented by real equipment 60 intended to be embedded in a payload of a satellite, an aircraft, a drone or a terrestrial platform. These arrangements make it possible to validate the protocol layers to be tested (i.e. the application module 42) on the real hardware on which they will be implemented in the real network. The real equipment is in this case interfaced with a link emulation module 41.

[0100] The switching system 30 makes it possible to connect each node 40 to the controller 20 and to the other nodes 40 via physical links 31, 33, 35. The physical links correspond, for example, to Ethernet cables (electrical cable or optical fiber). In the example considered, the switching system 30 comprises a high-speed switch 32 directly connected to the controller and several lower-speed access switches 34 each connected to the high-speed switch 32 and to several nodes 40. The different access switches 34 make it possible to offer a sufficient number of Ethernet ports.

[0101] In an exemplary embodiment, the emulation system 10 comprises a rack of sixteen servers 50, a switching system 30 and a controller 20. Each server 50 comprises twenty-four 25 Gbps (twenty-five gigabits per second) Ethernet interfaces. The switching system 30 comprises a switch 32 providing eight 100 Gbps Ethernet ports and one 10 Gbps port as well as four switches 34 providing 96 25 Gbps Ethernet ports. The connection link 31 between the controller 20 and the switch 32 is a 10 Gbps Ethernet cable in the case where the controller 20 and the switching system 30 are located on the same local area network (LAN) or a long-distance link through a private or public WAN (Wide Area Network) if the controller 20 and the switching system are not co-located. The connecting links 33 between the switch 32 and the switches 34 are 100 Gbps Ethernet cables.The connecting links 35 between the switches 34 and the nodes 40 are 25 Gbps Ethernet cables.

[0102] The switching system 30 makes it possible to create a physical separation between the different nodes 40. Each node 40 is connected to the switching system 30 via the link emulation module 41 and at least one connection link 35. The nodes 40 can communicate with each other only via the switching system 30. Even for nodes implemented on the same virtual machine or on several virtual machines hosted on the same server, there is no direct communication between the nodes 40. Such arrangements make it possible to maximize the representativeness of the system under test.

[0103] The hardware architecture formed by the switching system 30 also makes it possible to guarantee the necessary bandwidth for communications from or to the nodes 40. The transit delay introduced by the switching network is generally less than ten microseconds; the jitter introduced is generally less than 2 microseconds.

[0104] To limit the bandwidth required on the switching system 30, the controller 20 may be configured to determine a plurality of virtual local area networks (VLANs) on the switching system 30. Different VLANs may be associated with the different possible links between the nodes in order to reduce congestion at the switches 32, 34. The configuration of the switching system 30 consists of defining virtual networks between the nodes likely to be interconnected during the scenario. In particular modes of implementation, the extent of the virtual networks is strictly limited to the links likely to be established according to the test scenario.

[0105] Thus, the hardware configuration of the switching system 30 can remain the same from one scenario to another (the connection of the controller 20, the different nodes 40 and the switches 32, 34 with the physical links 31, 33, 35 remains unchanged), but different VLANs can be configured on the switching system 30 from one scenario to another. The configuration of the VLANs remains fixed for the duration of an emulation (execution of a scenario) and is intended to reduce the bandwidth requirements on the switching system 30. The possibility or not of communicating between two nodes at a given time is managed dynamically by the link emulation modules 41.

[0106] A VLAN common to all the nodes allows the controller 20 to communicate with all the nodes 40 using Ethernet broadcast mechanisms, in particular for sending the start of execution command or for a command relating to a change of operating mode (pause, switching to step-by-step mode, slowed down or accelerated playback, etc.). Figures 5 to 7 schematically represent different examples of implementation of a node 40 on a virtual machine of a server 50.

[0107] In the first implementation example illustrated in Figure 5, and in the second implementation example illustrated in Figure 6, each node 40 is implemented by a virtual machine. Each virtual machine is managed by a hypervisor 51 of virtualization software running on the server 50. Each virtual machine is formed by two processor cores 52 of the server 50. The first core (“core 1”) is used to operate the link emulation module 41. The second core (“core 2”) is used to operate the application module 42 (i.e., the protocol layers located above the physical layer).

[0108] The application module 42 interfaces with the switching system 30 via the link emulation module 41. For this purpose, the application module 42 interfaces with the link emulation module 41 via one or more virtual links 45, each representing a unidirectional link between the node 40 and another node. Virtual interfaces 44 are associated respectively with each virtual link 45 established between the application module 42 and the link emulation module 41. For example, a satellite-type node 40 may simultaneously have more than ten operational virtual links 45, for example four inter-satellite links, two feeder links and seven user links. The link emulation module 41 interfaces with the switching system 30 via at least one physical Ethernet interface 43 (Ethernet port) and at least one physical link 35 (connecting Ethernet cable).

[0109] In the first implementation example illustrated in Figure 5, the link emulation module 41 is configured to multiplex several virtual links 45 onto a single physical link 35 of the switching system 30. The VXLAN (Virtual Extensible Local Area Network) standard can be used for link multiplexing.

[0110] In the second implementation example illustrated in Figure 6, the link emulation module 41 is configured to multiplex several virtual links 45 onto several physical links 35 of the switching system 30. For example, each virtual link 45 can be associated with a physical link 35 respectively. However, nothing would prevent other multiplexing configurations from being considered, such as multiplexing several “user” type links 45 onto the same physical link, but associating each “inter-satellite” or “feeder” type link 45 with a different physical link. Thus, the bandwidth of a physical link 35 can be more or less shared between one or more virtual links 45. This makes it possible to manage nodes having virtual links 45 with high throughput constraints. In return, the number of nodes that can be supported by the system is reduced.

[0111] In the third implementation example illustrated in Figure 7, the same virtual machine implements several nodes 40. In particular, the first core implements the different link emulation modules 41, while the second core implements the application modules 42 of the different nodes 40. Such arrangements make it possible to increase the emulation capacity (increase in the number of nodes 40 that can be supported by the emulation system 10).

[0112] In these different examples, the separation of the link emulation module 41 and the application module 42 of the same node 40 on two separate cores allows for better isolation of the functionalities of each. This prevents the emulation from impacting the operation of the protocol layers to be tested. This provides better representativeness of the system under test.

[0113] It should be noted that the exemplary embodiments described with reference to FIGS. 5 to 7 are in no way limiting. Other embodiments of a node 40 may be envisaged. For example, it is conceivable to implement the link emulation module 41 and the application module 42 of a node 40 on the same core in two separate software containers.

[0114] A RAM type memory (Random Access Memory, also called “RAM”) is for example associated with each link emulation module 41 to store the state information 27 and the characteristics 28 of communication links specific to the associated node for the scenario considered.

[0115] During the execution of the test scenario, each node 40 is configured to operate autonomously to process packets in transmission or reception and to process the time series specific to this node according to the virtual time calculated by the emulation module 41.

[0116] Each link emulation module 41 is configured to regularly update, from the node-specific time series, instantaneous node state information and instantaneous characteristics of the communication links to and from the node, for the calculated virtual time. As illustrated in FIGS. 5 to 7, a RAM-type memory, shared between the two cores of the virtual machine, can be used to allow the link emulation module 41 to pass the instantaneous values ​​53 of the state information and the link characteristics to the application module 42. These instantaneous values ​​53 are intended to be used by the application module 42 to implement one or more packet routing algorithms. The frequency at which the instantaneous information is updated is for example defined as a function of the simulation step.In particular, a virtual time step calculated as a function of the simulation step can be used to update the instantaneous state information of the node and the instantaneous characteristics of the communication links to and from the node. The virtual time step can correspond to the simulation step, or to a subsampling or an oversampling of the simulation step.

[0117] Thus, during the execution of the scenario, each application module 42 is adapted to transmit and receive packets via the emulation module 41 and to carry out routing that can be a function of the instantaneous state information of the nodes and the instantaneous characteristics of the communication links updated by the emulation module 41. Each emulation module 41 is configured to control the transmission and reception of traffic packets as a function of the instantaneous characteristics of the communication links.

[0118] The operations of updating the instantaneous information and processing the packets in transmission or reception are carried out autonomously by the link emulation modules 41, independently of the controller 20. In other words, these operations are not triggered by the controller 20 (the emulation system 10 is based on a distributed architecture, and not on a centralized architecture). The link emulation modules 41 operate in a synchronized manner without intervention from the controller 20, except possibly for what concerns the commands for changing the operating mode.

[0119] In particular modes of implementation, the memory of the emulation module 41 for storing the node-specific state information 27 and the characteristics 28 of the communication links coming from and going to the node is a non-shared memory. Only the instantaneous node state information and the instantaneous characteristics of the communication links, updated regularly by the emulation module 41, are made accessible to the application module 42. Such arrangements make it possible to prevent the application module from having access to data to which it does not have access in reality (in particular on the evolution of the links in the future). Figure 8 schematically illustrates the processing of packets in transmission and reception by a link emulation module 41.

[0120] As illustrated in Figure 8, the characteristics 28 of the communication links include characteristics 28a in transmission (power, bandwidth, etc.), characteristics 28b in reception (antenna gain, power of the input signal, error rate, propagation delay, various attenuations, etc.). The links 45 are unidirectional but each emulation module 41 manages both the transmission and reception of packets. For example, a transmission sub-module uses the instantaneous values ​​53a of the characteristics 28a in transmission to process packets transmitted by the application module 42 on a virtual link 45a to another node. In parallel, a reception sub-module uses the instantaneous values ​​53b of the characteristics 28b in reception to process packets received from another node to the application module 42.

[0121] The processing of a packet in reception by the link emulation module 41 coming from another node comprises at least one of the following operations, depending on the instantaneous characteristics 53b in reception of the link on which the packet is received:

[0122] - a deletion of the packet if the link is not operational (for example if the link does not exist because the two nodes connected by the link are not in direct visibility),

[0123] - an addition of a transmission delay (a transmission delay of several tens or even several hundreds of milliseconds can be observed for a ground-satellite link),

[0124] - adding at least one bit-level or frame-level error to the packet to simulate a transmission error.

[0125] The processing of a packet in transmission by the link emulation module 41 towards another node includes a traffic smoothing function, depending on the instantaneous characteristics 53a in transmission of the link on which the packet is to be transmitted. The smoothing function may in particular include queuing of the packet to respect a transmission rate of the link on which the packet is to be transmitted.

[0126] Figure 9 schematically represents the main steps of a method 100 for emulating a network with variable topology. This method 100 is for example implemented by an emulation system 10 as described previously with reference to Figures 1 to 8. As illustrated in Figure 9, the emulation method 100 may firstly comprise a step 110 of defining a test scenario 26. This definition step 110 makes it possible to specify the types of nodes forming the network, and the types of links that may exist between these nodes 40 during the scenario. This definition step 110 is for example implemented using the human-machine interface 21 and the scenario generation module 22 described previously with reference to Figure 3.As explained previously, this step is optional and nothing would prevent considering that the generation of the test scenario 26 is not part of the emulation method 100 (in this case the test scenario is an input data of the emulation method 100).

[0127] The test scenario 26 may contain geographic and geometric parameters of the nodes, communication parameters of the nodes, propagators used to calculate trajectories of the nodes (in particular for taking into account the J2 and J4 perturbations for orbit propagation) and a definition of the communication links to be taken into account between the nodes. The scenario may also contain a start time and an end time.

[0128] The emulation method 100 comprises a simulation step 120 during which the controller 20 generates, as a function of the test scenario 26, the information 27 on the states of the nodes and the characteristics 28 of the communication links likely to be established between the application modules 42 of the nodes 40 during the scenario 26. As a reminder, the information 27 on the states of the nodes and the characteristics 28 of the communication links are established in the form of time series. This simulation step 120 is for example implemented using the simulation module 23 described previously with reference to FIG. 3.

[0129] The method 100 then comprises an initialization step 130, which notably comprises the configuration 133 of the link emulation modules 41.

[0130] For this configuration 133, the controller 20 provides each node 40 with the state information 27 specific to this node and the characteristics 28 of the communication links coming from and going to this node. The configuration 133 of the nodes can also comprise the configuration of the Ethernet interfaces 43 and the virtual interfaces 44 of the emulation modules 41 for the links 35 and 45 with the switching system 30 and the application module 42 respectively.

[0131] For each node 40 implemented on a virtual machine of a server 50, the initialization step 130 may also comprise the loading 132 onto the virtual machine of a disk image corresponding to said node 40. This loading of the disk image of the node is for example implemented by a hypervisor 51 of virtualization software executed on the server 50.

[0132] The initialization step 130 may also comprise the configuration 131 of the switching system 30. As explained previously, the configuration 131 of the switching system 30 may in particular comprise the determination of a plurality of virtual local area networks on the switching system 30. Different VLANs may thus be associated with the different possible links between the nodes in order to reduce the bandwidth requirements at the switching system 30.

[0133] Once the initialization step 130 is completed, the method 100 comprises a step 140 of launching the test scenario 26 (launching the emulation). This step 140 of launching the scenario 26 can be triggered by the user, for example via the human-machine interface 21. During this launching step 140, the command to start execution is transmitted to the various link emulation modules 41, for example via an Ethernet broadcast mechanism on the switching system 30.

[0134] During the execution 150 of the test scenario, each node 40 operates autonomously to process packets in transmission or reception and to process the time series specific to this node according to the virtual time.

[0135] In particular, execution 150 of the test scenario includes, for each node 40:

[0136] - a regular update 151, by the link emulation module 41, from the node-specific time series, the instantaneous node state information and the instantaneous characteristics of the communication links to and from the node,

[0137] - a control 152 of packets in reception or in transmission by the emulation module 41 from the instantaneous characteristics of the communication links coming from and going to the application module 42,

[0138] - packet routing 154, in which the application module 42 transmits and receives packets via the emulation module 41 and performs routing based on the instantaneous values ​​53 of the node state information and the characteristics of the communication links updated by the emulation module 41.

[0139] In particular, and as explained previously with reference to FIG. 8, a packet originating from the application module 42, via the virtual interface 44, is processed so as to comply with the bandwidth constraints before being sent on the switching system 30, to another node, via the physical interface 43. A packet originating from another node, received on the physical interface 43, is either eliminated (if the link is not operational at the virtual time considered) or processed according to the instantaneous characteristics 53b on reception of the link (addition of a delay, addition of an error at the bit level or at the frame level, etc.) before being sent on the virtual interface 44 associated with the link.

[0140] The execution step 150 of the test scenario 26 may also include the processing 153 of the operating mode commands. As a reminder, the operating mode commands are broadcast by the controller 20 to the link emulation modules 41 to change the operating mode during the execution 150 of the scenario (real-time mode, slow-motion mode, accelerated mode, step-by-step mode, forward or backward, pause, jump to a particular moment in the scenario, etc.). In the step-by-step mode, the link emulation modules 41 perform an emulation step forward or backward and stop while waiting for a new command. In the playback modes (real-time, slow-motion or accelerated), the link emulation modules 41 operate autonomously.The emulation step is calculated by the link emulation modules 41 depending on the operating mode: it corresponds for example to the simulation step in real-time mode, to an oversampling of the simulation step in slow motion mode, or to an undersampling of the simulation step in accelerated mode.

[0141] As illustrated in Figure 9, the method 100 may also comprise a validation and / or analysis phase 150 of the application module 42 of at least one of the nodes 40, for example from debugging traces captured by the application modules 42 to be tested, and / or by a network supervision node recovering information from the supervised application modules 42.

[0142] The proposed solution has many advantages. In particular, it makes it possible to emulate a network comprising a large number of nodes and a large number of links. In the example embodiment described previously with reference to Figure 4, with a rack of sixteen servers and twenty-four physical interfaces per server, it is possible to emulate three hundred and eighty-four nodes (16 x 24 = 384) for which a physical link with the switching system is reserved for each node (as in the example illustrated in Figure 5). The number of different communication links that can be established between the nodes during a test scenario can then reach several thousand or even several tens of thousands of links. It thus becomes possible to emulate a non-terrestrial communication network comprising a LEO constellation of several hundred satellites (for example approximately three hundred satellites).

[0143] During the scenario execution phase 150, the communication between the controller 20 and the nodes 40 is limited to the broadcasting of control messages relating to possible changes in operating mode. Thus, the bandwidth requirements on the switching system 30 for the control of the nodes 40 during the scenario execution phase 150 are almost zero. The broadcasting of the control messages also allows control of the switching system 30 and the nodes 40 from a controller 20 several hundred kilometers away without impacting the performance of the emulation.

[0144] The determination of the instantaneous characteristics of the nodes and links at a given instant of the scenario is entirely implemented by the link emulation modules 41. Similarly, the control 152 of the packets is entirely taken care of by the link emulation modules 41. This distributed architecture has the particular advantage of better distributing the computational load between the controller 20 and the link emulation modules 41, and of avoiding synchronization problems between the nodes 40 (with a centralized system, the updating of the nodes by the controller would cause a desynchronization problem due to the sequencing of the loading of the characteristics of the nodes at each emulation step).

[0145] The proposed solution offers a very good representativeness of the system under test. More specifically, the link emulation modules 41 can directly send radio signal quality information (signal-to-noise ratio, Doppler, interference level, etc.) and platform information (position, attitude) to the nodes 40 in order to test advanced routing algorithms (handover algorithms in particular).

[0146] The proposed solution also facilitates prototyping, debugging, verification and validation of the network. The controller 20 allows for the implementation of different operating modes. During prototyping and debugging phases, the step-by-step mode allows the emulation to be stopped, the node state to be analyzed and the network events and the network topology to be correlated at a given time. During verification phases, the time can be accelerated so as to reduce the execution of a test scenario (topology changes are slower than the execution speed of the protocol layers under test). It is therefore possible to verify a scenario lasting several hours in a few minutes and to determine the margins of the system under test in relation to more frequent topology changes than in reality. During validation phases, the emulator can operate in real time in order to test end-to-end real-time services.

[0147] The proposed solution also offers a particularly simple configuration of the emulation system 10. The connection of the switching system 30 with Ethernet cables can be done only once. There is no need to rewire the switching system 30 for different scenarios. The configuration of virtual local area networks on the switching system 30 is done by software by the controller 20 from the scenario data. The scenario management module 22 allows the platform, communication and network aspects to be managed in a unified manner. The data from the scenario are used both for simulation (by the simulation module 23) and for emulation (by the link emulation modules 41). This consistency of the simulation and emulation data makes it possible to avoid data handling errors that could be observed in separate simulation and emulation systems.

[0148] The proposed solution advantageously makes it possible to integrate real equipment 60 into the emulation system 10 (as in the example illustrated in Figure 4) and to test it under realistic conditions, for example to measure its electrical consumption, or to ensure the correct functioning of the protocol layers tested on the real hardware on which they will be implemented in the real network.

Claims

Claims 1. System (10) for emulating a network with variable topology, said system (10) comprising a controller (20), a switching system (30) and network nodes (40) each comprising an application module (42), characterized in that the controller (20) is adapted to generate, as a function of a stored test scenario (26), information (27) on the states of the nodes and characteristics (28) of communication links likely to be established between the application modules (42) of the nodes (40) during the scenario, the information (27) on the states of the nodes and the characteristics (28) of the communication links being established in the form of time series, each node (40) comprises a link emulation module (41) emulating a physical protocol layer and interfacing with the application module (42), the application module (42) comprising layers higher level protocols than the physical protocol layer,each emulation module (41) comprising a memory for storing state information (27) specific to this node and characteristics (28) of the communication links coming from and going to this node provided in the form of time series by the controller (20), the controller (20) is configured to transmit to the link emulation modules (41) a start of execution command common to all the nodes, each node is configured to operate autonomously during execution to process packets in transmission or reception and to process the time series specific to this node according to a virtual time:, - each link emulation module (41) is adapted to regularly update, from the node-specific time series, instantaneous node state information and instantaneous characteristics of the communication links coming from and going to the node, - each emulation module (41) is configured to control the transmission and reception of traffic packets according to the instantaneous characteristics of the communication links, and - each application module (42) is adapted to transmit and receive packets via the emulation module (41) and carry out routing which can be a function of the instantaneous state information and the instantaneous characteristics of the communication links updated by the emulation module (41). Tl 2. System (10) according to claim 1, in which the information (27) of states of the nodes generated by the controller (20), according to the test scenario (26), comprises geographical information relating to trajectories of the nodes, in the form of a time series.

3. System (10) according to any one of claims 1 to 2, in which the switching system (30) is configured by the controller (20) to establish virtual networks above physical links (31, 33, 35) of the switching system, these virtual networks being intended to be managed by the switching system and configured according to the communication links likely to be established between the application modules (42) during the scenario (26), these virtual networks remaining unchanged during the scenario.

4. System (10) according to any one of claims 1 to 3, in which at least one of the nodes (40) of the network corresponds to a satellite or an aircraft.

5. System (10) according to any one of claims 1 to 4, in which each emulation module (41) is configurable in step-by-step mode, in slow motion mode, in accelerated mode or in real time mode, from operating mode commands sent by a broadcast mechanism to all the nodes, the link emulation module (41) being configured to calculate a virtual time from the operating mode command, while the application module (42) is configured to operate in real time.

6. System (10) according to any one of claims 1 to 5, in which the processing of a packet in reception by the link emulation module (41) from another node comprises at least one of the following operations, depending on instantaneous characteristics (53b) in reception of the link on which the packet is received: - deletion of the package if the link is not operational, - an addition of a transmission delay, - adding at least one bit-level or frame-level error to the packet to simulate a transmission error.

7. System (10) according to any one of claims 1 to 6, in which the processing of a packet in transmission by the module (41) for emulating links to another node comprises a traffic smoothing function as a function of instantaneous characteristics (53a) in transmission of the link on which the packet is to be transmitted.

8. System (10) according to any one of claims 1 to 7, wherein in at least one of the nodes (40), the link emulation module (41) is configured to multiplex several virtual links (45) between the application module (42) and one or more other application modules (42) on a single physical link (35) of the switching system (30).

9. System (10) according to any one of claims 1 to 8, wherein in at least one of the nodes (40), the link emulation module (41) is configured to multiplex several virtual links (45) between the application module (42) and one or more other application modules (42) on several physical links (35) of the switching system (30).

10. System (10) according to any one of claims 1 to 9, in which at least one server (50) implements a plurality of nodes (40), each node being implemented on a virtual machine of the server (50), each virtual machine implementing a link emulation module (41) on a first core and an application module (42) on a second core. 1 1. Method (100) for emulating a network with variable topology, said method being implemented by a system (10) comprising a controller (20), a switching system (30) and network nodes (40) each comprising an application module (42), the method (100) being characterized in that it comprises: a simulation step (120), in which the controller (20) generates, as a function of a stored test scenario (26), information (27) on the states of the nodes and characteristics (28) of communication links likely to be established between the application modules (42) of the nodes (40) during the scenario (26), the information (27) on the states of the nodes and the characteristics (28) of the communication links being established in the form of time series, a configuration step (133) of the nodes (40),in which the controller (20) provides each node (40) with the information (27) of states specific to this node and the characteristics (28) of the communication links coming from and going to this node, each node comprising a link emulation module (41) emulating a physical protocol layer and interfacing with the application module (42), the application module (42) comprising protocol layers of a higher level than the physical protocol layer, a test scenario launch step (140), in which the controller (20) transmits to the link emulation modules (41) a start of execution command common to all the nodes, a test scenario execution step (150) in which each node (40) operates autonomously to process packets in transmission or reception and to process the time series specific to this node as a function of a virtual time, the execution step (150) comprising for each node (40) the following sub-steps: - a regular update (151), by the link emulation module (41), from the node-specific time series, of instantaneous node state information and instantaneous characteristics of the communication links coming from and going to the node, - a control (152) of packets in reception or in transmission by the emulation module (41) from the instantaneous characteristics of the communication links coming from and going to the application module (42), - packet routing (154), in which the application module (42) transmits and receives packets via the emulation module (41) and performs routing which can be a function of the instantaneous state information of the node and the instantaneous characteristics of the communication links updated by the emulation module (41).

12. Emulation method (100) according to claim 11, comprising, prior to the simulation step (120), a preliminary step of definition (110), by a user, of a test scenario (26) containing geographical and geometric parameters of the nodes, communication parameters of the nodes, propagators used to calculate trajectories of the nodes and a definition of the communication links to be taken into account between the nodes, the scenario comprising a start time and an end time.

13. Emulation method (100) according to any one of claims 11 to 12, further comprising, prior to execution (150), a configuration step (131) of the switching system (30) in which the controller (20) establishes virtual networks above physical links (31, 33, 35) of the switching system (30), these virtual networks being intended to be managed by the switching system and being configured according to the communication links likely to be established between the application modules (42) during the scenario (26), these virtual networks remaining unchanged during the scenario.

14. Method (100) according to any one of claims 11 to 13, comprising a broadcast, by the controller (20) to the nodes (40) of the system, of an operating mode command making it possible to configure the execution (150) in step-by-step mode, in slow motion mode, in accelerated mode or in real-time mode, and a step of processing (153) the operating mode command by the link emulation module (41) of each node (40), the operating mode command optionally comprising a virtual synchronization time between the nodes (40).

15. Method (100) according to any one of claims 11 to 14, comprising a validation and / or analysis step (160) comprising an analysis of traces and / or statistics of each node (40) acquired directly by the application modules (42) and / or by a network supervision node recovering information from the supervised application modules (42).

Images