Communication fault processing method and device for vehicle-mounted terminal

Abstract

The invention discloses a communication fault processing method and device for a vehicle-mounted terminal. The method comprises the following steps: periodically detecting a network registration state of the vehicle-mounted terminal; and if it is determined that the network is successfully registered, identifying connection states of the plurality of preset network access channels and obtaining a result. And based on the result, selecting a first target network access channel which does not establish effective connection within the first set duration from the channels, and performing progressive connection retry between the first target network access channel and the first target network access channel. And meanwhile, selecting a second target network access channel which does not establish effective connection within a second set time length (greater than the first set time length) from the channels, accumulating connection failure time of the second target network access channel, and sequentially executing different levels of recovery operations according to different preset connection threshold values. Besides, when the network registration state satisfies a preset abnormal condition, network injection abnormity is determined, network injection abnormity time is accumulated, and recovery operations of different levels are executed in sequence according to different preset network injection thresholds so as to guarantee stable communication of the vehicle-mounted terminal.

Description

Technical Field

[0001] This application relates to the field of intelligent transportation technology, and in particular to a method and apparatus for handling communication faults in vehicle-mounted terminals. Background Technology

[0002] In today's rapidly evolving automotive intelligence and connectivity landscape, the Telematics Box (TBOX) has become a crucial component for data interaction between vehicles and cloud platforms. It is responsible for uploading massive amounts of data, such as vehicle operating status and location information, to the cloud platform, and receiving control commands and updates from the cloud platform. The stability of its cellular network communication directly affects the timeliness, accuracy, and reliability of information interaction between the vehicle and the outside world, significantly impacting normal vehicle operation, the realization of intelligent functions, and user experience.

[0003] However, in real-world applications, TBOX frequently encounters dial-up failures when attempting to establish a network connection. This failure is particularly pronounced in areas with poor signal coverage or in complex and variable network environments. Therefore, improving the network connection success rate of TBOX has become a critical issue that urgently needs to be addressed. Summary of the Invention

[0004] In view of the above problems, this application provides a method and apparatus for handling communication faults in vehicle-mounted terminals, so as to improve the network connection success rate of TBOX. The specific solution is as follows:

[0005] The first aspect of this application provides a method for handling communication faults in a vehicle-mounted terminal, characterized in that it includes:

[0006] Periodically check the network registration status of the vehicle terminal;

[0007] If the detection result indicates that the vehicle terminal has successfully registered with the network, the connection status of multiple preset network access channels of the vehicle terminal is identified to obtain the identification result;

[0008] Based on the identification results, a first target network access channel that has not established a valid connection within a first set time period is selected from the plurality of preset network access channels;

[0009] Progressive connection retries are performed between the first target network access channels.

[0010] In one possible implementation, the progressive connection retries between the first target network access channels include:

[0011] Select one of the first target network access channels that has not been retried;

[0012] According to the detection cycle, the connection to the first target network access channel is retried, and the number of connection retries is accumulated.

[0013] When the number of connection retries reaches the set retry limit, the current retry ends, and the step of selecting a first target network access channel that has not been retried from the first target network access channels continues.

[0014] In one possible implementation, the communication fault handling method of the vehicle terminal further includes:

[0015] When the number of connection retries for all first target network access channels reaches the set retry limit, the detection period is adjusted according to the incremental strategy; and the step of selecting a first target network access channel that has not been retried from the first target network access channels continues to be executed.

[0016] In one possible implementation, the communication fault handling method of the vehicle terminal further includes:

[0017] Based on the identification results, a second target network access channel is selected from the plurality of preset network access channels, wherein the connection failure time reaches a second preset duration; the second preset duration is greater than the first preset duration;

[0018] Based on the different preset connection thresholds reached by the connection failure time of the second target network access channel, different levels of recovery operations are executed sequentially.

[0019] In one possible implementation, the step of sequentially executing different levels of recovery operations based on different preset connection thresholds reached by the connection failure time of the second target network access channel includes:

[0020] When the connection failure time of the second target network access channel reaches the first connection threshold, the communication module of the vehicle terminal is controlled to perform a soft reset.

[0021] When the connection failure time of the second target network access channel reaches the second connection threshold, a request is made to capture the underlying logs of the communication module; the second connection threshold is greater than the first connection threshold.

[0022] When the connection failure time of the second target network access channel reaches the third connection threshold, a request is made to restart the main processing unit of the vehicle terminal; the third connection threshold is greater than the second connection threshold.

[0023] In one possible implementation, before selecting a second target network access channel from the plurality of preset network access channels based on the identification result, the method further includes:

[0024] Determine whether the vehicle terminal is currently engaged in a voice call service;

[0025] If not, then based on the identification result, a second target network access channel is selected from the plurality of preset network access channels after the connection failure time reaches the second set duration.

[0026] In one possible implementation, the communication fault handling method of the vehicle terminal further includes:

[0027] Periodically check the network registration status of the vehicle terminal;

[0028] When the detection result shows that the network registration status meets the preset abnormal conditions, it is judged as a network registration abnormality, and the network registration abnormality time begins to accumulate.

[0029] Based on the different preset threshold values ​​reached during the abnormal netting time, different levels of recovery operations are executed sequentially.

[0030] In one possible implementation, the step of sequentially performing different levels of recovery operations based on different preset thresholds reached during the abnormal registration time includes:

[0031] When the abnormal network registration time reaches the first network registration threshold, the communication module of the vehicle terminal is controlled to perform a soft reset.

[0032] When the abnormal network registration time reaches the second network registration threshold, a request is made to capture the underlying logs of the communication module; the second network registration threshold is greater than the first network registration threshold.

[0033] When the abnormal network registration time reaches the third network registration threshold, a request is made to restart the main processing unit of the vehicle terminal; the third network registration threshold is greater than the second network registration threshold.

[0034] In one possible implementation, before determining that a network registration error has occurred, at least one of the following is also included:

[0035] It is determined that the vehicle-mounted terminal is in a valid network service environment;

[0036] It is determined that the vehicle terminal is not currently engaged in a voice call service.

[0037] Another aspect of this application provides a communication fault handling device for an in-vehicle terminal, comprising:

[0038] The network registration status monitoring module is used to periodically detect the network registration status of the vehicle terminal.

[0039] The dialing management module is used to identify the connection status of multiple preset network access channels of the vehicle terminal when the detection result shows that the vehicle terminal has successfully registered with the network, and obtain the identification result; and, based on the identification result, select a first target network access channel from the multiple preset network access channels that has not established a valid connection within a first set time period; and, perform progressive connection retries among the first target network access channels.

[0040] In this application, by periodically detecting the network registration status of the vehicle terminal, and when the vehicle terminal successfully registers with the network, the connection status of multiple preset network access channels of the vehicle terminal is identified, and an identification result is obtained. Based on the identification result, a first target network access channel that has not established a valid connection within a first set time period is selected from the multiple preset network access channels. Progressive connection retries are performed between the first target network access channels. This avoids blindly and frequently switching channels, reducing unnecessary resource consumption and operational complexity. For example, in a weak network environment, the current channel may only be temporarily interfered with, and retrying on that channel may result in a successful connection, while blindly switching channels may not solve the problem and may even increase connection time. Progressive connection retries can more rationally utilize each channel, improving the efficiency and success rate of retries. Attached Figure Description

[0041] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0042] Figure 1 A flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 1 of this application;

[0043] Figure 2 This is a flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 2 of this application.

[0044] Figure 3 This is a flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 3 of this application.

