语音业务杂音问题优化指导书.docx

语音业务杂音问题优化指导书
(仅供内部使用)

项目名称

文档编号

版 本 号
1.0.0
作 者
RNC支撑项目组

版权所有
大唐移动通信设备有限公司

本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。

文档更新记录
日期
更新人
版本
备注

2009-7-6
赵敏
V0.0.1
创建模板
2009-7-16
王锐、李彦峰、马忱、梁剑、杨蕾、施秉利、赵敏
V0.0.2
补充1~4、6~8章节内容
2009-7-22
赵敏
V1.0.0
根据中试、NB同事反馈，补充4.4、4.5、7.3章节的内容。

目 录
1 概述 4
2 语音杂音问题评估 4
2.1 语音QoS指标要求 4
2.2 可能的杂音情况 7
3 语音杂音问题CheckList 7
4 数据采集和分析 8
4.1 综述 8
4.2 NodeB侧 9
4.2.1 ATP抓日志的方法 9
4.2.2 传输问题导致该现象的排查方法 11
4.2.3 NODEB侧告警抓取和分析方法 12
4.3 RNC侧 13
4.3.1 IMA物理传输的LOG抓取和分析方法 13
4.3.2 RNC侧QOS跟踪LOG的抓取和分析方法 15
4.3.3 RNC侧IUUP统计抓取和分析方法 16
4.3.4 语音环回使用方法介绍 17
4.3.5 VP环回使用方法介绍（FP层） 18
4.3.6 VP环回使用方法介绍（IUUP层） 18
4.4 UE侧 19
4.4.1 SPAN Outum软件抓取终端信令信息 19
4.4.2 miniPTAS软件联芯log 21
4.5 CN侧 24
5 案例 24
5.1 语音业务在切换过程中存在短暂的金属杂音 24
5.2 贵州省移动大楼语音质量问题 25
5.3 上行语音质量差 26
5.4 No DATA数据情况下出现噪音 26
6 总结 27
7 附录 27
7.1 端到端QoS技术原理 27
7.2 RNC相关参数汇总 35
7.2.1 Iu参数配置 35
7.2.2 RRM算法全局参数 40
7.2.3 功率控制参数 40
7.2.4 上行外环功率控制参数 46
7.2.5 业务质量测量参数 47
7.2.6 业务同步参数 50
7.2.7 业务QoS参数调度 53
7.3 NodeB相关参数汇总 53
7.4 其他业务QoS保证建议 54

1 1          概述
语音业务是传统业务，衡量该业务的QoS指标有以下几个方面：
1）  时延，端到端的传输时延
2）  抖动
3）  误码率
衡量这些指标可以用MOS来评判。
l         本文针对语音业务在网络优化中经常出现的杂音、甚至因为语音不清晰最终导致掉话、声音小等问题，描述了排查方法、数据采集和分析方法，并给出一些案例说明和原理、背景知识介绍。
l        
l         本文定位于开局网优，比拼测试不在本文档的范围。
l        
l         本文档中所描述的内容主要基于目前产品版本：
l         RNC设备，TDR2000
l         RNC设备，TDR3000
l         相关工具和命令主要基于目前产品版本：
l         LDT-R（RNC告警、日志的提取和分析；传输层和无线的信令跟踪和分析；QOS跟踪分析；RNC各子系统SHELL命令的查询）。
l         LMT-B。

