Fault processing method, electronic device and computer program product

Abstract

The embodiment of the invention provides a fault processing method, an electronic device and a computer program product, and the method comprises the steps: determining whether a fault is triggered by software or not; under the condition that the fault is triggered by the software, a fault type is matched from a pre-stored fault information base according to the fault information, and the corresponding relation of the fault information, the fault type and a fault solution is stored in the fault information base; if the fault type corresponding to the fault information is not matched, determining a target fault type corresponding to the fault information, calling target redundancy configuration information corresponding to the target fault type from a second calling area arranged in an external memory according to the target fault type, and processing the fault according to the target redundancy configuration information. According to the invention, the problem that the radio frequency drive is automatically configured according to hardware information in the prior art, and the fault can not be automatically recovered once the configuration is wrong or part of information is lost can be solved, and the fault type caused by software can be quickly positioned and processed.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communication technologies, and more specifically, to a fault handling method, an electronic device, and a computer program product. Background Art

[0002] With the continuous development of 5G and 6G, the networking of Stand-Alone (SA), Non-Stand-Alone (NSA), and Carrier Aggregation (CA) frequency bands supported by UEs has become increasingly complex, and the switching paths inside the radio frequency front-end modems have also become correspondingly complex. The radio frequency software drivers for these physical devices consume a great deal of human resources, and the radio frequency software drivers are all manually configured by engineers. Once the configuration is incorrect or lost, it will cause faults such as the UE crashing and being unable to automatically recover, seriously affecting the user experience. Moreover, when automatically configuring the radio frequency driver according to the hardware information, if the configuration is incorrect or some information is lost, it will cause faults and other anomalies and be unable to automatically recover. Summary of the Invention

[0003] The embodiments of the present application provide a fault handling method, an electronic device, and a computer program product to at least solve the problem in the related art that when automatically configuring the radio frequency driver according to the hardware information, if the configuration is incorrect or some information is lost, it will cause faults and be unable to automatically recover.

[0004] According to an embodiment of the present application, a fault handling method is provided, including: determining whether the fault is triggered by software; in the case where the fault is triggered by software, matching the fault type from a pre-stored fault information library according to the fault information, where the fault information library stores the corresponding relationships among fault information, fault types, and fault solutions; if the fault type corresponding to the fault information is not matched, determining the target fault type corresponding to the fault information, calling the target redundant configuration information corresponding to the target fault type from a second call area set in the external memory according to the target fault type, and handling the fault according to the target redundant configuration information.

[0005] According to another embodiment of the present application, a computer-readable storage medium is further provided. A computer program is stored in the computer-readable storage medium, where the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0006] According to another embodiment of the present application, an electronic device is further provided, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0007] According to another embodiment of the present application, a computer program product is further provided, including a computer program, and when the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0008] Through the above embodiments of the present application, it is determined whether a fault is triggered by software; in the case where the fault is triggered by software, the fault type is matched from a pre-stored fault information library according to the fault information, wherein the corresponding relationships among fault information, fault types, and fault solutions are stored in the fault information library; if the fault type corresponding to the fault information is not matched, the target fault type corresponding to the fault information is determined, and the target redundant configuration information corresponding to the target fault type is called from a second call area provided in the external memory according to the target fault type, and the fault is processed according to the target redundant configuration information, which can solve the problem in the related art that when automatically configuring a radio frequency driver according to hardware information, a fault will occur and cannot be automatically recovered once the configuration is incorrect or some information is lost. If the fault is triggered by software, the fault type corresponding to the fault information is determined, and the corresponding redundant configuration information is called from the second call area provided in the external memory according to the fault type, which can quickly locate the fault type caused by software and call corresponding parameters from the preset redundant configuration information for processing, thereby significantly improving the fault handling efficiency and accuracy. In the fault scenario triggered by software, the processing delay caused by parameter missing or configuration conflict is avoided, ensuring the stable operation of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is a schematic hardware structure diagram of a mobile terminal on which the method embodiment of the present application runs;

[0010] Figure 2 is a flowchart of a fault handling method according to an embodiment of the present application;

[0011] Figure 3 is a schematic diagram of an intelligent error correction device for radio frequency drive faults according to an embodiment of the present application;

[0012] Figure 4 is a flowchart of fault error correction caused by missing calibration parameters according to an embodiment of the present application;

[0013] Figure 5 is a flowchart of generating NV parameters from calibration parameters in a second call area according to an embodiment of the present application;

[0014] Figure 6 is a flowchart of fault error correction caused by drive path conflict according to an embodiment of the present application;

[0015] Figure 7 is a schematic structural diagram of a drive path NV model according to an embodiment of the present application;

[0016] Figure 8 It is a schematic diagram of a driving path NV generation model according to an embodiment of the present application;

[0017] Figure 9 It is a schematic diagram of error correction for UE capability information mismatch faults according to an embodiment of the present application. Specific Embodiments

[0018] In the following, embodiments of the present application will be described in detail with reference to the accompanying drawings and in conjunction with the embodiments.

[0019] It should be noted that the terms "first", "second", etc. in the description and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence.

[0020] The method embodiments provided in the embodiments of the present application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 It is a schematic hardware structure diagram of the mobile terminal on which the method embodiment of the present application runs. As Figure 1 shown, the mobile terminal may include one or more ( Figure 1 only one is shown in the figure) processors 102 (the processors 102 may include, but are not limited to, processing devices such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Among them, the above-mentioned mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those of ordinary skill in the art can understand that Figure 1 the structure shown in the figure is only schematic and does not limit the structure of the above-mentioned mobile terminal. For example, the mobile terminal may further include more or fewer components than Figure 1 shown in the figure, or have a different configuration from Figure 1 shown in the figure.

[0021] The memory 104 can be used to store computer programs. For example, software programs and modules of application software, such as the computer program corresponding to the fault handling method in the embodiments of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implements the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely provided relative to the processor 102, and these remote memories can be connected to the mobile terminal through a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0022] The transmission device 106 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wireless network provided by a communication provider of a mobile terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, abbreviated as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a Radio Frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0023] In this embodiment, a fault handling method running on the above-mentioned mobile terminal or network architecture is provided. Figure 2 It is a flowchart of the fault handling method according to the embodiment of the present application, as Figure 2 shown, and the process includes the following steps:

[0024] Step S202, determine whether the fault is triggered by software;

[0025] Step S204, when the fault is triggered by software, match the fault type from the pre-stored fault information library according to the fault information, wherein the corresponding relationship between the fault information, the fault type and the fault solution is stored in the fault information library;

[0026] Step S206, if the fault type corresponding to the fault information is not matched, determine the target fault type corresponding to the fault information, call the target redundant configuration information corresponding to the target fault type from the second call area set in the external memory according to the target fault type, and process the fault according to the target redundant configuration information.

[0027] Through the above steps S202 to S206, it is possible to solve the problem in the related art that when automatically configuring the RF driver according to the hardware information, a fault will occur and cannot be automatically recovered once the configuration is incorrect or some information is lost. If the fault is triggered by software, determine the fault type corresponding to the fault information, and call the corresponding redundant configuration information from the second call area set in the external memory according to the fault type, which can quickly locate the fault type caused by software and call the corresponding parameters from the preset redundant configuration information for processing, thereby significantly improving the fault handling efficiency and accuracy. In the fault scenario triggered by software, the processing delay caused by parameter missing or configuration conflict is avoided, ensuring the stable operation of the system.

[0028] In one embodiment, determining the target fault type corresponding to the fault information and calling the target redundancy configuration information corresponding to the target fault type from the second call area set in the external memory further includes: determining that the target fault type is the lack of radio frequency calibration parameters according to the keywords carried in the fault information; calling the radio frequency calibration parameters from the second call area. The radio frequency calibration parameters refer to the parameters used to adjust and optimize the radio frequency performance of wireless communication devices (such as mobile phones, base stations, etc.), including all calibration parameter information of the single band supported by the UE hardware, Dual Connectivity (DC for short), and Carrier Aggregation (CA for short). Through the keyword recognition technology, the system can accurately determine that the fault type is the lack of radio frequency calibration parameters, and then call the corresponding radio frequency calibration parameters from the second call area for repair.

