Multi-stage pre-attack coordinated emergency communication guarantee method in complex environment

Abstract

The application provides a multi-level front-protruding cooperative emergency communication guarantee method in a complex environment, comprising: in view of the problem of insufficient key service session continuity in the link switching process of the existing multi-link emergency communication scheme, reading the node basic information, link quality parameters, baseband communication state parameters, edge network access parameters and service flow records in the multi-level front-protruding cooperative emergency communication network, generating a network topology state table and a key service session table; identifying the current service node and generating a shadow replacement table; splitting the key service session into transferable session fragments and non-transferable root authentication fragments, establishing a shadow session warehouse and a replacement preparation state table; when the replacement trigger condition is met, selecting a target replacement node and performing a restricted inheritance check to complete the service bearer relationship switching of the key service session; then following the key service session, migrating the non-key video subject service and generating a closed-loop update data set.

Description

Technical Field

[0001] This invention relates to the field of wireless communication network technology, and in particular to a multi-level forward-deployed emergency communication support method in complex environments. Background Technology

[0002] Emergency response demands high continuity and reliability in communication support. Existing emergency communication systems typically use vehicle-mounted satellite links as the primary backhaul channel, combined with portable satellite terminals, mesh self-organizing network links, UAV relay links, and individual terminals for forward assault teams, to construct a multi-level collaborative communication network consisting of vehicle-mounted command nodes, forward assault nodes, relay nodes, and rear command nodes. This type of solution addresses, to some extent, the problems of insufficient coverage and terrain obstruction.

[0003] However, existing technologies mostly focus on link establishment, signal coverage, bandwidth expansion, and relay coverage, typically judging communication status based on link connectivity, signal strength, and path reachability. When a node continuously moves between vehicle-mounted satellite links, portable satellite links, Mesh ad hoc network links, and UAV relay links, the network frequently experiences access switching and forwarding path changes. At this time, although a new link may have been established and the terminal may still appear online, the session state, buffer window, forwarding sequence number, and authentication association information relied upon by the original service session will not automatically continue with the link switch. This can easily lead to interruptions or mismatches in command and control services, location backhaul services, voice dispatch services, and critical video indexing services during the switching process.

[0004] Therefore, this invention proposes a multi-level forward-deployed collaborative emergency communication support method for complex environments. The information disclosed in the background section is only for enhancing understanding of the background of this disclosure and may therefore contain prior art information that is not common knowledge to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a multi-level forward-deployed emergency communication support method in complex environments, thereby solving the technical problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A multi-level forward-deployed collaborative emergency communication support method for complex environments includes the following steps: S1. Read the basic information of nodes, link quality parameters, baseband communication status parameters, edge network access parameters and service flow records in the multi-level forward-deployed emergency communication network, and generate a network topology status table and a key service session table; S2. Identify the current service node based on the network topology status table and the key business session table, filter candidate nodes for replacement, and generate a shadow replacement table. S3. Based on the key business session table, the session context is split into transferable session fragments and non-transferable root authentication fragments, and the transferable session fragments are pre-distributed to the successor candidate nodes to generate a shadow session repository and a successor preparation status table. S4. When the current service node meets the succession triggering conditions, select the target succession node according to the succession preparation status table, and perform restricted inheritance verification on the target succession node based on the shadow session repository and non-transferable root authentication fragment. After the verification is passed, switch the business bearer relationship of the key business session and generate the succession result. S5. Based on the handover completion result, continue the critical business session at the target successor node, perform delayed migration, downgraded migration or wait migration for non-critical video main business, update the shadow successor table, write back the results of this round, and generate a closed-loop update dataset.

[0007] S1 specifically includes: reading the node identifier, node type, access link type, backhaul exit identifier, adjacent node identifier, and security domain identifier of the vehicle-mounted command node, forward node, relay node, and rear command node to generate a basic node record set; reading the bit error rate, latency, jitter, packet loss rate, baseband synchronization status, baseband modulation and demodulation status, baseband frame processing load, edge network access layer, edge forwarding hop count, and edge exit stability and performing joint verification to generate a network topology status table; reading the service type, service priority, session number, session status, buffer window, forwarding sequence number, task number, and security authentication status, and combining the network topology status table to identify key service sessions and generate a key service session table.

[0008] S2 specifically includes: based on the current bearer node identifier, session number, task number, and backhaul path in the critical business session table, identifying the current service node with the highest service node score that assumes the current backhaul exit responsibility from the network topology status table; around the current service node, selecting replacement candidate nodes from adjacent nodes, nodes that can establish connections, and nodes with priority connection relationships that have corresponding business bearing capabilities, legal security domain identifiers, available backhaul exits, and meet the replacement adaptation value and edge forwarding hop count requirements, generating a set of replacement candidate nodes; calculating the shadow replacement priority value based on the set of replacement candidate nodes, establishing the shadow replacement relationship between the forward node and the replacement candidate nodes, and generating a shadow replacement table.

[0009] S3 specifically includes: extracting the session context corresponding to the main business flow according to the session number and task number based on the key business session table; dividing the session number, task number, business type, business priority, cache window, forwarding sequence number, short-cycle authentication digest, and state parameters required for continuation into transferable session fragments; dividing the root key material location identifier, root authentication credential location identifier, non-replicable authentication factor identifier, and call constraints into non-transferable root authentication fragments; pre-distributing the transferable session fragments to the succession candidate nodes and establishing a shadow session repository based on the shadow succession table; performing pre-verification based on the shadow session repository and the shadow succession table to generate a succession preparation state table.

[0010] S4 specifically includes: reading the network topology status table, shadow succession table, and succession preparation status table; determining whether the succession triggering conditions are met based on the current service node's link quality evaluation value, edge egress stability, baseband processing load ratio, and obstruction risk indicator; selecting nodes from the succession preparation status table whose pre-verification pass value meets the standard and whose time window covers the service cycle, and generating a target succession node selection result; performing restricted inheritance verification on the target succession node based on the target succession node selection result, the shadow session repository, and the non-transferable root authentication fragment set, and generating an inheritance pass result; switching the service bearer relationship of critical service sessions based on the inheritance pass result and updating the backhaul egress and the current forwarding path, and generating a succession completion result.

[0011] S5 specifically includes: based on the handover completion result and the critical service session table, restoring service priority, session state, cache window, and forwarding sequence number at the target replacement node, and performing continuation of command and control services, location backhaul services, voice dispatch services, and critical video indexes, generating critical service continuation results; based on the critical service continuation results, the shadow replacement table, and the network topology status table, performing delayed migration, downgraded migration, or waiting migration for non-critical video services, and updating the shadow replacement table, generating non-critical service migration results and the updated shadow replacement table; and performing closed-loop write-back based on the handover completion result, critical service continuation results, non-critical service migration results, and the updated shadow replacement table, generating a closed-loop update dataset.

