Link fault analysis method, electronic device, storage medium and program product

Abstract

The invention provides a link fault analysis method, electronic equipment, a storage medium and a program product, and the method comprises the steps: obtaining a topological link of network networking, the topological link comprises multiple layers of equipment, and each layer of equipment comprises multiple pieces of equipment; monitoring a key index of each piece of equipment in the topological link; and under the condition that the key index of the first equipment is abnormal, performing layer-by-layer analysis on the multi-layer equipment in the topological link, and determining a fault reason according to an analysis result. Therefore, under the condition that a link fault is caused by the abnormal key index of a certain device in the link, due to the fact that layer-by-layer analysis can be carried out on multiple layers of devices in the link, whether the link fault is an individual fault (the device has a fault) or a group fault (a common problem of multiple devices) can be determined according to the analysis result; therefore, the reason of the link fault can be quickly determined, and the accuracy of the link fault analysis result is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of network communication, and in particular to a link fault analysis method, an electronic device, a storage medium and a program product. BACKGROUND

[0002] With the rapid development of 5G technology, 5G technology is increasingly applied in various network scenarios, such as 5G To Business (ToB) park scenarios. In these network scenarios based on 5G technology, in order to ensure the reliability of the network link, it is usually necessary to monitor the network link, and when a link failure is monitored, the cause of the failure is analyzed and the failure is repaired to restore the link to normal.

[0003] In related technologies, when monitoring the network link, if the indicators of a certain device are abnormal, it is considered that the device has failed, and the cause of the link failure is located to the device. However, in actual applications, network links based on 5G technology are usually complex, and the causes of link failures are also complex. When analyzing link failures based on the scheme in related technologies, the determined cause of the failure is often not the real cause of the link failure, resulting in low accuracy of the analysis result of the link failure. SUMMARY

[0004] The present application provides a link fault analysis method, an electronic device, a storage medium and a program product, which are used to solve the problem of low accuracy of the analysis result of the link failure in related technologies.

[0005] To solve the above technical problems, the present application is implemented as follows:

[0006] In a first aspect, a link fault analysis method is provided, comprising:

[0007] Obtaining a topology link of network networking, the topology link including multiple layers of devices, each layer of devices including a plurality of devices;

[0008] Monitoring key indicators of each device in the topology link;

[0009] In the case that the key indicators of the first device are abnormal, performing layer-by-layer analysis on the multiple layers of devices in the topology link, and determining the cause of the failure according to the analysis result.

[0010] In a second aspect, an electronic device is provided, comprising:

[0011] A processor;

[0012] A memory for storing instructions executable by the processor;

[0013] The processor is configured to execute the instructions to implement the method according to the first aspect.

[0014] In a third aspect, a computer-readable storage medium is provided, which, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method according to the first aspect.

[0015] In a fourth aspect, a computer program product is provided, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to perform some or all of the steps in the method according to the first aspect.

[0016] In the embodiments of the present application, when the link monitoring and fault analysis are performed on the links of a certain network, the topology link of the network can be acquired, the topology link includes multiple layers of devices, each layer of devices includes multiple devices, then the key indicators of each device in the topology link are monitored, for any first device, when the key indicators of the first device are monitored to be abnormal, the multiple layers of devices in the topology link can be analyzed layer by layer, and the cause of the link fault can be determined according to the analysis result. In this way, when the key indicators of a certain device in the link are abnormal and cause the link fault, since the multiple layers of devices in the link can be analyzed layer by layer, the link fault is a single fault (the device itself is faulty) or a group fault (a common problem of multiple devices) can be determined according to the analysis result, so that the cause of the link fault can be quickly determined, and the accuracy of the analysis result of the link fault is improved. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0018] Figure 1 is a flowchart of the link fault analysis method of an embodiment of the present application;

[0019] Figure 2 is a schematic diagram of the multiple layers of devices included in the topology link of an embodiment of the present application;

[0020] Figure 3 is a schematic diagram of the link fault analysis method of an embodiment of the present application;

[0021] Figure 4 is a schematic diagram of the hardware network of the 5G ToB park of an embodiment of the present application;

[0022] Figure 5 is a schematic diagram of XDR data according to an embodiment of the present application;

[0023] Figure 6 is a schematic diagram of updating a full link configuration table according to an embodiment of the present application;

[0024] Figure 7 is a schematic diagram of the structure of an electronic device according to an embodiment of the present application;

[0025] Figure 8 is a schematic diagram of the structure of a link fault analysis device according to an embodiment of the present application. DETAILED DESCRIPTION

[0026] In the related art, when monitoring the links of a network, if an index of a certain device is found to be abnormal, it is considered that the device has failed, and the cause of the link failure is located to the device. For example, if a certain index of device 1 is found to be abnormal, it is considered that device 1 has failed, and it is determined that device 1 causes the link failure, i.e., the cause of the link failure is device 1.

[0027] However, for network networking based on 5G technology, the link is usually complex, and the cause of the link failure is also complex. When the link failure is analyzed based on the scheme in the related art, the determined cause of the failure is often not the real cause of the link failure, resulting in low accuracy of the analysis result of the link failure. For example, there is interaction of service data between device 1 and device 2, device 1 does not fail, and device 2 fails. When device 1 and device 2 interact data, since device 2 has failed, it will cause data interaction error, and further cause a certain index of device 1 to be abnormal. In this case, based on the scheme in the related art, it is considered that the cause of the link failure is device 1 (if the index of device 2 is also abnormal, it is considered that the cause of the link failure is device 1 and device 2), but actually the cause of the link failure is device 2, not device 1.

[0028] The embodiment of the present application provides a link fault analysis method, when a certain network is networked and link monitoring and fault analysis are performed, the topological link of the network can be acquired, the topological link comprises multiple layers of devices, each layer of devices comprises a plurality of devices, then the key indicators of each device in the topological link are monitored, for any first device, when the key indicators of the first device are monitored to be abnormal, the multiple layers of devices in the topological link can be analyzed layer by layer, and the cause of the link fault can be determined according to the analysis result. In this way, when the key indicators of a certain device in the link are abnormal and cause the link fault, since the multiple layers of devices in the link can be analyzed layer by layer, the link fault is a single fault (the device itself is faulty) or a group fault (a common problem of multiple devices) can be determined according to the analysis result, so that the cause of the link fault can be quickly determined, and the accuracy of the link fault analysis result is improved.

[0029] In order for those skilled in the art to better understand the technical solutions in the present application, the technical solutions in the present application will be clearly and completely described below in combination with the drawings in one or more embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should belong to the protection scope of the present application.

[0030] The terms "first", "second", and the like in the present application and claims are used to distinguish similar objects, not to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the present application can be implemented in an order other than those illustrated or described here. In addition, "and / or" in the present application and claims means at least one of the connected objects, and the character " / " generally means that the front and rear associated objects are in an "or" relationship.

[0031] It should be noted that the technical solutions provided by the embodiments of the present application can be applied to link fault analysis of network networking based on 5G technology, which includes but is not limited to network networking of 5G ToB park. Here, the network networking based on 5G technology is not specifically limited.

[0032] The technical solutions provided by the embodiments of the present application will be described in detail below in combination with the drawings.

[0033] Figure 1 is a flowchart of the link fault analysis method of an embodiment of the present application. Figure 1 The link fault analysis method shown is described as follows.

[0034] S102: Obtain the network topology links, which include multiple layers of devices, with each layer containing multiple devices.

[0035] When performing link monitoring and fault analysis on a network, the network topology can be obtained. The network topology can include multiple layers of devices; the specific number of layers depends on the actual network configuration and is not limited here. Each layer can include multiple devices (in special cases, it can be a single device; this example uses multiple devices). Devices on the same layer can be of the same type, such as terminals or customer premises equipment (CPE). Adjacent layers can exchange data.

[0036] In some implementations, a multi-layer device in a topology link may include at least two of the following layers:

[0037] Terminal layer;

[0038] CPE layer;

[0039] Community level;

[0040] Base station (the next generation Node B, gNB) layer;

[0041] Network slicing layer;

[0042] User Plane Function (UPF) layer.

[0043] The terminal layer includes multiple terminals, such as cameras and Programmable Logic Controllers (PLCs). The CPE layer includes multiple CPE devices; one CPE can connect to one or more terminals in the terminal layer. The cell layer includes multiple cells, and one cell can have multiple CPEs. The gNB layer includes multiple gNBs, and one gNB can have multiple cells. The network slicing layer includes multiple network slices (or slices), and one network slice can have multiple gNBs. The UPF layer includes multiple UPFs; UPFs are primarily responsible for routing and forwarding data packets in the 5G core network user plane, and one UPF can have multiple network slices.

[0044] It should be noted that in practical applications, the specific device layers included in the above six layers in the topology link can be determined based on the specific network topology, and no specific limitation is made here. For example, taking a 5G ToB campus network topology as an example, the network topology link of this network can include the above six layers of devices, namely, the terminal layer, CPE layer, cell layer, gNB layer, network slicing layer, and UPF layer. The positional relationship of these device layers can be as follows: Figure 2 As shown. Furthermore, this embodiment uses at least two of the following layers in the topology link: terminal layer, CPE layer, cell layer, gNB layer, network slice layer, and UPF layer. In other possible implementations, the topology link may also include other device layers, which are not specifically limited here.

[0045] S104: Monitor key metrics for each device in the topology link.

[0046] After obtaining the network topology, key metrics for each device in the topology can be monitored. These key metrics can be service-related, without specific limitations. Optionally, for devices within the same device layer, different devices can have the same key metrics; for devices in different device layers, different devices can have the same or different key metrics, without specific limitations.

[0047] In some implementations, for any device in the topology link, the key metrics of the device may include at least one of the following metrics:

[0048] Uplink round-trip time of Transmission Control Protocol (TCP);

[0049] TCP downlink round-trip time;

[0050] TCP uplink retransmission rate;

[0051] TCP downlink retransmission rate;

[0052] TCP maximum uplink packet interval;

[0053] Maximum uplink packet jitter in TCP;

[0054] S7COM message response average latency;

[0055] Average latency of MODBUS message response.

[0056] The above indicators can be obtained by monitoring and analyzing the equipment's business data. The specific indicators selected as key indicators for the equipment can be determined based on actual monitoring needs or business scenarios; no specific limitations are made here. For example, when the equipment is a camera, key indicators may include TCP uplink round-trip time, TCP downlink round-trip time, TCP uplink retransmission rate, and TCP downlink retransmission rate. When the equipment is a PLC terminal, key indicators may include TCP uplink maximum packet interval, TCP uplink maximum packet jitter, average S7COM message response latency, and average MODBUS message response latency.

[0057] It should be noted that this embodiment uses at least one of the key indicators of the device, including TCP uplink round-trip time, TCP downlink round-trip time, TCP uplink retransmission rate, TCP downlink retransmission rate, TCP uplink maximum packet interval, TCP uplink maximum packet jitter, S7COM message response average latency, and MODBUS message response average latency, as an example for illustration. In other possible implementations, the key indicators of the device may be other indicators, which are not specifically limited here.

[0058] S106: In the event of abnormal key indicators of the first device, perform layer-by-layer analysis of the multi-layer devices in the topology link, and determine the cause of the fault based on the analysis results.

[0059] The first device can be any device in the topology link. During the monitoring of key indicators for each device in the topology link, if an anomaly is detected in the key indicator of the first device, the link can be considered faulty. In this case, a layer-by-layer analysis of the multiple devices in the topology link can be performed, and the cause of the link failure can be determined based on the analysis results. Specifically, when performing a layer-by-layer analysis of the multiple devices in the topology link, one can start from the device layer where the first device is located, and analyze that device layer and its upstream device layers layer by layer. Based on the analysis results, it can be determined whether the link failure is an isolated fault or a group fault, thereby determining the cause of the link failure.

