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

WORD语音业务杂音问题优化指导书(仅供部使用)项目名称文档编号版 本 号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同事反馈，补充4.4、4.5、7.3章节的容。目 录1概述42语音杂音问题评估42.1语音QoS指标要求42.2可能的杂音情况73语音杂音问题CheckList74数据采集和分析84.1综述84.2NodeB侧94.2.1ATP抓日志的方法94.2.2传输问题导致该现象的排查方法114.2.3NODEB侧告警抓取和分析方法124.3RNC侧134.3.1IMA物理传输的LOG抓取和分析方法134.3.2RNC侧QOS跟踪LOG的抓取和分析方法154.3.3RNC侧IUUP统计抓取和分析方法164.3.4语音环回使用方法介绍174.3.5VP环回使用方法介绍（FP层）184.3.6VP环回使用方法介绍（IUUP层）184.4UE侧194.4.1SPAN Outum软件抓取终端信令信息194.4.2miniPTAS软件联芯log214.5CN侧245案例245.1语音业务在切换过程中存在短暂的金属杂音245.2省移动大楼语音质量问题255.3上行语音质量差265.4No DATA数据情况下出现噪音266总结277附录277.1端到端QoS技术原理277.2RNC相关参数汇总357.2.1Iu参数配置357.2.2RRM算法全局参数407.2.3功率控制参数407.2.4上行外环功率控制参数467.2.5业务质量测量参数477.2.6业务同步参数507.2.7业务QoS参数调度537.3NodeB相关参数汇总537.4其他业务QoS保证建议5455 / 551 概述语音业务是传统业务，衡量该业务的QoS指标有以下几个方面：1） 时延，端到端的传输时延2） 抖动3） 误码率衡量这些指标可以用MOS来评判。本文针对语音业务在网络优化中经常出现的杂音、甚至因为语音不清晰最终导致掉话、声音小等问题，描述了排查方法、数据采集和分析方法，并给出一些案例说明和原理、背景知识介绍。本文定位于开局网优，比拼测试不在本文档的围。本文档中所描述的容主要基于目前产品版本：RNC设备，TDR2000RNC设备，TDR3000相关工具和命令主要基于目前产品版本：LDT-R（RNC告警、日志的提取和分析；传输层和无线的信令跟踪和分析；QOS跟踪分析；RNC各子系统SHELL命令的查询）。LMT-B。2 语音杂音问题评估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与时延和信道质量相关，47都可归结为传输质量(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 DelayCS Call Setup Delay-AMR (Mobile to PSTN)关闭鉴权<3s3.5s打开鉴权<3s4.5s此延迟定义为以下2条消息之间的时间间隔：l RRC Connection Request (CS) sent by the mobilel RRC DownlinkDirectTransfer (CC Alerting) received by the mobile公式为：Ø 固话拨打移动(呼叫建立时延)Call Setup DelayCS Call Setup Delay-AMR (PSTN to Mobile)关闭鉴权<3s5s打开鉴权<5s7s此延迟定义为以下2条消息之间的时间间隔：l RANAP/Paging sent by the MSCl RANAP/CC Alerting received by the MSC公式为：Ø 移动拨打移动(呼叫建立时延)Call Setup DelayCS Call Setup Delay-AMR (PSTN to Mobile)关闭鉴权<4s6s打开鉴权<5s7s此延迟定义为以下2条消息之间的时间间隔：l RRC Connection Request (CS) sent by the mobilel 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 bitsfor 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 可能的杂音情况目前已经发现的杂音情况如下：ü 语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，通话能维持至结束；ü 语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，越来越差，但通话能维持至结束；ü 语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，越来越差，不能维持(掉话)；ü 语音接入正常，一直伴随有轻微杂音，通话能维持至结束；ü 语音接入正常，一直伴随有轻微杂音，越来越差，但通话能维持至结束；ü 语音接入正常，一直伴随有轻微杂音，越来越差，不能维持(掉话)；ü 语音接入正常，有突发杂音(若干次)，通话能维持至结束；ü 语音接入正常，有突发杂音(若干次)，不能维持(掉话)；ü 语音接入正常，声音小，通话能维持至结束；ü 语音接入正常，声音小，越来越小，但通话能维持至结束；ü 语音接入正常，声音小，越来越小，不能维持(掉话)；ü 语音接入正常，背景音大(超出正常围)，通话能维持至结束；ü 语音接入正常，背景音大(超出正常围)，不能维持(掉话)；ü 语音接入正常，音质清晰但有间断；ü 语音接入正常，音质不清晰伴随有间断；ü 语音接入正常，音质不清晰伴随有杂音和间断；ü 语音接入正常，切换时伴随金属杂音ü 语音接入至响铃，振铃间隙有杂音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.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支持人员直接定位即可。语音排查流程图如下：语音业务有杂音按照第3章检查按照第5章检查分析确认按照4.3节进行分析确认按照4.2节进行分析确认4.2 NodeB侧基站侧需要做好的工作：Ø 查询基站软件版本、固件版本、一单开站中的时钟信息。Ø 查询小区的ID、频点、码字。Ø 理清“频点BBURRU”的对应关系。Ø 查看小区ISCP的情况。Ø 提取公共日志（初始化日志、告警日志、数据一致性文件、动态配置文件）、CCU41/43号日志、BBU全部日志、ATP消息。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 传输问题导致该现象的排查方法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 NODEB侧告警抓取和分析方法使用LMT-B工具。1） NODEB告警抓取方法如下图：说明：登陆LMT-B后，选择文件，然后上传需要的各种日志2） 告警打开分析方法如下图：3） NODEB常见告警分析一般通过NODEB告警可以看出物理传输层的问题和NDOEB本地小区以与载波是否存在问题，如果NODEB本地小区或者载波有问题，在告警中也可以看到相应的告警，这样就可以判断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 芯片号, 链路号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 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 RNC侧IUUP统计抓取和分析方法1） 从LDT信令跟踪上确认需要环回语音的用户所在RTPA和DSP号，具体方法如下：在RAB指派后RNC本地资源分析消息中，查看倒数第二个响应消息，根据RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13RTPA业务板,根据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_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13RTPA业务板,根据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本地资源分析消息中，查看倒数第二个响应消息，根据RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13RTPA业务板,根据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） 首先根据信令跟踪分别找到主被叫用户所在DSP在RAB指派后RNC本地资源分析消息中，查看倒数第二个响应消息，根据RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位确定用户接入在1-2-13RTPA业务板,根据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侧目前UE侧数据采集一般可以使用两种软件：1. SPAN Outum 5.02. miniPTAS4.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 miniPTAS软件联芯log目前联芯提供的miniPTAS版本，可以抓取各层LOG，但只提供了LOG抓取功能，不能对LOG在软件上进行分析，只能发回联芯进行分析。第一步：单击“文件”->“新建”->“测试工程”->选择保存位置后，进行保存。第二步：单击“文件”->“新建”->“测试连接”->在弹出的界面上，查看是否是终端的->确认后，完成测试连接的建立。第三步：点击“连接”->在弹出菜单中->选择“连接”->在输出结果框中看到“已经连上”代表连接建立成功。第四步：点击“连接”->选择“无线参数”->在弹出的窗口选择需要抓取的LOG。第五步：使用终端发起业务，如果看到LOG数有变化，说明已经抓取了LOG第六步：保存后，发给联芯进行分析4.5 CN侧CN侧可以进行部数据采集，但较麻烦，采集数据必须CN研发人员用专门的解码工具转换后方可看，解码工具不公开。因此，CN侧的数据采集需要由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板卡出现问题，可以尝试替换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查看基站IMA链路是否有“接收非法ICP信元错误”和“帧失步”，STUFF信元发送统计是否在增加，判断传输层是否有信元丢弃；经定位没有发现传输问题。2） 业务QOS统计：对用户进行多次切换QoS跟踪，发现切换前后的上行误码都为0，只有在发生切换时的28S有误码产生；初步怀疑接力切换在实现上有问题。3） 查看小区切换方式，配置为接力切换，此时跟踪到的QoS切换误码围为1026块，修改小区切换方式为硬切换，QoS跟踪发现切换时误码明显减少，围为09，切换过程中杂音现象改善较大；经RNC研发确认RNC在接力切换目前的实现上存在问题，需要优化处理。4） 查看基站测告警进行分析，发现有DCH出窗告警，经基站研发分析告警LOG，认为基站对于上行丢帧的处理方式和上行译码错误情况的处理方式需要改善；5） 检查无线环境，是否服务小区和临区RSCP值相当，这样需要优化无线环境解决方法：1） RNC侧处理：判断对于语音业务，如果基站FP数据帧中的QE值上报为218的话，丢弃该数据包，不向CN发送，但外环功控的BLER统计需要正常累加。RNC判断在切换状态下，如果两个小区上报的数据帧一个正确一个错误，选择正确的上报CN；如果两个小区上报的数据帧都错误，判断QE值，选择BER低上报CN。2） 基站侧处理方式ü 对于上行丢帧的处理方式（此情况对应于终端应正常发送上行数据，但基站未能检测到的情况）：a.PL层未通过激活检测门限判断，即SJ上报CC的数据指示未通过激活检测；b.PL层通过激活检测，但CC对TFCI译码后，判断TFCI值超出建链参数的最大围；对于以上两种情况，CC上报FP丢帧（CRCI填写为0xff），FP上报RNC的数据帧中的CRCI指示为1，但QE值固定填写为218（对应0-255的协议值围）。ü 对于上行译码错误情况的处理方式：PL层通过激活检测，且CC对TFCI译码在合理的围，但对传输信道的TB块译码后CRC校验错；对于这种情况，CC上报FP的CRCI为0x80，误比特率BER值按照实际计算值上报，FP将BER值填写在QE位置供RNC使用。6.2 省移动大楼语音质量问题问题描述:移动总反映在新华苑（移动办公大楼）14楼语音模糊不清晰。移动投诉语音质量模糊不清楚的问题，复现情况描述如下：1） T网->G网，通话10分钟左右，突然上行出现单通，下行正常；2） T网->G网，通话两到三分钟，出现双方都听不到对方讲话。问题分析:测试人员在新华苑14楼进行了问题复现，我们发现语音质量模糊不清晰时占用的是茅台金波TD-1小区信号，通过RNC侧QoS信令跟踪发现上行误块率高，基站侧发现时隙干扰ISCP异常，上站提取告警发现同时有DSP任务运行故障告警，因此怀疑基站BBU板卡处理问题。解决方法:将茅台金波站的BBU板更换到红边门站测试时多次复现了语音质量问题，在茅台金波站更换其他BBU板，大量测试下来语音质量良好，但偶尔仍有毛刺，经分析发现，新华苑为单HSDPA 配置