CN108513288A - 一种系统信息更新方法及装置 - Google Patents

Abstract

本发明实施例提供了一种系统信息更新方法及装置，该方法包括：依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令；若是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻，其中，在线用户包括在当前系统更新周期内已接入用户以及当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间新接入用户；依据在线用户的数量，确定在线用户所需释放总时长；在释放在线用户的触发时刻，释放在线用户并禁止新用户接入，以及，在经过释放总时长后，依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。

Description

一种系统信息更新方法及装置

技术领域

本发明实施例涉及通信领域，尤其涉及一种系统信息更新方法及装置。

背景技术

目前，在NB-IoT(Narrowband Internet of Things，窄带物联网)系统中，处于连接态(RRC_CONNECTED)的终端不要求读取系统信息。因此，如果小区系统信息发生了变化，处于连接态的终端不能及时获得更新后的系统信息，但有些系统信息的变化，对于处于RRC_CONNECTED的终端的业务造成较大影响，目前对于系统信息更新的处理大致有如下几种处理方案：

方案一：系统信息更新通过去激活小区来处理，即在修改系统信息配置之前，先去激活小区，修改系统信息相关的信息配置后，再激活小区。系统信息更新过程中，之前处于连接态的终端随小区去激活全部掉线，等小区重新激活后，所有终端重新读取系统信息，有业务需求的终端重新接入系统做业务。

方案二：在修改后的系统信息更新生效点之前，释放所有终端，下一个系统信息周期开始时直接使用最新的系统信息。

方案三：小区系统信息更新过程不对连接态终端做任何处理，如果系统信息的更新导致无法正常业务，由终端自行处理。

但是，现有技术实施方案中存在较为明显的缺陷，例如：

方案一实现简单，但造成的影响很大，在修改系统信息期间去激活小区，造成网络一段时间停止提供服务，终端感知很差，影响网络KPI(Key Performance Indicator，关键绩效指标)。

方案二无需去激活小区，但是释放终端的时间没有与在线终端数相结合，可能存在过早释放了终端导致某些终端多次接入多次释放的情况或者过晚释放终端导致释放前终端产生大量业务传输错误的情况。

方案三系统侧在系统信息更新过程中对连接态终端未做任何处理，如果更新的系统信息严重影响了终端业务，终端只能在长时间业务传输失败后通过重建立过程恢复业务，影响终端感知和网络KPI。

发明内容

本发明实施例提供一种系统信息更新方法，以解决现有技术中的系统信息更新方案不完善，导致用户感知差等问题。

为了解决上述问题，本发明公开了一种系统信息更新方法，应用于基站，所述方法包括：

依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令；

若是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻，其中，在线用户包括在当前系统更新周期内已接入用户以及当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间新接入用户；

依据在线用户的数量，确定在线用户所需释放总时长；

在释放在线用户的触发时刻，释放在线用户并禁止新用户接入，以及，在经过释放总时长后，依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。

在本发明的一个优选的实施例中，依据预定时长内接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令的步骤，具体包括：

将一个或一个以上系统信息更新指令与指令分类列表中的表项进行匹配；

依据匹配结果，判断一个或一个以上系统信息更新指令是否具有预定指令类型。

在本发明的一个优选的实施例中，根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻的步骤，具体包括：

根据终端分布模型，计算已接入用户所需释放时长；以及，

根据已接入用户所需释放时长，确定当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间的允许用户接入时长；

根据业务模型，预估在允许用户接入时长内的新接入用户的数量；

根据所述新接入用户的数量以及所述已接入用户的数量，计算所述在线用户的数量。

在本发明的一个优选的实施例中，在释放在线用户的触发时刻，释放在线用户并禁止新用户接入的步骤之前，具体包括：

在当前系统信息更新周期结束时刻，触发第二定时器，其中，第二定时器的计时时长等于允许用户接入时长；以及，在第二定时器触发期间，允许新用户接入。

在本发明的一个优选的实施例中，方法进一步包括：

在第一定时器结束后，继续接收新系统更新指令，并将新系统更新指令与第三定时器触发期间接收到的系统更新指令合并，其中，第三定时器在释放总时长结束时刻触发。

根据本发明的另一方面，提供了一种系统信息更新装置，应用于基站，所述装置包括：

判断模块，用于依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令；

