CN108616822B - 一种lte集群系统的组呼被叫小区重选的方法 - Google Patents

Abstract

本发明公开一种LTE集群系统的组呼被叫小区重选的方法，方法包括：当集群UE在RRC空闲状态下且正在接收组呼时，根据小区重选评估时长确定满足当前UE小区重选的判定准则的目标小区；当UE从驻留小区切换到目标小区之前，向驻留小区发送RRC连接建立确认请求，RRC连接建立确认请求包括：用于获取目标小区的组呼资源配置的信息；以使驻留小区与网络侧网元交互，获取到所述目标小区的组呼资源配置；UE接收所述驻留小区发送的目标小区的组呼资源配置，以及接收驻留小区释放UE的RRC连接态的信息；UE从RRC连接态切换到RRC空闲态，并驻留到目标小区以根据所述组呼资源配置实现组呼。上述方法解决UE在小区切换时组呼断话的问题。

Description

一种LTE集群系统的组呼被叫小区重选的方法

技术领域

本发明涉及通信技术，具体涉及一种LTE集群系统的组呼被叫小区重选的方法。

背景技术

在移动通信系统中，UE在跨小区移动时，根据UE当前所处的状态会产生不同的移动性管理流程。当UE处于RRC空闲状态下跨小区移动时，UE将执行小区重选流程，以便驻留到一个无线信道质量更好的相邻小区。当UE处于RRC连接状态下跨小区移动时，UE将执行切换流程，以便接入到一个无线信道更好的相邻小区。

在LTE公网系统中，不考虑尚未大规模商用的eMBMS(enhancement MultimediaBroadcast Multicast Service，增强型多媒体广播多播业务)，主要的业务是点对点的单呼业务，且UE只有在RRC连接状态下才能进行单呼业务。当UE跨小区移动时，为了使UE在移动过程中业务不会出现严重的中断或时延，通常采用切换方式，使UE从源小区移动到相邻小区时，在相邻小区继续保持原有的链路接续，确保业务的连续性。

而在LTE(Long Term Evolution，长期演进)集群专网系统中，UE(UserEquipment，用户设备)除了具有单呼业务外，还具有专网业务，比较典型的专网业务是组呼业务。组呼业务的一个显著特点是，组呼被叫UE无论是在RRC(Radio Resource Control，无线资源控制)连接状态下还是在RRC空闲状态下都可接收组呼业务。在RRC连接状态下，组呼被叫UE跨小区移动时，仍然可通过切换方式保证组呼业务接收的连续性。但是在RRC空闲状态下，现有的3GPP协议以及B-TrunC标准所规定的小区重选流程已不能适应组呼业务的要求。

发明内容

鉴于上述问题，本发明提出了克服上述问题或者至少部分地解决上述问题的一种LTE集群系统的组呼被叫小区重选的方法。

为此目的，第一方面，本发明提出一种LTE集群系统的组呼被叫小区重选的方法，包括：

当集群UE在RRC空闲状态下且正在接收组呼时，根据预先从广播消息中获取的小区重选评估时长确定满足当前UE小区重选的判定准则的第一相邻小区，该第一相邻小区作为该UE在小区重选时的目标小区；

当所述UE从驻留小区切换到目标小区之前，向驻留小区发送RRC连接建立确认请求，所述RRC连接建立确认请求包括：用于获取目标小区的组呼资源配置的信息；以使所述驻留小区根据所述RRC连接建立确认请求与网络侧网元交互，获取到所述目标小区的组呼资源配置；

所述UE接收所述驻留小区发送的目标小区的组呼资源配置，以及接收驻留小区释放所述UE的RRC连接态的信息；

所述UE从RRC连接态切换到RRC空闲态，并驻留到所述目标小区以根据所述组呼资源配置实现组呼。

可选地，所述UE从RRC连接态切换到RRC空闲态，并驻留到所述目标小区以根据所述组呼资源配置实现组呼的步骤，包括：

所述UE从RRC连接态切换到RRC空闲态，且在所述目标小区完成下行同步并接收到MIB(Master Information Block，主信息块)后，根据所述组呼资源配置接听组呼。

可选地，当UE在RRC空闲状态下且正在接收组呼时，根据预先从广播消息中获取的小区重选评估时长确定满足当前UE小区重选的判定准则的第一相邻小区的步骤之前，所述方法还包括：

