Fault identification method and device, storage medium and product

Abstract

The embodiment of the invention provides a fault identification method and device, a storage medium and a product, and relates to the technical field of communication. The method is applied to first communication equipment, and specifically comprises the steps that maintenance and measurement information generated when a call with second communication equipment is abnormal is acquired, and the maintenance and measurement information comprises abnormal reason data used for describing the call abnormality; based on the abnormality reason data, determining that an abnormality type corresponding to the call abnormality cannot be obtained directly through the maintenance and measurement information; and based on the call stage corresponding to the call abnormality, if it is determined that a target call abnormality event corresponding to the call stage occurs, determining an abnormality type corresponding to the call abnormality according to the target call abnormality event, the abnormality type including a fault type and a non-fault type. According to the invention, the abnormal type corresponding to the abnormal call can be accurately identified at any call stage, and the accuracy of fault identification is improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a fault identification method, device, storage medium and product. Background Art

[0002] With the development of technology, communication devices such as smartphones and smartwatches have become widely used in people's lives. Currently, when two users use a communication device to make a call, they may encounter at least the following call failures: the call is suddenly dropped during the call; the calling user fails to dial the number, or the called user receives a notification that the call cannot be connected; the other party's voice is intermittent or silent during the call, etc.

[0003] Although communication equipment generally has a fault detection function, it is often unable to accurately identify the call failures that users may encounter during actual use. Summary of the Invention

[0004] Multiple aspects of the present application provide a fault identification method, device, storage medium and product for accurately identifying the abnormality type corresponding to the call abnormality at any call stage, thereby improving the accuracy of fault identification.

[0005] In a first aspect, an embodiment of the present application provides a fault identification method, applied to a first communication device, the method comprising:

[0006] Acquire maintenance information generated when a call abnormality occurs with the second communication device, the maintenance information including abnormality cause data describing the call abnormality;

[0007] Based on the abnormality cause data, determining that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information;

[0008] Based on the call stage corresponding to the call abnormality, if it is determined that a target call abnormality event corresponding to the call stage occurs, the abnormality type corresponding to the call abnormality is determined according to the target call abnormality event, and the abnormality type includes a fault type and a non-fault type.

[0009] In a possible implementation, the conversation phase is a calling phase;

[0010] If it is determined that a target call abnormality event corresponding to the call stage occurs, determining an abnormality type corresponding to the call abnormality according to the target call abnormality event includes:

[0011] If a network announcement is received, it is determined that the abnormality type corresponding to the call abnormality is a fault type, and the network announcement is used to prompt the calling communication device that the current call is abnormal.

[0012] In a possible implementation, the conversation phase is a calling phase;

[0013] If it is determined that a target call abnormality event corresponding to the call stage occurs, determining an abnormality type corresponding to the call abnormality according to the target call abnormality event includes:

[0014] If the network announcement is not received, a network announcement corresponding to the maintenance and measurement information is found in a preset mapping relationship table between network announcements and maintenance and measurement information, and the abnormality type corresponding to the call abnormality is determined to be a fault type. The network announcement is used to prompt the calling communication device that the current call is abnormal.

[0015] In a possible implementation, the call phase is any one of a calling phase, a called phase, and a call-in-progress phase;

[0016] If it is determined that a target call abnormality event corresponding to the call stage occurs, determining an abnormality type corresponding to the call abnormality according to the target call abnormality event includes:

[0017] If there is a first network abnormal behavior within a set time period before the maintenance information, it is determined that the abnormality type corresponding to the call abnormality is a fault type, and the first network abnormal behavior corresponds to a network connection condition.

[0018] In a possible implementation, the call phase is a call-in-progress phase;

[0019] If it is determined that a target call abnormality event corresponding to the call stage occurs, determining an abnormality type corresponding to the call abnormality according to the target call abnormality event includes:

[0020] If there is a second network abnormal behavior within a set time period before the maintenance and measurement information, it is determined that the abnormality type corresponding to the call abnormality is a fault type, and the second network abnormal behavior corresponds to a message sending and receiving situation.

[0021] In a possible implementation, determining, based on the abnormality cause data, that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information includes:

[0022] If the abnormality cause data is empty, it is determined that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information.

[0023] In a possible implementation, the abnormality cause data includes a target protocol type, a target cause value, and a target cause description information;

[0024] The determining, based on the abnormality cause data, that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information includes:

[0025] If the target protocol type, the target cause value, and the target cause description information do not match, it is determined that the exception type corresponding to the call exception cannot be directly obtained through the maintenance information.

[0026] In a possible implementation, the abnormality cause data includes at least two sets of cause information;

[0027] The determining, based on the abnormality cause data, that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information includes:

[0028] If the at least two sets of cause information do not match, it is determined that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information.

[0029] In a second aspect, an embodiment of the present application provides a fault identification device, the device comprising:

[0030] an acquisition module, configured to acquire maintenance information generated when a call abnormality occurs with the second communication device, wherein the maintenance information includes abnormality cause data describing the call abnormality;

[0031] A determination module, configured to determine, based on the abnormality cause data, an abnormality type corresponding to the call abnormality that cannot be directly obtained through the maintenance information;

[0032] An identification module is used to determine the abnormality type corresponding to the call abnormality based on the call stage corresponding to the call abnormality, if it is determined that a target call abnormality event corresponding to the call stage has occurred, and the abnormality type includes a fault type and a non-fault type.

[0033] In a third aspect, an embodiment of the present application provides a terminal device, comprising a memory for storing computer program instructions and a processor for executing program instructions, wherein when the computer program instructions are executed by the processor, the terminal device is triggered to execute the method described in the first aspect.

[0034] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute the method described in the first aspect.

[0035] In a fifth aspect, an embodiment of the present application provides a computer program product, comprising: a computer program, which, when executed by a processor of an electronic device, causes the processor to execute the method described in the first aspect.

[0036] In the solution provided in the embodiment of the present application, by obtaining maintenance information when a call abnormality occurs between the first communication device and the second communication device, and when the abnormality type corresponding to the call abnormality cannot be directly determined through the maintenance information, a judgment is made based on the call stage corresponding to the call abnormality. If a target call abnormality event corresponding to the call stage occurs, it can be determined that the abnormality type corresponding to the call abnormality is a fault type, that is, the present application can accurately identify the abnormality type corresponding to the call abnormality at any call stage, thereby improving the accuracy of fault identification. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0038] Figure 1 A schematic diagram of the structure of the communication system provided in an embodiment of the present application;

[0039] Figure 2 A flowchart of a fault identification method provided in an embodiment of the present application;

[0040] Figure 3 A specific example diagram of a fault identification method provided in an embodiment of the present application;

[0041] Figure 4 A diagram illustrating another specific example of a fault identification method provided in an embodiment of the present application;

[0042] Figure 5 A diagram illustrating another specific example of a fault identification method provided in an embodiment of the present application;

[0043] Figure 6 A flowchart of a method for determining an abnormality type corresponding to a call abnormality that cannot be directly obtained through maintenance information based on abnormality cause data provided in an embodiment of the present application;

[0044] Figure 7 A schematic diagram of the structure of a fault identification device provided in an embodiment of the present application;

[0045] Figure 8 A schematic diagram of the structure of a terminal device provided in an embodiment of the present application;

[0046] Figure 9 A software structure block diagram of a terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0048] The following is an explanation of the terms involved in this application:

[0049] Maintenance and testing information: the call-related information collected by the communication equipment for the call, including necessary abnormality information related to the detected abnormality of the call.

[0050] With the advancement of technology, communication devices such as smartphones and smartwatches have become widely used in people's lives. Currently, when two users use a communication device to make a call, they may encounter at least the following call failures: the call is dropped; the calling user fails to dial the number, or the called user receives a notification that the call cannot be connected; the other party hears intermittent or silent voice during the call. Although communication devices generally have fault detection capabilities, they are often unable to accurately identify these call failures that users may encounter in real-world use.

[0051] In view of this, the present application solves the above problem based on the following ideas: when a call abnormality occurs between two communication devices, maintenance information is obtained, and when the abnormality type corresponding to the call abnormality cannot be directly determined through the maintenance information, a judgment is made based on the call stage corresponding to the call abnormality (calling stage, called stage and call stage). If a target call abnormality event corresponding to the call stage occurs, it can be determined that the abnormality type corresponding to the call abnormality is a fault type.

[0052] Figure 1 This is a schematic diagram of the structure of the communication system provided in the embodiment of the present application. Figure 1 As shown, the system includes a first communication device and a second communication device, which can conduct calls based on a 4G network, a 5G network, etc. In actual applications, the first communication device can be used as a calling device and the second communication device as a called device; alternatively, the first communication device can be used as a called device and the second communication device can be used as a calling device.

[0053] The first communication device and the second communication device can both be terminal devices with call functions such as smart phones, smart watches, and tablet computers. In addition, it should be noted that the first communication device and the second communication device can be the same or different, and are not specifically limited here.

[0054] Based on the above system composition, the method for fault identification is described in detail below.

[0055] Figure 2 This is a flowchart of a fault identification method provided in an embodiment of the present application. Figure 1 The first communication device performs, such as Figure 2 As shown, the method includes the following steps:

[0056] 201. Obtain maintenance information generated when a call abnormality occurs with a second communication device, where the maintenance information includes abnormality cause data for describing the call abnormality.

[0057] 202. Based on the abnormality cause data, it is determined that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information.

[0058] 203. Based on the call stage corresponding to the call abnormality, if it is determined that a target call abnormality event corresponding to the call stage occurs, determine the abnormality type corresponding to the call abnormality according to the target call abnormality event, where the abnormality type includes a fault type and a non-fault type.

[0059] It should be understood that call anomalies between the first communication device and the second communication device generally occur in the following three stages: the calling stage, the called stage, and the in-call stage. Among them, the calling stage refers to: if the first communication device actively calls the second communication device, the time period from the first communication device dialing to the second communication device answering the call. The called stage refers to: if the first communication device actively calls the second communication device, the time period from the second communication device receiving the message forwarded to it by the network side to the second communication device answering the call. The in-call stage refers to: regardless of whether the first communication device actively calls the second communication device or the second communication device actively calls the first communication device, the time period from the start of the call between the first communication device and the second communication device until the end of the call.

[0060] In actual applications, when a call anomaly occurs between the first communication device and the second communication device, maintenance information is obtained. Specifically, if the first communication device detects that a call anomaly occurs, it extracts information related to the call anomaly from the call-related messages of the call to obtain maintenance information for the call. As for the call-related messages, for example, assuming that the first communication device is the caller and dials the second communication device, during this process, if a call anomaly occurs, the first communication device may receive a Session Initiation Protocol (SIP) message sent by the second communication device or the network side, such as a "bye" message (this message can be sent by one party hanging up during a call between the first communication device and the second communication device), or a "cancle" message (this message can be sent when the first communication device makes a call and the second communication device does not answer the call), which are not listed here one by one.

[0061] Among them, maintenance and measurement information includes but is not limited to: basic call signaling such as call negotiation messages, error codes for this call sent by the network side when a call failure is detected, error codes generated based on this call anomaly when the communication equipment detects this call anomaly, and basic call information such as call time information, the operator network used for the call, etc.

[0062] It should be noted that in this embodiment, the maintenance information includes exception cause data (Reason: Q.850; cause = 1; text = "Unallocated number", or Reason: Q.850; cause = 21; text = "Call rejected", not listed here one by one, where Reason represents the target protocol type, cause represents the exception cause value, and text represents the specific content corresponding to the exception cause value). The exception cause data may be normal or may have problems (for example, if the cause and text do not correspond and do not comply with the protocol specification, the problem will be specifically described in subsequent embodiments and will not be described in detail for the time being). If the exception cause data is normal, the exception type corresponding to the call exception can be directly determined based on the "cause and text", that is, the call failure can be determined.

[0063] However, if there is a problem with the abnormality cause data, the abnormality type corresponding to the call abnormality cannot be directly determined from the maintenance information. In this case, the judgment is made based on the call stage corresponding to the call abnormality. If a target call abnormality event corresponding to the current call stage occurs, the corresponding abnormality type of the call abnormality can be determined based on the target call abnormality event. In other words, it can be identified whether the abnormality type corresponding to the current call abnormality is a fault type.

[0064] Based on the above, the embodiment of the present application obtains maintenance information when a call abnormality occurs between the first communication device and the second communication device, and makes a judgment based on the call stage corresponding to the call abnormality when the abnormality type corresponding to the call abnormality cannot be directly determined through the maintenance information. If a target call abnormality event corresponding to the call stage occurs, it can be determined that the abnormality type corresponding to the call abnormality is a fault type, that is, the present application can accurately identify the abnormality type corresponding to the call abnormality at any call stage, thereby improving the accuracy of fault identification.

[0065] The following two steps are premised on obtaining maintenance and measurement information generated when a call anomaly occurs with the second communication device. The maintenance and measurement information includes data describing the cause of the call anomaly; based on the cause of the anomaly, determining the type of anomaly that corresponds to the call anomaly, which cannot be directly obtained from the maintenance and measurement information. The following describes how to determine the type of anomaly corresponding to the call anomaly, taking into account the call phase corresponding to the anomaly:

[0066] As the first implementation method: Figure 3 As shown, when the call phase is the calling phase, if it is determined that a target call abnormality event corresponding to the call phase occurs, the abnormality type corresponding to the call abnormality is determined according to the target call abnormality event, including:

[0067] If the network announcement is received, it is determined that the abnormality type corresponding to the call abnormality is a fault type.

[0068] If the network announcement is not received, a network announcement corresponding to the maintenance and measurement information is found in a preset mapping relationship table between network announcements and maintenance and measurement information, and the abnormality type corresponding to the call abnormality is determined to be a fault type. The network announcement is used to inform the calling party that the current call abnormality is occurring on the communication device.

[0069] A network announcement can be sent to the first communication device after the network identifies a call anomaly. Specifically, it can be: "The call you dialed is temporarily unavailable." It should be noted that in actual applications, a mapping table between network announcements and maintenance and testing information is created. This mapping table can be generated based on previous network announcements and the maintenance and testing information corresponding to them. As network announcements continue to occur, this mapping table can be updated in real time.

[0070] In specific implementation, under the premise that there is a problem with the maintenance and testing information, if the first communication device receives a network announcement, it can be directly determined that the abnormality type corresponding to the call abnormality is a fault type.

[0071] If the first communication device does not receive the network announcement, the mapping table may be searched based on the maintenance information. If the corresponding network announcement is found, the abnormality type corresponding to the call abnormality is determined to be a fault type. If the corresponding network announcement is not found, the abnormality type corresponding to the call abnormality is determined to be a non-fault type.

[0072] This embodiment uses network announcements as a reference factor and combines them with a pre-created mapping table between network announcements and maintenance information. This allows accurate identification of the type of abnormality corresponding to a call abnormality, regardless of whether the first communication device (i.e., the calling device in this embodiment) receives or fails to receive the network announcement, thereby improving the accuracy of fault identification.

[0073] As the second implementation method: Figure 4 As shown, when the call stage is any one of the calling stage, the called stage, and the in-call stage, if it is determined that a target call abnormality event corresponding to the call stage occurs, the abnormality type corresponding to the call abnormality is determined according to the target call abnormality event, including:

[0074] If the first network abnormal behavior exists within a set time period before the maintenance information, it is determined that the abnormality type corresponding to the call abnormality is a fault type, and the first network abnormal behavior corresponds to a network connection condition.

[0075] In actual applications, when a call abnormality occurs in the first communication device during the calling stage, the called stage, or the call stage, the network abnormal behavior within the set time period (such as 5s, 10s, etc.) before the maintenance information can be obtained based on the time corresponding to the maintenance information. If there is a first network abnormal behavior in the network abnormal behavior, it can be determined that the abnormality type corresponding to the call abnormality is a fault type.

[0076] The first network abnormal behavior corresponds to the network connection situation. For example, it may include: network disconnection, radio link failure (Radio Link Failure, RLF for short), radio bearer (Radio Bearer, RB for short) deletion or release, redirection failure, handover failure, random access failure, Tracking Area Update (Tracking Area Update, TAU for short) TAU is rejected or no response, service request (Service Request, SR for short) is rejected or no response, etc.

[0077] Among them, network disconnection may be caused by poor network signal or problems with communication equipment.

[0078] RLF is a communication failure in the call channel, such as the number of empty transmissions reaching the limit.

[0079] RB deletion or release: It should be understood that there are corresponding bearers on the links from the communication device to the base station and from the base station to the core network, and a call will establish a certain bearer. RB deletion or release can be understood as the communication device releasing or deleting the bearer.

[0080] Redirection failure and switching failure: It should be understood that the ways to switch from a 5G network to a 4G network include: directly switching the 5G network to the 4G network, or redirecting the 5G network to the 4G network. Failure in this process is considered a redirection failure or a switching failure.

[0081] Random access failure, for example: the user's communication device fails to randomly access the new cell network.

[0082] This embodiment determines whether there is abnormal behavior of the first network within a set time period before the maintenance and measurement information, and can accurately identify the abnormality type corresponding to the call abnormality at any stage of the calling stage, the called stage, or the call stage, thereby improving the accuracy of fault identification.

[0083] As a third implementation method: Figure 5 As shown, when the call stage is the call stage, if it is determined that a target call abnormality event corresponding to the call stage occurs, the abnormality type corresponding to the call abnormality is determined according to the target call abnormality event, including:

[0084] If there is a second network abnormal behavior within a set time period before the maintenance and measurement information, it is determined that the abnormality type corresponding to the call abnormality is a fault type, and the second network abnormal behavior corresponds to a message sending and receiving situation.

[0085] In actual applications, when the first communication device is in a call, the device can obtain abnormal network behavior within a set time period (e.g., 5 seconds, 10 seconds, etc.) prior to the maintenance and measurement information based on the time corresponding to the maintenance and measurement information. If a second abnormal network behavior is present in the abnormal network behavior, the abnormality type corresponding to the call abnormality can be determined to be a fault type. It should be noted that the "second abnormal network behavior" here is only used to distinguish it from the "first abnormal network behavior" and does not limit the "second abnormal network behavior" to a network abnormality. Specifically, the "second abnormal network behavior" can be caused by a terminal abnormality or a network abnormality.

[0086] The second abnormal network behavior corresponds to the message sending and receiving situation. For example, it may specifically include: no real-time transport protocol (RTP) packet in the uplink, no RTP packet in the downlink, abnormal uplink frame structure, abnormal downlink frame structure (abnormal frame structure can be understood as similar to Bad Frame), the actual uplink RTP packet format does not match the negotiated format, the actual downlink RTP packet format does not match the negotiated format (for example, assuming that the actual RTP packet format is AMR and the negotiated format is AMRWB, it is considered that the actual RTP packet format does not match the negotiated format), etc.

[0087] For uplink and downlink, the following examples are used to illustrate the situation:

[0088] No uplink RTP packets: Suppose user A calls user B. User A speaks, but user B cannot hear. This may be because user A does not send RTP packets, which is called no uplink RTP packets.

[0089] No RTP packets in the downlink: Suppose user A calls user B. User B speaks but user A cannot hear. This could be because user B sent an RTP packet but user A did not receive it. This is called no RTP packets in the downlink. Alternatively, user B may not send an RTP packet for some reason.

[0090] This embodiment can accurately identify the abnormal type corresponding to the call abnormality during the call phase by determining whether the second network abnormal behavior exists within a set time period before the maintenance and measurement information, thereby improving the accuracy of fault identification.

[0091] To facilitate understanding, the following describes the situation where, based on the exception cause data, it is determined that the corresponding exception type of the call exception cannot be directly obtained through maintenance and measurement information:

[0092] In the embodiment of the present application, the abnormal cause data includes the target protocol type, the target cause value and the target cause description information (ie, Reason, cause and text).

[0093] As an implementation method: if the abnormality cause data is empty, it is determined that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information.

[0094] For ease of understanding, for example, under normal circumstances, maintenance and measurement information contains Reason, cause, and text. However, if the exception reason data is empty, this means that the "Reason, cause, and text" header field is not present, or the "cause and text" field is not followed by the "Reason." This is also called a "no Reason" header field. In this case, it is impossible to directly determine the corresponding exception type of the call anomaly based on the maintenance and measurement information.

[0095] As another implementation manner: if the target protocol type, the target cause value, and the target cause description information do not match, it is determined that the exception type corresponding to the call exception cannot be directly obtained through the maintenance information.

[0096] In practice, there's a one-to-one mapping between the target protocol type, target reason value, and target reason description. If the cause and text fields don't match, the Reason header field is considered noncompliant with the protocol specification. In this case, it's impossible to directly determine the corresponding exception type from the maintenance information.

[0097] Specifically, for example, under normal circumstances, the target protocol type, target cause value, and target cause description information are: Reason; Q.850; cause = 24; text = "Call rejected due to feature at the destination". However, if the target protocol type, target cause value, and target cause description information are Reason: Q.850; cause = 24; text = "Call rejected", that is, under Q.850, the cause and text do not correspond, then it is considered that the target protocol type, target cause value, and target cause description information do not match.

[0098] As another implementation manner: the abnormality cause data includes at least two sets of cause information; if at least two sets of cause information do not match, it is determined that the abnormality type corresponding to the call abnormality cannot be directly determined through the maintenance information.

[0099] For example, if the maintenance information contains "Reason: SIP; cause = 200; text = "User Triggered", Q.850; cause = 16; text = "Destination out of order," this indicates that the Reason header field contains two protocol types (SIP and Q.850), and the cause values ​​in the two protocols are significantly different (i.e., the meanings of "200" and "16" are significantly different in SIP and Q.850). Alternatively, the cause and text values ​​for each protocol type do not match. For example, in Q.850, if cause = 16, the text should be "Terminated," but the actual text is "Destination out of order." Therefore, the cause and text values ​​in Q.850 do not match. In this case, at least the two sets of cause information do not match. In this case, it is impossible to directly determine the corresponding abnormality type of the call abnormality based on the maintenance information.

[0100] Figure 6 A flowchart of a method for determining an abnormality type corresponding to a call abnormality that cannot be directly obtained through maintenance information based on abnormality cause data provided in an embodiment of the present application is as follows: Figure 6 As shown, the method is applied to a first communication device, and the method specifically includes:

[0101] Acquire maintenance information generated when a call abnormality occurs with the second communication device.

[0102] Determine whether the target protocol type header field is carried in the maintenance and measurement information. If not, the abnormality cause data is determined to be empty, and the abnormality type corresponding to the call abnormality cannot be directly determined through the maintenance and measurement information.

[0103] If present, determine whether the exception cause data includes at least two sets of cause information. If so, determine whether the at least two sets of cause information match. If not, it may be because the Target Protocol Type header field contains two protocol types, and the meanings of the two protocol types are obviously inconsistent, making it impossible to directly determine the exception type corresponding to the call anomaly based on the maintenance information.

[0104] If it is determined that the exception cause data does not include at least two sets of cause information, the target protocol type, target cause value, and target cause description information are then checked to see if they match. If not, the target protocol type header field does not comply with the protocol specification, and the exception type corresponding to the call anomaly cannot be directly determined from the maintenance and testing information. If they match, the exception type corresponding to the call anomaly can be directly determined from the maintenance and testing information.

[0105] In some of the processes described in the above embodiments and the accompanying drawings, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this article or may be executed in parallel. The sequence numbers of the operations, such as 201, 202, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0106] The following describes in detail the fault identification device of one or more embodiments of the present application. Those skilled in the art will appreciate that these devices can be constructed by configuring commercially available hardware components through the steps taught in this solution.

[0107] Figure 7 A schematic diagram of a fault identification device provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the device includes: an acquisition module 11, a determination module 12 and an identification module 13.

[0108] The acquisition module 11 is used to acquire maintenance information generated when a call abnormality occurs with the second communication device. The maintenance information includes abnormality cause data for describing the call abnormality.

[0109] The determination module 12 is configured to determine, based on the abnormality cause data, an abnormality type corresponding to a call abnormality that cannot be directly obtained through maintenance and measurement information.

[0110] The identification module 13 is used to determine the abnormality type corresponding to the call abnormality based on the call stage corresponding to the call abnormality. If it is determined that the target call abnormality event corresponding to the call stage occurs, the abnormality type includes a fault type and a non-fault type.

[0111] Optionally, the call stage is the calling stage; the identification module 13 is specifically used to: if a network announcement is received, determine that the abnormality type corresponding to the call abnormality is a fault type, and the network announcement is used to prompt the calling communication device that the current call is abnormal; and if no network announcement is received, query the preset mapping relationship table of network announcements and maintenance information to find the network announcement corresponding to the maintenance information, then determine that the abnormality type corresponding to the call abnormality is a fault type, and the network announcement is used to prompt the calling communication device that the current call is abnormal.

[0112] Optionally, the call stage is any one of the calling stage, the called stage and the call stage; the identification module 13 is specifically used to: if there is a first network abnormal behavior in the set time period before the maintenance information, then determine that the abnormality type corresponding to the call abnormality is a fault type, and the first network abnormal behavior corresponds to the network connection status.

[0113] Optionally, the call stage is the call stage; the identification module 13 is specifically used to: if there is a second network abnormal behavior in the set time period before the maintenance information, then determine that the abnormal type corresponding to the call abnormality is a fault type, and the second network abnormal behavior corresponds to the message sending and receiving situation.

[0114] Optionally, the abnormal cause data includes a target protocol type, a target cause value and a target cause description information; the determination module 12 is specifically used to: if the abnormal cause data is empty, determine that the abnormal type corresponding to the call abnormality cannot be directly determined through the maintenance information, and if the target protocol type, the target cause value and the target cause description information do not match, determine that the abnormal type corresponding to the call abnormality cannot be directly determined through the maintenance information.

