Cross-domain fault positioning method and device of VoLTE network, and medium

By collecting multi-source data from the VoLTE network to generate a dynamic topology map and using the LightGBM algorithm to calculate the root cause, the efficiency and accuracy issues of VoLTE network fault location are solved, achieving efficient and accurate cross-domain fault location.

CN120856547APending Publication Date: 2025-10-28广州市申迪计算机系统有限公司
View PDF 0 Cites 2 Cited by

Patent Information

Application Number
CN202511040428.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-07-28
Publication Date
2025-10-28

AI Technical Summary

Technical Problem

Fault location in VoLTE networks suffers from a lack of complete network topology data, fragmented and redundant alarm information, and complex and diverse root causes of faults, making it difficult to accurately locate cross-domain faults. Existing systems cannot automatically construct complete topology maps, relying on manual experience, which is time-consuming and costly.

Method used

Multi-source data is collected through the LLDP protocol and network management interface to generate a dynamic end-to-end topology map. Combined with the LightGBM algorithm and influence factor calculation, the root cause of the fault is automatically located, and the faulty node and related links are marked with a dynamic topology map.

Benefits of technology

It improves the efficiency and accuracy of fault location, dynamically generates topology maps to intuitively display fault points, supports bearer layer priority analysis, and reduces maintenance costs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120856547A_ABST
    Figure CN120856547A_ABST
Patent Text Reader

Abstract

The invention relates to the field of mobile communication network operation and maintenance, in particular to a cross-domain fault positioning method and device of a VoLTE (Voice over Long Term Evolution) network and a medium, mainly comprising the following steps: collecting multi-source data of a physical layer, a virtualization layer, a bearing layer and a service layer in a VoLTE service chain; based on the network architecture hierarchy and the physical link information of the multi-source data, generating a dynamic end-to-end topological graph through association; when a plurality of network element warnings of a service layer are detected, checking an equipment state of a bearing layer associated with the service layer; if the devices of the bearing layer give an alarm at the same time, judging that the fault of the bearing layer is a root cause; if it is not detected that the devices of the bearing layer give an alarm at the same time, calculating a root cause probability based on a preset influence factor, and taking the node with the maximum probability as a root cause; and marking a node corresponding to the root cause and an associated link of the root cause in the dynamic end-to-end topological graph. According to the invention, the fault in the VoLTE network can be efficiently and accurately analyzed and positioned.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of mobile communication network operation and maintenance, and in particular to a method, apparatus and medium for cross-domain fault location of VoLTE networks. Background Technology

[0002] With the rapid development of 4G / 5G technologies, VoLTE technology is being used more and more widely, and the complexity of network services is constantly increasing. VoLTE not only has a complex network topology itself, but also needs to work in coordination with 4G / 5G service networks. Due to the diverse service scenarios and the massive amount of network data, the analysis and fault location of VoLTE networks face enormous challenges.

[0003] Currently, VoLTE network operation and maintenance mainly relies on manual experience, which presents three major pain points: first, a lack of complete network topology data; second, fragmented and redundant alarm information; and third, complex and diverse root causes of faults. These problems make it difficult to grasp the network status in a timely manner and accurately locate faults. Specifically, traditional methods rely on static network element registration analysis, which cannot dynamically reflect the end-to-end path of VoLTE services, resulting in inaccurate fault location. Moreover, the network architecture is complex, involving the collaboration of multiple networks such as EPC, 5GC, and VoLTE, but existing systems cannot automatically construct a complete VoLTE network topology map, affecting global fault analysis. Alarm and performance indicator data are scattered across different systems, requiring manual collection and correlation, which is inefficient and prone to missing key information. The lack of intelligent alarm aggregation and root cause analysis mechanisms makes it difficult for operation and maintenance personnel to quickly identify core problems. VoLTE services involve multiple links such as EPC, 5GC, and VoLTE, and traditional methods cannot automatically identify cross-domain faults. Manual troubleshooting is time-consuming and relies on expert experience, resulting in high maintenance costs and making it difficult to meet the needs of large-scale network operation and maintenance.

[0004] Therefore, there is an urgent need for a more efficient and accurate method for cross-domain fault location in VoLTE networks. Summary of the Invention

[0005] This application provides a cross-domain fault location method for VoLTE networks, which can efficiently and accurately analyze and locate faults in VoLTE networks.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a method for cross-domain fault location in a VoLTE network, comprising:

[0008] S1: Collect multi-source data from the physical layer, virtualization layer, bearer layer and service layer in the VoLTE service chain through the LLDP protocol and network management interface. The multi-source data includes at least device resource status, port traffic, KPI indicators and alarm information.

[0009] S2: Based on the network architecture hierarchy and physical link information of the multi-source data, a dynamic end-to-end topology diagram is generated. The nodes of the dynamic end-to-end topology diagram include, in sequence, device name, virtual machine name, physical machine name, TOR, EOR, and CE.

[0010] S3: When multiple network element warnings are detected at the service layer, check the device status of the bearer layer associated with the service layer;

[0011] S4: If all devices in the carrying layer issue warnings simultaneously, the fault in the carrying layer is determined to be the root cause; if no warnings are detected from all devices in the carrying layer simultaneously, the root cause probability is calculated based on a preset influence factor, and the node with the highest probability is taken as the root cause.

[0012] S5: Mark the node corresponding to the root cause and the associated link of the root cause in the dynamic end-to-end topology diagram.

[0013] In a preferred embodiment of this application, it can be further configured that, between S4 and S5, the following is also included:

[0014] S4': Process the network element warning, the matching results of the network element warning and the root cause using the LightGBM algorithm to obtain the root cause analysis results, and determine the root cause based on the root cause analysis results.

[0015] In a preferred example of this application, the preset influence factors may be further configured to include basic weights, historical failure rates, time period factors, and special weights preset according to the network element type.

[0016] In a preferred embodiment of this application, the node corresponding to the root cause and the associated links of the root cause can be further configured to be marked in the dynamic end-to-end topology graph, including:

[0017] The node corresponding to the root cause and the associated links of the root cause are highlighted in the dynamic end-to-end topology diagram.

[0018] In a preferred embodiment of this application, S1 may further include:

[0019] Collect CN2 layer resource data and link information.

[0020] In a preferred embodiment of this application, S1 may further include:

[0021] Collect call setup success rate, call drop rate, bearer layer port traffic, and CN2 layer port traffic.

[0022] Secondly, this application provides a cross-domain fault location device for a VoLTE network, the device comprising:

[0023] The data acquisition module is used to collect multi-source data from the physical layer, virtualization layer, bearer layer and service layer in the VoLTE service chain through the LLDP protocol and the network management interface. The multi-source data includes at least device resource status, port traffic, KPI indicators and alarm information.

[0024] The topology construction module is used to generate a dynamic end-to-end topology diagram based on the network architecture hierarchy and physical link information of the multi-source data. The nodes of the dynamic end-to-end topology diagram include, in sequence, device name, virtual machine name, physical machine name, TOR, EOR and CE.

[0025] The positioning module is used to check the device status of the bearer layer associated with the service layer when multiple network element warnings are detected in the service layer; if the devices of the bearer layer are warning at the same time, the fault of the bearer layer is determined to be the root cause; if no devices of the bearer layer are warning at the same time, the root cause probability is calculated based on a preset influence factor, and the node with the highest probability is taken as the root cause.

[0026] The display module is used to mark the node corresponding to the root cause and the associated links of the root cause in the dynamic end-to-end topology map.

[0027] Thirdly, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the cross-domain fault location method for VoLTE networks as described in any of the preceding claims.

[0028] Fourthly, this application provides a computer-readable storage medium storing a program, wherein when the program is executed by a processor, it implements the cross-domain fault location method for VoLTE networks as described in any of the preceding claims.

[0029] Fifthly, this application provides a computer program product including computer instructions that, when executed by a processor, implement the steps of the cross-domain fault location method for VoLTE networks as described in any of the preceding claims.

[0030] In summary, compared with the prior art, the beneficial effects of the technical solution provided in this application include at least the following:

[0031] By constructing a dynamic network topology and intelligent alarm association, the root cause of faults is automatically located, improving the efficiency of fault location. It overcomes the problem of isolated data from various network layers and the difficulty in associating EPC, 5GC, and VoLTE across layers. By restoring the end-to-end path, it supports bearer layer priority analysis and quickly locates the fault level.

