A method and system for multi-source heterogeneous network converged communication in emergency command scenarios

Abstract

This invention discloses a method and system for multi-source heterogeneous network converged communication in emergency command scenarios. It acquires remote relay link data, distributed self-organizing link data, and mobile access link data. For the remote relay link data, it performs protocol parsing to identify protocol feature identifiers and generates a unified access table based on these identifiers through cross-network mapping. Using the unified access table, it performs link complementarity analysis to extract strongly complementary link pairs and form multi-path transmission schemes. It identifies group communication nodes, establishes protocol conversion channels, performs protocol conflict detection to identify conflict resolution nodes, and performs protocol remapping to generate a collaborative routing table. It performs channel reverse extraction, route compensation processing, priority inversion identification, and transmission fault tolerance configuration to build a converged communication state. Finally, it determines the converged communication domain and converts the collaborative routing table into a multi-network converged communication deployment scheme, achieving the convergence of satellite communication, self-organizing network communication, and mobile communication, providing a communication guarantee solution for emergency command.

Description

Technical Field

[0001] This invention relates to the field of emergency communication technology, and in particular to a method and system for multi-source heterogeneous network converged communication in emergency command scenarios. Background Technology

[0002] Emergency command scenarios require simultaneous access to various heterogeneous communication resources such as satellite networks, wireless ad hoc networks, and mobile cellular networks. However, these networks use different communication protocols, address systems, and transmission mechanisms, which leads to technical obstacles to interconnection between networks.

[0003] Existing heterogeneous network access solutions suffer from the following shortcomings: First, gateway devices only provide basic protocol translation functions and cannot identify and resolve deep-seated protocol semantic conflicts. When group calls in trunked communications need to be transmitted across networks, critical service attribute information is easily lost. Second, the utilization methods of various network links are relatively independent, lacking comprehensive consideration of the transmission characteristics of different links. When a link experiences congestion or failure, service switching response is slow. Third, in scenarios with concurrent transmission of multiple services, high-priority services occupy channel resources for extended periods, while low-priority services continuously wait, lacking a reasonable scheduling mechanism. Fourth, fixed transmission parameter configurations are often used, failing to dynamically adjust fault tolerance strength according to changes in link status, resulting in insufficient transmission reliability when link quality deteriorates. Therefore, a new technical solution is needed to achieve effective integration and intelligent scheduling of heterogeneous networks. Summary of the Invention

[0004] This invention discloses a method and system for multi-source heterogeneous network converged communication in emergency command scenarios, addressing issues such as poor interoperability of heterogeneous network protocols, insufficient collaborative utilization of link resources, lack of service scheduling mechanisms, and inflexible transmission parameter configuration in existing technologies. By establishing cross-network protocol mapping relationships, analyzing link complementarity characteristics, detecting and resolving protocol conflicts, dynamically adjusting routing priorities and fault tolerance parameters, and ultimately generating a rapidly deployable communication configuration file, it provides stable and reliable multi-source heterogeneous network converged communication capabilities for emergency command scenarios.

[0005] The first aspect of this invention proposes a multi-source heterogeneous network fusion communication method for emergency command scenarios, comprising the following steps:

[0006] Acquire remote relay link data, distributed self-organizing link data, and mobile access link data; perform protocol parsing on the remote relay link data to identify protocol feature identifiers; and perform cross-network mapping between the distributed self-organizing link data and the mobile access link data based on the protocol feature identifiers to generate a unified access table.

[0007] The unified access table is used to perform link complementarity analysis to generate a complementarity relationship graph. Strong complementary link pairs are extracted from the complementarity relationship graph to generate complementary scheduling parameters. The complementary scheduling parameters are then used to perform complementary combinations to form a multipath transmission scheme.

[0008] Based on the multipath transmission scheme, group communication nodes are identified, a protocol conversion channel is established between the group communication nodes and real-time service nodes, protocol conflict detection is performed on the protocol conversion channel to identify conflict resolution nodes, and protocol remapping is performed based on the conflict resolution nodes to generate a cooperative routing table;

[0009] Based on the cooperative routing table, remote relay side channel reverse extraction is performed to form a reverse channel graph. The reverse channel graph is then processed by distributed self-organizing side routing compensation to generate a routing compensation matrix. The routing compensation matrix is ​​used to perform priority inversion identification to form a routing priority inversion table. The routing priority inversion table is then used for transmission fault tolerance configuration to build a converged communication state.

[0010] Based on the converged communication state, the converged communication domain is determined, and the collaborative routing table is converted into a multi-network converged communication deployment scheme according to the converged communication domain.

[0011] The second aspect of this invention proposes a multi-source heterogeneous network converged communication system for emergency command scenarios, comprising:

[0012] The data acquisition module is used to acquire remote relay link data, distributed self-organizing link data, and mobile access link data. It performs protocol parsing on the remote relay link data to identify protocol feature identifiers, and performs cross-network mapping between the distributed self-organizing link data and the mobile access link data based on the protocol feature identifiers to generate a unified access table.

[0013] The link analysis module is used to perform link complementarity analysis using the unified access table to generate a complementarity relationship graph, extract strongly complementary link pairs from the complementarity relationship graph to generate complementary scheduling parameters, and use the complementary scheduling parameters to perform complementary combinations to form a multi-path transmission scheme.

[0014] The protocol conversion module is used to identify group communication nodes based on the multipath transmission scheme, establish a protocol conversion channel between the group communication nodes and real-time service nodes, perform protocol conflict detection on the protocol conversion channel to identify conflict resolution nodes, and generate a cooperative routing table based on the conflict resolution nodes;

[0015] The routing optimization module is used to perform remote relay side channel reverse extraction based on the cooperative routing table to form a reverse channel graph, perform distributed self-organizing side routing compensation processing on the reverse channel graph to generate a routing compensation matrix, use the routing compensation matrix to perform priority inversion identification to form a routing priority inversion table, and use the routing priority inversion table to perform transmission fault tolerance configuration to build a converged communication state;

[0016] The configuration generation module is used to determine the converged communication domain based on the converged communication state, and convert the collaborative routing table into a multi-network converged communication deployment scheme according to the converged communication domain.

[0017] The beneficial effects of this invention are reflected in the following points: First, it solves the problem of protocol interoperability and collaborative utilization of link resources in heterogeneous networks. By parsing the remote relay link data and establishing a protocol classification table, protocol matching is performed on distributed self-organizing link data and mobile access link data, and cross-network address translation is executed to generate a unified access table, realizing address mapping and protocol interoperability among satellite networks, self-organizing networks, and mobile base station networks. By performing complementarity analysis on link characteristic vectors, link combinations that are complementary in performance indicators such as bandwidth and latency are identified, strongly complementary link pairs are extracted and complementary scheduling parameters are generated, and a multi-path transmission scheme is established, realizing collaborative utilization of link resources and automatic switching in case of failure. Second, it realizes automatic detection and resolution of cross-network protocol conflicts. By establishing a protocol conversion channel between group communication nodes and real-time service nodes, collecting protocol interaction sequences and analyzing protocol inconsistencies, conducting compatibility tests on conflict locations, and configuring protocol conversion rules on conflict resolution nodes based on the evaluation results, the field mapping conflict between the cluster communication protocol and the standard network protocol is resolved, ensuring the normal transmission of various services such as group calls, video transmission, and data acquisition in heterogeneous networks. Third, it improves the rationality of service scheduling and the ability to deploy quickly. By extracting routing load values ​​and identifying congestion thresholds, a priority reversal mechanism is triggered when the waiting time for low-priority routes exceeds the limit and the congestion severity reaches the reversal threshold, thus preventing long-term blocking of low-priority services. The link stability level is inferred based on the reversal trigger frequency in the route priority reversal table, and forward error correction coding parameters are configured for links with different stability levels, improving transmission reliability. Performance clustering of links based on converged communication states establishes a converged communication domain, transforming the collaborative routing table into a multi-network converged communication deployment scheme that includes domain configuration, route configuration, protocol conversion, and priority policies, shortening the deployment time for emergency communication.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0019] The accompanying drawings illustrate specific examples of the technical solutions described in this invention and, together with the detailed embodiments, form part of the specification, serving to explain the technical solutions, principles, and effects of this invention.

[0020] Unless otherwise specified, the same reference numerals in different figures represent the same or similar technical features, and different reference numerals may be used to represent the same or similar technical features.

[0021] Figure 1 This is a flowchart illustrating a multi-source heterogeneous network fusion communication method for emergency command scenarios according to the present invention.

[0022] Figure 2 This is a structural block diagram of a multi-source heterogeneous network converged communication system for emergency command scenarios according to the present invention. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] The technical solutions of the embodiments of this application will be described below.

[0027] like Figure 1As shown, this embodiment of the invention provides a multi-source heterogeneous network fusion communication method in an emergency command scenario, including the following steps S110-S150:

[0028] Step S110: Obtain remote trunk link data, distributed self-organizing link data, and mobile access link data; perform protocol parsing on the remote trunk link data to identify protocol feature identifiers; and perform cross-network mapping between the distributed self-organizing link data and the mobile access link data based on the protocol feature identifiers to generate a unified access table.

