An IMS virtualization network element cross-cluster dynamic disaster recovery method based on stateless architecture

Abstract

The application discloses an IMS virtualization network element cross-cluster dynamic disaster recovery method based on a stateless architecture and concretely relates to the technical field of communication network fault recovery, and is used for solving the problem that the existing disaster recovery method does not adaptively process the release strategy based on the original IP address established in the vertical encryption authentication device, resulting in that the media stream is discarded by the security device and the media plane cannot be synchronously switched with the signaling plane; the session context containing the security policy identifier is read from the distributed storage, the policy version number is extracted, and the effective policy version of the vertical encryption authentication device connected with the candidate cluster and the configuration shadow state are checked to exclude the inconsistent policy and the cluster in the fault propagation path, determine the target disaster recovery cluster, create the stateless IMS network element instance, determine the media stream address with the lowest conflict probability based on the historical policy conflict log, generate the policy release request and send the same to the vertical encryption authentication device, and the media stream is connected by the stateless IMS network element instance after the binding establishment.

Description

Technical Field

[0001] This invention relates to the field of communication network fault recovery technology, and more specifically, to a cross-cluster dynamic disaster recovery method for IMS virtualized network elements based on a stateless architecture. Background Technology

[0002] In existing power IMS virtualization network elements, fault takeover is typically achieved through primary / backup clusters or synchronized session states during cross-cluster disaster recovery. When a running cluster fails, the IMS network element instance needs to be recreated on the target cluster to restore signaling and media processing functions, and redirect service traffic from the failed side to the newly created instance. During this process, the reconstruction of the network element instance completes the loading of application layer states and the renegotiation of the signaling plane, enabling the reconstruction of call control between the terminal and the core network.

[0003] However, the power IMS network is carried on the dedicated power grid, and vertical encryption authentication devices and access control equipment are deployed in the transmission path. These devices implement security policy control over media streams based on network layer information such as IP addresses and ports. During cross-cluster migration, the newly created IMS network element instance in the target cluster will inevitably obtain a different IP address than the faulty cluster. However, the existing disaster recovery method does not adapt to the allowance policy established by the security device based on the original IP address. As a result, when media stream packets arrive at the new network element address, they are directly discarded by the security device. The media plane cannot switch synchronously with the signaling plane, resulting in the interruption of real-time services such as dispatch voice. The uninterrupted takeover required by power communication services cannot be achieved. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, this invention provides a cross-cluster dynamic disaster recovery method for IMS virtualized network elements based on a stateless architecture to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A cross-cluster dynamic disaster recovery method for IMS virtualized network elements based on a stateless architecture includes: S1. When disaster recovery is triggered in a faulty cluster, the session context of the IMS network element in the faulty cluster is read from the distributed storage. The session context contains the security policy identifier. S2. Extract the policy version number from the security policy identifier, identify the available clusters other than the faulty cluster as candidate clusters, obtain the effective policy version and configuration shadow status of the vertical encryption authentication device connected to each candidate cluster, eliminate candidate clusters whose effective policy version and policy version number are inconsistent or whose configuration shadow status is mismatched, and after excluding the clusters in the fault propagation path from the remaining candidate clusters, determine the target disaster recovery cluster. S3. Create a stateless IMS network element instance in the target disaster recovery cluster and configure signaling forwarding and media forwarding. S4. Obtain the historical policy conflict logs of the vertical encryption authentication device connected to the target disaster recovery cluster. Based on the security policy identifier and the historical policy conflict logs, determine the address with the lowest conflict probability as the media stream address of the stateless IMS network element instance. S5. Generate a policy clearance request, carrying the media stream address and security policy identifier, and send it to the vertical encryption authentication device; S6. After the vertical encryption authentication device establishes the binding between the media stream address and the security policy identifier, the stateless IMS network element instance continues the media stream corresponding to the media stream address.

[0006] Furthermore, when disaster recovery is triggered by a faulty cluster, the session context of the IMS network elements within the faulty cluster is read from distributed storage, including: Obtain disaster recovery trigger signals and faulty cluster identifiers; Query the session context corresponding to the faulty cluster identifier in the distributed storage; Extract the security policy identifier from the session context. The security policy identifier includes the encrypted tunnel identifier and the policy version number.

[0007] Further, the policy version number is extracted from the security policy identifier, and available clusters other than the faulty cluster are identified as candidate clusters. The effective policy version and configuration shadow status of the vertical encryption authentication devices connected to each candidate cluster are obtained. Candidate clusters whose effective policy version and policy version number are inconsistent or whose configuration shadow status does not match are eliminated. After excluding clusters in the fault propagation path from the remaining candidate clusters, the target disaster recovery cluster is determined, including: Extract the policy version number from the security policy identifier; The available clusters other than the faulty cluster are identified as candidate clusters; Query the effective policy version and configuration shadow status of the vertical encryption authentication device connected to each candidate cluster; Compare the effective policy version with the policy version number, and determine whether the configured shadow status matches the effective policy version. Eliminate candidate clusters that do not meet any of these criteria. Obtain the fault type and fault source location of the faulty cluster. Based on the sharing relationship between the bearer network topology and power supply links, determine whether the remaining candidate clusters are on the fault propagation path starting from the fault source location, and exclude clusters on the fault propagation path. The target disaster recovery cluster is determined from the remaining candidate clusters after eliminating fault propagation paths.

[0008] Furthermore, based on the sharing relationship between the bearer network topology and the power supply links, it is determined whether the remaining candidate clusters are on the fault propagation path starting from the fault source location. This includes: obtaining the bearer network topology connection relationship and the power supply link sharing relationship between the fault cluster and the remaining candidate clusters; starting from the fault source location, marking the fiber optic link nodes affected by the fault hop by hop along the bearer network topology connection relationship, and marking the candidate clusters sharing the same power supply circuit along the power supply link sharing relationship; and determining the candidate clusters located at the marked fiber optic link nodes or sharing the same power supply circuit as being on the fault propagation path.

[0009] Furthermore, create stateless IMS network element instances in the target disaster recovery cluster and configure signaling forwarding and media forwarding, including: Allocate computing resources to the target disaster recovery cluster and start stateless IMS network element instances; Obtain signaling forwarding configuration data and media forwarding configuration data from the session context; Load the signaling forwarding program and media forwarding program into the stateless IMS network element instance, and pass the signaling forwarding configuration data to the signaling forwarding program and the media forwarding configuration data to the media forwarding program.

[0010] Furthermore, obtain the historical policy conflict logs of the vertical encryption authentication devices connected to the target disaster recovery cluster. Based on the security policy identifier and the historical policy conflict logs, determine the address with the lowest conflict probability as the media stream address of the stateless IMS network element instance, including: Request historical policy conflict logs from the vertical encryption authentication device connected to the target disaster recovery cluster; Extract policy feature vectors from security policy identifiers. The policy feature vectors contain security domain identifiers, service level identifiers, and protocol quintuples. In the historical strategy conflict log, a strategy conflict graph is constructed using the feature vectors of strategies that have historically clashed as nodes and the conflict frequency as the edge weights. Identify the conflict subgraphs in the policy conflict graph that are associated with the extracted policy feature vectors; Obtain the available address pool of the target disaster recovery cluster, and for each candidate media stream address in the available address pool, calculate the conditional probability of it appearing as a conflict node in the conflict subgraph. The candidate media stream address with the lowest conditional probability is selected as the address with the lowest conflict probability and determined as the media stream address of the stateless IMS network element instance.

[0011] Furthermore, identifying conflict subgraphs in the policy conflict graph that are associated with the extracted policy feature vectors includes: calculating the similarity between the extracted policy feature vectors and the policy feature vectors of each node in the policy conflict graph; selecting nodes whose similarity exceeds a preset similarity threshold as associated nodes; and extracting the minimum connected subgraph in the policy conflict graph containing all associated nodes as the conflict subgraph associated with the extracted policy feature vectors, using the associated nodes as boundaries.

[0012] Furthermore, for each candidate media stream address in the available address pool, the conditional probability of it appearing as a conflict node in the conflict subgraph is calculated, including: counting the number of conflict records associated with the candidate media stream address in the conflict subgraph; counting the total number of all conflict records in the conflict subgraph; and using the ratio of the number of conflict records to the total number as the conditional probability of the candidate media stream address appearing as a conflict node in the conflict subgraph.

[0013] Further, a policy clearance request is generated, carrying the media stream address and security policy identifier, and sent to the longitudinal encryption authentication device, including: Extract the encrypted tunnel identifier from the security policy identifier; Based on the encrypted tunnel identifier and media stream address, generate verification information to validate the legitimacy of the policy permission request; Construct a policy-based allow request, which includes the media stream address, security policy identifier, and authentication information; Send a policy release request to the vertical encryption authentication device connected to the target disaster recovery cluster.

[0014] Furthermore, after the vertical encryption authentication device establishes the binding between the media stream address and the security policy identifier, the stateless IMS network element instance continues the media stream corresponding to the media stream address, including: Receive a policy approval success confirmation message returned by the vertical encryption authentication device connected to the target disaster recovery cluster; Parse the binding result between the media stream address and the security policy identifier from the successful policy approval confirmation message; After the binding establishment result indicates that the binding has been established, the stateless IMS network element instance continues the media stream corresponding to the media stream address through the configured media forwarding program.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. This method incorporates the original encrypted tunnel information and policy version number of the faulty cluster into the disaster recovery decision-making link through the end-to-end transmission of security policy identifiers in the session context. This ensures that the selection of target disaster recovery clusters not only considers computing resources and network reachability, but also verifies the consistency between the effective policy version and the configuration shadow state of the vertical encryption authentication device connected to the candidate cluster. This avoids scheduling stateless IMS network element instances to clusters where security policies are not synchronized or are about to change, eliminating the risk of policy release requests being rejected from the source. The method also constructs a policy conflict graph using historical policy conflict logs, identifies conflict subgraphs associated with the current security policy identifier through similarity calculation, and selects the address with the lowest conflict probability from the available address pool as the media stream address. This proactively avoids potential conflicts with existing policies of the vertical encryption authentication device, rather than passively waiting for conflicts to occur before processing.

[0016] 2. After the media stream address is determined, this method generates verification information and constructs a policy release request using the encrypted tunnel identifier and the media stream address. It then proactively initiates policy binding to the vertical encryption authentication device connected to the target disaster recovery cluster, ensuring that the security device has established the release rules for the media stream address and security policy identifier before the media stream arrives. Subsequently, the stateless IMS network element instance continues the media stream after the binding is established, achieving synchronous switching between the signaling plane and the media plane. The entire disaster recovery process requires no manual intervention. A closed loop is formed through the interconnection of security policy identifiers. The session state of the faulty cluster is completely transmitted to the target disaster recovery cluster through distributed storage. The dispatch voice is not interrupted due to security device interception during cross-cluster migration, ensuring uninterrupted takeover of power communication services. Attached Figure Description

[0017] Figure 1 This is a flowchart of a cross-cluster dynamic disaster recovery method for IMS virtualized network elements based on a stateless architecture, according to the present invention. Figure 2 This is a schematic diagram of the cross-cluster dynamic disaster recovery system structure of IMS virtualized network elements based on a stateless architecture, according to the present invention. Detailed Implementation

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

[0019] Example: Figure 1 This invention presents a cross-cluster dynamic disaster recovery method for IMS virtualized network elements based on a stateless architecture, comprising: S1. When disaster recovery is triggered in a faulty cluster, the session context of the IMS network element in the faulty cluster is read from the distributed storage. The session context contains the security policy identifier. S2. Extract the policy version number from the security policy identifier, identify the available clusters other than the faulty cluster as candidate clusters, obtain the effective policy version and configuration shadow status of the vertical encryption authentication device connected to each candidate cluster, eliminate candidate clusters whose effective policy version and policy version number are inconsistent or whose configuration shadow status is mismatched, and after excluding the clusters in the fault propagation path from the remaining candidate clusters, determine the target disaster recovery cluster. S3. Create a stateless IMS network element instance in the target disaster recovery cluster and configure signaling forwarding and media forwarding. S4. Obtain the historical policy conflict logs of the vertical encryption authentication device connected to the target disaster recovery cluster. Based on the security policy identifier and the historical policy conflict logs, determine the address with the lowest conflict probability as the media stream address of the stateless IMS network element instance. S5. Generate a policy clearance request, carrying the media stream address and security policy identifier, and send it to the vertical encryption authentication device; S6. After the vertical encryption authentication device establishes the binding between the media stream address and the security policy identifier, the stateless IMS network element instance continues the media stream corresponding to the media stream address.

[0020] Figure 2 A schematic diagram of a stateless IMS virtualized network element cross-cluster dynamic disaster recovery system based on this invention is provided. The dispatch center, deployed in the power IMS network management domain, is responsible for receiving disaster recovery trigger signals, screening candidate clusters, determining the target disaster recovery cluster, issuing creation instructions for stateless IMS network element instances, acquiring historical policy conflict logs, and constructing and sending policy release requests. The dispatch center is connected to the distributed storage via a management network. The dispatch center initiates key-value query requests to the distributed storage to read the session context of the IMS network element within the faulty cluster. The session context contains a security policy identifier, which in turn contains an encrypted tunnel identifier and a policy version number.

[0021] Distributed storage is a cross-cluster shared storage cluster deployed in the power IMS network storage domain. It adopts a key-value storage model, using the fault cluster identifier as the primary key to organize session context data. The distributed storage and the fault cluster are connected through a storage network. During normal operation, each IMS element in the fault cluster writes the real-time changing session state to the distributed storage incrementally or fully. When writing, the fault cluster identifier is used as the namespace prefix, and the session identifier is used as the record key to achieve persistence of the session context.

[0022] A faulty cluster is an IMS virtualization cluster that has experienced a failure. Failure types include power outages in the equipment room, complete fiber optic cable breaks, or virtualization platform crashes. When the disaster recovery monitoring component inside the faulty cluster detects an interruption in the signaling link and a continuous loss of bearer network heartbeat messages, it sends a disaster recovery trigger signal to the dispatch center. The disaster recovery trigger signal carries a faulty cluster identifier, which is a unique code for the faulty cluster in the power IMS network.

[0023] Candidate clusters are a set of available IMS virtualization clusters other than faulty clusters. Candidate clusters must meet basic availability conditions, including normal operation of the virtualization infrastructure layer within the cluster, reachability between the cluster management node and the control plane, and the cluster's ability to create stateless IMS network element instances. The vertical encryption authentication device connected to the candidate cluster is a power grid security device connected to the candidate cluster, used to implement security policy control over media streams passing through the candidate cluster. The dispatch center initiates a query request to the management interface of the vertical encryption authentication device connected to the candidate cluster to obtain the effective policy version and configuration shadow status. The effective policy version is the version number of the currently executed security policy, and the configuration shadow status is the status indicator of policies that have been configured and issued but have not yet taken effect.

