Exception handling methods, apparatus, electronic devices and readable storage media

Abstract

This application relates to the field of communication technology, and provides an exception handling method, apparatus, electronic device, and readable storage medium, which can be used to improve the problem that service continuity failures are easily caused by SR process exceptions. The exception handling method, applied to an electronic device, includes: sending a service request to a network device in a first network; and, if an exception occurs during the service request process, sending a service request to a network device in a second network.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to an exception handling method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] Currently, when terminals process services such as games and short videos, they typically trigger a service request (SR) process to establish a connection with network devices to carry service data. The SR process can include multiple steps such as establishing a radio resource control (RRC) connection between the terminal and the network device, authentication, and security mode procedures.

[0003] If any of these processes encounters an anomaly, the connection used to carry business data cannot be successfully established, leading to issues such as buffering in games and short videos. In this case, the terminal can re-trigger the SR process. However, the re-triggered SR process may also fail to establish a connection, resulting in continued service anomalies. Summary of the Invention

[0004] This application provides an exception handling method, apparatus, electronic device, and readable storage medium, which can be used to improve the problem that abnormal SR process conditions can easily lead to continuous business anomalies.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] Firstly, an exception handling method is provided: after an electronic device sends a service request to a network device in the first network, if an exception occurs during the service request process, it can send a service request to a network device in the second network.

[0007] As can be seen from the above, when an electronic device encounters an anomaly during the service request process, it will not re-trigger the service request process within the first network, but will instead re-initiate the service request process within the second network. This avoids the problem of invalid re-triggering of the service request due to network anomalies in the first network, thus achieving timely and effective re-triggering of the service request. Therefore, this application can be used to improve the problem of continuous service anomalies easily caused by SR process anomalies.

[0008] In one possible implementation, before sending a service request to the network device of the second network, the electronic device may also perform a first operation to trigger the handover process to the second network. The first operation includes one or more of the following: disabling the cell corresponding to the first network; adding the tracking area code corresponding to the first network to the block list; lowering the priority of the network standard to which the first network belongs; or disabling the network standard to which the first network belongs.

[0009] As can be seen from the above, this application provides multiple methods for handling exceptions. In the event of an exception during a service request, it can effectively support electronic devices in re-initiating service requests to a new network, promptly mitigating service lag and other anomalies.

[0010] In one possible implementation, the electronic device can determine that an anomaly exists in the service request process if a preset event occurs during the request. Alternatively, the electronic device can determine that an anomaly exists in the service request process if N preset events are continuously counted within a preset time period during the request. N is an integer greater than 0. The preset events include one or more of the following: receiving an RRC rejection message, receiving an RRC release message, T300 timer timeout, receiving a service rejection message, T3517 timer timeout, T3517 timer error, or DRB configuration error; the service rejection message is a rejection message used to indicate that the network cannot export the device identifier, or that there is implicit deregistration, or a protocol error.

[0011] In the above methods, a T3517 timer anomaly can occur if it stops prematurely without receiving a service acceptance message. A DRB configuration anomaly can occur if a service acceptance message is received but the DRB count is zero. Based on these methods, this application can support electronic devices in accurately and quickly identifying anomalies during service requests, thereby promptly preventing continuous anomalies in the service request process and effectively improving service lag and other anomalies.

[0012] In one possible implementation, the electronic device can determine whether it is in a screen-on state and / or a non-call state, and if it is determined to be in a screen-on state and / or a non-call state, it sends a service request to the network device of the second network.

[0013] As can be seen from the above, before sending a service request to the network device of the second network, this application can support the electronic device to determine its working status, so as to reduce resource consumption in the non-screen-on state and / or improve the stability of the call service in the call state, and improve the reliability when switching networks in abnormal situations.

[0014] In one possible implementation, the preset event can be an ICD event, and the electronic device can include a CHR module, a QMI layer, and a BOOSTER module. The QMI layer can receive ICD events from the CHR module. Based on the ICD events, the QMI layer can determine whether there are any anomalies during the service request process. If an anomaly is found during the service request process, the QMI layer can send an anomaly indication message to the BOOSTER module to trigger the operation of sending a service request to a network device in the second network.

[0015] Based on the above interaction process, this application can support the effective implementation of exception handling methods on electronic devices, thereby improving the reliability and smoothness of electronic devices in the process of handling business.

[0016] In one possible implementation, the electronic device can also update the number of times the preset event is continuously counted within a preset time period if any of the preset events exist during the business request process.

[0017] Based on the above method, this application can support electronic devices in recording the number of exceptions during the service request process, so as to accurately determine whether there are any abnormal situations during the service request process.

[0018] In one possible implementation, the electronic device can also reset the number of times the preset event is continuously counted within a preset time period if none of the preset events are present during the business request process.

[0019] Based on the above approach, this application can support electronic devices to implement exception clearing logic in the absence of any exceptions. That is, if any business request process is completed normally, the count of exceptions can be reset to avoid unnecessary network switching due to incorrect judgment that an exception exists during the business request process.

[0020] In a second aspect, a communication device is provided, comprising: a functional unit for executing an exception handling method as described in any of the first aspects; wherein the action performed by the functional unit is implemented by hardware or by hardware executing corresponding software.

[0021] Thirdly, this application provides an electronic device, including a memory and a processor, wherein the memory is used to store a computer program and the processor is used to invoke the computer program to implement the exception handling method as described in any of the ways in the first aspect.

[0022] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor in an electronic device, causes the electronic device to perform an exception handling method as described in any of the methods in the first aspect.

[0023] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to execute an exception handling method as described in any of the methods in the first aspect. The computer may be the aforementioned electronic device.

[0024] Understandably, the beneficial effects that can be achieved by the second to fifth aspects mentioned above can be referred to as the beneficial effects of the exception handling methods described in any of the ways in the first aspect, and will not be repeated here. Attached Figure Description

[0025] Figure 1 A schematic diagram of a business request process provided in an embodiment of this application;

[0026] Figure 2 A schematic diagram of an interaction process provided for an embodiment of this application;

[0027] Figure 3 A schematic diagram illustrating a re-triggering process provided in an embodiment of this application;

[0028] Figure 4 A schematic diagram illustrating yet another re-triggering process provided in an embodiment of this application;

[0029] Figure 5 A schematic diagram illustrating yet another re-triggering process provided in an embodiment of this application;

[0030] Figure 6 A schematic diagram illustrating yet another re-triggering process provided in an embodiment of this application;

[0031] Figure 7 This application provides a schematic diagram of the structure of a communication system according to an embodiment of the present application.

[0032] Figure 8 A flowchart illustrating an exception handling method provided in an embodiment of this application;

[0033] Figure 9 A flowchart illustrating another exception handling method provided in an embodiment of this application;

[0034] Figure 10 A flowchart illustrating another exception handling method provided in an embodiment of this application;

[0035] Figure 11 A flowchart illustrating another exception handling method provided in an embodiment of this application;

[0036] Figure 12 A flowchart illustrating another exception handling method provided in an embodiment of this application;

[0037] Figure 13 A flowchart illustrating another exception handling method provided in an embodiment of this application;

[0038] Figure 14 A flowchart illustrating another exception handling method provided in an embodiment of this application;

[0039] Figure 15 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0040] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., are not necessarily different. Also, in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0041] When a terminal processes services such as games or short videos through an application processor (AP) in a network using 5G or 4G technologies, it can trigger the SR process.

[0042] like Figure 1 The diagram shown is a schematic representation of a service request process according to an embodiment of this application. This service request process may include steps S101-S103.

[0043] In S101, the terminal's AP can trigger the SR process to the underlying modem (modulator-demodulator, Modem).

[0044] In S102, the terminal can further interact with the network device through the modem, and can establish a connection with the network device to carry service data if the interaction is completed normally.

[0045] In S103, the terminal's modem can send a response success message to the AP to notify that the service request was successful and the connection was successfully established.

[0046] In S102 above, the interaction process between the terminal and the network device generally includes multiple processes such as RRC connection establishment, authentication, security mode, capability query, and data radio bearer (DRB) establishment. Figure 2 The diagram shown is a schematic representation of an interaction process provided in an embodiment of this application. This interaction process may include steps S201-S215.

[0047] S201, The terminal sends an SR message.

[0048] Correspondingly, the network device receives the SR message.

[0049] In one possible approach, when a terminal sends an SR message to a network device, a T3517 timer can be started to begin timing the current SR process.

[0050] S202, The terminal sends an RRC connection request message.

[0051] Accordingly, the network device receives the RRC connection request message.

[0052] In one possible approach, when a terminal sends an RRC connection request message to a network device, a T300 timer can be started to begin timing the RRC connection establishment process.

[0053] In one possible approach, the RRC connection request message could be an RRC Connection Request message.

[0054] S203, The network device sends an RRC connection establishment message.

[0055] Accordingly, the terminal receives the RRC connection establishment message.

[0056] In one possible approach, the RRC connection establishment message could be an RRC Connection Setup message.

[0057] S204. The terminal sends an RRC connection establishment complete message.

[0058] Correspondingly, the network device receives the RRC connection establishment complete message.

[0059] In one possible implementation, when the terminal sends an RRC connection establishment completion message to the network device, the T300 timer can be stopped to stop timing the current RRC connection establishment process.

[0060] In one possible scenario, the RRC connection setup complete message could be an RRC Connection SetupComplete message.

[0061] The interaction process described above, S202-S204, is the RRC connection establishment process between the terminal and the network device, which is an interaction process that needs to be executed in the SR process.

[0062] S205. The network device sends an authentication request message.

[0063] Correspondingly, the terminal receives the authentication request message.

[0064] In one possible approach, the authentication request message could be an Authentication Request message.

[0065] S206. The terminal sends an authentication response message.

[0066] Correspondingly, the network device receives the authentication response message.

[0067] In one possible approach, the authentication response message could be an Authentication Response message.

[0068] During the interaction process described in S205-S206 above, the network device can be a network element of the core network. This interaction process can be an authentication process between the terminal and a network element of the core network, and is an optional interaction process executed in the SR procedure.

[0069] S207. The network device sends a first security mode command message.

[0070] Accordingly, the terminal receives the first security mode command message.

[0071] In one possible approach, the first security mode command message could be a Security Mode Command message.

[0072] S208, The terminal sends a message indicating that the first security mode has been completed.

[0073] Accordingly, the network device receives the first security mode completion message.

[0074] In one possible approach, the first security mode completion message could be a Security Mode Complete message.

[0075] During the interaction process described in S207-S208 above, the network device can be a network element of the core network. This interaction process can be a security mode process between the terminal and a network element of the core network, and is an optional interaction process executed in the SR procedure.

[0076] S209. The network device sends a second security mode command message.

[0077] Accordingly, the terminal receives the second security mode command message.

[0078] In one possible approach, the second security mode command message could be a Security Mode Command message.

[0079] S210, The terminal sends a message indicating that the second security mode has been completed.

[0080] Accordingly, the network device receives the second security mode completion message.

[0081] In one possible approach, the second security mode completion message could be a Security Mode Complete message.

[0082] During the interaction process described in S209-S210 above, the network device can be a base station. This interaction process can be a security mode process between the terminal and the base station, and it is an interaction process that needs to be executed in the SR procedure.

[0083] It should be understood that, in the cases where S207-S208 and S209-S210 involve interaction between the terminal and different devices, even if both the first security mode command message and the second security mode command message are Security Mode Command messages, the content carried by the first security mode command message and the second security mode command message may differ. Similarly, even if both the first security mode completion message and the second security mode completion message are Security Mode Complete messages, the content carried by the first security mode completion message and the second security mode completion message may also differ.

[0084] S211, The network device sends a terminal performance query message.

[0085] Correspondingly, the terminal receives a terminal performance query message.

[0086] In one possible approach, the terminal performance query message could be a UE Capability Enquiry message.

[0087] S212, The terminal sends a terminal performance information reporting message.

[0088] Correspondingly, network devices receive terminal performance information reports.

[0089] In one possible approach, the terminal performance information reporting message could be a UE Capability Information message.

