语音业务杂音问题优化指导书.docx
《语音业务杂音问题优化指导书.docx》由会员分享，可在线阅读，更多相关《语音业务杂音问题优化指导书.docx（103页珍藏版）》请在冰点文库上搜索。
语音业务杂音问题优化指导书
语音业务杂音问题优化指导书
（仅供内部使用）
项目名称
文档编号
版本号
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语音杂音问题CheckList7
4数据采集和分析8
4.1综述8
4.2NodeB侧9
4.2.1ATP抓日志的方法9
4.2.2传输问题导致该现象的排查方法11
4.2.3NODEB侧告警抓取和分析方法12
4.3RNC侧13
4.3.1IMA物理传输的LOG抓取和分析方法13
4.3.2RNC侧QOS跟踪LOG的抓取和分析方法15
4.3.3RNC侧IUUP统计抓取和分析方法16
4.3.4语音环回使用方法介绍17
4.3.5VP环回使用方法介绍（FP层）18
4.3.6VP环回使用方法介绍（IUUP层）18
4.4UE侧19
4.4.1SPANOutum软件抓取终端信令信息19
4.4.2miniPTAS软件联芯log21
4.5CN侧24
5案例24
5.1语音业务在切换过程中存在短暂的金属杂音24
5.2贵州省移动大楼语音质量问题25
5.3上行语音质量差26
5.4NoDATA数据情况下出现噪音26
6总结27
7附录27
7.1端到端QoS技术原理27
7.2RNC相关参数汇总35
7.2.1Iu参数配置35
7.2.2RRM算法全局参数40
7.2.3功率控制参数40
7.2.4上行外环功率控制参数46
7.2.5业务质量测量参数47
7.2.6业务同步参数50
7.2.7业务QoS参数调度53
7.3NodeB相关参数汇总53
7.4其他业务QoS保证建议54
11 概述
语音业务是传统业务，衡量该业务的QoS指标有以下几个方面：
1） 时延，端到端的传输时延
2） 抖动
3） 误码率
衡量这些指标可以用MOS来评判。
● 本文针对语音业务在网络优化中经常出现的杂音、甚至因为语音不清晰最终导致掉话、声音小等问题，描述了排查方法、数据采集和分析方法，并给出一些案例说明和原理、背景知识介绍。
●
● 本文定位于开局网优，比拼测试不在本文档的范围。
●
● 本文档中所描述的内容主要基于目前产品版本：
● RNC设备，TDR2000
● RNC设备，TDR3000
● 相关工具和命令主要基于目前产品版本：
● LDT-R（RNC告警、日志的提取和分析；传输层和无线的信令跟踪和分析；QOS跟踪分析；RNC各子系统SHELL命令的查询）。
● LMT-B。
22 语音杂音问题评估
2.12.1 语音QoS指标要求
根据ITU相关规范，以下三个因素会影响话音质量：
✓ 话音清晰度（VoiceClarity）；
✓ 话音效果，包括回声（Echo）、断续（Time-clipping）等；
✓ 时延（TimeDelay）。
由于话音效果会直接影响话音清晰度，故清晰度和时延是评估的重点。
时延是一个可以精确到毫秒级的客观指标，在实际评估方面不会有何争议；相反，人们对于清晰度一直缺乏一种统一的评判标准。
根据ITU规范，清晰度应该考虑以下几个因素：
✓ 受不同网络制式中不同类型失真（Distortion）的影响；
✓ 与时延无关；
✓ 与回声无关，因为回声是对发送方而言，清晰度是对接收方而言；
在实际网络中影响清晰度的失真（Distortion）类型包括：
1. 话音编解码（EncodingandDecodingofVoice）；
2. 断续（Time-Clipping，也称为Dropouts）；
3. 延时抖动（Jitter）；
4. 环境噪音（EnvironmentNoise）；
5. 信号衰减（SignalAttenuation）；
6. 电平削波（LevelClipping）；
7. 传输信道误码（TransmissionChannelErrors）；
其中2与时延和信道质量相关，4－7都可归结为传输质量（BER/FER）
这样分解成可量化的指标主要有3项：
（1）网络延迟：
网络延迟将引起语音会话过程的空白，带来语音的变形和会话的中断。
E-Model关注的是End-to-End的网络延迟。
在实际应用中，一般是如下几个方面而导致了网络延迟：
传播延时：
取决于传播的介质和距离；传输延时：
传输过程中在网络设备上所用时间；打包解包延时：
用采用的Codec进行数模转换的时间，不同的Codec所导致的延时是不一样的，但是对于同一种Codec，其延时基本是固定的；抖动缓冲延时：
在作用在接受端，为保持住一个或多个接收的数据包，克服网络抖动的影响。
（2）网络抖动：
网络抖动就是网络延时的变化，当网络抖动值大于50ms时，MOS值将急剧下降；但是在ITU-TG.107中，是这样说的：
“抖动对语音传输质量的影响还在作进一步的研究，可通过在接收端增加抖动缓冲的量，则可以有效地降低抖动的影响，但是却增加了网络延时。
（3）FER或BER：
FER是影响语音质量和MOS值的关键因素，随机出错，如果量小，对语音质量影响小；连续出错：
这是指连续一个以上的数据包的出错，这对语音质量的影响是明显的。
对于语音业务QoS来说，关键三点：
时延、抖动、误码率。
以下是参考《MTTFE2EQoS研究－WCDMAQoS网络KPI测试规范v1.1》以及中移动2，3期应标外厂测试得出的一些量化值。
Ø 移动拨打固话（呼叫建立时延）
CallSetupDelay
CSCallSetupDelay-AMR（MobiletoPSTN）
关闭鉴权
<3s～3.5s
打开鉴权
<3s～4.5s
此延迟定义为以下2条消息之间的时间间隔：
● RRCConnectionRequest（CS）sentbythemobile
● RRCDownlinkDirectTransfer（CCAlerting）receivedbythemobile
公式为：
Ø 固话拨打移动（呼叫建立时延）
CallSetupDelay
CSCallSetupDelay-AMR（PSTNtoMobile）
关闭鉴权
<3s～5s
打开鉴权
<5s～7s
此延迟定义为以下2条消息之间的时间间隔：
● RANAP/PagingsentbytheMSC
● RANAP/CCAlertingreceivedbytheMSC
公式为：
Ø 移动拨打移动（呼叫建立时延）
CallSetupDelay
CSCallSetupDelay-AMR（PSTNtoMobile）
关闭鉴权
<4s～6s
打开鉴权
<5s～7s
此延迟定义为以下2条消息之间的时间间隔：
● RRCConnectionRequest（CS）sentbythemobile
● RRCDownlinkDirectTransfer（CCAlerting）receivedbythemobile
公式为：
●
Ø 移动三期招标中兴/大唐（AMR呼叫建立时延比较）
AMR呼叫建立时延（MobiletoMobile）
项目
（中兴三期/大唐三期/大唐二期）
关鉴权
4.604/5.115/6.269
开鉴权
5.334/5.932/6.788
Ø 移动三期招标中兴/大唐（CS64KStreaming呼叫建立时延比较）
CS64k呼叫建立时延
项目
（中兴三期/大唐三期/大唐二期or大唐二期补测）
关鉴权
4.181/5.187/未测or5.603
开鉴权
5.046/6.228/6.472or6.586
Ø 移动三期招标中兴/大唐（语音与H并发业务呼叫建立时延比较）
HSDPA与R4CS12.2k语音业务并发情况下，R4CS12.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
误码率和传输抖动，在TS23.107中有明确的定义：
AMRspeechcodecpayload：
Ø Bitrate:
4,75-12,2kbit/s
Ø Delay:
end-to-enddelaynottoexceed100ms（codecframelengthis20ms）
Ø BER:
✓ 10-4forClass1bits
✓ 10-3forClass2bits
forsomeapplications,ahigherBERclass（~10-2）mightbefeasible.
Ø FER<0,5%（withgracefuldegradationforhighererasurerates）
附：
MPEG-4videopayload:
Ø Bitrate:
variable,averageratescalablefrom24to128kbit/sandhigher
Ø Delay:
✓ end-to-enddelaybetween150and400ms
✓ videocodecdelayistypicallylessthan200ms
Ø BER:
✓ 10-6-novisibledegradation
✓ 10-5-littlevisibledegradation
✓ 10-4-somevisibleartefacts
✓ >10-3-limitedpracticalapplication
对于“抖动”，一般都需要通过MOS（仪）测试，下面是宁波移动在5月份进行的抖动测试数据。
另外对于IUB接口的承载要区别ATM和IP，理论分析和正常测试都表明，IP传输比ATM传输时延要小。
2.22.2 可能的杂音情况
目前已经发现的杂音情况如下：
✓ 语音接入正常，音质正常（没有杂音或者间断）但不是很清晰，通话能维持至结束；
✓ 语音接入正常，音质正常（没有杂音或者间断）但不是很清晰，越来越差，但通话能维持至结束；
✓ 语音接入正常，音质正常（没有杂音或者间断）但不是很清晰，越来越差，不能维持（掉话）；
✓ 语音接入正常，一直伴随有轻微杂音，通话能维持至结束；
✓ 语音接入正常，一直伴随有轻微杂音，越来越差，但通话能维持至结束；
✓ 语音接入正常，一直伴随有轻微杂音，越来越差，不能维持（掉话）；
✓ 语音接入正常，有突发杂音（若干次），通话能维持至结束；
✓ 语音接入正常，有突发杂音（若干次），不能维持（掉话）；
✓ 语音接入正常，声音小，通话能维持至结束；
✓ 语音接入正常，声音小，越来越小，但通话能维持至结束；
✓ 语音接入正常，声音小，越来越小，不能维持（掉话）；
✓ 语音接入正常，背景音大（超出正常范围），通话能维持至结束；
✓ 语音接入正常，背景音大（超出正常范围），不能维持（掉话）；
✓ 语音接入正常，音质清晰但有间断；
✓ 语音接入正常，音质不清晰伴随有间断；
✓ 语音接入正常，音质不清晰伴随有杂音和间断；
✓ 语音接入正常，切换时伴随金属杂音
✓ 语音接入至响铃，振铃间隙有杂音
33 语音杂音问题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提取对应时间段性能统计，看该小区的上行TSISCP测量是否偏高。
备注：
观察ISCP平均和最大值，一般大于-90dBm就认为有异常。
2.3测试小区周边小区相同时间段的TSISCP是否异常。
2.4检查对应的传输IMA是否有告警连续有IMA帧失步（ICP帧错）。
2.5如果2.4有告警，在RNC的CASA板上做IMA组向RNC内部环回，在OMT上读ＭＡ组性能计数和状态，看是否有个别linkICP帧错误连续增加，说明IMA帧失步（ICP帧错）是CASA的IMA芯片产生。
2.6MSC如果是诺西设备，检查RNC静态参数中IU信息->IU信息（索引为8），是否含有Iu-RFCI信息3（对应三个子流为全0的RFCI配置）。
如果有，需要删除。
3、NB检查
3.1LMT-B上是否有CRC检验出错告警；
3.2LMT-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.2Log中是否存在丢帧情况。
4.3Log中是否存在PayloadCRC校验错。
4.3Log中是否有“错误报告”的控制帧出现。
44 数据采集和分析
4.14.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.24.2 NodeB侧
基站侧需要做好的工作：
Ø 查询基站软件版本、固件版本、一单开站中的时钟信息。
Ø 查询小区的ID、频点、码字。
Ø 理清“频点－BBU－RRU”的对应关系。
Ø 查看小区ISCP的情况。
Ø 提取公共日志（初始化日志、告警日志、数据一致性文件、动态配置文件）、CCU41/43号日志、BBU全部日志、ATP消息。
4.2.14.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.24.2.2 传输问题导致该现象的排查方法
1. 提取出现问题站点的告警日志。
查看告警日志，具体操作方法参见4.2.3。
检查是否存在大量“FP下行DCHCRC校验错误”和“FP收到TFI错误”告警。
说明：
少量马赛克，上述告警次数的量级在个位数的级别；明显马赛克，上述告警次数量级在100以上；大量马赛克，上述告警次数量级在1000次以上。
2. 用-B连接问题NB，查询IMA信息->链路性能统计，刷新并关注各条激活IMA链路的“帧失步”和“接收非法ICP信元”、“接收STUFF信元数”统计。
检查是否存在某条或某几条IMA链路的“帧失步”和“接收非法ICP信元”统计非零，统计值约为2个/秒的频率；”、“接收STUFF信元数”统计值为0。
如果存在则记录下该IMA链路的“逻辑链路号”。
以下是可选步骤：
3. 在该站点下做VP业务，观察每次做VP业务时是否一定伴随大量NBFP的下行DCHCRC校验告警（注意要等待一个告警过滤周期的时间）。
4. 可以在RNC上用命令行查询RNC的IMA发送统计信息，直接可以看到发送stuff计数。
如果某一路发送stuff统计一直为0，而其他统计参数正常，再结合步骤2）的结果即可以确认该问题。
如果同时存在
（1）
（2）（（3））中所描述现象，则重点怀疑是目前RNC侧IMA传输（驱动）发送的问题。
4.2.34.2.3 NODEB侧告警抓取和分析方法
使用LMT-B工具。
1） NODEB告警抓取方法如下图：
说明：
登陆LMT-B后，选择文件，然后上传需要的各种日志
2） 告警打开分析方法如下图：
3） NODEB常见告警分析
一般通过NODEB告警可以看出物理传输层的问题和NDOEB本地小区以及载波是否存在问题，如果NODEB本地小区或者载波有问题，在告警中
升级会员 