Network fault processing method, apparatus, device, and storage medium

Abstract

The application discloses a network fault processing method and device, equipment and a storage medium, which are used for fine processing of network faults to avoid false triggering of network recovery or missing processing of network abnormalities. The method comprises the following steps: acquiring state information of a neighbor node; when the state information indicates that the neighbor node is in a neighbor unreachable failure state, detecting an internet protocol type corresponding to the neighbor node; differentiating and reporting a failure event according to the internet protocol type, wherein the failure event is used to represent that the neighbor node is in the neighbor unreachable failure state; and performing network recovery processing on a current network when the failure event is reported.

Description

Technical Field

[0001] This application relates to the field of wireless communication, specifically to a network fault handling method, apparatus, device, and storage medium. Background Technology

[0002] With the development of wireless communication technology, terminal devices typically need to detect the availability of the currently accessed network to determine whether the network can provide normal data transmission capabilities for services. In existing implementations, terminal devices can monitor the reachability status of gateways, routers, or other neighboring nodes based on the Neighbor Unreachability Detection (NUD) mechanism. When a neighboring node is detected to be in an unreachable failure state (NUD_FAILED), the existing terminal network detection mechanism usually directly determines that the current network is abnormal and triggers recovery operations such as network disconnection, reconnection, network reselection, or network self-healing.

[0003] However, in real-world wireless network environments, a neighbor node entering the NUD_FAILED state does not necessarily indicate that the current network has lost internet access. For example, in scenarios involving fluctuations in wireless link quality, momentary packet loss, signal interference, changes in access point load, or link jitter, NUD probe packets may not receive a response for a short period, leading to the neighbor node being mistakenly judged as failing. In this case, the terminal device may still be able to access the internet normally through the current network. If the terminal device directly performs network disconnection or network self-healing operations based solely on the NUD_FAILED state, it can easily cause unnecessary network interruptions, service reconnection, data transmission pauses, and a degraded user experience, while also increasing terminal power consumption and network signaling overhead.

[0004] Therefore, a network fault handling method is needed to refine the handling of network faults in order to avoid accidentally triggering network recovery or missing network anomalies. Summary of the Invention

[0005] This application provides a network fault handling method, apparatus, device, and storage medium for fine-grained processing of network faults to avoid erroneous network recovery or missed processing of network anomalies.

[0006] The technical solution adopted by this invention to solve the problem is as follows: Firstly, this application provides a network fault handling method, including: Obtain the status information of neighboring nodes; When the status information indicates that the neighbor node is in a neighbor unreachable failure state, check the Internet protocol type of the neighbor node; The failure event is reported differently based on the Internet protocol type, where the failure event is used to indicate that the neighbor node is in a neighbor unreachable failure state; When the failure event is reported, network recovery procedures are performed on the current network.

[0007] In some embodiments of this application, the differentiated reporting of failure events based on the Internet protocol type includes: When the Internet Protocol type is Internet Protocol version 4 (IPv4), report the failure event directly; The failure event is reported when the Internet Protocol type is Internet Protocol version 6 (IPv6) and the historical state information of the neighboring node indicates that the neighboring node is in a reachable state.

[0008] In some embodiments of this application, performing network recovery processing on the current network when the failure event is reported includes: When the failure event is reported, check whether the current network has internet access capability; When the current network lacks internet access capability, network recovery processing is performed based on a three-layer network recovery mechanism.

[0009] In some embodiments of this application, the method further includes: When the current network has internet access capability, count the number of times this failure event is reported; When the number of reports exceeds a preset threshold, an Address Resolution Protocol (ARP) probe is initiated to obtain the probe results; When the detection result indicates that the gateway is reachable, it is determined that the network connection of the current network has been restored; When the detection result indicates that the gateway is unreachable, network recovery processing is performed based on the three-layer network recovery mechanism.

[0010] In some embodiments of this application, the network recovery process based on the three-layer network recovery mechanism includes: Count the number of network recovery operations performed based on the three-layer network recovery mechanism; If the number of operations exceeds the first threshold and the current network has not recovered, the wireless connection between the current node and the current access point will be interrupted. Re-establish the wireless connection between the current node and the current access point.

[0011] In some embodiments of this application, the method further includes: If the newly established wireless connection does not have internet access, establish a wireless connection with other access points and add the wireless access point identifier of the current access point to the blacklist.

[0012] In some embodiments of this application, the method further includes: when a wireless roaming event is detected in the current node, initiating an Address Resolution Protocol (ARP) probe to obtain the probe results; When the detection result indicates that the gateway is reachable, it is determined that the network connection of the current network has been restored; If the detection result indicates that the gateway is unreachable within a preset number of detection attempts, network recovery processing is performed based on the three-layer network recovery mechanism.

[0013] Secondly, this application provides a network fault handling device, comprising: The acquisition module is used to obtain the status information of neighboring nodes; The processing module is used to detect the Internet Protocol type of the neighbor node when the status information indicates that the neighbor node is in a neighbor unreachable failure state; to report the failure event in a differentiated manner according to the Internet Protocol type, wherein the failure event is used to characterize that the neighbor node is in a neighbor unreachable failure state; and to perform network recovery processing on the current network when the failure event is reported.

[0014] Thirdly, this application also provides a computer device, which includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor to implement the methods of any one of the first aspects.

[0015] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps of the method of any one of the first aspects.

