CN102083115A - 一种长期演进系统中rlf指示消息的处理方法和设备 - Google Patents

Abstract

本发明公开了一种长期演进系统中RLF指示消息的处理方法和设备，该方法包括：当基站接收到没有携带RLF report信息的第一RLF指示消息时，所述基站判断是否能接收到携带了RLF report信息的第二RLF指示消息；如果是，所述基站丢弃所述第一RLF指示消息，并根据接收到的第二RLF指示消息确定用户设备UE的失败原因；否则，所述基站根据所述第一RLF指示消息确定UE的失败原因。本发明实施例中，使网络可以正确地处理基站之间交互的信息，正确的统计失败原因，避免错误的失败事件统计，并使得网络可以获得真实的问题分类统计数据，避免了错误地触发优化动作。

Description

一种长期演进系统中RLF指示消息的处理方法和设备

技术领域

本发明涉及通信技术领域，尤其涉及一种长期演进系统中RLF指示消息的处理方法和设备。

背景技术

在目前的3GPP(The 3rd Generation Partnership Project，第三代合作伙伴计划)标准协议的Rel-9版本中，为了帮助网络检测失败原因，在UE(UserEquipment，用户设备)发生RLF(Radio Link Failure，无线链路失败)或切换失败(Handover failure)后，相关的基站之间需要进行信息的交互。

在Rel-9协议规定，当UE发生RLF或切换失败后，收到UE的RRC(RadioResource Control，无线资源控制)重建请求的基站(以下称此基站为重建基站)，需要通过X2接口向失败前服务小区所在基站(以下称为失败基站)发送无线链路失败指示(RLF INDICATION)消息，以使失败基站可以根据无线链路失败指示消息中携带的信息判断失败原因。

具体的，基站收到RRC连接重建请求后，可以有成功或失败两种结果。其中，如果基站具有此UE的上下文，则接纳RRC连接重建请求，完成重建过程。如果基站没有此UE的上下文，则拒绝RRC连接重建请求，重建失败。

如图1所示的RRC连接重建成功的示意图，当RRC连接重建成功后，在UE发送的上行“RRC连接重建完成”消息中，会携带一个指示位，UE通过该指示位告知基站自身保存有RLF失败相关的数据，随后重建基站将通过UEInformation信令过程从UE获取这些数据，即无线链路失败报告(RLFreport)，并将其携带在RLF INDICATION消息中发送给失败基站，供失败基站判断失败原因。

如图2所示的RRC连接重建失败的示意图，当RRC连接重建失败后，UE将进入IDLE(空闲)状态，因此重建基站无法从UE获取RLF相关数据(即RLFreport)，在发送给失败基站的RLF INDICATION消息中没有这个信息。

需要注意的是，上述过程中，在Rel-9版本的RLF report中包含以下信息：失败前服务小区的信号测量数据、周围邻区的信号测量数据。在Rel-9版本的RLF INDICATION消息中包含以下信息：失败小区物理层标识PCI(Physicallayer Cell Identity，小区物理层标识)、重建小区的全局标识ECGI(E-UTRAN(Evolved Universal Terrestrial Radio Access Network，演进的通用陆地无线网络)Cell Global Identity，E-UTRAN小区全局标识)、UE在失败前服务小区内的标识C-RNTI(Cell-Radio Network Temporary Identifier，小区-无线网络临时标识)、UE在失败前的服务小区内完整性保护算法参数shortMAC-I、RLF report信息(可选携带，根据重建结果而定)。

进一步的，如图3所示的Rel-9版本的RLF INDICATION消息处理流程示意图，当基站收到RLF INDICATION消息后，可包括以下步骤：

步骤301，判断失败前服务小区是否在本基站下。如果是，执行步骤302，否则，结束流程。

步骤302，判断RLF INDICATION消息中是否包含RLF report。如果是，执行步骤303，否则，执行步骤305。

步骤303，判断RLF report中是否有任何小区的信号足够好。如果是，执行步骤305，否则，执行步骤304。

步骤304，诊断失败原因为覆盖漏洞。

步骤305，判断基站内是否有UE的上下文。如果是，执行步骤307，否则，执行步骤306。

步骤306，丢弃该RLF INDICATION消息。

步骤307，判断定时器T_store_ue_ ctxt是否还在运行。如果是，执行步骤308，否则，执行步骤311。

步骤308，判断重建小区与切换前源服务小区是否相同。如果是，执行步骤309，否则，执行步骤310。

步骤309，向切换前源基站发送切换报告(HANDOVER REPORT)消息，指示切换过早。

步骤310，向切换前源基站发送HANDOVER REPORT消息，指示切换到错误小区。

步骤311，判断失败是否发生在切换进行中。如果是，执行步骤312，否则，执行步骤313。

步骤312，判断重建小区与切换目标小区是否相同。如果是，执行步骤313，否则，执行步骤314。

步骤313，诊断失败原因为切换过迟。

步骤314，诊断失败原因为切换到错误小区。

综上所述，在Rel-9版本中，只有当RRC重建成功时，RLF INDICATION消息中才会包含RLF report信息，从而使得Rel-9的机制并不完备。因此，在3GPP Rel-10版本中，对以上机制进行了扩展，以支持在重建失败的场景下，RLF信息的上报。

如图4所示的基站收到两条RLF INDICATION消息的示意图，在RRC重建失败的情况下，UE将进入到IDLE状态，一段时间后会发起新的连接，并在UE发送的上行“RRC连接建立完成”消息中携带一个指示位，UE通过指示位告知基站自身保存有RLF失败相关的数据，随后新的服务基站可通过UEInformation信令过程从UE获取这些数据(即RLF report)，并将其携带在RLFINDICATION消息中发送给失败基站，供失败基站判断失败原因。

需要注意的是，在Rel-10版本的RLF report信息中，除了Rel-9版本中已有的数据之外，还可包含以下信息：UE失败前所在服务小区的全局标识ECGI(1)；UE尝试重建连接的小区的全局标识ECGI(2)；从UE接收切换命令到发生失败的时间间隔；如果UE在切换中发生失败，则还包含失败时的目标小区的物理层标识PCI和频点。

在实现本发明的过程中，发明人发现现有技术中至少存在以下问题：

在Rel-9版本中，RLF report对于诊断问题原因具有重要意义，如果没有RLF report，则基站可能错误的将‘覆盖漏洞’问题判断为‘切换过迟’。为了解决上述问题，在Rel-10版本中进行了增强，使得基站可以获知RLF report，但此时又引出了新的问题。

从图4可以看出，失败基站可能收到UE相关的两条RLF INDICATION消息，一条是没有携带RLF report信息的RLF INDICATION消息，一条是携带了RLF report信息的RLF INDICATION消息。基站在处理没有携带RLF report信息的RLF INDICATION消息时，由于缺少RLF report信息，则判断失败问题原因可能是切换过迟，基站需要将切换过迟的统计次数加1。

在随后收到携带了RLF report信息的RLF INDICATION消息后，则基站依据RLF report信息判断问题原因可能是覆盖漏洞。可以看出，上述对切换过迟的统计发生了错误，经过一段时间的累计后，若此项统计概率超过了预先设定的阈值后，则基站会启动基于切换过迟的切换优化过程，对小区的切换参数进行调整。而由于网络中真正的问题是覆盖漏洞，原来的切换参数是合适的，在对参数进行调整后不但没有解决网络问题，反而可能恶化了系统的切换性能。

发明内容

本发明实施例提供一种长期演进系统中RLF指示消息的处理方法和设备，以准确获知失败原因，避免错误地触发优化动作。

为了达到上述目的，本发明实施例提供一种长期演进系统中无线链路失败RLF指示消息的处理方法，该方法包括：

当基站接收到没有携带RLF report信息的第一RLF指示消息时，所述基站判断是否能接收到携带了RLF report信息的第二RLF指示消息；

如果是，所述基站丢弃所述第一RLF指示消息，并根据接收到的第二RLF指示消息确定用户设备UE的失败原因；否则，所述基站根据所述第一RLF指示消息确定UE的失败原因。

本发明实施例提供一种长期演进系统中RLF指示消息的处理设备，该设备包括：

第一接收模块，用于接收没有携带RLF report信息的第一RLF指示消息；

判断模块，用于当所述第一接收模块接收到所述第一RLF指示消息时，判断是否能接收到携带了RLF report信息的第二RLF指示消息；

第二接收模块，用于接收所述第二RLF指示消息；

处理模块，用于当所述判断模块的判断结果为是时，丢弃所述第一接收模块接收到的所述第一RLF指示消息，并根据所述第二接收模块接收到的所述第二RLF指示消息确定UE的失败原因；

当所述判断模块的判断结果为否时，根据所述第一接收模块接收到的所述第一RLF指示消息确定UE的失败原因。

与现有技术相比，本发明实施例至少具有以下优点：