[0115] Optionally, the abnormality cause data includes at least two sets of cause information; the determination module 12 is specifically configured to: if the at least two sets of cause information do not match, determine that the abnormality type corresponding to the call abnormality cannot be directly determined through the maintenance information.

[0116] Figure 7 The device shown can execute the steps performed based on the fault identification method in the aforementioned embodiment. The detailed execution process and technical effects can be found in the description of the aforementioned embodiment and will not be repeated here.

[0117] An embodiment of the present application also provides a terminal device, comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the terminal device is triggered to execute the above-mentioned fault identification method.

[0118] The terminal device may be a mobile phone, a wearable device, a tablet computer, a vehicle-mounted terminal, etc. The embodiments of the present application do not limit the specific technology and specific device form adopted by the terminal device.

[0119] In order to better understand the embodiments of the present application, the structure of the terminal device to which the embodiments of the present application are applicable is described below. Figure 8 FIG. 1 is a schematic diagram of the structure of a terminal device provided in an embodiment of the present application. Figure 8The terminal device 10 shown may include a processor 110 , a memory 120 , a universal serial bus (USB) interface 130 , a power supply 140 , a communication module 150 , a display screen 160 , and the like.

[0120] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the terminal device 10. In other embodiments of the present application, the terminal device 10 may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently. The illustrated components can be implemented in hardware, software, or a combination of software and hardware. The processor 110 may include one or more processing units, for example: the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a digital signal processor (DSP, baseband processor), etc. Among them, different processing units may be independent devices or integrated into one or more processors.

[0121] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0122] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0123] The power supply 140 supplies power to the terminal device 10 .

[0124] The communication module 150 can use any transceiver or similar device to provide the terminal device 10 with the following functions:

[0125] Wireless Local Area Networks (WLAN) (such as Wireless Fidelity (Wi-Fi) networks), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR) and other wireless communication solutions. The communication module 150 can be one or more devices that integrate at least one communication processing module. The communication module 150 receives electromagnetic waves via an antenna, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110. The communication module 150 can also receive the signal to be sent from the processor 110, frequency modulate it, amplify it, and convert it into electromagnetic waves for radiation through the antenna.

[0126] In some embodiments, the antenna of the terminal device 10 is coupled to the communication module 150 so that the terminal device 10 can communicate with a network and other devices via wireless communication technologies. The wireless communication technologies may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology. The GNSS may include global positioning system (GPS), global navigation satellite system (GLONASS), Beidou navigation satellite system (BDS), quasi-zenith satellite system (QZSS) and / or satellite based augmentation system (SBAS).

[0127] The terminal device 10 implements display functions through a GPU, display screen 160, and an application processor. The GPU is a microprocessor for image processing that connects the display screen 160 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.

[0128] The display screen 160 is used to display images, videos, etc. The display screen 160 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-oLed, or a quantum dot light-emitting diode (QLED). In some embodiments, the terminal device 10 may include one or N display screens 160, where N is a positive integer greater than 1.

[0129] The memory 120 can be used to store one or more computer programs, each of which includes instructions. The processor 110 can execute the instructions stored in the memory 120, thereby enabling the terminal device 10 to perform various functional applications and data processing. The memory 120 may include a program storage area and a data storage area. The program storage area may store an operating system.

[0130] The data storage area can store data created during the use of the terminal device 10. In addition, the memory 120 can

[0131] It includes high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. In some embodiments, the processor 110 can enable the terminal device 10 to perform various functional applications and data processing by running instructions stored in the memory 120 and / or instructions stored in the memory provided in the processor 110.

[0132] Figure 9 This is a software structure block diagram of a terminal device provided in an embodiment of the present application.

[0133] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0134] The application layer can include a series of application packages.

[0135] Figure 9 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, etc.

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

[0137] Figure 9 As shown, the framework layer may include a phone framework, a Bluetooth framework, an audio framework, and the like.

[0138] The phone framework is used to manage phone applications. It can obtain the display size, determine whether there is a status bar, lock the screen, take screenshots, etc.

[0139] The Bluetooth framework is used to provide Bluetooth functionality.

[0140] The audio framework is used to provide audio data.

[0141] The Android runtime includes core libraries and a virtual machine. The Android runtime is responsible for scheduling and management of the Android system.

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

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

[0144] The hardware abstraction layer can include multiple functional modules, such as call manager, Bluetooth manager, audio manager, etc.

[0145] The call manager is used to manage call functions.

[0146] The Bluetooth manager is used to manage Bluetooth functions.

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

[0148] The driver layer is the layer between hardware and software. The driver layer includes at least display driver, Bluetooth driver, audio driver, etc.

[0149] The following describes the workflow of the software and hardware of the terminal device 10 in combination with a fault identification scenario.

[0150] After obtaining the maintenance and measurement information generated by the second communication device when a call abnormality occurs, the processor 110 determines, based on the abnormality cause data, that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance and measurement information, and based on the call stage corresponding to the call abnormality, if it is determined that a target call abnormality event corresponding to the call stage has occurred, the abnormality type corresponding to the call abnormality is determined according to the target call abnormality event.

[0151] The present application also provides a computer-readable storage medium, which includes a stored program, wherein the device where the computer-readable storage medium is located is controlled to execute the above-mentioned fault identification method when the program is running. It should be understood by those skilled in the art that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0152] An embodiment of the present application further provides a computer program product, which includes: a computer program, which, when executed by a processor of an electronic device, causes the processor to execute the above-mentioned fault identification method.

[0153] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0154] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0155] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0156] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0157] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0158] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0159] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0160] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A fault identification method, characterized in that: Applied to a first communication device, the method includes: Acquire maintenance information generated when a call abnormality occurs with the second communication device, the maintenance information including abnormality cause data describing the call abnormality; Based on the abnormality cause data, determining that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information; Based on the call stage corresponding to the call abnormality, if it is determined that a target call abnormality event corresponding to the call stage occurs, the abnormality type corresponding to the call abnormality is determined according to the target call abnormality event, and the abnormality type includes a fault type and a non-fault type.

2. The method according to claim 1, characterized in that The call phase is the calling phase; If it is determined that a target call abnormality event corresponding to the call stage occurs, determining an abnormality type corresponding to the call abnormality according to the target call abnormality event includes: If a network announcement is received, it is determined that the abnormality type corresponding to the call abnormality is a fault type, and the network announcement is used to prompt the calling communication device that the current call is abnormal.

3. The method according to claim 1, characterized in that The call phase is the calling phase; If it is determined that a target call abnormality event corresponding to the call stage occurs, determining an abnormality type corresponding to the call abnormality according to the target call abnormality event includes: If the network announcement is not received, a network announcement corresponding to the maintenance and measurement information is found in a preset mapping relationship table between network announcements and maintenance and measurement information, and the abnormality type corresponding to the call abnormality is determined to be a fault type. The network announcement is used to prompt the calling communication device that the current call is abnormal.

4. The method according to claim 1, wherein The call stage is any one of a calling stage, a called stage and a call-in-progress stage; If it is determined that a target call abnormality event corresponding to the call stage occurs, determining an abnormality type corresponding to the call abnormality according to the target call abnormality event includes: If there is a first network abnormal behavior within a set time period before the maintenance information, it is determined that the abnormality type corresponding to the call abnormality is a fault type, and the first network abnormal behavior corresponds to a network connection condition.

5. The method according to claim 1, wherein The call stage is the call stage; If it is determined that a target call abnormality event corresponding to the call stage occurs, determining an abnormality type corresponding to the call abnormality according to the target call abnormality event includes: If there is a second network abnormal behavior within a set time period before the maintenance and measurement information, it is determined that the abnormality type corresponding to the call abnormality is a fault type, and the second network abnormal behavior corresponds to a message sending and receiving situation.

6. The method according to claim 1, characterized in that The determining, based on the abnormality cause data, that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information includes: If the abnormality cause data is empty, it is determined that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information.

7. The method according to claim 1, characterized in that The abnormal reason data includes target protocol type, target reason value and target reason description information; The determining, based on the abnormality cause data, that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information includes: If the target protocol type, the target cause value, and the target cause description information do not match, it is determined that the exception type corresponding to the call exception cannot be directly obtained through the maintenance information.

8. The method according to claim 1, characterized in that The abnormal cause data includes at least two sets of cause information; The determining, based on the abnormality cause data, that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information includes: If the at least two sets of cause information do not match, it is determined that the abnormality type corresponding to the call abnormality cannot be directly obtained through the maintenance information.

9. A terminal device, characterized in that: The method comprises a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the terminal device is triggered to execute the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the method according to any one of claims 1 to 8.

11. A computer program product, characterized in that include: A computer program, when executed by a processor of an electronic device, causes the processor to perform the method according to any one of claims 1 to 8.

Images