A network fault processing method and related device

Abstract

The application relates to a network fault processing method and a related device, and the method comprises the following steps: receiving a target fault detection strategy corresponding to a first APN sent by a cloud device, the target fault detection strategy being determined by the cloud device based on running information corresponding to a vehicle and network scene information corresponding to the vehicle, and the cloud device being located in a network fault processing system; performing network fault detection on a link where the first APN is located based on the target fault detection strategy to obtain a target detection result corresponding to the first APN; when the target detection result indicates that the link where the first APN is located has a network fault, determining a target recovery strategy corresponding to the first APN; and performing a fault recovery operation corresponding to the target recovery strategy on the first APN based on the target recovery strategy. The application reduces the invalid computing power consumption and communication bandwidth resource waste of a vehicle-mounted remote communication terminal, and guarantees the stable operation of vehicle-mounted services.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a network fault handling method and related equipment. Background Technology

[0002] With the widespread adoption of intelligent connected vehicles, the network stability of in-vehicle intelligent cockpits has become a critical factor affecting user experience and functional safety. Intelligent cockpits rely on in-vehicle remote communication terminals (TBOX) to establish network links using different Access Point Names (APNs) to interact with cloud services and achieve functions such as remote control, status monitoring, and data reporting. However, due to issues such as abnormal APN dialing, network connections may be interrupted or degraded, leading to functional failures. Currently, most methods for handling network faults employ factory-configured network fault detection rules with fixed parameters to perform self-healing when a network fault is detected. However, this method cannot flexibly adjust the detection parameters throughout the entire usage cycle, making it unsuitable for all usage environments. It is prone to misjudging faults and frequently triggering unnecessary self-healing actions, wasting the computing power and communication bandwidth resources of the in-vehicle remote communication terminal and affecting the stable operation of in-vehicle services. Summary of the Invention

[0003] One objective of this application is to provide a network fault handling method that reduces the ineffective computing power consumption and communication bandwidth waste of the vehicle-mounted remote communication terminal, thereby ensuring the stable operation of vehicle-mounted services; another objective of this application is to provide a network fault handling device; a third objective of this application is to provide a vehicle-mounted remote communication terminal; and a fourth objective of this application is to provide a network fault handling system.

[0004] To achieve the above objectives, in a first aspect, this application provides a network fault handling method, applied to a vehicle-mounted remote communication terminal in a network fault handling system, the method comprising: The system receives a target fault detection strategy corresponding to the first APN sent by a cloud device. The target fault detection strategy is determined by the cloud device based on the vehicle's corresponding operating information and the vehicle's corresponding network scenario information. The cloud device is located in the network fault handling system. Based on the target fault detection strategy, network fault detection is performed on the link where the first APN is located to obtain the target detection result corresponding to the first APN; When the target detection result indicates that there is a network fault on the link where the first APN is located, a target recovery strategy corresponding to the first APN is determined; Based on the target recovery strategy, a fault recovery operation corresponding to the target recovery strategy is performed on the first APN.

[0005] To achieve the above objectives, in a second aspect, this application provides a network fault handling device, applied to a vehicle-mounted remote communication terminal in a network fault handling system, the device comprising: A receiving module is used to receive a target fault detection strategy corresponding to a first APN sent by a cloud device. The target fault detection strategy is determined by the cloud device based on the vehicle's corresponding operating information and the vehicle's corresponding network scenario information. The cloud device is located in the network fault handling system. The detection module is used to perform network fault detection on the link where the first APN is located based on the target fault detection strategy, so as to obtain the target detection result corresponding to the first APN; The determination module is used to determine the target recovery strategy corresponding to the first APN when the target detection result indicates that there is a network failure on the link where the first APN is located; The processing module is used to perform fault recovery operations on the link where the first APN is located, based on the target recovery strategy.

[0006] To achieve the above objectives, in a third aspect, this application provides a vehicle-mounted remote communication terminal, comprising: a processor and a memory, wherein the processor is used to execute a network fault handling program stored in the memory to implement the network fault handling method described above.

[0007] To achieve the above objectives, in a fourth aspect, this application provides a network fault handling system, including a cloud device and a vehicle-mounted remote communication terminal; wherein... The cloud device is used to determine the target fault detection strategy corresponding to the first APN based on the vehicle's corresponding operating information and the vehicle's corresponding network scenario information, and to send the target fault detection strategy to the vehicle-mounted remote communication terminal. The vehicle-mounted remote communication terminal is used to receive the target fault detection strategy in order to execute the network fault handling method described above.

[0008] The beneficial effects of this application are as follows: This application provides a network fault handling method, applied to a vehicle-mounted remote communication terminal in a network fault handling system. The method includes: receiving a target fault detection strategy corresponding to a first APN sent by a cloud device, wherein the target fault detection strategy is determined by the cloud device based on the vehicle's corresponding operating information and network scenario information, and the cloud device is located in the network fault handling system; performing network fault detection on the link where the first APN is located based on the target fault detection strategy to obtain a target detection result corresponding to the first APN; when the target detection result indicates that there is a network fault on the link where the first APN is located, determining a target recovery strategy corresponding to the first APN; and performing a fault recovery operation corresponding to the target recovery strategy on the first APN based on the target recovery strategy. Through the above methods, this application dynamically determines and distributes fault detection strategies that match the actual needs of the vehicle based on the vehicle's corresponding operating information and network scenario information via cloud devices. This enables remote and flexible configuration of network fault detection strategies. When a network fault is detected, corresponding fault recovery operations are performed based on the recovery strategy corresponding to the APN. This avoids fault misjudgment caused by using fixed fault detection parameters that cannot adapt to complex and changing usage environments, as well as the frequent triggering of unnecessary self-healing actions due to misjudgment. It also reduces the ineffective computing power consumption and communication bandwidth waste of the vehicle-mounted remote communication terminal, ensuring the stable operation of vehicle-mounted services. Attached Figure Description

[0009] Figure 1 This diagram illustrates a flowchart of a network fault handling method provided in an embodiment of this application. Figure 2 This diagram illustrates a flowchart of another network fault handling method provided in an embodiment of this application. Figure 3 This diagram illustrates the structure of a network fault handling system provided in an embodiment of this application. Figure 4 This diagram illustrates a flowchart of a network fault detection method provided in an embodiment of this application. Figure 5 This diagram illustrates a flowchart of a network fault recovery method provided in an embodiment of this application. Figure 6 This diagram illustrates the structure of a network fault detection device provided in an embodiment of this application. Figure 7 This diagram illustrates the structure of a vehicle-mounted remote communication terminal provided in an embodiment of this application. Detailed Implementation

[0010] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0011] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0012] To facilitate understanding of the embodiments of this application, the following will provide further explanation and description with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of this application.