[0029] Single band refers to the operating mode of a single frequency band. In such a case, a mobile device (such as a mobile phone or UE) communicates only on a specific frequency band. This is the most basic way of using the frequency band. In early 2G and 3G technologies, devices usually supported only one or a few frequency bands. Even now, when using the single band mode, devices may support many different frequency bands to adapt to various networks globally.

[0030] DC refers to the dual connectivity operating mode. This is a technology that allows a UE to connect to two different base stations (NodeB and eNodeB) simultaneously. One connection can be a 4G LTE network, and the other can be a 5G NR network. The advantage of this is to improve the data transmission rate and network coverage, because it allows the device to use the resources of two base stations to send and receive data. Especially in the initial stage of 5G, when the network coverage and capacity are not perfect, the dual connection of 4G and 5G can provide better service quality and user experience.

[0031] CA is a spectrum aggregation technology that allows a UE to communicate on multiple carriers simultaneously. These carriers can be on the same or different frequency bands. By aggregating the bandwidths of multiple carriers, the data transmission rate can be greatly improved. For example, a UE can use a 10MHz carrier on the 800MHz frequency band, a 15MHz carrier on the 1800MHz frequency band, and a 20MHz carrier on the 2100MHz frequency band. Through carrier aggregation, the UE can combine the bandwidths of these carriers to transmit data, thereby achieving a higher or more stable data rate than a single carrier.

[0032] In one embodiment, invoking radio frequency calibration parameters from the second invocation area includes: invoking corresponding radio frequency calibration parameters from the second invocation area based on an index. Among them, the radio frequency calibration parameters in the second invocation area correspond to the index of the radio frequency calibration parameters in the first invocation area set in the memory. The radio frequency calibration parameters include all calibration parameter information of single band, dual connectivity (DC), and carrier aggregation (CA) supported by the UE hardware. The index is a fast lookup mechanism. By assigning unique index values to different radio frequency calibration parameters, the system can immediately locate the parameter position to be invoked after receiving the fault information, greatly accelerating the fault handling speed. This mechanism is particularly applicable to complex and large quantities of configuration information such as radio frequency calibration parameters, ensuring that the correct calibration parameters can be quickly found and applied even among a large number of parameters. In addition, by storing the index associated with the parameters, the stability and efficiency of the invocation mechanism can be ensured even in the case of parameter updates or additions.

[0033] In one embodiment, the above method further includes: classifying the radio frequency calibration parameters according to network deployment, radio access technology, and band, where the index corresponding to each network deployment, radio access technology, and band is different; setting corresponding indexes for the radio frequency calibration parameters according to the classification results, and associatively storing the indexes and the radio frequency calibration parameters in the second invocation area. The classification and indexing of radio frequency calibration parameters are key steps to improve the fault handling efficiency. Network deployment (such as macro network, micro network), radio access technology (such as GSM, LTE, 5G NR), and band (such as Band 7, Band 41) are common classification dimensions in wireless communication. By classifying the radio frequency calibration parameters through these dimensions, it can be ensured that when dealing with specific types of faults, the system can quickly locate the relevant parameters, avoiding resource waste caused by blind search.

[0034] In one embodiment, determining the target fault type corresponding to the fault information and invoking the target redundant configuration information corresponding to the target fault type from the second invocation area set in the external memory may include: determining that the target fault type is an internal drive path conflict of the radio frequency modem according to the keyword carried in the fault information; invoking the drive path configuration information from the second invocation area. The internal drive path conflict of the radio frequency modem usually occurs during the loading process of the operating system or application programs, manifested as incorrect allocation or use of hardware resources, affecting the normal function of the device. Through keyword recognition technology, the system can accurately determine that the fault type is an internal drive path conflict of the radio frequency modem, and then invoke the drive path configuration information in the second invocation area for repair. The drive path configuration information includes all drive path parameters included under all bands, dual connectivity (DC), and carrier aggregation (CA) supported by the hardware. Each band, DC, and CA forms a drive path model with the supported drive path configuration information.

[0035] In one embodiment, invoking the drive path configuration information from the second invocation area includes: analyzing the hardware configuration of the UE; invoking the drive path configuration information in the second invocation area through drive path model matching. The analysis of the hardware configuration of the UE (User Equipment) is the basis for ensuring the correct invocation of the drive path configuration information. Through in-depth analysis of the UE hardware configuration, the system can understand the specific requirements of the device, such as supported frequency bands, dual connectivity, and carrier aggregation capabilities, and then invoke the drive path configuration information in the second invocation area through drive path model matching, avoiding potential risks caused by incompatibility or incorrect configuration.

[0036] In one embodiment, the drive path configuration information includes all drive path parameters included under all bands supported by the hardware, dual connectivity DC, and carrier aggregation CA. Each band, DC, and CA forms a drive path model with the supported drive path configuration information. The drive path model is a set of parameters designed for different hardware configurations and communication requirements. It contains the necessary parameters for the device to operate in various communication environments (such as different frequency bands, dual connectivity, and carrier aggregation). By establishing diverse drive path models, the system can flexibly handle various complex communication scenarios and ensure the stable operation of the device under different conditions.

[0037] In one embodiment, before invoking the drive path configuration information in the second invocation area through NV drive path model matching, the above method further includes: obtaining the corresponding drive path model according to the network architecture, radio access technology, and band. The selection of the NV (Non-Volatile Memory) drive path model is based on the current network architecture, radio access technology, and frequency band requirements of the device. This process ensures that the system can invoke the most suitable drive path configuration information according to real-time communication conditions, avoiding problems such as low communication efficiency and resource waste caused by improper model selection.

[0038] In one embodiment, determining the target fault type corresponding to the fault information and invoking the target redundant configuration information corresponding to the target fault type from the second invocation area set in the external memory includes: determining that the target fault type is that the UE registration capability information does not match the actual hardware capability information according to the keywords carried in the fault information; invoking the UE capability information parameters that match the hardware capability from the second invocation area. The mismatch between the UE registration capability information and the actual hardware capability information may cause the device to be unable to fully utilize its hardware resources, affecting communication performance and service quality. Through keyword recognition, the system can accurately identify such faults and invoke the UE capability information parameters that match the hardware capability from the second invocation area for repair.

[0039] In one embodiment, the UE capability information that matches the hardware capabilities and is called from the second call area includes: calling the UE capability information from the capability information list in the second call area in an encoded manner, where the capability information list is generated by a hardware capability information generator. The hardware capability information generator can generate a corresponding capability information list according to the actual hardware configuration of the UE, and each item of UE capability information in the list corresponds to a specific hardware function in an encoded manner.

[0040] In one embodiment, the UE capability information in the second call area is consistent with the maximum hardware capability information. Each type of UE capability information corresponds to the UE capability information in the first call area set in the memory in an encoded manner, and the capability information in the first call area is a subset of the UE capability information in the second call area. By ensuring that the UE capability information in the second call area is consistent with the maximum hardware capability information, the system can comprehensively cover all possible functions of the device, avoiding function limitations caused by missing capability information.

[0041] In one embodiment, the above method further includes: if a fault type corresponding to the fault information is matched, processing the fault according to the target fault solution corresponding to the fault type corresponding to the fault information. This step reflects the intelligent and automated characteristics of the fault processing method. When the system can match the fault type from the fault information library, it will automatically call the corresponding fault solution without manual intervention, greatly improving the efficiency and accuracy of fault processing.

[0042] In one embodiment, after processing the fault according to the target redundancy configuration information, the method further includes: storing the fault information, the target fault type, and the target redundancy configuration information in the fault information library in a corresponding manner. Storing the key information in the fault processing process feedback in the fault information library is an important means to improve the self-learning and optimization ability of the fault processing system. By recording the specific information, type, and redundancy configuration information used for each fault, the system can continuously accumulate fault processing experience, optimize the fault type matching algorithm and redundancy configuration information calling strategy, so that when encountering similar faults in the future, it can be processed more quickly and accurately. This mechanism solves the problem of the lack of self-evolution ability of the fault processing system and improves the long-term stability and efficiency of the system.

[0043] In the embodiments of the present application, by intelligently matching the fault types and redundant configuration information, the efficiency and accuracy of fault handling are significantly improved. In the fault scenarios triggered by software, the fault type can be quickly located, and the corresponding parameters can be called from the preset redundant configuration information for processing, avoiding processing delays caused by missing parameters or configuration conflicts. At the same time, by invoking the redundant configuration information in the external memory, the burden on the memory is effectively reduced, and the operating efficiency of the system is improved. In addition, storing the fault information, fault types, and redundant configuration information in correspondence provides data support for subsequent fault analysis and prevention, further enhancing the stability of the system and the user experience. The combination, cooperation, and interaction of these technical features not only solve various fault problems encountered by wireless communication devices at the software level but also optimize resource allocation and improve the overall performance of the system, including but not limited to increasing the fault handling speed, reducing resource waste, and enhancing the system's self-learning and optimization capabilities, thereby providing a more stable, efficient, and intelligent communication environment for users.

[0044] Taking the deadlock as an example below, the embodiments of the present application will be described by way of illustration.

[0045] Figure 3 It is a schematic diagram of an intelligent error correction device for radio frequency drive faults according to the embodiments of the present application. As Figure 3 shown, when the UE experiences a deadlock, the UE deadlock problem reporting module sends the deadlock problem to the deadlock problem determination module. After receiving this fault, the deadlock problem determination module starts the deadlock problem judgment process.

[0046] The deadlock problem determination module first determines whether the deadlock problem is a software-triggered deadlock or a hardware-triggered deadlock. If it is a hardware-triggered deadlock, it provides the user with the hardware device information corresponding to the triggered deadlock and terminates the process; if it is a software-triggered deadlock, the radio frequency drive intelligent analysis module starts the analysis and solution process. The radio frequency drive intelligent analysis module includes: a fault information library, an information library matching module, a fault type library, and a second call area NV parameter.

[0047] Fault information library: The fault information library stores common deadlock information types / deadlock causes and solutions.

[0048] Information library matching module: The information library matching module matches the received deadlock information with the deadlock types in the fault information library.

[0049] Fault type library: There are mainly three types of deadlocks, namely: missing registration band radio frequency calibration parameters, internal drive path conflicts of the radio frequency modem, and UE capability information not matching the currently registered band.

[0050] The NV (Non-Volatile) parameters in the second call area mainly consist of three parts of NV parameter content: calibrating parameters in the second call area to find suitable NV parameters, finding the internal drive path NV parameters of a suitable modem in the second call area, and finding the corresponding Band NV parameters supported by software in the second call area. Among them, NV parameters usually refer to the configuration data stored in non-volatile memory, which is used to save calibration data, frequency band configuration, etc. of the radio frequency module. Incorrect configuration will cause equipment failures.

[0051] If it is a software-triggered crash, the information library matching module matches according to the received crash information and the crash types in the fault information library. If the match is successful, the crash problem is solved according to the fault information library solution. If the match fails, it enters the fault type library identification process, matches the three types in the fault type library respectively, solves the crash problem according to the corresponding strategy, and stores the crash information type / crash reason and the solution in the fault information library.

[0052] The three solution strategies of the fault type library include:

[0053] The first type: the crash problem caused by the lack of calibration parameters in the currently registered bandwidth (band). By default, the calibration parameters in the first call area are stored in the memory and generated during product factory production. Figure 4 It is a flowchart of fault correction due to the lack of calibration parameters according to the embodiments of the present application. As Figure 4 shown, the UE second call area calibration parameters include all calibration parameter information of single band, DC, and CA supported by UE hardware. This calibration parameter is stored in the external memory, which reduces memory occupancy and has high security. It will not cause the lack of NV parameters due to user version upgrade or certain operations. For specific generation, see the second call area calibration parameter generation process. The calibration information is classified according to networking, system type, and Band. The corresponding indexes for each networking, system type, and band are different. The calibration parameters in the backup area correspond to the indexes of the UE working area calibration parameters, and the corresponding calibration parameters can be called by accessing the index indication method.

[0054] Figure 5 It is a flowchart of generating NV parameters from the second call area calibration parameters according to the embodiments of the present application. As Figure 5 shown, the NV parameter generator obtains the CA, DC, and normal cell bandwidth (Normal cell Band) and bandwidth combination (Bandcobination) information lists supported by the hardware from the terminal, writes the generated NV parameters into the terminal under test, and the NV parameter fitting device verifies the accuracy of the NV parameters. If it is inaccurate, the NV parameter generator will be enabled again.

