TD-SCDMA Trouble Shooting经验文档

1、 TD-SCDMA Trouble Shooting经验文档TD-SCDMA经验文档汇总目录第1章KPI问题处理流程- 1 -第2章起呼问题- 3 -2.1提高FACH的发射功率- 3 -2.2安全模式建立失败- 3 -2.2.1问题描述- 3 -2.2.2问题定位- 4 -2.3RABAssignmenFailRAB指派失败- 4 -2.3.1问题描述- 4 -2.3.2问题分析- 4 -2.3.3处理结果- 5 -第3章切换问题- 7 -3.1弱场导致切换失败- 7 -3.1.1问题描述- 7 -3.1.2问题分析- 7 -3.1.3处理结果- 8 -3.2跨RNC切换失败- 8 -3.2

2、.1问题描述- 8 -3.2.2问题分析- 10 -3.2.3处理结果- 10 -3.32&3G切换失败- 11 -3.3.1问题描述- 11 -3.3.2问题分析- 12 -3.4邻区同频同扰码- 12 -3.4.1问题描述- 12 -3.4.2问题分析- 13 -3.4.3处理结果- 14 -3.5跨CN重定位失败- 14 -3.5.1现象描述- 14 -3.5.2现象分析- 14 -3.5.3解决方法及验证- 15 -3.5.4经验总结- 18 -3.6外部小区配置错误- 19 -3.6.1问题描述- 19 -3.6.2问题分析- 19 -3.6.3解决办法- 20 -3.7终端

3、异常导致测量报告错误- 20 -3.7.1问题描述- 20 -3.7.2问题分析- 20 -3.7.3解决办法- 21 -3.8上行同步失败导致切换失败- 21 -3.8.1问题描述- 21 -3.8.2问题分析- 22 -3.8.3处理结果- 22 -3.9重定位失败- 23 -3.9.1问题描述- 23 -3.9.2问题分析- 23 -3.9.3处理结果- 24 -3.10沈阳跨RNC切换处理专题- 25 -3.10.1现场情况- 25 -3.10.2跨RNC切换正常流程- 26 -3.10.3问题分析- 27 -3.10.4后期工作- 34 -第4章掉话问题：- 36 -4.1跨RNC切

4、换失败掉话- 36 -4.1.1问题描述- 36 -4.1.2问题分析及解决- 36 -4.2UE上报CellUpdate导致掉话- 37 -4.2.1问题描述- 37 -4.2.2问题分析- 38 -II第1章 KPI问题处理流程1、首先从minos上导出KPI，对KPI较差的RNC进行筛选。筛选出KPI较差的RNC后再按流程往下操作。2、从OMCR上导出KPI，对各个小区进行筛选，看是否为少数几个小区的KPI恶化导致整个RNC的指标较差。现阶段很多情况是：RNC的KPI差都是因为几个小区或是某个用户、同一款终端导致的。3、定位出KPI小区后，查看KPI问题小区是否存在告警，如果这些问题是由

5、设备告警导致，转交给排障组处理。如果没有就继续往下排查。4、检查这几个KPI问题小区的参数配置，比如切换开关、公共信道的建立情况、UP干扰、时隙底噪等。如果是参数的问题，优先处理参数问题；如果不是就继续往下排查。5、检查邻区配置情况，如外部小区配置是否正确、邻区的LAC区配置、邻区同频同扰码组情况、地理上是否有同频同码组情况等等。如果是邻区问题请优先处理邻区问题，没有问题就继续往下排查。6、在后台取CallTrace信令进行分析，并将问题归类为起呼问题、切换问题、掉话问题。7、进行CT分析后是否能够定位出问题，如果能定位出问题就提出解决方案。如果没有定位出问题就继续往下排查。8、进行路测复现，

6、同时在后台进行信令跟踪、打印、NODEB测量等。如果还分析不出来就将数据提交给后方研发兄弟定位。- 38 -第2章 起呼问题起呼的问题有很多种，主要表现为：UE发送rrcConnectionRequest消息没有收到；UE没有收到rrcConnectionSetup消息；SecurityModeFail安全模式建立失败；RABAssignmenFailRAB指派失败等等。其中UE发送的rrcConnectionRequest消息没有收到主要是因为UP时隙干扰导致，需要进行UP偏移来解决。此案例不再在沈阳外场出现过，这里不再累述。2.1 提高FACH的发射功率根据中兴通讯TD工程项目指挥部技术通