[0013] refer to Figure 1 , Figure 1 This is a flowchart illustrating a network fault handling method provided in an embodiment of this application. The network fault handling method provided in this embodiment specifically includes the following steps: S101: Receive the target fault detection strategy corresponding to the first APN sent by the cloud device.

[0014] In this embodiment, the method is applied to the vehicle-mounted remote communication terminal (i.e., TBOX) in the network fault handling system, referring to... Figure 3 As shown, the network fault handling system also includes a cloud device. This cloud device determines the target fault detection strategy corresponding to the first APN based on the vehicle's operating information and network scenario information, and sends the target fault detection strategy to the in-vehicle remote communication terminal. This cloud device can be an SPM (System Management Platform). It should be noted that the target fault detection strategy includes target configuration information related to performing network fault detection on the link where the first APN is located. In other words, this target configuration information is actually target configuration information related to performing ping detection on the link where the first APN is located, and is not limited to sending a specified number of packets, specifying the time interval for each ping, specifying the timeout for waiting for each reply, specifying the domain name, etc.

[0015] To enable cloud devices to send target fault detection strategies to the vehicle-mounted remote communication terminal, the network fault handling system also includes IoT devices, both located within the vehicle's smart cockpit. Specifically, a ping detection configuration module is added to the cloud device. This module configures real-time ping command control commands. The command data format is JSON, encoded in UTF-8. The command content (i.e., target configuration information) is configured according to the "SPM-IoT Command Protocol" as shown in Table 1. Here, `msgId` identifies the sent message, with each message type having a unique identifier; `systemId` identifies the specific device to which the message belongs (in this embodiment, it belongs to TBOX); `msgType` distinguishes the type of SPM received messages, including real-time downlink messages, received message receipts, and command execution results; `action` configures the ping switch status; `cycle` configures the ping detection cycle; and `cmd` configures the sent ping commands, including sending a specified number of packets, specifying the time interval for each ping, specifying the timeout for each reply, and specifying the domain name, thereby achieving precise control over detection latency and packet loss rate.

[0016] Table 1 SPM-IoT Command Protocol

[0017] In IoT devices, a function to forward ping check commands is added. This function receives JSON-formatted commands from cloud devices, parses the command content, and forwards them to the in-vehicle remote communication terminal via the ANDROID-TBOX private communication protocol. Simultaneously, the detection results from the in-vehicle remote communication terminal are reported to the cloud device. The private communication protocol is detailed in Table 2. During the data flow from the IoT device to the in-vehicle remote communication terminal, pingCheckSt indicates the ping check on / off status; pingCycle indicates the ping check execution cycle; and pingString indicates the specific ping check command. During the data flow from the in-vehicle remote communication terminal to the IoT device, Result indicates the ping check execution result.

[0018] Table 2 ANDROID-TBOX Private Communication Protocol

[0019] This embodiment adds a ping detection module to the vehicle-mounted remote communication terminal. The main function of this module is to receive ping detection commands forwarded by IoT devices and parse the field content. Based on the pingCheckSt field, it determines whether to enable ping detection. If enabled, it configures the detection cycle based on the pingCycle field and the specific ping detection command to be executed based on the pingString field. After completing command reception, parsing, and execution, it returns the execution result through the Result field. The ping detection module also has a data tracking reporting function and fault self-recovery measures, achieving a closed-loop process of detection, reporting, and self-recovery.

[0020] S102: Based on the target fault detection strategy, perform network fault detection on the link where the first APN is located to obtain the target detection result corresponding to the first APN.

[0021] In this embodiment, the ping detection module in the vehicle-mounted remote communication terminal parses the field content after receiving the ping detection command (i.e., the target fault detection strategy) forwarded by the IoT device. First, it reads the value of the pingCheckSt field. If the value is 0, it indicates that detection is off; if there is a currently running detection timer, it will be turned off. If the value is 1, it indicates that detection is on. It further determines whether detection is enabled. If not, it first confirms whether the link to the first APN has been established. If the link is not established, it waits for it to be established; if the link is established, it sets a detection timer with a period of T based on the value of the pingCycle field and begins periodically executing the network fault detection task.

[0022] At each detection cycle point, a network probe is initiated on the link where the first APN is located, according to the instructions configured in the pingString field, to obtain network probe data. The ping detection module calculates network performance metrics based on this data. Fault judgment is then performed based on the calculated network performance metrics. If the network performance metrics meet the fault judgment criteria, the detection result for the target corresponding to the first APN indicates a fault in the link where the first APN is located; otherwise, the detection result for the target corresponding to the first APN indicates that the link where the first APN is located is not faulty. Simultaneously, the Result field (representing the ping detection execution result, i.e., the target detection result) is returned to the IoT device via the 0x96 identifier for reporting to the cloud device.

[0023] S103: When the target detection result indicates that there is a network fault on the link where the first APN is located, determine the target recovery strategy corresponding to the first APN.

[0024] In this embodiment, when the target detection result indicates a network fault on the link where the first APN is located, the ping detection module enters the fault self-recovery process. At this time, the ping detection module determines the target recovery strategy corresponding to the type of the first APN based on the first APN. For example, when the first APN is a public network APN, the target recovery strategy is the fault recovery strategy corresponding to the public network APN; when the first APN is a private network APN, the target recovery strategy is the fault recovery strategy corresponding to the private network APN.

[0025] It should be noted that when the target detection result indicates a network fault in the link where the first APN is located, and the first APN is a public network APN, the target detection result is reported to the cloud device. The cloud device obtains the current vehicle's location area and, based on the vehicle detection results reported by other vehicles within the location area, those related to the network fault detection of the first APN. If multiple vehicle detection results indicate that the network of the link where the first APN is located is normal, the cloud device issues a recovery command to the vehicle-mounted remote communication terminal. The vehicle-mounted remote communication terminal then determines the target recovery strategy corresponding to the first APN. However, if more than a preset number of vehicle detection results indicate a network fault in the link where the first APN is located, a pause recovery command is issued to the vehicle-mounted remote communication terminal. In other words, the vehicle-mounted remote communication terminal does not execute the step of determining the target recovery strategy corresponding to the first APN. Thus, the cloud device aggregates fault detection data from multiple vehicles in the same location area for collaborative verification, enabling the system to distinguish between individual faults and regional faults, avoiding the resource waste caused by ineffective individual recovery for regional faults.

[0026] S104: Based on the target recovery strategy, perform the fault recovery operation corresponding to the target recovery strategy on the first APN.

[0027] In this embodiment, the ping detection module in the vehicle-mounted remote communication terminal automatically initiates the corresponding fault recovery operation after confirming a network fault and determining the corresponding target recovery strategy. The fault recovery operation directly acts on the first APN to automatically attempt to repair the network connection, replacing the traditional network fault handling method that relies on manual user intervention. This automatic execution of fault recovery operations enables rapid response and closed-loop processing of network faults without human intervention, improving the efficiency and timeliness of fault repair.