[0012] The beneficial effects of this invention are as follows: This invention constructs a network topology status table, a critical service session table, a shadow succession table, and a shadow session repository, enabling the current service node to complete succession preparation before it becomes unstable. This reduces the probability of critical service session interruption during link switching and improves the continuous guarantee capability of emergency communication in complex environments.

[0013] This invention enables command and control services, location backhaul services, voice dispatch services, and critical video indexing services to be quickly resumed after handover by pre-distributing transferable session fragments before handover triggering and performing restricted inheritance verification at the target handover node, thereby reducing handover latency and service recovery latency.

[0014] This invention combines link quality evaluation value, edge egress stability, baseband processing load ratio, and obstruction risk indicator to determine the succession trigger condition, which can avoid making switching judgments based solely on link connectivity status and improve the accuracy and stability of target succession node selection.

[0015] This invention separates critical services from non-critical video core services, prioritizing the continuous support of critical services while performing delayed migration, downgraded migration, or waiting migration for non-critical video core services, thereby improving the rationality of the allocation of limited support resources.

[0016] This invention generates a closed-loop update dataset and writes it back to the network topology status table and critical service session table, enabling the results of the current switching round to be directly used as input for the next cycle, forming a continuously operating closed-loop protection mechanism, thereby improving the adaptive protection capability of the multi-level forward-deployed emergency communication network in complex environments. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of a multi-level forward-deployed emergency communication support method for complex environments according to the present invention.

[0018] Figure 2 This is a schematic diagram of the overall architecture logic of the emergency communication network according to an embodiment of the present invention; Figure 3 This is a service aggregation and transport topology diagram according to an embodiment of the present invention; Figure 4 This is a logic diagram of service relay and distribution on the vehicle-mounted command node side according to an embodiment of the present invention; Figure 5 This is a diagram of the global situation and session processing architecture on the rear command node side of an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Example: Figure 1 As shown, this embodiment provides a multi-level forward-deployed collaborative emergency communication support method in complex environments, including the following steps: S1. Read the basic information of nodes, link quality parameters, baseband communication status parameters, edge network access parameters and service flow records in the multi-level forward-deployed emergency communication network, and generate a network topology status table and a key service session table; S2. Identify the current service node based on the network topology status table and the key business session table, filter candidate nodes for replacement, and generate a shadow replacement table. S3. Based on the key business session table, the session context is split into transferable session fragments and non-transferable root authentication fragments, and the transferable session fragments are pre-distributed to the successor candidate nodes to generate a shadow session repository and a successor preparation status table. S4. When the current service node meets the succession triggering conditions, select the target succession node according to the succession preparation status table, and perform restricted inheritance verification on the target succession node based on the shadow session repository and non-transferable root authentication fragment. After the verification is passed, switch the business bearer relationship of the key business session and generate the succession result. S5. Based on the handover completion result, continue the critical business session at the target successor node, perform delayed migration, downgraded migration or wait migration for non-critical video main business, update the shadow successor table, write back the results of this round, and generate a closed-loop update dataset.

[0021] S1 specifically includes the following sub-steps: S110. Read the basic object information in the multi-level forward-deployed emergency communication network and generate a node basic record set.

[0022] Specifically, the node identifier, node type, region, access link type, backhaul exit identifier, and security domain identifier for each node are first read from the node registry. The node type is used to distinguish between vehicle-mounted command nodes, forward deployment nodes, relay nodes, and rear command nodes. The access link type is used to distinguish between vehicle-mounted satellite links, portable satellite links, Mesh self-organizing network links, and UAV relay links. The backhaul exit identifier is used to characterize the exit channel through which the node can output service flows to the superior node or rear command node in the current period. The security domain identifier is used to characterize the authentication domain and access range to which the node belongs. Next, the neighboring node identifiers are read from the adjacency discovery results in the most recent sampling period, and the service carrying capacity identifiers are read from the node capability reporting results. The service carrying capacity identifiers include at least command and control carrying capacity, positioning backhaul carrying capacity, voice dispatch carrying capacity, and video backhaul carrying capacity.

[0023] For multiple source records corresponding to the same node, they are sorted from most recent to oldest timestamp, and the record with the latest timestamp and complete fields is retained. Abnormal records with missing node identifiers, conflicting node types, missing access link types, or empty backhaul exit identifiers are deleted. When there is a conflict in the service carrying capacity identifier of the same node, the retention value is determined by the service stack that has been enabled in the current period and the link type that has been confirmed to be available in the current period.

[0024] After merging, a node basic record set is generated. The node basic record set includes at least the node identifier, node type, access link type, backhaul exit identifier, adjacent node identifier, service carrying capacity identifier, and security domain identifier. The node basic record set serves as the input to S120.

[0025] S120: Read the link quality parameters, baseband communication status parameters and edge network access parameters corresponding to the node basic record set, perform joint verification, and generate a network topology status table.

[0026] Specifically, for each node in the node basic record set, its link quality parameters are read, including at least bit error rate, latency, jitter, and packet loss rate; its baseband communication status parameters are read, including at least baseband synchronization status, baseband modulation and demodulation status, baseband frame processing load, and baseband buffer occupancy status; and its edge network access parameters are read, including at least edge network access level, edge forwarding hop count, edge egress stability, and edge coverage continuity.

[0027] Subsequently, the link quality evaluation value is calculated:

[0028] In the formula, This represents the link quality evaluation value; Indicates the bit error rate; Indicates the upper limit of the bit error rate; Indicates time delay; Indicates the upper limit of latency; Indicates shaking; Indicates the maximum jitter level; Indicates packet loss rate; Indicates the upper limit of packet loss rate; , , , These represent the weights corresponding to bit error rate, latency, jitter, and packet loss rate, respectively, and the sum of the four is 1.

[0029] In a typical forest fire prevention and emergency response scenario, the weight values ​​are exemplified as follows: (Bit error rate) = 0.4 (Delay) = 0.2 (Jitter) = 0.1 (Packet loss rate) = 0.3; The preset link hold-up threshold is recommended to be set to 0.65. When If the value is below this, the system determines that the link cannot support critical business operations. , , , Each service type has its own QoS standard upper limit set, such as the latency upper limit for voice dispatch services. Set to 150ms.

[0030] Next, calculate the baseband processing load ratio:

[0031] In the formula, Indicates the baseband processing load ratio; This indicates the actual amount of baseband frames processed within the current sampling period; This indicates the allowed baseband frame processing capacity within the current sampling period.