7、告-网规网优类012号（20080513）-关于RNC升级到1.30版本后SCCPCH功率和下行DPCH最大发射功率需要核.doc中提到的SCCPCH功率说明，经无线性能团队外场攻关后讨论决定，为了提高室外呼通率，各外场在RNC升级到1.30版本后，需修改室外小区的SCCPCH功率。针对PCCPCH 小于等于35dBm的小区，将每条SCCPCH功率从现场的配置值，修改为1.30默认参数3dB。注意，如果确实需要增大 PCCPCH功率来满足公共信道覆盖要求，对于这种场景，一般不会有导频污染，因此SCCPCH功率维持在0也够用了。只针对PCCPCH小于等于35的小区修改SCCPCH功率。室内SCC

8、PCH功率仍然是原默认参数0dB，不变。如图：UE没有收到rrcConnectionSetup消息。此次修改SCCPCH的功率就是提高FACH的功率，使得UE能够及时的接收到rrcConnectionSetup消息，提高呼通率。2.2 安全模式建立失败2.2.1 问题描述安全模式建立失败： 2.2.2 问题定位我们的网络是打开了完整性保护开关的，而在其他外场出现过核心网（华为CN）没有打开这个开关，导致安全模式建立失败，导致起呼失败。2.3 RABAssignmenFailRAB指派失败2.3.1 问题描述北京RNC5 PS激活成功率很低，经过对KPI性能表进行筛选发现有2个小区的无线接通率很

9、低，其RAB建立请求发了4208次只成功了120次，严重影响整个RNC的指标。如下图：服务小区分组域RAB建立成功率RAB建立成功率无线接通率分组域RAB指配建立成功的RAB数目分组域RAB指配请求建立的RAB数目41370.00%0.29%0.29%034441722.85%4.66%4.66%1204208对小区进行告警、参数配置、邻区和干扰进行了排查没有发现问题。2.3.2 问题分析对CT文件进行分析发现有一个尾号2555的用户一直在4172上进行PS业务，激活请求被拒绝了179次，查看原因解码发现有2个原因导致了此问题。原因1：用户激活了PS业务保持一段时间后去激活，然后在2秒内又发起

10、激活请求。如下图：由于RNC没有来的及释放资源，RAB指派失败，导致用户的PDP激活请求被拒绝。从解码来看，RAB失败的原因是因为核心网分配的传输层地址和该用户在RNC上没有释放的传输层地址不一致，是无效值。终端发起去激活后，在核心网未下发IU释放之前再次发起激活请求，导致RNC判断RAB ID相同，认为是RAB修改，在进行参数匹配时认为传输层地址不同，返回失败。原因2：用户在第一次激活PS业务的时候就被拒绝，拒绝原因是RRM_Unknown = 159，RRM未知类型，经与研发确认是由于目前北京网络没有打开可视电话1PS业务（I/B/S）开关导致。或是用户激活了一个PS业务然后又激活一个PS

11、业务，第二个PS业务会被拒掉，我们的设备暂时不支持这类业务。如下图：2.3.3 处理结果原因1：由于终端发起的业务请求消息对RNC来说都是透传，目前没有策略可以控制终端不在短时间内再次发起激活请求。原因2：可视电话1PS业务（I/B/S）开关已经申请打开了；PS+PS业务暂时不支持。第3章 切换问题切换问题主要表现为：目标NODEB没有上报RadioLinkRestoreIndcation；跨RNC切换时RadioBearerReconfigurationFailure失败；23G切换失败。主要原因有：弱场、导频污染、同频干扰、业务时隙干扰、系统外干扰、23G参数配置原因等等。这里简单介绍几个

12、案例：3.1 弱场导致切换失败3.1.1 问题描述925小区往926小区切换失败，目标小区NODEB没有上报RadioLinkRestoreIndcation消息，如下图：3.1.2 问题分析目标小区的PCCPCH RSCP值只有19-116=-103dbm，属于弱场切换。查看小区鼎利位置发现两小区相差1.7km，期间有覆盖弱场。如下图：3.1.3 处理结果此问题需要改善覆盖来解决问题。切换失败后回滚成功，并没有产生掉话。如果此时原小区上报RadioLinkFailIndcation消息，则UE将在原小区上产生掉话。3.2 跨RNC切换失败3.2.1 问题描述RNC20的188小区跨RNC切换