[0028] This embodiment provides a network fault handling method that dynamically determines and distributes fault detection strategies that match the actual needs of the vehicle based on the vehicle's corresponding operating information and network scenario information via cloud devices. This enables remote and flexible configuration of network fault detection strategies. When a network fault is detected, corresponding fault recovery operations are executed based on the recovery strategy corresponding to the APN. This avoids fault misjudgment caused by using fixed fault detection parameters that cannot adapt to complex and changing usage environments, as well as the frequent triggering of unnecessary self-healing actions due to misjudgment. It also reduces the ineffective computing power consumption and communication bandwidth waste of the vehicle-mounted remote communication terminal, ensuring the stable operation of vehicle services.

[0029] refer to Figure 2 , Figure 2 This is a flowchart illustrating another network fault handling method provided in an embodiment of this application. The network fault handling method provided in this embodiment specifically includes the following steps: S201: Receive the target fault detection strategy corresponding to the first APN sent by the cloud device.

[0030] In this embodiment, the cloud device determines the target fault detection strategy based on the vehicle's operational information and network scenario information. The operational information includes the vehicle's current operational status and the service type corresponding to the first service associated with the first APN. The cloud device determines the target fault detection strategy corresponding to the first APN in the following manner: Based on motion state information and network scene information, the first association relationship is queried to obtain the initial fault detection strategy corresponding to the first APN.

[0031] Based on the business type, determine the target correction information corresponding to the initial configuration information; The initial configuration information is corrected using the target correction information to obtain the target fault detection strategy corresponding to the first APN.

[0032] Among these, motion state information can be understood as data related to the vehicle's current driving state, such as whether the vehicle is traveling at high speed, low speed, or stationary. Different motion states have different requirements for the sensitivity and frequency of network fault detection.

[0033] Network scenario information can be understood as the current network environment status of the vehicle, such as whether the current network standard is 4G or 5G, the signal strength, and whether it is in an area where multiple base stations frequently switch.

[0034] Service type can be understood as the category of the primary service currently running through the link of the first APN, such as audio / video call services or background log upload services. Different service types have different sensitivities to network quality.

[0035] The first association stores the correspondence between multiple sets of motion state information, network scene information and preset fault detection strategies. The initial fault detection strategy includes the initial configuration information related to network fault detection for the link where the first APN is located. The initial fault detection strategy is one of multiple preset fault detection strategies.

[0036] Specifically, the cloud device first acquires the vehicle's current motion status information and network scenario information. Simultaneously, the cloud device identifies the service type corresponding to the first service currently running on the link of the first APN (e.g., a video call is in progress). Based on the acquired motion status information and network scenario information, it queries the internally preset first association relationship to obtain the initial fault detection strategy corresponding to the matching first APN. If no first service is running on the link of the first APN, the initial fault detection strategy is determined to be the target fault detection strategy corresponding to the first APN.

[0037] After obtaining the initial fault detection strategy, when there is a first service running on the link where the first APN is located, the target correction information corresponding to the initial configuration information is determined according to the service type corresponding to the first service. The target correction information includes the relevant information of the information to be corrected in the initial configuration information.

[0038] After determining the target correction information, the information to be corrected in the initial configuration information is corrected using the target correction information to obtain the target configuration information. Based on the target configuration information, the target fault detection strategy corresponding to the first APN is obtained.

[0039] In this embodiment, the cloud device first obtains an initial fault detection strategy by querying a preset first association relationship based on vehicle motion status information and network scene information. Then, based on the service type corresponding to the first service currently running through the link of the first APN, the initial configuration information in the initial fault detection strategy is specifically modified. Finally, a target fault detection strategy is generated and issued. This ensures that the issued target fault detection strategy not only adapts to the vehicle's operating and network environment but also matches the inherent network performance requirements of the currently carried service. This improves the accuracy of network fault detection and avoids false or missed faults caused by unreasonable configuration of detection parameters.

[0040] In the above, based on the business type, the target correction information corresponding to the initial configuration information is determined, including: Obtain the first network service quality corresponding to the first APN and the preset network service quality corresponding to the service type; Determine the service quality difference between the first network service quality and the preset network service quality; Based on the service quality difference, the target correction information corresponding to the initial configuration information is determined.

[0041] The first network service quality is obtained based on the network fault detection performed on the link where the first APN is located in the last time. The first network service quality reflects the actual communication quality of the link where the first APN is located in the most recent (i.e., the last) detection, and is usually comprehensively measured by network performance indicators such as latency and packet loss rate. The specific calculation method can be found in existing technologies, and will not be elaborated here. It should be noted that the smaller the value of the first network service quality, the better the network condition of the link where the first APN is located.

[0042] The preset network service quality (SMS) characterizes the worst network service quality that a service corresponding to a given service type can tolerate. In other words, if the first SMS is greater than or equal to the preset SMS, the service corresponding to that service type will not function properly, or the user experience will be affected.

[0043] Specifically, the actual detection results (i.e., network performance indicators, including actual latency, packet loss rate, etc.) obtained from the last network fault detection performed on the link where the first APN is located are acquired. The first network service quality corresponding to the first APN is obtained by calculating based on the actual detection results.

[0044] Based on the service type corresponding to the first service on the link currently running on the first APN, query the preset network service quality corresponding to that service type. Subtract the first network service quality from the preset network service quality to obtain the service quality difference. This service quality difference reflects the overall margin of the current network performance relative to the minimum requirements of the service. The larger the service quality difference, the more surplus the network performance, and the more relaxed the detection requirements can be; the smaller the service quality difference, the closer the network performance is to the service tolerance limit, and the more stringent the detection requirements should be, and the stronger the fault detection should be.

[0045] After determining the service quality difference, the target correction information corresponding to the determined service quality difference is obtained from the mapping relationship between the service quality difference and the correction information, and then the final target fault detection strategy is obtained by using the target correction information.

[0046] In this embodiment, by obtaining the first network service quality obtained from the previous detection and the preset network service quality corresponding to the current service type, the service quality difference between the two is calculated, and the target correction information for the initial configuration information is determined based on the service quality difference. This directly links the correction of the fault detection strategy with the gap between the actual network status and service requirements, realizing the dynamic optimization of the fault detection strategy and further improving the accuracy of network fault detection and the rationality of system resource utilization.

[0047] S202: Based on the target fault detection strategy, perform network fault detection on the link where the first APN is located to obtain the target detection result corresponding to the first APN.

[0048] In this embodiment, the target fault detection strategy includes performing network fault detection related target configuration information on the link where the first APN is located. Step S202 specifically includes: Obtain the target network performance metric threshold corresponding to the first APN; Based on the target configuration information, network fault detection is performed on the link where the first APN is located to obtain the actual network performance index value corresponding to the first APN; When the actual network performance index value is greater than or equal to the target network performance index threshold, the target detection result is determined to be that there is a network fault in the link where the first APN is located; When the actual network performance index value is less than the target network performance index threshold, the target detection result is determined to be that there is no network fault on the link where the first APN is located.

[0049] The target network performance index threshold is used to characterize the worst network performance index value that the link where the first APN is located can tolerate. Since a smaller network performance index value indicates better network performance, this target network performance index threshold is actually an upper limit. The actual network performance index can be understood as the network performance data actually measured by the vehicle-mounted remote communication terminal after performing network detection according to the target configuration information.

[0050] Specifically, the target fault detection strategy also includes the target network performance indicator threshold corresponding to the first APN. After receiving the target fault detection strategy from the cloud device, the target network performance indicator threshold corresponding to the first APN is parsed from the target configuration information.

[0051] After obtaining the target network performance threshold, the ping detection module performs network fault detection on the link where the first APN is located, based on the target configuration information contained in the target fault detection strategy. Specifically, according to the parameters set in the target configuration information, such as the number of packets sent, sending interval, timeout time, and target domain name, it initiates a network probe on the link where the first APN is located. After the probe is completed, raw result data is collected, including the total number of probe packets sent, the number of packets successfully received in response, and the round-trip time of each response packet. Based on this raw result data, the ping detection module calculates the actual network performance index value corresponding to the first APN. This actual network performance index value includes the actual latency value and the actual packet loss rate value obtained in this detection.

[0052] After obtaining the actual network performance index value, it is compared with the target network performance index threshold. If the actual network performance index value is greater than or equal to the target network performance index threshold, it indicates that the current network performance has deteriorated to a level exceeding the worst-case tolerance of the link where the first APN is located. In this case, the target detection result is determined to be a network fault on the link where the first APN is located. If the actual network performance index value is less than the target network performance index threshold, it indicates that the current network performance is still within an acceptable normal range. In this case, the target detection result is determined to be no network fault on the link where the first APN is located.

[0053] It should be noted that when there are multiple actual network performance index values, if any one of the actual network performance index values ​​is greater than or equal to the target network performance index threshold, it indicates that the link where the target detection result indicates the first APN is located has a network fault. If all actual network performance index values ​​are less than the target network performance index threshold, it indicates that the link where the target detection result indicates the first APN is located does not have a network fault.

[0054] By comparing the actual network performance index value with the target network performance index threshold, this embodiment determines that a network fault exists when the actual network performance index value is greater than or equal to the target network performance index threshold, and otherwise determines that no network fault exists. This achieves accurate judgment of network faults and provides a reliable basis for candidate fault self-recovery operations.

[0055] The target network performance metric thresholds mentioned above are determined by the segment device in the following manner: Obtain the environmental and location information of the vehicle, and obtain the preset network performance index threshold corresponding to the first APN; Based on environmental information, a first correction value corresponding to a preset network performance indicator threshold is determined, and based on location information, a second correction value corresponding to a preset network performance indicator threshold is determined. Based on the first correction value and the second correction value, determine the target correction value corresponding to the preset network performance index threshold. The target correction value is used to correct the preset network performance index threshold to obtain the target network performance index threshold.

[0056] Environmental information can be understood as information about the vehicle's current external environment, such as weather conditions (sunny, rainy, snowy, foggy), terrain information (plains, mountains, tunnels), and other environmental factors that may affect the quality of network signal propagation. Environmental information reflects the degree to which the vehicle's external physical conditions affect the quality of network signal propagation, and is used to distinguish between environmental fluctuations and actual network faults, avoiding misjudging signal attenuation caused by environmental factors such as rain, snow, and tunnels as link failures.

[0057] Location information can be understood as the vehicle's current geographical location, such as latitude and longitude coordinates, and the type of road (highway, urban road, rural road). Location information reflects the network coverage level of the area where the vehicle is located, in order to avoid frequent false alarms in areas with weak coverage.

[0058] The preset network performance index threshold can be understood as a basic network performance index threshold set in advance for the link where the first APN is located, before considering the environmental and location factors of the vehicle.

[0059] Specifically, when generating a target fault detection strategy, cloud devices need to simultaneously determine the target network performance index threshold carried in the target fault detection strategy.

[0060] First, the cloud device acquires the vehicle's current environmental information. This information can come from weather service data interfaces or third-party data platforms, reflecting environmental conditions such as weather and terrain features that may affect network signal propagation. Furthermore, it can obtain the vehicle's current location information through the vehicle's satellite positioning system and map data. Additionally, the cloud device needs to acquire preset network performance threshold values ​​set for the first APN.

[0061] After obtaining environmental information, location information, and preset network performance index thresholds, a first correction value corresponding to the preset network performance index threshold that matches the environmental information is determined based on the mapping relationship between environmental information and correction values. Simultaneously, a second correction value corresponding to the preset network performance index threshold that matches the location information is determined based on the mapping relationship between location information and correction values.

[0062] After determining the first and second correction values, the target correction value corresponding to the preset network performance index threshold can be calculated using methods such as summation or weighted summation. The target correction value is then multiplied by the preset network performance index threshold to correct it, resulting in the target network performance index threshold. Subsequently, the target network performance index threshold, along with the target configuration information, is encapsulated into the target fault detection strategy and sent to the vehicle-mounted remote communication terminal for subsequent network fault detection and recovery.

[0063] In this embodiment, when determining the target network performance index threshold, two correction dimensions are introduced: the environmental information and the location information of the vehicle. Corresponding correction values ​​are determined for each dimension, and the preset benchmark threshold is comprehensively corrected to obtain the final target network performance index threshold. This allows the fault judgment criteria to dynamically adapt to changes in the external environment and geographical location, further improving the accuracy of network fault detection.

[0064] S203: When the target detection result indicates that there is a network fault on the link where the first APN is located, determine the first historical detection result obtained from the last network fault detection of the link where the first APN is located and determine the target recovery strategy corresponding to the first APN.

[0065] S204: When the first historical detection result indicates that there is no network fault on the link where the first APN is located, determine the fault embedding information corresponding to the first APN.

[0066] S205: Report the fault location information to the cloud device through the link where the second APN is located.

[0067] Regarding steps S203 to S205 above, the method for determining the target recovery strategy corresponding to the first APN in step S203 is the same as the method for determining the target recovery strategy in step S103 above. For details, please refer to the above description. This embodiment will not repeat it here.

[0068] The second APN is of a different type than the first APN. For example, when the first APN is a public network APN, the second APN is a private network APN; when the first APN is a private network APN, the second APN is a public network APN.

