CN111212417A - Mobile terminal and crash fault recovery method thereof - Google Patents
Mobile terminal and crash fault recovery method thereof Download PDFInfo
- Publication number
- CN111212417A CN111212417A CN201911321115.XA CN201911321115A CN111212417A CN 111212417 A CN111212417 A CN 111212417A CN 201911321115 A CN201911321115 A CN 201911321115A CN 111212417 A CN111212417 A CN 111212417A
- Authority
- CN
- China
- Prior art keywords
- baseband processor
- mobile terminal
- module
- crash
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/19—Connection re-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
- H04W8/20—Transfer of user or subscriber data
- H04W8/205—Transfer to or from user equipment or user record carrier
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
The application discloses a crash fault recovery method of a mobile terminal. When the baseband processor detects that the baseband processor has a crash fault, the current effective information of the EMM module, the ESM module and the RRC module is stored in the nonvolatile memory, and then the baseband processor sends an abnormal indication to the application processor. And after receiving the abnormal indication, the application processor firstly powers off the baseband processor, then powers on the baseband processor, reloads the baseband processor and then sends a hot start instruction to the baseband processor. And after receiving the hot start instruction, the baseband processor reads the file and initializes the module. The baseband processor detects whether the registered state stored for the EMM module is an idle state or a service state when the mobile terminal is in a crash fault, and also detects whether the current serving cell is changed compared with the serving cell before the crash fault of the mobile terminal, and four processing modes are provided according to four different conditions. The method and the device can quickly recover the mobile terminal to the normal state before the crash fault occurs after the mobile terminal is restarted.
Description
Technical Field
The application relates to a crash fault solution method of a mobile terminal.
Background
A crash failure of a mobile terminal (UE) mainly includes the following. First, Data Abort (Data Abort), typically occurs when an illegal address is read or written. Second, prefetch abort (PrefetchAbort), typically occurs when the associated address does not fetch data or cannot be accessed when referring to a prefetch instruction. Third, Undefined instructions (Undefined Instruction) typically occur when illegal instructions are encountered. Fourth, others.
For example, when the mobile terminal performs data copy, if a destination address is not allocated, the destination address is usually "0" at this time, and a data suspension type exception occurs. When such a problem occurs, the mobile terminal must perform a special operation such as a restart to resume normal operation. Therefore, commercial handsets are generally configured with a dead-end auto-restart (silence) function.
Referring to fig. 1, a method for implementing automatic restart after crash of a conventional mobile terminal includes the following steps.
Step S110: when a Baseband Processor (Baseband Processor, BP) detects that the Baseband Processor has a dead halt fault, a restart instruction is sent to an Application Processor (AP).
Step S120: and after the application processor receives the restart instruction, powering down the baseband processor, powering up the baseband processor and reloading the baseband processor.
Step S130: and the baseband processor initializes modules such as file reading, memory and the like.
Step S140: the application processor loads the SIM card.
For convenience of description, in this document, a Subscriber Identity Module (SIM) card is used to denote a smart card used by a mobile terminal, in which subscriber identity data, an authentication algorithm, a corresponding key, and the like are stored for identifying and authenticating the mobile terminal accessing a mobile communication network. The SIM Card is to be understood in a broad sense, and includes R-uim (removable User Identity module) Card, uim (User Identity module) Card, UICC (Universal Integrated Circuit Card) built-in SIM application, usim (Universal electronic subscriber Identity module) application, csim (cdma Identity module) and the like having the same function in different mobile communication networks.
Step S150: and the baseband processor triggers a software starting process of the mobile terminal through a command.
Step S160: the baseband processor searches for a mobile communication network, resides in a serving cell, registers to the serving cell, and then the mobile terminal enters a standby state.
In the method for realizing the automatic restart after the mobile terminal crashes, the time from the mobile terminal failure to the normal recovery generally takes 10 seconds or even dozens of seconds, and the ongoing voice call, data service interruption or information loss can be caused, thereby seriously influencing the user experience and simultaneously increasing the repair rate of the mobile terminal.
The REGISTERED state (REGISTERED) means that the mobile terminal resides in a certain serving cell of the mobile communication network and completes a registration process with the network, the registration process includes authentication, security mode control, related resource allocation and the like, and the mobile terminal can receive and transmit information through the mobile communication network. The registration state corresponds to the content of the EMM-registered.normal-SERVICE (EMM registration state) part of the NAS (Non access stratum) protocol of 3GPP, and includes two modes, EMM-IDLE (IDLE state) and EMM-CONNECTED (traffic state). Where EMM denotes an epsmobiliity Management (EPS mobility Management) and EPS denotes an Evolved Packet System (Evolved Packet System).
Referring to fig. 2, the mobile terminal registering to a serving cell of the mobile communication network through the baseband processor includes the following steps. This is a normal cell registration procedure, which does not include the scenario that the mobile terminal is not inserted with a SIM card and an emergency call. These steps correspond to the "register to serving cell" part of step S160, i.e. the process of the mobile terminal acquiring the registration state from the mobile communication network through the baseband processor.
Step S210: after the baseband processor completes the search of the mobile communication network and resides in a certain serving cell, an RRC (Radio Resource Control) connection is established between the baseband processor and the mobile communication network.
Step S220: the baseband processor sends a registration request to the network side.
Step S230: the network side sends an authentication request to the baseband processor, and the baseband processor sends an authentication response to the network side.
Step S240: the network side sends an NAS security mode control instruction to the baseband processor, and the baseband processor reports the completion of the NAS security mode control to the network side.
Step S250: the base band processor and the network side perform AS (Access Transit) security mode control and bearer resource allocation.
Step S260: the network side receives and completes the registration of the mobile terminal to the service cell, and the mobile terminal is in a service mode in a registration state at the moment.
Step S270: the network side releases the RRC connection with the mobile terminal, and the mobile terminal is in an idle mode in a registered state, which is equivalent to the mobile terminal being in a standby state.
When the mobile terminal performs the automatic restart process after crash, the process of registering the cell dominated by the baseband processor shown in fig. 2 will be repeated again. In most cases, the mobile terminal is in the registered state before a crash failure occurs. As can be seen from a careful analysis of the flow charts shown in FIGS. 1 and 2, there are some redundant parts in the entire post-crash automatic restart process. For example, the mobile terminal has obtained a registration state in a certain serving cell before a crash failure occurs, and network retrieval, cell camping, and applying for cell registration to the network side during the restart process are redundant. In the process of automatic restart after crash, the mobile terminal initiates cell registration to the Network side again through the baseband processor, on one hand, air interface (air interface) signaling is added, and on the other hand, some repeated operations, such as text release and redistribution, between Network Elements (NE) on the Network side can be caused. These redundant operations make the automatic restart procedure after the mobile terminal crashes take a long time.
Disclosure of Invention
The technical problem to be solved by the application is to provide a crash fault recovery method for a mobile terminal, which can perform restart recovery in a short time and seamlessly connect with a service before a crash fault. Therefore, the application also provides a corresponding mobile terminal.
In order to solve the technical problem, the application discloses a crash fault recovery method of a mobile terminal, which comprises the following steps. Step S310: when the baseband processor detects that the baseband processor has a crash fault, the current effective information of the EMM module, the ESM module and the RRC module is stored in the nonvolatile memory, and then the baseband processor sends an abnormal indication to the application processor. Step S320: and after receiving the abnormal indication, the application processor firstly powers off the baseband processor, then powers on the baseband processor, reloads the baseband processor and then sends a hot start instruction to the baseband processor. Step S330: after receiving the hot start instruction, the baseband processor reads files and initializes the module; the file reading comprises reading out the valid information saved before from the nonvolatile memory; the module initialization comprises the step of applying the read effective information to the initialization process of each module to restore each module to the state before the occurrence of the crash fault. Step S340: the baseband processor detects whether the registered state stored for the EMM module is an idle state or a service state when the mobile terminal is in a crash fault, and also detects whether the current service cell is changed compared with the service cell before the crash fault occurs to the mobile terminal. If it is a traffic state and there is a change, the process proceeds to step S350. If it is a traffic state and there is no change, the process proceeds to step S360. If the state is idle and there is a change, the process proceeds to step S370. If the state is idle and there is no change, the process proceeds to step S380. Step S350: the baseband processor sends a tracking area updating request to the mobile communication network and informs the network side not to release RRC connection after the tracking area updating is finished; updating a tracking area between the baseband processor and the network side until the tracking area is updated, and keeping RRC connection between the network side and the mobile terminal; the baseband processor then reports completion of the warm boot to the application processor; and then the baseband processor sends a service request which is the same as the service performed before the crash fault to the mobile communication network, and the baseband processor and the network side perform bearing resource allocation. Step S360: the baseband processor reports completion of the warm boot to the application processor; and then the baseband processor sends a service request which is the same as the service performed before the crash fault to the mobile communication network, and the baseband processor and the network side perform bearing resource allocation. Step S370: the baseband processor sends a tracking area updating request to the mobile communication network; updating a tracking area between the baseband processor and the network side until the updating is finished; then the network side releases the RRC connection with the mobile terminal; the baseband processor then reports the warm boot completion to the application processor. Step S380: the baseband processor reports the completion of the warm boot to the application processor.
According to the crash fault recovery method of the mobile terminal, the effective information of each module is extracted and stored, so that the mobile terminal is quickly recovered to the normal state before the crash fault occurs after being restarted, and is in seamless connection with the service before the crash fault occurs, the perception of a user on the crash fault is greatly reduced, and the network load is reduced to a certain extent.
Further, in step S310, the valid information of each module refers to necessary information required when the mobile terminal restarts to perform state recovery, and specifically includes: cell information, registration state and security mode information are stored for the EMM module; public data network information is stored for the ESM module; and storing frequency point information, wireless resource configuration information, security mode information and system information for the RRC module. This is an exemplary preferred implementation.
Further, in step S320, powering down the baseband processor first and then powering up the baseband processor is regarded as the mobile terminal is restarted. This is an exemplary preferred implementation.
Further, in step S350, the time point when the baseband processor reports completion of the warm boot to the application processor is changed to be after bearer resource allocation is performed between the baseband processor and the network side. This is a variant implementation.
Further, in step S360, the time point when the baseband processor reports completion of the warm boot to the application processor is changed to be after bearer resource allocation is performed between the baseband processor and the network side. This is a variant implementation.
Further, after the step S350 or the step S360 is completed, the mobile terminal is in the service mode in the registration state, and is recovered to the service performed before the crash failure. This is a detailed description of the state of the mobile terminal after the execution of step S350 or step S360 is completed.
Further, after the step S370 or the step S380 is completed, the mobile terminal is in an idle mode in the registered state, which is equivalent to the mobile terminal being in a standby state. This is a detailed description of the state of the mobile terminal after the execution of step S370 or step S380 is completed.
The application also discloses a mobile terminal which comprises an application processor, a baseband processor and a nonvolatile memory. And the application processor is used for powering off the baseband processor, then powering on the baseband processor, reloading the baseband processor and then sending a hot start instruction to the baseband processor after receiving the abnormal instruction. The baseband processor is used for storing the current effective information of each module into the nonvolatile memory when detecting that the baseband processor has a crash fault, and then sending an abnormal instruction to the application processor; the baseband processor is also used for reading files and initializing modules after receiving the hot start instruction; the file reading comprises reading out the valid information saved before from the nonvolatile memory; the module initialization comprises the step of applying the read effective information to the initialization process of each module to restore each module to the state before the occurrence of the crash fault. The baseband processor is further configured to send a tracking area update request to the mobile communication network when the registration state stored for the EMM module is a service state when the mobile terminal has a crash failure and a current serving cell after warm start changes from a serving cell before the crash failure of the mobile terminal, and notify the network side not to release the RRC connection after the tracking area update is finished; updating a tracking area between the baseband processor and the network side until the tracking area is updated, and keeping RRC connection between the network side and the mobile terminal; the baseband processor then reports completion of the warm boot to the application processor; and then the baseband processor sends a service request which is the same as the service performed before the crash fault to the mobile communication network, and the baseband processor and the network side perform bearing resource allocation. The baseband processor is further configured to report completion of warm start to the application processor when the registration state stored for the EMM module is a service state when the mobile terminal has a crash failure and a current serving cell after warm start is unchanged from a serving cell before the mobile terminal has the crash failure; and then the baseband processor sends a service request which is the same as the service performed before the crash fault to the mobile communication network, and the baseband processor and the network side perform bearing resource allocation. The baseband processor is also used for sending a tracking area updating request to the mobile communication network when the registration state stored for the EMM module is an idle state when the mobile terminal has a crash fault and the current service cell after hot start is changed compared with the service cell before the crash fault of the mobile terminal; updating a tracking area between the baseband processor and the network side until the updating is finished; then the network side releases the RRC connection with the mobile terminal; the baseband processor then reports the warm boot completion to the application processor. The baseband processor is further configured to report completion of warm start to the application processor when the registration state stored for the EMM module is an idle state when the mobile terminal has a crash failure and a current serving cell after warm start is unchanged from a serving cell before the mobile terminal has the crash failure. The nonvolatile memory is used for storing effective information of each module when a crash fault occurs.
The mobile terminal extracts and stores the effective information of each module, so that the mobile terminal can be quickly recovered to a normal state before the occurrence of the crash fault after being restarted, and is in seamless connection with the service before the occurrence of the crash fault, the perception of a user on the crash fault is greatly reduced, and the network load is reduced to a certain extent.
Further, when the registration state stored for the EMM module by the baseband processor is a service state when the mobile terminal has a crash failure and the current serving cell after the warm start is changed from the serving cell before the crash failure of the mobile terminal, the time point at which the baseband processor reports the completion of the warm start to the application processor is changed to a time point after the baseband processor allocates the bearer resource between the baseband processor and the network side. This is a variant implementation.
Further, when the registration state stored for the EMM module by the baseband processor is a service state when the mobile terminal has a crash failure and the current serving cell after the warm start is unchanged from the serving cell before the crash failure of the mobile terminal, the time point at which the baseband processor reports the completion of the warm start to the application processor is changed to a time point after the baseband processor allocates the bearer resource between the baseband processor and the network side. This is a variant implementation.
Furthermore, the nonvolatile memory comprises an independent storage space protected by the memory management module, and a hardware lock is configured to indicate whether the content of the space is valid; the independent storage space is used for storing effective information of each module when the crash fault occurs. This is a preferred implementation.
The technical effect obtained by the application is that when the mobile terminal has a crash fault, the effective information of each module is extracted and stored, so that the mobile terminal does not need to perform the processes of searching, cell residing and cell registering of a mobile communication network after being restarted (namely, a baseband processor is powered off and then powered on), and the stored effective information is utilized to directly recover the mobile terminal to a normal state before the crash fault. This enables the service recovery time of the mobile terminal to be greatly reduced, from tens of seconds to hundreds of milliseconds. The method and the device can also automatically recover the service state after restarting when the mobile terminal has the crash fault, so that the voice call, the data service and the like before the crash fault occurs can be continuously connected in a seamless manner, the perception of the user on the crash fault is greatly reduced, and the network load is reduced to a certain extent.
Drawings
Fig. 1 is a flowchart of an implementation method of automatic restart after crash of an existing mobile terminal.
Fig. 2 is a detailed flowchart of the baseband processor registering a cell in step S160 of fig. 1.
Fig. 3 is a flowchart of a crash failure recovery method for a mobile terminal according to the present application.
Fig. 4 is a schematic structural diagram of a mobile terminal provided in the present application.
The reference numbers in the figures illustrate: 400 is a mobile terminal; 410 is an application processor; 420 is a baseband processor; 430 is a non-volatile memory; 435 are separate storage spaces.
Detailed Description
Referring to fig. 3, the crash fault recovery method for a mobile terminal provided by the present application includes the following steps.
Step S310: when the baseband processor detects that the baseband processor has a crash fault, current valid information of each module (including an EMM module, an ESM module and an RRC module) is stored in a nonvolatile memory such as Flash, and then the baseband processor sends an abnormal indication to the application processor.
The valid information refers to necessary information required when the mobile terminal restarts to perform state recovery, and specifically includes: cell information, registration state and security mode information are stored for the EMM module; storing Public Data Network (PDN) information for an ESM (EPS Session Management) module; and storing frequency point information, wireless resource configuration information, security mode information and system information for the RRC module.
Step S320: after receiving the abnormal indication, the application processor powers off the baseband processor, then powers on the baseband processor, reloads the baseband processor, and then sends a Hot start (Hot Reset) instruction to the baseband processor. In this step, powering down the baseband processor first and then powering up the baseband processor is considered a mobile terminal restart.
Step S330: and after receiving the hot start instruction, the baseband processor initializes modules such as file reading, memory and the like. The file reading includes reading out the previously saved valid information from the non-volatile memory. The module initialization comprises the step of applying the read effective information to the initialization process of each module to restore each module to the state before the occurrence of the crash fault.
Step S340: the baseband processor detects whether the registered state stored for the EMM module is an idle state or a service state when the mobile terminal is in a crash fault, and also detects whether the current service cell is changed compared with the service cell before the crash fault occurs to the mobile terminal.
If it is a traffic state and there is a change, the process proceeds to step S350.
If it is a traffic state and there is no change, the process proceeds to step S360.
If the state is idle and there is a change, the process proceeds to step S370.
If the state is idle and there is no change, the process proceeds to step S380.
Step S350: the baseband processor sends a Tracking Area Update (TAU) request to the mobile communication network, and informs the network side not to release the RRC connection after the Tracking area update is finished. And updating the tracking area between the baseband processor and the network side until the tracking area is updated, and keeping the RRC connection between the network side and the mobile terminal. The baseband processor then reports the warm boot completion to the application processor. Then the baseband processor sends a Service Request (Service Request) to the mobile communication network, wherein the Service Request is the same as the Service performed before the crash failure, and the baseband processor and the network side perform bearing resource allocation. At this time, the mobile terminal is in a service mode in a registration state and is restored to a service performed before the crash failure.
It is noted that the tracking area update procedure is not due to a crash failure. In the normal use process of the mobile terminal, a tracking area update process may also occur.
For example, the baseband processor is performing a voice telephone call before a crash failure, and voice telephone data is recovered from valid information stored in the application processor by warm-starting. In order to make the voice telephone proceed, the baseband processor needs to initiate a corresponding service request to the network side to carry a corresponding resource allocation.
Step S360: the baseband processor reports the completion of the warm boot to the application processor. And then the baseband processor sends a service request which is the same as the service performed before the crash fault to the mobile communication network, and the baseband processor and the network side perform bearing resource allocation. At this time, the mobile terminal is in a service mode in a registration state and is restored to a service performed before the crash failure.
Step S370: the baseband processor sends a tracking area updating request to the mobile communication network. And updating the tracking area between the baseband processor and the network side until the updating is completed. And then the network side releases the RRC connection with the mobile terminal, and the mobile terminal is in an idle state mode in a registration state, which is equivalent to the mobile terminal being in a standby state. The baseband processor then reports the warm boot completion to the application processor.
Step S380: the mobile terminal is in an idle mode in the registered state at this time, which corresponds to the mobile terminal being in a standby state. The baseband processor reports the completion of the warm boot to the application processor.
It should be noted that, in the steps S350 and S370, the tracking area update procedure is not caused by a crash failure. In the normal use process of the mobile terminal, a tracking area update process may also occur.
Optionally, in step S350, the baseband processor reports to the application processor that the timing of completion of the warm boot is changed; instead, when the mobile terminal is in a service mode in a registration state and recovers to a service performed before the crash failure, the baseband processor reports completion of the warm start to the application processor.
Optionally, in step S360, the baseband processor reports to the application processor that the timing of completion of the warm boot is changed; instead, when the mobile terminal is in a service mode in a registration state and recovers to a service performed before the crash failure, the baseband processor reports completion of the warm start to the application processor.
Referring to fig. 4, the present application further provides a mobile terminal corresponding to the crash fault recovery method of the mobile terminal shown in fig. 3. The mobile terminal 400 includes an application processor 410, a baseband processor 420, and a non-volatile memory 430.
The application processor 410 is configured to power down the baseband processor 420, then power up the baseband processor 420, reload the baseband processor 420, and then issue a warm boot instruction to the baseband processor after receiving the exception indication.
The baseband processor 420 is configured to, when a crash failure is detected, store current valid information of each module in the non-volatile memory 430, and then the baseband processor 420 issues an exception indication to the application processor 410. The baseband processor 420 is further configured to perform initialization of modules such as file reading and memory after receiving the warm start instruction. The file read includes reading out the previously saved valid information from the non-volatile memory 430. The module initialization comprises the step of applying the read effective information to the initialization process of each module to restore each module to the state before the occurrence of the crash fault.
The baseband processor 420 is further configured to send a tracking area update request to the mobile communication network when the registration state stored for the EMM module is a service state when the mobile terminal has a crash failure and the current serving cell after warm start changes from the serving cell before the crash failure of the mobile terminal, and notify the network side not to release the RRC connection after the tracking area update is completed. The base band processor 420 updates the tracking area with the network side until the completion, and the network side maintains the RRC connection with the mobile terminal. The baseband processor 420 then reports the warm boot completion to the application processor 410. Then the baseband processor 420 sends a service request to the mobile communication network, the service request being the same as the service request performed before the crash failure, and bearer resource allocation is performed between the baseband processor 420 and the network side. At this time, the mobile terminal is in a service mode in a registration state and is restored to a service performed before the crash failure. Alternatively, in this case, the time point at which the baseband processor 420 reports completion of the warm boot to the application processor 410 is changed to be after bearer resource allocation between the baseband processor 420 and the network side.
The baseband processor 420 is further configured to report completion of warm start to the application processor 410 when the registration state stored for the EMM module is a service state when the mobile terminal has a crash failure and a current serving cell after warm start is unchanged from a serving cell before the mobile terminal has the crash failure. Then the baseband processor 420 sends a service request to the mobile communication network, the service request being the same as the service request performed before the crash failure, and bearer resource allocation is performed between the baseband processor 420 and the network side. At this time, the mobile terminal is in a service mode in a registration state and is restored to a service performed before the crash failure. Alternatively, in this case, the time point at which the baseband processor 420 reports completion of the warm boot to the application processor 410 is changed to be after bearer resource allocation between the baseband processor 420 and the network side.
The baseband processor 420 is further configured to send a tracking area update request to the mobile communication network when the registration state stored for the EMM module is an idle state when the mobile terminal has a crash failure and the current serving cell after warm start changes from the serving cell before the crash failure of the mobile terminal. The tracking area update between the baseband processor 420 and the network side is performed until completion. And then the network side releases the RRC connection with the mobile terminal, and the mobile terminal is in an idle state mode in a registration state, which is equivalent to the mobile terminal being in a standby state. The baseband processor 420 then reports the warm boot completion to the application processor 410.
The baseband processor 420 is further configured to, when the registration state stored for the EMM module is an idle state when the mobile terminal has a crash failure, and when the current serving cell after warm start is unchanged from the serving cell before the crash failure occurs in the mobile terminal, the mobile terminal is in an idle state mode in the registration state, which is equivalent to the mobile terminal being in a standby state; the completion of the warm boot is reported to the application processor 410.
The non-volatile memory 430 contains a separate memory space 435 protected by the memory management module, and a hardware lock is configured to indicate whether the contents of this block of space are valid. The independent storage space 435 is used to store valid information of each module when a crash failure occurs.
The mobile terminal and the crash fault recovery method thereof have the following beneficial effects.
Firstly, when the mobile terminal has a crash fault, the effective information of each module is extracted and stored, so that the mobile terminal does not need to perform the processes of searching, cell residing and cell registering of a mobile communication network after being restarted (namely, the baseband processor is powered off and then powered on), and the stored effective information is utilized to directly recover the mobile terminal to a normal state before the crash fault. This enables the service recovery time of the mobile terminal to be greatly reduced, from tens of seconds to hundreds of milliseconds.
The method and the device are specifically realized based on the NarrowBand Internet of things (NB-IoT, NarrowBand IoT) terminal, and the test result shows that when the NarrowBand IoT terminal is in crash failure, the hot start mode can be directly recovered to a normal service state within a short time (about 500 ms), and compared with the existing automatic restart mode after crash, the method and the device are greatly improved.
Secondly, the mobile terminal can automatically recover the service state by utilizing the effective information stored by each module when the crash fault occurs, so that the voice call, the data service and the like before the crash fault occurs are continuously connected in a seamless manner, the perception of the user to the crash fault is greatly reduced, and the network load is reduced to a certain extent.
The above are merely preferred embodiments of the present application and are not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims (11)
1. A crash fault recovery method of a mobile terminal is characterized by comprising the following steps:
step S310: when the baseband processor detects that the baseband processor has a crash fault, the current effective information of the EMM module, the ESM module and the RRC module is stored in a nonvolatile memory, and then the baseband processor sends an abnormal indication to the application processor;
step S320: after receiving the abnormal indication, the application processor firstly powers off the baseband processor, then powers on the baseband processor, reloads the baseband processor and then sends a hot start instruction to the baseband processor;
step S330: after receiving the hot start instruction, the baseband processor reads files and initializes the module; the file reading comprises reading out the valid information saved before from the nonvolatile memory; the module initialization comprises the step of applying the read effective information to the initialization process of each module to restore each module to the state before the occurrence of the crash fault;
step S340: the base band processor detects whether the registered state stored for the EMM module is an idle state or a service state when the mobile terminal is in a crash fault, and also detects whether the current service cell is changed compared with the service cell before the crash fault occurs to the mobile terminal;
if the status is a service status and there is a change, step S350 is entered;
if the service state is the service state and there is no change, step S360 is entered;
if the state is idle and there is a change, go to step S370;
if the state is idle and there is no change, go to step S380;
step S350: the baseband processor sends a tracking area updating request to the mobile communication network and informs the network side not to release RRC connection after the tracking area updating is finished; updating a tracking area between the baseband processor and the network side until the tracking area is updated, and keeping RRC connection between the network side and the mobile terminal; the baseband processor then reports completion of the warm boot to the application processor; then the baseband processor sends a service request which is the same as the service performed before the crash fault to the mobile communication network, and the load-bearing resource allocation is performed between the baseband processor and the network side;
step S360: the baseband processor reports completion of the warm boot to the application processor; then the baseband processor sends a service request which is the same as the service performed before the crash fault to the mobile communication network, and the load-bearing resource allocation is performed between the baseband processor and the network side;
step S370: the baseband processor sends a tracking area updating request to the mobile communication network; updating a tracking area between the baseband processor and the network side until the updating is finished; then the network side releases the RRC connection with the mobile terminal; the baseband processor then reports completion of the warm boot to the application processor;
step S380: the baseband processor reports the completion of the warm boot to the application processor.
2. The method as claimed in claim 1, wherein in step S310, the valid information of each module is necessary information required when the mobile terminal restarts to perform state recovery, and specifically includes: cell information, registration state and security mode information are stored for the EMM module; public data network information is stored for the ESM module; and storing frequency point information, wireless resource configuration information, security mode information and system information for the RRC module.
3. The method for recovering from a crash failure of a mobile terminal as claimed in claim 1, wherein in step S320, powering down the baseband processor first and then powering up the baseband processor is regarded as a restart of the mobile terminal.
4. The method for recovering from crash failure of a mobile terminal as claimed in claim 1, wherein in step S350, the time point when the baseband processor reports completion of the warm boot to the application processor is changed to a time point after bearer resource allocation is performed between the baseband processor and the network side.
5. The method for recovering from crash failure of a mobile terminal as claimed in claim 1, wherein in said step S360, the time point when the baseband processor reports completion of the warm boot to the application processor is changed to a time point after bearer resource allocation is performed between the baseband processor and the network side.
6. The method as claimed in claim 1, wherein after step S350 or step S360 is completed, the mobile terminal is in a service mode in the registered state and recovers to the service performed before the crash failure.
7. The method as claimed in claim 1, wherein after step S370 or step S380 is completed, the mobile terminal is in an idle mode in the registered state, which is equivalent to the mobile terminal being in a standby state.
8. A mobile terminal is characterized by comprising an application processor, a baseband processor and a nonvolatile memory;
the application processor is used for powering off the baseband processor, then powering on the baseband processor, reloading the baseband processor and then sending a hot start instruction to the baseband processor after receiving the abnormal instruction;
the baseband processor is used for storing the current effective information of each module into the nonvolatile memory when detecting that the baseband processor has a crash fault, and then sending an abnormal instruction to the application processor; the baseband processor is also used for reading files and initializing modules after receiving the hot start instruction; the file reading comprises reading out the valid information saved before from the nonvolatile memory; the module initialization comprises the step of applying the read effective information to the initialization process of each module to restore each module to the state before the occurrence of the crash fault;
the baseband processor is further configured to send a tracking area update request to the mobile communication network when the registration state stored for the EMM module is a service state when the mobile terminal has a crash failure and a current serving cell after warm start changes from a serving cell before the crash failure of the mobile terminal, and notify the network side not to release the RRC connection after the tracking area update is finished; updating a tracking area between the baseband processor and the network side until the tracking area is updated, and keeping RRC connection between the network side and the mobile terminal; the baseband processor then reports completion of the warm boot to the application processor; then the baseband processor sends a service request which is the same as the service performed before the crash fault to the mobile communication network, and the load-bearing resource allocation is performed between the baseband processor and the network side;
the baseband processor is further configured to report completion of warm start to the application processor when the registration state stored for the EMM module is a service state when the mobile terminal has a crash failure and a current serving cell after warm start is unchanged from a serving cell before the mobile terminal has the crash failure; then the baseband processor sends a service request which is the same as the service performed before the crash fault to the mobile communication network, and the load-bearing resource allocation is performed between the baseband processor and the network side;
the baseband processor is also used for sending a tracking area updating request to the mobile communication network when the registration state stored for the EMM module is an idle state when the mobile terminal has a crash fault and the current service cell after hot start is changed compared with the service cell before the crash fault of the mobile terminal; updating a tracking area between the baseband processor and the network side until the updating is finished; then the network side releases the RRC connection with the mobile terminal; the baseband processor then reports completion of the warm boot to the application processor;
the baseband processor is further configured to report hot start completion to the application processor when the registration state stored for the EMM module is an idle state when the mobile terminal has a crash failure and a current serving cell after hot start is unchanged from a serving cell before the mobile terminal has the crash failure;
the nonvolatile memory is used for storing effective information of each module when a crash fault occurs.
9. The mobile terminal of claim 8, wherein the baseband processor changes a time point when the baseband processor reports completion of the warm-boot to the application processor to a point after bearer resource allocation is performed between the baseband processor and the network side when the registration state saved for the EMM module by the baseband processor when the mobile terminal has a crash failure is a traffic state and a current serving cell after the warm-boot is changed from a serving cell before the crash failure of the mobile terminal.
10. The mobile terminal of claim 8, wherein the baseband processor changes a time point when the baseband processor reports completion of the warm start to the application processor to a point after bearer resource allocation is performed between the baseband processor and the network side when the registration state stored for the EMM module when the mobile terminal has a crash failure is a traffic state and a current serving cell after the warm start is unchanged from a serving cell before the crash failure of the mobile terminal.
11. The mobile terminal of claim 8, wherein the non-volatile memory comprises a separate memory space protected by a memory management module, and a hardware lock is configured to indicate whether the contents of the memory space are valid; the independent storage space is used for storing effective information of each module when the crash fault occurs.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911321115.XA CN111212417B (en) | 2019-12-20 | 2019-12-20 | Mobile terminal and crash fault recovery method thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911321115.XA CN111212417B (en) | 2019-12-20 | 2019-12-20 | Mobile terminal and crash fault recovery method thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111212417A true CN111212417A (en) | 2020-05-29 |
| CN111212417B CN111212417B (en) | 2020-10-13 |
Family
ID=70788238
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911321115.XA Active CN111212417B (en) | 2019-12-20 | 2019-12-20 | Mobile terminal and crash fault recovery method thereof |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111212417B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103533665A (en) * | 2013-06-08 | 2014-01-22 | 北京星河亮点技术股份有限公司 | Realization method of LTE terminal comprehensive tester state machine |
| CN104581929A (en) * | 2013-10-16 | 2015-04-29 | 华为终端有限公司 | Network registering method, baseband chip and terminal |
| CN105376773A (en) * | 2015-11-24 | 2016-03-02 | 广东欧珀移动通信有限公司 | Network communication function anomaly processing method, application processor and mobile terminal |
| US20170332431A1 (en) * | 2016-05-12 | 2017-11-16 | Lg Electronics Inc. | Method and apparatus for resuming rrc connection in wireless communication system |
| US20190261270A1 (en) * | 2016-05-23 | 2019-08-22 | Zte Corporation | Method and device for reducing power consumption of terminal, and smart card |
-
2019
- 2019-12-20 CN CN201911321115.XA patent/CN111212417B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103533665A (en) * | 2013-06-08 | 2014-01-22 | 北京星河亮点技术股份有限公司 | Realization method of LTE terminal comprehensive tester state machine |
| CN104581929A (en) * | 2013-10-16 | 2015-04-29 | 华为终端有限公司 | Network registering method, baseband chip and terminal |
| CN105376773A (en) * | 2015-11-24 | 2016-03-02 | 广东欧珀移动通信有限公司 | Network communication function anomaly processing method, application processor and mobile terminal |
| US20170332431A1 (en) * | 2016-05-12 | 2017-11-16 | Lg Electronics Inc. | Method and apparatus for resuming rrc connection in wireless communication system |
| US20190261270A1 (en) * | 2016-05-23 | 2019-08-22 | Zte Corporation | Method and device for reducing power consumption of terminal, and smart card |
Non-Patent Citations (1)
| Title |
|---|
| 3GPP: "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; User Equipment (UE) procedures in idle mode and procedures for cell reselection in connected mode (Release 13)", 《3GPP TS 25.304 V13.0.0》 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111212417B (en) | 2020-10-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108616950B (en) | Mobility management method between wireless access networks, core network equipment and base station | |
| US20130231112A1 (en) | Method for triggering joint registration performed by lte single-card dual-standby multi-mode terminal, and terminal | |
| US20100238799A1 (en) | Method, Apparatus and Computer Program Product For Handover Failure Recovery | |
| US20100120427A1 (en) | Method and system for dual registration processing | |
| EP2106190A1 (en) | A method, system and device for preventing the degradation attack while terminal is moving | |
| CN106454793B (en) | Method for controlling timer in user equipment | |
| CN101778371A (en) | Paging method and device | |
| WO2019178755A1 (en) | Method for integrity validation, network device, ue, and computer storage medium | |
| CN112806073A (en) | Communication processing method, communication processing device, mobile terminal and storage medium | |
| US10159057B1 (en) | Device, system, and method for persisting network registration rejection causes | |
| CN101848535A (en) | Method for initiating registration to communication network by using terminal and terminal | |
| EP3248435B1 (en) | Method for error handling in a cellular system, network device, user equipment, computer program and computer program product therefore | |
| CN108064463B (en) | CSFB (Circuit switched Fall Back) result detection method and device and storage medium | |
| CN111212417B (en) | Mobile terminal and crash fault recovery method thereof | |
| CN116170869A (en) | Method and apparatus for improving registration failure condition between systems in mobile communication | |
| CN113490274B (en) | Downlink data paging method, SGW, electronic equipment and medium | |
| CN101325738B (en) | Method and apparatus for repairing fault of mobile communication core network register | |
| WO2016074163A1 (en) | Method and device for paging user equipment | |
| CN112423287A (en) | Control method and device for registration network, computer equipment and storage medium | |
| CN108064455B (en) | CSFB (Circuit switched Fall Back) result detection method and device and storage medium | |
| CN108509249B (en) | Virtual system restarting method and equipment | |
| EP3888386B1 (en) | Method and ue for handling ul nas transport message failure in wireless communication network | |
| CN111385795B (en) | Authentication method of user identification card, mobile terminal and computer readable storage medium | |
| CN110856098B (en) | Circuit switched fallback combined location update processing method, system, device and medium | |
| CN114698058A (en) | Network access method, device and terminal |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 201203 No. 399, Keyuan Road, Zhangjiang High-tech Park, Pudong New Area, Shanghai Applicant after: Aojie Technology Co., Ltd Address before: 201203 No. 399, Keyuan Road, Zhangjiang High-tech Park, Pudong New Area, Shanghai Applicant before: Aojie Technology (Shanghai) Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: 201203 Floor 9, building 10, No. 399, Keyuan Road, China (Shanghai) free trade pilot zone, Pudong New Area, Shanghai Applicant after: Aojie Technology Co., Ltd Address before: 201203 No. 399, Keyuan Road, Zhangjiang High-tech Park, Pudong New Area, Shanghai Applicant before: Aojie Technology Co., Ltd |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |