CN108271195B - 基于软硬采的信令关联分析方法和设备 - Google Patents

Abstract

提供了一种用于分析信令的方法和设备。所述用于分析信令的方法包括以下步骤：基于硬采的异常话单，筛选异常事件的异常原因；确定每个异常原因所对应的异常业务流程。所述信令关联分析步骤包括：根据软采的信令话单，分析异常信令与各接口处的流程的关联规则；基于所述关联规则，利用各个接口处的关键字段和时间戳来串联所述信令话单，从而确定所述异常业务流程产生的原因。

Description

基于软硬采的信令关联分析方法和设备

技术领域

本公开一般涉及无线网络，更具体地，涉及无线网络中基于软硬采的信令关联分析方法和设备。

背景技术

LTE网络扁平化后，原来可以通过2G、3G直接采集到的空口相关信息无法直接采集，但这些信息对分析无线网络问题非常有用，因此需要通过软硬采的方式获取这些数据。对于LTE***而言，数据采集主要是Uu、X2、S1、S11、S10、SGs、S6a、S5/S8等接口的接入和采集。通过对采集数据进行解析，可生成各接口的XDR(external data representation)格式的原始话单(也称为XDR话单)。每个话单可以由两个网元通过它们之间的接口发送的一来一回两条信令组成。如本领域公知的，信令指在通信***中除了传输用户信息之外，为使全网有轶序地工作，用来保证正常通信所需要的控制信号。信令通常表现为通信网络的不同网元之间传递的消息(以下，也称为信令消息)。信令包含多个代表信令的内容的字段(以下，也称为信元)，这些字段可由简单的单词或者单词的缩写构成的(例如，稍后将提到的CAUSE字段)。每个字段可被赋予数值，字段的值可以直接表示该字段的内容(例如，当CAUSE字段的值为1时，该字段的内容为TX2RELOCOverall Expiry)。

图1例示了LTE网络中的3GPP协议定义的多个网元(例如，UE，

eNB，MME等)以及各网元之间的接口(例如，UE和eNB之间的Uu口、eNB和MME之间的S1-MME口、eNB和eNB之间的X2口等)。其中，软采接口和硬采接口的示例性划分如虚线框所示。图1还示出了在接口上发送的信令(以下，也称为接口信令)可包含的字段(例如，在S1-MME口上发送的信令可包括MME UE S1AP ID字段、IMSI字段、GUTI字段等)，在图中被示于相应的接口名称后面(以下，简称为接口处的关键字段)，以冒号来引导。图1中所示的以及本文各处提及的各个网元、接口和字段的定义和具体描述可参见3GPP协议标准簇，该协议标准簇通过引用完全结合于此。

如本领域技术人员所知，在无线通信网络中，可通过多个网元之间的信息交互来完成各种业务。一个完整的业务流程可能需要经过多个网元，在不同网元之间的接口上可产生多条信令和话单。从网元之间的接口的角度来讲，每个接口上可能产生众多的信令和话单，这些信令和话单属于相同或不同的业务流程。图2示出了示例性业务流程，S1切换流程。其中，UE、S-eNB、T-eNB、CoreNetwork是如上所述的网元的示例，各个箭头上的单词或缩写的组合(例如Meas_RPRT等)表示各网元间发送的信令，箭头方向表示信令方向。从图2可见，S1切换流程会经过UE和S-eNB之间的接口，S-eNB和T-eNB之间的接口以及E-eNB和核心网之间的接口，因此根据3GPP协议的定义并参考图1所示，S1切换流程涉及UU口、X2口和S1-MME口。

现有的网络优化方案在对问题进行复现的时候，需要通过信令跟踪分析来确定问题所在。同时为了确保问题能够全面的体现出来，借助前场测试来进来空口质量的评估以及无线环境具体的体现。在全网指标优化上，只能做到小区级的模糊分析和优化，对问题的定界定位模糊不清，优化成效较低。

发明内容

传统的网络优化在分析问题过程中，需要通过信令跟踪分析、地理化分析、站点运营情况等手段分析，其中信令跟踪分析是在问题发生后再去跟踪定位，而且信令的捕捉需要单机版工具。单机版工具只能捕捉到单一接口信令，而网优分析需要多接口联合定位才能找到问题的准确原因。在全网层面上由于用户众多，海量信令混杂，在没有对应的关联分析算法上，无法甄别单用户，更别提该用户在多个接口上的信令关联。

