A two-stage hybrid parallel network simulation method

Abstract

The specification provides a two-stage hybrid parallel network simulation method, by establishing a mapping relationship between platform identification and partition identification, and determining the target simulation partition to which the destination platform belongs according to the mapping relationship when a network event occurs, so that the network event completes the attribution determination before entering any transmission link, and then is shunted to two independent transmission paths according to the determination result; when the simulation partition to which the destination platform belongs is the simulation partition corresponding to the physical node, the network event is transmitted through the same shared memory segment mapped to the respective address spaces of the related network simulation processes, and no longer experiences serialization, kernel protocol stack processing and network link transmission; when the simulation partition to which the destination platform belongs is the simulation partition corresponding to other physical nodes, the network event is transmitted through the cross-node message transmission channel, which bears the necessary overhead of crossing physical nodes, and the intra-node event is not forced to bear the overhead introduced by cross-node transmission because the simulation system has cross-node expansion capability.

Description

Technical Field

[0001] This specification relates to the field of network simulation technology, and for example to a two-level hybrid parallel network simulation method. Background Technology

[0002] Network simulation is a technical means for verifying network topology, testing communication protocols, and evaluating network performance. In simulation scenarios such as integrated air-space-ground networks, vehicular networks, and mobile trunking, where there are numerous simulation platforms and their locations are constantly changing, network protocols and data packet events proceed in a discrete event manner. There are causal order constraints between events, and the simulation capacity and speed during serial execution are limited by the processing capacity of a single executor. Therefore, simulation tasks are usually executed in parallel.

[0003] In parallel execution, network simulation of the entire platform is broken down into multiple parallel simulation tasks, each task undertaking network simulation of a portion of the platform. When a network event generated by one simulation task has the platform of another simulation task as its destination, the network event needs to be passed to the simulation task undertaking the destination platform. Existing parallel methods can be roughly divided into three categories according to the level they employ.

[0004] Firstly, thread-level parallelism, which involves executing simulation tasks within a single process using multiple threads sharing memory. This approach has complex synchronization logic and is prone to out-of-order event processing and data inconsistencies.

[0005] Secondly, single-machine multi-process parallelism involves multiple processes executing simulation tasks within a single computer, exchanging simulation data between processes via shared memory or local communication mechanisms within the computer. The simulation scale of this method is limited by the processor and memory resources of a single computer, making it difficult to scale horizontally as the number of platforms increases.

[0006] Third, cross-node distributed parallelism involves dividing the simulation task across multiple physical nodes, with each node undertaking a portion of the simulation task. Nodes exchange network events generated during the simulation via network channels. In this approach, all network events are transmitted uniformly through the network channels between nodes. Even if the destination platform of a network event and the simulation task that generated the event are both handled by the same physical node, the network event still needs to undergo serialization, kernel protocol stack processing, and network link transmission, thus introducing additional transmission latency and processing overhead.

[0007] The common feature of the above three methods is that only a single-level event transmission path is set in the same simulation system: the transmission path of the event is not distinguished according to the simulation task scope to which the destination platform of the network event belongs, and there is no mechanism to select between intra-node transmission path and cross-node transmission path. Therefore, it is difficult to reduce the overhead of intra-node event transmission while having multi-node expansion capability. Summary of the Invention

[0008] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0009] Firstly, embodiments of this specification provide a two-level hybrid parallel network simulation method. The method is applied to a network simulation system comprising multiple physical nodes. Each physical node corresponds to a simulation partition and performs network simulation on a platform within that partition. Each physical node runs multiple network simulation processes and has shared memory accessible to these processes. Each network simulation process performs network simulation on its corresponding platform. A cross-node message passing channel is established between the multiple physical nodes. The method includes: Establish a mapping relationship between platform identifiers and partition identifiers; When a network simulation process within a first physical node of the plurality of physical nodes generates a network event targeting a target platform, the target simulation partition to which the target platform belongs is determined according to the mapping relationship. When the target simulation partition is the simulation partition corresponding to the first physical node, the network event is transmitted through the shared memory of the first physical node to the second network simulation process within the first physical node that performs network simulation on the target platform. When the target simulation partition is the simulation partition corresponding to the second physical node among the plurality of physical nodes, the network event is transmitted to the second physical node via the cross-node message passing channel.

[0010] The two-level hybrid parallel network simulation method provided in the embodiments of this specification can achieve the following technical effects: By establishing a mapping relationship between platform identifiers and partition identifiers, and determining the target simulation partition to which the destination platform belongs based on this mapping relationship when a network event occurs, the network event completes its attribution determination before entering any transmission stage. Then, based on the determination result, it is split into two independent transmission paths: when the simulation partition to which the destination platform belongs is the simulation partition corresponding to this physical node, the network event is transmitted through the same shared memory segment mapped to the address spaces of the relevant network simulation processes, without undergoing serialization, kernel protocol stack processing, and network link transmission; when the simulation partition to which the destination platform belongs belongs is the simulation partition corresponding to another physical node, the network event is transmitted through a cross-node message passing channel, bearing the overhead necessary for crossing physical nodes. Thus, intra-node events are not forced to bear the overhead introduced by cross-node transmission due to the simulation system's cross-node scalability, thereby reducing the latency and processing overhead of intra-node event transmission while retaining the horizontal scalability of multiple physical nodes. In one specific embodiment, the intra-node event transmission latency is reduced from approximately 10μs to approximately 1μs, and the network event processing efficiency is improved by 40%; simultaneously, through the distributed deployment of 3 physical nodes, the simulation support scale is increased from 96 platforms to 288 platforms.

