通知用户设备关于无线电通信网络中即将发生的系统信息变化

申请号 CN200980159061.X 申请日 2009-04-27 公开(公告)号 CN102415172A 公开(公告)日 2012-04-11
申请人 瑞典爱立信有限公司; 发明人 C·法罗尼厄斯; L·赫德伦; W·米勒;
摘要 基本思路是引入用于处于连接模式的用户设备的附加寻呼时间表,它与用于处于空闲模式的用户设备的寻呼时间表不同。因此,本 发明 机制依靠按照用于处于空闲模式的用户设备的第一寻呼时间表在寻呼消息中分发(S1)即将发生的系统信息变化的通知,并且按照用于处于连接模式的用户设备的第二寻呼时间表在寻呼消息中分发(S2)即将发生的系统信息变化的通知。用于处于连接模式的用户设备的第二寻呼时间表与用于处于空闲模式的用户设备的第一寻呼时间表不同。这样,与处于连接模式和处于空闲模式的UE能够接收重要系统信息通知同时,实现令人满意的负荷分配。
权利要求

1.一种用于通知基于不连续接收(DRX)进行操作的用户设备(20,22)关于无线电通信网络中即将发生的系统信息变化的方法,其中所述方法包括下列步骤:
-按照用于处于空闲模式的用户设备(20)的第一寻呼时间表在寻呼消息中分发(S1)关于所述即将发生的系统信息变化的通知;以及
-按照用于处于连接模式的用户设备(22)的第二寻呼时间表在寻呼消息中分发(S2)关于所述即将发生的系统信息变化的通知,其中用于处于连接模式的用户设备的所述第二寻呼时间表与用于处于空闲模式的用户设备的所述第一寻呼时间表不同。
2.如权利要求1所述的方法,其中,所述空闲模式对应于无线电资源控制(RRC)空闲模式,而所述连接模式对应于RRC连接模式,并且所述按照第二寻呼时间表在寻呼消息中分发关于所述即将发生的系统信息变化的通知的步骤在系统信息变化之前的修改周期的至少一部分期间执行。
3.如权利要求1所述的方法,其中,用于处于连接模式的用户设备的所述第二寻呼时间表与用于处于空闲模式的用户设备的所述第一寻呼时间表无关。
4.如权利要求1所述的方法,其中,按照所述第二寻呼时间表分发的所述寻呼消息对于与所述无线电通信网络中的给定小区关联的、处于连接模式的用户设备而言是公共的。
5.如权利要求1所述的方法,其中,按照所述第二寻呼时间表分发的所述寻呼消息专用于处于连接模式的用户设备。
6.如权利要求1所述的方法,其中,按照所述第二寻呼时间表分发的所述寻呼消息专用于分发系统信息变化通知。
7.如权利要求1所述的方法,其中,所述第二寻呼时间表包括如下寻呼循环,即,所述寻呼循环的循环周期充分短以便可应用于与所述无线电通信网络中的给定小区关联的、在连接模式中基于不连续接收(DRX)进行操作的多个用户设备中每个用户设备。
8.如权利要求7所述的方法,其中,所述第二寻呼时间表包括如下寻呼循环,即所述寻呼循环基于与所述给定小区关联的、处于连接模式的所述多个用户设备的不连续接收(DRX)的最短配置的接通时长周期。
9.如权利要求8所述的方法,其中,所述按照第二寻呼时间表在寻呼消息中分发关于所述即将发生的系统信息变化的通知的步骤包括下列步骤:在系统信息变化之前的广播控制信道(BCCH)修改周期期间的至少每第n个子传送寻呼消息,其中n对应于不连续接收(DRX)的最短配置的接通时长周期。
10.如权利要求7所述的方法,其中,所述按照第二寻呼时间表在寻呼消息中分发关于所述即将发生的系统信息变化的通知的步骤包括下列步骤:在与所述给定小区关联的、处于连接模式的所述多个用户设备的最长不连续接收(DRX)循环周期期间的多个子帧中的每个子帧中传送寻呼消息。
11.如权利要求7所述的方法,其中,所述按照第二寻呼时间表在寻呼消息中分发关于所述即将发生的系统信息变化的通知的步骤包括下列步骤:在系统信息变化之前的广播控制信道(BCCH)修改周期期间的多个子帧中的每个子帧中传送寻呼消息。
12.如权利要求7所述的方法,其中,在没有系统信息需要更新时的周期期间,没有寻呼消息按照所述第二寻呼时间表来分发。
13.一种用于具有基于不连续接收(DRX)进行操作的用户设备(20,22)的无线电通信网络的无线电基站(10),其中,所述无线电基站包括:
-第一分发器(12),配置成按照用于处于空闲模式的用户设备(20)的第一寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知;以及
-第二分发器(14),配置成按照用于处于连接模式的用户设备(22)的第二寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知,其中用于处于连接模式的用户设备的所述第二寻呼时间表与用于处于空闲模式的用户设备的所述第一寻呼时间表不同。
14.如权利要求13所述的无线电基站,其中,所述空闲模式对应于无线电资源控制(RRC)空闲模式,而所述连接模式对应于RRC连接模式,并且所述第二分发器(14)配置成在系统信息变化之前的修改周期的至少一部分期间按照所述第二寻呼时间表来分发寻呼消息。
15.如权利要求13所述的无线电基站,其中,所述无线电基站(10)包括寻呼调度器(16),所述寻呼调度器(16)配置成使用于处于连接模式的用户设备的所述第二寻呼时间表与用于处于空闲模式的用户设备的所述第一寻呼时间表无关。
16.如权利要求13所述的无线电基站,其中,所述第二分发器(14)配置成按照所述第二寻呼时间表来分发对于与所述无线电基站的给定小区关联的已连接用户设备而言公共的寻呼消息。
17.如权利要求13所述的无线电基站,其中,所述第二分发器(14)配置成按照所述第二寻呼时间表来分发专用于处于连接模式的用户设备的寻呼消息。
18.如权利要求13所述的无线电基站,其中,所述第二分发器(14)配置成按照所述第二寻呼时间表来分发专用于分发系统信息变化通知的寻呼消息。
19.如权利要求13所述的无线电基站,其中,所述第二分发器(14)配置成基于如下寻呼循环按照所述第二寻呼时间表来分发寻呼消息,即所述寻呼循环的循环周期充分短以便可应用于与所述无线电基站(10)的给定小区关联、在连接模式基于不连续接收(DRX)进行操作的多个用户设备中的每个用户设备。
20.如权利要求19所述的无线电基站,其中,所述第二分发器(14)配置成按照具有如下寻呼循环的所述第二寻呼时间表来分发寻呼消息,即所述寻呼循环基于与所述给定小区关联的、处于连接模式的所述多个用户设备的不连续接收(DRX)的最短配置的接通时长周期。
21.如权利要求19所述的无线电基站,其中,所述第二分发器(14)配置成基于在系统信息变化之前的广播控制信道(BCCH)修改周期期间的至少每第n个子帧传输寻呼消息、按照所述第二寻呼时间表来分发寻呼消息,其中n对应于不连续接收(DRX)的最短配置的接通时长周期。
22.如权利要求19所述的无线电基站,其中,所述第二分发器(14)配置成基于在与所述给定小区关联的、处于连接模式的所述多个用户设备的最长不连续接收(DRX)循环周期期间的多个子帧中的每个子帧中传输寻呼消息、按照所述第二寻呼时间表来分发寻呼消息。
23.如权利要求19所述的无线电基站,其中,所述第二分发器(14)配置成基于在系统信息变化之前的广播控制信道(BCCH)修改周期期间的多个子帧中的每个子帧中传输寻呼消息、按照所述第二寻呼时间表来分发寻呼消息。
24.如权利要求19所述的无线电基站,其中,所述无线电基站(10)包括控制器(18),所述控制器(18)配置成定义所述第二寻呼时间表,使得在没有系统信息需要更新的周期期间,没有寻呼消息按照所述第二寻呼时间表来分发。
25.如权利要求13所述的无线电基站,其中,所述第一分发器(12)和所述第二分发器(14)在同一电路中作为不同功能单元来实现。
26.如权利要求13所述的无线电基站,其中,所述无线电基站(10)基于长期演进(LTE)系统的演进NodeB(eNodeB)。

