Network connection method and related product

Abstract

The present application relates to the technical field of communications, and provides a network connection method and related products, the method comprising: monitoring a target notification message, the target notification message being used for representing a target fault type that causes an IMS call abnormality; and in response to the target notification message, executing a target fault recovery operation according to the target fault type and a preset fault recovery strategy so as to connect the call service network, the fault recovery strategy comprising a corresponding relationship between a plurality of fault types and a plurality of fault recovery operations. According to the method, the call service can be recovered under the condition that the user does not perceive, and the user experience is improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a network connection method and related products. Background Art

[0002] With the progress of social production and people's lives, people have higher and higher requirements for communication quality. Among many communication methods, calling is one of the most common and important methods.

[0003] Generally, a call connection requires the terminal device to register with the corresponding network normally. For example, in the case of the second generation mobile communication technology (2G) network and the third generation mobile communication technology (3G) network, the terminal device implements the call service by registering the circuit switched domain (CS domain). In the case of the fourth generation mobile communication technology (4G) and the fifth generation mobile communication technology (5G) network, the call service can be implemented by registering the Internet Multimedia Subsystem (IMS) network. The support of the call service involves a complex network connection process. During the use of the terminal device, various faults may cause the caller or the called party of the call service to be unreachable and the call cannot be made.

[0004] In order to restore the call service, the common practice is that the user needs to restart the terminal device before the call service can be restored. This operation method is cumbersome, resulting in poor user experience and a long call service restoration time. Summary of the invention

[0005] The present application provides a network connection method, device, chip, application processor, modem, electronic device, computer-readable storage medium and computer program product, which can restore call services without the user's perception and improve the user experience.

[0006] In a first aspect, a network connection method is provided, comprising: monitoring a target notification message, the target notification message being used to characterize a target fault type that causes an IMS call abnormality; responding to the target notification message, performing a target fault recovery operation according to the target fault type and a preset fault recovery strategy to connect to a call service network, wherein the fault recovery strategy includes a correspondence between multiple fault types and multiple fault recovery operations.

[0007] A management module may be provided in the AP or the Modem to monitor and collect various abnormal information, for example, to receive target notification messages reported by various modules, and the target notification messages may carry the type of fault causing the abnormal call.

[0008] It should be noted that the above fault recovery strategy may include a correspondence between multiple fault types and multiple fault recovery operations. Optionally, different fault types may correspond to the same fault recovery operation, or may correspond to different fault recovery operations. Optionally, the above fault types may be represented by different error codes, and the above different fault recovery operations may also be represented by different instructions, so the correspondence in the above fault recovery strategy may be a correspondence between multiple different error codes and multiple fault recovery operation instructions.

[0009] Optionally, when the management module monitors the target notification message, it responds to the target notification message and searches in a preset fault recovery strategy according to the target fault type represented by the target notification message. After finding the target fault recovery operation corresponding to the target fault type, the management module executes the target fault recovery operation to reconnect to the call service network.

[0010] The above network connection method can search for the target fault recovery operation corresponding to the target fault type of the current fault in the preset fault recovery strategy based on the fault type that occurs when the call is abnormal, and automatically execute the target fault recovery operation to connect to the IMS network or other call service networks, thereby realizing targeted execution of reasonable network self-healing operations. This method does not require the user to manually restart the electronic device every time a call abnormality occurs, but quickly restores the call service through precise network self-healing operations. Due to the high efficiency of call service recovery, the call service can be restored without the user being able to perceive it, which greatly improves the user experience.

[0011] In a possible implementation, the call service network is an IMS network. In response to a target notification message, a target fault recovery operation is performed according to a target fault type and a preset fault recovery strategy to connect to the IMS network, including: determining a target fault module according to the target fault type and the fault recovery strategy, the target fault module being a module in an application processor or a modem, and the fault recovery strategy also including a correspondence between multiple fault types and multiple fault modules; issuing a restart instruction, the restart instruction being used to instruct the target fault module to restart to connect to the IMS network.

[0012] The above fault recovery strategy includes a correspondence between multiple fault types and multiple fault modules, indicating that the fault type needs to be restored by restoring the state of the corresponding fault module. The AP can search in the preset fault recovery strategy according to the target fault type, find the fault module corresponding to the target fault type, and record it as the target fault module. Usually, the target fault module is a module in the AP or Modem. The modules included in the AP are: UI module, AP IMSD module and Linux DATA module; the modules included in the Modem are: NAS module, DS module and Modem IMS module. The AP can issue a restart instruction to instruct the target fault module to restart to reconnect to the IMS network. This method can accurately restart the faulty module separately without restarting the entire electronic device. Since the time taken for the module to restart separately is short, for example, the restart of the Modem takes about two seconds, and the time for the whole machine to restart is much longer than the time for the module to restart separately, often up to tens of seconds, so this method has high self-healing efficiency; and the way of realizing network self-healing by a separate module can restore the call service without the user's perception, which improves the user experience.

[0013] In a possible implementation, the modem includes: a Modem IMS module and an ADSP module, the target fault type is abnormal communication between the Modem IMS module and the ADSP module, and the target fault module is the ADSP module.

[0014] In a possible implementation manner, the modem includes: a Modem IMS module and a DS module, the target fault type is that the DS module discards the incoming call message, and the target fault module is the Modem IMS module.

[0015] In a possible implementation manner, the modem includes a Modem IMS module, the target fault type is that the Modem IMS module has not initiated an IMS network registration request, and the target fault module is the Modem IMS module.

[0016] In a possible implementation manner, the modem includes a Modem IMS module and a DS module, the target fault type is that the DS module feeds back a not ready message to the Modem IMS module, and the target fault module is the DS module.

[0017] In a possible implementation, the application processor includes a Linux data module and an AP IMSD module, the target fault type is an event in which the Linux data module fails to notify the AP IMSD module of a successful service, and the target fault module is the Linux data module.

[0018] In a possible implementation, the target fault type is a continuous failure of the calling party and / or the called party, and the target fault recovery operation is restarting the modem.

[0019] The above different fault types correspond to different fault modules that cause the fault. Based on the above correspondence, the target fault module can be accurately located, so that the target fault module can be accurately restarted to restore the fault. This method does not involve the operation of other irrelevant modules, has high self-healing efficiency, will not be perceived by users, and improves user experience.

[0020] In a possible implementation, the call service network is an IMS network, the target fault type is a voice packet fault of the call, and the target fault recovery operation is VOLTE.

[0021] When a voice packet fails in the IMS network, it is most likely due to a failure on the network side. In this case, you can turn off VOLTE to implement network rollback, thereby reconnecting to the call service network and achieving call self-healing.

[0022] In a possible implementation, the voice packet failure includes: the data format of the voice packet does not conform to a preset format, or the effective load type of the voice packet does not conform to a preset load type.

[0023] In one possible implementation, the target fault type is the loss of the quality of service parameter QOS when the network connection is switched from 5G to 4G, and the target fault recovery operation is to turn off VONR.

[0024] The fault may be serious at this time, but the specific cause cannot be determined. The management module can issue a restart command to instruct the entire electronic device to turn off the screen and restart to achieve self-healing of the call. At the same time, it will reply 488 to the network, indicating that the call service cannot be supported normally. In the case of a more serious fault, the electronic device can automatically restart, and the call can be self-healed without manual operation by the user, ensuring a high probability of fault recovery and improving the user experience.

[0025] In a possible implementation, the target fault type is a failure in initializing a voice packet, and the target fault recovery operation is restarting the electronic device.

[0026] When the Modem IMS module receives a voice packet for processing, it fails to perform the voice packet initialization operation. This fault type is: voice packet initialization failure. The fault at this time may be more serious, but the specific cause cannot be determined. The management module can issue a restart command to instruct the entire electronic device to turn off the screen and restart to achieve call self-healing. At the same time, it will also reply 488 to the network, indicating that the call service cannot be supported normally. In the case of a more serious fault, the electronic device can automatically restart, and the call can be self-healed without manual operation by the user, ensuring a higher probability of fault recovery and improving the user experience.

[0027] In one possible implementation, executing a target fault recovery operation includes: determining whether a current state of the electronic device satisfies a preset restart condition; if so, executing the target fault recovery operation; if not, monitoring the state of the electronic device until the state of the electronic device satisfies the restart condition, and executing the target fault recovery operation.

[0028] In some embodiments, when the management module receives the reported target notification message, or monitors the target notification message, it will not directly issue a restart instruction to instruct the target fault module to restart, but will determine whether it is appropriate to restart the target fault module in combination with the current state of the electronic device. Optionally, the electronic device can monitor its current state. If it is found that the current state meets the preset restart condition, it means that restarting the target fault module at this time will not affect the user's use of the electronic device, or will not be perceived by the user. Then, after obtaining the target notification message, the AP can issue a restart instruction to restart the target fault module. If the current state does not meet the preset restart condition, it means that if the target fault module is restarted at this time, it will affect the user's use of the electronic device and will be perceived by the user, so it is not suitable to execute the restart operation of the target fault module. The AP can continue to monitor the state of the electronic device, and only issue a restart instruction to instruct the target fault module to restart when the state meets the restart condition, thereby restoring the call service network. In other words, the electronic device can choose the appropriate time to restart the target fault module according to the restart condition, realize network self-healing, do not affect user use, and thus avoid being perceived by the user.

[0029] In one possible implementation, the restart conditions include: the screen state is off, the electronic device is in idle state (IDLE state), the card has not been reinserted, the network state has not changed, the target associated service is not executed, the network supports IMS service, and is not in the self-healing inhibition period, any one or more of which, the target associated service is the service associated with the target fault module.

[0030] In a possible implementation, the method further includes: recording a target fault recovery operation event and / or a target fault recovery operation time; and / or reporting a target fault recovery operation event and / or a target fault recovery operation time.

[0031] The management module can also report the target fault recovery operation event and / or target fault recovery operation time to the application layer, and then report it to the cloud server through the corresponding APK set by the application layer, so that the cloud server can perform fault statistics, self-healing situation statistics and subsequent adjustments to the fault recovery strategy. The management module can also record the target fault recovery operation event and / or target fault recovery operation time, and write the target fault recovery operation event and / or target fault recovery operation time into NV so that it can be read when needed. For example, when judging whether a restart instruction needs to be issued next time, it can be judged whether it is in the self-healing inhibition period based on the target fault recovery operation time recorded this time.

[0032] In a second aspect, a network connection device is provided, comprising a unit composed of software and / or hardware, wherein the unit is used to execute any one of the methods in the technical solution described in the first aspect.

[0033] In a third aspect, a chip is provided, comprising a processor; the processor is used to read and execute a computer program stored in a memory to perform any one of the methods in the technical solution described in the first aspect.

[0034] In some embodiments, the processor is a modem.

[0035] In some embodiments, the processor is an application processor.

[0036] In some embodiments, the chip further includes a memory, and the memory is connected to the processor via a circuit or wire.

[0037] Further optionally, the chip also includes a communication interface.

[0038] In a fourth aspect, a modem is provided, and the modem is used to execute any one of the methods in the technical solution described in the first aspect.

[0039] In a fifth aspect, an application processor is provided, and the application processor is used to execute any one of the methods in the technical solution described in the first aspect.

[0040] In a sixth aspect, an electronic device is provided, comprising: a processor, a memory and an interface; the processor, the memory and the interface cooperate with each other so that the electronic device executes any one of the methods in the technical solution described in the first aspect.

[0041] In a seventh aspect, an electronic device is provided, comprising the chip described in the third aspect.

[0042] In an eighth aspect, an electronic device is provided, comprising the modem described in the fourth aspect.

[0043] In a ninth aspect, an electronic device is provided, comprising the application processor described in the fifth aspect.

[0044] In the tenth aspect, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the processor executes any one of the methods in the technical solution described in the first aspect.

[0045] In an eleventh aspect, a computer program product is provided, comprising: a computer program code, and when the computer program code is executed on an electronic device, the electronic device executes any one of the methods in the technical solution described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 is a schematic diagram of the structure of a terminal device 100 provided in an embodiment of the present application;

[0047] Figure 2 is a software structure block diagram of the terminal device 100 provided in an embodiment of the present application;

[0048] Figure 3 This is a schematic diagram of an IMS registration process provided in an embodiment of the present application;

[0049] Figure 4 A signaling diagram of a call connection provided in an embodiment of the present application;

[0050] Figure 5 A signaling diagram of another call connection provided in an embodiment of the present application;

[0051] Figure 6 It is a software architecture diagram of a method for restarting a target fault module provided in an embodiment of the present application;

[0052] Figure 7 It is a flowchart of a network connection method provided in an embodiment of the present application;

[0053] Figure 8 This is a flowchart of another network connection method provided in an embodiment of the present application;

[0054] Fig. 9 is an interaction diagram of a network connection method provided in an embodiment of the present application;

[0055] Fig.10 is an interaction diagram of another network connection method provided in an embodiment of the present application;

[0056] Fig.11 This is a software architecture diagram of a network connection method provided in an embodiment of the present application;

[0057] Fig.12 It is a structural diagram of a network connection device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0058] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0059] In the following, the terms "first", "second", and "third" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first", "second", and "third" may explicitly or implicitly include one or more of the features.

[0060] The network connection method provided in the embodiments of the present application can be applied to terminal devices such as mobile phones, tablet computers, wearable devices, vehicle-mounted devices, augmented reality (AR) / virtual reality (VR) devices, laptop computers, ultra-mobile personal computers (UMPC), netbooks, personal digital assistants (PDA), etc. The embodiments of the present application do not impose any restrictions on the specific types of terminal devices.

[0061] For example, Figure 11 is a schematic diagram of the structure of an example of a terminal device 100 provided in an embodiment of the present application. The terminal device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0062] It is understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the terminal device 100. In other embodiments of the present application, the terminal device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0063] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present application is only a schematic illustration and does not constitute a structural limitation on the terminal device 100. In other embodiments of the present application, the terminal device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0064] The software system of the terminal device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The present application embodiment takes the Android system of the layered architecture as an example to exemplify the software structure of the terminal device 100.

[0065] Figure 21 is a software structure diagram of the terminal device 100 of the embodiment of the present application. The layered architecture divides the software into several layers, each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom, namely, the application layer, the application framework layer, the Android runtime (Android runtime) and the system library, and the kernel layer. The application layer can include a series of application packages.

[0066] like Figure 2 As shown, the application package may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0067] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0068] like Figure 2 As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0069] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0070] Content providers are used to store and retrieve data and make it accessible to applications. The data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0071] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0072] The phone manager is used to provide communication functions of the terminal device 100, such as management of call status (including connection, disconnection, etc.).

[0073] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0074] The notification manager enables applications to display notification information in the status bar, which can be used to convey notification-type messages and disappear automatically after a short stay without user interaction.

[0075] Android runtime includes core libraries and virtual machines. Android runtime is responsible for scheduling and management of the Android system.

[0076] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

[0077] The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0078] The system library may include multiple functional modules, such as surface manager, media libraries, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

[0079] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

[0080] The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0081] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0082] A 2D graphics engine is a drawing engine for 2D drawings.

[0083] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and sensor driver.

[0084] With the progress of social production and people's lives, people have higher and higher requirements for communication quality. Among many communication methods, calling is one of the most common and important methods.

[0085] Normally, call connections require that the terminal device register with the corresponding network normally. For example, in the case of 2G and 3G networks, the terminal device implements call services by registering the CS domain, and in the case of 4G and 5G networks, call services can be implemented by registering the IMS. The support of call services involves a complex network connection process. During the use of terminal devices, various faults may cause the caller or the called party to be unable to make calls. In order to restore call services, it is common for users to manually operate the terminal device to enter flight mode, and then cancel the flight mode and reconnect to the network to try to restore it.

[0086] However, in some cases, even if the user sets the terminal device to enter the flight mode and then cancels the flight mode, the terminal device cannot resume the call service. In this case, the user needs to restart the terminal device to resume the call service. This operation method is cumbersome, resulting in a poor user experience and a long call service recovery time.

[0087] In order to clearly describe the implementation principle of the technical solution provided by this application, firstly Figure 3 The process shown is used to illustrate the specific situation when the calling or called party fails to connect during a call on the terminal device. Figure 3 Interaction flow chart for registering a terminal device with the IMS network. Figure 3 The interactive objects include: modem, application processor (AP) of terminal equipment and network (NW) side equipment as an example for description. Among them, the modem includes non-access stratum (NAS) module, data service (DS) module and ModemIMS module. The NAS module is used for information transmission on the control plane between the terminal equipment and the mobility management entity (MME); the DS module can establish a bearer with the NW side equipment after successful network registration; the Modem IMS module is used to continue to register the IMS network based on the successful bearer establishment to support call services. Optionally, the above-mentioned AP can also be replaced by a multimedia application processor (MAP). The specific registration process may include the following steps:

[0088] S301. The NAS module initiates a registration request to the NW side device (if it is 5G, it can be recorded as Registration Req, if it is 4G, it can be recorded as Attach Req).

[0089] Typically, when a terminal device is turned on or starts searching for a network, the NAS module initiates a registration request to the NW test device to register the network, such as registering a 4G network or a 5G network.

[0090] S302. The NW-side device returns a registration success message (remembered as Registration Accept) to the NAS module.

