WO2019141194A1

WO2019141194A1 - Method and device for updating system message

Info

Publication number: WO2019141194A1
Application number: PCT/CN2019/072043
Authority: WO
Inventors: 漆方媛
Original assignee: 华为技术有限公司
Priority date: 2018-01-18
Filing date: 2019-01-16
Publication date: 2019-07-25
Also published as: CN110062394B; CN110062394A

Abstract

Disclosed are a method and device for updating a system message, relating to the technical field of communications, for solving the problem of inconsistent system configuration between a terminal and a cell. The method comprises: detecting, under a pre-set scenario, whether a system message has been updated; and if it is detected that the system message has been updated, then acquiring an updated system message, wherein the pre-set scenario comprises at least one of the following: before state switching, an operation flow having failed and a timer having timed out, wherein the timer is used for indicating a cycle of detecting a system message. The present application is applicable for the process of a terminal updating a system message.

Description

Method and device for updating system messages

The present application claims priority to Chinese Patent Application No. 201810050090.3, filed on Jan. 18, 2018, the entire disclosure of which is incorporated herein by reference. .

Technical field

The present application relates to the field of communications technologies, and in particular, to a method and an apparatus for updating a system message.

Background technique

In the mobile communication system, the base station periodically broadcasts a system message to the terminal to notify the terminal of the common channel configuration and neighboring cell messages of the access cell.

When updating the system message, the base station sends a paging message in a System Information Modification Period to inform the terminal that the system message needs to be updated, and broadcasts the updated system message in the next system message modification period. After receiving the paging message, the terminal starts the receiving process of the system message in the next system message modification period, and updates the locally stored system message.

However, in some cases, such as a signal interruption between the terminal and the base station, the terminal inevitably misses receiving the paging message that updates the notification system message. Once the paging message is missed, the terminal is unable to maintain a consistent system configuration with the base station. Even if the content of the system message update is a configuration of a key common channel, the terminal is abnormally uplinked and downlinked, and the service cannot be performed normally.

Summary of the invention

The present application provides a method and apparatus for updating a system message, which is used to solve the problem that the terminal and the cell are not unified in system configuration.

To achieve the above objectives, the present application adopts the following technical solutions:

In a first aspect, the application provides a method for updating a system message, including: detecting, in a preset scenario, whether a system message has been updated. If it is detected that the system message has been updated, the updated system message is obtained. The foregoing preset scenario includes at least one of the following: before state switching, workflow failure, and timer timeout. The timer is used to indicate a period of detecting a system message.

The above method can be performed by a chip in a terminal or a terminal. In this way, even if the terminal misses receiving the paging message for notifying the system update, the terminal can actively detect whether the system message has been updated in various preset scenarios, thereby updating the system message in time, so that the system configuration between the terminal and the cell is performed. Consistent on the top.

Optionally, the state switching includes: switching from an idle state to a connected state, or switching from a connected state to an idle state.

In a possible design, the terminal in the idle state detects whether the system message has been updated before performing random access to switch to the connected state, thereby ensuring that the terminal is consistent with the system configuration in the system before the state switching, thereby making the idle state The terminal can smoothly switch to the connected state.

In a possible design, the connected terminal detects whether the system message has been updated before releasing the RRC connection to switch to the idle state, thereby ensuring that the terminal is consistent with the system configuration in the system before the state switching, thereby making the connection state The terminal can smoothly switch to the idle state.

In a possible design, in order to reduce the unnecessary detection of the system message by the terminal, the terminal acquires the detection duration before the state switching, and the detection duration is the duration between the current time and the time when the system message was last detected. If the detection duration is greater than the preset duration, the terminal detects whether the system message has been updated. If the detection duration is less than the preset duration, the terminal does not need to detect whether the system message has been updated.

Optionally, the workflow failure includes: random access failure or failure to receive downlink data in the connected state.

In a possible design, the terminal detects the signal quality of the terminal accessing the cell after the workflow fails. Then, if the signal quality is greater than the preset value, the terminal detects whether the system message has been updated, so that the terminal and the cell are consistent in system configuration.