计算模块，用于若判断模块判断为是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻，其中，在线用户包括在当前系统更新周期内已接入用户以及当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间新接入用户；

确定模块，用于依据在线用户的数量，确定在线用户所需释放总时长；

释放模块，用于在释放在线用户的触发时刻，释放在线用户并禁止新用户接入；

更新模块，用于在经过释放总时长后，依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。

在本发明的一个优选的实施例中，判断模块进一步用于：

将一个或一个以上系统信息更新指令与指令分类列表中的表项进行匹配；

依据匹配结果，判断一个或一个以上系统信息更新指令是否具有预定指令类型。

在本发明的一个优选的实施例中，计算模块进一步用于：

根据终端分布模型，计算已接入用户所需释放时长；以及，

根据已接入用户所需释放时长，确定当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间的允许用户接入时长；

根据业务模型，预估在允许用户接入时长内的新接入用户的数量；

根据所述新接入用户的数量以及所述已接入用户的数量，计算所述在线用户的数量。

在本发明的一个优选的实施例中，装置进一步包括：

触发模块，用于在当前系统信息更新周期结束时刻，触发第二定时器，其中，第二定时器的计时时长等于允许用户接入时长；以及，在第二定时器触发期间，允许新用户接入。

在本发明的一个优选的实施例中，装置进一步包括：

接收模块，用于在第一定时器结束后，继续接收新系统更新指令，并将新系统更新指令与第三定时器触发期间接收到的系统更新指令合并，其中，第三定时器在释放总时长结束时刻触发。

与现有技术相比，本发明中通过依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令；若是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻，其中，在线用户包括在当前系统更新周期内已接入用户以及当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间新接入用户；依据在线用户的数量，确定在线用户所需释放总时长；在释放在线用户的触发时刻，释放在线用户并禁止新用户接入，以及，在经过释放总时长后，依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。从而通过合理规划用户释放触发时间，有效降低释放用户期间对系统服务的影响性，进而显著提升用户感知。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例的一种系统信息更新方法的流程图；

图2是本发明实施例的一种系统信息更新方法的具体步骤流程图；

图3是本发明实施例的一种系统信息更新装置的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

参照图1，示出了本发明实施例的一种系统信息更新方法的流程图，该方法应用于基站，具体可以包括以下步骤：

步骤101，依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令。

具体的，在本发明的实施例中，基站在当前系统信息更新周期内，接收用户输入的系统信息更新指令。具体的，用户可通过OM(Operation and Maintenance，操作和维护)提供的操作界面下发系统参数修改指令，该系统参数修改指令用于指示基站修改一个或一个以上系统参数。OM接收该用户输入的系统信息更新指令，并发送给基站。

在本发明的实施例中，基站在当前系统信息更新周期开始时刻，即触发第一定时器，需要说明的是，第一定时器的计时时长小于一个系统信息更新周期时长，从而预留一定时长以使基站进行释放用户或其他准备工作。

基站统计第一定时器触发期间接收到的一个或一个以上系统信息更新指令，并识别一个或一个以上系统信息更新指令对应的指令类型。随后，基站依据指令类型，判断一个或一个以上系统信息更新指令是否具有预定指令类型。在本发明的实施例中，预定指令类型即为需要释放所有在线用户以更新系统信息的系统更新指令。

步骤102，若是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻，其中，在线用户包括在当前系统更新周期内已接入用户以及当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间新接入用户。

具体的，在本发明的实施例中，若基站判断出存在一个或一个以上系统信息更新指令具有预定指令类型，则基站可根据终端分布模型以及业务模型，计算在线用户数量以及释放在线用户的触发时刻。具体计算方法将在下面的实施例中进行详细阐述。其中，在本发明的实施例中，在线用户包括在当前系统更新周期内已接入用户，以及，当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间的新接入用户。

步骤103，依据在线用户的数量，确定在线用户所需释放总时长。

具体的，在本发明的实施例中，基站可依据在线用户的数量，确定在线用户所需释放总时长。

步骤104，在释放在线用户的触发时刻，释放在线用户并禁止新用户接入，以及，在经过释放总时长后，依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。

具体的，在本发明的实施例中，基站在计算出的释放在线用户的触发时刻，释放所有在线用户，并且，在释放在线用户期间，基站禁止新用户接入。