[0091] Specifically, when the NW side device module receives the registration request sent by the NAS module, if the NW side device is ready and the network status is normal, the subsequent registration process can be continued to complete the registration of the basic network. The terminal device that successfully registers can provide basic network support for subsequent data services and call services.

[0092] S303: The NAS module sends a notification of successful registration to the DS module.

[0093] S304. The NAS module also sends a notification of successful registration to the Modem IMS module.

[0094] Specifically, when the NAS module receives the registration success message returned by the NW side device, it determines that the NW side device is in a ready state and the network state is normal, and then the registration success message can be notified to the DS module and the IMS module.

[0095] S305. The Modem IMS module sends an instruction message for initiating bearer establishment to the DS module.

[0096] Specifically, after the Modem IMS module receives the notification of successful registration sent by the NAS module, it may send an instruction message of establishing an IMS bearer to the DS module to continue registering the call service.

[0097] S306. The DS module sends a request to establish a bearer to the NW side device.

[0098] Specifically, the DS module responds to the triggering of the indication message for establishing a bearer sent by the Modem IMS module, and sends a protocol data unit (PDU) bearer request for establishing IMS to the NW side device (for example, in the registered 5G network, recorded as PDU SESSION SETUP REQ for IMS).

[0099] S307. The NW-side device returns a response message (for example, recorded as PDUSESSION SETUP ACCEPT) to the DS module to indicate that it accepts the request to establish the bearer.

[0100] Specifically, if the 5G network is registered, when the NW side device receives the request sent by the DS module to establish the PDU bearer of the IMS, if the status of the NW side device is normal and the PDU bearer can be established, the NW side device will feedback the return message of accepting the bearer establishment to the DS module, thereby establishing the PDU bearer. If the 4G network is registered, when the NW side device receives the request sent by the DS module to establish the package data network (PDN) bearer of the IMS, if the status of the NW side device is normal and the PDN bearer can be established, the NW side device will feedback the return message of accepting the bearer establishment to the DS module, thereby establishing the PDN bearer.

[0101] When the bearer is successfully established, the terminal device can register with the IMS network.

[0102] Under normal circumstances, after receiving the return message of accepting the bearer establishment request, the DS module will continue to execute S308 and subsequent steps to register the IMS network.

[0103] It should be noted that the execution process of the above S306 and S307 is also forwarded by the NAS module (not shown in the figure), which will not be repeated here.

[0104] S308: The DS module sends a bearer establishment success event to the Modem IMS module.

[0105] When the bearer is successfully established, the DS module may send a bearer establishment success event to the Modem IMS module based on the return message of accepting the bearer establishment request, for example, send 200event to the Modem IMS module to notify the Modem IMS module that the bearer has been successfully established.

[0106] S309, the Modem IMS module reports an activation message for activating the registered IMS network to the AP;

[0107] Specifically, after receiving the bearer establishment success event, the Modem IMS module may report an activation message (remembered as IMS PDN Activate or IMS PDU Activate) for activating the registration IMS network to the AP, so as to request activation of the IMS registration process.

[0108] S310. The AP feeds back an activation success message to the Modem IMS module.

[0109] When the AP receives the activation message for activating the registration of the IMS network reported by the Modem IMS module, the AP may activate the IMS network registration, that is, return an activation success message to the Modem IMS module.

[0110] Under the instruction of the activation success message, the Modem IMS module requests the NW side device to register the IMS network. For details, please refer to S311 and subsequent steps:

[0111] S311. The Modem IMS module sends an IMS network registration request (referred to as IMS Register) to the NW side device.

[0112] S312. The Modem IMS module receives the authentication information fed back by the NW-side device.

[0113] The NW-side device responds to the IMS network registration request and feeds back authentication information to the IMS module, for example, returning 401, for performing two-way authentication with the terminal device.

[0114] S313: The Modem IMS module sends an IMS network registration request to the NW side device again.

[0115] S314. The Modem IMS module receives an IMS network registration success message returned by the NW side device.

[0116] After receiving 401, the IMS module calculates and authenticates according to the authentication parameters carried in the authentication information. Once the authentication is passed, the IMS network registration request can be sent to the NW side device again. The IMS network registration request carries the relevant user authentication response parameters (expected user response, XRES).

[0117] When the authentication is successful, the IMS network can be successfully registered, and the NW side device can return a registration success code to the IMS module, for example: register 200OK.

[0118] S315. The Modem IMS module sends a message to the AP indicating that the IMS network has been registered.

[0119] The Modem IMS module can also report to the AP that it has registered with the IMS network. At this point, the terminal device can support call services and receive paging and invitations initiated by the network side.

[0120] Above Figure 3 The process shown is the process of terminal equipment registering IMS network under normal circumstances. However, in some abnormal situations, Figure 3The process shown cannot be fully executed, and the dotted steps are steps that will not be continued in abnormal situations. For example, when the memory of the DS module is exhausted, resulting in an abnormal socket path between the DS module and the Modem IMS module, the two cannot communicate normally. In other words, even after the bearer is successfully established, the DS module cannot output the 200event event to the Modem IMS module, that is, the DS module cannot execute the above-mentioned step S308, then the Modem IMS module cannot be informed of the current successful bearer establishment, resulting in the Modem IMS module not reporting the activation message of the successful bearer establishment to the AP, and the subsequent IMS network registration process cannot be carried out. Then, in the case that the IMS network cannot be registered normally, the IMS domain will not know the existence of the user of the terminal device, and call services cannot be provided, and the called party and the calling party will not be able to connect.

[0121] In some cases, the call between the calling party and the called party may be connected but silent. Figure 4 As shown, when the calling party initiates a call request (Invite) to the called party through the NW side device. If the called party receives the call request, a temporary response message (100Trying) can be returned through the NW test device. The called party will also ring to remind the user to connect, and at the same time, reply to the NW side device with a message that the ringing is being processed (180Ringing). The called party also replies to the network test device with the result of the negotiation (200OK). After that, the call can be established. If the called party speaks, the called party's uplink voice packet will be generated and transmitted to the calling party through the NW side device. After receiving the called party's uplink voice packet, the calling party will parse it. Under normal circumstances, if the calling party parses the received voice packet normally, it will play it, and the calling party's user will hear the other party's voice. When a normal call is established, the calling party can also send the calling party's uplink voice packet to the called party through the NW side device. However, if the calling party fails, for example, the AP of the calling party cannot properly parse the uplink voice packet sent by the called party. Specifically, the format of the uplink voice packet of the called party forwarded by the NW side device is AMR format, and the previously agreed format of the uplink voice packet is AMRWB, which means that the format of the uplink voice packet forwarded by the NW side device is incorrect, then the calling party will discard the received uplink voice packet. At this time, although the call is connected, the user of the calling party cannot hear the other party's voice. After a period of time, the called party will also perceive that the call status is single-channel, that is, the call is connected but silent.

[0122] In some cases, the abnormal call service may be caused by a fault on the AP side. Figure 5Another interactive flow chart for registering a terminal device with an IMS network. Figure 5 The three modules included in the AP are described as follows: the user interface module (UI module), the IMS distribution module on the AP side (AP IMSD module) and the Linux data module (Linux DATA module). Among them, the APIMSD module is responsible for processing the relevant logic involved in the IMS service on the AP side; the Linux DATA module is the DS module of the Linux layer on the AP side, which is used to process data services, such as processing the establishment of data calls, route allocation, IP allocation and other related logic. The specific registration process may include the following steps:

[0123] First, the terminal device executes the steps S301 to S308 as described above. Then, S309 is executed. Specifically, the specific process of step S309 is that the Modem IMS module reports the activation message of activating the registration IMS network to the AP IMSD module on the AP side. For details, see Figure 5 As shown, including:

[0124] S501. The Modem IMS module reports an activation message for activating a registered IMS network to the AP IMSD module.

[0125] Specifically, the activation message for activating the registered IMS network may be recorded as: IMS PDN Activate or IMS PDUActivate.

[0126] S502: The AP IMSD module requests the Linux DATA module to start a service (for example, recorded as: startservice).

[0127] The AP IMSD module starts the service under the trigger of the activation message and feeds back the service startup message to the Linux DATA module.

[0128] S503. The Linux DATA module feeds back an event of successful service startup to the AP IMSD module (for example, recorded as: DSIevent1).

[0129] S504: The AP IMSD module feeds back an activation success message to the Modem IMS module.

[0130] After receiving the event of successful service startup, the AP IMSD module feeds back an activation success message to the Modem IMS module.

[0131] Afterwards, the Modem IMS module continues to execute steps S311 to S315 under the triggering of the activation success message fed back by the AP IMSD module.

