一种支持RAN初始寻呼消息的方法与流程

文档序号:14448110阅读:1623来源:国知局
一种支持RAN初始寻呼消息的方法与流程

本发明涉及移动通信,尤其涉及一种支持ran初始寻呼消息的方法。



背景技术:

随着无线移动通信技术的发展,人们对高速率,低延迟,低成本提出了越来越高的要求。lte(longtermevolution)项目就在这样的背景下产生了,追求更高的峰值速率和更短的传输时延。当前在lte技术演进中,物联网技术,mtc技术迅速发展,未来的网络部署面临高密集网络节点部署,海量终端连接的局面,所以面对如此巨大的终端连接数量,对于网络侧的信令负荷是个挑战,例如rrc接口的信令,s1接口信令。所以如何降低空口和网络侧的信令负荷是未来提升网络性能需要解决的一个问题。

r14中提出了一种新的ue连接状态,该连接状态处于rrc_idle和rrc_connected状态之间,可以有效降低空口和网络侧的信令负荷。这里可以称这种新的rrc状态为轻连接rrc_light_connected状态。该状态有如下特点:ue在进入轻连接状态时,ue和当时的enb保留ue的上下文信息,此时的enb叫做锚基站anchorenb;s1连接在anchorenb处保留且处于激活状态;支持ran初始的寻呼消息,即当有下行数据到达时,由ran侧而不是mme触发寻呼消息,这样可以降低数据发送时延和信令降低;进入的轻连接状态的ue执行基于移动性的小区重选操作,类似于idle状态ue的移动性;进入轻连接状态的ue被寻呼或者有数据要发送时,从轻连接状态进入rrc_connected状态。rrc_light_connected与rrc_idle和rrc_connected状态之间的转化制约关系如图1。

对于ran初始的寻呼机制,由于ran侧并不知道s-tmsi,且s-tmsi可能存在被mme再分配的可能,这种再分配对于ran侧来说是透明的。所以不能像mme触发的寻呼消息那样使用s-tmsi标识轻连接状态下的ue,同时也不能使用imsi,因为使用imsi寻呼是一种异常行为,而且ran侧保存imsi也是不安全的;对于寻呼时机的计算,使用小区级别pagingdrx和uespecificdrx取最小原则来计算寻呼时机,此时如何选择drx才能让ue更加节能;ue来到非锚基站覆盖区域时如何接收寻呼,来到网络侧后新的服务enb如何寻址到anchorenb等等,都成为亟待解决的问题。



技术实现要素:

针对上述问题,本发明提出一种支持ran初始寻呼消息的方法,包括:

为用户设备ue分配新的接入网ran侧ue标识和寻呼区域,或者分配新的接入网ran侧ue标识、寻呼区域和轻连接状态下的drx周期;

通过rrc信令消息下发给所述ue。

进一步地,所述新的ran侧ue标识由锚基站的基站标识和随机码、或锚基站的e-cgi和随机码组成。

进一步地,还包括:如果所述ue指示轻连接状态下需要节能,则所述轻连接状态下的寻呼drx周期分配为长drx;否则分配为短drx,或者默认使用小区drx。

进一步地,所述寻呼区域为小区列表、基站列表或者跟踪区域ta列表。

进一步地,还包括:将所述新的ue标识、寻呼区域、分配的寻呼drx通知给所述ue的服务基站和同一个寻呼区域的其他基站。

进一步地,还包括:寻呼轻连接状态的ue时,

在寻呼消息中使用所述新的ue标识寻呼所述ue;在寻呼时机计算时使用所述新的ue标识作为所述ue的ue-id输入;

根据所述轻连接状态下的drx周期,或者小区drx计算所述ue的寻呼时机。

进一步地,还包括:所述ue在连接恢复消息中携带所述新的ran侧ue标识;服务基站根据所述新的ran侧ue标识确定所述ue的锚基站。

本发明的方法定义了新的ran侧ue标识,在寻呼消息中标识被寻呼ue,同时用于服务enb寻址anchorenb,用于计算ue的寻呼时机;根据ue喜好来确定寻呼drx,使得寻呼消息的时延和节能遵循ue的意愿和实际需求。

附图说明

图1为rrc_light_connected与rrc_idle和rrc_connected状态之间的转化制约关系示意图;

图2为本发明提出的支持ran初始寻呼消息的方法流程示意图;

图3为本发明实施例的ue状态转换及轻连接状态下寻呼流程示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例;需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

本发明的一个实施例提出一种支持ran初始寻呼消息的方法,请参考图2,包括:

为用户设备ue分配新的接入网ran侧ue标识和寻呼区域,或者分配新的接入网ran侧ue标识、寻呼区域和轻连接状态下的drx周期;

通过rrc信令消息下发给所述ue。

在一个可选实施例中,新的ran侧ue标识由锚基站的基站标识和随机码、或锚基站的e-cgi和随机码组成。

在一个可选实施例中,还包括:如果所述ue指示轻连接状态下需要节能,则所述轻连接状态下的寻呼drx周期分配为长drx;否则分配为短drx,或者默认使用小区drx。

在一个可选实施例中,寻呼区域为小区列表、基站列表或者跟踪区域ta列表。

在一个可选实施例中,还包括:将所述新的ue标识、寻呼区域、分配的寻呼drx通知给所述ue的服务基站和同一个寻呼区域的其他基站。

在一个可选实施例中,还包括:寻呼轻连接状态的ue时,

在寻呼消息中使用所述新的ue标识寻呼所述ue;在寻呼时机计算时使用所述新的ue标识作为所述ue的ue-id输入;

根据所述轻连接状态下的drx周期,或者小区drx计算所述ue的寻呼时机。

在一个可选实施例中,还包括:所述ue在连接恢复消息中携带所述新的ran侧ue标识;服务基站根据所述新的ran侧ue标识确定所述ue的锚基站。

本发明的方法定义了新的ran侧ue标识,在寻呼消息中标识被寻呼ue,同时用于服务enb寻址anchorenb,用于计算ue的寻呼时机;根据ue喜好来确定寻呼drx,使得寻呼消息的时延和节能遵循ue的意愿和实际需求。

实施例

首先定义一种新的ran侧ue标识,该标识由anchorenb来分配。该标识由anchorenb的enbid和一个随机码组成,或者anchorenb的e-cgi和一个随机码组成。

anchorenb在获取ue是否支持lightconnection能力,同时获取到该支持lightconnection能力的ue在处于lightconnection状态时是否支持节能的指示。分配ue处于lightconnection状态时paging的drx,如果ue指示需要节能,则anchorenb分配长的drx,例如edrx。如果ue没有指示节能,则分配短的drx,或者默认使用各自小区的默认drx来计算寻呼时机。该分配的drx还通知给属于同一个寻呼区域的其他enb,以便于该enb计算寻呼时机发送寻呼消息。

分配寻呼区域,例如一个celllist或者enbidlist或者talist等。

在寻呼消息中,通过上述的新的ran侧ue标识来标识被寻呼ue,所以该标识被anchorenb分配后需要在rrc消息中配置ue。在计算寻呼时机时利用该新的ran侧ue标识来作为ue寻呼时机计算的ue-id输入。

新的ran侧ue标识通知给服务enb,及属于同一个寻呼区域的其他enb,当ue发送连接回复消息中,携带此新的ran侧ue标识,服务enb根据该新的ran侧ue标识确定anchorenb,以便于向anchorenb所要ue上下文,恢复uerrc连接。

请参考图3,ue状态转换及轻连接状态下寻呼过程具体包括:

ue处于rrc_connected状态,s1connected状态;

锚基站根据ue业务状态,网络侧负荷情况等因素决定让该ue进入轻连接状态,并给ue分配新的ueid;同时分配ue处于轻连接态时的寻呼drx;分配寻呼区域;通过rrc信令下发给ue;

ue和锚基站进入轻连接状态,保留ue上下文;mme保持rrc_connection状态;

由数据或nas消息到达时,锚基站使用新的ran侧ue标识寻呼ue,通知服务基站;服务基站根据指定的drx计算寻呼时机,使用新的ran侧ue标识寻呼ue;

ue与服务基站进行寻呼响应随机接入过程;

ue发起rrc连接恢复给服务基站,携带上述新的ue标识,或者锚基站标识;

服务基站根据新的ue标识或锚基站标识来寻址锚基站,索要as上下文;收到as上下文响应后,与核心网开始pathswitch过程,指示ue恢复rrc连接;

ue进入rrc_connected状态,服务基站作为新的锚基站进入rrc_connected状态;

恢复数据通信。

本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

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