[0029] Specifically, the system acquires remote relay link data, distributed self-organizing link data, and mobile access link data. Data acquisition modules deployed at the edge nodes of the outdoor space station acquire link data from three different network layers in real time. Remote relay link data originates from satellite communication relay stations and includes long-distance transmission link status information, packet header information, and routing and forwarding records. In emergency command scenarios, the outdoor space station establishes a communication connection with the remote command center via satellite links. The satellite relay stations record the performance status, data traffic, and transmission quality of the communication links as remote relay link data. Distributed self-organizing link data originates from self-organizing network nodes within a local area and includes communication data packets and network topology information between nodes. After an earthquake damages communication infrastructure, rescue personnel in the disaster area automatically establish temporary communication networks using handheld terminal devices. These devices discover each other, establish connections, and collaboratively forward data; the communication data between these nodes constitutes distributed self-organizing link data. Mobile access link data originates from the access layer of mobile base stations and includes service data and network access information from terminal devices. The mobile base stations equipped on the outdoor space station provide mobile communication services to on-site personnel. The base stations record the traffic and network status of each terminal device, forming mobile access link data. The collected link data from the three sources undergoes format standardization processing, mapping data fields from different sources to a standard data structure and unifying the timestamp format and address encoding method.

[0030] Protocol parsing is performed on remote relay link data to identify protocol features. Deep packet inspection is conducted on the collected remote relay link data to extract protocol field information from the packet header. The protocol type field is read from the IP layer header of the remote relay link data; common values ​​include TCP, UDP, and ICMP. The port number field is read from the transport layer header of the link data; the source and destination ports each occupy 16 bits, and different port numbers correspond to different application layer protocols. Feature matching is performed on the application layer payload of the remote relay link data to identify characteristic strings of application protocols such as HTTP, FTP, and DNS. When the outdoor space station transmits on-site video monitoring footage to the command center via satellite link, the video stream is encapsulated using the HTTP protocol. The protocol parsing module identifies the TCP transport protocol, port number 80, and HTTP application features from the data packets. The protocol type, port number, and application features extracted from the remote relay link data are integrated into a protocol feature identifier. Protocol feature identifiers are represented using a triple structure: (protocol type, port number, application feature). For example, the protocol feature identifier for a specific link's data is (TCP, 80, HTTP), indicating that the link transmits TCP protocol, uses port 80, and uses HTTP protocol at the application layer. A corresponding protocol feature identifier is generated for each data packet in the remote relay link data, providing the foundational data for subsequent protocol classification and cross-network mapping.

[0031] In some embodiments, the step of performing cross-network mapping between the distributed self-organizing link data and the mobile access link data based on the protocol feature identifier to generate a unified access table includes: extracting the protocol type code from the protocol feature identifier to form a protocol classification table; using the protocol classification table to perform protocol matching between the distributed self-organizing link data and the mobile access link data to generate a matching relationship matrix; performing cross-network address translation based on the matching relationship matrix to obtain an address mapping set; and integrating the address mapping set into a unified access table.

[0032] A protocol type code is extracted from the protocol feature identifier to form a protocol classification table. The first element, the protocol type field, is extracted from the triple structure of the protocol feature identifier; the value of this field is the protocol type code. All protocol feature identifiers identified from remote relay link data are traversed, and all occurrences of the protocol type code are collected. Duplicate values ​​are removed to form a protocol type code set. The protocol type code set is then classified and organized, grouping different application protocols of the same transport layer protocol into one category. TCP protocol type codes are mapped to category T, UDP protocol type codes to category U, and ICMP protocol type codes to category I. A mapping table is established between protocol type codes and protocol names and port ranges. Each entry includes the type code, protocol category, common port range, and protocol description. This organized mapping table serves as the protocol classification table. The protocol classification table records ports corresponding to TCP protocols, such as 21 (FTP), 80 (HTTP), and 443 (HTTPS), while ports corresponding to UDP protocols include 53 (DNS), 123 (NTP), and 161 (SNMP). The protocol classification table allows for the rapid determination of the protocol category and possible application scenarios of any protocol feature identifier, providing a reference for cross-network protocol matching.

[0033] A protocol classification table is used to match distributed ad hoc link data and mobile access link data to generate a matching relationship matrix. Protocol type identification is performed on both distributed ad hoc link data and mobile access link data based on the protocol classification table. Encapsulated IP packets are extracted from the packet payload of the distributed ad hoc link data, the IP header is parsed, and its protocol type field is identified. The identified protocol type is then matched against the protocol classification table. Service type information is extracted from the signaling messages of the mobile access link data. The corresponding protocol category is inferred based on the service type, and the inferred protocol category is matched against the protocol categories in the protocol classification table. A matching relationship is established between distributed ad hoc link data and the protocol classification table. For each ad hoc network node, the protocol type used by the node and its corresponding entry in the classification table are recorded. A matching relationship is also established between mobile access link data and the protocol classification table. For each mobile terminal, the protocol type used by the terminal and its corresponding entry in the classification table are recorded. A two-dimensional matching relationship matrix is ​​constructed, where rows correspond to nodes in the distributed ad hoc link data, columns correspond to terminals in the mobile access link data, and matrix element values ​​indicate whether there is a communication requirement for the same protocol category between the node and the terminal. When a self-organizing network node and a mobile terminal use the same or compatible protocol category, the corresponding element in the matching matrix is ​​set to 1, indicating a successful match; otherwise, it is set to 0, indicating a mismatch. Analyzing the distribution of non-zero elements in the matching matrix determines the communication path that needs to be established for cross-network connections.

[0034] Cross-network address translation is performed based on a matching relationship matrix to obtain an address mapping set. Based on the non-zero elements in the matching relationship matrix, the node-terminal pairs requiring address mapping are determined. For each element with a value of 1 in the matrix, the corresponding ad hoc network node address and mobile terminal address are extracted. The ad hoc network node address uses a private LAN address range, such as 192.168.xx or 10.xxx, while the mobile terminal address uses a public network address or NAT address assigned by the operator. Cross-network address translation is performed, mapping the private address of the ad hoc network node to a public network address or virtual address accessible by the mobile terminal. Address translation rules are configured on the edge gateway device of the outdoor space station. The rules include a triplet of source address, destination address, and translated address. The configured address translation rules are recorded as address mapping entries. Each mapping entry contains the ad hoc network node address, mobile terminal address, translated virtual address, and mapping validity period. All address mapping entries generated based on the matching relationship matrix are collected to form an address mapping set. The address mapping set is deduplicated, merging multiple mapping entries pointing to the same target address. The optimized address mapping set contains all valid address mapping relationships.

[0035] The address mapping set is integrated into a unified access table. Mapping entries in the address mapping set are sorted by destination address, with entries having the same destination address grouped together. A unified access identifier is assigned to each group of mapping entries for easy indexing and querying. The source address, destination address, virtual address, protocol type, and access identifier of the mapping entries are extracted from the address mapping set, and these fields are integrated into entries in the unified access table. The unified access table is stored using a relational database structure, with the access identifier as the primary key and source and destination addresses as index fields for fast querying. Each record in the access table includes fields such as source network type identifier (ad hoc network / mobile network / satellite network), source address, destination network type identifier, destination address, protocol type, virtual address, and mapping status. A dynamic update mechanism is set for the unified access table; incremental updates are triggered when distributed ad hoc link data or mobile access link data changes. When new rescue personnel join the ad hoc network or access a mobile base station with terminal equipment, the address mapping set automatically generates new mapping entries, and the unified access table automatically adds new address mapping records, ensuring seamless communication between the newly added device and existing network nodes. During operation, the edge gateway forwards data across networks by querying the unified access table, supporting protocol interoperability and data exchange between satellite communication, ad hoc network communication, and mobile base stations. The unified access table enables protocol interoperability and unified address management for three heterogeneous networks: remote relay link data, distributed ad hoc link data, and mobile access link data.

[0036] Step S120: Perform link complementarity analysis using the unified access table to generate a complementary relationship graph. Extract strongly complementary link pairs from the complementary relationship graph to generate complementary scheduling parameters. Use the complementary scheduling parameters to perform complementary combinations to form a multi-path transmission scheme.

[0037] Specifically, a unified access table is used to perform link complementarity analysis and generate a complementarity relationship graph. All valid cross-network connection records are read from the unified access table, and the source address, destination address, protocol type, and mapping status fields are extracted from each record. For each connection record, its network layer (remote relay, distributed ad hoc, mobile access) is identified, and the corresponding physical link identifier is determined. Physical links are characterized by high bandwidth capacity but high latency, typically 200-500 milliseconds, with bandwidth exceeding 10 Mbps. Ad hoc network links have low latency, typically 10-50 milliseconds, but limited bandwidth, typically 1-5 Mbps. Mobile access links have moderate performance, with latency of approximately 50-100 milliseconds and bandwidth of approximately 5-10 Mbps, but with significant stability fluctuations. These differentiated performance characteristics provide the foundational data for link complementarity analysis. The measured performance indicators are correlated with the link identifiers to form a link performance dataset. This study analyzes the complementarity of links in a link performance dataset, identifying link pairs with complementary performance metrics. A graph structure representing link complementarity is constructed, where nodes represent physical links, edges represent complementary relationships between links, and edge weights indicate complementarity strength. Complementarity strength is determined by calculating the degree of difference in performance metrics between two links; the greater the difference, the stronger the complementarity. This constructed graph structure serves as a complementarity graph, containing all link nodes participating in cross-network transmission and their complementary relationships.

[0038] In some embodiments, the step of extracting strongly complementary link pairs from the complementary relationship graph to generate complementary scheduling parameters includes: performing link characteristic decomposition on the complementary relationship graph to generate link characteristic vectors; calculating the complementarity between the link characteristic vectors to form a complementarity matrix; selecting the link combination corresponding to the maximum complementarity from the complementarity matrix as a strongly complementary link pair; and generating complementary scheduling parameters based on the characteristic differences of the strongly complementary link pairs.

[0039] Link characteristic vectors are generated by decomposing the complementary relationship graph. Performance metrics data for each link node are extracted from the complementary relationship graph, including measurements of bandwidth, latency, packet loss rate, and jitter. The raw data for the four performance dimensions are normalized to map metrics with different dimensions to a unified numerical range of 0-1, eliminating the influence of dimensional differences. Normalization is performed as follows: v'_k = (v_k - v_min) / (v_max - v_min), where v_k is the original performance metric value, v_min and v_max are the minimum and maximum values ​​of the metric across all links, respectively, and v'_k is the normalized value. The normalized four-dimensional performance metrics are combined into a link characteristic vector, represented as V = (v_bandwidth, v_latency, v_packet loss, v_jitter), where each component reflects the normalized characteristic value of the link in the corresponding performance dimension. For each link in the complementary relationship graph, a corresponding link characteristic vector is generated, and a mapping table between link identifiers and characteristic vectors is established. During emergency command operations, satellite links exhibit higher bandwidth and lower latency value in their link characteristic vectors, while ad hoc network links show the opposite characteristics. This differentiated distribution of characteristic vectors provides a quantitative basis for identifying complementary links. Integrating all link characteristic vectors into a characteristic vector set provides input data for quantifying complementarity.

[0040] A complementarity matrix is ​​formed based on the differences between link characteristic vectors. For any two link characteristic vectors V_i and V_j in the characteristic vector set, their complementarity is quantified. The complementarity is defined as the weighted sum of the differences between the two vectors in each dimension: C(i,j)=Σw_k|v_i,k-v_j,k|, where v_i,k represents the component value of the characteristic vector V_i of link i in the k-th dimension, k traverses four dimensions: bandwidth, latency, packet loss, and jitter, and w_k is the weight coefficient of the k-th dimension, with a weight sum of 1. The weight coefficients are dynamically adjusted according to the service type. Video conferencing is highly sensitive to latency and jitter, so the weights of these two dimensions are increased to 0.6; high-capacity data transmission is highly sensitive to bandwidth, so the weight of the bandwidth dimension is increased to 0.5. All link pairs are traversed, and the above formula is applied to each link pair to calculate the difference of its link characteristic vectors, obtaining the complementarity value, and generating a complementarity matrix of size N×N, where N is the number of link nodes in the complementarity relationship graph. The complementarity matrix is ​​a symmetric matrix, with diagonal elements equal to 0 and off-diagonal elements representing the complementarity strength of corresponding link pairs. The complementarity matrix shows that the complementarity values ​​between satellite links and ad hoc network links are generally high, indicating significant differences in performance characteristics between these two types of links and suggesting good complementary potential.

[0041] For example, selecting the link combination corresponding to the maximum complementarity value from the complementarity matrix as a strong complementary link pair includes: traversing all elements in the complementarity matrix to identify local maximum points; determining the corresponding link index pair at the local maximum point to form a candidate link set; evaluating the fluctuation difference of each link pair in the candidate link set to generate complementary fluctuation parameters; and selecting the link combination with the largest fluctuation characteristic difference as a strong complementary link pair based on the complementary fluctuation parameters.

[0042] Local maxima are identified by traversing all elements in the complementarity matrix. A sliding window method is used to scan the complementarity matrix, with a window size of 3×3 covering the current element and its surrounding neighboring elements. The complementarity values ​​of the center element in the window are compared with all other elements in its neighborhood. When the complementarity value of the center element is greater than that of all its neighbors, the element is marked as a local maxima. All off-diagonal elements of the complementarity matrix are traversed row by row and column by column, and a local maxima determination is performed for each element. All element locations that satisfy the local maxima condition are collected; these locations correspond to complementarity values ​​that peak within their neighborhoods. The location information of all identified local maxima points is recorded to form a set of local maxima points. This set contains multiple candidate high complementarity locations, and the link pairs corresponding to these locations have optimal complementarity within their local range. In emergency rescue scenarios, the complementarity matrix displays multiple local maxima points, corresponding to satellite-ad hoc network link pairs, satellite-mobile base station link pairs, and ad hoc network-mobile base station link pairs, indicating that there are multiple complementary combinations between different network layers. By identifying local maxima points, link combinations with good complementarity are avoided from being overlooked.

[0043] At local maxima, corresponding link index pairs are identified to form a candidate link set. For each local maxima in the set, its row and column indices in the complementarity matrix are read. The row and column indices correspond to two link nodes in the complementarity graph, and the specific link identifier is located through the index value. The mapping table between link identifiers and link characteristic vectors is queried to obtain the link identifier and network layer information corresponding to each index. The link index pair corresponding to each local maxima is recorded as a candidate, which includes the identifier of link i, the identifier of link j, and their complementarity value. All candidate options are collected to form a candidate link set. The candidate link set contains all link pairs with local optimal complementarity, and each link pair is a potential strong complementary link pair. The candidate link set is initially screened, and link pairs from the same network layer are eliminated because links at the same layer have similar performance characteristics and limited complementary effects. Although the two satellite links of the outdoor space station have high complementarity values, they are eliminated because they both belong to the remote relay layer, and their actual complementary effect is not as good as the combination of satellite links and ad hoc network links. The selected candidate link set contains link pairs from different network layers, ensuring the effectiveness of complementarity.

[0044] The fluctuation difference of each link pair in the candidate link set is evaluated to generate complementary fluctuation parameters. For each link pair in the candidate link set, the time-series fluctuation characteristics of the performance indicators of the two links are analyzed. The performance indicator sequence of each link within a 60-second time window is obtained, including the measured values ​​of bandwidth, latency, packet loss rate, and jitter at multiple times. An analysis of variance is performed on the performance indicator sequence of each link, and the variance reflects the stability of the link performance. The performance indicator variance σ_i of link i and the performance indicator variance σ_j of link j represent the fluctuation degree of the two links, respectively. The variance values ​​of the two links in the link pair are compared. The fluctuation difference is defined as: D(i,j)=|σ_i-σ_j|. The larger the fluctuation difference value, the more significant the difference in the stability characteristics of the two links. When the performance of one link is stable, the other link may fluctuate more. The fluctuation difference is correlated with the complementarity value of the corresponding link pair to form complementary fluctuation parameters. The complementary fluctuation parameters contain three core elements: link pair identifier, fluctuation difference, and complementarity value. In disaster relief communications, satellite links fluctuate significantly due to weather conditions, while ad hoc network links are relatively stable. The fluctuation differences between the two are high, and complementary fluctuation parameters indicate that this link pair exhibits good fluctuation complementarity characteristics. Corresponding complementary fluctuation parameters are generated for each link pair in the candidate link set, establishing a correspondence between link pairs and parameters.

[0045] Based on complementary fluctuation parameters, link pairs with the largest differences in fluctuation characteristics are selected as strongly complementary link pairs. The complementary fluctuation parameters of all link pairs in the candidate link set are comprehensively evaluated, and fluctuation difference values ​​are extracted from these parameters and sorted in descending order of fluctuation difference. Link pairs with larger fluctuation differences are ranked higher, indicating significant differences in performance fluctuation characteristics. Several link pairs with the highest fluctuation differences in the ranking are selected as the final strongly complementary link pairs; the number of selections is determined based on network scale and service requirements. The selected link pairs undergo dual verification of complementary fluctuation parameters to ensure that each pair has both high complementarity and significant fluctuation differences. The verified link pairs are confirmed as strongly complementary link pairs. These pairs are complementary not only in performance metrics but also in stability characteristics. When one link experiences performance fluctuations leading to a decrease in transmission quality, the other link often remains stable, taking over traffic and ensuring communication continuity. The link identifier, complementarity value, and fluctuation difference value of each strongly complementary link pair are recorded. This information serves as a component of the complementary fluctuation parameters, providing a data foundation for generating scheduling parameters.

[0046] Complementary scheduling parameters are generated based on the characteristic differences of strongly complementary link pairs. The link characteristic vector of each link pair in a strongly complementary link pair is extracted, and the difference values ​​of the two vectors in each dimension are analyzed to obtain the percentage performance difference of each link pair in four dimensions: bandwidth, latency, packet loss rate, and jitter, serving as a quantitative indicator of characteristic differences. Based on the percentage characteristic difference, the complementary direction of the link pair is determined; if one link has high bandwidth and high latency, and the other has low bandwidth and low latency, it is determined to be a bandwidth-latency complementary type. Scheduling priorities are assigned to each strongly complementary link pair. The priority is determined comprehensively based on the complementarity value and fluctuation difference of the link pair; the higher the complementarity and fluctuation difference, the higher the priority. A dynamic switching threshold is set for the link pair. When the performance index of the primary link drops below the threshold, traffic migration to the backup link is triggered. During disaster relief, when the satellite link's signal quality deteriorates due to severe weather, triggering the switching threshold, the complementary scheduling parameters instruct the edge gateway to automatically migrate some traffic to the ad hoc network link, ensuring communication continuity. The link pair's identifier, priority, complementarity type, and switching threshold are integrated into the complementary scheduling parameters. The complementary scheduling parameters contain scheduling configuration information for all strongly complementary link pairs, providing parameter input for the formulation of multipath transmission schemes.

[0047] In some embodiments, the step of using the complementary scheduling parameters to form a multipath transmission scheme includes: parsing the link complementarity features in the complementary scheduling parameters to form a feature matching table; generating complementary link groups by performing link complementarity grouping based on the feature matching table; allocating service traffic weights to the complementary link groups to obtain a traffic allocation strategy; and associating the traffic allocation strategy with the complementary link groups to form a multipath transmission scheme.

[0048] The complementary scheduling parameters are analyzed to form a feature matching table by analyzing the link complementarity characteristics. The link identifier and complementarity type information of each strongly complementary link pair are read from the complementary scheduling parameters. The characteristic values ​​of each link in the complementary scheduling parameters across four dimensions—bandwidth, latency, packet loss rate, and jitter—are extracted, along with the link's role within the link pair. Role positioning includes two types: primary link and backup link. The primary link undertakes the main data transmission task, while the backup link takes over traffic when the primary link's performance degrades. The complementarity type of the links in the complementary scheduling parameters is analyzed to identify whether the link is bandwidth-advantageous, latency-advantageous, or stability-advantageous. Bandwidth-advantageous links have high throughput but may have higher latency; latency-advantageous links have low transmission latency but limited bandwidth capacity; and stability-advantageous links have small performance fluctuations but generally lower peak capacity. The link identifier, characteristic values, role positioning, and advantage type are integrated into a link complementarity feature description. The link complementarity feature description is represented in a structured format, including a link identifier field, a four-dimensional characteristic value array, a role type field, and an advantage type field. A correspondence between link identifiers and complementary feature descriptions is established to form a feature matching table. The feature matching table contains all links participating in complementary transmission and their characteristic information, facilitating link grouping and traffic allocation. The feature matching table uses a key-value pair structure, with the link identifier as the key and the complementary feature description as the value, supporting efficient query operations. During emergency command operations, when large volumes of video surveillance data need to be transmitted, the feature matching table can be queried to quickly locate links with bandwidth advantages; when real-time voice commands need to be transmitted, links with latency advantages can be located, achieving optimal matching between services and links.

[0049] Complementary link groups are generated based on the feature matching table. Links with the same complementary type are filtered from the feature matching table and grouped into the same group. During the filtering process, all link records in the feature matching table are traversed, and the dominant type field of each link is read. Links with the same dominant type are collected into the same list. For bandwidth-latency complementary link pairs, high-bandwidth links and low-latency links are marked separately to form complementary pairs. High-bandwidth links are suitable for carrying data-intensive services, while low-latency links are suitable for carrying services with high real-time requirements. Using them together can meet the needs of mixed services. For stability complementary link pairs, links with large performance fluctuations are paired with links with small performance fluctuations to form stability complementary pairs. Links with large performance fluctuations may provide higher performance under normal conditions, but their quality degrades significantly under harsh environments; links with small performance fluctuations may have lower peak performance, but they can maintain stable transmission under various conditions. Multiple complementary pairs are integrated into complementary link groups, and each link group contains several links with complementary relationships. A unique group identifier is assigned to each complementary link group, and the identifiers and complementary relationships of each link within the link group are recorded. The records include a list of link identifiers, pairing relationships between links, and weight allocation for each link. Complementary link groups cover different network layers and protocol types, meeting diverse service transmission needs. When performing on-site video conferencing tasks, outdoor space stations select latency-advantaged link combinations from the complementary link groups to ensure real-time and smooth audio and video transmission.

[0050] Traffic allocation strategies are derived by assigning service traffic weights to complementary link groups. The characteristics of current network traffic are analyzed to identify the QoS requirements of different service types. Service types include video surveillance, voice calls, data transmission, and file downloads, each with different bandwidth and latency requirements. For bandwidth-intensive services, high-bandwidth links are prioritized; for latency-sensitive services, low-latency links are prioritized. Based on the characteristics and advantages of each link in the complementary link group, a traffic weight coefficient is determined. The traffic weight coefficient reflects the proportion of traffic shared by each link in the complementary link group. The traffic weight coefficient is dynamically adjusted based on the link's bandwidth capacity and current load to ensure balanced utilization of each link. When the current load of a link approaches its capacity limit, the weight coefficient of that link is reduced, allocating more traffic to links with lighter loads. Traffic allocation scheduling rules are set, defining the traffic sharing mechanism between primary and backup links. The primary link carries most of the service traffic, while the backup link carries a portion of the traffic to remain active and provide redundancy protection. The traffic weight coefficients and scheduling rules are integrated into a traffic allocation strategy. The traffic allocation strategy includes traffic allocation rules and dynamic adjustment mechanisms for each complementary link group. Environmental monitoring data is uploaded via satellite links, and emergency instructions are issued via ad hoc network links. The traffic allocation strategy distributes different services to the most suitable links for transmission based on data flow direction and priority.

[0051] A multi-path transmission scheme is formed by associating traffic allocation strategies with complementary link groups. A corresponding traffic allocation strategy is configured for each complementary link group, establishing a mapping relationship between link group identifiers and allocation strategies. This mapping relationship is stored using an association table structure, supporting fast lookups and dynamic updates. A routing table for multi-path transmission is generated, containing source address, destination address, complementary link group identifier, and traffic allocation strategy fields. Multi-path forwarding rules are configured for the edge gateway. These rules, based on the source and destination addresses and service type of data packets, query the routing table to select the corresponding complementary link group and distribute traffic according to the traffic allocation strategy. Service type identification is achieved by analyzing the protocol type and port number of the data packets. A monitoring mechanism for multi-path transmission is set up to monitor the performance status and traffic load of each link in real time. When a performance degradation of a link is detected, a dynamic adjustment of the traffic allocation strategy is triggered, migrating traffic to other links in the complementary link group. The routing table, forwarding rules, monitoring mechanism, and dynamic adjustment mechanism are integrated into the multi-path transmission scheme. This multi-path transmission scheme achieves cross-network multi-path data transmission based on a unified access table, improving data transmission reliability and network resource utilization efficiency through the collaborative work of strongly complementary link pairs.

[0052] Step S130: Identify group communication nodes based on multi-path transmission scheme, establish a protocol conversion channel between group communication nodes and real-time service nodes, perform protocol conflict detection on the protocol conversion channel to identify conflict resolution nodes, and generate a collaborative routing table based on the conflict resolution nodes through protocol remapping.

[0053] Specifically, group communication nodes are identified based on multipath transmission schemes. Information on all network nodes participating in multipath transmission is extracted from the multipath transmission scheme, including node identifier, node type, network layer, and supported communication protocols. Node types are analyzed to identify nodes with group communication capabilities, and nodes supporting trunking communication protocols (such as TETRA, DMR, and PDT) are marked as potential group communication nodes. The trunking communication base station on the outdoor space station serves as a typical group communication node, supporting one-to-many and many-to-many group call functions, and can simultaneously serve up to 100 terminal devices. Nodes meeting group communication capabilities are confirmed as group communication nodes; these nodes possess group communication functions such as trunking calls, group calls, all calls, and emergency calls. Group communication nodes play a crucial role in emergency rescue scenarios, enabling the rapid establishment of command and dispatch networks. At the emergency rescue site, the space station's trunking communication base station, acting as a group communication node, simultaneously connects the rescue team leader's handheld walkie-talkie, the on-site commander's individual terminal, and the dispatch console of the rear command center, forming a multi-level group communication network.

[0054] A protocol conversion channel is established between the group communication nodes and real-time service nodes. Real-time service nodes are identified; these nodes carry services with high real-time requirements, including video conferencing nodes, voice call nodes, and data acquisition nodes. Video conferencing nodes operate on satellite links to transmit live video feeds, voice call nodes operate on ad hoc network links for rescue coordination, and data acquisition nodes upload environmental monitoring information via mobile base stations. A protocol conversion module is deployed on the group communication nodes. This module has multi-protocol parsing and conversion capabilities, supporting bidirectional conversion between trunking communication protocols and the IP protocol suite. A logical connection is established between the group communication nodes and each real-time service node, forming a protocol conversion channel. The protocol conversion channel includes attributes such as source node identifier, destination node identifier, source protocol type, destination protocol type, and channel status. A unique channel identifier is assigned to each protocol conversion channel in UUID format for easy management and monitoring. The channel status includes four states: establishing, active, idle, and released, supporting channel lifecycle management and resource optimization.

[0055] In some embodiments, performing protocol conflict detection and identifying conflict resolution nodes on the protocol conversion channel includes: collecting protocol interaction sequences in the protocol conversion channel to form a protocol behavior record; analyzing protocol inconsistencies in the protocol behavior record to generate conflict location identifiers; performing protocol compatibility testing on the conflict location identifiers to obtain compatibility evaluation results; and setting protocol conversion rules based on the compatibility evaluation results to form conflict resolution nodes.