[0024] The target disaster recovery cluster is selected by the scheduling center from the candidate cluster set after policy version consistency verification, configuration shadow state matching judgment, and fault propagation path elimination. The scheduling center sends an instance creation request to the virtualization infrastructure management component of the target disaster recovery cluster, allocates computing resources within the target disaster recovery cluster, and starts the stateless IMS network element instance. The stateless IMS network element instance is a pure software instance running inside the target disaster recovery cluster. It is started by calling the pre-built stateless IMS network element image file and only contains the basic operating system environment, IMS protocol stack basic library, and binary files of signaling forwarding program and media forwarding program. It does not contain any session state persistent storage module, nor does it preload any session context data. When the stateless IMS network element instance is destroyed, the state synchronization in memory is lost.

[0025] The vertical encryption authentication device connected to the target disaster recovery cluster is a power grid security device connected to the target disaster recovery cluster, used to implement security policy control over media streams passing through the target disaster recovery cluster. The dispatch center requests historical policy conflict logs from the vertical encryption authentication device connected to the target disaster recovery cluster. Based on the security policy identifier and the historical policy conflict logs, it determines the address with the lowest conflict probability as the media stream address for the stateless IMS network element instance, and then sends a policy release request to the vertical encryption authentication device connected to the target disaster recovery cluster. The policy release request carries the media stream address and the security policy identifier. After the vertical encryption authentication device connected to the target disaster recovery cluster creates a binding entry between the media stream address and the security policy identifier in its internal policy table, the stateless IMS network element instance continues the media stream through the vertical encryption authentication device connected to the target disaster recovery cluster, realizing security policy adaptation and service recovery during cross-cluster dynamic disaster recovery.

[0026] When disaster recovery is triggered by a faulty cluster, the session context of the IMS network element in the faulty cluster is read from the distributed storage. The session context contains a security policy identifier. The specific implementation process is as follows.

[0027] Obtain the disaster recovery trigger signal and the fault cluster identifier. The disaster recovery trigger signal is generated by the disaster recovery monitoring component of the dispatch center. It is generated when the component detects an interruption in the signaling link of an IMS network element within a fault cluster and a continuous loss of bearer core jump messages. The disaster recovery trigger signal carries the fault cluster identifier, which is a unique code for the fault cluster in the power IMS network, such as a cluster number uniformly assigned by the company. The fault cluster identifier is used to locate the session context data associated with the fault cluster in distributed storage.

[0028] The process involves querying the session context corresponding to the faulty cluster identifier in the distributed storage. The distributed storage is a cross-cluster shared storage cluster deployed in the central data center, employing a key-value storage model. Session contexts are organized using the faulty cluster identifier as the primary key, with each faulty cluster identifier corresponding to a set of session contexts. The query process is as follows: using the faulty cluster identifier as the query key, a key-value query request is initiated to the distributed storage. The distributed storage locates the corresponding session context storage partition based on the faulty cluster identifier and returns all session context data stored in that partition. A session context is a collection of persistent session state data from each IMS network element within the faulty cluster at the last moment before the fault. Each session context corresponds to a dispatch call or terminal registration and contains complete state information of the corresponding session at the time of the fault.

[0029] The security policy identifier is extracted from the session context. This identifier includes an encrypted tunnel identifier and a policy version number. The security policy identifier is a field in the session context used to identify the security policy used by the media stream of the corresponding session when passing through the vertical encryption authentication device on the power grid. The encrypted tunnel identifier is a unique number established between the vertical encryption authentication devices for transmitting media streams, used to distinguish different end-to-end encrypted channels. The policy version number is the configuration version identifier of the security policy corresponding to the encrypted tunnel on the vertical encryption authentication device on the fault cluster side; the policy version number increments each time the security policy changes. The process of extracting the security policy identifier is as follows: traverse each record in the session context, read the data field marked as the security policy identifier in each record, and parse out the two subfields, the encrypted tunnel identifier and the policy version number, from the security policy identifier. Both the encrypted tunnel identifier and the policy version number are stored in string or integer form, and are extracted by splitting according to the preset field separation rules of the security policy identifier during parsing.

[0030] The persistence and retrieval mechanism of the session context ensures that the session state of the faulty cluster is not lost under the stateless architecture. During normal operation, each IMS network element in the faulty cluster writes the real-time changing session state to the distributed storage incrementally or in full during the processing of each scheduled call. The faulty cluster identifier is used as the namespace prefix, and the session identifier is used as the record key. When disaster recovery is triggered, the stateless IMS network element instance on the target disaster recovery cluster side can read the session context from the distributed storage to obtain the complete session state before the failure, including terminal registration information, call status, media negotiation parameters, and security policy identifiers. This provides a data foundation for subsequent cross-cluster reconstruction signaling and media processing.

[0031] The disaster recovery trigger signal acquisition method leverages the scheduling center's unified monitoring capability over the entire IMS cluster. The fault cluster identifier, used as a key-value query mechanism in distributed storage, utilizes the key-value indexing characteristics of distributed storage. The extraction of the security policy identifier utilizes pre-defined field labeling rules in the session context. Together, these methods enable the rapid and accurate retrieval of the fault cluster's session context and its associated security policy identifier from distributed storage when a fault occurs, providing the necessary data input for subsequent determination of the target disaster recovery cluster and security policy adaptation.

[0032] Extract the policy version number from the security policy identifier, identify available clusters other than the faulty cluster as candidate clusters, obtain the effective policy version and configuration shadow status of the vertical encryption authentication device connected to each candidate cluster, eliminate candidate clusters whose effective policy version and policy version number are inconsistent or whose configuration shadow status does not match, and after excluding clusters in the fault propagation path from the remaining candidate clusters, determine the target disaster recovery cluster. The specific implementation process is as follows.

[0033] The policy version number is parsed from the security policy identifier. The security policy identifier, obtained during session context extraction, contains two subfields: an encrypted tunnel identifier and a policy version number. The parsing process is as follows: The string or binary data of the security policy identifier is read and segmented according to a preset field separation rule. This rule is a data format agreed upon during the generation of the security policy identifier; for example, the first few bytes are the encrypted tunnel identifier, and the following few bytes are the policy version number, or the two subfields are separated by a specific delimiter. After segmentation, the corresponding policy version number subfield is extracted and converted to an integer form to obtain the policy version number value. The policy version number is used for subsequent comparison with the effective policy versions of the vertical encryption authentication devices connected to each candidate cluster.

[0034] Available clusters other than the faulty clusters are identified as candidate clusters. In a multi-level cluster deployment environment of power IMS, independent IMS virtualization clusters are deployed at various levels of dispatch centers, cities and prefectures, and some counties. These clusters are interconnected via a ring network carried by the dedicated power network and are managed uniformly by the resource scheduling component of the dispatch center. When a cluster is identified as a faulty cluster, the resource scheduling component removes the faulty cluster from the list of all clusters under unified management, and identifies the remaining clusters in the list as candidate clusters. Candidate clusters must also meet basic availability conditions, which refer to the normal operation of the virtualization infrastructure layer within the cluster, the reachability of the cluster management node and the control plane, and the cluster's ability to create stateless IMS network element instances. The judgment of basic availability conditions is based on the heartbeat detection results periodically issued by the resource scheduling component to each cluster and the cluster status information actively reported by each cluster. The heartbeat detection period is a pre-set time interval, such as 30 seconds. If a cluster times out in the most recent heartbeat detection period, or if the cluster actively reports an infrastructure degradation status, the cluster is excluded from the candidate clusters and does not proceed to the subsequent screening process.