In a possible design, the terminal acquires a first system message block in a preset scenario, where the first system message block carries version information, and the version information is used to indicate a version of the system message. Then, the terminal determines whether the version information carried in the first system message block is the same as the locally stored version information. If not, the terminal acquires a second system message block, where the second system message block carries the updated system message. With this implementation, the terminal may detect whether the system message is updated according to the first system message block and further obtain the updated system message according to the second system message block.

In a second aspect, the application provides an apparatus for updating a system message, including: a processing module, configured to detect, in a preset scenario, whether a system message has been updated. The receiving module is configured to obtain the updated system message after the processing module detects that the system message has been updated. The foregoing preset scenario includes at least one of the following: before state switching, workflow failure, and timer timeout. The timer is used to indicate a period of detecting a system message.

In one possible design, the processing module is configured to detect whether the system message has been updated before the switch to the connected state by random access from the idle state.

In one possible design, a processing module is configured to detect whether a system message has been updated before the connection state is released from the connected state by releasing the RRC connection to the idle state.

In a possible design, the processing module is configured to acquire the detection duration before the state switching, where the detection duration is the duration between the current time and the last time the system message is detected; if the detection duration is greater than the preset duration , to detect if the system message has been updated.

In a possible design, the processing module is configured to detect the signal quality of the access cell after the workflow fails; and if the signal quality is greater than the preset value, detect whether the system message has been updated.

In a possible design, the receiving module is configured to obtain a first system message block in a preset scenario, where the first system message block carries version information, and the version information is used to indicate a version of the system message. The processing module is configured to determine whether the version information carried in the first system message block is the same as the locally stored version information. And a receiving module, configured to: after the processing module determines that the version information carried by the first system message block is different from the locally stored version information, acquire the second system message block, where the second system message block carries the updated system message.

In a third aspect, the present application provides an apparatus for updating a system message, including: a memory for storing a program; a processor for executing a program stored by the memory, where the processor is used to execute various aspects or Any of the possible implementations described in the various aspects.

In a fourth aspect, the present application provides a computer readable storage medium having stored therein instructions that, when run on a computer, cause the computer to perform any of the first aspect and the first aspect described above The method of updating system messages as described in the design.

In a fifth aspect, the present application provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the updating of the system message as described in any of the above first aspect and any one of the possible aspects of the first aspect method.

DRAWINGS

1 is a schematic diagram of a process of updating a system message in the prior art;

2 is a network architecture diagram of a communication system according to an embodiment of the present application;

FIG. 3 is a schematic structural diagram of a network device and a terminal according to an embodiment of the present disclosure;

4 is a flowchart 1 of a method for updating a system message according to an embodiment of the present application;

FIG. 5 is a second flowchart of a method for updating a system message according to an embodiment of the present application;

FIG. 6 is a flowchart 3 of a method for updating a system message according to an embodiment of the present application;

FIG. 7 is a flowchart 4 of a method for updating a system message according to an embodiment of the present disclosure;

FIG. 8 is a flowchart 5 of a method for updating a system message according to an embodiment of the present application;

FIG. 9 is a schematic structural diagram of an apparatus for updating a system message according to an embodiment of the present disclosure.

Detailed ways

Currently, in a Long Term Evolution (LTE) system, a base station periodically broadcasts a system message to a terminal, so that the terminal knows the system configuration of the cell. System messages include a Master Information Block (MIB) and a System Information Block (SIB). The SIB can be further subdivided into system message blocks of different numbers such as SIB1, SIB2, and SIB3. The configuration information included in the above MIB and different numbered SIBs is shown in Table 1.

Table I

It should be noted that all the numbered SIBs are not necessarily included in the system information delivered by the base station. For example, for a base station deployed by an operator, since the terminal does not need to know the name of the home eNodeB, the SIB9 is not included in the system message of the cell. For another example, if a cell does not provide multimedia broadcast multicast service, the SIB 13 is not included in the system message of the cell. It can be understood that which SIBs are included in the system message of the cell can be determined according to the actual situation, and the embodiment of the present application does not impose any limitation on this.

SIB1 carries the system message tag value (systemInfoValueTag). The system message tag value represents the version of the system message. The value of systemInfoValueTag is {0, 1, 2, ..., 31}. When the system message changes, the value of systemInfoValueTag will be increased by 1. If the value exceeds 31, it will return to 0 and restart.

SIB1 also includes scheduling information of other SIBs, including scheduling periods, receiving window sizes, and offset parameters of other SIBs. In this way, the terminal detects whether the system message is updated by acquiring the SIB1 and comparing whether the systemInfoValueTag carried in the SIB1 is the same as the locally stored systemInfoValueTag. If the systemInfoValueTag carried in the SIB1 is different from the locally stored systemInfoValueTag, the terminal can determine that the system message has been updated, and the terminal needs to reacquire the system message. When acquiring the updated system message, the UE may determine, according to the scheduling information of other SIBs carried in the SIB1, at which time-frequency locations, the other SIBs are transmitted, and then receive other SIBs to obtain the updated system message.

As shown in FIG. 1, at present, in order to enable a terminal to use the same system message in synchronization with a cell, a system message modification period is specified in the standard. When the system message is updated, the base station notifies the terminal system that the message is about to be updated in the current system message modification period, and then, in the next system message modification period, the base station broadcasts the updated system message. Optionally, the base station notifies the terminal system that the message is about to be updated by a paging message in a paging cycle.

After the terminal successfully camps on the cell, the paging channel is established, so that the paging message sent by the base station can be received. The terminal listens for paging messages at a specific paging moment (Paging Occasion). If a paging message for notifying the system message update is received in a certain system message modification period, the terminal starts to receive the SIB in the next system message modification period. Specifically, the terminal first receives the SIB1, and then checks the systemInfoValueTag carried in the SIB1 and the local device. Whether the stored systemInfoValueTag is consistent. If they are inconsistent, the terminal receives other SIBs according to the scheduling information in the SIB1, so that the terminal completes the update of the system message.

However, in the following cases, the terminal may miss receiving a paging message for notifying the system of the message update:

1. The signal between the terminal and the base station is interrupted due to occlusion and other factors. The signal interruption will cause the terminal to receive no downlink data sent by the base station. Therefore, the terminal may miss receiving the message update for notifying the system during the signal interruption. Paging message. It is worth noting that the 5G network uses high-frequency signals, and the high-frequency signals are more easily blocked by buildings, trees, etc., resulting in more frequent signal interruptions in the terminal, and the probability that the terminal misses receiving the paging message will increase. .

2. Carrier Aggregation (CA) is a combination of two or more Carrier Carriers (CCs) to support a larger transmission bandwidth. When the base station configures a continuous CA for the terminal, the terminal performs bandwidth switching, and there is a reception error of one subframe (1 ms). Therefore, if the terminal receives the paging message for notifying the system message update during this time, the terminal may not be able to parse the paging message due to the error, thereby equivalent to missing the paging message. It is worth noting that in the 5G network, the carrier aggregation technology will be more widely used, so that the above terminal cannot resolve the paging message will occur more frequently.

3. Dual SIM Dual Standby (DSDS) is a low-cost solution widely adopted by terminals. The principle is that the terminal continuously uses two user identification modules through the underlying software and control chip (Subscriber). The Identification Module (SIM) card switches between the two networks. Because the switching time is very short, the two cards are simultaneously connected to the network. Since the terminal is switched between the networks corresponding to the two SIM cards, when one SIM card receives the downlink data, the other SIM card is downlink interrupted. In this way, during the downlink interruption of the SIM card, the SIM card may miss receiving a paging message for notifying the system of the message update.

4. When the terminal has not completed cell camping, the terminal has not configured the paging channel, so if the base station sends a paging message for notifying the system message update in this case, the terminal will miss receiving the paging message.

It can be seen that in the above various cases, the terminal may miss receiving a paging message for notifying the system of the message update. This will result in the terminal not being able to update the system message in time, resulting in the terminal not being able to maintain the same system configuration as the cell.