2 2          语音杂音问题评估
2.1 2.1         语音QoS指标要求
根据ITU相关规范，以下三个因素会影响话音质量：
ü         话音清晰度(Voice Clarity)；
ü         话音效果，包括回声(Echo)、断续(Time-clipping)等；
ü         时延(Time Delay)。
由于话音效果会直接影响话音清晰度，故清晰度和时延是评估的重点。时延是一个可以精确到毫秒级的客观指标，在实际评估方面不会有何争议；相反，人们对于清晰度一直缺乏一种统一的评判标准。根据ITU规范，清晰度应该考虑以下几个因素：
ü         受不同网络制式中不同类型失真(Distortion)的影响；
ü         与时延无关；
ü         与回声无关，因为回声是对发送方而言，清晰度是对接收方而言；
在实际网络中影响清晰度的失真(Distortion)类型包括：
1.     话音编解码(Encoding and Decoding of Voice)；
2.     断续(Time-Clipping，也称为Dropouts)；
3.     延时抖动(Jitter)；
4.     环境噪音(Environment Noise)；
5.     信号衰减(Signal Attenuation)；
6.     电平削波(Level Clipping)；
7.     传输信道误码(Transmission Channel Errors)；
其中2与时延和信道质量相关，4－7都可归结为传输质量(BER/FER)
这样分解成可量化的指标主要有3项：
(1)网络延迟：网络延迟将引起语音会话过程的空白，带来语音的变形和会话的中断。E-Model关注的是End-to-End的网络延迟。在实际应用中，一般是如下几个方面而导致了网络延迟：传播延时：取决于传播的介质和距离；传输延时：传输过程中在网络设备上所用时间；打包解包延时：用采用的Codec进行数模转换的时间，不同的Codec所导致的延时是不一样的，但是对于同一种Codec，其延时基本是固定的；抖动缓冲延时：在作用在接受端，为保持住一个或多个接收的数据包，克服网络抖动的影响。
(2)网络抖动：网络抖动就是网络延时的变化，当网络抖动值大于50ms时，MOS值将急剧下降；但是在ITU-T G.107中，是这样说的：“抖动对语音传输质量的影响还在作进一步的研究，可通过在接收端增加抖动缓冲的量，则可以有效地降低抖动的影响，但是却增加了网络延时。
(3)FER或BER：FER是影响语音质量和MOS值的关键因素，随机出错，如果量小，对语音质量影响小；连续出错：这是指连续一个以上的数据包的出错，这对语音质量的影响是明显的。

对于语音业务QoS来说，关键三点：时延、抖动、误码率。以下是参考《MTTF E2E QoS研究－WCDMA QoS网络KPI测试规范v1.1》以及中移动2，3期应标外厂测试得出的一些量化值。

Ø         移动拨打固话(呼叫建立时延)
Call Setup Delay
CS Call Setup Delay-AMR (Mobile to PSTN)
关闭鉴权
<3s～3.5s
打开鉴权
<3s～4.5s
此延迟定义为以下2条消息之间的时间间隔：
l          RRC Connection Request (CS) sent by the mobile
l          RRC DownlinkDirectTransfer (CC Alerting) received by the mobile
公式为：

Ø         固话拨打移动(呼叫建立时延)
Call Setup Delay
CS Call Setup Delay-AMR (PSTN to Mobile)
关闭鉴权
<3s～5s
打开鉴权
<5s～7s
此延迟定义为以下2条消息之间的时间间隔：
l          RANAP/Paging sent by the MSC
l          RANAP/CC Alerting received by the MSC

公式为：

Ø         移动拨打移动(呼叫建立时延)
Call Setup Delay
CS Call Setup Delay-AMR (PSTN to Mobile)
关闭鉴权
<4s～6s
打开鉴权
<5s～7s
此延迟定义为以下2条消息之间的时间间隔：
l          RRC Connection Request (CS) sent by the mobile
l          RRC DownlinkDirectTransfer (CC Alerting) received by the mobile

公式为：
l         

Ø         移动三期招标中兴/大唐(AMR呼叫建立时延比较)
AMR呼叫建立时延 (Mobile to Mobile)
项目
(中兴三期/大唐三期/大唐二期)
关鉴权
4.604/5.115/6.269
开鉴权
5.334/5.932/6.788

Ø         移动三期招标中兴/大唐(CS 64K Streaming呼叫建立时延比较)
CS 64k 呼叫建立时延
项目
(中兴三期/大唐三期/大唐二期or大唐二期补测)
关鉴权
4.181/5.187/未测 or 5.603
开鉴权
5.046/6.228/6.472 or 6.586

Ø         移动三期招标中兴/大唐(语音与H并发业务呼叫建立时延比较)
HSDPA与R4 CS12.2k语音业务并发情况下，R4 CS12.2k语音业务呼叫建立时延 / 单位：s
项目
(中兴三期/大唐三期/大唐二期补测)
关鉴权
3.979/5.313/7.890
开鉴权
5.318/6.042/8.567

Ø         移动三期招标中兴/大唐(AMR12.2切换时延时延比较)
同一RNC内不同NodeB间，AMR硬切换时延
项目
(中兴三期/大唐三期/大唐二期补测)
信令面
0.455/0.402/0.826