[0035] The system queries the vertical encryption authentication devices connected to each candidate cluster for the effective policy version and configuration shadow status. Each candidate cluster is connected to a corresponding vertical encryption authentication device in the power grid, and the correspondence between candidate clusters and vertical encryption authentication devices is stored in the network topology database of the dispatch center. The query process is as follows: The management address of the vertical encryption authentication device corresponding to each candidate cluster is read from the network topology database. A Simple Network Management Protocol (SMLP) query request or a Network Configuration Protocol (NIC) query request is then initiated to the management interface of the vertical encryption authentication device through the management address. The request parameters specify two object identifiers: the effective policy version and the configuration shadow status. When the security policy configuration changes, the vertical encryption authentication device generates a new policy version number and records the effective time. The effective policy version is the version number of the currently executed security policy. The configuration shadow status is the status indicator of a policy that has been configured and issued but has not yet taken effect in the vertical encryption authentication device. The configuration shadow status includes the version number of the policy to be effective and the expected effective timestamp. The response message returned by the vertical encryption authentication device carries the value of the effective policy version and the structured data of the configuration shadow status.

[0036] The effective policy version is compared with the policy version number, and it is determined whether the configuration shadow state matches the effective policy version. Candidate clusters that do not meet any of these criteria are eliminated. The comparison method is as follows: the policy version number parsed from the security policy identifier is compared with the effective policy version of the vertical encryption authentication device connected to each candidate cluster. If the value of the effective policy version of the vertical encryption authentication device connected to the candidate cluster is equal to the policy version number, the effective policy version comparison passes. If the value of the effective policy version is less than the policy version number, it means that the security policy of the vertical encryption authentication device connected to the candidate cluster has not been updated to the version recorded in the security policy identifier on the faulty cluster side, and cannot correctly identify the security policy identifier in the policy release request; the corresponding candidate cluster is eliminated. If the value of the effective policy version is greater than the policy version number, it means that the security policy version of the vertical encryption authentication device connected to the candidate cluster is newer and the security policy is backward compatible; the corresponding candidate cluster is retained. The method for determining the matching of configuration shadow states is as follows: Check if there are any pending policies in the configuration shadow state. If a pending policy exists and its version number is inconsistent with the version of the effective policy, it indicates that the vertical encryption authentication device is about to switch to a new policy version. The current allowance rules for the effective policy version may change in a short time, and there is a risk that the policy allowance request may be overridden by a subsequent new policy. In this case, it is determined that the configuration shadow state and the effective policy version do not match, and the corresponding candidate cluster is removed. If there are no pending policies in the configuration shadow state, or the version number of the pending policy is consistent with the version of the effective policy, it is determined that the configuration shadow state and the effective policy version match, and the corresponding candidate cluster is retained.

[0037] The system obtains the fault type and fault source location of the faulty cluster. Based on the shared relationship of the bearer network topology and power supply links, it determines whether the remaining candidate clusters are on the fault propagation path starting from the fault source location, and excludes clusters on the fault propagation path. The fault type is determined by the disaster recovery monitoring component of the dispatch center based on alarm information, such as power outage in the equipment room, complete fiber optic cable breakage, and virtualization platform crash. The fault source location is the physical or logical location where the fault occurred. Physical locations include, for example, the substation equipment room number or the transmission line tower number; logical locations include, for example, the node number in the power bearer network topology. The bearer network topology is the network connection structure formed by fiber optic links between clusters at all levels in the dedicated power network. The bearer network topology is stored in the network management database of the dispatch center and organized in a graph structure of nodes and links. Nodes represent clusters or aggregation nodes, and links represent fiber optic connections between nodes. The power supply link sharing relationship refers to whether each cluster site is powered by the same power supply circuit of the same substation. The power supply link sharing relationship is stored in the power resource management database of the dispatch center.

[0038] Obtain the bearer network topology connections and power supply link sharing relationships between the faulty cluster and the remaining candidate clusters. Retrieve the path set from the network management database, with the faulty cluster as the starting point and each remaining candidate cluster as the ending point; each path in the path set consists of several fiber optic link nodes. Retrieve the power supply circuit identifiers of the sites where the faulty cluster is located, and the power supply circuit identifiers of the sites where each remaining candidate cluster is located, from the power resource management database.

[0039] Starting from the location of the fault source, the affected fiber optic link nodes are marked hop-by-hop along the bearer network topology, and candidate clusters sharing the same power supply circuit are marked along the power supply link sharing relationship. The specific method of hop-by-hop marking is as follows: starting from the fiber optic link node corresponding to the fault source location, the network topology is traversed hop-by-hop outwards from the link adjacent to the fault source location, and an affected marker is set on each traversed fiber optic link node. The maximum number of hops traversed is determined based on a preset hop count threshold corresponding to the fault type. The preset hop count threshold is an integer value pre-set for different fault types, based on the redundant routing distance of the power dedicated network fiber optic links and historical experience of fault propagation. For example, the preset hop count threshold for a power outage in a computer room is set to 1 hop, because a power outage in a computer room usually only affects the computer room's outbound link; the preset hop count threshold for a complete fiber optic cable break is set to 3 hops to cover adjacent fiber optic switching nodes that may be affected along the direction of the cable break; and since a virtualization platform crash does not involve physical link damage, the preset hop count threshold is set to 0, meaning no fiber optic link node marking is performed. At the same time, query candidate clusters that share the same power supply circuit identifier as the faulty cluster, and mark the candidate clusters that share the same power supply circuit identifier as having a power supply link affected.

[0040] Candidate clusters located on marked fiber optic link nodes or sharing the same power supply circuit are identified as being on the fault propagation path and are excluded. The remaining set of candidate clusters after the exclusion operation is the set of safe candidate clusters that both meet the policy version consistency and configuration shadow state matching conditions and are not on the fault propagation path.

[0041] After eliminating fault propagation paths, the target disaster recovery cluster is determined from the remaining candidate clusters. If there is only one remaining candidate cluster, it is directly selected as the target disaster recovery cluster. If there are multiple remaining candidate clusters, the selection is further based on the computing resource status. The selection method is as follows: query the virtualization infrastructure management component of each remaining candidate cluster to find the total available computing resources. The total available computing resources include the number of idle CPU cores and the capacity of idle memory. Select the remaining candidate cluster with the largest total available computing resources as the target disaster recovery cluster. If the total available computing resources are the same, prioritize the remaining candidate cluster with the shortest network transmission latency as the target disaster recovery cluster. The network transmission latency is the round-trip latency measurement from the resource scheduling component of the scheduling center to each remaining candidate cluster. Once the identifier of the target disaster recovery cluster is determined, it will be passed to the subsequent stateless IMS network element instance creation process.

[0042] Create a stateless IMS network element instance in the target disaster recovery cluster and configure signaling forwarding and media forwarding. The specific implementation process is as follows.

[0043] The system allocates computing resources to the target disaster recovery cluster and starts a stateless IMS network element instance. The target disaster recovery cluster's identifier has already been determined during the candidate cluster screening process. The resource scheduling component of the scheduling center sends an instance creation request to the virtualization infrastructure management component of the target disaster recovery cluster. This request carries computing resource requirements, including the required number of CPU cores and memory capacity. The virtualization infrastructure management component allocates the corresponding number of CPU cores and memory from the available resource pool of the target disaster recovery cluster and starts a virtualization instance using a pre-built stateless IMS network element image file. The stateless IMS network element image file is a pre-built minimal image containing only the basic operating system environment, the IMS protocol stack library, and binary files for signaling forwarding and media forwarding programs. The image file does not contain any persistent session state storage modules, nor does it preload any session context data. After the virtualization instance starts, the virtualization infrastructure management component returns the instance identifier and the instance's network configuration information, including the network interface address and media stream transmission port range assigned to the instance.

[0044] Signaling forwarding configuration data and media forwarding configuration data are obtained from the session context. The session context is a collection of persistent session state data of each IMS network element within the faulty cluster, retrieved from distributed storage before the fault. Each session context record corresponds to a scheduled call or terminal registration. Signaling forwarding configuration data includes the registration status of the initial session protocol, call status, service routing information, timer parameters, and service quality tags. This data is obtained by parsing the data marked as signaling status fields in the session context. Media forwarding configuration data includes the remote address, remote port, local port, codec type, sampling rate, packet duration, and media stream direction identifier of the real-time transport protocol. This data is also obtained by parsing the data marked as media status fields in the session context. The parsing process is performed record by record, organizing the extracted signaling forwarding configuration data into a signaling configuration dataset by session identifier, and the extracted media forwarding configuration data into a media configuration dataset by session identifier.

[0045] The signaling forwarder and media forwarder are loaded into the stateless IMS network element instance, and signaling forwarding configuration data and media forwarding configuration data are passed to the signaling forwarder and media forwarding program, respectively. The loading process is as follows: The signaling configuration dataset and media configuration dataset are injected into the internal storage of the stateless IMS network element instance in file form through the configuration injection channel provided by the virtualization infrastructure management component. The configuration injection channel is a metadata service interface or configuration driver interface provided by the virtualization platform, which can be dynamically injected during or after instance startup. After the stateless IMS network element instance starts, the signaling forwarder and media forwarder are automatically started by the instance's internal process manager. When the signaling forwarder starts, it reads the injected signaling configuration dataset, loads the signaling forwarding configuration data for each session line by line, rebuilds the session's signaling state machine in memory, and binds it to the assigned network interface address to begin listening for signaling packets. When the media forwarder starts, it reads the injected media configuration dataset, loads the media forwarding configuration data for each session line by line, establishes a media streaming table in memory, and opens the corresponding media streaming transmission port to prepare for receiving and sending media packets. Since neither the signaling forwarding program nor the media forwarding program writes state data back to local storage, all runtime states exist only in memory. When the stateless IMS network element instance is destroyed, the state in memory becomes invalid, which is in line with the design principle of stateless IMS network elements.

[0046] The above process enables the target disaster recovery cluster to quickly allocate resources and start stateless IMS network element instances once identified. It eliminates the need to wait for the synchronization of large amounts of session data from the faulty cluster; instead, it only requires extracting configuration data from the session context already read from distributed storage and injecting it to complete the instance's service readiness. This stateless architecture-based instance creation method avoids the time-consuming database recovery and full state synchronization required when stateful network elements migrate across clusters. This allows the creation and configuration of network element instances to be completed in a very short time, providing an immediate runtime platform for subsequent policy approval and media stream continuation.

[0047] Obtain the historical policy conflict logs of the vertical encryption authentication device connected to the target disaster recovery cluster. Based on the security policy identifier and the historical policy conflict logs, determine the address with the lowest conflict probability as the media stream address of the stateless IMS network element instance. The specific implementation process is as follows.

[0048] The system requests historical policy conflict logs from the vertical encryption authentication device connected to the target disaster recovery cluster. The historical policy conflict log is a collection of policy conflict events recorded by the vertical encryption authentication device during operation. Each policy conflict event contains the policy feature vectors of the two or more conflicting policies, the conflict timestamp, and the network address information involved when the conflict occurred. A policy conflict occurs when a new policy approval request carries a security policy identifier that overlaps with or conflicts in priority with an already effective policy in the vertical encryption authentication device, preventing the device from simultaneously executing both conflicting rules. The request process is as follows: A log query request is initiated to the management interface via the management address of the vertical encryption authentication device connected to the target disaster recovery cluster. The log query request includes a log type parameter specifying it as a policy conflict log, and a time range parameter to limit the time span of the returned log records, such as policy conflict records from the last 90 days. The vertical encryption authentication device filters out policy conflict events that meet the conditions based on the request parameters and returns the historical policy conflict log in structured data format.

[0049] The policy feature vector is extracted from the security policy identifier. This vector contains a security domain identifier, a service level identifier, and a protocol quintuple. The security policy identifier is obtained during session context extraction and also carries policy attribute information. The security domain identifier indicates the security zone to which the security policy belongs; its value corresponds to the security zones in the power monitoring system, such as Security Zone I, Security Zone II, and Security Zone III. The service level identifier indicates the service priority of the corresponding session; its value is, for example, the highest priority for relay protection voice, the medium priority for municipal dispatch, and the normal priority for administrative office. The protocol quintuple includes the source IP address, destination IP address, source port, destination port, and transport layer protocol type. The extraction process involves reading the security domain identifier, service level identifier, and protocol quintuple fields from the structured data of the security policy identifier, combining these three fields into a multi-dimensional vector, which serves as the policy feature vector. This policy feature vector is used for subsequent matching and similarity analysis with policy feature vectors in historical policy conflict logs.

[0050] In the historical strategy conflict log, a strategy conflict graph is constructed using the strategy feature vectors that clashed historically as nodes and the conflict frequency as edge weights. The construction process is as follows: traverse each strategy conflict event in the historical log. For each pair of conflicting strategy feature vectors involved in each event, treat them as two nodes in the strategy conflict graph. If no edge exists between the two nodes, create an edge and set its initial weight to 1. If an edge already exists between the two nodes, increment the corresponding edge weight by 1. The edge weight represents the frequency of the two strategy feature vectors clashing in the historical record. The strategy conflict graph is stored in memory as an adjacency list or adjacency matrix, with each node accompanied by its own strategy feature vector value and each edge accompanied by its edge weight value.

[0051] The extracted policy feature vectors are compared with the policy feature vectors of each node in the policy conflict graph to calculate their similarity. The similarity calculation measures the closeness of two policy feature vectors in terms of policy attributes and network parameters. The similarity value is calculated as: S = Ssec × Slevel × Sflow; where S represents the overall similarity value of the policy feature vectors, Ssec represents the similarity contribution value of the security domain identifier component, Slevel represents the similarity contribution value of the service level identifier component, and Sflow represents the similarity contribution value of the protocol quintuple component. S is calculated by multiplying the similarity contribution values ​​of each dimension component.

[0052] The similarity contribution value Ssec of the security domain identifier components is determined by the following rule: if the two security domain identifiers are exactly the same, then Ssec is 1; otherwise, Ssec is 0.

[0053] The similarity contribution value Slevel of the business level identifier component is calculated as: Slevel = 1 - |Li - Lj| / Lmax; where Li and Lj represent the values ​​of the two business level identifiers, and Lmax represents the maximum value range of the business level identifier. The value range of Slevel is between 0 and 1.

[0054] The similarity contribution value Sflow of the protocol's five-element components is calculated as: Sflow = Sip × Sport × Sproto; where Sip represents the IP address overlap, Sport represents the port similarity contribution value, and Sproto represents the protocol type similarity contribution value. The IP address overlap (Sip) is calculated as the product of the overlap between two source IP addresses calculated by the subnet mask length and the overlap between two destination IP addresses calculated by the subnet mask length, with an overlap value between 0 and 1. The port similarity contribution value Sport is determined as follows: if both the source and destination ports are the same, Sport is 1; if either the source or destination port is within an adjacent port range, Sport is 0.5; otherwise, Sport is 0. The transport layer protocol type similarity contribution value Sproto is determined as follows: if the two transport layer protocol types are identical, Sproto is 1; otherwise, Sproto is 0.

[0055] Nodes with similarity exceeding a preset similarity threshold are selected as associated nodes. The preset similarity threshold is a discrimination boundary set based on statistical data of power IMS security policy conflicts. The preset similarity threshold is set as follows: Samples of policy conflict events occurring during normal operation of the power IMS network are collected; the lowest similarity distribution of security policy feature vectors of the same type of service in the samples before the policy conflict is calculated; and the lower limit of similarity that covers most related conflicts in the samples is selected as the preset similarity threshold. For example, in actual deployment, the preset similarity threshold can be set to 0.6, meaning that when the similarity value S of two policy feature vectors is greater than 0.6, they are determined to be associated nodes. Nodes with similarity values ​​S less than or equal to the preset similarity threshold are not included in the associated node set. If there are no nodes with similarity values ​​S exceeding the preset similarity threshold in the policy conflict graph, i.e., the associated node set is empty, then the entire policy conflict graph is directly determined to be a conflict subgraph, or the conflict subgraph is an empty graph.

[0056] Using associated nodes as boundaries, the minimum connected subgraph containing all associated nodes in the policy conflict graph is extracted as the conflict subgraph associated with the extracted policy feature vector. When the set of associated nodes is not empty, the minimum connected subgraph is extracted as follows: starting from any associated node, a breadth-first traversal is performed along the edges in the policy conflict graph, visiting all other nodes connected to the starting node with non-zero edge weights. During the traversal, all nodes and edges on the visited path are recorded. After the traversal, it is checked whether all associated nodes are included in the visited node set. If there are unincluded associated nodes, it means that the associated nodes are distributed in different connected components. In this case, each connected component is extracted separately and merged into a conflict subgraph. The conflict subgraph is a local graph of the policy conflict graph, which limits the range of historical conflicts highly associated with the extracted policy feature vector, avoiding the computational overhead of full graph analysis. If the set of associated nodes is empty and the conflict subgraph is determined to be empty, the subsequent conditional probability calculation is skipped, and any available address is directly selected from the available address pool as the media stream address.

[0057] Obtain the available address pool of the target disaster recovery cluster. For each candidate media stream address in the available address pool, calculate its conditional probability of appearing as a conflict node in the conflict subgraph. The available address pool is the set of media stream IP addresses in the target disaster recovery cluster that have not yet been assigned to other instances, provided by the virtualization infrastructure management component of the target disaster recovery cluster. A candidate media stream address is an IP address from the available address pool.

[0058] When the conflict subgraph is not empty, count the number of conflict records associated with candidate media stream addresses in the conflict subgraph. Each node in the conflict subgraph corresponds to a policy feature vector, which contains a protocol quintuple, and the protocol quintuple contains IP address information. Iterate through the source and destination IP addresses of the protocol quintuples of all nodes in the conflict subgraph, and accumulate the number of conflict events associated with nodes containing candidate media stream addresses. Specifically, for each node in the conflict subgraph, if the source or destination IP address of the protocol quintuple in the node's policy feature vector equals the candidate media stream address, then the sum of the edge weights of all connected edges in the conflict subgraph for that node is recorded as the number of conflict records associated with that node. Sum the number of conflict records associated with each node to obtain the number of conflict records associated with the candidate media stream address. Count the total number of all conflict records in the conflict subgraph; the total number of all conflict records is the sum of the edge weights of all edges in the conflict subgraph.

[0059] The conditional probability of a candidate media stream address appearing as a conflict node in the conflict subgraph is calculated as: P = Ca / Ct; where P represents the conditional probability of a candidate media stream address appearing as a conflict node in the conflict subgraph, Ca represents the number of conflict records associated with the candidate media stream address, and Ct represents the total number of all conflict records in the conflict subgraph. The value of P ranges from 0 to 1, and P is a dimensionless value.

[0060] The candidate media stream address with the lowest conditional probability is selected as the address with the lowest conflict probability and thus determined as the media stream address of the stateless IMS network element instance. If multiple candidate media stream addresses have the lowest and equal conditional probabilities, the candidate media stream address ranked first in the available address pool is selected as the media stream address of the stateless IMS network element instance. When the conflict subgraph is empty, the candidate media stream address ranked first in the available address pool is directly selected as the media stream address of the stateless IMS network element instance.

[0061] The entire process transforms address selection into graph mining and probabilistic reasoning based on historical conflict data. Existing technologies typically allocate media stream addresses using sequential or random address pooling, failing to consider the risk of newly allocated addresses conflicting with existing security policies in the vertical encryption authentication device. This method proactively avoids historically frequently conflicting addresses by constructing a policy conflict graph, identifying conflict subgraphs, and calculating conditional probabilities. It selects the address with the lowest conflict probability as the media stream address, thereby reducing the probability of policy release requests being rejected or triggering policy conflicts, ensuring successful transmission of policy release requests and secure continuation of the media stream.

[0062] A policy-based approval request is generated, carrying the media stream address and security policy identifier, and sent to the vertical encryption authentication device. The specific implementation process is as follows.

[0063] Extract the encrypted tunnel identifier from the security policy identifier. The security policy identifier is obtained during session context extraction and contains two subfields: the encrypted tunnel identifier and the policy version number. The extraction process is as follows: read the structured data of the security policy identifier, segment it according to the preset field separation rules of the security policy identifier, locate the subfield corresponding to the encrypted tunnel identifier, and extract the content of the encrypted tunnel identifier subfield as the value of the encrypted tunnel identifier. The encrypted tunnel identifier is a unique number established between the vertical encryption authentication device on the fault cluster side and the vertical encryption authentication device on the terminal side for transmitting media streams. It is used to identify the encrypted tunnel associated with the request in the policy approval request. The format of the encrypted tunnel identifier is the tunnel index value used internally by the vertical encryption authentication device, such as integer or string form.

[0064] Based on the encrypted tunnel identifier and media stream address, verification information is generated to validate the legitimacy of the policy release request. This verification information proves to the vertical encryption authentication device connected to the target disaster recovery cluster that the policy release request was generated by a legitimate disaster recovery scheduling component and not forged by an unauthorized third party. The verification information is generated as follows: the encrypted tunnel identifier and media stream address are concatenated to obtain a data string to be signed; using a pre-shared key between the resource scheduling component of the scheduling center and the vertical encryption authentication device connected to the target disaster recovery cluster, a hash operation message authentication code is calculated on the data string to be signed to obtain the verification information. The pre-shared key is a symmetric key established during system initialization by the key management function of the scheduling center and each vertical encryption authentication device through a key negotiation protocol; the key length is, for example, 256 bits. The hash operation message authentication code calculation uses a cryptographic hash function, and the generated verification information is a fixed-length byte string. The verification information generation process ensures that only the scheduling center, which holds the pre-shared key, can generate legitimate verification information. After receiving the policy release request, the vertical encryption authentication device connected to the target disaster recovery cluster can confirm the legitimacy of the request by recalculating the verification information and comparing it with the verification information carried in the request.

[0065] A policy release request is constructed, which includes the media stream address, security policy identifier, and verification information. The media stream address is determined by identifying the stateless IMS network element instance's media stream address using the address with the lowest collision probability. The security policy identifier is a complete security policy identifier obtained during session context extraction, including the encrypted tunnel identifier and policy version number. The verification information is a hash-based message authentication code generated based on the encrypted tunnel identifier and the media stream address. The policy release request is constructed using a structured data format, such as key-value pair format or markup language format. It contains three data fields: the media stream address field specifies the target address for the stateless IMS network element instance to receive media stream packets; the security policy identifier field informs the vertical encryption authentication device of the security policy associated with the corresponding media stream; and the verification information field proves the legitimacy of the request. After construction, the policy release request is serialized into a network transmission format.

[0066] A policy release request is sent to the vertical encryption authentication device connected to the target disaster recovery cluster. The sending process is as follows: The management address of the vertical encryption authentication device connected to the target disaster recovery cluster is obtained. This management address has been read from the network topology database and cached during the candidate cluster screening process. A Transmission Control Protocol (TCP) connection or a Secure Transport Layer (STL) connection is established with the management interface of the vertical encryption authentication device connected to the target disaster recovery cluster through the management address. The serialized policy release request is then sent to the vertical encryption authentication device connected to the target disaster recovery cluster via this connection. After sending, the resource scheduling component of the scheduling center waits for a policy release confirmation message from the vertical encryption authentication device connected to the target disaster recovery cluster.

[0067] The determined media stream address and extracted security policy identifier are encapsulated into a policy release request conforming to the vertical encryption authentication device interface specification, and verification information is attached to ensure the security and traceability of the request. Existing cross-cluster disaster recovery solutions do not send policy release requests to the vertical encryption authentication device, causing the media stream addresses of newly created network element instances to be discarded because they are not recognized by the security device. This method, by carrying the binding relationship between the encryption tunnel identifier and the media stream address when constructing the policy release request, enables the vertical encryption authentication device to associate the media stream address with the security policy identifier, thereby allowing the media stream of new instances to pass the security policy check. This solves the defect in existing disaster recovery solutions where the media plane cannot switch synchronously with the signaling plane.

[0068] After the vertical encryption authentication device establishes the binding between the media stream address and the security policy identifier, the stateless IMS network element instance continues the media stream corresponding to the media stream address. The specific implementation process is as follows.

[0069] The system receives a successful policy release confirmation message from the vertical encryption authentication device connected to the target disaster recovery cluster. This message is a response from the device after successfully processing the policy release request. The policy release request has been sent to the device via the management connection. Upon receiving the request, the device extracts the verification information and performs a validity check. If the check passes, it extracts the security policy identifier and media stream address, creating a binding entry between the media stream address and the security policy identifier in its internal policy table. After the binding is established, the device constructs the successful policy release confirmation message and returns it along the original management connection. The message contains three fields: media stream address, security policy identifier, and binding establishment result. The resource scheduling component in the scheduling center listens for and receives the successful policy release confirmation message on the management connection.

[0070] The binding establishment result between the media stream address and the security policy identifier is parsed from the successful policy approval confirmation message. The parsing process is as follows: The structured data of the successful policy approval confirmation message is read, and the value of the binding establishment result field is extracted. The binding establishment result field is an enumerated status flag set by the vertical encryption authentication device connected to the target disaster recovery cluster, used to indicate whether the binding relationship has been successfully established. When the binding establishment result field is a success status code, it indicates that the vertical encryption authentication device connected to the target disaster recovery cluster has completed the binding between the media stream address and the security policy identifier. Subsequent media stream packets arriving at the vertical encryption authentication device connected to the target disaster recovery cluster that match the media stream address will be allowed to pass and will no longer be discarded. When the binding establishment result field is a failure status code, it indicates that the binding establishment has failed. After parsing, it is determined whether the value of the binding establishment result field is equal to the success status code.

[0071] When the value of the binding establishment result field equals the success status code, the stateless IMS network element instance continues the media stream corresponding to the media stream address through the configured media forwarding program. The stateless IMS network element instance has been started and loaded with the signaling forwarding program and media forwarding program during the creation of the target disaster recovery cluster. The media forwarding program has established a media stream forwarding table based on the media forwarding configuration data at startup. The media forwarding configuration data records the remote address, remote port, local port, codec type, and media stream direction of the real-time transmission protocol for each session before the failure. The connection process is as follows: the resource scheduling component of the scheduling center sends a media stream connection instruction to the process manager of the stateless IMS network element instance, which carries the media stream address. The process manager of the stateless IMS network element instance passes the media stream connection instruction to the media forwarding program. The media forwarding program searches for a matching media stream configuration entry in the media stream forwarding table based on the media stream address, activates the forwarding function of the corresponding media stream configuration entry, starts receiving media packets from the terminal on the allocated media stream transmission port, and forwards them to the remote end according to the media stream direction identifier. For dispatch sessions that are already in a hold-on state, the media forwarding procedure continues to maintain a bidirectional forwarding channel for the media stream after activation, and the established dispatch call will not be interrupted.

[0072] When the value of the binding establishment result field is equal to the failure status code, the resource scheduling component of the scheduling center generates an alarm record and records the reason for the failure. At the same time, it re-executes the address determination with the lowest probability of conflict, excludes the current media stream address from the available address pool, selects a new media stream address, reconstructs and sends a new policy release request, until the value of the binding establishment result field in the received policy release success confirmation message is equal to the success status code.

[0073] By receiving a successful policy release confirmation message, parsing the binding establishment result, and immediately triggering the stateless IMS network element instance to continue the media stream after successful binding, seamless integration of security policy adaptation and service recovery is achieved. In existing technologies, due to the lack of policy synchronization with the vertical encryption authentication device, the media stream is still intercepted by the security device during continuation, leading to interruption of dispatch voice. This method uses policy release confirmation as a prerequisite for media stream continuation. The media stream continuation action is only executed after the policy binding relationship is established on the security device side, ensuring that media stream packets can pass the policy check of the security device. This eliminates packet loss gaps during media plane switching, enabling power IMS dispatch communication to achieve service continuity in cross-cluster disaster recovery scenarios.

[0074] All calculations involved in the embodiments are performed using dimensionless numerical values, and the preset parameters and thresholds in the calculations can be set by those skilled in the art according to actual conditions.

[0075] This technical solution can be flexibly deployed, for example, as embedded software running on device hardware, or installed on personal computers or other smart terminals with user interfaces, thus adapting to various hardware environments and usage requirements.

[0076] The above solutions can be implemented in software, hardware, firmware, or a combination thereof. When implemented in software, they are presented, in whole or in part, as a computer program product, containing one or more computer instructions or programs. When these instructions or programs are loaded and executed on a computer, results are produced corresponding to the processes or functions of the embodiments of this application. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one medium to another via wired or wireless means, such as from a website, server, or data center via wired means such as fiber optic cables, twisted-pair cables, or coaxial cables, or wireless means such as infrared or microwaves to another site. A computer-readable storage medium refers to any usable medium that a computer can access or a data storage device such as a server or data center that contains one or more usable media, including magnetic media such as floppy disks, hard disks, and magnetic tapes, optical media such as DVDs, and semiconductor media such as solid-state drives.

[0077] The specific working process of the system, device and module can be found in the method embodiment, and will not be repeated here.

[0078] The disclosed systems, devices, and methods can be implemented in other ways. The device embodiments are for illustrative purposes only, and the module division is only a logical division. In practice, different divisions can be implemented, such as merging or integrating multiple modules or components, or omitting some features. Coupling, direct coupling, or communication connections between the components can be achieved through interfaces, while indirect coupling or communication connections can take electrical, mechanical, or other forms.

[0079] The modules described as separate components may or may not be physically separated. The components shown as modules can be physical hardware or software, and can be deployed centrally or distributed across multiple network nodes. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0080] The functional modules in each embodiment can be integrated into one processing module, or they can exist independently, or two or more modules can be integrated into one.