根据本发明的一个方面，提供了一种用于基于软硬采的信令关联分析的方法，包括以下步骤：异常业务流程分析步骤，包括：基于硬采的异常话单，筛选异常事件的异常原因；确定每个异常原因所对应的异常业务流程；信令关联分析步骤，包括：根据软采的信令话单，分析异常信令与各接口处的流程的关联规则；基于所述关联规则，利用各个接口处的关键字段和时间戳来串联所述信令话单，从而确定所述异常业务流程产生的原因。

根据本发明的另一方面，提供了一种用于基于软硬采的信令关联分析的设备，包括以下装置：异常业务流程分析装置，包括：筛选模块，被配置成基于硬采的异常话单，筛选异常事件的异常原因；确定模块，被配置成确定每个异常原因所对应的异常业务流程；信令关联分析装置，包括：分析模块，被配置成根据软采的信令话单，分析异常信令与各接口处的流程的关联规则；串联模块，被配置成基于所述关联规则，利用各个接口处的关键字段和时间戳来串联所述信令话单，从而确定所述异常业务流程产生的原因。

使用本发明的实施例能够关联多个数据接口(例如，S1-MME、S1-U、S11、S6a、X2、UU等)的相关信令。根据时间戳以及关键字段实现了多接口间的信令串联，达到整个业务流程一体化。通过分析整个业务流程能够更好的分析异常信令的出现在哪个阶段，从而制定出相应的优化对策来规避异常问题。

附图说明

通过阅读以下参照附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显，其中，相同或相似的附图标记表示相同或相似的特征。在附图的图中，实施例是通过示例方式而非限制方式被例示的。

图1是例示了LTE网络中的网元、接口和每个接口的信令所包含的字段的示意图。

图2是例示了S1切换流程的时序的示意图。

图3是根据本公开的各种实施例的基于软硬采的示例性信令关联分析方法的流程图。

图4是根据本公开的各种实施例的基于软硬采的示例性信令关联分析设备的框图。

图5是可被用来实施本文描述的各种实施例的示例计算设备的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的实施方式；相反，提供这些实施方式使得本发明更全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而没有所述特定细节中的一个或更多，或者可以采用其它的方法、组元、材料等。在其它情况下，不详细示出或描述公知结构、材料或者操作以避免模糊本发明的主要技术创意。

结合图3描述根据本公开的实施例的基于软硬采的示例性信令关联分析方法300，所述方法300包括异常业务流程分析步骤301和信令关联分析步骤302。所述异常业务流程分析步骤301包括：基于硬采的异常话单，筛选异常事件的异常原因3011；确定每个异常原因所对应的异常业务流程3012。所述信令关联分析步骤302包括：根据软采的信令话单，分析异常信令与各接口处的流程的关联规则3021；基于所述关联规则，利用各个接口处的关键字段和时间戳来串联所述信令话单，从而确定所述异常业务流程产生的原因3022。

如上所述，软硬采的数据源包括S1-U、S11、SGs、S6a、Uu、S1-MME、X2等接口的话单。目前针对异常话单的分析维度包括掉线、脱网。异常事件的异常原因是掉线还是脱网可通过查看由eNB经由图1所示的S1-MME口向MME发起的S1AP_UE_CONTEXT_REL_REQ信令消息来确定。S1AP_UE_CONTEXT_REL_REQ消息由字段Procedure Type＝20来表征。如果该消息中的CAUSE字段等于1，3，6，8，9，10,21,26中的任一个，则可认为异常事件是因为掉线；如果该消息的CAUSE字段等于28，则可认为异常事件是因为脱网。上述CAUSE字段的不同取值又可代表不同的掉线和脱网的进一步原因。3GPP TS36.413协议规范中关于上下文释放(UE_CONTEXT_REL_REQ)字段的定义如表1所示。

表1 掉线CAUSE和脱网CAUSE说明

在异常话单中筛选出的异常原因后，可确定该异常原因对应的业务流程。本公开涉及的异常业务流程包括：站内执行流程失败，X2切换准备流程失败，X2切换执行流程失败，X2切换完成流程失败，S1切换准备流程失败，S1切换执行流程失败，S1切换完成流程失败，人工干涉，人为原因修改中断业务参数，UU口无线链路故障，终端人为误操作，盲重定向流程。在一些实施例中，可按表2所示的对应关系确定每个异常原因所 关联的异常业务流程或异常业务流程集合。表2是通过实际的测试经验获得的。

表2 异常原因及其关联的业务流程

信令关联分析步骤202包括时间关联、接口关联、X2信令关联和UU信令关联。

所述时间关联根据异常业务流程，依据协议(例如，3GPP协议)规定的各接口上的信令，提取各接口的与所述异常业务流程相关的话单时间起止范围。在一个实施例中，可通过异常话单信令涉及的数据接口的Procedure Start Time字段以及Procedure End Time字段所表示的时间点以及keyword字段的不同比特位确定话单属于什么业务流程，以及具体关联到哪些接口和信令。

所述接口关联例如在异常业务流程所涉及的各接口话单时间起止范围内，根据协议规定所述异常业务流程应该具有的话单类型搜索并定位需要关联的话单(以下，也称为目标话单)。在一些实施例中，可根据异常业务流程所涉及的数据接口的Procedure Type字段及上述CAUSE值找到用户IMSI字段，并根据该IMSI字段筛选该IMSI字段下的业务流程对应的接口话单，从而确定目标话单。

所述X2信令关联利用Failure Cause字段、Keyword字段、S1-MME UE APID字段、占用小区等信息，对X2口异常话单及原因进行定位。在一些实施例中，可在异常话单对应的接口确定后，用异常话单时间找到相关的X2口的Procedure Type字段及起始时间和结束时间，同时利用Failure Cause字段协助分析涉及的流程。

所述UU信令关联将S1-MME口、X2口、UU口话单进行串联，定位Uu口的异常话单及原因。在一些实施例中，可利用异常话单对应的接口的起始时间和X2口的结束时间，找到相关的UU口XDR格式的信令数据的Procedure Type字段以及Procedure Status字段，并借助Keyword字段分析是否包含MobilityControlInfo信元值。

需要说明的是，在以上描述中，Failure Cause、Keyword代表关键字段，可通过对应的字段值来确定涉及的信令。其中，Keyword字段分为Keyword1、Keyword3。在UU信令关联中，需要通过将Keyword十进制值转换成二进制。根据软采规范制定的Keyword字段的不同比特位代表关键信元，不同的关键信元代表不同的业务流程。

下面，以掉线CAUSE和脱网CAUSE为例，进一步描述用于上述表2中列举的一些流程的示例性关联分析方法。

X2切换准备流程失败

注：该异常业务流程(即X2切换准备流程失败)由S1口XDR数据的Procedure Type＝20和CAUSE＝26触发。

第一步：确定掉线对应的CAUSE以及时间；

确定S1口XDR数据Procedure Type＝20，且CAUSE＝26的流程的起始时间；

第二步：确定X2口切换流程以及时间；

1.在S1口起始时间的前20S去X2口找到距离最近的一个X2口Procedure Type＝1的流程，确定该X2口Procedure Type＝1的流程的起始时间和结束时间；

2.若该流程X2口的Procedure Type＝1且Procedure Status＝1，则判断X2切换准备流程失败；

第三步：关联UU口流程并确定切换定时器；

1.判断该流程S1口的起始时间后1S和X2口流程起始时间的前1S这两个时间点之间是否存在UU口XDR数据Procedure Type＝4的流程；

2.若UU口不存在Procedure Type＝4的流程，则判断随机接入参数配置；

(1)核查RA-ResponseWindowSize(该参数的取值范围为[SF7～SF10])、preambleInitial Received Target Power(该参数的取值范围为[-100～-104])、DELTA_PREAMBLE(该参数的取值范围为[0～2])、PREAMBLE_TRANSMISSION_COUNTER(该参数的取值范围为[8，10])、powerRampingStep(该参数的取值范围为[2，4])是否在上述合理配置范围内；注：参见3GPP 36.321第5.1.1节

(2)核查随机前导比例(该参数的取值范围为[30％～50％])、A组随机前导比例(该参数的取值范围为[30％～50％])是否在上述合理配置范围内；注：参见3GPP36.321第5.1.1节

随机前导序列个数＝4×rounddown，其中rounddown＝小区总前导序列个数×RandomPreambleRatio/4

A组随机前导序列个数＝4×roundup，其中rounddup＝随机前导序列个数×RaPreambleGrpARatio/4

3.若UU口存在Procedure Type＝4的流程，则关联S1口的起始时间后1S和X2口流程起始时间的前1S这两个时间点之间的Procedure Type＝4的流程；

4.若S1口的起始时间后1S和X2口流程起始时间的前1S这两个时间点之间Procedure Type＝4的流程的Procedure Status＝1且Keyword1的1bit位为1(确定切换失败)，则判断UU口Procedure Type＝4流程失败；

(1)判断UU口Procedure Type＝4的流程的Target Cell ID是否等于X2口Procedure Type＝1的流程的Source Cell ID，若相同，则判断重建返还源小区失败；

(2)判断UU口Procedure Type＝4的流程的Target Cell ID是否等于X2口Procedure Type＝1的流程的Source Cell ID，若不相同，则判断重建返还目标小区或者第三方小区失败；

5.核查重建相关的参数

(1)核查T311、N311、T301是否满足3GPP规范；注：参见3GPP 36.331第5.3.7.6节

(2)核查Procedure Type＝4的流程中的mac-ContentionResolutionTimer(该参数的取值范围为[7ms～64ms])配置；注：参见3GPP 36.321第5.1.1节

(3)核查当前站点是否具备X2口上下文传递功能；注：参见3GPP 36.423第7节；

X2切换执行流程失败

注：该异常业务流程(即X2切换执行流程失败)由S1口XDR数据的Procedure Type＝20和CAUSE＝1触发。

第一步：确定掉线对应的CAUSE以及时间；

确定S1口XDR数据Procedure Type＝20，且CAUSE＝1的流程的起始时间；

第二步：确定X2口切换流程以及时间；

1.在S1口起始时间的前20S去X2口找到距离最近的一个X2口Procedure Type＝1的流程，确定该X2口Procedure Type＝1的流程的起始时间&结束时间；

第三步：关联UU口流程RRC重新配置是否存在；

1.在S1口的起始时间后1S和X2口起始时间的前1S这两个时间点之间确定是否存在UU口XDR数据Procedure Type＝3的流程；

2.若UU口存在Procedure Type＝3且Procedure Status＝255且Keyword1字段3bit为1的流程，则判断UU口Procedure Type＝3的流程失败且X2切换执行流程失败；

(1)核查RA-ResponseWindowSize(该参数的取值范围为[SF7～SF10])、preambleInitial Received Target Power(该参数的取值范围为[-100～-104])、DELTA_PREAMBLE(该参数的取值范围为[0～2])、PREAMBLE_TRANSMISSION_COUNTER(该参数的取值范围为[8，10])、powerRampingStep(该参数的取值范围为[2，4])是否在上述合理配置范围内；注：参见3GPP 36.321第5.1.1节

(2)核查随机前导比例(该参数的取值范围为[30％～50％])、A组随机前导比例(该参数的取值范围为[30％～50％])是否在上述合理配置范围内；注：参见3GPP 36.321第5.1.1节

随机前导序列个数＝4×rounddown，其中rounddown＝小区总前导序列个数×RandomPreambleRatio/4

A组随机前导序列个数＝4×roundup，其中roundup＝随机前导序列个数×RaPreambleGrpARatio/4

(3)核查定时器T304(该参数的取值范围为[ms50，ms100，ms150，ms200，ms500，ms1000，ms2000])是否在上述合理配置范围内；注：参见3GPP 36.331第5.3.5.6节

第四步：关联是否存在重建流程；

1.确定X2切换执行流程失败后，在S1口的起始时间后1S和X2口流程起始时间的前1S两个时间点之间，判断UU口XDR数据是否存在Procedure Type＝4的流程；

2.若UU口不存在Procedure Type＝4的流程则判断随机接入参数配置；

(1)核查RA-ResponseWindowSize(该参数的取值范围为[SF7～SF10])、preambleInitial Received Target Power(该参数的取值范围为[-100～-104])、DELTA_PREAMBLE(该参数的取值范围为[0～2])、PREAMBLE_TRANSMISSION_COUNTER(该参数的取值范围为[8，10])、powerRampingStep(该参数的取值范围为[2，4])是否在上述合理配置范围内；注：参见3GPP 36.321第5.1.1节

(2)核查随机前导比例(该参数的取值范围为[30％～50％])、A组随机前导比例(该参数的取值范围为[30％～50％])是否在上述合理配置范围内；注：参见3GPP 36.321第5.1.1节

随机前导序列个数＝4×rounddown，其中rounddown＝小区总前导序列个数×RandomPreambleRatio/4

A组随机前导序列个数＝4×roundup，其中roundup＝随机前导序列个数×RaPreambleGrpARatio/4

3.若存在Procedure Type＝4的流程，则关联S1口的起始时间后1S和X2口流程起始时间的前1S这两个时间点之间的Procedure Type＝4的流程；

4.若S1口的起始时间后1S和X2口流程起始时间的前1S内这两个时间点之间的Procedure Type＝4的流程的Procedure Status＝1且Keyword1的1bit位为1(确定切换失败)，则判断UU口Procedure Type＝4的流程失败；

(1)判断UU口Procedure Type＝4的流程的Source PCI是否等于X2口ProcedureType＝1的流程对应的Source Cell ID的PCI，若相同，则判断重建返还源小区失败；

(2)判断UU口Procedure Type＝4的流程的Source PCI是否等于X2口ProcedureType＝1的流程对应的Source Cell ID的PCI，若不相同，则判断重建返还目标小区或者第三方小区失败；

5.核查重建相关的参数

(1)核查T311(该参数的取值范围为[ms1000，ms3000，ms5000，ms10000，ms15000，ms20000，ms30000])、N311(该参数的取值范围为[n1，n2，n3，n4，n5，n6，n8，n10]、T301[ms100，ms200，ms300，ms400，ms600，ms1000，ms1500，ms2000])是否在上述合理配置范围内；注：参见3GPP36.331第5.3.7.6节

(2)核查Procedure Type＝4中的mac-ContentionResolutionTimer(该参数的取值范围为[7ms～64ms])是否在上述合理配置范围内；注：参见3GPP 36.321第5.1.1节

(3)核查当前站点是否具备X2口上下文传递功能；注：参见3GPP 36.423第7节

X2切换完成流程失败

(1)确定S1口XDR数据Procedure Type＝20且CAUSE＝1或6的流程对应的起始时间点；

(2)在该流程S1口的起始时间后1S和X2口结束时间前1S之间的时间段内，判断是否存在S1口XDR数据Procedure Type＝14且Procedure Status＝空值的流程，若存在S1口Procedure Type＝14且Procedure Status＝空值(代表超时)，则判断X2切换完成流程失败；

重定向流程

注：该异常业务流程(即重定向流程)由S1口XDR数据的ProcedureType＝20和CAUSE＝28触发。

第一步：确定掉线对应的CAUSE以及时间；

1.确定S1口XDR数据Procedure Type＝20且CAUSE＝28的流程对应的起始时间点；

2.根据S1口Procedure Type＝20且Procedure Status＝0且CAUSE＝28，判断为重定向流程；

第二步：关联周期性测量事件

1.根据S1口Procedure Type＝20且CAUSE＝28对应的起始时间点，关联5s内最近一条RLF-Report或周期性MR(测量报告)，计算Srxlev和Srxqual任一一个(其中Srxlev＝Qrxlevmeas-Qrxlevmin-max(UE_TXP-WR_MAX_RACH-P_MAX，0)；Squal＝Qqualmeas-Qqualmin)，若Srxlev和Srxqual任一一个<＝0，则判断无线环境恶化导致脱网

第三步：关联UU口流程

判断UU口是否存在Procedure Type＝3的流程，若存在则判断为重定向流程

1.在S1口的Procedure Type＝20前后1S内找到UU口ProcedureType＝5且keyword1的1bit位为1，同时Redirected Network＝0、1(0代表重定向G网，1代表重定向TD网)的流程；

2.在S1口的Procedure Type＝20起始时间前10S内找到UU口最近的一条UE_MR消息，若MR type＝3，则判断为上报的A2事件并记录该消息时间点；

3.在UU口Procedure Type＝5的起始时间点以及UU口最近的一条UE_MR消息时间点内，判断UU口是否存在Procedure Type＝3的流程，若存在则判断为重定向流程；

(1)核查重定向参数(异***重定向开关、A1A2事件RSRP门限、异***A2RSRP门限偏置、异***A1 RSRP触发门限、异***A2 RSRP触发门限、基于覆盖的GERAN触发门限)

4.判断MR type＝3(表示A2事件)消息Serving RSRP是否低于弱覆盖门限，若低于弱覆盖门限，则判断为弱覆盖导致重定向；

5.若MRtype＝3(A2事件)消息Serving RSRP不低于弱覆盖门限，则判断为非覆盖导致重定向；

判断UU口是否存在Procedure Type＝3，若不存在则关联盲重定流程

1.在S1口的Procedure Type＝20前后1S内找到UU口Procedure Type＝5且keyword1的1bit位为1，同时Redirected Network＝0、1(0代表重定向G网，1代表重定向TD网)的流程；

2.在S1口的Procedure Type＝20起始时间前10S内找到UU口最近的一条UE_MR消息对应的时间点；

3.在UU口Procedure Type＝5的起始时间点以及UU口最近的一条UE_MR消息时间点内，判断UU口是否存在Procedure Type＝3的流程，若不存在则判断为盲重定向流程；

(1)核查重定向参数(异***盲重定向开关、最高级优先级异***、UTRAN***盲重定向优先级、GERAN***盲重定向优先级、UTRAN***连接态频率优先级、GERAN***连接态频率优先级)

4.判断MR type＝3(表示A2事件)消息Serving RSRP是否低于弱覆盖门限，若低于弱覆盖门限，则判断为弱覆盖导致盲重定向；

5.若MR type＝3(表示A2事件)消息Serving RSRP不低于弱覆盖门限，则判断为非覆盖导致盲重定向；

人为原因修改中断业务参数

注：该异常业务流程(即人为原因修改中断业务参数)由S1口XDR数据的ProcedureType＝20和CAUSE＝10触发。

1.确定S1口XDR数据Procedure Type＝20且CAUSE＝10的流程的起始时间。

2.在此时间前后1分钟内，通过网管OMC-＞***-＞日志管理-＞查看操作记录是否存在PCI的调整，若存在则判断人为操作触发；

UU口无线链路故障

注：该异常业务流程(即UU口无线链路故障)由S1口XDR数据的Procedure Type＝20和CAUSE＝21触发。

第一步：确定掉线对应的CAUSE以及时间；

确定S1口XDR数据Procedure Type＝20，且CAUSE＝21的流程的起始时间；

第二步：关联UU口释放流程

1.判断S1口Procedure Type＝20且CAUSE＝21的流程的结束时间点前后1S内，UU口是否存在最近的一条Procedure Type＝5的流程；

2.若存在UU口Procedure Type＝5的流程，则认为是无线链路故障；

第三步：关联UU口流程并确定相关参数配置；

1.判断S1口Procedure Type＝20且CAUSE＝21的流程的结束时间点前后1S内，UU口是否存在最近的一条Procedure Type＝4的流程；

2.若不存在UU口Procedure Type＝4的流程，则需要核查随机接入参数配置；

(1)核查RA-ResponseWindowSize(该参数的取值范围为[SF7～SF10])、preambleInitial Received Target Power(该参数的取值范围为[-100～-104])、DELTA_PREAMBLE(该参数的取值范围为[0～2])、PREAMBLE_TRANSMISSION_COUNTER(该参数的取值范围为[8，10])、powerRampingStep(该参数的取值范围为[2，4])是否在上述合理范围内；注：参见3GPP 36.321第5.1.1节

(2)核查随机前导比例(该参数的取值范围为[30％～50％])、A组随机前导比例(该参数的取值范围为[30％～50％])是否在上述合理范围内；注：参见3GPP 36.321第5.1.1节

随机前导序列个数＝4×rounddown，其中rounddown＝小区总前导序列个数×RandomPreambleRatio/4

A组随机前导序列个数＝4×roundup，其中roundup＝随机前导序列个数×RaPreambleGrpARatio/4

3.若存在UU口Procedure Type＝4的流程，则关联S1口的起始时间后1S和X2口流程起始时间的前1S这两个时间点之间的UU口ProcedureType＝4的流程；

4.若S1口的起始时间后1S和X2口流程起始时间的前1S这两个时间点之间的UU口Procedure Type＝4的流程Procedure Status＝1且Keyword1的1bit位为1(确定切换失败)，则判断UU口Procedure Type＝4的流程失败；

(1)判断UU口Procedure Type＝4的流程的Source PCI是否等于X2口ProcedureType＝1的流程对应的Source Cell ID的PCI，若相同，则判断重建返还源小区失败；

(2)判断UU口Procedure Type＝4的流程的Source PCI是否等于X2口ProcedureType＝1的流程对应的Source Cell ID的PCI，若不相同，则判断重建返还目标小区或者第三方小区失败；

5.核查重建相关的参数

(1)核查T311(该参数的取值范围为[ms1000，ms3000，ms5000，ms10000，ms15000，ms20000，ms30000])、N311(该参数的取值范围为[n1，n2，n3，n4，n5，n6，n8，n10])、T301(该参数的取值范围为[ms100，ms200，ms300，ms400，ms600，ms1000，ms1500，ms2000])是否在上述合理配置范围内；注：参见3GPP 36.331第5.3.7.6节

(2)核查Procedure Type＝4中的mac-ContentionResolutionTimer(该参数的取值范围为[7ms～64ms])是否在上述合理范围内；注：参见3GPP 36.321第5.1.1节

(3)核查当前站点是否具备X2口上下文传递功能；注：参见3GPP 36.423第7节

终端人为误操作

注：该异常业务流程(即终端人为误操作)由S1口XDR数据的Procedure Type＝20和CAUSE＝21触发。

1.确定S1口XDR数据Procedure Type＝20，且CAUSE＝21的流程的起始时间以及结束时间；

2.判断S1口Procedure Type＝20且CAUSE＝21的流程的结束时间点后的1S内，UU口是否存在最近的一条Procedure Type＝5的流程；

3.若不存在UU口Procedure Type＝5的流程，则认为终端人为误操作；人工干涉

注：该异常业务流程(即人工干涉)由S1口XDR数据的ProcedureType＝20和CAUSE＝3触发。

1.若S1口硬采XDR数据Procedure Type＝20且CAUSE＝3(表示O&MIntervention)，则判断为人为干预流程。

根据本公开实施例的基于软硬采的示例性信令关联分析方法相比于传统的网络优化方法具有以下优势：

(1)单用户信令关联分析减少了信令重新追溯；

(2)根据信令关联分析弥补了LTE扁平化后单站点信令跟踪不全面的缺陷；

(3)信令关联分析对网络分析问题有着重大的改善，能够更加精确的接近用户实际感知，减少不必要的信令元分析。只要通过对应的XDR字段就能够清晰的反应具体现象。

以上结合图3详细描述了根据本公开实施例的基于软硬采的示例性信令关联分析方法，下面结合图4描述根据本公开实施例的基于软硬采的示例性信令关联分析设备。

如图4所示，根据本公开另一个方面的基于软硬采的示例性信令关联分析设备400可包括异常业务流程分析装置401和信令关联分析装置402。其中异常业务流程分析装置401包括筛选模块4011和确定模块4012。筛选模块4011被配置成基于硬采的异常话单，筛选异常事件的异常原因(即，执行步骤3011)。确定模块4012被配置成确定每个异常原因所对应的异常业务流程(即，执行步骤3012)。信令关联分析装置402包括分析模块4021和串联模块4022。分析模块4021被配置成根据软采的信令话单，分析异常信令与各接口处的流程的关联规则(即，执行步骤3021)。串联模块4022被配置成基于所述关联规则，利用各接口处的关键字段和时间戳来串联所述信令话单，从而确定所述异常业务流程产生的原因(即，执行步骤3022)。

根据本公开实施例的基于软硬采的示例性信令关联分析设备400的其他细节与以上结合图3描述的相应方法相同，这里不再赘述。

结合图3和图4描述的基于软硬采的示例性信令关联分析方法和设备的至少一部分可以由计算设备实现。图5是示出能够实现根据本发明实施例的基于软硬采的示例性信令关联分析方法和设备的计算设备500的示例性硬件架构的结构图。如图5所示，计算设备500包括输入设备501、输入接口502、中央处理器503、存储器604、输出接口505、以及输出设备506。其中，输入接口502、中央处理器503、存储器504、以及输出接口505通过总线510相互连接，输入设备501和输出设备506分别通过输入接口502和输出接口505与总线510连接，进而与计算设备500的其他组件连接。具体地，输入设备501接收来自外部的输入信息，并通过输入接口502将输入信息传送到中央处理器503；中央处理器503基于存储器504中存储的计算机可执行指令对输入信息进行处理以生成输出信息，将输出信息临时或者永久地存储在存储器504中，然后通过输出接口505将输出信息传送到输出设备506；输出设备506将输出信息输出到计算设备500的外部供用户使用。

也就是说，图3和图4所示的基于软硬采的示例性信令关联分析方法和设备也可以被实现为包括：存储有计算机可执行指令的存储器；以及一个或多个处理器，该处理器在执行计算机可执行指令时可以实现结合图3和图4描述的基于软硬采的示例性信令关联分析方法和装置。

需要明确的是，本发明并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本发明的方法过 程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本发明的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

本发明可以以其他的具体形式实现，而不脱离其精神和本质特征。例如，特定实施例中所描述的算法可以被修改，而***体系结构并不脱离本发明的基本精神。因此，当前的实施例在所有方面都被看作是示例性的而非限定性的，本发明的范围由所附权利要求而非上述描述定义，并且，落入权利要求的含义和等同物的范围内的全部改变从而都被包括在本发明的范围之中。

Claims (6)

1.一种用于基于软硬采的信令关联分析的方法，包括以下步骤：

异常业务流程分析步骤，包括：

基于硬采的异常话单，筛选异常事件的异常原因；

确定每个异常原因所对应的异常业务流程；

信令关联分析步骤，包括：

根据软采的信令话单，分析异常信令与各接口处的流程的关联规则；

基于所述关联规则，利用各接口处的关键字段和时间戳来串联所述信令话单，从而确定所述异常业务流程产生的原因；

其中关联规则包括：

时间关联，根据所述异常业务流程，依据协议规定的各接口上的信令，提取各接口的与所述异常业务流程相关的话单时间起止范围；

接口关联，在各接口的话单时间起止范围内，根据协议规定所述异常业务流程具有的话单类型，搜索并定位需要关联的话单和接口；

信令关联，利用所述关键字段，串联所述需要关联的接口的异常话单，从而对原因进行定位。

2.根据权利要求1所述的方法，其中所述异常原因包括掉线和脱网。

3.根据权利要求1所述的方法，其中所述异常业务流程包括：站内执行流程失败，X2切换准备流程失败，X2切换执行流程失败，X2切换完成流程失败，S1切换准备流程失败，S1切换执行流程失败，S1切换完成流程失败，人工干涉，人为原因修改中断业务参数，UU口无线链路故障，终端人为误操作，盲重定向流程。

4.一种用于基于软硬采的信令关联分析的设备，包括以下装置：

异常业务流程分析装置，包括：

筛选模块，被配置成基于硬采的异常话单，筛选异常事件的异常原因；

确定模块，被配置成确定每个异常原因所对应的异常业务流程；

信令关联分析装置，包括：

分析模块，被配置成根据软采的信令话单，分析异常信令与各接口处的流程的关联规则；

串联模块，被配置成基于所述关联规则，利用各接口处的关键字段和时间戳来串联所述信令话单，从而确定所述异常业务流程产生的原因；

其中，关联规则包括：

时间关联装置，根据所述异常业务流程，依据协议规定的各接口上的信令，提取各接口的与所述异常业务流程相关的话单时间起止范围；

接口关联装置，在各接口的话单时间起止范围内，根据协议规定所述异常业务流程具有的话单类型，搜索并定位需要关联的话单和接口；

信令关联装置，利用所述关键字段，串联所述需要关联的接口的异常话单，从而对原因进行定位。

5.根据权利要求4所述的设备，其中所述异常原因包括掉线和脱网。

6.根据权利要求4所述的设备，其中所述异常业务流程包括：站内执行流程失败，X2切换准备流程失败，X2切换执行流程失败，X2切换完成流程失败，S1切换准备流程失败，S1切换执行流程失败，S1切换完成流程失败，人工干涉，人为原因修改中断业务参数，UU口无线链路故障，终端人为误操作，盲重定向流程。

Images