误码率和传输抖动，在TS 23.107中有明确的定义：
AMR speech codec payload：
Ø         Bit rate: 4,75 - 12,2 kbit/s
Ø         Delay: end-to-end delay not to exceed 100ms (codec frame length is 20ms)
Ø         BER:
ü         10-4 for Class 1 bits
ü         10-3 for Class 2 bits
for some applications, a higher BER class (~10-2) might be feasible.
Ø         FER < 0,5% (with graceful degradation for higher erasure rates)

附：MPEG-4 video payload:
Ø         Bit rate: variable, average rate scalable from 24 to 128 kbit/s and higher
Ø         Delay:
ü         end-to-end delay between 150 and 400ms
ü         video codec delay is typically less than 200 ms
Ø         BER:
ü         10-6 - no visible degradation
ü         10-5 - little visible degradation
ü         10-4 - some visible artefacts
ü         > 10-3 - limited practical application

对于“抖动”，一般都需要通过MOS(仪)测试，下面是宁波移动在5月份进行的抖动测试数据。另外对于IUB接口的承载要区别ATM和IP，理论分析和正常测试都表明，IP传输比ATM传输时延要小。

2.2 2.2         可能的杂音情况
目前已经发现的杂音情况如下：
ü         语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，通话能维持至结束；
ü         语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，越来越差，但通话能维持至结束；
ü         语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，越来越差，不能维持(掉话)；
ü         语音接入正常，一直伴随有轻微杂音，通话能维持至结束；
ü         语音接入正常，一直伴随有轻微杂音，越来越差，但通话能维持至结束；
ü         语音接入正常，一直伴随有轻微杂音，越来越差，不能维持(掉话)；
ü         语音接入正常，有突发杂音(若干次)，通话能维持至结束；
ü         语音接入正常，有突发杂音(若干次)，不能维持(掉话)；
ü         语音接入正常，声音小，通话能维持至结束；
ü         语音接入正常，声音小，越来越小，但通话能维持至结束；
ü         语音接入正常，声音小，越来越小，不能维持(掉话)；
ü         语音接入正常，背景音大(超出正常范围)，通话能维持至结束；
ü         语音接入正常，背景音大(超出正常范围)，不能维持(掉话)；
ü         语音接入正常，音质清晰但有间断；
ü         语音接入正常，音质不清晰伴随有间断；
ü         语音接入正常，音质不清晰伴随有杂音和间断；
ü         语音接入正常，切换时伴随金属杂音
ü         语音接入至响铃，振铃间隙有杂音

3 3          语音杂音问题CheckList
针对UE、RAN（RNC/NB分开）、CN、IU口、其他，制定CheckList，方便现场快速缩小问题范围和定位故障。

检查类别
检查项
自检
1、UE检查
1.1 更换其它品牌终端是否还存在话音质量问题

1.2 出现问题终端在其它小区是否存在语音质量问题

1.3 是否使用耳机连线，不使用耳机连线是否还存在话音质量问题。

1.4使用固话拨打移动电话、移动电话拨打固话是否有话音质量问题

2、RNC检查
2.1 抓取Qos跟踪log，通过log初步分析是否有上行误码情况。
备注：Qos跟踪的每个统计周期(28S)的错误块数超过14块时，一般会出现明显话音质量变差现象。

2.2 提取对应时间段性能统计，看该小区的上行TS ISCP测量是否偏高。
备注：观察ISCP平均和最大值，一般大于-90dBm就认为有异常。

2.3测试小区周边小区相同时间段的TS ISCP是否异常。

2.4检查对应的传输IMA是否有告警连续有IMA帧失步（ICP帧错）。

2.5如果2.4有告警，在RNC的CASA板上做IMA组向RNC内部环回，在OMT上读ＭＡ组性能计数和状态，看是否有个别link ICP帧错误连续增加，说明IMA帧失步（ICP帧错）是CASA的IMA芯片产生。

2.6 MSC如果是诺西设备，检查RNC静态参数中IU信息->IU信息（索引为8），是否含有Iu-RFCI信息3（对应三个子流为全0的RFCI配置）。如果有，需要删除。

3、NB检查
3.1 LMT-B上是否有CRC检验出错告警；
3.2 LMT-B上是否有DSP任务运行故障告警。
3.3LMT_B上IMA链路是否有丢弃信元，STUFF信元发送是否正常增加
3.4LMT-B上是否有DCH的FP出窗告警
3.5LMT-B上是否有PCH的FP出窗告警

4、IU口
4.1 如果能够在IU口架表，可以抓取用户面Log。查看IUUP帧是否有抖动，即IUUP帧号不连续，跳变。

