An underwater acoustic network physical layer simulation method, system and medium of a network simulator

Abstract

This application relates to a method, system, and medium for simulating the physical layer of an underwater acoustic network in a network simulator. It includes: a mirror event scheduler monitoring transmission events at the physical layer; when any node triggers a transmission event, the mirror event scheduler adds the transmission event to a preset micro-batch buffer for buffering; when preset conditions are met, the mirror event scheduler performs micro-batch aggregation processing on all current transmission events in the micro-batch buffer; the mirror event scheduler generates a transmission signal based on the micro-batch aggregation result; the mirror event scheduler generates an uplink parameter file based on the transmission signal and sends it to the channel simulation end; the channel simulation end determines the target channel impulse response; the channel simulation end generates a downlink parameter file based on the target channel impulse response and the transmission signal and returns it to the network simulation end; the mirror event scheduler in the network simulation end processes the corresponding reception events based on the downlink parameter file. This application can avoid the interference underestimation and collision misjudgment caused by traditional packet-by-packet processing.

Description

Technical Field

[0001] This application relates to the field of underwater acoustic communication network simulation technology, and in particular to a method, system and medium for simulating the physical layer of an underwater acoustic network in a network simulator. Background Technology

[0002] Performance evaluation of underwater acoustic network protocol stacks (including MAC, routing, and transport layers) typically relies on discrete-event network simulators (such as AquaSim or ns-3). However, the physical layer models built into these simulators often employ statistical or highly simplified abstractions (such as fixed bit error rate and ideal acquisition models), making it difficult to accurately characterize the key physical characteristics of underwater acoustic channels, including multipath delay spread, frequency-selective attenuation and dispersion effects, concurrent signal interference and collisions, strong and weak signal acquisition effects, and reception uncertainties caused by synchronization failures or demodulation errors.

[0003] The existing approach is to directly couple physical layer modules (such as channel impulse response calculation, waveform-level modulation and demodulation, and common channel pool that supports multiple signal superposition) into the network simulation process packet by packet. For example, a common practice is to "call the external physical layer separately for each transmission event".

[0004] However, this approach makes it difficult to uniformly model concurrent transmission events within the same time window, which can easily lead to problems such as incorrect collision judgment, underestimation of multi-user interference, and mismatch of receiving timestamps, thereby undermining the causal consistency and statistical reliability of discrete event simulation. Summary of the Invention

[0005] This application provides a method, system, and medium for simulating the physical layer of an underwater acoustic network in a network simulator. It aims to solve the problem in traditional underwater acoustic network simulation where the "packet-by-packet calling of the external high-fidelity physical layer" makes it impossible to jointly model concurrently transmitted signals within the same time window, thereby compromising the causal consistency and statistical reliability of discrete event simulation.

[0006] In a first aspect, embodiments of this application provide a method for simulating the physical layer of an underwater acoustic network using a network simulator. The underwater acoustic network physical layer simulation system includes a network simulation terminal and a channel simulation terminal. The network simulation terminal is equipped with a mirror event scheduler. The method includes: During the process of driving discrete events in the network simulation terminal, the mirror event scheduler listens for events sent from the physical layer. When any node triggers the sending event, the mirror event scheduler adds the sending event to a preset micro-batch buffer for buffering; When preset conditions are met, the mirror event scheduler performs micro-batch aggregation processing on all currently sent events in the micro-batch buffer to obtain the micro-batch aggregation result; The mirror event scheduler generates a transmission signal based on the micro-batch aggregation result; The mirror event scheduler generates an uplink parameter file based on the transmitted signal and sends it to the channel simulation terminal. The channel simulation terminal determines the target channel impulse response based on the uplink parameter file and the slow variable of underwater acoustic propagation. The channel simulation terminal generates a downlink parameter file based on the target channel impulse response and the transmitted signal, and returns it to the network simulation terminal. The mirror event scheduler in the network simulation terminal parses the downlink parameter file and processes the corresponding receive events based on the downlink parameter file in the network simulation terminal.

[0007] A further technical solution is that the network physical layer simulation system also includes a platform interconnection layer, which adopts a bidirectional parameter file communication protocol, and the protocol defines at least two types of structured messages; The two types of structured messages include the original event parameter file and the physical layer received event parameter file; Both the original event parameter file and the physical layer received event parameter file contain multiple target fields, including micro-batch identifier, window start simulation time, micro-batch time window length, environment version number, geometry version number, and packet unique identifier.

[0008] A further technical solution is that, before exporting the sending event to the channel simulation end, the mirror event scheduler assigns a globally unique packet unique identifier to each data packet to be sent, and maintains a processing mapping table locally on the network simulation end. The processing mapping table records the mapping relationship between the packet unique identifier and the corresponding data packet's internal packet object handle in the network simulation end. When generating the physical layer receive event parameter file, the channel simulation terminal uses only the packet unique identifier to identify the data packet. When the mirror event scheduler receives the physical layer receive event parameter file, it queries the pending mapping table based on the packet unique identifier contained therein, restores the corresponding internal packet object handle, and calls the native physical layer receive event injection interface in the network simulation terminal to submit the restored internal packet object to the upper layer protocol for processing in a manner that conforms to the semantics of the native protocol stack.

[0009] A further technical solution is that the slow variables of underwater acoustic propagation include node geometry information and underwater acoustic environment information. The channel simulation terminal determines the target channel impulse response based on the uplink parameter file and the slow variables of underwater acoustic propagation, including: After receiving the uplink parameter file, the channel simulation terminal parses the uplink parameter file and extracts the node positions. Determine whether the changes in the node geometry information and the underwater acoustic environment information exceed a preset threshold. If the change in the node geometry information or the underwater acoustic environment information exceeds a preset threshold, the current channel impulse response is recalculated based on the node position and external input data, and the current channel impulse response is used as the target channel impulse response. If the changes in the node geometry information and the underwater acoustic environment information do not exceed a preset threshold, the cached channel impulse response will be used as the target channel impulse response.

[0010] A further technical solution is that the external input data includes hydrological data, seabed topography parameters, sediment parameters, and coastline parameters; the node location includes spatial information of the receiving node and spatial information of the transmitting node; and the current channel impulse response is recalculated based on the node location and the external input data. Temperature, salinity, and pressure are read from the hydrological data; The preset ocean thermohaline equation of state library is used to convert temperature, salinity, and pressure into depth-sound velocity profiles; The OSM interface is used to read the coastline parameters based on the BBox, and a planar map is drawn. The seabed topography parameters and sediment parameters are clipped using BBox to generate a seabed topography mesh, and the depth map and seabed file are output. Based on the depth-velocity profile, the planar map, the depth map, the spatial information of the receiving node, the spatial information of the transmitting node, the frequency information, and the preset control parameters, a main configuration file is generated; Input the seabed file and the main configuration file into the acoustic propagation solver; The sound propagation solver is invoked to calculate the multipath propagation characteristics from the transmitting node to the receiving node, and the arrival structure is obtained. The arrival structure is converted into a set of CIR taps to obtain the current channel impulse response.

[0011] A further technical solution is that the channel simulation terminal is equipped with a modulation and demodulation module and a common channel pool. Based on the target channel impulse response and the transmitted signal, the channel simulation terminal generates a downlink parameter file and returns it to the network simulation terminal, including: The channel simulation terminal establishes a window-level receiving port for each receiving node, and inputs the transmitted signals of all transmitting sources within the current micro-batch window into the modulation and demodulation module to add environmental noise processing to obtain the processed transmitted signal; The processed transmit signal is input into the common channel pool of the channel simulation terminal; The common channel pool processes the target channel impulse response and the processed transmitted signal to obtain the received signal set of each node; The common channel pool returns the output signal sets received by each node to the modulation and demodulation module; The modulation and demodulation module detects the received signal sets of each node and generates a set of received events; The channel simulation terminal generates a downlink parameter file based on the received event set and returns it to the network simulation terminal through the platform interconnection layer.

[0012] A further technical solution involves processing the corresponding received events in the network simulation terminal, including: Read the receive event set from the downlink parameter file; The received event set is mapped to event types consistent with the semantics of the physical layer's native events, which include successful reception, failed reception, and packet loss. For a reception event marked as successful reception, a native send event is injected into the discrete event scheduler at the corresponding reception completion time, carrying the internal packet object recovered from the packet's unique identifier; For reception events marked as reception failures, the existing implementation mechanism can be used to either inject the reception failure event or simply update the packet loss statistics. After all received events have been injected, the pause state of the discrete event network simulator is lifted, and control is returned to the native event scheduler to allow it to continue to advance subsequent simulation events.

[0013] A further technical solution is that the uplink parameter file includes the original event parameter file, modulation and demodulation and environment parameters, network data packet parameters, and transmission event timestamps; The downlink parameter file includes a physical layer receive event parameter file, pre-demodulation results, channel parameters, and receive event timestamps.

[0014] Secondly, this application also provides an underwater acoustic network physical layer simulation system for a network simulator. The underwater acoustic network physical layer simulation system includes a network simulation terminal, a channel simulation terminal, and a platform interconnection layer. The network simulation terminal is equipped with a mirror event scheduler. The mirror event scheduler is used to monitor physical layer transmission events during the process of driving discrete events at the network simulation terminal; when any node triggers the transmission event, the transmission event is added to a preset micro-batch buffer for buffering; when preset conditions are met, all current transmission events in the micro-batch buffer are subjected to micro-batch aggregation processing to obtain a micro-batch aggregation result; a transmission signal is generated based on the micro-batch aggregation result, and an uplink parameter file is generated based on the transmission signal, and sent to the channel simulation terminal through the platform interconnection layer; The channel simulation terminal is used to receive the uplink parameter file of the platform interconnection layer, determine the target channel impulse response based on the uplink parameter file and the slow variable of underwater acoustic propagation, and generate a downlink parameter file based on the target channel impulse response and the transmitted signal, and return it to the network simulation terminal through the platform interconnection layer. The mirror event scheduler in the network simulation terminal is also used to parse the downlink parameter file and inject or delete corresponding reception events in the network simulation terminal based on the reception completion time and reception success flag of the downlink parameter file. The channel simulation terminal sends back the physical layer reception result in the form of "reception event parameters", which are consumed by the network simulation terminal through the native reception entry.

