经典网络AMR异常掉话问题定位案例
掉话问题常见案例1
掉话问题常见案例1.1.1 弱覆盖掉话问题分析1.现象描述在广州明经村附近测试时，发现由广州明经村2扇区（RNC16站点）往广州潭山（RNC18站点）方向移动时有部分区域PCCPCH RSCP相对较差（大部分可保持在-95dbm以上），但语音业务可以保持，没有发生掉话，而在同一路段由广州潭山往广州明经村方向移动时，则出现大面积的弱覆盖现象且由于弱覆盖引起掉话。
2.分析推理过程不同行进方向UE测试时PCCPCH RSCP对比图如下：图-1 不同行进方向时PCCPCH RSCP对比图不同行进方向UE测试时PCCPCH C/I对比图如下：图-2 不同行进方向时PCCPCH C/I对比图观察测试log可以发现，在该路段由南往北行进时，服务小区切换到广州岳溪1扇区后，在靠近广州明经村附近时，没有在广州岳溪邻小区列表中发现广州明经村的信号，经与RNC 机房确认，广州明经村2扇区与广州岳溪1扇区无邻区关系，造成由南往北行进时UE不能进行正常的切换，结果引起弱覆盖并造成掉话。
另外，在该路段部分区域广州西山村2扇区的PCCPCH RSCP强度可以达到-80dbm左右且占主导地位，下图为UE测试时PCCPCH_RSCP覆盖图：图-3 UE测试情况优化措施增加RNC18_广州岳溪_70_1(3336) RNC16_广州明经村_51_2(3535)/RNC16_广州西山村_58_2(3559)互为邻区。
添加邻区后针对不同行进方向复测UE测试时PCCPCH RSCP对比图如下：图-4 添加邻区后复测结果-PCCPCH RSCP不同行进方向UE测试时PCCPCH C/I对比图如下：图-5 添加邻区后复测结果-PCCPCH C/I 与调整前比较，由北往南行进时各项指标及语音业务没有受到影响，而由南往北行进时则得到较大的改善。
另外，该区域为郊区，附近站点较少，广州西山村及广州岳溪距这部分区域都在2公里以上，距离较近且对区域进行覆盖的只有广州明经村2扇区一个小区，广州潭山虽然也较近，但无小区对该路段进行主覆盖，如还需对覆盖进行进一步改善的话比较困难。
重定位-完成重定位后掉话问题案例分析
重定位-完成重定位后掉话问题案例分析版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。
未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。
目录1 问题现象描述 (2)2 分析推理过程 (5)3 问题结论、优化措施、优化前后效果对比 (10)4 总结该类问题一般分析优化思路 (10)1 问题现象描述10月24日下午，测试车辆沿桂平路向北行驶至宜山路后向西左转。
如下：被叫UE2占用RNC405漕桂_1小区。
随着服务小区漕桂_1覆盖质量的下降，被叫UE2发起2A的测量报告，目标小区显示为主频点为10104，CPI＝1的小区，没有得到网络响应。
过了大约30秒以后发送第二条测试报告，目标小区显示为主频点为10112，CPI＝96的小区。
随后收到Radio Bearer Reconfiguration消息，指示UE向主频点为10112，CPI＝96的小区切换，随后UE在主频点为10112，CPI＝96的小区上面发送Radio Bearer Reconfiguration Complete。
8秒以后进入空闲状态。
没有发生小区更新，然后掉话。
测试图以及各条信令具体内容如下：RB Reconfiguration 消息解码该次掉话中，出现的异常情况有两个：1) 第一条目标小区为主频点为10104，CPI ＝1小区的测量报告发送后，网络侧没有下发切换命令2)重定位完成以后UE掉话。
2 分析推理过程首先对第一个异常现象进行分析。
分析CDL数据（10月24日 RNC405，时间15点），对UE_ID=3630过滤，如下：对RNC收到第一条向测量报告使用ASNDecode软件进行解码，解码后观察其消息内容，显示目标小区为10104，CPI＝1的小区，RNC收到该条测量报告以后，内部生成原语MULTICCSS_SOURCE_TARGET_RL_SETUP_REQ，目标小区CELL_ID＝10018，核查基站数据库显示，目标小区为田州_2小区，主频点10104，CPI＝1。
干扰导致的高掉话案例_故障类
干扰导致的高掉话案例
关键字：干扰
设备型号：2206
软件版本：R12
故障描述：
在处理高掉话小区时，发现葛化街中百超市的WEX10A小区出现高掉话，其掉话原因以突然掉话以及其他原因掉话为主。
故障分析与处理：
一、核查小区硬件无告警及故障；
二、小区传输质量核查，其中DIP=221RB2有较高的误滑码:
对该条传输进行整改，清除误滑码，清除后误滑码不再增长：
三、取MRR统计分析，该小区下行4~7级占比偏高：
四、关注是否存在频率干扰：
通过查看ICMBAND的分布，其4,5级干扰主要集中在RXOTRX-375-0上，对应ARFCN为92：
结合MCOM查询频率干扰情况如下：
由以上分析，WX586A的BCCH 92与WEX10A的BCCH 92同频,干扰引起小区质量下降并伴随高掉话，更换WX586A(葛化街中百超市1)的BCCHNO 由92->75。
处理效果：
完成上述整改以后，该小区的MRR质量统计改善，掉话指标也明显提升。
如下图：
MRR下行质差统计(基本为0级)：
调整前后掉话指标对比情况(掉话明显改善)：
处理总结：
通过核查小区硬件故障，传输质量、结合后台干扰统计以及频率核查，对问题逐个解决并跟踪观察指标，最终将掉话原因进行定位。
在对干扰频点进行处理后，解决该小区的高掉话问题。
从优化前后的各项指标可以看到，传输质量，小区下行Rxqual，小区掉话等指标均有显著改善。
处理流程图：。
TOPN AMR掉话问题分析总结
CS掉话问题分析总结来自:弱覆盖：针对这类问题，首先是路测找到弱覆盖区域，在不影响路测指标和覆盖的前提下，调整方向角和下倾，通过RF解决；如果对于无法调整的弱覆盖，比如边界地区，因为你再怎么调还是弱，只不过把弱覆盖的地方外延了；针对这种场景，我们采取控制覆盖的方法：1.调整下倾角，收缩覆盖；2.降低CS异系统切换判决门限和2D2F门限，让CS业务尽量承载在2G小区；如果是弱覆盖的情况，2G信号好的话，应会切到2G上？2G/3G都是属于弱覆盖的，有需求的话，只能加站；过覆盖针对这类问题，首先联系RF组确认过覆盖情况，在不影响路测指标和覆盖的前提下，调整方向角和下倾，通过RF解决过覆盖问题；对于无法调整的过覆盖，比如大桥和高速等有特殊覆盖需求的位置，还可以通过调整切换参数防止掉话：如增大邻区CIO偏置，调整1A、1B事件参数，使RL加入激活集更加容易，而离开更加困难；干扰下行干扰通常是指导频污染，指覆盖地区存在3个以上的小区满足切换条件，由于信号的波动常常出现活动集替换或者最优小区发生变化，通常当活动集综合质量不好（CPICH的EcIo都在-10dB左右波动），容易出现切换失败导致SRB复位，也可能出现TRB 复位。
上行干扰增加了连接模式的手机上行发射功率，从而产生过高的BLER导致SRB、TRB 复位或者由于失步导致掉话。
另外，在切换的时候，新建链路由于上行干扰导致链路不能同步，从而造成该小区的切换成功率低，或者造成切换失败而导致掉话。
邻区切换类掉话解决切换来不及导致的掉话，可以通过调整天线扩大切换区，也可以配置1a事件的切换参数使切换更容易发生，或者配置CIO使目标小区能够提前发生切换。
解决乒乓切换带来的掉话问题，可以调整天线使覆盖区域形成主导小区，也可以配置1b事件的切换参数减少乒乓切换的发生等方法来进行。
对于异频切换和系统间切换，在切换前需要通过启动压缩模式来进行异频或者异系统测量。
压缩模式启动太迟，可能导致手机来不及测量目标小区的信号，从而产生掉话，也可能手机完成了测量，但下发的异频切换或者异系统切换请求手机不能正常接收而导致掉话。
典型案例(掉话)
问题点1：润州区一泉村（边界同频干扰）测试时间：2009-9-2 09：52：51事件描述：用户投诉在润州区一泉村附近经常出现通话过程中掉话现象。
优化前信号图：（测试文件：0902-01.log）问题分析：在一泉村用户家附近测试时，MS占用Z135-鲇鱼套（BSIC=16，BCCH=115）出现连续7级质差最终导致掉话。
经查MCOM发现，Z135A -鲇鱼套（BSIC=16，BCCH=115）与Y3246B （BSIC=53，BCCH=115）同频对打，在该区域形成同频干扰致使MS占用Z135A -鲇鱼套（BSIC=16，BCCH=115）连续7级质差掉话。
优化建议：修改Z135A鲇鱼套BCCH=115->117。
修改后复测，在用户家中MS占用Z135A鲇鱼套BSIC=16 BCCH=117通话质量很好，无质差出现。
优化后效果图：（测试文件：0902-03.log）问题点2：丁卯桥路沃尔玛附近（邻区缺失）测试时间：2010-01-12 10：19：48事件描述：在丁卯桥路由东向西行驶，MS占用Z146A-丁卯大楼（BSIC=10 BCCH=117 TCH=97）在沃尔玛附近开始出现连续质差内切。
优化前信号图：（1208-03.log）问题分析：该段路应该由Z146C-丁卯大楼（BSIC=23 BCCH=109）和Z149B-丁卯村委（BSIC=16 BCCH=112）联合主覆盖，但由于MS偶然切换到Z146A-丁卯大楼（BSIC=10 BCCH=117 TCH=97），而Z146A和Z149B没有切换关系，导致MS长时间占用Z146A-丁卯大楼（BSIC=10 BCCH=117）越区而出现连续质差内切直至拖死。
优化建议：添加Z146A（丁卯大楼）和Z149B（丁卯村委）的双向邻区关系；修改Z146A（丁卯大楼）TCH=97->100。
调整后复测，MS在占用Z146A（丁卯大楼）信号时，经过几次间接切换顺利切换到Z149B（丁卯村委），且在该路段信号电平覆盖正常，通话质量良好，情况明显得到改善。
网络AMR异常掉话问题定位案例
网络A M R异常掉话问题定位案例Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-199982)参数设置检查：包括了与NT公司参数的对比，以及和其它商用网络的对比，列出与掉话相关的几个不同参数。
分析后发现主要可以修改的是软切换参数（1A的延迟触发时间改为100ms，滤波系数改为2），这能够解决一些切换不及时造成的掉话，而事实上该网络的无线传播环境并不复杂，切换不及时发生的概率较低，而NT公司以前是根据秒周期报告来做软切换的，比我司目前320ms的配置更慢。
因此，修改该参数能带来的增益并不大。
3)Node B问题：该网络普遍采用我司RRU，以前没有普遍商用过，一度怀疑RRU可能有问题。
为此还对比其它商用局RRU的话统，并对CHR进行分析；对Node B的日志分析也没有什么结果。
4)设备告警：检查IUB传输告警、小区VSWR、RTWP告警以及拥塞等告警，发现这些告警与当天的TOP 5小区相关性不大。
5)通过以上分析，定位问题的手段主要都落在CDT和IOS跟踪上。
对前一天CHR统计的AMR掉话Top5用户进行CDT跟踪，结果好几个用户没有开机（或者在NT网络），跟到的两个也没有什么异常发生。
分析的重点只能放在IOS跟踪数据上面。
3．锁定异常掉话发生过程——RB Setup后的RL Failure根据对掉话TOP5小区的IOS跟踪数据进行分析，重点只分析RL Failure造成的AMR掉话。
在这些RL Failure原因的掉话中，刨除掉一些确实是信号问题（Ec/Io或RSCP较差）造成的掉话，有相当大一部分RL Failure的掉话确实是在信号非常好的地方发生（前几秒的Ec/Io和RSCP一般达到-8dB/-80dBm以上），而且掉话的过程非常一致——都是在RB Setup完成后10秒左右收到RLFailure(这时候一般还没有发生软切换，激活集只有一个小区)，5秒钟后没有RL Restore掉话。
网规网优案例(掉话问题总结)
确认覆盖的问题简单直接的方式：
直接观察Scanner采集的数据，若最好小区的RSCP和EcNo都很低，就可以认为是覆盖问题。
6、其他异常问题。通过查看设备的日志，告警等进一步来处理掉话。
建议与总结
Summary
备注信息
Remark
审核
Checked by
审核日期
Check Date
发布
Issued by
发布日期
IssueDate
Title
掉话问题总结
提交人
submitter
肖晋兵176808
提交日期
Submit Date
2009.07.20
现象描述
Description
掉话问题总结
原因分析
Cause Analysis
1、邻区漏配
一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。对于同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：
3、切换问题
软切换/同频导致掉话主要分为两类原因：切换来不及或者乒乓切换。
从信令流程上CS业务表现为手机收不到活动集更新命令（同频硬切换时为物理信道重配置）。
从信号上看，切换来不及时主要有以下两种现象：
1）源小区EcIo陡将，目标小区EcNo陡升（即突然出现就是很高的值）；
2）源小区EcIo快速下降后一段时间后上升，目标小区出现短时间的陡升。
5、流程交互类问题
山西电信cdma网络掉话问题专题--山西案例
中国电信CDMA网络掉话问题专题张玉亮（中国电信山西分公司无线网优中心）【摘要】:随着移动通信业务的迅速发展，用户对网络质量的要求也越来越高，运营商对网络的管理也从对信号覆盖的定性要求转变为对网络性能指标的定量要求。
而网络掉话既是反映网络性能的一项重要指标，也是影响用户对网络使用感受的重要因素。
本文根据作者在网络优化过程中处理掉话的经验，结合路测和话统数据分析造成掉话的各种原因。
分析其掉话原因，主要发生在以下四种情况下：（1）切换掉话，主要是由于邻居关系的缺失或搜索窗大小设置不当；（2）干扰掉话；（3）覆盖弱掉话；（4）导频污染掉话。
【关键词】: PN 搜索窗TEK YBT250 掉话率等。
CDMA2000标准中只定义了手机的掉话机制：（1）手机连续收到12个错帧，停止发射功率。
（2）手机连续收到2个好帧，开启发射功率、衰落定时器清零。
（3）手机收到错帧开启衰落定时器（时长5S），衰落定时器到时后掉话。
主要发生在以下四种情况下：（1）切换掉话，主要是由于邻居关系的缺失或搜索窗大小设置不当；（2）干扰掉话；（3）覆盖弱掉话；（4）导频污染掉话。
1、切换掉话1.1由邻区参数设置不当引起的掉话1.1.1由于地型问题_漏配邻区引起的掉话掉话前主导频为市区农机公司CELL0、CELL2小区，导频分别为39、375。
由于此处的掉话位置地型较低，在掉话前激活集中一直只有PN39、375导频做主导，MS检测到北阎庄PN57大于T_ADD，并且上报了PSMM消息，但由于市区北阎庄CELL0未将市区农机公司CELL0、CELL2小区配置成邻区，导致基站不能下发HDM消息，手机未切换至北阎庄PN57形成强干扰，随着PN39的不断衰落FER达到100%，此时MS与基站基本上已经断链，造成掉话。
详见下面前台测试与后台数据配置图：图1-1 前台测试掉话前导频情况图1-2 前台测试掉话后导频情况图1-3 市区北阎庄后台邻区配置情况图1-4 市区农机公司后台邻区配置情况从上面的四张前后台数据测试和配置图中，我们能够很清楚的看出此处掉话是由于基站双方邻区没有配置所导致。
cdma掉话案例分析
CDMA网络搜索窗设置不当导致掉话的优化案例【案例摘要】针对CDMA网络中搜索窗的设置不当导致的掉话进行了分析，对搜索窗设置不当导致的掉话进行了分析，并结合实际经验提出了解决方法。
1、问题描述【问题描述】2010年7月26日，一VIP客户投诉在A附近打电话有杂音，并且经常打不通电话，打通电话后经常掉话。
接到投诉后，我们马上对该用户和用户所在区域进行了回访和测试，发现A站点与A广场、西沟站点无切换关系，导致用户在拨打电话的过程中掉话，给用户带来了不便。
具体测试路线图如下：RxPower覆盖图(1-4)调整前掉话区示意图(1-5)图 1-6投诉区域FFCHFER覆盖图（图中红圈标注区域FER非常差，为投诉问题区域）图 1-7投诉区域掉话前电平图上图看出，手机RxPower电平-48.91dbm、TxPower电平25.58dbm、TxAdj为6.00，随着车辆的移动PN231的Ec/Io和前向FER迅速降低，高FER掉话就是空中接口误帧率高，触发手机掉话机制造成掉话。
我们知道在测试当中表现出：RxPower 高，Ec/Io差，FER高的原因：1、切换过慢。
2、邻区表设置不当(强导频不在邻区表中)。
3、搜索窗口过小（强导频在邻区表中但搜索不到）。
4、BTS（当前基站或者邻区基站) GPS失锁，造成不同步。
5、干扰。
2方案实施与上面问题对应的解决措施有：1、优化邻区表。
2、将未解调强导频加入到邻区表。
3、加大SRCH_WIN_N(或者调整天线)。
4、修整GPS，保证同步。
5、排除干扰源。
方案分析: 对于这种突发性掉话，首先在后台检查了邻区列表及切换参数，可以排除上述原因中的第二种可能，也就是说基本上不会是漏加邻区出现问题，从路测消息上看，手机也没能搜索到可供切换的强导频信号，在掉话之前没有发出HDM （切换指示消息），所以我们也排除掉第一种可能（切换过慢）。
对于第四种可能我们采取了更换GPS天线，但更换后故障现象依旧。
CDMA掉话案例分析
6. 导频混淆 7. 同PN 8. 导频污染 9. 边界硬切换失败 10. 终端问题 11. 外部干扰 12. 其它
解决办法
调整Neighbour List中邻区列表顺序
（4）邻区位序不合理导致的掉话（续-1）
案例分析
现象
在2005年5月份对重庆市区进行路测时，从玉带山到煤气公司切换时 发生掉话
掉话前Ec/Io迅速变差，掉话后同步到PN312,并且Ec/Io良好
分析
经检查，“煤气公司”已经被加在“玉带山”的二、三扇区的邻小区 列表，不存在邻区缺失问题
（1）覆盖不足导致的掉话（续-1）
案例分析
掉话地点
重庆成渝高速路－中梁山隧道
问题发现
2005年重庆地区的优化过程中，在对成渝高速的路测数据分析时发现 在中梁山隧道（4公里长）的中端的300米左右的区域内CDMA网络 信号相当弱，极易掉话
问题主要是隧道口的基站发射功率无法满足隧道内覆盖
（1）覆盖不足导致的掉话
移动台特点
接收功率小于-100dBm 发射功率大于20dBm 发射功率增益调整大于-10dB 接收Ec/Io小于-14dB 接收FER较高
解决办法
检查该区域是否在预期覆盖范围之内 如不在
忽略 如在
通过调整天线方向角、下倾角、发射功率等增强覆盖 如不能通过调整天线增强覆盖，则需要增加新的基站
（4）邻区位序不合理导致的掉话（续-2）
掉话前后的信号Ec/Io图
掉话前
掉话点
信号恢复正常
掉话后重新起呼
（4）邻区位序不合理导致的掉话（续-3）
掉话前NEIGHBOUR LIST UPDATE消息
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
如果NT公司不存在上述高通芯片的问题，我司的配置也不会有问题。于是决定打开盲检测开关，现场使 用V980手机进行对比测试。
下行盲检测开关关闭时，V980做被叫如果不接听则频频掉话，跟踪的消息和我们先前分析的异 常掉话原因相同；
下行盲检测开关打开时，单独对V980的手机进行被叫测试，连续进行上百次的测试，没有一次 掉话。
Top AMR Drop IMSI 214014001028124 214019800996086 214018400245450 214015502901764 214019802036798 214019800794715 214019800805920 214016002234223
IMEI Prefix 354757 357390 354757 354909 355603 354757 354757 354757
上图查到的V980对应的2个IMEI占42％，后来查到354757也是V980，所以V980手机实际比例为 56%，这与V980在网络中占有的较小比例显然不符，因此怀疑V980手机引起异常掉话。 为了进一步证实我们的怀疑， 把2天CHR统计的掉话TOP 10的IMSI逐个进行跟踪， 并查看Identity Response消息。一共抓到8个用户的消息，其IMEI和对应的手机型号如下表：
而且RL Failure之前也没有看到UE的发射功率攀升，见下图所示，UE Tx power 上报值为51，由 此计算UE发射功率Tx Power=51-71=-20dBm。
分析了IOS中很多的这类异常，发现都是这种情况：RTWP和UE发射功率都很正常的情况下发生 的RL Failure。因此基本可以排除上行问题导致，而信号这么好的情况下下行怎么会有问题呢？这种 错误的假设也导致我们在问题定位的前期一直没有注意查看下行质量。
打开盲检测开关后话统指标验证：
打开盲检测开关后18:00一小时的AMR掉话率降到了0.44％，在这个时段是从未有过的新低；而
接下来的几个忙时，掉话率也都在0.4%左右保持；
修改后18:00~21:00各时段AMR掉话率与前两天同期的对比统计图如下：
RNCId 121 121 121 121 121 121 121 121 121 121 121 121 RNCName RNC:121 RNC:121 RNC:121 RNC:121 RNC:121 RNC:121 RNC:121 RNC:121 RNC:121 RNC:121 RNC:121 RNC:121 Time(As hour) 2006-11-15 18:00 2006-11-15 19:00 2006-11-15 20:00 2006-11-15 21:00 2006-11-16 18:00 2006-11-16 19:00 2006-11-16 20:00 2006-11-16 21:00 2006-11-17 18:00 2006-11-17 19:00 2006-11-17 20:00 2006-11-17 21:00 AMR drop call rate 0.70% 0.86% 1.04% 0.69% 0.68% 0.84% 0.93% 0.75% 0.44% 0.43% 0.38% 0.27% AMR Call Attempts 8337 8561 7895 6533 8082 8383 8180 6617 9211 9212 8829 7313
无
1．定位问题的基本手段
首先根据所有可能原因，从以下几个方面分别进行定位分析： 1) 2) 3) 4) Top N 小区的路测 Top 5 用户的 CDT 跟踪 Top 5 小区的 IOS 跟踪 网络参数对比
5) 6)
Node B 的日志分析 设备告警与掉话小区相关性检查
2．初步的排查
1) 路测： 首先在对掉话率比较高的几个小区进行路测后， 没有发现掉话。 路测无法重现这类掉话， 因此基本排除了依靠路测定位此问题的可能； 2) 参数设置检查：包括了与NT公司参数的对比，以及和其它商用网络的对比，列出与掉话相关的 几个不同参数。分析后发现主要可以修改的是软切换参数（1A的延迟触发时间改为100ms，滤 波系数改为2），这能够解决一些切换不及时造成的掉话，而事实上该网络的无线传播环境并 不复杂，切换不及时发生的概率较低，而NT公司以前是根据0.5秒周期报告来做软切换的，比 我司目前320ms的配置更慢。因此，修改该参数能带来的增益并不大。 3) Node B问题：该网络普遍采用我司RRU，以前没有普遍商用过，一度怀疑RRU可能有问题。为 此还对比其它商用局RRU的话统，并对CHR进行分析；对Node B的日志分析也没有什么结果。 4) 设备告警：检查IUB传输告警、小区VSWR、RTWP告警以及拥塞等告警，发现这些告警与当 天的TOP 5小区相关性不大。 5) 通过以上分析，定位问题的手段主要都落在CDT和IOS跟踪上。对前一天CHR统计的AMR掉话 Top5用户进行CDT跟踪，结果好几个用户没有开机（或者在NT网络），跟到的两个也没有什 么异常发生。分析的重点只能放在IOS跟踪数据上面。
某网络AMR异常掉话问题定位案例 某项目搬迁割接后， 客户反映AMR语音掉话率不论是RNC级话统， 还是Cluster话统都要比搬迁前NT网络 高，RNC语音掉话率在1%左右。尤其在小区半径改大以后，掉话率呈现进一步上升的趋势。
现场分析话统发现超过70%的语音掉话原因是上行RL Failure， 检查上行同失步参数觉得失步比较 容易触发，因此修改了上行同失步参数。然而参数修改并没有取得预想的效果，掉话率没有任何 改善；
从CDT信令分析， 也发现了一次这样的掉话， 也是下行BLER很差但是TCP很小， 而对方 （主 叫）号码是一个特服号码101，怀疑在接听时刻传送的用户面数据异常；
在正常呼叫流程中，在UE接听之前，E公司的核心网下发的IUUP是没有数据的，而此时我 司RNC配置的传输格式是0×0。
由此猜测，在没有数据传输时，V980可能按照1×0的传输格式来解，导致100%的BLER。这个猜测 比较切合实际，因为前几天看到的掉话确实大部分都是被叫，而且也都是在UE接听之前发生的，此 时用户面没有数据。 通过对比我司和NT公司的RB Setup消息，确认我司配置了0×81的传输格式（A子流），而NT公司没有 这种配置。 而如果此问题就是导致下行BLER 100%的原因， 则可以打开下行盲检测开关来规避， 使用SET CORRMALGOSWITCH命令，打开DOWNLINK_BLIND_DETECTION_SWITCH (下行盲检测开关)。因 为下行盲检测开关打开后不下发0×81的TF，而是下发一个1×0的TF，如下图所示：
（1）下行盲检测开关关闭时
（2）下行盲检测开关打开时
检查NT公司的消息，发现其盲检测开着的（NT公司没有面向客户的这个开关）：
然而我们不敢轻易打开盲检测开关，因为有些老版本的高通芯片有个BUG，如果盲检测开关打开，而网 络侧配置了太多的CTFC则可能导致问题，因此目前我司的商用网络全部关闭了这个开关。而对于AMR 语音核心网只指配了3种速率，于是检查NT公司的CTFC和我司的对比，发现都是6个，见下图所示： NT Huawei
UE Type MOTO V980 MOTO V3x MOTO V980 MOTO V980 MOTO V980 MOTO V980 MOTO V980 MOTO V980
这样问题逐渐明显，肯定是与V980手机有关的。
在我司的某个商用局，V980手机的问题是不做内环功控，而是固定以满功率发射，因此导致很 多站的RTWP抬升导致其它用户掉话。从现网问题小区的RTWP跟踪来看，确实也有类似RTWP尖 峰：
4．锁定异常掉话发生手机类型——V980
根据跟踪的IOS信令，网络发了NAS层消息Idendity Request，而UE回的Idendity Response中上带 了手机的IMEI，因此根据IMEI的前6为数字可以确定手机的型号。
如上图的IMEI:3549090098161989，在Google上查询“IMEI:354909”发现这是MOTO V980手机。 这款手机存在较多问题，其中在其它商用网上发现该款手机存在内环功控的问题。将RL Failure掉话 的IMEI全部检查，并一一在网上搜索其对应的手机型号，发现V980手机占的比例相当大，见下图：
MOD Cell Radius MOD In/Out Sync Para
MOD AMR Max RL PWR
1.20% 1.00% 0.80% 0.60% 0.40% 0.20% 0.00% Wed Thu Fri Sat Sun Mon Tue Wed Thu HUAWEI Fri Sat Sun Mon Tue Wed
6．锁定 RL Failure 的原因——下行 BLER 100%
于是打开了IOS中的UE质量上报（下行BLER）和下行码发射功率的测量。 发现RL Failure前的下行BLER达到100%，而此时的导频Ec/Io非常好：
通过上图UE上报的数据可以计算： 服务小区CPICH Ec/Io=(39-1)/2-24=-5dB, RSCP=(29-1)-115=-87dBm; 下行码发射功率TCP=(86-10)/2-10-PO3=28dBm-3dB=25dBm 下行BLER＝100％（上报值63映射为100％）
通过以上计算，下行业务信道码发射功率为25 dBm，并没有达到最大发射功率。虽然下行的外 环功控我们看不到，但是在覆盖这么好的地方，即使SIR Target调到上限（满足SIR的要求。这种情况是合理的。 下行BLER为100%意味着下行连续误码，这时会触发下行失步，下行失步后UE会在40ms时间内 关闭发射机，因此大约8秒后上行RL Failure。 为什么在下行信号如此好的地方，会频频出现DL BLER为100%的情况呢？ 后来得到一些信息：
3．锁定异常掉话发生过程——RB Setup 后的 RL Failure