13、失败，查看邻区和测量报告定位出是往RNC22的227小区切换失败。RNCCELLIDCELLPARAIDNRNCNCELLIDNCELLPARAID2018887222291232018887525470121201888720459119201888720203431022018887204699101201888720187932018887223189201888722204008820188872045779201888722787420188872279692018887223368201888720204436420188872277632018887204842622018887

14、22227512018887201891220188872095883.2.2 问题分析查看CT信令，发现重定位失败的原因是radioNetwork=TRANAP_unknown_target_rnc，也就是说RNC20的188小区检测到227小区的信号，要往227上切换，但不知道227小区是属于哪个RNC，导致重定位失败。如下图：经与CN侧联系排查，发现RNC22的DNS解析配置错误，导致所有往RNC22切换的PS业务均失败。3.2.3 处理结果修改后DNS解析错误后，测试结果如下：PS业务切入RNC22正常，问题得到解决。3.3 2&3G切换失败3.3.1 问题描述现网中很多2&a

15、mp;3G切换失败的现象，查看原因代码发现主要有3种，interRAT_ChangeFailureCause 中：t=1是网络侧参数配置错误；t=2是与2G小区同步失败；t=3是协议错误；就是说终端和网络侧对协议的理解不一致。3.3.2 问题分析CT文件中主要的23G切换失败原因是终端与2G小区同步失败。此问题需要与2G方面协调优化。3.4 邻区同频同扰码3.4.1 问题描述5952小区往丰台垒球馆8036切换失败300多次，查看邻区配置发现5952的邻区中有2个扰码为6、频点为10120的小区。一个为5223，一个为8036。查看小区地理位置发现5952小区本是要往5223切换的，但由于80

16、36也在邻区关系中，且和5223同频同扰码，UE无法区分这两个小区的信号，导致UE与8036同步不上，切换失败。3.4.2 问题分析从CT信令解出UE的测量报告，可以看到这两个扰码为6的小区信号强度是一样的，UE无法区分这2个信号。如下图：3.4.3 处理结果修改8036的扰码为36。附上邻区同频同扰码检查宏工具：3.5 跨CN重定位失败3.5.1 现象描述在路测中发现PS业务进行FTP下载时，在中兴和大唐的交界区，UE可以从大唐切换到中兴而从中兴不能重定位到大唐小区。路测仪上表现为UE连续上发测量报告。但没有网络侧下发的RB重配消息。3.5.2 现象分析要定位此问题还是需要从信令流程上入手，

17、查找问题。定位此问题主要从以下几步展开：Ø 终端不停上上报Measurement Report,后台 RNC Trace中有没有收到测量报告？Ø 如果收到了测量报告，那RNC有没有向中兴的CN发Relocation required消息，消息中携带的切换目标小区是否与终端上报的小区一致？并且其它消息内定容 是否正确？Ø 中兴CN有没有收到Relocation required消息，如果收到了有没有向大唐方面的CN发Relocation_repare_handover消息？消息中的内容是否正确？Ø 对端大唐方面的CN有没有收到这条来自中兴CN发过来的Rel

18、ocation_repare_handover,如果收到了并且内容正确，大唐CN会向大唐RNC发relocation_request消息。3.5.3 解决方法及验证首先，我们必须找到一个测试点进行相关测试。前后台配合采集数据、查找问题。我们确定的测试点如下图所示：测试方向如上图黑色箭头所示。从中兴小区-驻港1扇（911）切换到大唐小区-青专大酒店1扇（931）。2个小区主要参数如下：小区名CELLID频点扰码驻港1扇9111008867青专大酒店1扇9311009651我们分两步定位问题：第一步：到达现场后我们首先进行了一次测试，复现问题。结果发现UE连续上发测量报告。而且两个小区的无线参数配

19、置正确。邻区关系存在。信号质量良好（约-70dBm）。第二步：当我们查看RNC侧信令时发现出现上发的测量报告中携带的目标小区信息正确：但是当RNC将RelocationRequired消息发给CN后，CN回发一条：RelocationPreparationFailure消息。查看消息树形解码发现：失败原因：TRANAP_unknow_target_rnc具体如下图所示：Unknow rnc的可能原因是重定位请求消息中带的RNC ID在SGSN中未配置。于是查看RELOCATION REQUIRED消息中带的RNC ID。如下图：发现目标RNCID为3。和事实相符。于是，可推断可能我们的配置有问