说明书全文

通知用户设备关于无线电通信网络中即将发生的系统信息

变化

技术领域

[0001] 一般来说,本发明涉及无线电通信系统,更具体来说,涉及这类网络中与系统信息变化有关的过程。

背景技术

[0002] 一旦用户终端已经同步到无线电通信网络中的无线电小区、获取了小区的物理层识别码并且检测到小区定时,终端还必须获取小区系统信息。这个系统信息通常由网络重复广播,并且需要由用户终端获取,以便使其能够在网络中以及在特定小区中正确地访问和操作。
[0003] 相关系统信息的示例包括与下行链路和上行链路小区带宽和/或配置有关的信息、与随机接入传输、上行链路功率控制相关的参数等等。
[0004] 为了便于更好的理解,基于LTE(长期演进)的示范无线电通信系统的简介和概述会是有用的。
[0005] LTE是由3GPP进行标准化的新无线电接入技术。只有分组交换(PS)域才得到LTE支持,即,所有服务在PS域中得到支持。该标准在下行链路将基于OFDM(正交频分复用)以及在上行链路将基于SC-FDMA(单载波频域多址)。
[0006] 在LTE无线电基站周围建立LTE无线电接入架构,其中LTE无线电基站称作eNodeB,它们与又称作用户设备(UE)的移动终端进行通信。
[0007] LTE无线电接入的基本原理之一是共享信道传输,其中在用户之间动态共享时间频率资源。
[0008] 参照图1,在时域中,一个1ms时长的子帧根据配置而被分为12或14个OFDM(或SC-FDMA)符号。一个OFDM(或SC-FDMA)符号根据信道带宽和配置而在频域中包括若干副载波。一个副载波上的一个OFDM(或SC-FDMA)符号称作RE(资源元素)。图1对于2个天线的示例是有效的。如果例如使用4个天线,则将传送两倍的参考符号。
[0009] 在LTE中,没有使用专用数据信道,而是在下行链路和上行链路均使用共享信道资源。这些共享资源、即DL-SCH(下行链路共享信道)和UL-SCH(上行链路共享信道)由调度功能性来控制,调度功能性向不同UE指配下行链路和上行链路共享信道的不同部分分别用于接收和传输。
[0010] 在覆盖各下行链路子帧开始处的少数OFDM符号的控制区域中传送DL-SCH和UL-SCH的指配,如图1所示。在覆盖各下行链路子帧中的其余OFDM符号的数据区域中传送DL-SCH。将要求UE监视控制区域,以便能够检测在数据区域中针对它们的指配。控制区域中的指配通常由物理下行链路控制信道(PDCCH)来携带。数据区域中可用于数据传递的下行链路共享信道由物理下行链路共享信道(PDSCH)组成。
[0011] 在长期演进(LTE)系统中,例如,系统信息一般通过依靠两个不同传输信道的两种不同机制来传递:
[0012] -使用所谓的广播信道(BCH)来传送与所谓的主信息(MIB)对应的受限系统信息量。
[0013] -使用下行链路共享信道(DL-SCH)来传送与不同的所谓系统信息块(SIB)对应的系统信息的较大部分。
[0014] 使用BCH所传送的MIR一般包括用户终端能够读取使用DL-SCH所提供的其余SIB系统信息绝对必要的这种系统信息。
[0015] 图2是对于LTE的特定示例中的下行链路示出逻辑信道、传输信道和物理信道之间的映射的示意图。
[0016] 媒体接入控制(MAC)层向采取逻辑信道的形式的无线电链路控制(RLC)层提供服务。逻辑信道一般通过它携带的信息类型来定义,并且通常分类为用于传输操作LTE系统所需的控制和配置信息的控制信道或者用于用户数据的数据信道。为LTE所定义的逻辑信道集合包括:
[0017] -寻呼控制信道(PCCH),用于寻呼又称作用户设备(UE)的移动用户终端。
[0018] -广播控制信道(BCCH),用于系统信息从网络到小区中的所有移动用户终端的传输。
[0019] -公共控制信道(CCCH),用于结合随机接入的控制信息的传输。
[0020] -专用业务信道(DTCH),用于用户数据向/从移动终端的传输。
[0021] -专用控制信道(DCCH),用于移动终端的个体配置的控制信息的传输。
[0022] -多播业务信道(MTCH),用于多媒体广播和多播服务(MBMS)的下行链路传输。
[0023] -多播控制信道(MCCH),用于MTCH的接收所需的控制信息的传输。
[0024] 类似的逻辑信道结构用于宽带码分多址(WCDMA)和/或高速分组接入(HSPA)系统。与WCDMA/HSPA相比,LTE具有略微更简化的逻辑信道结构,其中具有数量降低的逻辑信道类型。
[0025] 物理层向采取所谓的传输信道的形式的MAC层提供服务。传输信道一般通过经由无线电接口传送信息的方式和特性来定义。例如,对于LTE,为下行链路定义下列传输信道:
[0026] -寻呼信道(PCH)用于来自PCCH逻辑信道的寻呼信息的传输。
[0027] -广播信道(BCH)用于包括MIB块的BCCH系统信息的部分的传输。
[0028] -下行链路共享信道(DL-SCH)是主要传输信道,如前面所述。
[0029] ·多播信道(MCH)用于支持MBMS服务。
[0030] 各传输信道映射到对应物理信道:
[0031] -物理广播信道(PBCH)携带终端访问网络所需的系统信息的部分。
[0032] -物理下行链路共享信道(PDSCH)是用于单播传输并且也用于寻呼信息的主要物理信道。
[0033] -物理多播信道(PMCH)用于通过单频网络的多播/广播(MBSFN)操作。
[0034] 但是应当注意,还存在没有对应传输信道的物理信道,特别是对于下行链路控制信息(DCI):
[0035] -物理下行链路控制信道(PDCCH)用于各种下行链路控制信息。
[0036] -物理混合ARQ指示符信道(PHICH)携带指示是否应当重传传输块的混合ARQ确认。
[0037] -物理控制格式指示符信道(PCFICH)提供对PDCCH解码所需的信息。
[0038] 对于上行链路也存在逻辑信道、传输信道和物理信道的对应映射(未示出)。
[0039] 在LTE中,例如,用户设备(UE)能够处于无线电资源控制(RRC)级上的两种不同状态,如图3所示。
[0040] RRC_CONNECTED是在UE为活动并且连接到网络中的特定小区时使用的状态。RRC_CONNECTED能够被说成是具有两个子状态IN_SYNC和OUT_OF_SYNC,取决于上行链路是否同步到网络。
[0041] RRC_IDLE是所谓的低活动状态,其中UE在大部分时间睡眠,以便降低电池消耗。没有保持上行链路同步,并且可发生的仅有上行链路传输活动是从RRC_IDLE转移到RRC_CONNECTED的所谓随机接入。在下行链路,UE能够按照不连续接收(DRX)循环周期地唤醒以监视寻呼信道(PCH),以便被寻呼用于进入的呼叫,下面将更详细地说明。
[0042] 除了对DL-SCH和UL-SCH的指配之外,对寻呼信道(PCH)的指配在控制区域中也由PDCCH来携带。PCH用于向处于RRC_IDLE的UE传送寻呼信息和/或通知处于RRC_IDLE的UE和处于RRC_CONNECTED的UE关于系统信息变化。UE可通过定期检查某个值,或者通过查找寻呼消息中的所述系统信息变化指示,来检验所获取的系统信息是否仍然有效。
[0043] 如上所述,LTE允许UE的不连续接收(DRX),以便节省UE电池。图4是示出DRX机制的基本原理的示意图。DRX机制用于允许UE终端在大部分时间睡眠,其中切断UE接收器电路,并且仅周期地唤醒短时段,以便监视寻呼信道。如图4所示,DRX循环周期通常包括短的、所谓的接通时长(On Duration)周期,之后跟随较长睡眠周期。对于处于RRC_IDLE的UE,对UE集合以组为基础来应用与基本寻呼时间表对准的DRX图案。DRX图案与寻呼时间表对准,对准方式使得UE在唤醒而不是在处于电池节省DRX睡眠模式的同时具有读取寻呼消息的可能性。
[0044] 为了进一步降低UE的电池消耗,还可应用处于RRC_CONNECTED的UE的DRX功能性。为此已经标准化产生大量不同可能配置的若干参数。
[0045] 应用与RRC_IDLE_UE的DRX图案对准的RRC_CONNECTEDUE的DRX图案使得UE在RRC_CONNECTED和RRC_IDLE均有可能检测包括系统信息通知的寻呼消息。然而,发现这种方式引起相对于网络性能和操作的问题。
[0046] 与系统信息通知和/或指示的分发相关的类似问题还会存在于具有基于不连续接收(DRX)在连接和空闲模式操作的用户设备的其它无线电通信网络。