[0055] The NV parameter structure in the second call area:

[0056] Each band has different bandwidth parameters, and the specific bandwidth follows the 3GPP protocol. Each bandwidth parameter is composed of different frequency parameters. Each frequency parameter contains information such as Tx calibration information / Rx calibration information / voltage / power gain control word / band flatness parameter / path loss compensation parameter, etc. TX represents the UE transmission link, and RX represents the UE reception link.

[0057] In the NV parameters of the second call area, the index numbers of each band correspond to the index of the band in the first call area, and the calibration parameters can be fully matched after being called.

[0058] Figure 6 It is a flowchart of fault correction caused by drive path conflict according to the embodiment of the present application. As Figure 6 shown, if the call is successful and the crash fault can be solved, the error correction success flag = 1; insert a window to maintain the data for X seconds. If the number of times cal_flag_num when flag = 1 >= 5, then enable the call data to complete the error correction.

[0059] The second type: The NV parameters of the radio frequency modulation and demodulation drive path include all drive path NV parameters included in all Bands, CAs, and DCs supported by the hardware. The NV parameters of this path are stored in the external memory, reducing memory occupancy and having relatively high security. It covers all path combinations supported by the hardware and will not trigger a crash due to user version upgrade or certain operation applications causing NV drive path conflict. Each band, CA, and DC form an NV drive path model with the supported modulation and demodulation drive path NV.

[0060] Figure 7 It is a schematic structural diagram of the drive path NV model according to the embodiment of the present application. As Figure 7As shown, the input ports of the Primary Receiver (PRX) and the Diversity Receiver (DRX) represent the input ports of different bands at the modem. PRX refers to the main set reception, and DRX refers to the diversity reception. A, B, C, and D represent different mixers. PRX_M0 is connected to mixer A, with drive path configuration 1_2; PRX_M1 is connected to mixer B, with drive path configuration 2_2; DRX_M0 is connected to mixer D, with drive path configuration 4_3; DRX_M1 is connected to mixer C, with drive path configuration 3_3. If N1 supports 1T4R, then 2 different PRX paths and 2 different DRX paths need to be configured. The RX DFE (Receiver Decision Feedback Equalizer) is used to compensate for the signal distortion generated during channel transmission and improve the signal reception quality. The mixer mixes the radio frequency signal with the local oscillator signal generated by the local oscillator to achieve frequency conversion and finally convert it into a lower intermediate frequency signal. In the CA, DC, and Normal cell scenarios, the drive path NV represents the mixer paths passed by different PRXs and DRXs of different bands. When the mixer paths of two or more bands working simultaneously cannot conflict, otherwise it will trigger a crash. For example, based on the above N1 configuration, for the DC composed of B3_N1, B3 cannot select the paths of mixers A and B of PRX, and DRX cannot select the paths of mixers C and D of DRX.

[0061] Figure 8 is a schematic diagram of the drive path NV generation model according to an embodiment of the present application, as Figure 8 shown, the process of generating the drive path NV parameters in the second call area includes: each drive path includes a PRX-specified mixer and a DRX-specified mixer. Each path is generated by the drive path NV parameter generator. The number of drive paths for a single band is the largest, and each path is different. The CA and DC drive path generators will list all non-conflicting path combinations and make specifications to ensure that each combination does not conflict. For example, the first combination of band3 and band41 DC is: the second path of band3 and the third path of band41, and list them in turn to form the NV parameters in the second call area.

[0062] When the UE has a conflict in NV parameters of the radio frequency modulation and demodulation drive path, the UE obtains the corresponding NV drive path model according to the network configuration, radio access technology, and Band, and calls the corresponding drive path NV model to solve the freeze problem. If the NV drive path model is successfully called and the freeze problem is solved, the error correction success flag = 1; maintain an interpolation window for data for X seconds. If the number of times flag = 1, path_flag_num >= 5, then enable the NV drive path model.