[0060] Taking the device layer where the first device resides as the first device layer as an example, in some implementations, layer-by-layer analysis is performed on the multi-layer devices in the topology link, and the cause of the fault is determined based on the analysis results. This may include:

[0061] Determine whether all key indicators of all devices in the first device layer are abnormal;

[0062] If all key indicators of all devices in the first device layer are abnormal, the cause of the failure will be attributed to the second device layer, which is the upstream device layer of the first device layer.

[0063] When some key indicators of equipment in the first equipment layer are abnormal, the cause of the fault is determined to be the equipment in the first equipment layer with abnormal key indicators.

[0064] Specifically, if the key performance indicators (KPIs) of the first device are determined to be abnormal, we can first determine which device layer the first device is located in. Here, we will use the example of the first device being located in the first device layer as an example. Then, we can determine whether the KPIs of all devices in the first device layer are abnormal. If the KPIs of all devices in the first device layer are abnormal, it indicates that the KPI abnormality is a common problem (group failure). In this case, the cause of the failure can be considered to be a failure in the upstream device layer of the first device layer, leading to the KPI abnormality in all devices in the first device layer. The cause of the failure can then be delimited to the upstream device layer of the first device, i.e., the second device layer. If only some devices in the first device layer have abnormal KPIs, it indicates that the KPI abnormality is a problem with the device itself (individual failure), not a common problem. In this case, the cause of the failure can be delimited to the device in the first device layer whose KPI is abnormal, such as the first device.

[0065] The aforementioned first device layer can be any one of the following: terminal layer, CPE layer, cell layer, gNB layer, and network slicing layer. Specifically, if the first device layer is a terminal layer, the second device layer can be a CPE layer; if the first device layer is a CPE layer, the second device layer can be a cell layer; if the first device layer is a cell layer, the second device layer can be a gNB layer; if the first device layer is a gNB layer, the second device layer can be a network slicing layer; and if the first device layer is a network slicing layer, the second device layer can be a UPF layer.

[0066] It should be noted that when determining whether the key indicators of all devices in the first device layer are abnormal, "all devices" here can refer to multiple devices corresponding to the same upstream device. For example, if the first device layer is the terminal layer and the upstream device layer is the CPE layer, and the terminal layer includes devices A to E, where devices A, B, and C are devices under CPE1, and devices D and E are devices under CPE2, then, assuming the first device is device A, when determining whether the key indicators of all devices in the terminal layer are abnormal when the key indicators of device A are abnormal, specifically, it can be determined whether the key indicators of devices A, B, and C (the three devices correspond to the same CPE, i.e., CPE1) are all abnormal. If all are abnormal, the cause of the fault can be attributed to CPE1; if only device A is abnormal, the cause of the fault can be attributed to device A. Similarly, if the first device is device D, when the key indicators of device D are abnormal and it is determined whether the key indicators of all devices in the terminal layer are abnormal, specifically, it can be determined whether the key indicators of device D and device E (the two devices correspond to the same CPE, i.e., CPE2) are both abnormal. If both are abnormal, the cause of the fault can be determined to CPE2. If only device D is abnormal, the cause of the fault can be determined to device D.

[0067] After delineating the cause of the fault to the second device layer, if the second device layer is not the upstream device layer, further analysis can be performed on the second device layer (the specific implementation method is the same as the specific implementation method for analyzing the first device layer mentioned above). Thus, multi-layer devices in the topology link can be analyzed layer by layer, and the cause of the link fault can be determined based on the analysis results, thereby improving the accuracy of link fault analysis.

[0068] For example, in a topology link that includes the terminal layer, CPE layer, cell layer, gNB layer, network slice layer, and UPF layer, if a key indicator of a device in the terminal layer is found to be abnormal, the analysis of link faults can include the following steps 1 to 5:

[0069] Step 1: Determine if all key indicators of all terminals in the terminal layer are abnormal. If so, it is determined to be a group failure, and the cause of the failure is delimited to the CPE layer, and Step 2 is executed. If not, it is determined to be an individual failure, and the cause of the failure is delimited to the terminal in the terminal layer where the key indicators are abnormal.

[0070] Step 2: Determine if all key indicators of all CPEs in the CPE layer are abnormal. If so, it is determined to be a group failure, and the cause of the failure is delineated to the cell layer, and Step 3 is executed. If not, it is determined to be an individual failure, and the cause of the failure is delineated to the CPE in the CPE layer where the key indicators are abnormal.

[0071] Step 3: Determine whether all key indicators of all cells in the cell layer are abnormal. If so, it is determined to be a group failure, and the cause of the failure is delimited to the gNB layer, and step 4 is executed. If not, it is determined to be an individual failure, and the cause of the failure is delimited to the cell in the cell layer where the key indicators are abnormal.

[0072] Step 4: Determine if all key metrics of all gNBs in the gNB layer are abnormal. If so, it is determined to be a group failure, and the cause of the failure is delimited to the network slice layer, and step 5 is executed. If not, it is determined to be an individual failure, and the cause of the failure is delimited to the gNB in ​​the gNB layer where the key metrics are abnormal.

[0073] Step 5: Determine if all key metrics of all network slices in the network slice layer are abnormal. If so, it is determined to be a group failure, and the cause of the failure is delimited to the UPF layer. If not, it is determined to be an individual failure, and the cause of the failure is delimited to the network slice in the network slice layer where the key metrics are abnormal.

[0074] As can be seen, the fault localization logic proceeds sequentially from step 1 to step 5. The fault localization logic starts from the terminal layer and gradually checks the upper-layer devices until the UPF layer. Ultimately, the possibility and scope of impact of fault localization of the service link change with the increase of the layer, from individual terminals to the entire network slice. Clearly distinguishing between group faults and individual faults helps to quickly identify the source of the problem and effectively guide fault diagnosis and network optimization.

[0075] For easier understanding, please refer to Figure 3 . Figure 3 In the process of monitoring key indicators of each device in the topology link, if abnormalities are detected in the indicators of terminals 3 to 12, then, based on the link fault analysis method provided in this application embodiment, the analysis of the fault cause may include:

[0076] At the terminal layer:

[0077] For terminal 3, since terminal 3, terminal 1, and terminal 2 are all terminals under CPE1, and the key indicators of terminals 1 and 2 are not abnormal, it can be determined that the abnormal key indicator of terminal 3 is a single fault, and the cause of the fault is attributed to terminal 3. For terminals 4 to 6, since these three terminals are all terminals under CPE2, and the key indicators of all three terminals are abnormal, it can be determined that it is a group fault, and the cause of the fault is attributed to CPE2. Similarly, for terminals 7 to 9, the abnormal indicators can be determined to be a group fault, and the cause of the fault is attributed to CPE3. For terminals 10 to 12, the abnormal indicators can be determined to be a group fault, and the cause of the fault is attributed to CPE4.

[0078] At the CPE layer:

[0079] Based on the above terminal layer fault analysis, CPE1 is normal, while CPE2 through CPE4 are abnormal. Therefore, for CPE2, since CPE1 and CPE2 are both CPEs in cell 1, and CPE1 is normal, the abnormality of CPE2 can be determined as an individual fault, and the cause of the fault can be attributed to CPE2. For CPE3 and CPE4, since these two CPEs are both in cell 3 and are abnormal, it can be determined as a group fault, and the cause of the fault can be attributed to cell 3.

[0080] At the community level:

[0081] Based on the fault analysis of the CPE layer above, it can be seen that cell 1 is normal and cell 3 is abnormal. Therefore, for cell 3, since cell 3 and cell 4 are cells under gNB2, and cell 4 is normal, it can be determined that the abnormality of cell 3 is a fault, and the cause of the fault can be attributed to cell 3.

[0082] At this point, it can be confirmed Figure 3 In the topology link shown, the cause of the failure is CPE2 and cell 3.

[0083] It should be noted that the fault analysis method provided in this application embodiment can delineate the cause of the fault to one or more devices in the topology link, but the specific problems that occur in these devices (such as hardware problems, software algorithm problems, or network problems) still need to be further analyzed. For details, please refer to the solutions in related technologies. This application embodiment will not describe them in detail.

[0084] The link failure analysis method provided in this application, when performing link monitoring and failure analysis on a network topology, can acquire the network topology, which includes multiple layers of devices, each layer containing multiple devices. Key indicators of each device in the topology are then monitored. If any first device's key indicator is found to be abnormal, the multiple layers of devices in the topology can be analyzed layer by layer, and the cause of the link failure can be determined based on the analysis results. Thus, when a link failure is caused by an abnormal key indicator of a device, because the multiple layers of devices in the link can be analyzed layer by layer, it is possible to determine whether the link failure is an individual failure (a fault in the device itself) or a group failure (a common problem among multiple devices), thereby quickly determining the cause of the link failure and improving the accuracy of the link failure analysis results.

[0085] It should be noted that the link failure analysis method provided in this application embodiment is based on the network topology links. Therefore, the accuracy of the topology links affects the accuracy of the link failure analysis. In related technologies, when determining the network topology links, the service path is usually reconstructed through manual analysis or by using route tracing tools (tracert / traceroute) to determine the topology links. However, manual analysis is slow and lacks real-time performance, which may lead to inaccurate path reconstruction. Moreover, in scenarios with large-scale networks and complex network structures, reconstructing service paths through manual analysis is prone to errors. Route tracing tools are not suitable for complex network situations, such as large networks using multi-protocol label switching technology. Simply performing route tracing is difficult to accurately reconstruct service paths, resulting in low accuracy of the topology links determined in related technologies. To improve the accuracy of topology links, this application embodiment also provides a method for determining topology links. This method can reconstruct the network topology links based on Layer 3 IP pairs of tunneling protocols. When obtaining the network topology links in S102 above, the topology links can be reconstructed and obtained according to this method.

[0086] Specifically, in S102 above, obtaining the network topology links may include:

[0087] Obtain external data representation (XDR) data for network topology;

[0088] Parse the XDR data to obtain multiple IP addresses, including the IP addresses of multiple devices in the network.

[0089] Based on multiple IP addresses in the XDR data, determine the network topology links.

[0090] XDR data includes user service behavior data, which can reflect user service behavior within the network. In some implementations, acquiring XDR data for a network may include:

[0091] The network's service message data is obtained by using a probe acquisition server deployed in the network topology.

[0092] Determine the XDR data for network topology based on service message data.

[0093] Specifically, a probe acquisition server can be pre-deployed in the network. A probe acquisition server is a server that collects communication packet data. With a probe acquisition server deployed in the network, it can collect and obtain the network's service packet data. After obtaining the network's service packet data, it can be analyzed and processed to obtain the network's XDR data. The XDR data may include the IP addresses of multiple devices in the network.

[0094] After obtaining the XDR data of the network topology, the XDR data can be parsed, and multiple IP addresses included in the XDR data can be obtained based on the parsing results. The parsing of XDR data can be performed according to certain rules. Optionally, in some implementations, parsing the XDR data to obtain multiple IP addresses may include:

[0095] Obtain the correspondence between different IP types and fields in the XDR data;

[0096] Based on the correspondence between different IP types and fields in the XDR data, the XDR data is parsed to determine the IP addresses corresponding to different IP types in the XDR data.

[0097] The correspondence between different IP types and fields in XDR data can be determined according to business specifications. When parsing XDR data, this correspondence can be used to match the fields in the XDR data with different IP types, thereby extracting the IP addresses corresponding to different IP types from the XDR data.

[0098] Optionally, in some implementations, the correspondence between different IP types and fields in the XDR data can be as shown in Table 1 below.

[0099] Table 1

[0100] IP Type Description Corresponding field in XDR terminal_ip Terminal inner_source_ip AR / LSW ar_source_ip user_ip CPE user_ip gnb_ip gNB source_ip upf_ip UPF dest_ip server_ip MEC server_ip ar_dest_ip AR / LSW ar_dest_ip app_ip APP inner_dest_ip Figure 4

