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