[0090] During the interaction process described in S211-S212 above, the network device can be a base station. This interaction process can be a capability query process between the terminal and the base station, and is an optional interaction process executed in the SR procedure.

[0091] S213, The network device sends an RRC reconfiguration message.

[0092] Correspondingly, the terminal receives the RRC reconfiguration message.

[0093] In one possible approach, the RRC reconfiguration message could be an RRC Reconfiguration message.

[0094] S214. The terminal sends an RRC reconfiguration complete message.

[0095] Correspondingly, the network device receives the RRC reconfiguration complete message.

[0096] In one possible approach, the RRC reconfiguration complete message could be an RRC Reconfiguration Complete message.

[0097] The above S213-S214 can be the DRB establishment process between the terminal and the network device, which is the interaction process that needs to be executed in the SR process.

[0098] S215. The network device sends a service acceptance message or a service rejection message.

[0099] Accordingly, the terminal receives a service acceptance message or a service rejection message.

[0100] In one possible implementation, when the terminal receives a service acceptance message or a service rejection message from the network device, it can stop the T3517 timer and stop timing for the current SR process.

[0101] In one possible approach, the service acceptance message could be a Service Accept message, and the service rejection message could be a Service Reject message.

[0102] like Figure 2 If any of the processes shown in the diagram fails, the terminal will be unable to successfully establish a connection with the network device to carry business data, which will cause lag and other abnormalities in services such as games and short videos, affecting the user's business experience.

[0103] based on Figure 2 As shown in the interaction process, possible anomalies during the service request process can include RRC connection establishment request rejection, premature release of the RRC connection, RRC connection establishment process timeout (i.e., T300 timer timeout), service request rejection (i.e., receiving a service rejection message), service request process timeout (i.e., T3517 timer timeout), DRB establishment failure, or the T3517 timer stopping prematurely without receiving a service acceptance message. The reason value for the service rejection message can be #9, #10, or #111. #9 indicates the network cannot export the device identifier. #10 indicates implicit deregistration. #111 indicates a protocol error, not specified. DRB establishment failure can occur when a service acceptance message is received but the number of DRBs is zero; this can also be referred to as a DRB configuration anomaly.

[0104] In the event of an anomaly, in order to improve the situation of service interruption or other abnormalities, the terminal can re-trigger the SR process.

[0105] like Figure 3 The diagram illustrates a re-triggering process as an example of related technology. After a terminal sends an SR message to a network device, if it receives a service rejection message with a reason value of #9 or #10, the terminal can interrupt the first SR process and re-trigger the registration process on the network to further re-trigger the second SR process. If the network device continues to reject the terminal's service requests with reasons of #9 or #10, the terminal can continuously re-trigger the SR process.

[0106] It should be understood that, if Figure 3 The second SR process shown occurred Figure 3 Other anomalies besides the one shown, or anomalies that occurred in the SR process after the second SR process. Figure 3 For any other exceptions not shown, the terminal can also re-trigger the SR process.

[0107] like Figure 4 The diagram illustrates another re-triggering process provided as an example of related technology. After the terminal sends an SR message to the network device, if it receives a service rejection message with a reason value of #111, or receives an RRC rejection message (i.e., the RRC connection establishment request is rejected), or receives an RRC release message (i.e., the RRC connection is prematurely released), the terminal can interrupt the first SR process and re-trigger the second SR process. If the network device continues to reject the terminal's service request with the reason value of #111, or if the network device continues to send RRC rejection messages or RRC release messages to the terminal, the terminal can continuously re-trigger the SR process.

[0108] It should be understood that, if Figure 4 The second SR process shown occurred Figure 4 Other anomalies besides the one shown, or anomalies that occurred in the SR process after the second SR process. Figure 4 For any other exceptions not shown, the terminal can also re-trigger the SR process.

[0109] like Figure 5 The diagram illustrates another re-triggering process provided as an example of related technology. After the terminal sends an SR message and an RRC connection request message to the network device, if it determines that the T300 timer has expired, the terminal can interrupt the first SR process and re-trigger the second SR process. If the network device continues not to respond to the RRC connection request message, causing the T300 timer to continuously expire, the terminal can continuously re-trigger the SR process.

[0110] It should be understood that, if Figure 5 In the second or subsequent SR processes shown, even if the T300 timer does not time out but other abnormalities occur, the terminal can still re-trigger the SR process. For example, the network device might reply with an RRC rejection message.

[0111] like Figure 6 The diagram illustrates another re-triggering process provided by a related technology example. After the terminal sends an SR message to the network device, if it determines that the T3517 timer has expired, the terminal can interrupt the first SR process and re-trigger the second SR process. If the network device continues not to reply with a service acceptance message or a service rejection message, causing the T3517 timer to continuously expire, the terminal can continuously re-trigger the SR process. When the T3517 timer expires five times, the terminal can start the T3525 timer and re-trigger the SR process after the T3525 timer expires.

[0112] If the T3517 timer malfunctions, i.e., the T3517 timer stops prematurely without receiving a service acceptance message, the terminal can also interrupt the first SR process and re-trigger the second SR process.

[0113] It should be understood that, if Figure 6 In the second SR process shown or subsequent SR processes, if the T3517 timer does not time out but other abnormalities occur, the terminal can also re-trigger the SR process.

[0114] Based on the above Figures 3-6 As described above, although the terminal can re-trigger the SR process, the re-triggered SR process may still fail to establish a connection. Furthermore, in the event of an abnormal service request, the terminal will not stop triggering the SR process, leading to continued service anomalies. Additionally, if DRB establishment fails, the terminal has already received the service acceptance message and confirmed the end of the current SR process, and will not re-trigger the SR process, also resulting in continued service anomalies.

[0115] To address the aforementioned issues, this application provides an exception handling method. After an electronic device sends a service request to a network device in a first network, if an exception occurs during the service request process, it can send the service request to a network device in a second network. That is, if an exception occurs during the service request process (i.e., the SR process), the electronic device will not re-trigger the service request process within the first network, but will instead re-initiate the service request process within the second network. Based on this, when the network device in the first network has difficulty responding to the service request normally, this application can support the terminal in processing services such as games and short videos normally in the new network, avoiding the problem of continuous failures in the service request process within the first network, thereby preventing continuous service exceptions and enabling service recovery in abnormal situations. Therefore, this application can be used to improve the problem that abnormal SR process situations easily lead to continuous terminal service exceptions.

