切换失败的原因

  手机在通话中为了保证通话质量，经常会切换到能够提供更好服务的小区上去，如果移动的距离较长，则会发生多次切换的现象。虽然切换失败不等同于掉话，但在GSM网络中切换失败就意味着增加了网络的信令流量，并且也是掉话的隐患。因此处理好切换关系，减少切换失败的任务是优化工作非常重要的一项环节。 在这一章里我们将从路测角度结合实例来分析日常工作中会遇到的切换失败的现象，并分析造成各种现象的原因以及相应的处理办法。     总的来说，在遇到切换失败事件时首先应该从HO_FAILURE消息中查找切换失败的原因解释（Cause value）,有些切换失败是可以直接查到切换失败原因的（可以详查GSM规范）。但对于有些Cause value，如Cause value111（Protocol error，unspecified）、Cause value 3（Abnormal release，timer expired）等就无法定位具体原因。对于这些情况，我们就应该再进一步的对信令、多种测量参数、统计报告以及测试现场的环境等进行综合的分析，从而进一步确定切换失败原因。下面的大部分篇幅的分析解决办法都是基于这些无法定位具体原因的Cause value。      一、连续的切换失败 测试中我们有时会遇到这样的情况：如图7所示，接连不断的出现切换失败，当测试工程师继续驱车向前行驶时，就可能导致拖带掉话。从系统下行发送的Handover_Command消息中我们可以发现，目标小区都是同一个小区（或同一个基站的不同小区）。此种现象一般都和基站或传输设备的时钟故障有关，但也有可能是同频同BISC的小区造成的。     二、单独出现的切换失败 如上所述，面对连续的切换失败时，我们的目标比较明确，而且基本上都是与时钟等硬件有关，比较容易发现问题，也比较好解决。而实际工作中，却存在着偶尔单独出现的切换失败现象。出现这种现象的原因却是多种多样，我们在这一节中将针对不同的现象分析不同的原因，值得注意的是，虽然大多数单独出现的切换失败现象很相似，但通过对信令的分析（时间、帧号、信令内容等），就会找出切换失败的具体原因。 连续多个下行Physical Information，超过系统设置造成失败 2）无下行physical information 3）三层消息中出现HO_Complete后手机再上行发送HO_Failure消息 4）其它可能出现的切换失败现象 除了以上所介绍的几种常见的切换失败的类型外，我们还可能遇到一些其它不常见的切换失败，这些都是GSM规范中定义的切换失败类型，主要是系统设置出现问题，或手机不支持网络设置所致。 A．超过目标小区的最大服务距离，Cause: “handover impossible, timing advance out of range”（见GSM规范04.08） B． Cause: “frequency not implemented”（见GSM规范04.08） C．Cause: “channel mode unacceptable” 如果手机不支持HANDOVER COMMAND中提供的信道模式或者根本没有此类信道模式，手机就会立即发送HANDOVER FAILURE消息，并保持现有信道和信道模式。（详见GSM规范04.08） D．lower layer 信道建立失败造成切换失败 此类现象在实际工作中从未遇到过，但是规范中有此类原因的切换失败。（详见GSM规范04.08） E．目标小区要求加密、VGCS等设置与源小区不同且在HO_Command中没有提及的；（见GSM规范04.08） 分类：技术技巧 　　一、切换的定义及划分。 　　所谓切换，就是指当移动台在通话过程中从一个基站覆盖区移动到另一个基站覆盖区，或者由于外界干扰而造成通话质量下降时，必须改变原有的语音信道而转接到一条新的空闲语音信道上去，以继续保持通话的过程。切换根据手机和基站测出的上下行电平质量和TA值作为最基本的测量数据，根据切换判断算法和资源分配算法来决定是否应该切换和切向哪个小区。切换是移动通信系统中一项非常重要的技术，切换失败会导致通话失败，影响网络的运行质量。因此，切换成功率（包括切入和切出）是网络考核的一项重要指标，如何提高切换成功率、降低切换失败率是网络优化的重点工作之一。 　　游戏-GSM中切换种类切换失败的原因分析留着备用。 　　根据不同的切换判决触发条件，切换可以分为紧急切换、负荷切换等5类。 　　（1）紧急切换。包括TA过大紧急切换、质量差（BQ）紧急切换、快速电平下降紧急切换、干扰切换。 　　●TA过大切换条件：服务小区的TA大于等于紧急切换TA*。 　　●BQ切换条件：服务小区的上行链路质量在滤波器长度时间内平均值大于等于紧急切换上行链路质量*；服务小区的下行链路质量在滤波器长度时间内平均值大于等于紧急切换下行链路质量*。 　　游戏-GSM中切换种类切换失败的原因分析留着备用。 　　●快速电平下降切换在呼叫中电平突然下降时触发，触发条件：服务小区如果Value＞B（Value：一个与滤波器参数A1～A8相关的值，该值表示在一段时间内接收电平的变化趋势；B：滤波器参数）切换最后的MR6已经低于边缘切换门限，则发生切换。 　　●干扰切换：也属于紧急切换，当接收电平大于一定值但传输质量又低于干扰切换质量门限时触发。 　　（2）负荷切换。负荷切换触发要同时满足三个条件：系统信令流量小于允许负荷切换系统流量级别门限；需要切换的小区负荷高于负荷切换启动门限；接收切换的小区的负荷低于负荷切换接收门限。 　　（3）正常切换。包括边缘切换、分层分级切换和PBGT切换。 　　●边缘切换条件：服务小区已低于边缘切换门限；在边缘切换统计时间（如5s）内，服务小区电平持续低于边缘切换门限（如4s）。 　　●分层分级切换：在不同层或同层不同优先级之间才有层间切换，同层同级之间没有层间切换。触发条件是邻小区电平值高于层间切换门限和磁滞之和，对服务小区电平值没有要求；邻区排在服务小区之前，且优先级比服务小区更高，邻区电平值大于等于层间切换门限和层间切换磁滞之和；满足P/N判决，如5s内有4s始终处于最好；边缘切换和层间切换只能选一个，它先判断是否触发边缘切换，再判断是否触发层间切换。 　　●PBGT切换算法是基于路径损耗的切换。PBGT切换算法实时地寻找是否存在一个路径损耗更小并且满足一定系统要求的小区，并判断是否需要进行切换。不同层没有PBGT切换。PBGT切换至少带来了如下好处：解决了越区覆盖问题；减少了双频切换的次数；使话务引导和控制有更灵活的手段；始终能为用户提供当前最好的服务质量。PBGT和其他切换算法的最大区别在于它能以路径损耗而不是接收功率作为切换的触发条件。为了避免乒乓切换，PBGT只在同层同级的小区之间进行切换，邻近小区的路径损耗小于服务小区路径损耗一定的门限值。PBGT切换的触发准则：邻区排在服务小区之前，在一定的统计时间内满足P/N准则。 　　（4）速度敏感性切换（快速移动切换）。在一定时间门限里达到快速移动小区实际个数时，认为是快速移动，就会切换到宏小区上去（第4层），并且对原有小区在惩罚时间里给予电平惩罚。 　　（5）同心圆切换。可以实现外圆的广覆盖和内圆的频率紧密复用，能够提高系统容量和通话质量。可以根据手机下行接收电平、质量和TA值来区分内圆和外圆。 　　同心圆切换的相关参数如下：。 　　●内外圆信号强度差异（dB）：内圆进行功率补偿的值。 　　●接收电平门限（dBm）：与接收电平磁滞、TA门限、TA磁滞共同决定内外圆区域，必须大于边缘切换门限值。 　　●接收电平磁滞（dB）：与接收电平门限、TA门限、TA磁滞共同决定内外圆区域。 　　●TA门限：与接收电平门限、接收电平磁滞、TA磁滞共同决定内外圆区域，必须大于TA紧急切换门限值。 　　●TA磁滞：与接收电平门限、接收电平磁滞、TA门限共同决定内外圆区域。 　　●同心圆切换统计时间（s）：同心圆切换也需要满足P/N判决，建议取5s。 　　●同心圆切换持续时间（s）：P/N判决持续时间，建议取4s。 　　二、切换失败的原因分析。 　　切换失败引起掉话的原因虽然比较复杂，但只要能对整个切换过程有一个完整的、正确的认识，问题就不难解决了。一般，我们可以通过以下三个步骤进行分析：。 　　（1）从MSC、BSC告警中获得网络不正常的信息。在因相邻小区数据配置有误或邻区的BCCH、BCC（基站收发台色码）、LAC（位置区码）等设置不对而造成切换失败掉话时，都会在MSC及BSC中产生相应的告警。因此，可以应该经常查看MSC、BSC中的告警记录，找出问题存在的原因。 　　（2）对OMC的统计信息进行分析来发现不正常的原因。基站切换失败偏高，有时在MSC及BSC中并无告警信息，这时可以通过对OMC中的数据进行分析来发现问题。通过对OMC中的数据进行分析，可以发现某些基站存在的隐性问题（如TRX、RTX等的隐性障碍，天线等硬件问题），从而找出问题之所在，达到网络优化的目的。 　　（3）借助无线场强测试仪的测试来判断切换失败的原因。在一般情况下，应该对目标小区周边进行较大范围的测试，通过实地路测，可获得基站的覆盖情况及切换情况，从而得到某些OMC所不能提供的信息。在实测时，特别要把那些与目标小区有切换拓扑关系而拥塞率又较高的小区作为测试的重点，然后通过对测试结果的分析，判断切换失败的原因，从而找出解决问题的办法。 　　当失败率高涉及到切换问题时，应抓住切换及切换失败的原因作为突破点，进而找出解决问题的办法。一般而言，由于切换是在小区及基站之间发生的，因此本小区的失败有可能是因为与相邻小区之间的切换设置不合理造成的。如果是这种原因，则应及时修改切换参数，同时需要检查小区周围是否有盲区存在；如果是由于网络存在漏覆盖区或盲区而导致的切换失败，则可以通过增加新基站或扩大原有基站的覆盖范围予以解决；对于因频率设置不合理而导致的切换失败，可根据实测情况适当修改小区的频率参数；对于那些由于话务量不均衡，使忙时因目标基站无空闲信道而产生的切换失败，可以根据实际话务量的情况，通过修改或增加基站配置或者扩大原有基站的覆盖范围等办法予以解决。 　　下面从路测角度来分析日常工作中会遇到的切换失败的现象，并分析造成各种现象的原因以及相应的处理办法。 　　总的来说，在遇到切换失败事件时首先应该从HO_FAILURE消息中查找切换失败的原因解释（Causevalue）,有些切换失败是可以直接查到切换失败原因的（可以详查GSM规范）。但对于有些Causevalue，如Causevalue111（Protocolerror，unspecified）、Causevalue3（Abnormalrelease，timerexpired）等就无法定位具体原因。对于这些情况，我们就应该再进一步的对信令流程、多种测量参数、统计报告以及测试现场的环境等进行综合的分析，从而进一步确定切换失败原因。下面的大部分篇幅的分析解决办法都是基于这些无法定位具体原因的Causevalue。 　　①、连续的切换失败。 　　测试中我们有时会遇到这样的情况：接连不断的出现切换失败，当测试工程师继续驱车向前行驶时，就可能导致拖带掉话。从系统下行发送的Handover_Command消息中我们可以发现，目标小区都是同一个小区（或同一个基站的不同小区）。此种现象一般都和基站或传输设备的时钟故障有关，但也有可能是同频同BISC的小区造成的。 　　②、单独出现的切换失败。 　　如上所述，面对连续的切换失败时，我们的目标比较明确，而且基本上都是与时钟等硬件有关，比较容易发现问题，也比较好解决。而实际工作中，却存在着偶尔单独出现的切换失败现象。出现这种现象的原因却是多种多样，我们在这一节中将针对不同的现象分析不同的原因，值得注意的是，虽然大多数单独出现的切换失败现象很相似，但通过对信令的分析（时间、帧号、信令内容等），就会找出切换失败的具体原因。带着这个思路我们来看下面的介绍。 　　1）连续多个下行PhysicalInformation，超过系统设置造成失败。 　　实例：马家堡DCS1。 　　现象：从Handover_Command到系统下行发第一个PhysicalInformation正常，因此软件认为切换成功，发送HO_Complete消息。但1.05秒后又上行发送HandoverFailure消息。 　　分析：首先看HandoverFailure中的CauseValue=111(Protocolerror,unspecified)无法证实具体失败原因。随后再对该地区的频率规划进行了核查，未发现有频率干扰。在OMC端也未发现传输和基站硬件的告警信息。但在2层消息中我们可以看出，从Handover_Access后上行发送的SABM消息一直没有得到UA_RSP消息的响应，造成LAPDm信令重发T200×（N200＋1）超时，致使切换失败。 　　Layer2Layer3信令流程如下。 　　FrameNO.UL/DLLayerMessageTypeInfoinMessageTime。 　　12364048DL2I-CMDHO_Command14'4810.94。 　　22364049DL3HO_Command14'4810.94。 　　31946551UL2RR-RSP14'4810.80。 　　41946555UL3HO_Access14'4810.83。 　　51946580DL3Physical_InfoTA=114'4810.94。 　　61946580UL3HO_Complete14'4810.94。 　　71946582UL2SABM-CMD14'4810.95。 　　81946593DL3Physical_InfoTA=114'4811.00。 　　91946606DL3Physical_InfoTA=114'4811.06。 　　101946619DL3Physical_InfoTA=114'4811.13。 　　111946621UL2SABM-CMD14'4811.13。 　　121946632DL3Physical_InfoTA=114'4811.19。 　　131946645DL3Physical_InfoTA=114'4811.25。 　　141946658DL3Physical_InfoTA=114'4811.31。 　　151946660UL2SABM-CMD14'4811.32。 　　161946671DL3Physical_InfoTA=114'4811.37。 　　171946684DL3Physical_InfoTA=114'4811.43。 　　181946697DL3Physical_InfoTA=114'4811.49。 　　191946699UL2SABM-CMD14'4811.50。 　　201946710DL3Physical_InfoTA=114'4811.55。 　　211946723DL3Physical_InfoTA=114'4811.61。 　　221946729DL3System_Infor_614'4811.64。 　　231946736DL3Physical_InfoTA=114'4811.67。 　　241946738UL2SABM-CMD14'4811.68。 　　251946739UL3MRnull14'4811.68。 　　261946749DL3Physical_InfoTA=114'4811.73。 　　271946762DL3Physical_InfoTA=114'4811.79。 　　281946775DL3Physical_InfoTA=114'4811.85。 　　291946777UL2SABM-CMD14'4811.86。 　　301946788DL3Physical_InfoTA=114'4811.91。 　　311946801DL3Physical_InfoTA=114'4811.97。 　　322364314UL3HO_Failure14'4811.99。 　　332364323UL2SABM-CMD14'4812.04。 　　342364347DL2UA-RSP14'4812.15。 　　352364349UL2I-CMDHO_Failure14'4812.16。 　　我们发现该小区的呼叫成功率和切换成功率均很低，怀疑为硬件有问题。在对硬件模块和天线的驻波比等参数进行检测未发现问题后，经过更换信道盘后该问题解决。说明是CTU中某些功能模块出现故障。 　　该案例说明，在实际工作中的任何时候，我们都不能忽略硬件问题，尤其是在没有发现硬件告警的情况下，更需要通过超过常规手段的新办法来发现硬件问题。这样，除了能解决眼前的问题以外，还能为发现网络深层次问题和发现问题的新思路积累经验。 　　2）无下行physicalinformation。 　　A．同站不同小区之间将SynchronizedIndicator置为True;。 　　实例：北太平庄路口DCS。 　　现象：测试工程师在北三环自西向东行驶，占用小区31047，随着继续行驶，TA已经达到3，这时服务小区的覆盖电平已经降到－8xdBm，Quality也达到4、5级，但邻区覆盖电平并不高。后系统令手机向同站的31048发出切换命令，但切换失败。 　　分析：首先先看Handover_failure中的CauseValue＝111。再分析信令流程：从HO_Access到HO_Complete之间无任何信令，原因是同站不同小区之间我们在邻区设置时，将默认同步值设为True，因此，在切换时系统不会下行发送PhysicalInformation，而手机在发送HO_Acces后也不会等待下行消息，不会触发T3124。如下表：。 　　FrameNO.UL/DLLayerMessageTypeInfoinMessageTime。 　　11707367DL2I-CMDHO_command15'3912.62。 　　21707370UL2RR-RSP15'3912.64。 　　31707372DL3HO_Command15'3912.65。 　　41707387UL3HO_Access15'3912.71。 　　51707391UL3HO_Complete15'3912.73。 　　61707396UL2SABM-CMD15'3912.76。 　　71707435UL2SABM-CMD15'3912.94。 　　81707474UL2SABM-CMD15'3913.12。 　　91707514UL2SABM-CMD15'3913.30。 　　101707544DL2DM-RSPSAPI=315';3913.44。 　　111707552UL2SABM-CMD15'3913.48。 　　121707593UL2SABM-CMD15'3913.67。 　　131707656UL3HO_Failure15'3913.96。 　　141707663UL2SABM-CMD15'3913.99。 　　151707692DL2UA-RSP15'3914.12。 　　161707694UL2I-CMDHOF15'3914.13。 　　171707718DL2RR-RSP15'3914.24。 　　181708634DL2DM-RSPSAPI=315';3918.47。 　　但是为什么最后还是切换失败了呢？仔细研究2层消息，手机连续发送6条SABM消息，等待接收UA-RSP的连接确认消息，造成Um接口的LAPDm协议上的T200×（N200＋1）超时是切换失败的原因。经过核查邻区关系，我们发现小区31047缺少东边一些相邻的邻区，造成只能回切至自己本站的2小区的现象，但由于距离太远，已经无法收到下行或上行的消息，造成了切换失败。 　　故障解决：加上适当邻区后该问题解决。 　　我们在下面的注解中将刚才提到的有关同步/非同步切换所涉及到的计时器介绍一下：。 　　注：设置小区同步切换对切换流程的影响。 　　#61692;在邻区关系设为Non_Synchronized时，手机在发送HO_Access同时会启动T3124，在这个计时器期间未收到下行的PhysicalInformation，便认为切换失败；收到PhysicalInformation后T3124自动停止，这时会上行发送Layer2SABM消息，启动LAPDm的T200和N200计时器，在T200×（N200＋1）时间内未收到下行的UA-RSP的确认消息就会发送切换失败消息。 　　#61692;在邻区关系设为Synchronized时，手机不会启动T3124计时器步骤，直接进入Layer2计时器阶段。 　　B．小区之间将SynchronizedIndicator置为False;。 　　在收到手机上报的HO_ACCESS消息后，从理论上基站是应该发出下行PhysicalInformation的，但造成手机端未收到或未正确解码的原因有很多。这种情况下应当首先考虑硬件问题，比如信道盘、时钟、传输等。另外考虑是否有频率干扰的问题，由于干扰造成的上下行消息不能正确接受的影响范围很广，产生的原因也多种多样，所以有时不能单单从GI分析软件（GSMInvestigator,Motorola开发的优化工具）等方法中发现带内干扰，例如可能由于邻区不全造成拖带，从而造成与远处基站的干扰等等，这就要视具体情况而定。 　　3）三层消息中出现HO_Complete后手机再上行发送HO_Failure消息。 　　实际上在GSM规范中没有此类的，仅在用TEMS测试中中发现此类现象。如果系统收到的手机上报的切换失败的消息后，会通知源小区进行拆线，空出原信道，这样手机切换失败后就不能回到原信道，从而造成切换掉话。但经过大量TEMS的路测文件的分析，并没有出现上述的切换掉话现象，从这个角度说，我们可以认为这是软件问题，实际上系统并没有收到切换成功的消息。至于软件问题的具体原因，Ericsson公司还没有给出正面的答复。 　　实际我们可以参照第一种情况“连续多个下行PhysicalInformation，超过系统设置造成失败”的解决办法。 　　4）*可能出现的切换失败现象。 　　除了以上所介绍的几种常见的切换失败的类型外，我们还可能遇到一些*不常见的切换失败，这些都是GSM规范中定义的切换失败类型，主要是系统设置出现问题，或手机不支持网络设置所致。 　　A．超过目标小区的最大服务距离，Cause:“handoverimpossible,timingadvanceoutofrange”（见GSM规范04.08）。 　　在小区设置时，可以设置小区的最大服务距离，参数以TA为单位，最小可以设到0。该参数的目的有两个：1、控制小区用户起呼的范围，超过设置范围的用户将不能起呼；2、控制该小区的话务量，使得超过该小区设置范围的用户自动切出，另外“阻止”超过改设置范围的用户切入。 　　这样在HandoverFailure中的Cause:handoverimpossible,timingadvanceoutofrange。在GSM规范中规定在同步切换或预同步切换的时候，下行系统发送的HO_Command消息中包含了目标小区TA设置为多大，由于手机会以源小区的TA为基准向目标小区接入，当发现自己所用的TA值超过目标小区的*时，便会立即上行发送HO_Falure消息，并且Cause:handoverimpossible,timingadvanceoutofrange。 　　B．Cause:“frequencynotimplemented”（见GSM规范04.08）。 　　如果切换失败原因为Causefrequencynotimplemented时，说明有以下两种可能：一种是手机不能调谐到HANDOVERCOMMAND消息中所包含的频率上，例如单频手机不能切到其他频段上，但此类现象只有在交换机上设置参数错误或出现故障时才可能发生，因为系统是会根据手机的类别来有针对性的发出切换命令的；另外一种原因是手机在收到的包含有FrenquencyList的字节中包含有不同频段的频点。以上两种情况手机就会立即直接发送HANDOVERFAILURE消息，并保持使用原先的信道不变，返回系统的失败原因就是Causefrequencynotimplemented。 　　C．Cause:“channelmodeunacceptable”。 　　如果手机不支持HANDOVERCOMMAND中提供的信道模式或者根本没有此类信道模式，手机就会立即发送HANDOVERFAILURE消息，并保持现有信道和信道模式。（详见GSM规范04.08）。 　　D．lowerlayer信道建立失败造成切换失败。 　　此类现象在实际工作中从未遇到过，但是规范中有此类原因的切换失败。（详见GSM规范04.08）。 　　E．目标小区要求加密、VGCS等设置与源小区不同且在HO_Command中没有提及的；（见GSM规范04.08）。 　　5）Cause3与Cause111的对比。 　　在日常工作中，我们使用的测试设备有两大类，一类是Ericsson公司的TEMS系列，这其中包括TEMS98，TEMS-Investigation2.0/3.0，TEMS-Automatic等；一类是NEMO公司的NEMO-TOM/SAM系列。由于双方软件设计的一些不同，一些方面需要引起大家注意。最主要的在于信令流程中的差异。TEMS中三层消息较全，另外还有二层消息，对于分析问题更加便利。相比而言TOM的三层消息就比较少，有些重复发送的例如系统消息和测量报告就不会纪录下来，另外还没有二层消息。另外，我们发现在Ho_Failure中的CauseValue中也有这不同的判断，这一般体现在不明原因的切换失败上，在TEMS中均为Cause111（Protocolerror,unspecified），而在TOM中则多为Cause3（timerexpired）。因此，前文中CauseValue不明原因的切换失败是基于TEMS的Cause111的，但在用TOM测试的分析中，遇到的CauseValue3也同样适用。