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

1、语音业务杂音问题优化指导书(仅供内部使用)项目名称文档编号版 本 号1.0.0作 者RNC支撑项目组版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。文档更新记录日期更新人版本备注2009-7-6赵敏V0.0.1创建模板2009-7-16王锐、李彦峰、马忱、梁剑、杨蕾、施秉利、赵敏V0.0.2补充14、68章节内容2009-7-22赵敏V1.0.0根据中试、NB同事反馈，

2、补充4.4、4.5、7.3章节的内容。目录 HYPERLINK l _Toc236019658 1概述4 HYPERLINK l _Toc236019659 2语音杂音问题评估4 HYPERLINK l _Toc236019660 2.1语音QoS指标要求4 HYPERLINK l _Toc236019661 2.2可能的杂音情况7 HYPERLINK l _Toc236019662 3语音杂音问题CheckList7 HYPERLINK l _Toc236019663 4数据采集和分析8 HYPERLINK l _Toc236019664 4.1综述8 HYPERLINK l _Toc236

3、019665 4.2NodeB侧9 HYPERLINK l _Toc236019666 4.2.1 ATP抓日志的方法9 HYPERLINK l _Toc236019667 4.2.2 传输问题导致该现象的排查方法11 HYPERLINK l _Toc236019668 4.2.3 NODEB侧告警抓取和分析方法12 HYPERLINK l _Toc236019669 4.3RNC侧13 HYPERLINK l _Toc236019670 4.3.1 IMA物理传输的LOG抓取和分析方法13 HYPERLINK l _Toc236019671 4.3.2 RNC侧QOS跟踪LOG的抓取和分析方

4、法15 HYPERLINK l _Toc236019672 4.3.3 RNC侧IUUP统计抓取和分析方法16 HYPERLINK l _Toc236019673 4.3.4 语音环回使用方法介绍17 HYPERLINK l _Toc236019674 4.3.5 VP环回使用方法介绍（FP层）18 HYPERLINK l _Toc236019675 4.3.6 VP环回使用方法介绍（IUUP层）18 HYPERLINK l _Toc236019676 4.4UE侧19 HYPERLINK l _Toc236019677 4.4.1 SPAN Outum软件抓取终端信令信息19 HYPERLI

5、NK l _Toc236019678 4.4.2 miniPTAS软件联芯log21 HYPERLINK l _Toc236019679 4.5CN侧24 HYPERLINK l _Toc236019680 5案例24 HYPERLINK l _Toc236019681 5.1语音业务在切换过程中存在短暂的金属杂音24 HYPERLINK l _Toc236019682 5.2贵州省移动大楼语音质量问题25 HYPERLINK l _Toc236019683 5.3上行语音质量差26 HYPERLINK l _Toc236019684 5.4No DATA数据情况下出现噪音26 HYPERLI

6、NK l _Toc236019685 6总结27 HYPERLINK l _Toc236019686 7附录27 HYPERLINK l _Toc236019687 7.1端到端QoS技术原理27 HYPERLINK l _Toc236019688 7.2RNC相关参数汇总35 HYPERLINK l _Toc236019689 7.2.1 Iu参数配置35 HYPERLINK l _Toc236019690 7.2.2 RRM算法全局参数40 HYPERLINK l _Toc236019691 7.2.3 功率控制参数40 HYPERLINK l _Toc236019692 7.2.4 上行

7、外环功率控制参数46 HYPERLINK l _Toc236019693 7.2.5 业务质量测量参数47 HYPERLINK l _Toc236019694 7.2.6 业务同步参数50 HYPERLINK l _Toc236019695 7.2.7 业务QoS参数调度53 HYPERLINK l _Toc236019696 7.3NodeB相关参数汇总53 HYPERLINK l _Toc236019697 7.4其他业务QoS保证建议54 1 概述语音业务是传统业务，衡量该业务的QoS指标有以下几个方面：1） 时延，端到端的传输时延2） 抖动3） 误码率衡量这些指标可以用MOS来评判。

8、本文针对语音业务在网络优化中经常出现的杂音、甚至因为语音不清晰最终导致掉话、声音小等问题，描述了排查方法、数据采集和分析方法，并给出一些案例说明和原理、背景知识介绍。 本文定位于开局网优，比拼测试不在本文档的范围。 本文档中所描述的内容主要基于目前产品版本： RNC设备，TDR2000 RNC设备，TDR3000 相关工具和命令主要基于目前产品版本： LDT-R（RNC告警、日志的提取和分析；传输层和无线的信令跟踪和分析；QOS跟踪分析；RNC各子系统SHELL命令的查询）。 LMT-B。2 语音杂音问题评估2.1 语音QoS指标要求根据ITU相关规范，以下三个因素会影响话音质量： 话音清晰度

9、(Voice Clarity)； 话音效果，包括回声(Echo)、断续(Time-clipping)等； 时延(Time Delay)。由于话音效果会直接影响话音清晰度，故清晰度和时延是评估的重点。时延是一个可以精确到毫秒级的客观指标，在实际评估方面不会有何争议；相反，人们对于清晰度一直缺乏一种统一的评判标准。根据ITU规范，清晰度应该考虑以下几个因素： 受不同网络制式中不同类型失真(Distortion)的影响； 与时延无关； 与回声无关，因为回声是对发送方而言，清晰度是对接收方而言；在实际网络中影响清晰度的失真(Distortion)类型包括：1. 话音编解码(Encoding and D

10、ecoding of Voice)；2. 断续(Time-Clipping，也称为Dropouts)；3. 延时抖动(Jitter)；4. 环境噪音(Environment Noise)；5. 信号衰减(Signal Attenuation)；6. 电平削波(Level Clipping)；7. 传输信道误码(Transmission Channel Errors)；其中2与时延和信道质量相关，47都可归结为传输质量(BER/FER)这样分解成可量化的指标主要有3项：(1)网络延迟：网络延迟将引起语音会话过程的空白，带来语音的变形和会话的中断。E-Model关注的是End-to-End的网络延

11、迟。在实际应用中，一般是如下几个方面而导致了网络延迟：传播延时：取决于传播的介质和距离；传输延时：传输过程中在网络设备上所用时间；打包解包延时：用采用的Codec进行数模转换的时间，不同的Codec所导致的延时是不一样的，但是对于同一种Codec，其延时基本是固定的；抖动缓冲延时：在作用在接受端，为保持住一个或多个接收的数据包，克服网络抖动的影响。(2)网络抖动：网络抖动就是网络延时的变化，当网络抖动值大于50ms时，MOS值将急剧下降；但是在ITU-T G.107中，是这样说的：“抖动对语音传输质量的影响还在作进一步的研究，可通过在接收端增加抖动缓冲的量，则可以有效地降低抖动的影响，但是却增

12、加了网络延时。(3)FER或BER：FER是影响语音质量和MOS值的关键因素，随机出错，如果量小，对语音质量影响小；连续出错：这是指连续一个以上的数据包的出错，这对语音质量的影响是明显的。对于语音业务QoS来说，关键三点：时延、抖动、误码率。以下是参考MTTF E2E QoS研究WCDMA QoS网络KPI测试规范v1.1以及中移动2，3期应标外厂测试得出的一些量化值。 移动拨打固话(呼叫建立时延)Call Setup DelayCS Call Setup Delay-AMR (Mobile to PSTN)关闭鉴权3s3.5s打开鉴权3s4.5s此延迟定义为以下2条消息之间的时间间隔： RR

13、C Connection Request (CS) sent by the mobile RRC DownlinkDirectTransfer (CC Alerting) received by the mobile公式为： 固话拨打移动(呼叫建立时延)Call Setup DelayCS Call Setup Delay-AMR (PSTN to Mobile)关闭鉴权3s5s打开鉴权5s7s此延迟定义为以下2条消息之间的时间间隔： RANAP/Paging sent by the MSC RANAP/CC Alerting received by the MSC公式为： 移动拨打移动(呼叫

14、建立时延)Call Setup DelayCS Call Setup Delay-AMR (PSTN to Mobile)关闭鉴权4s6s打开鉴权5s7s此延迟定义为以下2条消息之间的时间间隔： RRC Connection Request (CS) sent by the mobile RRC DownlinkDirectTransfer (CC Alerting) received by the mobile公式为： 移动三期招标中兴/大唐(AMR呼叫建立时延比较)AMR呼叫建立时延 (Mobile to Mobile)项目(中兴三期/大唐三期/大唐二期)关鉴权4.604/5.115/6.

15、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 移