所述UE接收网络侧的广播消息，所述广播消息中携带小区重选评估时长，该小区重选评估时长与LTE公网中的小区重选评估时长不同。

可选地，所述小区重选评估时长为下述的一种：

0ms、40ms、64ms、100ms、128ms、160ms、256ms、320ms、480ms、512ms、640ms、1024ms、1280ms、2560ms和5120ms。

可选地，所述组呼资源配置包括：目标小区所在载频的UARFCN无线频率信道号和PCI物理小区标识、该UE正在接收的当前组呼的组呼标识Trunking Group ID。

第二方面，本发明还提供一种LTE集群系统的组呼被叫小区重选的方法，包括：

源基站接收UE发送的RRC连接建立确认请求，所述RRC连接建立确认请求包括：目标小区组呼资源配置的请求信息；所述RRC连接建立确认请求为UE在RRC空闲状态下且正在接收组呼时，根据广播消息中的小区重选评估时长确定小区重选的目标小区之后并从空闲态切换至连接态时发送的；

所述源基站根据所述RRC连接建立确认请求向核心网发送初始UE信息Initial UEMessage；以及接收MME根据所述Initial UE Message发送初始上下文建立请求消息；

所述源基站向MME发送目标跟踪区组呼资源请求消息，所述目标跟踪区组呼资源请求消息包括：Initial UE Message中的eNB UE S1AP ID和初始上下文建立请求消息中的MME UE S1AP ID、目标小区所在的目标基站标识、目标小区所属的跟踪区标识、目标小区的全局标识和当前组呼的组呼标识；

在所述目标小区所属的跟踪区存在所述组呼标识对应的组呼业务时，MME根据所述目标跟踪区组呼资源请求消息构造目标跟踪区组呼资源索取消息；

所述MME向目标基站发送所述目标跟踪区组呼资源索取消息，所述目标跟踪区组呼资源索取消息包括：MME Trunk S1AP ID、eNB Trunk S1AP ID、目标小区的全局标识、请求组呼资源的UE的MME UE S1AP ID；

所述目标基站根据所述目标跟踪区组呼资源索取消息获取MME Trunk S1AP ID、eNB Trunk S1AP ID对应组呼的组呼资源配置；向MME发送确认消息，该确认消息包括：MMETrunk S1AP ID、eNB Trunk S1AP ID、请求组呼资源的UE的MME UE S1AP ID、目标小区的组呼资源配置、组呼寻呼配置、组呼下行功率分配信息；

所述MME根据所述确认消息向源基站发送所述目标跟踪区组呼资源请求消息的响应消息，该响应消息包括：eNB UE S1AP ID、MME UE S1AP ID、组呼标识、目标小区的组呼资源配置、组呼寻呼配置、组呼下行功率分配信息；

源基站根据所述响应消息向所述UE发送目标小区组呼资源指示消息，该目标小区组呼资源指示消息包括：目标小区所在载频的UARFCN、目标小区的PCI、组呼标识、目标小区的组呼资源配置、组呼寻呼配置、组呼下行功率分配信息。

可选地，所述方法还包括：所述UE接收所述目标小区组呼资源指示消息后，向所述源基站发送目标小区组呼资源指示消息的确认消息。

可选地，所述方法还包括：

源基站在接收所述目标小区组呼资源指示消息的确认消息后，向所述MME发送UE上下文释放请求，以触发包括MME的核心网侧释放UE的上下文；

所述核心网侧释放UE的上下文之后，源基站向所述UE发送RRC连接释放信息；

所述UE在接收到所述RRC连接释放信息后，从RRC连接态切换到RRC空闲态，并驻留到目标小区；在目标小区完成下行同步，并接收到MIB之后接收组呼。

可选地，核心网侧网元向源基站发送UE驻留到目标小区后的UE释放消息，所述源基站在接收所述UE释放消息后释放该UE的相关信息。

可选地，源基站接收UE发送的RRC连接建立确认请求的步骤之前，所述方法还包括：

所述UE根据广播消息中的小区重选评估时长确定小区重选的目标小区之后向源基站发送RRC连接请求；

所述源基站根据RRC连接请求向所述UE发送RRC连接建立响应；以及

所述UE在接收RRC连接建立响应后，从空闲态切换至连接态，相应地，执行所述源基站接收UE发送的RRC连接建立确认请求的步骤。