[0032] Based on the above results, a consistency check is performed: if the baseband synchronization state is abnormal, or the baseband modulation and demodulation state is abnormal, or Below the preset link hold threshold, or If the load exceeds the preset baseband load threshold, or the edge output stability is lower than the preset output retention threshold, the connection relationship corresponding to the node is marked as a restricted connection relationship and is not written into the priority connection relationship field; if a valid connection chain cannot be formed between the node identifier, the adjacent node identifier, and the return output identifier, the record is deleted directly.

[0033] For example, when a certain Mesh self-organizing network link When the preset link retention threshold of 0.58 is lower than 0.65, only the historical association record of that link is retained, and it is not used as the priority forwarding path when identifying the current service node. After verification, the node identifier, node type, access link type, backhaul exit identifier, adjacent node identifier, edge network access layer, edge forwarding hop count, edge exit stability, link quality evaluation value, baseband processing load ratio, priority connection relationship and restricted connection relationship are written into the network topology status table. The network topology status table serves as the input for S130 and S210.

[0034] Specifically, link quality parameters (bit error rate, latency, jitter, and packet loss rate) are obtained by periodically sampling the statistical registers of the baseband processing chips at each node every 50ms-100ms; the baseband frame processing load is calculated by reading the ratio of the real-time task queue length to the maximum queue capacity of the baseband driver interface; the edge egress stability is calculated by weighted averaging the connection duration of the backhaul egress links in the most recent 10 heartbeat cycles; and the occlusion risk indicator is obtained by combining the GPS positioning trajectory of the forward node with a preset digital terrain map for collision prediction.

[0035] S130. Read the service flow records carried by each node in the current period, and identify key service sessions in combination with the network topology status table to generate a key service session table.

[0036] Specifically, first, read the service type, service priority, session number, session status, cache window, forwarding sequence number, task number, and security authentication status from the service flow record; then, based on the priority connection relationship, backhaul exit identifier, edge network access layer, and baseband processing load ratio in the network topology status table, identify the bearer node and corresponding backhaul path that each service flow is currently passing through.

[0037] For each business flow, calculate the key business judgment value:

[0038] In the formula, Indicates key business judgment values; Indicates the business priority level value; Indicates the real-time performance level value; This indicates the impact level on command continuity after a service interruption; the values ​​G, R, and C mentioned above are all pre-normalized to the level based on service attributes. The values ​​within the range. , , These represent the weights corresponding to business priority, real-time performance, and impact level, respectively, and the sum of the three is 1. In a typical emergency communication scenario, the example values ​​are: a=0.4, b=0.3, c=0.3.

[0039] The service priority level value is directly mapped from the service priority field, the real-time level value is determined based on the upper limit of the service's allowable latency, and the impact level value is determined based on whether the service interruption directly affects command and control, location feedback, voice dispatch, or critical video indexing.

[0040] when When the threshold value is greater than or equal to a preset critical business threshold, the business flow is marked as a critical business session; when the same session number corresponds to multiple business flows, it is retained. The largest business flow is designated as the primary business flow, while the remaining business flows are marked as subordinate business flows and maintain the same task number as the primary business flow.

[0041] For example, when a certain location backhaul service When the value is 0.82 and the preset critical business threshold is 0.70, the location backhaul service is written into the critical business session table, and its corresponding bearer node is written into the current bearer node field.

[0042] Finally, the session number, task number, service type, service priority, critical service judgment value, current bearer node identifier, cache window, forwarding sequence number, security authentication status, and associated backhaul path are written into the critical service session table. The critical service session table serves as the input for S220, S310, and S510, enabling subsequent steps to identify the current service node based on the current bearer node identifier and associated backhaul path, and to filter candidate replacement nodes that meet the replacement conditions based on the critical service judgment value and service type.

[0043] S2 specifically includes the following sub-steps: S210. Read the network topology status table, identify the current service node of the critical service session of the current forward node, and generate a set of current service node identifiers. The current service node is the node in the current bearer node set that actually undertakes the responsibility of outputting the current backhaul exit. The current bearer node set is determined based on the current bearer node identifier in the critical service session table and its corresponding backhaul path.

[0044] Specifically, for each forward node, the corresponding main service flow is first extracted from the critical service session table based on the session number and task number. Then, based on the backhaul path of the main service flow, the current bearer node identifier, and the backhaul exit identifier, the set of bearer nodes corresponding to the main service flow is extracted from the network topology status table. When the bearer node set contains only one node, that node is directly identified as the current service node. When the bearer node set contains multiple nodes, a current service node score is calculated for each bearer node.

[0045] In the formula, This indicates the current service node's score. This represents the link quality evaluation value; Indicates the stability of the edge export; Indicates the baseband processing load ratio; , , These represent the weights of the link quality evaluation value, edge egress stability, and baseband processing load ratio in the node scoring model, respectively, and their sum is 1. Under the strategy of prioritizing link stability, the example values ​​are: =0.5, =0.3, =0.2.

[0046] In the calculation, a higher link quality evaluation value indicates a more stable link for that node; a higher edge egress stability indicates a stronger continuous carrying capacity for that node as an edge network egress; and a lower baseband processing load ratio indicates more sufficient remaining baseband communication processing capacity for that node. Therefore, the following approach is adopted. Participate in the calculation.

[0047] Select The largest node is used as the current service node; when two nodes... If the number of edge forwarding hops is the same, the node with the smaller number of edge forwarding hops will be retained first. If the number of edge forwarding hops is also the same, the node with a stable session state will be retained first, and the remaining nodes will be marked as auxiliary bearer nodes and will not be written into the current service node field.

[0048] After the above processing, a current service node identifier set is generated. The current service node identifier set includes at least the forward node identifier, session number, task number, current service node identifier, current return exit identifier, and current service node score value. The current service node identifier set is used as the input of S220.

[0049] S220: Read the current service node identifier set, network topology status table, and key business session table; filter replacement candidate nodes; and generate a set of replacement candidate nodes.

[0050] Specifically, for each current service node, nodes that are adjacent to it, nodes that can be connected to the corresponding forward node, and nodes in the priority connection field are extracted from the network topology status table as the initial candidate node set. Then, each node in the initial candidate node set is compared with the service type, service priority, session status, and task number in the critical service session table to verify whether the node has the corresponding service carrying capacity identifier, legal security domain identifier, available backhaul exit, and baseband processing load ratio that is not exceeded.

[0051] For nodes that pass the basic verification, calculate the succession adaptation value:

[0052] In the formula, Indicates the replacement fit value; This represents the link quality evaluation value; Indicates the stability of the edge export; Indicates the baseband processing load ratio; Indicates the degree of matching between service carrying capacity and actual service requirements; , , , These represent the weights corresponding to the link quality evaluation value, edge egress stability, baseband processing load ratio, and service carrying capacity matching degree in the succession adaptation calculation, respectively, and the sum of the four is 1.

[0053] Replacement fit value An example of weight allocation is as follows: =0.3, =0.3, =0.2, =0.2. The recommended default succession adaptation threshold is 0.75. Only... Only nodes with a value of ≥0.75 are considered to have reliable succession potential.

[0054] The service carrying capacity matching degree is determined as follows: 1 is assigned when a node simultaneously possesses the carrying capacity for the corresponding service type, a valid security domain identifier, and an available backhaul exit; 0 is assigned if any one of these is missing. Only when... A node will be retained as a candidate node for replacement only if its value is greater than or equal to the preset replacement adaptation threshold and the number of edge forwarding hops is not higher than the preset hop limit; otherwise, it will be deleted.

[0055] For example, when a certain drone relay node If the threshold is 0.78, the preset replacement adaptation threshold is 0.72, and the edge forwarding hop count is 2, which is not higher than the preset hop count limit of 3, the drone relay node will be retained as a replacement candidate node. If a forward node fails to find a node that meets the conditions within the current cycle, the restricted connection relationship corresponding to the current service node will be retained as a temporary replacement placeholder relationship, and the forward node will be marked as a node to be added to the replacement relationship to avoid subsequent S310 interruptions.

[0056] After screening, a set of candidate replacement nodes is generated. The set of candidate replacement nodes includes at least the forward node identifier, session number, task number, candidate replacement node identifier, replacement adaptation value, edge forwarding hop count, service carrying capacity matching degree, and security domain matching result. The set of candidate replacement nodes serves as the input to S230 and S320.

[0057] S230. Read the set of succession candidate nodes, establish the shadow succession relationship between the leading node and the succession candidate nodes, and generate the shadow succession table.

[0058] Specifically, for each critical business session corresponding to each forward node, the shadow succession priority value is calculated based on the succession adaptation value, the number of edge forwarding hops, and the coverage of the effective succession time window:

[0059] In the formula, Indicates the priority value for shadow succession; Indicates the replacement fit value; Indicates the number of hops for edge forwarding; Indicates the maximum allowed edge forwarding hops; Indicates the coverage rate of the effective time window for replacement; , , These represent the weights corresponding to the succession adaptation value, edge forwarding hop count, and succession effective time window coverage in the shadow succession priority assessment, respectively, and the sum of the three is 1. Example values ​​are: =0.4, =0.3, =0.3.

[0060] Among them, the effective time window coverage rate of the replacement is used to characterize the proportion of time that the candidate replacement node can maintain the replacement state within the current business cycle. The larger the value, the more suitable the node is as a shadow replacement node. Candidate nodes are arranged from high to low to form a shadow succession chain; at least 2 shadow succession nodes are reserved for each critical business session, and at most 3 shadow succession nodes are reserved. When there are fewer than 2 candidate succession nodes that meet the conditions, the actual number is reserved.

[0061] Subsequently, for each shadow succession relationship, the current service node identifier, succession candidate node identifier, shadow succession priority value, succession priority order, range of business types allowed to be inherited, succession effective time window, and security domain matching result are written. When the succession effective time window of a succession candidate node expires, or its succession adaptation value drops below the preset succession adaptation threshold, or its security domain matching result becomes mismatched, the shadow succession relationship is marked as invalid and deleted.

[0062] After the above processing, a shadow succession table is generated. The shadow succession table serves as the direct input for S320 to establish a shadow session repository and for S410 to select the target successor node.

[0063] S3 specifically includes the following sub-steps: S310. Read the critical business session table, perform field-level splitting on the session context of each critical business session, and generate a set of transferable session fragments and a set of non-transferable root authentication fragments.

[0064] Specifically, the session context corresponding to the main business flow is first extracted from the critical business session table according to the session number and task number. Then, the session number, task number, business type, business priority, cache window, forwarding sequence number, short-cycle authentication digest, and status parameters required for reconnection in the session context are divided into transferable fields, while the root key material location identifier, root authentication credential location identifier, non-replicable authentication factor identifier, and corresponding call constraints are divided into non-transferable fields. Among them, the session number, task number, business type, and short-cycle authentication digest are required fields in the transferable fields. If any one of them is missing, the session context is not allowed to enter the transferable session fragment set.

[0065] To avoid the drift in segmentation caused by relying solely on manual judgment, the completeness of the session fragment is calculated for each session context:

[0066] In the formula, Indicates the completeness of a conversation segment; Indicates the number of required fields that have been successfully retrieved in the current session context; This indicates the total number of preset required fields needed to split a session fragment.

[0067] Only when Only when the time is right will the corresponding session context be written into the transferable session fragment set; when If this occurs, the session number, task number, and missing field type will be written to the session record to be completed, instead of proceeding to the subsequent pre-distribution process.

[0068] After the split is completed, the forward node identifier, current service node identifier, session number, task number, service type, service priority, cache window, forwarding sequence number, short-cycle authentication digest, and state parameters required for reconnection are written into the transferable session fragment set. The session number, task number, root key material location identifier, root authentication credential location identifier, non-replicable authentication factor identifier, and call constraints are written into the non-transferable root authentication fragment set. The transferable session fragment set and the non-transferable root authentication fragment set are used as inputs to S320.

[0069] The specific state parameters required for resuming the connection include: the byte offset of the current TCP / UDP sliding window, the RTP protocol sequence number, the current initialization vector (IV) index of the encrypted stream, and the status flags of the most recent service layer handshake. By pre-distributing these parameters before the takeover, the target takeover node can directly resume data stream transmission from the breakpoint without having to re-perform the three-way handshake or service layer authentication.

[0070] S320: Read the set of transferable session fragments, the set of non-transferable root authentication fragments, the set of succession candidate nodes, and the shadow succession table; perform session fragment pre-distribution and establish a shadow session repository.

[0071] Specifically, pre-distribution is performed only on candidate nodes in the shadow succession table that are marked as not invalid and whose security domain matching results are matched; for candidate nodes whose security domains do not match, whose valid succession time window has expired, or whose nodes have been marked as invalid, no shadow storage unit is established.

[0072] During pre-distribution, the transferable session fragments are sent to the corresponding successor candidate nodes according to the forward node identifier, session number, and task number, and a shadow storage unit is established in the local storage area of ​​the successor candidate node. The shadow storage unit is used to cache the digest of the transferable session fragments, record the location identifier and call constraints of the non-transferable root authentication fragments, and save the timestamp of this repository creation.