16、动三期招标中兴/大唐(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 bitsfor som

17、e applications, a higher BER class (10-2) might be feasible. FER 10-3 - limited practical application对于“抖动”，一般都需要通过MOS(仪)测试，下面是宁波移动在5月份进行的抖动测试数据。另外对于IUB接口的承载要区别ATM和IP，理论分析和正常测试都表明，IP传输比ATM传输时延要小。2.2 可能的杂音情况目前已经发现的杂音情况如下： 语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，通话能维持至结束； 语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，越来越差，但通话能维持至结

18、束； 语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，越来越差，不能维持(掉话)； 语音接入正常，一直伴随有轻微杂音，通话能维持至结束； 语音接入正常，一直伴随有轻微杂音，越来越差，但通话能维持至结束； 语音接入正常，一直伴随有轻微杂音，越来越差，不能维持(掉话)； 语音接入正常，有突发杂音(若干次)，通话能维持至结束； 语音接入正常，有突发杂音(若干次)，不能维持(掉话)； 语音接入正常，声音小，通话能维持至结束； 语音接入正常，声音小，越来越小，但通话能维持至结束； 语音接入正常，声音小，越来越小，不能维持(掉话)； 语音接入正常，背景音大(超出正常范围)，通话能维持至结束； 语音

19、接入正常，背景音大(超出正常范围)，不能维持(掉话)； 语音接入正常，音质清晰但有间断； 语音接入正常，音质不清晰伴随有间断； 语音接入正常，音质不清晰伴随有杂音和间断； 语音接入正常，切换时伴随金属杂音 语音接入至响铃，振铃间隙有杂音3 语音杂音问题CheckList针对UE、RAN（RNC/NB分开）、CN、IU口、其他，制定CheckList，方便现场快速缩小问题范围和定位故障。检查类别检查项自检1、UE检查1.1 更换其它品牌终端是否还存在话音质量问题1.2 出现问题终端在其它小区是否存在语音质量问题1.3 是否使用耳机连线，不使用耳机连线是否还存在话音质量问题。1.4使用固话拨打移动

20、电话、移动电话拨打固话是否有话音质量问题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上读组性能计数和状态，看是否有个

21、别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。查看IUU

22、P帧是否有抖动，即IUUP帧号不连续，跳变。4.2 Log中是否存在丢帧情况。4.3 Log中是否存在Pay load CRC校验错。4.3 Log中是否有“错误报告”的控制帧出现。4 数据采集和分析4.1 综述语音业务在接入以及通话过程中会存在各种各样的问题，但是问题定位和定位LOG的采集一般方法都很通用；(1) 语音业务接入过程中信令失败的定位方法首先如果语音在接入过程中信令失败，按照哪个网元返回失败那个网元先定位的原则，如果信令过程是终端、NODEB、CN返回的失败，一般除带有明显的错误原因外，首先需要其他网元分析失败的原因和抓取相应的LOG进行定位。其次如果接入过程是RNC返回失败导致

23、业务接入失败，那样一般需要先抓取小区详细级（带有RNC内子系统的信令交互过程，可以方便定位是哪个子系统返回德失败）信令跟踪来分析，一般内部失败都会带有失败原因，根据失败原因查找错误码表，找到对应的错误；另外需要根据失败原因采用对应的SHELL命令查找核对对应的资源信息，最后是根据失败返回的子系统，在LDT上开启对应得打印消息，抓取打印分析；这样一般的RNC问题就可以得到定位和解决。(2) 语音业务通话过程中问题的定位方法一般语音业务保持过程中，会存在掉话、切换失败、有杂音等问题，掉话和切换失败一般同上面的信令失败的定位方法，有杂音问题是在业务保持过程中存在丢弃数据包造成的，主要是定位在那个接口

24、（IU、UU、IUB）或者网元内部丢弃了数据包造成，目前各个网元基本都提供了定位的手段。RNC可以通过QOS跟踪来定位IUB口上行的数据是否存在丢包，如果存在丢包，则需要先查传输层是否有丢包，然后再根据业务处理的IUUP统计和业务处理计数器统计来定位是否在IUB口和RNC内部存在问题；另外RNC提供了语音环回功能，可以定位接入网内是否有问题；NODEB也提供了数据环回功能，可以定位空口到NODEB内部是否有问题，另外NODEB也提供了动态查询物理传输是否存在丢包的功能，可以方便定位物理层是否有问题。终端问题一般比较难定位，一般方法就是通过终端物理层抓取软件（TT）和信令抓取软件(outum)对

25、终端物理层何信令进行分析，另外也可以通过不同厂家的网络来进行对比测试验证，来定位是否是终端的问题。CN的问题一般接入网人员很难定位，一般需要借助CN侧专用分析工具才可以解析LOG来分析定位，一般如果定位到CN问题，可以找CN支持人员直接定位即可。语音排查流程图如下：4.2NodeB侧基站侧需要做好的工作： 查询基站软件版本、固件版本、一单开站中的时钟信息。 查询小区的ID、频点、码字。 理清“频点BBURRU”的对应关系。 查看小区ISCP的情况。 提取公共日志（初始化日志、告警日志、数据一致性文件、动态配置文件）、CCU41/43号日志、BBU全部日志、ATP消息。4.2.1 ATP抓日志的

26、方法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

27、_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

28、）后，搜索“CRNC_CC_ID=49821”，找到第一条消息对应的消息名应该是O_APSAPB_RL_SETUP_REQ，最后一条消息对应的消息名应该是O_APSAPB_RL_DEL_REQ。这样，就找到了一个完整的消息。截取两条消息之间的内容，搜索各关键字，看各关键消息是否抓到。如M1FC、CCBC、RNCFP、CCAPB等。4.2.2 传输问题导致该现象的排查方法1. 提取出现问题站点的告警日志。查看告警日志，具体操作方法参见4.2.3。检查是否存在大量“FP下行DCH CRC校验错误”和“FP收到TFI错误”告警。说明：少量马赛克，上述告警次数的量级在个位数的级别；明显马赛克，上述告警

29、次数量级在100以上；大量马赛克，上述告警次数量级在1000次以上。2. 用-B连接问题NB，查询 IMA信息-链路性能统计，刷新并关注各条激活IMA链路的“帧失步”和“接收非法ICP信元”、“接收STUFF信元数”统计。检查是否存在某条或某几条IMA链路的“帧失步”和“接收非法ICP信元”统计非零，统计值约为2个/秒的频率；”、“接收STUFF信元数”统计值为0。如果存在则记录下该IMA链路的“逻辑链路号”。以下是可选步骤：3. 在该站点下做VP业务，观察每次做VP业务时是否一定伴随大量NB FP 的下行DCH CRC校验告警（注意要等待一个告警过滤周期的时间）。4. 可以在RNC上用命令行

30、查询RNC的IMA发送统计信息，直接可以看到发送stuff计数。如果某一路发送stuff统计一直为0，而其他统计参数正常，再结合步骤2）的结果即可以确认该问题。如果同时存在(1)(2)(3)中所描述现象，则重点怀疑是目前RNC侧IMA传输（驱动）发送的问题。4.2.3 NODEB侧告警抓取和分析方法使用LMT-B工具。1） NODEB告警抓取方法如下图：说明：登陆LMT-B后，选择文件，然后上传需要的各种日志2） 告警打开分析方法如下图：3） NODEB常见告警分析一般通过NODEB告警可以看出物理传输层的问题和NDOEB本地小区以及载波是否存在问题，如果NODEB本地小区或者载波有问题，在告

31、警中也可以看到相应的告警，这样就可以判断NODEB本地小区和载波是否有问题。4.3 RNC侧使用LDT-R工具。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, 6drv_ima_ldt_task_count_print 芯片号, 1, 9drv_ima_ldt_imalink_event 芯片号,

32、链路号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传输问题），则

33、说明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_l

34、dt_imalink_alarm 芯片号, 链路号/查看打印结果中IMA链路的告警计数；当IMA组统计有信元丢弃时，再采用该命令查看IMA组内的那些IMA链路存在告警，以确认IMA组内的那些链路故障。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是否只在

35、在切换过程中存在误码，首先在位置不变得情况下保持通话，看QOS跟踪是否恒定在4200块，没有误码，此时移动UE，使得UE发生切换（在UE的工程信息和OMT上的小区内UE信息查询都可以查询UE是否进行了切换），然后看切换发生的28S内是否存在误码，然后再保持一段时间，看28S内的数据块和误码是否恢复正常，就可以确定是否是切换引起的误块。4.3.3 RNC侧IUUP统计抓取和分析方法1） 从LDT信令跟踪上确认需要环回语音的用户所在RTPA和DSP号，具体方法如下：在RAB指派后RNC本地资源分析消息中，查看倒数第二个响应消息，根据RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DS

36、PAddr后三位确定用户接入在1-2-13 RTPA业务板,根据DSPIP的最后一个字节确认在9号CPU（DSP）。2） 在1-2-13 9CPU的模拟shell上敲：rnc_tpss_iuup_shell3） 分析方法：一般查看语音从正常到有杂音前后IUUP统计那些错误统计项有变化。当语音正常没有误码时，IUUP错误统计项维持不变，当发生切换等产生误码后，IUUP错误统计项统计发生变化，说明有误码产生。4.3.4 语音环回使用方法介绍1） 从LDT信令跟踪上确认需要环回语音的用户所在RTPA和DSP号，具体方法如下：在RAB指派后RNC本地资源分析消息中，查看倒数第二个响应消息，根据RDBS

37、_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 VP环回使用方法介绍（FP层）1）首先根据信令跟踪分别找到主被叫用户所在DSP：在RAB指派后RNC本地资源分析消息中，查看倒数第二个

38、响应消息，根据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, 04.3.6 VP环回使用方法介绍（IUUP层）1） 首先根据信令跟踪分别找到主被叫用户所在

39、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, 04.4 UE侧目前U

40、E侧数据采集一般可以使用两种软件：1. SPAN Outum 5.02. miniPTAS4.4.1 SPAN Outum软件抓取终端信令信息Outum软件（SPAN Outum 5.0）可以抓取终端的各项测量信息和层三信令抓取各项测量信息的方法。第一步：在 outum软件的选择“Line chart”-在弹出的“Line chart”窗口-点击右键选择“属性”-在弹出的“设置Chart属性”窗口-点击“修改”如下图：第二步：在弹出的窗口中，在左侧选中需要添加的测量IE，单击“添加”-将选择的IE添加到左侧菜单中。在例子中添加一些测量值，具体测量值可以根据需要进行添加。第三步：单击“确定”键后

41、，完成添加，可以在“Line chart”窗口看到测量结果，完成测试后保存LOG，可以保存测试结果，供大家分析。抓取层三信令的方法：第一步：在 outum软件的选择“UU口消息”在弹出的窗口可以看到UU口的消息，双击每条信令可以看到每条信息的详细IE，在“UU口消息”界面右键弹出列表后，点击“Export Results”可以将UU口消息名、时间戳等保存出来。右键点击“UU口消息解码”可以将信令保存下来，共后台分析。4.4.2 miniPTAS软件联芯log目前联芯提供的miniPTAS版本，可以抓取各层LOG，但只提供了LOG抓取功能，不能对LOG在软件上进行分析，只能发回联芯进行分析。第一

42、步：单击“文件”-“新建”-“测试工程”-选择保存位置后，进行保存。第二步：单击“文件”-“新建”-“测试连接”-在弹出的界面上，查看是否是终端的链接-确认后，完成测试连接的建立。第三步：点击“连接”-在弹出菜单中-选择“连接”-在输出结果框中看到“已经连上”代表连接建立成功。第四步：点击“连接”-选择“无线参数”-在弹出的窗口选择需要抓取的LOG。第五步：使用终端发起业务，如果看到LOG数有变化，说明已经抓取了LOG第六步：保存后，发给联芯进行分析4.5 CN侧CN侧可以进行内部数据采集，但较麻烦，采集数据必须CN研发人员用专门的解码工具转换后方可看，解码工具不公开。因此，CN侧的数据采集需

43、要由CN研发人员来做。这里不作介绍。5 语音杂音问题不同原因分析5.1 语音保持过程中存在一直有杂音的情况1） 当语音业务保持过程中一直存在杂音时，首先需要检查传输是否正常，按照4.2.2节描述的排查IUB传输是否有问题2） 如果传输正常，杂音还存在，需要根据4.1节描述的问题定位流程进行排查5.2 语音保持过程中突然出现单通或者双方都听不到声音1） 首先根据4.3.2节描述获取QOS跟踪，确认是否误码较大2） 提取ISCP15分钟统计值，检查ISCP是否有突变的情况3） 检查NODEB告警是否有DSP故障告警4） 如果NDOEB存在DSP告警，一般是NODEB的BBU板卡出现问题，可以尝试替

44、换BBU进行测试，确认问题返修有问题的BBU5） 如果问题还不能解决需要按照4.1节流程进行排查5.3 语音保持双方静默时，主被叫均可以听到明显有节奏的噪音。若双方进行通话后，噪音会逐渐减轻1） 首先需要确认CN是那个厂商的设备，是否支持RFCI为NO_DATA（3个子流全0）的情况2） 如果CN支持RFCI为NO_DATA，则需要将RNC侧rIuRfci表里面的RFCI对应子流为0的字段删掉3） 如果问题还不能解决需要按照4.1节流程进行排查6 案例6.1 语音业务在切换过程中存在短暂的金属杂音问题描述：语音业务在接力切换过程中存在短暂的金属杂音问题分析：1） 传输排查：登陆LMT-B查看基

45、站IMA链路是否有“接收非法ICP信元错误”和“帧失步”，STUFF信元发送统计是否在增加，判断传输层是否有信元丢弃；经定位没有发现传输问题。2） 业务QOS统计：对用户进行多次切换QoS跟踪，发现切换前后的上行误码都为0，只有在发生切换时的28S内有误码产生；初步怀疑接力切换在实现上有问题。3） 查看小区切换方式，配置为接力切换，此时跟踪到的QoS切换误码范围为1026块，修改小区切换方式为硬切换，QoS跟踪发现切换时误码明显减少，范围为09，切换过程中杂音现象改善较大；经RNC研发确认RNC在接力切换目前的实现上存在问题，需要优化处理。4） 查看基站测告警进行分析，发现有DCH出窗告警，经

46、基站研发分析告警LOG，认为基站对于上行丢帧的处理方式和上行译码错误情况的处理方式需要改善；5） 检查无线环境，是否服务小区和临区RSCP值相当，这样需要优化无线环境解决方法：1） RNC侧处理：判断对于语音业务，如果基站FP数据帧中的QE值上报为218的话，丢弃该数据包，不向CN发送，但外环功控的BLER统计需要正常累加。RNC判断在切换状态下，如果两个小区上报的数据帧一个正确一个错误，选择正确的上报CN；如果两个小区上报的数据帧都错误，判断QE值，选择BER低上报CN。2） 基站侧处理方式 对于上行丢帧的处理方式（此情况对应于终端应正常发送上行数据，但基站未能检测到的情况）：a.PL层未通

47、过激活检测门限判断，即SJ上报CC的数据指示未通过激活检测；b.PL层通过激活检测，但CC对TFCI译码后，判断TFCI值超出建链参数的最大范围；对于以上两种情况，CC上报FP丢帧（CRCI填写为0 xff），FP上报RNC的数据帧中的CRCI指示为1，但QE值固定填写为218（对应0-255的协议值范围）。 对于上行译码错误情况的处理方式：PL层通过激活检测，且CC对TFCI译码在合理的范围内，但对传输信道的TB块译码后CRC校验错；对于这种情况，CC上报FP的CRCI为0 x80，误比特率BER值按照实际计算值上报，FP将BER值填写在QE位置供RNC使用。6.2 贵州省移动大楼语音质量问

48、题问题描述:移动李总反映在新华苑（贵州移动办公大楼）14楼语音模糊不清晰。移动投诉语音质量模糊不清楚的问题，复现情况描述如下：1） T网-G网，通话10分钟左右，突然上行出现单通，下行正常；2） T网-G网，通话两到三分钟，出现双方都听不到对方讲话。问题分析:测试人员在新华苑14楼进行了问题复现，我们发现语音质量模糊不清晰时占用的是茅台金波TD-1小区信号，通过RNC侧QoS信令跟踪发现上行误块率高，基站侧发现时隙干扰ISCP异常，上站提取告警发现同时有DSP任务运行故障告警，因此怀疑基站BBU板卡处理问题。解决方法:将茅台金波站的BBU板更换到红边门站测试时多次复现了语音质量问题，在茅台金波

49、站更换其他BBU板，大量测试下来语音质量良好，但偶尔仍有毛刺，经分析发现，新华苑为单HSDPA 配置，旁边的新华社为双HSDPA配置，HSDPA干扰了R4，将新华社改为单HSDPA配置后，再次经过大量测试，没有发现语音质量问题，语音模糊不清晰的原因就是基站BBU板卡和HSDPA干扰了R4业务。其它:将茅台金波站出现问题的BBU板已经反馈给北京研发分析定位。6.3 上行语音质量差问题描述:使用TD手机通话过程中出现语音不清晰现象问题分析:现场定位：第一：正常拨打语音电话，主被叫同时监听语音质量；存在语音不清晰现象，但出现概率很低，两天测试才抓到4次这样的现象。第二：拨打语音电话，然后触发小区间切

50、换、NB间切换；容易出现语音不清晰现象，比例大概在30%到40%。第三：拨打测试，主被叫同时监听语音质量。中间涉及到的变动包括更换基站版本、更换RRU、更换BBU槽位、更换基站（整站）、跳过室分系统、关闭外环功率控制。结果显示都存在话音不清晰问题。现场定位总结：1、接入后就会出现不清晰的现象，但没有切换触发的语音不清晰的概率高。2、语音不清晰的时候，从空口上看RSCP、C/I、UE发射功率均正常。3、室内分布3个基站（包含移动大楼）有语音不清晰问题，室外基站测试了2个小时没有出现语音不清晰的现象。4、从NB和RNC联合分析的结论：Iub口传输没有问题。研发定位：单机测试环境下，模拟组织上行语音

51、帧处理。由于考虑到该问题主要频繁出现在触发切换后（切换时容易出现时间抖动），因此模拟抖动情况进行测试。模拟组织上行语音帧，测试发现发送到CN的语音帧帧号错误，第一帧语音数据的帧号不为0，且后续的帧号不连续，这样就会导致CN在接收到语音帧并进行帧号检查时发现帧号错误，做出帧号异常情况处理，进而造成语音不清晰。代码走查发现，在目前的处理机制中，主调函数中每隔一个20ms调用一次上行数据处理函数。用户实体建立成功后，上行数据处理函数第一次被调用时没有判断是否是真正的数据，就当作是第一帧数据赋予初始帧号，这样的话，当第一帧真正的数据到来时帧号已经不是初始值。而且在第一帧数据到来时，没有存储当前的rfn

52、值，这样导致计算后续帧号时前一个rfn和当前rfn的差值diffrfn过大，由此计算出来的帧号不连续。解决方法:修改上行数据处理函数。在第一帧数据处理之前增加是否是真正数据的判断，只有真正的数据才赋予帧号。在第一帧数据处理中增加存储当前的rfn值，这样才能保证后续计算帧号时diffrfn为固定的差值，计算出来的帧号就是连续值。其他:该案例发生于2009年6月13日保定移动大楼。6.4 No DATA数据情况下出现噪音 问题描述： 手机互打，双方静默时，主被叫均可以听到明显有节奏的噪音。若双方进行通话后，噪音会逐渐减轻。CN测发送NO_DATA数据（即3个子流全部为0）的情况下，在终端会有杂音。

53、 定位过程： 判断CN是哪家的设备，因为有些厂家支持RFCI为NO_DATA（3个子流全0）的情况。如果CN不发NO_DATA数据，语音清晰。 阿尔卡特的CN支持全0的情况，而RNC在IUUP初始化消息里面携带了RFCI为全0的情况，所以CN认为RNC支持RFCI为NO_DATA，会下发全0的数据。此时双方静默时，主被叫均可以听到明显有节奏的噪音，判断可能是RNC对NO_DATA数据处理有问题，经与研发沟通，定位过程如下：只模拟发送下行12.2k语音帧，数据处理正常；只模拟发送下行静默帧（子流长度为39、0、0）数据处理正常；模拟发送下行NO_DATA数据（子流长度为0、0、0）数据处理有误；

54、模拟有抖动的情况下交替发送数据帧和静默帧，则数据不能正常发送。这是由于语音处理有2个缓存交替存储数据。正常情况下，只有一个缓存有数据，IU口每20ms来一包数据存下来。每20msMAC调度一次，MAC根据IUUP通知的数据量通知进行TFC选择，然后MAC根据选择结果从IUUP取数据，MAC加头之后交给FP处理，FP发送数据。 异常情况下（有抖动），两个缓存都有数据（语音数据和静默数据），由于当前缓存处理完毕之后IUUP通知MAC剩余数据量（下一个缓存的数据长度）有误，导致MAC TFC选择有误，当前缓存下的数据不能发送，导致语音质量差。 解决方法： 在当时RNC没有升级的情况下，如果CN支持R

55、FCI为NO_DATA，则需要将RNC侧rIuRfci表里面的RFCI对应子流为0的字段删掉；RNC升级版本后不会出现该问题。其他：该案例发生于2009年7月1日长春。7 总结本文针对语音业务网络优化中出现的语音不清晰甚至掉话、语音声音小、突发噪音等问题，描述了如何一步步排查这些问题的方法、以及需要采集的数据和抓取的log，并如何进行数据分析，最终问题解决。本文还给出了一些案例分析，通过这些案例积累对于我们解决类似问题也给出了很好的借鉴。另外也介绍了相关技术原理和背景知识。根据后续更多案例分析以及问题定位方法等积累，可以再进一步完善本文档。8 附录介绍相关背景知识、以及一些原理性知识。8.1

56、端到端QoS技术原理在描述E2E的QoS之前，我们先了解一下语音的呼叫流程。在TD-SCDMA系统中，一个呼叫的建立，首先是通过终端与网络侧的信令交互，也就是控制面的过程，完成用户面连接的建立。在一般的UMTS系统，一个标准的移动到移动的语音呼叫，原始信号(语音数据)首先在发起侧UE中编码，经过无线接口的传送，在本地代码转换机中转换成A律或者律PCM编码(符合ITU-TG.711 制式标准)后，在核心网中向远端传输；在远端代码转换机中再次进行代码转换，将PCM语音格式转换成为一种适合在无线接口上传送的编码格式，以便在远端无线接口上发送，最后在终结的UE中解码，这种呼叫连接在核心网内进行两次代码

57、转换，通常称为级联配置。在讲述语音的呼叫流程前，我们先要了解几个关键概念：编解码器、TFO、TrFO、AMR声码器、RFCI。其中TFO/TrFO的出现是因为编解码器的级联引入的两次代码转换降低了语音质量，当语音编解码器低速率工作时，这种影响尤为明显。而TFO(Tandem Free Operation)和TrFO(Transcoder Free Operation)机制的应用可以避免核心网内的两次代码转换，它们共同的特点都是TC不进行码转换（汇接），不将AMR语音编码转化为64kbps PCM编码，而是直接将AMR语音编码在网络中传输，从而大大地提高了语音QoS。 CODEC(COder a

58、nd DECoder)编解码器)用来对信息的原始表达方式进行采样，量化和编码使其成为某种形式的码流以及能将该码流进行解码使其还原成为原始表达方式的一种设备。在3G网络中，用于下行方向的编解码器位于MSC；而用于上行的位于UE手机终端中。位于MSC和UE中的CODEC需要接收RNC的信令，以便根据RNC的要求来动态地调节和使用编码速率。(上行是通过空中接口的控制面协议进行控制，对于下行，RNC通过Iu接口的用户面协议进行控制)。需要指出的是位于MSC中的编解码器也称为TranSCoder它用于将一种编码方式的信息转化成另一种不同的编码方式。通常是将AMR编码的压缩语音转换成PCM语音码流，或是反