4.2 Log中是否存在丢帧情况。

4.3 Log中是否存在Pay load CRC校验错。

4.3 Log中是否有“错误报告”的控制帧出现。

4 4          数据采集和分析
4.1 4.1         综述
语音业务在接入以及通话过程中会存在各种各样的问题，但是问题定位和定位LOG的采集一般方法都很通用；
(1) 语音业务接入过程中信令失败的定位方法
首先如果语音在接入过程中信令失败，按照哪个网元返回失败那个网元先定位的原则，如果信令过程是终端、NODEB、CN返回的失败，一般除带有明显的错误原因外，首先需要其他网元分析失败的原因和抓取相应的LOG进行定位。
其次如果接入过程是RNC返回失败导致业务接入失败，那样一般需要先抓取小区详细级（带有RNC内子系统的信令交互过程，可以方便定位是哪个子系统返回德失败）信令跟踪来分析，一般内部失败都会带有失败原因，根据失败原因查找错误码表，找到对应的错误；另外需要根据失败原因采用对应的SHELL命令查找核对对应的资源信息，最后是根据失败返回的子系统，在LDT上开启对应得打印消息，抓取打印分析；这样一般的RNC问题就可以得到定位和解决。
(2) 语音业务通话过程中问题的定位方法
一般语音业务保持过程中，会存在掉话、切换失败、有杂音等问题，掉话和切换失败一般同上面的信令失败的定位方法，有杂音问题是在业务保持过程中存在丢弃数据包造成的，主要是定位在那个接口（IU、UU、IUB）或者网元内部丢弃了数据包造成，目前各个网元基本都提供了定位的手段。
RNC可以通过QOS跟踪来定位IUB口上行的数据是否存在丢包，如果存在丢包，则需要先查传输层是否有丢包，然后再根据业务处理的IUUP统计和业务处理计数器统计来定位是否在IUB口和RNC内部存在问题；另外RNC提供了语音环回功能，可以定位接入网内是否有问题；
NODEB也提供了数据环回功能，可以定位空口到NODEB内部是否有问题，另外NODEB也提供了动态查询物理传输是否存在丢包的功能，可以方便定位物理层是否有问题。
终端问题一般比较难定位，一般方法就是通过终端物理层抓取软件（TT）和信令抓取软件(outum)对终端物理层何信令进行分析，另外也可以通过不同厂家的网络来进行对比测试验证，来定位是否是终端的问题。
CN的问题一般接入网人员很难定位，一般需要借助CN侧专用分析工具才可以解析LOG来分析定位，一般如果定位到CN问题，可以找CN支持人员直接定位即可。
语音排查流程图如下：

4.2 4.2         NodeB侧
基站侧需要做好的工作：
Ø         查询基站软件版本、固件版本、一单开站中的时钟信息。
Ø         查询小区的ID、频点、码字。
Ø         理清“频点－BBU－RRU”的对应关系。
Ø         查看小区ISCP的情况。
Ø         提取公共日志（初始化日志、告警日志、数据一致性文件、动态配置文件）、CCU41/43号日志、BBU全部日志、ATP消息。

4.2.1 4.2.1        ATP抓日志的方法
1.         BCP消息跟踪，打开菜单“消息跟踪->跟踪设置”：
APB-PL 、PL-APB、APS-APB、APB-APS、APB-FP，用于跟踪BBU内部信令流程。
RNC-FP，用于抄出FPRNC、RNCFP的消息。
GTS-L2，用于抄出FPCC的消息。
PL-GTS，用于抄出PL的消息。
文件自动覆盖条件，按照实际需求设置，一般取默认值，可以大些50M。

2.         DSP之间相关消息跟踪，打开菜单“消息跟踪->测试消息设置”：
O_M1FC_INSTANT_TS，分析物理层测量上报。
O_SJCC_DATA，分析上行数据解调结果。
O_CCBC_VRU_DATA，分析CC给BC数据。
O_FCBC_CONTROL_DATA，分析下行发送功率和上行功控命令字。
O_CCFC_RL_SYNC_IND，分析FC同步结果。
O_FPFC_SIR_TARGET，分析外环功控结果。
CC的10号FPCC。
FP的11号FPRNC。
FP的12号RNCFP。
FP的13号CCFP，option3设置为255，分析CRCI译码结果。
需要按照现场实际情况设置跟踪的频点号。