[0045] Figure 4 A flowchart illustrating a progressive connection retry process provided in this application;

[0046] Figure 5 This is a flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 4 of this application.

[0047] Figure 6 A flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 6 of this application;

[0048] Figure 7 A flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 7 of this application;

[0049] Figure 8 This application provides a flowchart illustrating two abnormal scenarios: network registration anomaly and persistent connection failure.

[0050] Figure 9 This is a schematic diagram of the structure of a communication fault handling device for a vehicle-mounted terminal provided in this application. Detailed Implementation

[0051] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0052] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0053] The terms "first," "second," etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0054] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, this application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0055] Reference Figure 1 This is a flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 1 of this application. Figure 1 As shown, the method may include, but is not limited to, the following steps:

[0056] Step S101: Periodically check the network registration status of the vehicle terminal.

[0057] The vehicle-mounted terminal is set with a timer to trigger a network registration status detection task at preset time intervals, such as every minute. When the timer is triggered, the vehicle-mounted terminal can communicate with the communication module (such as a 4G or 5G module) to send query commands to the communication module and obtain relevant information about the current network registration.

[0058] After receiving the instruction, the communication module can check its registration status in the PS and CS domains and send the results back to the vehicle terminal. For example, for the PS domain, it will report whether it has successfully registered with the packet-switched network and whether the registered network type is 4G or 5G; for the CS domain, it will report whether it has successfully registered with the circuit-switched network to support services such as voice calls.

[0059] Step S102: If the detection result indicates that the vehicle terminal has successfully registered with the network, identify the connection status of multiple preset network access channels of the vehicle terminal to obtain the identification result.

[0060] In this embodiment, the vehicle terminal can complete operator network registration through a cellular module (such as a 4G module or a 5G module), or it can complete hotspot access authentication through a Wi-Fi module, thus possessing basic network communication capabilities.

[0061] The preset network access channels can be used to enable the vehicle terminal to perform functions such as data uploading and command interaction. For example, multiple preset network access channels may include, but are not limited to:

[0062] Vehicle-to-Everything (V2X) Dedicated APN: This is a dedicated channel allocated by operators for services such as remote vehicle control and OTA (Over-the-Air) upgrades. Because it is designed specifically for vehicle-critical operations, it has the highest priority. For example, when performing remote vehicle start-up, emergency braking, and other control operations, data transmission through this channel ensures timeliness and reliability, avoiding command delays or loss due to network congestion.

[0063] General Data APN: Primarily used for general internet access, such as navigation map updates. When a vehicle needs to update its navigation map data, it downloads the latest map information from the cloud server through this channel to ensure the accuracy and real-time performance of navigation.

[0064] Backup APN: Activated when the primary channel (such as a vehicle-to-everything (V2X) APN or a general data APN) fails. Backup APNs are typically associated with different operators or frequency bands, thus leveraging the network coverage advantages and frequency band characteristics of different operators to improve network connectivity reliability. For example, when the primary channel becomes unusable due to an operator's network failure, the backup APN can switch to another operator's network to continue ensuring network communication for the vehicle-mounted terminal.

[0065] After the vehicle-mounted terminal successfully registers with the network, it can monitor the dialing process of each preset network access channel in real time, including initiating the dialing command, patiently waiting for the network response, and accurately judging the dialing result. Through these monitoring operations, it can accurately identify the current status of each network access channel, such as dialing successful (meaning that the channel has successfully established a network connection and can transmit data normally), dialing in progress (meaning that it is attempting to establish a connection and has not yet obtained a final result), and dialing failed (meaning that the current channel has failed to connect to the network successfully), as well as the time since each preset network access channel initiated the dialing command.

[0066] Step S103: Based on the identification result, select the first target network access channel from the plurality of preset network access channels that has not established a valid connection within a first set time period.

[0067] If a network access channel fails to establish a valid connection within a specified time, it indicates that the channel may be experiencing a malfunction or poor signal. Monitoring these channels promptly helps to quickly identify and resolve network connectivity issues, preventing prolonged connection failures from affecting the normal functioning of the vehicle terminal. For example, during remote vehicle control operations, if the relevant network access channel cannot establish a connection for an extended period, commands may not be transmitted in a timely manner, impacting normal vehicle operation and user experience.

[0068] In this embodiment, if the preset network access channel is determined to be in a successful dialing state based on the identification result, it indicates that the channel has established a valid connection and does not need to be included in the first target network access channel. If the preset network access channel is in a dialing state, it can be further determined whether the time from initiating the dialing command to the current time exceeds a first set time. If a valid connection is not established after the first set time, the channel is identified as the first target network access channel; if the channel is in a dialing failure state and continues for the first set time, it can also be identified as the first target network access channel.

[0069] The initial preset duration can be set according to actual needs and is not limited in this application. For example, the time required to establish a network access channel connection will vary under different network environments (such as signal coverage strength, network congestion level, etc.). The setting of the initial preset duration can take these factors into account to adapt to various complex network environments. For example, in areas with poor signal coverage, network connections may take longer, in which case the initial preset duration can be appropriately extended; while in areas with better network conditions, the preset duration can be relatively shortened to improve the timeliness of fault handling.

[0070] Step S104: Perform progressive connection retry between the first target network access channels.

[0071] In this embodiment, if there are multiple first target network access channels, a certain number of retries can be attempted on one of the first target network access channels. If the retries still fail, the system switches to other first target network access channels and so on, gradually progressing until a network connection is successfully established or all channels have been tried. This progressive connection retry method avoids blindly and frequently switching channels, improving the efficiency and success rate of retries.

[0072] For example, network access channels can be attempted sequentially according to priority. The dedicated APN for vehicle-to-everything (V2X) connections is a dedicated channel allocated by operators for core services such as remote vehicle control and OTA upgrades. Because it is directly linked to critical vehicle functions, it has extremely high requirements for network connection stability and timeliness, and therefore can be given the highest priority. During the progressive connection retry process, network connections can be established first through the dedicated V2X APN to ensure the smooth operation of core services.

[0073] If the dedicated APN channel for vehicle-to-everything (V2X) fails, the system can proceed to the general data APN. The general data APN is mainly used for ordinary internet access, such as navigation map updates. While its importance is slightly lower than that of core services, it still plays a crucial role in the daily use of vehicles.

[0074] If the general data APN also fails to connect, you can try using a backup APN as a last resort. Backup APNs are usually associated with different operators or frequency bands, serving as a supplement to the first two channels and providing a final connection guarantee when the first two channels cannot connect normally.

[0075] This prioritization approach ensures the connection of core business channels is guaranteed first, thereby improving the availability of critical functions.

[0076] In this embodiment, by periodically detecting the network registration status of the vehicle terminal, when the vehicle terminal successfully registers with the network, the connection status of multiple preset network access channels of the vehicle terminal is identified, and an identification result is obtained. Based on the identification result, a first target network access channel that has not established a valid connection within a first set time period is selected from the multiple preset network access channels. Progressive connection retries are then performed among the first target network access channels. This avoids blindly and frequently switching channels, reducing unnecessary resource consumption and operational complexity. For example, in a weak network environment, the current channel may only be temporarily interfered with, and retrying on that channel may lead to a successful connection. Blindly switching channels may not solve the problem and may even increase connection time. Progressive connection retries can more rationally utilize each channel, improving the efficiency and success rate of retries.

[0077] As another optional embodiment of this application, refer to Figure 2 This is a flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 2 of this application. This embodiment is mainly an implementation of step S104 in Embodiment 1, such as... Figure 2 As shown, step S104 may include, but is not limited to, the following steps:

[0078] Step S11: Select a first target network access channel that has not been retried from the first target network access channels.

[0079] In this embodiment, a simple sequential selection method can be used, such as selecting channels in the order of a preset channel list; alternatively, intelligent selection can be performed based on some characteristics of the channels, such as prioritizing channels with relatively high signal strength (if relevant signal information can be obtained). For example, if there are three first target network access channels A, B, and C, channel A is selected the first time. If channel A fails to retry, channel B is selected the next time, and so on.

[0080] Selecting channels that have not been retried ensures that each channel has a chance to participate in the connection attempt, avoiding repeated attempts on channels that have already failed and may still have problems, thus improving the efficiency and effectiveness of retrying.

[0081] Step S12: Retry the connection to the first target network access channel according to the detection cycle, and accumulate the number of connection retries.

[0082] In this embodiment, the detection period can be set as needed, and no limitation is imposed in this application. For example, the setting of the detection period can take into account multiple factors, such as the stability of the network environment and the frequency of signal changes. If the network environment changes rapidly, the detection period can be set shorter to capture changes in the network status in a timely manner; if the network environment is relatively stable, the detection period can be appropriately extended to reduce unnecessary retries and reduce system resource consumption. For example, setting the detection period to 5 seconds means that a dial-up retry request is initiated every 5 seconds for the target network access channel to attempt to establish a network connection.

[0083] Step S13: When the number of connection retries reaches the set retry limit, end the current retry and continue to execute step S11.

[0084] To avoid endless retries on a channel where a connection cannot be established, wasting system resources and time, a retry limit can be set. Each network access channel can share the same retry limit, or a separate retry limit can be set for each target network access channel.

[0085] When the number of retries for the target network access channel reaches the set retry limit, it indicates that the probability of establishing a connection through this channel under the current conditions is low, and the retry operation for this channel can be terminated. Then, continue to execute step S11, select a non-retweeted first target network access channel from the remaining first target network access channels, and repeat steps S12 and S13 until a network connection is successfully established or all first target network access channels have been tried. For example, if the retry limit is set to 3 times, if a first target network access channel still fails after 3 retries, switch to other non-retweeted channels to continue trying.

[0086] In this embodiment, when the vehicle terminal receives an emergency dialing request from another application, it can bypass the detection cycle limitation and immediately initiate a dialing operation. This is to ensure that a network connection can be quickly established in emergency situations, guaranteeing the timely transmission of critical information.

[0087] Furthermore, to ensure system stability and reliability, the in-vehicle terminal system includes a dedicated interface for handling dialing requests. New redial requests are prohibited until a dialing request interface returns a processing result. This prevents system chaos caused by multiple simultaneous dialing requests, ensuring that each dialing request is processed accurately and in an orderly manner.

[0088] In this embodiment, selecting a non-retrieved first target network access channel from the first target network access channels ensures that each channel has a chance to participate in the connection attempt, avoiding repeated attempts on channels that have already failed and may still have problems. For example, when there are three first target network access channels, selecting non-retrieved channels in sequence allows for more comprehensive utilization of the resources of each channel, improves the effectiveness of retries, and increases the chance of successfully establishing a connection.

[0089] According to the detection cycle, the connection to the first target network access channel is retried. The detection cycle can be set to take into account factors such as network environment stability and signal change frequency. If the network environment changes rapidly, a shorter detection cycle can be set to promptly capture changes in network status and quickly adjust the connection strategy. If the network environment is relatively stable, the detection cycle can be appropriately extended to reduce unnecessary retries and lower system resource consumption. This flexible detection cycle setting can better adapt to different network environments and improve the targeting and efficiency of retries.

[0090] Furthermore, a retry limit is set for each primary target network access channel. When the retry count reaches the limit, the current retry ends and the system switches to another channel that has not yet been retried. This measure avoids endless retries on a channel that cannot establish a connection, thus saving system resources and time. For example, setting a retry limit of 3 times means that if a channel fails after 3 retries, the channel is switched promptly, and resources are concentrated on trying other potentially successful channels, improving the efficiency of system resource utilization and speeding up connection establishment.

[0091] As another optional embodiment of this application, refer to Figure 3 This is a flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 3 of this application. This embodiment is mainly an implementation of step S104 in Embodiment 1, such as... Figure 3 As shown, step S104 may include, but is not limited to, the following steps:

[0092] Step S21: Select a first target network access channel that has not been retried from the first target network access channels.

[0093] Step S22: Retry the connection to the first target network access channel according to the detection cycle, and accumulate the number of connection retries.

[0094] Step S23: When the number of connection retries reaches the set retry limit, end the current retry and continue to execute step 21.

[0095] For detailed procedures of steps S21-S23, please refer to the relevant description of steps S11-S13 in Example 2, which will not be repeated here.

[0096] Step S24: When the number of connection retries for all first target network access channels reaches the set retry limit, adjust the detection period according to the incremental strategy; and continue to execute the step of selecting a first target network access channel that has not been retried from the first target network access channels.

[0097] When all connection retries for the primary target network access channels reach the set retry limit, it means that, according to the current detection period and retry strategy, all channels have failed to establish a network connection. In this case, increasing the detection period allows more time for the network environment to improve; for example, in a weak network environment, signal strength may gradually increase over time, or base station load may decrease. Extending the detection period means that the network conditions may have improved by the time the next connection attempt is made, thus increasing the probability of a successful connection.

[0098] Adjusting the detection cycle according to an incremental strategy may include, but is not limited to, any of the following:

[0099] Linear increment: For example, the initial detection period is set to 5 seconds. Once all channels have reached their retries limit, the detection period is linearly increased by a certain value, such as 2 seconds each time. The next detection period then becomes 7 seconds, the following time 9 seconds, and so on. This incrementing method is simple, direct, and easy to implement. It can gradually extend the detection interval, reducing resource consumption caused by frequent retries in potentially unstable network environments.

[0100] Exponential increment: Taking an initial detection period of 5 seconds as an example, following an exponential increment strategy, the next detection period can become 5 × 2 = 10 seconds, and the following time it becomes 10 × 2 = 20 seconds. The exponential increment method results in relatively slow growth in the early stages but rapid growth in the later stages. It is suitable for situations where the network environment may fluctuate significantly and a longer period is needed for the network condition to improve. When network problems are severe and their duration is uncertain, exponential increment can avoid prematurely initiating a large number of invalid retries.

[0101] Alternatively, the detection cycle can be increased in the order of "2 seconds -> 10 seconds -> 30 seconds", and then remain unchanged after reaching 30 seconds, in order to reduce the retry frequency.

[0102] Dynamic incrementing based on historical data: The vehicle-mounted terminal can record historical data such as the average time required to successfully establish a connection under different network environments. When all channel retries reach their limit, the detection cycle is dynamically adjusted based on the degree of matching between the current network environment and historical data. For example, if historical data shows that an average of 15 seconds is needed to successfully connect in a similar weak network environment, while the current detection cycle is 8 seconds, then the detection cycle can be adjusted to a value closer to 15 seconds, such as 14 seconds. This incrementing method is more intelligent and can make more reasonable adjustments based on the actual network conditions.

[0103] When any of the first target network access channels is successfully connected, or when the main processing unit of the vehicle terminal enters a sleep state, the detection cycle can be reset to the initial value.

[0104] In this embodiment, the first target network access channel is retried one by one. After each channel reaches the set limit for retry and still fails to connect, the detection period is adjusted according to the incremental strategy and the attempt continues. This progressive connection retry method makes full use of the resources of each channel and adapts to different network environments by adjusting the detection period, avoiding blind and frequent retries, improving retry efficiency and connection success rate, and effectively ensuring the stability of the vehicle terminal network connection.