[0101] In Table 1, terminal_ip and app_ip are a pair of IPs, user_ip and server_ip are a pair of IPs, and gnb_ip and upf_ip are a pair of IPs, totaling three layers of IP pairs. The topology links will be restored based on these three layers of IP pairs in the future.

[0102] Based on Table 1, the multiple IP addresses obtained after parsing the XDR data can include at least two of the following:

[0103] The terminal's IP address (terminal_ip), which corresponds to the terminal, such as a camera;

[0104] The source IP address (ar_source_ip) of the access point corresponds to the access router (AR) and / or LAN switch (LSW);

[0105] The IP address (user_ip) of the CPE corresponds to the CPE;

[0106] The IP address (gnb_ip) of the gNB corresponds to the gNB;

[0107] The IP address of UPF (upf_ip) corresponds to UPE;

[0108] The IP address (server_ip) of Mobile Edge Computing (MEC), corresponding to the MEC;

[0109] The destination IP address (ar_dest_ip) of the access point, corresponding to AR and / or LSW;

[0110] The IP address (app_ip) of the application (APP) corresponds to the APP service provider.

[0111] After resolving multiple IP addresses from the XDR data, the network topology can be determined based on these IP addresses. In some implementations, determining the network topology based on multiple IP addresses in the XDR data may include:

[0112] Obtain the full link configuration table, which is used to store the link information of the network topology;

[0113] Update the link information in the full link configuration table based on multiple IP addresses in the XDR data;

[0114] Based on the updated link information in the full link configuration table, determine the network topology links.

[0115] The full link configuration table is a pre-set data table used to store link information for multiple links in a network. Each link can include multiple devices, and the link information for each link can include the IP addresses of these devices. When determining the network topology based on multiple IP addresses in the XDR data, the link information in the full link configuration table can be updated according to the IP addresses in the XDR data. Based on the updated link information, the network topology can be obtained.

[0116] In some implementations, updating the link information in the full link configuration table based on multiple IP addresses in the XDR data may include:

[0117] Retrieve multiple XDR data within a specified period;

[0118] Based on multiple XDR data within a specified period, perform at least one of the following operations:

[0119] For each XDR data, determine whether the IP address corresponding to the link information in the full link configuration table includes multiple IP addresses from the XDR data; if the IP address corresponding to the link information in the full link configuration table does not include multiple IP addresses from the XDR data, insert a link information entry into the full link configuration table based on the multiple IP addresses from the XDR data.

[0120] For each link information entry in the full link configuration table, determine whether the IP address in multiple XDR data within a specified period includes the IP address corresponding to the link information; if the IP address in multiple XDR data within a specified period does not include the IP address corresponding to the link information, delete the link information from the full link configuration table.

[0121] The specified period can be set according to actual needs, such as 5 minutes, 30 minutes, 1 hour, 24 hours, etc., without specific limitations. When updating the link information in the full link configuration table, updates can be performed according to a specified period. That is, the link information in the full link topology table can be updated based on the IP addresses in multiple XDR data within a specified period. Updating the link information in the full link topology table can involve inserting or deleting one or more link entries, or inserting or deleting one or more link entries simultaneously; there are no specific limitations.

[0122] When updating the full link configuration table, specifically, for each XDR data within a specified period, it can be determined whether the IP address corresponding to the link information in the full link configuration table includes multiple IP addresses from the XDR data. If so, it means that the link information corresponding to the multiple IP addresses in the XDR data has been recorded in the full link configuration table, and in this case, there is no need to insert new link information into the full link configuration table. If not, it means that the link information corresponding to the multiple IP addresses in the XDR data has not been recorded in the full link configuration table, and in this case, a new link information can be inserted into the full link configuration table based on the multiple IP addresses in the XDR data.

[0123] For each link information entry in the full link configuration table, it can be determined whether the IP addresses among multiple XDR data within a specified period include the IP address corresponding to the link information. If so, it indicates that multiple devices involved in the link information are online within the specified period, and the link information can be left undeleted. If not, it indicates that one or more devices involved in the link information are offline within the specified period, and the link information can be deleted from the full link configuration table. Optionally, in some implementations, to avoid the accuracy of the final determined topology links being lowered due to accidental deletion of link information in the full link configuration table, the link information to be deleted can be submitted to the operations and maintenance personnel for review before deletion. The deletion operation is only performed after the operations and maintenance personnel confirm that the link information can be deleted.

[0124] In determining the network topology links, this embodiment can self-learn and reconstruct the topology links based on the Layer 3 IP pairs of the tunneling protocol. Specifically, it can obtain XDR data reflecting user service behavior in the network topology and automatically reconstruct the topology links based on the IP addresses included in the XDR data. This eliminates the need for manual intervention, resulting in high efficiency and accuracy. Furthermore, since network topology data is typically included, determining the network topology links based on XDR data has good versatility and can be applied to any complex network. In addition, when determining the topology links, the link information in the full link configuration table can be updated based on XDR data within a specified period, thus enabling periodic dynamic updates of the topology links.

[0125] To facilitate understanding of the technical solutions provided in the embodiments of this application, the following will take the network topology of a 5G ToB park as an example to explain in detail how the embodiments of this application determine the network topology links and how to analyze the causes of link failures in the event of link failures.

[0126] Figure 4 This is a schematic diagram of the hardware network topology of a 5G ToB campus according to an embodiment of this application.

[0127] Figure 4 The 5G ToB campus shown includes cameras and PLC devices. These devices are connected to the CPE via switches and AR routers. The CPE communicates with the 5G base station via the network. The 5G base station is connected to the campus MEC. The 5G base station and the campus MEC can communicate with the 5G core network (5GCore, 5GC). The campus MEC is connected to the central control room via AR routers and switches.

[0128] based on Figure 5 The network topology of the 5G ToB campus shown may include the following steps when determining the network topology links.

[0129] Step 41: Collect packet data of the 5G ToB campus network through the probe acquisition server.