3.         确认消息跟踪完整
出现问题后，不要立即关闭，等待10s左右关闭LOG。
在日志中搜索“CRNC_CC_ID=”，找到出现问题的ID（可以由RNC提供，也可以找到完整消息后向RNC确认CRNC-CommunicationContextID）。
确认ID（如49821）后，搜索“CRNC_CC_ID=49821”，找到第一条消息对应的消息名应该是O_APSAPB_RL_SETUP_REQ，最后一条消息对应的消息名应该是O_APSAPB_RL_DEL_REQ。这样，就找到了一个完整的消息。
截取两条消息之间的内容，搜索各关键字，看各关键消息是否抓到。如M1FC、CCBC、RNCFP、CCAPB等。

4.2.2 4.2.2        传输问题导致该现象的排查方法
1.         提取出现问题站点的告警日志。查看告警日志，具体操作方法参见4.2.3。
检查是否存在大量“FP下行DCH CRC校验错误”和“FP收到TFI错误”告警。
说明：少量马赛克，上述告警次数的量级在个位数的级别；明显马赛克，上述告警次数量级在100以上；大量马赛克，上述告警次数量级在1000次以上。
2.         用-B连接问题NB，查询 IMA信息->链路性能统计，刷新并关注各条激活IMA链路的“帧失步”和“接收非法ICP信元”、“接收STUFF信元数”统计。
检查是否存在某条或某几条IMA链路的“帧失步”和“接收非法ICP信元”统计非零，统计值约为2个/秒的频率；”、“接收STUFF信元数”统计值为0。如果存在则记录下该IMA链路的“逻辑链路号”。
以下是可选步骤：
3.         在该站点下做VP业务，观察每次做VP业务时是否一定伴随大量NB FP 的下行DCH CRC校验告警（注意要等待一个告警过滤周期的时间）。
4.         可以在RNC上用命令行查询RNC的IMA发送统计信息，直接可以看到发送stuff计数。如果某一路发送stuff统计一直为0，而其他统计参数正常，再结合步骤2）的结果即可以确认该问题。
如果同时存在(1)(2)((3))中所描述现象，则重点怀疑是目前RNC侧IMA传输（驱动）发送的问题。

4.2.3 4.2.3        NODEB侧告警抓取和分析方法
使用LMT-B工具。
1）  NODEB告警抓取方法如下图：

说明：登陆LMT-B后，选择文件，然后上传需要的各种日志

2）  告警打开分析方法如下图：

3）  NODEB常见告警分析
一般通过NODEB告警可以看出物理传输层的问题和NDOEB本地小区以及载波是否存在问题，如果NODEB本地小区或者载波有问题，在告警中也可以看到相应的告警，这样就可以判断NODEB本地小区和载波是否有问题。

4.3 4.3         RNC侧
使用LDT-R工具。
4.3.1 4.3.1        IMA物理传输的LOG抓取和分析方法
1）  在RNC侧接口板主CPU的SHELL上查询以下信息获取传输层IMA组和IMA链路信息

drv_ima_ldt_group_count 芯片号, IMA组号
drv_ima_ldt_imalink_count 芯片号, 链路号
drv_ima_ldt_task_count_print 芯片号, 0, 6
drv_ima_ldt_task_count_print 芯片号, 1, 9
drv_ima_ldt_imalink_event 芯片号, 链路号
drv_ima_ldt_imalink_alarm 芯片号, 链路号

2）  分析方法：
drv_ima_ldt_group_count 芯片号, IMA组号
//查看打印结果是否有丢弃计数，如果IMA组存在信元丢弃统计，下一步在RNC侧才需要确认是那些链路上有信元丢弃，需要查询IMA组内各个链路的信元统计情况；如果不存在，以下链路的统计命令则不需要执行，说明该IMA组工作正常

drv_ima_ldt_imalink_count 芯片号, 链路号
//查看打印结果中发送stuff信元个数，如果IMA组工作异常，查看RNC侧STUFF信元发送统计，如果RNC侧不发送STUFF信元（银川IMA传输问题），则说明RNC侧IMA工作异常。
drv_ima_ldt_task_count_print 芯片号, 0, 6
//查看打印结果中IMA组添加、删除的计数；当出现IMA组工作异常后，需要查询该统计以确认出现问题时是否进行过频繁的删除、添加操作还是因为IMA闪断引起的IMA工作异常