使网络可以正确地处理基站之间交互的信息，正确的统计失败原因，避免错误的失败事件统计，并使得网络可以获得真实的问题分类统计数据，避免了错误地触发优化动作。

附图说明

为了更清楚地说明本发明的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术中RRC连接重建成功的示意图；

图2是现有技术中RRC连接重建失败的示意图；

图3是现有技术中Rel-9版本的RLF INDICATION消息处理流程示意图；

图4是现有技术中基站收到两条RLF INDICATION消息的示意图；

图5是本发明实施例一提供的一种长期演进系统中RLF指示消息的处理方法流程示意图；

图6是本发明实施例提供的一种长期演进系统中RLF指示消息的处理设备结构示意图。

具体实施方式

在移动通信网络中，由于切换时机不当而引起的用户发生掉话是移动运营商所不愿意看到的，另外当网络中有覆盖漏洞的情况时，也会发生掉话。上述两种原因都会导致掉话且掉话后UE的行为是相同的，但是对于两类问题来说，网络需要采取的优化措施是不相同的。因此，移动网络需要获得足够的信息以区分这两种情况，而为了解决上述问题，网络需要利用UE报告的信息以及基站之间交互的信息，来诊断失败的原因，以便能够决定采取何种解决措施来进行优化。

现有技术中，Rel-10版本(或更高版本)的基站可能接收到同一个UE相关的两条RLF INDICATION消息，并对这两条RLF INDICATION消息都进行处理，从而导致问题类型的统计出错，并错误地触发优化动作。

针对上述问题，本发明实施例提供一种长期演进系统中RLF指示消息的处理方法和设备，使网络可以正确地处理基站之间交互的信息，正确的统计失败原因，避免错误的失败事件统计，并使得网络可以获得真实的问题分类统计数据，避免了错误地触发优化动作。

下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例一提供一种长期演进系统中RLF指示消息的处理方法，当接收到同一个UE相关的两条RLF指示消息后，基站可避免对该两条RLF指示消息都做处理，从而避免了错误地触发优化动作。

具体的，由于携带了RLF report信息的RLF指示消息(例如，Rel-10版本中携带了RLF report信息的RLF指示消息)可以帮助基站更好地判断出UE的失败原因，因此，当基站在接收到UE相关的没有携带RLF report信息的RLF指示消息(本发明实施例中以第一RLF指示消息为例进行说明)后，确定还可以接收到同一个UE的携带了RLF report信息的RLF指示消息(本发明实施例中以第二RLF指示消息为例进行说明)，则基站可以丢弃第一RLF指示消息，并只处理第二RLF指示消息。为了实现上述操作，在接收到第一RLF指示消息后，需要基站能够获知是否还会接收到同一个UE的第二RLF指示消息。

本发明实施例中，首先分析不同版本的UE和基站组合的情况：

第一种情况：Rel-10版本(或者Rel-10以上版本)的UE和Rel-10版本(或者Rel-10以上版本)的基站。

(1)当RRC连接重建失败时，重建基站可经过X2接口向失败基站发送没有携带RLF report信息的第一RLF指示消息。

(2)UE进入IDLE态，之后发起新的无线连接，并告知网络自身有RLF相关数据，连接建立后的新服务基站从UE获取RLF report信息，并经过X2接口向失败基站发送携带了RLF report信息的第二RLF指示消息。

因此，在Rel-10版本的UE和Rel-10版本(或者Rel-10以上版本)的基站通讯的情况下，基站可收到两条RLF INDICATION消息。

第二种情况：Rel-9版本的UE和Rel-10版本(或者Rel-10以上版本)的基站。

(1)当RRC连接重建失败时，重建基站可经过X2接口向失败基站发送没有携带RLF report信息的第一RLF指示消息。

(2)UE进入IDLE态，之后发起新的无线连接，由于Rel-9版本的UE不告知网络自身是否有RLF相关数据，则新服务基站不从UE获取RLF report，也无法生成和发送携带了RLF report信息的第二RLF指示消息。

因此，在Rel-9版本的UE和Rel-10版本(或者Rel-10以上版本)的基站通讯的情况下，基站只接收到一条RLF INDICATION消息。

综上所述，在Rel-10版本的UE和Rel-10版本(或者Rel-10以上版本)的基站进行通讯时，可产生两条RLF INDICATION消息。因此只要基站能够获得UE的版本信息，即可以知道是否会收到两条RLF INDICATION消息。

基于上述情况，如图5所示，该方法包括以下步骤：

步骤501，基站接收没有携带RLF report信息的第一RLF指示消息。其中，该基站包括但不限于Rel-10版本的基站以及更高版本的基站。

具体的，当UE重建连接失败时，则基站(即UE发生失败的小区所在基站)可以接收到第一RLF指示消息。

步骤502，基站判断是否能接收到携带了RLF report信息的第二RLF指示消息。如果是，执行步骤503，否则，执行步骤504。

本发明实施例中，由于可根据UE的版本信息获知是否会收到两条RLFINDICATION消息，因此，基站可通过获取UE的版本信息，并根据该版本信息判断是否能接收到第二RLF指示消息。

具体的，在第一RLF指示消息中携带了UE在失败小区内的标识信息(例如，UE在失败小区内的标识C-RNTI)，则该基站可以通过该标识信息C-RNTI查询该UE的上下文；如果该基站中还保留有该UE的上下文，则从该UE的上下文中获取UE的能力信息(其中包含了UE的版本信息)，继而获得UE的版本信息。

进一步的，可通过判断该UE的版本信息是否大于等于预设版本的方式来判断基站是否能接收到第二RLF指示消息；如果大于等于预设版本，则基站确定能接收到第二RLF指示消息；如果小于预设版本，则基站确定不能接收到第二RLF指示消息。

实际应用中，该预设版本包括Rel-10版本；当然，实际应用中，该预设版本还可以进行调整，本发明实施例中不再赘述。

需要注意的是，本发明实施例中，如果基站已经没有UE的上下文，则无法获得UE的版本信息，此时基站可通过其他方式获得UE的版本信息，该基站也可以直接丢弃第一RLF指示消息，如果在之后接收到第二RLF指示消息，则根据第二RLF指示消息进行通常的处理，如果在之后没有接收到第二RLF指示消息，则结束流程。

步骤503，基站丢弃第一RLF指示消息，并根据第二RLF指示消息确定UE的失败原因。

具体的，如果UE版本是Rel-10(或者以上版本)，则基站需要丢弃当前第一RLF指示消息，之后基站将接收到第二RLF指示消息，此时该基站可以根据第二RLF指示消息确定UE的失败原因，该过程与现有技术中的处理过程类似，在此不再赘述。

步骤504，基站根据第一RLF指示消息确定UE的失败原因。

具体的，如果UE版本是Rel-9，则基站不会接收到第二RLF指示消息，此时该基站可以根据第一RLF指示消息确定UE的失败原因，该过程与现有技术中的处理过程(如图3中所示的处理流程)类似，在此不再赘述。

综上所述，本发明实施例中，使网络可以正确地处理基站之间交互的信息，正确的统计失败原因，避免错误的失败事件统计，并使得网络可以获得真实的问题分类统计数据，避免了错误地触发优化动作。

本发明实施例二提供一种长期演进系统中RLF指示消息的处理方法，当接收到同一个UE相关的两条RLF指示消息后，基站可避免对该两条RLF指示消息都做处理，从而避免了错误地触发优化动作。其中，由于携带了RLFreport信息的RLF指示消息可帮助基站更好地判断出UE的失败原因，因此，当基站接收到UE相关的没有携带RLF report信息的RLF指示消息(本发明实施例中以第一RLF指示消息为例进行说明)后，确定还可以接收到同一个UE的携带了RLF report信息的RLF指示消息(本发明实施例中以第二RLF指示消息为例进行说明)，则基站可以丢弃第一RLF指示消息，并只处理第二RLF指示消息。为了实现上述操作，在接收到第一RLF指示消息后，需要基站能够获知是否还会接收到同一个UE的第二RLF指示消息。

基于上述实施例，在本发明实施例中，还可以考虑UE是否具备RLF信息上报能力，此时不同版本的UE和基站组合的情况为：

第一种情况：具备RLF信息上报能力的Rel-10版本(或者Rel-10以上版本)的UE和Rel-10版本(或者Rel-10以上版本)的基站。

(1)当RRC连接重建失败时，重建基站可经过X2接口向失败基站发送没有携带RLF report信息的第一RLF指示消息。

(2)UE进入IDLE态，之后发起新的无线连接，并告知网络自身有RLF相关数据，连接建立后的新服务基站从UE获取RLF report信息，并经过X2接口向失败基站发送携带了RLF report信息的第二RLF指示消息。

因此，在具备RLF信息上报能力的Rel-10版本的UE和Rel-10版本(或者Rel-10以上版本)的基站通讯的情况下，基站可收到两条RLF INDICATION消息。

第二种情况：不具备RLF信息上报能力的Rel-10版本(或者Rel-10以上版本)的UE和Rel-10版本(或者Rel-10以上版本)的基站。

(1)当RRC连接重建失败时，重建基站可经过X2接口向失败基站发送没有携带RLF report信息的第一RLF指示消息。

(2)UE进入IDLE态，之后发起新的无线连接，由于UE不具备RLF信息上报能力，因此连接建立后新服务基站不会从UE获取RLF report信息，也无法生成和发送携带了RLF report信息的第二RLF指示消息。

因此，在不具备RLF信息上报能力的Rel-10版本的UE和Rel-10版本(或者Rel-10以上版本)的基站通讯的情况下，基站可收到一条RLF INDICATION消息。

第三种情况：Rel-9版本的UE和Rel-10版本(或者Rel-10以上版本)的基站。

(1)当RRC连接重建失败时，重建基站可经过X2接口向失败基站发送没有携带RLF report信息的第一RLF指示消息。

(2)UE进入IDLE态，之后发起新的无线连接，由于Rel-9版本的UE不告知网络自身是否有RLF相关数据，则新服务基站不从UE获取RLF report，也无法生成和发送携带了RLF report信息的第二RLF指示消息。

因此，在Rel-9版本的UE和Rel-10版本(或者Rel-10以上版本)的基站通讯的情况下，基站只接收到一条RLF INDICATION消息。

综上所述，只有在具备RLF信息上报能力的Rel-10UE与Rel-10基站通讯时，才产生两条RLF INDICATION消息。因此只要基站能够获得UE的版本信息以及UE是否具备上报RLF信息的能力，即可以知道是否会收到两条RLF INDICATION消息。

本发明实施例中，Rel-10版本的基站在接收到第一RLF指示消息后，需要获取UE的版本信息以及UE是否具备上报RLF信息的能力，以判断是否会收到第二RLF指示消息，然后采取相应的操作，该方法包括以下步骤：

(1)基站接收没有携带RLF report信息的第一RLF指示消息。其中，该基站包括但不限于Rel-10版本的基站以及更高版本的基站。

具体的，当UE重建连接失败时，则基站(即UE发生失败的小区所在基站)可以接收到第一RLF指示消息，其中包含UE在失败小区内的标识C-RNTI，基站可以通过该标识查询UE的上下文。

(2)如果基站还保留有UE的上下文，则从中获取UE的能力信息，其中包含了UE的版本信息以及是否具备上报RLF信息的能力信息。

具体的，根据UE的版本信息以及是否具备上报RLF信息的能力信息，如果UE版本小于预设版本(Rel-10版本)，则基站确定不能接收到第二RLF指示消息；如果UE版本大于等于预设版本(Rel-10版本)，且UE不具备上报RLF信息的能力信息，则基站确定不能接收到第二RLF指示消息；如果UE版本大于等于预设版本(Rel-10版本)，且UE具备上报RLF信息的能力信息，则基站确定可接收到第二RLF指示消息。

本发明实施例中，如果基站已经没有UE的上下文，则无法获得UE的版本信息及是否具备上报RLF信息的能力信息，该基站可以直接丢弃第一RLF指示消息，如果在之后接收到第二RLF指示消息，则根据第二RLF指示消息进行通常的处理，如果在之后没有接收到第二RLF指示消息，则结束流程。

(3)如果基站确定不能接收到第二RLF指示消息，则根据第一RLF指示消息确定UE的失败原因；如果基站确定可接收到第二RLF指示消息，则丢弃第一RLF指示消息，并根据第二RLF指示消息确定UE的失败原因。

为了更加清楚的阐述本发明实施例提供的技术方案，下面结合具体的应用场景对本发明实施例进行详细说明。

本发明实施例三提供一种长期演进系统中RLF指示消息的处理方法，该方法应用于Rel-10UE(具备RLF信息上报能力)和Rel-10基站进行通讯的场景中，该方法包括以下步骤：

(1)UE在基站A的小区发生无线链路失败，或者UE从基站A的小区向其它小区切换时失败。

(2)UE尝试恢复连接，执行小区选择，并选中基站B的小区尝试连接重建。此时，该UE需要记录下与RLF相关的数据，即RLF report。

(3)由于基站B没有该UE的上下文，则拒绝连接重建，并根据RRC连接重建请求消息中的信息，基站B通过X2接口向基站A发送没有携带RLFreport信息的第一RLF指示消息。