[0130] Step 42: Combine the message data into XDR data.

[0131] XDR data includes the IP addresses of multiple devices. In some implementations, XDR data can be as follows: Figure 5 As shown, Figure 6 The content enclosed in a box is the IP address.

[0132] Step 43: Parse the XDR data to obtain multiple IP addresses from the XDR data.

[0133] When parsing XDR data, the IP fields of the XDR call detail record (CDR) data can be parsed according to the specifications of China Mobile Communications Group. Specifically, the IP fields in the XDR data can be parsed according to the field correspondence in Table 1 above. These IP fields may include terminal_ip (terminal IP), ar_source_ip (access point source IP), user_ip (user IP), gnb_ip, upf_ip, server_ip (server IP), ar_dest_ip (access point destination IP), and app_ip (application IP), corresponding to the terminal (camera or PLC), AR / LSW, CPE, gNB, UPF, MEC, AR / LSW, and APP service provider, respectively. After parsing multiple IP fields, the corresponding IP addresses can be obtained.

[0134] Step 44: Determine the topology of the 5G ToB campus network based on the IP address in the XDR data.

[0135] The specific implementation method can be as follows: Figure 6 As shown. Figure 7In this process, when determining the topology links, a full link configuration table for storing link information can be obtained first. Then, at specified intervals, the link information in the full link configuration table is updated based on the XDR data within that specified period. Specifically, taking one period as an example, it can be determined whether the IP address in the XDR data within that period is in the full link configuration table. If not, the XDR data is inserted into the full link configuration table, indicating an addition of a link. At the same time, it can also be determined whether the link data in the full link configuration table is in the XDR data within that period. If not, the link data can be deleted from the full link configuration table, indicating a reduction of a link. When deleting link data, a prompt for manual review can be displayed on the interface. The deletion operation is only performed after manual review and approval to avoid accidental deletion.

[0136] Through steps 41 and 44 above, the goal of restoring the 5G ToB campus network topology link based on XDR data can be achieved.

[0137] Optionally, after updating the full link configuration table, the data in the full link configuration table can be presented on the web, thereby allowing a direct view of the topology links of the 5G ToB campus network.

[0138] After determining the topology of the 5G ToB campus network, link faults can be quickly identified based on this topology. Specifically, this can include the following steps.

[0139] Step 45: Select key business KPI indicators according to the dimensions of terminals, CPEs, cells, gNBs, slices, and UPFs on the topology link and perform hourly-level quality difference statistical calculations.

[0140] When selecting key performance indicators (KPIs) for high-definition camera terminals, the following four key indicators can be chosen:

[0141] TCP uplink round-trip time (RTT);

[0142] TCP Round Trip Time (RTT);

[0143] TCP uplink retransmission rate;

[0144] TCP downlink retransmission rate.

[0145] For PLC device terminals, the following four key indicators can be selected:

[0146] TCP maximum uplink packet interval;

[0147] Maximum uplink packet jitter in TCP;

[0148] S7COM message response average latency;

[0149] Average latency of MODBUS message response.

[0150] For devices in the CPE layer, cell layer, gNB layer, slice layer, and UPF layer, their key indicators may include at least one of the key indicators of the aforementioned camera and PLC devices.

[0151] Step 46: When a critical indicator of a device is detected to be abnormal, the abnormal indicators can be checked layer by layer from the terminal layer to the UPF layer for the physical or logical devices through which the abnormal indicator passes, to determine whether it is an individual fault (individual failure) or a common problem (group failure).

[0152] Taking the abnormality of a key indicator of a device at the terminal layer as an example, the analysis of link failure can include:

[0153] (1) Fault delimitation at the terminal layer:

[0154] If all terminals show abnormal metrics, it is determined to be a group failure, and the fault is delimited to the CPE layer. If only some terminals show abnormal metrics, while the metrics of other terminals are normal, it is determined to be an individual failure, and the fault is delimited to the abnormal terminal.

[0155] (2) Fault delimitation of CPE layer:

[0156] If all CPE metrics are abnormal, it is determined to be a group fault, and the fault is delimited to the cell level. If only some CPE metrics are abnormal, while the metrics of other CPEs are normal, it is determined to be an individual fault, and the fault is delimited to the abnormal CPE.

[0157] (3) Small cell layer fault delimitation:

[0158] If all cell indicators are abnormal, it is determined to be a group failure, and the fault is delimited to the gNB layer. If only some cells have abnormal indicators, while the indicators of other cells are normal, it is determined to be an individual failure, and the fault is delimited to the abnormal cell.

[0159] (4) GNB layer fault delimitation:

[0160] If all gNB metrics are abnormal, it is determined to be a group failure, and the fault is delimited to the slice layer. If only some gNB metrics are abnormal, while the metrics of other gNBs are normal, it is determined to be an individual failure, and the fault is delimited to the abnormal gNB.

[0161] (5) Fault delimitation of sliced ​​layers:

[0162] If all slices show abnormal metrics, it is classified as a group failure, and the fault is delimited to the UPF layer. If only some slices show abnormal metrics while the metrics of other slices are normal, it is classified as an individual failure, and the fault is delimited to the abnormal slice.

[0163] The fault localization logic proceeds sequentially from (1) to (5). The fault localization logic starts from the terminal layer and gradually checks the upper-layer devices until the UPF layer. Ultimately, the probability and scope of fault localization of the service link change with the increase of the layer, from individual terminals to the entire network slice. Clearly distinguishing between group faults and individual faults helps to quickly identify the source of the problem, effectively guide fault investigation and network optimization, thereby meeting the security and high availability requirements of the production network and realizing rapid analysis of link faults.

[0164] Based on the technical solution provided in the embodiments of this application, since the link failure is caused by the abnormality of the key indicators of a certain device in the link, the multi-layer devices in the link can be analyzed layer by layer. Therefore, it is possible to determine whether the link failure is a single fault (the fault of the device itself) or a group fault (a common problem of multiple devices) based on the analysis results, so as to quickly determine the cause of the link failure and improve the accuracy of the link failure analysis results.