[0016] The beneficial effects of this invention are as follows: By adopting different neighbor failure reporting strategies for Internet Protocol version 4 and Internet Protocol version 6, the probability of false reporting and unnecessary network recovery attempts can be reduced, as well as service interruptions, signaling overhead and terminal power consumption can be reduced, and the accuracy of network anomaly detection, network connection stability and user experience in complex wireless network environments can be improved. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the system architecture provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of an embodiment of the network fault handling method provided by the present invention; Figure 3 This is a schematic flowchart of a network fault handling method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the NUD failure handling state machine provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of a specific embodiment of the network fault handling device provided in this invention. Figure 6 This is a schematic diagram of an embodiment of the computer device provided in this invention. Detailed Implementation

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

[0020] In the description of this application, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more features.

[0021] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0022] It should be noted that since the method in this application embodiment is executed in a computer device, the processing objects of each computer device exist in the form of data or information, such as time, which is essentially time information. It is understood that if size, quantity, position, etc. are mentioned in subsequent embodiments, they are all corresponding data that exist so that the computer device can process them. Specific details will not be elaborated here.

[0023] With the development of wireless communication technology, terminal devices often need to detect the availability of the currently accessed network to determine whether the network can provide normal data transmission capabilities for services. In existing implementations, terminal devices can monitor the reachability status of gateways, routers, or other neighboring nodes based on the NUD mechanism. When a neighboring node's status is detected as NUD_FAILED, existing terminal network detection mechanisms typically directly determine that the current network is abnormal and trigger recovery operations such as network disconnection, reconnection, network reselection, or network self-healing. However, in a real wireless network environment, a neighboring node's status entering NUD_FAILED does not necessarily mean that the current network has lost its ability to access the Internet. For example, in scenarios such as fluctuations in wireless link quality, instantaneous packet loss, signal interference, changes in access point load, or link jitter, NUD probe packets may not receive a response for a short period of time, leading to the neighboring node being mistakenly judged as failing. In this case, the terminal device may still be able to access the Internet normally through the current network. If the terminal device directly performs network disconnection or network self-healing operations based solely on the NUD_FAILED status, it can easily cause unnecessary network interruptions, service reconnection, data transmission pauses, and a decline in user experience, while also increasing terminal power consumption and network signaling overhead. Therefore, a network fault handling method is needed to refine the handling of network faults in order to avoid accidentally triggering network recovery or missing network anomalies.

[0024] To address this technical problem, this application provides the following technical solution: acquiring the status information of neighboring nodes; when the status information indicates that the neighboring node is in a neighbor unreachable failure state, detecting the Internet Protocol type corresponding to the neighboring node; differentially reporting the failure event according to the Internet Protocol type, wherein the failure event is used to characterize that the neighboring node is in a neighbor unreachable failure state; and performing network recovery processing on the current network in response to the failure event. In scenarios with frequent signal fluctuations, this approach introduces the signal fluctuation frequencies of the current cell and neighboring cells, and uses these frequencies to determine whether the signal of the current cell and neighboring cells is stable. When the signal fluctuation frequency of the current cell meets the handover conditions, a target cell with stable signal is determined based on the signal fluctuation frequencies of neighboring cells. Finally, the terminal device is switched to this target cell, enabling the terminal device to communicate in a cell with stable signal, thereby reducing the power consumption of the terminal device.

[0025] The technical solution of this application can be applied to various communication systems. For example, 5G systems, new radio (NR) systems, long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, universal mobile telecommunication system (UMTS), mobile communication systems after 5G networks (e.g., 6G mobile communication systems), vehicle-to-everything (V2X) communication systems, etc.

[0026] The communication systems to which this application applies include terminal equipment and network equipment. The terminal equipment and network equipment described in this application are described below.

[0027] The terminal equipment and network equipment used in this application are described below.

[0028] Terminal equipment, also known as user equipment (UE), mobile station (MS), mobile terminal (MT), customer premises equipment (CPE), etc., refers to devices that include wireless communication capabilities (providing voice / data connectivity to users). Examples include handheld devices with wireless connectivity, in-vehicle devices, and machine-type communication (MTC) terminals. Currently, terminal equipment can include: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, self-driving, remote medical surgery, smart grids, transportation safety, smart cities, and smart homes. For example, the wireless terminal in autonomous driving can be a drone, helicopter, or airplane. Similarly, the wireless terminal in vehicle-to-everything (V2X) communication can be in-vehicle equipment, vehicle components, in-vehicle modules, vehicles, or ships. In industrial control, the wireless terminal can be a camera, robot, or robotic arm. In smart homes, the wireless terminal can be a television, air conditioner, robot vacuum cleaner, speaker, or set-top box.

[0029] It should be noted that the terminal device may be a device or apparatus with a chip, or a device or apparatus with integrated circuitry, or a chip, module or control unit in the device or apparatus shown above. This application does not limit the specific device.

[0030] A network device can be a device deployed in a wireless access network to provide wireless communication functions for terminal devices. For example, a network device can be an access network (RAN) node that connects terminal devices to a wireless network, and can also be called an access network device, RAN entity, access node, network node, network device, or communication device, etc.

[0031] Specifically, the network equipment can be access network equipment for cellular systems related to the 3rd Generation Partnership Project (3GPP). For example, fourth-generation (4G) mobile communication systems, 5G mobile communication systems, or further developed mobile communication systems. The network equipment can also be access network equipment in open RAN (O-RAN or ORAN) or cloud radio access network (CRAN). Alternatively, the network equipment can also be access network equipment in a communication system formed by the integration of two or more of the above communication systems.

[0032] Network equipment includes, but is not limited to: evolved Node B (eNB), radio network controller (RNC), Node B (NB), base station controller (BSC), base transceiver station (BTS), home base station (e.g., home-evolved Node B, or home Node B, HNB), baseband unit (BBU), access point (AP) in a Wi-Fi system, macro base station, micro base station, wireless relay node, donor node, radio controller in a CRAN scenario, wireless backhaul node, transmission point (TP), or transmission and receiving point (TRP). Network equipment can also be access network equipment in 5G mobile communication systems. For example, next-generation Node B (gNB), TRP, TP in a new radio (NR) system, or one or more antenna panels (including multiple antenna panels) of a base station in a 5G mobile communication system. Alternatively, network devices can also be network nodes that constitute a gNB or transmission point. Examples include centralized units (CUs), distributed units (DUs), CU-control planes (CPs), CU-user planes (UPs), or radio units (RUs). CUs and DUs can be separate entities or included in the same network element, such as a BBU. RUs can be included in radio equipment or radio units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs). Alternatively, network devices can also be servers, wearable devices, vehicles, or in-vehicle equipment. For example, network devices in V2X technology can be roadside units (RSUs).

[0033] It should be noted that the network device can be the device or apparatus shown above, or a component (e.g., a chip), module, or unit in the device or apparatus shown above; this application does not limit the specific details.

[0034] This application provides a network fault handling method, apparatus, device, and storage medium for refined processing of network faults to avoid falsely triggering network recovery or overlooking network anomalies. The electronic device provided in this application can be implemented as various types of user terminals or as a server.

[0035] Electronic devices can perform refined processing of network faults by running the network fault handling method provided in the embodiments of this application, so as to avoid erroneous network recovery or failure to handle network anomalies.

[0036] The above method can be applied to many wireless communication scenarios, such as mobile phones accessing the Internet through a router.

[0037] In one exemplary solution, this network fault handling method can be applied to scenarios where a mobile phone accesses the internet through a router. For instance, in such scenarios, after connecting to Wi-Fi, the mobile phone maintains both IPv4 and IPv6 neighbor states. When the mobile phone detects a neighbor unreachable failure event corresponding to the IPv4 gateway, since IPv4 typically relies on the gateway for forwarding and carrying the main internet access services, the mobile phone can immediately report this IPv4 neighbor failure event to the network management module to trigger network recovery processing in a timely manner.

[0038] When a mobile phone detects an IPv6 neighbor unreachable failure event, it may not report it immediately but instead perform a secondary judgment. Specifically, the phone can first check whether the IPv6 neighbor node has ever been in a successfully reachable state in its history, such as having received a neighbor advertisement response or router advertisement message from the neighbor node, or the neighbor's state having reached REACHABLE. If the IPv6 neighbor has been successfully reachable in the past, it means that the neighbor node was originally a valid gateway, router, or communicable node. In this case, its NUD_FAILED state is more likely to indicate a real link anomaly, so the failure event can be reported to trigger network recovery processing in a timely manner. If the IPv6 neighbor has never been successfully reachable in the past, the failure state may only be an initialization failure, an invalid neighbor entry, a temporary probe failure, an intermediate state during address configuration, or an abnormal cached entry, and does not necessarily mean that the current network is truly unavailable. Therefore, reporting can be suppressed to avoid falsely triggering network self-healing, network outages, or reconnections.

[0039] It should be understood that the above is only an exemplary application scenario of network processing, and there are many other possible application scenarios, which are not limited here.

[0040] The network fault handling method provided in this application embodiment is applied to, for example, Figure 1 The system architecture diagram shown is for your reference. Figure 1To support a network fault handling method, the terminal device 100 connects to the server 300 via network 200, and the server 300 connects to the database 400. Network 200 can be a wide area network (WAN), a local area network (LAN), or a combination of both. The client used to implement the network fault handling solution is deployed on the terminal device 100, or it can run on the terminal device 100 as a standalone application. The specific form of the client is not limited here.

[0041] The server 300 involved in this application can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms.

[0042] For terminal device 100, please refer to the aforementioned description; it will not be repeated here.

[0043] It should be noted that the terminal device 100 may be a device or apparatus with a chip, or a device or apparatus with integrated circuitry, or a chip, module, or control unit in the device or apparatus shown above; this application does not impose any specific limitations. The solution provided in this application can be implemented by the terminal device 100 and the server 300 working together.

[0044] In short, a database can be viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, shared by multiple users, with minimal redundancy, and independent of application programs. A Database Management System (DBMS) is a computer software system designed to manage databases, generally possessing basic functions such as storage, retrieval, security, and backup. DBMSs can be classified according to the database model they support, such as relational or Extensible Markup Language (XML); or according to the type of computer they support, such as server clusters or mobile phones; or according to the query language used, such as Structured Query Language (SQL) or XQuery; or according to performance priorities, such as maximum scale or maximum operating speed; or other classification methods. Regardless of the classification method used, some DBMSs can cross categories, for example, supporting multiple query languages ​​simultaneously. In this application, database 400 can be used to store data such as failure events, the number of failure event reports, and the number of times network recovery processing is performed.

[0045] Those skilled in the art will understand that Figure 1 The system architecture diagram shown is one possible system architecture for this application and does not constitute a limitation on the system architecture of this application. Other system architectures may include more advanced architectures. Figure 1 The number of more or fewer terminal devices or servers shown, for example Figure 1 The diagram shows one server. It is understood that the system architecture may also include one or more other terminal devices or servers, which are not limited here.

[0046] It should be noted that, Figure 1 The system architecture shown is an example. The servers and scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of servers and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0047] like Figure 2 The diagram shown is a flowchart of an embodiment of the network fault handling method in this application. The following description, using a terminal device as the execution subject, details the network fault handling method, which may include the following steps 201-204: 201. Obtain the status information of neighboring nodes.

[0048] In this embodiment, when a terminal device accesses one of the wireless networks, it can obtain the status information of neighboring nodes. These neighboring nodes may include routers, gateways, default gateways, or other network nodes that communicate with the terminal device. This status information is used to indicate whether the neighboring node is reachable or unreachable.

[0049] In one exemplary scheme, after a terminal device connects to a wireless network, it obtains a neighbor entry corresponding to the current network. This neighbor entry records the Internet Protocol address, link layer address, and neighbor status of neighboring nodes. The terminal device periodically reads this neighbor entry or when preset trigger conditions are met to determine the current status of the neighboring nodes. The preset trigger conditions include at least one of the following: detecting network access anomalies, data transmission failure, decreased Internet access capability, completion of wireless roaming, or receiving a system neighbor status change notification. In this scheme, the neighbor entry can be maintained by the neighboring node itself or by the network management center of the current network.

[0050] In another exemplary scheme, the terminal device performs reachability detection on neighbor nodes based on the NUD mechanism. For example, when a neighbor node is not confirmed to be reachable for an extended period, or when the neighbor table entry status changes from reachable to delayed, probe, or failed, the terminal device sends a neighbor probe message to that neighbor node. For IPv4 neighbor nodes, this neighbor probe message can be an Address Resolution Protocol (NRP) request message; for IPv6 neighbor nodes, it can be a neighbor request message. If the terminal device receives a corresponding response message within a preset time, it determines that the neighbor node is reachable; if no response message is received after a preset number of probes, it determines that the neighbor node is in a neighbor unreachable failure state. In this scheme, the status information of the neighbor node can be determined by the terminal device itself.

[0051] 202. When the status information indicates that the neighbor node is in a neighbor unreachable failure state, check the Internet protocol type corresponding to the neighbor node.

[0052] In this embodiment, after reading the status information of each neighbor node, the terminal device determines the reachability of each neighbor node based on the status information; when the status information indicates that a certain neighbor node is in a neighbor unreachable failure state, the terminal device can determine the Internet protocol type corresponding to the neighbor node through the neighbor table entry.

[0053] In this embodiment, the Internet protocol type may include IPv4 and IPv6.

[0054] Optionally, if the status information is not a neighbor unreachable failure status, the terminal device can maintain the current network connection and continue to monitor the status information of neighboring nodes.

[0055] Optionally, when the status information is a neighbor unreachable failure state, the terminal device can further obtain at least one of the following: the historical reachability record (also known as historical status information) of the neighbor node, the current network connectivity detection result, and the number of failures.

[0056] 203. Report failure events in a differentiated manner according to the Internet protocol type, wherein the failure event is used to indicate that the neighbor node is in a neighbor unreachable failure state.

[0057] In this embodiment, after determining the Internet Protocol type corresponding to the neighboring node, the terminal device reports the failure event in a differentiated manner based on the Internet Protocol type. The failure event is used to indicate that the neighboring node is in a neighbor unreachable state.

[0058] In one possible implementation, the terminal device can perform differentiated processing based on the connectivity characteristics and abnormal behavior of the Internet protocol type. For example, the terminal device can directly report the failure event when the Internet protocol type is IPv4; and report the failure event when the Internet protocol type is IPv6 and the historical state information of the neighboring node indicates that the neighboring node is in a reachable state.

[0059] Specifically, when the Internet Protocol type corresponding to the neighbor node is IPv4, since IPv4 usually serves as the main forwarding path for terminal devices to access the Internet through routers, its gateway neighbor status directly affects the ability of data packets to leave the network. When the IPv4 neighbor status changes to a neighbor unreachable failure state, it is highly likely that the gateway link or address resolution is abnormal. Therefore, the failure event can be reported immediately to trigger network recovery processing.

[0060] When the Internet Protocol type corresponding to the neighbor node is IPv6, the terminal device can first query whether the neighbor node has ever been in a successfully reachable state in its history. For example, it could have received a neighbor advertisement response or router advertisement message from the neighbor node, or the neighbor's state could have reached REACHABLE. If the neighbor node has been successfully reachable in the past, it means that the neighbor node was originally a valid gateway, router, or communicable node. In this case, its NUD_FAILED state is more likely to indicate a real link anomaly, so the failure event can be reported to trigger network recovery processing in a timely manner. If the neighbor node has never been successfully reachable in the past, the failure state may only be an initialization failure, an invalid neighbor entry, a temporary probe failure, an intermediate state during address configuration, or an abnormal cached entry. It does not necessarily mean that the current network is truly unavailable. Therefore, reporting can be suppressed to avoid falsely triggering network self-healing, network outages, or reconnections.

[0061] 204. When the failure event is reported, perform network recovery processing on the current network.

[0062] After reporting the failure event, the terminal device can trigger network recovery processing for the current network.

[0063] The network recovery process may include protocol stack reset processing, network disconnection reconnection processing, Layer 3 network recovery mechanism (also known as Layer 3 network self-healing), gateway detection processing, access point switching processing, etc.

[0064] The three-layer network recovery mechanism may include at least one of the following: reacquiring Internet Protocol addresses, refreshing default routes, refreshing Domain Name System configuration, and updating neighbor cache.

[0065] In one exemplary solution, to avoid erroneous self-healing operations triggered by neighbor unreachability failures, momentary packet loss, or link jitter, thereby reducing unnecessary network outages, reconnections, and configuration updates, lowering service interruptions, signaling overhead, and terminal power consumption, and improving the accuracy of network anomaly detection and connection stability, this embodiment can also provide the following solution: After the failure event is reported, the terminal device can also detect whether the current network has Internet access capability; if the current network does not have Internet access capability, it performs network recovery processing based on the three-layer network recovery mechanism.

[0066] The current network can be a Wi-Fi network that the terminal device accesses through a router, and the Internet access capability is used to characterize whether the terminal device can access public Internet resources through the current network.

[0067] Optionally, the terminal device can determine whether the current network has internet access capability through various detection methods. These methods may include at least one of public network probe, protocol connectivity detection, domain name system resolution detection, and business data transmission result detection. Through these detections, the terminal device can confirm the true availability of the current network before triggering network recovery processing, avoiding misjudging network unavailability due to a single abnormal event.

[0068] The public network detection method refers to the terminal device sending a detection request to a preset connectivity detection server, detection domain name, or detection URL, and determining whether the current network has Internet access capability based on whether a valid response is received within a preset time.

[0069] Protocol connectivity detection refers to the terminal device sending probe messages to a preset public network address based on Internet Protocol version 4 and / or Internet Protocol version 6, and determining whether the current network can access the Internet based on whether at least one protocol path is successfully detected.

[0070] Domain Name System (DNS) resolution detection refers to the process by which a terminal device sends a DNS resolution request to the DNS server configured in the current network, and determines its internet access capability based on whether a valid resolution result is obtained and whether the target address can be accessed based on the resolution result.

[0071] The business data transmission result detection method refers to the terminal device statistically analyzing the success rate of application layer data requests, the number of timeouts, the number of connection establishment failures or retransmissions within a preset time window, and judging whether the current network can still normally support business access.

[0072] Optionally, when the current network has internet access capability, in order to improve the accuracy of anomaly identification and the timeliness of recovery processing, improve network connection stability and reduce power consumption and signaling overhead, the terminal device can also perform gateway reachability determination, and determine that the network is normal or the network has recovered on its own when the gateway is reachable; if the gateway is unreachable, the three-layer network recovery mechanism can be executed.

[0073] The terminal device can perform gateway reachability checks from both the link-layer and network-layer gateway reachability levels. Gateway reachability indicates that the terminal device can establish communication with the gateway or router within the current local area network. For example, receiving an ARP response, neighbor discovery response, or Internet Control Message Protocol (ICMP) response from the gateway indicates that the link between the terminal and the router is essentially normal.

[0074] In one exemplary scheme, the terminal device can count the number of times the failure event is reported; when the number of reports exceeds a preset threshold, it initiates an ARP probe to obtain the probe result; when the probe result indicates that the gateway is reachable, it determines that the network connection of the current network has been restored; when the probe result indicates that the gateway is unreachable, it performs network recovery processing based on the three-layer network recovery mechanism.

[0075] In another exemplary scheme, the terminal device can count the number of times the failure event is reported; when the number of reports exceeds a preset threshold, it sends an Internet Control Message Protocol echo request to the default gateway address; if there are multiple consecutive timeouts or failures, it can help determine that the gateway is unreachable, and then perform network recovery processing based on the three-layer network recovery mechanism.

[0076] In another exemplary scheme, the terminal device can count the number of times the failure event is reported; when the number of reports exceeds a preset threshold, it checks whether there is a valid default route and the gateway address corresponding to the default route; if the default route is missing, invalid, or the gateway table entry is abnormal, it can be determined that the gateway is unreachable or there is an abnormal gateway path, and then network recovery processing is performed based on the three-layer network recovery mechanism.

[0077] In this embodiment, when the terminal device performs network recovery based on the three-layer network recovery mechanism, in order to avoid increasing power consumption and recovery latency due to continuous execution of invalid self-healing operations, and to reduce the impact on services caused by long-term unavailability or repeated self-healing, the terminal device may perform the following operations: count the number of network recovery operations performed based on the three-layer network recovery mechanism; when the number of operations exceeds a first threshold and the current network has not recovered, interrupt the wireless connection between the current node and the current access point; and re-establish the wireless connection between the current node and the current access point.

[0078] Specifically, after completing a Layer 3 network self-healing process, the terminal device re-detects whether the current network has internet access capability. If the detection result indicates that the current network has restored internet access capability, the terminal device maintains the current network connection and resets or reduces the Layer 3 network self-healing failure count. If the detection result indicates that the current network still does not have internet access capability, the terminal device increments the Layer 3 network self-healing failure count by one and determines whether the Layer 3 network self-healing failure count has reached or exceeded a first threshold.

