Network connection method and related product

Abstract

The present application relates to the technical field of communications. Provided are a network connection method and a related product. The method comprises: monitoring a target notification message, wherein the target notification message is used for representing a target fault type that causes an call abnormality in an Internet protocol multimedia subsystem (IMS); and in response to the target notification message, executing a target fault recovery operation on the basis of the target fault type and a preset fault recovery policy, so as to connect a call service network, wherein the fault recovery policy comprises a correspondence between a plurality of fault types and a plurality of fault recovery operations. By means of the method, a call service can be recovered without the perception of a user, thereby improving the user experience.

Description

Network connection methods and related products

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on October 31, 2023, with application number 202311440625.5 and application name “Network Connection Method and Related Products”, the entire contents of which are incorporated by reference into this application. Technical Field

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

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

[0004] Typically, a call connection requires the terminal device to properly register with the corresponding network. For example, in the case of second-generation mobile communication technology (2G) and third-generation mobile communication technology (3G) networks, the terminal device implements call services by registering in the circuit switched domain (CS domain). In the case of fourth-generation mobile communication technology (4G) and fifth-generation mobile communication technology (5G) networks, the call service can be implemented by registering in the Internet Multimedia Subsystem (IMS) network. Supporting call services involves a complex network connection process. During the use of the terminal device, various faults may cause the caller or the called party to be unable to connect and make calls.

[0005] 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 a poor user experience and a long call service restoration time.

[0006] Summary of the Invention

[0007] 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, thereby improving the user experience.

[0008] 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 causing an IMS call abnormality; and in response to the target notification message, executing a target fault recovery operation based on 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.

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

[0010] It should be noted that the above-mentioned 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-mentioned fault types may be represented by different error codes, and the above-mentioned different fault recovery operations may also be represented by different instructions. Therefore, the correspondence in the above-mentioned fault recovery strategy may be a correspondence between multiple different error codes and multiple fault recovery operation instructions.

[0011] Optionally, when the management module monitors the target notification message, it responds to the target notification message and searches a preset fault recovery strategy based on the target fault type indicated by the target notification message. After finding a target fault recovery action corresponding to the target fault type, the management module executes the target fault recovery action, thereby reconnecting to the call service network.

[0012] The above-mentioned network connection method 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 network, thereby achieving 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, which takes a long time. Instead, it quickly restores call services through precise network self-healing operations. Due to the high efficiency of call service recovery, call services can be restored without the user being easily aware of it, greatly improving the user experience.

[0013] In one 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, where the target fault module is a module in an application processor or a modem, and the fault recovery strategy also includes a correspondence between multiple fault types and multiple fault modules; and issuing a restart instruction, where the restart instruction is used to instruct the target fault module to restart to connect to the IMS network.

[0014] The aforementioned fault recovery strategy includes a mapping between multiple fault types and multiple faulty modules, indicating that each fault type requires recovery by restoring the status of the corresponding faulty module. Based on the target fault type, the AP can search the preset fault recovery strategy to find the faulty module corresponding to the target fault type, which is referred to as the target faulty module. Typically, the target faulty module is a module within the AP or modem. AP modules include the UI module, AP IMSD module, and Linux DATA module; modem modules include the NAS module, DS module, and Modem IMS module. The AP can issue a restart command, instructing the target faulty module to restart and reconnect to the IMS network. This method accurately restarts the faulty module individually without requiring a complete reboot of the electronic device. This method is highly efficient because individual module reboots are quick (for example, a modem reboot takes about two seconds, while a full device reboot takes significantly longer, often taking tens of seconds). Furthermore, by implementing network self-healing within individual modules, call services can be restored without the user noticing, improving the user experience.

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

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

[0017] In a possible implementation, 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.

[0018] In a possible implementation, 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.

[0019] 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 service success, and the target fault module is the Linux data module.

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

[0021] The different fault types described above correspond to different faulty modules that cause the problem. Based on these relationships, the target faulty module can be precisely located and then restarted to recover from the problem. This approach eliminates the need to operate other unrelated modules, resulting in highly efficient self-healing and imperceptible user experience.

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

[0023] 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 disable VOLTE to achieve network fallback, thereby reconnecting to the call service network and achieving call self-healing.

[0024] 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 payload type of the voice packet does not conform to a preset payload type.

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

[0026] The fault may be serious, but the specific cause cannot be determined. The management module can then issue a restart command, instructing 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 high probability of fault recovery and improving the user experience.

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