[0165] Furthermore, in determining the network topology links, this embodiment obtains the XDR data of the network topology and automatically reconstructs the topology links based on the IP addresses included in the XDR data, without manual intervention. Therefore, it is highly efficient and accurate. Moreover, since network topology data is typically included, determining the network topology links based on XDR data has good versatility and can be applied to any complex network. Additionally, when determining the topology links, since the link information in the full link configuration table can be updated based on the XDR data within a specified period, periodic dynamic updates of the topology links can be achieved.

[0166] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0167] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Please refer to it. Figure 7 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0168] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0169] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0170] The processor reads the corresponding computer program from non-volatile memory into main memory and then executes it, forming a link fault analysis device at the logical level. The processor executes the program stored in memory and specifically performs the following operations:

[0171] Obtain the network topology links, which include multiple layers of devices, with each layer including multiple devices;

[0172] Monitor the key metrics of each device in the aforementioned topology link;

[0173] When the key indicators of the first device are abnormal, the multi-layer devices in the topology link are analyzed layer by layer, and the cause of the failure is determined based on the analysis results.

[0174] The above is as stated in this application. Figure 1The method executed by the link failure analysis apparatus disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0175] The electronic device can also perform Figure 1 The method, and the implementation of the link fault analysis device in Figure 1 The functions described in the illustrated embodiments will not be repeated here.

[0176] Of course, in addition to software implementation, the electronic device of this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0177] This application also discloses a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable electronic device including multiple applications, enable the portable electronic device to perform... Figure 8 The method of the illustrated embodiment is specifically used to perform the following operations:

[0178] Obtain the network topology links, which include multiple layers of devices, with each layer including multiple devices;

[0179] Monitor the key metrics of each device in the aforementioned topology link;

[0180] When the key indicators of the first device are abnormal, the multi-layer devices in the topology link are analyzed layer by layer, and the cause of the failure is determined based on the analysis results.

[0181] Figure 8 This is a schematic diagram of the structure of a link failure analysis device 80 according to an embodiment of this application. Please refer to... Figure 1 In one software implementation, the link fault analysis device 80 may include: an acquisition module 81, a monitoring module 82, and an analysis module 83, wherein:

[0182] The acquisition module 81 acquires the network topology links, which include multiple layers of devices, and each layer of devices includes multiple devices.

[0183] Monitoring module 82 monitors the key indicators of each device in the topology link;

[0184] Analysis module 83 performs layer-by-layer analysis on the multi-layer devices in the topology link when the key indicators of the first device are abnormal, and determines the cause of the failure based on the analysis results.

[0185] In some embodiments, the multilayer device includes at least two of the following layers:

[0186] Terminal layer;

[0187] User-end device CPE layer;

[0188] Community level;

[0189] Base station gNB layer;

[0190] Network slicing layer;

[0191] User plane functionality UPF layer.

[0192] In some implementations, the key metrics include at least one of the following:

[0193] TCP uplink round-trip time;

[0194] TCP downlink round-trip time;

[0195] TCP uplink retransmission rate;

[0196] TCP downlink retransmission rate;

[0197] TCP maximum uplink packet interval;

[0198] Maximum uplink packet jitter in TCP;

[0199] S7COM message response average latency;

[0200] Average latency of MODBUS message response.

[0201] In some implementations, the first device is a device in a first device layer; the analysis module 83 performs layer-by-layer analysis on the multi-layer devices in the topology link, and determines the cause of the fault based on the analysis results, including:

[0202] Determine whether the key indicators of all devices in the first device layer are abnormal;

[0203] If all key indicators of all devices in the first device layer are abnormal, the cause of the fault is delineated to the second device layer, which is the upstream device layer of the first device layer.

[0204] If the key indicators of some devices in the first device layer are abnormal, the cause of the fault will be attributed to the device in the first device layer with the abnormal key indicators.

[0205] In some implementations, at least one of the following is included:

[0206] In the case where the first device layer includes a terminal layer, the second device layer includes a CPE layer;

[0207] In the case where the first device layer includes a CPE layer, the second device layer includes a cell layer;

[0208] In the case where the first device layer includes a cell layer, the second device layer includes a gNB layer;

[0209] In the case where the first device layer includes a gNB layer, the second device layer includes a network slicing layer;

[0210] In the case where the first device layer includes a network slicing layer, the second device layer includes a UPF layer.

[0211] In some implementations, the acquisition module 81 acquires the network topology links, including:

[0212] Obtain the external data representation XDR data of the network topology;

[0213] The XDR data is parsed to obtain multiple IP addresses, including the IP addresses of multiple devices in the network.

[0214] The network topology is determined based on multiple IP addresses in the XDR data.

[0215] In some implementations, the acquisition module 81 parses the XDR data to obtain multiple IP addresses from the XDR data, including:

[0216] Obtain the correspondence between different IP types and fields in the XDR data;

[0217] The XDR data is parsed according to the correspondence to determine the IP addresses in the XDR data that correspond to different IP types.

[0218] In some implementations, the IP addresses of the plurality of devices include at least two of the following:

[0219] The terminal's IP address;

[0220] The source IP address of the access point;

[0221] The IP address of the CPE;

[0222] The IP address of the gNB;

[0223] UPF IP address;

[0224] The IP address of the mobile edge computing (MEC);

[0225] The destination IP address of the access point;

[0226] The IP address of the application (APP).

[0227] In some implementations, the acquisition module 81 determines the network topology links based on multiple IP addresses in the XDR data, including:

[0228] Obtain the full link configuration table, which is used to store the link information of the network topology;

[0229] The link information in the full link configuration table is updated based on multiple IP addresses in the XDR data.

[0230] Based on the updated link information in the full link configuration table, the network topology is determined.

[0231] In some implementations, the acquisition module 81 updates the link information in the full link configuration table based on multiple IP addresses in the XDR data, including:

[0232] Acquire multiple XDR data within a specified period;

[0233] Based on the XDR data within the specified period, perform at least one of the following operations:

[0234] For each XDR data, determine whether the IP address corresponding to the link information in the full link configuration table includes multiple IP addresses in the XDR data; if the IP address corresponding to the link information in the full link configuration table does not include multiple IP addresses in the XDR data, insert a link information entry into the full link configuration table based on the multiple IP addresses in the XDR data.

[0235] For each link information in the full link configuration table, determine whether the IP addresses of the multiple XDR data within the specified period include the IP address corresponding to the link information; if the IP addresses of the multiple XDR data within the specified period do not include the IP address corresponding to the link information, delete the link information from the full link configuration table.

[0236] In some implementations, the acquisition module 81 acquires the XDR data of the network topology, including:

[0237] The network's service message data is obtained through a probe acquisition server deployed in the network.

[0238] The XDR data of the network topology is determined based on the service message data.

[0239] The link fault analysis device 80 provided in this application can also perform... Figure 1 The method, and the implementation of the link fault analysis device 80 in ​ The functions of the embodiments shown will not be described again in this application.

[0240] This application also proposes a computer program product comprising a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps in the above-described link failure analysis method embodiments.

[0241] In summary, the above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

[0242] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0243] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0244] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0245] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

Claims

1. A method for analyzing link fault, comprising: obtaining a topology link of a network configuration, wherein the topology link comprises a plurality of layers of devices, and each layer of devices comprises a plurality of devices; monitoring key indicators of each device in the topology link; in a case where a key indicator of a first device is abnormal, performing layer-by-layer analysis on the plurality of layers of devices in the topology link, and determining a fault cause according to an analysis result.

2. The method of claim 1, wherein the plurality of layers of devices comprises at least two of the following: a terminal layer; a customer premises equipment (CPE) layer; a cell layer; a base station (gNB) layer; a network slice layer; a user plane function (UPF) layer.

3. The method of claim 1, wherein the key indicators comprise at least one of the following: a transmission control protocol (TCP) uplink round trip time; a TCP downlink round trip time; a TCP uplink retransmission rate; a TCP downlink retransmission rate; a TCP uplink maximum packet interval; a TCP uplink maximum packet jitter; an S7COM message response average time delay; a MODBUS message response average time delay.

4. The method of claim 1, wherein the first device is a device in a first layer of devices, and the performing layer-by-layer analysis on the plurality of layers of devices and determining the fault cause according to the analysis result comprises: determining whether key indicators of all devices in the first layer of devices are abnormal; in a case where the key indicators of all devices in the first layer of devices are abnormal, bounding the fault cause to a second layer of devices, which is an upstream layer of devices of the first layer of devices; and in a case where the key indicators of some devices in the first layer of devices are abnormal, bounding the fault cause to the devices in the first layer of devices whose key indicators are abnormal.

5. The method of claim 4, comprising at least one of the following: in a case where the first layer of devices comprises a terminal layer, the second layer of devices comprises a CPE layer; in a case where the first layer of devices comprises a CPE layer, the second layer of devices comprises a cell layer; in a case where the first layer of devices comprises a cell layer, the second layer of devices comprises a gNB layer; in a case where the first layer of devices comprises a gNB layer, the second layer of devices comprises a network slice layer; in a case where the first layer of devices comprises a network slice layer, the second layer of devices comprises a UPF layer.

6. The method of any one of claims 1 to 5, wherein the obtaining the topology link of the network configuration comprises: obtaining external data representation (XDR) data of the network configuration; parsing the XDR data to obtain a plurality of IP addresses in the XDR data, wherein the plurality of IP addresses comprise IP addresses of the plurality of devices in the network configuration; and determining the topology link of the network configuration according to the plurality of IP addresses in the XDR data.

7. The method of claim 6, wherein the parsing the XDR data to obtain the plurality of IP addresses in the XDR data comprises: obtaining a correspondence between different IP types and fields in the XDR data; and parsing the XDR data according to the correspondence to determine IP addresses corresponding to the different IP types in the XDR data. 8.The method of claim 6, wherein the IP addresses of the plurality of devices comprise at least two of: an IP address of a terminal; a source IP address of an access point; an IP address of a CPE; an IP address of a gNB; an IP address of a UPF; an IP address of a mobile edge computing (MEC) ; a destination IP address of an access point; and an IP address of an application (APP). 9.The method of claim 6, wherein determining the topology link of the network based on the plurality of IP addresses in the XDR data comprises: obtaining a full link configuration table, wherein the full link configuration table is configured to store link information of the network; updating the link information in the full link configuration table based on the plurality of IP addresses in the XDR data; and determining the topology link of the network based on the updated link information in the full link configuration table. 10.The method of claim 9, wherein updating the link information in the full link configuration table based on the plurality of IP addresses in the XDR data comprises: obtaining a plurality of the XDR data within a specified period; and performing at least one of the following operations based on the plurality of the XDR data within the specified period: determining, for each of the XDR data, whether the plurality of IP addresses in the XDR data are included in IP addresses corresponding to the link information in the full link configuration table, and inserting a link information in the full link configuration table based on the plurality of IP addresses in the XDR data, in a case that the plurality of IP addresses in the XDR data are not included in the IP addresses corresponding to the link information in the full link configuration table; and determining, for each of the link information in the full link configuration table, whether IP addresses of the plurality of the XDR data within the specified period are included in IP addresses corresponding to the link information, and deleting the link information in the full link configuration table, in a case that the IP addresses corresponding to the link information are not included in the IP addresses of the plurality of the XDR data within the specified period. 11.The method of claim 6, wherein obtaining the XDR data of the network comprises: obtaining traffic data of the network by a probe collection server deployed in the network; and determining the XDR data of the network based on the traffic data. 12.An electronic device comprising: a processor; a memory storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the method of any one of claims 1 to 11. 13.A computer-readable storage medium storing instructions that, when executed by a processor of an electronic device, cause the electronic device to perform the method of any one of claims 1 to 11. 14.A computer program product comprising a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of the method of any one of claims 1 to 11. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​

Images