[0116] This exception handling method can be applied to electronic devices within a communication system. The following describes the communication system provided in the embodiments of this application.

[0117] like Figure 7 The diagram shown is a schematic representation of a communication system 100 provided in an embodiment of this application. The communication system 100 may include an electronic device 10, a network device 20 of a first network, and a network device 30 of a second network. The electronic device 10 may establish a connection with the network device 20 of the first network via a wired or wireless network, and may also establish a connection with the network device 30 of the second network via a wired or wireless network.

[0118] Figure 7 The electronic device 10 can be configured with applications that handle business such as games, short videos, or online shopping, and can support users to access business-related data on the Internet. Figure 7 The diagram shows an example of the device configuration of electronic device 10 and is not intended to limit the device configuration of electronic device 10.

[0119] Optionally, electronic device 10 may also be referred to as a terminal, which can be user equipment (UE), access terminal, terminal unit, user station, terminal station, mobile station, mobile station, remote station, remote terminal, user terminal equipment (TE), mobile device, wireless communication equipment, terminal agent, tablet computer, wearable device, or terminal device in a 5G network or a public land mobile network (PLMN) evolved after 5G. The access terminal can be a cellular phone, a personal digital assistant (PDA), a wireless terminal in a smart home, etc. For example, electronic device 10 can be one of the above. Figures 1-6 The terminal in the application. This application does not limit this.

[0120] Figure 7 The network devices 20 and 30 of the first and second networks can be network elements in the 4G or 5G core network or in the 4G or 5G access network, used to support the implementation of the service request process. When acting as network elements in the 4G or 5G core network, the network devices 20 and 30 can respond to service requests from the electronic device 10 and interact with the electronic device 10 during the authentication process. When acting as network elements in the 4G or 5G access network, the network devices 20 and 30 can be base stations, and can interact with the electronic device 10 during the capability query process.

[0121] Optionally, the network device 20 of the first network or the network device 30 of the second network may be a network element running on proprietary hardware, or a software instance running on proprietary hardware, or a virtual function instantiated on a suitable platform, such as implemented on a cloud infrastructure. This application does not limit this aspect.

[0122] The exception handling method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0123] like Figure 8 The diagram shown is a flowchart illustrating an exception handling method provided in an embodiment of this application. This exception handling method can be applied to... Figure 7 The electronic equipment in the communication system shown. For example... Figure 8 As shown, the exception handling method may include: S801-S802.

[0124] S801, The electronic device sends a service request to the network device of the first network.

[0125] The first network can be the network where the electronic device is currently residing.

[0126] Optionally, the first network can be a 4G network, a 5G network, or a network of other standards. This application does not limit this.

[0127] In one possible approach, when an electronic device needs to interact with the data network of a service while processing services such as games or short videos, it can send a service request to the network device of the first network to further establish a wireless bearer with the data network.

[0128] In one possible approach, the service request may include service type information and electronic device authentication information, which are used by the network devices of the first network for preliminary verification.

[0129] S802. If an electronic device encounters an abnormality during the service request process, it sends a service request to the network device of the second network.

[0130] In one possible approach, the second network can be a different network from the first network. For example, the second network and the first network can correspond to different cells under the same base station, or they can correspond to different cells under different base stations. When the second network and the first network correspond to different cells under different base stations, these different base stations can be base stations belonging to the same tracking area (TA), or they can be base stations belonging to different TAs. That is, the second network and the first network can belong to the same TA, or they can belong to different TAs. As another example, the second network and the first network can be networks under different network standards.

[0131] In one possible approach, after an electronic device sends a service request to a network device in the first network, it can begin the interaction process with the network device. Examples include RRC connection establishment, authentication, security mode establishment, or DRB establishment.

[0132] If an anomaly occurs during the interaction with network devices, the terminal will be unable to establish a wireless bearer with the data network. In this case, the electronic device can switch from the first network to the second network and send a service request to the network devices in the second network to establish a wireless bearer with the data network.

[0133] As described in S801-S802 above, after an electronic device sends a service request to a network device in the first network, if an anomaly occurs during the service request process, it can send a service request to a network device in the second network. That is, if an anomaly occurs during the service request process (i.e., the SR process), the electronic device will not re-trigger the service request process in the first network, but will instead re-initiate the service request process in the second network.

[0134] Therefore, when network devices in the first network have difficulty responding to service requests normally, this application can support terminals to process services such as games and short videos normally in the new network, avoiding the problem of continuous failures in the service request process in the first network, thereby avoiding continuous service anomalies and enabling services to escape in abnormal situations. Therefore, this application can be used to improve the problem that abnormal SR processes can easily lead to continuous abnormalities in terminal services.

[0135] In one embodiment, combined with Figure 8 The flowchart of the exception handling method shown is as follows: Figure 9 As shown in the figure, this application provides a flowchart of another exception handling method. Figure 9 In the illustrated S901-S904, S901 or S902 is an optional implementation, specifically used to determine if an exception exists during the process of determining a service request in S802. S903 and S904 may also include content from the exception handling method provided in this embodiment before sending the service request to the network device of the second network in S802. The following will further describe... Figure 9 S901-S904 are shown for further explanation.

[0136] S901. If a preset event exists during the process of a service request by an electronic device, an anomaly is determined to exist during the process of the service request.

[0137] The preset events may include one or more of the following: receiving an RRC rejection message, receiving an RRC release message, T300 timer timeout, receiving a service rejection message, T3517 timer timeout, T3517 timer error, or DRB configuration error, etc.

[0138] In one possible implementation, the service rejection message can be a rejection message used to indicate that the network cannot export the device identifier, or implicitly deregister, or that there is a protocol error. That is, the reason value carried in the service rejection message can be #9, #10, or #111.

[0139] In one possible implementation, a T3517 timer anomaly could be caused by the T3517 timer stopping prematurely before the electronic device receives a service acceptance message. For example, a timing error during the T3517 timer's operation could cause it to stop prematurely before the specified duration.

[0140] In one possible implementation, a DRB configuration anomaly could occur when an electronic device receives a service acceptance message but the number of DRBs is zero. In this case, although the signaling interaction in the SR process has been completed, the radio bearer for service data has not been successfully established at the data layer, and the anomaly still exists.

[0141] In one possible implementation, the preset events may also include the T300 timer stopping prematurely when the electronic device does not receive an RRC connection establishment message, or other events. This application does not impose limitations on this.

[0142] In combination with the above Figures 3-6 As described in the re-triggering process, if an electronic device receives an RRC rejection message, an RRC release message, a T300 timer timeout, a service rejection message, or a T3517 timer timeout during a service request, it can re-trigger the SR procedure to the network device in the first network, potentially leading to continuous service anomalies. Furthermore, if the T3517 timer malfunctions, the electronic device can also re-trigger the SR procedure to the network device in the first network, potentially leading to continuous service anomalies. Additionally, if the DRB configuration is abnormal, the electronic device will not re-trigger the SR procedure to the network device in the first network, resulting in continuous service anomalies.

[0143] To improve the situation where there are continuous service anomalies, electronic devices can determine that there is an anomaly in the service request process if any preset event occurs during the service request process, and switch to a second network to initiate the service request through the network devices of the second network.

[0144] S902. If an electronic device continuously records N preset events within a preset time period during the process of making a service request, it is determined that there is an anomaly in the process of making the service request.

[0145] Where N is a positive integer. For example, N can be 3 or 5, etc. The preset duration can be pre-set in the electronic device. For example, the preset duration can be 2 minutes or 3 minutes, etc.

[0146] It should be noted that, in the event of a preset event during a service request for services such as games and short videos, considering that the SR process may be retried without switching networks, the retried SR process may still complete and successfully establish the wireless bearer for the service data. Furthermore, to avoid frequent network switching due to frequent anomalies during service requests, the electronic device can perform a network switch only after N preset events have been recorded consecutively within a preset time period, and then trigger the SR process in the new network.

[0147] In one possible approach, the electronic device can record preset events that occur during business requests for services such as games and short videos, and continuously determine whether there are N preset events that occur consecutively within a preset time period.

[0148] For example, an electronic device can be pre-configured with a first counter and a first timer. The first counter can be used to count the number of times a preset event is sent. The timing trigger duration of the first timer can be a preset duration. The electronic device can increment the first counter by one when a preset event occurs during any service request. Furthermore, the electronic device can start the first timer to begin timing when the first counter is 1.

[0149] If none of the preset events occur during the service request process before the first timer expires, it indicates that the service request process has been completed normally and the wireless bearer for the service data has been successfully established. In this case, the electronic device can reset the first timer and clear the first counter, i.e., reset the number of consecutive preset events counted within the preset duration. The electronic device can restart the first timer and the first counter when the first preset event occurs subsequently to execute new exception handling logic.

[0150] If the count value of the first counter is less than N before the first timer ends, and a preset event occurs during the service request process, the electronic device can increment the first counter to update the number of preset events continuously counted within the preset duration.

[0151] If the count value of the first counter is N before the first timer expires, it indicates that N preset events have been counted consecutively within the preset time period. The electronic device can then determine that an anomaly exists during the service request process, and further trigger the SR (Service Response) process in the new network to prevent continued service anomalies and achieve service escape in the event of continuous anomalies. Simultaneously, the electronic device can continue to execute statistical and judgment logic.

[0152] If the first timer finishes counting and the count value of the first counter is less than N, the electronic device can set the timing of the first timer to a first duration and update the count value of the first counter to a first value to continue executing the exception handling logic. The first duration can be the interval between the occurrence time of the first preset event and the current time. The first preset event can be the earliest occurring preset event among continuously counted preset events, and the interval between its occurrence time and the current time is less than the preset duration. The first value can be the number of times the preset event occurs within the time period between the occurrence time of the first preset event and the current time.

[0153] In one possible approach, a preset event may occur during a single service request. After a preset event occurs, the service request process may be interrupted (e.g., in the case of a T300 timer timeout) or it may have ended (e.g., in the case of a DRB configuration error). Therefore, the N preset events continuously recorded by the electronic device represent those occurring during N consecutive service request processes. These N consecutive service request processes can be N service request processes triggered consecutively by the same service, or N service request processes triggered by multiple different services.

[0154] In one possible example, suppose an electronic device triggers N consecutive service request processes for the first service within a preset time period, and a preset event occurs during each of these N service request processes, without triggering any service request processes for other services. Then, the N preset events continuously recorded by the electronic device within the preset time period can be the N preset events occurring during the N consecutively triggered service request processes for the first service.

[0155] Alternatively, if an electronic device triggers N-1 service request processes for the first service and 1 service request process for the second service within a preset time period, and a preset event occurs in each of the N-1 service request processes for the first service and the 1 service request process for the second service, without triggering any other service request processes, then the N preset events continuously counted by the electronic device within the preset time period can be the N-1 preset events occurring during the N-1 service request processes for the first service and the 1 preset event occurring during the 1 service request process for the second service.

[0156] Optionally, S901 and S902 are two alternative execution methods when an exception occurs during the process of determining a business request. In practical applications, either one can be selected for execution based on different levels of business needs, and this embodiment does not limit this.

[0157] S903, The electronic device is determined to be in a screen-on state and / or a non-call state.

[0158] In one possible implementation, if the electronic device is in a non-screened state (i.e., a black screen state), it indicates that the electronic device is not providing services such as games or short videos to the user. In this case, even if the SR process is abnormal, it does not need to be retried to reduce resource consumption. In this scenario, if an SR process abnormality occurs, the electronic device may not need to re-trigger service requests for games or short videos.

[0159] If the electronic device's screen is on, it indicates that the device may be providing services such as games or short videos to the user. If the Service Response (SR) process encounters an anomaly, it needs to be retried to mitigate the service disruption. In this scenario, the electronic device can process games or short videos within a new network environment, avoiding a decline in user experience caused by the service anomaly.