[0063] The third type: The freeze caused by the mismatch between the UE registration capability information NV parameter and the actual hardware capability information. Because the memory is limited, to save memory and improve the running speed, the NV parameters in the default memory are a subset of the NV parameters in the external memory. When the memory NV parameters do not match or are greater than the hardware capability information, a freeze is triggered. At this time, the memory NV parameters call the NV parameters in the second call area of the external memory to restore the freeze problem. The NV parameters in the second call area are stored in the external memory, with less memory occupancy and high security, and will not cause a freeze due to the user upgrading the version or certain operations resulting in the loss or increase of the capability information NV parameters.

[0064] Call the corresponding NV parameters to solve the problem. For the first type, call the calibration parameters in the NV parameters of the second call area, and directly locate the required calibration parameters through the index. Because the NV parameters in the second call area cover all possible parameter information and are stored in the external memory, they are more secure and reliable. Once the location is successful, the calibration parameters stored in the external memory will be called to restore the calibration function and make the UE return to normal. For the second type, call the drive path model in the NV parameters of the second call area to match the drive path NV parameters under the current network configuration, radio access technology, and Band. By calling the perfectly matched NV model, reconfigure the drive path to eliminate the conflict between paths, thereby solving the freeze problem. For the third type, call the UE capability information NV parameters in the NV parameters of the second call area. By judging through the encoding and decoding method, if the decoding result is 1, it means that the matching capability information NV parameters are found, and then call the NV parameters to solve the freeze problem.

[0065] Figure 9 It is a schematic diagram of error correction for the UE capability information mismatch fault according to the embodiment of the present application, as Figure 9As shown, the capability information in the second call area NV parameter is consistent with the maximum hardware capability information, including single band\CA\DC combinations. The UE generates a corresponding list through the hardware capability information generator. Each type of capability information corresponds to the NV parameter of the memory working area capability information through encoding. The call is through encoding and decoding. Here, the encoding and decoding are determined by 0 and 1. If the decoding is successful, the result is 1, and if the crash problem is solved, the error correction success flag = 1; maintain an insertion window for data for X seconds. If the number of times flag = 1, cap_flag_num >= 5, then enable the NV parameter of the external memory capability information.

[0066] The successful cases of solving the above three types of fault type library solutions will be stored in the fault information library. Subsequently, if the information library matching module matches successfully with the fault information library, the solution will be directly called without further classification calls.

[0067] Through the description of the above implementation manners, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disc) and includes several instructions for causing a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of the present application.

[0068] In this embodiment, a fault processing device is also provided. This device is used to implement the above embodiments and preferred implementation manners, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated. The device includes:

[0069] A determination module, configured to determine whether the fault is triggered by software;

[0070] A matching module, configured to, when the fault is triggered by software, match the fault type from a pre-stored fault information library according to the fault information, where the fault information library stores the corresponding relationships between fault information, fault types, and fault solutions;

[0071] A processing module, configured to, if the fault type corresponding to the fault information is not matched, determine the target fault type corresponding to the fault information, call the target redundant configuration information corresponding to the target fault type from a second call area set in the external memory according to the target fault type, and process the fault according to the target redundant configuration information.

[0072] It should be noted that the above-mentioned various modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited thereto: all the above-mentioned modules are located in the same processor; or, the above-mentioned various modules are respectively located in different processors in any combination form.

[0073] An embodiment of the present application also provides a computer-readable storage medium, in which a computer program is stored. Wherein, the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0074] In an exemplary embodiment, the above-mentioned computer-readable storage medium may include, but is not limited to: USB flash drive, read-only memory (ROM for short), random access memory (RAM for short), mobile hard disk, magnetic disk or optical disc and other various media that can store computer programs.

[0075] An embodiment of the present application also provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0076] In an exemplary embodiment, the above-mentioned electronic device may further include a transmission device and an input / output device. Wherein, the transmission device is connected to the above-mentioned processor, and the input / output device is connected to the above-mentioned processor.

[0077] Specific examples in this embodiment may refer to the examples described in the above embodiments and exemplary embodiments, and will not be repeated here.

[0078] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present application can be implemented by a general-purpose computing device. They can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order than here, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module to implement. In this way, the present application is not limited to any specific combination of hardware and software.