59、之。注意：通常网络都具有ITU G.711 A-律的编解码器可将信息转换成为64Kb/s PCM语音码流。 TFO(Tandem Free Operation)在GSM网络发展的后期，出现了TFO机制，它是一种呼叫配置，在信号链路上物理地存在代码转换设备，但代码转换功能被绕过。这种做法被第三代移动通信系统UMTS网络继承，但具体实现时又有差异，在两端的呼叫建立阶段完成之后，媒体网关中的代码转换机设备交换根据ITU-T G。711 A律或律编码的传统64 kb/s PCM语音抽样。代码转换机通过窃取(stealing)每第16个抽样中的一个最不重要的比特位，交换TFO消息，进行两端UE中编解码器

60、的协商。如果两端的UE中应用了兼容的语音编解码类型，代码转换机自动激活TFO，传输压缩语音的信道被映射在64 kb/s的PCM编码的最不重要的比特位上。如果应用了不兼容的语音编解码类型，TFO就不能被立即激活，呼叫回到一般的代码转换级联操作模式下。但是，代码转换机还一直监视PCM信号中是否含有带内协商编解码的TFO消息，如果由于某种呼叫配置的改变，例如，远端发生了切换等，可能满足TFO建立的条件时，代码转换机将再次尝试发起和建立TFO(在TD系统中，TRO是基本支持功能项)。在一个连接中配置的两个编解码转换器它们都支持TFO协议并且配置一致的编解码类型。这样能够让压缩语音包在不进行编解码转换的