[0160] Based on this, before sending a service request to the network device of the second network, the electronic device can determine whether the screen is on, thus avoiding unnecessary resource consumption caused by re-triggering when the screen is off, and achieving the effect of saving resources.

[0161] In one possible implementation, if the electronic device is in a call state, it cannot temporarily switch to a new network to provide a stable call service. If the electronic device is not in a call state, it indicates that switching to a new network will not affect the call service. In this case, if the SR process encounters an anomaly, the electronic device can re-trigger service requests for games or short videos within the new network.

[0162] Based on this, before sending a service request to the network device of the second network, the electronic device can determine whether it is in a call state, thus avoiding call interruption caused by re-triggering while in a call state and improving the stability of the call service.

[0163] Optionally, to reduce resource consumption, the electronic device may send a service request to the network device of the second network when it is determined that the screen is on. Alternatively, to improve the stability of the call service, the electronic device may send a service request to the network device of the second network when it is determined that it is not in a call state. Or, to reduce resource consumption and improve the stability of the call service, the electronic device may also send a service request to the network device of the second network when it is determined that the screen is on and not in a call state. These can be selectively executed based on different levels of service needs, and this application embodiment does not limit them.

[0164] S904, The electronic device performs the first operation.

[0165] The first operation may include one or more of the following operations: disabling the cell corresponding to the first network; adding the tracking area code (TAC) corresponding to the first network to the block list; reducing the priority of the network standard to which the first network belongs; or disabling the network standard to which the first network belongs.

[0166] In one possible implementation, the anomaly during the service request process might be due to a signal interruption in the cell corresponding to the first network. To avoid continuous anomalies in the SR process within the cell corresponding to the first network, the electronic device can disable that cell. If the electronic device is in an idle state, it can switch to the cell corresponding to the second network through a cell reselection process. If the electronic device is in a connected state, it can switch to the cell corresponding to the second network through a cell redirection process. Then, the electronic device can send service requests to the network devices of the second network.

[0167] In one possible implementation, the anomaly during the service request process might be due to a power outage or network device configuration error within the TA (Transportation Area) of the first network. To prevent the SR (Service Request) process from continuing to fail after switching to another cell within the TA of the first network, the electronic device can add the TAC (Transportation Control Area) corresponding to the first network to the blocked list. Then, the electronic device can switch to a second network under another TA to send service requests to the network devices of the second network.

[0168] Optionally, the electronic device can also remove the TAC corresponding to the first network from the ban list after a pre-specified duration (e.g., 30 minutes) to restore access to the first network.

[0169] In one possible implementation, the anomaly during the service request process might be due to configuration deficiencies or functional malfunctions in the core network elements of the network standard to which the first network belongs. To prevent the SR process from continuing to malfunction after switching to other TAs under the network standard of the first network, the electronic device can lower the priority of the network standard to which the first network belongs. Furthermore, the electronic device can switch to another network standard and register with a second network within that other network standard to send service requests to the network devices of the second network.

[0170] In one possible implementation, considering that lowering the priority of the network standard to which the first network belongs may not prompt a network switch, the electronic device can disable the network standard to which the first network belongs. Then, the electronic device can switch to another network standard and register with a second network within that other network standard to send service requests to the network devices of the second network.

[0171] In one possible example, if an anomaly occurs during the first service request, the electronic device can first disable the cell corresponding to the first network and trigger a second service request in the new cell. If an anomaly still occurs during the second service request, the electronic device can add the Tracking Area Control (TAC) of the new cell to the blocked list and trigger a third service request in the new tracking area. If an anomaly still occurs during the third service request, the electronic device can lower the priority of the network standard currently being used, or disable the network standard currently being used, and trigger a fourth service request in the network under the new network standard.

[0172] As described above, in the event of an anomaly during a service request, an electronic device can execute one or more of various escape methods, thereby switching to a new network (e.g., a second network) and initiating the service request process within the new network. For example, if the first network is a 5G network, the electronic device can disable the corresponding new radio (NR) cell or lower the NR network priority. Similarly, if the first network is a 4G network, the electronic device can disable the corresponding long-term evolution (LTE) cell or disable the LTE network.

[0173] Therefore, when network devices in the first network have difficulty responding to service requests normally, this application can support terminals to process services such as games and short videos normally in the new network, avoiding the problem of continuous failures in the service request process in the first network, thereby avoiding continuous service anomalies and enabling services to escape in abnormal situations. Therefore, this application can be used to improve the problem that abnormal SR processes can easily lead to continuous abnormalities in terminal services.

[0174] like Figure 10 The diagram shows a flowchart of an exception handling method provided in an embodiment of the application. If the interaction process is abnormal in all consecutive SR processes from the first to the Nth SR process within a preset time period, the electronic device can consider that N preset events have been continuously counted within the preset time period, and at this time, the electronic device can perform a first operation. For example, the electronic device can disable the cell corresponding to the first network, or add the TAC corresponding to the first network to the block list, or reduce the priority of the network standard to which the first network belongs, or disable the network standard to which the first network belongs.

[0175] Furthermore, electronic devices can switch to a new cell, TA, or network under a new network standard (e.g., a second network) and initiate service requests on the new network. Based on this, this application can avoid continuous anomalies in the SR process caused by network abnormalities, reduce the time of service delays and other anomalies, and improve the user experience.

[0176] In one possible approach, the SR messages in the first SR process to the Nth SR process within a preset time period can be SR messages from the same business or SR messages from different businesses.

