用于机器类型通信的增强型寻呼机制

申请号 CN201280001240.2 申请日 2012-07-11 公开(公告)号 CN103339967A 公开(公告)日 2013-10-02
申请人 联发科技股份有限公司; 魏宏宇; 发明人 徐家俊; 魏宏宇; 林冠宇; 周敬淳;
摘要 提出在第三代合作计划网络中用于机器类型通信装置的增强型寻呼机制。首先,提出自适应寻呼用于机器类型通信装置自适应分配额外的寻呼时段,不具有任何普通用户设备的额外 进程 或电量消耗。其次,提出分组寻呼以利用一个寻呼同时呼叫多个机器类型通信装置。为了优化信令以及更简管理,在不同层控制分组寻呼。在一 实施例 中,利用了分组广播与分组释放。最后,提出具有响应方案的寻呼以预定义或动态配置机器类型通信装置的寻呼响应方案。
权利要求

1.一种方法,包含:
移动通信网络中由机器与机器装置接收从基站发送的寻呼消息,其中该寻呼消息指示一组或多组机器与机器装置;
基于寻呼匹配规则与寻呼响应策略决定是否响应该寻呼消息;
在该移动通信网络中与该基站建立连接;以及
从该基站接收分组广播消息,其中该分组广播消息包含分组无线电网络临时标识码。
2.如权利要求1所述的方法,进一步包含:
该机器与机器装置接收分组标识码配置信息,其中该机器与机器装置配置分组标识码。
3.如权利要求2所述的方法,其中该分组标识码包含由移动管理实体发送的分组伺服临时移动用户标识码。
4.如权利要求2所述的方法,其中该分组标识码包含机器与机器服务器控制的机器与机器应用标识码。
5.如权利要求1所述的方法,其中该匹配规则包含指示多个机器与机器装置或者多个机器与机器分组利用通配符的寻呼掩码。
6.如权利要求1所述的方法,其中该匹配规则包含适用于该分组寻呼标识码以及机器与机器组分类/属性的逻辑操作数。
7.如权利要求1所述的方法,其中该寻呼响应策略明确地包含在该寻呼消息中。
8.如权利要求1所述的方法,其中该寻呼响应策略通过寻呼无线电网络临时标识码、特定寻呼码/标识或者预配置寻呼机会隐性地加载。
9.如权利要求1所述的方法,进一步包含:
从该基站接收分组释放消息,从而如果该机器与机器装置属于该分组释放消息指示的装置类型,则释放该连接。
10.如权利要求1所述的方法,其中只有如果该机器与机器装置已经缓冲了数据,该机器与机器装置尝试建立无线电资源控制连接,以及其中如果不存在已缓冲的数据,则该机器与机器装置不尝试建立无线电资源控制连接。
11.一种机器类型通信装置,包含:
射频模,用于在移动通信网络中接收从基站发送的寻呼消息,其中该寻呼消息指示一组或多组机器与机器装置;
寻呼管理模块,用于基于寻呼匹配规则与寻呼响应策略决定是否响应该寻呼消息;以及
连接管理模块,用于与该基站建立连接使得该机器类型通信装置从该基站接收分组广播消息,其中该分组广播消息包含分组无线电网络临时标识码。
12.如权利要求11所述的机器类型通信装置,其中该射频模块接收分组标识码配置信息,以及其中该机器与机器装置配置分组标识码。
13.如权利要求12所述的机器类型通信装置,其中该分组标识码包含由移动管理实体发送的分组伺服临时移动用户标识码。
14.如权利要求12所述的机器类型通信装置,其中该分组标识码包含机器与机器服务器控制的机器与机器应用标识码。
15.如权利要求11所述的机器类型通信装置,其中该匹配规则包含指示多个机器与机器装置或者多个机器与机器分组利用通配符的寻呼掩码。
16.如权利要求11所述的机器类型通信装置,其中该匹配规则包含适用于该分组寻呼标识码以及机器与机器组分类/属性的逻辑操作数。
17.如权利要求11所述的机器类型通信装置,其中该寻呼响应策略明确地包含在该寻呼消息中。
18.如权利要求11所述的机器类型通信装置,其中该寻呼响应策略通过寻呼无线电网络临时标识码、特定寻呼码/标识或者预配置寻呼机会隐性地加载。
19.如权利要求11所述的机器类型通信装置,其中该射频模块从该基站接收分组释放消息,从而如果该机器与机器装置属于该分组释放消息指示的装置类型,则释放该连接。
20.如权利要求11所述的机器类型通信装置,其中只有如果该机器与机器装置已经缓冲了数据,该机器与机器装置尝试建立无线电资源控制连接,以及其中如果不存在已缓冲的数据,则该机器与机器装置不尝试建立无线电资源控制连接。
21.一种方法,包含:
在移动通信网络中由用户设备监测寻呼时段,其中每个寻呼周期为该用户设备预定义该寻呼时段;
接收从基站发送的寻呼消息,其中该寻呼消息包含继续旗标;
如果该用户设备属于第一装置类型则忽略该继续旗标;以及如果该用户设备属于第二装置类型继续监测寻呼时段,直到如果该继续旗标设定为真则该用户设备接收寻呼为止。
22.如权利要求21所述的方法,其中如果该继续旗标设定为假,该用户设备在不连续接收模式下在每个寻呼周期监测一次寻呼时段。
23.如权利要求21所述的方法,其中该第二装置类型是机器与机器装置类型。
24.如权利要求21所述的方法,其中通过是否忽略该继续旗标或者是否继续监测寻呼时段的信令配置该用户设备。

说明书全文

用于机器类型通信的增强型寻呼机制

[0001] 交叉引用
[0002] 本申请依据35U.S.C.§119要求如下优先权:编号为61/506,463,申请日为2011年7月11日,名称为“Enhanced Paging Mechanism for Machine Type Communication”的美国临时申请。上述申请标的在此一起作为参考。

技术领域

[0003] 本发明有关于机器类型通信(Machine Type Communication,MTC),并且特别有关于在移动网络中用于机器类型通信的增强型寻呼机制。

背景技术

[0004] 机器类型通信涉及一个或多个不需要人类干预的实体的数据通信形式。优化机器类型通信的服务不同于人与人之间(Human-to-Human,H2H)通信的服务。典型地,机器类型通信服务由于涉及不同的市场情况、纯数据通信、更低的成本与代价以及潜在较大数量的每个终端具有极少讯务的通信终端,因此其不同于当前移动网络通信服务。
[0005] 利用术语机器与机器(Machine-to-Machine,M2M)与MTC描述使用实例以及机器类型通信服务的不同特征。M2M与MTC装置将是用于实现“物联网”的下一代无线网络的一部分。M2M与MTC潜在的应用包含安保、追踪、支付、健康、远程维护/控制、计量(metering)以及消费装置。机器类型通信服务的主要特征包含低移动性、时间可控性、延迟容忍性、仅分组切换、低数据传输、仅移动始端、低频移动终端、MTC监视、优先级警报、安全连接、位置特定触发、提供上行链路数据终端的网络、低频传输以及基于分组的MTC特征。
[0006] 第三代合作计划(3rd Generation Partnership Project,3GPP)提供MTC装置与MTC服务器之间或者两个MTC装置之间的端对端(end-to-end)应用。3GPP移动网络提供MTC的优化传输与通信服务。然而,上述移动网络中的M2M装置的数量预计远远大于用户设备(User Equipment,UE)的当前数量,即高数据级的差距(order larger)。由于具有如此大的数量,网络可能用完寻呼资源并且引起额外延迟。例如,由于maxPageRec为16并且无线电的最大寻呼子帧为4,所以移动网络在一秒钟内最多呼叫6400个MTC装置。因此,潜在问题是对于未来的MTC装置,当前的寻呼资源将变得不足。
[0007] 目前存在几个关于在3GPP移动网络中寻呼过载的解决方案。一个解决方案是优先寻呼S1应用协议(S1 Application Protocol,S1AP)以在临时过载时选择性地舍弃寻呼。另一个解决方案是由系统信息区(System Information Block,SIB)修改以动态改变寻呼配置。然而两种解决方案对于MTC装置来说皆不理想。这是因为对于特定的M2M应用,由于节省电量的考虑,其可具有较低的工作周期(duty cycle)。例如,MTC装置仅当具有上行链路数据或者在空闲模式(idle mode)下具有远远长于当前允许的不连续接收(Discontinuous Reception,DRX)时才启动。除了空闲模式下的DRX,如果DRX值不足够长以支持其操作,则MTC装置甚至可具有更长的休眠周期(sleep cycle)。当寻呼事件发生时,MTC装置做下列动作:在寻呼事件之前启动、检查系统信息(System Information,SI)值标签(tag)并且取得最新的SIB;在几个DRX周期内监测实体下链控制信道(Physical Downlink Control Channel,PDCCH)中的寻呼无线电网络临时标识(Paging-Radio Network Temporary Identifier,P-RNTI);如果具有匹配标识码(Identity,ID)则进行响应;以及当时间结束时回到休眠状态。
[0008] 如果寻呼过载发生,基站(eNB)将花费几秒钟来重新配置寻呼信道。在重新配置后,将花费更多的时间来处理拥塞的情况。因此,MTC装置在回到休眠状态之前,eNB可能不会及时寻呼MTC装置。然后延迟可为几分钟甚至几小时。此外,如果eNB决定在过载解决后重新配置寻呼配置,则普通UE在无任何好处的情况下必须两次取得SIB。因此,上述的寻呼过载问题将降低在空闲模式下普通UE的效能。

发明内容

[0009] 本发明提出在第三代合作计划网络中用于机器类型通信装置的增强型寻呼机制。首先,提出自适应寻呼用于机器类型通信装置自适应分配额外的寻呼时段,不具有任何普通使用者设备的额外进程或电量消耗。其次,提出分组寻呼以利用一个寻呼同时呼叫多个机器类型通信装置。为了优化信令以及更简管理,在不同层控制分组寻呼。在一实施例中,利用了分组广播与分组释放。然后,提出具有响应方案的寻呼以预定义或动态配置机器类型通信装置的寻呼响应方案。
[0010] 在自适应寻呼中,可自适应分配额外的寻呼时段。在一实施例中,在寻呼消息中引入“继续”旗标。当基站不能在相应的寻呼事件中插入所有寻呼时,将“继续”旗标设定为真。普通用户设备将忽略上述旗标并且按照传统行为进行。然而,对于机器类型通信装置,当设定旗标时,如果还未接收到寻呼,机器类型通信装置将继续监测寻呼事件,而不是直到下一个寻呼事件之前进入不连续接收。一旦上述机器类型通信装置接收了寻呼,则不考虑旗标停止寻呼监测并且响应上述寻呼。
[0011] 分组寻呼是机器类型通信装置的增强寻呼效能的另一机制。机器与机器分组在许多层皆是有帮助的。在存取层,可为机器与机器分组配置分组标识码。一个寻呼可用于寻呼在监测寻呼分组中的所有机器类型通信装置。基站可控制上述机器与机器分组以节省存取层资源。在非存取层,机器与机器分组可在核心网络层执行以节省信令开销,例如,可由移动管理实体控制。在应用层,为了更简管理,机器类型通信用户或机器类型通信服务器可控制机器与机器分组。不同层的机器与机器分组可为独立的或者共存以提供灵活性。分组寻呼可用于分组广播。在某些机器类型通信应用中,例如,运行管理维护或软件升级,消息的内容对于机器类型通信装置分组很可能是相同的。因此,分组广播是有帮助的并且可节省无线电资源。
[0012] 对于机器与机器寻呼,当寻呼消息包含装置标识码时,其可具有两种可能涵义。在第一涵义中,一旦接收了寻呼,被寻呼机器类型通信装置必须启动并且建立连接(移动终端时段)。在第二涵义中,网络询问被寻呼机器类型通信装置是否将启动以建立连接(移动始端时段)。因此,寻呼消息应该指示被寻呼机器类型通信装置是否应该立即响应(移动终端时段)或者是否应该只基于移动始端数据的可用性进行响应(移动始端时段)。除了指示不同的寻呼响应,可配置不同的响应策略以优化寻呼效能。在第一实施例中,装置预定义寻呼响应策略。在第二实施例中,可动态安排寻呼响应策略。
[0013] 其他实施例以及优势将在下面作详细描述。本发明内容不限定本发明,本发明由权利要求限定。附图说明
[0014] 本发明的附图用于说明本发明的实施例,其中相同的标号代表相同的组件。
[0015] 图1是根据新颖方面描述的支持MTC增强型寻呼的3GPP网络。
[0016] 图2是根据新颖方面描述的MTC装置的示意图。
[0017] 图3是根据新颖方面描述的移动通信网络中用于MTC装置的增强型寻呼机制。
[0018] 图4是描述在3GPP网络中定义的寻呼帧以及寻呼时段。
[0019] 图5是描述用于MTC装置的自适应寻呼设计的一个实施例。
[0020] 图6是描述3GPP网络中的分组寻呼。
[0021] 图7是描述用于分组寻呼的RRC寻呼消息。
[0022] 图8是描述利用G-IMSI作为分组寻呼ID的分组寻呼实施例。
[0023] 图9是描述利用G-S-TMSI作为分组寻呼ID的分组寻呼实施例。
[0024] 图10是描述利用分组寻呼机制的分组广播的一实施例。
[0025] 图11是描述关联MO时段或者MT时段的寻呼示例。
[0026] 图12是描述动态安排寻呼响应策略的两种选择。

具体实施方式