[0069] Specifically, after the ping detection module in the vehicle-mounted remote communication terminal completes a network probe and obtains the target detection result indicating that there is a network fault in the link where the first APN is located, it does not immediately trigger a report, but first determines the nature of this network fault.

[0070] The ping detection module retrieves the first historical detection result obtained when performing network fault detection on the link where the first APN is located. The current target detection result is compared with the first historical detection result. If the first historical detection result indicates that there is no network fault on the link, it means that the current network fault is the first fault that transitions from a normal state to a fault state. If the first historical detection result already indicates that there is a network fault on the link, it means that the network fault occurred before, and the current state is merely a continuation of the fault state, not the first fault.

[0071] After determining that the current network failure is the first one, the ping detection module initiates its automatic event tracking function. This function completes the event tracking service initialization during initialization. At this point, the ping detection module collects key context information about the current network failure, configures the corresponding event identifier, and associates it with relevant system log paths. This information together constitutes the fault tracking information corresponding to the first APN, providing a data foundation for subsequent remote diagnostics.

[0072] After determining the fault location information, this information needs to be reported to the cloud device. To avoid reporting failure due to a fault in the link where the first APN is located, the report should be sent through the link where the second APN is located.

[0073] In this embodiment, when a network fault is detected on the link where the first APN is located, the fault information is generated and reported through a second APN link of a different type than the first APN only when the previous historical detection results are compared with the first APN. This avoids information redundancy and resource waste caused by repeatedly reporting the same alarm during the fault period. At the same time, the use of different types of communication links ensures the reliable reporting of fault information, providing a data foundation for cloud devices to accurately grasp the network health status of vehicles and perform proactive maintenance.

[0074] S206: Obtain the second historical detection result set obtained by performing network fault detection on the link where the first APN is located.

[0075] S207: Based on the second historical detection result set and the target detection result, determine the target number of consecutive link failures where the first APN is located.

[0076] S208: When the target number of times reaches the first preset number of times threshold, the first APN is redialed.

[0077] S209: If the link where the first APN is located still has a network fault after redialing and the target number of times reaches the second preset number of times threshold, lock the network type corresponding to the first APN.

[0078] Regarding steps S206 to S209 above, the detection time corresponding to each second historical detection result in the second historical detection result set is all prior to the detection time corresponding to the target detection result.

[0079] The target count can be understood as the cumulative number of times the link where the first APN is located has been continuously judged to have a network fault since the most recent transition from a normal state to a fault state.

[0080] The second preset number of times threshold is greater than the first preset number of times threshold. The first preset number of times threshold is used to determine whether a lightweight recovery operation needs to be performed, and the second preset number of times threshold is used to determine whether an upgrade in recovery intensity needs to be performed.

[0081] Redialing can be understood as re-dialing the first APN to re-establish the communication link corresponding to that first APN. Locking the network standard can be understood as locking the network standard (such as 4G or 5G) currently used by the first APN to prevent unnecessary switching between multiple network standards.

[0082] Specifically, after the ping detection module determines that there is a network fault on the link where the first APN is located, it first obtains the second historical detection result set corresponding to the first APN. This second historical detection result set stores the determination results of each network fault detection on the link where the first APN is located over a period of time, and each record records whether the link where the first APN is located is in a normal state or a fault state.

[0083] Based on the acquired second historical detection result set and the current target detection result, starting from the most recent normal state, the number of times the link where the first APN is located has been continuously identified as a target with network failure since the first failure occurred is counted.

[0084] After determining the target number of attempts, the target number is compared with a first preset threshold. If the target number reaches the first preset threshold (e.g., three times), it indicates a non-incidental network failure requiring self-recovery. At this point, the first APN is redialed. After the redial operation, the ping detection module continues to periodically detect the link (i.e., returns to the receive step of executing the target failure detection strategy). Once the link where the first APN is located returns to normal after the redial, the count counter is reset to zero, and the self-recovery process ends.

[0085] If the link is still determined to have a network fault after redialing, the fault count continues to accumulate. When the target number of attempts reaches a second preset threshold (e.g., nine times), it indicates that the redial operation failed to resolve the fault, and the cause of the fault may be more complex. At this point, the network standard corresponding to the first APN is locked. By locking the current network standard, repeated interruptions caused by frequent attempts to switch standards in weak signal areas are avoided, thus achieving a more thorough fault repair.

[0086] In this embodiment, by counting the target number of consecutive failures of the link where the first APN is located, and based on a preset graded number threshold, a progressive recovery measure of first redialing and then locking the network mode is adopted to achieve self-recovery of the failure of the link where the first APN is located. In the early stage of the failure, a lightweight redial operation is used to avoid excessive consumption of system resources. When redialing is ineffective and the failure continues to accumulate and reaches a higher number threshold, it automatically upgrades to a powerful recovery operation that locks the network mode. While ensuring the failure repair effect, the impact of the recovery operation on the normal operation of the vehicle service is reduced.

[0087] The above-mentioned step S209 specifically includes: If a network fault still exists on the link where the first APN is located after redialing and the target number of times reaches the second preset number threshold, the target priority corresponding to the first service running on the link where the first APN is located is determined. When the target priority is lower than the preset priority, the network type corresponding to the first APN is locked.

[0088] The target priority can be understood as the priority level corresponding to the first service, used to quantify the importance of the first service and its sensitivity to network outages. The preset priority can be understood as a pre-set priority threshold, used to distinguish between high-priority and low-priority services.

[0089] If a network failure persists on the link where the first APN is located after a redial and the target number of attempts reaches a second preset threshold, the first service currently running on the link where the first APN is located is first determined. After determining the first service, the target priority corresponding to that first service is queried. The target priority is preset based on the service's requirements for network stability and real-time performance. For example, emergency call services (XCALL) have the highest priority, while audio-visual entertainment services have lower priorities.

[0090] After determining the target priority, it is compared with the preset priority. If the target priority is lower than the preset priority, it indicates that the current primary service is of lower importance and there is a certain tolerance for network interruption. In this case, the network standard corresponding to the first APN is locked. By locking the current network standard, repeated interruptions caused by frequent attempts to switch standards in areas with weak signals are avoided.

[0091] If the target priority is greater than or equal to the preset priority, the current primary service is identified as a high-priority service, which is extremely sensitive to network interruptions. At this time, the operation of locking the current network standard is temporarily suspended to avoid the impact of network fluctuations that may occur during the locking process on high-priority services. The current state can be maintained, and further processing can be carried out at a more appropriate time later.

[0092] In this embodiment, before performing the network locking operation, the target priority of the first service currently running on the link of the first APN is confirmed, and the network locking operation is only performed when the target priority is less than the preset priority. This ensures that the strong recovery operation of network locking will not have a cascading impact on high-priority critical services, thus guaranteeing the stable operation of vehicle services.