在本发明的实施例中，从释放在线用户的触发时刻起，经过确定出的在线用户所需释放总时长后，基站依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。

综上所述，本发明中通过依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令；若是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻，其中，在线用户包括在当前系统更新周期内已接入用户以及当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间新接入用户；依据在线用户的数量，确定在线用户所需释放总时长；在释放在线用户的触发时刻，释放在线用户并禁止新用户接入，以及，在经过释放总时长后，依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。从而通过合理规划用户释放触发时间，有效降低释放用户期间对系统服务的影响性，进而显著提升用户感知。

此外，在本发明的一个优选的实施例中，依据预定时长内接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令的步骤，具体包括：

将一个或一个以上系统信息更新指令与指令分类列表中的表项进行匹配；

依据匹配结果，判断一个或一个以上系统信息更新指令是否具有预定指令类型。

在本发明的一个优选的实施例中，根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻的步骤，具体包括：

根据终端分布模型，计算已接入用户所需释放时长；以及，

根据已接入用户所需释放时长，确定当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间的允许用户接入时长；

根据业务模型，预估在允许用户接入时长内的新接入用户的数量；

根据所述新接入用户的数量以及所述已接入用户的数量，计算所述在线用户的数量。

在本发明的一个优选的实施例中，在释放在线用户的触发时刻，释放在线用户并禁止新用户接入的步骤之前，具体包括：

在当前系统信息更新周期结束时刻，触发第二定时器，其中，第二定时器的计时时长等于允许用户接入时长；以及，在第二定时器触发期间，允许新用户接入。

在本发明的一个优选的实施例中，方法进一步包括：

在第一定时器结束后，继续接收新系统更新指令，并将新系统更新指令与第三定时器触发期间接收到的系统更新指令合并，其中，第三定时器在释放总时长结束时刻触发。

为了使本领域技术人员更好的理解本发明的系统信息更新方法，下面以具体实施例进行详细阐述。

参照图2，示出了本发明实施例的一种系统信息更新方法的具体步骤流程图，具体可以包括以下步骤：

步骤201，依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令。

具体的，步骤201包括：

子步骤2011，将一个或一个以上系统信息更新指令与指令分类列表中的表项进行匹配。具体的，在本发明的实施例中，基站将一个或一个以上系统信息更新指令与指令分类列表中的表项进行匹配。指令分类列表如表1所示。

表1

步骤2012：依据匹配结果，判断一个或一个以上系统信息更新指令是否具有预定指令类型。具体的，在本发明的实施例中，如表1所示，存在4种类型的系统信息更新指令，其中，第三类，即支持动态修改且需要特殊处理类的系统信息更新指令，需要释放所有连接态用户，才能进行系统信息更新。因此，基站将接收到一个或一个以上系统信息更新指令与指令分类列表进行匹配，若一个或一个以上系统信息更新指令与第三类指令类型匹配成功，即可确定存在具有第三类(即本发明实施例中的预定指令类型)指令类型的一个或一个以上系统信息更新指令。

步骤202，根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻。

在本发明的实施例中，步骤202具体包括：

步骤2021，根据终端分布模型，计算已接入用户所需释放时长。

具体的，3GPP协议中规定，NB-IoT的终端分布模型为：95％的UE(User Equipment，用户设备)的MEL(Minimum Coupling Loss，最小耦合损耗)<144dB，99％的UE的MEL<154dB，1％的UE的MEL>154dB。根据业务模型，对三种覆盖等级进行仿真，仿真结果为：

其中，n为用户数量，并且，在仿真过程中，上行子载波间隔取3.75KHz。

由此可得，已接入用户所需释放时长为：t1＝6.18n(ms)。

步骤2022，根据已接入用户所需释放时长，确定当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间的允许用户接入时长。

具体的，在本发明的实施例中，设系统信息更新周期时长为T，若t1<T，则t2＝T-t1；若t1>T，则t2＝T-(t1mod T)。其中，t2为允许用户接入时长。

步骤2023，根据业务模型，预估在允许用户接入时长内的新接入用户的数量。

具体的，3GPP协议中规定，NB-IoT的业务模型中包括两项主要周期业务，分别为：Mobile Autonomous Reporting periodic reports(周期性MAR)和Network Command(网络命令)。其中，周期性MAR和网络命令的业务周期均为：40％的UE一天发送一次数据，40％的UE每2小时发送一次数据，15％的UE每1小时发送一次数据，5％的UE每30分钟发送一次数据。并且，每个小区包括52547个UE。

因此，根据业务模型可计算，每个小区每秒大约有6.8个UE接入该小区进行业务处理。具体计算方法如下：

随后，基站可根据允许用户接入时长以及预估的每秒接入用户个数，计算允许用户接入时长内可接入用户数量，即为6.8*t2。

步骤2024，根据所述新接入用户的数量以及所述已接入用户的数量，计算所述在线用户的数量。

具体的，在本发明的实施例中，基站计算新接入用户的数量与已接入用户的数量之和，即为在线用户的数量，即N＝n+6.8*t2。

步骤203，依据在线用户的数量，确定在线用户所需释放总时长。

具体的，在本发明的实施例中，基站依据计算出的在线用户的数量，确定在线用户所需释放总时长。由上文可知，n个终端的释放时长为6.18n，则，在线用户所需的总释放时长为t＝6.18N。

步骤204，在当前系统信息更新周期结束时刻，触发第二定时器。其中，第二定时器的计时时长等于允许用户接入时长；以及，在第二定时器触发期间，允许新用户接入。

步骤205，在释放在线用户的触发时刻，释放在线用户并禁止新用户接入。

步骤206，经过释放总时长后，依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。

此外，在本发明的实施例中，在第一定时器结束后，基站将继续接收新系统更新指令，并将新系统更新指令与第三定时器触发期间接收到的系统更新指令合并，其中，第三定时器在释放总时长结束时刻触发。

综上所述，本发明实施例中的技术方案，通过合理规划允许用户接入时长、释放用户操作的触发时刻以及释放用户所需时长，从而有效地降低释放用户期间对系统服务质量的影响，有效地提高了用户感知。

参照图3，示出了本发明实施例的一种系统信息更新装置的结构框图，该装置应用于基站，具体可以包括以下模块：

判断模块301，用于依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令。

计算模块302，用于若判断模块判断为是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻，其中，在线用户包括在当前系统更新周期内已接入用户以及当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间新接入用户。

确定模块303，用于依据在线用户的数量，确定在线用户所需释放总时长。

释放模块304，用于在释放在线用户的触发时刻，释放在线用户并禁止新用户接入。

更新模块305，用于在经过释放总时长后，依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。

在本发明的一个优选的实施例中，判断模块301进一步用于：

将一个或一个以上系统信息更新指令与指令分类列表中的表项进行匹配；

依据匹配结果，判断一个或一个以上系统信息更新指令是否具有预定指令类型。

在本发明的一个优选的实施例中，计算模块302进一步用于：

根据终端分布模型，计算已接入用户所需释放时长；以及，

根据已接入用户所需释放时长，确定当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间的允许用户接入时长；

根据业务模型，预估在允许用户接入时长内的新接入用户的数量；

根据所述新接入用户的数量以及所述已接入用户的数量，计算所述在线用户的数量。

在本发明的一个优选的实施例中，装置进一步包括：

触发模块(图中未示出)，用于在当前系统信息更新周期结束时刻，触发第二定时器，其中，第二定时器的计时时长等于允许用户接入时长；以及，在第二定时器触发期间，允许新用户接入。

在本发明的一个优选的实施例中，装置进一步包括：

接收模块(图中未示出)，用于在第一定时器结束后，继续接收新系统更新指令，并将新系统更新指令与第三定时器触发期间接收到的系统更新指令合并，其中，第三定时器在释放总时长结束时刻触发。

综上所述，本发明实施例中的装置，通过依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令；若是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放在线用户的触发时刻，其中，在线用户包括在当前系统更新周期内已接入用户以及当前系统信息更新周期结束时刻至释放在线用户的触发时刻之间新接入用户；依据在线用户的数量，确定在线用户所需释放总时长；在释放在线用户的触发时刻，释放在线用户并禁止新用户接入，以及，在经过释放总时长后，依据具有预定指令类型的系统信息更新指令更新基站自身的系统信息。从而通过合理规划用户释放触发时间，有效降低释放用户期间对系统服务的影响性，进而显著提升用户感知。

对于设备实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本发明实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种系统信息更新方法及装置进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种系统信息更新方法，所述方法应用于基站，其特征在于，所述方法包括：

依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令；

