深圳联通第三方测试保障后台信令跟踪分析过程总结V10.docx
《深圳联通第三方测试保障后台信令跟踪分析过程总结V10.docx》由会员分享，可在线阅读，更多相关《深圳联通第三方测试保障后台信令跟踪分析过程总结V10.docx（17页珍藏版）》请在冰点文库上搜索。
深圳联通第三方测试保障后台信令跟踪分析过程总结V10
第三方测试保障后台信令跟踪分析过程V1.0
目录
1软件工具使用1
1.1后台信令抓取1
1.1.1后台信令抓取任务设置和过程1
1.1.2后台信令保存2
1.2信令文件处理工具2
1.2.1信令文件处理工具包2
1.2.2生成文件内容简介3
1.3PS业务速率统计4
2数据统计分析6
2.1测试号码业务定位6
2.1.1判断业务速率6
2.1.2判断业务主被叫6
2.2呼叫次数统计6
2.2.1CS业务呼叫次数统计方式6
2.2.1.1主叫相关次数统计7
2.2.1.2被叫相关次数统计8
2.2.2PS业务拨号相关次数统计方式10
2.3呼损分析11
2.3.1主叫呼损分析11
2.3.2被叫引起呼损分析11
2.3.3呼损案例分析12
2.4掉话分析13
2.4.1CS业务掉话分析13
2.4.2PS业务掉话分析13
2.5注意事项13
2.5.1IMSIDetachIndication异常13
2.5.2跨Iur口切换造成信令流程不完整13
2.5.32-3G互操作13
1软件工具使用
1.1后台信令抓取
1.1.1后台信令抓取任务设置和过程
本次深圳联通第三方测试主要在关内的8个RNC下测试，在信令跟踪Debug模式下，跟踪第三方测试的不同用户的RNLC_UESIGNALBYUEID任务信令。
首先在信令跟踪工具启动需要跟踪的RNC传输网络层的连接:
选择文件->连接，在弹出的对话框中选择或添加RNC的服务器名称，ip地址以及端口号：
然后跟踪用户IMSI，过程如下：
选择任务管理->创建RNL任务，填写任务名称，选择任务类型为：
RNLC_UESIGNALBYUEID信令：
再在任务详细设置中填写IMSI号，勾选所有选项。
1.1.2后台信令保存
深圳联通信令数据保存时间分上下午保存，分别保存.std格式和.txt格式。
注：
因为后续批处理工具需要使用.txt文档的格式的码流，.Std格式的码流也需要抓取，用于后期详细分析使用。
1.2信令文件处理工具
1.2.1信令文件处理工具包
该工具包包括UESigStat.exe和UESig.bat，同时需要站点信息列表索引文件。
其中站点信息索引文件需要放在C盘根目录下，即C：
\，使用文本编辑软件（UEdit、Notepad等）打开来编辑。
里面的数据以“cellid=23cellname=金华新联通-3”的格式来添加。
通过后台信令抓取工具SignalTraceTool抓取信令后，需要保存1个或若干个*.txt的信令码流文件，然后把start.bat、UESigStat.exe放到和该信令码流同目录下，右键单击start.bat点编辑，再在文本中UESigStat命令的后面添加上需要处理的若干个码流文件名即可（如果添加了不存在的文件名，运行时也会跳过，不影响其他文本的生成）。
举例如下：
A：
抓取信令后，需要保存1个或若干个*.txt的信令码流文件，然后把start.bat、UESigStat.exe放到和该信令码流同目录下；
B：
可以对Uesig.bat进行编辑，目的是在文本中UESigStat命令的后面添加上需要处理的若干个码流文件名：
C：
运行Uesig.bat，就可以在当前目录生成名称为之对应的多个*.txt，Report.txt的文本文件：
1.2.2生成文件内容简介
附生成的*.txt，Report.txt文本：
生成的文本大致分为4部分：
1部分：
为信令计数器列表，列举了流程中所有可能出现的信令并计数。
对分析失败所处的流程有很大的参考意义。
2部分：
为业务计数器列表，主要统计了该信令中各类业务主被叫成功和失败次数，其中Unkown为部分特殊信令流程，如注册、位置区更新等，需要在实际信令中确认。
3部分：
为每一次完整呼叫流程的关键信令，同时包括了信令的时间、方向、小区信息、时延等信息，对发现异常后的定位有很大帮助。
4部分：
为跑车路线。
1.3PS业务速率统计
PS业务后，需要在RNC端对前台速率进行评估，这里需要使用后台信令保存后的std格式文件。
显示如下：
导入std格式码流文件：
显示速率相关信息：
生成名称为RateRecord.csv的文件是按照一分钟粒度进行采用，表中给出了每次采用的时间和速率：
在本次第三方测试中统计PS业务的速率的平均值，以及采样次数。
2数据统计分析
2.1测试号码业务定位
2.1.1判断业务速率
有2种方式可以看业务速率：
第一种：
通过RAB_AssignmentRequestMsg信令中rAB_Parameters.maxBitrate.elem[0]=64000可以取得该业务上下行指派速率。
第二种：
通过IuupSetupReq信令中的消息如下行的dwUlAssignedBitRate=5760000可以取得该USIM的签约速率。
2.1.2判断业务主被叫
业务建立起来后，通过rrcConnectionRequest信令中establishmentCause=terminatingConversationalCall可以判断该业务是主叫还是被叫。
对于CS主叫业务，可以通过安全模式结束后第一个DirectTransfer（Setup）中的Numberingplanidentification=130********获取被叫的号码，从而方便将主被叫配对。
2.2呼叫次数统计
2.2.1CS业务呼叫次数统计方式
CS业务包括CS12.2K业务和CS64K业务，这两种业务在业务建立的时候所进过的信令流程相同，因此呼叫次数统计方式也相同。
2.2.1.1主叫相关次数统计
CS业务主叫呼叫包含如下信令，在第三方测试中，通常以RRCConnectionRequest到Alerting的信令流程为正常起呼，信令中包含了RRC建立流程、RAB建立流程、RB建立流程等，任何一个流程信令不完整而导致整个起呼信令不完整都可能认为是一次起呼失败。
步骤1：
获取主叫起呼次数
首先可以由信令处理软件生成的Report.txt中以下内容确认主叫次数（MOSucc+MOFail=158+1），可以得到初步的起呼次数
#########################################################
MOSucc=158MOFail=1
MTSucc=158MTFail=1
PSSucc=0PSFail=0
Unkown=1
#########################################################
步骤2：
获取主叫业务建立成功次数
由文本中MOSucc的计数可以得出主叫建立成功的次数。
步骤3：
获取主叫建立失败次数
由文本中MOFail可以进一步判断主叫建立失败次数。
（由于软件将ConnectDL被叫接听的信令作为呼叫成功的依据，但如AlertingDL后被叫未及时接听或挂断，也判断为一次建立失败，但此时应该根据实际情况来处理。
）
通过上述2个步骤可以初步得出主叫建立失败次数，但仍然需要对出现异常的信令进行分析，以进一步判断是否是符合测试规范中定义的呼损。
2.2.1.2被叫相关次数统计
CS业务被叫包含如下信令，在第三方测试中，通常以RRCConnectionRequest到Alerting的信令流程为正常起呼，信令中包含了RRC建立流程、RAB建立流程、RB建立流程等，任何一个流程信令不完整而导致整个起呼信令不完整都可能认为是一次起呼失败。
步骤1：
获取被叫寻呼到次数
首先可以由信令处理软件生成的Report.txt文本中以下内容确认被叫次数（MTSucc+MTFail），可以得到初步的被叫次数：
#########################################################
MOSucc=158MOFail=1
MTSucc=158MTFail=1
PSSucc=0PSFail=0
Unkown=1
#########################################################
步骤2：
获取被叫业务建立成功次数
由文本中MTSucc的计数可以得出被叫建立成功的次数。
步骤3：
获取被叫建立失败次数
由生成的文本中MTFail可以进一步判断被叫建立失败次数。
（由于软件将ConnectUL被叫接听的信令作为成功的依据，但如AlertingUL后被叫未及时接听或挂断，也判断为一次建立失败，但此时应该根据实际情况来处理。
）
通过上述2个步骤可以初步得出被叫建立失败次数，但仍然需要对出现异常的信令进行分析，以进一步判断是否是符合测试规范中定义的呼损。
2.2.2PS业务拨号相关次数统计方式
测试中PS业务没有主被叫之分，因此只需要判断PS业务起呼次数。
由于测试中可能下载完成导致转Idle，再回来时候是不需要重新拨号，因此只需要统计PDP激活的次数。
PS业务拨号相关流程如下图：
步骤1：
获取拨叫次数
首先可以由信令处理软件生成的Report.txt文本中以下内容确认拨叫次数（PSSucc+PSFail），可以得到初步的拨号次数：
#########################################################
MOSucc=158MOFail=1
MTSucc=158MTFail=1
PSSucc=5PSFail=0
Unkown=1
#########################################################
步骤2：
获取拨叫成功次数
由生成的文本中PSSucc的计数可以得出拨号建立成功的次数。
步骤3：
获取拨叫失败次数
由生成文本中PSFail的技术可以得出拨号建立失败的次数。
2.3呼损分析
2.3.1主叫呼损分析
确认主叫起呼的次数，可以通过rrcConnectionRequest、LocationUpdateReques和CMServiceRequest三条信令个数的关系来判断，如果rrcConnectionRequest=LocationUpdateRequest+CMServiceRequest，则可以判断RRC建立阶段没有失败，起呼次数为CMServiceRequest的个数。
如果上式不满足，则可以认为RRC建立阶段出现呼损，需要到具体信令中定位（这一步需要根据实际规范看是否算在业务呼损里）。
其次可以进一步判断，通过CMServiceRequest、CallProceeding、ConnectDL三条信令个数的关系可以判断呼损位置，如果CMServiceRequest=CallProceeding=ConnectDL，则可以判断业务建立阶段没有失败，建立成功次数为AlertingDL。
如果CMServiceRequest＞CallProceeding，则可能在RAB指派阶段产生了异常；如果CallProceeding＞ConnectDL，有可能是被叫切换到了其他RNC或发生了2-3G互操作。
具体异常需要到具体信令中定位。
2.3.2被叫引起呼损分析
其次可以进一步判断被叫寻呼到的次数，可以分别通过rrcConnectionRequest、LocationUpdateReques和PagingResponse三条信令个数的关系来判断，如果rrcConnectionRequest=LocationUpdateRequest+PagingResponse，则可以判断RRC建立阶段没有失败，被叫寻呼到次数为PagingResponse的个数。
如果上式不满足，则可以认为RRC建立阶段出现呼损，需要到具体信令中定位（这一步需要根据实际规范看是否算在业务呼损里）。
其次可以进一步通过PagingResponse、CallConfirm、ConnectUL三条信令个数的关系可以判断是否有呼损，如果PagingResponse=CallConfirm=ConnectUL，则可以判断业务建立阶段没有失败，建立成功次数为ConnectUL。
如果PagingResponse＞CallConfirm，则可能在其中阶段产生了异常；如果CallConfirm大于ConnectUL，则可能在业务建立产生了异常。
具体异常需要到具体信令中定位。
2.3.3呼损案例分析
以这次测试中的某一次呼损为例（这是一个2G呼3G的IMSI），下面给出初步的定位呼损原因的分析方法：
在生成的report.txt中的统计MOfail的次数可以认为是在这个RNC下此次导出的数据中可能出现呼损的次数
#########################################################
MOSucc=3MOFail=0
MTSucc=1MTFail=1
PSSucc=0PSFail=0
Unkown=6
#########################################################
再在这个文本文件中找到相关的呼损记录中的起呼流程如下，从该流程可以看出本次fail是被叫，在被叫振铃8s后发起了一个disconnect，为什么会disconnect呢？
根据时间点再到信令中去分析是哪里出了问题，从这条消息中我们可以看到disconnect的原因为userbusy，从而可以认为此次呼损是因为被叫用户因为繁忙而释放此次连接。
2.4掉话分析
2.4.1CS业务掉话分析
对CS业务来说，查找是否有Iu_ReleaseRequestMsg，如果有，一般为掉话，此时可以查看原信令文件查看相关信令流程，定位问题。
2.4.2PS业务掉话分析
对PS业务来说，查找是否有Iu_ReleaseRequestMsg，如果存在，则在原信令中查找到该Iu_ReleaseRequestMsg信令，看其cause.u.radioNetwork，判断过程如下：
●如果Cause值为TRANAP_user_inactivity，则PS业务为转空闲过程，不算掉话。
●如果Cause为其余值，则查看下一次rrcConnectionRequest后的第一次呼叫中是否存在PDPActiveRequest，如果有，说明下次业务建立为新的拨号，则上次Iu释放为掉话。
●根据Cause值和其余相关信息定位此次PS业务掉话原因。
2.5注意事项
2.5.1IMSIDetachIndication异常
在测试过程中，PS业务可能会出现IMSIDetach的情况，该情况是由于数据卡或终端硬件异常导致，不能算为一种掉话。
但在前面用生成的.t统计过程中会认为这是掉话。
需要将这类失败去掉。
2.5.2跨Iur口切换造成信令流程不完整
在测试过程中，跨Iur口切换业务可能会导致本RNC内信令流程不完整，从而影响掉话原因的分析，同时还可能造成在本RNC下主被叫呼叫次数的不一致。
此时需要将跨Iur口前后的2个数据综合分析，排除异常。
2.5.32-3G互操作
在测试过程中，有可能会出现23G互操作的情况，如果被叫到了2G从而被主叫寻呼到，则在RNC的统计中会少了这次被叫的建立成功，因此需要通过cellChangeOrderFromUTRAN或handoverFromUTRANCommand_GSM信令查看是否发生了23G互操作，从而定位呼叫是否成功，寻呼是否成功。
23G互操作也可能造成其他方面的统计问题（这种情况暂时还未遇到）
升级会员 