[0105] The following section uses three primary target network access channels, APN1, APN2, and APN3, as examples to explain the progressive connection retry process in detail. For example, ... Figure 4 As shown, APN1 status check and processing:

[0106] First, obtain the connection status of APN1 and determine whether APN1 is in a state of requesting a connection but has not yet successfully connected.

[0107] If APN1 is not in a request-to-connect and not-connected state, it means that APN1 does not need to attempt to connect or has already successfully connected. In this case, directly obtain the connection status of APN2 and enter the processing flow of APN2.

[0108] If APN1 is in a request-to-connection-but-not-connected state, further determine whether the number of retries for APN1 has reached the set retry limit (e.g., 3 times).

[0109] If APN1 has not retried three times, it indicates that APN1 still has a chance to retry. In this case, APN1 is triggered to initiate a dialing operation to attempt to establish a network connection. Afterwards, the process returns to the step of obtaining the APN1 connection status and continuously monitors the connection status of APN1.

[0110] If APN1 has retried 3 times, it means that under the current detection cycle and retry policy, APN1 cannot successfully establish a connection temporarily. At this time, the connection status of APN2 is obtained, and the APN2 processing flow is entered.

[0111] APN2 Status Check and Handling:

[0112] After obtaining the connection status of APN2, determine whether APN2 is in a state of requesting a connection but has not yet successfully connected.

[0113] If APN2 is not in a request-to-connect and not-connected state, it means that APN2 does not need to attempt to connect or has already successfully connected. In this case, directly obtain the connection status of APN3 and enter the APN3 processing flow.

[0114] If APN2 is in a request-to-connect but not-connected state, further determine whether the number of retries for APN2 has reached the set retry limit (e.g., 3 times).

[0115] If APN2 has not retried three times, it indicates that APN2 still has a chance to retry. In this case, APN2 is triggered to initiate a dialing operation to attempt to establish a network connection. Afterwards, the process returns to the step of obtaining the APN2 connection status, continuously monitoring the APN2 connection status.

[0116] If the number of retries for APN2 has reached 3, it means that under the current detection cycle and retry policy, APN2 cannot successfully establish a connection temporarily. At this time, the connection status of APN3 is obtained, and the APN3 processing flow is entered.

[0117] APN3 Status Check and Handling:

[0118] After obtaining the connection status of APN3, determine whether APN3 is in a state of requesting connection but has not yet successfully connected.

[0119] If APN3 is not in a request-to-connect and not-connected state, it means that APN3 does not need to attempt to connect or has already successfully connected. In this case, the retry process for all preset network access channels ends.

[0120] If APN3 is in a request-to-connect-but-not-connected state, further determine whether the number of retries for APN3 has reached the set retry limit (e.g., 3 times).

[0121] If APN3 has not retried three times, it indicates that APN3 still has a chance to retry. In this case, APN3 is triggered to initiate a dialing operation to attempt to establish a network connection. Afterwards, the process returns to the step of obtaining the APN3 connection status, continuously monitoring the APN3 connection status.

[0122] If APN3 has retried 3 times, it means that under the current detection period and retry policy, APN3 will also be temporarily unable to establish a connection. At this point, the retry process for all preset network access channels ends. Simultaneously, the detection period is increased according to the preset incremental policy, and then a new round of progressive connection retry begins, that is, the above process restarts from obtaining the connection status of APN1.

[0123] As another optional embodiment of this application, refer to Figure 5 This is a flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 4 of this application. Figure 5 As shown, the method may include, but is not limited to, the following steps:

[0124] Step S201: Periodically check the network registration status of the vehicle terminal.

[0125] Step S202: If the detection result shows that the vehicle terminal has successfully registered with the network, identify the connection status of multiple preset network access channels of the vehicle terminal to obtain the identification result.

[0126] Step S203: Based on the identification result, select the first target network access channel from the plurality of preset network access channels that has not established a valid connection within a first set time period.

[0127] Step S204: Perform progressive connection retry between the first target network access channels.

[0128] For a detailed description of steps S201-S204, please refer to the relevant description of steps S101-S104 in Example 1, which will not be repeated here.

[0129] Step S205: Based on the identification result, select a second target network access channel from the plurality of preset network access channels whose connection failure time reaches a second preset duration; the second preset duration is greater than the first preset duration.

[0130] In this embodiment, the first set time period is relatively short, establishing a preliminary judgment benchmark. In a normal network operating environment, most functional network access channels should successfully establish a connection within the first set time period. If a channel fails to establish a valid connection within the first set time period, it indicates that the channel may have some relatively minor problems, such as brief network signal interference or localized network congestion. For these channels that fail to establish a valid connection within the first set time period—i.e., the first target network access channel—a retry mechanism can be immediately activated to attempt to restore its normal connection status through multiple connection attempts.

[0131] The second set duration is longer than the first, establishing a more stringent and longer-term judgment standard. Its core purpose is to accurately filter out channels that have been in a connection failure state for an extended period. During the operation of the vehicle terminal, even after retrying the first target network access channel, some channels may still fail to establish a connection. These channels are highly likely to face more serious and complex network faults, such as physical damage to network hardware or serious errors in network configuration parameters.

[0132] By setting a longer second set time period, channels that fail to establish a valid connection within the second set time period can be comprehensively and accurately identified and designated as the second target network access channels. This screening process lays a solid foundation for subsequent in-depth and detailed troubleshooting and handling of these channels with prolonged connection failures, enabling vehicle terminals to address network connectivity issues more effectively and improve the overall stability and reliability of the network.

[0133] In this embodiment, when the preset network access channel experiences its first connection failure, this moment can be recorded as the starting point for accumulating connection failure time. Starting from this starting point, as long as the preset network access channel remains in a connection failure state, the time can be continuously accumulated to obtain the connection failure time of the second target network access channel.

[0134] When the connection failure time reaches the second set duration, the preset network access channel can be determined as the second target network access channel.

[0135] If the channel remains in a connection failure state after the second set time period has elapsed, the connection failure time can continue to accumulate.

[0136] Step S206: Based on the different preset connection thresholds reached by the connection failure time of the second target network access channel, perform different levels of recovery operations in sequence.

[0137] Different preset connection thresholds can be used to measure the severity of network access channel connection failures. As the connection failure time accumulates, reaching different preset connection thresholds indicates different degrees of severity of the problem in the second target network access channel. At this point, different levels of recovery operations need to be taken sequentially to attempt to resolve the fault.

[0138] For example, three connection thresholds are preset as T1, T2, and T3 (T1 < T2 < T3). When the connection failure time reaches T1, the first level of recovery operation is performed. This level of operation may be relatively basic and simple, such as re-checking network configuration parameters and restarting some software modules related to the network access channel, aiming to attempt to restore the connection through some preliminary adjustments and checks.

[0139] If the connection failure time continues to accumulate to T2, it means that the first-level recovery operation has failed to solve the problem. At this time, the second-level recovery operation is executed. This level of operation may be more in-depth than the first level, such as reinstalling the network access-related drivers or performing a more comprehensive hardware test on the second target network access channel.

[0140] When the connection failure time reaches T3, a third-level recovery operation is executed. This is likely the most thorough and complex operation, such as performing a system-level factory reset of the vehicle terminal or contacting professional technicians for on-site repair, to resolve the long-term connection failure issue of the second target network access channel to the greatest extent possible. By sequentially executing different levels of recovery operations based on different preset connection thresholds, network faults of varying severity can be handled more effectively, proactively recovering from software freezes or abnormal network states of various communication modules, thereby improving the efficiency and success rate of fault handling.

