CN101902800B - 一种系统信息发送、接收的方法及设备 - Google Patents
一种系统信息发送、接收的方法及设备 Download PDFInfo
- Publication number
- CN101902800B CN101902800B CN 200910246704 CN200910246704A CN101902800B CN 101902800 B CN101902800 B CN 101902800B CN 200910246704 CN200910246704 CN 200910246704 CN 200910246704 A CN200910246704 A CN 200910246704A CN 101902800 B CN101902800 B CN 101902800B
- Authority
- CN
- China
- Prior art keywords
- system information
- beep
- page message
- member carrier
- base station
- 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.)
- Active
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提出了一种系统信息发送的方法，包括以下步骤：基站判断成员载波CC是否需要更新系统信息；当成员载波CC_change需要更新系统信息时，所述基站在CC_change上发送寻呼消息1，通知CC_change所属小区下的终端更新系统信息；所述基站在CC_change所属基站的其他CC上发送寻呼消息2，通知基站下的终端存在CC更新系统信息。其中，寻呼消息1和寻呼消息2为同类型的RRC消息或不同类型的RRC消息。本发明还提出了一种系统信息接收的方法及设备。根据本发明提出的技术方案，解决了系统中终端能够对多个CC实现监听，及时发现系统信息的变化并进行更新的问题。
Description
技术领域
本发明涉及移动通信领域，具体而言，本发明涉及一种系统信息发送、接收的方法及设备。
背景技术
移动和宽带成为现代通信技术的发展方向，3GPP(3rd GenerationPartnership Project，第三代合作伙伴计划)致力于3G系统的演进，目标是发展3GPP无线接入技术向着高数据速率、低延迟和优化分组数据应用方向演进。3GPP在LTE-A(Long Term Evolution-Advanced，长期演进高级)系统中，要求峰值速率比LTE(Long Term Evolution，长期演进)系统有巨大的提高，要求达到下行1Gbps，上行500Mbps。在单个载波上已经无法满足这种需求，因此在LTE-A系统引入CA(Carrier Aggregation，载波聚合)技术，即同一基站下，将连续或不连续的多个载波集中在一起，在需要时多载波同时为终端服务，以提供所需的频率资源，参与CA的各载波称为成员载波(Component Carrier，简称CC)，每个成员载波可能对应于一个可以独立工作的小区，也可能对应于一个不能独立工作的载波资源。为了保证LTE的终端能在每个CC下都能工作，每个CC最大不超过20MHz。LTE-A的CA技术如图1所示，图1中的LTE-A基站聚合了4个载波。基站可以同时在4个载波上和终端进行数据传输，以提高系统吞吐量。在LTE-A系统中，通常一个基站下管辖一个或多个小区(cell)，每个小区可以看成是一个成员载波。
对于LTE-A终端，可以同时看到四个载波，网络可以根据用户业务速率的要求，调度其中一个或者多个载波的资源为该终端服务。对于LTE终端，只会看到存在4个小区，它们彼此之间互为邻小区。为了使LTE终端正常工作，在各CC上需要广播本CC的系统信息。
在LTE系统中，系统信息广播的主要内容包括：
主系统信息块(MIB)，主要参数有：下行带宽，PHICH的配置信息，系统帧号(SFN)；
系统信息块1(SIB1)，主要内容有：与小区接入相关的信息(PLMNID，TAC，小区标识等等)，与小区选择相关的参数，最大发射功率，频段信息，系统信息的调度信息，TDD配置参数，SI窗口长度，systemInfoVal终端Tag等；
系统信息块2(SIB2)，主要内容包括：接入禁止信息，无线资源配置信息，终端定时器以及一些常数信息，频率信息，MBSFN子帧配置信息，同步定时器的信息等；
系统信息块3(SIB3)，主要内容有：小区重选的公共参数，服务频点的小区重选参数，同频小区重选的相关参数等信息；
系统信息块4(SIB4)，主要内容有：同频小区列表，同频黑名单小区列表，CSG小区的物理小区标识以及其范围；
系统信息块5(SIB5)，主要内容有：异频载波信息列表，包括每个载波的频率，重选参数，优先级信息，异频邻小区信息，黑名单等；
系统信息块6(SIB6)，主要内容为用于到UTRA系统小区重选的相关信息，包括：UTRA系统的相关信息，可以包含UTRA FDD载波信息列表，UTRA TDD载波信息列表，重选参数等等；
系统信息块7(SIB7)，主要内容为用于到GERAN系统小区重选的相关信息，包括：GERAN载波信息及其重选参数；
系统信息块8(SIB8)，主要内容为用于到CDMA2000系统小区重选的相关信息，包括：cdma2000系统时间信息，搜索窗大小及小区重选参数；
系统信息块9(SIB9)，只携带home node b的标识信息；
系统信息块10(SIB10)，携带用于预警ETWS的主通知，包括消息标识号，序列号，告警类型，告警安全信息等；
系统信息块11(SIB11)，携带用于预警ETWS的辅助通知，包括消息标识号，序列号，告警消息的分段信息，分段号，段，数据编码方案等。
在上述系统信息中，LTE系统中，RRC_CONNECTED状态的终端要进行数据收发，就必须知道当前小区的MIB，SIB1和SIB2消息。在LTE-A系统中，一个基站下有多个CC，考虑到兼容LTE终端的要求，每个CC上需要广播一套独立的系统信息，且各CC上的系统信息可能会有所不同：如频率信息，PHICH的配置等。因此，LTE-A终端在使用多个CC进行数据传输之前，需要获取各CC上最新的系统信息。
在LTE系统中的载波监听机制为：图2为下行子帧的结构示意图，其中，每个下行子帧由OFDM符号组成，下行子帧的前几个OFDM符号为控制符号，用于承载下行控制信令，承载下行控制信令的信道称为PDCCH信道。其余OFDM符号承载下行数据，承载下行数据的物理层信道称为PDSCH信道。控制信令包括：对本下行子帧以及相应上行子帧的调度信息以及相关HARQ信息等。终端通过接收下行子帧的控制信令确定在对应子帧是否分配了资源。如果分配了资源，终端根据调度信令的指示获得资源的时间频率位置，并进行数据收发。在LTE系统中，每个小区只有一个下行载波，故终端只需要监听一个下行载波上的PDCCH和PDSCH。
在LTE-A系统中引入了CA技术，一个基站可能配置了多个CC，例如N个。LTE-A的终端可能同时使用M个CC进行数据传输，其中M小于等于N。当LTE-A终端收发的数据量比较大时，需要同时在多CC上进行数据传输。此时终端同时监听多个CC上的PDCCH和PDSCH。当终端数据量不大的情况下，同时监听多个CC就没有太多的必要了。停止对不使用的CC的接收和解码，将有利于终端节电。为了方便下文的描述，将终端进行接收和解码的CC或CC组定义为Anchor CC。
因此，在LTE-A系统中的载波监听机制为：通常情况下，终端监听Anchor CC上的PDCCH和PDSCH；当有大量数据需要收发时，网络通过终端正在监听的CC向终端发送控制信令，要求终端增加监听的CC的数量；终端收到上述信令后，启动对应CC的监听；网络和终端在多个CC上进行通信。
终端在CC上进行数据收发有一个前提条件：终端需要知道该CC的最新的系统信息。但是每个CC只会广播本CC对应的系统信息，UE在收到网络发送的激活CC监听的控制信令前，只会监听Anchor CC。这就导致了UE在收到激活CC监听的控制信令时，可能不知道被激活的CC的最新的系统信息。
如果终端在收到CC激活信令后，才开始接收对应CC上的系统信息，则在完成系统信息接收前，终端不能在该CC上收发数据。系统信息的发送是周期性的，MIB和各SIB的发送周期从几十到几百毫秒不等。也就是说，在终端收到CC激活信令后，可能需要经过几十甚至上百毫秒的系统信息读取过程之后，才能在对应CC上进行数据收发。可见，如果终端在收到CC激活信令后，才开始接收对应CC上的系统信息，将引入较大的时延，为了解决这一问题，在LTE-A系统中，引入了下面的系统信息监听机制。
LTE-A系统中的系统信息监听机制为：在LTE-A系统中引入了CA技术，LTE-A的终端为了能在多个CC上快速数据收发，需要在接入LTE-A小区或切换到新的LTE-A小区后，立即读取相关CC上的系统信息。并在各CC上发生系统信息变更后，重新读取该CC上的系统信息。该机制要求LTE-A的终端能及时获得当前基站的各CC上的系统信息变更通知。
当终端同时在M个CC上与基站进行通信时，需要同时维护这些CC上的最新系统信息，如果一直同时监听所有CC的系统信息，对UE来说也没有必要，不利于终端节电。
LTE系统中的系统信息变更的通知机制为：除了ETWS(Earthquake andTsunami Warning System，地震与海啸预警系统)消息外，系统信息的变更只能在特定的无线帧发生，由修改周期(modification period)确定。在一个修改周期内，系统信息可能会发送多次，多次发送的系统信息内容相同。系统信息只能在修改周期的边界之后发生变化，修改周期的边界定义如下：SFN mod m＝0。其中，SFN为系统帧号，m为修改周期，单位为无线帧。
当网络需要变更全部或部分系统信息时，其首先需要向终端发送“系统信息变更指示”，通知终端将发生的系统信息变化，通知过程可能需要持续一个修改周期。在下一个修改周期，网络就可以发送更新后的系统信息了。上述规则如图3所示，为系统信息变更示意图。在收到系统信息变更指示后，终端立即在下一个修改周期的开始处读取更新后的系统信息。在终端获取新的系统之前，终端继续使用旧的系统信息。
网络使用寻呼消息来向处于RRC_IDLE和RRC_CONNECTED状态的终端发送“系统信息变更指示”。如果终端收到了包含“systemInfoModification”的寻呼消息，就知道系统信息会在下一个修改周期的边界处发生变化。“系统信息变更指示”只会通知终端系统信息将发生变化，不会向终端指示哪一个或哪些系统信息将发生变化。
某些系统信息的变更不会触发包含“systemInfoModification”的寻呼消息的发送，如ETWS的变更。终端可以通过以下方法确定所存的系统信息是否有效，在没有收到systemInfoModification指示的情况下，终端需要在一个修改周期内，至少读取modificationPeriodCoeff次寻呼消息，以期找到systemInfoModification指示。
如果没有读到寻呼消息，终端认为系统信息在下一个修改周期内将不会发生变化。如果终端读取到包含systemInfoModification指示的寻呼消息，就认为系统信息将在下一个修改周期内发生变化。systemInfoModification的引入可以避免终端频繁的读取系统信息，降低终端的功耗。
此外，LTE系统使用寻呼过程来触发被叫业务和通知终端系统信息即将发生变化。寻呼消息通过P-RNTI进行调度。网络中的终端在特定的时刻对PDCCH信道进行解码，获取寻呼消息。目前P-RNTI对应的PDCCH DCI格式是format 1a和format 1c。DCI是指下行控制信息(Downlink ControlInformation)。
如上所述，在上述技术方案下，LTE-A的终端无法及时获得当前为其提供服务的各CC的系统信息变更通知。当某个服务CC，下称该CC为CC_change，其系统信息发生变化时，用于通知终端系统信息变更的寻呼消息只会在CC_change上发送。如果LTE-A终端同时监听所有CC的系统信息变更通知，将对节省电量不利，因此，终端可能选择只监听某个CC(Anchor CC)的系统信息变更通知，如果该Anchor CC不是CC_change，终端将无法知道有CC的系统信息发生变化，进而导致终端保存的CC_change的系统信息不是最新的。当网络需要激活该终端在CC_change上的数据收发时，终端使用已经无效的CC配置信息，将导致数据传输发生错误。
因此有必要提出相应的技术方案，解决系统中终端能够对多个CC实现监听，及时发现系统信息的变化并进行更新的问题。
发明内容
本发明的目的旨在至少解决上述技术缺陷之一，特别是解决系统中终端能够对多个CC实现监听，及时发现系统信息的变化并进行更新的问题。
为了达到上述目的，本发明一方面提出了一种系统信息发送的方法，包括以下步骤：基站判断成员载波CC是否需要更新系统信息；当成员载波CC_change需要更新系统信息时，基站在CC_change上发送寻呼消息1，通知CC_change所属小区下的终端更新系统信息；基站在CC_change所属基站的其他CC上发送寻呼消息2，通知基站下的终端存在CC更新系统信息。
本发明另一方面还提出了一种基站设备，包括判断模块以及发送模块，判断模块用于判断成员载波CC是否需要更新系统信息；当判断模块判断成员载波CC_change需要更新系统信息时，发送模块用于在CC_change上发送寻呼消息1，通知CC_change所属小区下的终端更新系统信息以及在CC_change所属基站的其他CC上发送寻呼消息2，通知基站下的终端存在CC更新系统信息。
本发明另一方面还提出了一种系统信息接收的方法，包括以下步骤：端在当前监听的一个或多个成员载波CC读取寻呼消息；当终端收到寻呼消息2，寻呼消息2指示存在CC更新系统信息时，终端在下一个BCCH广播信道修改周期的起始位置，对未监听的CC进行监听并读取系统信息；终端完成对系统信息读取之后，保存系统信息。
本发明另一方面还提出了一种用户设备，包括接收模块、判断模块以及存储模块，接收模块用于监听一个或多个成员载波CC，并读取寻呼消息，根据寻呼消息指示接收系统信息；判断模块用于判断是否收到寻呼消息2，寻呼消息2指示存在CC更新系统信息时，接收模块在下一个BCCH广播信道修改周期的起始位置，对未监听的CC进行监听并读取系统信息；存储模块用于在接收模块完成对系统信息读取之后，保存系统信息。
根据本发明提出的技术方案，解决了系统中终端能够对多个CC实现监听，及时发现系统信息的变化并进行更新的问题。根据本发明提出的技术方案，终端既可以及时发现多个CC系统信息的变化并进行更新，也不会因为更新系统信息而长时间对多个CC进行监听而增大终端的耗电量。此外，本发明提出的技术方案，对现有系统的改动很小，不会影响系统的兼容性，而且实现简单、高效。
本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为根据本发明实施例的采用CA的LTE-A基站的示意图；
图2为根据本发明实施例的下行子帧的结构的示意图；
图3为根据本发明实施例的系统信息变更的示意图；
图4为根据本发明实施例的系统信息发送方法的流程图；
图5为根据本发明实施例的系统信息接收方法的流程图；
图6为根据本发明实施例的用户设备的结构示意图。
具体实施方式
下面详细描述本发明的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。
在LTE-A系统中，通常一个基站下管辖一个或多个小区(cell)，每个小区由一个或多个成员载波构成。在本发明的实施例中，本小区、所属小区以及其他载波通过CC、CC上的信息或消息进行修饰限定，例如，CC或某个系统消息的本小区指的是包括该CC为其成员载波的那个小区或者承载系统消息的载波为其成员载波的那个小区；CC_change所属小区指的是包括CC_change为其成员载波的那个小区，相应地，其他载波指的是该小区中除了CC_change的其他载波；MIB、SIB、IE等信息所属小区指的是包括该承载MIB、SIB、IE等信息的载波为其成员载波的那个小区，相应地，其他载波指的是该小区中除了该承载MIB、SIB、IE等信息的载波的其他载波。
根据本发明的实施例的系统信息发送的方法包括以下步骤：基站判断成员载波CC是否需要更新系统信息；当成员载波CC_change需要更新系统信息时，基站在CC_change上发送寻呼消息1，通知CC_change所属小区下的终端更新系统信息；基站在CC_change所属基站的其他CC上发送寻呼消息2，通知基站下的终端存在CC更新系统信息。
图4为根据本发明实施例的系统信息发送方法的流程图。如图4所示，该方法包括以下步骤：
S101：基站判断成员载波CC是否需要更新系统信息。
在兼容LTE系统的LTE-A系统中，存在两类用户，对于LTE-A终端，例如如图1所示，该终端可以看到该LTE-A小区是由四个载波组成的，网络可以根据用户业务速率的要求，调度其中一个或者多个载波的资源为该终端服务。对于LTE终端，只会看到存在4个小区，它们彼此之间互为邻小区。因此，基站将随时判断各个成员载波CC是否需要更新系统信息。
S102：当成员载波需要更新系统信息时，基站在该载波上发送寻呼消息1，通知小区下的终端更新系统信息。
当其中存在某个成员载波需要更新系统信息时，例如，将该载波以CC_change表述(也可以采用其他形式的表述)，基站在该载波上发送寻呼消息1，指示LTE和LTE-A终端，本载波系统信息发生更新。发送寻呼消息1可以沿用LTE系统中现有的技术方案。对于LTE-A小区中的终端而言，如果其没有监听CC_change，则该寻呼消息对其是不可见的。
例如，在LTE系统中，通过ASN.1(Abstract Syntax Notation One，抽象语律记法.1)标准语言对寻呼消息1描述如下：
Paging::＝ SEQUENCE{
pagingRecordList PagingRecordList OPTIONAL，--Need ON
systemInfoModification ENUMERATED{true} OPTIONAL，--Need ON
etws-Indication ENUMERATED{true } OPTIONAL，--Need ON
nonCriticalExtension SEQUENCE{} OPTIONAL --Need OP
}
S103：基站在本基站的其他CC上发送寻呼消息2，通知基站下的终端存在CC更新系统信息。
监听其他CC的终端虽然是本小区下的终端，由于没有监听CC_change，也听不到CC_change上的寻呼，为了能让这些终端及时更新CC_change的系统信息，基站在CC_change所属小区的其他CC上发送寻呼消息2，通知小区下的终端存在CC更新系统信息。
作为本发明的实施例，寻呼消息2为对寻呼消息1进行扩展实现，通过在寻呼消息1中增加一个比特信息，指示是否存在本小区的CC更新系统信息。进一步而言，一个比特信息指示还可以表示是否存在除本CC外的本小区的其他CC更新系统信息。
例如，在LTE-A系统中，一种寻呼消息扩展方式是增加一个比特，指示其他CC上的系统信息是否将发生变化，当有其他CC上的系统信息将发生变化时，该比特设置为true；否则，该比特为false。扩展之后的寻呼消息2的消息格式如下：
Paging::＝ SEQUENCE{
pagingRecordList PagingRecordList OPTIONAL，--Need ON
systemInfoModification ENUMERATED{true} OPTIONAL，--Need ON
etws-Indication ENUMERATED{true} OPTIONAL，--Need ON
r10NonCriticalExtension SEQUENCE{
systemInfoModification-r10ext ENUMERATED{true} OPTIONAL，--Need ON
nonCriticalExtension SEQUENCE{}OPTIONAL--Need OP
} OPTIONAL --Need OP
}
即，当基站判断CC_change将更新系统信息时，在系统信息更新时刻之前的BCCH修改周期内，基站在该小区的其他CC上发送寻呼消息2，在寻呼消息2中，将systemInfoModification-r10ext设置为true。
作为本发明的实施例，寻呼消息2为对寻呼消息1进行扩展实现，通过在寻呼消息1中增加系统信息变更比特图样bitmap信息，指示更新系统信息的相应CC。
例如，在LTE-A系统中，另一种寻呼消息扩展方式是使用系统信息变更比特图像bitmap的形式指示其他各CC上的系统信息是否将发生变化。当有CC的系统信息发生变化时，bitmap中对应CC的比特指示被设置为true，系统信息不发送变化的CC对应的比特设置为false。当除本CC外的其他CC没有系统信息将发生变化时，该bitmap可以不出现。扩展之后的寻呼消息2的消息格式如下：
Paging::＝ SEQUENCE{
pagingRecordList PagingRecordList OPTIONAL，--Need ON
systemInfoModification ENUMERATED{true} OPTIONAL，--Need ON
etws-Indication ENUMERATED{true} OPTIONAL，--Need ON
r10NonCriticalExtension SEQUENCE {
CC-SystemInfoModification::＝ SEQUENCE {
CC0x0001_change BOOLEAN，
CC0x0002_change BOOLEAN，
CC0x0003_change BOOLEAN，
CC0x0004_change BOOLEAN，
CC0x0005_change BOOLEAN
} OPTIONAL，--Need ON
nonCriticalExtension SEQUENCE{}OPTIONAL--Need OP
} OPTIONAL --Need OP
即，当基站判断CC_change将更新系统信息时，在系统信息更新时刻之前的BCCH修改周期内，基站在该小区的其他CC上发送寻呼消息，在寻呼消息中携带bitmap，且将bitmap中的CC_change对应的比特设置为true；系统信息为发生变化的CC对应的比特设置为false。
作为本发明的实施例，寻呼消息2为通过定义新的寻呼ID实现，寻呼ID携带一个比特信息，用于指示是否存在本小区的CC更新系统信息。此外，寻呼ID携带的一个比特信息可以为隐式携带，当调度信道上出现新的寻呼ID时，表示存在其他CC发生了系统信息变更，否则没有其他CC发生系统信息变更。
例如，在LTE系统中，寻呼消息1通过寻呼ID P-RNTI进行调度。在LTE-A中，可以定义新的寻呼ID为P-RNTI2。P-RNTI2对LTE终端是不可见的，LTE-A通过对P-RNTI2解码接收寻呼消息，在该寻呼消息中，包含其他CC系统信息变更指示，携带1比特指示寻呼原因为其他CC上的系统信息发生变化。
即，当基站判断CC_change将更新系统信息时，在系统信息更新时刻之前的BCCH修改周期内，基站在该小区的其他CC上发送寻呼消息，寻呼ID为P-RNTI2，寻呼原因为其他CC上的系统信息发生变化。
进一步而言，如果定义寻呼ID P-RNTI2仅用于指示其他CC上系统信息发生变更，则当基站使用寻呼ID P-RNTI2对终端进行调度时，终端就可以知道其他CC上系统信息发生变更，寻呼消息中可以不需再携带寻呼原因。
此外，作为本发明的实施例，寻呼消息2为通过定义新的寻呼ID实现，寻呼ID携带一个bitmap信息，用于指示更新系统信息的相应CC。
即，当基站判断CC_change将更新系统信息时，在系统信息更新时刻之前的BCCH修改周期内，基站在该小区的其他CC上，发送寻呼消息：寻呼ID为P-RNTI2，寻呼消息中携带bitmap。Bitmap中将系统信息发生变化的CC对应的比特位设置为true；未发生变化的CC对应的比特位设置为false。
根据本发明的实施例的系统信息接收的方法包括以下步骤：终端在当前监听的一个或多个成员载波CC读取寻呼消息；当终端收到寻呼消息2，寻呼消息2指示存在CC更新系统信息时，终端在下一个BCCH广播信道修改周期的起始位置，对未监听的CC进行监听并读取系统信息；终端完成对系统信息读取之后，保存系统信息。
图5为根据本发明的实施例的系统信息接收方法的流程图。如图5所示，该方法包括以下步骤：
S201：终端在当前监听的一个或多个成员载波CC读取寻呼消息。
对于LTE-A终端，例如如图1所示，该终端可以看到该LTE-A小区是由四个载波组成的，因此终端在当前监听的一个或多个成员载波CC读取寻呼消息，并根据寻呼消息指示接收系统信息。
S202：当寻呼消息2指示存在CC更新系统信息时，终端在下一个BCCH广播信道修改周期的起始位置，对未监听的CC进行监听并读取系统信息；以及
S203：终端完成对系统信息读取，保存系统信息。
监听其他CC的终端虽然是本小区下的终端，由于没有监听CC_change，也听不到CC_change上的寻呼，为了能让这些终端及时更新CC_change的系统信息，基站在CC_change所属小区的其他CC上发送寻呼消息2，通知小区下的终端存在CC更新系统信息。
作为本发明的实施例，寻呼消息2为对寻呼消息1进行扩展实现，通过在寻呼消息1中增加一个比特信息，指示是否存在本小区的CC更新系统信息。
例如，在LTE-A系统中，一种寻呼消息扩展方式是增加一个比特，指示其他CC上的系统信息是否将发生变化，当有其他CC上的系统信息将发生变化时，该比特设置为true；否则，该比特为false。扩展之后的寻呼消息2的消息格式如下：
Paging::＝ SEQUENCE{
pagingRecordList PagingRecordList OPTIONAL，--Need ON
systemInfoModification ENUMERATED{true} OPTIONAL，--Need ON
etws-Indication ENUMERATED{true} OPTIONAL，--Need ON
r10NonCriticalExtension SEQUENCE{
systemInfoModification-r10ext ENUMERATED{true} OPTIONAL，--Need ON
nonCriticalExtension SEQUENCE{}OPTIONAL--Need OP
} OPTIONAL --Need OP
}
即，LTE-A终端在当前监听的CC上读取寻呼消息，可以是一个或多个CC；如果收到寻呼消息2，且systemInfoModification-r10ext设置为true，则在下一个BCCH修改周期的起始位置，对未监听的CC上的系统信息进行重新读取；在完成未监听的CC上的系统信息读取之后，终端保存这些系统信息。
作为本发明的实施例，寻呼消息2为对寻呼消息1进行扩展实现，通过在寻呼消息1中增加系统信息变更比特图样bitmap信息，指示更新系统信息的相应CC。
例如，在LTE-A系统中，另一种寻呼消息扩展方式是使用系统信息变更比特图像bitmap的形式指示其他各CC上的系统信息是否将发生变化。当有CC的系统信息发生变化时，bitmap中对应CC的比特指示被设置为true，系统信息不发送变化的CC对应的比特设置为false。当除本CC外的其他CC没有系统信息将发生变化时，该bitmap可以不出现。扩展之后的寻呼消息2的消息格式如下：
Paging::＝ SEQUENCE{
pagingRecordList PagingRecordList OPTIONAL，--Need ON
systemInfoModification ENUMERATED{true} OPTIONAL，--Need ON
etws-Indication ENUMERATED{true} OPTIONAL，--Need ON
r10NonCriticalExtension SEQUENCE{
CC-SystemInfoModification::＝ SEQUENCE{
CC0x0001_change BOOLEAN，
CC0x0002_change BOOLEAN，
CC0x0003_change BOOLEAN，
CC0x0004_change BOOLEAN，
CC0x0005_change BOOLEAN
} OPTIONAL，--Need ON
nonCriticalExtension SEQUENCE{}OPTIONAL--Need OP
} OPTIONAL --Need OP
即，LTE-A终端在当前监听的CC上读取寻呼消息，可以是一个或多个CC；如果收到寻呼消息2，且携带了系统信息变更bitmap，则在下一个BCCH修改周期的起始位置，对bitmap中设置为true的CC上的系统信息进行重新读取；在完成对应CC上的系统信息读取之后，终端保存这些系统信息。
作为本发明的实施例，寻呼消息2为通过定义新的寻呼ID实现，寻呼ID携带一个比特信息，用于指示是否存在本小区的CC更新系统信息。
例如，在LTE系统中，寻呼消息1通过寻呼ID P-RNTI进行调度。在LTE-A中，可以定义新的寻呼ID为P-RNTI2。P-RNTI2对LTE终端是不可见的，LTE-A通过对P-RNTI2解码接收寻呼消息，在该寻呼消息中，包含其他CC系统信息变更指示，携带1比特指示寻呼原因为其他CC上的系统信息发生变化。
即，LTE-A终端在当前监听的CC上读取寻呼消息，可以是一个或多个CC；如果收到寻呼消息2，且寻呼原因为其他CC上的系统信息发生变化，则在下一个BCCH修改周期的起始位置，对未监听的CC上的系统信息进行重新读取；在完成对应CC上的系统信息读取之后，终端保存这些系统信息。
进一步而言，如果定义寻呼ID P-RNTI2仅用于指示其他CC上系统信息发生变更，则当基站使用寻呼ID P-RNTI2对终端进行调度时，终端就可以知道其他CC上系统信息发生变更，寻呼消息中可以不需再携带寻呼原因。
此外，作为本发明的实施例，寻呼消息2为通过定义新的寻呼ID实现，寻呼ID携带一个bitmap信息，用于指示更新系统信息的相应CC。
即，LTE-A终端在当前监听的CC上读取寻呼消息，可以是一个或多个CC；如果收到寻呼消息，且携带了系统信息变更bitmap，则在下一个BCCH修改周期的起始位置，对bitmap中设置为true的CC上的系统信息进行重新读取；在完成对指示更新系统信息的相应CC上的系统信息读取之后，终端保存这些系统信息。
本发明的实施例的上述方法解决了系统中终端能够对多个CC实现监听，及时发现系统信息的变化并进行更新的问题。根据本发明的实施例的上述方法，终端既可以及时发现多个CC系统信息的变化并进行更新，也不会因为更新系统信息而长时间对多个CC进行监听而增大终端的耗电量。此外，本发明实施例的上述方法，对现有系统的改动很小，不会影响系统的兼容性，而且实现简单、高效。
图6示出了根据本发明实施例的基站200的结构示意图。如图6所示，根据本发明实施例的基站200包括判断模块210以及发送模块220。
其中，判断模块210用于判断成员载波CC是否需要更新系统信息；当判断模块210判断成员载波CC_change需要更新系统信息时，发送模块220用于在CC_change上发送寻呼消息1，通知CC_change所属小区下的终端更新系统信息以及在CC_change所属基站的其他CC上发送寻呼消息2，通知基站下的终端存在CC更新系统信息。
作为上述设备的实施例，寻呼消息2为对寻呼消息1进行扩展实现，通过在寻呼消息1中增加一个比特信息，指示是否存在本小区的CC更新系统信息。
作为上述设备的实施例，寻呼消息2为对寻呼消息1进行扩展实现，通过在寻呼消息1中增加系统信息变更比特图样bitmap信息，指示更新系统信息的相应CC；或者寻呼消息2为通过定义新的寻呼ID实现，寻呼ID携带一个比特信息，用于指示是否存在本小区的CC更新系统信息；或者寻呼消息2为通过定义新的寻呼ID实现，寻呼ID携带一个bitmap信息，用于指示更新系统信息的相应CC。
图6示出了根据本发明的实施例的用户设备100的结构示意图。如图6所示，根据本发明的实施例的用户设备100包括接收模块110、判断模块120以及存储模块130。
其中，接收模块110用于监听一个或多个成员载波CC，并读取寻呼消息，根据寻呼消息指示接收系统信息；判断模块120用于判断是否收到寻呼消息2，寻呼消息2指示存在CC更新系统信息时，接收模块110在下一个BCCH广播信道修改周期的起始位置，对未监听的CC进行监听并读取系统信息；存储模块130用于在接收模块110完成对系统信息读取之后，保存系统信息。
作为上述设备的实施例，寻呼消息2为对现有系统的寻呼消息进行扩展实现，通过在现有系统的寻呼消息中增加一个比特信息，指示是否存在本小区的CC更新系统信息。
作为上述设备的实施例，寻呼消息2为对现有系统的寻呼消息进行扩展实现，通过在现有系统的寻呼消息中增加系统信息变更比特图样bitmap信息，指示更新系统信息的相应CC，接收模块110在下一个BCCH广播信道修改周期的起始位置，对指示更新系统信息的相应CC进行监听并读取系统信息。
作为上述设备的实施例，寻呼消息2为通过定义新的寻呼ID实现，寻呼ID携带一个比特信息，用于指示是否存在本小区的CC更新系统信息。
作为上述设备的实施例，寻呼消息2为通过定义新的寻呼ID实现，寻呼ID携带一个bitmap信息，用于指示更新系统信息的相应CC，接收在下一个BCCH广播信道修改周期的起始位置，对指示更新系统信息的相应CC进行监听并读取系统信息。
在LTE-A系统中，通常一个基站下管辖一个或多个小区(cell)，每个小区可以看成是一个成员载波。当LTE-A终端工作在CA模式下时，UE聚合多个成员载波进行数据收发，因此，该UE需要及时对这些成员载波的系统信息进行更新。如果LTE-A终端同时监听所有CC的系统信息变更通知，将对节省电量不利，在本发明的实施例中，使在CA传输模式下的UE仅监听一个聚合CC便可以进行系统信息更新，其中，所述的一个聚合CC可以是网络通过信令指定的，或者是UE的特定小区(special cell)，或者是UE的锚小区(anchor cell)，或者是UE任意选择的一个成员载波。本发明的实施例中的监听是指UE监听某CC的寻呼消息，寻呼消息中含有系统消息变更通知。
根据本发明的实施例的系统信息发送的方法可以包括以下步骤：
步骤一、基站判断成员载波CC是否需要更新系统信息；
步骤二、当成员载波CC_change需要更新系统信息时，基站在CC_cnange上发送寻呼消息1，通知CC_change小区下的终端更新系统信息；
步骤三、基站在CC_change基站以外的其他CC上发送寻呼消息2，通知其他基站下的终端存在CC更新系统信息。
其中，寻呼消息1和寻呼消息2可以是同一类型的RRC消息(只有具体消息内容不同)，也可以是不同类型的两种RRC消息。基站可以只在有聚合UE的载波上发送寻呼消息2。
实例1：可以通过增加一个比特位指示SI Change，具体方法包括：
1、基站判断成员载波CC是否需要更新系统信息。基站将随时判断各个成员载波CC是否需要更新系统信息。
2、在CA传输过程中，当某一成员载波CC_change需要更新系统信息时，基站在载波CC_change上发送寻呼消息1，通知小区下的终端更新系统信息。寻呼消息1可以沿用LTE系统中现有的技术方案。如果UE此时正在监听CC_change，该UE就可以收到寻呼消息1，从而进行系统消息更新；如果UE此时监听的载波不是CC_change，UE就无法收到寻呼消息1，也就无法得到CC_change的系统消息变更通知，这种情况下UE需要通过寻呼消息2来获取系统消息更新。
3、基站只在有聚合UE的载波上发送寻呼消息2，通知正在监听其他CC的UE更新系统信息。可以采用将寻呼消息扩展一个比特的方式来指示该CC以外的其他CC上的系统信息是否将发生变化，当有其他CC上的系统信息将发生变化时，该比特设置为true；否则，该比特为false。扩展之后的寻呼消息2的消息格式如下：
Paging::＝ SEQUENCE{
pagingRecordList PagingRecordList OPTIONAL，--Need ON
systemInfoModification ENUMERATED{true} OPTIONAL，--Need ON
etws-Indication ENUMERATED{true} OPTIONAL，--Need ON
r10NonCriticalExtension SEQUENCE{
systemInfoModification-r10ext ENUMERATED{true} OPTIONAL，--Need ON
nonCriticalExtension SEQUENCE{}OPTIONAL--Need OP
} OPTIONAL --Need OP
}
即，当基站判断CC_change将更新系统信息时，在系统信息更新时刻之前的BCCH修改周期内，基站在CC_change以外的其他CC上，发送寻呼消息2：寻呼消息2中，将systemInfoModification-r10ext设置为true。LTE-A终端在当前监听的CC上(例如，special cell或者anchor cell)读取寻呼消息，如果收到寻呼消息2，且systemInfoModification-r10ext设置为true，则在下一个BCCH修改周期的起始位置，对未监听的CC上的系统信息进行重新读取，在完成未监听的CC上的系统信息读取之后，终端保存这些系统信息。
实例2：可以通过增加bitmap方式指示SI Change，具体方法包括：
1、基站判断成员载波CC是否需要更新系统信息。基站将随时判断各个成员载波CC是否需要更新系统信息。
2、在CA传输过程中，当某一成员载波CC_change需要更新系统信息时，基站在载波CC_change上发送寻呼消息1，通知小区下的终端更新系统信息。寻呼消息1可以沿用LTE系统中现有的技术方案。如果UE此时正在监听CC_change，该UE就可以收到寻呼消息1，从而进行系统消息更新，如果UE此时监听的载波不是CC_change，UE就无法收到寻呼消息1，也就无法得到CC_change的系统消息变更通知，这种情况下UE需要通过寻呼消息2来获取系统消息更新。
3、基站只在有聚合UE的载波上发送寻呼消息2，通知正在监听其他CC的UE更新系统信息。寻呼消息2是将寻呼消息1进行扩展来实现的，通过在寻呼消息1中增加系统信息变更比特图样bitmap信息，指示更新系统信息的相应CC。当有CC的系统信息发生变化时，bitmap中对应CC的比特指示被设置为true，系统信息不发生变化的CC对应的比特设置为false。当除本CC外的其他CC没有系统信息将发生变化时，该bitmap可以不出现。扩展之后的寻呼消息2的消息格式如下：
Paging::＝ SEQUENCE{
pagingRecordList PagingRecordList OPTIONAL，--Need ON
systemInfoModification ENUMERATED{true} OPTIONAL，--Need ON
etws-Indication ENUMERATED{true} OPTIONAL，--Need ON
r10NonCriticalExtension SEQUENCE{
CC-SystemInfoModification::＝ SEQUENCE{
CC0x0001_change BOOLEAN，
CC0x0002_change BOOLEAN，
CC0x0003_change BOOLEAN，
CC0x0004_change BOOLEAN，
CC0x0005_change BOOLEAN
} OPTIONAL，--Need ON
nonCriticalExtension SEQUENCE{}OPTIONAL--Need OP
} OPTIONAL --Need OP
即，当基站判断CC_change将更新系统信息时，在系统信息更新时刻之前的BCCH修改周期内，基站在CC_change以外的其他CC上，发送寻呼消息2：寻呼消息中，携带bitmap，且将bitmap中，系统信息发生变化的CC对应的比特设置为true；系统信息未发生变化的CC对应的比特设置为false。LTE-A终端在当前监听的CC上(例如，特定小区或者锚小区)读取寻呼消息，如果收到寻呼消息2，且携带了系统信息变更bitmap，则在下一个BCCH修改周期的起始位置，对bitmap中设置为true的CC上的系统信息进行重新读取，在完成对应CC上的系统信息读取之后，终端保存这些系统信息。
实例3：可以通过定义新寻呼ID，在新寻呼ID对应的寻呼消息中携带一个比特位方式指示SI Change，具体方法包括：
1、基站判断成员载波CC是否需要更新系统信息。基站将随时判断各个成员载波CC是否需要更新系统信息。
2、在CA传输过程中，当某一成员载波CC_change需要更新系统信息时，基站在载波CC_change上发送寻呼消息1，通知小区下的终端更新系统信息。寻呼消息1可以沿用LTE系统中现有的技术方案。如果UE此时正在监听CC_change，该UE就可以收到寻呼消息1，从而进行系统消息更新；如果UE此时监听的载波不是CC_change，UE就无法收到寻呼消息1，也就无法得到CC_change的系统消息变更通知，这种情况下UE需要通过寻呼消息2来获取系统消息更新。
3、基站只在有聚合UE的载波上发送寻呼消息2，通知正在监听其他CC的UE更新系统信息。寻呼消息2通过定义新的寻呼ID来实现，该寻呼ID对应于寻呼消息2，寻呼消息2中携带一个比特指示是否存在其他CC更新系统信息。
例如，在LTE系统中，寻呼消息1通过寻呼ID：P-RNTI进行调度。在LTE-A中，可以定义新的寻呼ID：P-RNTI2。P-RNTI2对LTE终端是不可见的，LTE-A通过对P-RNTI2解码接收寻呼消息，在该寻呼消息中，包含其他CC系统信息变更指示，携带1比特指示寻呼原因为其他CC上的系统信息发生变化。
即，当基站判断CC_change将更新系统信息时，在系统信息更新时刻之前的BCCH修改周期内，基站在CC_change以外的其他CC上，发送寻呼消息：寻呼ID为P-RNTI2，寻呼原因为其他CC上的系统信息发生变化。LTE-A终端在当前监听的CC上(例如，特定小区或者锚小区)读取寻呼消息，如果收到寻呼消息2，且寻呼原因为其他CC上的系统信息发生变化，则在下一个BCCH修改周期的起始位置，对未监听的CC上的系统信息进行重新读取，在完成对应CC上的系统信息读取之后，终端保存这些系统信息。
进一步而言，如果定义寻呼ID P-RNTI2仅用于指示其他CC上系统信息发生变更，则当基站使用寻呼ID P-RNTI2对终端进行调度时，终端就可以知道其他CC上系统信息发生变更，寻呼消息中可以不需再携带寻呼原因。
实例4：可以通过定义新寻呼ID，在新寻呼ID对应的寻呼消息中携带bitmap方式指示SI Change，具体方法包括：
1、基站判断成员载波CC是否需要更新系统信息。基站将随时判断各个成员载波CC是否需要更新系统信息。
2、在CA传输过程中，当某一成员载波CC_change需要更新系统信息时，基站在载波CC_change上发送寻呼消息1，通知小区下的终端更新系统信息。寻呼消息1可以沿用LTE系统中现有的技术方案。如果UE此时正在监听CC_change，该UE就可以收到寻呼消息1，从而进行系统消息更新；如果UE此时监听的载波不是CC_change，UE就无法收到寻呼消息1，也就无法得到CC_change的系统消息变更通知，这种情况下UE需要通过寻呼消息2来获取系统消息更新。
3、基站只在有聚合UE的载波上发送寻呼消息2，通知正在监听其他CC的UE更新系统信息。寻呼消息2为通过定义新的寻呼ID实现，该寻呼ID携带一个bitmap信息，用于指示更新系统信息的相应CC。LTE-A终端在当前监听的CC上(例如，特定小区或者锚小区)读取寻呼消息，如果收到寻呼消息，且携带了系统信息变更bitmap，则在下一个BCCH修改周期的起始位置，对bitmap中设置为true的CC上的系统信息进行重新读取，在完成对指示更新系统信息的相应CC上的系统信息读取之后，终端保存这些系统信息。
实例5：可以通过定义新寻呼ID，在新寻呼ID本身中携带一个比特位方式指示SI Change，具体实现方法与实例3类似。对于寻呼消息2通过定义新的寻呼ID来实现，该寻呼ID携带一个比特信息，用于指示是否存在其他CC更新系统信息。但与实例3不同的是，该增加比特位位于新寻呼ID本身之中，即，LTE-A终端无需对寻呼消息进行解码就可以判断出其他CC上的系统信息是否发生变化。如果考虑进一步优化，寻呼消息可以不携带任何信息或者不需要对应的寻呼消息。此外，该寻呼ID携带的一个比特信息可以为隐式携带，当调度信道上出现新的寻呼ID时，表示存在其他CC发生了系统信息变更，否则没有其他CC发生系统信息变更。
例如，在LTE-A中，定义新的寻呼ID：P-RNTI2。P-RNTI2对LTE终端是不可见的，LTE-A终端直接根据P-RNTI2的格式(增加的一个比特位)来判断其他CC上的系统信息是否发生了变化。例如，P-RNTI2是对LTE的P-RNTI的扩展，体现在对PDCCH DCI format 1a或者format 1c增加一个比特位。此外，如果P-RNTI2携带的一个比特信息为隐式携带，当调度信道上出现P-RNTI2时，表示存在其他CC发生了系统信息变更，否则没有其他CC发生系统信息变更。
系统信息发送和接收的其他相关步骤与实例3相同。
实例6：可以通过定义新寻呼ID实现，在新寻呼ID本身中携带bitmap方式指示SI Change，具体方法与实例4类似，对于寻呼消息2通过定义新的寻呼ID来实现，该寻呼ID携带一个bitmap信息，用于指示更新系统信息的相应CC。但与实例4不同的是，该bitmap信息位于新寻呼ID本身之中，即，LTE-A终端无需对寻呼消息进行解码就可以判断出哪些CC上的系统信息发生了变化。如果考虑进一步优化，寻呼消息可以不携带任何信息或者不需要对应的寻呼消息。
例如，在LTE-A中，定义新的寻呼ID为P-RNTI2。P-RNTI2对LTE终端是不可见的，LTE-A终端直接根据P-RNTI2的格式(增加的bitmap信息)来判断哪些CC上的系统信息发生了变化。例如，P-RNTI2是对LTE的P-RNTI的扩展，体现在对PDCCH DCI format 1a增加bitmap信息。
系统信息发送和接收的其他相关步骤与实例4相同。
实例7：可以通过增加载波编号(CC Index)来指示SI Change，具体方法包括：
1、基站判断成员载波CC是否需要更新系统信息。基站将随时判断各个成员载波CC是否需要更新系统信息。
2、在CA传输过程中，当某一成员载波CC_change需要更新系统信息时，基站在载波CC_change上发送寻呼消息1，通知小区下的终端更新系统信息。寻呼消息1可以沿用LTE系统中现有的技术方案。如果UE此时正在监听CC_change，该UE就可以收到寻呼消息1，从而进行系统消息更新；如果UE此时监听的载波不是CC_change，UE就无法收到寻呼消息1，也就无法得到CC_change的系统消息变更通知，这种情况下UE需要通过寻呼消息2来获取系统消息更新。
3、基站只在有聚合UE的载波上发送寻呼消息2，通知正在监听其他CC的UE更新系统信息。可以采用将寻呼消息扩展载波编号的方式来指示该CC以外的其他CC上的系统信息是否将发生变化，当有其他CC上的系统信息将发生变化时，通知UE该CC的载波编号；否则，不通知UE该CC的载波编号。扩展之后的寻呼消息2的消息格式如下：
Paging::＝ SEQUENCE{
pagingRecordList PagingRecordList OPTIONAL，--Need ON
systemInfoModification ENUMERATED{true} OPTIONAL，--Need ON
etws-Indication ENUMERATED{true} OPTIONAL，--Need ON
r10NonCriticalExtension SEQUENCE{
CC-SystemInfoModification::＝ SEQUENCE of CC_Index OPTIONAL，--Need ON
nonCriticalExtension SEQUENCE{}OPTIONAL--Need OP
} OPTIONAL --Need OP，
CC_Index INTEGER(1..8)
}
即，当基站判断CC_change将更新系统信息时，在系统信息更新时刻之前的BCCH修改周期内，基站在CC_change以外的其他CC上，发送寻呼消息2：寻呼消息2中，CC-SystemInfoModification包含CC_change的载波编号(CC Index)。LTE-A终端在当前监听的CC上(例如，special cell或者anchor cell)读取寻呼消息，如果收到寻呼消息2，且CC-SystemInfoModification包含CC_change的载波编号(CC Index)，则在下一个BCCH修改周期的起始位置，对获取了载波编号的CC_change上的系统信息进行重新读取，在完成CC_change上的系统信息读取之后，终端保存这些系统信息。
实例8：可以通过定义新寻呼ID，在新寻呼ID对应的寻呼消息中增加载波编号(CC Index)来指示SI Change，具体方法包括：
1、基站判断成员载波CC是否需要更新系统信息。基站将随时判断各个成员载波CC是否需要更新系统信息。
2、在CA传输过程中，当某一成员载波CC_change需要更新系统信息时，基站在载波CC_change上发送寻呼消息1，通知小区下的终端更新系统信息。寻呼消息1可以沿用LTE系统中现有的技术方案。如果UE此时正在监听CC_change，该UE就可以收到寻呼消息1，从而进行系统消息更新；如果UE此时监听的载波不是CC_change，UE就无法收到寻呼消息1，也就无法得到CC_change的系统消息变更通知，这种情况下UE需要通过寻呼消息2来获取系统消息更新。
3、基站只在有聚合UE的载波上发送寻呼消息2，通知正在监听其他CC的UE更新系统信息。寻呼消息2通过定义新的寻呼ID来实现，该寻呼ID对应的寻呼消息2中携带系统信息更新CC的载波编号(CC Index)，用于指示是否存在其他CC更新系统信息。寻呼消息2的格式与实例7中相同。
例如，在LTE系统中，寻呼消息1通过寻呼ID：P-RNTI进行调度。在LTE-A中，可以定义新的寻呼ID：P-RNTI2。P-RNTI2对LTE终端是不可见的，LTE-A通过对P-RNTI2解码接收寻呼消息，在该寻呼消息中，包含其他CC系统信息变更指示，携带载波编号(CC Index)指示哪些其他CC的系统信息发生了变化。
即，当基站判断CC_change将更新系统信息时，在系统信息更新时刻之前的BCCH修改周期内，基站在CC_change以外的其他CC上，发送寻呼消息：寻呼ID为P-RNTI2，对应的寻呼消息中携带CC_change的载波编号，表示CC_change上的系统信息发生变化。LTE-A终端在当前监听的CC上(例如，special cell或者anchor cell)读取寻呼消息，如果收到寻呼消息2，且寻呼消息中携带了CC_change的载波编号(CC Index)，指示CC_change的系统信息发生变化，则在下一个BCCH修改周期的起始位置，对CC_change的系统信息进行重新读取，在完成CC_change上的系统信息读取之后，终端保存这些系统信息。
实例9：可以通过定义新寻呼ID，在新寻呼ID本身中携带载波编号(CCIndex)来指示SI Change，具体实现方法与实例8类似。对于寻呼消息2通过定义新的寻呼ID来实现，该寻呼消息2携带载波编号(CC Index)信息，用于指示是否存在其他CC更新系统信息。但与实例8不同的是，该增加载波编号(CC Index)位于新寻呼ID本身之中，即，LTE-A终端无需对寻呼消息进行解码就可以判断出其他CC上的系统信息是否发生变化。如果考虑进一步优化，寻呼消息可以不携带任何信息或者不需要对应的寻呼消息。此外，该寻呼ID携带的载波编号(CC Index)可以重用已有的载波编号指示信息，例如CI bits(CI为carrier index)。如果新寻呼ID中携带了某个CC的载波编号，那么就标识该CC发生了系统信息更新。
例如，在LTE-A中，定义新的寻呼ID：P-RNTI2。P-RNTI2对LTE终端是不可见的，LTE-A终端直接根据P-RNTI2的格式(增加的载波编号)来判断其他CC上的系统信息是否发生了变化。例如，P-RNTI2是对LTE的P-RNTI的扩展，体现在对PDCCH DCI format 1a或者format 1c增加载波编号。
系统信息发送和接收的其他相关步骤与实例8相同。
此外，本发明实施例提出的上述设备，解决了系统中终端能够对多个CC实现监听，及时发现系统信息的变化并进行更新的问题。根据本发明实施例提出的上述设备，终端既可以及时发现多个CC系统信息的变化并进行更新，也不会因为更新系统信息而长时间对多个CC进行监听而增大终端的耗电量。此外，本发明实施例提出的上述设备，对现有系统的改动很小，不会影响系统的兼容性，而且实现简单、高效。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
Claims (50)
1.一种系统信息发送的方法，其特征在于，包括以下步骤：
基站判断成员载波是否需要更新系统信息；
当一成员载波CC_change需要更新系统信息时，所述基站在CC_change上发送寻呼消息1，通知CC_change所属小区下的终端更新系统信息；
所述基站在CC_change所属基站的其他成员载波上发送寻呼消息2，通知基站下的终端存在成员载波更新系统信息。
2.如权利要求1所述的系统信息发送的方法，其特征在于，所述寻呼消息1和所述寻呼消息2为同类型的RRC消息或不同类型的RRC消息。
3.如权利要求2所述的系统信息发送的方法，其特征在于，所述寻呼消息2为对所述寻呼消息1进行扩展实现，通过在寻呼消息1中增加一个比特信息，指示是否存在本基站的成员载波更新系统信息。
4.如权利要求3所述的系统信息发送的方法，其特征在于，所述一个比特信息指示是否存在除本成员载波外的本基站的其他成员载波更新系统信息。
5.如权利要求2所述的系统信息发送的方法，其特征在于，所述寻呼消息2为对所述寻呼消息1进行扩展实现，通过在寻呼消息1中增加系统信息变更比特图样bitmap信息，指示更新系统信息的相应成员载波。
6.如权利要求2所述的系统信息发送的方法，其特征在于，所述寻呼消息2为对所述寻呼消息1进行扩展实现，通过在寻呼消息1中增加一个载波编号，指示更新系统信息的相应成员载波。
7.如权利要求2所述的系统信息发送的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个比特信息，用于指示是否存在本基站的成员载波更新系统信息。
8.如权利要求7所述的系统信息发送的方法，其特征在于，所述寻呼ID携带的一个比特信息为隐式携带，当调度信道上出现所述新的寻呼ID时，表示存在本基站的成员载波更新系统信息，否则本基站没有成员载波更新系统信息。
9.如权利要求2所述的系统信息发送的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个bitmap信息，用于指示更新系统信息的相应成员载波。
10.如权利要求2所述的系统信息发送的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个载波编号，用于指示更新系统信息的相应成员载波。
11.如权利要求2所述的系统信息发送的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述寻呼ID中增加一个比特信息，用于指示是否存在本基站的成员载波更新系统信息。
12.如权利要求2所述的系统信息发送的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述寻呼ID中增加一个bitmap信息，用于指示更新系统信息的相应成员载波。
13.如权利要求2所述的系统信息发送的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述寻呼ID中增加一个载波编号，用于指示更新系统信息的相应成员载波。
14.如权利要求1至13中任一项所述的系统信息发送的方法，其特征在于，所述基站在有聚合UE的载波上发送所述寻呼消息2。
15.如权利要求1至13中任一项所述的系统信息发送的方法，其特征在于，所述CC_change所属基站的其他成员载波是与所述CC_change进行载波聚合的成员载波。
16.一种基站设备，其特征在于，包括：
判断模块，用于判断成员载波是否需要更新系统信息；
发送模块，用于当所述判断模块判断一成员载波CC_change需要更新系统信息时，在CC_change上发送寻呼消息1，通知CC_change所属小区下的终端更新系统信息以及在CC_change所属基站的其他成员载波上发送寻呼消息2，通知基站下的终端存在成员载波更新系统信息。
17.如权利要求16所述的基站设备，其特征在于，所述寻呼消息1和所述寻呼消息2为同类型的RRC消息或不同类型的RRC消息。
18.如权利要求17所述的基站设备，其特征在于，所述寻呼消息2为对所述寻呼消息1进行扩展实现，通过在寻呼消息1中增加一个比特信息，指示是否存在本基站的成员载波更新系统信息。
19.如权利要求17所述的基站设备，其特征在于，所述寻呼消息2为对所述寻呼消息1进行扩展实现，通过在寻呼消息1中增加系统信息变更比特图样bitmap信息，指示更新系统信息的相应成员载波。
20.如权利要求17所述的基站设备，其特征在于，所述寻呼消息2为对所述寻呼消息1进行扩展实现，通过在寻呼消息1中增加一个载波编号，指示更新系统信息的相应成员载波。
21.如权利要求17所述的基站设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个比特信息，用于指示是否存在本基站的成员载波更新系统信息。
22.如权利要求17所述的基站设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个bitmap信息，用于指示更新系统信息的相应成员载波。
23.如权利要求17所述的基站设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述寻呼ID对应的寻呼消息中增加一个载波编号，用于指示更新系统信息的相应成员载波。
24.如权利要求17所述的基站设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述寻呼ID中增加一个比特信息，用于指示是否存在本基站的成员载波更新系统信息。
25.如权利要求17所述的基站设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述寻呼ID中增加一个bitmap信息，用于指示更新系统信息的相应成员载波。
26.如权利要求17所述的基站设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述新的寻呼ID中增加一个载波编号，用于指示更新系统信息的相应成员载波。
27.如权利要求16至26中任一项所述的基站设备，其特征在于，所述发送模块在有聚合UE的载波上发送所述寻呼消息2。
28.如权利要求16至26中任一项所述的基站设备，其特征在于，所述CC_change所属基站的其他成员载波是可以与所述CC_change进行载波聚合的成员载波。
29.一种系统信息接收的方法，其特征在于，包括以下步骤：
终端在当前监听的一个或多个成员载波读取寻呼消息；
当所述终端收到寻呼消息2，所述寻呼消息2指示存在成员载波更新系统信息时，所述终端在下一个BCCH广播信道修改周期的起始位置，对指示更新系统信息的成员载波进行监听并读取其系统信息；以及
所述终端完成对所述系统信息读取之后，保存所述系统信息。
30.如权利要求29所述的系统信息接收的方法，其特征在于，所述寻呼消息2为对现有系统的寻呼消息进行扩展实现，通过在现有系统的寻呼消息中增加一个比特信息，指示是否存在本基站的成员载波更新系统信息。
31.如权利要求29所述的系统信息接收的方法，其特征在于，所述寻呼消息2为对现有系统的寻呼消息进行扩展实现，通过在现有系统的寻呼消息中增加系统信息变更比特图样bitmap信息，指示更新系统信息的相应成员载波，所述终端在下一个BCCH广播信道修改周期的起始位置，对指示更新系统信息的相应成员载波进行监听并读取系统信息。
32.如权利要求29所述的系统信息接收的方法，其特征在于，所述寻呼消息2为对现有系统的寻呼消息进行扩展实现，通过在现有系统的寻呼消息中增加一个载波编号，指示更新系统信息的相应成员载波。
33.如权利要求29所述的系统信息接收的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个比特信息，用于指示是否存在本基站的成员载波更新系统信息。
34.如权利要求29所述的系统信息接收的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个bitmap信息，用于指示更新系统信息的相应成员载波，所述终端在下一个BCCH广播信道修改周期的起始位置，对指示更新系统信息的相应成员载波进行监听并读取系统信息。
35.如权利要求29所述的系统信息接收的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个载波编号，用于指示更新系统信息的相应成员载波。
36.如权利要求29所述的系统信息接收的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述寻呼ID中增加一个比特信息，用于指示是否存在本基站的成员载波更新系统信息。
37.如权利要求29所述的系统信息接收的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述寻呼ID中增加一个bitmap信息，用于指示更新系统信息的相应成员载波。
38.如权利要求29所述的系统信息接收的方法，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述新的寻呼ID中增加一个载波编号，用于指示更新系统信息的相应成员载波。
39.如权利要求29至38中任一项所述的系统信息接收的方法，其特征在于，所述终端仅监听一个聚合成员载波的寻呼消息，所述一个聚合成员载波是网络通过信令指定的成员载波、终端的特定小区、终端的锚小区、或者是终端任意选择的一个成员载波。
40.一种用户设备，其特征在于，包括：
接收模块，用于监听一个或多个成员载波并读取寻呼消息，根据所述寻呼消息指示接收系统信息；
判断模块，用于判断是否收到寻呼消息2，所述寻呼消息2指示存在成员载波更新系统信息时，所述接收模块在下一个BCCH广播信道修改周期的起始位置，对指示更新系统信息的成员载波进行监听并读取其系统信息；以及
存储模块，用于在所述接收模块完成对所述系统信息读取之后，保存所述系统信息。
41.如权利要求40所述的用户设备，其特征在于，所述寻呼消息2为对现有系统的寻呼消息进行扩展实现，通过在现有系统的寻呼消息中增加一个比特信息，指示是否存在本基站的成员载波更新系统信息。
42.如权利要求40所述的用户设备，其特征在于，所述寻呼消息2为对现有系统的寻呼消息进行扩展实现，通过在现有系统的寻呼消息中增加系统信息变更比特图样bitmap信息，指示更新系统信息的相应成员载波，所述接收模块在下一个BCCH广播信道修改周期的起始位置，对指示更新系统信息的相应成员载波进行监听并读取系统信息。
43.如权利要求40所述的用户设备，其特征在于，所述寻呼消息2为对现有系统的寻呼消息进行扩展实现，通过在现有系统的寻呼消息中增加一个载波编号，指示更新系统信息的相应成员载波。
44.如权利要求40所述的用户设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个比特信息，用于指示是否存在本基站的成员载波更新系统信息。
45.如权利要求40所述的用户设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个bitmap信息，用于指示更新系统信息的相应成员载波，所述接收模块在下一个BCCH广播信道修改周期的起始位置，对指示更新系统信息的相应成员载波进行监听并读取系统信息。
46.如权利要求40所述的用户设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，所述寻呼ID对应的寻呼消息携带一个载波编号，用于指示更新系统信息的相应成员载波。
47.如权利要求40所述的用户设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述新的寻呼ID中增加一个比特信息，用于指示是否存在本基站的成员载波更新系统信息。
48.如权利要求40所述的用户设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述新的寻呼ID中增加一个bitmap信息，用于指示更新系统信息的相应成员载波。
49.如权利要求40所述的用户设备，其特征在于，所述寻呼消息2为通过定义新的寻呼ID实现，在所述新的寻呼ID中增加一个载波编号，用于指示更新系统信息的相应成员载波。
50.如权利要求40至49中任一项所述的用户设备，其特征在于，所述用户设备仅监听一个聚合成员载波的寻呼消息，所述一个聚合成员载波是网络通过信令指定的成员载波、终端的特定小区、终端的锚小区、或者是终端任意选择的一个成员载波。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200910246704 CN101902800B (zh) | 2009-05-26 | 2009-11-26 | 一种系统信息发送、接收的方法及设备 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910085598 | 2009-05-26 | ||
| CN200910085598.8 | 2009-05-26 | ||
| CN 200910246704 CN101902800B (zh) | 2009-05-26 | 2009-11-26 | 一种系统信息发送、接收的方法及设备 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101902800A CN101902800A (zh) | 2010-12-01 |
| CN101902800B true CN101902800B (zh) | 2013-02-20 |
Family
ID=43227910
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200910246704 Active CN101902800B (zh) | 2009-05-26 | 2009-11-26 | 一种系统信息发送、接收的方法及设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101902800B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024035922A1 (en) * | 2022-08-12 | 2024-02-15 | Apple Inc. | System information modification indication for cross-carrier sib transmission |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102651890B (zh) * | 2011-02-24 | 2015-03-25 | 电信科学技术研究院 | 一种系统信息的传输方法及装置 |
| CN102868467B (zh) * | 2011-07-08 | 2016-08-03 | 中兴通讯股份有限公司 | Etws及处理etws告警消息的方法 |
| CN106550417A (zh) * | 2012-12-06 | 2017-03-29 | 电信科学技术研究院 | 系统信息发送、获取方法和设备 |
| CN110662253B (zh) * | 2013-04-03 | 2022-12-09 | 安华高科技股份有限公司 | 用于载波分配的方法和设备 |
| US9497682B2 (en) | 2013-06-07 | 2016-11-15 | Intel Corporation | Central processing unit and methods for supporting coordinated multipoint transmission in an LTE network |
| CN107371218B (zh) * | 2016-05-12 | 2022-04-29 | 中兴通讯股份有限公司 | 广播系统信息的更新、接收方法及装置 |
| CN107645760A (zh) * | 2016-07-22 | 2018-01-30 | 夏普株式会社 | 基站、用户设备和相关方法 |
| CN114845392B (zh) * | 2017-01-24 | 2024-11-19 | 中兴通讯股份有限公司 | 一种寻呼优化的方法、装置、基站、用户设备和介质 |
| JP2020511841A (ja) * | 2017-03-24 | 2020-04-16 | 富士通株式会社 | システム情報の指示方法、装置及び通信システム |
| CN108809491B (zh) * | 2017-05-04 | 2020-02-18 | 维沃移动通信有限公司 | 系统信息传输方法、终端及网络侧设备 |
| CN108964850B (zh) * | 2017-05-17 | 2021-04-23 | 维沃移动通信有限公司 | 信息携带方法、网络侧设备及终端 |
| WO2019019140A1 (zh) * | 2017-07-28 | 2019-01-31 | Oppo广东移动通信有限公司 | 发送系统信息的方法、网络设备和终端设备 |
| CN111096010B (zh) * | 2017-09-22 | 2023-03-28 | 株式会社Ntt都科摩 | 用户装置及基站装置 |
| KR20210010905A (ko) * | 2018-05-21 | 2021-01-28 | 광동 오포 모바일 텔레커뮤니케이션즈 코포레이션 리미티드 | 시스템 정보 업데이트 정보 통신 방법 및 장치 |
| CN111132187B (zh) * | 2018-11-01 | 2023-04-18 | 维沃移动通信有限公司 | 确定方法、终端设备及网络设备 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1768291A1 (en) * | 2004-06-29 | 2007-03-28 | ZTE Corporation | A method for adjusting dynamically subsidiary carrier frequency in the multiple carrier frequencies cell |
| CN101005711A (zh) * | 2007-01-19 | 2007-07-25 | 重庆重邮信科股份有限公司 | 一种缩短用户终端从连接模式返回空闲模式时延的方法 |
| CN101378528A (zh) * | 2007-08-27 | 2009-03-04 | 鼎桥通信技术有限公司 | 一种在mbms专用载波上通知系统消息改变的方法 |
| CN101400188A (zh) * | 2007-09-26 | 2009-04-01 | 中兴通讯股份有限公司 | 一种非cell_dch状态下高速下行共享信道的传输方法 |
-
2009
- 2009-11-26 CN CN 200910246704 patent/CN101902800B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1768291A1 (en) * | 2004-06-29 | 2007-03-28 | ZTE Corporation | A method for adjusting dynamically subsidiary carrier frequency in the multiple carrier frequencies cell |
| CN101005711A (zh) * | 2007-01-19 | 2007-07-25 | 重庆重邮信科股份有限公司 | 一种缩短用户终端从连接模式返回空闲模式时延的方法 |
| CN101378528A (zh) * | 2007-08-27 | 2009-03-04 | 鼎桥通信技术有限公司 | 一种在mbms专用载波上通知系统消息改变的方法 |
| CN101400188A (zh) * | 2007-09-26 | 2009-04-01 | 中兴通讯股份有限公司 | 一种非cell_dch状态下高速下行共享信道的传输方法 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024035922A1 (en) * | 2022-08-12 | 2024-02-15 | Apple Inc. | System information modification indication for cross-carrier sib transmission |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101902800A (zh) | 2010-12-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101902800B (zh) | 一种系统信息发送、接收的方法及设备 | |
| CN101902799B (zh) | 一种系统信息发送、接收的方法及设备 | |
| US12200678B2 (en) | System and method for multi-carrier network operation | |
| EP2481182B1 (en) | System and method for multi-carrier network operation | |
| EP2656664B1 (en) | Methods and nodes for setting values of system parameters used in a wireless communication system | |
| CN101873694B (zh) | 系统信息变更通知的方法、系统及装置 | |
| CN108353347B (zh) | 控制对无线通信网络的接入 | |
| RU2452096C2 (ru) | Способ отправки, передачи и диспетчеризации системных сообщений в системе lte | |
| CN102104854A (zh) | 一种系统信息更新通知方法、系统和设备 | |
| EP2563069A2 (en) | System and method for multi-carrier network operation | |
| CN102349327A (zh) | 在无线通信系统中的切换期间处理上行链路同步定时器的方法 | |
| CN107431962A (zh) | 使用未更新的移动信息的小区重选 | |
| WO2013189220A1 (zh) | Tdd上下行配置的更新方法及装置和tdd重配置信息的通知方法及装置 | |
| JP2019512956A (ja) | Ｎｂ−ｉｏｔデバイスのページングのための共通検索スペース（ｃｓｓ） | |
| EP3372012B1 (en) | Methods, network node and wireless device for handling system information | |
| CN105828436A (zh) | 寻呼方法、装置、mme、基站及用户设备 | |
| CN107251455A (zh) | 电信设备和方法 | |
| CN107211352A (zh) | 电信装置与方法 | |
| EP3457602B1 (en) | System message transmitting method, transmitting equipment, receiving method, receiving equipment and storage medium | |
| CN102215201A (zh) | 一种系统信息更新方法和装置 | |
| Goyal et al. | Reducing the paging overhead in highly directional systems | |
| EP3576439B1 (en) | Data transmission methods, devices and computer-readable medium | |
| CN101925157B (zh) | 传输非驻留载波连接信息的方法、系统及装置 | |
| EP4387338A1 (en) | Power saving method and apparatus, device, and readable storage medium | |
| WO2026030866A1 (en) | On-demand rach partition activation and deactivation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| ASS | Succession or assignment of patent right |
Owner name: INST OF TELECOMMUNICATION SCIENCE AND TECHNOLGOY Free format text: FORMER OWNER: DATANG MOBILE COMMUNICATION EQUIPMENT CO., LTD. Effective date: 20110402 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 100083 NO. 29, XUEYUAN ROAD, HAIDIAN DISTRICT, BEIJING TO: 100191 NO. 40, XUEYUAN ROAD, HAIDIAN DISTRICT, BEIJING |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20110402 Address after: 100191 Haidian District, Xueyuan Road, No. 40, Applicant after: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY Address before: 100083 Haidian District, Xueyuan Road, No. 29, Applicant before: DATANG MOBILE COMMUNICATIONS EQUIPMENT Co.,Ltd. |
|
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CP01 | Change in the name or title of a patent holder | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 100191 No. 40, Haidian District, Beijing, Xueyuan Road Patentee after: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY Address before: 100191 No. 40, Haidian District, Beijing, Xueyuan Road Patentee before: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20210609 Address after: 100085 1st floor, building 1, yard 5, Shangdi East Road, Haidian District, Beijing Patentee after: DATANG MOBILE COMMUNICATIONS EQUIPMENT Co.,Ltd. Address before: 100191 No. 40, Haidian District, Beijing, Xueyuan Road Patentee before: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY |