Emulator of a variable topology network 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 includes an emulation module for emulating a physical layer and an application module with higher-level protocol layers to be tested. During the execution of a test scenario, the emulation module of each node is configured to calculate instantaneous node state information and instantaneous characteristics of the links to and from the node. The node's application module is adapted to send and receive packets via the emulation module and to route packets based on the instantaneous node and link information. Each emulation module is configured to control packet transmission and reception based on the instantaneous characteristics of the communication links. Figure for the abstract: Fig. 1

Description

Title of the invention: Emulator of a variable topology network and emulation method. Field of the invention

[0001] The present invention relates to the field of telecommunications, and more particularly to systems for prototyping, developing, and testing applications operating on variable topology networks. The invention specifically relates to a system for emulating a variable topology network. The invention is particularly well-suited for emulating a non-terrestrial network comprising a space and / or air component and involving a large number of nodes. Prior art

[0002] The sixth generation of cellular communication technologies, or 6G, promises to bring significant improvements, particularly in terms of speed, reliability, coverage, and new features. Among these developments, the standardization of non-terrestrial networks (or NTNs) is a subject of great importance.

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

[0004] Non-terrestrial networks undergo frequent changes in their topology, particularly due to the mobility of some of their infrastructure, variable propagation delays, and disturbances (obstructions, atmospheric attenuation, interference, Doppler, transmission errors, etc.) in radio or optical communication links. Terrestrial network protocols, which operate for quasi-fixed topologies with low-latency, low-error links (fiber optics, cable, microwave links), must therefore be adapted to function in a non-terrestrial network. Within the framework of the 6G standard, the standardization of non-terrestrial networks 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.

[0005] Solutions exist 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 equipment, the practical difficulties related to cabling, and the resulting space requirements.

[0006] Patent application EP2955876A1 proposes the simulation of multiple communication links between network nodes, using a set of virtually interconnected simulated modules. Such a solution does not, in particular, allow for precise control of the evolution 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 the precision needed to realistically test routing algorithms. Description of the invention

[0007] The present invention aims to provide a test solution for prototyping, developing, and testing a variable topology communication network while enabling better network representativeness. The solution is particularly well-suited for emulating a non-terrestrial network comprising a space and / or air component and several hundred mobile nodes.

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

[0009] The controller is adapted to generate, according to a stored test scenario, information on the state of the nodes and the characteristics of communication links that may be established between the application modules of the nodes during the scenario, the information on the state of the nodes and the characteristics of the communication links being established in the form of time series.

[0010] Each node includes a link emulation module emulating a physical protocol layer and interfacing with the application module, the application module comprising protocol layers higher than the physical protocol layer, each emulation module including a memory to store state information specific to that node and characteristics of the communication links to and from that node provided as time series by the controller.

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

[0012] Each node is configured to operate autonomously during execution to process packets being sent or received and to process time series specific to that node according to a virtual time: - Each link emulation module is adapted to regularly update, using node-specific time series, instantaneous information on the node's state and instantaneous characteristics of the communication links to and from the node. - Each emulation module is configured to control the transmission and reception of traffic packets based on the instantaneous characteristics of the communication links, and - Each application module is adapted to send and receive packets via the emulation module and perform routing that can be based on instantaneous state information and instantaneous characteristics of the communication links updated by the emulation module.

[0013] 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 loss) and to develop and test advanced routing algorithms exploiting information relating to the state of the nodes and the characteristics of the communication links between the nodes.

[0014] In particular embodiments, the emulation system may further include one or more of the following features, taken individually or in all technically possible combinations.

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

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

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

[0018] In particular embodiments, the state information of the nodes 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.

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

[0020] In particular embodiments, the switching system is configured by the controller to establish virtual networks over the 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 that may be established between the application modules during the scenario. These virtual networks remain unchanged during the scenario.

[0021] In particular embodiments, the extent of the virtual networks is strictly limited to the links that can be established according to the scenario.

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

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

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

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

[0026] In particular embodiments, the processing of a received packet by the link emulation module from another node includes at least one of the following operations, depending on instantaneous received characteristics of the link on which the packet is received: - the package will be removed if the link is not operational, - the addition of a transmission delay, - adding at least one bit-level or frame-level error in the packet to simulate a transmission error.

[0027] 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 transmitting characteristics of the link on which the packet is to be sent.

[0028] 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.

[0029] 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.

[0030] 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.

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

[0032] 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.

[0033] According to a second aspect, a method for emulating a network with a variable topology is proposed. 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: - a simulation step, in which the controller generates, based on a stored test scenario, node state information and communication link characteristics that may be established between the application modules of the nodes during the scenario, with the node state information and communication link characteristics being established in the form of time series, - a node configuration step, in which the controller provides each node with node-specific state information and the characteristics of the communication links to and from that node, each node having a link emulation module emulating a physical protocol layer and interfacing with the application module, the application module comprising protocol layers higher than the physical protocol layer, - a test scenario launch step, in which the controller transmits a common start-execution command to the link emulation modules, applicable to all nodes, - an execution stage of the test scenario in which each node operates autonomously to process packets in transmission or reception and to process time series specific to that node according to a virtual time, the execution stage comprising for each node the following sub-steps: • a regular update, by the link emulation module, based on node-specific time series, of instantaneous node state information and instantaneous characteristics of communication links to and from the node, • packet control during reception or transmission by the emulation module based on the real-time characteristics of the communication links to and from the application module, • packet routing, in which the application module sends and receives packets via the emulation module and performs routing that can be based on instantaneous node state information and instantaneous communication link characteristics updated by the emulation module.

[0034] In particular embodiments, the emulation method may further include one or more of the following characteristics, taken individually or in all technically possible combinations.

[0035] In particular embodiments, the emulation method includes, 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.

[0036] In particular embodiments, the emulation process includes, prior to the execution of the scenario, a switching system configuration step in which the controller establishes 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 are configured according to the links of communication that may be established between application modules during the scenario, these virtual networks remaining unchanged during the scenario.

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

[0038] In particular embodiments, the emulation process includes a controller-driven configuration step 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.

[0039] In particular embodiments, the emulation method includes a broadcast, by the controller to the nodes of the system, of an operating mode command enabling the execution to be configured in step-by-step mode, in slow-motion mode, in accelerated mode or in real-time mode, and a processing step of the operating mode command by the link emulation module of each node, the operating mode command optionally including a virtual synchronization time between the nodes.

[0040] In particular embodiments, the emulation process includes 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 monitoring node retrieving information from the monitored application modules. Presentation of the figures

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

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

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

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

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

[0046] [Fig.5] a first example of the implementation of a node on a virtual machine from a server,

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

[0048] [Fig.7] an example of the implementation of multiple nodes on a virtual machine of a server,

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

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

[0051] In these figures, identical reference numerals from one figure to another designate identical or analogous elements. For clarity, the elements shown are not necessarily to the same scale, unless otherwise stated. Detailed description of the invention

[0052] As explained previously, the invention makes it possible to create, in a laboratory environment, a digital twin of an existing or developing real network. The invention is particularly well suited to a network with a large number of nodes whose positions may vary over time. This variability in the network topology may concern not only user nodes, but also nodes corresponding to elements of the network infrastructure, such as routers embedded in satellites orbiting the Earth, in aerial platforms (drones, airplanes, balloons), or in land vehicles (trains, ships).

[0053] Figure 1 illustrates, by way of example, 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-Earth orbit satellite, and an aircraft. The upper part of Figure 1 represents the actual network, while its lower part represents the digital twin of the actual network, i.e., the emulated network.

[0054] As illustrated in [Fig. 1], an emulation system 10 allows the emulation of 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 by real machines, and the switching system 30 can include one or more Ethernet switches and physical interconnection links such as Ethernet cables.

[0055] The controller 20 can, in particular, allow the creation of a test scenario via a human-machine interface (HMI), and the definition of the characteristics of the nodes and links. communication linking the different nodes during the scenario, configuring the system, and then launching and controlling the execution of the scenario remotely.