[0032] By aggregating relevant alarms using the maximum matching rule and filtering high-probability root causes through impact factor calculation, the accuracy of root cause localization is improved.

[0033] Dynamically generate VoLTE network topology maps, mark faulty nodes and related links, and provide root cause dashboards to intuitively display fault points and causes, improving the convenience of fault location and providing visualized data for subsequent analysis. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating a cross-domain fault location method for a VoLTE network, as provided in one embodiment of this application.

[0035] Figure 2 This is a functional hierarchy diagram of a cross-domain fault location method for a VoLTE network provided in one embodiment of this application.

[0036] Figure 3 This is a flowchart illustrating the warning data processing of a cross-domain fault location method for a VoLTE network, provided as an embodiment of this application.

[0037] Figure 4 This is a block diagram of a cross-domain fault location device for a VoLTE network provided in one embodiment of this application. Detailed Implementation

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

[0039] In one embodiment of this application, a deep learning-based method for real-time estimation of vehicle road slope is provided. Please refer to [link / reference]. Figure 1 As shown, the method includes:

[0040] S1: Collect multi-source data from the physical layer, virtualization layer, bearer layer and service layer in the VoLTE service chain through the LLDP protocol and network management interface. The multi-source data includes at least device resource status, port traffic, KPI indicators and alarm information.

[0041] S2: Based on the network architecture hierarchy and physical link information of the multi-source data, a dynamic end-to-end topology diagram is generated. The nodes of the dynamic end-to-end topology diagram include, in sequence, device name, virtual machine name, physical machine name, TOR, EOR, and CE.

[0042] S3: When multiple network element warnings are detected at the service layer, check the device status of the bearer layer associated with the service layer;

[0043] S4: If all devices in the carrying layer issue warnings simultaneously, the fault in the carrying layer is determined to be the root cause; if no warnings are detected from all devices in the carrying layer simultaneously, the root cause probability is calculated based on a preset influence factor, and the node with the highest probability is taken as the root cause.

[0044] S5: Mark the node corresponding to the root cause and the associated link of the root cause in the dynamic end-to-end topology diagram.

[0045] In specific implementation, such as Figure 2 As shown, the method comprises three levels. The data acquisition layer is responsible for collecting data and inputting it into the analysis layer. After processing the data, the analysis layer outputs the analysis results to the visualization layer.

[0046] The data acquisition layer collects data from various layers of the VoLTE network, including:

[0047] Resource data: Device, virtual machine, physical machine, bearer layer, CN2 layer resource data, link information, alarm information;

[0048] Performance data: EPC / 5GC KPIs (e.g., call setup success rate, call drop rate), bearer layer port traffic, CN2 layer port traffic.

[0049] During data collection, a hybrid approach using the LLDP protocol and network management interface is employed to ensure data integrity.

[0050] The analysis layer's functions include dynamic service chain construction, alarm correlation, and root cause analysis. Specifically, based on the network architecture hierarchy and physical link information of the multi-source data, a dynamic end-to-end topology diagram is generated. The nodes of the dynamic end-to-end topology diagram include, in sequence, device name, virtual machine name, physical machine name, TOR, EOR, and CE, as shown in Table 1.

[0051]

[0052]

[0053] Table 1

[0054] The alarm correlation function of the analysis layer performs alarm correlation analysis on the acquired data, such as... Figure 3As shown. Specifically, if multiple network elements alarm simultaneously, cross-domain associations are prioritized. For example, if both the SGW and P-CSCF are abnormal, it is determined to be a bearer problem. First, based on the network architecture hierarchy and physical link information of the multi-source data, a dynamic end-to-end topology map is generated. The nodes of the dynamic end-to-end topology map include, in sequence, device name, virtual machine name, physical machine name, TOR, EOR, and CE. Then, when multiple network element warnings are detected at the service layer, the device status of the bearer layer associated with the service layer is checked. If the devices of the bearer layer are alarming simultaneously, the bearer layer failure is determined to be the root cause.

[0055] The analysis layer also constructs a multi-dimensional association rule base, including:

[0056] (1) Cross-domain association rules

[0057] Define the PSBC-SCSCF-MMTEL three-level linkage rules;

[0058] Establish ENUMDNS-SCSCF-TOR call routing exception rules;