[0177] In one embodiment, combined with Figure 2 The sequence of interactions shown categorizes preset events into three types. The first type of event occurs before S215, i.e., before receiving a service acceptance or rejection message, specifically receiving an RRC rejection message, receiving an RRC release message, and T300 timer timeout. The second type of event occurs during S215, i.e., receiving a service rejection message (reason value #9, #10, or #111). The third type of event occurs after S215, i.e., DRB configuration exceptions. The execution flow of exception handling methods can differ for different event types. The following describes the execution flow of exception handling methods for different event types.

[0178] For the first type of event, such as Figure 11 The diagram shown illustrates a flowchart of another exception handling method provided in this application. After sending a service request, the electronic device can begin executing judgment logic. The electronic device can determine whether the service type of the service request is a first preset type, thereby determining whether the service request is a request for processing services such as games and short videos. The first preset type may include signaling type, data type, and downlink service type.

[0179] If the electronic device determines that the service type of the service request is not the first preset type, it will terminate directly. If it determines that the service type of the service request is the first preset type, it will further determine whether a first type of event has occurred during the service request process. If a first type of event has occurred, the electronic device can further determine whether a service acceptance message has been received. The determination of whether a service acceptance message has been received is to improve the reliability of the service processing; this determination process is optional.

[0180] If a service acceptance message is received, the process ends directly. If no service acceptance message is received, the electronic device can update the anomaly count, i.e., update the number of consecutive occurrences of a preset event within a preset time period. The specific implementation process is described in S1301 above and will not be repeated here. The electronic device can determine whether it is in a screen-on and non-call state; if not, it ends directly. If so, it further determines whether the anomaly count meets a preset condition; if not, it ends directly. If so, it executes the first operation. The preset condition can be either the occurrence of a preset event once, or the occurrence of N consecutive preset events within a preset time period.

[0181] For the second type of event, such as Figure 12 The diagram shown is a flowchart illustrating another exception handling method provided in an embodiment of this application. Because the second type of event occurs... Figure 2 Therefore, in S215, Figure 12 The flow of the exception handling method shown is similar to... Figure 11 The exception handling method shown differs in that it no longer requires determining whether a business acceptance message has been received. The implementation process for the other steps remains the same; please refer to the above description. Figure 11 The specific description of the exception handling methods shown is not repeated here.

[0182] For the third type of event, such as Figure 13 The diagram shown is a flowchart illustrating another exception handling method provided in this application. Because the third type of event is... Figure 2 The event that occurs after S215, that is, after receiving the service acceptance message, therefore... Figure 13 The flow of the exception handling method shown is similar to... Figure 11 The exception handling method shown differs in that if the electronic device determines that it has not received a service acceptance message, it terminates directly. Furthermore, if it determines that a service acceptance message has been received, the electronic device can further determine whether the DRB count is greater than zero. If so, it indicates that there are no exceptions in the service request process, and the electronic device can reset the exception count, i.e., reset the number of consecutively detected preset events within a preset time period. Otherwise, it indicates that there is a DRB configuration exception in the service request process, and the electronic device can update the exception count.

[0183] Furthermore, in the case of a service request with a specific service type and signaling type, the third type of event will not occur, and no judgment logic needs to be executed. Therefore, the second preset type differs from the first preset type and can include data type and downlink service type. The implementation process for other steps is the same, and can be referred to the above. Figure 11 The specific description of the exception handling methods shown is not repeated here.

[0184] In one embodiment, the electronic device may include multiple functional modules. Through the coordinated execution of these multiple functional modules, the exception handling methods provided in the above embodiments of this application can be implemented. In a 5G Standalone (SA) network scenario, the multiple functional modules included in the electronic device can be divided into an NR RRC module, an NR nonaccess stratum (NAS) module, a communication history record (CHR) module, a Qualcomm message interface (QMI) layer, a radio interface layer (RIL), and a booster module.

[0185] The NR RRC module can be used to manage configuration and registration information for wireless networks. For example, it can disable cells in the network. It can also control the priority of different network standards. Furthermore, the NR RRC module can manage RRC connections. For instance, when receiving an RRC rejection message, it can report an Interface Control Document (ICD) event indicating RRC rejection to the CHR module. Similarly, when receiving an RRC release message, it can report an ICD event indicating RRC release to the CHR module. ICD events can be events defined and described in the ICD and may carry fields indicating the preset events mentioned in S1101 above.

[0186] The NR NAS module can be used to process signaling in the control plane, supporting reliable communication with the core network and implementing operations such as mobility management and service requests. The NR NAS module can also be used to manage timers. For example, it can report ICD events indicating T300 timer timeout to the CHR module. Similarly, it can report ICD events indicating T3517 timer timeout to the CHR module. Furthermore, when the T3517 timer malfunctions, the NR NAS module can report ICD events indicating the T3517 timer malfunction to the CHR module. Finally, when a service rejection message is received, the NR NAS module can report ICD events indicating that the service has been rejected to the CHR module.

[0187] The CHR module can be used to parse ICD events and record event information, and can send the event information to the QMI layer via a message mechanism. For example, the CHR module can send a message carrying event information to the QMI layer through a message middleware.

[0188] The QMI layer can receive messages from the CHR module through a message middleware and parse the messages to obtain ICD event information. This allows it to statistically analyze ICD events occurring during service requests that correspond to preset events. Furthermore, the QMI layer can be configured with preset conditions and can continuously determine whether the statistically analyzed ICD events meet these conditions to further decide whether to report an anomaly indication. The preset conditions can be the occurrence of any preset event or the occurrence of N consecutive preset events within a preset time period. The anomaly indication information can be used to trigger the sending of service requests to network devices in the second network.

[0189] RIL supports connections between the QMI layer and the BOOSTER module, as well as between the BOOSTER module and the NR RRC module (Modem layer). For example, the QMI layer can report exception indication information to the BOOSTER module via RIL. Similarly, the BOOSTER module can send a first indication message to the NR RRC module via RIL. This first indication message can be used to instruct the execution of a first operation.

[0190] like Figure 14 The diagram shown is a flowchart of another exception handling method provided in the application embodiment. The collaborative execution process between multiple functional modules may include: S1001-S1008.

[0191] The S1001 and NR RRC modules send the first ICD event to the CHR module.

[0192] Accordingly, the CHR module receives the first ICD event from the NR RRC module.

[0193] The first ICD event can be an ICD event used to indicate RRC rejection, or an ICD event used to indicate RRC release, etc.

[0194] The S1002 and NR NAS modules send a second ICD event to the CHR module.

[0195] Correspondingly, the CHR module receives a second ICD event from the NR NAS module.

[0196] The second ICD event can be an ICD event indicating that the T300 timer has timed out, or an ICD event indicating that the T3517 timer has timed out, or an ICD event indicating that the T3517 timer is abnormal, or an ICD event indicating that the service has been rejected, etc.

[0197] S1003, the CHR module sends the first message to the QMI layer.

[0198] Accordingly, the QMI layer receives the first message from the CHR module and parses the first message to obtain the event information of the ICD event. For example, the event information of the first ICD event.

[0199] In one possible approach, the CHR module can also receive a third ICD event. This third ICD event can originate from the module managing the DRB and can be an ICD event used to indicate a DRB configuration anomaly.

[0200] In one possible approach, the first message may carry event information such as a first ICD event, a second ICD event, or a third ICD event.

[0201] S1004, QMI layer determines whether the preset conditions are met.

[0202] In one possible approach, the QMI layer can determine whether there are any situations that meet preset conditions based on the statistically recorded ICD events, thereby determining whether there are any anomalies in the process of business requests.

[0203] If an exception occurs during a business request, the S1005 and QMI layers will send an exception indication message to the BOOSTER module via RIL.

[0204] The anomaly indication information can be used to trigger the operation of sending a service request to a network device in the second network. For example, the anomaly indication information can be used to indicate the triggering of a first operation. Then, the electronic device can switch to the second network and send a service request to the network device in the second network.

[0205] S1006, the BOOSTER module generates the first instruction information and triggers the first operation.

[0206] The first instruction information can be used to instruct the execution of the first operation.

[0207] S1007, the BOOSTER module sends the first instruction information to the NR RRC module via RIL.

[0208] Accordingly, the NR RRC module receives the first indication information.

[0209] The S1008 and NR RRC modules perform the first operation to switch networks.

[0210] In one possible approach, the NR RRC module can switch to a second network. Then, the electronic device can send service requests to the network devices in the second network.

[0211] Another embodiment of this application provides a communication device, including: a functional unit for executing an exception handling method as described in any of the first aspects; wherein the actions performed by the functional unit are implemented by hardware or by hardware executing corresponding software. For example, the communication device may include a transmitting unit. Figure 8 The transmitting unit can be used to execute S801 and S802. Similarly, a communication device may include an execution unit. (Combined with...) Figure 9 The execution unit can be used to execute S904.

[0212] Another embodiment of this application provides an electronic device, including: one or more processors and a memory. The memory is coupled to the processor; the memory stores one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device implements the exception handling method described in any of the above embodiments.

[0213] Figure 15 A schematic diagram of one structure of the aforementioned electronic device is shown. For example... Figure 15 As shown, the electronic device 200 includes at least one processor 1101 and at least one interface circuit 1102. The processor 1101 and the interface circuit 1102 are interconnected via lines. For example, the interface circuit 1102 can be used to receive signals from other devices (e.g., a computer's memory). As another example, the interface circuit 1102 can be used to send signals to other devices (e.g., the processor 1101).

[0214] For example, interface circuit 1102 can read instructions stored in memory and send those instructions to processor 1101. When the instructions are executed by processor 1101, the electronic device can perform the various steps in the above embodiments. Of course, the chip system may also include other discrete devices, and this application embodiment does not specifically limit this.

[0215] Another embodiment of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor in an electronic device, causes the electronic device to implement the exception handling method described in any of the above embodiments.

[0216] This application also provides a computer program product that, when run on a computer, causes the computer to perform the various functions or steps described in the above method embodiments.

[0217] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0218] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0219] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0220] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0221] If the integrated unit is implemented as 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 solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0222] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions 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 determined by the scope of the claims.