[0056] Protocol interaction sequences in the protocol conversion channels are collected to form a protocol behavior record. A protocol capture mechanism is deployed on each protocol conversion channel to capture all data packets passing through that channel in real time. The capture mechanism uses a lossless mirroring method to avoid affecting normal data transmission. Protocol header information for each data packet is extracted, including protocol type, source address, destination address, port number, sequence number, and timestamp, with timestamp accuracy down to the microsecond level. The captured data packets are arranged in chronological order to form a protocol interaction sequence. The protocol interaction sequence records the transmission order of data packets in the protocol conversion channel and the process of protocol field changes. Request-response pairs in the protocol interaction sequence are analyzed to identify the complete protocol interaction process. For example, a soldier's terminal at the rescue site initiates a group call request to the trunking base station. The base station converts the request into SIP protocol and forwards it to the command center. After the command center responds, the base station converts the response back into trunking communication protocol and sends it to the terminal. This complete process constitutes the protocol interaction sequence. The captured protocol interaction sequences and their associated metadata are integrated into a protocol behavior record. The protocol behavior record includes information such as channel identifier, interaction sequence, protocol type changes, field mapping relationships, and interaction duration. Establish a storage structure for protocol behavior records, using a time-series database format, and support querying and retrieval by channel identifier and time range.

[0057] Analyze protocol inconsistencies in the protocol behavior record to generate conflict location identifiers. Traverse each protocol interaction sequence in the protocol behavior record, comparing the field correspondence between the source and destination protocols. Identify fields present in the source protocol but missing in the destination protocol; these fields will cause information loss during protocol conversion. Identify fields with the same name but different semantics in the source and destination protocols; these fields may cause misunderstandings during conversion. For each identified inconsistency, quantify its degree of inconsistency: I = w_m × N_m + w_s × N_s, where I is the degree of inconsistency, N_m is the number of missing fields, N_s is the number of semantically conflicting fields, and w_m and w_s are the weighting coefficients for missing and semantically conflicting fields, typically set to w_m = 0.6 and w_s = 0.4. Mark locations with an inconsistency degree higher than a threshold (usually set to 0.5) as protocol conflict points, recording the position of the conflict point in the protocol interaction sequence of the protocol behavior record. Generate a conflict location identifier for each conflict point, containing attributes such as channel identifier, sequence position, conflict type, and degree of inconsistency. The group identifier field of the trunking communication protocol cannot be directly mapped when converted to the SIP protocol. The position corresponding to this field is marked as a conflict position identifier, with an inconsistency level of 0.7, which is considered high conflict. All conflict position identifiers are integrated into a conflict identifier set to provide input data for compatibility testing.

[0058] Protocol compatibility testing was conducted on conflict location identifiers to obtain compatibility assessment results. Protocol compatibility test cases were designed for each conflict location identifier. The test cases simulated real-world protocol interaction scenarios, introducing protocol inconsistencies corresponding to the conflict location identifiers. The test cases were executed in the test environment to observe the success rate of protocol conversion and data integrity. Test metrics included conversion power, field retention rate, and end-to-end latency increment. Conversion power reflects whether the protocol conversion could be completed, field retention rate reflects whether critical information was lost, and latency increment reflects conversion overhead. For conflicts with missing group identifier fields, the test results showed a conversion power of 100% but a field retention rate of only 60%, indicating that although the conversion could be completed, critical group information was lost. Based on test metrics, a compatibility score is generated for each conflict location identifier: S = α × R_s + β × R_f + γ × (1 - D / D_max), where S is the compatibility score, R_s is the conversion power, R_f is the field retention rate, D is the latency increment, D_max is the maximum tolerable latency, and α, β, and γ are weighting coefficients satisfying α + β + γ = 1. A typical configuration is α = 0.3, β = 0.5, and γ = 0.2. The compatibility score and detailed test data are integrated into a compatibility assessment result. The compatibility assessment result includes conflict location identifiers, compatibility scores, test metrics, and improvement suggestions, providing a quantitative basis for the formulation of protocol conversion rules.

[0059] Based on the compatibility assessment results, protocol conversion rules are set to form conflict resolution nodes. The compatibility assessment results are analyzed, compatibility score data is extracted, and conflict location markers with low compatibility scores (below 0.7) are identified. These locations require specific protocol conversion rules. For conflicts with missing fields identified in the compatibility assessment results, field completion rules are set to add extended fields to the destination protocol to carry unique information from the source protocol. For semantic conflicts identified in the compatibility assessment results, field mapping rules are set to define the semantic conversion relationship from source protocol fields to destination protocol fields. Addressing the issue of missing group identifier fields in the compatibility assessment results, a conversion rule is set: an X-Group-ID field is added to the custom header of the SIP protocol to carry group identifier information for the cluster communication protocol. All protocol conversion rules are configured in the protocol conversion module of the group communication nodes, using XML-formatted rule description files. A conflict resolution mechanism is enabled on the group communication nodes; when a protocol interaction corresponding to a conflict location marker is detected, the corresponding conversion rule is automatically applied. Nodes with configured protocol conversion rules and enabled conflict resolution mechanisms are identified as conflict resolution nodes. The conflict resolution node has the ability to automatically identify protocol conflicts, apply conversion rules, and monitor conversion effects. It records the number of conversion rules configured on each conflict resolution node, the types of conflicts handled, and the resolution success rate. The success rate is calculated by monitoring the field retention rate after conversion in real time, providing reference data for protocol remapping.

[0060] A collaborative routing table is generated based on protocol remapping using conflict resolution nodes. Protocol conversion paths are replanned based on the location and conversion capabilities of these nodes. For data streams requiring protocol conversion, their routing paths are adjusted to pass through conflict resolution nodes. Protocol conversion is performed at the conflict resolution nodes, converting source protocol data to destination protocol data and applying appropriate conversion rules to resolve protocol conflicts. A protocol remapping relationship table is generated, recording the correspondence between source protocol, destination protocol, conversion node, and conversion rules. This table is stored using a relational database structure. Based on the protocol remapping relationship, the routing information in the multipath transmission scheme is updated, replacing existing direct routes with indirect routes passing through conflict resolution nodes. A collaborative routing table is constructed, containing fields such as source address, destination address, source protocol, destination protocol, routing path, and conflict resolution node. The collaborative routing table supports data interoperability between heterogeneous protocol networks, ensuring seamless communication between nodes of different protocol types. The collaborative routing table is deployed on the edge gateway, which performs packet forwarding and protocol conversion scheduling based on the routing table, using a minimum latency priority strategy in the scheduling algorithm. A dynamic update mechanism for the collaborative routing table is configured, with an update cycle set to 30 seconds. The routing table content is automatically updated when network topology changes or protocol conversion rules are adjusted. Through the collaborative routing table, protocol and routing coordination between trunked communication, satellite communication, ad hoc network communication, and mobile communication is achieved, enabling various terminal devices at the emergency command site to interconnect across protocol differences.

[0061] Step S140: Based on the cooperative routing table, perform remote relay side channel reverse extraction to form a reverse channel graph. Perform distributed self-organizing side routing compensation processing on the reverse channel graph to generate a routing compensation matrix. Use the routing compensation matrix to perform priority inversion identification to form a routing priority inversion table. Use the routing priority inversion table to perform transmission fault tolerance configuration and build a converged communication state.

[0062] Specifically, a reverse channel graph is formed by performing reverse channel extraction on the remote relay side based on the cooperative routing table. All routing records involving remote relay links are read from the cooperative routing table, and the source address, destination address, and routing path information are extracted from these records to identify links belonging to the remote relay side, i.e., links accessed via satellite links or backbone networks. Based on the routing path information in the cooperative routing table, a reverse extraction operation is performed, extracting uplink channel information from the field terminal to the remote command center in the reverse direction of the data transmission path. Uplink channel information includes attributes such as channel identifier, channel capacity, current load, and available bandwidth. Channel capacity is typically expressed in Mbps, and current load is expressed as a percentage. In emergency rescue scenarios, video data collected by drones needs to be uploaded to the command center via satellite links. Reverse extraction obtains the real-time status information of this uplink channel, including a channel capacity of 10 Mbps and a current load rate of 75%. A reverse channel topology is established, organizing all remote relay side uplink channels into a graph structure. Nodes in the graph represent network devices (such as satellite ground stations, gateways, and routers), and edges represent reverse channels, with edge attributes including channel capacity and load status. The constructed graph structure is used as a reverse channel graph, which reflects the data backhaul channels from the field to the remote command center and their load distribution, providing a topological basis for subsequent routing compensation processing.