[0093] The network fault handling method provided in this embodiment further includes the following steps after executing step S209: After identifying the network type corresponding to the first APN, a network fault detection step is performed on the link where the first APN is located to obtain the target detection result corresponding to the first APN again. If the target detection result obtained again still indicates that there is a network fault on the link where the first APN is located, generate a fault prompt message corresponding to the first APN; The fault message is sent to the cloud device so that the fault can be displayed through the cloud device.

[0094] After locking the network standard corresponding to the first APN, the ping detection module in the vehicle-mounted remote communication terminal does not necessarily assume that the network fault has been repaired. Following a predetermined target fault detection strategy, the ping detection module continues to perform network fault detection steps on the link where the first APN is located. The purpose of this re-detection is to verify whether the network locking operation is effective, that is, whether locking the network standard has successfully eliminated link interruptions or quality degradation caused by frequent standard switching.

[0095] After the detection is completed, the target detection results are obtained again. If the obtained target detection results indicate that the link where the first APN is located has returned to normal, it means that the network locking operation has taken effect, the continuous fault counter is reset to zero, and the self-recovery process ends. If the obtained target detection results still indicate that there is a network fault on the link where the first APN is located, it means that the network locking operation has failed to resolve the fault. At this time, the cause of the fault may not be due to network mode switching, but may involve other network faults. In this case, a fault message corresponding to the first APN is generated. This fault message integrates key information such as the duration of the network fault and the tiered recovery operations performed (redialing and network locking), providing complete contextual information for subsequent manual diagnosis.

[0096] After generating the fault message, the message is sent to the cloud device. Upon receiving the fault message, the cloud device can display the network fault status of the vehicle to maintenance personnel through its management interface or associated alarm system, allowing for manual intervention.

[0097] In this embodiment, after performing the network standard locking operation, network fault detection is continued on the link where the first APN is located to verify the self-recovery effect. If the network fault still exists, a fault prompt message containing the fault context is automatically generated and sent to the cloud device for alarm, so as to ensure that when all self-recovery methods fail, the operation and maintenance level is upgraded to manual intervention, thereby improving the ability to deal with network faults.

[0098] This embodiment provides a network fault handling method that dynamically determines and distributes fault detection strategies that match the actual needs of the vehicle based on the vehicle's corresponding operating information and network scenario information via cloud devices. This enables remote and flexible configuration of network fault detection strategies. When a network fault is detected, corresponding fault recovery operations are executed based on the recovery strategy corresponding to the APN. This avoids fault misjudgment caused by using fixed fault detection parameters that cannot adapt to complex and changing usage environments, as well as the frequent triggering of unnecessary self-healing actions due to misjudgment. It also reduces the ineffective computing power consumption and communication bandwidth waste of the vehicle-mounted remote communication terminal, ensuring the stable operation of vehicle services.

[0099] refer to Figure 4 and Figure 5 The following is an example of the network fault detection and recovery process when the first APN is a public APN and the second APN is a private APN: Network fault detection process: The cloud device determines the target fault detection strategy corresponding to the public network APN (i.e., the first APN) based on the vehicle's corresponding operating information and network scenario information, and then distributes the target fault detection strategy to the vehicle-mounted remote communication terminal via the IoT device. The vehicle-mounted remote communication terminal has ping detection disabled by default. After the process begins, it first checks the pingCheckSt field to see if a command to enable ping detection has been received. If no command to enable ping detection is received, it proceeds to the disable process: it checks if ping detection is already disabled. If it is enabled, the ping detection timer is disabled, a stop ping operation is performed, and the process ends; if it is disabled, no action is taken.

[0100] If a ping detection enable command is received, it is determined whether ping detection is enabled. If it is enabled, the detection cycle is directly entered for judgment. If it is not enabled, it waits for the link where the public network APN is located to be established. Once the link where the public network APN is located is successfully established, the ping detection timer is started and the detection cycle T is set.

[0101] After entering the detection cycle, it determines whether the ping detection time has arrived; if not, it continues to wait; if it has arrived, it executes the start ping operation to ping probe the link where the public APN is located.

[0102] Determine if the ping probe is abnormal; if the probe is normal, return and continue to wait for the next detection cycle; if the probe is abnormal, record the number of ping probe abnormalities and determine if this abnormality is the first abnormality within the abnormal cycle.

[0103] If this is not the first time an anomaly has occurred, the network fault recovery process will be started directly. If this is the first time an anomaly has occurred, the fault tracking information will be reported through the private network APN: first, the tracking service will be initialized (buried_data_client_init), then the eventID and path will be configured to report the tracking (repo_state_with_log), and after the tracking is reported, the network fault recovery process will be started.

[0104] After the network fault recovery process is completed, determine whether to end the ping test; if not, return to wait for the next test cycle; if it is ended, the process terminates.

[0105] Network fault recovery process: After the process starts, it is determined whether a public network APN abnormality is detected by ping; if no abnormality is detected, it returns to continue detection; if an abnormality is detected, it is determined whether there have been three public network APN abnormalities.

[0106] If no more than three anomalies are detected, the process will return to continue testing; if three anomalies are detected, the public APN will be redialed.

[0107] After the redial operation is completed, check again whether the public network APN is abnormal detected by ping; if the detection is normal after redial, return to continue the detection; if the abnormality is still detected after redial, check whether the public network APN has accumulated nine abnormalities.

[0108] If the cumulative number of anomalies does not reach nine, the process returns to continue testing; if the cumulative number of anomalies reaches nine, the process determines whether an XCALL service (i.e., a high-priority service) is currently being executed.

[0109] If an XCALL service is in progress, no action will be taken; if an XCALL service is not in progress, the 4G / 5G network standard corresponding to the public APN will be locked.

[0110] refer to Figure 6 , Figure 6This is a schematic diagram of a network fault handling device provided in an embodiment of this application. The network fault handling device provided in this embodiment is applied to a vehicle-mounted remote communication terminal in a network fault handling system. The device includes: a receiving module 10, a determining module 20, a detecting module 30, and a processing module 40. The receiving module 10 is used to receive a target fault detection strategy corresponding to a first APN sent by a cloud device. The target fault detection strategy is determined by the cloud device based on the vehicle's corresponding operating information and network scenario information. The cloud device is located in the network fault handling system. The detecting module 30 is used to perform network fault detection on the link where the first APN is located based on the target fault detection strategy to obtain a target detection result corresponding to the first APN. The determining module 20 is used to determine a target recovery strategy corresponding to the first APN when the target detection result indicates that there is a network fault on the link where the first APN is located. The processing module 40 is used to perform a fault recovery operation corresponding to the target recovery strategy on the first APN based on the target recovery strategy.

[0111] In this embodiment, the operational information includes the vehicle's current motion status information and the service type corresponding to the first service running on the link where the first APN is located; the cloud device is also used for: Based on the motion state information and the network scene information, the first association relationship is queried to obtain the initial fault detection strategy corresponding to the first APN. The first association relationship stores multiple sets of correspondences between the motion state information, the network scene information and the preset fault detection strategy. The initial fault detection strategy includes initial configuration information related to network fault detection for the link where the first APN is located. Based on the business type, determine the target correction information corresponding to the initial configuration information; The initial configuration information is corrected using the target correction information to obtain the target fault detection strategy corresponding to the first APN.

[0112] In this embodiment, the cloud device is also used for: The first network service quality corresponding to the first APN and the preset network service quality corresponding to the service type are obtained. The first network service quality is obtained by performing network fault detection on the link where the first APN is located in the last time. The preset network service quality is used to characterize the worst network service quality that can be tolerated when running the service corresponding to the service type. Determine the quality of service difference between the first network service quality and the preset network service quality; Based on the service quality difference, the target correction information corresponding to the initial configuration information is determined.

[0113] This embodiment provides a network fault handling device, which further includes a reporting module. The reporting module is used for: When the target fault detection result indicates that there is a network fault on the link where the first APN is located, the first historical detection result obtained from the last network fault detection performed on the link where the first APN is located is determined. When the first historical detection result indicates that there is no network fault on the link where the first APN is located, the fault tracking information corresponding to the first APN is determined; The fault information is reported to the cloud device through the link where the second APN is located. The second APN is of a different type than the first APN.

[0114] In this embodiment, the processing module 40 is further configured to: Obtain a second historical detection result set obtained by performing network fault detection on the link where the first APN is located. The detection time corresponding to each second historical detection result in the second historical detection result set is all before the detection time corresponding to the target detection result. Based on the second historical detection result set and the target detection result, the target number of consecutive failures of the link where the first APN is located is determined; When the target number of times reaches the first preset number of times threshold, the first APN is redialed; If the link where the first APN is located still has a network fault after redialing and the target number of times reaches the second preset number of times threshold, the network type corresponding to the first APN is locked, and the second preset number of times threshold is greater than the first preset number of times threshold.

[0115] In this embodiment, the processing module 40 is further configured to: If a network fault still exists on the link where the first APN is located after redialing and the target number of times reaches the second preset number threshold, the target priority corresponding to the first service running on the link where the first APN is located is determined. When the target priority is less than the preset priority, the network type corresponding to the first APN is locked.

[0116] In this embodiment, the reporting module is also used for: After locking down the network type corresponding to the first APN, a network fault detection step is performed on the link where the first APN is located, so as to obtain the target detection result corresponding to the first APN again; If the target detection result obtained again still indicates that there is a network fault on the link where the first APN is located, generate a fault prompt message corresponding to the first APN; The fault information is reported to the cloud device so that the fault can be indicated through the cloud device.

[0117] In this embodiment, the target fault detection strategy includes performing network fault detection-related target configuration information on the link where the first APN is located; the detection module 30 is further configured to: Obtain the target network performance index threshold corresponding to the first APN. The target network performance index threshold is used to characterize the worst network performance index value that the link where the first APN is located can tolerate. Based on the target configuration information, network fault detection is performed on the link where the first APN is located to obtain the actual network performance index value corresponding to the first APN. When the actual network performance index value is greater than or equal to the target network performance index threshold, the target detection result is determined to be that there is a network fault on the link where the first APN is located; When the actual network performance index value is less than the target network performance index threshold, the target detection result is determined to be that there is no network fault on the link where the first APN is located.

[0118] In this embodiment, the cloud device is also used for: Obtain the environmental and location information of the vehicle, and obtain the preset network performance index threshold corresponding to the first APN; Based on the environmental information, a first correction value corresponding to the preset network performance indicator threshold is determined, and based on the location information, a second correction value corresponding to the preset network performance indicator threshold is determined. Based on the first correction value and the second correction value, determine the target correction value corresponding to the preset network performance index threshold; The preset network performance index threshold is corrected using the target correction value to obtain the target network performance index threshold.

[0119] This embodiment provides a network fault handling device that dynamically determines and distributes fault detection strategies that match the actual needs of the vehicle based on the vehicle's corresponding operating information and network scenario information via cloud devices. This enables remote and flexible configuration of network fault detection strategies. When a network fault is detected, corresponding fault recovery operations are performed based on the recovery strategy corresponding to the APN. This avoids fault misjudgment caused by using fixed fault detection parameters that cannot adapt to complex and changing usage environments, as well as the frequent triggering of unnecessary self-healing actions due to misjudgment. It also reduces the ineffective computing power consumption and communication bandwidth waste of the vehicle-mounted remote communication terminal, ensuring the stable operation of vehicle services.

[0120] refer to Figure 7 As shown, Figure 7 This is a schematic diagram of the structure of a vehicle-mounted remote communication terminal provided in an embodiment of this application. The vehicle-mounted remote communication terminal 700 in this embodiment may include: at least one processor 701, a memory 702, at least one network interface 704, and other user interfaces 703. The various components in the vehicle-mounted remote communication terminal 700 are coupled together via a bus system 705. It is understood that the bus system 705 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 705 also includes a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as bus system 705.

[0121] The user interface 703 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0122] It is understood that the memory 702 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 702 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0123] In some implementations, memory 702 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 7021 and application program 7022.

[0124] The operating system 7021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 7022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of the embodiments of this application can be included in the application program 7022.

[0125] In the embodiments of this application, the processor 701 executes the methods provided in the various method embodiments by calling the program or instructions stored in the memory 702, specifically the program or instructions stored in the application program 7022.

[0126] The methods disclosed in the embodiments of this application can be applied to or implemented by processor 701. Processor 701 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 701 or by instructions in the form of software. The processor 701 may be a general-purpose processor, 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 the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 702. Processor 701 reads the information in memory 702 and uses its hardware to complete the above method.

[0127] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0128] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0129] This application also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0130] The storage medium contains one or more programs that can be executed by one or more processors. This method is applicable when the storage medium is used in a vehicle-mounted remote communication terminal. The processor executes the programs stored in the memory to implement the aforementioned execution method.

[0131] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0132] It should be noted that the terms "one implementation," "embodiment," "exemplary embodiment," and "some embodiments" used in the specification indicate that the described embodiment may include a specific feature, structure, or characteristic, but not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a specific feature, structure, or characteristic is described in connection with an embodiment, implementing such a feature, structure, or characteristic in conjunction with other embodiments, whether explicitly described or not, is within the knowledge scope of those skilled in the art.

[0133] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, or article that comprises a list of elements, or not only those elements, but also other elements not expressly listed, or elements inherent to such a process, method, or article. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, or article that includes said element.

[0134] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A network fault handling method characterized by, A vehicle-mounted remote communication terminal used in a network fault handling system, the method comprising: The system receives a target fault detection strategy corresponding to the first APN sent by a cloud device. The target fault detection strategy is determined by the cloud device based on the vehicle's corresponding operating information and the vehicle's corresponding network scenario information. The cloud device is located in the network fault handling system. Based on the target fault detection strategy, network fault detection is performed on the link where the first APN is located to obtain the target detection result corresponding to the first APN; When the target detection result indicates that there is a network fault on the link where the first APN is located, a target recovery strategy corresponding to the first APN is determined; Based on the target recovery strategy, a fault recovery operation corresponding to the target recovery strategy is performed on the first APN.

2. The network fault processing method according to claim 1, wherein The operational information includes the vehicle's current motion status information and the service type corresponding to the first service running on the link where the first APN is located; the target fault detection strategy corresponding to the first APN is determined in the following way: Based on the motion state information and the network scene information, the first association relationship is queried to obtain the initial fault detection strategy corresponding to the first APN. The first association relationship stores multiple sets of correspondences between the motion state information, the network scene information and the preset fault detection strategy. The initial fault detection strategy includes initial configuration information related to network fault detection for the link where the first APN is located. Based on the business type, determine the target correction information corresponding to the initial configuration information; The initial configuration information is corrected using the target correction information to obtain the target fault detection strategy corresponding to the first APN.

3. The network fault processing method according to claim 2, wherein The step of determining the target correction information corresponding to the initial configuration information based on the service type includes: The first network service quality corresponding to the first APN and the preset network service quality corresponding to the service type are obtained. The first network service quality is obtained by performing network fault detection on the link where the first APN is located in the last time. The preset network service quality is used to characterize the worst network service quality that can be tolerated when running the service corresponding to the service type. Determine the quality of service difference between the first network service quality and the preset network service quality; Based on the service quality difference, the target correction information corresponding to the initial configuration information is determined.

4. The network fault processing method of claim 1, wherein, The method further includes: When the target fault detection result indicates that there is a network fault on the link where the first APN is located, the first historical detection result obtained from the last network fault detection performed on the link where the first APN is located is determined. When the first historical detection result indicates that there is no network fault on the link where the first APN is located, the fault tracking information corresponding to the first APN is determined; The fault information is reported to the cloud device through the link where the second APN is located. The second APN is of a different type than the first APN.

5. The network fault processing method of claim 1, wherein, The step of performing fault recovery operations corresponding to the target recovery strategy on the first APN based on the target recovery strategy includes: Obtain a second historical detection result set obtained by performing network fault detection on the link where the first APN is located. The detection time corresponding to each second historical detection result in the second historical detection result set is all before the detection time corresponding to the target detection result. Based on the second historical detection result set and the target detection result, the target number of consecutive failures of the link where the first APN is located is determined; When the target number of times reaches the first preset number of times threshold, the first APN is redialed; If the link where the first APN is located still has a network fault after redialing and the target number of times reaches the second preset number of times threshold, the network type corresponding to the first APN is locked, and the second preset number of times threshold is greater than the first preset number of times threshold.

6. The network fault processing method according to claim 5, wherein When the link where the first APN is located still has a network fault after redialing and the target number of times reaches a second preset threshold, locking the network type corresponding to the first APN includes: If a network fault still exists on the link where the first APN is located after redialing and the target number of times reaches the second preset number threshold, the target priority corresponding to the first service running on the link where the first APN is located is determined. When the target priority is less than the preset priority, the network type corresponding to the first APN is locked.

7. The network fault processing method of claim 5, wherein, The method further includes: After locking down the network type corresponding to the first APN, a network fault detection step is performed on the link where the first APN is located, so as to obtain the target detection result corresponding to the first APN again; If the target detection result obtained again still indicates that there is a network fault on the link where the first APN is located, generate a fault prompt message corresponding to the first APN; The fault information is reported to the cloud device so that the fault can be indicated through the cloud device.

8. The network fault processing method of claim 1, wherein, The target fault detection strategy includes performing network fault detection related target configuration information on the link where the first APN is located; Based on the target fault detection strategy, network fault detection is performed on the link where the first APN is located to obtain the target detection result corresponding to the first APN, including: Obtain the target network performance index threshold corresponding to the first APN. The target network performance index threshold is used to characterize the worst network performance index value that the link where the first APN is located can tolerate. Based on the target configuration information, network fault detection is performed on the link where the first APN is located to obtain the actual network performance index value corresponding to the first APN. When the actual network performance index value is greater than or equal to the target network performance index threshold, the target detection result is determined to be that there is a network fault on the link where the first APN is located; When the actual network performance index value is less than the target network performance index threshold, the target detection result is determined to be that there is no network fault on the link where the first APN is located.

9. The network fault processing method according to claim 8, wherein, The target network performance indicator threshold is determined by the cloud device in the following manner: Obtain the environmental and location information of the vehicle, and obtain the preset network performance index threshold corresponding to the first APN; Based on the environmental information, a first correction value corresponding to the preset network performance indicator threshold is determined, and based on the location information, a second correction value corresponding to the preset network performance indicator threshold is determined. Based on the first correction value and the second correction value, determine the target correction value corresponding to the preset network performance index threshold; The preset network performance index threshold is corrected using the target correction value to obtain the target network performance index threshold.

10. A network fault handling device, characterized in that, A vehicle-mounted remote communication terminal used in a network fault handling system, the device comprising: A receiving module is used to receive a target fault detection strategy corresponding to a first APN sent by a cloud device. The target fault detection strategy is determined by the cloud device based on the vehicle's corresponding operating information and the vehicle's corresponding network scenario information. The cloud device is located in the network fault handling system. The detection module is used to perform network fault detection on the link where the first APN is located based on the target fault detection strategy, so as to obtain the target detection result corresponding to the first APN; The determination module is used to determine the target recovery strategy corresponding to the first APN when the target detection result indicates that there is a network failure on the link where the first APN is located; The processing module is used to perform fault recovery operations on the link where the first APN is located, based on the target recovery strategy.

11. A vehicle-mounted remote communication terminal, characterized in that, include: A processor and a memory, wherein the processor is configured to execute a network fault handling program stored in the memory to implement the network fault handling method according to any one of claims 1 to 9.

12. A network fault handling system, characterized in that, This includes cloud-based devices and in-vehicle remote communication terminals; among which, The cloud device is used to determine the target fault detection strategy corresponding to the first APN based on the vehicle's corresponding operating information and the vehicle's corresponding network scenario information, and to send the target fault detection strategy to the vehicle-mounted remote communication terminal. The vehicle-mounted remote communication terminal is used to receive the target fault detection strategy in order to execute the network fault handling method as described in any one of claims 1 to 9.

Images