[0073] To prevent baseband communication congestion from rendering established shadow storage units unusable, the availability of the shadow session repository is calculated for each shadow storage unit:

[0074] In the formula, Indicates the availability of the shadow session repository; Indicates the completeness of a conversation segment; Indicates the baseband processing load ratio; Indicates the stability of the edge export; This indicates the security domain matching result; it is set to 1 if a match is found and 0 if no match is found. , , , These represent the weights corresponding to session fragment integrity, baseband processing load ratio, edge egress stability, and security domain matching result in the session repository availability calculation, respectively, and the sum of the four is 1. Example values: =0.4, =0.2, =0.2, =0.2; The preset threshold for opening a position is set to 0.75.

[0075] Only if the successor candidate node has received the complete transferable session fragment, recorded the location identifier and invocation constraints of the corresponding non-transferable root authentication fragment, and If the value is greater than or equal to the preset available threshold for warehouse construction, the shadow storage unit is determined to have been successfully established; otherwise, the pre-distributed record corresponding to the candidate node for replacement is deleted.

[0076] For example, when a candidate node for replacement... When the value is 0.81 and the preset threshold for available positions is 0.75, its shadow storage unit is retained; when... When the value is 0.68, delete the shadow storage unit.

[0077] After screening, a shadow session repository is generated. The shadow session repository includes at least the forward node identifier, the successor candidate node identifier, the session number, the task number, the transferable session fragment summary, the non-transferable root authentication fragment location identifier, the call constraint, the repository creation timestamp, the shadow session repository availability and the failure flag. The shadow session repository serves as the input to S330 and the subsequent S420.

[0078] S330: Read the shadow session repository and shadow succession table, perform pre-verification on each shadow succession relationship, and generate a succession preparation status table.

[0079] Specifically, for each shadow succession relationship, first check if there is a shadow storage unit in the shadow session repository corresponding to the shadow succession relationship; if not, mark the shadow succession relationship as invalid. For shadow succession relationships with shadow storage units, further verify whether the session fragment integrity corresponding to the transferable session fragment is equal to 1, whether the non-transferable root authentication fragment location identifier exists, whether the effective succession time window covers the current business cycle, whether the baseband processing load ratio is not higher than the preset succession load threshold, and whether the edge egress stability and edge coverage continuity in the edge network access parameters meet the succession conditions.

[0080] To standardize the pre-verification exit point, a pre-verification pass value is calculated for shadow succession relationships that meet the basic verification conditions:

[0081] In the formula, This indicates a value that passed the pre-validation. Indicates the completeness of a conversation segment; Indicates the coverage rate of the effective time window for replacement; Indicates the availability of the shadow session repository; , , These represent the weights corresponding to session fragment completeness, effective time window coverage, and shadow session repository availability in the pre-verification process, respectively, and the sum of the three is 1. Example values ​​are: =0.4, =0.3, =0.3.

[0082] Only if the non-transferable root authentication fragment location identifier exists and If the value is greater than or equal to the preset pre-verification threshold, the corresponding shadow succession relationship is written into the succession preparation status table; otherwise, the shadow succession relationship is marked as invalid, and the forward node identifier, session number, task number and failure reason are written into the succession relationship record to be rebuilt, so that it can be called when the shadow succession table is updated later.

[0083] Ultimately, the succession preparation status table includes at least the forward node identifier, session number, task number, succession candidate node identifier, pre-verification pass value, succession valid time window, and call status identifier. The succession preparation status table serves as the direct input for S410 to select the target succession node, thereby completing the closed-loop transition from session splitting and shadow warehouse creation to succession preparation.

[0084] S4 specifically includes the following sub-steps: S410. Read the network topology status table, shadow succession table, and succession preparation status table, determine whether the current service node meets the succession triggering conditions, and generate the target successor node selection result when the succession triggering conditions are met.

[0085] Specifically, for each critical service session corresponding to each forward node, the link quality evaluation value, edge egress stability, baseband processing load ratio, and obstruction risk indicator corresponding to the current service node are first read from the network topology status table, and then the succession trigger value is calculated:

[0086] In the formula, Indicates that the trigger value will be replaced; This represents the link quality evaluation value; Indicates the stability of the edge export; Indicates the baseband processing load ratio; This indicates an occlusion risk indicator. It is set to 1 if the current node has entered the occlusion area or will enter the occlusion area within a preset time window according to the current movement direction, and 0 otherwise. , , , These represent the weights of the link quality evaluation value, edge egress stability, baseband processing load ratio, and occlusion risk identifier in the succession trigger determination, respectively, and the sum of the four is 1.

[0087] Replacement trigger value The weighting coefficients should be tilted towards the risk items, for example: (Link instability) = 0.3 (Export instability) = 0.2 (Baseband load) = 0.2 (Occlusion risk) = 0.3. The preset replacement trigger threshold is set to 0.80. Once... If the value is ≥0.80, the system immediately locks the target replacement node and initiates the switching process.

[0088] Since a higher link quality evaluation value and edge egress stability indicate greater stability of the current service node, these values ​​are used in the calculation. and This indicates the degree of instability; a higher baseband processing load ratio indicates a smaller baseband communication processing margin for the current service node, thus directly contributing to risk accumulation.

[0089] when When the threshold value is greater than or equal to the preset succession trigger threshold, the succession trigger condition is determined to be met; when When the threshold is less than the preset failover trigger threshold, the current service node continues to carry out the service, and the failover trigger status corresponding to the current session is marked as not triggered.

[0090] For critical business sessions that meet the failover trigger conditions, all target failover candidate nodes with the same session number and task number are read from the failover preparation status table. Only failover candidate nodes with a pre-verification pass value not lower than the preset pre-verification threshold, a failover effective time window covering the current business cycle, a failure mark of not failing, and a call status mark of callable are retained. If more than one node is retained, the node with the highest failover priority and the largest pre-verification pass value is selected as the target failover node. If the failover priority and pre-verification pass value are the same, the node with the larger remaining amount of the failover effective time window is selected.

[0091] After the above processing, the target replacement node selection result is generated. The target replacement node selection result includes at least the forward node identifier, session number, task number, target replacement node identifier, replacement trigger value, pre-verification pass value, replacement trigger status, and replacement effective time window. The target replacement node selection result is used as the input of S420.

[0092] S420: Read the target successor node selection result, shadow session repository, and non-transferable root authentication fragment set; perform restricted inheritance verification on the target successor node; and generate inheritance pass result.