[0079] The above are only the preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the principle of the present application shall be included within the protection scope of the present application.

Claims

1. A fault handling method, characterized in that: include: Determine if the fault was triggered by software; In the case where the fault is triggered by software, the fault type is matched from a pre-stored fault information library according to the fault information, wherein the fault information library stores the corresponding relationship between the fault information, the fault type and the fault solution; If the fault type corresponding to the fault information is not matched, determine the target fault type corresponding to the fault information, call the target redundant configuration information corresponding to the target fault type from the second calling area set in the external memory according to the target fault type, and process the fault according to the target redundant configuration information.

2. The method according to claim 1, characterized in that Determining a target fault type corresponding to the fault information, and calling target redundant configuration information corresponding to the target fault type from a second calling area set in the external memory according to the target fault type includes: Determining, according to the keywords carried in the fault information, that the target fault type is missing radio frequency calibration parameters; The radio frequency calibration parameters are called from the second calling area.

3. The method according to claim 2, characterized in that Calling the radio frequency calibration parameters from the second calling area includes: Based on the index index, the corresponding RF calibration parameters are called from the second calling area, wherein the RF calibration parameters of the second calling area correspond to the index of the RF calibration parameters of the first calling area set in the memory, and the RF calibration parameters include all calibration parameter information of single frequency band, dual connection DC and carrier aggregation CA supported by UE hardware.

4. The method according to claim 3, characterized in that The method further comprises: Classify the radio frequency calibration parameters according to networking, standard and / or band, wherein each networking, standard and band has a different index; A corresponding index is set for the radio frequency calibration parameter according to the classification result, and the index is associated with the radio frequency calibration parameter and stored in the second calling area.

5. The method according to claim 1, characterized in that: Determining a target fault type corresponding to the fault information, and calling target redundant configuration information corresponding to the target fault type from a second calling area set in the external memory according to the target fault type includes: Determining, according to the keywords carried in the fault information, that the target fault type is an internal drive path conflict of a radio frequency modem; The driving path configuration information is called from the second calling area.

6. The method according to claim 5, characterized in that Calling the drive path configuration information from the second calling area includes: Analyze the hardware configuration of UE; The driving path configuration information in the second calling area is called through driving path model matching.

7. The method according to claim 6, characterized in that The driving path configuration information includes all driving path parameters contained in all bands, dual connections DC and carrier aggregation CA supported by the hardware. Each band, DC, CA and the supported driving path configuration information form a driving path model.

8. The method according to claim 6, characterized in that Before calling the drive path configuration information in the second calling area through NV drive path model matching, the method further includes: The corresponding driving path model is obtained according to the network, standard and Band.

9. The method according to claim 1, characterized in that: Determining a target fault type corresponding to the fault information, and calling target redundant configuration information corresponding to the target fault type from a second calling area set in the external memory according to the target fault type includes: Determining, according to the keywords carried in the fault information, that the target fault type is that the UE registration capability information is inconsistent with the actual hardware capability information; The UE capability information parameters matching the hardware capability are called from the second calling area.

10. The method according to claim 9, characterized in that Calling the UE capability information matching the hardware capability from the second calling area includes: The UE capability information is called from a capability information list in the second calling area in an encoding manner, wherein the capability information list is generated by a hardware capability information generator.

11. The method according to claim 10, characterized in that The UE capability information of the second calling area is consistent with the hardware maximum capability information. Each type of UE capability information corresponds to the UE capability information of the first calling area set in the memory through encoding. The capability information of the first calling area is a subset of the UE capability information of the second calling area.

12. The method according to claim 1, characterized in that The method further comprises: If a fault type corresponding to the fault information is matched, the fault is processed according to a target fault solution corresponding to the fault type corresponding to the fault information.

13. The method according to any one of claims 1 to 12, characterized in that After processing the fault according to the target redundant configuration information, the method further includes: The fault information, the target fault type and the target redundant configuration information are correspondingly stored in the fault information library.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method described in any one of claims 1 to 13 are implemented.

15. A computer program product, characterized in that The invention comprises a computer program, which implements the steps of the method described in any one of claims 1 to 13 when being executed by a processor.

Images