[0059] Configure EOR-TOR media stream anomaly association rules;

[0060] (2) Time dimension rules

[0061] Multiple network element alarms within 5 minutes are considered related events;

[0062] Alarms issued within 30 seconds of the same session are considered related events.

[0063] (3) Topology Dependency Rules

[0064] Define upstream and downstream dependencies based on the IMS network architecture;

[0065] Upstream network element failures are prioritized as the root cause.

[0066] The analysis layer also constructs an impact factor model, including:

[0067] (1) Network element weight allocation

[0068] PSBC: 35% (Core Access Network Element);

[0069] SCSCF: 25% (Session Control Core);

[0070] MMTEL: 20% (Multimedia Business Engine);

[0071] ENUMDNS: 10% (number routing);

[0072] EOR / TOR: 5% (Media and Signaling Boundary).

[0073] (2) Dynamic probability calculation

[0074] Calculate the failure probability of each network element based on historical alarm data;

[0075] Consider time period factors (different weights for peak and off-peak hours);

[0076] Special weight is included in the network change window.

[0077] The analysis layer also incorporates an intelligent aggregation engine, including:

[0078] (1) Rule priority execution mechanism

[0079] An exact match rule immediately triggers aggregation;

[0080] Some matching rules have entered the confirmation queue;

[0081] The unmatched alarm will trigger the machine learning analysis process.

[0082] (2) Multi-level aggregation strategy

[0083] Level 1: Precise rule matching (cross-domain key rules);

[0084] Level 2: Fuzzy rule matching (same as session / time window);

[0085] Level 3: Model prediction association (LightGBM algorithm).

[0086] In summary, the analysis layer prioritizes cross-domain rule matching results as high-probability fault points, or prioritizes alarms from high-weight network elements as high-probability fault points.

[0087] The visualization layer provides a network topology map and a fault location dashboard, including:

[0088] Topology diagram: Dynamically displays the VoLTE service chain, highlighting abnormal network elements (faulty network elements are marked in red);

[0089] Root Cause Dashboard: Outputs fault alarms and root cause location information.

[0090] In this embodiment, by constructing a dynamic network topology and intelligent alarm association, the root cause of the fault is automatically located, improving the efficiency of fault location. It overcomes the problem of isolated network data and difficulty in associating EPC, 5GC, and VoLTE across layers. By restoring the end-to-end path and supporting bearer layer-priority analysis, the fault level is quickly located. Relevant alarms are aggregated using the maximum matching rule, and high-probability root causes are filtered through influence factor calculation, improving the accuracy of root cause location. A dynamically generated VoLTE network topology map is provided, marking fault nodes and associated links, offering a root cause dashboard that intuitively displays the fault point and its cause, improving the convenience of fault location and providing visualized data for subsequent analysis.

[0091] In some embodiments, between S4 and S5, the following is further included:

[0092] S4': Process the network element warning, the matching results of the network element warning and the root cause using the LightGBM algorithm to obtain the root cause analysis results, and determine the root cause based on the root cause analysis results.

[0093] In practice, data preprocessing is performed first to extract alarm features. Key features are extracted from the raw alarm data, including:

[0094] Time characteristics: alarm timestamp, alarm interval (e.g., within 5 minutes), time period (busy / off-peak hours).

[0095] Topology characteristics: network element type (e.g., P-CSCF, S-CSCF), network element weight (PSBC: 35%), upstream and downstream dependencies (e.g., PSBC→S-CSCF→MMTEL).

[0096] Business characteristics: alarm code (e.g., IMS-5003), severity level (urgent / important / general), additional parameters (e.g., number of timeouts, relay group).

[0097] Historical statistical characteristics: historical failure probability of network elements, number of times similar alarms are associated.

[0098] Then, model training is performed, including the following steps:

[0099] Input data: Historical alarm data (labeled associated alarm events, such as alarm combinations corresponding to "DNS resolution failure").

[0100] Training objective: To learn the correlation patterns between alarms (such as cross-domain correlation, time synchronization, and topology dependency).

[0101] Decision tree splitting: Construct multiple decision trees based on feature importance (such as "time interval" or "network element type") to optimize association prediction.

[0102] Loss function: Use log loss or cross-entropy to minimize the false positive rate (e.g., aggregate irrelevant alarm errors).