[0093] Specifically, when the succession trigger status in the target successor node selection result is triggered, the shadow storage unit that matches the target successor node identifier, session number, and task number is retrieved from the shadow session repository, and the root key material location identifier, root authentication credential location identifier, non-replicable authentication factor identifier, and call constraint corresponding to the session number and task number are retrieved from the non-transferable root authentication fragment set; then, session consistency verification, time and path constraint verification, and authentication association verification are performed in sequence.

[0094] The session consistency check is used to determine whether the transferable session fragment retrieved by the target replacement node is consistent with the current business object. The session consistency check is considered to pass only when the task number is consistent, the session number is consistent, and the business type falls within the range of allowed inherited business types recorded in the shadow replacement table. The time and path constraint check is used to determine whether the target replacement node is still in the allowed replacement state. The time and path constraint check is considered to pass only when the effective replacement time window covers the current business cycle and the number of hops on the forwarding path where the target replacement node is located is not higher than the preset allowed hop limit. The authentication association check is used to determine whether the target replacement node is qualified to call the non-transferable root authentication fragment. The authentication association check is considered to pass only when the non-transferable root authentication fragment location identifier recorded in the shadow session repository exists and the calling constraint corresponding to the location identifier is consistent with the security domain matching result of the target replacement node.

[0095] To ensure a consistent inheritance validation exit point, the restricted inheritance pass value is calculated based on the above results:

[0096] In the formula, Indicates restricted inheritance by value; This indicates the session consistency check result, set to 1 if it passes and 0 if it fails. Indicates the coverage rate of the effective time window for replacement; This indicates the authentication verification result, set to 1 if successful and 0 if unsuccessful. , , These represent the weights corresponding to the session consistency verification result, the succession effective time window coverage, and the authentication association verification result in the restricted inheritance verification, respectively, and the sum of the three is 1. Example values: =0.4, =0.3, =0.3.

[0097] Only when , and Only when the inheritance pass threshold is greater than or equal to the preset inheritance pass threshold will an inheritance pass result be generated; otherwise, the current target successor node will be marked as an inheritance failure node, and the succession priority in the shadow succession table will be rolled back to the next successor candidate node to re-execute the target successor node selection logic in S410.

[0098] The inheritance pass result includes at least the forward node identifier, session number, task number, target successor node identifier, restricted inheritance pass value, inheritance pass flag, range of allowed inheritance business types, and failure rollback flag. The inheritance pass result is used as input to S430.

[0099] S430: Read the inheritance result, perform business bearer relationship switching and path update, and generate a switching completion result.

[0100] Specifically, when the inheritance pass mark in the inheritance pass result is passed, the target replacement node inherits the service priority, session state, cache window and forwarding sequence number of the corresponding critical service session, and switches the service bearer relationship of the critical service session corresponding to the forward node from the current service node to the target replacement node; the current backhaul exit and current forwarding path in the network topology status table are updated synchronously, the original current service node identifier and the target replacement node identifier are written into the switch completion result, and the target replacement node is updated to the current bearer node in the network topology status table.

[0101] It should be noted that the handover completion determination in this step only applies to command and control services, location backhaul services, voice dispatch services, and critical video indexing services in critical business sessions. Non-critical video main services are not included in the handover completion determination in this step, and will be subject to delayed migration or downgrade migration in subsequent S510.

[0102] To avoid confusion between "switched over" and "successfully switched over", a switchover completion value is calculated for each critical business session:

[0103] In the formula, Indicates the value after the switch is complete; This indicates the result of the service bearing relationship switch. It is set to 1 if the bearing relationship from the current service node to the target replacement node has been updated, and 0 otherwise. This indicates the path update result, and is set to 1 if both the current backhaul exit and the current forwarding path have been updated, otherwise it is set to 0. This indicates the result of critical service continuity preparation. It is set to 1 when the service priority, session state, cache window, and forwarding sequence number have all been inherited and written to the target successor node; otherwise, it is set to 0. , , These represent the weights corresponding to the service bearer relationship handover result, path update result, and critical service continuity preparation result in the handover completion assessment, respectively, and the sum of the three is 1. The weights of this type of logical judgment status are usually set to be evenly distributed, as shown in the example: =1 / 3, =1 / 3, =1 / 3.

[0104] Only when , , and If the value is greater than or equal to the preset handover completion threshold, the handover is considered complete; otherwise, the handover is considered incomplete, and the corresponding session number, task number, and reason for incompleteness are written into the pending service record.

[0105] Finally, a handover completion result is generated. The handover completion result includes at least the forward node identifier, session number, task number, original current service node identifier, target replacement node identifier, handover completion value, current backhaul exit, current forwarding path, critical service inheritance status, and pending service record marker. The handover completion result serves as the common input for S510 to perform critical service continuation and S530 to perform closed-loop writeback.

[0106] S5 specifically includes the following sub-steps: S510: Read the handover completion result and the critical business session table, perform critical business continuation processing, and generate critical business continuation results.

[0107] Specifically, for each critical business session whose handover completion value reaches a preset handover completion threshold in the handover completion results, the original business priority, original session state, original cache window, and original forwarding sequence number corresponding to the critical business session are first extracted from the critical business session table based on the session number and task number. Then, the target replacement node is controlled to restore the original business priority, original session state, original cache window, and original forwarding sequence number according to the original values, so that the target replacement node maintains the same business continuity attributes as the current service node after the bearer relationship switch. Critical business sessions only include command and control services, location backhaul services, voice dispatch services, and critical video index services, and do not include non-critical video main services.

[0108] After the recovery is completed, further verification is conducted to determine whether the target replacement node has the conditions to send and receive critical services. Specifically, the command and control service is considered available if it can receive control messages and return confirmation messages; the location backhaul service is considered available if it can output current location records; the voice dispatch service is considered available if it can output continuous voice frames; and the critical video index service is considered available if it can output valid index frames.

[0109] To ensure unified connection continuity, critical service continuity values ​​are calculated for each critical service session:

[0110] In the formula, Indicates the critical business continuity value; This indicates the service priority and session state recovery result; it is set to 1 when recovery is complete, and 0 otherwise. This indicates the result of the cache window and forwarding sequence number recovery. It is set to 1 when the recovery is complete, and 0 otherwise. This indicates the availability of the service; it is set to 1 if the target replacement node is ready to send and receive, and 0 otherwise. , , These represent the weights corresponding to service priority and session state recovery results, cache window and forwarding sequence number recovery results, and service availability results in the critical service continuity assessment, respectively, and the sum of the three is 1. The weights for this type of logical state determination are typically set to be evenly distributed, as shown in the example below: =1 / 3, =1 / 3, =1 / 3.

[0111] Only when , , and Only when the threshold for successful continuation is greater than or equal to the preset threshold will the corresponding critical service session be written into the critical service continuation result; otherwise, the critical service session will be written into the pending continuation service record. For example, when a location backhaul service... , , When both are 1, the result is If the value is 1, the location feedback service is recorded as being resumed.

[0112] After the above processing, a critical service continuation result is generated. The critical service continuation result includes at least the forward node identifier, session number, task number, target replacement node identifier, critical service type, critical service continuation value, continuation status identifier, and pending continuation service record marker. The critical service continuation result serves as the common input for S520 and S530.

[0113] S520 reads the critical service continuation results, shadow succession table, shadow session warehouse, and network topology status table; performs non-critical service migration, operation status update, and shadow succession table update; and generates non-critical service migration results, operation status update results, and the updated shadow succession table.

[0114] Specifically, for critical service sessions whose continuation status is marked as "continued" in the critical service continuation results, the current backhaul exit, current forwarding path, baseband processing load ratio, edge network access level, and edge exit stability corresponding to the target replacement node are first read from the network topology status table. Based on the above parameters, it is determined whether to trigger the next round of shadow replacement relationship update. The changes in the current backhaul exit compared to before the switch, the changes in the current forwarding path compared to before the switch, the changes in the baseband processing load ratio, the changes in the edge network access level, and the changes in the edge exit stability are merged to generate the operation status update result. The operation status update result includes at least the backhaul path change result, the baseband communication status change result, and the edge network access change result.

[0115] To ensure consistent updates to the export, calculate the shadow succession update value:

[0116] In the formula, This indicates that the shadow takes over and updates the value; This indicates the result of the change in the backhaul path. It is set to 1 if the current backhaul exit or the current forwarding path has changed compared to before the switch, and 0 otherwise. This indicates the result of baseband processing load change. It is set to 1 when the change in baseband processing load exceeds the preset update threshold, and 0 otherwise. This indicates the result of changes in edge network access. It is set to 1 when the change in the stability of the edge network access level or edge exit exceeds the preset threshold, and 0 otherwise. , , These represent the weights corresponding to the changes in backhaul path, baseband processing load, and edge network access in the shadow succession update evaluation, respectively, and the sum of the three is 1. Example values: =0.4, =0.3, =0.3.

[0117] when When the threshold is greater than or equal to the preset shadow succession update threshold, the succession candidate nodes for the critical business session are re-filtered, and the succession priority and effective succession time window are rebuilt; when When the threshold is less than the preset shadow replacement update threshold, only shadow replacement relationships in the original shadow replacement table that are marked as not invalid and whose security domain matching results are matched are inherited.

[0118] Subsequently, migration processing is performed on non-critical video main services. The migration processing includes three methods: delayed migration, degraded migration, and waiting migration. When the remaining capacity of the target replacement node is higher than the preset non-critical service migration threshold, delayed migration is performed. When the remaining capacity is lower than the preset non-critical service migration threshold but higher than the minimum retention threshold, degraded migration is performed. When the remaining capacity is lower than the minimum retention threshold, waiting migration is performed, and the service identifier, migration method, migration status, and reason for migration of the corresponding non-critical service are written into the non-critical service migration results.

[0119] Delete shadow replacement relationships in the original shadow replacement table that have expired the effective replacement time window, dropped below the preset replacement adaptation threshold, changed the security domain matching result to a mismatch, or have a shadow session repository availability lower than the preset repository creation availability threshold. If the same forward node and session number are not added to the new relationship after deletion, write them to the replacement relationship record to be created.

[0120] After the update, non-critical business migration results, operational status update results, and an updated shadow succession table are generated. The updated shadow succession table includes at least the forward node identifier, session number, task number, succession candidate node identifier, succession priority, succession effective time window, failure flag, succession relationship record flag to be added, and shadow succession update value. The non-critical business migration results and operational status update results serve as inputs to S530, and the updated shadow succession table serves as input to S530, and as the basis for inputs to the next cycle S320 and S410.

[0121] S530 reads the handover completion result, critical business continuation result, non-critical business migration result, running status update result, and updated shadow succession table, performs closed-loop write-back, and generates closed-loop update dataset.

[0122] Specifically, based on the forward node identifier, session number, and task number, the following data are merged to form a data group to be written back: the target replacement node identifier, the original current service node identifier, the current backhaul exit, and the current forwarding path in the handover completion result; the critical service continuation value, continuation status identifier, and pending continuation service record mark in the critical service continuation result; the migration method, migration status, and pending migration reason in the non-critical service migration result; the backhaul path change result, baseband communication status change result, and edge network access change result in the operation status update result; and the replacement priority, replacement effective time window, failure mark, and pending replacement relationship record mark in the updated shadow replacement table.

[0123] To ensure that the write-back data group can be directly used in the next cycle, the closed-loop write-back integrity is calculated for each data group to be written back:

[0124] In the formula, Indicates the completeness of the closed-loop write-back; This indicates the actual number of required fields in the current data group to be written back; This indicates the total number of preset required fields for closed-loop write-back. Required fields include at least the preceding node identifier, session number, task number, and target successor node identifier.

[0125] Only when Only when the specified time is reached will the data group to be written back be allowed to be written into the closed-loop update dataset; when At this time, the corresponding forward node identifier, session number, task number, and missing field type are written to the closed loop record to be completed, without performing a formal write-back.

[0126] After the closed-loop update dataset is generated, the target replacement node identifier, the original current service node identifier, the current backhaul exit, the current forwarding path, the backhaul path change results, the baseband communication status change results, and the edge network access change results are written back to the network topology status table. The critical service continuation results, non-critical service migration results, the updated shadow replacement table summary, and the current bearer node change results are written back to the critical service session table. After the write-back is complete, the temporary records of the data groups that have been written back in this round are cleared, and only the closed-loop records to be completed are retained to avoid repeated calls in the next cycle.

[0127] Finally, a closed-loop update dataset is generated. This dataset serves as the common input for the next cycle's S210 to identify the current service node, S310 to split key business sessions, and S410 to determine the takeover trigger conditions, thus completing the closed-loop connection from the handover result to the next round of network status identification.

[0128] For example, consider the case of a forward node entering a densely forested area from a vehicle-mounted satellite relay area.

[0129] Phase S1: The link quality to the current service node (vehicle node) deteriorates drastically. The marginal export stability index dropped from 0.95 to 0.20. Reduced to 0.30, baseband processing load ratio Surges to 0.80, while obscuring risk indicators. It changes from 0 to 1.