Claims

1. An exception handling method, characterized in that, Applied to electronic devices, including: Send a service request to a network device in the first network; the first network is the network where the electronic device is currently residing. If an anomaly occurs during the service request process, and it is determined that the electronic device is in a screen-on state and / or a non-call state, the device registers with the second network and sends the service request to the network device of the second network. Wherein, if the business type of the business request is a first preset type or a second preset type, and a preset event exists during the business request process, it is determined that an anomaly exists during the business request process; or, if the business type of the business request is a first preset type or a second preset type, and N preset events are continuously counted within a preset time period during the business request process, it is determined that an anomaly exists during the business request process; N is an integer greater than 0.

2. The method according to claim 1, characterized in that, Before sending the service request to the network device of the second network, the method further includes: Perform the first operation; The first operation includes one or more of the following operations: Disable the cell corresponding to the first network; Add the tracking region code corresponding to the first network to the block list; Lower the priority of the network standard to which the first network belongs; or, Disable the network type to which the first network belongs.

3. The method according to claim 1 or 2, characterized in that, The preset events include one or more of the following: receiving a Radio Resource Control (RRC) rejection message, receiving an RRC release message, T300 timer timeout, receiving a service rejection message, T3517 timer timeout, T3517 timer error, or Data Radio Bearer (DRB) configuration error; the service rejection message is a rejection message used to indicate that the network cannot export the device identifier, or implicitly deregisters, or that there is a protocol error.

4. The method according to claim 3, characterized in that, The preset event is an Interface Control Document (ICD) event. The electronic device includes a Communication History Record (CHR) module, a Qualcomm Information Interface (QMI) layer, and an Accelerator Booster module. The method further includes: The QMI layer receives the ICD event from the CHR module; The QMI layer determines whether there is an anomaly during the process of the service request based on the ICD event; If an exception occurs during the service request process, the QMI layer sends an exception indication message to the BOOSTER module to trigger the operation of sending the service request to the network device of the second network.

5. The method according to claim 3, characterized in that, The method further includes: If any of the preset events occurs during the business request process, update the number of times the preset event is continuously counted within the preset time period.

6. The method according to claim 5, characterized in that, The method further includes: If none of the preset events are present during the business request process, the number of times the preset events are continuously counted within the preset time period is reset.

7. A communication device, characterized in that, include: A functional unit for performing the exception handling method as described in any one of claims 1 to 6; wherein the action performed by the functional unit is implemented by hardware or by hardware executing corresponding software.

8. An electronic device, characterized in that, It includes a memory and a processor, the memory being used to store a computer program, and the processor being used to invoke the computer program to implement the exception handling method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It includes computer program instructions that, when executed by a processor in an electronic device, implement the exception handling method as described in any one of claims 1 to 6.

Images