[0103] Next, real-time prediction is performed. Common features are extracted from real-time alarm data and input into the model to predict the correlation probability between alarms. The correlation confidence score (e.g., 89.1%) for each alarm combination is output, and a comprehensive decision is made by combining the results from the rule engine.

[0104] The collaborative process with the rules engine includes:

[0105] Rule priority: Alarms that completely match predefined rules (such as "P-CSCF+S-CSCF alarm simultaneously → bearer problem") are directly aggregated.

[0106] Model Supplement: Alarms for unmatched rules are entered into LightGBM analysis, and probabilistic correlation results are output.

[0107] Dynamic weight adjustment: Adjust the confidence level of the model output based on factors such as time period and network change window.

[0108] In summary, the model's input data includes:

[0109] 1. Structured alarm data (feature vector of each alarm record), as shown in Table 2.

[0110]

[0111] Table 2

[0112] 2. Topology and historical data (external relational information):

[0113] Network element dependencies (e.g., S-CSCF depends on P-CSCF);

[0114] Network element weight (PSBC: 35%, S-CSCF: 25%);

[0115] Historical failure probability (e.g., P-CSCF failure rate of 10% in the past 30 days).

[0116] The model's output data includes:

[0117] 1. The results of the association analysis are shown in Table 3:

[0118]

[0119] Table 3

[0120] 2. The intermediate results of the model include:

[0121] Alarm feature importance ranking (e.g., "time interval" has the highest weight).

[0122] A prediction probability matrix (e.g., the correlation probability between alarm A and alarm B is 0.891). In some embodiments, the root cause analysis and localization process includes:

[0123] The original alarm data is shown in Table 4:

[0124]

[0125]

[0126] Table 4

[0127] Next, the analysis layer performs correlation analysis, and the results are shown in Table 5:

[0128]

[0129] Table 5

[0130] Then, faults are detected by the degradation of the 1-minute golden indicator. Combined with indicator-based, link-based, other alarms and operation logs, a four-layer analysis is performed according to the business layer, virtual layer, physical layer and bearer layer to accurately locate the problem boundary.

[0131] The following analysis is conducted to begin analyzing the deterioration of the 1-minute gold indicator:

[0132] 1. Link Concentration Analysis: Query all link failure alarms within 10 minutes in the pool corresponding to the province with the deteriorated indicator. Analyze the target IP and target network element name in the alarm. When there are 2 or more link alarms, they all point to the same peer network element name or IP. Compare the target network element IP or hostname to see if it is an IMS network element within the same pool or province. If it is, it is an intra-domain problem; otherwise, it is an extra-domain problem.

[0133] 2. Non-link alarm analysis, combining and associating the four layers.

[0134] (1) Query all alarms within 10 minutes in the pool corresponding to the province with the deteriorated indicator (link-related alarms need to be removed).

[0135] (2) If a single PSBC within the province experiences performance degradation, the IMS virtual layer alarm will be filtered.

[0136] (3) When the PSBC registration index drops, if the associated switch is a PSBC switch, only associate it with switches in the same data center (the PSBC and regional identifiers are in the data communication equipment table).

[0137] (4) Retrieve operation logs: Check if there are any operation logs for the network elements involved within 1 hour.

[0138] 3. Based on step 2, perform specific layer-by-layer location.

[0139] Positioning is a problem of the bearing layer:

[0140] (1) If there are EOR or DCGW alarms, and multiple Tor alarms, multiple physical machine alarms, and multiple VNF alarms, then the problem is located in the bearer layer. The alarms should be merged according to EOR or DCGW.

[0141] (2) If there are eor or dcgw alarms, and there is only one tor alarm, then the problem is located in the bearer layer, and the alarms should be merged according to tor.

[0142] (3) If there are no EOR or DCGW alarms, but there are multiple sets of Tor alarms, then the problem is located in the bearer layer. If there are EOR alarms, merge them according to EOR alarms; otherwise, merge them according to EOR alarms.

[0143] (4) If there are no EOR or DCGW alarms, but multiple Tor alarms, the problem is likely a bearer layer issue. Alarms should be merged according to Tor.

[0144] (5) If there are no EOR or DCGW alarms, and there are only one or a group of Tors and multiple physical machines or no physical machine alarms, then locate the bearer layer problem and merge the alarms according to Tors.