[0027] 关于本发明的多个实施例将作为详细参考,附图是为描述本发明的实施例所作。
[0028] 图1是根据新颖方面描述的支持MTC增强型寻呼的3GPP网络100。3GPP网络100包含MTC服务器111,MTC服务器111通过与多个MTC装置(例如图1所示的MTC装置114)通信向MTC用户112提供各种MTC服务。在图1的示例中,MTC服务器111、MTC用户112以及分组数据网关(Packet Data Network Gateway,PDN GW)属于核心网络110的一部分。MTC装置114与服务的基站115属于无线电存取网络(Radio Access Network,RAN)120的一部分。MTC服务器111通过PDN GW 113、服务网关(Serving Gateway,S-GW)116以及基站115与MTC装置114通信。此外,移动管理实体(Mobility Management Entity,MME)117与基站115、S-GW 116以及PDN GW 113进行通信用于3GPP网络100中无线电存取装置的移动管理。值得注意的是,相比于人与人通信,术语MTC称为M2M通信,于此同时相比于人与人装置,MTC装置称为M2M装置。
[0029] 在图1的示例中,MTC服务器111在应用协议层通过已建立的应用程序编程接口(Application-Programming Interface,API)140向MTC用户112提供各种MTC服务/应用。典型的MTC应用包含安保(例如监控系统)、追踪定位(例如里程保险服务)、支付(例如自动售货机以及游戏机)、健康(例如健康说服系统)、远程维护/控制、量测(例如智能电网)以及消费装置(例如电子书)。为了提供端对端MTC服务,在3GPP网络中MTC服务器111与多个MTC装置进行通信。每个MTC装置(例如MTC装置114)包含各种协议层模块以支持端对端MTC应用以及数据连接。在应用层,应用(Application,APP)模块131在APP协议层上与MTC服务器111通信(例如虚线141所示),其中APP模块131提供端对端控制/数据。在网络层,非存取层(Non-Access Stratum,NAS)模块132在NAS协议层与MME 117通信(例如虚线142所示),其中NAS模块132支持移动管理以及其他信令功能。在RAN层,无线电资源控制(Radio Resource Control,RRC)模块133在RRC协议层与基站115通信(例如虚线143所示),其中RRC模块133负责系统信息广播、RRC连接控制、寻呼、无线电配置控制、服务质量(Quality of Service,QoS)控制等。
[0030] 在移动通信网络中,可利用寻呼来搜索空闲UE以及建立信令连接。例如,到达S-GW的下行链路数据包触发寻呼。当S-GW接收目标为空闲UE的下行链路数据包时,其不具有向eNB发送数据包的eNB地址。替换地,S-GW通知MME下行链路数据包已经到达。MME获知UE在哪个追踪区域(Tracking Area,TA)漫游并且MME向TA清单中的所有eNB发送寻呼请求。一旦接收到寻呼消息,UE响应MME并且激活承载(bearer)使得下行链路数据包发送至UE。
[0031] 存在3GPP网络中定义的各种寻呼程序。对于长期演进技术(Long Term Evolution,LTE)核心网络(Core Network,CN),网络可利用寻呼程序以请求与UE的NAS信令连接的建立。寻呼程序的另一目的是由于网络失败如果需要提示UE重新获取。另外,网络可利用寻呼程序建立移动终端向后支持电路交换(Circuit Switched,CS)程序。对于LTE RAN,可利用寻呼向在RRC_IDLE中的UE发送寻呼信息;将系统信息改变通知至在RRC_IDLE或RRC_CONNECTED中的UE;通知地震海啸预警系统(Earthquake and Tsunami Warning System,ETWS)主要通知及/或ETWS次级通知;及/或通知商业移动预警系统(CMAS)。
[0032] 预计移动网络中的M2M装置的数量远远大于目前UE的数量,即高数量级的差距。由于数量较大,网络可用完寻呼资源并且产生额外延迟。例如,在无线电帧中maxPageRec为16并且最大寻呼子帧为4时,移动网络在一秒钟最多可寻呼6400个MTC装置。因此,一个潜在问题是当前的寻呼资源对于将来的MTC装置是不足的。此外,对于某些M2M应用,处于节省电量的考虑,其具有较低的工作周期。因此,如果由于较低优先级选择性的舍弃MTC寻呼,寻呼过载可引起对MTC装置不可接受的长延迟,或者如果系统信息(例如SIB)调整动态改变了寻呼配置,因为普通UE必须获得两次SIB,则降低了空闲模式下普通UE的电量效能。
[0033] 在一新颖方面,可将增强型寻呼机制应用于3GPP网络的MTC装置中。首先,提出自适应寻呼用于MTC装置自适应分配额外的寻呼时段(Paging Occasion,PO),不具有任何普通UE的额外过程或电量消耗。其次,提出分组寻呼以利用一个寻呼同时呼叫多个MTC装置。另外提出了分组广播与分组释放。然后,提出具有响应方案的寻呼以预定义或动态配置MTC装置的寻呼响应方案。
[0034] 图2是根据新颖方面描述的MTC装置201的示意图。MTC装置201包含存储器211、处理器212、耦接天线214的射频模块213、基带模块215、支持各种协议层的3GPP协议栈模块226、TCP/IP协议栈模块227、应用模块228以及包含寻呼管理模块231与连接管理模块232的管理模块230,上述各种协议层包含NAS 225、RRC 224、分组数据汇聚协议/无线电连接控制(Packet Data Convergence Protocol/Radio Link Control,PDCP/RLC)223、介质访问控制(Media Access Control,MAC)222以及实体(Physical,PHY)221。各种模块是功能模块并且由软件、固件硬件或其任意组合实施。当处理器212执行功能时(通过包含在存储器中的程序说明),上述功能模块相互协作以允许MTC装置201执行自适应寻呼、分组寻呼、分组广播及/或具有对应响应策略的寻呼。例如,当连接管理模块232负责建立/释放与网络的连接时,寻呼管理模块231负责监测寻呼时段并且响应寻呼。
[0035] 图3是根据新颖方面描述的移动通信网络中用于MTC装置的增强型寻呼机制。在图3的示例中,多个MTC装置(例如MTC装置310)通过基站320以及MME 330与MTC服务器340进行通信。在步骤351,MTC服务器340将下行链路数据包发送至MTC装置310。在步骤352,MME 330向基站320发送寻呼请求。在步骤353,基站320向MTC 310发送RRC寻呼消息。最终,在步骤354,MTC 310接收上述寻呼消息并且向基站320发送回寻呼响应。在第一新颖方面,MTC装置310基于包含在寻呼消息中的“继续旗标”自适应地监测寻呼时段。
在第二新颖方面,MTC装置310利用分组寻呼ID监测寻呼通道,其中可在AS层、NAS层、应用层或者单独或者任意结合控制。在第三新颖方面,MTC装置310基于预定义或动态安排寻呼策略响应寻呼消息。
[0036] 图4是描述在3GPP网络中定义的寻呼帧(Paging Frame,PF)以及寻呼时段。寻呼帧为一个无线电帧,其可包含一个或多个寻呼时段。PF由下列公式给出:
[0037] SFN mod T=(T/N)*(UE_ID mod N)
[0038] 其中
[0039] -T=min(TC,TUE):特定UE与特定小区之间的最小DRX周期
[0040] ○在系统信息中广播默认DRX周期
[0041] ○上层配置UE特定DRX
[0042] -N=min(T,nB):上述UE寻呼周期中的寻呼帧数量
[0043] ○nB={4T,2T,T,T/2,T/4,T/8,T/16,T/32}(SIB2,IE nB)
[0044] -UE_ID=IMSI mod 1024(存储在USIM中)
[0045] 寻呼时段为子帧,其中可存在PDCCH上发送的为寻呼消息提供方向的P-RNTI。如列表410所示,利用寻呼消息用于寻呼以及系统信息改变通知。用于寻呼的传输信道称为寻呼信道(Paging Channel,PCH),并且用于寻呼的逻辑信道称为寻呼控制信道(Paging Control Channel,PCCH)。如列表420(用于分频多任务)与列表430(用于分时多任务)所示,从子帧类型指向PO的指标i_s从下列公式中取得:
[0046] i_s=floor(UE_ID/N)modNs
[0047] 其中
[0048] -Ns=max(1,nB/T)=max(1,{4,2,1,1/2,1/4,1/8,1/16,1/32})=1,2或4[0049] -i_s=floor(UE_ID/N)mod Ns=1,2或4
[0050] 当网络中预定义PF与PO时,然而寻呼MTC装置的数量随时间的不同而不为常数。在某些情况下,上述数量远远大于当前的容量。通常,如果考虑MTC寻呼的第二优先级,则由于不足的寻呼空间,存在网络不能及时在装置的PO中插入装置ID的情况,这样可引起显著延迟。这样不清楚网络可提供何种程度的寻呼。如果网络甚至不能提供寻呼负载,并且由于较长延迟寻呼请求连续的丢失寻呼,由于“重新寻呼”将在核心网络中引起更多的寻呼请求。某些不走运的MTC装置可遭受无限期的寻呼停止。
[0051] 图5是描述用于MTC装置的自适应寻呼设计的一个实施例。空闲模式下的普通UE在每个DRX周期内只必须启动一个子帧(PO)。典型地,MTC装置运用UE特定DRX值的最长DRX周期。除了空闲模式下的DRX,如果DRX值对于操作来说不足够长,则MTC装置可具有更长的休眠周期。在休眠模式下,MTC装置完全关闭其无线电,并且在休眠模式下MTC用户或网络不能到达/触发/寻呼MTC装置。因此,如图5所示,用于MTC装置的PO在寻呼周期N的子帧#1,以及在接下来的寻呼周期N+1的子帧#2发生。在每个寻呼周期中,MTC装置监测其PO并且进入DRX直到下一个PO。例如,如果MTC装置在子帧#1不能接收寻呼,则其进入DRX直到子帧#2的下一个PO。
[0052] 在自适应寻呼下,可自适应安排额外的寻呼时段。在图5的实施例中,可在寻呼消息中引入“继续”旗标。当基站在对应的PO中不能插入所有的寻呼时,可将“继续”旗标设定为真。普通UE将忽略上述旗标并且按照传统方式进行。然而对于MTC装置,当设定了旗标时,如果未接收到寻呼,MTC装置将“继续”监测PO而不是进入DRX直到下一个PO。例如,MTC装置在接下来的N寻呼子帧中监测PDCCH,其中N可为1、2、3等。旗标可能包含N或者N是预定义的。另外可配置MTC装置的哪个分组需要监测额外的PO(例如子帧#3)。例如,通过RRC或NAS的专用信令可配置MTC装置忽略旗标。基站亦可广播通知MTC分组应该继续监测寻呼子帧。一旦MTC装置接收了寻呼,则不考虑上述旗标停止寻呼监测并且响应上述寻呼。
[0053] 分组寻呼是MTC装置增强寻呼效能的另一机制。M2M分组可用于许多层。在AS层,可为M2M分组配置分组ID。可利用一个寻呼以寻呼监测寻呼分组中的所有MTC装置。基站可控制上述M2M分组以节省AS资源。在NAS层,可在核心网络层应用M2M分组以节省信令开销,例如由MME控制。在应用层,MTC用户或MTC服务器可控制M2M分组以用于更简管理。不同层的M2M分组可为独立的或者共存以提供灵活性。
[0054] 图6是描述3GPP网络中的分组寻呼。移动通信网络600包含MTC服务器610、PDN GW 620、S-GW 630、MME 640、基站641与642以及大分组M2M装置650。在图6的示例中,由于装置管理,例如软件升级或定期轮询(periodic polling),MTC服务器需要分组中的每个MTC装置皆作岀响应。在没有分组寻呼的支持下,寻呼信令需要一个一个地完成。在具有分组寻呼的支持下,MTC服务器610基于所有MTC装置650的M2M应用建立具有分组ID的M2M分组。MTC服务器610向MME 640发送分组ID,接着MME 640向已连接的基站641与642发送具有分组ID的寻呼请求,并且基站641与642将分组ID插入寻呼消息。通过分组寻呼的支持可优化信令。
[0055] 图7是描述RRC寻呼消息700的一个示例。寻呼消息包含寻呼纪录列表。每个寻呼纪录包含UE标识码,其在国际移动用户标识码(International Mobile Subscriber Identity,IMSI)与伺服临时移动用户标识码(Serving Temporary Mobile Subscriber Identity,S-TMSI)作出选择。可利用各种分组ID用于组寻呼。在第一实施例中,基于IMSI执行分组寻呼。在第二实施例中,基于S-TMSI执行分组寻呼。
[0056] 图8是描述利用分组IMSI作为分组寻呼ID的分组寻呼实施例。除了IMSI,可利用分组IMSI(Group IMSI,G-IMSI)配置每个MTC装置。对于每个G-IMSI与IMSI,上层应该指示是否应跟随对应寻呼时段。在步骤851,MTC装置组810向MTC服务器840预定(subscribe)MTC服务。在步骤852,MTC服务器840利用预定信息确认MTC装置,预定信息包含分组寻呼ID(G-IMSI)。在本示例中,MTC服务器预定义寻呼分组并且将其存储在每个MTC装置的SIM中(步骤853)。MME 830维持G-IMSI的TA清单(步骤854)。在步骤855,MME 830向涉及的基站820发送寻呼请求。在步骤856,基站820向MTC装置组810发送寻呼消息。可利用新的机制监测PO的G-IMSI,G-IMSI不如IMSI频率高(步骤857)。例如,为G-IMSI定义不同的寻呼周期或nB。最终,在匹配包含在寻呼消息中的G-IMSI后,MTC装置810向基站820发送回寻呼响应(步骤858)。典型地,建立RRC连接并且激活用于MTC装置的承载。
[0057] 图9是描述利用分组S-TMSI作为分组寻呼ID的分组寻呼实施例。除了S-TMSI,当连接到网络时可利用分组S-TMSI(Group S-TMSI,G-S-TMSI)配置每个MTC装置。在步骤951,MTC装置组910与一个或多个基站920建立RRC连接。在步骤952,MME 930向MTC装置发送NAS信令消息。NAS信令消息包含为MTC装置配置分组寻呼ID(G-S-TMSI)的配置信息。在本示例中,G-S-TMSI寻呼分组是灵活的并且可由NAS信令改变。例如,MME 930可基于其自身决定或者来自本籍用户服务器(Home Subscriber Server,HSS)的信息以配置分组。在步骤953,MME 930维持G-S-TMSI的TA清单。在步骤954,MME 930向涉及基站
920发送寻呼请求。在步骤955,基站920向MTC装置组910发送寻呼消息。在步骤956,MTC装置910监测PO。G-S-TMSI分组不能改变寻呼监测。最终,在匹配包含在寻呼消息中的G-S-TMSI后,MTC装置910向基站920发送回寻呼响应(步骤957)。典型地,建立RRC连接并且激活用于MTC装置的承载。
[0058] 可利用其他机制进一步加强分组寻呼支持。例如,可利用随分组寻呼ID发送过来的其他规则提供颗细性(finer granularity)或者更大灵活性。在一实施例中,寻呼规则可包含用于装置分组ID的“掩码”或者“通配符”。例如,可利用问号“?”作为或为0或为1的通配符。分组寻呼ID“101011??”表示要寻呼具有“10101100”、“10101110”、“10101101”、“10101111”装置ID的所有装置。在另一实施例中,可为分组寻呼ID提供操作数(operand)。为了执行复杂分组寻呼任务,可利用逻辑操作数AND/OR/NOT、M2M分类及/或属性、掩码共同构成分组寻呼规则。例如,一种寻呼规则可为寻呼具有优先级为1并且分类为智能电表的所有MTC装置,另一寻呼规则可为寻呼属于寻呼组为111100??并且属性为定期报告的所有MTC装置。
[0059] 寻呼分组可在不同层进行不同管理。在第一示例中,整个公共陆地移动网络(Public Land Mobile Network,PLMN)共享相同的寻呼分组。一个基站或者TA 下的分组X与另一基站或者TA下的分组X属于相同寻呼分组X。在第二示例中,整个TA共享相同的寻呼分组。在一个TA下的分组Y与在另一个TA下的分组Y是不同的。在相同TA中,在一个基站下的分组Y'与在另一个基站下的分组Y'属于相同的寻呼分组Y'。在第三示例中,寻呼分组在特定基站下是单一的。在一个基站下的分组Z与在另一个基站下的分组Z是不同的。另外可优化寻呼分组的大小。如果寻呼分组太大,可引起高随机存取信道(Random Access Channel,RACH)冲突可能性,这导致更长的延迟与更多电量消耗。另一方面,如果寻呼组太小,则不能充分利用RACH资源。当从PLMN或MTC服务器请求分组寻呼时,发送组标识码(可选择操作数与规则)而不是发送完整的UE标识码(IMSI或者S-TMSI)。一旦配置了分组标识码,MTC装置监测在对应寻呼时段与资源中的分组的寻呼。如果存在匹配分组标识码或者符合规则组合,则响应上述寻呼。
[0060] 可利用分组寻呼用于分组广播。在某些MTC应用中,例如运行管理维护(Operations,Administration,and Maintenance,OAM)或者软件升级,消息内容对于MTC装置分组很可能是相同的。因此,分组广播是有用的并且可节省无线电资源。图10是描述在3GPP网络中分组广播的实施例。在步骤1051,MTC服务器1040向MME 1030发送分组ID,其中根据可选择的目的指示,例如分组软件升级。在步骤1052,MME 1030向一个或多个具有分组ID的涉及基站1020发送寻呼请求。在步骤1053,基站1020将分组ID插入寻呼消息并且将上述寻呼消息发送至MTC装置组1010。MTC装置监测PO的分组ID(步骤1054)。一旦接收了寻呼消息,MTC装置1010与基站1020建立RRC连接(步骤1055)。在连接建立或RRC重新配置期间安排分组无线电网络临时标识(Group-Radio Network Temporary Identifier,G-RNTI)。MTC装置1010亦连接MME 1030并且向S-GW建立承载(步骤1056)。
在步骤1057,MME/S-GW利用分组ID将软件升级消息发送至基站1020。升级消息用于分组中的所有MTC装置。
[0061] 在步骤1058,基站1020利用G-RNTI将升级消息广播至分组中的所有MTC装置。分组中的MTC装置利用G-RNTI用于广播数据的PDCCH监测(例如软件升级)。如果不存在混合式自动重传请求(Hybrid Automatic Repeat reQuest,HARQ),与广播控制信道(Broadcast Control Channel,BCCH)相似(小区广播信道,例如BCCH上的新SIB),利用PHY机制保证成功率,例如,重复或者传输时间间隔(Transmission Time Internal,TTI)绑。如果利用HARQ,则基站假定HARQ回馈是非应答的(Non-Acknowledge,NACK)直到达到最大HARQ重传。MTC装置成功地接收将不发送任何消息的TB,MTC装置不能译码将发送NACK的TB,以及如果至少存在一个已接收的NACK,基站将重新发送。可在MAC中执行NACK而不是在PHY中。在步骤1059,MTC装置1010执行软件升级。
[0062] 可利用分组释放命令释放已连接的MTC装置组(步骤1060)。例如,利用信令消息作为RRCConnectionRelease的广播版本以指示装置的应用类型。当低优先级装置发现上述消息时,执行RRC连接释放(RRC Connection Release)以释放资源。可在细胞广播信道上发送上述消息(BCCH上的新SIB)至仅涉及的MTC装置收听。
[0063] 图11是描述关联MO时段或者MT时段的M2M寻呼示例。对于M2M寻呼,当寻呼消息包含装置ID时,其可具有两种可能的涵义。在第一种涵义中,一旦接收了上述寻呼(步骤1131),被寻呼的MTC装置必须启动并且建立连接(步骤1132)(MT时段)。在第二种涵义中,网络询问被寻呼的MTC装置是否想启动以建立连接(MO时段)。一旦MTC装置接收了特定寻呼(步骤1133),则其确定是否符合条件并且需要利用MO数据进行回复(步骤1134)。如果MTC装置决定回复MO数据,则必须启动连接建立过程,例如,RACH前导传输(步骤1135)。
[0064] 如果数据讯务是可预测的,则来自CN或MTC服务器的轮询MO为一灵活方案以实施端对端负载控制。MO的基于寻呼方案的主要优势在于其灵活性,例如与BCCH控制的预定义时间安排方案相比较。MO寻呼可在先前卸除讯务。对于延迟容忍应用,例如读表,亦可能完全停止MO请求并且唯一回复MO寻呼以从MTC装置中得到数据。这样由于协调MO时段创造的讯务突发(traffic burst),例如同一时间不同类型的读表,可减少RAN过载(例如RACH过载)的可能性。除了MO,需要所有MTC装置支持MT时段,例如,为了OAM或软件升级的目的。因此,寻呼消息应该指示要寻呼的MTC装置是否应该立即响应(MT时段)或者是否应该只基于MO数据的可用性进行响应(MO时段)。
[0065] 不同寻呼响应的指示可以各种方式实施。在第一示例中,寻呼消息中存在旗标或者配置选项,例如,“MO寻呼”或者“MT寻呼”。在第二示例中,可利用不同的P-RNTI。在第三示例中,可利用特定寻呼代码或者寻呼ID。在第四示例中,MTC装置可适用于预配置寻呼情况(例如,在某些寻呼情况中发送普通寻呼(MT)以及在另外寻呼情况下发送特定寻呼(MO))。
[0066] 除了指示不同寻呼响应,可配置不同响应策略以优化寻呼效能。在第一实施例中,为装置预定义寻呼响应策略(paging response policy)。例如,在接收寻呼消息后,可配置装置具有三种响应策略。对于第一种策略,装置必须立即连接网络。对于第二种策略,装置必须连接网络,但可具有一定程度的延迟。可联合该策略与网络进入拥塞改善技术(network entry congestion alleviation technique)。对于第三种策略,装置可或者不可连接网络,例如,只有当存在缓冲数据(buffered data)时,装置连接网络。装置可基于是否存在报告的数据(及/或报告数据的优先级)作出决定。装置亦可基于网络负载状态作出决定。
[0067] 在第二实施例中,可动态安排寻呼响应策略。可在寻呼消息中定义寻呼响应策略(例如,信息单元或旗标位、概率信息)。对于概率信息,可利用分组标识码以及概率执行寻呼(在每个UE的基础上执行随机化),而不是单独轮询多个装置。这对于特定应用来说是有用的,例如,收集分组状态。例如,装置掷出骰子并且与给定概率进行比较以确定其是否连接到网络。寻呼响应策略亦可在装置进入空闲模式(例如撤销消息或其他信令)之前或者同时进行配置。
[0068] 图12是描述动态安排寻呼响应策略的两种选择。在图11的示例中,寻呼消息包含寻呼响应策略。例如,可通过寻呼消息携带加载策略(loading-aware policy)及/或差异式接入分级策略(differentiated access class policy)。在第一选择中,在一个寻呼消息中,应用上述策略的寻呼装置ID集合紧跟着每个策略标识。例如,寻呼装置ID1、ID2、ID3、ID4在策略标识I下应用响应策略,与此同时,寻呼装置ID5、ID6、ID7在策略标识II下应用另一响应策略。在第二选择中,在一个寻呼消息中,对应的策略标识紧跟着每个寻呼装置ID。例如,具有ID1-ID4的每个寻呼装置关联于策略标识I,与此同时,具有ID5-ID6的每个寻呼装置关联于策略标识II。
[0069] 虽然为了说明目的已经描述了与本发明联系的特定的实施例,然本发明并不局限于此。因此,对上述实施例的多个特征所作的各种修改、调整以及组合,皆视为未超出本发明的权利要求的范围。
QQ群二维码
意见反馈