[0141] In this embodiment, different processing strategies are adopted for the first target network access channel and the second target network access channel. For the first target network access channel, progressive connection retries are used to make full use of the resources of each channel and improve the connection success rate. For the second target network access channel, by accumulating the connection failure time and performing recovery operations according to different thresholds, more serious connection problems can be gradually identified and resolved, ensuring the stability of the vehicle terminal network communication.

[0142] As another optional embodiment of this application, this embodiment provides a communication fault handling method for a vehicle terminal, specifically an implementation of step S206 in the above embodiments. The method may include, but is not limited to, the following steps:

[0143] Step S31: When the connection failure time of the second target network access channel reaches the first connection threshold, control the communication module of the vehicle terminal to perform a soft reset.

[0144] A soft reset can be understood as a fault recovery method that does not involve a physical hardware restart. It can restore the communication module to its initial state or reinitialize some functions through specific operations, thereby solving communication problems caused by abnormal software operation, temporary conflicts, or state disorder, without having to completely cut off the power for a hardware restart. It can quickly restore the normal operation of the communication module to a certain extent and reduce interference with the overall system operation.

[0145] For example, the cellular communication module can be controlled to enter and exit airplane mode to achieve a soft reset. Airplane mode is a functional state that disconnects the device from all wireless communication networks (such as cellular networks, Wi-Fi, Bluetooth, etc.). When the duration of persistent connection failure reaches a first connection threshold, it means that the connection problem has persisted for a period of time that may affect normal communication. In this case, a soft reset should be attempted first.

[0146] For example, the first connection threshold can be set to 1 minute. When a network access channel experiences a prolonged connection failure, and the cumulative failure time reaches 1 minute, the vehicle terminal can issue a control command to put the cellular communication module into airplane mode. Upon entering airplane mode, the device's connection to all wireless networks is immediately severed, and the relevant processes and status of the communication module are temporarily frozen. After waiting a few seconds (e.g., 3-5 seconds), the vehicle terminal issues another command to exit airplane mode. This in-and-out operation is equivalent to a simple restart of the communication module, clearing potential temporary software faults, refreshing signal status, and resolving connection problems caused by conflicts or accumulated errors during software operation. It may allow the communication module to re-establish a stable network connection without requiring a more complex and time-consuming hardware restart.

[0147] Step S32: When the connection failure time of the second target network access channel reaches the second connection threshold, request to capture the underlying log of the communication module; the second connection threshold is greater than the first connection threshold.

[0148] The second connection threshold is greater than the first connection threshold. For example, the first connection threshold could be 1 minute, and the second connection threshold could be set to 3 minutes. When the connection failure time reaches 3 minutes, it indicates that the soft reset has failed to resolve the issue, and at this point, a request is made to capture the underlying logs of the communication module.

[0149] The underlying logs can record various detailed information during the operation of the communication module, including signal strength changes, connection requests and responses, error codes, etc. By analyzing these logs, technicians can gain a deeper understanding of the reasons for connection failures, such as whether it is due to interference from a specific signal frequency or a communication protocol error, providing a basis for subsequent troubleshooting and repair.

[0150] Step S33: When the connection failure time of the second target network access channel reaches the third connection threshold, request to restart the main processing unit of the vehicle terminal; the third connection threshold is greater than the second connection threshold.

[0151] When the connection failure time reaches the third connection threshold of 5 minutes, it often means that even after lower-level recovery operations such as repeatedly entering and exiting airplane mode (soft reset), the network connection still cannot be successfully restored, and the fault may have become quite serious and complex. At this point, requesting a restart of the vehicle terminal's main processing unit becomes a necessary solution. As the core control component of the vehicle terminal, the main processing unit is responsible for the operation management and coordination of the entire system. It controls the execution of various software programs, the driving of hardware devices, and critical tasks such as data processing and transmission. Restarting the main processing unit is equivalent to performing a comprehensive initialization of the entire system, which can clear accumulated error states during system operation, release occupied resources, and reload the correct software configuration. This may resolve serious connection problems caused by system software conflicts, memory leaks, program malfunctions, etc., and restore the normal communication function of the vehicle terminal.

[0152] In this embodiment, before requesting a restart of the main processing unit of the vehicle terminal, a restart configuration item check can be performed. The specific process is as follows:

[0153] The vehicle terminal has a set of pre-set configuration parameters related to restart, which constitute the restart configuration items. These configuration items may include whether to allow the main processing unit to restart when a specific connection threshold is reached, details of the restart trigger conditions (e.g., whether restart is only allowed in a specific network environment), and log recording requirements before restart (e.g., whether detailed system status information needs to be recorded for subsequent analysis of the cause of the failure).

[0154] When the connection failure time reaches the third connection threshold, the values ​​of each configuration item can be read one by one. For example, for the configuration item "Allow restart", if the read value is "yes", it means that the basic prerequisites for restarting are met under the current circumstances; if the read value is "no", even if the connection failure time reaches the threshold, the restart operation will not be performed, and other backup fault handling measures may be taken instead.

[0155] For other configuration items, such as pre-reboot logging requirements, if the configuration specifies the need for detailed logging, the fault handling module will invoke the logging module before requesting a reboot of the main processing unit. This will record key system status information, such as the list of running processes, memory usage, and network connection status parameters, into a designated log file according to a specific log format. The purpose of this is to allow maintenance personnel to analyze this log information after a reboot, enabling more accurate identification of the root cause of the fault and facilitating targeted repairs and optimizations.

[0156] After completing the checks and processing of all relevant restart configuration items, if the restart conditions are met, a request can be made to restart the main processing unit of the vehicle terminal.

[0157] In this embodiment, to avoid frequent system restarts, the number of restarts per day can be counted, and the cumulative number of restarts can not exceed a preset restart threshold (e.g., 3 times).

[0158] In this embodiment, the connection threshold, whether to capture system logs when the threshold is reached (for subsequent analysis of the cause of the failure), and whether to allow restart operations can be flexibly adjusted through configuration items according to specific application scenarios and requirements.

[0159] In this embodiment, depending on the duration of the connection failure, different levels of recovery operations are sequentially performed, including soft reset, capturing underlying logs, and restarting the main processing unit. This tiered approach allows for the initial attempt at simple and quick solutions when the problem is minor. If the problem persists, more in-depth measures are then gradually implemented. This improves problem-solving efficiency, avoids unnecessary complex operations, and ensures the stability and reliability of the vehicle terminal network communication.

[0160] As another optional embodiment of this application, refer to Figure 6 This is a flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 6 of this application. Figure 6 As shown, the method may include, but is not limited to, the following steps:

[0161] Step S301: Periodically check the network registration status of the vehicle terminal.

[0162] Step S302: If the detection result shows that the vehicle terminal has successfully registered with the network, identify the connection status of multiple preset network access channels of the vehicle terminal to obtain the identification result.

[0163] Step S303: Based on the identification result, select the first target network access channel from the plurality of preset network access channels that has not established a valid connection within a first set time period.

[0164] Step S304: Perform progressive connection retry between the first target network access channels.

[0165] For a detailed description of steps S301-S304, please refer to the relevant description of steps S201-S204 in Example 4, which will not be repeated here.

[0166] Step S305: Determine whether the vehicle terminal is currently in a voice call service.

[0167] Voice call services have extremely high requirements for the real-time performance and stability of network connections. Performing network recovery operations during a call may affect call quality. For example, if the in-vehicle terminal is in the middle of an emergency voice call, performing a soft reset or restart may cause the call to be interrupted, causing inconvenience to the user and even safety hazards.

[0168] If not, proceed to step S306.

[0169] Step S306: Based on the identification result, select a second target network access channel from the plurality of preset network access channels whose connection failure time reaches a second preset duration; the second preset duration is longer than the first preset duration.

[0170] Step S307: Based on the different preset connection thresholds reached by the connection failure time of the second target network access channel, perform different levels of recovery operations in sequence.

[0171] For a detailed description of steps S306-S307, please refer to the relevant description of steps S205-S206 in Example 4, which will not be repeated here.

[0172] In this embodiment, before selecting a second target network access channel from the plurality of preset network access channels that has not established a valid connection within a second set time period based on the identification result, it is determined whether the vehicle terminal is currently in a voice call service. This step fully considers the special characteristics of voice call services, avoids network recovery operations that may affect call quality during the call, ensures the user's communication experience during the call, and also ensures that long-term connection failures can be dealt with in a timely manner when not in a call state, thereby improving the overall stability and reliability of the vehicle terminal's network communication.

[0173] As another optional embodiment of this application, refer to Figure 7 This is a flowchart illustrating a communication fault handling method for a vehicle-mounted terminal provided in Embodiment 7 of this application. Figure 7 As shown, the method may include, but is not limited to, the following steps:

[0174] Step S401: Periodically check the network registration status of the vehicle terminal.

[0175] The vehicle-mounted terminal is set with a timer to trigger a network registration status detection task at preset time intervals, such as every minute. When the timer is triggered, the vehicle-mounted terminal can communicate with the communication module (such as a 4G or 5G module) to send query commands to the communication module and obtain relevant information about the current network registration.

[0176] After receiving the instruction, the communication module can check its registration status in the PS and CS domains and send the results back to the vehicle terminal. For example, for the PS domain, it will report whether it has successfully registered with the packet-switched network and whether the registered network type is 4G or 5G; for the CS domain, it will report whether it has successfully registered with the circuit-switched network to support services such as voice calls.

[0177] Step S402: If the detection result shows that the vehicle terminal has successfully registered with the network, identify the connection status of multiple preset network access channels of the vehicle terminal to obtain the identification result.

[0178] Step S403: Based on the identification result, select the first target network access channel from the plurality of preset network access channels that has not established a valid connection within a first set time period.

[0179] Step S404: Perform progressive connection retry between the first target network access channels.

[0180] For detailed procedures of steps S401-S404, please refer to the relevant description of steps S101-S104 in Example 1, which will not be repeated here.

[0181] Step S405: When the detection result shows that the network registration status meets the preset abnormal conditions, it is determined to be an abnormal network registration, and the abnormal network registration time is accumulated.

[0182] The preset abnormal conditions can include a variety of situations. For example, if either the PS domain or the CS domain fails to register, that is, if even one domain fails to register successfully with the network, it is judged as a network registration abnormality; or if the network type registered is lower than the preset value, such as the preset requirement that the vehicle terminal must register with a 4G or 5G network, but it is actually registered with a 2G or 3G network, it is also judged as a network registration abnormality.

[0183] When the network registration status is detected to meet these abnormal conditions, the vehicle terminal can start a timer to accumulate the abnormal network registration time. The timer starts from the moment the abnormality is determined, and the accumulated time increases by one second for every second that passes.

[0184] Step S406: Based on the different preset threshold values ​​reached during the abnormal netting time, perform different levels of recovery operations in sequence.

[0185] Different preset network registration thresholds represent varying durations of network registration anomalies. As the anomaly duration reaches higher preset thresholds, progressively higher-level recovery operations can be executed until network communication returns to normal or the highest-level preset operation is achieved. This approach allows for targeted recovery measures of varying intensities based on the severity and duration of the network registration anomaly, improving the efficiency and success rate of resolving network communication failures.

[0186] Step S407: Based on the identification result, select a second target network access channel from the plurality of preset network access channels whose connection failure time reaches a second preset duration; the second preset duration is greater than the first preset duration.

[0187] Step S408: Based on the different preset connection thresholds reached by the connection failure time of the second target network access channel, perform different levels of recovery operations in sequence.

[0188] For detailed procedures of steps S407-S408, please refer to the relevant descriptions of S205-S206 in Example 4, which will not be repeated here.

[0189] In this embodiment, the network registration status of the vehicle terminal is periodically checked. When the network registration status meets preset abnormal conditions, it is determined to be a network registration anomaly, and the network registration anomaly time is accumulated. Based on different preset network registration thresholds reached during the network registration anomaly time, different levels of recovery operations are executed sequentially. This hierarchical processing method fully considers the severity and duration of network faults. Different levels of recovery measures are adopted for different degrees of network faults, avoiding a one-size-fits-all approach and enabling more reasonable and effective use of resources to resolve network communication faults.

[0190] As another optional embodiment of this application, the communication fault handling method for a vehicle terminal provided in Embodiment 8 of this application is mainly an implementation of the above-mentioned step S403, which may include but is not limited to the following steps:

[0191] Step S41: When the abnormal registration time reaches the first registration threshold, control the communication module of the vehicle terminal to perform a soft reset.

[0192] When the cumulative abnormal registration time reaches the first registration threshold (such as 5 minutes, 10 minutes, 15 minutes), the vehicle terminal can send a soft reset command to the communication module.

[0193] A soft reset can be achieved by controlling the communication module to enter and exit flight mode. For example, first send a command to put the communication module into flight mode, disconnecting from all wireless networks. After waiting 3-5 seconds, send another command to exit flight mode and re-attempt network registration.

[0194] Step S42: When the abnormal network registration time reaches the second network registration threshold, request to capture the underlying logs of the communication module; the second network registration threshold is greater than the first network registration threshold.

[0195] When the network registration anomaly time reaches the second network registration threshold (e.g., 9 minutes, 14 minutes), it indicates that a soft reset has failed to resolve the network registration anomaly. At this time, the vehicle terminal sends a request to the communication module to capture its underlying logs. After receiving the request, the communication module collects and records underlying information related to network registration, such as signal strength changes, connection requests and responses, error codes, etc., and then sends this log information to the main processing unit of the vehicle terminal for storage.

[0196] Step S43: When the abnormal registration time reaches the third registration threshold, request to restart the main processing unit of the vehicle terminal; the third registration threshold is greater than the second registration threshold.

[0197] When the network registration anomaly time reaches the third network registration threshold (e.g., 18 minutes), it often means that the network registration anomaly problem has not been resolved after previous soft resets and log capture operations, and the fault may be quite serious and complex. At this time, the vehicle terminal can first perform a restart configuration check, reading the internally preset restart-related configuration parameters, such as whether a main processing unit restart is allowed when the threshold is reached, and the log recording requirements before restart. If the restart conditions are met (e.g., the configuration allows restart and the necessary log recording has been completed), a restart command is sent to the main processing unit to perform a full initialization.

[0198] In this embodiment, to avoid frequent system restarts, the number of restarts per day can be counted, and the cumulative number of restarts can not exceed a preset restart threshold (e.g., 3 times).

[0199] In both network registration anomalies and persistent connection failures, the main processing unit can share the same daily counter when restarting, for example, the total number of restarts cannot exceed 3.