[0056] 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 of the node's antennas, etc.). The characteristics of the communication links define, in particular, a transmission quality (in other words, a link budget, for example, in terms of data rate, propagation delay, error rate, attenuation, etc.) for each link that can be established between two nodes in the scenario under consideration. 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.

[0057] The proposed solution follows a hybrid 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 processing; second, the behavior of the physical layer of the different nodes during the scenario is emulated in real time. Such arrangements allow for real-time debugging of the layers above the physical layer.

[0058] Figure 2 schematically illustrates how the various protocol layers of the OSI model (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 containing higher-level protocol layers to be tested. These higher-level layers correspond to the OSI model layers located above the physical layer (data 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 real network equipment. As illustrated in Figure 2, the switching system 30 provides communication between the link emulation modules 41.

[0059] Thus, by executing 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.

[0060] In particular, the emulation system 10 allows testing of 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 network In cellular networks, routing must also be optimized based on radio criteria and user mobility. In non-terrestrial networks, the position of mobile network infrastructure elements (particularly space or aerial platforms) must also be considered. Routing algorithms then become especially complex. As a non-exhaustive example, in a communication network involving satellites in low Earth orbit (LEO) or medium Earth orbit (MEO), routing algorithms must take into account the need to limit or even prevent emissions in certain geographical regions, particularly around the geostationary arc, at the poles, or over certain countries.Routing algorithms can also take into account the position of the nodes to determine if they are within line of sight of each other ("LOS"), as well as the orientation of the nodes' antennas.

[0061] 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 a network device). As will be seen later, each link emulation module 41 interfaces directly with one or more physical links of the switching system 30.

[0062] Fig. 3 schematically represents an example of an embodiment of the controller 20 of the emulation system 10, and its interactions with the switching system 30 and the various nodes 40.

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

[0064] The human-machine interface 21 allows a user to create a test scenario 26, configure the emulation system 10, and launch and control the execution of the emulation. The human-machine interface 21 includes, for example, an application programming interface (API) for creating the scenario 26 and a graphical user interface (GUI) for analyzing the simulation results, for controlling the execution of the emulation, and / or for analyzing the emulation results.

[0065] The scenario generation module 22 allows the creation of test scenarios 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, generator, etc.). traffic, etc). Communication links are unidirectional and allow transmitters and receivers to be connected for link budget calculations.

[0066] It should be noted, however, that the scenario generation module 22 is not essential to the invention. For example, nothing would prevent 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 removable storage memory). Furthermore, the controller 20 can optionally store a plurality of predetermined scenarios selectable by a user (each scenario being intended to be executed individually).

[0067] Based on scenario 26, the simulation module 23 allows the definition, in the form of time series, of, on the one hand, information 27 on the states of the nodes 40 and, on the other hand, characteristics 28 of the communication links that can be established between the application modules 42 of the nodes 40 during scenario 26. The node state information 27 relates 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. The link characteristics relate to the 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..

[0068] The simulation module 23 can in particular be implemented by an orbital simulator such as STK (acronym for "System Tool Kit" in English).

[0069] The state information 27 (or platform information) of a node 40 relates, for example, to the position, velocity, or attitude of a node over time (for example, it represents the orbital position and attitude of a satellite orbiting the Earth). It may also relate to information concerning the geometries of the nodes, such as the orientation of one or more of the node's antennas. These characteristics are determined for each simulation step of the scenario, and they allow the communication links existing at the considered simulation step to be determined. For example, for two nodes corresponding to satellites in orbit, it is possible to determine, at each simulation step, whether the two satellites are within line of sight (LOS). If so, a communication link is considered operational between the two nodes, and the characteristics 28 of the communication link can be calculated.The characteristics 28 of a communication link are for example related to a throughput, a propagation delay, jitter, a bit error rate (BER for "Bit Error Rate" in English) or a frame error rate (FER for "Frame Error Rate" in English), a doppler level, a . interference rate, signal-to-noise ratio, signal attenuation, thermal noise, etc.

