用于小区重选增强的方法以及用户设备与流程

文档序号:17688926发布日期:2019-05-17 20:52阅读:233来源:国知局
用于小区重选增强的方法以及用户设备与流程

本申请依据35U.S.C.§119要求2013年5月10日递交的,申请号为61/821,801标题为“用于功率节省LTE装置的超长DRX(Super Long DRX for Power Saving LTE Device)”的美国临时申请案的优先权,上述申请的标的在此合并作为参考。

技术领域

本发明所揭露实施例一般有关于移动通信网络装置,以及更具体地,有关于用于功耗优化(power consumption optimization)的UE增强(enhancement)。



背景技术:

LTE是改进的通用移动电信系统(Universal Mobile Telecommunication System,UMTS),LTE提供更高数据率,更低延迟以及改进的系统容量。在LTE系统中,演进通用陆地无线接入网络(Universal Terrestrial Radio Access Network)与多个移动台通信,演进通用陆地无线接入网络包含多个基站,称作演进节点B,移动台称作用户设备(User Equipment,UE)。UE可以透过DL以及UL与基站或者eNB通信。DL指从基站到UE的通信。UL指从UE到基站的通信。

虽然LTE系统中有改进,但是随着不同移动用户的快速增长依然面临容量(capacity)以及效率(efficiency)问题。特别地,在移动网络中的多个UE面临功率增加的问题。功耗对于电池供电的UE以及使用外部电源供电的UE而言是重要的。重要性随着装置数量的持续增长以及更多需求使用情况的增加而增加。智能用户的快速崛起以及不同类型装置,例如机器类型通信(Machine Type Communication,MTC)装置的产生,对于功率构成了新的挑战。

对于机器对机器(Machine-to-Machine,M2M)使用情况,具有调制解调器(modem)的类传感器(sensor-like)装置基于电池运行,电池的更换或者改变成本对于大量装置的适应而言需要高成本。电池寿命可能决定装置的寿命或者网络寿命。对于大量应用(例如,智能应用,或者MTC应用),UE电池寿命也成为大问题。大量应用显示出了消耗不必要的功耗的业务类型,因为很多背景应用以及背景业务没有对于功耗而进行优化。即使对于可能从外部电池供电消耗电源的UE的场景,依然期望从能量节省目的出发而消耗更少电量。

对于UE功耗的优化因此对于各种移动应用的增长的数量是需要的。LTE系统已经在连接状态(connected state)以及空闲状态(idle state)引入了不连续接收(discontinuous reception,DRX)。一般说来,长DRX周期(cycle)有助于提高UE电池寿命以及减少网络信令开销。但是,长DRX周期也对于LTE带来了潜在的问题。在空闲状态的UE需要周期性醒来以及监视用于DL数据的寻呼信道(Paging Channel,PCH)。对于一些服务或者装置,当前寻呼周期太短因此没有功率优化。对于LTE装置,当前最大DRX周期为2.56秒,即,每2.56秒UE醒来一毫秒(millisecond)。如果当前计算寻呼时机(paging occasion)的方式没有改变,那么寻呼周期扩展受到系统帧号(System Frame Number,SFN)卷绕(wrap around)的限制,其中SFN卷绕为10.24秒。如果比上述更长,计算寻呼时机的当前方式不再有效。

另一个问题是,很长休眠周期可能影响UE移动性(mobility)。当UE处于长休眠周期,不实施移动性测量(measurements)。UE只在每次醒来时为移动性估计(evaluation)而实施测量。网络因此使用更不精确的测量以结束,以在UE的准备切换(handover)中有效地协助。进一步说,如果DRX周期为分钟级别(in the magnitude of minutes),可能小区重选(cell reselection)不再工作以及不再可用。这是因为UE可能移动长距离,以及远离了原始驻留小区的覆盖范围。当UE醒来听寻呼,前一小区中被存储小区重选参数不再可用。所以,UE必须做小区选择(cell selection)。为了实现网络策略以及限制全扫描(full scanning)的消耗(effort),期望网络依然能够提供小区重选参数,其中该小区重选参数对于具有长休眠周期的UE在更宽范围内有效。

长休眠周期的另一个潜在问题为寻呼鲁棒性(robustness),因为寻呼时机在小区之间是非同步的。这意味着当UE醒来以及超出原始驻留小区覆盖范围之外时,UE需要驻留在一个新小区上以接收寻呼,以及等待(休眠(sleep)模式中)寻呼。对于更快移动UE,休眠中多次改变覆盖范围小区,结果可能是为寻呼的醒来时间总是错误的,即UE基于旧的驻留小区的参数而计算自己的寻呼周期,在该寻呼时机上,UE醒来时不再在上述旧驻留小区的覆盖范围内。即使对于不经常改变小区的UE,由于在错误的时序监视寻呼,很长休眠也导致了时钟漂移(drift)以及丢失寻呼(page)的风险。此外,如果寻呼周期很长,因为UE可能需要经过更长准备,所以期望更长醒来会话。举例说明,时序漂移,可能对于长寻呼周期而言达到一秒,因此,一毫秒醒来时间对于UE不足以用于准备同步。一般说来,如果寻呼周期扩展到~10秒,那么只扩展当前寻呼机制是可行的。但是,如果寻呼周期扩展到分钟级别或者更长,那么影响更大。期望新的哦寻呼机制以改进鲁棒性以及寻呼的灵活性



技术实现要素:

在LTE系统中,长寻呼周期有助于提高装置电池寿命以及减少网络信令开销。在本发明中,当UE配置有很长寻呼周期时,增强小区重选过程以及增强寻呼机制被提出。

在第一新颖方面,提出小区重选增强的方法。移动通信网络中UE获得用于扩展小区重选(Extended Cell Reselection,ECR)的参数。UE转到休眠,然后周期性醒来监视寻呼信道。UE或者应用具有正常(normal)寻呼周期长度的正常寻呼周期,或者应用具有很长寻呼周期长度的功率节省(power-saving)寻呼周期。如果应用正常寻呼周期,那么该UE实施小区选择。如果应用功率节省寻呼周期以及如果ECR参数基于多个条件的列表依然有效时,那么该UE基于ECR参数实施小区重选。网络为具有长寻呼周期的UE提供用于更宽范围的ECR参数,这样,UE可以在从长休眠醒来之后使用小区重选而减少功耗。

在一个实施例中,ECR参数包含E-UTRAN频率或者无线接入技术(Radio Access Technology,RAT)之间(inter-RAT)频率的不同绝对优先级(absolute priorities)、RAT偏移、小区重选以获得更高/更低优先级RAN/频率的阈值、小区重选周期(Treselection)以及移动性缩放因数(scaling factor)、停止测量标准(Stop-Measure criterion)阈值、最大传送功率以及黑/白名单小区列表。ECR参数有效性的条件包含小区识别符(identity,ID)、跟踪区域(tracking area)、公共陆地移动网络(PLMN)、定时器、小区改变计数、距离以及物理位置。可以预先定义多个条件,或者UE从高层(higher layer)、系统信息、专用信令,或者从其他RAT获取,以作为ECR参数的一部分。

在第二新颖方面中,提供增强寻呼机制用于从很长寻呼周期醒来的UE以提高寻呼鲁棒性以及灵活性。增强寻呼包含绝对时间寻呼(Absolute Time Paging,ATP)以及具有扩展醒来时间(extended wakeup time)的寻呼。对于绝对时间寻呼,UE接收ATP配置以及如果满足条件则使用实际WALL时间以计算寻呼时机。ATP配置为基于UE能力(capability)以及需求(requirement)。用于ATP有效的条件可以包含定时器、PLMN或者TA。在一个实施例中,经过(wall)时间从下列多个中至少其中之一获取:内部UE时钟、全球定位系统(Global Position System,GPS)时间、网络广播的信息,或者来自高层信令的信息。

对于扩展醒来时间的寻呼,UE在长寻呼周期的休眠中醒来之后,UE应用长功率节省寻呼周期,再应用多个正常寻呼周期中。长功率节省寻呼周期长度为至少在多个分钟或者更多的级别(in the magnitude of minutes or more)。UE被认为是在AS等级为功率关闭(power off),以及在深度休眠中,不实施空闲模式过程。在满足一个条件之后,UE从多个正常寻呼周期返回到长寻呼周期。在一个实施例中,长寻呼周期长度是无限的(infinite),以及只在跟踪区域更新(Tracking Area Update,TAU)触发寻呼,或者UL业务时UE进入正常寻呼周期。