[0015] Thirdly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0016] This application provides a method, system, and medium for simulating the physical layer of an underwater acoustic network in a network simulator. The method includes: during the process of driving discrete events at the network simulator, a mirror event scheduler monitors transmission events at the physical layer; when any node triggers a transmission event, the mirror event scheduler adds the transmission event to a preset micro-batch buffer for buffering; when preset conditions are met, the mirror event scheduler performs micro-batch aggregation processing on all current transmission events in the micro-batch buffer to obtain a micro-batch aggregation result; the mirror event scheduler generates a transmission signal based on the micro-batch aggregation result; the mirror event scheduler generates an uplink parameter file based on the transmission signal and sends it to the channel simulator; the channel simulator determines the target channel impulse response based on the uplink parameter file and the slow variable of underwater acoustic propagation; the channel simulator generates a downlink parameter file based on the target channel impulse response and the transmission signal and returns it to the network simulator; the mirror event scheduler in the network simulator parses the downlink parameter file and processes corresponding reception events in the network simulator based on the downlink parameter file.

[0017] The underwater acoustic network physical layer simulation method provided in this application introduces a mirror event scheduler at the network simulation end. The mirror event scheduler intercepts physical layer transmission events and adds them to a preset micro-batch buffer for buffering. When preset conditions are met, the mirror event scheduler performs micro-batch aggregation processing on all current transmission events within the same micro-batch time window in the micro-batch buffer and exports an uplink parameter file, which is then uniformly submitted to the channel simulation end. This allows the channel simulation end to process based on a complete set of transmitted signals. In this way, interference underestimation and collision misjudgment caused by traditional packet-by-packet processing can be avoided. Furthermore, by batch processing transmission events, the frequency of interaction with the channel simulation end can be reduced, avoiding the inter-process / language communication overhead caused by "one call per packet".

[0018] In addition, after the channel simulation end returns the downlink parameter file with timing information, the mirror event scheduler can process the corresponding receive events, which allows the upper-layer protocol stack to still operate according to the native semantics. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0022] Figure 1 The structural block diagram of the collaborative simulation system provided in this application; Figure 2 A flowchart illustrating the first embodiment of the underwater acoustic network physical layer simulation method for a network simulator provided in this application; Figure 3 A flowchart of the mirror event scheduler provided in this application; Figure 4 A flowchart of the CIR calculation module provided in this application; Figure 5 A flowchart illustrating the modulation and demodulation implementation of the CIR buffer and common channel pool provided in this application; Figure 6A schematic diagram of network performance evaluation provided for this application; Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0025] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0026] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0027] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0028] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0029] To address the aforementioned issues, this application provides a simulation method for the physical layer of underwater acoustic networks in a network simulator, which avoids the underestimation of interference and misjudgment of collisions caused by traditional packet-by-packet processing.

[0030] First, let's introduce some of the technical terms used in this application: 1. AquaSim: Underwater acoustic network simulator (an underwater acoustic network simulation framework based on discrete event mechanisms, often built on top of the network simulator ns-3).

[0031] 2. ns-3: NetworkSimulator3 (Discrete Event Network Simulation Platform).

[0032] 3. Discrete-Event Simulation (DES): Discrete-Event Simulation is a simulation method that uses event queues and event timestamps to advance the simulation clock.

[0033] 4. MATLAB: Matrix Laboratory (Matlab, a platform for numerical computation, signal processing, and engineering modeling).

[0034] 5. Co-simulation: Co-simulation (which involves exchanging information and jointly advancing different simulators / computing modules under a unified temporal semantics).

[0035] 6. Event Barrier: An event barrier is a pause / synchronization point set during the discrete event simulation process to collect events within a certain time window and wait for external solution results before continuing.

[0036] 7. Micro-batch: Micro-batch is a mechanism that aggregates and processes multiple concurrent events within a preset very short time window, used for unified modeling of concurrent interference and collision determination.

[0037] 8. Mirror Scheduler: Mirror Scheduler / Barrier Controller (a control logic module on the network simulator side used to implement event barriers, micro-batch aggregation, result backfilling, and event injection).

[0038] 9. JSON: JavaScript Object Notation (a lightweight structured data exchange format, used in this embodiment for cross-process data interaction; it can also be equivalently replaced by sockets, shared memory, etc.).

[0039] 10. BBox: Geographic Bounding Box (a rectangular geographic area defined by minimum / maximum latitude and longitude, used for data cropping and coastline / topography / sediment extraction).

[0040] 11. CIR: Channel Impulse Response (used to characterize the time delay and amplitude-phase structure of multipath propagation in underwater acoustic channels, and can be represented as a set of taps or a discrete filter).

[0041] 12. PDP: Power Delay Profile (a statistical representation of the distribution of multipath power in a channel over time).

[0042] 13. TDL: Tapped Delay Line (a model of a multipath channel represented by multiple discrete taps).

[0043] 14. SSP: Sound Speed ​​Profile (depth-sound speed curve).

[0044] 15. Bellhop / Bellhop3D: Bellhop Sound Tracing Propagation Model (Bellhop is a tool for calculating underwater acoustic propagation based on sound ray tracing; Bellhop3D is a three-dimensional propagation calculation method).

[0045] 16. env file: Environment configuration file (one of the Bellhop input files, used to describe environmental parameters such as sound velocity profile, boundary conditions, frequency, sound source / receiver).

[0046] 17. bty file: Bathymetryfile (one of the Bellhop input files, used to describe the seabed topography grid / profile).

[0047] 18. GEBCO: General Bathymetric Chart of the Oceans (providing seabed elevation / depth raster data).

[0048] 19. DBOIT: Seabed Sediment Database (used to provide sediment category / attribute data for target sea areas, used for mapping seabed acoustic parameters).

[0049] 20. OSM: OpenStreetMap (an open geographic data platform; in this embodiment, it is used to obtain the vector boundary of the coastline).

[0050] 21. Overpass Interface: OSM query interface (an interface format used to retrieve OSM geographic feature data based on conditions such as BBox).

[0051] 22. GSW Repository: Gibbs SeaWater (a database for calculating ocean thermal and salinity equations of state, used to derive ocean physical quantities such as sound velocity from temperature / salinity / pressure).

[0052] This application provides an underwater acoustic network physical layer simulation system for a network simulator, which includes a network simulation terminal and a channel simulation terminal.

[0053] The network simulation client (AquaSim / ns-3) includes an event scheduler, a mirror event scheduler, and a simulation log module.

[0054] The event scheduler is responsible for advancing ns-3 discrete events and managing event queues.

[0055] The mirror event scheduler is primarily used to set barriers at specified times, pausing or suspending physical layer-related processes; after obtaining external solution results, it removes the barriers and injects subsequent events. It intercepts transmit events at the physical layer transmission entry point, adding them to the current micro-batch buffer; and triggers micro-batch commit (FlushBatch) when the window ends. It is responsible for atomic writing of JSON files, polling reads, timeout handling, and error code logging (including ready / ok / done states). Based on the reception results returned by MATLAB (success / failure, reception completion time), it calls the native PHY's reception success callback or failure callback (or only counts packet loss), ensuring that the upper-layer protocol stack is unaware of this.

[0056] The simulation log module is used to output logs such as batch, latency, throughput, packet loss, and SINR for visualization and experimental reproduction.

[0057] The channel simulation module (MATLAB) includes a CIR calculation module, a CIR buffer management module, a common channel pool module, a modulation and demodulation module, and a result encapsulation and write-back module.

[0058] The CIR calculation module is used to calculate the link CIR (which can be in tap parameter form or discrete FIR form) based on node geometry and environmental parameters.

[0059] The CIR cache management module (geo_version) is used to cache CIRs in geo_version version and provide fast access by index (sender node, receiver node).

[0060] The common channel pool module is used to time-align and superimpose signals from multiple transmitters at each receiver within a micro-batch window, forming an equivalent input at the receiver.

[0061] The modulation and demodulation module is used to generate the transmit baseband waveform (or use a predefined modulation configuration), and perform synchronization, matched filtering, demodulation decoding and CRC check (or use index-level decision).

[0062] The result encapsulation and write-back module is used to encapsulate the judgment result of each receiver for each packet into a JSON response and write it back to the response directory.

[0063] For example, the network simulation client interacts with the channel simulation client through two types of interfaces: "geometric update request / response" and "micro-batch send request / receive result response"; the channel simulation client decouples slow variables from fast variables using geo_version; the network simulation client injects events after waiting for results at the barrier point and continues to advance.

[0064] Among them, the channel simulation terminal (MATLAB) can realize waveform level (generating baseband waveforms, convolution superposition, synchronization detection, demodulation decoding and CRC decision) or index level (calculating SINR based on propagation loss, noise and interference, and then mapping it to packet error rate / success failure).

[0065] In some embodiments, the underwater acoustic network physical layer simulation system further includes a platform interconnection layer, which uses structured parameter files (e.g., JSON) as a cross-platform exchange carrier and defines at least two types of file sets (including uplink parameter files and downlink parameter files).

[0066] Specifically, the mirror event scheduler is used to monitor physical layer transmission events during the process of driving discrete events at the network simulation terminal; when any node triggers the transmission event, the transmission event is added to a preset micro-batch buffer for buffering; when preset conditions are met, all current transmission events in the micro-batch buffer are subjected to micro-batch aggregation processing to obtain a micro-batch aggregation result; a transmission signal is generated based on the micro-batch aggregation result, and an uplink parameter file is generated based on the transmission signal, and sent to the channel simulation terminal through the platform interconnection layer; The channel simulation terminal is used to receive the uplink parameter file of the platform interconnection layer, determine the target channel impulse response based on the uplink parameter file and the slow variable of underwater acoustic propagation, and generate a downlink parameter file based on the target channel impulse response and the transmitted signal, and return it to the network simulation terminal through the platform interconnection layer. The mirror event scheduler in the network simulation terminal is also used to parse the downlink parameter file and inject or delete corresponding reception events in the network simulation terminal based on the reception completion time and reception success flag of the downlink parameter file. The channel simulation terminal sends back the physical layer reception result in the form of "reception event parameters", which are consumed by the network simulation terminal through the native reception entry.

[0067] In some embodiments, the data exchange medium may be: a file (JSON), a socket (TCP / UDP), shared memory, named pipes, etc. This embodiment uses a JSON file as an example; other media are equivalent substitutes.

[0068] The interaction between the network simulation terminal, the channel simulation terminal, the platform interconnection layer, and the mirror event scheduler can be found in [reference needed]. Figure 1 ,like Figure 1 As shown, the left side represents the network simulation end. The application layer, network layer, data link layer, and physical layer of AquaSim-NG run under the drive of the ns-3 native event scheduler. To achieve high-fidelity external physical layer injection, the system introduces a "MirrorScheduler" in the scheduling layer. This monitors whether the platform interconnect layer generates new parameter files and performs thread blocking / resumption control on event progression when key events such as physical layer transmit / recv are detected, ensuring that concurrent transmissions are processed consistently within a unified time window. The middle "platform interconnect layer" uses structured parameter files (such as JSON) to carry raw event parameters, modulation / demodulation and environment parameters, network packet parameters, and event timestamps. It passes the physical layer transmission events and necessary context generated by the network simulation end to the channel simulation end, and simultaneously receives results such as "physical layer receive event set / pre-demodulation result / channel parameters / timestamp" returned by the channel simulation end, filling them back into data content that can be consumed by the AquaSim native interface.

[0069] The right side is the channel simulation end: First, the CIR calculation module models and visualizes the underwater acoustic environment, comprehensively reads location parameters, hydrology (sound velocity profile), seabed topography, coastline and seabed parameters, and generates the environment and seabed input files required by Bellhop3D. Then, Bellhop is called to calculate the multipath propagation from the sound source to the receiver to obtain the channel impulse response (CIR). Subsequently, geometric / environmental change detection and versioned reuse are performed through CIR cache management (CIR only needs to be calculated once when the geometry / environment remains unchanged). In the modulation and demodulation module, the transmitted signal is generated according to the transmission event and environmental noise is added. Through the "common channel pool", the signals from multiple transmission sources within the same micro-batch window are aligned and superimposed (waveform-level convolution superposition or index-level power superposition). Synchronization / matched filtering / detection and demodulation decisions are completed to form the reception results and timestamps of each receiving node. The results are returned to the network simulation end in the form of "generating a set of received events", so that the network layer and above protocol stack can obtain higher fidelity physical layer propagation and collision effect evaluation capabilities without modifying the original interface semantics.

[0070] See Figures 2-6 The underwater acoustic network physical layer simulation method provided in this application includes the following steps: Step 110: During the process of driving discrete events at the network simulation terminal, the mirror event scheduler listens for the physical layer's transmitted events.

[0071] The mirror event scheduler can listen for the following physical layer send events: 1) The MirrorScheduler continuously monitors the physical layer for whether a Transmit event is triggered during the ns-3 rollout.

[0072] 2) When any node triggers Transmit, MirrorScheduler adds the transmission event to the "Mirror Event Information Buffer".

[0073] In some embodiments, if concurrent windows are enabled, MirrorScheduler opens a collection window of the same length, collecting multiple sending events that occur almost simultaneously within the window to form a batch request (batch_id).

[0074] In some embodiments, before step 110, system initialization and directory and parameter settings can be performed first, specifically including the following: 1. Start AquaSim-NG on the network simulation end, which includes the application layer, network layer, data link layer and physical layer, and drive discrete events to advance by the ns-3 native event scheduler.

[0075] 2. Initialize the MirrorScheduler and configure its listener objects and interconnected directories: Output directory on the sending side: contains "raw event parameter file, modulation and demodulation and environment parameters, network packet parameters, and event timestamp"; Receiver input directory: Read "physical layer receive event parameter file, pre-demodulation results, channel parameters, and event timestamps".

[0076] 3. Start the MATLAB persistent process (working loop) on the channel simulation end, and configure the Bellhop3D path, data source (hydrological data Excel / GEBCO / DBOIT / OSM) and basic simulation parameters (sound velocity, center frequency, bandwidth, noise model, etc.).

[0077] The original event parameter file (send event request, TX_REQUEST) contains the following information: 1) File type and version information; The message type is used to distinguish between requests and responses.

[0078] 2) Batch / window information (used for concurrency consistency and replay), including but not limited to, batch number batch_id, window start time t0 (simulation time), and window length dt_batch (simulation time).

[0079] 3) Environment and geometry version information (used for CIR cache reuse), including: environment version number env_id (corresponding to a set of sound velocity profile / terrain / substance / coastline inputs, etc.) and geometry version number geo_version (corresponding to node position status and CIR cache version).

[0080] 4) Sending event list tx_events (core content): Each sending event must contain at least the packet unique identifier packet_uid (used to find the original packet object during backfilling), sending node identifier tx_node_id, sending time t_tx (simulation time), transmitting power tx_power (specify unit: dB / dBm / linear), payload length (bits or bytes, specify unit), and packet duration pkt_duration (seconds; or can be derived from rate + payload, but it is recommended to give it explicitly to reduce ambiguity between the two parties).

[0081] 5) The status field ostatus=ready (indicates that the file has been written and can be read and processed by the channel end).

[0082] 6) Modulation and demodulation configuration index Among them, omodem_profile_id (specifies the index or name of the modulation scheme, symbol rate, preamble, encoding, and other configurations); If different modulations are allowed for different packets in the same batch, this field can be overridden within each tx_event.

[0083] 7) Basic physical layer parameters (ensure consistency between both parties), including: center frequency carrier_freq, bandwidth, and sampling rate fs.

[0084] It should be noted that waveform level must include the sampling rate, while index level may not include the index level sampling rate.

[0085] 8) Noise model information (for the common channel pool), including: noise model type (e.g., wideband Gaussian noise), noise power or noise power spectral density (indicate units).

[0086] 9) Node snapshots (nodes_snapshot, used to generate link sets at the channel end) include: All nodes, or at least the sending node and candidate receiving nodes, have their node_id, position pos_xyz, velocity vel, and coordinate system and unit declaration (e.g., local ENU, meters).

[0087] In some embodiments, the physical layer receive event parameter file (receive event set response, TX_RESPONSE) should contain the following information: 1) File type and version information, i.e., otype (response type).

[0088] 2) Batch / window information (used for backfill alignment), including batch_id, t0, and dt_batch (used to verify which window the response corresponds to).

[0089] 3) Environment and geometry version information (used for consistency verification), namely oenv_id and geo_version (the response must be consistent with the request; an error should be reported if they are inconsistent).

[0090] 4) Results list (core content): Each result must include at least the receiving node identifier rx_node_id, packet unique identifier packet_uid, receiving completion time t_rx_end (based on which the network simulation end injects the Recv event), and receiving success flag rx_ok (success / failure).

[0091] 5) Status field ostatus=ok or status=error (used by the network simulation end to decide whether to resume / roll back / terminate).

[0092] 6) Receive start time ot_rx_start (facilitates network-side modeling of "receive occupancy / half-duplex / energy detection", etc.).

[0093] 7) The key physical quantities used as the basis for judgment (for easy statistics and visualization) may include sinr_db (signal-to-interference-plus-noise ratio), rx_power_db (received power), and reason_code (failure reason code), such as: normal reception, collision, insufficient signal-to-interference-plus-noise ratio, synchronization failure, out-of-range unreachable, parameter inconsistency, etc.

[0094] In some implementations, interference power, noise power, and detection peak values ​​may also be included.

[0095] The reason code is defined as follows: "Normal reception": via synchronization / demodulation / CRC; "Collision": Strong interference exists within the window, causing demodulation failure; "Insufficient signal-to-interference-plus-noise ratio": SINR is below the threshold; "Detection threshold not reached": Received power is below the threshold. "Other": Timeout, inconsistent parameters, corrupted files, etc.

[0096] Step 120: When any node triggers the sending event, the mirror event scheduler adds the sending event to a preset micro-batch buffer for buffering.

[0097] Step 130: When the preset conditions are met, the mirror event scheduler performs micro-batch aggregation processing on all currently sent events in the micro-batch buffer to obtain the micro-batch aggregation result.

[0098] Step 140: The mirror event scheduler generates a transmission signal based on the micro-batch aggregation result.

[0099] Step 150: The mirror event scheduler generates an uplink parameter file based on the transmitted signal and sends it to the channel simulation terminal.

[0100] In some embodiments, the uplink parameter file includes a raw event parameter file, modulation and demodulation and environment parameters, network packet parameters, and transmission event timestamps.

[0101] The original event parameter file may include sending node ID, receiving candidate set, sending time, packet duration, etc. Modulation and demodulation parameters and environmental parameters may include modulation method, sampling rate / bandwidth, noise parameters, current environment version number, etc. Network packet parameters may include packet_uid (unique packet identifier), payload length, and service type / priority; Event timestamps can include simulation time t_tx and window number batch_id (if concurrent windows are enabled).

[0102] In some embodiments, during the process of generating uplink parameter files at the network emulation end and triggering processing at the channel emulation end, pause control can be performed on the network emulation end. That is, during the period of "waiting for the channel emulation end to return packets", the reception progress related to this batch can be blocked or delayed to prevent causal inconsistency.

[0103] Step 160: The channel simulation terminal determines the target channel impulse response based on the uplink parameter file and the slow variable of underwater acoustic propagation.

[0104] Step 170: The channel simulation terminal generates a downlink parameter file based on the target channel impulse response and the transmitted signal and returns it to the network simulation terminal.

[0105] In some embodiments, the uplink parameter file includes a raw event parameter file, modulation and demodulation and environment parameters, network packet parameters, and transmission event timestamps; In some embodiments, the downlink parameter file includes a physical layer receive event parameter file, pre-demodulation results, channel parameters, and receive event timestamps.

[0106] The physical layer receive event parameter file includes the receiving node ID, packet_uid, receive completion time t_rx_end, success / failure flags, etc. The pre-demodulation results include leader detection results, collision / capture decision, and matched filter peak values ​​(optional); Channel parameters include link-level delay / gain, SINR (signal-to-interference-plus-noise ratio), etc. The event timestamp includes the corresponding batch_id and simulation time, ensuring that it can be backfilled and reproduced.

[0107] Step 180: The mirror event scheduler in the network simulation terminal parses the downlink parameter file and processes the corresponding reception events in the network simulation terminal based on the downlink parameter file.

[0108] The underwater acoustic network physical layer simulation method provided in this embodiment introduces a mirror event scheduler at the network simulation end. The mirror event scheduler intercepts physical layer transmission events and adds them to a preset micro-batch buffer for buffering. When preset conditions are met, the mirror event scheduler performs micro-batch aggregation processing on all current transmission events within the same micro-batch time window in the micro-batch buffer and exports an uplink parameter file, which is then uniformly submitted to the channel simulation end. This allows the channel simulation end to process based on a complete set of transmitted signals. In this way, interference underestimation and collision misjudgment caused by traditional packet-by-packet processing can be avoided. Furthermore, by batch processing transmission events, the frequency of interaction with the channel simulation end can be reduced, avoiding the inter-process / language communication overhead caused by "one call per packet".

[0109] In addition, after the channel simulation end returns the downlink parameter file with timing information, the mirror event scheduler can process the corresponding receive events, which allows the upper-layer protocol stack to still operate according to the native semantics.

[0110] In some embodiments, the platform interconnection layer adopts a bidirectional parameter file communication protocol, which defines at least two types of structured messages; wherein, the two types of structured messages include a raw event parameter file and a physical layer received event parameter file; both the raw event parameter file and the physical layer received event parameter file contain multiple target fields, the target fields including micro-batch identifier, window start simulation time, micro-batch time window length, environment version number, geometry version number, and packet unique identifier.

[0111] In other words, both the original event parameter file and the physical layer received event parameter file carry fields such as batch_id, t0, dt_batch, env_id, geo_version, and packet_uid, enabling traceable backfilling.

[0112] In some embodiments, the mirror event scheduler encapsulates the transmission events in the current micro-batch into a structured raw event parameter file and transmits it as an uplink parameter file to the channel simulation terminal.

[0113] In some embodiments, before exporting the sending event to the channel emulation end, the mirror event scheduler assigns a globally unique packet identifier to each data packet to be sent and maintains a processing mapping table locally on the network emulation end. The processing mapping table records the mapping relationship between the packet identifier and the corresponding data packet's internal packet object handle in the network emulation end. When generating the physical layer receive event parameter file, the channel emulation terminal uses only the packet unique identifier to identify the data packet. When the mirror event scheduler receives the physical layer receive event parameter file, it queries the pending mapping table based on the packet unique identifier contained therein, restores the corresponding internal packet object handle, and calls the native physical layer receive event injection interface in the network emulation terminal to submit the restored internal packet object to the upper layer protocol for processing in a manner that conforms to the semantics of the native protocol stack.

[0114] In other words, the network simulation end maintains a pending mapping table from packet_uid to the handle of the internal packet object; externally, only packet_uid is transmitted, and during backfilling, the original packet object is restored by the mirror event scheduler and the native receiving entry is called.

[0115] In some embodiments, the slow variables of underwater acoustic propagation include node geometry information and underwater acoustic environment information. Step 160, i.e., the channel simulation terminal determines the target channel impulse response based on the uplink parameter file and the slow variables of underwater acoustic propagation, includes: Step 161: After receiving the uplink parameter file, the channel simulation terminal parses the uplink parameter file and extracts the node location.

[0116] Step 162: Determine whether the changes in the node geometry information and the underwater acoustic environment information exceed a preset threshold.

[0117] Step 163: If the change in the node geometry information or the underwater acoustic environment information exceeds a preset threshold, the current channel impulse response is recalculated based on the node position and external input data, and the current channel impulse response is used as the target channel impulse response.

[0118] For steps 161-163, the channel simulation end reads the uplink parameter file, performs geometry / environment detection, and decides whether to calculate the channel impulse response (CIR).

[0119] Specifically, the channel emulation end monitors the interconnect directory, and once a new uplink parameter file is detected, the following operations can be performed: 1) Parse tx_events[] and related parameters to extract the set of sending nodes, receiving candidate nodes and their positions required for this calculation.

[0120] 2) Enter CIR cache management: Execute "Geometry / Environment Detection" to determine whether the current geometry / environment has changed compared to the last time (e.g., the position change exceeds the threshold, or the environment version has changed).

[0121] 3) If the geometry / environment remains unchanged: directly reuse the CIR in the cache.

[0122] 4) If the geometry / environment changes: then rebuild the environment and calculate the CIR.

[0123] In some embodiments, the external input data includes hydrological data, seabed topography parameters, sediment parameters, and coastline parameters; the node location includes spatial information of the receiving node and spatial information of the transmitting node; step 163 is the recalculation of the current channel impulse response based on the node location and the external input data. 1) Read temperature, salinity, and pressure from the aforementioned hydrological data; 2) Call the preset seawater thermohaline equation of state library to convert temperature, salinity, and pressure into depth-sound velocity profiles; 3) Use the BBox to call the OSM interface to read the coastline parameters and draw a planar map; 4) Perform BBox cropping on the seabed topography parameters and sediment parameters to generate a seabed topography mesh, and output a depth map and seabed file; 5) Generate a main configuration file based on the depth-velocity profile, the planar map, the depth map, the spatial information of the receiving node, the spatial information of the transmitting node, the frequency information, and the preset control parameters; 6) Input the seabed file and the main configuration file into the acoustic propagation solver; 7) Call the sound propagation solver to calculate the multipath propagation characteristics from the transmitting node to the receiving node, and obtain the arrival structure; 8) Convert the arrival structure into a CIR tap set to obtain the current channel impulse response.

[0124] In other words, the CIR calculation module in the channel simulation terminal is responsible for completing the underwater acoustic environment modeling (including data fusion, visualization, and parameter standardization), and automatically generating the input files required by Bellhop3D based on the model. The specific process is as follows: 1) Read location parameters: parse the location (latitude and longitude / local coordinates) and depth of the sending / receiving node.

[0125] 2) Read hydrological parameters: Read temperature / salinity / pressure from the HydrologyData worksheet in Excel, call GSW (Gibbs Reservoir) to calculate the sound velocity profile (depth-sound velocity), generate the original interpolation curve and visualize the output.

[0126] 3) Read terrain parameters: Read the global seabed terrain grid and crop it according to BBox to generate a seabed terrain grid, output the depth map, and form a .bty file.

[0127] 4) Read coastline parameters: Use BBox to call the OSM (Open Street Map) interface to pull coastline vector data and draw a planar map (for environmental display and optional occlusion constraints).

[0128] 5) Read sediment parameters: Extract sediment attributes of the target area from the DBOIT sediment database, map them to bottom acoustic parameters and visualize the classification map.

[0129] 6) Use Bellhop3D to generate CIR: Generate inputs such as .env (environment file) and .bty (seabed file), then call Bellhop3D to calculate multipath propagation and obtain the arrival structure (delay / amplitude, etc.), organize it into a CIR tap set and write it into the CIR cache.

[0130] Step 164: If the changes in the node geometry information and the underwater acoustic environment information do not exceed the preset threshold, then the cached channel impulse response is taken as the target channel impulse response.

[0131] In some embodiments, the channel simulation terminal includes a modulation / demodulation module and a common channel pool. Step 170, which involves the channel simulation terminal generating a downlink parameter file based on the target channel impulse response and the transmitted signal and returning it to the network simulation terminal, includes: Step 171: The channel simulation terminal establishes a window-level receiving port for each receiving node, and inputs the transmission signals of all transmitting sources within the current micro-batch window into the modulation and demodulation module to add environmental noise processing to obtain the processed transmission signal.

[0132] The modulation and demodulation module is used to generate transmit signals based on events and add environmental noise.

[0133] Specifically, for each transmission event m in tx_events[], the modulation and demodulation module mainly performs the following: 1) Generate the baseband transmit signal xm(t) (or discrete sequence) based on the modulation method and parameters (bandwidth, symbol rate, preamble structure, etc.).

[0134] 2) Construct a transmission waveform of the corresponding length based on packet_uid, payload length, and packet duration.

[0135] 3) Generate additive noise (wideband or band-limited) based on the noise model, and use it as a component of the noise term at the receiver port for superposition in the common channel pool.

[0136] Step 172: Input the processed transmit signal into the common channel pool of the channel simulation terminal.

[0137] Step 173: The common channel pool processes the target channel impulse response and the processed transmitted signal to obtain the received signal set of each node.

[0138] The common channel pool mainly performs the following operations: 1) CIR signal convolution: For each transmission event m and each receiving node r, the transmitted signal is convolved with a buffered CIR (tap set or discrete filter) to obtain sm→r(t).

[0139] 2) Alignment and superposition: Based on the geometric propagation delay and tap delay, sm→r(t) is aligned to the receiving time axis, the contributions of all transmitting sources within the window are superimposed, and noise is superimposed to obtain the total signal yr(t) at the receiving port.

[0140] 3) Generate N channels based on nodes: Repeat the above process for all receiving nodes to form N receiving port outputs (N is the number of receiving nodes or the size of the candidate receiving set).

[0141] 4) Generate the received signal set of each node / reassemble based on location delay: If it is necessary to support the observation alignment, resampling or time base unification of different receiving nodes, the received signals of each node are reassembled and unified indexed for subsequent detection and decision input.

[0142] Step 174: The common channel pool returns the received signal sets from each node to the modulation and demodulation module.

[0143] Step 175: The modulation and demodulation module detects the received signal sets of each node and generates a set of received events.

[0144] In some embodiments, pre-demodulation collision detection and matched filtering detection can be performed. Specifically, the following can be performed on the receiving port yr(t) of each receiving node r: 1) Pre-demodulation collision detection: Use the leader correlation peak, energy mutation or multi-peak structure to determine whether a collision / capture has occurred, and output the collision flag and candidate synchronization point.