[0132] Afterwards, also execute:

[0133] S505: The Modem IMS module returns an IMS network registration success message to the UI module.

[0134] Specifically, when the UI module receives the IMS network registration success message, the call service success information may be displayed on the interface to inform the user that the call service is normal.

[0135] Above Figure 5 The process shown is the process of terminal equipment registering IMS network under normal circumstances. However, when a fault occurs inside the AP, Figure 5 The process shown cannot be fully executed, and the dotted steps are steps that will not be executed normally under abnormal circumstances. For example, when the Linux DATA module inside the AP fails, the above step S503 cannot be executed normally. In other words, the Linux DATA module cannot normally send the event DSI event1 to the AP IMSD module to indicate that the service to start the IMS registration has been successful, and the AP IMSD module cannot send an activation success message to the Modem IMS module, and it cannot trigger the Modem IMS module to execute the subsequent IMS network registration process. Then, in the case that the IMS network cannot be registered normally, the IMS domain will not know the existence of the user of the terminal device, and call services cannot be provided, and the called party and the calling party will not be able to connect.

[0136] There are many other cases where call abnormalities occur due to various faults in the terminal device or chip, and we will not give examples one by one here.

[0137] Based on the above situation, the embodiment of the present application provides a network connection method, which can perform reasonable network self-healing operations in a targeted manner based on the fault type that occurs when the call is abnormal. For example, when a fault occurs inside the terminal device, the modem can collect the fault type and then report the fault type to the AP, and the AP judges the faulty module that has failed according to the specific fault type, and performs accurate network self-healing operations on the faulty module, thereby restoring the call service. Optionally, after collecting the fault type, the modem does not need to report it to the AP, but the modem itself judges the faulty module that has failed according to the specific fault type, and then performs accurate network self-healing operations on the faulty module. This method does not need to spend a lot of time manually restarting the terminal device by the user every time a call abnormality occurs, but quickly restores the call service through accurate network self-healing operations. Due to the high efficiency of call service recovery, the call service can be restored without the user being able to perceive it, which greatly improves the user experience.

[0138] The implementation logic of the network connection method provided in the embodiment of the present application can also be found in Figure 6 When a terminal device fails, the modem or AP can collect the fault type and then report the fault type to the abnormal monitoring module of the application layer through the protocol conversion layer (Radiointerface layer, RIL). After the abnormal monitoring module receives the fault type, it can instruct the restart module of the application layer to issue a restart instruction for the modem. Figure 6 The restart module in can also be called a self-healing module. The restart instruction is generated by the restart module and passed to the target fault module via the RIL to instruct the target fault module to restart. The exception monitoring module can also report the fault type (also called exception reporting) to the cloud server so that the cloud server can perform statistics. Optionally, a configuration file can also be set at the application layer. The configuration file can be a file in XML format. The corresponding relationship between different fault types and different fault recovery operations can be set in the configuration file.

[0139] The above is an overview of the principles of the technical solutions involved in the embodiments of the present application. Next, the technical solutions of the present application are described in detail with reference to the accompanying drawings. Optionally, the execution subject of the embodiments of the present application can be an AP or a Modem. Figure 7 The execution subject is first described as AP, including:

[0140] S701. Monitor a target notification message, where the target notification message is used to characterize a target fault type that causes an abnormal IMS call.

[0141] Optionally, a management module may be provided in the AP, and the AP may establish a connection relationship with the modem or AP through the management module and monitor the connection, thereby collecting target notification messages indicating call abnormalities reported by the modem or AP. Optionally, the target notification message may carry the type of fault causing the call abnormality. The call abnormality may be a call failure, a called failure, a silent call, a call failure, a dropped call, etc., which is not limited in the embodiments of the present application.

[0142] S702. In response to the target notification message, according to the target fault type and a preset fault recovery strategy, a target fault recovery operation is performed to connect to the call service network, wherein the fault recovery strategy includes a correspondence between multiple fault types and multiple fault recovery operations.

[0143] Optionally, when the AP monitors the target notification message, it responds to the target notification message and searches in a preset fault recovery strategy according to the target fault type represented by the target notification message. After finding the target fault recovery operation corresponding to the target fault type, the AP executes the target fault recovery operation and can reconnect to the IMS network or other call service network.

[0144] It should be noted that the above fault recovery strategy may include a correspondence between multiple fault types and multiple fault recovery operations. Optionally, different fault types may correspond to the same fault recovery operation, or may correspond to different fault recovery operations. Optionally, the above fault types may be represented by different error codes, and the above different fault recovery operations may also be represented by different instructions, so the correspondence in the above fault recovery strategy may be a correspondence between multiple different error codes and multiple fault recovery operation instructions.

[0145] Optionally, the above fault recovery strategy can be stored in a configuration file, which can be an XML file. When the AP monitors the target notification message, it can read the configuration file to obtain the fault recovery strategy and find the target fault recovery operation corresponding to the target fault type to execute.

[0146] The network connection method provided in the embodiment of the present application can search for a target fault recovery operation corresponding to the target fault type of the current fault in a preset fault recovery strategy based on the fault type that occurs when a call is abnormal, and automatically execute the target fault recovery operation to connect to the IMS network or other call service networks, thereby realizing targeted execution of reasonable network self-healing operations. This method does not require the user to manually restart the terminal device every time a call abnormality occurs, but quickly restores the call service through precise network self-healing operations. Due to the high efficiency of call service recovery, the call service can be restored without the user being able to perceive it, which greatly improves the user experience.

[0147] In some embodiments, the above-mentioned fault recovery strategy includes a correspondence between multiple fault types and multiple fault modules, indicating that the fault type needs to be restored by restoring the state of the corresponding fault module. An implementation method of the above-mentioned step S702 includes: the AP can search in the preset fault recovery strategy according to the target fault type, find the fault module corresponding to the target fault type, and record it as the target fault module. Usually, the target fault module is a module in the AP or the Modem. The modules included in the AP are: UI module, AP IMSD module and Linux DATA module; the modules included in the Modem are: NAS module, DS module and Modem IMS module. The AP can issue a restart instruction to instruct the target fault module to restart to reconnect to the IMS network. The correspondence shown in the following Table 1 shows the correspondence between different fault types and different fault modules.

[0148] Table 1

[0149]

[0150] As shown in Table 1:

[0151] When fault 1 occurs, that is, the core voice driver (CVD) is not ready (CVD notready), resulting in abnormal interaction of voice packets between the Modem IMS module and the audio digital signal processor (ADSP) module, a silent call will occur. In other words, the Modem IMS module can parse the voice packet normally, but when it is sent to the ADSP for playback, it is found that the handshake between the ADSP and the Modem IMS module fails and the connection cannot be established normally. This type of fault is: abnormal communication between the Modem IMS module and the ADSP module. Based on this, it can be determined that the abnormality of the ADSP module causes the Modem IMS module to report the notification message of the ADSP module failure to the management module, and the ADSP module is determined as the target fault module. The Modem IMS module may discard the currently received voice packet (RTP). At the same time, the AP can issue a command to restart the ADSP module to instruct the ADSP module to restart in order to recover from the fault and achieve self-healing of the call.

[0152] When fault 2 occurs, that is, an exception occurs when the Modem IMS module operates the Socket command, resulting in the DS module being unable to notify the Modem IMS module of the incoming call message through the path between the two. Therefore, the DS module will discard the incoming call message, resulting in the restriction of the called party's failure. Based on this, it can be determined that the abnormality of the Modem IMS module causes the communication failure between the Modem IMS module and the DS module, so that the DS module cannot normally notify the Modem IMS module of the incoming call message. However, the Modem IMS module cannot perceive such anomalies and needs to be perceived through the DS module. This type of fault is: the DS module discards the incoming call message. When the DS module discards the incoming call message, the DS module can report the notification message of the Modem IMS module failure to the management module, and the Modem IMS module is determined to be the target fault module. At the same time, the AP can issue a restart instruction to restart the Modem IMS module to instruct the Modem IMS module (Modem IMS protocol stack) to restart to recover the fault, thereby re-registering the IMS network and realizing call self-healing.

[0153] It should be noted that in the embodiment of the present application, the restart of the target fault module is a soft restart of the target fault module, which can also be called a restart of the protocol stack corresponding to the target fault module. For example, restarting the Modem IMS module can also be called restarting the Modem IMS protocol stack, restarting the Modem can be called restarting the Modem protocol stack, restarting the DS module can be called restarting the DS protocol stack, etc., which will not be repeated here.

[0154] When fault 3 occurs, the internal module status of the Modem IMS is inconsistent. Usually, the Modem IMS module is a general service module, which also includes multiple submodules, such as submodule 1 responsible for registration and submodule 2 responsible for call flow management. If submodule 1 believes that the IMS network has been registered, it will not initiate registration again; while submodule 2 believes that the IMS network is not registered, the call will fail, thinking that it has not been registered. When the status of these submodules is inconsistent, it will cause the IMS network to be unregistered. In other words, the Modem will not initiate registration or re-registration, and the phenomenon of called failure will occur. In other words, the IMS network has not been successfully registered. This type of fault is: the Modem IMS module has not initiated an IMS network registration request. Based on this, it can be determined that it is caused by an abnormality in the Modem IMS module, and the Modem IMS module reports a notification message of the Modem IMS module failure to the management module, and the Modem IMS module is determined as the target fault module. At the same time, the AP can issue a command to restart the Modem IMS module to instruct the Modem IMS module (IMS protocol stack) to restart to recover from the fault, thereby re-registering with the IMS network and achieving call self-healing.

[0155] When fault 4 occurs, that is, the DS module receives an incoming call message and needs to prepare call resources, but finds that the memory is exhausted and cannot create a Socket command channel for the voice packet (QCI#1), that is, it cannot provide call resources. At this time, it can reply 488 to the network, indicating that it cannot support call services normally. At the same time, the DS module also returns an unready message to the Modem IMS module indicating that it is in an unready state. When the Modem IMS module receives the unready message fed back by the DS module, it reports it to the management module. This type of fault is: the DS module feeds back an unready message to the Modem IMS module. Based on this, it can be determined that it is caused by an abnormality in the DS module. The Modem IMS module reports a notification message of the DS module failure to the management module, and the DS module is determined as the target fault module. At the same time, the AP can issue a command to restart the DS module (DS protocol stack) to instruct the DS module to restart to restore the fault, thereby re-registering the IMS network and realizing call self-healing.

[0156] When fault 5 occurs, that is, the Linux data module fails to notify the AP IMSD module of the event of successful activation of the Packet Data Protocol (PDP) service, the subsequent normal registration process of the IMS network cannot be executed, so the phenomenon of failure to successfully register the IMS network will occur. This fault type is: the Linux data module fails to notify the AP IMSD module of the event of successful service. Based on this, it can be determined that it is caused by an abnormality in the Linux data module. Specifically, when the AP IMSD module feeds back a message to start the service to the Linux data module within a period of time, for example, the timer can be started. When the timing reaches the agreed period, the event (DSI event 1) of successful service notification fed back by the Linux data module has not been received, indicating that the Linux data module has a fault. The AP IMSD module reports the notification message of the AP IMSD module fault to the management module, and the AP IMSD module is determined as the target fault module. At the same time, the AP can issue an instruction to restart the AP IMSD module to instruct the AP IMSD module to restart to restore the fault, thereby re-registering the IMS network and realizing call self-healing.

[0157] In some cases, if a fault occurs in the received voice packet, the Modem IMS module cannot parse the voice packet normally or the data of the parsed voice packet does not meet the requirements, and a silent call will occur. This type of fault is: voice packet failure of the call. Optionally, the voice packet failure may be that the data format of the voice packet does not match the preset format. For example, the voice packet lacks frame data (Frame data) compared to the preset format, and the voice packet is an empty packet with no voice content. When the Modem IMS module parses a voice packet whose data format does not meet the preset format, the voice packet failure of the call can be reported to the management module. Based on the fault type, the management module determines that the cause of the fault is usually a problem on the network side, so the call service can be restored by rolling back the network. Specifically, the management module can shut down the LTE voice bearer (VOLTE). Optionally, VOLTE can be temporarily shut down. If the network is 5G before VOLTE is turned off, it will automatically fall back to 4G after it is turned off; if the network is 4G before VOLTE is turned off, it will automatically fall back to 2G or 3G after it is turned off, realizing automatic network fallback, thereby reconnecting to the call service network and achieving call self-healing.

[0158] It should be noted that the actual operation of shutting down VOLTE is to shut down the IMS service. For voice-centric devices (such as smartphones), if the 5G network is not registered with the IMS network (IMS service), it means that there is no voice service capability, so it is necessary to fall back to the 4G LTE network. The 4G LTE network has the ability to register the IMS network and the CS domain at the same time. If the IMS network is not registered, the voice call capability of the CS domain can still be retained.

[0159] In some embodiments, the fault type of the voice packet failure of a call may also be: the payload type (payload type) of the voice packet does not conform to the preset payload type, in which case a silent call restriction will occur. For example, the agreed payload type is identified as 100, but the payload type of the received voice packet is identified as 96, which means that the payload type 96 does not match the preset payload type 100. The Modem IMS module cannot parse the voice packet normally, so no sound can be heard. The Modem IMS module reports the payload type of the voice packet of the call that does not conform to the preset payload type to the management module, and this fault type. Based on the fault type, the management module determines that the cause of the fault is usually a problem on the network side, so the call service can be restored by rolling back the network. Specifically, the management module can shut down the LTE voice bearer (VOLTE), and optionally, it can temporarily shut down VOLTE to roll back the network. If the network is 5G before VOLTE is turned off, it will automatically fall back to 4G after it is turned off; if the network is 4G before VOLTE is turned off, it will automatically fall back to 2G or 3G after it is turned off, realizing automatic network fallback, thereby reconnecting to the call service network and achieving call self-healing.

[0160] In some cases, when the network switches from 5G to 4G, if the Modem IMS module finds that the quality of service (QOS) parameter is lost, it means that the bearer is lost, such as the bearer loss of voice QCI=1. Specifically, the notification received from the NAS module lacks the QOS parameter, indicating that the bearer is lost and calls will be dropped. This type of failure is: QOS is lost when the network connection switches from 5G to 4G. If the bearer is lost, the voice call service cannot be established normally based on the successfully established bearer. At this time, the Modem IMS module can report the fault type to the management module, and the management module can output an instruction to instruct the closure of the new air interface voice bearer (Voice over New Radio, VONR). Optionally, it can be instructed to temporarily close VONR to avoid the phenomenon of bearer loss when the network connection switches from 5G to 4G.

[0161] In some cases, when the Modem IMS module receives a voice packet for processing, it fails to perform the voice packet initialization operation (RTP init fail). This fault type is: voice packet initialization failure. The fault may be serious at this time, but the specific cause cannot be determined. The management module can issue a restart command to instruct the entire terminal device to turn off the screen and restart to achieve call self-healing. At the same time, it will reply 488 to the network, indicating that the call service cannot be supported normally. In the case of a more serious fault, the terminal device can automatically restart, and the call can be self-healed without manual operation by the user, ensuring a high probability of fault recovery and improving the user experience.

[0162] In some cases, whether in the calling state or the called state, failures will be returned directly and continuously. This fault type is: continuous failure of calling and / or called. At this time, it can be determined that the fault is caused by the modem, but it is impossible to determine which module of the modem is faulty. In this case, the entire modem can be determined as the target faulty module, and the AP can directly send a command to restart the modem (modem protocol stack) to instruct the modem to restart to recover from the fault, thereby re-registering the IMS network and realizing call self-healing.

[0163] In some embodiments, the management module may also monitor messages inside the Modem to specifically determine that the Modem is abnormal, and then execute an operation to restart the Modem. Specifically, it may be:

[0164] The AP can monitor the bearer establishment of the Modem through the management module, for example, whether the PDU bearer or PDN bearer is successfully established. Taking the registration of the 5G network as an example, when the PDU bearer is successfully established, the DS module will receive a return message from the NW side device accepting the bearer establishment request, and in response to the return message, determine whether the IMS network is successfully registered.

[0165] When the bearer is successfully established, the AP can continue to monitor whether the modem is successfully registered with the IMS network. Optionally, the AP can monitor whether the modem is successfully registered with the IMS network through the management module. It should be noted that the AP can monitor whether the bearer of the modem is successfully established by monitoring the status of the DS module, and the AP can monitor whether the IMS network registration of the modem is successful by monitoring the status of the Modem IMS module.

[0166] If the Modem fails to successfully register with the IMS network after the bearer is successfully established. For example, if the management module monitors that the Modem does not receive a message of successful registration with the IMS network within a preset period of time after the bearer is successfully established, it means that the Modem has failed to successfully register with the IMS network, which may be due to a fault inside the Modem. For example, when the socket path between the DS module and the Modem IMS module is blocked, even if the bearer is successfully established, the DS module cannot send a bearer establishment success event to the Modem IMS module, resulting in the Modem IMS module being unable to execute the subsequent process of registering with the IMS network. At this time, the AP can send a restart command to the Modem, instructing the Modem to restart and achieve network self-healing.

[0167] In some embodiments, the AP determines whether the modem has successfully registered with the IMS network by starting a timer when the AP monitors that the bearer of the modem has been successfully established. If the AP does not monitor a message indicating that the modem has successfully registered with the IMS network within a preset period of the timer, or monitors a message indicating that the modem has failed to successfully register with the IMS network, it means that the modem has not successfully registered with the IMS network. At this time, the AP can continue to monitor whether the bearer of the modem has been successfully established, or continue to monitor whether the modem has successfully registered with the IMS network. If the AP monitors that the modem has successfully registered with the IMS network within a preset period after starting the timer, there is no need to restart the modem.

[0168] After monitoring the successful bearer establishment of the modem, if the AP has not successfully registered the IMS network, it can restore the connection to the IMS network by restarting the modem. This method can achieve network self-healing without the user having to manually restart the entire terminal device. Since the time taken for the modem restart is short, usually only about 2 seconds, while the time for the entire machine to restart is much longer than two seconds, often up to tens of seconds, this method has high self-healing efficiency; and the way to achieve network self-healing by restarting the modem alone can restore call services without the user's perception, improving the user experience.

[0169] In some embodiments, when the AP receives a target notification message of a fault type characterizing a module fault reported by the module, or when the AP monitors a target notification message of a fault type characterizing a module fault, it will not directly issue a restart instruction to instruct the target fault module to restart, but will determine whether it is appropriate to restart the target fault module in combination with the current state of the terminal device. Optionally, the terminal device can monitor its own current state. If it is found that the current state meets the preset restart condition, it means that restarting the target fault module at this time will not affect the user's use of the terminal device, or will not be perceived by the user. Then, the AP can issue a restart instruction to restart the target fault module after obtaining the target notification message. If the current state does not meet the preset restart condition, it means that if the target fault module is restarted at this time, it will affect the user's use of the terminal device and will be perceived by the user, so it is not appropriate to execute the restart operation of the target fault module. The AP can continue to monitor the state of the terminal device, and only issue a restart instruction to instruct the target fault module to restart when the state meets the restart condition, thereby restoring the network. In other words, the terminal device can choose a suitable time to restart the target fault module according to the restart condition, realize network self-healing, do not affect user use, and thus avoid being perceived by the user.

[0170] Next, the restart conditions are described in detail. The restart conditions may include: the screen is off, the terminal device is in IDLE state, the target associated service is not executed (i.e., the service associated with the target fault module, for example, the terminal device does not perform any service involving the Modem), the terminal device is not in the self-healing inhibition period at the current moment, the card is not reinserted, the network status has not changed, and the network supports any one or more of the following combinations.

[0171] Optionally, when the screen of the terminal device is off, it is considered that the possibility that the user is currently using the terminal device is relatively small, so it can be determined that the restart condition is met, and a restart instruction is issued; if the screen is on, it is considered that the possibility that the user is currently using the terminal device is relatively high. If the restart target fault module is easily perceived by the user, it is determined that the restart condition is not met. The restart instruction may not be issued temporarily, but the status of the terminal device may continue to be monitored until the restart condition is met.

[0172] Optionally, when the terminal device is in the ILDE state, it is determined that the restart condition is met and a restart instruction is issued; if the terminal device is not in the ILDE state, but in a non-ILDE state such as a data service state, it is determined that the restart condition is not met, and the restart instruction may not be issued temporarily, but the status of the terminal device continues to be monitored until the restart condition is met.

[0173] Optionally, if the terminal device is not currently performing any services involving the target fault module, such as a modem, it can be determined that the restart condition is met and a restart instruction can be issued; if the terminal device is currently performing any services involving the target fault module, such as a modem, such as playing a video or music, it can be determined that the restart condition is not met, and therefore a restart instruction is not issued for the time being, but the status of the terminal device continues to be monitored until the restart condition is met.

[0174] Optionally, if the current moment is not within the self-healing inhibition period, it means that the operation of restarting the modem has not been performed within a self-healing inhibition period, then it can be determined that the restart condition is met and a restart instruction is issued; if the terminal device is currently in the self-healing inhibition period, that is, the time difference between the current moment and the last self-healing moment (the last time the target fault module was restarted) is less than the preset self-healing inhibition period, in order to avoid repeated restarts of the target fault module that may cause other faults to be masked and unidentifiable, then it can be determined that the restart condition is not met, so the restart instruction is not issued temporarily, but the status of the terminal device continues to be monitored until the restart condition is met.

[0175] Optionally, if the terminal device detects that the card, such as the Subscriber Identity Module (SIM), has not been reinserted, for example, there is no record of inserting the card within a preset period after the timer is started, indicating that the user has not manually performed the self-healing operation of pulling out and inserting the card, it can be determined that the restart condition is met, and a restart instruction is issued; if the terminal device detects that the card has been reinserted, for example, there is a record of inserting the card within a preset period after the timer is started, indicating that the user has manually performed the self-healing operation of pulling out and inserting the card, in order to avoid repeated self-healing of the network, the restart instruction may not be issued temporarily, and the status of the terminal device continues to be monitored until the restart condition is met.

[0176] Optionally, if the network status of the terminal device has not changed, for example, the call service on the 5G network is not supported, and the current network status is still in the 5G network, indicating that the network has not rolled back, it can be determined that the restart condition is met and a restart instruction is issued. If the network status of the terminal device has changed, for example, the call service on the 5G network is not supported, and the network status at this time is registered with the 4G network; or, the call service on the 4G network is not supported, and the network status at this time is registered with the 2G or 3G network, it means that the terminal device has rolled back the network. In some cases, the rolled back network can restore the call service, so there is no need to restart the modem to repeat the self-healing network. Therefore, it can be determined that the restart condition is not met and there is no need to issue a restart instruction.

[0177] Optionally, if the terminal device detects that the network side does not support call services, for example, the user of the terminal device is in arrears and the operator has stopped the call service of the terminal device, then even if the target fault module is restarted, the call service cannot be restored, then it can be determined that the restart conditions are not met, and there is no need to issue a restart instruction; if the terminal device detects that the network supports call services and there is no arrears that caused the operator to stop the call service, then it can be determined that the restart conditions are met, and a restart instruction is issued.

[0178] Optionally, the restart condition may also be met when the terminal device detects that the current state satisfies any two, three or more combinations of the following states: the screen is off, the terminal device is in IDLE state, the terminal device is not performing any service involving the target fault module, the terminal device is not in the self-healing inhibition period, the card has not been reinserted, the network status has not changed, and the network supports IMS services. In this case, it can be determined that the restart condition is met and a restart instruction is output.

[0179] Optionally, each condition involved in the above restart conditions may also be different according to the type of specific faulty module. For example, if the target faulty module does not involve data services, the restart condition may not include that the terminal device is in the IDLE state.

[0180] For example, when it is determined that the target fault module is a Modem IMS module or an AP IMSD module, it is not necessary to determine whether the terminal device is in an idle state, for example, it is sufficient to determine whether the screen is off. In the off state, restart the Modem IMS module or the AP IMSD module. If the screen is on, the restart command may not be issued temporarily.

[0181] For another example, when it is determined that the target fault module is the entire Modem or Modem DS module, it is necessary to determine whether the terminal device is in an idle state. For example, when the terminal device is in an idle state and the screen is off, it can be determined that the restart condition is met and a restart instruction is issued. Otherwise, the restart instruction is not issued temporarily.

[0182] Figure 8 A flowchart of a network connection method provided in an embodiment of the present application. The method uses the restart conditions including: the screen is off, the terminal device is in the IDLE state, and the terminal device is not in the self-healing inhibition period as an example, including:

[0183] S801. Monitor target notification messages.

[0184] For details of this step, please refer to Figure 7 The relevant description in the embodiments will not be repeated here.

[0185] S802: In response to the target notification message, determine a target fault module according to a target fault type and a preset fault recovery strategy.

[0186] S803, determine whether the current screen is in the off state. If yes, execute S804; if no, return to execute S801 or periodically execute S803 until the terminal device is in the off state.

[0187] S804: Determine whether the terminal device is currently in an idle state. If yes, execute S805; if no, return to execute S801 or periodically execute S804 or S803 until the terminal device enters an idle state.

[0188] S805, judging whether the current state is in the self-healing inhibition period according to the last self-healing time. If yes, returning to S801 or periodically executing S805, S804 or S802 until the self-healing inhibition period is satisfied; if no, executing S806.

[0189] S806: Issue a restart instruction to instruct the target faulty module to restart.

[0190] When it is necessary to restart the target fault module, the AP will not directly issue a restart instruction to the target fault module, but can determine whether the restart conditions are met in combination with the current state of the terminal device, that is, determine whether the current time is appropriate for restarting. If the screen of the terminal device is off and the terminal device is in IDLE state, it means that the user is not using the terminal device at this time, and the target fault module can be restarted. If the screen is on, or the terminal device is not in IDLE state, but in a business state such as data service, it means that the user is using the terminal device at this time, and it is not a suitable time to restart, so you can return to the step of executing S804 and wait for the arrival of the restart time.

[0191] Optionally, when the screen is off and the terminal device is in the IDLE state, the step of S805 can be continued. The AP can obtain the last self-healing time, and then determine whether the current moment is in the self-healing inhibition period according to the last self-healing time. Optionally, the last self-healing time can be stored in a non-volatile memory (NV) so that it can be read when needed. Optionally, the self-healing inhibition period can be set according to user needs, for example, for three days, seven days, and other periods. Taking the self-healing inhibition period of seven days as an example, if the last self-healing time was three days ago, it means that the current moment is still in the self-healing inhibition period, then the target fault module is not restarted temporarily, and S801 can be continued to be returned to execute or S805 periodically. If the last self-healing time was eight days ago, it means that the current moment is no longer in the self-healing inhibition period, then it is determined that the restart condition is currently met, so a restart instruction is issued to instruct the target fault module to restart. Optionally, the restart event and / or restart time can also be stored in other locations, and the embodiment of the present application is not limited to this.

[0192] Optionally, the AP can determine whether the current state of the terminal device meets the restart condition by first determining whether it is in the self-healing inhibition period, then determining whether it is in the screen-off state, and finally determining whether the terminal device is in the IDLE state. That is, the above steps S803, S804 and S805 can be interchanged. When the restart conditions include any single conditions of the screen being in the screen-off state, the terminal device being in the IDLE state, the terminal device not performing any service involving the modem, the terminal device not being in the self-healing inhibition period, the card not being reinserted, the resident state not changing, and the network supporting IMS services, the embodiment of the present application does not limit the judgment order of each single condition in the restart condition. As long as the preset restart conditions are determined one by one, it can be determined that the restart timing is met. When the call service fails to be successfully supported, the target fault module can be restarted to achieve network self-healing.

[0193] Optionally, the restart conditions can also be written into a configuration file in XML format, and then stored in the application layer of the terminal device for reading. Optionally, the user can also modify the configuration file in XML format as needed to modify the restart conditions, such as adding new conditions, deleting or modifying existing conditions to meet the needs of different scenarios.

[0194] Optionally, the above Figure 8 The embodiments may also include:

[0195] S807: Record the target fault recovery operation event and / or the target fault recovery operation time.

[0196] Optionally, the AP can report the target fault recovery operation event and / or target fault recovery operation time to the application layer, and then report it to the cloud server through the corresponding APK (such as the exception monitoring module) set by the application layer, so as to facilitate the cloud server to perform fault statistics, self-healing status statistics and subsequent adjustments to the fault recovery strategy.

[0197] Optionally, the AP may also record the target fault recovery operation event and / or target fault recovery operation time, and write the target fault recovery operation event and / or target fault recovery operation time into NV so that it can be read when needed. For example, when the AP determines whether it needs to issue a restart instruction next time, it can determine whether it is in the self-healing inhibition period based on the target fault recovery operation time recorded this time.

[0198] The above step S807 can be executed or not executed as needed.

[0199] To clearly describe Figure 8 The timing of the embodiment can be Figure 5 The technical solution is explained in combination with the timing interaction diagram. For details, please refer to Fig. 9 As shown. Fig. 9 As shown, including:

[0200] S901. Monitor target notification messages.

[0201] After the terminal device is powered on, the target notification message can be obtained by monitoring the status of the AP and the Modem through the management module set in the AP, such as monitoring the AP IMSD module in the AP, the Modem IMS module in the Modem, and the DS module in the Modem. At this time, the terminal device executes the normal registration process. When a fault occurs inside the AP and the Modem, the corresponding module will report the fault type through the target notification message.

[0202] S902: The modules inside the AP and the Modem report a target notification message to the management module.

[0203] S903: The management module determines a target fault module according to the target fault type represented by the received target notification message and the fault recovery strategy.

[0204] S904: Determine whether the current state of the terminal device meets the restart condition. If yes, execute S905; if no, continue to periodically execute S904 until the restart condition is met.

[0205] S905: Issue a restart instruction.

[0206] Specifically, the management module may issue a restart instruction to the target fault module, instructing the target fault module to restart.

[0207] It should be noted that Fig. 9 The example in which only some modules report target notification messages in failure situations and some modules issue restart instructions is given, which does not mean that the embodiments of the present application can only perform fault recovery on the modules shown.

[0208] S906: Record the target fault recovery operation event and / or the target fault recovery operation time.

[0209] For the step S906, please refer to the related description in the previous text, which will not be repeated here.

[0210] Optionally, the management module may be a functional module set at the FWK layer. The management module obtains various states of the terminal device through various probes at the application layer, and then determines the restart timing in combination with the various states of the terminal device, for example, executing Figure 8 and Fig. 9 Technical solutions of embodiments and related embodiments.

[0211] The above embodiments are described with AP as the execution subject. The technical solution of the present application can also be implemented with Modem as the execution subject. Specifically, a management module similar to that in the above embodiments can be set in the Modem to collect the fault types inside the Modem and the AP, and determine the target fault module according to the specific fault type, and restart. For details, see Fig.10 As shown, Fig.10 The relevant steps can be found in Fig. 9 The difference is that the management module is located in the Modem, and the Modem executes the related steps.

[0212] Optionally, no matter whether the AP or the Modem is the executor, the above-mentioned management module can be set in the FWK layer. The management module can obtain the status of the terminal device detected by the application layer, for example: whether the screen is off or on, whether the terminal device is in the IDLE state, whether the terminal device is performing services involving the Modem, whether the terminal device is in the self-healing inhibition period at the current moment, whether the card is reinserted, whether the resident status changes, and whether the network supports any one or more combinations of IMS services. Optionally, the management module can also monitor whether the bearer is successfully established and whether the IMS network is registered. In other words, the two conditions of whether the bearer is successfully established and whether the IMS network is registered can also be used as part of multiple restart conditions, and then combined with other conditions to determine whether the Modem needs to be restarted. The management module makes a self-healing decision based on the preset self-healing strategy, that is, it decides whether the Modem needs to be restarted, and instructs the Modem to restart at an appropriate restart time, thereby achieving network self-healing. Optionally, the software architecture diagram of this embodiment can be found in Fig.11 Specifically including:

[0213] The application layer of the terminal device can set various probes to detect the status of the terminal device (also known as the status of the system). The relevant information of these statuses can be transmitted to the management module 1 in the FWK layer. The management module 1 makes a self-healing decision based on the preset self-healing strategy and the acquired status. Optionally, if the management module 1 determines that the bearer has not been successfully established, it means that the fault at this time is more serious and may not be solved by restarting the Modem alone. Therefore, the self-healing operation of stage 1 can be performed, such as restarting the terminal device (restarting the Radio). If the bearer is successfully established and the IMS network registration fails, it can be judged based on other status whether the current status meets the restart conditions. If it does, the self-healing operation of stage 2 can be performed, that is, restarting the Modem. When the Modem needs to be restarted, the management module can send a restart instruction to the Modem through the restart interface of the RIL layer. It should be noted that a management module 2 needs to be set up on the modem side. The management module 2 can report the abnormal information on the modem side, such as the target notification message, to the RIL layer through the corresponding interface (such as QMI or AT), and then transmit it to the management module 1 of the FWK layer through the relevant interface (IMS / NAS / UIM) of the RIL layer to realize self-healing judgment.

[0214] The above describes in detail an example of the method provided by the present application. It is understandable that, in order to implement the above functions, the corresponding device includes a hardware structure and / or software module corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0215] The present application can divide the network connection device into functional modules according to the above method examples. For example, each function can be divided into each functional module, or two or more functions can be integrated into one module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0216] Fig.12 The schematic diagram of the structure of a network connection device provided by the present application is shown. The device 1200 includes:

[0217] A monitoring module 1201 is used to monitor a target notification message, where the target notification message is used to characterize a target fault type that causes an abnormal IMS call;

[0218] The fault recovery module 1202 is used to respond to the target notification message and perform a target fault recovery operation according to the target fault type and a preset fault recovery strategy to connect to the call service network. The fault recovery strategy includes a correspondence between multiple fault types and multiple fault recovery operations.

[0219] In some embodiments, the call service network is an IMS network, and the fault recovery module 1202 is specifically used to determine the target fault module according to the target fault type and the fault recovery strategy, and issue a restart instruction. The target fault module is a module in the application processor or the modem. The fault recovery strategy also includes a correspondence between multiple fault types and multiple fault modules. The restart instruction is used to instruct the target fault module to restart to connect to the IMS network.

[0220] In some embodiments, the modem includes: a Modem IMS module and an ADSP module, the target fault type is abnormal communication between the Modem IMS module and the ADSP module, and the target fault module is the ADSP module.

[0221] In some embodiments, the modem includes: a Modem IMS module and a DS module, the target fault type is that the DS module discards the incoming call message, and the target fault module is the Modem IMS module.

[0222] In some embodiments, the modem includes a Modem IMS module, the target fault type is that the Modem IMS module has not initiated an IMS network registration request, and the target fault module is the Modem IMS module.