由上述技术方案可知，本发明提出的一种LTE集群系统的组呼被叫小区重选的方法，在满足组呼业务要求的前提下，降低组呼被叫UE小区重选的时延，并使组呼被叫UE提前在本小区获取目标小区的组呼配置，可在经小区重选到目标小区后直接接收组呼，保证组呼业务接收的连续性，减小断话时延。

附图说明

图1为现有技术中组呼被叫小区重选的方法的流程图；

图2为本发明一实施例提供的LTE集群系统的组呼被叫小区重选的方法的流程示意图；

图3为本发明另一实施例提供的LTE集群系统的组呼被叫小区重选的方法的信令图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。

需要说明的是，在本文中，“第一”、“第二”、“第三”、“第四”字样仅仅用来将相同的名称区分开来，而不是暗示这些名称之间的关系或者顺序。

目前，图1示出了现有的B-TrunC标准规定的组呼被叫小区重选的方案，在图1中，组呼被叫UE根据3GPP协议，判定如果某个同频相邻小区在小区重选评估时长(Treselection EUTRA(3GPP TS36.331中该参数定义为0,1,2...7s))所规定的时间内一直满足小区重选的S准则和R准则后，该相邻小区就被UE视为小区重选的目标小区。

UE驻留到目标小区后，发起随机接入，建立RRC连接，发起Tracking Area Update(跟踪区更新)流程。

网络侧受到Tracking Area Update流程的触发后检测目标小区是否存在组呼，如果目标小区所在的TA(Tracking Area跟踪区)中不存在UE正在接收的组呼，则在目标小区扩建该组呼。如果目标小区所在的TA(Tracking Area跟踪区)中存在UE正在接收的组呼，则网络侧广播组呼寻呼和组呼建立消息。

此后，组呼被叫UE在目标小区通过监听组呼寻呼和组呼建立消息，获取到目标小区的组呼资源配置，开始接收组呼业务。

然而，现有的B-TrunC标准中的组呼被叫小区重选方案存在如下缺点：

(1)组呼被叫UE小区重选的评估时间较长，容易造成业务中断。

例如，现有的B-TrunC标准中，组呼被叫UE判决相邻小区满足小区重选的持续时间仍然延用了公网3GPP标准规定的Treselection EUTRA(E-UTRAN的小区重选定时器)参数。

LTE公网业务主要发生在RRC连接状态，而非RRC空闲状态，因此，在RRC空闲状态下无需考虑业务在恶劣的无线环境下保持接续。为了避免乒乓效应而导致UE进行频繁的小区重选，公网的3GPP标准对于RRC空闲状态下的小区重选评估时长Treselection定义的时间较长，为秒级参数，0、1、2...7s。相反，对于RRC连接状态下UE的切换，考虑到业务的连续性，3GPP标准将切换触发时长time To Trigger定义为从0ms、40ms、64ms、100ms、128ms、160ms、256ms、320ms、480ms、512ms、640ms、1024ms，1280ms、2560ms、5120ms。在实际网络部署时，对于该参数一般选择为几百ms。LTE公网对于没有业务的小区选择/重选过程是“粗放型管理”，而对于存在业务的切换过程则是“精细化控制”，由此可见，评估时长对于业务的用户体验是至关重要的。

上述3GPP规定的参数对于LTE公网业务的特征而言无疑具有其合理性，但是考虑到LTE集群专网的组呼业务特征，即组呼被叫在空闲状态下也可接收组呼，小区重选评估时长(Treselection)的秒级参数已经不适合组呼业务。这是因为当组呼被叫在Treselection所规定的时间内(例如1s～7s)评估小区重选时，由于评估时间较长，如果无线环境在此时逐渐恶化，UE将无法正确接收到组呼业务的下行信号，造成断话。因此，对于LTE集群系统，需要引入新的小区重选评估时长，其定义的时长要考虑到RRC空闲状态下组呼被叫接听组呼业务的连续性。

(2)组呼被叫UE获取目标小区的组呼配置的时机过晚，将会导致组呼掉话。

具体地，现有的B-TrunC标准中，组呼被叫UE经小区重选到目标小区后，还无法获知目标小区的组呼资源的配置信息。为此，UE首先在目标小区获取SIB1(SystemInformation Block 1，系统信息块1)和SIB2(System Information Block 1，系统信息块1)等SIB(System Information Block，系统信息块)，驻留到该小区，随后发起随机接入，建立RRC连接建立、再发起Tracking Area Update流程。网络侧在受到Tracking Area Update流程的触发后，在目标小区进行组呼扩建，并广播组呼寻呼和组呼建立消息；UE在目标小区通过监听组呼寻呼和组呼建立消息，获取到目标小区的组呼资源配置，开始接收组呼业务。

上述流程所消耗的时延，最为乐观的估计约为(200～200+组呼寻呼DRX周期)ms。这段时延就是组呼被叫UE业务中断的时间。

组呼寻呼DRX(Discontinuous Reception，非连续接收)周期(也就是TruningPaging DRX周期)取值为20、40、60、80、160、320、640、1280ms。为了UE节电的需要，集群系统一般将TruningPaging DRX周期设置为80、160ms，甚至更长。此时，上述流程所消耗的时延约为200～280ms、200～360ms，其上限已经接近或超过300ms。300ms对于语音业务的用户体验而言意味着没有听到某个字，即“丢字”，严重情况下会引起组呼接听者理解上的歧义，这对应用于专网通信，特别是公安、应急、铁路等关键部门的集群通信系统是不能接受的。

为此，本发明针对处于RRC空闲状态的组呼被叫接收组呼业务的特点，提出了一种小区重选的方法，在满足组呼业务要求的前提下，降低组呼被叫UE小区重选的时延，并使组呼被叫UE提前在本小区获取目标小区的组呼配置，可在经小区重选到目标小区后直接接收组呼，保证组呼业务接收的连续性，减小断话时延。

图2示出了本发明一实施例提供的LTE集群系统的组呼被叫小区重选的方法的流程示意图，如图2所示，本实施例的方法包括下述步骤：

201、当集群UE在RRC空闲状态下且正在接收组呼时，根据预先从广播消息中获取的小区重选评估时长确定满足当前UE小区重选的判定准则的第一相邻小区，该第一相邻小区作为该UE在小区重选时的目标小区。

202、当所述UE从驻留小区切换到目标小区之前，向驻留小区发送RRC连接建立确认请求，所述RRC连接建立确认请求包括：用于获取目标小区的组呼资源配置的信息；以使所述驻留小区根据所述RRC连接建立确认请求与网络侧网元交互，获取到所述目标小区的组呼资源配置。

203、UE接收所述驻留小区发送的目标小区的组呼资源配置，以及接收驻留小区释放所述UE的RRC连接态的信息。

204、UE从RRC连接态切换到RRC空闲态，并驻留到所述目标小区以根据所述组呼资源配置实现组呼。

本实施例的组呼资源配置可包括：目标小区所在载频的UARFCN(无线频率信道号)和PCI(Physical Cell ID，物理小区标识)、该UE正在接收的当前组呼的组呼标识(Trunking Group ID)。

举例来说，UE从RRC连接态切换到RRC空闲态，且在所述目标小区完成下行同步并接收到MIB后，根据所述组呼资源配置接听组呼。

也就是说，集群组呼被叫UE在小区重选的目标小区完成下行同步，接收到MIB后，无需等待接收到SIB1、SIB2及其他SIB，就可立刻利用已经获取的目标小区的组呼配置在目标小区的TCCH和TTCH信道上接收组呼。换言之UE在目标小区接收组呼的处理和读取所有SIB的处理可并发进行。这是因为处于RRC空闲状态下的组呼被叫UE在本小区进行小区重选时已经读取了目标小区的SIB1；此外，该UE在重选到目标小区后接收组呼时并不需要发起随机接入去建立RRC连接，既无需获取SIB2中的公共信道配置，也无需获取SIB2中影响随机接入的负载控制参数。这种机制缩短了组呼被叫UE在小区重选的目标小区接收组呼的时延，避免UE在目标小区出现组呼断话。

可选地，在一种可选的实现方案中，上述图2所示的方法还可包括下述的图中未示出的步骤200：

200、所述UE接收网络侧的广播消息，所述广播消息中携带小区重选评估时长，该小区重选评估时长与LTE公网中的小区重选评估时长不同。

本实施例中的小区重选评估时长可为下述的一种：

0ms、40ms、64ms、100ms、128ms、160ms、256ms、320ms、480ms、512ms、640ms、1024ms、1280ms、2560ms和5120ms。

可理解的是，现有3GPP标准中LTE公网的小区重选评估时长(TreselectionEUTRA)所定义的各个时间取值较长，不适应于LTE集群专网的组呼被叫UE。因此，针对集群组呼被叫UE的业务特点，为保证组呼被叫接听组呼业务的连续性，引入新的小区重选评估时长参数Treselection EUTRATrunk。该参数的时间取值定义为0ms、40ms、64ms、100ms、128ms、160ms、256ms、320ms、480ms、512ms、640ms、1024ms，1280ms、2560ms、5120ms。一般该参数的默认取值为几百ms。

上述参数可在System Information Block Type Trunking(集群系统信息块)中广播。集群UE通过接收System Information Block Type Trunking获取TreselectionEUTRATrunk(E-UTRAN集群小区重选定时器)参数。当集群UE在RRC空闲状态下且正在接收组呼时，以Treselection EUTRA Trunk代替LTE公网参数TreselectionEUTRA，作为小区重选的评估时长参数。当相邻小区在TreselectionEUTRATrunk所规定的时间内满足小区重选的判定准则时，则这个相邻小区就被UE视为小区重选的目标小区。

集群组呼被叫UE小区重选时，一旦确定了合适的目标小区，在驻留到目标小区之前，立刻在本小区发起RRC连接建立请求，通过和网络侧信令交互，提前在本小区获取目标小区的组呼资源配置。同时，UE可仍然在本小区接收组呼。当集群UE获取到目标小区的组呼资源配置后则被网络侧释放，回退到RRC空闲状态。并驻留到经小区重选的目标小区。

集群组呼被叫UE在驻留到目标小区后可立刻接收组呼，例如，当UE尝试驻留到经小区重选的目标小区时，UE在目标小区完成下行同步，接收到MIB后，无需等待接收到SIB1、SIB2及其他SIB，就可利用已经获取的目标小区的组呼配置立刻接听组呼，换言之，UE接收组呼和读取SIB可并行发生。这种机制可避免UE经小区重选到目标小区后，还要在目标小区发起随机接入，建立RRC连接建立，进一步和网络侧进行信令交互以便临时获取目标小区的组呼配置，造成信令交互时延较长，导致UE接收组呼时在目标小区掉话。

本实施例的方法还具有下述的优点：

(1)集群组呼被叫UE小区重选时，提前在本小区建立RRC连接，获取目标小区的组呼资源配置，以便UE经小区重选到目标小区之后，可立刻接听组呼，避免UE在目标小区出现掉话，且缩短了组呼被叫UE在小区重选的目标小区接收组呼的时延。

(2)集群组呼被叫UE获取目标小区的组呼资源配置后，通过网络侧的释放，仍然回退到RRC空闲状态，并直接驻留到此前小区重选所选择的目标小区，而不是通过切换驻留到目标小区。这种机制可增加UE驻留到目标小区的成功率，避免UE由于在目标小区的随机接入过程失败而导致切换失败，造成UE无法在目标小区正确接收组呼，出现断话。

(3)针对集群组呼被叫UE的业务特点，引入新的小区重选评估时长参数，该参数增加了几十ms到几百ms的时间取值，缩小了集群组呼被叫UE的小区重选时延，减小了UE在本小区的组呼的断话概率。

图3示出了本发明另一实施例提供的LTE集群系统的组呼被叫小区重选的方法的信令示意图，如图3所示，本实施例的方法包括下述步骤：

首先，集群UE接收网络侧的广播消息，所述广播消息中携带小区重选评估时长，该小区重选评估时长与LTE公网中的小区重选评估时长不同。

301、当集群UE在RRC空闲状态下且正在接收组呼时，根据预先从广播消息中获取的小区重选评估时长确定满足当前UE小区重选的判定准则的第一相邻小区，该第一相邻小区作为该UE在小区重选时的目标小区。

302、UE根据广播消息中的小区重选评估时长确定小区重选的目标小区之后向源基站发送RRC连接请求。

303、源基站根据RRC连接请求向所述UE发送RRC连接建立响应。

针对上述的步骤301至步骤303，可说明如下：

正在接收组呼的处于RRC空闲状态下的组呼被叫UE，在本小区以SystemInformation Block Type Trunking广播的Treselection EUTRA Trunk为小区重选判决时间，根据现有3GPP所规定的S准则和R准则进行小区重选，当选定了目标小区之后，UE在本小区发起NAS(Non-Access-Stratum，非接入层)的Service Request流程，触发RRC连接建立请求，向Source eNodeB(源基站)请求建立RRC连接。

304、UE在接收RRC连接建立响应后，从空闲态切换至连接态，并向源基站发送RRC连接建立确认请求。

应说明的是，本实施例中RRC连接建立确认请求可包括：目标小区组呼资源配置的请求信息。

本实施例的RRC连接建立确认请求可为UE在RRC空闲状态下且正在接收组呼时，根据广播消息中的小区重选评估时长确定小区重选的目标小区之后并从空闲态切换至连接态时发送的。

也就是说，UE在RRC连接建立流程中，通过RRC Connection Setup Complete消息携带Neigh Cell Trunk Resource Enquiry(即相邻小区组呼资源请求)信元，该信元向Source eNodeB(源基站)指示小区重选的目标小区所在载频的UARFCN(无线频率信道号)和PCI(物理小区ID)，以及UE正在接收的当前组呼的Trunking Group ID(组号)。

305、源基站根据所述RRC连接建立确认请求向核心网发送Initial UE Message(初始UE消息)。

本实施例中的Initial UE Message可包括eNB UE S1AP ID。

306、源基站接收MME根据所述Initial UE Message发送初始上下文建立请求消息。

本实施例的初始上下文建立请求消息可包括MME UE S1AP ID。

应说明的是，MME随后向Source eNodeB发送初始上下文建立请求消息(或是用于NAS鉴权的下行直传消息，对UE进行鉴权。这种情况很少发生，除非是EPC没有该UE的安全上下文，或是UE在Sevice Request中上报的eKSI(Key Set Identifier for E-UTRAN，E-UTRAN的安全密钥)和EPC中该UE上下文中的eKSI不相符。但这种情况是异常情况，本实施例不对其详述。)，

本步骤的初始上下文建立请求消息中可含有MME为UE分配的MME UE S1AP ID，随后eNodeB开始进行初始上下文建立流程(或在异常情况下，向UE透传下行直传消息，用于NAS鉴权的下行直传消息，对UE进行鉴权)。

307、源基站向MME发送目标跟踪区组呼资源请求消息。

本实施例的目标跟踪区组呼资源请求消息可包括：eNB UE S1AP ID、MME UE S1APID、目标小区所在的目标基站标识、目标小区所属的跟踪区标识、目标小区的全局标识和当前组呼的组呼标识。

也就是说，Source eNodeB获取了UE的MME UE S1AP ID后，向MME发送目标跟踪区组呼资源请求消息，其中包含UE的eNB UE S1AP ID和MME UE S1AP ID、目标小区所在的target eNodeB的global eNB ID、目标小区所属TA(跟踪区)的TAI(跟踪区标识)、targetcell的E-UTRAN CGI(目标小区的全局标识)，以及当前组呼的Trunking Group ID。

308、在所述目标小区所属的跟踪区存在所述组呼标识对应的组呼业务时，MME根据所述目标跟踪区组呼资源请求消息构造目标跟踪区组呼资源索取消息。

应说明的是，如果目标小区所属的TA中存在Trunking Group ID所标识的组呼业务，则MME直接执行步骤308。否则，参见图3中的步骤8a至步骤8c，MME向target eNodeB(目标基站)发起组呼扩建，在目标小区所属的TA中扩建Trunking Group ID所标识的组呼。

309、所述MME向目标基站发送所述目标跟踪区组呼资源索取消息。

本实施例中，目标跟踪区组呼资源索取消息可包括：MME Trunk S1AP ID、eNBTrunk S1AP ID、目标小区的全局标识、请求组呼资源的UE的MME UE S1AP ID。

可理解的是，MME构造目标跟踪区组呼资源索取消息后，向target eNodeB发送该消息，包含组呼MME Trunk S1AP ID、eNB Trunk S1AP ID，target cell的E-UTRAN CGI，请求组呼资源的UE标识MME UE S1AP ID。target eNodeB只透传MME UE S1AP ID，不对该UE进行解析。

310、目标基站根据所述目标跟踪区组呼资源索取消息获取MME Trunk S1AP ID、eNB Trunk S1AP ID对应组呼的组呼资源配置；向MME发送确认消息。