[0145] 2) Matched filtering detection: Matched filtering is performed on the preceding / training sequence corresponding to the target packet to obtain the peak position and statistics (used to determine the arrival time and detection confidence).

[0146] 3) Demodulation decision: If full demodulation is enabled, rx_ok can be obtained by demodulating, decoding and CRC checking the payload; if only the original AquaSim interface semantics are maintained, success / failure can be given directly by the detection statistics / SINR threshold.

[0147] 3) Generate a set of receiving events: For each successful or failed packet_uid, form a "physical layer receiving event" record (receiving node, arrival / completion time, success flag, reason code, etc.).

[0148] Step 176: The channel simulation terminal generates a downlink parameter file based on the received event set and returns it to the network simulation terminal through the platform interconnection layer.

[0149] In some embodiments, step 180, processing the corresponding reception event at the network emulation terminal, includes: Step 181: Read the receive event set from the downlink parameter file.

[0150] Step 182: Map the received event set to event types consistent with the physical layer native event semantics, which include successful reception, failed reception, and packet loss.

[0151] Step 183: For a reception event marked as successful reception, inject a native send event into the discrete event scheduler at the corresponding reception completion time, carrying the internal packet object recovered from the packet's unique identifier.

[0152] Step 184: For reception events marked as reception failure, inject the reception failure event or only update the packet loss statistics information according to the original implementation mechanism.

[0153] Step 185: After injecting all received events, release the pause state of the discrete event network simulator and return control to the native event scheduler so that it can continue to advance subsequent simulation events.

[0154] In other words, the output from the external channel does not directly change the state of the network protocol stack. Instead, it is filled back in the form of "received event parameters" and consumed by the network simulation end through the native entry point. This allows the network layer / link layer / application layer to obtain a high-fidelity physical layer effect without modification.

[0155] Specifically, for steps 181-185, the mirror event scheduler imports the downlink results and adds / deletes / restores Recv events. For details, please refer to the following: 1) Read the received event set results[] and convert it into native event semantics that the AquaSim physical layer can consume (still the original interface data content such as "received successfully / received failed / packet lost", and the data content returned to AquaSim is still the same data content in the original interface).

[0156] 2) Controlling the addition and deletion of Recv events: 2-1) For the result of rx_ok=true, inject a Recv event into the corresponding t_rx_end and carry the packet object mapped by packet_uid; 2-2) For the result of rx_ok=false, inject a receiving failure event or only record packet loss statistics.

[0157] 3) Event execution recovery: Unsuspend and return the generated event scheduler ns-3 to continue execution.

[0158] This process continues in a loop until the simulation termination conditions are met (simulation duration, number of events, task completion, etc.). The simulation then ends and outputs visualization results. For example, the MATLAB visualization module can output sound velocity profiles, coastline maps, terrain / sediment maps, example CIR tap plots, reception success rate / SINR heatmaps, throughput / delay curves, etc., based on logs and intermediate results. The network simulation end outputs protocol layer statistics and link statistics to form an end-to-end evaluation report.

[0159] In some embodiments, the process implemented by the image event scheduler mainly includes initialization and installation, listening for whether the physical layer has a Transmit event triggered, exporting parameters, pausing the event logic to wait for the downlink result, listening for whether the platform interconnection layer generates a parameter file, controlling the addition / deletion / injection of Recv events, and resuming / continuing the execution of events.

[0160] Initialization and installation (executed once at the start of simulation) include the following 1-1)-1-4): 1-1) Register a hook: Bind the AquaSim physical layer's send entry point (such as functions like PhyTxBegin / SendPacket / Transmit) to MirrorScheduler::OnTransmit().

[0161] 1-2) Prepare interconnected directories: Create / clean uplink / , downlink / , done / , error / , logs / .

[0162] 1-3) Load static configurations, including odt_batch (concurrency window length, which can be set to 0 if micro-batch is not enabled), opoll_interval (polling interval for listening to the downstream file), otimeout (timeout threshold for waiting for MATLAB to return), fixed env_id, geo_version, or policy flags for "whether to update with position changes"; 1-4) Start listening event: Schedule a periodic event CheckInterop() (used to "listen for whether the platform interconnect layer generates a parameter file").

[0163] Among these, monitoring whether the physical layer has triggered a Transmit event includes 2-1) - 2-1) Generate packet_uid: It is preferable to use the UID that comes with ns-3Packet or a custom globally incrementing UID.

[0164] 2-2) Temporarily store image event information: Write to PendingTxTable[packet_uid] and save opacket_uid, tx_node_id, t_tx=Now(), pkt_duration, tx_power, payload_bits / bytes, modem_profile_id, oPacketHandle (pointing to the original packet object / copyable handle), etc.

[0165] 2-3) Enter batch buffer: Add the current sending event to TxBatchBuffer.tx_events[].

[0166] 2-4) Determine when to export: For example, if TxBatchBuffer is empty → create a new batch, record t0=Now(), and schedule(t0+dt_batch,FlushBatch); if it is already in the collection window → continue adding the batch. The exported parameters (generated and written to the upstream JSON) can include the following 3-1)-3-3): 3-1) Assemble the "raw event parameter file (TX_REQUEST)": containing obatch_id,t0,dt_batch,env_id,geo_version otx_events[] (Each item contains packet_uid, tx_node_id, t_tx, tx_power, payload, pkt_duration, and modem_profile_id) In some embodiments, if the channel requires location snapshots for link pruning, nodes_snapshot[] may also be included; 3-2) Atomic writing: Write first After writing the .tmp file, rename it to... The .json file is marked with status=ready.

[0167] 3-3) Batch status update: state=SUBMITTED, record submit_time=Now().

[0168] Among them, the event logic pause waiting for the downlink result can include the following 4-1)-4-4): 4-1) FlushBatch() returns immediately after writing the previous line, without blocking the main loop of ns-3; 4-2) The downstream file is checked periodically by CheckInterop() or per batch by Schedule(poll_interval,PollResp(batch_id)); 4-3) Perform backfilling only after a response is detected.

[0169] Among them, monitoring whether the interconnection layer of the monitoring platform generates a parameter file may include scanning the downlink / whether a TX_RESPONSE file exists; if it exists: read and parse the "physical layer receive event parameter file".

[0170] Among them, controlling the addition, deletion / injection of Recv events, in some embodiments, can be the control of each result record (rx_node_id, packet_uid, t_rx_end, rx_ok, ...) in TX_RESPONSE.results[], specifically including the following 5-1)-5-5): 5-1) Recover the packet object by looking up the table: PendingTxTable[packet_uid] retrieves the original packet handle.

[0171] 5-2) Injecting a receive event: Scheduling an event in ns-3 oSchedule(t_rx_end,InjectRecv(rx_node_id,packet_uid,rx_ok,meta)).

[0172] 5-3) Internal behavior of InjectRecv(): If rx_ok=true: Call the native receive entry point of the receiving node's physical layer / device (preserving the original AquaSim interface semantics) and deliver the packet to the MAC / network layer; If rx_ok=false: Follow the original AquaSim processing options: "Receive failure callback / Packet loss statistics / Direct discard".

[0173] 5-4) Cleanup status: The pending entries for this packet_uid are deleted after injection is complete to prevent memory leaks.

[0174] 5-5) Batch Complete: When all results of the batch have been processed, the batch status is set to DONE, and the response file is moved to done / archive.

[0175] The event resumption / continuation (corresponding to the "thread blocking resumption" block diagram) can be implemented in either a blocking or non-blocking manner. A blocking implementation reads and completes the backfilling, then immediately exits the waiting loop, and the simulation continues. A non-blocking implementation releases the resources occupied by the batch after batch DONE, allowing subsequent batches to flush and backfill normally.

[0176] In some embodiments, the CIR calculation module is mainly used for module positioning, input, and output.

[0177] In terms of module positioning, the CIR calculation module is mainly used to build an "underwater acoustic environment digital model" on the MATLAB side, and automatically generate the environment input files (such as .env, .bty, etc.) required by Bellhop3D based on the model. Then, it drives the Bellhop module to calculate the multipath propagation process from the sound source to the receiver, obtain the arrival delay and amplitude (and optional phase / angle of arrival, etc.) of the propagation path, and organize them into channel impulse response (CIR) cache entries required for subsequent "common channel pool + modulation and demodulation".

[0178] For input, the CIR calculation module mainly takes in geographic bounding boxes (BBox), simulation configuration, hydrological data Excel, GEBCO terrain grid data, DBOIT (submarine sediment) database (i.e., raster or vector attribute data), and OSM coastline data interface access parameters (Overpass / OSMAPI).

[0179] The geographic bounding box (BBox) can include, but is not limited to, [lon_min, lat_min, lon_max, lat_max]. Simulation configurations may include, but are not limited to, center frequency f0, sound speed reference / sea state, sound source / receiver location (latitude, longitude and depth), three-dimensional range of propagation calculation and grid resolution; Hydrological data in Excel can be a worksheet named HydrologyData (such as temperature, salinity, pressure, etc.).

[0180] GEBCO terrain grid data can be in formats such as NetCDF and GeoTIFF.

[0181] Regarding output, the CIR calculation module mainly outputs the following: 1) Bellhop3D input files: .env: The main environment configuration file (containing sound velocity profile, boundary conditions, frequency, sound source / receiver, calculation control parameters, etc.).

[0182] .bty: Bathymetry file.

[0183] In some embodiments, the Bellhop3D input file can also be a substrate / sediment partition file or a substrate parameter table (if a partitioned substrate or multi-substrate approximation is used).

[0184] 2) Bellhop3D Key Output: Arrival Information File (arrival delay, magnitude, number of paths, etc.; the specific file extension depends on the Bellhop version and configuration).

[0185] 3) CIR cache structure: CIR_CACHE(geo_version).links(tx_id,rx_id)=taps.

[0186] 4) Visualization maps: sound velocity profile map, coastline map, topographic elevation (depth) map, sediment classification map, Bellhop propagation path / arrival structure diagram (all saved as PNG).