[0028] When the Modem IMS module receives a voice packet for processing, it fails to initialize the voice packet. This fault type is: voice packet initialization failure. The fault may be serious, but the specific cause cannot be determined. In this case, the management module can issue a restart command, instructing 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 high probability of fault recovery and improving the user experience.

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

[0030] In some embodiments, when the management module receives a reported target notification message or monitors a target notification message, it does not directly issue a restart instruction to instruct the target faulty module to restart. Instead, it determines whether it is appropriate to restart the target faulty module based on the current state of the electronic device. Optionally, the electronic device can monitor its current state. If the current state meets preset restart conditions, restarting the target faulty module at this time will not affect the user's use of the electronic device or will not be perceived by the user. The AP can then issue a restart instruction to restart the target faulty module after receiving the target notification message. If the current state does not meet the preset restart conditions, restarting the target faulty module at this time will affect the user's use of the electronic device and will be perceived by the user, making it inappropriate to restart the target faulty module. The AP can then continue to monitor the electronic device's state and only issue a restart instruction to instruct the target faulty module to restart when the state meets the restart conditions, thereby restoring the call service network. In other words, the electronic device can select an appropriate time to restart the target faulty module based on the restart conditions, achieving network self-healing without affecting user use and thus avoiding user perception.

[0031] In one possible implementation, the restart conditions include: the screen state is off, the electronic device is in idle state (IDLE state), the card is not 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 suppression period, any one or more of which, the target associated service is the service associated with the target fault module.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0048] FIG1 is a schematic structural diagram of a terminal device 100 provided in an embodiment of the present application;

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

[0050] FIG3 is a schematic diagram of an IMS registration process according to an embodiment of the present application;

[0051] FIG4 is a signaling diagram of a call connection provided in an embodiment of the present application;

[0052] FIG5 is a signaling diagram of another example call connection provided in an embodiment of the present application;

[0053] FIG6 is a software architecture diagram of a method for restarting a target fault module provided in an embodiment of the present application;

[0054] FIG7 is a flow chart of a network connection method according to an embodiment of the present application;

[0055] FIG8 is a flow chart of another network connection method provided in an embodiment of the present application;

[0056] FIG9 is an interaction diagram of a network connection method provided in an embodiment of the present application;

[0057] FIG10 is an interaction diagram of another network connection method provided in an embodiment of the present application;

[0058] FIG11 is a software architecture diagram of a network connection method according to an embodiment of the present application;

[0059] FIG12 is a schematic structural diagram of a network connection device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying 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 merely a description of the association relationship of associated objects, indicating that three relationships can exist, 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.

[0061] In the following, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the technical features indicated. Therefore, a feature specified as "first," "second," or "third" may explicitly or implicitly include one or more of the features.

[0062] 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 (UMPCs), netbooks, and personal digital assistants (PDAs). The embodiments of the present application do not impose any restrictions on the specific type of terminal device.

[0063] For example, FIG1 is a schematic diagram of the structure 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 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.

[0064] It should be understood that the structures illustrated in the embodiments of the present application do 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, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0065] It is understood that the interface connection relationship between the modules illustrated in the embodiments of the present application is merely an illustrative 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 a different interface connection method from the above embodiments, or a combination of multiple interface connection methods.

[0066] The software system of the terminal device 100 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the present application, the Android system with a layered architecture is used as an example to illustrate the software structure of the terminal device 100.

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

[0068] As shown in FIG2 , the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and short message.

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

[0070] As shown in FIG2 , the application framework layer may include a window manager, a content provider, a view system, a telephony manager, a resource manager, a notification manager, and the like.

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

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

[0073] The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views. For example, a display interface containing a text notification icon might include a view for displaying text and a view for displaying images.

[0074] The phone manager is used to provide communication functions of the terminal device 100, such as management of call status (including answering, hanging up, etc.).

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

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

[0077] The Android runtime includes the core library and the virtual machine. The Android runtime is responsible for scheduling and management of the Android system.

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

[0079] The application layer and application framework layer run in a virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

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

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

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

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

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

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

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

[0087] Generally, call connections require the terminal device to register with the corresponding network normally. For example, in the case of 2G and 3G networks, the terminal device implements call services by registering in the CS domain, and in the case of 4G and 5G networks, it can implement call services by registering in the IMS. Supporting 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 connect and 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.