[0079] If the count of failed Layer 3 network self-healing processes does not reach the first threshold, the terminal device can continue to perform the next Layer 3 network self-healing process, or check the current network's internet access capability again after a preset waiting time. If the count of failed Layer 3 network self-healing processes reaches or exceeds the first threshold, the terminal device determines that the current network cannot be restored through Layer 3 configuration refresh, and thus triggers a disconnect and reconnection process.

[0080] The disconnect-and-reconnect process can be understood as follows: the terminal device first disconnects the wireless connection with the current access point, releasing or invalidating the link state and network layer configuration corresponding to the current connection; then, the terminal device rescans for available wireless networks and re-initiates a connection request based on the service set identifier of the current network to reconnect to the current access point or an available access point under the same service set identifier. During the reconnection process, the terminal device re-executes the authentication, association, address acquisition, routing configuration, and domain name system configuration processes to re-establish the link layer connection and network layer connection.

[0081] Furthermore, after the terminal device completes the disconnection and reconnection process, it checks again whether the current network has internet access capability. If the check result indicates that the current network has restored internet access capability, the terminal device determines that the disconnection and reconnection process was successful and clears the Layer 3 network self-healing failure count.

[0082] To avoid situations where terminal devices repeatedly connect to abnormal access points, causing the network to remain unavailable or frequently fail to recover, if the current network still lacks internet access capability after the disconnect and reconnect process, the terminal device can perform the following operations: that is, the terminal device establishes a wireless connection with other access points and adds the wireless access point identifier of the current access point to the blacklist.

[0083] Optionally, the terminal device can also report network anomaly information and / or prompt the user that the network is unavailable.

[0084] Optionally, if the terminal device uses a roaming handover method when performing access point handover (i.e., the terminal remains under the same wireless network service set identifier and switches from the current access point to another access point based on the access point signal strength, link quality, or roaming policy; or, it switches between different access points in a mesh network), then the terminal device can also perform the following: When a wireless roaming event is detected at the current node, an Address Resolution Protocol (ARP) probe is initiated to obtain the probe result. If the probe result indicates that the gateway is reachable, the network connection of the current network is determined to have been restored. If the probe result indicates that the gateway is unreachable within a preset number of probes, network recovery processing is performed based on a three-layer network recovery mechanism. In this way, the terminal device can promptly confirm the gateway connectivity status under the new access point after a roaming handover, avoiding the misjudgment that the network has been restored based solely on a successful wireless link connection. This improves the accuracy of network recovery judgment after roaming, shortens service recovery time, and enhances connection stability in complex multi-access-point or mesh network environments.

[0085] The following is based on Figure 3 The flowchart shown illustrates the network fault handling method of this application: like Figure 3 As shown, the current node detects the status information of its associated neighbor nodes within the current network; it determines whether the status information indicates a neighbor unreachable failure; if not, it continues to detect the status information of its associated neighbor nodes; if so, it performs differentiated reporting of failure events based on the Internet Protocol type corresponding to the current node; then, the current node determines whether the current network has Internet access capability; if it has Internet access capability, it records the number of failure event reports and continues to detect the status information of its associated neighbor nodes; when the number of failure event reports exceeds a first threshold, the current node can determine whether the current network meets the gateway access requirements. If the gateway is reachable, the network connection is considered restored. If the gateway is unreachable, Layer 3 network self-healing is performed. If internet access is unavailable, Layer 3 network self-healing is performed. The success of Layer 3 network self-healing and the number of self-healing attempts are determined. If successful and within the preset number of attempts, the network connection is considered restored. If unsuccessful and within the preset number of attempts, disconnection and reconnection are performed. The success of disconnection and reconnection is determined. If successful, the network connection is considered restored. If unsuccessful, the wireless access point identifier of the current access point is added to the blacklist, and a new access point is selected.

[0086] The failure handling state machine diagram of the neighbor unreachability detection mechanism can be as follows: Figure 4 As shown: Under normal connection conditions, NUD failure detection is performed; network detection is performed based on the NUD failure detection results; the network detection results include network normal or network abnormal; under normal network conditions, NUD failure detection continues; under abnormal network conditions, the process transitions to Layer 3 network self-healing processing; the results of Layer 3 network self-healing processing include disconnection and reconnection processing or successful recovery; the results of disconnection and reconnection processing include wireless access point identifier switching or successful recovery.

[0087] To better implement the network fault handling method in the embodiments of this application, based on the network fault handling method, the embodiments of this application also provide a network fault handling device, such as... Figure 5 As shown, the network fault handling device 500 includes: The acquisition module is used to obtain the status information of neighboring nodes; The processing module is used to detect the Internet Protocol type of the neighbor node when the status information indicates that the neighbor node is in a neighbor unreachable failure state; to report the failure event in a differentiated manner according to the Internet Protocol type, wherein the failure event is used to characterize that the neighbor node is in a neighbor unreachable failure state; and to perform network recovery processing on the current network when the failure event is reported.

[0088] In this embodiment, different neighbor failure reporting strategies are adopted for IPv4 and IPv6, which can reduce the probability of false reporting and unnecessary network recovery attempts, reduce service interruptions, signaling overhead and terminal power consumption, improve the accuracy of network anomaly judgment, network connection stability and user experience in complex wireless network environments.