In order to enable the terminal to obtain the updated system message in time to make the terminal consistent with the cell in the system configuration, the embodiment of the present application provides a method for updating the system message, and the method can be applied to the communication system shown in FIG. 2 .

As shown in FIG. 2, the embodiment of the present application provides a communication system 10, which includes a network device 20 and a terminal 30.

The network device 20 is configured to send a system message to the terminal 30, so that the terminal 30 can perform system configuration according to the system message delivered by the network device 20. The network device 20 may be a base station or a base station controller or the like for wireless communication. For example, the base station may be a Global System for Mobile Communication (GSM) or a Base Transceiver Station (BTS) in Code Division Multiple Access (CDMA), or may be a wideband code division multiple access. The base station (NodeB) in the (Wideband Code Division Multiple Access, WCDMA) may be an evolved base station eNB or an e-NodeB (evolutional Node B) in LTE. Or the eNB in the Internet of Things (IoT) or the Narrow Band-Internet of Things (NB-IoT), which is not specifically limited in this embodiment of the present application. Of course, the network device 20 may also be a device in other networks, such as a network device in a future 5th generation (5G) mobile communication network or a future evolved Public Land Mobile Network (PLMN). The embodiment of the present application does not specifically limit this.

The terminal 30 provides voice and/or data connectivity services for the user, for example, user equipment (UE), access terminal, terminal unit, terminal station, mobile station, mobile station, remote station, remote terminal, mobile device , wireless communication equipment, terminal agents or terminal devices. The access terminal may be a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), with wireless communication. Functional handheld devices, computing devices or other processing devices connected to wireless modems, in-vehicle devices, wearable devices, terminals in future 5G networks or terminals in future evolving public Land Mobile Network (PLMN) networks The embodiment of the present application does not specifically limit this.

FIG. 3 is a schematic structural diagram of hardware of a network device 20 and a terminal 30 according to an embodiment of the present disclosure.

The terminal 30 includes at least one processor 301, at least one memory 302, and at least one transceiver 303. Optionally, the terminal 30 may further include an output device 304 and an input device 305.

The processor 301, the memory 302, and the transceiver 303 are connected by a bus. The processor 301 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more programs for controlling the execution of the program of the present application. integrated circuit. The processor 301 may also include a plurality of CPUs, and the processor 301 may be a single-CPU processor or a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, or processing cores for processing data, such as computer program instructions.