[0063] A routing compensation matrix is ​​generated by performing distributed self-organizing side routing compensation processing on the reverse channel graph. The load status of each channel in the reverse channel graph is analyzed, and the current load value of each channel is extracted from the graph to identify channels with high load (over 70%) or near saturation (over 90%). For reverse channels with high load in the reverse channel graph, backup routing paths on the distributed self-organizing side are found. These backup paths can share some uplink traffic. In disaster relief, when satellite links become congested due to traffic surges, some uplink data can first be transmitted to nearby mobile base stations via the self-organizing network link, and then forwarded by the base stations to the command center. A correspondence between reverse channels and backup routes is established. For each channel in the reverse channel graph, the available backup route identifier and the available capacity of the backup route are recorded. The routing compensation capability is evaluated by comparing the total available capacity of the backup routes with the capacity of the primary reverse channel to determine the traffic sharing ratio that the backup routes can bear. The sharing ratio is calculated using the formula: R_comp = C_backup / C_main, where R_comp is the compensation capability ratio, C_backup is the total capacity of the backup routes, and C_main is the capacity of the primary channel. All reverse channels and their corresponding backup routes are organized into a matrix. Rows in the matrix correspond to reverse channels, columns to backup routes, and matrix elements represent the compensation capability of the backup route for that reverse channel. Simultaneously, the current load value of each reverse channel is recorded in the routing compensation matrix, reflecting the channel's traffic occupancy rate. The generated matrix is ​​the routing compensation matrix, which provides the basis for routing resource allocation for priority inversion identification.

[0064] In some embodiments, the step of using the routing compensation matrix to perform priority inversion identification to form a routing priority inversion table includes: extracting routing load values ​​from the routing compensation matrix to generate a load distribution sequence; identifying congestion threshold points in the load distribution sequence to form congestion determination conditions; performing routing priority inversion judgment based on the congestion determination conditions to obtain an inversion trigger identifier; and establishing a priority mapping relationship based on the inversion trigger identifier to form a routing priority inversion table.

[0065] The routing load values ​​in the routing compensation matrix are extracted to generate a load distribution sequence. Each row of the routing compensation matrix is ​​traversed, corresponding to a reverse channel, and the current load information of that channel is extracted from the row element. The routing load value reflects the channel's traffic occupancy rate, ranging from 0 to 1, where 0 represents idle and 1 represents full load. Load values ​​are obtained through a real-time monitoring mechanism, which samples channel traffic statistics every second, including used bandwidth and total bandwidth capacity; the ratio of these two is the load value. For each reverse channel in the routing compensation matrix, its real-time monitoring data is queried to obtain the load value at the current moment. The load values ​​of all reverse channels are arranged in order of channel identifier, forming a one-dimensional load value sequence. The order of the one-dimensional sequence is consistent with the row order of the routing compensation matrix for easy lookup of subsequent correspondences. The load value sequence is extended along the time dimension by collecting load values ​​at multiple consecutive time points, forming two-dimensional time-series load data. The time window for the time-series load data is typically set to 5 to 10 minutes, with a sampling interval of 1 second, resulting in a load change record containing 300 to 600 time points. Time series analysis was performed on the time-series load data to extract the trend of load values ​​over time. The trend included four modes: rising, falling, fluctuating, and stable. An rising trend indicates increasing traffic demand, while a falling trend indicates decreasing traffic demand. During the on-site support of large-scale events, as the event progressed, the video livestream traffic gradually increased, and the load value of the satellite uplink channel rose from 0.3 to 0.85. The load distribution sequence recorded this change. The load values ​​of all reverse channels at each time point were integrated into a load distribution sequence, which includes data in three dimensions: channel identifier, timestamp, and load value.

[0066] Congestion thresholds are identified in the load distribution sequence to form congestion determination criteria. The statistical characteristics of load values ​​in the load distribution sequence are analyzed to obtain statistics such as the mean, variance, and quantiles of the load values. A congestion threshold is set, typically using the high quantile of the load value as the congestion threshold. When the load value in the load distribution sequence exceeds the threshold, the channel is determined to be in a congested state. Commonly used congestion thresholds are set to the 75th or 80th quantile, indicating that congestion determination is triggered when the load value exceeds most historical records. The congestion threshold is set based on network performance test results. Tests determine at what load level the channel latency and packet loss rate significantly increase; typically, when the load exceeds 0.7, end-to-end latency begins to rise significantly. The congestion threshold, reasonable waiting time reference value, and threshold determination rules are integrated into the congestion determination criteria. The congestion determination criteria include threshold parameters (e.g., 0.7 or 0.75), reasonable waiting time reference values ​​(set according to service type, e.g., 30 seconds or 60 seconds), and determination rules, used to determine whether the channel is in a congested state and to provide a reference for priority inversion. The congestion determination criteria provide a quantitative standard for subsequent route priority reversal judgments.

[0067] For example, the step of determining route priority reversal based on the congestion determination condition to obtain the reversal trigger identifier includes: collecting the waiting time of low-priority routes of the current routing node and comparing it with the congestion determination condition to generate a waiting time deviation value; identifying low-priority routes that exceed the limit based on the waiting time deviation value to form a blocked route set; calculating the proportion of routes in the blocked route set to generate a congestion severity index; and determining whether the reversal threshold has been reached based on the congestion severity index to generate a reversal trigger identifier.

[0068] The system collects the low-priority route waiting time of the current routing node and compares it with congestion judgment conditions to generate a waiting time deviation value. A monitoring mechanism is deployed on each routing node to monitor the status of the packet queue in real time. Low-priority packets in the queue are identified, and the enqueue time of each low-priority packet is recorded. The waiting time of the low-priority packet is obtained by the difference between the current time and the enqueue time. A reference value for a reasonable waiting time is extracted from the congestion judgment conditions. This reference value is set according to the service type and QoS requirements; different waiting time reference values ​​are defined for different service types in the congestion judgment conditions. For each low-priority packet, its waiting time deviation value is defined as: D_wait = T_wait - T_ref, where D_wait is the waiting time deviation value, T_wait is the actual waiting time, and T_ref is the reference waiting time (obtained from the congestion judgment conditions). A positive waiting time deviation value indicates that the waiting time exceeds a reasonable range; the larger the value, the more severe the timeout. The waiting time deviation values ​​of all low-priority packets are collected, and a correspondence between the deviation value and the packet identifier is established. In disaster area communications, daily status reports are considered low-priority data, with a reference waiting time (obtained from congestion judgment conditions) of 30 seconds. However, the actual waiting time has reached 2 minutes, with a waiting time deviation of 90 seconds, indicating that the waiting time of this data packet has seriously exceeded the standard.

[0069] A set of congested routes is formed by identifying low-priority routes that exceed the limit based on their wait time deviation values. A wait time deviation threshold is set, determined according to the QoS requirements of the service type. For log data and status reports with low real-time requirements, the deviation threshold can be set to 60 seconds; for monitoring data and work instructions requiring timely processing, the deviation threshold should be set to 30 seconds. When the wait time deviation value exceeds this threshold, the corresponding low-priority route is determined to be an over-limit route. The wait time deviation values ​​of all low-priority data packets are traversed, and data packets with deviation values ​​exceeding the threshold are filtered out. The routing information corresponding to these over-limit data packets is extracted, including the source node, destination node, and routing path. Routing information extraction is accomplished by querying the routing table, finding the corresponding routing entry based on the source and destination addresses of the data packets. All over-limit low-priority routes are collected to form a set of congested routes. Each route in the congested route set faces the problem of prolonged congestion, requiring priority inversion or route reselection to alleviate it. Low-priority services such as non-urgent messages from field commanders and requests for replenishment of logistical supplies, which have not been transmitted for extended periods due to satellite link congestion, are included in the congested route set.

[0070] A congestion severity metric is generated by statistically analyzing the percentage of routes in the congested route set. The total number of low-priority routes on the current routing node is obtained, including both normally transmitting and congested routes. The absolute number of congested routes is calculated from the total number of routes in the congested route set. The congestion severity metric is defined as the ratio of the number of congested routes to the total number of low-priority routes: I_block = N_blocked / N_total, where I_block is the congestion severity metric, N_blocked is the number of congested routes, and N_total is the total number of low-priority routes. The congestion severity metric ranges from 0 to 1; a value closer to 1 indicates a more severe congestion situation, with low-priority routes being significantly affected. The congestion severity metric is associated with the routing node identifier to record the congestion severity of each node. For example, if 60% of the low-priority routes of a certain ad hoc network node at the rescue site are congested, the congestion severity metric is 0.6, indicating that the low-priority service transmission of this node faces severe difficulties.

[0071] Based on the congestion severity metric, a priority reversal trigger flag is generated to determine whether the reversal threshold has been reached. A congestion severity reversal threshold is set, typically 0.5 or 0.6, indicating that priority reversal is triggered when more than half of the low-priority routes are congested. The congestion severity metric for each routing node is compared with the reversal threshold; when the metric value exceeds the threshold, it is determined that the node needs to trigger priority reversal. For nodes requiring reversal, a reversal trigger flag is generated, containing the node identifier, trigger time, congestion severity metric value, and the number of routes requiring reversal. All generated reversal trigger flags are recorded to form a reversal trigger event sequence. The reversal trigger flag serves as the activation signal for the priority reversal mechanism, notifying the routing scheduling mechanism to prioritize low-priority routes on the specified node. Through the reversal trigger flag, the edge gateway can respond promptly to congestion issues of low-priority routes, preventing data starvation and improving network fairness.

