专利名称：系统消息更新方法
技术领域：
本发明涉及长期演进(Long Term Evolution,简称为LTE )系 统，具体地，涉及一种系统消息更新方法，用于处于连接状态的不 连续4妄"欠(Discontinuous Receive,筒称为DRX )才莫式下的乡冬端的 系统消息更新处理。
背景技术：
如图1所示，长期演进(Long Term Evolution,简称为LTE) 系统主要由终端、基站、和核心网(Core Network, CN)组成。基 站组成的网全各称为无线4妾入网(Radio Access Network, RAN),负 责接入层事务，例如无线资源的管理等。基站(例如，图1中的基 站1和基站2或基站3 )之间可以4艮据实际情况存在物理或者逻辑 上的连4妾。每个基站可以和一个或者一个以上的核心网节点连4妄。 核心网负责非接入层事务，例如位置更新等。终端是指可以和蜂窝 无线通讯网络进行通讯的各种设备，例如移动电话、个人数字助理、 笔记本电脑等。
在LTE系统中，系统时间的基本单元是无线帧。无线帧的长度 是10ms， 一个无线帧又包4舌10个子帧，每个子帧为lms。
系统消息是用来广播系统配置参数的消息。在LTE中，按照功 能划分，主要有主系统消息块(Master Information Block,简称为 MIB)、调度信息块1 (简称为SU-1)，其他的调度信息块在本文中简称为su-x。每个su-x上可能包括一个或者多个系统信息块
(System Information Block,简一尔为SIB),也;f尤是"i兌，映射到相同 SU-X的SIB在时域上有相同的调度*见4聿。MIB包括部分物理层参 凄史、系统帧号(System Frame Number,简称为SFN)、和SU-1的调 度信息。SU-1包括其他SU-X的调度信息、运营商号码列表(Public Land Mobile Network LIST,简称为PLMN LIST )、小区标识、4妾入 控制参数和系统消息标记(value tag)等等。除了 MIB和SU-1上 的内容发生改变以外，当网络开始广播新的系统消息时，SU-l上的 value tag会发生更#斤。
MIB在系统广4番4言道(Physical Broadcast Channel, PBCH )上 广播，PBCH在时域和频域上的资源配置是静态的。MIB的调度周 期固定，即，其内容每40ms重复一次。MIB总是在所在的无线帧 的0#子帧上。SU-1和SU-X由下行的共享信道来承载。SU-1的调 度周期也固定，即，每80ms调度一次。SU-1占用一个子帧，该子 帧在SU-1所在的无线帧上的位置也固定。在一个子帧上广"f番的系 统消息块承载在系统的无线资源上，无线资源相关的控制参数(例 如，调制和编码参凄t( Modulation and Coding Scheme,简称为MCS )， 传车命4各式等)是由^艮随的专用控制4言道PDCCH ( Physical Downlink Control Channel,物理下4亍控制信道)来^是供的，即，采用了动态 调度的方法。
如图2所示，UE ( User Equipment,用户i殳备)读取系统消息 的顺序是，先读取MIB,然后获得SU-1的调度信息，之后再读取 SU-1的内容。终端可以从SU-1中获得其他SU-X的调度信息，进 而再读取这些系统消息块的内容。
在LTE中，在无线资源控制层(Radio Resource Control, RRC ) 上有两个状态，即，空闲状态(RRC—IDLE )和连4妄a犬态 (RRC—CONNECTED )。当终端处于RRC_IDLE状态时，如果系统消息的内容发生了改 变，则网络会通过寻呼消息通知终端，然后终端被触发重新读取系 统消息的内容。终端在RRC一IDLE状态的时候， 一般不会错过上述 的寻呼消息。网络还会在另外 一 个物理信道上广纟番系统消息改变的 通知消息，用来通知处于RRC—CONNECTED状态的终端。这个通 知消息在时域上会在一定的时间内周期性地进行广播。之后才开始 广4番更杀斤以后的系统消息。在某些情况下，处于RRC—CONNECTED 状态的终端需要读取SU-1上的value tag用来确认系统消息是否发 生了改变，例如，终端在失去网络覆盖以后又重新回到小区的覆盖 范围。
图3示出了上述处理的示意图。其中，图3中所示的系统消息 更新通知消息，对于处于RRC一IDLE状态的终端来说是寻呼消息； 对于处于RRC一CONNECTED状态的终端来说是在PDCCH上发送 的通知消息。
终端处于RRC—CONNECTED状态时，为了节省电池的消侔毛， 有时会处于不连续4妾^: ( Discontinuous Reception,简称为DRX )的 才莫式。如图4所示，DRX才莫式中的终端有规j律地苏醒(正常的苏醒 阶段)，以接收和发送数据包；在其他时间，终端都处于睡眠状态。 目前的LTE系统-见定，处于RRC—CONNECTED状态的终端需要周 期性读取可能的系统消息更新通知，以触发系统消息的更新过程。 对于同时处于DRX模式下的终端来说，如果系统消息更新通知的 发送4几会和睡眠阶_险重叠，那么终端需要额外的苏醒阶,殳读取 PDCCH,然后重新回到睡眠状态，而实际上绝大多凄史情况下，因为 没有通知消息，该过程使得终端白白消耗了电池。
因此，对于处于RRC—CONNECTED状态的DRX才莫式下的终 端而言，需要一种新的系统消息更新才几制，以解决该纟冬端不必要的 苏醒而导致电池损津毛的问题。
发明内容
考虑到相关才支术中存在的处于RRC—CONNECTED状态的 DRX模式下的终端为了接收通知消息而苏醒，而在大多数情况下并 没有通知消息供接收，导致不必要的消耗电池的问题而^是出本发明。 为此，本发明旨在提供一种用于DRX模式下的终端的系统更新消 息处理方法，以减少终端在DRX才莫式下的电池消诔毛。
才艮据本发明，4是供了一种系统更新消息方法，用于处于连接状 态(RRC—CONNECTED )的不连续4妾收(DRX)才莫式下的终端的 系统消息更新处理。在不连续^t妾收才莫式下，终端周期性地处于睡眠 阶段和用于发送和接收数据包的苏醒阶段。
在上述方法中，将不连续接收模式下的终端设置为，在其处于 睡眠阶段的情况下，不接收系统消息更新通知消息(其中，系统侧 在系统消息^修改周期内发送系统消息更新通知消息)。
优选地，在终端在苏醒阶萃殳中没有接收到系统消息更新通知消 息的情况下，终端需要通过读取无线帧的调度信息块1上的系统消 息标记来判断系统消息是否更新。具体地，终端在发起随枳4妄入过 程的同时读取系统消息标记。
进一步优选地，在终端判断系统消息更新的情况下，进一步包 括终端根据调度信息块1上的调度信息判断系统消息块出现的传 專lr时间间隔；终端在传^^时间间隔苏醒，读耳又更新的系统消息。
通过本发明，通过4吏处于RRC一CONNECTED状态的DRX才莫 式下的终端设置为在其处于睡眠阶段的情况下，不接收系统消息更 新通知消息，可以减少电池的损肆毛；并且通过读取SU-1上7>共的 value tag来判断系统消息是否改变，可以确4呆不会漏读系统消息更 新通知。
6本发明的其它特征和优点将在随后的说明书中阐述，并且，部 分地乂人说明书中变得显而易见，或者通过实施本发明而了解。本发 明的目的和其他优点可通过在所写的i兌明书、斥又利要求书、以及附 图中所特别指出的结构来实现和获得。
附图用来^是供对本发明的进一 步理解，并且构成说明书的 一部 分，与本发明的实施例一起用于解释本发明，并不构成对本发明的
限制。在附图中
图1是根据相关技术的LTE架构的示意图2是4艮据相关技术的无线帧的结构示意图3是才艮据相关技术的系统消息更新过程的示意图4是根据相关技术的DRX模式下的终端的系统消息更新过 程的示意图5是根据本发明实施例的系统消息更新方法的实例1的示意
图6是根据本发明实施例的系统消息更新方法的实例2的示意图。
具体实施例方式
如上所述，在LTE系统中，系统消息最快的变化频率是大约每 小时更新一次，而系统消息更新的周期和最长的系统消息块的重复 周期有关，因此不会很长。也就是说，在绝大多数情况下，系统消 息修改周期内没有系统消息更新通知消息。如果终端每次都需要读取通知消息，则首先需要从睡眠状态苏醒，然后尝试读取系统消息 更新通知消息，之后再次进入睡眠状态。如果终端在多数情况下都 重复这个过程，将会显著增加终端电池的消耗。
鉴于上述内容，在本发明实施例中，对于处于
RRC—CONNECTED状态的DRX才莫式中的终端，^f吏其在睡眠阶^殳忽 略系统消息更新通知消息，这样可以大大减少终端电池的消库毛。另 外在需要的时候，通过读取SU-1上公共的value tag来获知系统消 息是否改变，以避免漏读系统消息更新通知。
以下结合附图对本发明的优选实施例进行说明，应当理解，此 处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本 发明。
根据本发明实施例，提供了一种系统更新消息方法，用于连接 状态(RRC—CONNECTED )的不连续4妾收(DRX)才莫式下的终端 的系统消息更新处理。其中，在不连续接收模式下，终端周期性地 处于睡眠阶段和用于发送和接收数据包的苏醒阶段。
在本发明实施例的系统更新消息方法中，将DRX才莫式下的终 端设置为，在其处于睡眠阶段的情况下，不接收系统消息更新通知 消息。
优选地，在终端在苏醒阶^殳中没有4妾收到系统消息更新通知消 息的情况下，当终端需要通过随机接入过程发送緩冲状态报告时， 因为无法确认和随机接入相关的参数是否已经发生了改变，因此在 发起随机接入过程的同时，终端通过读取无线帧的SU-1上公共的 系统消息标i己(value tag)来判断系统消息是否更新。具体地，在终端判断系统消息更新的情况下，进一步包括终 端根据SU-1上的调度信息判断系统消息块出现的传输时间间隔 (TTI);乡冬端在该TTI苏醒，读取更4斤的系统消息。
需要说明的是，如果系统消息发生了更新(例如，与随机接入 有关的参数更新了 )，则可能导致本次发起的随机接入过程失败。在 这种情况下，终端将进入睡眠阶4殳，并在下一次处于苏醒状态时重 新发起随机接入过程。如果系统消息中更新的参数不影响随机接入 过程，则本次发起的随机接入过程可以继续进行。
以下将进一 步结合实例来描述本发明的实施例。
实例1
图5示出了该实例的示意图。在该实例中，系统消息没有改变， 所以在可能的系统消息更新通知的机会上，实际上网络并没有发送 系统消息更新通知消息。将在DRX才莫式的终端i殳置为在睡眠阶4殳 不会醒过来周期性读取通知消息，实际上，这个通知消息在第n个 系统消息修改周期/第(n+l)个系统消息修改周期中并没有发送。
通过对比图4和图5可以发现，图5中减少了额外的苏醒过程， 因此减小了终端电池的消耗。
实例2
图6示出了该实例的示意图。
在该实例中，假设终端DRX的周期是2秒。网络侧4奮改了随 机接入信道参数，即，发生了系统消息更新，并且在第n个系统消 息l奮改周期上在PDCCH信道上发送系统消息更新通知消息。因为 纟冬端在睡眠阶l殳忽略了系统消息更新通知消息，而苏醒阶,殳也和通知消息错开，所以终端错过了在第n个系统消息修改周期内所有的 系统消息更新通知。
在第(n+m)个系统消息修改周期内(m>0)，当终端需要通过 随扭4妄入过程发送緩沖状态才艮告时，因为无法确i人和随机接入相关 的参凌t是否已经发生了改变，因此终端在发起随才几接入过程的同时， 开始读取SU-1上的value tag。结果发现系统消息已经发生了改变， 于是更新系统消息。
在图6中，终端才艮据SU-1上的调度信息，在只有系统消息块 出现的TTI (Transfer Time Interval,传l"时间间隔)苏醒，并且读 取系统消息块。同时随机4妄入过禾呈失败，乡冬端重新回到睡眠阶^殳。
在下一个DRX的苏醒阶萃殳，终端重新发起随枳4妄入过程。因 为更新了随机接入参数，因此终端可以成功接入网络，并且发送了 緩冲状态报告。
如上所述，借助于本发明提供的^支术方案，通过使处于 RRC—CONNECTED状态的DRX才莫式下的终端i殳置为在其处于睡 眠阶段的情况下，不接收系统消息更新通知消息，可以减少电池的 损耗；并且通过读取SU-1上公共的value tag来判断系统消息是否 改变，可以确^呆不会漏读系统消息更新通知。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明， 对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在 本发明的精神和原则之内，所作的任何修改、等同替换、改进等， 均应包含在本发明的保护范围之内。
10
权利要求
1. 一种系统消息更新方法，用于处于连接状态的不连续接收模式下的终端的系统消息更新处理，在所述不连续接收模式下，所述终端周期性地处于睡眠阶段和用于发送和接收数据包的苏醒阶段，其特征在于，在所述方法中将所述不连续接收模式下的终端设置为，在其处于所述睡眠阶段的情况下，不接收系统消息更新通知消息。
2. 4艮据权利要求1所述的方法，其特征在于，在所述终端在所述 苏醒阶段中没有接收到所述系统消息更新通知消息的情况下， 所述终端需要通过读取系统消息的调度信息块1上的系统消 息标记来判断所述系统消息是否更新。
3. 一艮据权利要求2所述的方法，其特征在于，所述终端在发起随 机接入过程的同时读取所述系统消息标记。
4. 根据权利要求2所述的方法，其特征在于，在所述终端判断系 统消息更新的情况下，进一步包纟舌以下处理所述终端根据所述调度信息块1上的调度信息判断系统 消息块出现的传输时间间隔；所述终端在所述传#T时间间隔苏醒，读耳又更新的系统消自
5. 根据权利要求1至4中任一项所述的方法，其特征在于，系统 侧在系统消息4奮改周期内发送所述系统消息更新通知消息。
全文摘要
本发明公开了一种系统消息更新方法，用于处于连接状态(RRC_CONNECTED)的不连续接收(DRX)模式下的终端的系统消息更新处理，在上述方法中，将不连续接收模式下的终端设置为，在其处于睡眠阶段的情况下，不接收系统消息更新通知消息，并且在终端在苏醒阶段中没有接收到系统消息更新通知消息的情况下，当需要发起随机接入过程时，终端通过读取无线帧的调度信息块1上的系统消息标记来判断系统消息是否更新。通过本发明，可以减少电池的损耗，并且可以确保不会漏读系统消息更新通知。
文档编号H04W28/16GK101459935SQ20071019862
公开日2009年6月17日 申请日期2007年12月11日 优先权日2007年12月11日
发明者杜忠达 申请人:中兴通讯股份有限公司