20、题。检查SGSN网管配置，的确没有关于RNC3的解析配置，在add sgsnhost地址解析配置中添加了如下数据：逻辑名称：RNC0003.MNC007.MCC460.GPRS IP：（对端SGSN的IP）这条对RNC0003解析的数据后，同步数据。配置后再次测试，重定位成功。成功信令如下：附：跨CN切换的详细信令：3.5.4 经验总结当切换失败的时候，我们要根据正常信令流程一步步查找信令在哪一步出问题。而且一些主要信令中包含的信息是否正确。比如，Relocation required消息，消息中携带的切换目标小区是否与终端上报的小区一致？然后关注失败信令的原因。根据失

21、败原因提供的信息定位问题。3.6 外部小区配置错误3.6.1 问题描述在往鼎桥区域切换过程中，手机切换失败在松坪2扇区掉话。3.6.2 问题分析松坪2扇区和鼎桥小区北环1扇区不属于同一个RNC,在松坪2扇区所在的RNC3需要添加外部邻小区信息（包括频点、扰码等）才能正常切换。鼎桥把频点由10104改为10096后，没有及时通知我方进行更新，造成手机只能单项切换正常，在松坪二2扇区上无法切换出而掉话。3.6.3 解决办法外部小区中修改北环1扇区的频点信息即可实现双向正常切换。3.7 终端异常导致测量报告错误3.7.1 问题描述在深南大道与鼎桥区域切换测试中，手机一直在发测量报告，却一直未发出判决

22、命令，导致最后车行驶到一定位置和同RNC的另一个弱场小区发生切换，并且切换超时掉话。下图为该路段测试的C/I覆盖图，当前终端服务小区为沙河东二1扇区。3.7.2 问题分析当前测量报告显示，最强邻区为频点10088、扰码99的小区，但该处正常情况下最强邻区应该是中兴区域内的大冲三2扇区（10088、120）。在连续发了几个测量报告后，由于车已行驶到离大冲三2扇区较远位置，在沙河东二邻区测量中，最强邻区已变为RNC站点，变成RNC内切换，但由于该小区对当前位置覆盖较弱，造成切换超时掉话。3.7.3 解决办法该现象偶然几率较大，大多由于手机异常造成，在手机重启后该问题会得到改善。再度测试时，没有复现

23、该现象。本例中，由于测试路线的选择，可能同时受到拐弯效应导致和源小区链路失步，网络侧无法接收到UE的测量报告，造成切换失败，此时要想办法改变切换带解决。3.8 上行同步失败导致切换失败3.8.1 问题描述从后台发现大冲三1扇（50911）上有跨厂家切换时失败现象。3.8.2 问题分析由信令解码发现失败原因为目标小区的上行同步失败造成，硬切换模式下的上行同步通常有两种：1目标小区上行UPPCH干扰严重，或者同时有其他UE的上行同步碰撞，导致和目标小区的上行同步失败；2目标小区的UPPTS期望接收到的功率设置过小，功率步长、可能会导致同步无法完成、功率爬坡步长等。3.8.3 处理结果通常解决上行失

24、步问题要通过调整网络结构改变上行干扰来解决，在本例中，我们通过分析切换前的测量报告，发现目标小区白石二3扇区和当前服务小区几乎没有覆盖交集，在实际路测中，两站点附近干道测试多次，都没发现两小区有任何切换可能，推测应该是切换区域为信号经过强反射或其他途径传播造成，直接删除二者的邻区关系能更好解决问题。3.9 重定位失败3.9.1 问题描述信令如下，在后台发现跨厂家切换时，产生重定位失败现象。3.9.2 问题分析查看CT信令，发现重定位失败的原因是radioNetwork=TRANAP_unknown_target_rnc，目标小区归属RNC无法获得，导致重定位失败。经与CN侧联系排查，发现该RN

25、C的DNS解析配置错误导致。3.9.3 处理结果修改后DNS解析错误后，问题得到解决，测试结果如下：3.10 沈阳跨RNC切换处理专题3.10.1 现场情况近期沈阳中兴区域全网RNC间切换成功率统计见下表：统计时间RNC间切换成功率2008-09-0876.35%2008-09-0980.13%2008-09-1084.55%2008-09-1184.36%2008-09-1285.65%2008-09-1383.47%2008-09-1480.93%2008-09-1583.88%2008-09-1685.33%2008-09-1783.91%2008-09-1881.89%2008-09-