该步骤的确认消息可包括：MME Trunk S1AP ID、eNB Trunk S1AP ID、请求组呼资源的UE的MME UE S1AP ID、目标小区的组呼资源配置、组呼寻呼配置、组呼下行功率分配信息。

也就是输，Target eNodeB获取目标小区中MME Trunk S1AP ID、eNB Trunk S1APID所标识的组呼的组呼资源配置(例如G-RNTI等)后，向MME发送目标跟踪区组呼资源确认消息。该消息中包含组呼MME Trunk S1AP ID、eNB Trunk S1AP ID、请求组呼资源的UE标识MME UE S1AP ID。、目标小区的组呼资源配置、组呼寻呼配置，以及组呼下行功率分配参数等信息。

311、MME根据所述确认消息向源基站发送所述目标跟踪区组呼资源请求消息的响应消息。

该步骤的响应消息可包括：eNB UE S1AP ID、MME UE S1AP ID、组呼标识、目标小区的组呼资源配置、组呼寻呼配置、组呼下行功率分配信息。

即，MME向source eNodeB发送目标跟踪区组呼资源响应消息，该消息中包含UE的eNB UE S1AP ID和MME UE S1AP ID、组呼的Trunking Group ID、目标小区的组呼资源配置(例如G-RNTI等)、组呼寻呼配置，以及组呼下行功率分配参数等信息。

312、源基站根据所述响应消息向UE发送目标小区组呼资源指示消息。

该步骤的目标小区组呼资源指示消息可包括：目标小区所在载频的UARFCN、目标小区的PCI、组呼标识、目标小区的组呼资源配置、组呼寻呼配置、组呼下行功率分配信息。

也就是说，source eNodeB向UE发送目标小区组呼资源指示消息，该消息包含目标小区所在载频的UARFCN、目标小区的PCI、组呼的Trunking Group ID、目标小区的组呼资源配置(例如G-RNTI等)、组呼寻呼配置，以及组呼下行功率分配参数等信息。

313、UE接收所述目标小区组呼资源指示消息后，向所述源基站发送目标小区组呼资源指示消息的确认消息，表示获取了目标小区的组呼资源配置。

314、源基站在接收所述目标小区组呼资源指示消息的确认消息后，向所述MME发送UE上下文释放请求，以触发包括MME的核心网侧释放UE的上下文；

315、核心网侧释放UE的上下文之后，源基站向所述UE发送RRC连接释放信息。

即，eNodeB向MME发送UE Context Release Request，触发EPC释放UE上下文，并向UE发送RRC Connection Release。

316、UE在接收到所述RRC连接释放信息后，从RRC连接态切换到RRC空闲态，并驻留到目标小区；在目标小区完成下行同步，并接收到MIB之后接收组呼。

可理解的是，UE在接收到RRC Connection Release回到RRC空闲状态后，立即驻留到此前经小区重选所选择的目标小区，在目标小区完成和PSS、SSS信号的下行同步，接收到MIB后，不必等待接收到SIB1、SIB2及其他SIB，可立刻接收组呼的TCCH或TTCH信道。

317、核心网侧网元向源基站发送UE驻留到目标小区后的UE释放消息，所述源基站在接收所述UE释放消息后释放该UE的相关信息。

318、源基站向核心网发送UE释放消息的释放完成的响应信息。

在本实施例中，UE切换到目标小区之后，EPC命令源eNodeB释放UE上下文，源eNodeB完成UE上下文的释放。

本实施例的方法中，集群组呼被叫UE小区重选时，提前在本小区建立RRC连接，获取目标小区的组呼资源配置，以便UE经小区重选到目标小区之后，可立刻接听组呼。

接着，集群组呼被叫UE获取目标小区的组呼资源配置后被网络侧释放，仍然回退到RRC空闲状态，并直接驻留到此前小区重选所选择的目标小区。

进一步地，集群组呼被叫UE在目标小区完成下行同步，接收到MIB后，无需等待接收到SIB1、SIB2及其他SIB，就可立刻利用已经获取的目标小区的组呼配置在目标小区的TCCH和TTCH信道上接收组呼。

特别地，针对集群组呼被叫UE的业务特点，引入新的小区重选评估时长参数，该参数增加了几十ms到几百ms的时间取值，缩小了集群组呼被叫UE的小区重选时延，减小了UE在本小区的组呼的断话概率。

另外，需要说明的是，上述图2和图3中提及的在System Information Block TypeTrunking消息中，使用扩展IE的位置增加了Treselection EUTRA Trunk参数。

在图3中的RRC Connection Setup Complete消息中，使用Release 8的扩展IE的位置增加了Neigh Cell Trunk Resource Enquiry参数。即对现有的3GPP中定义的RRC消息进行相应的修改以实现上述图2和图3所示的方法。

本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。

本领域技术人员可以理解，实施例中的各步骤可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。

虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (5)

1.一种LTE集群系统的组呼被叫小区重选的方法，其特征在于，包括：

源基站接收UE发送的RRC连接建立确认请求，所述RRC连接建立确认请求包括：目标小区组呼资源配置的请求信息；所述RRC连接建立确认请求为UE在RRC空闲状态下且正在接收组呼时，根据广播消息中的小区重选评估时长确定小区重选的目标小区之后并从空闲态切换至连接态时发送的；

所述源基站根据所述RRC连接建立确认请求向核心网发送初始UE信息Initial UEMessage；以及接收MME根据所述Initial UE Message发送初始上下文建立请求消息；

所述源基站向MME发送目标跟踪区组呼资源请求消息，所述目标跟踪区组呼资源请求消息包括：Initial UE Message中的eNB UE S1AP ID和初始上下文建立请求消息中的MMEUE S1AP ID、目标小区所在的目标基站标识、目标小区所属的跟踪区标识、目标小区的全局标识和当前组呼的组呼标识；

在所述目标小区所属的跟踪区存在所述组呼标识对应的组呼业务时，MME根据所述目标跟踪区组呼资源请求消息构造目标跟踪区组呼资源索取消息；

所述MME向目标基站发送所述目标跟踪区组呼资源索取消息，所述目标跟踪区组呼资源索取消息包括：MME Trunk S1AP ID、eNB Trunk S1AP ID、目标小区的全局标识、请求组呼资源的UE的MME UE S1AP ID；

所述目标基站根据所述目标跟踪区组呼资源索取消息获取MME Trunk S1AP ID、eNBTrunk S1AP ID对应组呼的组呼资源配置；向MME发送确认消息，该确认消息包括：MMETrunk S1AP ID、eNB Trunk S1AP ID、请求组呼资源的UE的MME UE S1AP ID、目标小区的组呼资源配置、组呼寻呼配置、组呼下行功率分配信息；

所述MME根据所述确认消息向源基站发送所述目标跟踪区组呼资源请求消息的响应消息，该响应消息包括：eNB UE S1AP ID、MME UE S1AP ID、组呼标识、目标小区的组呼资源配置、组呼寻呼配置、组呼下行功率分配信息；

源基站根据所述响应消息向所述UE发送目标小区组呼资源指示消息，该目标小区组呼资源指示消息包括：目标小区所在载频的UARFCN、目标小区的PCI、组呼标识、目标小区的组呼资源配置、组呼寻呼配置、组呼下行功率分配信息。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：所述UE接收所述目标小区组呼资源指示消息后，向所述源基站发送目标小区组呼资源指示消息的确认消息。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

源基站在接收所述目标小区组呼资源指示消息的确认消息后，向所述MME发送UE上下文释放请求，以触发包括MME的核心网侧释放UE的上下文；

所述核心网侧释放UE的上下文之后，源基站向所述UE发送RRC连接释放信息；

所述UE在接收到所述RRC连接释放信息后，从RRC连接态切换到RRC空闲态，并驻留到目标小区；在目标小区完成下行同步，并接收到MIB之后接收组呼。

4.根据权利要求3所述的方法，其特征在于，核心网侧网元向源基站发送UE驻留到目标小区后的UE释放消息，所述源基站在接收所述UE释放消息后释放该UE的相关信息。

5.根据权利要求1至4任一所述的方法，其特征在于，源基站接收UE发送的RRC连接建立确认请求的步骤之前，所述方法还包括：

所述UE根据广播消息中的小区重选评估时长确定小区重选的目标小区之后向源基站发送RRC连接请求；

所述源基站根据RRC连接请求向所述UE发送RRC连接建立响应；以及

所述UE在接收RRC连接建立响应后，从空闲态切换至连接态，相应地，执行所述源基站接收UE发送的RRC连接建立确认请求的步骤。

Images