[0081] If the functionality is implemented as a software module and used as an independent product, it can be stored in a computer-readable storage medium. Under this understanding, the substantial contribution of the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and contains instructions to cause a computer device, such as a personal computer, server, or network device, to execute all or part of the steps of the methods in the embodiments of this application. The storage medium includes any medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, or optical disk.

[0082] The above are merely specific embodiments of this application, and 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 fall within the scope of protection of this application.

Claims

1. A method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture, characterized in that, include: S1. When disaster recovery is triggered in a faulty cluster, the session context of the IMS network element in the faulty cluster is read from the distributed storage. The session context contains the security policy identifier. S2. Extract the policy version number from the security policy identifier, identify the available clusters other than the faulty cluster as candidate clusters, obtain the effective policy version and configuration shadow status of the vertical encryption authentication device connected to each candidate cluster, eliminate candidate clusters whose effective policy version and policy version number are inconsistent or whose configuration shadow status is mismatched, and after excluding the clusters in the fault propagation path from the remaining candidate clusters, determine the target disaster recovery cluster. S3. Create a stateless IMS network element instance in the target disaster recovery cluster and configure signaling forwarding and media forwarding. S4. Obtain the historical policy conflict logs of the vertical encryption authentication device connected to the target disaster recovery cluster. Based on the security policy identifier and the historical policy conflict logs, determine the address with the lowest conflict probability as the media stream address of the stateless IMS network element instance. S5. Generate a policy clearance request, carrying the media stream address and security policy identifier, and send it to the vertical encryption authentication device; S6. After the vertical encryption authentication device establishes the binding between the media stream address and the security policy identifier, the stateless IMS network element instance continues the media stream corresponding to the media stream address.

2. The method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture as described in claim 1, characterized in that, When disaster recovery is triggered by a failed cluster, the session context of the IMS network element within the failed cluster is read from distributed storage, including: Obtain disaster recovery trigger signals and faulty cluster identifiers; Query the session context corresponding to the faulty cluster identifier in the distributed storage; Extract the security policy identifier from the session context. The security policy identifier includes the encrypted tunnel identifier and the policy version number.

3. The method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture as described in claim 1, characterized in that, Extract the policy version number from the security policy identifier, identify available clusters other than the faulty cluster as candidate clusters, obtain the effective policy version and configuration shadow status of the vertical encryption authentication devices connected to each candidate cluster, and eliminate candidate clusters whose effective policy version and policy version number are inconsistent or whose configuration shadow status does not match. After excluding clusters on the fault propagation path from the remaining candidate clusters, determine the target disaster recovery cluster, including: Extract the policy version number from the security policy identifier; The available clusters other than the faulty cluster are identified as candidate clusters; Query the effective policy version and configuration shadow status of the vertical encryption authentication device connected to each candidate cluster; Compare the effective policy version with the policy version number, and determine whether the configured shadow status matches the effective policy version. Eliminate candidate clusters that do not meet any of these criteria. Obtain the fault type and fault source location of the faulty cluster. Based on the sharing relationship between the bearer network topology and power supply links, determine whether the remaining candidate clusters are on the fault propagation path starting from the fault source location, and exclude clusters on the fault propagation path. The target disaster recovery cluster is determined from the remaining candidate clusters after eliminating fault propagation paths.

4. The method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture as described in claim 3, characterized in that, Based on the sharing relationship between the bearer network topology and the power supply links, it is determined whether the remaining candidate clusters are on the fault propagation path starting from the fault source location. This includes: obtaining the bearer network topology connection relationship and the power supply link sharing relationship between the fault cluster and the remaining candidate clusters; starting from the fault source location, marking the fiber optic link nodes affected by the fault hop by hop along the bearer network topology connection relationship, and marking the candidate clusters sharing the same power supply circuit along the power supply link sharing relationship; and determining the candidate clusters located at the marked fiber optic link nodes or sharing the same power supply circuit as being on the fault propagation path.

5. A method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture, as described in claim 1, is characterized in that... Create a stateless IMS network element instance in the target disaster recovery cluster and configure signaling forwarding and media forwarding, including: Allocate computing resources to the target disaster recovery cluster and start stateless IMS network element instances; Obtain signaling forwarding configuration data and media forwarding configuration data from the session context; Load the signaling forwarding program and media forwarding program into the stateless IMS network element instance, and pass the signaling forwarding configuration data to the signaling forwarding program and the media forwarding configuration data to the media forwarding program.

6. The method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture as described in claim 1, characterized in that, Obtain the historical policy conflict logs of the vertical encryption authentication devices connected to the target disaster recovery cluster. Based on the security policy identifier and the historical policy conflict logs, determine the address with the lowest conflict probability as the media stream address of the stateless IMS network element instance, including: Request historical policy conflict logs from the vertical encryption authentication device connected to the target disaster recovery cluster; Extract policy feature vectors from security policy identifiers. The policy feature vectors contain security domain identifiers, service level identifiers, and protocol quintuples. In the historical strategy conflict log, a strategy conflict graph is constructed using the feature vectors of strategies that have historically clashed as nodes and the conflict frequency as the edge weights. Identify the conflict subgraphs in the policy conflict graph that are associated with the extracted policy feature vectors; Obtain the available address pool of the target disaster recovery cluster, and for each candidate media stream address in the available address pool, calculate the conditional probability of it appearing as a conflict node in the conflict subgraph. The candidate media stream address with the lowest conditional probability is selected as the address with the lowest conflict probability and determined as the media stream address of the stateless IMS network element instance.

7. A method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture, as described in claim 6, is characterized in that... Identifying conflict subgraphs in the policy conflict graph that are associated with the extracted policy feature vectors includes: calculating the similarity between the extracted policy feature vectors and the policy feature vectors of each node in the policy conflict graph; selecting nodes whose similarity exceeds a preset similarity threshold as associated nodes; and extracting the minimum connected subgraph containing all associated nodes in the policy conflict graph, using the associated nodes as boundaries, as the conflict subgraph associated with the extracted policy feature vectors.

8. A method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture, as described in claim 6, is characterized in that... For each candidate media stream address in the available address pool, calculate the conditional probability of it appearing as a conflict node in the conflict subgraph, including: counting the number of conflict records associated with the candidate media stream address in the conflict subgraph; counting the total number of all conflict records in the conflict subgraph; and using the ratio of the number of conflict records to the total number as the conditional probability of the candidate media stream address appearing as a conflict node in the conflict subgraph.

9. A method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture, as described in claim 1, is characterized in that... Generate a policy clearance request, carrying the media stream address and security policy identifier, and send it to the longitudinal encryption authentication device, including: Extract the encrypted tunnel identifier from the security policy identifier; Based on the encrypted tunnel identifier and media stream address, generate verification information to validate the legitimacy of the policy clearance request; Construct a policy-based allow request, which includes the media stream address, security policy identifier, and authentication information; Send a policy release request to the vertical encryption authentication device connected to the target disaster recovery cluster.

10. A method for dynamic disaster recovery across clusters of IMS virtualized network elements based on a stateless architecture, as described in claim 1, is characterized in that... After the vertical encryption authentication device establishes the binding between the media stream address and the security policy identifier, the stateless IMS network element instance continues the media stream corresponding to the media stream address, including: Receive a policy approval success confirmation message returned by the vertical encryption authentication device connected to the target disaster recovery cluster; Parse the binding result between the media stream address and the security policy identifier from the successful policy approval confirmation message; After the binding establishment result indicates that the binding has been established, the stateless IMS network element instance continues the media stream corresponding to the media stream address through the configured media forwarding program.

Images