发明内容

[0047] 一般目的是提供一种通知用户设备关于无线电通信网络中即将发生的系统信息变化的有效方式。
[0048] 具体目的是提供一种用于通知基于不连续接收(DRX)进行操作的用户设备关于无线电通信网络中即将发生的系统信息变化的方法。
[0049] 另一个具体目的是提供一种用于无线电通信网络的改进无线电基站。
[0050] 与用于空闲UE的基本DRX图案对准的、用于已连接UE的DRX图案的使用使得UE在连接模式和空闲模式均有可能检测包括系统信息通知的寻呼消息。但是,本发明人已经认识到,这种方式遭受相对于网络性能和操作的若干问题。例如,严重问题与用于已连接UE的同步DRX图案所引起的负荷峰值相关。负荷峰值对于已连接UE因其比处于空闲模式的UE更高的活动程度而更成问题。产生于负荷峰值的不良负荷分配又引起无线电通信网络中降低的吞吐量和延迟。
[0051] 如果为了避免负荷峰值和/或为了其它原因而允许用于已连接UE的未同步DRX图案,则有效地分发关于即将发生的系统信息变化的通知的问题仍然存在。
[0052] 因此,基本思路是引入用于处于连接模式的用户设备的附加寻呼时间表,它与用于处于空闲模式的用户设备的寻呼时间表不同。因此,本发明机制依靠按照用于处于空闲模式的用户设备的第一寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知,并且按照用于处于连接模式的用户设备的第二寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知。用于处于连接模式的用户设备的第二寻呼时间表与用于处于空闲模式的用户设备的第一寻呼时间表不同。
[0053] 这样,在处于连接模式和空闲模式的UE能够接收重要系统信息通知的同时,实现令人满意的负荷分配。
[0054] 还提供一种用于具有基于不连续接收(DRX)进行操作的用户设备的无线电通信网络的无线电基站。无线电基站包括:第一分发器,配置成按照用于处于空闲模式的用户设备的第一寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知;以及第二分发器,配置成按照用于处于连接模式的用户设备的第二寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知。用于处于连接模式的用户设备的第二寻呼时间表与用于处于空闲模式的用户设备的第一寻呼时间表不同。附图说明
[0055] 通过参照以下结合附图进行的描述,可透彻地理解本发明以及本发明的其它目的和优点,附图包括:
[0056] 图1是示出基于共享信道传输进行操作的无线电通信网络中的时间频率资源的结构的示例的示意图。
[0057] 图2是对于LTE的特定示例中的下行链路示出逻辑信道、传输信道和物理信道之间的映射的示意图。
[0058] 图3是示出无线电资源控制(RRC)级上的两种不同UE状态的示意图。
[0059] 图4是示出DRX机制的基本原理的示意图。
[0060] 图5是示出一种用于通知用户设备关于即将发生的系统信息变化的方法的示例的示意流程图
[0061] 图6是示出两个不同寻呼时间表、即IDLE(空闲)模式寻呼时间表和CONNECTED(连接)模式寻呼时间表的使用的示例的示意图。
[0062] 图7是示出用于已连接UE的寻呼时间表的配置的示例的示意图。
[0063] 图8示出修改周期的基本框架及其与系统信息分发的关系的示例。
[0064] 图9是示出用于已连接UE的四个不同寻呼时间表相对于成本和可靠性的性能的示意图。
[0065] 图10是按照一个示范实施例的无线电基站的示意框图
[0066] 图11是按照另一个示范实施例的无线电基站的示意框图。