[0223] In some embodiments, the modem includes a Modem IMS module and a DS module, the target fault type is that the DS module feeds back a not ready message to the Modem IMS module, and the target fault module is the DS module.

[0224] In some embodiments, the application processor includes a Linux data module and an AP IMSD module, the target fault type is an event in which the Linux data module fails to notify the AP IMSD module of a successful service, and the target fault module is the Linux data module.

[0225] In some embodiments, the call service network is an IMS network, the target fault type is a voice packet fault of the call, and the target fault recovery operation is to close the LTE voice bearer.

[0226] In some embodiments, the voice packet failure includes: the data format of the voice packet does not conform to a preset format, or the payload type of the voice packet does not conform to a preset payload type.

[0227] In some embodiments, the target fault type is QOS loss when the network connection is switched from 5G to 4G, and the target fault recovery operation is to turn off VONR.

[0228] In some embodiments, the target fault type is a continuous failure of the calling party and / or the called party, and the target fault recovery operation is restarting the modem.

[0229] In some embodiments, the target fault type is a failure in initializing a voice packet, and the target fault recovery operation is restarting the electronic device.

[0230] In some embodiments, the fault recovery module 1202 is specifically used to determine whether the current state of the electronic device meets the preset restart condition; if so, perform the target fault recovery operation; if not, monitor the state of the terminal device until the state of the terminal device meets the restart condition, and perform the target fault recovery operation.