The memory 302 can be a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM), or other type that can store information and instructions. The dynamic storage device can also be an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical disc storage, and a disc storage device. (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store desired program code in the form of instructions or data structures and can be Any other media accessed, but not limited to this. The memory 302 can exist independently and be coupled to the processor 301 via a bus. The memory 302 can also be integrated with the processor 301. The memory 302 is used to store application code for executing the solution of the present application, and is controlled by the processor 301 for execution. The processor 301 is configured to execute the computer program code stored in the memory 302, thereby implementing the method for updating the system message in the embodiment of the present application.

The transceiver 303 can use any device such as a transceiver for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Networks (WLAN), etc. . The transceiver 303 includes a transmitter Tx and a receiver Rx.

Output device 304 is in communication with processor 301 and can display information in a variety of ways. For example, the output device 304 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. Wait. Input device 305 is in communication with processor 301 and can receive user input in a variety of ways. For example, input device 305 can be a mouse, keyboard, touch screen device, or sensing device, and the like.

Network device 20 includes at least one processor 201, at least one memory 202, at least one transceiver 203, and at least one network interface 204. The processor 201, the memory 202, the transceiver 203, and the network interface 204 are connected by a bus. The network interface 204 is configured to connect to a core network device through a link (for example, an S1 interface), or connect to a network interface of other access network devices through a wired or wireless link (for example, an X2 interface) (not shown in the figure) The embodiment of the present application does not specifically limit this. In addition, a description of the processor 201, the memory 202, and the transceiver 203 can be referred to the description of the processor 301, the memory 302, and the transceiver 303 in the terminal 30, and details are not described herein again.

As shown in FIG. 4, the embodiment of the present application provides a method for updating a system message, which is applied to the communication system shown in FIG. 2. The method of updating system messages includes steps 401-402. The above steps 401-42 may be performed by the terminal 30 or by a chip in the terminal 30.

401. Detect whether the system message has been updated in a preset scenario.

The preset scenario includes at least one of the following: before the state switching, the workflow failure, and the timer timeout, where the timer is used to indicate the period of detecting the system message.

In an optional implementation manner, the terminal acquires a first system message block in a preset scenario, where the first system message block carries version information, and the version information is used to indicate a version of the system message. The terminal determines whether the version information carried in the first system message block is the same as the locally stored version information.

Optionally, the first system message block is SIB1. When the first system message block is SIB1, the version information is the field systemInfoValueTag in SIB1.

It can be understood that if the version information carried by the first system message block is the same as the locally stored version information, the system message is not updated, so the terminal does not need to reacquire the system message. If the version information carried by the first system message block is different from the locally stored version information, the system message is updated, so the terminal performs the following step 402.

402. Obtain an updated system message.

In an optional implementation manner, the terminal acquires a second system message block, where the second system message block carries the updated system message. Exemplarily, in conjunction with Table 1, the first system message block is SIB1, and the second system message block is other SIBs than SIB1.

Optionally, in the process of obtaining the updated system message, the terminal immediately uses the configuration information carried by the SIB when acquiring an SIB. For example, the terminal obtains an updated system message before performing random access. After receiving the SIB2, the terminal immediately starts the random access procedure according to the public radio resource configuration and the access information carried by the SIB2.

The foregoing method provided by the embodiment of the present application is specifically described below with reference to different preset scenarios.

1. The preset scene is before the state switching.

The state of the terminal includes an idle state and a connected state. The idle state refers to a state in which the terminal does not establish an RRC connection with any base station. The connected state refers to a state in which the terminal establishes an RRC connection with the base station, and the connected terminal can perform data transmission. Therefore, the above state switching includes: the terminal switches from the idle state to the connected state, or the terminal switches from the connected state to the idle state.

If the terminal wants to switch from the idle state to the connected state, the terminal needs to initiate random access. Random access refers to the process before the terminal sends a random access preamble to try to access the network to establish a basic signaling connection with the network. The random access generally includes the following steps: the terminal sends a random access preamble to the base station, the base station returns a random access response message, and then the terminal sends an RRC connection request, and the terminal establishes an RRC connection with the base station.

Therefore, the method shown in FIG. 4 can be implemented as steps 501-503 in FIG. 5 before the terminal is switched from the idle state to the connected state. The above steps 501-503 may be performed by the terminal 30 or by a chip in the terminal 30.

501. Receive SIB1 from the idle state by random access to switch to the connected state.

Optionally, the idle state terminal receives the SIB1 before transmitting the random access preamble.

502. Check whether the systemInfoValueTag carried in the SIB1 is the same as the locally stored systemInfoValueTag.

If the systemInfoValueTag carried in the SIB1 is different from the locally stored systemInfoValueTag, the system message is updated. Therefore, the terminal performs the following step 503.

503. Receive other SIBs except SIB1.

If the terminal wants to switch from the connected state to the idle state, the terminal needs to release the RRC connection. For example, the RRC layer of the terminal actively releases the RRC connection according to the indication of the Network Attached Storage (NAS) layer, so that the connected terminal switches to the idle state. Therefore, the method shown in FIG. 4 can be implemented as steps 601-603 in FIG. 6 before the terminal is switched from the connected state to the idle state. The above steps 601-603 may be performed by the terminal 30 or by a chip in the terminal 30.

601. Receive SIB1 from the connected state by releasing the RRC connection to switch to the idle state.

602. Check whether the systemInfoValueTag carried in the SIB1 is the same as the locally stored systemInfoValueTag.

If the systemInfoValueTag carried in the SIB1 is different from the locally stored systemInfoValueTag, the system message is updated. Therefore, the terminal performs the following step 603.

603. Receive other SIBs except SIB1.

It can be understood that the terminal detects whether the system message is updated before the state is switched, so that the terminal can be unified with the system configuration of the cell when the state is switched, thereby avoiding the terminal state switching failure.

In addition, if the time interval between the current time and the time when the system message was last detected is short, the possibility that the system message is updated during this short time interval is small. In this case, the terminal may not detect whether the system message has been updated to reduce unnecessary detection of the system message by the terminal. Therefore, the method shown in FIG. 4 can also be implemented as steps 701-705 in FIG. The above steps 701-705 can be performed by the terminal 30 or by the chip in the terminal 30.

701. Obtain a detection duration before the state is switched.

The detection duration is the duration between the current time and the time when the system message was last detected.

702. Determine whether the detection duration is greater than a preset duration.

If the detection duration is less than or equal to the preset duration, the terminal directly performs state switching without detecting whether the system message has been updated. If the detection duration is greater than the preset duration, the terminal performs the following step 703.

703. Receive SIB1.

704. Check whether the systemInfoValueTag carried in the SIB1 is the same as the locally stored systemInfoValueTag.

If the systemInfoValueTag carried in the SIB1 is different from the locally stored systemInfoValueTag, the system message is updated. Therefore, the terminal performs the following step 705.

705. Receive other SIBs except SIB1.

2. The preset scenario is a workflow failure.

Optionally, the workflow failure includes: random access failure or failure to receive downlink data in the connected state. The terminal random access failure includes: the terminal does not receive the random access response message, or the random access response message received by the terminal is abnormal. The failure of the terminal to receive downlink data in the connected state includes: the terminal in the connected state does not receive the downlink data within a certain length of time during the execution of the service.

It can be understood that the workflow failure may be caused by the inconsistency of the terminal and the cell in the system configuration. Therefore, after the workflow fails, the terminal detects whether the system message has been updated and updates the system message in time to keep the configuration of the terminal and the cell consistent. Therefore, the method illustrated in FIG. 4 can be implemented as steps 801-805 in FIG. The above steps 801-805 may be performed by the terminal 30 or by a chip in the terminal 30.

801. Detect the signal quality of the access cell after the workflow fails.

Considering that the signal quality of the cell accessed by the terminal is poor, the working process of the terminal may fail. Therefore, in order to reduce unnecessary detection of the system message by the terminal, the terminal performs step 801 and step 802 to detect terminal access. The signal quality of the cell. Of course, the terminal may directly perform the following step 803 after the workflow fails.

802. Detect whether a signal quality of the access cell is greater than a preset value.

If the signal quality of the access cell is less than or equal to the preset value, the terminal workflow failure is likely to be caused by poor signal quality, and not because the terminal and the cell are not unified in system configuration, so the terminal may not detect the system message. Has it been updated?

If the signal quality of the access cell is greater than the preset value, the signal quality of the access cell is good. Therefore, the failure of the terminal workflow is not caused by poor signal quality, but may be caused by the inconsistency between the terminal and the cell in system configuration. . In this case, the terminal performs the following step 803.

803. Receive SIB1.

804. Check whether the systemInfoValueTag carried in the SIB1 is the same as the locally stored systemInfoValueTag.

If the systemInfoValueTag carried in the SIB1 is different from the locally stored systemInfoValueTag, the system message is updated. Therefore, the terminal performs the following step 805.

805. Receive other SIBs except SIB1.

3. The preset scenario is that the timer expires.

Optionally, the terminal is configured with a timer for indicating a message period of the detection system, so that after the timer expires, the terminal detects whether the system message has been updated. It should be noted that the timer is automatically reset after the timeout, so that the terminal periodically detects whether the system message has been updated, so that the terminal can keep the system configuration consistent with the cell.

In addition, frequent detection of system messages by the terminal increases the power consumption of the terminal. Therefore, the terminal can set the period of detecting the system message to be moderate, and reduce the frequency of the terminal detecting the system message while ensuring that the terminal timely updates the system message.

Optionally, the foregoing three preset scenarios can be combined with each other.

For example, the terminal is provided with a timer indicating the detection of the system message period. Before the timer expires, the terminal prepares to switch the state. At this time, the terminal can refer to the method shown in FIG. 7. Optionally, after the terminal detects whether the system message is updated, the terminal resets the timer.

For another example, the terminal is provided with a timer indicating the detection of the system message period, and the terminal's workflow fails before the timer expires. In this case, the terminal immediately detects whether the system message has been updated. Optionally, after the terminal detects whether the system message is updated, the terminal resets the timer.

The solution provided by the embodiment of the present application is mainly introduced from the perspective of the terminal. It can be understood that, in order to implement the above functions, the foregoing terminal includes a hardware structure or a software module corresponding to executing each function. Those skilled in the art will readily appreciate that the present application can be implemented in a combination of hardware or hardware and computer software in combination with the elements and algorithm steps of the various examples described in the embodiments disclosed herein. Whether a function is implemented in hardware or computer software to drive hardware depends on the specific application and design constraints of the solution. A person skilled in the art can use different methods to implement the described functions for each particular application, but such implementation should not be considered to be beyond the scope of the present application.

The embodiment of the present application may divide the function module into the terminal according to the foregoing method example. For example, each function module may be divided according to each function, or two or more functions may be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of the module in the embodiment of the present application is schematic, and is only a logical function division, and the actual implementation may have another division manner.

For example, in the case of dividing each functional module by corresponding functions, FIG. 9 shows a possible structural diagram of the apparatus 900 for updating system messages involved in the above embodiment. The device for updating the system message may be a terminal device, or may be a chip or the like in the terminal device. As shown in FIG. 9, the apparatus 900 for updating a system message includes a processing module 901 and a receiving module 902. The device 900 used by the processing module 901 to support the update system message performs step 401 in FIG. 4, step 502 in FIG. 5, step 602 in FIG. 6, and steps 701, 702, and 704 in FIG.

Steps

801, 802, and 804 in Figure 8, and/or other processes for the techniques described herein. The receiving module 902, the apparatus 900 for supporting the updating system message performs step 402 in FIG. 4, steps 501 and 503 in FIG. 5, steps 601 and 603 in FIG. 6,

steps

703 and 705 in FIG.

Steps

803 and 805 in Figure 8, and/or other processes for the techniques described herein. All the related content of the steps involved in the foregoing method embodiments may be referred to the functional descriptions of the corresponding functional modules, and details are not described herein again.

In the embodiment of the present application, the device is presented in the form of dividing each functional module corresponding to each function, or the device is presented in a form that divides each functional module in an integrated manner. A "module" herein may include an Application-Specific Integrated Circuit (ASIC), a circuit, a processor and memory that executes one or more software or firmware programs, an integrated logic circuit, or other device that can provide the above functions. . In a simple embodiment, those skilled in the art will appreciate that the apparatus 900 for updating system messages can take the form of the terminal 30 shown in FIG. For example, the processing module 901 in FIG. 9 can be implemented by the processor 301 in the terminal 30 of FIG. Specifically, the receiving module 902 can be executed by using the application code stored in the memory 302 by the processor 301, which is not limited in this embodiment.

The device provided by the embodiment of the present application can be used to perform the foregoing method for updating the system message. Therefore, the technical solution can be obtained by referring to the foregoing method embodiment.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using a software program, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with embodiments of the present application are generated in whole or in part. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be from a website site, computer, server or data center Transmission to another website site, computer, server, or data center by wire (eg, coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (eg, infrared, wireless, microwave, etc.). The computer readable storage medium can be any available media that can be accessed by a computer or a data storage device that includes one or more servers, data centers, etc. that can be integrated with the media. The usable medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (such as a Solid State Disk (SSD)) or the like.

The foregoing is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto, and any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application. It should be covered by the scope of protection of this application. Therefore, the scope of protection of the present application should be determined by the scope of the claims.

Claims

A method for updating a system message, the method comprising:

Detect whether the system message has been updated in the preset scenario;

If it is detected that the system message has been updated, the updated system message is obtained;

The preset scenario includes at least one of the following: before state switching, a workflow failure, and a timer timeout, where the timer is used to indicate a period of detecting the system message.
The method of claim 1, wherein the state switching comprises: switching from an idle state to a connected state, or switching from a connected state to an idle state.
The method of claim 2, wherein detecting whether the system message has been updated before switching from the idle state to the connected state comprises:

Whether the system message has been updated is detected from the idle state by random access to switch to the connected state.
The method of claim 2, wherein detecting whether the system message has been updated before switching from the connected state to the idle state comprises:

Detects whether the system message has been updated from the connected state by releasing the RRC connection to switch to the idle state.
The method according to claim 3 or 4, wherein detecting whether the system message has been updated before the state switching comprises:

Obtaining a detection duration before the state switching, where the detection duration is a duration between a current time and a time when the system message was last detected;

If the detection duration is greater than the preset duration, it is detected whether the system message has been updated.
The method according to claim 1, wherein the failure of the workflow comprises: failure of random access or failure to receive downlink data in a connected state.
The method according to claim 6, wherein detecting whether the system message has been updated in a scenario in which the workflow fails includes:

Detecting the signal quality of the access cell after the workflow fails;

If the signal quality of the access cell is greater than a preset value, it is detected whether the system message has been updated.
The method according to any one of claims 1 to 7, wherein the detecting whether the system message has been updated in a preset scenario comprises:

Obtaining a first system message block in a preset scenario, where the first system message block carries version information, where the version information is used to indicate a version of the system message;

Determining whether the version information carried in the first system message block is the same as the locally stored version information;

If the system message is detected to be updated, the updated system message is obtained, including:

If the version information carried by the first system message block is different from the locally stored version information, the second system message block is obtained, and the second system message block carries the updated system message.
An apparatus for updating a system message, comprising:

a processing module, configured to detect, in a preset scenario, whether the system message has been updated;

a receiving module, configured to obtain an updated system message after the processing module detects that the system message has been updated;

The preset scenario includes at least one of the following: before state switching, a workflow failure, and a timer timeout, where the timer is used to indicate a period of detecting a system message.
The apparatus of claim 9, wherein the state switching comprises: switching from an idle state to a connected state, or switching from a connected state to an idle state.
The apparatus according to claim 10, wherein the processing module is configured to detect whether the system message has been updated before the switch to the connected state by random access from the idle state.
The apparatus according to claim 10, wherein the processing module is configured to detect whether the system message has been updated before the connection state is released from the connected state by releasing the RRC connection to the idle state.
The device according to claim 11 or 12, wherein the processing module is configured to acquire a detection duration before the state switching, where the detection duration is a duration between a current time and a time when the system message was last detected; In the case that the detection duration is greater than the preset duration, it is detected whether the system message has been updated.
The apparatus according to claim 9, wherein the workflow failure comprises: random access failure or failure to receive downlink data in a connected state.
The apparatus according to claim 14, wherein the processing module is configured to detect a signal quality of the access cell after the workflow fails; and when the signal quality of the access cell is greater than a preset value, the detection system Whether the message has been updated.
The device according to any one of claims 9 to 15, wherein the receiving module is configured to acquire a first system message block in a preset scenario, where the first system message block carries version information, The version information is used to indicate the version of the system message;

The processing module is configured to determine whether version information carried in the first system message block is the same as locally stored version information;

The receiving module is configured to: after the processing module determines that the version information carried by the first system message block is different from the locally stored version information, acquire the second system message block, where the second system message block carries the updated information System message.
An apparatus for updating a system message, comprising:

Memory for storing programs;

a processor for executing the program stored by the memory, the processor for performing the method of updating a system message according to any one of claims 1-8 when the program is executed.
A computer readable storage medium, wherein the computer readable storage medium stores instructions that, when run on a computer, cause the computer to perform the update of any one of claims 1 to 8 The method of system messages.