下面详细描述说明中详细介绍本发明的其他实施例以及有益效果。发明内容不用于限定本发明。本发明保护范围以权利要求为准。

附图说明

附图中,相同数字表示相似元件,用于说明本发明。

图1为根据一个新颖方面,支持增强小区重选以及增强寻呼的移动通信网络示意图。

图2为支持本发明实施例的UE的简化方块示意图。

图3为根据一个新颖方面扩展小区重选的方法流程图。

图4为UE醒来之后,用于支持扩展小区选择的UE以及网络之间的信令序列流程图。

图5为根据一个新颖方面,用于扩展小区重选的方法流程图。

图6为绝对时间寻呼的方法流程图。

图7为用于支持绝对时间寻呼机制的UE以及网络之间信令序列流程图。

图8为根据一个新颖方面,用于绝对时间寻呼的方法流程图。

图9为用于支持具有扩展醒来时间的扩展寻呼机制中,UE以及网络之间信令序列流程图。

图10为根据一个新颖方面,具有扩展醒来时间的增强寻呼方法流程图。

具体实施方式

下面详细参考本发明的一些实施例,结合附图用于说明示例。

图1为根据一个新颖方面,支持增强小区重选以及增强寻呼的移动通信网络示意图。在图1的例子中,移动通信网络102为LTE网络。步骤111中,用户设备UE 101处于正常空闲模式,驻留在一个小区中,或者已经在连接模式中与一个服务基站建立无线资源控制(Radio Resource Control,RRC)连接。在步骤112中,UE101从网络102获取配置以及参数。配置以及参数,例如,可以与休眠模式运作相关,以及与寻呼和小区重选配置和参数相关。UE101可以配置为休眠模式以及连接模式具有不同休眠周期的不同休眠模式运作。

步骤113中,UE101基于已配置寻呼周期而进入休眠。步骤114中,UE101从寻呼周期中醒来以监视寻呼信道(Paging Channel,PCH)。举例说明,如果UE101处于正常空闲模式,那么UE101可能转入具有正常寻呼周期长度的已配置正常寻呼周期的休眠,以及UE101正常空闲模式中周期性醒来以监视PCH。另一方面,为了功耗节省以及电池寿命目的,UE101可以配置有很长功率节省寻呼周期长度的功率节省寻呼周期,例如,多个分钟或者更多的级别。如果UE101从很长功率节省寻呼周期的深度休眠中醒来,那么由于很长寻呼周期可能产生多个问题,包含UE移动性,小区重选以及寻呼鲁棒性。

在一个新颖方面中,当UE配置有很长寻呼周期以用于功率节省目的时,增强小区重选过程以及增强寻呼机制被提出。步骤115中,UE101在从很长寻呼周期醒来之后,实施增强小区重选过程(procedure)。从UE以及网络角度看,与小区选择相比小区重选是优选的。但是,当前小区重选只在之前已驻留小区的多个相邻小区中有效。因此,如果UE101已经在长休眠之后离开了临近区域(neighborhood),那么那些小区重选参数可能变得废弃(obsolete)。相应地,网络102提供多个参数用于小区重选,其中该多个参数可以用于更宽范围区域。所以,UE101在从长深度休眠之后实施小区重选。这被称作“扩展小区重选(Extended Cell Reselection,ECR)”。

除了小区重选增强,如果UE101被配置有很长寻呼周期,增强寻呼机制也被期望。步骤116中,UE101实施增强寻呼,其中包含ATP以及具有扩展醒来时间的寻呼。如果UE101为更快移动UE,在长深度休眠中,多次改变覆盖范围小区,用于寻呼的醒来时间通常是错误的,即,UE基于旧的已驻留小区的多个参数计算自己的寻呼时机,对于旧的已驻留小区而言,该UE在醒来时不再在其覆盖范围内。即使UE101不经常改变小区,很长深度休眠也导致了时钟漂移以及由于在错误时序监视寻呼的失去寻呼(page)的风险。相应地,UE101不基于已驻留小区的参考而计算寻呼时机,但是基于实际时间,例如WALL时间。作为结果,如果网络以及UE之间的时序为同步,那么在长深度休眠之后的错误时序上,醒来的机会降低了。