[0070] The orchestration module 24 allows in particular to configure the switching system 30, to control a hypervisor 51 of a virtualization software (for example a software of the VMWare type) 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, and then to launch and control the execution of the scenario in real time.

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

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

[0073] 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 time. On the contrary, the determination of the characteristics of the nodes and communication links at a given time is carried out autonomously by the link emulation modules 41.

[0074] 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.

[0075] 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: slow speed or step-by-step mode for debugging, accelerated speed for validation, or real time for a demonstration.

[0076] Thus, one or more of the following operating modes can be supported during the scenario execution phase: - real-time mode, - Slow motion mode, with execution slower than real time, - Accelerated mode, with execution faster than real time, - Step-by-step mode.

[0077] 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 in forward or reverse (i.e., in the normal direction of time flow, or in reverse). 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. User control of the emulation can be performed via the human-machine interface 21. It is also possible to start 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 (Tv) based on the virtual time of the start of the scenario (To), an internal clock (TR), and the current operating mode (Tv = To + k.TR, with k > 1 in accelerated mode, k < 1 in slow-motion mode, and k = 1 in real-time mode). The internal clock of the link emulation module 41 corresponds, for example, to a clock on the server hosting the virtual machine on which the node is implemented. The clocks of the different nodes are synchronized before the emulation execution starts (for example, via the start command), and any potential time drift between the clocks of the different nodes is considered negligible during the execution of the scenario. Optionally, the operating mode command can include a virtual synchronization time between the nodes.

[0078] Fig. 4 schematically represents an example of an implementation of an emulation system 10 according to the invention, with a large number of nodes 40 implemented by virtual machines running on different servers 50.

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

[0080] It should be noted that, as illustrated in [Fig. 4], a node 40 can also be implemented by actual equipment 60 intended to be carried in a payload of a satellite, aircraft, drone, or ground platform. These arrangements allow the protocol layers to be tested (i.e., the application module 42) to be validated on the actual hardware on which they will be implemented in the real network. In this case, the actual equipment is interfaced with a link emulation module 41.

[0081] The switching system 30 connects each node 40 to the controller 20 and to the other nodes 40 via physical links 31, 33, 35. These physical links correspond, for example, to Ethernet cables (electrical cable or fiber optic cable). 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 various access switches 34 provide a sufficient number of Ethernet ports.

[0082] In one embodiment, the emulation system 10 comprises a bay of sixteen servers 50, a switching system 30, and a controller 20. Each server 50 has 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 if the controller 20 and the switching system 30 are located on the same local area network (LAN), or a long-distance link over a private or public wide area network (WAN) if the controller 20 and the switching system are not co-located. The 33 connection links between switch 32 and switches 34 are 100 Gbps Ethernet cables.The 35 connecting links between the switches 34 and the nodes 40 are 25 Gbps Ethernet cables.

[0083] The switching system 30 provides 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 connecting link 35. The nodes 40 can communicate with each other only through 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 maximize the representativeness of the system under test.

[0084] The hardware architecture formed by the switching system 30 also makes it possible to guarantee the bandwidth necessary for communications to or from 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.

[0085] To limit the bandwidth required on the switching system 30, the controller 20 can be configured to define a plurality of virtual local area networks (VLANs) on the switching system 30. Different VLANs can be associated with the different Possible links between nodes are used to reduce congestion at switches 32 and 34. The switching system configuration 30 involves defining virtual networks between the nodes that may be interconnected during the scenario. In certain implementation modes, the scope of the virtual networks is strictly limited to the links that may be established according to the test scenario.

[0086] 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 various 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 VLAN configuration remains fixed for the duration of an emulation (execution of a scenario) and aims to reduce the bandwidth requirements on the switching system 30. The possibility of communication between two nodes at a given time is managed dynamically by the link emulation modules 41.

[0087] A VLAN common to all nodes allows the controller 20 to communicate with all nodes 40 using Ethernet broadcast mechanisms, in particular for sending the start execution command or for a command relating to a change of operating mode (pause, step-by-step mode, slow or fast reading, etc.).

[0088] Figures 5 to 7 schematically represent different examples of implementation of a node 40 on a virtual machine of a server 50.

[0089] In the first implementation example shown in [Fig. 5], and in the second implementation example shown in [Fig. 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 consists of two processor cores 52 of the server 50. The first core ("core 1") is used to run the link emulation module 41. The second core ("core 2") is used to run the application module 42 (i.e., the protocol layers located above the physical layer).

[0090] The application module 42 interfaces with the switching system 30 via the link emulation module 41. To this end, 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. By way of example, a satellite-type node 40 may simultaneously have more than ten operational virtual links 45, for example, four interconnected links satellite, 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 (Ethernet patch cable).

[0091] In the first implementation example illustrated in [Fig. 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 standard (Virtual Extensible Local Area Network) can be used for link multiplexing.

[0092] In the second implementation example illustrated in [Fig. 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. However, nothing prevents other multiplexing configurations, 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 with virtual links 45 with high throughput constraints. On the other hand, the number of nodes that the system can support is reduced.

[0093] In the third implementation example illustrated in [Fig.7], a single 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 (increasing the number of nodes 40 that can be supported by the emulation system 10).

[0094] In these various examples, separating the link emulation module 41 and the application module 42 of the same node 40 onto two separate cores allows for better isolation of each component's functionalities. This prevents the emulation from impacting the operation of the protocol layers under test. This results in a more representative system under test.

[0095] It should be noted that the embodiment examples described with reference to Figures 5 to 7 are by no means limiting. Other embodiments of a node 40 can be considered. For example, it is possible 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.

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

[0097] 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 time series specific to that node according to the virtual time calculated by the emulation module 41.

[0098] Each link emulation module 41 is configured to regularly update, from 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 Figures 5 to 7, RAM, 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 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 according to the simulation step.In particular, a virtual time step calculated based on 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 be the same as the simulation step, or a subsampling or oversampling of the simulation step.

[0099] Thus, during the execution of the scenario, each application module 42 is adapted to send and receive packets via the emulation module 41 and to perform routing that can be based on 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 sending and receiving of traffic packets according to the instantaneous characteristics of the communication links.

[0100] The operations of updating real-time information and processing transmitted or received packets are performed 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, not a centralized one). The link emulation modules 41 operate synchronously without intervention from the controller 20, except possibly for commands to change the operating mode.

[0101] In particular implementation modes, the memory of the emulation module 41 for storing node-specific state information 27 and the characteristics 28 of the communication links to and from the node is non-shared memory. Only the instantaneous state information of the node 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 prevent the application module from accessing data to which it does not have access in reality (in particular, data concerning the future evolution of the links).

[0102] Fig. 8 schematically illustrates the processing of packets in transmission and reception by a link emulation module 41.

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

[0104] The processing of a received packet by the link emulation module 41 from another node includes at least one of the following operations, depending on the instantaneous 53b receive characteristics of the link on which the packet is received: - a packet deletion 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 line of sight), - 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), - adding at least one bit-level or frame-level error in the packet to simulate a transmission error.

[0105] The processing of a transmitted packet by the link emulation module 41 to another node includes a traffic smoothing function, based on the instantaneous transmitting characteristics 53a of the link on which the packet is to be transmitted. The function of Smoothing may include queuing the packet to comply with a transmission rate of the link on which the packet is to be sent.

[0106] Figure 9 schematically represents the main steps of a method 100 for emulating a network with variable topology. This method 100 is implemented, for example, by an emulation system 10 such as the one described above with reference to Figures 1 to 8.

[0107] As illustrated in [Fig. 9], the emulation process 100 may initially include a definition step 110 of a test scenario 26. This definition step 110 specifies 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 implemented, for example, using the human-machine interface 21 and the scenario generation module 22 described previously with reference to [Fig. 3]. As explained previously, this step is optional, and there is nothing to prevent the generation of the test scenario 26 from being considered as not being part of the emulation process 100 (in which case the test scenario is an input to the emulation process 100).

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

