TD-SCDMA 语音业务接入问题定位指导书.doc

td-scdma 语音业务接入问题定位指导书(v400r005)文档版本01发布日期2010-06-04华为技术有限公司 td-scdma 语音业务接入问题定位指导书(v400r005)前言前言修订记录第一次正式发布。读者对象本书适合下列人员阅读：l 现场工程师l 系统工程师标志约定本书采用各种醒目标志来表示在操作过程中应该特别注意的地方，这些标志的意义如下：小心、警告、危险：提醒操作中应注意的事项。注意，重要提示信息。提醒操作中应采用esd防静电保护措施。&说明、提示、窍门、思考：对操作内容的描述进行必要的补充和说明。文档版本 01 (2010-06-04)华为专有和保密信息版权所有 华为技术有限公司5-5 td-scdma 语音业务接入问题定位指导书(v400r005)目 录目 录1 概述1-12 接入类故障2-12.1 接入类故障定义2-12.1.1 背景信息2-12.2 ue找不到网络2-1操作步骤2-32.3 ue上不了网或频繁掉网2-32.3.1 背景信息2-42.3.2 操作步骤2-52.4 ue找到网络后打不通电话2-62.4.1 背景信息2-62.4.2 操作步骤2-72.5 接入类故障案例2-82.5.1 案例：某用户手机经常掉网2-82.5.2 案例：地铁站的用户无法接入2-82.5.3 案例：ue rrc接入失败2-82.6 ue选择网络流程2-93 切换类故障3-13.1 切换类故障定义3-13.2 硬切换失败3-13.2.1 前提条件3-13.3 系统间切换失败3-43.3.1 背景信息3-43.3.2 操作步骤3-53.4 切换类故障处理案例3-63.4.1 案例：部分区域用户3g 到2g 切换成功率低3-63.4.2 案例：某小区掉话率偏高3-83.4.3 案例：物理信道重配置多次失败3-83.4.4 案例：切换时出现rl fail导致rnc收不到物理信道重配完成3-93.5 ue切换流程3-104 语音质量类故障4-14.1 语音质量类故障定义4-14.1.1 单通4-14.1.2 双不通4-14.1.3 断续4-14.1.4 杂音4-14.1.5 串话4-14.1.6 回声4-24.2 杂音4-24.3 单通4-44.4 语音质量类故障案例4-74.4.1 案例：某商用局用户有偶发的杂音4-74.4.2 案例：某商用局用户偶尔几秒钟没声音4-74.4.3 案例：某商用局用户语音中有咔嗒声4-84.4.4 案例：某商用局用户语音单通4-164.4.5 案例：某局点跨msc切换mos分下降4-205 vp质量类故障5-15.1 vp质量类故障定义5-15.2 vp图像质量类故障定义5-15.2.1 背景信息5-15.2.2 操作步骤5-35.3 vp质量类故障定义5-45.3.1 案例：某用户使用vp 业务语音质量差5-45.3.2 案例：某用户使用vp 业务图像出现马赛克5-45.3.3 案例：某rnc覆盖区出现vp电话黑屏5-5 td-scdma 语音业务接入问题定位指导书(v400r005)5 vp质量类故障1 概述本手册主要给工程师和客户处理语音基本功能问题的思路，如果涉及网络性能方面的问题，请参看网络优化参数设置指导手册。2 接入类故障。本章详细介绍了接入类故障的定义及解决方法。3 切换类故障。本章详细介绍了切换类故障的定义及解决方法。4 语音质量类故障。本章详细介绍了语音业务质量类故障的定义及解决方法。5 vp质量类故障。本章详细介绍了vp质量类故障的定义及解决方法。2 接入类故障介绍接入类的各种故障，并给出不同的故障情况下的故障处理方法，对常见的接入类故障案例进行分析。2.1 接入类故障定义ue 开机时可能会出现无法入网或者开机正常后有掉网现象，这种故障就有可能是接入类问题。2.1.1 背景信息l 接入类故障的具体现象如以下章节： 2.2 ue 找不到网络 2.3 ue 上不了网或频繁掉网 2.4 ue 找到网络后打不通电话 2.2 ue找不到网络ue 找不到网络表现为：ue 显示为没有信号，搜索不到网络。ue 搜索不到网络的故障定位思路如图2-1所示图2-1 ue 搜索不到网络的故障定位思路图表2-1 ue 搜索不到网络的故障定位思路说明序号概要步骤详细步骤*1-1重现问题。1 *1-2判断问题是否属于无线信号覆盖差问题。2*1-3在rnc上检查该区域是否出现小区故障。 3*1-4判断是否ue问题。4*1-5判断业务是否恢复。步骤5 *1-6收集故障定位信息，联系技术支持中心。收集故障定位信息，并联系技术支持中心。操作步骤1. 问题重现结合用户遇到的问题反馈的信息，到特定地点，进行问题重现。2. 检查无线信号质量确认覆盖问题的直接方式是观察网络优化软件采集的数据，若最好小区的rscp 和c/i 都很低，就可以认为是覆盖问题。如果rscp-90dbm，c/i2g 的切换，而且影响系统间切换因素很多，包括3g 系统设备和2g 系统设备。这里只描述3g 接入网部分的故障诊断。系统间切换定位思路如图3-2所示。图3-2 系统间切换定位思路图表3-2 系统间切换定位思路说明序号概要步骤详细步骤*1-1重现问题。3.3.2 步骤 1*1-2判断问题是否属于ran侧。3.3.2 步骤 2*1-3判断是否参数设置问题。 3.3.2 步骤 3*1-4判断是否2g系统资源受限问题。3.3.2 步骤 4*1-5判断是否属于无线信号覆盖差问题。3.3.2 步骤 5*1-6判断是否ue问题。3.3.2 步骤 6*1-7判断业务是否恢复3.3.2 步骤 7*1-8收集故障定位信息，联系技术支持中心。收集故障定位信息，并联系技术支持中心。3.3.2 操作步骤步骤 1 问题重现系统间切换问题的定位，一般依赖于问题的重现。重现问题主要通过到问题出现的切换点，进行路测，记录详细的信令，初步分析到是系统间切换过程问题。步骤 2 判断问题是否属于ran 侧系统间切换牵涉网元较多，判断是否ran 侧的问题，通过单用户的信令跟踪，从信令流程来判断失败是否发生在ran 侧。步骤 3 判断是否参数配置问题系统间切换牵涉到的参数很多，和系统间切换相关的参数主要有：邻区参数、系统间切换开关。3g/2g 属于两张网络，在网络扩容、调整中容易出现一些点邻区漏配的问题。这个问题在商用网络中反复出现。一般判断邻区漏配的方法是到问题出现的地点，进行问题重现，然后使用路测仪器来检查3g 小区信息和同一个地点2g 小区的信息，并在rnc 上检查他们是否有正确配置的邻区，使用mml 命令 lst gsmncell 。rnc 内部有控制系统切换的开关，首先要确保这些开关打开，才可以进行系统间切换。查询命令 lst corrmalgoswitch 。对于系统间切换，测量到异系统邻区时才能启动系统间切换流程。rnc 通过ue 的3a 事件报告启动压缩模式，因此3a 事件上报不能太晚，如果太晚，则小区质量已经严重恶化，无法进行后续的切换流程了。判断的标准主要在于使用路测设备观察ue 的3a 事件报告后小区信号质量变化趋势。系统间切换牵涉到接入网的参数配置，在3g 接入网也要配置2g 的邻区信息，也要确保正确才能正常完成切换，在切换失败时也请接入网侧维护人员检查邻区参数配置。如何检查接入网的参数配置，请找接入网支持人员支持。 通过调整参数设置来解决。步骤 4 判断是否2g 资源受限问题在进行系统间切换的时候，需要2g 预先准备好无线链路资源，如果此时2g 系统负荷比较重，资源不足，则新的无线链路建立不起来，无法完成系统间切换。判断是否2g 资源受限，主要通过3g 核心网向2g 核心网发起切换请求，收到的响应是no resource。只能通过增加资源，或者增加可供切换的其他小区的办法来解决问题。步骤 5 判断是否无线覆盖问题无线覆盖和系统间切换相关的主要问题是切换区信号变化较快，一般网络中配置系统间切换参数，都是按照整网来设置，不过部分切换区域，比如地铁、高速公路等区域，因为用户可能移动很快，需要专门调整参数或者通过改善覆盖来解决。判断的标准主要在于使用路测设备观察ue 的2d 事件报告后小区信号质量变化趋势，并且请网规人员来进行评估。步骤 6 判断是否ue 问题引起部分ue 不支持系统间切换。步骤 7 判断系统间切换故障是否解决在网络调整后，重新进行该地点的路测，以确认切换是否能正常完成，必要时需要来回测试多次。-结束3.4 切换类故障处理案例提供两个常见切换类故障案例供参考，增加处理切换类故障的方法。l 2g 小区的lac 和2g msc 映射错误导致用户3g 到2g 的切换失败，出现掉话现象。通过修改2g 小区的lac 和2g msc 映射关系解决问题。 l 小区越区覆盖导致同一个位置上出现严重的同频干扰，出现掉话现象。通过调整小区扰码分配解决问题。 3.4.1 案例：部分区域用户3g 到2g 切换成功率低2g 小区的lac 和2g msc 映射错误导致用户3g 到2g 的切换失败，出现掉话现象。通过修改2g 小区的lac 和2g msc 映射关系解决问题。l 故障现象某商用局部分区域3g 到2g 切换成功率低，出现掉话现象。l 故障定位和排除 在发现问题后，首先通过切换的小区相关信息找到对应的问题地点，到现场测试进行问题重现。发现ps 业务可以进行正常的系统间切换，而语音业务无法完成。 通过观察问题重现时的信令跟踪发现，问题出现在rnc 向核心网发起relocation_required 之后，经常回relocation_preparation_failure，最后无线信号越来越差，但是又不能切换到2g，最终掉话。 2g msc 回的prepare handover confirm 消息如下：图3-3、图3-4信令跟踪图图3-3 信令跟踪图图3-4 信令跟踪图从消息中可以看到2g 的核心网认为没有此小区。此运营商2g 核心网有5 个lac，很容易配错，通过双方的反复确认，最后发现有一个lac 到2g msc 映射错误。 正确修改2g 小区的lac 和2g msc 映射关系后切换正常。3.4.2 案例：某小区掉话率偏高小区越区覆盖导致同一个位置上出现严重的同频干扰，出现掉话现象。通过调整小区扰码分配解决问题。l 故障现象通过话务统计发现某小区掉话率偏高，而且从小区的业务量统计来看，大部分都是切换掉话。l 故障定位和排除 首先通过地图和小区关系判断是哪个小区进行较多切换，然后到该区域进行了多次的实际路测，开始并没有找到掉话点。 经过反复的测试，甚至包括对区域中的一个高级酒店的室内进行了多次测试，终于找到了一个异常掉话点。 通过路测数据分析，判断是两个相同的扰码在同一个空间上有重叠，构成了严重的同频干扰，导致掉话。经过深入分析，发现是因为其中一个扰码的小区造成了干扰，从而导致掉话。 通过调整扰码分配，问题解决。 3.4.3 案例：物理信道重配置多次失败l 故障现象通过话务统计发现rnc下由于物理信道重配置失败导致的切换失败特别多，有3.4%左右的异频切换失败和10%左右的同频切换失败是由于该原因导致。；从ue log，发现在切换过程中，出现了连续多次切换失败，而且原因均为“physicalchannelfailure”。bho.attinintrarncinterfreq ：rnc内小区间异频接力切换入请求次数bho.attinintrarncintrafreq ：rnc内小区间同频接力切换入请求次数bho.failinintrarncinterfreq.2：rnc内小区间异频接力切换入失败次数bho.failinintrarncintrafreq.2：rnc内小区间同频接力切换入失败次数下图是ue侧的log：图3-5 日志界面l 故障定位和排除终端反馈物理信道重配置失败原因“physicalchannelfailure”是因为和目标小区同步不上导致。经查，系统消息中同步定时器t312配置为1秒。即1秒内如果不能同步就会反馈同步失败。修改t312定时器到5秒；通过修改之后的话统可以看出，该原因导致的异频切换失败率1.9%；同频切换失败率4%。与以前相比有较大的降低。3.4.4 案例：切换时出现rl fail导致rnc收不到物理信道重配完成l 故障现象拉网跟踪发现信号较好的情况下掉话中较多出现rl fail，即在切换中出现同步失败，同时切换失败导致掉话，如下图所示：图3-6 消息跟踪界面l 故障定位和排除主要原因可能是以下几点：1、进行同步等待（或者保护时间）时间较短导致同步失败；2、切换后功率不足导致同步失败而掉话；解决方法有两个：1、尽量使用接力切换代替硬切换；2、提高dlinterferersvforho值，从而提高切换时下行初始发射功率，现网中一般使用250。3.5 ue切换流程切换类的信令流程分析，请参见td-scdma 信令分析指导手册。4 语音质量类故障对常见的语音业务质量类故障案例进行分析。4.1 语音质量类故障定义语音业务类故障分为两大类：l 单通：含单通、双不通、串话。l 杂音：含上述杂音、语音质量差、断续和偶尔静音等。4.1.1 单通指通话的双方（a、b），a 可以听到b 的语音，而b 无法听到a 的语音。4.1.2 双不通指通话的双方（a、b），都无法听到对方的语音。4.1.3 断续指通话中语音有短暂停顿，受话方所听语音中会出现“吞字现象”。4.1.4 杂音指通话中出现其他异常的声音，如水泡声、咔咔声、金属声等，严重时甚至只能听到噪声而完全听不到正常语音。4.1.5 串话表现为通话过程中不仅听到对方语音，还能听到第三方的语音；或听不到对方语音，却听到第三方的语音。4.1.6 回声回声现象是指通话时一方从听筒中不仅能听到对方的语音，还能听到自己的语音。回声现象严重时将干扰正常通话。4.2 杂音用户在通话的过程中有杂音、语音质量差、断续和偶尔的静音现象。杂音类故障定位思路如图4-1所示图4-1 杂音类故障定位思路图表4-1 杂音类故障定位思路序号概要步骤详细步骤*1-1重现问题。步骤 1 *1-2判断问题是否属于ran侧。步骤 2*1-3查看ue所在ran侧的无线信号质量，确认是否无线网络质量问题。步骤 3*1-4检查此时网络是否存在丢包，确认是否存在丢包的情况。步骤 4*1-5在rnc侧启动单用户跟踪，确认用户是否处在切换区，出现杂音的时刻和用户切换相关信令之间时否存在关联。步骤 5*1-6ue重新开关机，看杂音现象是否消失，如果消失，可能是ue的问题，更换ue重试。步骤 6*1-7判断是否加密模式问题。步骤 7*1-8判断业务是否恢复。步骤 8*1-9收集故障定位信息，联系技术支持中心。收集故障定位信息，并联系技术支持中心。步骤 1 问题重现结合用户遇到的问题反馈的信息，到特定地点，对不同局向、不同地点多次拨测，直到问题重现。问题重现的同时，需要跟踪用户的完整信令流程。问题重现后保持ue 与网络的连接。重点观察是否发生切换流程（3g-2g 切换、异频硬切换等）。步骤 2 判断问题所在的子网是否属于ran 侧如果问题重现后能一直保持，采用分段环回的方式来初步划分问题。在rnc lmt 上启动单用户环回功能。如果单用户上行环回后，杂音消失，表明故障在cn 侧，请联系核心网。步骤 3 检查无线信号质量l 检查小区信噪比和ue 接收信号功率，确定是否下行覆盖质量差。如果下行rscp - 98dbm，请改善无线环境，提高下行信号质量，如果下行c/i -95dbm，需要检查是否有其他外界干扰。l 检查单用户的上行质量：在rnc 维护台监测传输信道bler，如果业务传输信道bler 大于10%，则可能出现导致语音质量下降。请改善无线环境，提高上行信号质量。l 检查所在的基站传输是否出现闪断、故障告警。如果有，请先消除传输类告警。l 检查所在的基站和rnc 是否有时钟相关告警。如果有，请先消除时钟相关告警。步骤 4 检查网络侧是否存在丢包情况检查所在的基站传输是否出现闪断、故障告警。 如果有，请先消除传输类告警。步骤 5 判断是否切换问题l 在问题重现步骤中，观察问题出现时记录的信令流程上是否有共同点，比如是否出现系统间切换、异频硬切换等。l 如果确认和切换相关，需要检查是否加密模式问题、或者与ue 相关，参见步骤 6和步骤 7；如果排除这两点，请联系技术支持。步骤 6 判断是否ue 问题l 换用多个不同厂家的ue，来对比测试，观察问题的出现是否与特定ue 相关；即使是相同型号ue，内部软件版本可能也不一致。如何查询ue 型号和版本，请参考购买ue 时提供的使用说明书。l 换用其他ue 测试，如果问题消失，就可以认为是ue 问题，反馈给终端厂商。步骤 7 判断是否加密模式问题l 需要使用终端侧的测试工具，分析对比ue 收到的切换过程中的加密算法是否和网络侧配置一致。l 如果是组合业务，需要检查ps 域和cs 域的加密算法是否配置为一致。l 如果不一致，请改为一致，验证问题是否消除。核心网cs 和ps 的加密算法参数，设置请联系核心网人员处理。步骤 8 判断业务是否恢复在前面步骤中，定位到问题所在，并采取调整措施后，然后在问题出现地点，多次拨测，判断杂音问题是否真正消失。-结束4.3 单通在通话过程中，只有一方能听到声音，另一方听不到，或者双方都听不到对方声音。单通或者双不通一般都是设备层面相关，包括网络设备和ue 以及传输设备，可以基本排除无线信号覆盖、解密算法类的问题。单通类故障定位思路如图4-2所示。图4-2 单通类故障定位思路图表4-2 单通类故障定位思路说明序号概要步骤详细步骤*1-1重现问题。步骤 1 *1-2判断问题所在的子网是否在ran侧。步骤 2 *1-3在rnc侧启动单用户跟踪，确认用户是否处在切换区，出现杂音的时刻和用户切换相关信令之间时否存在关联。步骤 3 *1-4ue重新开关机，看杂音现象是否消失，如果消失，可能是ue的问题，更换ue重试。步骤 4 *1-5判断业务是否恢复。步骤 5*1-6收集故障定位信息，联系技术支持中心。请参考1.3技术支持，收集故障定位信息，并联系技术支持中心。步骤 1 问题重现结合用户遇到的问题反馈的信息，到特定地点，对不同局向、不同地点多次拨测，直到问题重现。问题重现的同时，需要跟踪用户的完整信令流程。问题重现后保持ue 与网络的连接。重点观察的流程是否发生切换（3g-2g 切换、异频硬切换等）。步骤 2 判断问题所在的子网是否属于ran 侧如果问题重现后能一直保持，采用分段环回的方式来初步划分问题。 在rnc lmt 上启动单用户环回功能。如果单用户上行环回后，单通不消失，而是能够听到自己的声音，表明故障在ran 侧。请参考步骤3 步骤5判断故障点。如果单用户下行环回后，单通消失，表明故障在cn 侧，请联系核心网维护人员处理。步骤 3 判断是否切换问题l 在问题重现步骤中，观察问题出现时记录的信令流程上是否有共同点，比如是否出现系统间切换、异频硬切换等。l 如果确认和切换相关，需要检查是否与ue 相关。l 如果排除这两点，请联系技术支持。步骤 4 判断是否ue 问题l 观察问题的出现是否与特定ue 相关，即使是相同型号ue，内部软件版本可能也不一致。l 换用其他ue 测试，如果问题消失，就可以认为是ue 问题，反馈给终端厂商。步骤 5 判断业务是否恢复在问题定位并采取相应调整措施，判断业务是否恢复主要采用在出现问题地点多次拨测的方法来判断问题是否真正解决。-结束4.4 语音质量类故障案例提供常见语音质量类故障供参考。4.4.1 案例：某商用局用户有偶发的杂音小区邻区漏配会造成切换不及时，影响下行业务质量。小区覆盖范围过大同样会影响业务的质量。通过增加邻区配置和调整天线的方式来解决问题。l 故障现象某商用局有用户投诉，在某段区域有偶发的语音质量问题。l 故障定位和排除 了解出现问题的区域和大致时间。 到该地点附近反复拨测，终于记录到了几次出现的丢字、杂音现象。 通过记录的用户信令分析，判断是下行业务质量差。 同时结合以前的路测结果知道，该区域无线覆盖信号是很好的。 重新经过多次路测，数据分析发现：是邻区漏配造成的切换不及时，使得下行业务质量较差，影响了语音质量。 进一步分析发现，在同样的路线上，多次测试都出现同样的问题，发现是小区越区覆盖造成的。 通过调整天线的方式，改变了无线信号覆盖区域。 正确增加邻区后，重新到该区域进行多次测试，问题不再出现。4.4.2 案例：某商用局用户偶尔几秒钟没声音在使用端到端业务时，对端的上行突发干扰会导致本端业务出现异常。在遇到类似的问题要注意检查端到端业务所经过路径的突发干扰，通过消除干扰解决问题。l 故障现象某商用局用户投诉偶尔遇到几秒钟时间没有声音的问题。现概率大约几天碰到一次。l 故障定位和排除 在问题出现时，局方同时反馈了该用户的单用户信令跟踪。是从信令分析来看，并没有任何异常之处。 通过初步分析，考虑到对端用户有可能出现问题，所以需要把主叫、被叫信令都跟踪下来。 在出现问题的地方（某栋大楼办公室）进行多次拨测，问题重现了几次。经信令分析发现对端用户的信令出现了上行失步。这样问题就锁定到了对端的所在的地点。 在对端用户所在的地点经过大量拨测，重现问题。通过观察发现，上行信令有突发干扰。 通过对上行突发干扰的信号强度和周边小区的分析，初步判断是外界干扰。转给网络规划人员处理突发干扰问题。 在干扰问题解决后，通过多次拨测，验证问题是否彻底解决。4.4.3 案例：某商用局用户语音中有咔嗒声核心网对于上行的错包处理存在问题l 故障现象现场反馈两移动终端互打时主被叫都能听见“咔咔”的杂音，尤其在移动或者晃动状态下更为明显。l 故障定位和排除现场反馈两移动终端互打时主被叫都能听见“咔咔”的杂音，尤其在移动或者晃动状态下更为明显。更换多部不同品牌终端进行测试，均有同样的问题的，基本排除终端问题引入杂音。在不同站点下拨测，包括室分和室外站，均存在同样问题，排除个别基站硬件问题引入杂音。随时进行拨测，均能发现杂音，时间上无规律性，排除空口干扰引入的杂音。按照基线参数调整了相关功控的参数，问题还是未解决。同时跟踪主被叫用户cdt，进行用户面的数传分析。通过将cdt l2数据转换为语音文件，发现当另一端ue听到咔咔音时，本端ue的上行就已经产生了杂音，说明杂音是在上行引入。语音波形图如下：图中红色标注的毛刺就是杂音波形。为定位上行语音质量差的情况，nb和rnc对应抓了有“咔咔”音的tpcwin log（设testlevel抓fp数据包）和rnc cdt，并在rnc侧打开上行传输信道误块率记录。通过rnc和nb通过建链绝对时间对齐时间（rnc比nb晚14秒左右）。分析连接性能监测_上行传输信道误块率可以看到arm数据有零星的误块率(每500ms能够看到偶尔有错包1、2或3)。分析nb log在观察时间段内amr上下行数据基本没有看到丢数据包、crc错的情况（方框为帧号tti20ms，圈内为crci）；分析rnc cdt上行数据，可以看到这段时间内还存在毛刺。毛刺是1.735s开始，1.807s结束，历时0.072s，在4个tti内。检查对应cdt相同时间段的l2数传。发现在43.120和43.140两个时刻出现了crc校验错包（43.100也出现一个crc错包）。举例说明错包的判断方法：图中红色圆圈处的16进制数值中包含iub口数据crc标志位，此处填“80”值，表示此数据包在nodeb已经crc校验错误，nodeb已经置了标志位。正常是“00”值。而这一段l2统计也确实统计出错包3个。（l2统计错包的数值是累计值，前后2个时间段的统计结果相减便得到这一时刻的错包数量。） 而将此连续的3个错包单独转化为语音波图，发现这3个数据包转化成杂音，而且杂音波形图与之前的波形图对比是一致的，说明杂音的数据源就是这连续的3个错包。到此，所有焦点就集中在空口错包上，如果能消除错包，便可以消除杂音。尝试修改arm的外环功控参数提高终端发射功率（initsirtarget=maxsirtarget= minsirtarget242），将目标值调整到最大，功控调整到极限。即便如此，在ue处于移动或晃动状态还是会产生错包，形成杂音。这就是说，无论功控做的如何好，空口总是会产生一些误帧，这是无线通信的一个固有特点。因为无线信号的变化，空口总是存在一定的误帧率，无线设备可以通过功率控制算法使误帧率收敛到一个目标值，达到一定程度上控制误帧产生的目的。而观测朝阳ue处于静止和移动2种状态下的上行误帧率，静止时在0.2%左右，移动时在0.7%左右。可以说，这个误帧率完全在正常的水平内，功控本身是没有问题的。nodeb上观察到的误码和功控也都正常。另外，从统计看当arm连续出现3帧crci错误时出现“咔咔”杂音的概率比较大。为进一步明确空口跟语音质量关系，进行了如下两个测试，将朝阳的外环ulbler从1提高到10，此时不论静止还是移动，“咔咔”杂音明显提高；同样将其他城市的ulbler提到10，不论静止还是移动基本听不到“咔咔”杂音，并不是全网都存在问题。从以上表现看“咔咔”杂音跟crc错包处理有直接关系，空口是避免不了crc错的，需要关注rnc和cn如何处理crc错包。rnc和cn肯定都为对错包进行处理，才导致杂音数据包被接收端收到。我们通过对比主叫上行和被叫下行的语音波形图可以明显看出，两侧的语音波形图完全一致（其中“咔咔”杂音部分为图中大脉冲部分），rnc和cn确实未对错包进行处理。协议表明，当rnc从iub收到crc错包后，需要根据cn下发的rab指派中携带的信息来对错包进行处理，或丢弃或透传。而当核心网下发的rab指派消息中the delivery of erroneous sdu ie置为yes时、并且至少有1个无线帧子流出现错误帧，则rnc在iuup层的fqc置为 frame bad due to radio发给核心网。协议中对帧质量标志位的规定如下：frame quality classification (fqc)帧质量分类器description: frame quality classification is used to classify the iu up frames depending on whether errors have occurred in the frame or not. frame quality classification is dependent on the rab attribute delivery of erroneous sdu ie.value range: 0=frame good, 1=frame bad, 2=frame bad due to radio, 3=spare.field length: 2 bits.而现场cn设置是yes，也就是说，rnc会将空口crc错包，标记帧质量标志位2后发送给cn，由cn进行处理。下图为iub口上来数据包，可以看到nodebcrc校验错误。再看此数据包经过iuup模块封装后的码流。02 80 0e 1c即为iuup的帧头，其中ulbit2fqc是80的前来两个bit。80换算成二进制是1000 0000，前2个bit是10，即十进制的2。协议中，2表示帧在无线传输中损坏。这表明，rnc是按照协议对crc错包进行了正确地处理！cn应该根据协议规定对fqc2的iuup帧，进一步处理。根据协议描述，cn应该丢弃该iuup帧，并进行平滑处理，例如增补静默帧。这样可以保证杂音不会被透传，而几十毫秒的静默音并不会对听觉感受产生影响。但是通过主被叫上下行语音波形图对比，我司umg并没有平滑处理这些误帧，而是继续透传了。与umg开发了解到，umg新版本上有软参可以控制umg对frc=2的误帧的处理方式。fqc非good非bad帧(fqc为2)是否丢弃开关默认0：不丢弃设置1：丢弃检查朝阳现场umg参数配置，此软参设置为0。也就是说umg只丢弃fqc=1的误帧，会透传fqc=2的误帧。cn同事将此软参设置为1后，杂音问题消失！4.4.4 案例：某商用局用户语音单通语音单通主要是ue侧和核心网侧编解码模块的问题l 故障现象某局点td电话出现单通现象，拨打一个下午有两次单通现象l 故障定位和排除rnc侧cdt可以统计l2的数据。主叫在15：53：27时业务建立后，上下行