[0088] However, in some cases, even if a user sets their terminal device to airplane mode and then cancels it, call service may not be restored. In such cases, the user needs to restart the terminal device to restore call service. This cumbersome operation results in a poor user experience and a long call service recovery time.

[0089] In order to clearly describe the implementation principle of the technical solution provided by the present application, we first use the process shown in Figure 3 to illustrate the specific situation when the terminal device fails to connect the caller or the called party during a call. Figure 3 is an interactive flow chart for the terminal device to register with the IMS network. Figure 3 takes the interactive objects including: a modem, an application processor (AP) of the terminal device, and a network (NW) side device as an example for description. Among them, the Modem includes a non-access stratum (NAS) module, a data service (DS) module, and a Modem IMS module. The NAS module is used for information transmission on the control plane between the terminal device and the Mobility Management Entity (MME); the DS module can establish a bearer with the NW side device after the network registration is successful; the Modem IMS module is used to continue to register with 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:

[0090] 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).

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

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

[0093] 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, it can continue to perform the subsequent registration process to complete the basic network registration. The terminal device that successfully registers can provide basic network support for subsequent data services and call services.

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

[0095] S304: The NAS module also sends a registration success notification to the Modem IMS module.

[0096] 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 it can notify the DS module and the IMS module of the registration success message.

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

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

[0099] S306. The DS module sends a bearer establishment request to the NW-side device.

[0100] Specifically, the DS module responds to the triggering of the bearer establishment indication message 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, it is recorded as PDU SESSION SETUP REQ for IMS).

[0101] S307 : The NW-side device returns a response message (for example, PDU SESSION SETUP ACCEPT) to the DS module, indicating that it accepts the bearer establishment request.

[0102] Specifically, if the 5G network is registered, when the NW-side device receives a request from the DS module to establish an IMS PDU bearer, if the NW-side device is in normal condition and can establish the PDU bearer, it will feedback a 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 a request from the DS module to establish an IMS packet data network (PDN) bearer, if the NW-side device is in normal condition and can establish the PDN bearer, it will feedback a return message of accepting the bearer establishment to the DS module, thereby establishing the PDN bearer.

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

[0104] 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 with the IMS network.

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

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

[0107] 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, sending a 200 event to the Modem IMS module to notify the Modem IMS module that the bearer has been successfully established.

[0108] S309. The Modem IMS module reports an activation message to the AP to activate the registration IMS network.

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

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

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

[0112] Instructed by the activation success message, the Modem IMS module requests the NW-side device to register with the IMS network.

[0113] For details, please refer to S311 and subsequent steps:

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

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

[0116] In response to the IMS network registration request, the NW-side device feeds back authentication information to the IMS module, for example, returning 401, for performing bidirectional authentication with the terminal device.

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

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

[0119] After receiving the 401 message, the IMS module calculates and authenticates the user based on the authentication parameters contained in the authentication information. Once the authentication is successful, the IMS module can send another IMS network registration request to the NW device. The IMS network registration request carries the relevant user authentication response parameters (expected user response, XRES).

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

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

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

[0123] The process shown in Figure 3 above is the normal process for a terminal device to register with the IMS network. However, in some abnormal situations, the process shown in Figure 3 cannot be fully executed. The dashed steps are steps that will not be continued in these abnormal situations. For example, if the DS module's memory is exhausted, causing the socket path between the DS module and the Modem IMS module to become abnormal, normal communication between the two cannot be established. In other words, even after a bearer is successfully established, the DS module cannot output a 200 event to the Modem IMS module. In other words, the DS module cannot execute step S308 above. As a result, the Modem IMS module cannot be notified of the successful bearer establishment. As a result, the Modem IMS module will not report the bearer establishment activation message to the AP, and subsequent IMS network registration processes cannot be carried out. Therefore, if IMS network registration cannot be performed normally, the IMS domain will not be aware of the existence of the terminal device user, and call services will not be provided, resulting in caller and caller disconnection.

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

[0125] In some cases, the failure of call services to operate normally may also be due to a fault on the AP side. Figure 5 is another interactive flow chart for the terminal device to register on the IMS network. Figure 5 describes the three modules included in the AP: 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) as an example. Among them, the AP IMSD 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:

[0126] First, the terminal device executes steps S301 to S308 as described above. Then, it executes S309. Specifically, the process of step S309 is that the Modem IMS module reports an activation message to the AP IMSD module on the AP side, activating the registration IMS network. For details, see FIG5 , including:

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

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

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

[0130] The AP IMSD module, triggered by the activation message, starts the service and feeds back a service startup message to the Linux DATA module.

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

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

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

[0134] Afterwards, the Modem IMS module, triggered by the activation success message fed back by the AP IMSD module, continues to execute steps S311 to S315.

[0135] Afterwards, also execute:

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

[0137] Specifically, when the UI module receives the IMS network registration success message, it may display a call service success message on the interface to inform the user that the call service is normal.

[0138] The process shown in Figure 5 above is the process for a terminal device to register with the IMS network under normal circumstances. However, when a fault occurs within the AP, the process shown in Figure 5 cannot be fully executed, and the steps indicated by the dashed lines are steps that will not be executed normally under abnormal circumstances. For example, when the Linux DATA module within the AP fails, the above step S503 cannot be executed normally. In other words, the Linux DATA module cannot normally send the DSI event1 event to the AP IMSD module to indicate that the service for starting the IMS registration has been successful. The AP IMSD module cannot then send an activation success message to the Modem IMS module, and thus cannot trigger the Modem IMS module to execute the subsequent IMS network registration process. Therefore, if the IMS network cannot be registered normally, the IMS domain will not be aware of the existence of the user of the terminal device, and call services will not be provided, resulting in caller and caller disconnection.

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

[0140] Based on the above situation, an embodiment of the present application provides a network connection method that can perform reasonable network self-healing operations in a targeted manner based on the fault type that occurs when a call is abnormal. For example, when a fault occurs inside a terminal device, the modem can collect the fault type and then report the fault type to the AP. The AP determines the faulty module that has failed based on the specific fault type and performs precise 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. Instead, the modem determines the faulty module that has failed based on the specific fault type and then performs precise network self-healing operations on the faulty module. This method does not require the user to manually restart the terminal device every time a call abnormality occurs, but instead 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 easily aware of it, greatly improving the user experience.

[0141] The implementation logic of the network connection method provided in the embodiment of the present application can also be seen as shown in Figure 6. When a fault occurs in the terminal device, the modem or AP can collect the fault type and then report the fault type to the exception monitoring module of the application layer through the protocol conversion layer (Radio interface layer, RIL). After the exception monitoring module receives the fault type, it can instruct the restart module of the application layer to issue a restart instruction for the modem. The restart module in Figure 6 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, and the correspondence between different fault types and different fault recovery operations can be set in the configuration file.

[0142] The principles of the technical solutions involved in the embodiments of this application have been summarized above. Next, the technical solutions of this application will be described in detail with reference to the accompanying drawings. Optionally, the execution entity of the embodiments of this application can be an AP or a modem. FIG7 first describes the execution entity as an AP, including:

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

[0144] Optionally, a management module can be provided within the AP. Through the management module, the AP can establish a connection with a modem or AP and monitor the connection, thereby collecting target notification messages from the modem or AP indicating call anomalies. Optionally, the target notification message can include the type of call anomaly. Call anomalies can include call failure, call failure, call silence, call failure, dropped calls, and other situations, which are not limited in this embodiment of the present application.

[0145] S702. In response to the target notification message, 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.

[0146] Optionally, upon receiving a target notification message, the AP responds to the target notification message and searches a preset fault recovery policy based on the target fault type indicated by the target notification message. After finding a target fault recovery action corresponding to the target fault type, the AP executes the target fault recovery action, thereby reconnecting to the IMS network or other call service network.

[0147] It should be noted that the above-mentioned 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-mentioned fault types may be represented by different error codes, and the above-mentioned different fault recovery operations may also be represented by different instructions. Therefore, the correspondence in the above-mentioned fault recovery strategy may be a correspondence between multiple different error codes and multiple fault recovery operation instructions.

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

[0149] 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 network, thereby achieving 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, which takes a long time. Instead, it 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 easily aware of it, greatly improving the user experience.

[0150] 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 recovered by restoring the status 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 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 in order 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.

[0151] Table 1

[0152] As shown in Table 1:

[0153] When fault 1 occurs (the core voice driver (CVD) is not ready), causing abnormal voice packet exchange between the Modem IMS module and the audio digital signal processor (ADSP) module, a silent call occurs. This means that the Modem IMS module can parse voice packets normally, but when sending them to the ADSP for playback, the handshake fails, preventing a connection from being established. This fault type is considered a communication anomaly between the Modem IMS and ADSP modules. Based on this, it is determined that the ADSP module is causing the problem. The Modem IMS module reports an ADSP module failure notification message to the management module, identifying the ADSP module as the target faulty module. The Modem IMS module may discard the currently received voice packets (RTP). At the same time, the AP can issue a restart command to instruct the ADSP module to restart, thereby resolving the fault and achieving call self-healing.

[0154] When fault 2 occurs, namely, an anomaly in the Modem IMS module's socket command processing prevents the DS module from notifying the Modem IMS module of an incoming call through the communication path between the two modules. Consequently, the DS module discards the incoming call, resulting in a call failure restriction. Based on this, it can be determined that the anomaly in the Modem IMS module causes a communication failure between the DS module and the Modem IMS module, preventing the DS module from properly notifying the Modem IMS module of incoming call messages. However, the Modem IMS module is unaware of this anomaly and must rely on the DS module for detection. This fault type is: DS module discards incoming call messages. When the DS module discards incoming call messages, it reports a Modem IMS module failure notification to the management module, identifying the Modem IMS module as the target faulty module. Simultaneously, the AP can issue a restart command to the Modem IMS module, instructing the Modem IMS module (Modem IMS protocol stack) to restart and recover from the fault, thereby re-registering with the IMS network and achieving call self-healing.

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

[0156] Fault 3 occurs when the internal module states of the Modem IMS are inconsistent. Typically, the Modem IMS module is a general service module that includes multiple submodules, such as Submodule 1, which is responsible for registration, and Submodule 2, which is responsible for call flow management. If Submodule 1 believes the device is already registered with the IMS network, it will not initiate further registration. Meanwhile, if Submodule 2 believes the device is not registered with the IMS network, the call will fail, believing it has not yet been registered. When these submodule states are inconsistent, the device remains in the IMS network unregistered state. This means that the modem will not initiate registration or re-registration, resulting in call failures. This means that the IMS network registration has not been successfully completed. This fault type indicates that the Modem IMS module has not initiated an IMS network registration request. Based on this, it can be determined that the fault is caused by an abnormality in the Modem IMS module. The Modem IMS module then reports a Modem IMS module failure notification message to the management module, identifying the Modem IMS module as the target faulty 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.

[0157] When fault 4 occurs, the DS module receives an incoming call message and, while preparing call resources, discovers that it has exhausted its memory and cannot create a socket command channel for the voice packet (QCI#1). This means that call resources cannot be provided. In this case, the DS module responds with a 488 message to the network, indicating that it cannot support call services. Simultaneously, the DS module returns a "Not Ready" message to the Modem IMS module, indicating that it is not ready. When the Modem IMS module receives this "Not Ready" message from the DS module, it reports it to the management module. This fault type is: the DS module reports a "Not Ready" message to the Modem IMS module. Based on this, it is determined that a DS module anomaly is causing the problem. The Modem IMS module reports a DS module failure notification message to the management module, identifying the DS module as the faulty module. The AP can also issue a restart command for the DS module (DS protocol stack) to instruct the DS module to restart and recover from the fault, thereby re-registering with the IMS network and achieving call self-healing.

[0158] If fault 5 occurs (i.e., the Linux data module fails to notify the AP IMSD module of a successful service activation event for the Packet Data Protocol (PDP)), the subsequent normal IMS network registration process cannot proceed, resulting in a persistent failure to successfully register with the IMS network. This fault type is: the Linux data module fails to notify the AP IMSD module of a successful service activation event. Based on this, it can be determined that the cause is an abnormality in the Linux data module. Specifically, after the AP IMSD module sends a service activation message back to the Linux data module within a certain period of time, for example, after sending back a service activation message, it can start a timer. If, after the timer reaches the agreed period, it still fails to receive a service success notification event (DSI event 1) from the Linux data module, it indicates that the Linux data module has failed. The AP IMSD module then reports the AP IMSD module failure notification message to the management module, identifying the AP IMSD module as the target faulty module. Simultaneously, the AP can issue a restart command to instruct the AP IMSD module to restart and recover from the fault, thereby re-registering with the IMS network and achieving call self-healing.

[0159] 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: call voice packet fault. Optionally, the voice packet fault may be that the data format of the voice packet does not conform to 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 conform to the preset format, it can report the call voice packet fault type 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 falling back to 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.

[0160] It should be noted that turning off VOLTE actually means turning off 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 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 with the IMS network and the CS domain at the same time. If it is not registered with the IMS network, the voice call capability of the CS domain can still be retained.

[0161] 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 this 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 conform to 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 failure type that the payload type of the voice packet of the call does not conform to the preset payload type to the management module. Based on the failure type, the management module determines that the cause of the failure 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 turn off the LTE voice bearer (VOLTE). Optionally, it can temporarily turn off 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.

[0162] 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 the call 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, it is impossible to normally establish a voice call service 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.

[0163] 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 type of failure is: voice packet initialization failure. The failure at this time may be more serious, but the specific cause cannot be determined. The management module can then 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 also 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.

[0164] In some cases, whether in the calling or called state, continuous failures may be returned. This fault type is: continuous calling and / or called failures. In this case, it can be determined that the fault is due to the modem, but it is not possible to determine which module of the modem is faulty. In this case, the entire modem can be identified as the faulty module. The AP can then directly issue a restart modem (modem protocol stack) command to instruct the modem to restart and recover, thereby re-registering with the IMS network and achieving call self-healing.

[0165] In some embodiments, the management module can also monitor the internal messages of the modem to specifically determine that the modem has an abnormality, and then perform an operation to restart the modem. Specifically, it can be:

[0166] The AP can monitor the modem's bearer establishment status through the management module, for example, monitoring whether the PDU bearer or PDN bearer is successfully established. Taking 5G network registration as an example, when the PDU bearer is successfully established, the DS module will receive a return message from the network-side device accepting the bearer establishment request. In response to the return message, it determines whether the IMS network registration is successful.

[0167] After monitoring that the bearer is successfully established, the AP can continue to monitor whether the modem has successfully registered with the IMS network. Optionally, the AP can monitor whether the modem has successfully registered with the IMS network through the management module. It should be noted that the AP can monitor the status of the DS module to determine whether the bearer is successfully established for the modem, and the AP can monitor the status of the modem's IMS module to determine whether the modem has successfully registered with the IMS network.

[0168] If the modem fails to successfully register with the IMS network after the bearer is successfully established, for example, if the management module detects that the modem has not received a successful IMS network registration message within a preset period after the bearer is successfully established, then this indicates that the modem has failed to successfully register with the IMS network. This may be due to an internal fault in the modem. For example, if 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 subsequent IMS network registration processes. In this case, the AP can issue a restart command to the modem, instructing it to restart and achieve network self-healing.

[0169] In some embodiments, the AP determines whether the modem has successfully registered with the IMS network by starting a timer upon detecting that the modem has successfully established a bearer. If the AP does not detect a message indicating that the modem has successfully registered with the IMS network within a preset period of the timer, or detects a message indicating that the modem has failed to successfully register with the IMS network, then the modem has not successfully registered with the IMS network. At this point, the AP can continue to monitor whether the modem's bearer has been successfully established or whether the modem has successfully registered with the IMS network. If the AP detects that the modem has successfully registered with the IMS network within the preset period after starting the timer, there is no need to restart the modem.

[0170] After monitoring the successful bearer establishment of the modem, if the AP fails to successfully register with the IMS network, it can restore the IMS network connection by restarting the modem. This method enables network self-healing without the user having to manually restart the entire terminal device. Because a modem restart takes a short time, typically only about two seconds, while a full device restart takes much longer, often taking tens of seconds, this method is highly efficient. Furthermore, by restarting the modem alone to achieve network self-healing, call service can be restored without the user noticing, improving the user experience.

[0171] In some embodiments, when an AP receives a target notification message indicating a module fault type reported by a module, or when the AP monitors a target notification message indicating a module fault type, it does not directly issue a restart instruction to instruct the target module to restart. Instead, it determines whether it is appropriate to restart the target module based on the current state of the terminal device. Optionally, the terminal device can monitor its current state. If the current state meets preset restart conditions, restarting the target module will not affect the user's use of the terminal device or will not be perceived by the user. The AP can then issue a restart instruction to restart the target module after receiving the target notification message. If the current state does not meet the preset restart conditions, restarting the target module will affect the user's use of the terminal device and will be perceived by the user, making it inappropriate to restart the target module. The AP can then continue to monitor the terminal device's state and only issue a restart instruction to instruct the target module to restart when the state meets the restart conditions, thereby restoring the network. In other words, the terminal device can select an appropriate time to restart the target module based on the restart conditions, achieving network self-healing without affecting user use and thus avoiding user perception.

[0172] The following describes the restart conditions in detail. These conditions may include any combination of the following: the screen is off, the terminal device is in the IDLE state, the target associated service (i.e., the service associated with the target faulty module, for example, the terminal device is not performing any modem-related service), the terminal device is not currently in the self-healing suppression period, the card has not been reinserted, the network status has not changed, and the network supports IMS services.

[0173] Optionally, when the screen of the terminal device is in the off state, 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 in the bright state, it is considered that the user is currently using the terminal device. If the restart target fault module is easily perceived by the user, 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 may continue to be monitored until the restart condition is met.

[0174] 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 is 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 may continue to be monitored until the restart condition is met.

[0175] Optionally, if the terminal device is not currently performing any business involving the target fault module, such as a modem, it can be determined that the restart condition is met and a restart instruction is issued; if the terminal device is currently performing any business 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, so the 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.

[0176] 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 within the self-healing inhibition period, that is, the time difference between the current moment and the last self-healing moment (the moment when the target fault module was last restarted) is less than the preset self-healing inhibition period, in order to avoid repeatedly restarting the target fault module, which 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.

[0177] 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, it means that the user has not manually performed the self-healing operation of removing and inserting the card, and it can be determined that the restart condition is met, then 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, it means that the user has manually performed the self-healing operation of removing 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.

[0178] Optionally, if the network status of the terminal device has not changed, for example, the call service on the 5G network is not supported, then the current network status is still in the 5G network, indicating that the network has not rolled back, and 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.

[0179] Optionally, if the terminal device detects that the network side does not support the call service, 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. It can be determined that the restart condition is not met and there is no need to issue a restart instruction; if the terminal device detects that the network supports the call service and there is no arrears that causes the operator to stop the call service, it can be determined that the restart condition is met and a restart instruction is issued.

[0180] Optionally, the restart condition may also be met when the terminal device detects that the current state satisfies any two, three or more 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 suppression period, the card has not been reinserted, the on-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.

[0181] Optionally, each condition involved in the above restart conditions may also be different according to the specific type of the 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.

[0182] For example, if the target faulty module is determined to be the Modem IMS module or the AP IMSD module, there's no need to determine whether the terminal device is in the idle state. For example, it's sufficient to determine whether the screen is off. If the screen is off, the Modem IMS module or AP IMSD module is restarted. If the screen is on, the restart command can be temporarily deferred.

[0183] For example, if the target faulty module is determined to be the entire modem or Modem DS module, it is necessary to determine whether the terminal device is in idle state. For example, if the terminal device is in idle state and the screen is off, it can be determined that the restart conditions are met and a restart command can be issued. Otherwise, the restart command is temporarily not issued.

[0184] FIG8 is a flowchart of a network connection method provided by an embodiment of the present application. The method uses the following three conditions as examples for example: the screen is off, the terminal device is in the IDLE state, and the terminal device is not in the self-healing suppression period, including:

[0185] S801. Monitor target notification messages.

[0186] Specifically, the detailed process of this step can be found in the relevant description of the embodiment in FIG7 , which will not be repeated here.

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

[0188] S803: Determine whether the current screen is in the off state. If yes, execute S804; if not, return to execute S801 or periodically execute S803 until the terminal device is in the off state.

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

[0190] S805: Determine whether the current state is in the self-healing inhibition period based on the last self-healing time. If yes, return to S801 or periodically execute S805, S804, or S802 until the self-healing inhibition period is satisfied; if not, execute S806.

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

[0192] 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 will determine whether the restart conditions are met based on the current status of the terminal device, that is, 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 is 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 for restarting. Therefore, it is possible to return to the step of executing S804 and wait for the arrival of the restart time.

[0193] Optionally, when the screen is off and the terminal device is in the IDLE state, step 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 based on 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, to a period of three days, seven days, etc. Taking a 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 will not be restarted temporarily, and S801 can be returned to execute or S805 can be executed 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, and 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 this embodiment of the present application is not limited to this.

[0194] 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 modem-related services, the terminal device not being in the self-healing inhibition period, the card not being reinserted, the network status not changing, and the network supporting IMS services, the embodiment of the present application does not limit the order of judging each single condition in the restart condition. As long as the preset restart conditions are judged 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.

[0195] Alternatively, the restart conditions can be written into an XML-formatted configuration file and stored in the application layer of the terminal device for future reading. Alternatively, the user can modify the XML-formatted configuration file as needed to modify the restart conditions, such as adding new conditions, deleting or modifying existing conditions, to meet the needs of different scenarios.

[0196] Optionally, the embodiment of FIG8 may further include:

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

[0198] 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 set by the application layer (such as the exception monitoring module), so as to facilitate the cloud server to perform fault statistics, self-healing status statistics and subsequent adjustments to the fault recovery strategy.

[0199] Optionally, the AP 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 determining whether to issue a restart command next time, the AP can determine whether it is within the self-healing inhibition period based on the target fault recovery operation time recorded this time.

[0200] The above step S807 can be performed or not as needed.

[0201] In order to clearly describe the timing of the embodiment of FIG8, the technical solution of FIG5 can be combined with the timing interaction diagram for explanation, as shown in FIG9. As shown in FIG9, it includes:

[0202] S901. Monitor target notification messages.

[0203] After powering on, a terminal device can monitor the status of the AP and modem through the management module within the AP, for example, by monitoring the AP IMSD module, the Modem IMS module, and the DS module within the modem. During this time, the terminal device performs the normal registration process. If a fault occurs within the AP or modem, the corresponding module reports the fault type through a targeted notification message.

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

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

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

[0207] S905: Issue a restart instruction.

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

[0209] It should be noted that Figure 9 only illustrates the module reporting target notification messages in partial fault situations and issuing restart instructions to some modules, which does not mean that the embodiment of the present application can only perform fault recovery on the modules shown.

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

[0211] For step S906, please refer to the relevant description in the previous text and will not be repeated here.

[0212] Optionally, the management module may be a functional module provided 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 based on the various states of the terminal device, for example, by executing the technical solutions of the embodiments of Figures 8 and 9 and related embodiments.

[0213] While the above embodiments are described with the AP as the execution entity, the technical solution of the present application can also be implemented with a modem as the execution entity. Specifically, a management module similar to that in the above embodiments can be provided in the modem to collect fault types within the modem and the AP, determine the target fault module based on the specific fault type, and restart the system. For details, see FIG10 . The relevant steps in FIG10 can be referred to as described in FIG9 . The difference is that the management module is located in the modem, and the relevant steps are executed by the modem.

[0214] Optionally, no matter whether the AP or the Modem is the executing entity, 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 IDLE state, whether the terminal device is performing services involving the Modem, whether the terminal device is in the self-healing suppression period at the current moment, whether the card is reinserted, whether the network status changes, and whether the network supports IMS services, any one or more combinations thereof. 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 shown in Figure 11. Specifically including:

[0215] 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 statuses whether the current status meets the restart conditions. If so, 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 target notification messages, 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 of the RIL layer (IMS / NAS / UIM) to realize self-healing judgment.

[0216] 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 a hardware or computer software driven hardware manner 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 this application.

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

[0218] FIG12 shows a schematic diagram of the structure of a network connection device provided by the present application. The device 1200 includes:

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

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

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

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

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

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

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

[0226] 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 service success, and the target fault module is the Linux data module.

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

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

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

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

[0231] In some embodiments, the target fault type is voice packet initialization failure, and the target fault recovery operation is restarting the electronic device.

[0232] 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 conditions; 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 conditions, and perform the target fault recovery operation.

[0233] 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 suppression period. Any one or more of the following, the target associated service is the service associated with the target fault module.

[0234] In some embodiments, the apparatus 1200 further 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.

[0235] 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 of the method embodiment, which will not be repeated here.

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

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

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

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

[0240] An embodiment of the present application also provides an electronic device, comprising the above-mentioned processor. The electronic device provided in this embodiment may be the terminal device 100 shown in Figure 1, which is used to execute 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 stored program codes and data, etc. The communication module can be used to support communication between the terminal device and other devices.

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

[0242] 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 device having the structure shown in FIG. 1 .

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

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

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

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

[0247] An embodiment of the present application further 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.

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

[0249] In the several embodiments provided in this 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 merely 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 can be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

[0250] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0251] 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 and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0252] The above descriptions are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any modifications or substitutions that can be readily conceived by a person skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection 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 performing a 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 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.

6. 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 feeds back a not ready message to the Modem IMS 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