[0145] If the location is a physical machine problem, then:

[0146] (1) If there are EOR or DCGW alarms and multiple Tor alarms, but only one physical machine alarm, then the problem is identified as a physical machine issue, and alarms should be merged according to the physical machine.

[0147] (2) If there are no EOR or DCGW alarms, and there is only one or a group of Tor alarms and one physical machine alarm, or only one physical machine alarm, then locate the physical machine problem and merge them according to the physical machine.

[0148] If the issue is identified as a business layer or a virtual layer problem, then:

[0149] (1) There are EOR or DCGW alarms, and multiple Tor alarms and multiple physical machine alarms, but only one VNF alarm. The alarms are merged according to NVF, and then it is determined whether there is a virtual layer alarm. If there is, the problem is located as a virtual layer issue.

[0150] (2) If there are EOR or DCGW alarms, and the number of alarms of network elements under DCGW or EOR is less than 50%, merge them according to VNF, and then determine whether there are virtual layer alarms. If there are, the problem is located as a virtual layer issue.

[0151] (3) If there are EOR or DCGW alarms, and the number of alarms on network elements under DCGW or EOR is less than 50%, then the problem is identified as a service layer issue and should be merged according to EOR or DCGW.

[0152] (4) If there are no EOR or DCGW alarms, and more than 50% of the network elements under the DC to which the degraded network element belongs have alarms, then it is a service layer problem. Merge them according to the EOR or DCGW under this DC.

[0153] (5) If there are no EOR or DCGW alarms, and less than 50% of the network elements under the DC to which the degraded network element belongs have alarms, then it is a service layer problem and should be merged according to NVF.

[0154] In some embodiments, the preset influence factors include basic weights, historical failure rates, time period factors, and special weights preset according to the network element type.

[0155] In this embodiment, the accuracy of identifying root causes is improved by constructing influencing factors.

[0156] In some embodiments, marking the node corresponding to the root cause and the associated links of the root cause in the dynamic end-to-end topology graph includes:

[0157] The node corresponding to the root cause and the associated links of the root cause are highlighted in the dynamic end-to-end topology diagram.

[0158] In this embodiment, the intuitiveness of displaying root causes is improved, and the analysis efficiency of staff is increased.

[0159] In some embodiments, S1 further includes:

[0160] Collect CN2 layer resource data and link information.

[0161] Collect call setup success rate, call drop rate, bearer layer port traffic, and CN2 layer port traffic.

[0162] In this embodiment, more comprehensive data was collected, improving the accuracy of root cause localization.

[0163] This application also provides a cross-domain fault location device for VoLTE networks; please refer to [link to relevant documentation]. Figure 4 As shown, the device includes:

[0164] The data acquisition module 100 is used to collect multi-source data from the physical layer, virtualization layer, bearer layer and service layer in the VoLTE service chain through the LLDP protocol and the network management interface. The multi-source data includes at least device resource status, port traffic, KPI indicators and alarm information.

[0165] The topology construction module 200 is used to generate a dynamic end-to-end topology diagram based on the network architecture hierarchy and physical link information of the multi-source data. The nodes of the dynamic end-to-end topology diagram include, in sequence, device name, virtual machine name, physical machine name, TOR, EOR and CE.

[0166] The positioning module 300 is used to check the device status of the bearer layer associated with the service layer when multiple network element warnings are detected in the service layer; if the devices of the bearer layer are simultaneously warned, the fault of the bearer layer is determined to be the root cause; if no simultaneous warnings are detected in the bearer layer devices, the root cause probability is calculated based on a preset influence factor, and the node with the highest probability is taken as the root cause.

[0167] Display module 400 is used to mark the node corresponding to the root cause and the associated link of the root cause in the dynamic end-to-end topology map.

[0168] The functions of each module in the above-mentioned cross-domain fault location device for VoLTE network correspond to the steps in the above-mentioned cross-domain fault location method embodiment for VoLTE network, and their functions and implementation processes will not be described in detail here.

[0169] This application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the cross-domain fault location method for VoLTE networks as described in any of the above embodiments.