[0130] Phase S2: Calculate the neighboring UAV relay nodes. The value is 0.88, so it is used as the first shadow successor node.

[0131] Phase S3: Pretransmit the current RTP sequence number (e.g., 54321) and authentication digest of the key voice scheduling to the UAV node.

[0132] Phase S4: Calculate the succession trigger value =0.3×(1-0.20)+0.2×(1-0.30)+0.2×0.80+0.3×1=0.24+0.14+0.16+0.30=0.84. Since If (0.84) is greater than the preset replacement trigger threshold of 0.80, the system determines that the replacement trigger condition is met and immediately locks the target replacement node.

[0133] In the S5 phase: after receiving the instruction, the drone node immediately resumes the service using RTP sequence number 54322, and the call interruption time perceived by the frontline soldier's handheld terminal is less than 50ms.

[0134] The weighting coefficients in the above formula (such as...) (etc.) can be obtained through normalized learning from offline historical communication samples, or adjusted dynamically by the backend management plane by issuing a configuration table based on the priority of the emergency scenario (e.g., video priority or command priority). All the above thresholds are set with reference to the packet loss and latency tolerance limits in the emergency communication standard protocol.

[0135] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0136] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0137] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A multi-stage pre-eminence coordination emergency communication guarantee method in a complex environment, characterized in that, Includes the following steps: S1. Read the basic information of nodes, link quality parameters, baseband communication status parameters, edge network access parameters and service flow records in the multi-level forward-deployed emergency communication network, and generate a network topology status table and a key service session table; S2. Identify the current service node based on the network topology status table and the key business session table, filter candidate nodes for replacement, and generate a shadow replacement table. S3. Based on the key business session table, the session context is split into transferable session fragments and non-transferable root authentication fragments, and the transferable session fragments are pre-distributed to the successor candidate nodes to generate a shadow session repository and a successor preparation status table. S4. When the current service node meets the succession triggering conditions, select the target successor node according to the succession preparation status table, and perform restricted inheritance verification on the target successor node based on the shadow session repository and non-transferable root authentication fragment. After the verification passes, switch the service bearing relationship of the key business session and generate the succession completion result.

2. The multi-stage pre-emptive cooperative emergency communication guarantee method in a complex environment according to claim 1, characterized in that, Also includes: S5. Based on the handover completion result, continue the critical business session at the target successor node, perform delayed migration, downgraded migration or wait migration for non-critical video main business, update the shadow successor table, write back the results of this round, and generate a closed-loop update dataset.

3. The multi-stage pre-emptive cooperative emergency communication guarantee method in a complex environment according to claim 1, characterized in that, S1 specifically includes: Read the node identifier, node type, access link type, backhaul exit identifier, adjacent node identifier, and security domain identifier of the vehicle-mounted command node, forward node, relay node, and rear command node, and generate a basic node record set; Read the bit error rate, latency, jitter, packet loss rate, baseband synchronization status, baseband modulation and demodulation status, baseband frame processing load, edge network access layer, edge forwarding hop count, and edge egress stability, and perform joint verification to generate a network topology status table.

4. The multi-stage pre-emptive cooperative emergency communication guarantee method in a complex environment according to claim 3, characterized in that, It also includes: reading service type, service priority, session number, session status, cache window, forwarding sequence number, task number, and security authentication status, combining the network topology status table to identify key service sessions, and generating a key service session table.

5. The multi-stage pre-emptive cooperative emergency communication guarantee method in a complex environment according to claim 1, characterized in that, S2 specifically includes: Based on the current bearer node identifier, session number, task number, and backhaul path in the critical business session table, identify the current service node with the highest service node score that is responsible for the current backhaul exit output from the network topology status table; Around the current service node, select replacement candidate nodes from adjacent nodes, nodes that can establish connections, and nodes with priority connection relationships. These nodes should have corresponding business carrying capacity, legal security domain identifiers, available backhaul exits, and meet the replacement adaptation value and edge forwarding hop count requirements. This will generate a set of replacement candidate nodes. Calculate the shadow succession priority value based on the set of succession candidate nodes, establish the shadow succession relationship between the leading node and the succession candidate node, and generate the shadow succession table.

6. The multi-stage pre-emptive cooperative emergency communication guarantee method in a complex environment according to claim 1, characterized in that, S3 specifically includes: Based on the key business session table, extract the session context corresponding to the main business flow according to the session number and task number. Divide the session number, task number, business type, business priority, cache window, forwarding sequence number, short-cycle authentication digest and the status parameters required for reconnection into transferable session fragments. Divide the root key material location identifier, root authentication credential location identifier, non-replicable authentication factor identifier and call constraints into non-transferable root authentication fragments. Based on the shadow succession table, transferable session fragments are pre-distributed to succession candidate nodes and shadow session repositories are established; pre-verification is performed based on the shadow session repositories and the shadow succession table to generate a succession preparation status table.

7. The multi-stage pre-emptive cooperative emergency communication guarantee method in a complex environment according to claim 1, characterized in that, S4 specifically includes: Read the network topology status table, shadow succession table, and succession preparation status table. Determine whether the succession triggering conditions are met based on the link quality evaluation value, edge egress stability, baseband processing load ratio, and occlusion risk indicator of the current service node. Select nodes from the succession preparation status table whose pre-verification pass value meets the standard and whose time window covers the business cycle, and generate the target succession node selection result. Based on the target successor node selection result, shadow session repository, and non-transferable root authentication fragment set, perform restricted inheritance verification on the target successor node and generate an inheritance pass result.

8. The multi-stage pre-emptive cooperative emergency communication guarantee method in a complex environment according to claim 7, characterized in that, Also includes: Based on the inheritance, the service bearer relationship of the key service session is switched through the result, and the backhaul exit and current forwarding path are updated to generate a switchover completion result.

9. The multi-stage pre-emptive cooperative emergency communication guarantee method in a complex environment according to claim 1, characterized in that, S5 specifically includes: Based on the handover completion result and the critical business session table, restore the service priority, session status, cache window and forwarding sequence number at the target replacement node, and perform the continuation of command and control services, location backhaul services, voice dispatch services and critical video indexes, and generate critical business continuation results; Based on the critical service continuation results, shadow succession table, and network topology status table, non-critical video services are subject to delayed migration, downgraded migration, or pending migration. The shadow succession table is then updated, generating non-critical service migration results and an updated shadow succession table.

10. The multi-stage pre-emptive cooperative emergency communication guarantee method in a complex environment according to claim 9, characterized in that, Also includes: Based on the handover completion results, critical business continuation results, non-critical business migration results, and the updated shadow succession table, a closed-loop write-back is performed to generate a closed-loop update dataset.

Images