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

语音业务杂音问题优化指导书
(仅供内部使用)
版权所有
大唐移动通信设备有限公司
本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。

未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。

文档更新记录
目录
1概述4
2语音杂音问题评估4
2.1语音Q O S指标要求4
2.2可能的杂音情况7
3语音杂音问题CheckList8
4数据采集和分析9
4.1综述9
4.2N ODE B侧10
4.2.1ATP抓日志的方法10
4.2.2传输问题导致该现象的排查方法12
4.2.3NODEB侧告警抓取和分析方法13
4.3RNC侧14
4.3.1IMA物理传输的LOG抓取和分析方法14
4.3.2RNC侧QOS跟踪LOG的抓取和分析方法16
4.3.3RNC侧IUUP统计抓取和分析方法17
4.3.4语音环回使用方法介绍18
4.3.5VP环回使用方法介绍（FP层）19
4.3.6VP环回使用方法介绍（IUUP层）19
4.4UE侧20
4.4.1SPAN Outum软件抓取终端信令信息20
4.4.2miniPTAS软件联芯log23
4.5CN侧26
5案例错误!未定义书签。

5.1语音业务在切换过程中存在短暂的金属杂音26
5.2贵州省移动大楼语音质量问题27
5.3上行语音质量差28
5.4N O DATA数据情况下出现噪音28
6归纳总结29
7附录29
7.1端到端Q O S技术原理29
7.2RNC相关参数汇总37
7.2.1Iu参数配置37
7.2.2RRM算法全局参数42
7.2.3功率控制参数42
7.2.4上行外环功率控制参数48
7.2.5业务质量测量参数49
7.2.6业务同步参数52
7.2.7业务QoS参数调度55
7.3N ODE B相关参数汇总55
7.4其他业务Q O S保证建议56
1 概述
语音业务是传统业务，衡量该业务的QoS指标有以下几个方面：
1）时延，端到端的传输时延
2）抖动
3）误码率
衡量这些指标可以用MOS来评判。

本文针对语音业务在网络优化中经常出现的杂音、甚至因为语音不清晰最终导致掉话、声音小等问题，描述了排查方法、数据采集和分析方法，并给出一些案例说明和原理、背景知识介绍。

本文定位于开局网优，比拼测试不在本文档的范围。

本文档中所描述的内容主要基于目前产品版本：
RNC设备，TDR2000
RNC设备，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与时延和信道质量相关，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期应标外厂测试得出的一些量化值。

误码率和传输抖动，在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传输时延要小。

副本时延抖动对比
数据.xls
副本MOS数据（ATMI
P）.xls
2.2 可能的杂音情况
目前已经发现的杂音情况如下：
✓语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，通话能维持至结束；
✓语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，越来越差，但通话能维持至结束；
✓语音接入正常，音质正常(没有杂音或者间断)但不是很清晰，越来越差，不能维持(掉话)；
✓语音接入正常，一直伴随有轻微杂音，通话能维持至结束；
✓语音接入正常，一直伴随有轻微杂音，越来越差，但通话能维持至结束；
✓语音接入正常，一直伴随有轻微杂音，越来越差，不能维持(掉话)；
✓语音接入正常，有突发杂音(若干次)，通话能维持至结束；
✓语音接入正常，有突发杂音(若干次)，不能维持(掉话)；
✓语音接入正常，声音小，通话能维持至结束；
✓语音接入正常，声音小，越来越小，但通话能维持至结束；
✓语音接入正常，声音小，越来越小，不能维持(掉话)；
✓语音接入正常，背景音大(超出正常范围)，通话能维持至结束；
✓语音接入正常，背景音大(超出正常范围)，不能维持(掉话)；
✓语音接入正常，音质清晰但有间断；
✓语音接入正常，音质不清晰伴随有间断；
✓语音接入正常，音质不清晰伴随有杂音和间断；
✓语音接入正常，切换时伴随金属杂音
✓语音接入至响铃，振铃间隙有杂音
3 语音杂音问题CheckList
针对UE、RAN（RNC/NB分开）、CN、IU口、其他，制定CheckList，方便现场快速缩小问题范围和定位故障。

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支持人员直接定位即可。

语音排查流程图如下：
4.2 NodeB侧
基站侧需要做好的工作：
➢查询基站软件版本、固件版本、一单开站中的时钟信息。

➢查询小区的ID、频点、码字。

➢理清“频点－BBU－RRU”的对应关系。

➢查看小区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, 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 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_shell
3）分析方法：一般查看语音从正常到有杂音前后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, 0
4.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, 0
4.4 UE侧
目前UE侧数据采集一般可以使用两种软件：
1.SPAN Outum 5.0
2.miniPTAS
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 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进行测试，确认问题返修有问题的BBU
5）如果问题还不能解决需要按照4.1节流程进行排查
5.3 语音保持双方静默时，主被叫均可以听到明显有节奏的噪音。

若双方进行通话后，噪
音会逐渐减轻
1）首先需要确认CN是那个厂商的设备，是否支持RFCI为NO_DA TA（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切换误码范围为10~26块，
修改小区切换方式为硬切换，QoS跟踪发现切换时误码明显减少，范围为0~9，切换过
程中杂音现象改善较大；经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侧Q o S信令跟踪发现上行误块率高，基站侧发现时隙干扰ISCP异常，上站提取告警发现同时有DSP任务运行故障告警，因此怀疑基站BBU板卡处理问题。

解决方法:
将茅台金波站的BBU板更换到红边门站测试时多次复现了语音质量问题，在茅台金波站更换其他BBU板，大量测试下来语音质量良好，但偶尔仍有毛刺，经分析发现，新华苑为单HSDPA 配置，旁边的新华社为双HSDPA配置，HSDPA干扰了R4，将新华社改为单HSDPA配置后，再次经过大量测试，没有发现语音质量问题，语音模糊不清晰的原因就是基站BBU板卡和HSDPA干扰了R4业务。

其它:
将茅台金波站出现问题的BBU板已经反馈给北京研发分析定位。