若是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放所述在线用户的触发时刻，其中，所述在线用户包括在当前系统更新周期内已接入用户以及所述当前系统信息更新周期结束时刻至所述释放在线用户的触发时刻之间新接入用户；

依据所述在线用户的数量，确定所述在线用户所需释放总时长；

在所述释放在线用户的触发时刻，释放所述在线用户并禁止新用户接入，以及，在经过所述释放总时长后，依据所述具有预定指令类型的系统信息更新指令更新所述基站自身的系统信息。

2.根据权利要求1所述的方法，其特征在于，所述依据预定时长内接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令的步骤，具体包括：

将所述一个或一个以上系统信息更新指令与指令分类列表中的表项进行匹配；

依据匹配结果，判断所述一个或一个以上系统信息更新指令是否具有预定指令类型。

3.根据权利要求1所述的方法，其特征在于，所述根据终端分布模型以及业务模型计算在线用户的数量以及释放所述在线用户的触发时刻的步骤，具体包括：

根据所述终端分布模型，计算所述已接入用户所需释放时长；以及，

根据所述已接入用户所需释放时长，确定所述当前系统信息更新周期结束时刻至所述释放在线用户的触发时刻之间的允许用户接入时长；

根据所述业务模型，预估在所述允许用户接入时长内的新接入用户的数量；

根据所述新接入用户的数量以及所述已接入用户的数量，计算所述在线用户的数量。

4.根据权利要求3所述的方法，其特征在于，在所述释放在线用户的触发时刻，释放所述在线用户并禁止新用户接入的步骤之前，具体包括：

在所述当前系统信息更新周期结束时刻，触发第二定时器，其中，所述第二定时器的计时时长等于所述允许用户接入时长；以及，在所述第二定时器触发期间，允许新用户接入。

5.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

在所述第一定时器结束后，继续接收新系统更新指令，并将所述新系统更新指令与第三定时器触发期间接收到的系统更新指令合并，其中，所述第三定时器在所述释放总时长结束时刻触发。

6.一种系统信息更新装置，所述装置应用于基站，其特征在于，所述装置包括：

判断模块，用于依据第一定时器触发期间接收到的一个或一个以上系统信息更新指令对应的指令类型，判断是否存在具有预定指令类型的系统信息更新指令；

计算模块，用于若所述判断模块判断为是，则根据终端分布模型以及业务模型计算在线用户的数量以及释放所述在线用户的触发时刻，其中，所述在线用户包括在当前系统更新周期内已接入用户以及所述当前系统信息更新周期结束时刻至所述释放在线用户的触发时刻之间新接入用户；

确定模块，用于依据所述在线用户的数量，确定所述在线用户所需释放总时长；

释放模块，用于在所述释放在线用户的触发时刻，释放所述在线用户并禁止新用户接入；

更新模块，用于在经过所述释放总时长后，依据所述具有预定指令类型的系统信息更新指令更新所述基站自身的系统信息。

7.根据权利要求6所述的装置，其特征在于，所述判断模块进一步用于：

将所述一个或一个以上系统信息更新指令与指令分类列表中的表项进行匹配；

依据匹配结果，判断所述一个或一个以上系统信息更新指令是否具有预定指令类型。

8.根据权利要求6所述的装置，其特征在于，所述计算模块进一步用于：

根据所述终端分布模型，计算所述已接入用户所需释放时长；以及，

根据所述已接入用户所需释放时长，确定所述当前系统信息更新周期结束时刻至所述释放在线用户的触发时刻之间的允许用户接入时长；

根据所述业务模型，预估在所述允许用户接入时长内的新接入用户的数量；

根据所述新接入用户的数量以及所述已接入用户的数量，计算所述在线用户的数量。

9.根据权利要求8所述的装置，其特征在于，所述装置进一步包括：

触发模块，用于在所述当前系统信息更新周期结束时刻，触发第二定时器，其中，所述第二定时器的计时时长等于所述允许用户接入时长；以及，在所述第二定时器触发期间，允许新用户接入。

10.根据权利要求6所述的装置，其特征在于，所述装置进一步包括：

接收模块，用于在所述第一定时器结束后，继续接收新系统更新指令，并将所述新系统更新指令与第三定时器触发期间接收到的系统更新指令合并，其中，所述第三定时器在所述释放总时长结束时刻触发。