[0011] Furthermore, each network simulation process performs network simulation on its corresponding platform. The network simulation processes are independent of each other in terms of model loading and event handling, enabling multiple network simulation processes to advance their respective network simulations in parallel within the same physical node. Moreover, after cross-node events reach the destination physical node, they can still reach the specific network simulation process according to the platform affiliation. The two-level routing remains consistent between and within nodes.

[0012] Furthermore, when the hash mapping routing table carries the mapping relationship between platform identifiers and partition identifiers, the query time does not increase with the increase in the number of platforms. Therefore, in simulation scenarios with a large number of platforms, the attribution determination itself will not become a new bottleneck on the event transmission path.

[0013] Furthermore, events within a node are written to and retrieved via a lock-free circular queue in shared memory. The process of events being written from the producing process to the receiving process is completed within the same shared memory segment, without needing to be transmitted through the kernel network protocol stack and cross-node network links. This reduces the latency of event transmission within a node to the order of magnitude of shared memory access.

[0014] Furthermore, when multiple lock-free circular queues set in shared memory correspond one-to-one with multiple network simulation processes within the same physical node, each network simulation process retrieves events from its corresponding queue. The event streams of different receiving processes do not interfere with each other, and the competition between the writer and the retriever is limited to a single queue. Thus, when multiple network simulation processes are running within the same physical node, low concurrency overhead can still be maintained.

[0015] Furthermore, when the cross-node event message carries the platform identifier of the destination platform, the physical node receiving the message does not need to query the mapping relationship again and can complete the distribution to the specific network simulation process locally, reducing the processing steps of cross-node events on the receiving side.

[0016] Furthermore, the actual motion state data is written to the Redis state cache service, and the availability of the state is delivered via a publish-subscribe channel in the form of notifications. This avoids the transmission of large volumes of six-DOF motion state data through the publish-subscribe channel, thus avoiding the corresponding serialization overhead. At the same time, it eliminates the need for the network simulation process to repeatedly poll the Redis state cache service to detect state updates, preventing processor idle time. The Redis state cache service can be accessed by multiple physical nodes, enabling the network simulation process to obtain platform motion states across simulation partitions on demand.

[0017] Furthermore, each network simulation process compares the data version number in the status availability notification with the version number in the local cache, and combines this with the simulation time range of data availability. Only when the data has been updated and the pending event falls within the time range will the motion status be read from the Redis status cache service, so that the reading action matches the actual needs and further reduces unnecessary cache access.

[0018] Furthermore, each physical node determines the upper bound of the time window to which it can safely advance based on the current simulation time and look-ahead of its simulation partition, and determines the minimum value among the upper bounds of the time windows of each simulation partition as the global safe advance limit. This allows each physical node to process only events whose timestamps are not greater than the global safe advance limit, thereby maintaining the temporal consistency of network events across simulation partitions without event rollback. Attached Figure Description

[0019] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic diagram of the network simulation structure provided in the embodiments of this specification; Figure 2 This is a schematic diagram of the process-level shared memory parallel layer architecture provided in the embodiments of this specification; Figure 3 This is a schematic diagram of the structure of the network-level MPI distributed parallel layer provided in the embodiments of this specification; Figure 4 This is a flowchart of a two-level hybrid parallel network simulation method provided in the embodiments of this specification. Detailed Implementation

[0020] To provide a more detailed understanding of the features and technical content of the embodiments of this specification, the implementation of the embodiments is described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this specification. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0021] The terms "first," "second," etc., in the description, claims, and accompanying drawings of the embodiments herein are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of the present specification described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0022] In the embodiments of this specification, the terms "upper," "lower," "inner," "middle," "outer," "front," and "rear," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are primarily used to better describe the embodiments of this specification and their implementations, and are not intended to limit the indicated devices, elements, or components to having a specific orientation, or to construct and operate in a specific orientation. Furthermore, some of the above terms may be used to indicate other meanings besides orientation or positional relationship; for example, the term "upper" may also be used in some cases to indicate a certain dependency or connection relationship. Those skilled in the art can understand the specific meaning of these terms in the embodiments of this specification according to the specific circumstances.

[0023] Furthermore, the terms "set up," "connect," and "fix" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral structure; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or it can be an internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of the above terms in the embodiments of this specification according to the specific circumstances.

[0024] Unless otherwise stated, the term "multiple" means two or more.

[0025] In the embodiments described in this specification, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0026] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0027] It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of this specification can be combined with each other.

[0028] See Figure 1 The two-level hybrid parallel network simulation method provided in this invention is applied to a network simulation system comprising multiple physical nodes. The network simulation system includes multiple physical nodes, each corresponding to a simulation partition, and performs network simulation on platforms within that partition. These platforms refer to various moving vehicles participating in the simulation, such as aircraft, satellites, vehicles, and pedestrians; the network simulation refers to the simulation of network service processes such as data packet transmission and reception, routing and forwarding, and protocol parsing between platforms. In some examples, network protocols and data packet events between platforms are advanced in a discrete event manner, and the platform's motion state is updated according to a preset simulation step size.

[0029] It should be noted that, Figures 1 to 3 The “computing nodes” mentioned here all correspond to the physical nodes described in this article; Figures 1 to 3 The “communication simulation process” mentioned above corresponds to the network simulation process described in this article.

[0030] Each network simulation process performs network simulation on its corresponding platform. In some examples, platforms within the same simulation partition are divided according to their subnets. Each network simulation process loads the topology, communication devices, and protocol stack models of its corresponding subnet and undertakes the network simulation of the platforms within that subnet. A network simulation process can correspond to one subnet or more than two subnets. The correspondence between platforms and network simulation processes is determined during the initialization phase to explicitly distribute the target platform to a unique receiving process. In this way, each network simulation process is independent in model loading and event handling, enabling multiple network simulation processes to perform their respective network simulations in parallel within the same physical node.

[0031] In some examples, the correspondence between platforms and network simulation processes is determined during the simulation initialization phase along with subnetting: platforms within the same simulation partition are divided according to their respective subnets, and each network simulation process undertakes the network simulation of the platform within its corresponding subnet. This establishes a correspondence between platforms and network simulation processes within each physical node's simulation partition. This correspondence allows the network simulation process within the physical node to determine the receiving network simulation process when transmitting network events, and also allows the physical node to determine the receiving object within its own physical node when receiving network events from other physical nodes.

[0032] A cross-node message passing channel is established between the aforementioned multiple physical nodes. In some examples, the cross-node message passing channel is a communication channel based on a message passing interface protocol. During the simulation initialization phase, each physical node completes network formation and node registration through the message passing interface, and obtains its own partition identifier within the communication domain.

[0033] Discrete event network simulation processes simulation events sequentially, with causal order constraints existing between events. In simulation scenarios with numerous platforms and continuously changing platform locations, the simulation scale and speed during serial execution are limited by the processing capacity of a single executor. Therefore, the network simulation of all platforms is typically broken down into multiple parallel simulation tasks, each task undertaking the network simulation of a portion of the platforms. In this case, when a network event generated by one simulation task targets a platform undertaken by another simulation task, the network event needs to be passed to the simulation task undertaking that target platform.

[0034] In a parallel approach with only a single-level event transmission path, the event transmission path is independent of the destination platform. Taking the method of dividing simulation tasks across multiple physical nodes as an example, all network events are transmitted uniformly through the network channels between nodes. In this case, even if the destination platform of a network event and the simulation task that generated the event are both located on the same physical node, the network event still needs to go through three stages: serialization, kernel protocol stack processing, and network link transmission. The serialization stage converts the event object into a byte stream and restores it on the receiving side; the kernel protocol stack processing stage introduces context switching between user mode and kernel mode; and the network link transmission stage introduces link latency. These three stages represent additional overhead for event transmission that could otherwise be completed directly within a node. In scenarios where platform locations continuously change and interactions between platforms within a node are frequent, such events account for a high proportion of all events, resulting in significant accumulated latency and processing overhead.

[0035] In the parallel execution mode within a single computer, although the event propagation within a node does not go through the three steps mentioned above, the simulation scale is limited by the processor and memory resources of a single computer, making it difficult to scale horizontally with the increase in the number of platforms.

[0036] Therefore, the technical problem that needs to be solved is: how to reduce the latency and processing overhead of event transmission within a node while having the ability to expand to multiple physical nodes.

[0037] To solve the above technical problems, in some examples, such as Figure 4 As shown, the two-level hybrid parallel network simulation method provided in this embodiment of the invention includes the following specific steps: Step 500: Establish the mapping relationship between platform identifiers and partition identifiers; Step 502: When the first network simulation process in the first physical node among the above multiple physical nodes generates a network event targeting the target platform, determine the target simulation partition to which the target platform belongs based on the above mapping relationship. Step 504: If the target simulation partition is the simulation partition corresponding to the first physical node, the network event is transmitted through the shared memory of the first physical node to the second network simulation process that performs network simulation on the target platform within the first physical node. Step 506: If the target simulation partition is the simulation partition corresponding to the second physical node among the multiple physical nodes, the network event is transmitted to the second physical node through the cross-node message passing channel.

[0038] Establish a mapping relationship between platform identifiers and partition identifiers. The platform identifier is used to identify the platform in the network simulation system, and the partition identifier is used to identify the simulation partition. Since each physical node corresponds to a simulation partition, the above mapping relationship essentially indicates which physical node is responsible for network simulation for each platform.

[0039] When a network simulation process within the first physical node of the aforementioned plurality of physical nodes generates a network event targeting a specific platform, the target simulation partition to which the target platform belongs is determined according to the aforementioned mapping relationship. The aforementioned network events include, for example, packet transmission and reception events, route update events, and other simulation events targeting a specific platform.

[0040] When the target simulation partition is the simulation partition corresponding to the first physical node, the network events are transmitted via the shared memory of the first physical node to the second network simulation process within the first physical node that performs network simulation on the target platform. In some examples, the first network simulation process determines the second network simulation process within the first physical node that performs network simulation on the target platform based on the platform identifier of the target platform, according to the correspondence between the platform and the network simulation process, and transmits the network events to the second network simulation process. In the scenario of intra-node event transmission via shared memory described in this embodiment of the invention, the second network simulation process is a network simulation process within the first physical node that is different from the first network simulation process; that is, the target platform is network simulated by a network simulation process different from the network simulation process that generated the network events.

[0041] When the target simulation partition is the simulation partition corresponding to the second physical node among the multiple physical nodes, the network event is transmitted to the second physical node via the cross-node message passing channel.

[0042] The mechanism of the above scheme is as follows. The mapping relationship transforms the event attribute of "who is the destination platform" into the attribution determination of "which physical node is responsible for the destination platform," thus enabling the determination of whether an event needs to cross physical node boundaries at the moment of its occurrence. Since this determination occurs before the event enters any transmission stage, intra-node events and cross-node events are diverted to two independent transmission paths: the former is transmitted via the same shared memory segment mapped to the respective address spaces of the relevant network simulation processes, without needing to be serialized and deserialized according to the cross-node event message format, nor needing to be transmitted via the kernel network protocol stack and cross-node network links; the latter is transmitted via the cross-node message passing channel, bearing the necessary overhead of crossing physical nodes. In this way, intra-node events are no longer forced to bear the overhead of cross-node transmission due to the system's cross-node scalability, thereby enabling the system to reduce the latency and processing overhead of intra-node event transmission to the order of shared memory access while retaining the horizontal scalability of multiple physical nodes.

[0043] The above causal chain can be restated as follows: because events are diverted to two paths according to the partition affiliation of the destination platform when they are generated, events within a node can bypass serialization and kernel protocol stack steps, thereby reducing the latency and processing overhead of event transmission within a node without sacrificing cross-node scalability.

[0044] In some examples, the mapping relationship between the platform identifier and the partition identifier is a hash-mapped routing table. Determining the target simulation partition to which the target platform belongs based on this mapping relationship includes: querying the hash-mapped routing table using the platform identifier of the target platform to obtain the partition identifier of the target simulation partition. This hash-mapped routing table is established along with the partition boundary rules during the simulation initialization phase. When this mapping relationship is carried by a hash map, the query time does not increase with the number of platforms. Therefore, in simulation scenarios with a large number of platforms, the attribution determination itself will not become a new bottleneck in the event propagation path.

[0045] In some examples, attribution is determined by comparing the found partition identifier with the partition identifier of the local physical node: if they are the same, it is determined to be an intra-node event; if they are different, it is determined to be a cross-node event, and the physical node to which the event should be sent is determined by the found partition identifier.

[0046] In other examples, the above mapping relationship can also be carried by a lookup table, interval partitioning rules, or other corresponding relationships that can obtain the partition identifier from the platform identifier, as long as the partition affiliation of the destination platform can be determined when the event occurs.

[0047] See Figure 2In some examples, the above-mentioned transmission of the network event to the second network simulation process via the shared memory of the first physical node includes: writing the network event into a lock-free circular queue in the shared memory of the first physical node; and having the second network simulation process retrieve the network event from the lock-free circular queue.

[0048] In some examples, the shared memory of the first physical node is divided into a header area and an event data area: the header area stores queue metadata; the event data area contains the aforementioned lock-free circular queue. Each network simulation process accesses this shared memory segment through memory mapping to write and retrieve network events within the node. Motion state is not written to the shared memory but is handled by the Redis state cache service.

[0049] In some examples, the shared memory of the first physical node contains multiple lock-free circular queues, each corresponding one-to-one with a network simulation process within the first physical node. Writing the network events to the lock-free circular queues in the shared memory includes writing the network events to the lock-free circular queue corresponding to the second network simulation process. Since the second network simulation process is determined according to the correspondence between the platform and the network simulation process, the writer selects its corresponding lock-free circular queue accordingly. Thus, each network simulation process retrieves events from its corresponding lock-free circular queue, and the event streams of different receiving processes do not interfere with each other. Therefore, when multiple network simulation processes are running within the same physical node, the competition between the writer and the retriever is limited to a single queue. In other examples, a network simulation process may correspond to two or more lock-free circular queues, for example, by setting queues according to event type.

[0050] In some examples, the read and write pointers of the lock-free circular queue described above are maintained through atomic comparison and swap operations. The writer advances the write pointer atomically, and the retrieval process advances the read pointer atomically. This eliminates the need for mutex locks when multiple processes concurrently access the same queue, avoiding blocking and waiting caused by lock contention. In some examples, memory barriers are also used to prevent instruction reordering and maintain data visibility during access to the lock-free circular queue. This ensures that the writer's write to the queue is visible to the retrieval process before its advance of the write pointer, thus preventing the retrieval process from reading events that have not yet been completed.