[0109] The emulation method 100 includes a simulation step 120 during which the controller 20 generates, according to the test scenario 26, the node state information 27 and the communication link characteristics 28 that may be established between the application modules 42 of the nodes 40 during the scenario 26. As a reminder, the node state information 27 and the communication link characteristics 28 are established in the form of time series. This simulation step 120 is implemented, for example, using the simulation module 23 described previously with reference to [Fig. 3].

[0110] The process 100 then includes an initialization step 130, which includes in particular the configuration 133 of the link emulation modules 41.

[0111] For this configuration 133, the controller 20 provides each node 40 with node-specific state information 27 and the characteristics 28 of the communication links to and from that node. The node configuration 133 may also include 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.

[0112] For each node 40 implemented on a virtual machine of a server 50, the initialization step 130 may also include 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 a virtualization software running on the server 50.

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

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

[0115] During the execution 150 of the test scenario, each node 40 operates autonomously to process packets in transmission or reception and to process time series specific to that node as a function of virtual time.

[0116] In particular, the execution 150 of the test scenario includes, for each node 40: - a regular update 151, by the link emulation module 41, from node-specific time series, of instantaneous node state information and instantaneous characteristics of the communication links to and from the node, - a control of 152 packets received or transmitted by the emulation module 41 based on the instantaneous characteristics of the communication links coming from and going to the application module 42, - a 154 packet routing, in which the application module 42 sends and receives packets via the emulation module 41 and performs routing based on the instantaneous values ​​53 of the node state information and the communication link characteristics updated by the emulation module 41.

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

[0118] 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, fast-motion mode, step-by-step mode, forward or backward, pause, jump to a specific point in the scenario, etc.). In step-by-step mode, the link emulation modules 41 perform one emulation step forward or backward and stop, waiting for a new command. In the playback modes (real-time, slow-motion, or fast-motion), the link emulation modules 41 operate autonomously.The emulation step size is calculated by the 41 link emulation modules according to the operating mode: it corresponds, for example, to the simulation step size in real-time mode, to an oversampling of the simulation step size in slow-motion mode, or to an undersampling of the simulation step size in accelerated mode.

[0119] As illustrated in [Fig.9], the process 100 may also include a validation and / or analysis phase 150 of the application module 42 of at least one of the nodes 40, for example from debug traces captured by the application modules 42 to be tested, and / or by a network monitoring node retrieving information from the monitored application modules 42.

[0120] The proposed solution has many advantages. In particular, it allows the emulation of a network with a large number of nodes and a large number of links. In the embodiment described above with reference to [Fig. 4], with an array 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 to the switching system is reserved for each node (as in the example illustrated in [Fig. 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 with a LEO constellation of several hundred satellites (for example, approximately three hundred satellites).

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

[0122] The determination of the instantaneous characteristics of the nodes and links at a given time in the scenario is entirely implemented by the link emulation modules 41. Similarly, packet control 152 is entirely handled 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, updating the nodes by the controller would cause a desynchronization problem due to the sequencing of the loading of the node characteristics at each emulation step).

[0123] The proposed solution offers a very good representation of the system under test. More specifically, the link emulation modules 41 can directly transmit 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).

[0124] The proposed solution also facilitates network prototyping, debugging, verification, and validation. Controller 20 allows for the implementation of different operating modes. During prototyping and debugging phases, step-by-step mode allows the emulation to be stopped, the state of nodes to be analyzed, and network events and the network topology to be correlated at a given time. During verification phases, time can be accelerated to reduce the execution time 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 against topology changes more frequent than in reality. During validation phases, the emulator can operate in real time to test end-to-end real-time services.