另一个寻呼增强为具有扩展醒来时间的寻呼。用于空闲模式UE的当前醒来时间只为每个寻呼周期一个毫秒。如果寻呼周期很长,因为UE被期待经历更长准备,期待更长醒来会话。这是因为一般说来时序与寻呼周期的时间段(duration)成正比。对于长寻呼周期,时序漂移可能高达一秒,因此一毫秒的醒来时间对于UE准备,例如同步而言不再足够。相应地,UE可以比当前需求保持醒来更长时间。扩展醒来时间也允许MME寻呼请求上的更多灵活性,以及减少了丢失寻呼以及封包(packet)延迟的机会。

图2为支持本发明实施例的UE201的方块示意图。UE201包含存储器211、处理器212,无线频率(RF)发送器以及接收器模块213,其中发送器以及接收器模块213耦接到天线214,以及支持各种协议栈的3GPP协议栈,包含非接入层(Non-Access Stratum,NAS)NAS 230、RRC 231、RLC 232、MAC 233以及PHY 234。在发送方向,发送器将来自处理器的已接收基频信号转换为RF信号,然后发送给天线。在接收方向,处理器处理来自收发器的已接收基频信号,以及激发不同功能模块以实施UE所支持的不同功能。

不同功能模块包含配置模块220、测量模块221以及休眠模式(sleep-mode)控制模块222,小区选择(cell selection)以及重选(reselection)模块223,寻呼控制模块224,内部时钟225以及定时器(timer)226。功能模块可以软件、固件、硬件,或者上述几者的任意组合实现。功能模块,当被处理器212所执行时(透过存储器211中包含的程序指令215),彼此协作以允许UE201实施增强小区重选以及增强寻呼机制。举例说明,配置模块从网络接收用于扩展小区重选(Extended Cell Reselection,ECR)的参数,以及用于ATP的配置,以及为UE配置不同寻呼周期。休眠模式控制模块使能UE进入休眠,以及相应地从寻呼周期醒来。小区选择以及重选模块在UE从长寻呼周期醒来之后,为UE实施扩展小区重选。寻呼控制模块使能UE实施增强寻呼,其中增强寻呼更强健(robust)以及更灵活。

扩展小区重选(ECR)

图3为根据一个新颖方面扩展小区重选的方法流程图。步骤311中,UE处于正常空闲模式(normal idle mode)驻留在一个小区上,或者已经在连接模式与一个服务基站建立RRC连接。UE配置有具有正常寻呼周期长度的寻呼周期,或者很长功率节省寻呼周期长度的寻呼周期。步骤312中,UE进入已配置寻呼周期长度的休眠。在步骤313,UE从寻呼周期醒来。步骤314中,UE决定是否已经休眠了很长寻呼周期。如果答案是否,那么UE在步骤321应用旧有(legacy)小区选择。旧有小区选择过程消耗了高功耗,因为包含可能频率的全扫描,以为UE找到最适合的小区。

如果步骤314中答案为是,那么步骤331中,UE获取用于ECR的已存储参数。小区重选为UE用于在UE已经驻留小区之后改变小区的机制。基于已配置小区重选参数,UE使用某个标准以及多个算法用于小区重选处理(process)。一般说来,ECR参数用于定义用于UE的某个标准以及多个算法,以在UE深度休眠之后用于小区重选目的。ECR参数的列表(list)如表310所描述,以及包含不同E-UTRAN频率或者RAT之间频率的绝对优先级(absolute priorities)、RAT偏移(offset)用于小区重选到较高(higher)/较低(lower)优先级RAN/频率的阈值、小区重选周期(cell reselection periodicity,记作Treselection)、以及移动性缩放因数,停止测量标准的阈值,最大传送功率以及黑/白名单小区列表。

绝对优先级定义了用于扫描的不同频率的优先级。相似地,RAT偏移定义了小区重选的偏好(preferred)RAT。LTE小区重选为一个基于优先级的处理。UE总是基于绝对优先级以及RAT偏移测量具有较高优先级的多个频率以及RAT。所以,UE能够尽可能快地找到偏好频率,以及能够基于网络策略考虑而选择偏好RAT,网络策略考虑例如业务拥塞(traffic congestion)以及负载均衡。用于小区重选的阈值指小区重选处理中,决定满足条件的小区的标准。

Treselection指UE需要实施小区重选的频率。这样的周期性可以基于UE移动性而缩放。举例说明,慢速移动UE可以每一秒实施小区重选,而快速移动UE可以每半秒实施小区重选。停止测量阈值指当UE可以停止用于找到更好小区的测量搜索时的标准。最大传送功率与UL功率条件的小区重选相关。最后,黑/白名单小区列表定义了UE可以避免(黑名单小区列表)以及可以选择(白名单小区列表)的一些小区。

步骤332中,UE决定已存储ECR参数的有效。依赖于UE已经休眠了多久,以及UE在休眠中移动了多远,已存储ECR参数可能是无效的,因为UE已经休眠了很长时间,或者已经从网络为适当小区重选目的所预期的原始位置移动了太远。ECR参数的有效可以基于图表330所描述的条件列表而决定。一般说来,多个条件与定义更宽区域相关,该更宽区域中ECR参数在UE从很长深度休眠中醒来之后依然可用。条件的列表包含小区ID、跟踪区域(Tracking Area,TA)、PLMN、定时器、小区改变(cell change)计数(count)、距离以及物理位置。

小区ID(PCI、CGI、等等)指属于预先定义地理区域的多个小区的列表。只要UE驻留在或者感知到(sense)该列表中一个小区,那么ECR信息被认为是有效的。TA也定义了地理区域。只要UE没有改变自己的TA,或者依然位于TA范围内,那么ECR信息被认为是有效。PLMN指特定PLMN,即,只要UE认出(spot)PLMN,然后,ECR信息被认为是有效的。定时器定义了ECR参数超时时间。只要定时器没有超时,ECR信息被认为是有效。小区改变计数指UE改变小区有多么频繁。只要小区改变计数没有达到一个阈值,那么ECR信息被认为是有效的。小区改变计数阈值可以根据UE速度进行缩放。举例说明,更快移动UE可以具有较高阈值。如果新驻留小区也提供ECR信息,小区改变计数可以重启(re-started)。距离指当前UE位置以及UE所收到ECR信息的位置之间的距离。只要UE在ECR信息被收到的位置的一个距离范围内,那么ECR信息依然被认为是有效的。最后,物理位置定义了更宽地理区域,即只要UE在被定义更宽地理区域内,ECR信息依然被认为是有效的。

如果在步骤332的答案为否,那么UE转到步骤321,以及实施旧有小区选择。另一方面,如果步骤332的答案为是,那么UE转到步骤333以及基于已存储ECR参数实施小区重选。小区重选降低了UE功耗,因为UE不需要实施全扫描。相反,UE只需要基于ECR参数提供的优先级以及标准实施有限的扫描以及测量,以驻留到新小区。最后,步骤334中,UE驻留到新小区,或者在新小区中建立新连接。

图4为UE从长深度休眠醒来之后,支持扩展小区选择的UE401以及网络402之间的信令序列(sequence)流程。步骤411中,UE401处于正常空闲模式驻留在一个小区上,或者在连接模式中与服务基站已经建立RRC连接。步骤412中,UE401从网络402获取ECR参数。如列表410所描述,ECR参数可以透过不同方式获取。举例说明,在UE离开专用信令的连接状态之前,网络402可以转发(forward)ECR参数用于使用很长寻呼周期的该UE,专用信令即,RRC连接释放消息(RRC Connection Release message)或者新RRC消息。可替换地,网络402可以广播ECR参数作为系统信息(例如,SIB)的一部分,所以UE401可以在需要时获取ECR参数。UE401可以从另一个RAT中继承ECR信息。ECR信息也可以来自高层(higher layer),例如来自MME的非接入状态(non-access stratum,NAS)层信令,或者来自开放移动联盟(Open Mobile Alliance,OMA)装置管理(Device Management,DM)的信令。

步骤413中,UE401存储已获取ECR参数。稍后,UE401决定转到具有已配置很长功率节省寻呼周期的休眠模式。步骤421中,UE401转入具有功率节省寻呼周期长度的深度休眠。步骤422中,UE401从很长寻呼周期中醒来。步骤431中,UE401决定驻留在新小区上,以及决定已存储ECR参数对于扩展小区重选是否有效。如果答案为是,那么UE401在步骤441实施扩展小区重选。ECR包含已优化小区搜索以及因此减少功率消耗。否则,UE401在步骤442实施旧有小区选择。旧有小区选择包含全扫描以及与ECR相比消耗更多时间以及功率。最后,步骤451中,UE401驻留在新小区上,或者在新小区上建立新连接。

只要ECR参数是有效的,以及当新数值可用时则替换该ECR参数UE401保存该ECR参数。步骤461中,如果UE401决定该ECR参数不再有效,则UE401删除废弃ECR参数。步骤462中,UE401从网络402获取已更新ECR参数。与步骤412相似,UE401可以透过如列表460所示多个方式获取已更新ECR参数。步骤463中,UE401存储已更新ECR参数。

图5为根据一个新颖方面,用于扩展小区重选的方法流程图。步骤501中,UE在移动通信网络中获取用于ECR的多个参数。步骤501中,UE转入休眠,然后周期性醒来监视寻呼信道。UE或者应用具有正常寻呼周期长度的正常寻呼周期,或者应用具有很长寻呼周期长度的功率节省寻呼周期。步骤503中,如果正常寻呼周期被应用,则UE实施小区选择。步骤504中,如果功率节省寻呼周期被应用,以及如果ECR参数基于多个条件的列表依然有效,UE基于ECR参数实施小区重选。步骤505,UE删除废弃ECR参数,以及从网络获取已更新ECR参数。

增强寻呼机制

在UE从很长寻呼周期醒来之后,除了小区重选增强,增强寻呼机制也被期望。增强寻呼包含ATP以及具有扩展醒来时间的寻呼。

寻呼是网络传送寻呼消息给空闲模式的UE,或者EMM已注册状态UE的过程。寻呼消息可以在核心网络中由MME所触发,或者在RAN中由eNB所触发。用于UE的寻呼信息承载在物理下行链路共享信道(Physical Downlink Shared Channel,PDSCH)上,在物理下行链路控制(Physical Downlink Control Channel,PDCCH)中指示的资源区块中。不同组UE为了自己的寻呼消息监视不同子帧(例如,寻呼时机)。对于空闲模式中的DRX运作,UE被允许不连续监视寻呼消息以节省功率。UE转到休眠以及周期性醒来以监视自己的PCH。成功寻呼接收需要UE解码PDCCH以及PDSCH,以用于PCH消息,其中该解码需要时序同步。如果UE在短休眠之后醒来,时序同步不是问题。但是,当休眠时间变得太长,这个问题变得更严重。保证时序同步的一个方式为使用ATP。

图6为ATP的方法流程图。步骤611中,UE处于空闲模式,驻留在一个小区中。步骤612中,UE决定ATP是否已经配置。如果答案为否,那么UE保持在正常空闲模式以及周期性醒来以在步骤632实施正常寻呼。如果已配置ATP,那么UE在步骤621决定用于ATP的条件是否满足。ATP的有效可以受到多个条件的限制,例如,定时器,PLMN,TA等。当没有满足条件,那么ATP被释放,以及UE返回到(revert)正常寻呼。对于TAU的需求可以与旧有寻呼以及ATP不同。举例说明,当ATP被配置时,UE可以被注册到额外TA。这样的配置,可以使得UE在长休眠之后对于实施TAU的需要降低。在步骤621的例子中,UE决定是否该UE在一个已定义区域中,例如PLMN或者TA。如果答案为是,那么用于ATP的条件满足,以及UE转到步骤631用于ATP。如果答案为否,那么用于ATP的条件没有满足,以及UE在步骤622丢弃ATP配置,以及转到步骤632用于正常寻呼。

典型地,寻呼时机基于已驻留小区的参考而计算。但是,如果UE从很长休眠醒来,UE可能已经从参考小区移动很远,以及没法保证在不同eNb的不同小区之间的时序为同步。因此,如果寻呼时机基于实际时间,例如WALL时间计算,使用ATP可以保住保证时序同步。如果在网络以及UE之间的时序为同步,那么UE在场休眠之后,在错误时序醒来的机会被降低。举例说明,步骤631中,在ATP过程中,UE转入深度休眠,以及然后基于WALL时间根据预先定义时序(例如,一个子帧/多个子帧),从很长功率节省寻呼周期醒来,以及因此监视寻呼信道。

图7为支持ATP机制的UE701以及网络702之间信令序列流程示意图。步骤710中,UE701在正常空闲模式驻留在一个小区。步骤711中,UE701提供UE能力(capability)以及需求给网络702。例如,UE能力指示出,UE的WALL时间可用,以及UE需求指示出对于超长(super long)寻呼周期的需要。步骤712中,UE701从网络702获取ATP配置。ATP配置为基于UE能力以及需求。例如,ATP配置为基于WALL时间的时序,例如,协调世界时间(Coordinated Universal Time),或者用于时序的任何其他格式。一旦UE701配置为用于ATP,对于时序同步的预先定义需求需要被定义。例如,UE可以在预先定义时间段中,至少一次获取WALL时间。可替换地,UE可以保证在预先定义值内,例如一秒范围内的时序漂移(drift)。

步骤713中,UE701获取WALL时间。如列表710所示,WALL时间可以透过不同方式获取。举例说明,UE701可以从自己的内部时钟获取WALL时间,从GPS时间,从网络广播的系统信息(例如,SIB),或者从高层(例如,来自MME的NAS信令)。步骤714中,UE701从长寻呼周期转入深度休眠。步骤715中,UE701从长寻呼周期醒来以及如果配置了ATP以及满足ATP条件时,实施ATP(步骤721)。也就是说,UE701基于WALL时间,根据预先定义时序醒来。醒来之后,UE701应用旧有寻呼(步骤722)。可替换地,如果没有配置ATP,或者没有满足ATP条件,UE701在正常空闲模式实施旧有寻呼(步骤722)。在一个特定例子中,如果满足条件,例如定时器已经超时,或者正常寻呼计数已经道道预先定义阈值数值,UE701可以从正常空闲模式进入深度休眠,。

图8为根据一个新颖方面用于ATP的方法流程图。步骤801中,UE在移动通信网络中获得用于ATP的配置。配置为基于UE能力对于WALL时间的可获得(availability)以及与长寻呼周期相关的UE需求。步骤802中,如果UE配置有ATP,以及如果满足第一条件,UE基于WALL时间实施ATP。否则,UE保持在正常空闲模式以及实施正常寻呼。步骤803中,在RRC连接释放或者在第二条件在正常空闲模式被满足时,或者在正常可能空闲模式中满足第二条件之后,UE直接进入具有长功率节省寻呼周期的深度休眠。步骤804中,基于WALL时间,根据预先定义时序,UE从长功率节省寻呼周期醒来,以及监视PCH。

另一个寻呼增强机制为在长寻呼周期之后,扩展UE醒来时间。已扩展醒来时间可以帮助UE经过更长准备,以及允许对于MME寻呼需求的更多灵活性,以及降低丢失寻呼以及封包延迟(packet delay)的机会。原则上,为了扩展UE醒来时间,UE可以配置有两个不同寻呼周期。例如,UE可以配置有正常寻呼周期以及长功率节省寻呼周期。当UE在长寻呼周期之后醒来时,UE可以在几个正常寻呼周期监视寻呼。直到满足一个条件,UE再次回到长寻呼周期,以用于功率节省目的。

图9为用于支持具有扩展醒来时间的增强寻呼机制,UE901以及网络902之间的信令序列流程。步骤911中,UE901在连接模式中,与网络902建立RRC连接。UE901配置有正常寻呼周期以及可选地长功率节省寻呼周期。步骤921中,RRC连接释放之后,UE保持在正常空闲预先定义时间段之后,UE901进入具有长功率节省寻呼周期的深度休眠模式。步骤922中,UE901在长寻呼周期之后醒来。步骤923中,UE901进入具有正常寻呼周期的休眠模式。UE周期性醒来以连续几个正常寻呼周期监视寻呼。在一个例子中,UE901启动一个定时器,用于全部正常寻呼周期的时间段。无论何时有UL活动(activity)(例如,移动发起(Mobile Originated,MO)接入)或者DL活动(例如,接收寻呼),UE901转入空闲模式以及重启定时器。在另一个例子中,全部寻呼周期的数量也是可配置的。在到达正常寻呼周期的最大数量之后,UE901再次回到长功率节省寻呼周期。可替换地,一旦UE901从长寻呼周期醒来,UE901可以保持醒来连续多个寻呼子帧,或者预先定义时间段。在到达最大数量寻呼子帧或者时间段之后,UE901再次回到长寻呼周期。当UE901在长寻呼周期中处于深度休眠时,UE被AS级别认为是关机(power off)以及不实施任何空闲模式程序(procedure)。但是,UE901依然实施接入阻止(barring)相关AS功能(functionality)。

步骤924中,UE进入具有长功率节省寻呼周期的深度休眠模式。在该例子中,长寻呼周期长度可以为无限的(infinity),所以UE不进入短寻呼周期,直到有Ul触发事件,例如TAU或者UL业务。TAU主要在UE检测到自己已经进入新TA时发生,该新TA没有在UE已经与网络注册的跟踪区域指示符(Tracking Area Indicator,TAI)的列表中。TAU也发生在一些其他场景,包含当周期性TA更新定时器已经超时,或者当UE改变自己的无线能力,等等。如果UE比寻呼监视更频繁地实施TAU,TAU成为UE空闲模式中功率节省的瓶颈。为了避免快速移动UE的频繁醒来,网络可以在来自UE的TAU发生时触发寻呼。步骤925中,UE901在TAU时醒来以用于事件触发寻呼。当UE901为TAU醒来时,该UE几个寻呼周期的寻呼,或者预先定义时间段保持醒来以监视寻呼。对于具有长寻呼周期的UE901,当因TAU醒来时,UE901发送MO信令(例如,TAU请求),或者MO数据(UL数据)(步骤931)。然后UE901被释放到空闲(步骤932)。以此方式,UE901被保持更长空闲时间,以及网络可以转发已缓冲DL数据(步骤930)给UE901。请注意,那些数据为延迟容忍,以及网络必须能够缓冲数据一段时间。这样的机制也可以用于导致UE醒来的任何其他事件。举例说明,UE可以在从UL数据会话中释放之后,保持正常寻呼周期。在到达正常寻呼周期的最大数量之后,UE然后转入长寻呼周期。透过在长寻呼周期以及正常寻呼周期之间切换,UE能够在长寻呼周期中节省功率,以及在醒来之后监视寻呼,以及在多个正常寻呼周期中,更有效地实施其他过程。

图10为根据一个新颖方面,具有扩展醒来时间的增强寻呼的方法流程图。步骤1001中,UE在移动通信网络中与服务eNB建立RRC连接。核心网络为UE配置有正常寻呼周期,以及可选地长功率节省寻呼周期。步骤1002中,在RRC连接释放之后,在UE在正常空闲保持一预先定义时间段之后,UE进入具有长功率节省寻呼周期的休眠(如果已经配置)。步骤1003中,UE从长功率节省寻呼周期中醒来,以及监视寻呼信道。步骤1004中,UE进入具有正常寻呼周期长度的休眠,以及UE在多个正常寻呼周期中连续监视PCH。步骤1005中,在满足一个条件之后,UE回到具有长功率节省寻呼周期的休眠。

虽然本发明已经联合多个特定实施例进行描述以用于说明,本发明不限于此。相应地,对所属实施例的各种修改、润饰以及各种特征的组合可以被实施,并不脱离本发明的保护范围,本发明保护范围以权利要求为准。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1