[0051] In some examples, the aforementioned lockless circular queue is the lockless circular queue read by the aforementioned second network simulation process; after the writer determines the aforementioned second network simulation process according to the correspondence between the aforementioned platform and the network simulation process, it writes the aforementioned network events into the lockless circular queue read by the network simulation process.

[0052] In some examples, the shared memory segment is established through a shared memory creation interface and initialized according to the layout of the header area and event data area. Each process maps the shared memory segment to its own address space through a memory mapping interface, and the read / write pointers of the lock-free circular queue are initialized to zero. The capacity of the shared memory segment is, for example, 2GB, and the depth of a single lock-free circular queue is, for example, 10,000 events.

[0053] In the above manner, the process of an event being written by the producing process to being retrieved by the receiving process is completed through the same shared memory segment, without the need for transmission via the kernel network protocol stack and cross-node network links. Using the event latency transmitted via the above path as the criterion (the criterion being the time from when the producing process completes writing to when the receiving process completes retrieval), this latency is approximately 1 μs in the implementation environment described later.

[0054] See Figure 3 In some examples, the above-mentioned transmission of the network event to the second physical node via the cross-node messaging channel includes: encapsulating the network event into a cross-node event message, the cross-node event message including a source partition identifier, a destination partition identifier, a platform identifier of the destination platform, an event type, and a serialized event payload; and sending the cross-node event message to the second physical node via the cross-node messaging channel.

[0055] The functions of the above fields are as follows: the source partition identifier identifies the simulation partition that generated the event; the destination partition identifier indicates the simulation partition to which the event should be received; the platform identifier of the destination platform is used by the second physical node to further determine the receiving object of the event locally; the event type is used by the receiving side to select the corresponding processing logic; and the serialized event payload carries the specific content of the network event. Specifically, the cross-node event message instructs the second physical node to distribute the network event to the network simulation process within the second physical node that performs network simulation on the destination platform. After receiving the cross-node event message, the second physical node reconstructs the network event based on the serialized event payload, and determines the target network simulation process for performing network simulation on the destination platform based on the platform identifier of the destination platform and the correspondence between platforms and network simulation processes within this simulation partition. The reconstructed network event is then delivered to the target network simulation process. Since the destination partition has already been determined by the sending side, the second physical node does not need to perform partition attribution determination again. Therefore, the attribution determination of network events is divided into two levels: the first level determines the simulation partition to which the target platform belongs based on the above mapping relationship, and selects between intra-node transmission paths and cross-node transmission paths accordingly; the second level determines the network simulation process undertaking the network simulation of the target platform based on the above correspondence relationship, and determines the specific receiver within the physical node, so that cross-node events can still reach the specific network simulation process according to platform attribution after reaching the target physical node. The above two levels of attribution determination, partition-level and process-level, correspond to the parallelism between multiple physical nodes and the parallelism between multiple network simulation processes within the same physical node, respectively.

[0056] In some examples, network events arriving at the target network simulation process via the aforementioned shared memory or cross-node messaging channels participate in timing scheduling as local events of the corresponding simulation partition. Each physical node processes only network events whose timestamps are not greater than the aforementioned global security advance limits, according to the aforementioned global security advance limits.

[0057] In some examples, the aforementioned cross-node messaging channel is a communication channel based on a messaging interface protocol. The sending side calls the message sending interface to send the aforementioned cross-node event message, and the receiving side listens in real time using a non-blocking probe interface and calls the message receiving interface to obtain the message. Using the event latency transmitted via the aforementioned path as the criterion (with the same definition as above), this latency is approximately 10μs in the implementation environment described later. In other examples, the aforementioned cross-node messaging channel can also be carried by other communication protocols capable of transmitting messages between physical nodes.

[0058] See Figure 1 and Figure 2In some examples, each physical node also runs a motion simulation process. The network simulation system also includes a Redis state cache service accessible to multiple physical nodes, as well as a publish-subscribe channel for the motion simulation process and network simulation process within multiple physical nodes to access. Figure 2 and Figure 3 The Redis node shown is used to provide the aforementioned Redis state caching service. The motion simulation process uniformly completes the kinematic calculation, attitude update, and trajectory inference of the platform within the simulation partition corresponding to this physical node. The network simulation process does not participate in motion calculation and only undertakes network service simulation. Thus, the two types of services are decoupled at the process level.

[0059] In this case, the above method further includes: updating the six-degree-of-freedom motion state of the first platform within the simulation partition corresponding to the first physical node through the motion simulation process within the first physical node, and writing the updated motion state into the Redis state cache service; publishing a state availability notification to the network simulation process via a publish-subscribe channel, wherein the state availability notification includes the platform identifier of the first platform, the data version number of the updated motion state, and the simulation time range in which the data is available, but does not carry the updated motion state; and, upon receiving the state availability notification, reading the motion state of the first platform from the Redis state cache service according to the state availability notification.

[0060] In some examples, the aforementioned six-degree-of-freedom motion states include position, attitude, velocity, angular velocity, acceleration, and angular acceleration, and are written to the Redis state cache service indexed by the platform identifier and simulation time. The publish-subscribe channel is the data distribution service (DDS) channel, with the motion simulation process acting as the publisher and the network simulation process as the subscriber. Notifications are used to indicate the available state versions and their corresponding simulation time ranges, but do not carry the actual motion state data.

[0061] The data version number is associated with the motion state written to the Redis state cache service. The simulation time range available for this data is used to characterize the simulation time range within which the motion state of the corresponding data version can be invoked by the network simulation process.

[0062] The mechanism behind this scheme is as follows: Six-DOF motion state data is substantial, and the network simulation process may need to read platform states from other simulation partitions. Writing the actual data to a Redis state cache service accessible to multiple physical nodes allows each network simulation process to read the data as needed, based on platform identifier and simulation time, avoiding the serialization and redundant distribution overhead introduced by transmitting large volumes of state data via DDS. Actively delivering the availability of the state and its time range via DDS in the form of notifications avoids the network simulation process repeatedly polling the Redis state cache service to detect state updates. In this way, the motion state is uniformly calculated by the motion simulation process, and the Redis state cache service caches the data across partitions for reuse by the network simulation process, balancing cross-partition accessibility and communication overhead.

[0063] In some examples, the process of reading the motion state of the first platform from the Redis state cache service based on the status availability notification includes: the network simulation process receiving the status availability notification compares the data version number in the status availability notification with the data version number of the first platform's motion state in the network simulation process's local cache, and determines whether the timestamp of the current pending network event falls within the data availability simulation time range indicated by the status availability notification; if the data version number in the status availability notification is later than the data version number in the local cache, and the timestamp of the current pending network event falls within the data availability simulation time range, the process reads the motion state corresponding to the platform identifier of the first platform, the timestamp of the current pending network event, and the data version number in the status availability notification from the Redis state cache service, updates the local cache with the actually read motion state, and updates the data version number of the first platform's motion state in the local cache according to the data version number of the actually read motion state. By jointly determining the version number and the simulation time range, duplicate readings of the same version of motion state can be avoided, as well as reading data that is not yet available for the current simulation time.

[0064] In some examples, the motion state read by the network simulation process is used to calculate communication parameters, such as path loss and Doppler shift. In other examples, the motion simulation process updates the motion state and issues state change notifications at preset simulation steps (e.g., 10 ms).

[0065] See Figure 3In some examples, each physical node also maintains the subnet topology, local event queue, and local logical clock for its corresponding simulation partition. To satisfy the causal order constraints of cross-simulation partition network events, each physical node employs a conservative discrete event simulation mechanism to advance local events: During the simulation initialization phase, a look-ahead quantity is determined based on the minimum propagation delay of cross-simulation partition network events over simulation time; each physical node determines the upper bound of the time window to which its simulation partition can be safely advanced based on the current simulation time of its simulation partition and the look-ahead quantity, and publishes the upper bound of the time window through the cross-node message passing channel according to a preset time window; the minimum value among the upper bounds of the time windows published by each simulation partition is determined as the global safe advancement limit. Each physical node only processes events whose timestamps are not greater than the global safe advancement limit, thereby maintaining the temporal consistency of cross-simulation partition network events without event rollback. Figure 4 The “safe time / clock synchronization” shown refers to the process by which each simulation partition publishes the upper bound of the time window and determines the global safe advance limit based on the upper bound of each time window.

[0066] In one specific embodiment, a distributed simulation cluster consisting of three physical servers is built. Each node has the same configuration: a 24-core processor, 64GB of memory, and interconnection via 10 Gigabit Ethernet. It runs a Linux operating system, a message passing interface runtime library, a shared memory development library, a Redis state caching service, and a DDS component. Each server serves as an independent simulation partition, with one motion simulation process and eight network simulation processes deployed per node. Key configurations include: 2GB of shared memory, a lock-free circular queue depth of 10000, a simulation step size of 10ms, data retention time for the Redis state caching service covering at least one preset time window, a DDS notification period consistent with the simulation step size, and a cross-node message timeout of 100ms.

[0067] During the simulation, each physical node completes the motion calculation and network simulation of the platform within its simulation partition in the aforementioned manner: intra-node network events are transmitted via a lock-free circular queue in shared memory, cross-partition network events are forwarded via a cross-node message passing channel, and the six-degree-of-freedom motion state is written to the Redis state cache service and notified by DDS of the available version and simulation time range; each physical node processes local events within the global safe advance limit according to the conservative discrete event time window mechanism.

[0068] Using a satellite constellation scenario comprising 288 low-Earth orbit satellites divided into 6 regional logical subnets, tests were conducted based on the aforementioned 3-node cluster, yielding the following results.

[0069] Firstly, the event transmission latency within a node. Compared to the method of transmitting all events uniformly through the inter-node network channel, the event transmission latency within the local subnet is reduced from approximately 10μs to approximately 1μs, improving network event processing efficiency by 40%.

[0070] Secondly, simulation capacity. Using the number of platforms simulating simultaneously as the criterion, the capacity was increased from 96 to 288 through a 3-node distributed deployment, a 3-fold increase.

