掉话处理案例总结.docx
《掉话处理案例总结.docx》由会员分享，可在线阅读，更多相关《掉话处理案例总结.docx（15页珍藏版）》请在冰点文库上搜索。
掉话处理案例总结
路测掉话的原因分析及解决
1.关于掉话的描述
在GSM系统中掉话从统计角度讲分为两大类：
RF_LOSS和HO_LOSS即射频掉话和切换掉话。
考虑到2层信令的接续等问题，我们把掉话作如下描述。
1）射频掉话
●下行原因：
Radio_link_timeout计数器减至0
●上行原因：
BSS在link_fail的设定时间内未能接收到ULSACCH消息，使link_fail计数器减至0。
BSS下行功率停止发射
●在Layer2上：
BSS/MS每T200时间发送N200＋1次SABM/DISC消息，但未从接收端收到回应
2）切换掉话
●MS未能成功切换至目标小区,但未能回到源小区
●MS发送HOFAILURE和UL-SABM消息给源小区，但未得到回应
2.在路测时发现的掉话问题时,我们应从哪些方面进行考虑？
在路测中，如果我们发现了掉话，我们应该如何入手？
建议根据不同的现象作出一些初步的判断，可以尽量减少不必要的周折，提高工作效率。
归纳起来初步判断有以下几点：
●带内、外干扰
●无可切换的小区（拥塞、无邻区）
●覆盖问题（overshooting/poorcoverage）
●有线口的信道释放
●基站硬件故障（时钟、CTU低功、信道盘的收发功率不平）
●天线错误（下倾角、方位角等错误）
●由于切换失败造成的掉话
●参数设置不当
●其它特殊原因（手机问题、交换机参数设置问题）
3.对掉话现象进行分析以及可能的原因
在这一节中我们对每种造成掉话的可能原因进行具体的研究。
在每一种原因中，我们尽可能的举出实际例子来进行说明。
1）频率干扰
干扰会导致误码率升高，通信质量下降，是造成掉话的一个重要的原因。
干扰可以分为带内干扰和带外干扰，也可以叫做系统内部干扰和系统外部干扰。
带外干扰：
随着科技的进步，空中的无线电波越来越多，有些系统如TCS系统与GSM系统工作在同一频段，如果频率设置不当，会造成严重的频率干扰。
在发射设备的非线性单元由于载波与通过天线进入的干扰信号产生互调干扰，会引起通话质量下降，产生掉话。
另外一种情况就是人为的加建GSM频段的直放站，对功率以及天线方向不进行控制，对系统会造成上下行的干扰。
一般有这种直放站时，基站会通过对话音信道空闲时的干扰电平测量值（IOI）上有所体现。
带内干扰：
GSM系统内部干扰主要由以下几个方面原因产生：
●频率规划不合理，引起同频、邻频干扰；
●基站或手机功率设置不合理，引起下、上行链路干扰；
●频率复用不合理；
●由于多径效应、建筑物反射等造成干扰；
●码间干扰；
●TA与实际不符造成时隙干扰。
当MS在服务小区收到很强的同频或邻频干扰信号时，会引起误码率恶化，使手机无法准确解调邻近小区的BSIC或不能正确接收MS的测量报告，从而产生掉话。
下面两个例子分别从由于直放站造成的带外干扰、由于频率规划原因造成的带内干扰两个方面对干扰造成的掉话进行了说明。
实例1：
频率规划问题
现象：
从图1我们看到：
从当前显示的信息看，3361基站信号很强，但是质量很差，致使RLT超时掉话。
手机掉话后马上进行小区重选，基站为914，但是BCCH与3361同频，同时我们发现掉话时3361的TA已经为4，且覆盖方向也不应该是掉话地点。
分析：
在我们日常测试中这种情况多是由于干扰或是硬件问题引起的。
通过OMC我们未观察到该基站存在硬件问题，由此我们认为该基站存在干扰情况。
这样我们就初步判断除了掉话原因。
结合小区分布图来判断，我们认定这个掉话是由于同频干扰引起的。
图1：
掉话时刻情况
又经过分析，发现之所以在该地区占用3361，主要是由于3363基站无法切换到914基站。
3361是3363的邻区但是914不是，由于3361于914同BCCH，手机切到了3361上。
再加上网络规划不好，这就造成了同频干扰，继而掉话。
图2：
事故原因：
同频干扰造成掉话，通过对规划的调整和修改邻区参数，上述问题得到解决。
实例2：
直放站、阻断器造成的掉话
随着用户的增多，很多宾馆酒店写字楼等建筑物内为了解决电梯、地下室等信号覆盖的盲区就会出现私建直放站，从而产生了强烈的上下行干扰，有时波及周围很多小区的性能，对网络指标的影响非常大。
频率阻断器是一种宽带的干扰器，其安装的目的就是要对移动通信系统产生强烈的干扰，以达到阻断器周围一定范围内手机无法接入系统服务的目的。
一般在路测时我们很难直接从下行的测量发现是否有上行干扰，可以结合统计是否有上行的IOI来分析。
如下图，占上问题小区后下行Rx_Level，Rx_Quality都很好，但是过了十几秒后系统停止发送SystemInfo5/5ter/6，进入了IDLE状态，没有Disconnect以及ChannelRelease等拆线消息。
通过分析发现虽然Level和Quality都很好，但是手机却在逐渐的提升功率，造成功控的原因就是上下行的Level和Quality，因此可以因为问题出现在上行。
查找该小区的统计发现，整个小区的各个载频均有较严重的IOI干扰电平，因此，可以认定当时基站是Link_Fail计时器超时自行拆线，而上行干扰是造成这次掉话的罪魁祸首。
图3：
下行电平和通话质量很好，但是手机却在提升功率
虽然都是对网络产生了干扰，但是阻断器和直放站的影响有些不同，阻断器会带来话务量下降，并对周围基站的切换影响更大。
因此阻断器的干扰影响比直放站更加严重。
2）缺少邻区&目标小区话务信道拥塞严重
其实缺少邻区的现象和目标小区TCH拥塞严重在DT测试中的现象是极为相似的。
下面仅以缺邻区为例进行分析。
实例：
Cell56缺Cell3703邻区最终导致掉话。
现象：
Cell56（BCCH46）缺Cell3703邻区（BCCH35），但有Cell3266邻区（BCCH34）。
但3703强度高20dbm，但由于无3703邻区，只能切换至3266，造成干扰。
切换时如图4所示，当前服务小区为CELL56（BSIC2-BCCH46）,经过判断，向排在邻区第三位的CELL3266（BSIC23-BCCH34）切换，如图所示，源小区56当前的下行电平为－76dbm,目标小区3266当前的下行电平为－65dbm。
图4：
系统消息5中没有35号频点
切换后，发现服务小区电平依然很强但Quality突然变差，最后致使掉话。
如图5所示，我们看到有频点号为34，35的邻频存在，C/I=-21dbm。
从源小区56的SYSTEMINFORMATIONTYPE5中看到Neighbor的频点list中没有35号频点，即说明56没有3703的邻区，因此在56为服务小区时，手机没有对35号频点进行扫描。
若对35号频点进行扫描，则会切至该小区，同时也避免了邻频的干扰。
加上邻区后，一切恢复正常。
图5：
切换后发现邻频干扰
一般来说，如果缺少了邻区，将会发生拖带直至掉话的现象。
在整个拖带过程中，很有可能邻区列表中的场强远远大于服务小区电平值，同时其它频点的BSIC也已经解出，但就是没有下行的Handover_Command消息。
出现这种现象说明了以下两点：
①手机所扫描的邻区频点必定是在当前服务小区下行所发的系统消息5/5ter（SystemInformation5/5ter）的BA_LIST中所包含的，即当前服务小区的邻区中有BCCH为该频点的邻区;
②排在邻区列表前几位的频点与已解出的BSIC组合之后得出的小区必定不是当前服务小区的邻区。
在实际工作中，如果遇到上述情况，在分析出不是缺邻区的问题后，就应该检查是否目标小区TCH拥塞。
3）覆盖问题（Poorlevel&Overshooting）
a.覆盖场强低（PoorLevel）
在测试中，我们在遇到覆盖场强很低的情况下，通常会导致RxQuality随着场强的下降而恶化，最终由于Radio_link_timeout或Link_fail超时导致掉话。
这种情况一般发生在郊区缺乏基站覆盖或山区信号阻挡较严重的地区，解决这种无信号覆盖的唯一办法就是加站或是直放站扩大覆盖。
图6：
很差的覆盖造成了掉话
b.过覆盖（Overshooting）
还有一种覆盖问题就是邻区间交叠区过大，甚至出现了过覆盖（Overshooting）的现象。
比较典型的情况是：
一个较高的基站A的天线没有作下倾角或只有很小的下倾角度，与它相邻的一个基站B的天线高度较低，覆盖范围很小，造成B的覆盖范围被A完全包含。
如图7所示。
所以在越过绿色的B小区主控覆盖范围后，手机还会“回切”至A小区，但是由于种种原因，A小区并没有C小区的邻区。
因此，当测试人员继续行驶后，就会因无邻区可切而造成拖带掉话（例如在红色区域）。
解决的办法就是如图中所示，将小区A的覆盖范围控制好（小区A’），就可以解决过覆盖造成掉话的问题。
图7：
Overshooting现象
同前边一节缺邻区掉话中所提到的类似，Overshooting造成的掉话现象有两种：
①在邻区列表中有很强的信号，同时BSIC早已解出，但根本没有下行的HO_Command消息，这说明手机所扫描的邻区频点必定是在当前服务小区下行所发的系统消息5/5ter（SystemInformation5/5ter）的BA_LIST中所包含的，即当前服务小区的邻区中有BCCH为该频点的邻区;
②看不到有比当前服务小区信号更强的信号，说明小区C的频点不在A小区的BA_LIST中，手机没有对该频点进行扫描。
对于后一种情况，测试人员更不容易发现，因此需要测试人员在测试现场结合基站位置图对原因进行判断。
4）有线口的信道释放造成的掉话
●Abis掉话：
这类掉话主要是传输质量引起的，如传输误码、滑码、帧丢失等。
●A接口掉话：
A接口掉话特别容易发生在MSC之间、BSC之间等与A接口有关的切换过程中，MSC、BSC之间的切换除了与无线网络有关外，还与网间信令配合、信号同步等因素有关，局间切换相对较复杂，也较容易引起掉话。
5）硬件故障直接导致的掉话
经验指出在现网中大多数掉话都是由于频率干扰和这样或那样的基站硬件问题所导致的。
在这一节中，我们就介绍以下所遇到过的硬件问题导致的掉话，一般来说，如果硬件有问题的话，从统计结果的掉话次数和掉话率上就能比较明显的发现异常。
但是，对于话务量分布比较特殊的基站，例如：
小区覆盖范围内没有主要道路，用户移动速度较慢等情况，部分天线问题就不容易从统计结果中发现。
这就需要从路测中的每一个起呼，每一个切换过程乃至掉话现象都要从异常现象中发现问题，以专业知识和工作经验为基础，开阔思路，才能找出问题的根本原因。
这点的具体分析可以见后面的《第四章－路测中见到的典型的掉话现象》。
①由于天馈线原因而导致的掉话
在上行方向，天线是BTS从空中接口接收信号的第一级设备，而在下行方向，它又是最后一级设备。
而且天线包含的参数也有很多，象方位角、机械下倾角、电子下倾角、波瓣宽度、空间分集接收天线距离、馈线驻波比等。
因此，可以说天线某个环节如果出现问题，对于基站性能的影响都是巨大的。
i由于信道盘和天线接错而产生的掉话
此种情况常发生于大配置站型，由于会牵扯到跨机柜的扩展连接等问题，有时会出现整个基站2个甚至3个小区互相连错天线的情况，还有两个小区间单个载频对调错连天线的情况。
整个小区对调连错的情况比较容易发现，因为在IDLE状态或根据邻区强度仅仅测试BCCH的强度即可，但是，单个载频对接连错的情况就不容易发现了，因为只有手机占到错误信道盘时才会发现，例如场强的突然衰减等。
此时路测现象就是电平衰耗较大，同时Quality变差导致掉话。
具体现象可见§2.4一节。
ii由于两副天线俯仰角不同而产生的掉话
在基站安装过程中定向小区有可能用两副单极化收发天线，当小区的SDCCH和BCCH采用NO-COMBINEDMODE时，该小区的BCCH和SDCCH就有可能分别从两副不同的天线发出。
当两副天线的俯仰角不同时，就会造成两副天线的覆盖范围不同，当用户在某个区域中，能收到BCCH信号，但产生呼叫时却因无法占用SDCCH而掉话。
iii由于天馈线方位角原因而产生的掉话
在基站安装过程中每个定向小区可能会有两副单极化天线，当两副天线的方位角不同时就会形成如图8中A和C所示小区。
在A小区中的用户可以收到控制信号SDCCH，但用户一旦被指定为由另一副天线发射出的TCH时就会造成掉话。
在C小区中的用户将无法收到BCCH信号。
图8：
同小区天馈线方位角不同
iv由于天馈线自身原因而产生的掉话。
天馈线损伤、进水、打折和接头处接触不良，均会降低发射功率和收信灵敏度，从而产生严重的掉话。
通常我们仅仅从OMC-R的统计中看小区天线的PathBalance是不能完全反映实际天线情况的，这时应该对怀疑有问题的天线进行核查，排除这方面的故障。
v由于两副天线之间的距离原因而产生的掉话。
采用空间分集的小区两副天线之间应保持一定的水平距离以实现分集接收，否则将会降低收信灵敏度产生掉话。
两副天线之间的水平距离（经验值）应为垂直距离的十分之一，至少应大于3m。
②由于信道盘故障引起掉话
信道盘故障包括CTU自身数字模块出现故障和各信道盘未作Calibration。
如果在路测中遇到原因不明的通话质量差造成掉话的现象，应该通过OMC-R提出该小区以及该载频的RF_LOSS统计，加以验证是CTU的硬件问题。
如果在路测中发现起呼占上TCH后信号衰减严重造成掉话，应该从各信道盘功率是否未调平入手考虑。
注：
在远端登录，观察基站Calibration
用Telnet等方式接入基站，可以使用disp_cal_data
命令通过offset值来看各个载频功率是否调平。
③由于时钟失锁引起的掉话
时钟失锁的原因有很多，比如传输2M中的时钟不稳、基站MSI板子出现问题、GCLK出现问题等。
但影响到Um接口路测的现象没有什么不同。
理论上，时钟失锁会影响到起呼和切换的正常进行。
在实际情况中，时钟的漂移对于起呼的影响是微弱的，通常对于切换的影响是巨大的。
往往由于目标小区或服务小区时钟失锁，造成切换失败，严重影响了通话质量和掉话率。
所以，由于时钟问题造成的掉话，也可以归结为切换掉话的范畴，我们在《路测切换失败的分析》部分中有详细介绍。
6）BSS参数设置不当
其实参数设置不当中，有很大一部分是与切换有关的。
如果不处理好切换参数，造成延迟切换或乒乓切换都对通话有很大的影响。
例如PBGTHandover的HO_Margin设置过大，就有可能造成切换较晚，有可能等到邻区强于服务小区很高电平后，才切换，也有可能由于通话质量不佳等原因触发紧急切换，这就造成了掉话隐患。
可以这样说，大多数的BSS参数设置都涉及到起呼和切换，一旦设置不当就会造成掉话隐患，如何在网络中找到最合理的参数配置就是网络优化最核心的工作，不仅是无线参数同时还要考虑有线口的需要，甚至还要考虑长途来话接通率等问题。
在这里我们仅摘出几个影响严重，但又不容易被想到的参数列出来，在一般经常调整的参数为发现异常的时候，就需要我们多深入的检查其他参数的合理性。
①missingreport设为enable
手机在DedicateMode下上报的MeasurementReport中所报告的服务小区的RxLev和RxQual以及Neighbor的接收电平值是系统进行平均、筛选、判决和排队过程的基础。
在这个复杂的判决过程中，会涉及到很多参数，例如Hreqave、Hreqt、n值、p值等，在motorola的小区参数里有一个参数missingreport。
简要来说，将设为enable时，系统由于种种原因没有收到手机上报的MeasurementReport的SACCH帧时，RxLev将用-110dBm代替。
这样一般情况下就会降低平均电平值，从而会影响PBGT的切换速度，有可能造成延迟切换或不切换。
从而造成掉话。
一般应把该参数设为disable，即用上一个采样值顶替该丢失帧的采样值。
②pbgt_ho_type中参数设置过于苛刻
这也是一种延迟切换造成掉话的可能原因。
在motorola系统中可以根据覆盖环境的不同定义几种不同的PBGT算法。
其中有些算法是要设置一些计时器的，如果参数设置不够合理，设置了过长的Timer，如Type5,type6，用户走出了邻区范围还没有切换，就会拖带掉话。
其它参数设置不当也会造成拖带，例如Type3中包括上下行的Rxlev的门限，即当手机和基站对应的接受电平高于设置门限电平时才会考虑切换。
因此，需要根据实际覆盖情况进行优化参数配置，消除不当的配置所带来的负面效果。
③设置偏大的参数hreqt*hreqave
一般来说，解出邻区的BSIC以后，且该邻区为上报的最好的六个邻区内，系统才会对其是否切换进行判决。
hreqt*hreqave又被称为Warmtime，即系统对该小区进行判决的第一个测量报告开始算起至少经过Warmtime的时长后才会进行切换。
④没有用OMC-RProxyCell广播externalneighbor信息
此种情况出现在跨OMC的externalneighbor在进行了BSIC或BCCH的改变之后，但未在其他OMC上进行改动，结果数据库不一致，造成无法切换，继而拖带掉话。
⑤允许的网络色码（NCCPERMITTED）参数设置不当导致掉话
允许的网络色码参数定义了移动台需测量的小区的NCC码的集合，为手机切换提供可行的目标小区。
我们知道BSIC=8*NCC+BCC，实际上NCC、BCC在帧结构中各为3bit的数据，因此NCC的取值范围为0～7。
在小区里可以设置NCCPERMITTED参数来限制小区的切换目标小区和重选小区。
如果该数据定义错误将引起越区切换不成功和小区重选失败，产生掉话。
7）切换掉话理论上任何一种切换失败都有可能造成切换掉话，因此可参照切换失败的分析。
图9为Intra_bsshandover为例：
当切换失败后，手机向源小区发送HandoverFailure消息，若由于各种原因造成源小区未收到该消息，从而造成T3103超时，这时BSS的ho_lostms计数器就会加1，记做一次切换掉话。
图9：
切换掉话示意图
8）手机问题
在日常路测工作中，我们使用的测试设备的手机前端一般都是有别于商业用机的。
这些测试手机功能更强大，软硬件上都有新的设计，使得它们可以满足测试的需求。
但是我们发现测试手机因为装载了测试软件后，要求的处理能力更高，要求在通话的基础上还要进行与测试软件相呼应的动作，如果由于硬件老化等原因，就可能造成死机、解码错误等现象，从而影响测试结果，如果测试人员不能发现手机问题，还会造成对异常现象的错误判断。
下面这个实例就是通过几次异常的掉话情况查找出来的手机故障引起掉话的问题。
实例TEMS888不切换掉话
我们曾在DT测试中发现了几次通话过程中不切换导致掉话的现象。
经过分析，发现了一些问题，分析如下：
①现象：
i长安街：
占用小区京燕饭店3（880），不切换持续3’10”掉话，TA=3。
通话过程中邻区BSIC已经解出，且满足切换条件。
ii三环：
占用小区公主坟DCS2（30958），不切换持续6’37”掉话TA=6。
通话过程中邻区BSIC已经解出，且满足切换条件。
iii平安大街：
占用小区平安里DCS1（30361），不切换持续1’05”掉话TA=2。
通话过程中邻区BSIC已经解出，且满足切换条件。
iv四环：
占用小区清华园DCS2（30578），不切换持续12”，然后连续三次切换失败，切换成功至学院路2（542），值得注意的是该小区并不在手机上报的最好的六个邻区之内。
然后迅速切出至学院路1（541）后一切正常。
v玉泉营路：
占用小区洋桥西南1（743），不切换持续2’56”，掉话时TA=3。
通话过程中邻区BSIC已经解出，且满足切换条件。
掉话现象:
图10:
不切换直至拖带掉话
②对问题的分析
在分析问题之前，我们先来了解一下系统消息5/5ter与手机中bit-map的对应关系。
系统消息5/5ter（SystemInformation5/5ter）消息为在DedicateMode下，系统通过SACCH发送给手机的系统消息，其中包括BA_LIST，即邻区的BCCH频点序列。
手机就按照BA_LIST中的频点在通话过程中进行扫描，将已解出BSIC码的最好的6个邻区上报给BSC。
当满足某个切换条件时，系统会控制手机进行切换。
另一方面，手机将该小区的BA_LIST中的频点按照频点号顺序记录在手机的bitmap中，而上报系统时，则是按照bit_map中的频点位置号上报。
例如BA_LIST:
23,34,27,512,525,所以对应的bit_map中应为0对应23、1对应34?
?
?
4对应525，若此时邻区BSIC均已解出，信号强度由大到小为27，34，525，23，512，则在MR（MeasurmentReport）上报系统邻区情况时手机上报的频点号顺序应为2，1，4，0，3（十进制）。
我们对测试文件进行了仔细的分析。
从三层消息中我们发现，在这几次不切换的通话过程中，上行的MR（MeasurementReport）中邻区报告的频点序号与下行系统发给的系统消息5/5ter中的频点号不符。
这其中有两种情况造成上报的频点号错误，从而造成了系统不能正确识别邻区关系不让手机进行切换：
i切换完成后，手机继续扫描一两个源小区BA_LIST中的频点，而该频点不属于当前服务小区的BA_LIST，因此这一两个频点号在bitmap中的位置肯定就是错的，所以导致其他正确频点在bitmap中的位置发生混乱；（三环、长安街）
ii收到系统消息5（本频段信息）后，频点对应正常，但受到系统消息5ter（另一频段信息）后出现异常，最后导致所有频点号混乱不能切换。
（平安、玉泉营、四环）
值得我们注意的是这五次事件中有一次并未掉话，而只是三次切换失败。
但正是通过对这个通话的分析，才令问题变得更加清晰明朗。
具体情况如下：
当前服务小区为清华园DCS2（30578），切换失败的目标小区为学院路2（542），而手机此时位于学院路1方向的位置，542并不在手机上报的最好的六个邻区之内，但系统却令手机切换至BSIC=3，BCCH=27的542，而541的BSIC=3，BCCH=1。
通过系统消息5/5terBA_LIST的排列，正常情况下，频点1对应bit-map位置12，而频点27对应bit-map位置19。
在MeasurementReport中手机将541的频点1错报为19（bit-map
升级会员 