[0072] A routing priority reversal table is formed by establishing priority mapping relationships based on reversal trigger identifiers. For each reversal trigger identifier, the low-priority data packets or data flows that need priority reversal are identified. A mapping relationship between the original priority and the reversed priority is established, temporarily promoting the original low priority (priority value 3 or 4) to medium priority (priority value 2) or high priority (priority value 1). The duration and termination conditions of priority reversal are set. The reversal duration is dynamically adjusted according to congestion relief, usually set to 1 to 5 minutes, and the reversal terminates when congestion is relieved or the low-priority data packets are successfully transmitted. Necessary information of the priority mapping relationship is recorded, including the original priority, the reversed priority, the reversal start time, and the termination conditions. All priority mapping relationships are organized into a table structure to form the routing priority reversal table. The routing priority reversal table contains fields such as channel identifier, data flow identifier, original priority, reversed priority, and reversal status. In emergency rescue sites, environmental monitoring data that was originally low priority but has not been transmitted for a long time is temporarily promoted from priority 3 to priority 2 by the routing priority reversal table to ensure that the data is not lost.

[0073] In some embodiments, the step of constructing a converged communication state by using the routing priority inversion table for transmission fault tolerance configuration includes: extracting the inversion trigger frequency from the routing priority inversion table to generate an inversion frequency distribution; inferring the link stability level based on the inversion frequency distribution to form a fault tolerance requirement table; configuring forward error correction coding parameters for the fault tolerance requirement table to obtain the transmission fault tolerance configuration; and performing communication link deployment verification on the transmission fault tolerance configuration to generate a converged communication state.

[0074] Extract the reversal trigger frequency from the routing priority reversal table to generate a reversal frequency distribution. Traverse all records in the routing priority reversal table and count the number of times each channel triggers a priority reversal within the observation time window (usually 1 or 2 hours). The reversal trigger frequency reflects the frequency of channel congestion; a higher frequency indicates that the channel is frequently congested. Group the reversal trigger frequency according to channel identifier, extract the reversal event record for each channel from the routing priority reversal table, and obtain the reversal frequency value for each channel. Organize the reversal frequencies of all channels into a distribution form and analyze the statistical characteristics of the reversal frequencies, including the maximum, minimum, mean, and standard deviation. Identify channels with high reversal frequencies; these channels are hotspots of network congestion. During emergency command, the satellite uplink channel triggered 8 priority reversals within 1 hour, while the ad hoc network link only triggered 1, reflecting that the load pressure on the satellite link was much higher than that on the ad hoc network link. Associate the reversal frequency with channel identifier, time window, and network layer to form a reversal frequency distribution. The reversal frequency distribution includes fields such as channel identifier, reversal frequency, observation duration, and reversal frequency (times / hour).

[0075] A fault tolerance requirement table is generated by inferring link stability levels based on the inversion frequency distribution. The inversion frequency of each channel in the inversion frequency distribution is analyzed, and the channels are divided into three levels according to the inversion frequency: high frequency (≥5 times / hour), medium frequency (2-4 times / hour), and low frequency (<2 times / hour). High-frequency inversion channels indicate poor link stability, with frequent congestion and transmission fluctuations; low-frequency inversion channels indicate good link stability, with infrequent congestion. The link stability level is inferred from the inversion frequency level, with high-frequency inversion corresponding to low stability and low-frequency inversion corresponding to high stability. Different stability levels of links have different fault tolerance requirements; low-stability links require stronger fault tolerance protection. A mapping relationship between stability level and fault tolerance requirements is established. Low-stability links require high-redundancy error correction coding (e.g., coding rate 0.75-0.85), while high-stability links can be configured with low-redundancy error correction coding (e.g., coding rate 0.9-0.95). The stability level and corresponding fault tolerance requirements of each link are recorded to form a fault tolerance requirement table. The fault tolerance requirements table includes fields such as link identifier, stability level, recommended error correction coding type, and coding redundancy. In disaster relief communications, satellite links that are frequently congested are marked as having a low stability level, and the fault tolerance requirements table recommends configuring RS(255,223) error correction coding for them to provide strong fault tolerance capabilities.

[0076] To obtain the transmission fault tolerance configuration, configure forward error correction coding parameters according to the fault tolerance requirement table. Read the recommended error correction coding type and coding redundancy for each link in the fault tolerance requirement table. Select a suitable forward error correction coding algorithm; commonly used algorithms include Reed-Solomon codes, convolutional codes, and LDPC codes. Determine the coding parameters based on the stability level of the links in the fault tolerance requirement table. For low-stability links, set higher error correction capability and coding redundancy. Coding redundancy is represented by the coding rate: r = k / n, where r is the coding rate, k is the number of information bits (actual data bits), and n is the total number of bits after coding (data bits + parity bits). A lower coding rate indicates higher redundancy and stronger error correction capability. Configure specific coding parameters for each link in the fault tolerance requirement table, including coding algorithm, coding rate, interleaving depth, and number of parity bits. Associate the configured coding parameters with the link identifier to form the transmission fault tolerance configuration. The transmission fault tolerance configuration includes fields such as link identifier, coding algorithm, coding rate, interleaving parameters, and error correction capability. The satellite link is configured with RS(255,223) encoding according to the fault tolerance requirements table, with a encoding rate of 0.875, which can correct up to 16 symbol errors and provide reliable protection for unstable transmission environments.

[0077] The transmission fault-tolerant configuration is deployed and verified on communication links to generate a converged communication state. The transmission fault-tolerant configuration is deployed to the actual communication links, enabling forward error correction coding at the sending end and error correction decoding at the receiving end. After deployment, link performance testing is performed, sending test data packets and monitoring the bit error rate and packet loss rate at the receiving end. The test data packets contain known check sequences, and the error correction effect of the transmission fault-tolerant configuration is verified by comparing the received data with the original data. Performance metrics of the link after deployment are recorded, including bit error rate, packet loss rate, transmission latency, and throughput. The changes in performance metrics before and after deployment are compared to verify whether the transmission fault-tolerant configuration effectively improves transmission reliability. When the link's bit error rate decreases from 10^-4 to below 10^-6 and the packet loss rate decreases from 5% to below 0.1%, the link is considered to have entered a stable transmission state. The deployment verification results of all links are summarized to identify which links have achieved stable and reliable transmission and which links still require further optimization. For links that have achieved stable transmission, their communication state is marked as converged, indicating that the transmission quality of this link meets business requirements. The convergence status information of all links is integrated to form the convergence communication status. The convergence communication status includes fields such as link identifier, bit error rate, packet loss rate, error correction coding effect, and convergence judgment result. The multi-network converged communication of the outdoor space station confirms through the convergence communication status that satellite links, ad hoc network links, and mobile base station links have all achieved stable and reliable data transmission.

[0078] Step S150: Determine the converged communication domain based on the converged communication state, and convert the collaborative routing table into a multi-network converged communication deployment scheme according to the converged communication domain.

[0079] Specifically, converged communication domains are determined based on converged communication states. Convergence determination results for all links are extracted from the converged communication states to identify which links have achieved stable and reliable transmission. For links determined to be in a converged state, key performance parameters, including bit error rate, packet loss rate, transmission latency, and throughput, are extracted from the converged communication states. The network hierarchy affiliation of these links is analyzed to identify the network type to which the links belong, including satellite networks, ad hoc networks, and mobile base station networks. Links with similar performance parameters and related network hierarchies are grouped, with links having similar transmission characteristics and service capabilities grouped together. In emergency rescue scenarios, all connections using satellite links with a bit error rate below 10^-6 are grouped together to form a satellite communication domain; all connections using ad hoc network links with a latency below 50 milliseconds are grouped together to form an ad hoc communication domain. Boundary definitions for communication domains are established, determined jointly by the link performance thresholds and network hierarchy. A unique domain identifier is assigned to each communication domain, recording the list of links and network address range contained within that domain. The interconnection requirements between various communication domains are analyzed to determine the location of gateway nodes and inter-domain communication rules. Gateway nodes are responsible for protocol conversion and data forwarding between different communication domains. All the divided communication domains are then integrated to form a converged communication domain. The converged communication domain contains multiple subdomains, each corresponding to a network type or transmission characteristic. Interconnection between subdomains is achieved through gateway nodes.

[0080] The collaborative routing table is converted into a multi-network converged communication deployment scheme based on the converged communication domain. Definition information of the communication domain is extracted from the converged communication domain, including domain identifier, domain type, link list, network address range, and domain boundary conditions. All routing records in the collaborative routing table are read, and the routing records are labeled with domains according to the converged communication domain to identify the communication domains traversed by each route. For cross-domain routes, the sequence of domains they cross and the inter-domain handover points are labeled, and protocol conversion rules and routing forwarding rules are configured at the handover points. Protocol conversion rules are set based on conflict resolution nodes, and routing forwarding rules are determined based on inter-domain interoperability rules. The collaborative routing table is reorganized, grouped by communication domain, with intra-domain routes grouped together and cross-domain routes labeled separately. Communication configuration parameters are generated, including domain configuration, routing configuration, protocol conversion, and priority configuration. Domain configuration defines the network address range, gateway location, and interoperability rules for each communication domain. Routing configuration defines the forwarding rules for intra-domain and cross-domain routes. Protocol conversion parameters define the rules and node locations for inter-domain protocol conversion. Priority configuration defines the transmission priorities for different service types. The configuration parameters are organized in a standard format and encoded using JSON to form a multi-network converged communication deployment solution. This solution includes complete information such as converged communication domain definitions, routing configurations, protocol conversion rules, priority policies, and fault tolerance configurations, providing plug-and-play communication assurance for emergency command and supporting the collaborative operation of satellite communication, ad hoc network communication, and mobile communication.