[0089] In some embodiments of this application, the processing module 502 is specifically used for: When the Internet Protocol type is Internet Protocol version 4 (IPv4), the failure event is reported directly. The failure event is reported when the Internet Protocol type is Internet Protocol version 4 (IPv6) and the historical state information of the neighboring node indicates that the neighboring node is in a reachable state.

[0090] In this embodiment, differentiated processing is performed based on the connectivity characteristics and abnormal behavior of different protocol stacks to avoid false alarms or network self-healing caused by short-term failures of IPv6 neighbor status, while ensuring that IPv4 anomalies can be detected and handled in a timely manner. This reduces the probability of false alarms and unnecessary network recovery attempts, decreases service interruptions, signaling overhead, and terminal power consumption, and improves the accuracy of network anomaly detection, network connection stability, and user experience in complex wireless network environments.

[0091] In some embodiments of this application, the processing module 502 is specifically used for: When the failure event is reported, check whether the current network has internet access capability; When the current network lacks internet access capability, network recovery processing is performed based on a three-layer network recovery mechanism.

[0092] In this embodiment, network connectivity detection is performed before executing the three-layer self-healing mechanism. This can confirm whether the current network still has actual Internet access capability, avoid erroneous triggering of self-healing operation due to neighbor unreachability failure, instantaneous packet loss or link jitter, thereby reducing unnecessary network outages, reconnections and configuration refreshes, reducing service interruption, signaling overhead and terminal power consumption, and improving the accuracy of network anomaly judgment and connection stability.

[0093] In some embodiments of this application, the processing module 502 is further configured to: When the current network has internet access capability, count the number of times this failure event is reported; When the number of reports exceeds a preset threshold, an Address Resolution Protocol (ARP) probe is initiated to obtain the probe results. When the detection result indicates that the gateway is reachable, it is determined that the network connection of the current network has been restored; When the detection result indicates that the gateway is unreachable, network recovery processing is performed based on the three-layer network recovery mechanism.

[0094] In this embodiment, the number of reported failure events is counted when the network is connected, and address resolution protocol detection is triggered based on the number of reports. This can avoid misjudging network anomalies due to single or occasional neighbor failure events, and reduce the probability of unnecessary detection, self-healing and network reconnection. At the same time, when the accumulated failure events reach a certain level, the gateway connectivity is verified in a timely manner, thereby balancing the accuracy of anomaly identification and the timeliness of recovery processing, improving network connection stability and reducing power consumption and signaling overhead.

[0095] In some embodiments of this application, the processing module 502 is specifically used for: Count the number of network recovery operations performed based on the three-layer network recovery mechanism; If the number of operations exceeds the first threshold and the current network has not recovered, the wireless connection between the current node and the current access point will be interrupted. Re-establish the wireless connection between the current node and the current access point.

[0096] In this embodiment, disconnecting and reconnecting first when the number of Layer 3 self-healing failures exceeds a preset threshold can avoid the terminal continuously performing invalid self-healing operations, which increases power consumption and recovery latency. By re-establishing the link connection and refreshing network configurations such as address, routing, domain name system and neighbor status, possible abnormal connection states can be cleared, improving the network recovery success rate, reducing the impact of long-term unavailability or repeated self-healing on services, and improving network connection stability and user experience.

[0097] In some embodiments of this application, the processing module 502 is further configured to: If the newly established wireless connection does not have internet access, establish a wireless connection with other access points and add the wireless access point identifier of the current access point to the blacklist.

[0098] In this embodiment, if the network cannot be restored after disconnection and reconnection, adding the current access point's identifier to the blacklist and switching the access point can prevent the terminal from repeatedly connecting to abnormal access points, resulting in continuous network unavailability or frequent recovery failures. At the same time, it can guide the terminal to prioritize other available access points, improve the network recovery success rate and switching efficiency, reduce invalid reconnections, self-healing attempts and service interruption time, reduce terminal power consumption and signaling overhead, and improve connection stability and user experience in multi-access point networks with the same name or mesh network scenarios.

[0099] In some embodiments of this application, the processing module 502 is further configured to: When a wireless roaming event is detected at the current node, an Address Resolution Protocol (ARP) probe is initiated to obtain the probe results; When the detection result indicates that the gateway is reachable, it is determined that the network connection of the current network has been restored; If the detection result indicates that the gateway is unreachable within a preset number of detection attempts, network recovery processing is performed based on the three-layer network recovery mechanism.

[0100] In this embodiment, address resolution protocol detection is triggered in roaming scenarios, and layer 3 self-healing is enabled when the detection results indicate that the gateway is unreachable multiple times. This enables timely verification of the actual reachability of the gateway under the new link after the terminal switches access points, avoiding false triggering of self-healing due to a single detection failure or short-term link jitter. At the same time, when it is confirmed that the gateway is continuously unreachable, the Internet Protocol address, routing and domain name system configuration are refreshed in a timely manner, improving the network recovery speed and connection stability after roaming, reducing service interruption and improving user experience.

[0101] This application also provides a computer device that integrates any of the network fault handling devices provided in this application. The computer device includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor from the steps of the network fault handling method in any of the embodiments described above.

[0102] This application also provides a computer device that integrates any of the network fault handling devices provided in this application. For example... Figure 6 As shown, it illustrates a structural schematic diagram of the computer device involved in the embodiments of this application, specifically: The computer device may include components such as a processor 601 with one or more processing cores, a memory 602 with one or more computer-readable storage media, a power supply 603, and an input unit 604. Those skilled in the art will understand that... Figure 6 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 601 is the control center of the computer device. It connects various parts of the computer device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 602, and by calling data stored in the memory 602, thereby providing overall monitoring of the computer device. Optionally, the processor 601 may include one or more processing cores; preferably, the processor 601 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601.

[0103] The memory 602 can be used to store software programs and modules. The processor 601 executes various functional applications and data processing by running the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 602 may also include a memory controller to provide the processor 601 with access to the memory 602.

[0104] The computer device also includes a power supply 603 that supplies power to the various components. Preferably, the power supply 603 can be logically connected to the processor 601 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 603 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0105] The computer device may also include an input unit 604, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0106] Although not shown, the computer device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 601 in the computer device loads the executable files corresponding to the processes of one or more application programs into the memory 602 according to the following instructions, and the processor 601 runs the application programs stored in the memory 602 to realize various functions, as follows: Obtain the status information of neighboring nodes; when the status information indicates that the neighboring node is in a neighbor unreachable failure state, detect the Internet Protocol type corresponding to the neighboring node; report the failure event in a differentiated manner according to the Internet Protocol type, wherein the failure event is used to characterize that the neighboring node is in a neighbor unreachable failure state; when the failure event is reported, perform network recovery processing on the current network.

[0107] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0108] Therefore, embodiments of this application provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a disk, or an optical disk, etc. A computer program is stored thereon, and the computer program is loaded by a processor to execute the steps in any of the network fault handling methods provided in embodiments of this application. For example, the computer program loaded by the processor can execute the following steps: Obtain the status information of neighboring nodes; when the status information indicates that the neighboring node is in a neighbor unreachable failure state, detect the Internet Protocol type corresponding to the neighboring node; report the failure event in a differentiated manner according to the Internet Protocol type, wherein the failure event is used to characterize that the neighboring node is in a neighbor unreachable failure state; when the failure event is reported, perform network recovery processing on the current network.

[0109] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.

[0110] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.

[0111] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0112] The foregoing has provided a detailed description of a network fault handling method, apparatus, device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A network fault handling method, characterized in that, include: Obtain the status information of neighboring nodes; When the status information indicates that the neighbor node is in a neighbor unreachable failure state, the Internet Protocol type corresponding to the neighbor node is detected; The failure event is reported differently according to the Internet protocol type, wherein the failure event is used to indicate that the neighbor node is in a neighbor unreachable failure state; When the failure event is reported, network recovery processing is performed on the current network.

2. The method according to claim 1, characterized in that, The differentiated reporting of failure events based on the Internet protocol type includes: When the Internet Protocol type is Internet Protocol version 4 (IPv4), the failure event is reported directly. The failure event is reported when the Internet Protocol type is Internet Protocol version 6 (IPv6) and the historical state information of the neighboring node indicates that the neighboring node is in a reachable state.

3. The method according to claim 1, characterized in that, The step of performing network recovery processing on the current network when the failure event is reported includes: When the failure event is reported, it is checked whether the current network has internet access capability; When the current network lacks internet access capability, network recovery processing is performed based on a three-layer network recovery mechanism.

4. The method according to claim 3, characterized in that, The method further includes: When the current network has internet access capability, count the number of times the failure event is reported; When the number of reports exceeds a preset threshold, an Address Resolution Protocol (ARP) probe is initiated to obtain the probe results; When the detection result indicates that the gateway is reachable, it is determined that the network connection of the current network has been restored; When the detection result indicates that the gateway is unreachable, network recovery processing is performed based on the three-layer network recovery mechanism.

5. The method according to claim 3 or 4, characterized in that, The network recovery process based on the three-layer network recovery mechanism includes: Count the number of network recovery operations performed based on the three-layer network recovery mechanism; If the number of operations exceeds a first threshold and the current network has not recovered, the wireless connection between the current node and the current access point is interrupted. Re-establish the wireless connection between the current node and the current access point.

6. The method according to claim 5, characterized in that, The method further includes: If the newly established wireless connection does not have internet access, establish a wireless connection with other access points and add the wireless access point identifier of the current access point to the blacklist.

7. The method according to any one of claims 1 to 4 and 6, characterized in that, The method further includes: When a wireless roaming event is detected at the current node, an Address Resolution Protocol (ARP) probe is initiated to obtain the probe results. When the detection result indicates that the gateway is reachable, it is determined that the network connection of the current network has been restored; When the detection results indicate that the gateway cannot be reached within a preset number of detection attempts, network recovery processing is performed based on a three-layer network recovery mechanism.

8. A network fault handling device, characterized in that, include: The acquisition module is used to obtain the status information of neighboring nodes; The processing module is used to detect the Internet Protocol type corresponding to the neighbor node when the status information indicates that the neighbor node is in a neighbor unreachable failure state; The failure event is reported differently according to the Internet protocol type, wherein the failure event is used to indicate that the neighbor node is in a neighbor unreachable failure state; When the failure event is reported, network recovery processing is performed on the current network.

9. A computer device, characterized in that, The computer device includes: One or more processors; Memory; and One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It contains a computer program that is loaded by a processor to perform the steps of the method according to any one of claims 1 to 7.

Images