[0170] This application also provides a computer-readable storage medium storing a program. The computer-readable storage medium refers to a data storage medium, which may include, but is not limited to, floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or Memory Sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The working process, details, and technical effects of the computer-readable storage medium provided in this embodiment can be found in the above embodiment regarding a cross-domain fault location method for VoLTE networks, and will not be repeated here.

[0171] The application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the cross-domain fault location method for VoLTE networks as described in any of the above embodiments.

[0172] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM).

[0173] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. The above embodiments only illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that for those skilled in the art, several modifications and improvements can be made without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for cross-domain fault location in a VoLTE network, characterized in that, include: S1: Collect multi-source data from the physical layer, virtualization layer, bearer layer and service layer in the VoLTE service chain through the LLDP protocol and network management interface. The multi-source data includes at least device resource status, port traffic, KPI indicators and alarm information. S2: Based on the network architecture hierarchy and physical link information of the multi-source data, a dynamic end-to-end topology diagram is generated. The nodes of the dynamic end-to-end topology diagram include, in sequence, device name, virtual machine name, physical machine name, TOR, EOR, and CE. S3: When multiple network element warnings are detected at the service layer, check the device status of the bearer layer associated with the service layer; S4: If all devices in the carrying layer issue warnings simultaneously, the fault in the carrying layer is determined to be the root cause; if no warnings are detected from all devices in the carrying layer simultaneously, the root cause probability is calculated based on a preset influence factor, and the node with the highest probability is taken as the root cause. S5: Mark the node corresponding to the root cause and the associated link of the root cause in the dynamic end-to-end topology diagram.

2. The cross-domain fault location method for VoLTE networks according to claim 1, characterized in that, Between S4 and S5, the following is also included: S4': Process the network element warning, the matching results of the network element warning and the root cause using the LightGBM algorithm to obtain the root cause analysis results, and determine the root cause based on the root cause analysis results.

3. The cross-domain fault location method for VoLTE networks according to claim 2, characterized in that, The preset influence factors include basic weights, historical failure rates, time period factors, and special weights preset according to the network element type.

4. The cross-domain fault location method for VoLTE networks according to claim 1, characterized in that, The dynamic end-to-end topology map is used to mark the node corresponding to the root cause and the associated links of the root cause, including: The node corresponding to the root cause and the associated links of the root cause are highlighted in the dynamic end-to-end topology diagram.

5. The cross-domain fault location method for VoLTE networks according to claim 1, characterized in that, The S1 also includes: Collect CN2 layer resource data and link information.

6. The cross-domain fault location method for VoLTE networks according to claim 5, characterized in that, The S1 also includes: Collect call setup success rate, call drop rate, bearer layer port traffic, and CN2 layer port traffic.

7. A cross-domain fault location device for a VoLTE network, characterized in that, include: The data acquisition module is used to collect multi-source data from the physical layer, virtualization layer, bearer layer and service layer in the VoLTE service chain through the LLDP protocol and the network management interface. The multi-source data includes at least device resource status, port traffic, KPI indicators and alarm information. The topology construction module is used to generate a dynamic end-to-end topology diagram based on the network architecture hierarchy and physical link information of the multi-source data. The nodes of the dynamic end-to-end topology diagram include, in sequence, device name, virtual machine name, physical machine name, TOR, EOR and CE. The location module is used to check the device status of the bearer layer associated with the service layer when multiple network element warnings are detected in the service layer. If the devices of the bearer layer are warning at the same time, the fault of the bearer layer is determined to be the root cause. If no device in the carrying layer issues a warning, the root cause probability is calculated based on a preset impact factor, and the node with the highest probability is taken as the root cause. The display module is used to mark the node corresponding to the root cause and the associated links of the root cause in the dynamic end-to-end topology map.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the cross-domain fault location method for VoLTE networks as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program, wherein when the program is executed by a processor, it implements the cross-domain fault location method for a VoLTE network as described in any one of claims 1 to 6.

10. A computer program product comprising computer instructions, characterized in that, When executed by a processor, the computer instructions implement the steps of the cross-domain fault location method for VoLTE networks as described in claims 1 to 6.

Citation Information

Cited By

  • Trinity full-link intelligent monitoring system from new energy station to centralized control center

    CN121710539A

  • Trinity full-link intelligent monitoring system from new energy station to centralized control center

    CN121710539B