[0231] In some embodiments, the restart conditions include: the screen state is off, the terminal device is in IDLE state, the card has not been reinserted, the network status has not changed, the target associated service is not executed, the network supports IMS service, and is not in the self-healing inhibition period, any one or more of which, the target associated service is the service associated with the target fault module.

[0232] In some embodiments, the device 1200 also includes a recording module for recording target fault recovery operation events and / or target fault recovery operation time; and / or, reporting target fault recovery operation events and / or target fault recovery operation time.

[0233] The specific manner in which the network connection device 1200 executes the network connection method and the beneficial effects produced can be found in the relevant description in the method embodiment, which will not be repeated here.

[0234] An embodiment of the present application further provides a chip, comprising a processor; the processor is used to read and execute a computer program stored in a memory to perform a method as described in any one of the aforementioned embodiments.

[0235] Optionally, the chip may be an application processor (AP) or a modem.

[0236] An embodiment of the present application also provides a modem, which is used to execute the method as described in any of the above embodiments.

[0237] An embodiment of the present application further provides an application processor, which is used to execute the method as described in any one of the aforementioned embodiments.

[0238] The present application also provides an electronic device, including the above processor. The electronic device provided by this embodiment can be Figure 1 The terminal device 100 shown is used to perform the above-mentioned network connection method. In the case of an integrated unit, the terminal device may include a processing module, a storage module and a communication module. Among them, the processing module can be used to control and manage the actions of the terminal device, for example, it can be used to support the terminal device to execute the steps performed by the display unit, the detection unit and the processing unit. The storage module can be used to support the terminal device to execute and store program codes and data, etc. The communication module can be used to support the communication between the terminal device and other devices.

[0239] Among them, the processing module can be a processor or a controller. It can implement or execute various exemplary logic boxes, modules and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of digital signal processor (DSP) and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a device that interacts with other terminal devices, such as a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, etc.

[0240] In one embodiment, when the processing module is a processor and the storage module is a memory, the terminal device involved in this embodiment may be a Figure 1 Device of the structure shown.

[0241] An embodiment of the present application also provides an electronic device, comprising the above chip.

[0242] An embodiment of the present application also provides an electronic device, including the above-mentioned modem.

[0243] An embodiment of the present application also provides an electronic device, including the above-mentioned application processor.

[0244] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the processor executes the network connection method described in any of the above embodiments.

[0245] The embodiment of the present application also provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above-mentioned related steps to implement the network connection method in the above-mentioned embodiment.

[0246] Among them, the electronic device, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above and will not be repeated here.

[0247] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, the replaced units may or may not be physically separated, and the components displayed as units may be one physical unit or multiple physical units, that is, they may be located in one place, or they may be distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

[0248] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0249] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0250] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A network connection method, characterized in that: include: monitoring a target notification message, wherein the target notification message is used to characterize a target fault type causing an abnormal Internet Protocol Multimedia Subsystem IMS call; In response to the target notification message, a target fault recovery operation is performed according to the target fault type and a preset fault recovery strategy to connect to the call service network, wherein the fault recovery strategy includes a correspondence between multiple fault types and multiple fault recovery operations.

2. The method according to claim 1, characterized in that The call service network is the IMS network, and the responding to the target notification message and executing the target fault recovery operation according to the target fault type and a preset fault recovery strategy to connect to the IMS network includes: Determine a target fault module according to the target fault type and the fault recovery strategy, wherein the target fault module is a module in an application processor or a modem, and the fault recovery strategy further includes a correspondence between multiple fault types and multiple fault modules; A restart instruction is issued, where the restart instruction is used to instruct the target fault module to restart to connect to the IMS network.

3. The method according to claim 2, characterized in that The modem includes: a Modem IMS module and an ADSP module, the target fault type is abnormal communication between the Modem IMS module and the ADSP module, and the target fault module is the ADSP module.

4. The method according to claim 2, characterized in that: The modem includes: a Modem IMS module and a DS module, the target fault type is that the DS module discards the incoming call message, and the target fault module is the Modem IMS module.

5. The method according to claim 2, characterized in that: The modem includes a ModemIMS module, the target fault type is that the ModemIMS module has not initiated an IMS network registration request, and the target fault module is the ModemIMS module.

6. The method according to claim 2, characterized in that The modem includes a ModemIMS module and a DS module, the target fault type is that the DS module feeds back a not ready message to the ModemIMS module, and the target fault module is the DS module.

7. The method according to claim 2, characterized in that The application processor includes a Linux data module and an AP IMSD module, the target fault type is an event in which the Linux data module fails to notify the AP IMSD module of a successful service, and the target fault module is the Linux data module.

8. The method according to claim 1, characterized in that The call service network is the IMS network, the target fault type is a voice packet fault of the call, and the target fault recovery operation is to close the LTE voice bearer.

9. The method according to claim 8, characterized in that The voice packet failure includes: the data format of the voice packet does not conform to a preset format, or the effective load type of the voice packet does not conform to a preset load type.

10. The method according to claim 1, characterized in that The target fault type is that the quality of service parameter QOS is lost when the network connection is switched from 5G to 4G, and the target fault recovery operation is to close the new air interface to carry voice VONR.

11. The method according to claim 1, characterized in that: The target fault type is continuous failure of calling and / or called parties, and the target fault recovery operation is restarting the modem.

12. The method according to claim 1, characterized in that The target fault type is a voice packet initialization failure, and the target fault recovery operation is restarting the electronic device.

13. The method according to claim 2, characterized in that The performing of the target fault recovery operation includes: Determining whether the current state of the electronic device meets a preset restart condition; If yes, then executing the target fault recovery operation; If not, the state of the electronic device is monitored until the state of the electronic device meets the restart condition, and the target fault recovery operation is performed.

14. The method according to claim 13, characterized in that The restart conditions include: the screen state is off, the terminal device is in idle state (IDLE state), the card has not been reinserted, the network state has not changed, the target associated service is not executed, the network supports IMS service, and is not in the self-healing inhibition period. Any one or more of the following, the target associated service is the service associated with the target fault module.

15. The method according to any one of claims 1 to 14, characterized in that The method further comprises: Recording target failure recovery operation events and / or target failure recovery operation times; and / or, Report the target fault recovery operation event and / or the target fault recovery operation time.

16. A chip, characterized in that: The method comprises a processor; the processor is used to read and execute a computer program stored in a memory to perform the method according to any one of claims 1 to 15.

17. The chip according to claim 16, characterized in that: The processor is a modem or an application processor.

18. An electronic device, characterized in that: include: Processors, memory, and interfaces; The processor, the memory and the interface cooperate with each other so that the electronic device performs the method according to any one of claims 1 to 15; Alternatively, the electronic device comprises the chip as described in any one of claims 16 to 17.

19. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor is caused to perform the method according to any one of claims 1 to 15.

Images