drv_ima_ldt_task_count_print 芯片号, 1, 9
//查看打印结果中IMA链路添加、删除的计数；当出现IMA组工作异常后，需要查询该统计以确认出现问题时是否进行过频繁的删除、添加操作还是因为IMA闪断引起的IMA工作异常

drv_ima_ldt_imalink_event 芯片号, 链路号
drv_ima_ldt_imalink_alarm 芯片号, 链路号
//查看打印结果中IMA链路的告警计数；当IMA组统计有信元丢弃时，再采用该命令查看IMA组内的那些IMA链路存在告警，以确认IMA组内的那些链路故障。

4.3.2 4.3.2        RNC侧QOS跟踪LOG的抓取和分析方法
1）  QOS跟踪抓取方法如下图：

2）  QOS跟踪分析方法如下图：

3）  分析方法：选择QOS跟踪界面的QOS分析，RNC侧只能分析上行QOS，针对语音业务，28S内的上下行TB块数应该保持一致，一般语音业务正常的TB块数为4200个（28s/20ms*3（语音业务块数）），如果上行有误块，说明传输或者NODEB到RNC的处理数据有问题。如UE是否只在在切换过程中存在误码，首先在位置不变得情况下保持通话，看QOS跟踪是否恒定在4200块，没有误码，此时移动UE，使得UE发生切换（在UE的工程信息和OMT上的小区内UE信息查询都可以查询UE是否进行了切换），然后看切换发生的28S内是否存在误码，然后再保持一段时间，看28S内的数据块和误码是否恢复正常，就可以确定是否是切换引起的误块。

4.3.3 4.3.3        RNC侧IUUP统计抓取和分析方法
1）  从LDT信令跟踪上确认需要环回语音的用户所在RTPA和DSP号，具体方法如下：

在RAB指派后RNC本地资源分析消息中，查看倒数第二个响应消息，根据RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13 RTPA业务板,根据DSPIP的最后一个字节确认在9号CPU（DSP）。

2）  在1-2-13 9CPU的模拟shell上敲：
rnc_tpss_iuup_shell

3）  分析方法：一般查看语音从正常到有杂音前后IUUP统计那些错误统计项有变化。当语音正常没有误码时，IUUP错误统计项维持不变，当发生切换等产生误码后，IUUP错误统计项统计发生变化，说明有误码产生。

4.3.4 4.3.4        语音环回使用方法介绍
1）  从LDT信令跟踪上确认需要环回语音的用户所在RTPA和DSP号，具体方法如下：

在RAB指派后RNC本地资源分析消息中，查看倒数第二个响应消息，根据RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13 RTPA业务板,根据DSPIP的最后一个字节确认在9号CPU（DSP）。

2）  在1-2-13 9CPU的模拟shell上敲：
rnc_tpss_iuup_sm_loop_para_set 1,UEID
这样可以打开此用户的语音环回功能，其他用户不受影响。

rnc_tpss_iuup_sm_loop_para_set 0,UEID
则关闭此用户的语音环回功能。

4.3.5 4.3.5        VP环回使用方法介绍（FP层）
1） 首先根据信令跟踪分别找到主被叫用户所在DSP：

在RAB指派后RNC本地资源分析消息中，查看倒数第二个响应消息，根据RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13 RTPA业务板,根据DSPIP的最后一个字节确认在9号CPU（DSP）。

2）   在RNC FP层进行环回：
打开环回：在用户所在DSP的模拟shell窗口中敲：
rnc_tpss_fp_vp_loop UeID, 0, 16777216, 0 （UEID根据信令跟踪中确定）
关闭环回：在用户所在DSP的模拟shell窗口中敲：
rnc_tpss_fp_vp_loop UeID, 0, 0, 0

4.3.6 4.3.6        VP环回使用方法介绍（IUUP层）
1）   首先根据信令跟踪分别找到主被叫用户所在DSP

在RAB指派后RNC本地资源分析消息中，查看倒数第二个响应消息，根据RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13 RTPA业务板,根据DSPIP的最后一个字节确认在9号CPU（DSP）。

2） 在RNC IUUP层进行环回：
打开环回：在用户所在DSP的模拟shell窗口中敲：
rnc_tpss_iuup_vp_loop UeID, 0, 16777216, 0 （UEID根据信令跟踪中确定）
关闭环回：在用户所在DSP的模拟shell窗口中敲：
rnc_tpss_iuup_vp_loop UeID, 0, 0, 0

4.4 4.4         UE侧
目前UE侧数据采集一般可以使用两种软件：
1.         SPAN Outum 5.0
2.         miniPTAS
4.4.1 4.4.1        SPAN Outum软件抓取终端信令信息
Outum软件（SPAN Outum 5.0）可以抓取终端的各项测量信息和层三信令抓取各项测量信息的方法。
第一步：在 outum软件的 选择“Line chart”->在弹出的“Line chart”窗口->点击右键选择“属性”->在弹出的“设置Chart属性”窗口->点击“修改”如下图：

第二步：在弹出的窗口中，在左侧选中需要添加的测量IE，单击“添加”->将选择的IE添加到左侧菜单中。
在例子中添加一些测量值，具体测量值可以根据需要进行添加。

第三步：单击“确定”键后，完成添加，可以在“Line chart”窗口看到测量结果，完成测试后保存LOG，可以保存测试结果，供大家分析。

抓取层三信令的方法：
第一步：在 outum软件的 选择“UU口消息”在弹出的窗口可以看到UU口的消息，双击每条信令可以看到每条信息的详细IE，在“UU口消息”界面右键弹出列表后，点击“Export Results”可以将UU口消息名、时间戳等保存出来。

右键点击“UU口消息解码”可以将信令保存下来，共后台分析。

4.4.2 4.4.2        miniPTAS软件联芯log
目前联芯提供的miniPTAS版本，可以抓取各层LOG，但只提供了LOG抓取功能，不能对LOG在软件上进行分析，只能发回联芯进行分析。

第一步：单击“文件”->“新建”->“测试工程”->选择保存位置后，进行保存。

第二步：单击“文件”->“新建”->“测试连接”->在弹出的界面上，查看是否是终端的链接->确认后，完成测试连接的建立。

第三步：点击“连接”->在弹出菜单中->选择“连接”->在输出结果框中看到“已经连上”代表连接建立成功。

第四步：点击“连接”->选择“无线参数”->在弹出的窗口选择需要抓取的LOG。

第五步：使用终端发起业务，如果看到LOG数有变化，说明已经抓取了LOG

第六步：保存后，发给联芯进行分析

4.5 4.5         CN侧
CN侧可以进行内部数据采集，但较麻烦，采集数据必须CN研发人员用专门的解码工具转换后方可看，解码工具不公开。因此，CN侧的数据采集需要由CN研发人员来做。这里不作介绍。

5 5          语音杂音问题不同原因分析
5.1 5.1         语音保持过程中存在一直有杂音的情况
1）  当语音业务保持过程中一直存在杂音时，首先需要检查传输是否正常，按照4.2.2节描述的排查IUB传输是否有问题
2）  如果传输正常，杂音还存在，需要根据4.1节描述的问题定位流程进行排查

5.2 5.2         语音保持过程中突然出现单通或者双方都听不到声音
1）  首先根据4.3.2节描述获取QOS跟踪，确认是否误码较大
2）  提取ISCP15分钟统计值，检查ISCP是否有突变的情况
3）  检查NODEB告警是否有DSP故障告警
4）  如果NDOEB存在DSP告警，一般是NODEB的BBU板卡出现问题，可以尝试替换BBU进行测试，确认问题返修有问题的BBU
5）  如果问题还不能解决需要按照4.1节流程进行排查

5.3 5.3         语音保持双方静默时，主被叫均可以听到明显有节奏的噪音。若双方进行通话后，噪音会逐渐减轻
1）              首先需要确认CN是那个厂商的设备，是否支持RFCI为NO_DATA（3个子流全0）的情况
2）              如果CN支持RFCI为NO_DATA，则需要将RNC侧rIuRfci表里面的RFCI对应子流为0的字段删掉
3）              如果问题还不能解决需要按照4.1节流程进行排查

6 6          案例
6.1 6.1         语音业务在切换过程中存在短暂的金属杂音
问题描述：
语音业务在接力切换过程中存在短暂的金属杂音
问题分析：
1）  传输排查：登陆LMT-B查看基站IMA链路是否有“接收非法ICP信元错误”和“帧失步”，STUFF信元发送统计是否在增加，判断传输层是否有信元丢弃；经定位没有发现传输问题。
2）  业务QOS统计：对用户进行多次切换QoS跟踪，发现切换前后的上行误码