具体实施方式

[0067] 在所有附图中,相同的参考标号用于相似或对应的元件。
[0068] 当为了避免负荷峰值和/或为了其它原因而允许已连接UE的未同步DRX图案时,基本思路是引入用于处于连接模式的用户设备的附加寻呼时间表,它与用于处于空闲模式的用户设备的寻呼时间表不同。
[0069] 图5是示出一种用于通知用户设备关于即将发生的系统信息变化的方法的示例的示意流程图。步骤S1基于按照用于处于空闲模式的用户设备的第一寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知。步骤S2基于按照用于处于连接模式的用户设备的第二不同寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知。
[0070] 这样,在处于连接模式和空闲模式的UE能够接收重要系统信息通知的同时,实现令人满意的负荷分配。
[0071] 在一个示范实施例中,按照第二寻呼时间表所分发的寻呼消息对于与无线电通信网络中的给定小区关联的处于连接模式的用户设备是公共的。因此,可存在用于每个小区的已连接UE的单独寻呼时间表。优选地,按照第二寻呼时间表的寻呼消息专用于处于连接模式的用户设备,并且还可专用于分发系统信息变化通知。换言之,这个单独寻呼时间表能够联合地针对处于连接模式的UE。另外,按照这个附加寻呼时间表的寻呼消息可配置用于仅携带已改变系统信息的指示,即,这些寻呼消息的目的不是按照普通方式来寻呼UE。优选地,这个附加寻呼时间表预计完全且联合地用于已连接UE,并且仅在恰发生系统信息更新之前的修改周期期间应用。
[0072] 图6是示出两个不同寻呼时间表、即IDLE模式寻呼时间表和CONNECTED(连接)模式寻呼时间表的使用的示例的示意图。
[0073] 从图6能够看到,一组IDLE模式UE的基本DRX图案与IDLE模式UE的基本寻呼时间表、即所谓的IDLE模式寻呼时间表对准。
[0074] 对于已连接UE,允许未同步DRX图案。这基本上表示,对于个体UE,可能允许任何任意DRX图案。通常,各种网络设定和要求可影响个体UE的实际DRX配置。但是,实际DRX配置超出了本发明的范围。可以肯定地说,连接模式UE的DRX图案可在不同UE之间显著改变,并且还能够注意,已连接UE的DRX图案通常不与IDLE模式DRX图案对准。
[0075] 为了能够向已连接UE分发关于即将发生的系统信息变化的通知,附加寻呼时间表用于连接模式UE,即所谓的CONNECTED模式寻呼时间表。从图6示意示出的示例能够看到,CONNECTED模式寻呼时间表不同于IDLE模式寻呼时间表。优选地,用于处于连接模式的用户设备的寻呼时间表与用于处于空闲模式的用户设备的寻呼时间表无关。
[0076] 在一个示范实施例中,IDLE模式对应于无线电资源控制(RRC)IDLE模式,而CONNECTED模式对应于RRC CONNECTED模式。
[0077] 在一个示范实施例中,CONNECTED模式寻呼时间表包括寻呼循环,其中具有充分短以便可应用于与无线电通信网络中的给定小区关联的多个已连接UE中每个已连接UE的循环周期。这意味着,按照单独CONNECTED模式寻呼时间表周期地分发包括关于即将发生的系统信息变化的通知或等效指示的寻呼消息。参照图6的示例,CONNECTED模式寻呼时间表对于所考虑小区中的所有已连接UE是公共的,而不管已连接UE的各种DRX循环周期和DRX起始偏移。但是应当理解,作为对使用周期性寻呼循环的替代,实际上有可能采用寻呼消息的非周期性传输。
[0078] 能够确保寻呼消息的至少一部分在每一个子帧中传送时将由已连接UE来接收。但是,这从传输观点来看可能成本过高。在一个备选实施例中,优选地基于已连接UE的DRX配置,例如基于所考虑的已连接UE的最短DRX接通时长周期,来配置用于已连接UE的寻呼时间表,下面更详细地说明。
[0079] 图7是示出用于已连接UE的寻呼时间表的配置的示例的示意图。多个已连接UE的DRX图案的示例通过实线示出。这些DRX图案具有在这里为范围从4至40个子帧的不同接通时长计数器(OnDurationTimer)以及在这里为范围从32至128个子帧的不同长DRX循环(LongDRX Cycle)周期。在图7的示例中,按照专用于已连接UE的单独寻呼时间表在虚线所示的某些时刻来分发预计送往所考虑的已连接UE的寻呼消息。在这个示例中,CONNECTED模式寻呼时间表的寻呼循环按照与4个子帧的寻呼循环周期对应的最短接通时长计数器来适配。这意味着,所有已连接UE将有机会接收包括关于即将发生的系统信息变化的通知的寻呼消息中的至少一个寻呼消息,如图7的点所示。
[0080] 如图7的示例示意示出,在系统信息变化之前的所谓修改周期的至少一部分、优选地整个周期,分发CONNECTED模式寻呼时间表的寻呼消息。为了减少网络中的信令,当没有系统信息需要更新时,没有寻呼消息按照CONNECTED模式寻呼时间表来分发。但是,在即将发生的系统信息变化之前的修改周期开始时,有益的是开始按照CONNECTED模式寻呼时间表来分发寻呼消息,以便确保将给予所有已连接UE得到关于即将发生的系统信息变化的通知的机会,使得它们将准备好在下一个修改周期中监听并且接收已更新系统信息。
[0081] 图8示出修改周期的基本标准框架的示例及其与系统信息分发的关系。图8的示例涉及LTE和类似系统,但是本发明并不局限于这个特定上下文。
[0082] 当网络改变系统信息(的至少一部分)时,它在实际变化发生之前首先通知UE关于这个变化。这个通知可在修改周期、诸如BCCH(广播控制信道)修改周期(n)期间执行。在下一个BCCH修改周期(n+1)中,网络传送已更新系统信息。图8的两个不同BCCH修改周期的系统信息块中的不同哈希类型指示不同的系统信息。在修改周期(n)中接收到变化通知时,UE则可在下一个修改周期(n+1)开始时获取新的系统信息。然后,UE应用新的已更新系统信息,直到UE再次得到关于即将发生的系统信息变化的通知并且获取新的系统信息。
[0083] 应当理解,虽然所提供技术特别适用于LTE和RRC_CONNECTED UE,但是本发明并不局限于此。该技术可适用于类似无线电通信网络,在类似情况下用于向基于DRX进行操作的已连接UE分发关于即将发生的系统信息变化的通知。
[0084] 图9是示出用于已连接UE的四个不同寻呼时间表相对于成本和可靠性的性能的示意图。
[0085] 如前面所述,能够确保,如果在整个BCCH修改周期期间的每一个子帧中分发寻呼消息,则所有已连接UE将能够接收系统信息通知。这提供最大可靠性,但以相当高成本为代价。
[0086] 将在下行链路子帧的数据区域中的PDSCH(物理下行链路共享信道)上传送的寻呼消息各要求下行链路子帧的控制区域中采取PDCCH(物理下行链路控制信道)的形式的对应指配。但是,视情况而定,PDCCH往往可能是稀有资源。为了避免使PDCCH过载,包含CONNECTED模式寻呼时间表的寻呼循环的适配会是明智的。如前面所述,优选地基于最短配置的所谓接通时长周期-在标准规范中又称作“接通时长计数器”-来适配CONNECTED模式寻呼循环。为了得到最低可能的PDCCH负荷并且同时确保每个已连接(RRC_CONNECTED)UE接收可能包括系统信息指示的单独UE公共连接模式寻呼时间表的寻呼消息中至少一个寻呼消息的可能性,应用与处于连接模式的UE的最短配置的接通时长计数器对应的CONNECTED模式寻呼循环。换言之,连接模式寻呼时间表包括基于与给定小区关联的处于连接模式的多个用户设备的不连续接收(DRX)的最短配置接通时长周期的寻呼循环。更具体来说,在系统信息变化之前的广播控制信道(BCCH)修改周期期间的至少每第n个子帧传送寻呼消息,其中n对应于不连续接收(DRX)的最短配置接通时长周期。这以适当低的成本来提供高可靠度。
[0087] 另一种变型包括在与给定小区关联的处于连接模式的多个用户设备的最长不连续接收(DRX)循环周期期间的多个子帧的每个子帧中传送寻呼消息。这以适当低的成本来提供适度可靠性。
[0088] 还有可能使用基于最短接通时长周期的寻呼循环,但是仅在最长DRX循环周期(假定它比总BCCH修改周期更短)期间。这给予甚至更低的成本,但是也给予较低程度的可靠性。
[0089] 为了在确保接收系统信息变化通知的可能性的同时进一步降低PDCCH负荷而没有引起负荷峰值,应当在其后没有跟随任何实际系统信息更新的所有修改周期期间完全停用CONNECTED模式寻呼循环。这是可能的,因为CONNECTED模式寻呼时间表及关联寻呼消息完全被建立用于分发系统信息通知,并且因此是寻呼UE完全不需要的。基本上,这意味着,在没有系统信息需要更新的周期期间,没有寻呼消息按照连接模式寻呼时间表来分发。
[0090] 在RRC_CONNECTED UE的特定上下文中,改进负荷分配的可能性通过下列步骤来实现:将RRC_CONNECTED DRX图案从RRC_IDLE寻呼循环分离(decouple),并且仔细配置用于在寻呼消息中分发关于系统信息变化的通知的单独RRC_CONNECTED模式寻呼时间表。在一个示范实施例中,通过利用对于所有RRC_CONNECTEDUE公共的寻呼时间表、适合于配置的接通时长计数器的寻呼循环周期以及通过当没有系统信息将要更新时能够停用RRC_CONNECTEDUE的整个附加寻呼循环,来限制PDCCH上的负荷。
[0091] 可例如通过硬件和/或软件和运行软件的处理硬件的适当组合,将上述过程作为无线电基站或类似单元中的功能单元来实现。
[0092] 图10是按照一个示范实施例的无线电基站的示意框图。无线电基站(RBS)10基本上包括:第一分发器12,配置成按照用于处于IDLE模式的用户设备20的第一寻呼时间表来分发寻呼消息;以及第二分发器14,配置成按照用于处于CONNECTED模式的用户设备的第二寻呼时间表来分发寻呼消息。
[0093] 用于处于CONNECTED模式的用户设备22的第二寻呼时间表与用于处于IDLE模式的用户设备的第一寻呼时间表不同。
[0094] 如前面所述,DRX用于允许UE在大部分时间睡眠,其中切断UE接收器电路,并且仅周期地唤醒短时段,以便监视寻呼信道。对于处于IDLE模式的UE,DRX图案与第一寻呼时间表对准。第一分发器12通常向IDLE模式UE分发适用时包括关于即将发生的系统信息变化的通知的标准寻呼信息。第二分发器14配置成按照用于处于CONNECTED模式的用户设备的第二寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知。
[0095] 无线电基站当然包括普通无线电链(未明确示出)以及用于支持寻呼消息的传输的一个或多个天线。
[0096] 虽然第一分发器12和第二分发器14在图10中示为分开的单元,但是应当理解,它们可在同一电路中作为不同功能单元来实现。
[0097] 现在在下文描述无线电基站的其它示例和/或可选特征。
[0098] 图11是按照另一个示范实施例的无线电基站的示意框图。图11的无线电基站10包括用于IDLE模式的第一分发器12、用于CONNECTED模式的第二分发器14、与第一分发器12和第二分发器14关联的寻呼调度器16以及与寻呼调度器和/或分发器12和14关联的控制器18。
[0099] 第一分发器12配置成按照用于处于IDLE模式的用户设备的第一寻呼时间表来分发寻呼消息。它向IDLE模式UE分发适用时包括关于即将发生的系统信息变化的通知的标准寻呼信息。第二分发器14配置成按照用于处于CONNECTED模式的用户设备的第二寻呼时间表在寻呼消息中分发关于即将发生的系统信息变化的通知。寻呼调度器16和/或控制器18可帮助配置寻呼时间表,除非在分发器12和14中实现缺省或人工配置的寻呼时间表。
[0100] 在一个示范实施例中,空闲模式对应于无线电资源控制(RRC)空闲模式,而连接模式对应于RRC连接模式。优选地,第二分发器14配置成在系统信息变化之前的修改周期的至少一部分期间按照第二寻呼时间表来分发寻呼消息。
[0101] 第二分发器14通常配置成按照对于与无线电基站的给定小区关联的已连接用户设备而言公共的第二寻呼时间表来分发寻呼消息。换言之,通常每个小区存在一个CONNECTED模式寻呼时间表。如该表达所示,CONNECTED模式寻呼时间表优选地专用于处于连接模式的用户设备。按照第二寻呼时间表的寻呼消息通常还专用于分发系统信息变化通知。
[0102] 寻呼调度器16优选地配置成使用于处于连接模式的用户设备的第二寻呼时间表与用于处于空闲模式的用户设备的第一寻呼时间表无关。寻呼调度器16可与控制器18关联,控制器18提供能够用于控制寻呼时间表的某种控制输入信息。具体来说,控制器18可配置成定义第二寻呼时间表,使得在没有系统信息需要更新时的周期期间,没有寻呼消息被分发。根据需要并且在需要时,诸如DRX接通时长周期和DRX循环周期之类的相关DRX信息以及关于BCCH修改周期的信息等等将是寻呼调度器16和/或控制器18可用的。
[0103] 将会有益的是,将用于CONNECTED模式的第二分发器14配置成基于如下寻呼循环来分发寻呼消息,即该寻呼循环的循环周期充分短以便可应用于与无线电基站10的给定小区关联的多个已连接用户设备中的每个用户设备。例如,可应用结合图9所述的任何CONNECTED模式寻呼时间表。
[0104] 在图10和图11的上述框图中,仅明确示出涉及分发系统信息通知的单元。因此,预期无线电基站包括其传统操作中使用的其它单元和功能性。例如,无线电基站可基于长期演进(LTE)系统的演进NodeB(eNodeB)。
[0105] 以上所述的实施例要被理解为本发明的少数说明性示例。本领域的技术人员会理解,在没有背离本发明的范围的情况下,可对实施例进行各种修改、组合和变更。具体来说,不同实施例中的不同部分解决方案能够在技术上可能的情况下以其它配置相组合。但是,本发明的范围由所附权利要求来定义。
[0106] 参考文献
[0107] [1]3GPP TS 36.211
[0108] [2]3GPP TS 36.212
[0109] [3]3GPP TS 36.321
[0110] [4]3GPP TS 36.331
QQ群二维码
意见反馈