[0187] In some implementations, the CIR calculation module can be divided into 5 sub-modules and 1 aggregator, forming a step chain such as: sound velocity profile reading and processing → coastline boundary acquisition → seabed topography and sediment modeling → Bellhop3D configuration file generation → Bellhop3D running and CIR output processing.

[0188] The reading and processing of sound velocity profiles may include the following: 1) Use readtable() to read an Excel file containing hydrological data: The worksheet name is fixed as HydrologyData.

[0189] Specify column name mappings: Temperature T (°C), Salinity SP (Practical Salinity), Pressure P (dbar).

[0190] Data cleaning: Remove NaN / outliers (such as salinity <0, temperature outside the physical range, pressure not monotonic).

[0191] Pressure → Depth: The depth (m) is calculated using the relevant functions of the GSW (GibbsSeaWater) library, and the depth is uniformly positive downwards.

[0192] 2) Use GSW to calculate the speed of sound. 2-1) Calculate absolute salinity (SA) from practical salinity.

[0193] 2-2) Calculate the conservative temperature (CT) from temperature.

[0194] 2-3) Call the sound speed calculation interface to obtain the sound speed c(z) (m / s).

[0195] 3) Interpolation and resampling 3-1) Set the depth grid z_grid (e.g., 0:Δz:Zmax, Δz=0.5–2m is configurable); 3-2) c_grid is obtained by piecewise cubic Hermite interpolation (pchip, shape-preserving interpolation) or spline interpolation; 3-3) Perform small window smoothing (moving average or Savitzky-Golay) on c_grid to suppress measurement noise, but the cascade characteristics must be preserved (this point can be written as "smoothing does not change the main cascade structure").

[0196] 4) Visualization and Saving 4-1) Plot the original point and the interpolation curve: depth is the vertical axis and sound velocity is the horizontal axis; 4-2) Save as SSP_raw.png and SSP_interp.png; 4-3) Write ssp_interp into the required sonic profile segment in Bellhop.env.

[0197] In some embodiments, obtaining the coastline boundary may include the following: 1) Construct a BBox query and request OSM data: 1-1) Generate an Overpass / OSM query string (natural coastline element) based on the BBox. 1-2) MATLAB uses webread() to initiate an HTTP request to obtain JSON / GeoJSON.

[0198] 2) Analyze vectors and clip them 2-1) Parse the returned nodes and line segments to reconstruct the coastline polyline; 2-2) Trim the line segments that cross the BBox to ensure that the vector falls within the area.

[0199] 3) Draw a plan map 3-1) Overlay the coastline onto the map coordinate system; 3-2) Mark the following on the map: BBox boundary, sound source point, receiver point, and main geographical direction; 3-3) Output PNG as the environmental visualization result in the patent embodiment.

[0200] In some embodiments, the seafloor topography and sediments (GEBCO+DBOIT) include the following: 1) Read and trim the GEBCO mesh. 1-1) Read NetCDF / GeoTIFF (e.g., ncread()) to obtain latitude and longitude grid and elevation. 1-2) Perform subset clipping based on the BBox; 1-3) Unit uniformity: Seabed depth is a positive value (depth = -Elevation, if Elevation is negative, it indicates the seabed). 2) Coordinate transformation and regular meshing: 2-1) Select a reference point (usually the center of BBox) to establish a local ENU (East-North-Sky) coordinate system. 2-2) Convert the latitude and longitude grid to a local (x,y) (meters) grid. 2-3) Generate a regular, equally spaced grid (Δx, Δy are configurable, e.g., 25–200m), and resample the original GEBCO. 3) Output .bty seabed topography file According to the input format requirements of Bellhop3D, write the x–y grid size, spacing and depth of each grid point, and output Bathymetry.png (depth heat map / isodiameter map), and mark the projection position of the sound source / receiver.

[0201] 4) Read sediment data and crop and align it. It can read DBOIT data, which includes sediment category or attribute fields (such as mud / sand / gravel / rock, etc.), crop to BBox, and align with the terrain grid (the same (x,y) grid).

[0202] 5) Sediment classification and acoustic parameter mapping To make sediment data usable for propagation simulation, the “category” needs to be mapped to a set of bottom acoustic parameters, such as bottom longitudinal wave velocity c_bottom, bottom density rho_bottom, and bottom attenuation coefficient alpha_bottom (which can be frequency-dependent).

[0203] One way to achieve this is to create a lookup dictionary called sedtable with the structure "category → parameter" and assign parameters to each grid point.

[0204] In some embodiments, Bellhop3D configuration file generation (.env / .bty, etc.) includes env environment file generation and .bty seabed terrain file generation.

[0205] The .env file must contain at least the parameter sections for calculation frequency, sound velocity profile (SSP), boundary conditions, sound source / receiver definitions, and control parameters.

[0206] The calculated frequency can be the center frequency f0 (Hz); The sound velocity profile (SSP) can be written (depth-sound velocity pair) by ssp_interp obtained from E1. Boundary conditions may include sea surface boundary, seabed boundary, and sediment parameters (sediment mapping results from E3).

[0207] The sound source / receiver definition includes the sound source location: horizontal coordinates (transformed x, y) and depth z, and the receiver: a single point or an array (which can be multiple depths or multiple horizontal locations).

[0208] Control parameters include, but are not limited to, the range of ray angles, the number of ray beams, the maximum number of reflections, and the step size.

[0209] In some embodiments, the .bty seabed topography file can be generated by E3-3, ensuring that the seabed topography referenced by .env is consistent with the .bty file (same coordinate system, same unit, same reference origin).

[0210] In some embodiments, Bellhop3D execution and CIR extraction and processing (output to subsequent communication simulation) may include the following: 1) Bellhop Operation Control 1-1) Check the integrity of the input file (grid size, depth range, whether the sound source is in the water, etc.); 1-2) Call Bellhop3D to calculate the multipath propagation from the sound source to the receiver; 1-3) Generate key output files (reaching structures, path lists, etc.; determined by Bellhop configuration); 2) Generate a set of CIR taps from Bellhop output: For each link (sound source tx → receiver rx), a path set k=1..K is obtained. Each path includes at least: arrival delay (seconds), amplitude (linear amplitude or dB, internal linear complex gain is recommended), phase, and angle of arrival (horizontal / vertical).

[0211] Formation of CIR: .

[0212] in, It is a complex gain (consisting of amplitude and phase). Then Deposit: ; CIR is calculated only once during geometry / environment updates and is identified by geo_version; each subsequent TxBatch only references this cache and Bellhop is not called repeatedly.

[0213] It should be noted that all steps are uniformly arranged by the "Environment Modeling Controller" of MATLAB on the channel simulation side, and an environment version number env_id is assigned for each environment generation (for reproducibility and cache reuse).

[0214] In some embodiments, the CIR cache structure includes: First-level index: geo_version; Secondary index: Sending node tx_id; Third-level index: receiving node rx_id; Value: Tap set taps = {(delay_k, gain_k)} or {(delay_k, gain_k, doppler_k)}.

[0215] This structure supports fast lookup and reuse, and can record invalid link states (e.g., links exceeding R_max do not generate taps).

[0216] In some embodiments, the common channel pool is primarily used for the following operations: 1) Definition and data structure of window-level "receive port" Within each micro-batch window, a window-level "receive port" object RxPort(r, batch_id) is created for each receiving node, which contains at least: t0: Window start timestamp (consistent with AquaSim's batch time); Fs: Sampling rate (used at waveform level; not required at index level); y_r[n]: Discrete time series buffer at the receiver port (used at the waveform level, with optional complex baseband); P_sig[r,m]: Target signal power table (index level, indexed by "packet / transmission event m"); P_int[r,m]: Interference power table (indicator level); P_noise[r]: Noise power (indicator level); results: This window displays a list of decision outputs for the receiving node (one result item per packet). The "send event" is defined as a send transaction within the window: tx_node_id, packet_uid, t_tx, tx_power, modem_profile_id, payload_len, etc.

[0217] 2) Waveform-level implementation 2-1) For each send event within the window and each receiving node The following input is required: Among them, the transmitted waveform (Generated by the modem_profile_id by the modem_demodulation module, with length covering packet duration); The link multipath tap set (CIR) can be calculated using the following formula: ; in, Arrival delay (seconds) For complex gain (linear amplitude and phase), there is an additional propagation delay (geometric direct-to-line delay). (If the taps already contain absolute delay, they can be set to 0).

[0218] Noise power spectral density or bandwidth Corresponding noise power .

[0219] In some embodiments, the steps performed on each receiving node r within the window may include the following: S1: Allocate a timeline for the receiving port and clear the buffer, i.e., set a coverage window and its maximum propagation delay buffer length: .

[0220] in It represents the maximum latency of all link taps within this window.

[0221] Generate a discrete cache y_r[n] with a length of It is initialized to 0.

[0222] S2: Construct and sum the contribution of each transmitted event to the receiving port, i.e., for each transmitted event... First, calculate its "arrival at the starting sampling point" at the receiving port: ; It is then processed through a multipath tap to form the received signal: ; Then superimposed onto the receiving port: ; S3: Superimposed noise (optional: whitening / bandpass), i.e., generating additive Gaussian noise. (Complex baseband or real signal), satisfying power , superimposed: ; S4: Perform synchronization and demodulation on each packet to be decided. For each send event within the window In its expected arrival range Internal execution: 1) Optimal alignment point is obtained through synchronization / arrival detection (such as correlation peak detection, preamble detection, matched filtering). ; 2) Demodulation and decoding (BPSK / QPSK / FSK / OFDM, etc., according to modem_profile_id).

[0223] 3) CRC check yields rx_ok, and can output the statistic: sinr_db_est (e.g., estimated using decision pilot or preamble correlation output).

[0224] In some embodiments, each output result record includes, but is not limited to, response type (type), batch_id, environment and geometry version information (env_id, geo_version), receiving node identifier (rx_node_id), packet unique identifier (packet_uid), receiving completion time (t_rx_end, used by the network simulation end to inject a Recv event), receiving success flag (rx_ok, success / failure), status=ok or status=error (used by the network simulation end to decide to resume / roll back / terminate), t_rx_start (facilitating network-side modeling of "receiver occupancy / half-duplex / energy detection, etc."), sinr_db (signal-to-interference-plus-noise ratio), rx_power_db (received power), interference power, noise power, and detected peak value.