[0125] The proposed solution also offers a particularly simple configuration of the emulation system 10. Connecting the switching system 30 with Ethernet cables only needs to be done once. There is no need to rewire the switching system 30 for different scenarios. Virtual local area network configuration on the switching system 30 is done via software by the controller. 20. Based on scenario data. Scenario management module 22 manages platform, communication, and network aspects in a unified manner. Data from the scenario is used both for simulation (by simulation module 23) and for emulation (by link emulation module 41). This consistency between simulation and emulation data prevents data manipulation errors that might occur in separate simulation and emulation systems.

[0126] The proposed solution advantageously allows real equipment 60 to be integrated into the emulation system 10 (as in the example illustrated in [Fig.4]) and tested under realistic conditions, for example to measure its power consumption, or to ensure the proper functioning of the protocol layers tested on the real hardware on which they will be implemented in the real network.

Claims

1. Demands A system (10) for emulating a network with a 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, according to a stored test scenario (26), node state information (27) and communication link characteristics (28) that may be established between the application modules (42) of the nodes (40) during the scenario, the node state information (27) and the communication link characteristics (28) being established in the form of time series, each node (40) 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 higher than the physical protocol layer,each emulation module (41) having a memory to store information (27) of states specific to that node and characteristics (28) of the communication links to and from that node provided as time series by the controller (20), the controller (20) is configured to transmit to the link emulation modules (41) a start execution command common to all 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 that node according to a virtual time:, - each link emulation module (41) 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, - 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 send and receive packets via the emulation module (41) and perform routing that can be based on instantaneous state information and instantaneous characteristics of the communication links updated by the emulation module (41).

2. System (10) according to claim 1, wherein the node state information (27) generated by the controller (20), depending on the test scenario (26), includes geographical information relating to node trajectories, in the form of a time series.

3. System (10) according to any one of claims 1 to 2, wherein the switching system (30) is configured by the controller (20) to establish virtual networks over 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 that may 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, wherein 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, wherein each emulation module (41) is configurable in step-by-step mode, slow-motion mode, fast-motion mode or real-time mode, from operating mode commands sent by a broadcast mechanism to all 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, wherein the processing of a packet received by the link emulation module (41) from another node includes at least one of the following operations, depending on instantaneous characteristics (53b) received by the link on which the packet is received: - dropping the packet if the link is not operational, - adding 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, wherein the processing of a packet in transmission by the link emulation module (41) to another node includes a traffic smoothing function based on instantaneous transmitting characteristics (53a) 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) over 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) over several physical links (35) of the switching system (30).

10. System (10) according to any one of claims 1 to 9, wherein 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.

11. A method (100) for emulating a variable topology network, 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, based on a stored test scenario (26), node state information (27) and communication link characteristics (28) that may be established between the application modules (42) of the nodes (40) during the scenario (26), the node state information (27) and the communication link characteristics (28) being established in the form of time series; a node configuration step (133), in which the controller (20) provides each node (40) the information (27)

12. of states specific to this node and the characteristics (28) of the communication links to and from 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 higher 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-execution command common to all nodes, a test scenario execution step (150) in which each node (40) operates autonomously to process packets in transmission or reception and to process time series specific to that node according to a virtual time, the execution step (150) comprising for each node (40) the following substeps: - a regular update (151), by the link emulation module (41), based on node-specific time series, of instantaneous node state information and instantaneous characteristics of communication links to and from the node, - a control (152) of packets received or transmitted by the emulation module (41) based on the instantaneous characteristics of the communication links coming from and going to the application module (42), - a packet routing (154), in which the application module (42) sends and receives packets via the emulation module (41) and performs routing that can be based on instantaneous node state information and instantaneous communication link characteristics updated by the emulation module (41). Method (100) of emulation 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 including a start time and an end time.

13. Method (100) of emulation 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 over 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 that may be established between the application modules (42) during the scenario (26), these virtual networks remaining unchanged during the scenario.

14. A 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 enabling the execution (150) to be configured in step-by-step mode, in slow-motion mode, in fast-motion mode or in real-time mode, and a processing step (153) of 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) including an analysis of traces and / or statistics of each node (40) acquired directly by the application modules (42) and / or by a network monitoring node retrieving information from the monitored application modules (42).