[0200] In this embodiment, when the network registration anomaly time reaches the first network registration threshold, the control communication module performs a soft reset. The soft reset operation is relatively simple and quick, achieved by controlling the communication module to enter and exit airplane mode, first disconnecting from all wireless networks, and then re-attempting network registration. This method can attempt to restore network connectivity at a lower cost in the early stages of a network registration anomaly, avoiding more complex and time-consuming operations. It helps to quickly resolve network registration anomalies when the problem is minor, restoring the normal network communication function of the vehicle terminal and minimizing the impact on user experience.

[0201] When the network registration anomaly time reaches the second network registration threshold, it indicates that a soft reset has failed to resolve the network registration anomaly. At this point, a request is made to capture the underlying logs of the communication module. The underlying logs record detailed information about the communication module's operation, such as signal strength changes, connection requests and responses, and error codes. By analyzing these logs, technicians can gain a deeper understanding of the specific causes of the network registration anomaly, such as whether it is due to interference from a specific signal frequency or a communication protocol error. This provides accurate and detailed information for subsequent troubleshooting and repair, helping to resolve network faults more effectively.

[0202] When the abnormal network registration time reaches the third network registration threshold, restarting the main processing unit can perform a comprehensive initialization of the entire system, clear the error states accumulated during system operation, release occupied resources, and reload the correct software configuration. This may resolve some serious network registration problems caused by system software conflicts, memory leaks, abnormal program operation, etc., and restore the normal communication function of the vehicle terminal.

[0203] As another optional embodiment of this application, the communication fault handling method for a vehicle terminal provided in Embodiment 9 of this application is mainly an implementation method for determining a network registration anomaly when the network registration status meets preset abnormal conditions. Specifically, it may include, but is not limited to, at least one of the following:

[0204] Step S51: When the network registration status meets the preset abnormal conditions, and it is determined that the vehicle terminal is in a valid network service environment, it is judged as a network registration abnormality.

[0205] The vehicle-mounted terminal obtains its own geographical location information through a built-in positioning module (such as a GPS module), and combines this information with pre-stored map data and network coverage information to determine whether the current location is within a valid network service area. For example, the map data marks the network coverage areas of various operators, and the vehicle-mounted terminal compares its own location with these coverage areas. If the location is within the coverage area and a signal of a certain strength can be detected (e.g., signal strength greater than -95dBm), then it is determined to be in a valid network service environment.

[0206] For a detailed description of the process by which the network registration status meets the preset abnormal conditions, please refer to the relevant description in the foregoing embodiments, which will not be repeated here.

[0207] Determining a valid network service environment is crucial to rule out registration failures caused by being in an area with no network coverage. If the vehicle terminal itself is not located in an area where it can effectively receive a network signal, then registration failure is likely normal and does not require classification as a network registration anomaly and complex troubleshooting. Only when registration fails despite being in a valid network service environment is it more likely that a genuine network fault has occurred. In this case, classifying it as a network registration anomaly and proceeding with subsequent processing is reasonable and can improve the accuracy and efficiency of fault handling.

[0208] Step S52: When the network registration status meets the preset abnormal conditions, and it is determined that the vehicle terminal is not currently in a voice call service, it is judged as a network registration abnormality.

[0209] The vehicle-mounted terminal obtains information about whether it is currently engaged in a voice call by checking its own call status flag or interacting with the call management module. If the call status flag shows a no-call status, or the call management module reports that no voice call is currently in progress, it is determined that the vehicle-mounted terminal is not currently engaged in a voice call.

[0210] Voice call services have extremely high requirements for the real-time performance and stability of network connections. Performing network recovery operations during a call may affect call quality. For example, if the in-vehicle terminal is engaged in an emergency voice call, performing a soft reset or restart may cause call interruption, causing inconvenience to the user and even potential safety hazards. Therefore, before determining a network registration anomaly and taking recovery actions, it is necessary to ensure that the in-vehicle terminal is not engaged in a voice call. Only when the registration anomaly conditions are met in a non-call state should a network registration anomaly be determined and processed. This ensures the user's communication experience during calls and also ensures that network registration issues can be addressed promptly in non-call states, improving the overall stability and reliability of the in-vehicle terminal's network communication.

[0211] In this embodiment, two abnormal scenarios—network registration anomalies and persistent connection failures—will be described in detail using examples. For instance, as... Figure 8 As shown, with the network registration anomaly detection configuration enabled:

[0212] First, determine if the location was successfully located and if the person is not currently on a call.

[0213] If location is successful and the user is not in a call, obtain the PS and CS network registration status and network type. Then determine if there is a network registration error or if the network type is less than 4G.

[0214] If the conditions of network registration error or network type less than 4G are met, the network registration error time will be increased.

[0215] If the above conditions are not met, the abnormal registration time will be reset to zero.

[0216] If location tracking fails or the user is in a call, the abnormal registration time will be reset to zero.

[0217] If the network anomaly detection configuration is not enabled:

[0218] Determine if the APN connection error configuration is enabled.

[0219] If the APN connection is abnormally configured and enabled, determine whether the network type reaches 4G.

[0220] If the network type reaches 4G, obtain the APN connection status, and then determine whether the APN dialing has failed.

[0221] If APN dialing fails, increase the APN connection failure time.

[0222] If the APN dialing does not fail, the APN connection failure time will be reset to zero.

[0223] If the APN connection failure configuration is not enabled, or if operations such as increasing the network registration failure time or increasing the APN connection failure time have already been performed, proceed to the next step of judgment.

[0224] Determine whether the abnormal registration time or APN connection failure time has reached 5, 10, or 15 minutes.

[0225] If 5, 10, or 15 minutes are reached, the operation of entering and exiting flight mode will be performed, and the module log will be captured on the 2nd or 3rd recovery.

[0226] If the timeframes of 5, 10, and 15 minutes are not reached, continue to check whether the network registration anomaly time or APN connection failure time has reached 18 minutes.

[0227] If 18 minutes have elapsed, check if the restart strategy configuration is enabled.

[0228] If the restart policy is enabled, the power management interface is called to restart the MPU (i.e., the main processing unit).

[0229] If the restart strategy configuration is not enabled, the process ends.

[0230] The process ends if 18 minutes have not been reached.

[0231] The following section describes the communication fault handling device for the vehicle terminal provided in this application. The communication fault handling device for the vehicle terminal described below can be referred to in correspondence with the communication fault post-processing method for the vehicle terminal described above.

[0232] Reference Figure 9The communication fault handling device for the vehicle-mounted terminal may include:

[0233] The system includes a dialing management module 100, a dialing status monitoring module 200, and a network registration status monitoring module 300.

[0234] The 300 network status monitoring module can be used for:

[0235] The network registration status of the vehicle terminal is periodically checked.

[0236] Dialing management module 100 is used for:

[0237] If the detection result indicates that the vehicle terminal has successfully registered with the network, the connection status of multiple preset network access channels of the vehicle terminal is identified to obtain the identification result;

[0238] Based on the identification results, a first target network access channel that has not established a valid connection within a first set time period is selected from the plurality of preset network access channels;

[0239] Progressive connection retries are performed between the first target network access channels.

[0240] The dial-up management module 100, which performs progressive connection retries between the first target network access channels, may include:

[0241] Select one of the first target network access channels that has not been retried from the first target network access channels; retry the connection for the first target network access channel according to the detection cycle, and accumulate the number of connection retries;

[0242] When the number of connection retries reaches the set retry limit, the current retry ends, and the step of selecting a first target network access channel that has not been retried from the first target network access channels continues.

[0243] The dialing management module 100 can also be used to adjust the detection period according to an incremental strategy when the number of connection retries for all first target network access channels reaches the set retry limit; and continue to execute the step of selecting a first target network access channel that has not been retried from the first target network access channels.

[0244] The dialing status monitoring module 200 is used for:

[0245] Based on the identification results, a second target network access channel is selected from the plurality of preset network access channels, wherein the connection failure time reaches a second preset duration; the second preset duration is greater than the first preset duration;

[0246] Based on the different preset connection thresholds reached by the connection failure time of the second target network access channel, different levels of recovery operations are executed sequentially.

[0247] The dialing status monitoring module 200, based on different preset connection thresholds reached by the connection failure time of the second target network access channel, sequentially executes different levels of recovery operations, which may include:

[0248] When the connection failure time of the second target network access channel reaches the first connection threshold, the communication module of the vehicle terminal is controlled to perform a soft reset.

[0249] When the connection failure time of the second target network access channel reaches the second connection threshold, a request is made to capture the underlying logs of the communication module; the second connection threshold is greater than the first connection threshold.

[0250] When the connection failure time of the second target network access channel reaches the third connection threshold, a request is made to restart the main processing unit of the vehicle terminal; the third connection threshold is greater than the second connection threshold.

[0251] The dialing status monitoring module 200 can interact with the restart management module in the power management service to request a restart of the main processing unit of the vehicle terminal. Simultaneously, when necessary, this module can also interact with the sleep / wake-up management module and the device status management module. For example, before restarting the main processing unit, it can obtain device status information to ensure the safety and rationality of the restart operation, or perform corresponding follow-up processing based on the information fed back by the device status management module after restarting. The sleep / wake-up management module can work in conjunction with the dialing status monitoring module 200 in certain situations, such as when the system needs to restore network connectivity after entering low-power mode, to ensure the normal restoration of network connectivity.

[0252] The 300 network status monitoring module can also be used for:

[0253] When the network registration status meets the preset abnormal conditions, it is determined to be a network registration abnormality, and the network registration abnormality time begins to accumulate.

[0254] Based on the different preset threshold values ​​reached during the abnormal netting time, different levels of recovery operations are executed sequentially.

[0255] The network registration status monitoring module 300 performs different levels of recovery operations sequentially based on different preset network registration thresholds reached during the abnormal network registration time, which may include:

[0256] When the abnormal network registration time reaches the first network registration threshold, the communication module of the vehicle terminal is controlled to perform a soft reset.

[0257] When the abnormal network registration time reaches the second network registration threshold, a request is made to capture the underlying logs of the communication module; the second network registration threshold is greater than the first network registration threshold.

[0258] When the abnormal network registration time reaches the third network registration threshold, a request is made to restart the main processing unit of the vehicle terminal; the third network registration threshold is greater than the second network registration threshold.

[0259] Before the network registration status monitoring module 300 determines that the network registration is abnormal, it may also execute at least one of the following:

[0260] It is determined that the vehicle-mounted terminal is in a valid network service environment;

[0261] It is determined that the vehicle terminal is not currently engaged in a voice call service.

[0262] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0263] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0264] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0265] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for handling communication faults in a vehicle-mounted terminal, characterized in that, include: Periodically check the network registration status of the vehicle terminal; If the detection result indicates that the vehicle terminal has successfully registered with the network, the connection status of multiple preset network access channels of the vehicle terminal is identified to obtain the identification result; Based on the identification results, a first target network access channel that has not established a valid connection within a first set time period is selected from the plurality of preset network access channels; Progressive connection retries are performed between the first target network access channels.

2. The communication fault handling method for the vehicle-mounted terminal according to claim 1, characterized in that, The progressive connection retry between the first target network access channels includes: Select one of the first target network access channels that has not been retried; According to the detection cycle, the connection to the first target network access channel is retried, and the number of connection retries is accumulated. When the number of connection retries reaches the set retry limit, the current retry ends, and the step of selecting a first target network access channel that has not been retried from the first target network access channels continues.

3. The communication fault handling method for the vehicle-mounted terminal according to claim 2, characterized in that, The communication fault handling method for the vehicle-mounted terminal also includes: When the number of connection retries for all first target network access channels reaches the set retry limit, the detection period is adjusted according to the incremental strategy; and the step of selecting a first target network access channel that has not been retried from the first target network access channels continues to be executed.

4. The communication fault handling method for the vehicle-mounted terminal according to claim 1, characterized in that, The communication fault handling method for the vehicle-mounted terminal further includes: Based on the identification results, a second target network access channel is selected from the plurality of preset network access channels, wherein the connection failure time reaches a second preset duration; the second preset duration is greater than the first preset duration; Based on the different preset connection thresholds reached by the connection failure time of the second target network access channel, different levels of recovery operations are executed sequentially.

5. The communication fault handling method for the vehicle-mounted terminal according to claim 4, characterized in that, The step of sequentially executing different levels of recovery operations based on different preset connection thresholds reached by the connection failure time of the second target network access channel includes: When the connection failure time of the second target network access channel reaches the first connection threshold, the communication module of the vehicle terminal is controlled to perform a soft reset. When the connection failure time of the second target network access channel reaches the second connection threshold, a request is made to capture the underlying logs of the communication module; the second connection threshold is greater than the first connection threshold. When the connection failure time of the second target network access channel reaches the third connection threshold, a request is made to restart the main processing unit of the vehicle terminal; the third connection threshold is greater than the second connection threshold.

6. The communication fault handling method for the vehicle-mounted terminal according to claim 4, characterized in that, Before selecting a second target network access channel from the plurality of preset network access channels based on the identification result, the process further includes: Determine whether the vehicle terminal is currently engaged in a voice call service; If not, then based on the identification result, a second target network access channel is selected from the plurality of preset network access channels after the connection failure time reaches the second set duration.

7. The communication fault handling method for an in-vehicle terminal according to any one of claims 1-6, characterized in that, The communication fault handling method for the vehicle-mounted terminal further includes: When the detection result indicates that the network registration status meets the preset abnormal conditions, it is determined to be an abnormal network registration, and the abnormal network registration time begins to accumulate. Based on the different preset threshold values ​​reached during the abnormal netting time, different levels of recovery operations are executed sequentially.

8. The communication fault handling method for the vehicle-mounted terminal according to claim 7, characterized in that, The step of sequentially executing different levels of recovery operations based on different preset thresholds reached during the abnormal network registration time includes: When the abnormal network registration time reaches the first network registration threshold, the communication module of the vehicle terminal is controlled to perform a soft reset. When the abnormal network registration time reaches the second network registration threshold, a request is made to capture the underlying logs of the communication module; the second network registration threshold is greater than the first network registration threshold. When the abnormal network registration time reaches the third network registration threshold, a request is made to restart the main processing unit of the vehicle terminal; the third network registration threshold is greater than the second network registration threshold.

9. The communication fault handling method for a vehicle-mounted terminal according to claim 7, characterized in that, Before determining that the network registration is abnormal, at least one of the following is also included: It is determined that the vehicle-mounted terminal is in a valid network service environment; It is determined that the vehicle terminal is not currently engaged in a voice call service.

10. A communication fault handling device for a vehicle-mounted terminal, characterized in that, include: The network registration status monitoring module is used to periodically detect the network registration status of the vehicle terminal. The dialing management module is used to identify the connection status of multiple preset network access channels of the vehicle terminal when the detection result shows that the vehicle terminal has successfully registered with the network, and to obtain the identification result. And, based on the identification result, a first target network access channel that has not established a valid connection within a first set time period is selected from the plurality of preset network access channels; In addition, progressive connection retries are performed between the first target network access channels.

Images