[0225] Based on the above embodiments, this application achieves high simulation accuracy, good data openness, and support for real hardware integration by integrating the physical layer communication module implemented by AquaSim-ng (underwater network simulation extension library) based on NS-3 (network simulator 3), MATLAB (Matrix Laboratory) and Bellhop.

[0226] This application adopts a collaborative simulation architecture of "network master control, physical externalization, dual time-scale decoupling, and semantic transparency", which specifically includes the following four core design principles: 1) The network layer master controller remains unchanged. As the sole master node of the simulation system, AquaSim / ns-3 continuously drives the simulation clock and schedules discrete events, ensuring the determinism and reproducibility of the overall simulation logic.

[0227] 2) High-fidelity external physical layer The high-fidelity physical layer processing—including channel impulse response (CIR) calculation, waveform-level modulation and demodulation, alignment and superposition of multiple signals in a common channel pool, and collision determination—is uniformly migrated to the MATLAB side to support accurate underwater acoustic channel modeling.

[0228] 3) Decoupling of fast and slow variables under dual time scales Slow timescale: Variables related to the marine environment and node geometry (such as sound velocity profile, seabed topography, node position / velocity) only trigger CIR recalculation when changes occur, and are versioned and cached using the geometry version number (geo_version); Fast timescale: Aggregates concurrently sent events within a micro-batch time window. MATLAB directly reuses the corresponding geo_version CIR buffer to perform efficient overlay and receive decision, avoiding redundant calculations and improving simulation throughput.

[0229] 4) Interface semantics are fully preserved MATLAB only outputs structured packet-level reception results (such as success / failure, SINR, reception time, etc.) and does not directly interfere with the protocol stack state. AquaSim maps this result to native standard events such as "reception successful", "reception failed" or "packet loss" and injects it into the protocol stack through the existing callback mechanism to ensure that the MAC layer, routing layer and application layer can obtain high-fidelity physical layer behavior without any modification.

[0230] In other words, this application uses AquaSim-NG / ns-3 as the master clock and protocol stack framework for discrete event simulation. A MirrorScheduler is introduced at the network simulation end to intercept physical layer events and export the original event parameter files. This interacts with the channel simulation end (MATLAB) through the platform interconnect layer. The channel simulation end uses the CIR calculation module to model the underwater acoustic environment and calls Bellhop to calculate multipath propagation. Based on CIR cache management, it achieves "no repeated calculations if geometry / environment remains unchanged." Then, a common channel pool superimposes and decides on concurrent signals within the same window. Finally, the "physical layer received event set" is backfilled to the network simulation end to control the addition and deletion of Recv events, ensuring that the upper-layer protocol stack maintains its original interface semantics. Based on this, this application has the following beneficial effects: 1) High-fidelity underwater acoustic physical layer injection is achieved without altering the semantics of the AquaSim protocol stack, significantly improving the reliability of the simulation.

[0231] Because existing AquaSim physical layers typically employ simplified propagation models (empirical loss, fixed packet error rate, simplified multipath), they are unable to reflect the changes in sound velocity profile, seabed topography, and seabed sediment caused by multipath structural variations.

[0232] This application explicitly constructs a complete underwater acoustic environment model at the channel simulation end, including sound velocity profile, coastline boundary, seabed topography and sediment bottom. Based on this model, it automatically generates the input files required by Bellhop3D, and then calculates a high-fidelity multipath arrival structure (including the time delay, amplitude and phase of each path) to form an accurate channel impulse response (CIR).

[0233] This CIR is directly used to drive the signal superposition and physical layer detection and decision process in the common channel pool, thereby naturally reproducing the key effects unique to real underwater acoustic propagation, including: multipath delay spread, frequency selective fading, and non-uniform path energy distribution.

[0234] In addition, since the physical layer decision results are generated by the high-fidelity acoustic propagation model and backfilled to the network simulation end in the form of a structured set of received events, the whole process does not modify any logic or interface semantics of the upper-layer protocol stack, but makes the simulation system highly sensitive to changes in the marine environment (such as thermoclines, seabed types, and shoreline reflections), significantly improving the physical realism and statistical reliability of underwater acoustic link behavior.

[0235] 2) By using “CIR cache management + geometry / environment detection”, repeated calls to Bellhop are avoided, significantly reducing computational load and improving simulation throughput.

[0236] The computational overhead of existing Bellhop3D mainly comes from marine environment modeling, 3D ray tracing, and multipath arrival structure output, resulting in high time consumption per call. If a Bellhop calculation is triggered independently for each transmission event, the total computational load will increase linearly with the number of transmission events, making it difficult to support large-scale or long-term underwater acoustic network simulations.

[0237] This application effectively alleviates this bottleneck by employing a fast-slow variable decoupling strategy: Specifically, slow variables in channel propagation (including sound speed profile, seabed topography, sediment substrate and relative geometric relationships between nodes) are separated from fast variables (such as specific transmission time, number of concurrent packets, interference superposition, etc.); A geometry version number (geo_version) is introduced to identify the state of slow variables. Only when a significant change (exceeding a preset threshold) is detected in the node position, environmental parameters, or seabed boundary, geo_version is updated and Bellhop3D is called again to generate a new set of CIR taps. While the geo_version remains unchanged, all transmitted events reuse the cached CIR data, eliminating the need to repeatedly perform the costly acoustic propagation solution.

[0238] Therefore, the computational complexity of physical layer processing changes from being strongly correlated with the number of events sent (O(N)) to being strongly correlated with the number of geometry / environment updates (O(M), and M...). N). Because node movement and environmental changes are usually slow in real-world scenarios, the geo_version update frequency is much lower than the packet sending frequency, thus significantly reducing the number of Bellhop3D calls.

[0239] 3) The common channel pool achieves concurrent consistency of "superposition first, decision later", which can realistically depict collision, capture and near-far effects.

[0240] In existing underwater acoustic communication technologies, due to signal propagation time delays and significant multipath spread, multiple concurrently transmitted signals often exhibit significant time overlap and energy superposition at the receiving end. If traditional methods are used to independently model each link and make reception decisions separately, the interference relationships within the same window are artificially severed, failing to accurately reflect the actual physical layer collision behavior. This leads to serious distortion in the assessment of MAC layer collision probability, acquisition capability, and retransmission mechanisms.

[0241] In this application, within each micro-batch time window, a window-level receiving port is established for each receiving node. The arriving signals from all transmitting sources within the window, after being convolved by the corresponding link CIR, are time-aligned and linearly superimposed according to the precise propagation delay. Environmental noise is uniformly introduced into the superposition result to form a complete noisy received waveform. Subsequently, a unified physical layer processing flow is performed based on this synthesized signal, including synchronization, matched filtering, interference-sensing demodulation, and final decision.

[0242] Under this mechanism, the target signal and concurrent interference are naturally coupled within the receiving port, and their power relationship directly determines the success or failure of demodulation, thus truly presenting the following key phenomena: strong signal captures weak signal (Capture Effect); near-far effect causes strong interference at close range to suppress weak signal at long range; non-ideal collision behavior under multi-packet overlap (partial success, partial failure).

[0243] Since all concurrent signals are jointly modeled and uniformly decided at the receiver, this application can characterize the collision and capture mechanism in the underwater acoustic channel with high fidelity, significantly improving the accuracy and reliability of performance evaluation of upper-layer mechanisms such as MAC protocol, routing strategy and retransmission control.

[0244] 4) The mirror event scheduler ensures controllable timing through “export-backfill-inject Recv”, avoiding causal disorder introduced by the external physical layer.

[0245] Since the correctness of discrete event simulation depends on the execution of events in the order of timestamps, when an external solver (MATLAB / Bellhop) is introduced, if timing encapsulation and unified backfilling are not performed, causal problems such as incorrect order of received events and missed counts of cross-window interference can easily occur.

[0246] This application uses a mirrored event scheduler to collect and send events and bind batch timestamps. After the external return results, only the receive events are injected according to t_rx_end, so that all received events have clear and reproducible landing points on the ns-3 time axis.

[0247] Meanwhile, the platform interconnection layer carries consistency fields such as batch_id, t0, dt_batch, and geo_version in the file to ensure that the backfill correspondence is clear.

[0248] In other words, since the generation and injection of received events are completely controlled by the mirror scheduler and constrained by a unified timestamp, the external physical layer will not disrupt the causal progression of ns-3, thus improving the stability and reproducibility of the simulation.

[0249] 5) Environmental modeling and visualization output form an "interpretable chain of evidence," improving the auditability and deliverability of simulation results.

[0250] Existing technologies only output network metrics such as throughput / packet loss, which cannot explain the reasons for performance changes. Especially in underwater acoustic environments with strong time-varying / spatial differences, the lack of interpretability weakens the persuasiveness of simulation conclusions.

[0251] The CIR calculation module of this application can output corresponding visualizations (sound velocity profile curves, topographic depth maps, sediment classification maps, and example CIR tap / reach structure maps) after constructing sound velocity profiles, coastlines, topography, and sediments.

[0252] These graphs are bound to env_id / geo_version, forming an evidence chain of "environment—propagation—received judgment—protocol performance".

[0253] Therefore, this application proposes a method to couple an external high-fidelity physical layer (including geometrically correlated channel response, common channel pool superposition, and modulation / demodulation decision) into an underwater acoustic network simulation in a scalable and causally consistent manner, without changing the time control mechanism of the discrete event network simulator and without altering the upper-layer protocol stack interface as much as possible. This allows for a unified solution of the collision / capture effect of concurrent transmission and the receiving timing, while significantly reducing channel computation overhead and improving simulation reproducibility and engineering feasibility.

[0254] like Figure 7As shown in the figure, this application provides a computer device including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114. Memory 113 is used to store computer programs; In one embodiment of this application, when the processor 111 executes the program stored in the memory 113, it implements the underwater acoustic network physical layer simulation method of the network simulator provided in any of the foregoing method embodiments, including: During the process of driving discrete events in the network simulation terminal, the mirror event scheduler listens for events sent from the physical layer. When any node triggers the sending event, the mirror event scheduler adds the sending event to a preset micro-batch buffer for buffering; When preset conditions are met, the mirror event scheduler performs micro-batch aggregation processing on all currently sent events in the micro-batch buffer to obtain the micro-batch aggregation result; The mirror event scheduler generates a transmission signal based on the micro-batch aggregation result; The mirror event scheduler generates an uplink parameter file based on the transmitted signal and sends it to the channel simulation terminal. The channel simulation terminal determines the target channel impulse response based on the uplink parameter file and the slow variable of underwater acoustic propagation. The channel simulation terminal generates a downlink parameter file based on the target channel impulse response and the transmitted signal, and returns it to the network simulation terminal. The mirror event scheduler in the network simulation terminal parses the downlink parameter file and processes the corresponding receive events based on the downlink parameter file in the network simulation terminal.

[0255] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0256] Therefore, this application embodiment also provides a computer-readable storage medium storing a computer program thereon, wherein when the computer program is executed by a processor, it implements the steps of the underwater acoustic network physical layer simulation method of the network simulator provided in any of the foregoing method embodiments, including: During the process of driving discrete events in the network simulation terminal, the mirror event scheduler listens for events sent from the physical layer. When any node triggers the sending event, the mirror event scheduler adds the sending event to a preset micro-batch buffer for buffering; When preset conditions are met, the mirror event scheduler performs micro-batch aggregation processing on all currently sent events in the micro-batch buffer to obtain the micro-batch aggregation result; The mirror event scheduler generates a transmission signal based on the micro-batch aggregation result; The mirror event scheduler generates an uplink parameter file based on the transmitted signal and sends it to the channel simulation terminal. The channel simulation terminal determines the target channel impulse response based on the uplink parameter file and the slow variable of underwater acoustic propagation. The channel simulation terminal generates a downlink parameter file based on the target channel impulse response and the transmitted signal, and returns it to the network simulation terminal. The mirror event scheduler in the network simulation terminal parses the downlink parameter file and processes the corresponding receive events based on the downlink parameter file in the network simulation terminal.

[0257] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0258] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0259] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0260] The steps in the methods of this application embodiment can be adjusted, merged, or deleted according to actual needs. The units in the apparatus of this application embodiment can be merged, divided, or deleted according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0261] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0262] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0263] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Since these modifications and variations fall within the scope of the claims and their equivalents, this application also intends to include these modifications and variations.

[0264] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for simulating the physical layer of an underwater acoustic network in a network simulator, characterized in that, The underwater acoustic network physical layer simulation system includes a network simulation terminal and a channel simulation terminal. The network simulation terminal is equipped with a mirror event scheduler. The method includes: During the process of driving discrete events in the network simulation terminal, the mirror event scheduler listens for events sent from the physical layer. When any node triggers the sending event, the mirror event scheduler adds the sending event to a preset micro-batch buffer for buffering; When preset conditions are met, the mirror event scheduler performs micro-batch aggregation processing on all currently sent events in the micro-batch buffer to obtain the micro-batch aggregation result; The mirror event scheduler generates a transmission signal based on the micro-batch aggregation result; The mirror event scheduler generates an uplink parameter file based on the transmitted signal and sends it to the channel simulation terminal. The channel simulation terminal determines the target channel impulse response based on the uplink parameter file and the slow variable of underwater acoustic propagation. The channel simulation terminal generates a downlink parameter file based on the target channel impulse response and the transmitted signal, and returns it to the network simulation terminal. The mirror event scheduler in the network simulation terminal parses the downlink parameter file and processes the corresponding receive events based on the downlink parameter file in the network simulation terminal.

2. The method according to claim 1, characterized in that, The network physical layer simulation system also includes a platform interconnection layer, which adopts a bidirectional parameter file communication protocol, and the protocol defines at least two types of structured messages; The two types of structured messages include the original event parameter file and the physical layer received event parameter file; Both the original event parameter file and the physical layer received event parameter file contain multiple target fields, including micro-batch identifier, window start simulation time, micro-batch time window length, environment version number, geometry version number, and packet unique identifier.

3. The method according to claim 1, characterized in that, Before exporting the sending event to the channel simulation end, the mirror event scheduler assigns a globally unique packet identifier to each data packet to be sent and maintains a processing mapping table locally on the network simulation end. The processing mapping table records the mapping relationship between the packet identifier and the corresponding data packet's internal packet object handle in the network simulation end. When generating the physical layer receive event parameter file, the channel simulation terminal uses only the packet unique identifier to identify the data packet. When the mirror event scheduler receives the physical layer receive event parameter file, it queries the pending mapping table based on the packet unique identifier contained therein, restores the corresponding internal packet object handle, and calls the native physical layer receive event injection interface in the network simulation terminal to submit the restored internal packet object to the upper layer protocol for processing in a manner that conforms to the semantics of the native protocol stack.

4. The method according to claim 1, characterized in that, The slow variables of underwater acoustic propagation include node geometry information and underwater acoustic environment information. Based on the uplink parameter file and the slow variables of underwater acoustic propagation, the channel simulation terminal determines the target channel impulse response, including: After receiving the uplink parameter file, the channel simulation terminal parses the uplink parameter file and extracts the node positions. Determine whether the changes in the node geometry information and the underwater acoustic environment information exceed a preset threshold. If the change in the node geometry information or the underwater acoustic environment information exceeds a preset threshold, the current channel impulse response is recalculated based on the node position and external input data, and the current channel impulse response is used as the target channel impulse response. If the changes in the node geometry information and the underwater acoustic environment information do not exceed a preset threshold, the cached channel impulse response will be used as the target channel impulse response.

5. The method according to claim 4, characterized in that, The external input data includes hydrological data, seabed topography parameters, sediment parameters, and coastline parameters. The node location includes spatial information of the receiving node and spatial information of the transmitting node. The current channel impulse response is recalculated based on the node location and the external input data. Temperature, salinity, and pressure are read from the hydrological data; The preset ocean thermohaline equation of state library is used to convert temperature, salinity, and pressure into depth-sound velocity profiles; The OSM interface is used to read the coastline parameters based on the BBox, and a planar map is drawn. The seabed topography parameters and sediment parameters are clipped using BBox to generate a seabed topography mesh, and the depth map and seabed file are output. Based on the depth-velocity profile, the planar map, the depth map, the spatial information of the receiving node, the spatial information of the transmitting node, the frequency information, and the preset control parameters, a main configuration file is generated; Input the seabed file and the main configuration file into the acoustic propagation solver; The sound propagation solver is invoked to calculate the multipath propagation characteristics from the transmitting node to the receiving node, and the arrival structure is obtained. The arrival structure is converted into a set of CIR taps to obtain the current channel impulse response.

6. The method according to claim 1, characterized in that, The channel simulation terminal is equipped with a modulation / demodulation module and a common channel pool. Based on the target channel impulse response and the transmitted signal, the channel simulation terminal generates a downlink parameter file and returns it to the network simulation terminal, including: The channel simulation terminal establishes a window-level receiving port for each receiving node, and inputs the transmitted signals of all transmitting sources within the current micro-batch window into the modulation and demodulation module to add environmental noise processing to obtain the processed transmitted signal; The processed transmit signal is input into the common channel pool of the channel simulation terminal; The common channel pool processes the target channel impulse response and the processed transmitted signal to obtain the received signal set of each node; The common channel pool returns the output signal sets received by each node to the modulation and demodulation module; The modulation and demodulation module detects the received signal sets of each node and generates a set of received events; The channel simulation terminal generates a downlink parameter file based on the received event set and returns it to the network simulation terminal through the platform interconnection layer.

7. The method according to claim 1, characterized in that, The corresponding received events are processed in the network simulation terminal, including: Read the receive event set from the downlink parameter file; The received event set is mapped to event types consistent with the semantics of the physical layer's native events, which include successful reception, failed reception, and packet loss. For a reception event marked as successful reception, a native send event is injected into the discrete event scheduler at the corresponding reception completion time, carrying the internal packet object recovered from the packet's unique identifier; For reception events marked as reception failures, the existing implementation mechanism can be used to either inject the reception failure event or simply update the packet loss statistics. After all received events have been injected, the pause state of the discrete event network simulator is lifted, and control is returned to the event scheduler to allow it to continue with subsequent simulation events.

8. The method according to claim 1, characterized in that, The uplink parameter file includes the original event parameter file, modulation and demodulation and environment parameters, network data packet parameters, and transmission event timestamps; The downlink parameter file includes a physical layer receive event parameter file, pre-demodulation results, channel parameters, and receive event timestamps.

9. A network simulator's underwater acoustic network physical layer simulation system, characterized in that, The underwater acoustic network physical layer simulation system includes a network simulation terminal, a channel simulation terminal, and a platform interconnection layer. The network simulation terminal is equipped with a mirror event scheduler. The mirror event scheduler is used to listen for events sent from the physical layer during the process of driving discrete events at the network simulation terminal. When any node triggers the sending event, the sending event is added to a preset micro-batch buffer for buffering; When preset conditions are met, all current transmission events in the micro-batch buffer are aggregated in a micro-batch to obtain a micro-batch aggregation result; a transmission signal is generated based on the micro-batch aggregation result, and an uplink parameter file is generated based on the transmission signal, and then sent to the channel simulation terminal through the platform interconnection layer; The channel simulation terminal is used to receive the uplink parameter file of the platform interconnection layer, and determine the target channel impulse response based on the uplink parameter file and the slow variable of underwater acoustic propagation. Based on the target channel impulse response and the transmitted signal, a downlink parameter file is generated and returned to the network simulation terminal through the platform interconnection layer; The mirror event scheduler in the network simulation terminal is also used to parse the downlink parameter file and inject or delete corresponding reception events in the network simulation terminal based on the reception completion time and reception success flag of the downlink parameter file. The channel simulation terminal sends back the physical layer reception result in the form of "reception event parameters", which are consumed by the network simulation terminal through the native reception entry.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images