[0071] Third, the synchronization failure rate. The number of synchronization failures per simulation hour was used as the criterion, and the rate was reduced from 5 to below 0.2.

[0072] Fourth, processor load balancing. The deviation between the processor utilization rates of each physical node is used as the criterion, and this deviation should be less than 5%.

[0073] The results show that while retaining the horizontal scaling capability of multiple physical nodes, the latency and processing overhead of event transmission within nodes are significantly reduced.

[0074] In other examples, the platform simulated by the above network simulation system is not limited to satellites, but can also be various moving carriers such as airplanes, vehicles, and pedestrians, or combinations of the above carriers.

[0075] In other examples, the number of network simulation processes within a physical node can be configured based on the number of processor cores on that physical node.

[0076] In other examples, the correspondence between simulation partitions and physical nodes can be adjusted according to the cluster size; each simulation partition can be divided according to the number of platforms, network service load, or subnet topology correlation, so that the simulation load borne by each physical node tends to be balanced.

[0077] In summary, the two-level hybrid parallel network simulation method provided in the embodiments of this specification can achieve the following technical effects: By establishing a mapping relationship between platform identifiers and partition identifiers, and determining the target simulation partition to which the destination platform belongs based on this mapping relationship when a network event occurs, the network event completes its attribution determination before entering any transmission stage. Then, based on the determination result, it is split into two independent transmission paths: when the simulation partition to which the destination platform belongs is the simulation partition corresponding to this physical node, the network event is transmitted through the same shared memory segment mapped to the address spaces of the relevant network simulation processes, without undergoing serialization, kernel protocol stack processing, and network link transmission; when the simulation partition to which the destination platform belongs belongs is the simulation partition corresponding to another physical node, the network event is transmitted through a cross-node message passing channel, bearing the overhead necessary for crossing physical nodes. Thus, intra-node events are not forced to bear the overhead introduced by cross-node transmission due to the simulation system's cross-node scalability, thereby reducing the latency and processing overhead of intra-node event transmission while retaining the horizontal scalability of multiple physical nodes. In one specific embodiment, the intra-node event transmission latency is reduced from approximately 10μs to approximately 1μs, and the network event processing efficiency is improved by 40%; simultaneously, through the distributed deployment of 3 physical nodes, the simulation support scale is increased from 96 platforms to 288 platforms.

[0078] Furthermore, each network simulation process performs network simulation on its corresponding platform. The network simulation processes are independent of each other in terms of model loading and event handling, enabling multiple network simulation processes to advance their respective network simulations in parallel within the same physical node. Moreover, after cross-node events reach the destination physical node, they can still reach the specific network simulation process according to the platform affiliation. The two-level routing remains consistent between and within nodes.

[0079] Furthermore, when the hash mapping routing table carries the mapping relationship between platform identifiers and partition identifiers, the query time does not increase with the increase in the number of platforms. Therefore, in simulation scenarios with a large number of platforms, the attribution determination itself will not become a new bottleneck on the event transmission path.

[0080] Furthermore, events within a node are written to and retrieved via a lock-free circular queue in shared memory. The process of events being written from the producing process to the receiving process is completed within the same shared memory segment, without needing to be transmitted through the kernel network protocol stack and cross-node network links. This reduces the latency of event transmission within a node to the order of magnitude of shared memory access.

[0081] Furthermore, when multiple lock-free circular queues set in shared memory correspond one-to-one with multiple network simulation processes within the same physical node, each network simulation process retrieves events from its corresponding queue. The event streams of different receiving processes do not interfere with each other, and the competition between the writer and the retriever is limited to a single queue. Thus, when multiple network simulation processes are running within the same physical node, low concurrency overhead can still be maintained.

[0082] Furthermore, when the cross-node event message carries the platform identifier of the destination platform, the physical node receiving the message does not need to query the mapping relationship again and can complete the distribution to the specific network simulation process locally, reducing the processing steps of cross-node events on the receiving side.

[0083] Furthermore, the actual data of the six-DOF motion state is written to the Redis state cache service. The availability of the state and its simulation time range are delivered via DDS in the form of notifications, so that the large amount of motion state data is not transmitted through DDS, avoiding the corresponding serialization overhead. At the same time, the network simulation process does not need to repeatedly poll the Redis state cache service to detect state updates, avoiding processor idle time. The Redis state cache service can be accessed by multiple physical nodes, and the motion state is uniformly calculated by the motion simulation process and shared and reused across partitions by the network simulation process.

[0084] Furthermore, each network simulation process compares the data version number in the DDS status availability notification with the version number in the local cache, and combines it with the data availability simulation time range in the notification. Only when the data has been updated and the pending event falls within the time range will the motion status be read from the Redis status cache service, so that the reading action matches the actual needs and further reduces unnecessary cache access.

[0085] Furthermore, each physical node determines the upper bound of the time window to which it can safely advance based on the current simulation time and look-ahead of its simulation partition, and determines the minimum value among the upper bounds of the time windows of each simulation partition as the global safe advance limit. This allows each physical node to process only events whose timestamps are not greater than the global safe advance limit, thereby maintaining the temporal consistency of network events across simulation partitions without event rollback.

[0086] The foregoing description and accompanying drawings fully illustrate embodiments of this specification to enable those skilled in the art to practice them. Other embodiments may include structural and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included or substituted for parts and features of other embodiments. The embodiments of this specification are not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from their scope. The scope of this specification is limited only by the appended claims.

Claims

1. A two-level hybrid parallel network simulation method, characterized in that, The method is applied to a network simulation system comprising multiple physical nodes. Each physical node corresponds to a simulation partition and performs network simulation on the platform within the corresponding simulation partition. Each physical node runs multiple network simulation processes and is provided with shared memory accessible to the multiple network simulation processes. Each network simulation process performs network simulation on its corresponding platform. A cross-node message passing channel is provided between the multiple physical nodes. The method includes: Establish a mapping relationship between platform identifiers and partition identifiers; When a network simulation process within a first physical node of the plurality of physical nodes generates a network event targeting a target platform, the target simulation partition to which the target platform belongs is determined according to the mapping relationship. When the target simulation partition is the simulation partition corresponding to the first physical node, the network event is transmitted through the shared memory of the first physical node to the second network simulation process within the first physical node that performs network simulation on the target platform. When the target simulation partition is the simulation partition corresponding to the second physical node among the plurality of physical nodes, the network event is transmitted to the second physical node via the cross-node message passing channel.

2. The method according to claim 1, characterized in that, The mapping relationship between the platform identifier and the partition identifier is a hash mapping routing table; Determining the target simulation partition to which the target platform belongs based on the mapping relationship includes: The target simulation partition's partition identifier is obtained by querying the hash mapping routing table using the platform identifier of the target platform.

3. The method according to claim 1, characterized in that, The second network simulation process, which transmits the network events through the shared memory of the first physical node to perform network simulation on the target platform within the first physical node, includes: Write the network events into a lock-free circular queue in the shared memory of the first physical node; The network event is retrieved from the lock-free circular queue by the second network simulation process.

4. The method according to claim 3, characterized in that, The shared memory of the first physical node contains multiple lock-free circular queues, and each of the multiple lock-free circular queues corresponds one-to-one with a multiple network simulation process within the first physical node; The step of writing the network event into a lock-free circular queue in the shared memory of the first physical node includes: The network events are written to the lockless circular queue corresponding to the second network simulation process.

5. The method according to claim 1, characterized in that, The step of transmitting the network event to the second physical node via the cross-node messaging channel includes: The network event is encapsulated into a cross-node event message, which includes a source partition identifier, a destination partition identifier, a platform identifier of the destination platform, an event type, and a serialized event payload. The cross-node event message is sent to the second physical node via the cross-node message passing channel; The cross-node event message is used to instruct the second physical node to distribute the network event to the network simulation process within the second physical node that performs network simulation on the target platform.

6. The method according to claim 1, characterized in that, The cross-node message passing channel is a communication channel based on a message passing interface protocol.

7. The method according to claim 1, characterized in that, Each physical node also runs a motion simulation process. The network simulation system also includes a Redis state cache service accessible to multiple physical nodes, and a publish-subscribe channel for the motion simulation process and network simulation process within multiple physical nodes to access. The method further includes: The motion simulation process within the first physical node updates the six-degree-of-freedom motion state of the first platform within the simulation partition corresponding to the first physical node, and writes the updated motion state into the Redis state cache service. The status availability notification is published to the network simulation process through the publish-subscribe channel. The status availability notification includes the platform identifier of the first platform, the data version number of the updated motion status, and the simulation time range in which the data is available, but does not carry the updated motion status. Upon receiving the status availability notification, the network simulation process reads the motion status of the first platform from the Redis status cache service based on the status availability notification.

8. The method according to claim 7, characterized in that, The step of reading the motion status of the first platform from the Redis state cache service based on the status availability notification includes: The network simulation process that receives the status availability notification compares the data version number in the status availability notification with the data version number of the motion status of the first platform in the local cache of the network simulation process, and determines whether the timestamp of the network event to be processed falls within the simulation time range of the data availability. If the data version number in the status availability notification is later than the data version number in the local cache, and the timestamp of the current pending network event falls within the simulation time range of the data availability, the motion status corresponding to the platform identifier of the first platform, the timestamp of the current pending network event, and the data version number in the status availability notification is read from the Redis status cache service. The actually read motion status is updated to the local cache, and the data version number of the motion status of the first platform in the local cache is updated according to the data version number of the actually read motion status.

9. The method according to claim 1, characterized in that, Also includes: Each physical node employs a conservative discrete event simulation mechanism to advance local events.

10. The method according to claim 9, characterized in that, The local events are advanced by a conservative discrete event simulation mechanism for each of the physical nodes, including: The look-ahead quantity is determined based on the minimum propagation delay of cross-simulation partition network events over simulation time. Each physical node determines the upper bound of the time window to which the simulation partition can be safely advanced based on the current simulation time of the simulation partition and the look-ahead quantity, and publishes the upper bound of the time window according to the preset time window. The minimum value among the upper bounds of the time windows published by each simulation partition is determined as the global safety advancement limit; Only events with timestamps no greater than the global security advance limit are processed.

Images