[0081] To implement the multi-source heterogeneous network fusion communication method for emergency command scenarios corresponding to the above method embodiments, and to achieve the corresponding functions and technical effects. See also Figure 2 , Figure 2 This diagram illustrates a structural block diagram of a multi-source heterogeneous network converged communication system 200 for emergency command scenarios, provided in an embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown. The multi-source heterogeneous network converged communication system 200 for emergency command scenarios provided in this embodiment includes:

[0082] Data acquisition module 201 is used to acquire remote relay link data, distributed self-organizing link data, and mobile access link data; perform protocol parsing to identify protocol feature identifiers on the remote relay link data; and perform cross-network mapping between the distributed self-organizing link data and the mobile access link data based on the protocol feature identifiers to generate a unified access table.

[0083] Link analysis module 202 is used to perform link complementarity analysis using the unified access table to generate a complementary relationship graph, extract strongly complementary link pairs from the complementary relationship graph to generate complementary scheduling parameters, and use the complementary scheduling parameters to perform complementary combinations to form a multi-path transmission scheme;

[0084] Protocol conversion module 203 is used to identify group communication nodes based on the multipath transmission scheme, establish a protocol conversion channel between the group communication nodes and real-time service nodes, perform protocol conflict detection on the protocol conversion channel to identify conflict resolution nodes, and generate a cooperative routing table based on the conflict resolution nodes;

[0085] The routing optimization module 204 is used to perform remote relay side channel reverse extraction based on the cooperative routing table to form a reverse channel graph, perform distributed self-organizing side routing compensation processing on the reverse channel graph to generate a routing compensation matrix, use the routing compensation matrix to perform priority inversion identification to form a routing priority inversion table, and use the routing priority inversion table to perform transmission fault tolerance configuration to build a converged communication state;

[0086] The configuration generation module 205 is used to determine the converged communication domain based on the converged communication state, and convert the collaborative routing table into a multi-network converged communication deployment scheme according to the converged communication domain.

[0087] The multi-source heterogeneous network converged communication system 200 in the above-described emergency command scenario can implement the multi-source heterogeneous network converged communication method in the emergency command scenario described in the above method embodiments. The options in the above method embodiments are also applicable to this embodiment, and will not be detailed here. The remaining content of this application embodiment can be referred to the content of the above method embodiments, and will not be repeated in this embodiment.

[0088] The purpose of the above embodiments is to reproduce and derive the technical solution of the present invention by way of example, and to fully describe the technical solution, purpose and effect of the present invention. The purpose is to enable the public to have a more thorough and comprehensive understanding of the disclosure of the present invention, and not to limit the scope of protection of the present invention.

[0089] The above embodiments are not an exhaustive list based on the present invention, and there may be many other embodiments not listed. Any substitutions and improvements made without departing from the concept of the present invention are within the protection scope of the present invention.

Claims

1. A method for multi-source heterogeneous network fusion communication in an emergency command scene, characterized in that comprising: acquiring remote relay link data, distributed self-organizing link data and mobile access link data, performing protocol analysis on the remote relay link data to identify protocol feature identifiers, performing cross-network mapping on the distributed self-organizing link data and the mobile access link data based on the protocol feature identifiers to generate a unified access table; performing link complementarity analysis on the unified access table to generate a complementary relationship graph, extracting strong complementary link pairs from the complementary relationship graph to generate complementary scheduling parameters, and performing complementary combination using the complementary scheduling parameters to form a multi-path transmission scheme; identifying group communication nodes based on the multi-path transmission scheme, establishing a protocol conversion channel between the group communication nodes and real-time service nodes, performing protocol conflict detection on the protocol conversion channel to identify conflict resolution nodes, and performing protocol remapping based on the conflict resolution nodes to generate a cooperative routing table; performing remote relay side channel reverse extraction based on the cooperative routing table to form a reverse channel graph, performing distributed self-organizing side routing compensation processing on the reverse channel graph to generate a routing compensation matrix, performing priority inversion identification using the routing compensation matrix to form a routing priority inversion table, and using the routing priority inversion table to perform transmission fault tolerance configuration to build a converged communication state; determining a fusion communication domain based on the converged communication state, and converting the cooperative routing table into a multi-network fusion communication deployment scheme according to the fusion communication domain.

2. The method of claim 1, wherein The protocol feature identifiers are extracted to form a protocol classification table. The protocol classification table is used to perform protocol matching on the distributed self-organizing link data and the mobile access link data to generate a matching relationship matrix. Cross-network address translation is performed based on the matching relationship matrix to obtain an address mapping set. The address mapping set is integrated into a unified access table. The complementary relationship graph is subjected to link characteristic decomposition to generate link characteristic vectors.

3. The method of claim 1, wherein The complementarity degrees between the link characteristic vectors are calculated to form a complementarity degree matrix. The link combination corresponding to the maximum complementarity degree is selected from the complementarity degree matrix as a strong complementary link pair. Complementary scheduling parameters are generated based on the characteristic differences of the strong complementary link pair. The complementary scheduling parameters are analyzed to form a feature matching table. Based on the feature matching table, complementary link groups are generated by grouping link complementarity.

4. The method of claim 1, wherein Traffic flow weights are assigned to the complementary link groups to obtain a flow distribution strategy. The flow distribution strategy is associated with the complementary link groups to form a multi-path transmission scheme. Protocol interaction sequences in the protocol conversion channel are collected to form protocol behavior records. Protocol inconsistency points in the protocol behavior records are analyzed to generate conflict location identifiers. ​ 5. The method of claim 1, wherein ​ ​ ​ The protocol compatibility test is performed on the conflict position identifier to obtain a compatibility evaluation result; A protocol conversion rule is set according to the compatibility evaluation result to form a conflict resolution node.

6. The method of claim 1, wherein The priority inversion identification is performed by using the routing compensation matrix to form a routing priority inversion table, including: A routing load value in the routing compensation matrix is extracted to generate a load distribution sequence; A congestion threshold point in the load distribution sequence is identified to form a congestion determination condition; Routing priority inversion judgment is performed based on the congestion determination condition to obtain an inversion trigger identifier; A priority mapping relationship is established according to the inversion trigger identifier to form a routing priority inversion table.

7. The method of claim 1, wherein The transmission fault tolerance configuration is performed by using the routing priority inversion table to build a converged communication state, including: An inversion trigger frequency in the routing priority inversion table is extracted to generate an inversion frequency distribution; A link stability level is inferred according to the inversion frequency distribution to form a fault tolerance demand table; Forward error correction coding parameters are configured for the fault tolerance demand table to obtain transmission fault tolerance configuration; The transmission fault tolerance configuration is verified by communication link deployment to generate a converged communication state.

8. The method of claim 3, wherein The strong complementary link pair is selected from the complementarity matrix as the link combination corresponding to the maximum complementarity, including: All elements in the complementarity matrix are traversed to identify local maximum points; The corresponding link index pair is determined at the local maximum point to form a candidate link set; A fluctuation difference degree of each link pair in the candidate link set is evaluated to generate a complementary fluctuation parameter; The link combination with the largest fluctuation characteristic difference is selected as the strong complementary link pair according to the complementary fluctuation parameter.

9. The method of claim 6, wherein The inversion trigger identifier is obtained by performing routing priority inversion judgment based on the congestion determination condition, including: A low-priority routing waiting time of a current routing node is collected and compared with the congestion determination condition to generate a waiting time deviation value; A blocked routing set is formed by identifying the low-priority routing that exceeds the limit based on the waiting time deviation value; A blocking severity index is generated by counting the proportion of the number of routings in the blocked routing set; Whether the inversion threshold is reached is determined according to the blocking severity index to generate the inversion trigger identifier.

10. A multi-source heterogeneous network fusion communication system in an emergency command scene, characterized in that Including: A data acquisition module is configured to acquire remote relay link data, distributed self-organizing link data and mobile access link data, perform protocol analysis on the remote relay link data to identify protocol feature identifiers, and perform cross-network mapping on the distributed self-organizing link data and the mobile access link data based on the protocol feature identifiers to generate a unified access table; A link analysis module is configured to perform link complementarity analysis on the unified access table to generate a complementary relationship graph, extract a strong complementary link pair from the complementary relationship graph to generate a complementary scheduling parameter, and perform complementary combination by using the complementary scheduling parameter to form a multi-path transmission scheme; A protocol conversion module is configured to identify group communication nodes based on the multi-path transmission scheme, establish a protocol conversion channel between the group communication nodes and real-time service nodes, perform protocol conflict detection on the protocol conversion channel to identify a conflict resolution node, and perform protocol remapping based on the conflict resolution node to generate a cooperative routing table. The routing optimization module is configured to perform remote relay side channel reverse extraction based on the cooperative routing table to form a reverse channel graph, perform distributed ad hoc side routing compensation processing on the reverse channel graph to generate a routing compensation matrix, perform priority inversion identification using the routing compensation matrix to form a routing priority inversion table, and perform transmission fault tolerance configuration using the routing priority inversion table to build a converged communication state. The configuration generation module is configured to determine a converged communication domain based on the converged communication state, and convert the cooperative routing table into a multi-network converged communication deployment scheme according to the converged communication domain.

Images