(4)基站A接收第一RLF指示消息，并根据第一RLF指示消息中携带的C-RNTI查询该UE的上下文。

如果没有该UE的上下文，则丢弃当前的第一RLF指示消息。

如果有该UE的上下文，则从上下文中获取UE的无线能力信息，并获知该UE的版本信息以及是否具备RLF信息上报能力，此时发现UE的版本信息为Rel-10且具备RLF信息上报能力。因此，该基站A获知还会接收到该UE相关的第二RLF指示消息，则丢弃当前的第一RLF指示消息。

(5)连接重建失败后UE进入IDLE态，经过一段时间UE在基站C(该基站可能与基站B相同，也可能与基站B不同)的小区内发起新的RRC连接，此时，UE与基站C交互并完成RRC连接建立过程，并在RRC连接建立完成消息中，UE通知网络自身有RLF report数据。在连接建立完成后，基站C从UE获取RLF report。

(6)基于RLF report中包含的失败前服务小区的全局标识ECGI，基站C寻址到该小区所在基站(本实施例中即为基站A)，并通过X2接口向基站A发携带了RLF report信息的第二RLF指示消息。

(7)基站A接收到第二RLF指示消息后，根据第二RLF指示消息中的信息，对UE的失败原因进行诊断。

本发明实施例四提供一种长期演进系统中RLF指示消息的处理方法，该方法应用于Rel-10UE(不具备RLF信息上报能力)和Rel-10基站进行通讯的场景中，该方法包括以下步骤：

(1)UE在基站A的小区发生无线链路失败，或者UE从基站A的小区向其它小区切换时失败。

(2)UE尝试恢复连接，执行小区选择，并选中基站B的小区尝试连接重建。此时，该UE需要记录下与RLF相关的数据，即RLF report。

(3)由于基站B没有该UE的上下文，则拒绝连接重建，并根据RRC连接重建请求消息中的信息，基站B通过X2接口向基站A发送没有携带RLFreport信息的第一RLF指示消息。

(4)基站A接收第一RLF指示消息，并根据第一RLF指示消息中携带的C-RNTI查询该UE的上下文。

如果没有该UE的上下文，则丢弃当前的第一RLF指示消息。

如果有该UE的上下文，则从上下文中获取UE的无线能力信息，并获知该UE的版本信息以及是否具备RLF信息上报能力，此时发现UE的版本信息为Rel-10且不具备RLF信息上报能力。因此，该基站A获知不会接收到该UE相关的第二RLF指示消息，并根据第一RLF指示消息确定UE的失败原因，该过程本发明实施例中不再赘述。

本发明实施例五提供一种长期演进系统中RLF指示消息的处理方法，该方法应用于Rel-9UE和Rel-10基站进行通讯的场景中，该方法包括以下步骤：

(1)UE在基站A的小区发生无线链路失败，或者UE从基站A的小区向其它小区切换时失败。

(2)UE尝试恢复连接，执行小区选择，并选中基站B的小区尝试连接重建。此时，该UE需要记录下与RLF相关的数据，即RLF report。

(3)由于基站B没有该UE的上下文，则拒绝连接重建，并根据RRC连接重建请求消息中的信息，基站B通过X2接口向基站A发送没有携带RLFreport信息的第一RLF指示消息。

(4)基站A接收第一RLF指示消息，并根据第一RLF指示消息中携带的C-RNTI查询该UE的上下文。

如果没有该UE的上下文，则丢弃当前的第一RLF指示消息。

如果有该UE的上下文，则从上下文中获取UE的无线能力信息，并获知该UE的版本信息，此时发现UE的版本信息为Rel-9。因此，该基站A获知不会接收到该UE相关的第二RLF指示消息，并根据第一RLF指示消息采用现有的处理方式对UE的失败原因进行诊断。

(5)连接重建失败后UE进入IDLE态，经过一段时间UE在基站C(该基站可能与基站B相同，也可能与基站B不同)的小区内发起新的RRC连接，此时，UE与基站C交互并完成RRC连接建立过程，在RRC连接建立完成消息中，UE不会通知网络自身是否有RLF report数据(因为该UE是Rel-9版本的UE)。由于基站C没有获得RLF report信息，则基站C不会向基站A发送第二RLF指示消息。

基于与上述方法同样的发明构思，本发明实施例中还提供了一种长期演进系统中RLF指示消息的处理设备，如图6所示，该设备包括：

第一接收模块11，用于接收没有携带RLF report信息的第一RLF指示消息；

判断模块12，用于当所述第一接收模块11接收到所述第一RLF指示消息时，判断是否能接收到携带了RLF report信息的第二RLF指示消息；

第二接收模块13，用于接收所述第二RLF指示消息；

处理模块14，用于当所述判断模块12的判断结果为是时，丢弃所述第一接收模块11接收到的所述第一RLF指示消息，并根据所述第二接收模块13接收到的所述第二RLF指示消息确定UE的失败原因；

当所述判断模块12的判断结果为否时，根据所述第一接收模块11接收到的所述第一RLF指示消息确定UE的失败原因。

所述判断模块12具体包括：

获取子模块121，用于获取所述UE的版本信息；

判断子模块122，用于根据所述获取子模块121获取的所述版本信息判断是否能接收到所述第二RLF指示消息。

所述第一RLF指示消息中携带了所述UE在失败小区内的标识信息；

所述获取子模块121，具体用于根据所述第一RLF指示消息中的标识信息查询所述UE的上下文；

如果在基站中有所述UE的上下文，则从所述UE的上下文中获取所述UE的版本信息。

所述判断子模块122，具体用于判断所述版本信息是否大于等于预设版本，如果是，则确定能接收到所述第二RLF指示消息；否则，确定不能接收到所述第二RLF指示消息。

获取子模块121，还用于获取所述UE的版本信息以及所述UE是否具备RLF信息上报能力信息；

判断子模块122，还用于根据所述版本信息以及是否具备RLF信息上报能力信息判断是否能接收到所述第二RLF指示消息。

所述第一RLF指示消息中携带了所述UE在失败小区内的标识信息；

所述获取子模块121，具体用于根据所述第一RLF指示消息中的标识信息查询所述UE的上下文；如果所述基站中有所述UE的上下文，则从所述UE的上下文中获取所述UE的版本信息以及所述UE是否具备RLF信息上报能力信息。

所述判断子模块122，具体用于判断所述版本信息是否大于等于预设版本且具备RLF信息上报能力信息；如果是，则确定能接收到所述第二RLF指示消息；否则，确定不能接收到所述第二RLF指示消息。

所述处理模块14，还用于如果在所述基站中没有所述UE的上下文，则丢弃所述第一RLF指示消息。

本发明实施例中，所述预设版本包括长期演进系统中的Rel-10版本。所述RLF指示消息的处理设备为基于长期演进系统Rel-10(或更高版本)标准的基站。

其中，本发明装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

可见，本发明实施例中，使网络可以正确地处理基站之间交互的RLF指示信息，正确的统计失败原因，避免错误的失败事件统计，并使得网络可以获得真实的问题分类统计数据，避免了错误地触发优化动作。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (20)

1.一种长期演进系统中无线链路失败RLF指示消息的处理方法，其特征在于，该方法包括：

当基站接收到没有携带RLF report信息的第一RLF指示消息时，所述基站判断是否能接收到携带了RLF report信息的第二RLF指示消息；

如果是，所述基站丢弃所述第一RLF指示消息，并根据接收到的第二RLF指示消息确定用户设备UE的失败原因；否则，所述基站根据所述第一RLF指示消息确定UE的失败原因。

2.如权利要求1所述的方法，其特征在于，所述基站判断是否能接收到携带了RLF report信息的第二RLF指示消息，包括：

所述基站获取所述UE的版本信息，并根据所述版本信息判断是否能接收到所述第二RLF指示消息。

3.如权利要求2所述的方法，其特征在于，所述第一RLF指示消息中携带了所述UE在失败小区内的标识信息；所述基站获取所述UE的版本信息，包括：

所述基站根据所述第一RLF指示消息中的标识信息查询所述UE的上下文；

如果所述基站中有所述UE的上下文，则所述基站从所述UE的上下文中获取所述UE的版本信息。

4.如权利要求2所述的方法，其特征在于，根据所述版本信息判断是否能接收到所述第二RLF指示消息，包括：

所述基站判断所述版本信息是否大于等于预设版本，如果是，则所述基站确定能接收到所述第二RLF指示消息；否则，所述基站确定不能接收到所述第二RLF指示消息。

5.如权利要求1所述的方法，其特征在于，所述基站判断是否能接收到携带了RLF report信息的第二RLF指示消息，包括：

所述基站获取所述UE的版本信息以及所述UE是否具备RLF信息上报能力信息，并根据所述版本信息以及是否具备RLF信息上报能力信息判断是否能接收到所述第二RLF指示消息。