26、1988.34%2008-09-2084.72%2008-09-2190.47%表 1 沈阳中兴区域RNC间切换后台性能指标统计指标变化图：图 1沈阳中兴区域RNC间切换后台性能指标统计从上图可以看出RNC间切换成功率通过一段时间的优化得到了一定的提升。但是整体指标依然在90%左右，未达到预期的目标。3.10.2 跨RNC切换正常流程跨RNC切换目前通过重定位形式，以硬切换方式实现。如图2所示正常的重定位全过程。图 2 跨RNC切换信令流程正常的RNC后台重定位信令流程见下图3，其中蓝框中的信令是源RNC侧看到的消息，红框中的信令是目标RNC侧看到的消息。图 3 RNC后台信令3.10.3 问

27、题分析近两个月来通过对沈阳跨RNC切换失败问题进行跟踪与分析，现场对问题的原因进行了总结，具体分为终端问题原因、目标小区同步失败原因、邻区参数设置原因等，详述见下文。 终端问题在以往的DT测试中，现场发现有跨RNC切换失败而导致掉话的问题，虽然此问题在DT测试中不是较为频繁也存在着一定的偶然性，但该问题也是影响沈阳TD网络指标的一个因素，为了查明并解决跨RNC切换失败而导致掉话问题，现场对重定位过程进行跟踪与问题定位，并结合后台CT和信令跟踪进行分析。最终发现有部分终端在处理切换后测量控制消息的机制方面存在问题。典型信令如下所示：图 4 RNC后台异常信令序号199该IMSI刚

28、刚进行完成一次重定位，仅仅间隔40ms即序号200开始该IMSI又发起一次切换请求，但是目前网络中无论1G还是2A事件的触发参数Time_to_Trigger均为1280ms，且测量报告中的内容也并非新小区测量控制所规定的，由此看来终端并没有按照新下发的测量控制上报测量报告。而在25.331协议上明确指出：“8.3.5 Hard handoverWhen performing hard handover with change of frequency, the UE：1> stop all intrafrequency and interfrequency measurement re

29、porting CELL_INFO_LIST. Each stopped measurement is restarted received with the corresponding measurement identity.”根据协议和现场采集的信令有理由相信终端处理有误。与协议不符。例如：进行某天的CT分析时，在皇姑热力供暖3小区（RNC1、4边界）就发现了这种问题。图 5 CT纪录异常信令对于这种情况：华为核心网的处理策略：无线侧给核心网侧上报RelocationComplete消息后，核心网需要调整并进行释放资源，存在一段系统保护时间，在此时间内对于同一终端用户上报的切换请求，核心

30、网不予处理。同时由于目前网络处理能力，在核心网收到RANAP：Iu- ReleaseComplete消息之后的0.17秒内，对于同一终端用户上报的重定位请求，核心网同样不予处理。中兴RNC的处理策略：RNC侧在上报RelocationComplete消息后，认为前一次流程结束，可再次进行重定位。由于终端仅间隔40毫秒上发测量报告，由于华为CN处理能力问题此时尚未将IU资源释放完毕，导致CN对重定位请求无响应，RNC等待定时器超时后发起IU释放流程，导致掉话。解决方法：A、解决终端问题。需要协调各个终端厂家确定终端能否正确理解系统下发的测量控制消息，对于不能按照协议理解测量控制消息的终端确定如何

31、解决处理。B、核心网进行策略调整。从2G核心网对类似事件处理的方法和流程来看，目前核心网简单丢弃消息不做处理的策略是需要商榷的。如果核心网考虑需要Iu释放过程中0.17秒的保护避免Iu口拥塞，应该给RNC返回RelocationPreparationFailure消息，失败原因为interaction_with_ other_procedure，表示当前上一流程并未结束；或者可以缓存处理，先将请求排队，等待资源释放后处理（中兴RNC侧在发送请求后设置了10秒定时器）。目前华为核心网计划返回RelocationChancel消息（切换失败原因值使用Message not compatible w

32、ith receiver state (99)），来解决该问题。C、接入网进行策略调整。1）如果无线侧能够对终端上报的非法测量报告进行控制，而不是只对切换条件进行判断就决定向核心网请求，就能够避免该问题发生。RNC V1.30.110C3之前的版本在切换成功后首先关闭测量再打开测量，这种方式也能够有效抑制该问题的发生。但是这种方式有可能导致另一种情况的发生：即UE上报测量报告后，由于某种原因未收到网络侧下发的消息，导致UE不测量不上报，最终被拖死掉话。2）使系统抑制乒乓切换的参数起作用（例如抑制乒乓切换惩罚时间），减少乒乓切换的影响。（但是无法消除类似A（RNC1）->B（RNC2）-&

33、gt;C（RNC1）的情况发生） 目标小区同步失败问题图 6 硬切换时与目标小区同步过程硬切换过程中在收到RB重配消息后，UE需要同目标小区建立同步，在此期间容易由于UP时隙干扰或UE没有收到FPACH，导致RB重配失败。现场分析的主要原因分类为：A、UP时隙干扰。当用户处于弱场区域、小区边缘时此问题会更加明显。在信号较强区域不会太明显，这就是路测时切换指标良好，而后台指标较差的原因之一。在9月25日对全网室外UP时隙干扰大于-90dBm的小区进行UP偏移后，RNC间切换成率有所提升。但是由于目前UPshifting会占用TS1时隙，导致上行容量的减小，尤其是S111等单载频的

34、站点影响更大。对混合业务（6终端同车）测试会有一定的影响。要综合考虑上行容量和KPI提升的关系，找到平衡点，毕竟RNC间切换次数相对全网比例较小。B、无线环境差导致UE没有收到FPACH。主要是一些无室内分布的楼宇（住宅所占比重较大）及覆盖弱区。C、基站同步帧问题。当该问题发生时站间切换掉话率100%。UP时隙干扰典型事件：三八里小区2 图 7 三八里小区站点位置示意图图 8 测量报告中显示的目标小区信息图 9 三八里小区2重定位取消CT信令 目标小区12541 Up时隙干扰统计：TRNS子网服务小区 IDMax_UpPCH_POSSYRNS2(402)12541-94.5dBm表 2无线环境

35、差典型事件皇姑热力供暖1图 10 皇姑热力供暖站点位置示意图图 11 CT信令两个站点相距1.2km，用户在弱场进行切换，导致RB重配失败。基站帧问题典型事件：劳动大厦三个小区与其它站点小区间无论是同一RNC还是不同RNC小区间切换（切入切出）AMR和CS64k都会掉话（100%掉话）；PS业务切换正常未出现掉话与起呼失败现象，切换成功后进行Cell Update失败掉话；本站三个小区间切换正常未掉话。前台路测信令：图 12 前台路测信令可以看出UE上发物理信道重配置，之后掉话。后台跟踪信令:图 13 后台跟踪信令可以看出RNC下发了物理信道重配置，并没有收到UE上发的物理信道重配置完成，且N

36、odeB上报RL失败，进行CALLUPDATE未成功，导致掉话。原因为上行同步出现问题，此问题和用服同事进行排查，发现劳动大厦的SFN帧号为奇数导致。通过运行GPS脚本，并进行系统帧号同步后，UE可以和其他站点正常切换。此问题会造成切换失败、掉话。在版本没有升级解决前，需重点关注，尽量找到有问题的站点进行处理，对提升KPI会有比较明显的效果。 邻区参数设置问题网络中存在邻小区关系的漏配或单边邻区的情况，或存在邻区同频同扰码情况，导致虚假的邻小区关系造成切换失败。此类问题已经通过奥运期间对全网扰码与邻区关系的检查、梳理，在封网结束后通过全网调整解决。3.10.4 后期工作3.10

37、.4.1 工作建议1、由于终端测量问题引起的，需要移动推动核心网与终端厂商协同解决，同时我司无线网络系统侧也应该考虑规避的手段与措施。2、由于UE和目标小区不能上行同步问题导致的需要区别对待。对UP时隙有干扰的小区进行UPShifting，规避UP时隙干扰；检查目标NodeB是否正常工作，系统帧是否同步，排除NodeB故障。3、由于新建站点、无线环境变化等因素，需要对邻区参数设置进行相应修改。 问题排查思路该问题与无线信号质量、无线参数设置或终端相关，因此需要确定故障发生位置和用户终端。1、可以查看对应计数器“RNC间切换出失败次数”。得到发生次数多的源小区列表。2、检查邻区与扰码参数（可使用后台合法性参数检查排除同频同扰码邻区），查看是否在附近区域存在同频同扰码的小区，导致虚假信号。3、通过CallTrace找到相关异常呼叫记录。将由于终端问题导致的剔除（回访用户记录终端类型）。确定是否为同一用户多次反复乒乓切换失败，确定用户IMSI，通过回访用户，确定故障发生地点、