6.如权利要求5所述的方法，其特征在于，所述第一RLF指示消息中携带了所述UE在失败小区内的标识信息；所述基站获取所述UE的版本信息以及所述UE是否具备RLF信息上报能力信息，包括：

所述基站根据所述第一RLF指示消息中的标识信息查询所述UE的上下文；如果所述基站中有所述UE的上下文，则所述基站从所述UE的上下文中获取所述UE的版本信息以及所述UE是否具备RLF信息上报能力信息。

7.如权利要求5所述的方法，其特征在于，根据所述版本信息以及是否具备RLF信息上报能力信息判断是否能接收到所述第二RLF指示消息，包括：

所述基站判断所述版本信息是否大于等于预设版本且具备RLF信息上报能力信息；如果是，则所述基站确定能接收到所述第二RLF指示消息；否则，所述基站确定不能接收到所述第二RLF指示消息。

8.如权利要求3或6所述的方法，其特征在于，所述基站根据所述第一RLF指示消息中的标识信息查询所述UE的上下文，之后还包括：

如果所述基站中没有所述UE的上下文，所述基站丢弃所述第一RLF指示消息。

9.如权利要求4或7所述的方法，其特征在于，所述预设版本包括长期演进系统中的Rel-10版本。

10.如权利要求1-7任一项所述的方法，其特征在于，所述基站为基于长期演进系统Rel-10标准的基站。

11.一种长期演进系统中RLF指示消息的处理设备，其特征在于，该设备包括：

第一接收模块，用于接收没有携带RLF report信息的第一RLF指示消息；

判断模块，用于当所述第一接收模块接收到所述第一RLF指示消息时，判断是否能接收到携带了RLF report信息的第二RLF指示消息；

第二接收模块，用于接收所述第二RLF指示消息；

处理模块，用于当所述判断模块的判断结果为是时，丢弃所述第一接收模块接收到的所述第一RLF指示消息，并根据所述第二接收模块接收到的所述第二RLF指示消息确定UE的失败原因；

当所述判断模块的判断结果为否时，根据所述第一接收模块接收到的所述第一RLF指示消息确定UE的失败原因。

12.如权利要求11所述的设备，其特征在于，所述判断模块具体包括：

获取子模块，用于获取所述UE的版本信息；

判断子模块，用于根据所述获取子模块获取的所述版本信息判断是否能接收到所述第二RLF指示消息。

13.如权利要求12所述的设备，其特征在于，所述第一RLF指示消息中携带了所述UE在失败小区内的标识信息；

所述获取子模块，具体用于根据所述第一RLF指示消息中的标识信息查询所述UE的上下文；

如果在基站中有所述UE的上下文，则从所述UE的上下文中获取所述UE的版本信息。

14.如权利要求12所述的设备，其特征在于，

所述判断子模块，具体用于判断所述版本信息是否大于等于预设版本，如果是，则确定能接收到所述第二RLF指示消息；否则，确定不能接收到所述第二RLF指示消息。

15.如权利要求11所述的设备，其特征在于，

获取子模块，还用于获取所述UE的版本信息以及所述UE是否具备RLF信息上报能力信息；

判断子模块，还用于根据所述版本信息以及是否具备RLF信息上报能力信息判断是否能接收到所述第二RLF指示消息。

16.如权利要求15所述的设备，其特征在于，所述第一RLF指示消息中携带了所述UE在失败小区内的标识信息；

所述获取子模块，具体用于根据所述第一RLF指示消息中的标识信息查询所述UE的上下文；如果所述基站中有所述UE的上下文，则从所述UE的上下文中获取所述UE的版本信息以及所述UE是否具备RLF信息上报能力信息。

17.如权利要求15所述的设备，其特征在于，

所述判断子模块，具体用于判断所述版本信息是否大于等于预设版本且具备RLF信息上报能力信息；如果是，则确定能接收到所述第二RLF指示消息；否则，确定不能接收到所述第二RLF指示消息。

18.如权利要求13或16所述的设备，其特征在于，

所述处理模块，还用于如果在所述基站中没有所述UE的上下文，则丢弃所述第一RLF指示消息。

19.如权利要求14或17所述的设备，其特征在于，所述预设版本包括长期演进系统中的Rel-10版本。

20.如权利要求11-17任一项所述的设备，其特征在于，所述RLF指示消息的处理设备为基于长期演进系统Rel-10标准的基站。

Images